Bug#842237: zfsutils-linux: 0.6.5.9-2 still fails - zfs-share.service

[Fabian Grünbichler]

On Mon, Mar 13, 2017 at 02:22:16PM -0400, Mike Fiedler wrote:
> Package: zfsutils-linux
> Version: 0.6.5.9-2
> Followup-For: Bug #842237
> 
> Dear Maintainer,
> 
> zfs-share.service fails to start:
> 
> <
> Mar 13 13:40:34 deb01 systemd[1]: Starting ZFS file system shares...
> -- Subject: Unit zfs-share.service has begun start-up
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> --
> -- Unit zfs-share.service has begun starting up.
> Mar 13 13:40:34 deb01 zed[11499]: eid=2 class=config.sync pool=rpool
> Mar 13 13:40:34 deb01 systemd[11500]: zfs-share.service: Failed at step EXEC 
> spawning /usr/bin/rm: No such file or directory
> -- Subject: Process /usr/bin/rm could not be executed
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> --
> -- The process /usr/bin/rm could not be executed and failed.
> --
> -- The error number returned by this process is 2.
> >
> 
> I checked the changelog for 0.6.5.9-3 and I also do not see  /bin/rm  
> changed/added for the x86 32&64 arch for "dh_auto_configure"
> 
> Thank you!
> 
> Mike
> 
> 
> 

I think 0.6.5.9-1 closed this one prematurely - only the second part of
my proposed fixes was applied, the first one (hardcoding "/bin/rm"
instead of "@bindir@/rm" was missed (I attached a full patch again this
time).
>From 190dfc116dfa539a8e1e40c120e4b961c986c2ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabian=20Gr=C3=BCnbichler?= 
Date: Thu, 27 Oct 2016 10:18:55 +0200
Subject: [PATCH] fix rm path in zfs-share.service
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Fabian Grünbichler 
---
 etc/systemd/system/zfs-share.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/etc/systemd/system/zfs-share.service.in b/etc/systemd/system/zfs-share.service.in
index 688731e..494f5cb 100644
--- a/etc/systemd/system/zfs-share.service.in
+++ b/etc/systemd/system/zfs-share.service.in
@@ -9,7 +9,7 @@ PartOf=smb.service
 [Service]
 Type=oneshot
 RemainAfterExit=yes
-ExecStartPre=-@bindir@/rm -f /etc/dfs/sharetab
+ExecStartPre=-/bin/rm -f /etc/dfs/sharetab
 ExecStart=@sbindir@/zfs share -a
 
 [Install]
-- 
2.1.4

Bug#860870: RFS: docopt.cpp/0.6.2-2

[Ghislain Antony Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "docopt.cpp"

* Package name: docopt.cpp
  Version : 0.6.2-2
  Upstream Author : Jared Grubb
* URL : https://github.com/docopt/docopt.cpp
* License : MIT / BSL
  Section : libs

One can check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/docopt.cpp.git

Changes since the last upload:

  * Switch from git-dpm to gbp
- Drop git-dpm configuration
- Unapply patch queue
- Add gbp configuration
  * Refresh and drop numbering of the patch queue
  * Fixup the VCS-Browser URI
  * Support the nocheck build profile
- Add versioned b-dep on dpkg-dev
- Mark test b-deps as !nocheck
- Use DEB_BUILD_PROFILES in nocheck guards
  * Run the tests using Python 3 instead of Python 2
- Testing now depends on any Python 3 interpreter
- New patch Make-tests-compatible-with-Python-3.patch
  * Fixup the Maintainer and Uploaders fields
- Move myself from Maintainer to Uploaders
- Set the Debian Science Team as Maintainer

Best regards,
Ghis

Bug#860869: ghostscript: CVE-2016-10317: Heap-buffer overflow in the fill_threshold_buffer function

[Salvatore Bonaccorso]

Source: ghostscript
Version: 9.20~dfsg-3
Severity: important
Tags: upstream security
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=697459

Hi,

the following vulnerability was published for ghostscript.

CVE-2016-10317[0]:
| The fill_threshhold_buffer function in base/gxht_thresh.c in Artifex
| Software, Inc. Ghostscript 9.20 allows remote attackers to cause a
| denial of service (heap-based buffer overflow and application crash) or
| possibly have unspecified other impact via a crafted PostScript
| document.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10317
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10317
[1] https://bugs.ghostscript.com/show_bug.cgi?id=697459

The reproducer is not yet public available, and the severity should
probably be increased due to the heap buffer overflow. But we can
ammend once more details public.

Regards,
Salvatore

Bug#860868: RFS: xtensor-python/0.10.0-1

[Ghislain Antony Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

* Package name: xtensor-python
  Version : 0.10.0-1
  Upstream Author : Johan Mabille and Sylvain Corlay
* URL : http://quantstack.net/xtensor
* License : BSD
  Section : libs

One can check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/xtensor-python.git

Changes since the last upload:

  * New upstream version 0.10.0
  * Refresh the patch queue
  * Build depends on xtensor >= 0.9.0

Best regards,
Ghis


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

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

Bug#860865: Correction to my previous suggestion

[Stephane Lapie]

Further investigation in the internals of select() showed me I initially
misunderstood how FD_SET worked.

This restriction was to ensure the number of the FDs themselves do not go
over 1023, because if an accept()ed connection receives such a number, it
will be impossible to insert it in a FD_SET and to manage it via select().

The only proper way to avoid this bug would be to prevent accepting of
connections after 900 or 1000.
Alternatively, rejecting connections outside of select() when the FD number
is above FD_SETSIZE.

Neither are desirable solutions, but the alternative is to stop using
select(), which means a significant rewrite of Sendmail.
-- 
ラピー ステファン Lapie Stephane
株式会社朝日ネット システム部

Bug#860867: RFS: xtensor/0.9.0-1

[Ghislain Antony Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

* Package name: xtensor
  Version : 0.9.0-1
  Upstream Author : Johan Mabille and Sylvain Corlay
* URL : http://quantstack.net/xtensor
* License : BSD
  Section : libs

One can check out the package by visiting the following URL:

  https://anonscm.debian.org/git/debian-science/packages/xtensor.git

Changes since the last upload:

  * New upstream version 0.9.0

Best regards,
Ghis


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

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

Bug#860866: activemq: CVE-2015-7559: DoS in client via shutdown command

[Salvatore Bonaccorso]

Source: activemq
Version: 5.6.0+dfsg1-4
Severity: important
Tags: upstream patch security
Forwarded: https://issues.apache.org/jira/browse/AMQ-6470

Hi,

the following vulnerability was published for activemq.

CVE-2015-7559[0]:
DoS in client via shutdown command

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-7559
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7559
[1] https://issues.apache.org/jira/browse/AMQ-6470
[2] https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=b8fc78e

I'm not too familiar with activemq, but from code inspection only the
class (although on different path in the source) is present back as
well in the version in jessie.

Regards,
Salvatore

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Salvatore Bonaccorso]

Hi Lars,

On Fri, Apr 21, 2017 at 06:07:40AM +0200, Lars Tangvald wrote:
> Hi,
> 
> I lost internet connectivity where I am right now, so probably unable to get
> this done until Monday. Could maybe use the previous debdiff for Jessie if
> you're ok with closing the bug manually.
> Also, I think we still don't have any active members in the maintainer team
> with upload access for 5.5

Okay, I will look if I can take care of the upload for
jessie-security.

Regards,
Salvatore

Bug#860865: sendmail: arbitrary setrlimit(1024, 1024) causes file descriptor starvation

[Stephane Lapie]

Package: sendmail-bin
Version: 8.14.4-4+deb7u1
Severity: important
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?

Running Sendmail as a production mail server for front-line processing
(determining if e-mail should be accepted for further processing or not)
with a constant flow of 100msgs/s spanned over 4 servers.

At peak time, it happens that the open file limit for the process is
reached. Sendmail runs limited to 1024 file descriptors, which can be
verified with the following command :

$ cat /proc/`pgrep sendmail`/limits  | grep "open file"
Max open files1024 1024 files

File descriptor starvation causes sendmail to be unable to do name resolution
for the next SMTP relay server, either by means of DNS query, or of /etc/hosts.

This in turn causes e-mail to be deferred or bounced, and since it can not
resolve the relay host name for bouncing, this can cause messages to be
discarded after accepting them.

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

I tried modifying the limits by hand before launching sendmail,
by inserting a "ulimit -Sn 4096" command in /etc/default/sendmail,
expecting it to be ran during the init script.

(This is ran on a server that does not use systemd as its init system)

   * What was the outcome of this action?

Investigation reveals that sendmail has hardcoded a setrlimit() call
for open files, limiting it to FD_SETSIZE (1024) no matter what.
The initial "ulimit -Sn 4096" call is overridden by sendmail itself,
and the open files limit does not change.

   * What outcome did you expect instead?

I understand the limiting to FD_SETSIZE since sendmail relies on select(),
but this only takes in account mail-processing related connections,
and not any other file descriptor sendmail itself might need to open to work.

I would at the very least expect sendmail to have some leeway for other file
descriptors. (Such as running setrlimit() with more than FD_SETSIZE)

Ideally, the user should be able to set this limit by way of configuration,
or at least be able to override it via the initialization script like I tried,
since it is not intrusive to sendmail's code.

The easiest way would be to patch the resetlimits() function
(called from main.c at line 1357, defined in conf.c at line 3751)
so that it :
- Checks whether FD_SETSIZE is inferior to the current limitation before
  applying it
- allocates FD_SETSIZE + N descriptors (N being a value such as 64 or 128,
though personal taste would lean towards higher values)

These limits are supposedly in place to avoid denial-of-service, but in my
situation they end up aggravating the situation.

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


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sendmail-bin depends on:
ii  debconf1.5.56
ii  libc6  2.19-18+deb8u4
ii  libdb5.3   5.3.28-9
ii  libldap-2.4-2  2.4.40+dfsg-1+deb8u2
ii  liblockfile1   1.09-6
ii  libsasl2-2 2.1.26.dfsg1-13+deb8u1
ii  libssl1.0.01.0.1t-1+deb8u2
ii  libwrap0   7.6.q-25
ii  procps 2:3.3.9-9
pn  sendmail-base  
pn  sendmail-cf

sendmail-bin recommends no packages.

Versions of packages sendmail-bin suggests:
pn  libsasl2-modules  
ii  openssl   1.0.1t-1+deb8u2
pn  sasl2-bin 
pn  sendmail-doc  

Bug#860864: unblock: distro-info-data/0.35

[Stefano Rivera]

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

Please unblock package distro-info-data

Ubuntu 17.04 has now released, and we need to add 17.10.

Of course there will still need to be one more update of
distro-info-data once stretch has a release date (that could be after
the release).

unblock distro-info-data/0.35

Thanks,

SR
diff -Nru distro-info-data-0.33/debian/changelog 
distro-info-data-0.35/debian/changelog
--- distro-info-data-0.33/debian/changelog  2017-01-15 15:53:52.0 
-0800
+++ distro-info-data-0.35/debian/changelog  2017-04-20 19:43:47.0 
-0700
@@ -1,3 +1,15 @@
+distro-info-data (0.35) unstable; urgency=medium
+
+  * Correct Ubuntu Zesty release date.
+
+ -- Stefano Rivera   Thu, 20 Apr 2017 19:43:47 -0700
+
+distro-info-data (0.34) unstable; urgency=medium
+
+  * Add Ubuntu 17.10, Artful Aardvark.
+
+ -- Stefano Rivera   Thu, 20 Apr 2017 16:42:23 -0700
+
 distro-info-data (0.33) unstable; urgency=medium
 
   * Add Debian 11 codename (with provisional creation date) (Closes: #851447)
diff -Nru distro-info-data-0.33/ubuntu.csv distro-info-data-0.35/ubuntu.csv
--- distro-info-data-0.33/ubuntu.csv2016-10-21 15:48:30.0 -0700
+++ distro-info-data-0.35/ubuntu.csv2017-04-20 19:43:47.0 -0700
@@ -24,4 +24,5 @@
 15.10,Wily Werewolf,wily,2015-04-23,2015-10-22,2016-07-22
 16.04 LTS,Xenial Xerus,xenial,2015-10-22,2016-04-21,2021-04-21
 16.10,Yakkety Yak,yakkety,2016-04-21,2016-10-13,2017-07-20
-17.04,Zesty Zapus,zesty,2016-10-13,2017-04-20,2018-01-25
+17.04,Zesty Zapus,zesty,2016-10-13,2017-04-13,2018-01-25
+17.10,Artful Aardvark,artful,2017-04-13,2017-10-19,2018-07-19

Bug#858163: unblock: gitlab/8.13.11+dfsg-6

[Pirate Praveen]

Control: tags -1 -moreinfo

On Saturday 15 April 2017 01:24 AM, Niels Thykier wrote:
> Sorry for the delay in getting back to you.

Thanks for the detailed review.

> 
>  * In the postrm (RC bug):
> 
> """
> su ${gitlab_user} -c 'psql gitlab_production -c ""' && \
>su postgres -c "dropdb gitlab_production"
> """
> 
> This does not appear to be idempotent.  If the database is dropped but a
> later part of the purge fails, then this line will prevent dpkg from
> rerunning the purge and reach the desired state (as the code is run
> under "set -e")
> 
> You probably want something like:
> 
> """
>   if su ${gitlab_user} -c 'psql gitlab_production -c ""'; then
>  su postgres -c "dropdb gitlab_production"
>   fi
> """

done

> A similar remark can be made for the following code where it would be
> prudent to apply the same fix:
> 
> """
> test -e ${gitlab_log_dir} && rm -rf ${gitlab_log_dir}
> test -e ${gitlab_cache_path} && rm -rf ${gitlab_cache_path}
> test -e ${gitlab_pid_path} && rm -rf ${gitlab_pid_path}
> test -e ${gitlab_data_dir} && rm -rf ${gitlab_data_dir}
> [...]
>   id -u ${gitlab_user} && userdel -r ${gitlab_user}
> 
> [...]
> test -f ${nginx_site} && echo "Found nginx site"
> [...]
> # remove the configuration file itself
> test -f ${nginx_site} && rm -f ${nginx_site}
> test -f ${gitlab_debian_conf} && rm -f ${gitlab_debian_conf}
> test -f ${gitlab_yml} && rm -f ${gitlab_yml}
> test -f ${gitlab_tmpfiles} && rm -f ${gitlab_tmpfiles}
> test -f ${gitlab_shell_config} && rm -f ${gitlab_shell_config}
>   [...]
>   test -n "${nginx_site}" && ucf --purge ${nginx_site}
>   test -n "${gitlab_debian_conf}" && ucf --purge ${gitlab_debian_conf}
>   test -n "${gitlab_yml}" && ucf --purge ${gitlab_yml}
>   test -n "${gitlab_tmpfiles}" && ucf --purge ${gitlab_tmpfiles}
>   test -n "${gitlab_shell_config}" && ucf -purge ${gitlab_shell_config}
>   [...]
>   test -n "${nginx_site}" && ucfr --purge gitlab ${nginx_site}
>   test -n "${gitlab_debian_conf}" && ucfr --purge gitlab
> ${gitlab_debian_conf}
>   test -n "${gitlab_yml}" && ucfr --purge gitlab ${gitlab_yml}
>   test -n "${gitlab_tmpfiles}" && ucfr --purge gitlab ${gitlab_tmpfiles}
>   test -n "${gitlab_shell_config}" && ucfr -purge gitlab
> ${gitlab_shell_config}
> 
> """

This also done.

> Note I got a follow up remark for the "id+userdel" line below.  As for
> the "test -n", these mean that the script will fail if these values are
> not (still) present in the config OR worse - if the gitlab config is
> already deleted (this is also listed a separate item below)
> 

Changed to if; then;fi like above.

> 
>  * debian/postrm (RC bug):
> 
> The postrm will fail if the admin removes the gitlab config files prior
> to purging gitlab.  This happens because then most of the variables are
> set and as shown above, this will make several test statements evaluate
> to false on the left-hand-side of an && under "set -e".
> 
> Admittedly, this is partly mitigated by gitlab providing its own default
> as a copy under /var/lib/gitlab/gitlab-debian.defaults.  But in theory,
> the machine could fail after removing
> "/var/lib/gitlab/gitlab-debian.defaults" but prior to dpkg committing
> that it had purged gitlab.
> 
> It is an unlikely corner-case, but as it leaves the admin with an
> unpurgeable package it is RC.  To my knowledge, it is *not* sufficient
> to make the removal of the /var/lib file the last thing.  That just
> narrows the window for the issue without fixing it.

Now all conditions are inside if; then; fi blocks so it will ot fail if
file is removed already. If the variables are not defined, it won't try
deletion.

>  * debian/postrm (important)
> 
> As I recall, the general consensus on handling of system users is that
> we should lock them rather than remove them.  The gitlab postrm deletes
> the user:
> 
> """
>   id -u ${gitlab_user} && userdel -r ${gitlab_user}
> """
> 
> That said, I believe gitlab is not the only package deleting the user,
> so it is not RC.

I have kept it like before for now.

>  * debian/config (important/RC bug):
> 
> The config file uses the debconf database as a registry.  It should
> "pre-seed" itself with the defaults from the configuration files.  See
> "man 8 debconf-devel" under "config file handling":
> 
> https://manpages.debian.org/jessie/debconf-doc/debconf-devel.7.en.html#ADVANCED_PROGRAMMING_WITH_DEBCONF
> 

all variables are now seeded from config file.

>  * debian/postinst (RC bug):
> 
> """
>   # Override User for systemd services
>   for service in mailroom unicorn sidekiq workhorse; do
> path=/etc/systemd/system/gitlab-${service}.service.d
> mkdir -p $path
> printf "[Service]\nUser=${gitlab_user}\n" > $path/override.conf
>   done
> """
> 
> This part appears to override
> "/etc/systemd/system/gitlab-${service}.service.d/override.conf"
> 

Bug#860782: libnauty2-dev: suggest include geng.c source

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Kelvin, thanks a lot for your suggestion.
Jerome

On 20/04/17 06:35, Kevin Ryde wrote:
> Package: libnauty2-dev
> Version: 2.6r7+ds-1
> Severity: wishlist
> 
> The source codes geng.c, gentourng.c, gentreeg.c have some #define
> GENG_MAIN stuff allowing them to be included in a user program.  Those
> files could be helpfully included in the package for that.  Not certain
> where they might best live, maybe /usr/share/nauty/.
> 
> callgeng.c example program shows the way to use them.  Perhaps it would
> go with the other examples in /usr/share/doc/nauty-doc/examples.  Though
> the Makefile there might then want the special compile rule shown in
> callgeng.c and perhaps plus -I/usr/include/nauty, unless wanted to
> change geng.c #include "gtools.h" to  which is where
> that file is packaged.  That could be helpful for all uses.
> 
> 
> -- System Information:
> Debian Release: 9.0
> Architecture: i386 (i686)
> 
> Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
> Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages libnauty2-dev depends on:
> ii  dpkg   1.18.23
> ii  libnauty2  2.6r7+ds-1
> 
> libnauty2-dev recommends no packages.
> 
> Versions of packages libnauty2-dev suggests:
> ii  nauty-doc   2.6r7+ds-1
> ii  pkg-config  0.29-4+b1
> 
> -- no debconf information
> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJY+YbFAAoJED+SGaZ/NsaL1Q4gALSCTOiTD7ZT1XrKpxqbobAp
rWT3kfpgN//bJApYTpNuWoVjcDIjqLTWLil1Cp9Qtc1dohu4QE6KE3RosOJ6Yx6i
3pEdLMWfCa0JupAp7HPLvvTdFQo5QlcjXzamQEXQMYtg40RbeLwqF2caUBHN3HcM
0j/qTmzShxJUQq8iH2BHsZGzzNwkpAHrU0+nGFk4DglUruJs/sej6jRy97vCh0dr
3UCOoInnWu1LGq8vQ/trHSspreZyMEQOmQJ0eU7a0mZMwnxyLQapSnT3JyVYUWmL
UOtJvVh0cysOfP5jDCXhx6UhEbC1J7ndrcr+dAEzdqgBxiYlByw0cxZzDpbLmNK7
6HjRYFdmoQ9u2FPwQlQDqghj1EosOtZAjmsLYEfi/Xx7t1eoCdaitj2FjiHn203u
q77L5aufM16sNsfbehUepPSB7rwZw4LCfdEuURRQQ/X0EZnKr6MPc5MPI68ayq5p
1tosAi1BgkADFKnq9Ehg5rKaAL3Ft5og3fjUJmoeYRdMgBOU/ylCfd/ctssB+eYi
40TKJx+McGHeXmK99brQg46OSzqiAzyECsypJV3ADFbWKS33OCYNW0Ggt4lBrAeH
RhQJNZYE9p2gm2I0PE3J/dad5jLjab1L1MlssHRkVXwoM/Jbj1v0/FYB8xuUNywJ
CWk6bZP717Caj+4h4hCobjnnmFJb9oCXNk3BEJ+9IljaRw7q4vRzBsE1TaocoNv2
8wzVm5TwkcDmvjDm0Li3jE7SZfiDV5y/Rwzs35qDLgtIXktfEkkwbXGuhbunjpSe
7NA6mV1wHwAWolXR2VVYx04AkfGCV29GUJg1dvWGQW7YQ8tBn2OCBQ8frlFwkAQ8
0Qf4p/s1MX5dpe013JhmtszPIuSWvIA7p1fpYkuu+/lfbmxMtyWApEkaymsviAE0
Ly/RJ48I21DlKPOqBATVJQAZrwLOOy3zjRxS2GAqB3rybqLE6j0+Kl0LQTdt7V++
iLl3wu7sNYTuygwYA4x+CT1TzLxh9hxoYyMBhPjaU+wCOky32f8A2XG3exPu1blH
Zk2QSC/j575kp1Il937KB3hqT0DJ11viYW+tk/c37y1vxx/KkwhpMV+DySxpCT0m
/5pRMPvOpQ1R8sWcDcZsCkCib6Z5ZtHUcgWZTSM5ZNO0UlZN6gatsvjzG1AgcWrF
nkmtUBUK+zKrz8Dt99euc9xoBT9I5whUEo2Wvp1zwfY0ajuNhJIvuNyl6NB3XcQp
e98WANaYZVbGFnmL7CuGBVKVOo9ioe1pvGdJFsVoU8T1/KcMiyJPw82q29wZKeBv
eNGnL5U0WX2j3VSUo7UtFXhp6tuwTtHQJcJQBV6GeJeMjDa+ZHy2sT072zrRh2o=
=As8C
-END PGP SIGNATURE-

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

[Lumin]

Hi Adam,

Thank you for reviewing this package!

Updated package was uploaded to mentors:
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

and debomatic:
http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog

Changes:
* fixed the mistaken /lib//libxxx.a install path.
The static library didn't drop
  sip_tree_hash.o object.
* patched upstream makefile to produce a shared object file
(sip_tree_hash.o is dropped from so file)
* added symbols control file
* override dh_auto_test to run upstream test binaries (except for the
"benchmark").

Is it acceptable now?
:-)

On 20 April 2017 at 16:08, Adam Borowski  wrote:
> On Thu, Apr 20, 2017 at 10:35:41AM +, Lumin wrote:
>>   I am looking for a sponsor for my package "highwayhash"
>>
>>  * Package name: highwayhash
>>Upstream Author : google
>>  * URL : https://github.com/google/highwayhash
>
>>   It builds those binary packages:
>>
>> libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash
>
> You install the .a file into /lib, that's a place for important boot-time
> shared libraries, not for stuff that's used only during compilation.
>
> I see no shared library at all -- why do you provide only a static version?
> That's useful only for limited special uses, unfit for a general purpose
> library.  Static libs might sort-of work for Google's internal projects, as
> they have a centralized tightly managed infrastructure so "recompile world"
> for every single bug fix is doable, but in a loose ecosystem such as a
> distribution it's unfeasible.  You might get away with static libs if you
> closely cooperate with all of your reverse dependencies, but that's
> pointless for a library meant for wide use, such as hashes.
>
> Also, the SipTreeHash runs only a small set of CPUs and thus is useless for
> an universal distibution.  The other two hashes provide portable versions
> that work on every CPU of every arch, but as SipTreeHash gives a different
> output, its inclusion is kind of pointless.
>
>
> Your choices may differ, but I'd make the following changes:
> * provide a shared library
> * drop the static one -- or at least move it into the proper place
> * disable SipTreeHash, as failing at compile time rather than runtime is
>   nicer to users
>
> --
> ⢀⣴⠾⠻⢶⣦⠀ Meow!
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
> ⠈⠳⣄ preimage for double rot13!



-- 
Best,
Lumin

Bug#860341: Issue fixed

[Julien Aubin]

Hi,

Just this small message to confirm that w/ new libmtp version things work.

Rgds

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

Hi,

I lost internet connectivity where I am right now, so probably unable to 
get this done until Monday. Could maybe use the previous debdiff for 
Jessie if you're ok with closing the bug manually.
Also, I think we still don't have any active members in the maintainer 
team with upload access for 5.5


--
Lars

On 19. april 2017 15:30, Salvatore Bonaccorso wrote:

Hi Lars,

On Wed, Apr 19, 2017 at 04:26:30AM -0700, Lars Tangvald wrote:

Hi,


We've prepared and tested the update to MySQL 5.5.55 for Jessie.
Debdiff output is attached.
Only packaging changes are one refreshed patch and one that is no
longer needed (5.5.54 for Wheezy had an additional patch added,
which is also no longer needed).

Thanks for preparing the update.

CVE-2017-3302 is as well know nin BTS as #854713, can you add a bug closer for
this one as well? If it's too much of hassle, then leave it, and we close it
manually.

Ok, please upload to security-master.

Regards,
Salvatore

Bug#860863: devscripts: Fix debsnap to preserve the mtime

[Guillem Jover]

Package: devscripts
Version: 2.17.5
Severity: wishlist
Tags: patch

Hi!

While importing some orig tarballs into git, found out that
gbp-import-dsc was using the wrong time. Regardless of the command
using the current localtime, or the file mtime, the latter would be
definitely wrong in this case when fetched via debsnap anyway, so it
would not be usable for the commit.

The attached patch, changes it to preserve the remote mtime, which I
think it's a more correct behavior.

Thanks,
Guillem
From 31b4b6d3b16e7a4aed44bb480e91c15ec5c795ef Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 21 Apr 2017 04:51:31 +0200
Subject: [PATCH] debsnap: Use the remote mtime when creating the local file

Making a more exact copy, is useful so that you can see when the orig
tarball was created, and it can be used further as the timestamp when
importing into git for example.
---
 scripts/debsnap.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/debsnap.pl b/scripts/debsnap.pl
index 8a3bf0ff..4f0ae0a9 100755
--- a/scripts/debsnap.pl
+++ b/scripts/debsnap.pl
@@ -320,7 +320,7 @@ elsif ($opt{binary}) {
 	if (!have_file("$opt{destdir}/$file_name", $hash)) {
 		verbose "Getting file $file_name: $file_url";
 		$mkDestDir->();
-		LWP::Simple::getstore($file_url, "$opt{destdir}/$file_name");
+		LWP::Simple::mirror($file_url, "$opt{destdir}/$file_name");
 	}
 	}
 }
@@ -354,7 +354,7 @@ else {
 	if (!have_file("$opt{destdir}/$file_name", $hash)) {
 		verbose "Getting file $file_name: $file_url";
 		$mkDestDir->();
-		LWP::Simple::getstore($file_url, "$opt{destdir}/$file_name");
+		LWP::Simple::mirror($file_url, "$opt{destdir}/$file_name");
 	}
 	}
 }
-- 
2.12.2.816.g281164

Bug#860862: linux-image-3.16: fragmented ipv6 packets can't be forwarded

[Jonathan Lane]

Package: src:linux
Version: 3.16.39-1+deb8u2
Severity: important
Tags: upstream ipv6

Dear Maintainer,

The fix for Ubuntu bug #1463911 (fragmented IPv6 packets can't be forwarded) 
never made it upstream to Debian.  This breaks Jessie as an IPv6-capable router 
or VM host.  It was fixed upstream in Linux 4.2.  Please consider backporting a 
fix to 3.16 as the 4.x kernels in jessie-backports do not receive security 
patches.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1463911

Thanks,

Jon Lane

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 
root=UUID=da0aca99-dfd8-473d-b0ce-6ec8ca5df2e7 ro quiet

** Not tainted

** Kernel log:
[2830694.134287] audit: type=1326 audit(1492739057.790:202034): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5125 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830695.471015] audit: type=1326 audit(1492739059.130:202035): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5137 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830696.863909] audit: type=1326 audit(1492739060.522:202036): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5141 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830698.312669] audit: type=1326 audit(1492739061.970:202037): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5153 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830700.838154] audit: type=1326 audit(1492739064.494:202038): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5166 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830712.368568] audit: type=1326 audit(1492739076.018:202039): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5216 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830718.091916] audit: type=1326 audit(1492739081.737:202040): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5248 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830748.993413] audit: type=1326 audit(1492739112.621:202041): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5462 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830762.044798] audit: type=1326 audit(1492739125.665:202042): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5522 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830775.181467] audit: type=1326 audit(1492739138.793:202043): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5584 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830805.669545] audit: type=1326 audit(1492739169.264:202044): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5720 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830812.181314] audit: type=1326 audit(1492739175.772:202045): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5750 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830832.528853] audit: type=1326 audit(1492739196.108:202046): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5843 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830862.377829] audit: type=1326 audit(1492739225.940:202047): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=5974 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830891.097947] audit: type=1326 audit(1492739254.644:202048): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=6097 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830912.486156] audit: type=1326 audit(1492739276.019:202049): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=6196 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830913.242553] audit: type=1326 audit(1492739276.775:202050): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=6199 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830956.202979] audit: type=1326 audit(1492739319.711:202051): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=6415 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2830974.834368] audit: type=1326 audit(1492739338.331:202052): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=6496 comm="vsftpd" exe="/usr/sbin/vsftpd" 
sig=31 syscall=37 compat=0 ip=0x7f9a5945dcc7 code=0x0
[2831012.830962] audit: type=1326 audit(1492739376.306:202053): auid=4294967295 
uid=114 gid=123 ses=4294967295 pid=

Bug#856590: systemd: Unspecified problems mounting /usr partition

[Joel Cross]

On Wed, 12 Apr 2017, at 02:28 PM, Michael Biebl wrote:
> Am 12.04.2017 um 22:11 schrieb Joel Cross:
> > Mar 29 21:25:09 abijah systemd[1]: 
> > dev-disk-by\x2duuid-F0C4F042C4F00C9A.device: Job 
> > dev-disk-by\x2duuid-F0C4F042C4F00C9A.device/start failed with result 
> > 'timeout'.
> > Mar 29 21:25:09 abijah systemd[1]: 
> > dev-disk-by\x2duuid-0797ee37\x2dd1b9\x2d49ea\x2da865\x2dc73682cd96a7.device:
> >  Job 
> > dev-disk-by\x2duuid-0797ee37\x2dd1b9\x2d49ea\x2da865\x2dc73682cd96a7.device/start
> >  timed out.
> > Mar 29 21:25:09 abijah systemd[1]: Timed out waiting for device 
> > dev-disk-by\x2duuid-0797ee37\x2dd1b9\x2d49ea\x2da865\x2dc73682cd96a7.device.
> > Mar 29 21:25:09 abijah systemd[1]: Dependency failed for 
> > /dev/disk/by-uuid/0797ee37-d1b9-49ea-a865-c73682cd96a7.
> > Mar 29 21:25:09 abijah systemd[1]: 
> > dev-disk-by\x2duuid-0797ee37\x2dd1b9\x2d49ea\x2da865\x2dc73682cd96a7.swap: 
> > Job 
> > dev-disk-by\x2duuid-0797ee37\x2dd1b9\x2d49ea\x2da865\x2dc73682cd96a7.swap/start
> >  failed with result 'dependency'.
> > Mar 29 21:25:09 abijah systemd[1]: 
> > dev-disk-by\x2duuid-0797ee37\x2dd1b9\x2d49ea\x2da865\x2dc73682cd96a7.device:
> >  Job 
> > dev-disk-by\x2duuid-0797ee37\x2dd1b9\x2d49ea\x2da865\x2dc73682cd96a7.device/start
> >  failed with result 'timeout'.
> > Mar 29 21:25:09 abijah systemd[1]: 
> > dev-disk-by\x2duuid-868996eb\x2d2b9d\x2d42eb\x2d9bcc\x2d2b23b89dc11b.device:
> >  Job 
> > dev-disk-by\x2duuid-868996eb\x2d2b9d\x2d42eb\x2d9bcc\x2d2b23b89dc11b.device/start
> >  timed out.
> > Mar 29 21:25:09 abijah systemd[1]: Timed out waiting for device 
> > dev-disk-by\x2duuid-868996eb\x2d2b9d\x2d42eb\x2d9bcc\x2d2b23b89dc11b.device.
> > Mar 29 21:25:09 abijah systemd[1]: Dependency failed for /home.
> > Mar 29 21:25:09 abijah systemd[1]: Dependency failed for Local File Systems.
> > Mar 29 21:25:09 abijah systemd[1]: local-fs.target: Job 
> > local-fs.target/start failed with result 'dependency'.
> > Mar 29 21:25:09 abijah systemd[1]: local-fs.target: Triggering OnFailure= 
> > dependencies.
> > Mar 29 21:25:09 abijah systemd[1]: home.mount: Job home.mount/start failed 
> > with result 'dependency'.
> > Mar 29 21:25:09 abijah systemd[1]: 
> > dev-disk-by\x2duuid-868996eb\x2d2b9d\x2d42eb\x2d9bcc\x2d2b23b89dc11b.device:
> >  Job 
> > dev-disk-by\x2duuid-868996eb\x2d2b9d\x2d42eb\x2d9bcc\x2d2b23b89dc11b.device/start
> >  failed with result
> 
> Your problem doesn't look like it's related to /usr, but /home and swap,
> as configured in /etc/fstab, failing.
> 
> Can you please verify that that you have in /etc/fstab actually matches
> your current configuration.

Hi,

I'm pretty sure the failure actually occurs with all three partitions,
but it is more severe with /usr because I cannot use the 'nofail' option
to ignore the failure.

Here's the relevant part of my /etc/fstab:
UUID=1ac3a9b3-2ced-4e6c-9378-f8c94ac2983e   /usrext4   
rw,errors=remount-ro,commit=600 0   1
# /dev/sda7
UUID=868996eb-2b9d-42eb-9bcc-2b23b89dc11b   /home   ext4   
rw,errors=remount-ro0   0
# /dev/sdb4
UUID=0797ee37-d1b9-49ea-a865-c73682cd96a7   swapswap   
sw,nofail   0   0

Here's the output of `lsblk -o NAME,UUID,LABEL`:
NAME   UUID LABEL
sda 
├─sda1 7876BEE376BEA174 SYSTEM
├─sda2  
├─sda3 F2DAFCDFDAFCA151 Recovery
├─sda4 C281-C9E0HP_TOOLS
├─sda5 F0C4F042C4F00C9A 
├─sda6 033d10f2-5402-4632-bed0-5e24842cf1b7 
├─sda7 868996eb-2b9d-42eb-9bcc-2b23b89dc11b HOME
└─sda8 84f3e7a4-c3af-4ac1-a789-cc554395a50b 
sdb 
├─sdb1 06ad2c23-eac6-4a49-9623-79d9e4a02bbe Boot
├─sdb2 1ac3a9b3-2ced-4e6c-9378-f8c94ac2983e User
├─sdb3 13dc09db-ec38-480a-ac28-fd0ed1a952f8 
└─sdb4 0797ee37-d1b9-49ea-a865-c73682cd96a7 Swap

And here's the relevant parts of the output of 'mount' after booting the
system (pressing ctrl-d after the timeout) - notice that /usr and /home
are mounted correctly:
/dev/sdb2 on /usr type ext4
(rw,relatime,errors=remount-ro,commit=600,data=ordered)
/dev/sda7 on /home type ext4
(rw,relatime,errors=remount-ro,data=ordered)

And the output of `swapon -v:
NAME  TYPE  SIZE USED PRIO
/dev/sdb4 partition 9.3G   0B   -1

-Joel

Bug#848075: cubox i4x4 hard drive seen in D-I but not in installed system.

[Vagrant Cascadian]

On 2016-12-13, peter green wrote:
> On 13/12/16 21:42, peter green wrote:
>> I would guess at this point either a race condition or a power glitch 
>> (maybe powering the HDD off one of the USB ports wasn't such a good 
>> idea).
>>
> OK, I found that adding  ahci-imx.hotplug=1 to the kernel command line 
> made it work.
>
> Checking the schematic I notice that the USB ports seem to have power 
> control, I wonder if they are power-cycled at some point during the boot 
> process.

Had a similar issue on a Cubox-I4pro, and your ahci-imx.hotplug=1
workaround also worked for me.

Maybe it's not loading the USB drivers in the initramfs... or maybe it's
just a race condition.

A different (more cumbersome) workaround is making sure all the drivers
are available in the initramfs. I use this from time to time when adding
support to debian for new arm systems. Why it worked in this case seems
surprising... but... well...

/etc/initramfs-tools/hooks/all-drivers:
  
  #!/bin/sh
  # must be marked executable, e.g. chmod +x 
  
  PREREQS=""
  
  prereqs() { echo "$PREREQS"; }
  
  case "$1" in
  prereqs)
  prereqs
  exit 0
  ;;
  esac
  
  . /usr/share/initramfs-tools/hook-functions
  
  copy_modules_dir kernel/drivers
  

lsmod from initramfs shell where it failed to mount the rootfs on sata:

  Module  Size  Used byTainted: G  
  ci_hdrc_imx 6936  0 
  ci_hdrc35216  1 ci_hdrc_imx
  extcon_core13223  1 ci_hdrc
  ahci_imx6207  0 
  ehci_hcd   64996  1 ci_hdrc
  libahci_platform6494  1 ahci_imx
  libahci23377  2 ahci_imx,libahci_platform
  udc_core   26444  1 ci_hdrc
  libata192873  3 ahci_imx,libahci_platform,libahci
  usbcore   195888  2 ci_hdrc,ehci_hcd
  sdhci_esdhc_imx12147  0 
  sdhci_pltfm 3338  1 sdhci_esdhc_imx
  scsi_mod  187963  1 libata
  sdhci  39324  2 sdhci_esdhc_imx,sdhci_pltfm
  usb_common  3659  3 ci_hdrc,udc_core,usbcore
  i2c_imx15436  0 
  usbmisc_imx 6594  1 ci_hdrc_imx
  anatop_regulator4712  1 
  phy_mxs_usb 6386  2 
  at803x  4176  0 

lsmod on a successfully booted system:

  Module  Size  Used by
  snd_soc_imx_spdif   1954  0
  sg 23603  0
  snd_soc_fsl_spdif  16193  2
  imx_pcm_dma 1244  1 snd_soc_fsl_spdif
  snd_soc_core  144850  3 
snd_soc_fsl_spdif,imx_pcm_dma,snd_soc_imx_spdif
  snd_pcm_dmaengine   3583  1 snd_soc_core
  snd_pcm83374  2 snd_pcm_dmaengine,snd_soc_core
  snd_timer  20317  1 snd_pcm
  snd55403  3 snd_timer,snd_soc_core,snd_pcm
  soundcore   5571  1 snd
  ip_tables  12425  0
  x_tables   14826  1 ip_tables
  autofs432792  2
  ext4  551118  2
  crc16   1274  1 ext4
  jbd2   94046  1 ext4
  crc32c_generic  1862  2
  fscrypto   15747  1 ext4
  ecb 2191  0
  mbcache 5508  3 ext4
  dm_mod103345  7
  sd_mod 32731  3
  brcmfmac  240005  0
  brcmutil5789  1 brcmfmac
  cfg80211  475128  1 brcmfmac
  rfkill 16819  2 cfg80211
  imx_ipuv3_crtc 10746  0
  ahci_imx6207  2
  libahci_platform6494  1 ahci_imx
  libahci23377  2 libahci_platform,ahci_imx
  libata192873  3 libahci_platform,libahci,ahci_imx
  ci_hdrc_imx 6936  0
  imx_ipu_v3 75709  1 imx_ipuv3_crtc
  ci_hdrc35216  1 ci_hdrc_imx
  scsi_mod  187963  3 sd_mod,libata,sg
  extcon_core13223  1 ci_hdrc
  ehci_hcd   64996  1 ci_hdrc
  udc_core   26444  1 ci_hdrc
  i2c_imx15436  0
  sdhci_esdhc_imx12147  0
  sdhci_pltfm 3338  1 sdhci_esdhc_imx
  usbcore   195888  3 ehci_hcd,brcmfmac,ci_hdrc
  sdhci  39324  2 sdhci_pltfm,sdhci_esdhc_imx
  usbmisc_imx 6594  1 ci_hdrc_imx
  usb_common  3659  3 udc_core,usbcore,ci_hdrc
  ir_lirc_codec   5112  0
  anatop_regulator4712  1
  phy_mxs_usb 6386  2
  imx2_wdt4189  0
  dw_hdmi_imx 3203  0
  dw_hdmi14062  1 dw_hdmi_imx
  imxdrm  5486  1 imx_ipuv3_crtc
  drm_kms_helper117326  4 imx_ipuv3_crtc,dw_hdmi,imxdrm
  lirc_dev8715  1 ir_lirc_codec
  etnaviv66053  0
  pwm_imx 3678  1
  drm   276288  7 
imx_ipuv3_crtc,etnaviv,dw_hdmi,dw_hdmi_imx,imxdrm,drm_kms_helper
  evdev  12740  0
  leds_pwm3220  0
  gpio_ir_recv3212  0
  at803x 

Bug#860837: Acknowledgement (dash: single quote does not protect \f from being converted to form feed)

[Norman Ramsey]

Followup: the issue lies with dash's echo builtin, not with the parser.
The software that triggered the issue has not been used in four years.
I don't know whether dash has changed in that time or if /bin/sh
was different four years ago.

In any case, the echo builtin is behaving consistently with the dash
man page, so I cannot blame dash for anything.

I apologize for the noise---please close this bug report.


Norman Ramsey

Bug#856708: shotwell: Various packaging improvements

[Jeremy Bicha]

Here's an updated version of the 0001, 0003, and 0005 patches along
with one more patch. The 0002 and 0004 patches from the previous email
are still valid.

It would be nice if you could push shotwell 0.26.1 to experimental.
You could probably have it close 851711 too.

Thanks,
Jeremy Bicha
From 54fed96e29b5532943ac8193e4c38a14f98dc83a Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Thu, 20 Apr 2017 15:32:19 -0400
Subject: [PATCH 1/6] Don't build-depend on m4 since autoreconf already pulls
 it in

---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 02d320a..16d6b56 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,6 @@ Build-Depends:
  libsqlite3-dev (>= 3.5.9),
  libwebkit2gtk-4.0-dev,
  libxml2 (>= 2.6.32),
- m4,
  valac (>= 0.22.0)
 Standards-Version: 3.9.8
 Homepage: https://wiki.gnome.org/Apps/Shotwell
-- 
2.11.0

From 9dd52ece71ca960fb529910214da098cf52bbec1 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Fri, 3 Mar 2017 23:22:41 -0500
Subject: [PATCH 3/6] Clean up debian/rules

Use dh_auto_configure instead of ./configure
Update rm paths for multiarch
Don't install the .a file either
---
 debian/rules | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/debian/rules b/debian/rules
index f8d940b..eea7ad3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,9 @@ B_DATE:=$(shell LC_ALL=C date --utc -d "$(CHDATE)")
 	dh $@
 
 override_dh_auto_configure:
-	./configure --prefix=/usr --libexec=/usr/lib --disable-schemas-compile 
+	dh_auto_configure --prefix=/usr \
+		--libexec=/usr/lib \
+		--disable-schemas-compile
 
 override_dh_install:
 	dh_install
@@ -23,8 +25,10 @@ override_dh_install:
 	tar --mode=go=rX,u+rw,a-s --mtime="$(B_DATE)" -cJf temp-source.tar.xz temp-source
 	rm -fr debian/shotwell-dbg/usr/share/doc/shotwell-dbg/temp-source
 	# Remove unwanted la files
-	rm -f debian/shotwell/usr/lib/shotwell/plugins/builtin/*.la
-	rm -f debian/shotwell/usr/lib/*.la
+	rm -f debian/shotwell/usr/lib/*/shotwell/plugins/builtin/*.la
+	rm -f debian/shotwell/usr/lib/*/*shotwell*.a
+	rm -f debian/shotwell/usr/lib/*/*shotwell*.la
+
 
 override_dh_installchangelogs:
 	dh_installchangelogs NEWS
-- 
2.11.0

From 2c0e832f11cb138258e955009efed23e05e0154f Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Fri, 3 Mar 2017 23:50:45 -0500
Subject: [PATCH 5/6] Move .desktop and appstream metadata from shotwell-common
 to shotwell

https://wiki.debian.org/AppStream/Guidelines#General
---
 debian/control |  2 ++
 debian/rules   |  4 
 debian/shotwell-common.install |  6 +-
 debian/shotwell.1  | 14 --
 debian/shotwell.install|  2 ++
 5 files changed, 9 insertions(+), 19 deletions(-)
 delete mode 100644 debian/shotwell.1

diff --git a/debian/control b/debian/control
index 16d6b56..f9c94bf 100644
--- a/debian/control
+++ b/debian/control
@@ -43,6 +43,8 @@ Depends:
  dconf-cli,
  default-dbus-session-bus | dbus-session-bus,
  librsvg2-common
+Breaks: shotwell (<< 0.26.1-1)
+Replaces: shotwell (<< 0.26.1-1)
 Description: digital photo organizer
  Shotwell is a digital photo organizer designed for the GNOME desktop
  environment. It allows you to import photos, pictures, images and videos
diff --git a/debian/rules b/debian/rules
index eea7ad3..57541c5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -38,7 +38,3 @@ override_dh_strip:
 
 override_dh_compress:
 	dh_compress -X.tar.xz
-
-override_dh_installman:
-	dh_installman
-	rm -fr debian/shotwell-common/usr/share/man
diff --git a/debian/shotwell-common.install b/debian/shotwell-common.install
index dd222db..2d160cf 100644
--- a/debian/shotwell-common.install
+++ b/debian/shotwell-common.install
@@ -1 +1,5 @@
-usr/share
+usr/share/glib-2.0
+usr/share/help
+usr/share/icons
+usr/share/locale
+usr/share/shotwell
diff --git a/debian/shotwell.1 b/debian/shotwell.1
deleted file mode 100644
index e68bcc2..000
--- a/debian/shotwell.1
+++ /dev/null
@@ -1,14 +0,0 @@
-.TH shotwell 1 "December 30, 2009"
-.SH NAME
-shotwell \- a digital photo organizer
-.SH DESCRIPTION
-.B shotwell
-is a digital photo organizer designed for the GNOME desktop environment. It
-allows you to import photos from disk or camera, organize them in various ways,
-view them in full-window or fullscreen mode, and export them to share with
-others.
-.SH AUTHOR
-shotwell was written by Jim Nelson, Lucas Beeler and Allison Barlow.
-.PP
-This manual page was written by Devid Antonio Filoni ,
-for the Debian project (and may be used by others).
diff --git a/debian/shotwell.install b/debian/shotwell.install
index 527b78f..4afb4cf 100644
--- a/debian/shotwell.install
+++ b/debian/shotwell.install
@@ -1,2 +1,4 @@
 usr/bin
 usr/lib
+usr/share/appdata
+usr/share/applications
-- 
2.11.0

From f677ed6cbec9492ff086bd101c680cc2fc191fbc Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Thu, 20 Apr 2017 15:34:44 -0400
Subject: [PATCH 6/6] Drop obsolete patche

Bug#860751: Bug#860695: win32-loader: FTBFS on i386: segmentation fault

[Thomas Dickey]

On Thu, Apr 20, 2017 at 05:11:17PM +0200, Bernhard Übelacker wrote:
> Hello,
> this seems to be the same problem seen in #391051 for regular
> expressions (collect_RE).
> 
> In this bug we overrun the size limit of string_buff (tempbuff._string_buff)
> in function collect_string.
> 
> Attached patch adds a similar check like in #391051 to collect_string.

hmm - upstream mawk makes 7 checks like this in scan.c

start here:

https://github.com/ThomasDickey/mawk-snapshots/blob/master/scan.c#L72

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#860861: run-vmblock\x2dfuse.mount present but not enabled

[Oliver Kurth]

Package: open-vm-tools-desktop
Version: 2:10.1.5-5055683-3


The systemd unit file /lib/systemd/system/run-vmblock\x2dfuse.mount is present, 
but it's not enabled or started when installed. This causes drag and drop to 
not work.


When running:


sudo systemctl start run-vmblock\\x2dfuse.mount
sudo systemctl enable run-vmblock\\x2dfuse.mount

and restarting the vmtoolsd user process, drag and drop work fine.

Bug#860834: u-boot-amlogic: u-boot.bin is not directly usable

[Heinrich Schuchardt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

** FIP_CREATE **

Hardkernel's fip_create is based on the tool of the same name in
ARM Trusted Platform, version 0.4
https://github.com/ARM-software/arm-trusted-firmware

toc_entry_lookup_list contains an Amlogic specific entry:
{ "SCP Firmware BL3-0-1", UUID_SCP_FIRMWARE_BL301,
  "bl301", NULL, FLAG_FILENAME},
#define UUID_SCP_FIRMWARE_BL301 \
{0xAABBCCDD, 0xABCD, 0xEFEF, 0xAB, 0xCD, {0x12, 0x34, 0x56,
0x78, 0xAB, 0xCD} }

The only other difference is image_offset and toc_size having hard
coded values. I wonder if this is relevant for booting or only nice
for debugging.

ARM Trusted Platform, version 1.3 has replaced fip_create by fiptool.

So maybe we simply want to package 1.3 with the additional UUId for bl30
1.

** FIRMWARE **

All of the firmware blobs are based on the Arm Trusted Firmware and
therefore should be subject to the ARM BSD license.

bl31.bin for the Odroid C2 is based on
Arm Trusted Firmware, version 1.1 with some gxbb specific enhancements.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY+VaFAAoJEMSB27wsBRrE+cgQAIVyGuuhmxcG//hIhPG2LiCz
zSqixvcUBXJqtW0qldTZNzLcN20oYiSl5+laE+IzHEU39Ua+2NlKBGfq9F6MeoxN
7LeqN7NHpNbOv7/DSQ+Y5DQ663KOqA3VkkwOSIFRIlgJYREE5Q5Zv0gNNUpNEqq4
yNJq4dDLEfzsYLhTPlYJIQ57ui79jPGpKggO1YRUFft4UftQY3l49TJika8Ei506
Oba/u8tou+MaHoQlCERF1Qpn1qXjllajUpg56b7hSDfp5VHIW1pl0GCdiZSh1+wi
ZDJCEFi3zATa+l5EtLCJXiDet2I7KNu/OfOsz18AyozNtv4zQrvkh9wOGHttL+S8
PY3X40nFVsFpW39O7MImExsmoo8oWD1XD6qrVDLSSEoSBDG+dlf/e3UNnH0By6hh
VLkPE0cGL3W7VH4ClWX3trYtTttyM61NIqbVsNhMCmk5263ZIZVJ3VAFxrspJg9p
oFsMsikJed1xM2o0ALudMrjramUy18858kEmAPkTGysdcMHswD5qiVXOdumDxTp2
XS8zCHDy7zNw0NDkfFhKPzStkwrlJv7EUFbxqdAVEWO6za7pX2MIQcFCJzZ1Bz/4
db6eau7YiikdTkqCL4Yg4VU1CTtR8tOMNGVp6/OHpRkjYHPIqqP6eOQJfg3/LURM
scXvFdTrp/2viDe3MSe2
=qb6D
-END PGP SIGNATURE-

Bug#860860: Please support using updatechecksums on dsc files directly

[peter green]

Package: reprepro

Sometimes one needs to update checksums in a dsc to match the files on disk, 
usually this is a result of Debian releasing two orig tarballs with the same 
name, same contents but slight differences in the tarball metadata.

Right now to fix this I can do something like.

changestool --create temp.changes adddsc fonts-senamirmir-washra_4.1-5.dsc
changestool temp.changes updatechecksums
rm temp.changes

This works but is annoying, it would be useful if I could use updatechecksums 
directly on dsc files.

Bug#689508: ignore obsolete conffiles which are not owned by the package

[Andreas Beckmann]

Followup-For: Bug #689508
Control: tag -1 patch

Doing longterm dist-upgrade tests with piuparts (starting in lenny/squeeze
and going release by release up to stretch) I'm still running into false
positive reports for modified files that are actually obsolete conffiles
still "owned" by the package that shipped them in the past.
A common case is a former conffile that is now a configuration file
managed by ucf (and is no longer matching the ancient md5sum).
Making dpkg "forget" about the conffile is difficult if the name is
still being used (dpkg-maintscript-helper rm_conffile could be abused
in non-intuitive ways).

The attached patch unconditionally excludes all obsolete conffiles.
Maybe that is not the optimal approach and a new command line option
should be used instead (and then we could discuss whether obsolete
conffiles should be ignored by default - I would say yes).


Andreas
>From 54097a012d33c8c05e143a91d627394405c4ec71 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Fri, 21 Apr 2017 01:35:49 +0200
Subject: [PATCH] ignore obsolete conffiles

even if still 'owned' by the package according to dpkg, the obsolete
conffile either no longer exists (in this case the old md5sum should
be still valid) or is managed differently (e.g using ucf) and the md5sum
is outdated and likely causes a false positive report of a modified file
---
 debsums | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debsums b/debsums
index faee262..1a748fb 100755
--- a/debsums
+++ b/debsums
@@ -262,7 +262,7 @@ my %replaced;
 $package_name{$field{"Package"}} = $field{"binary:Package"};
 }
 $installed{$field{"binary:Package"}}{Conffiles} = {
-map m!^\s*/(\S+)\s+([\da-f]+)!, split /\n/, $field{Conffiles}
+map m!^\s*/(\S+)\s+([\da-f]+)!, grep {!/ obsolete$/} split /\n/, $field{Conffiles}
 } if $field{Conffiles};
 
 for (split /,\s*/, $field{Replaces})
-- 
2.11.0

Bug#860742: liferea: 'Update Monitor' dialog does not expand properly

[Paul Wise]

On Thu, 2017-04-20 at 22:12 +0200, Paul Gevers wrote:

> Hmm, the debdiff is 1.5 MB big.

That is quite large.

> Did you actually look at the changes, or just at the changelog?

Just what upstream wrote on their releases page.

> Do you really think I should try to convince the RT?

I'm not sure at this point, but I lean towards yes.

> (I could strip the translations from the debdiff (nearly all line number
> changes), but an other huge part of the delta was already included in
> the 0001-Removing-GtkDoc-warnings.patch. So when I create a diff of the
> patched source tree, and not including the stripped patch, I am still
> left with ~50KB of diff or approximately "34 files changed, 374
> insertions(+), 278 deletions(-)")

That sounds quite reasonable, assuming translations are filtered out.

> > https://github.com/lwindolf/liferea/issues/208
> 
> Do you think this is an RC bug? Than cherry-picking only that fix is
> more trivial than the full rc3.

Yes. For a while I personally was resorting to making hourly backups of
the liferea database just so I can mitigate it. Later I figured out how
to avoid triggering my instance of the symptom.

> -rw-r--r-- 1 paul paul 1.5M apr 20 21:30 /tmp/liferea_1.12~rc3-1.debdiff
> > 102 files changed, 11055 insertions(+), 14088 deletions(-)

That definitely isn't reasonable.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#859988: closed by Adam Borowski (Re: Bug#859988: RFS: gcc-6-doc/6.3.0-1)

[Guo Yixuan]

Hi Adam and Mattias,

Thank you! I'll try to upload gcc-doc-default soon.

Cheers,
Yixuan

On Mon, Apr 10, 2017 at 1:27 AM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
>
> #859988: RFS: gcc-6-doc/6.3.0-1
>
> It has been closed by Adam Borowski .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Adam Borowski <
kilob...@angband.pl> by
> replying to this email.
>
>
> --
> 859988: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859988
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Adam Borowski 
> To: 859988-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 10 Apr 2017 07:23:45 +0200
> Subject: Re: Bug#859988: RFS: gcc-6-doc/6.3.0-1
> On Sun, Apr 09, 2017 at 11:44:03PM -0400, Guo Yixuan wrote:
> > I'm looking for a sponsor for my package gcc-6-doc.
> >
> > Changes for this upload:
> >  gcc-6-doc (6.3.0-1) unstable; urgency=medium
> >  .
> >* New upstream release.
> >* Synced patches with gcc-6, 6.3.0-12.
> >* Build manpages for gcov-tool/gcov-dump. (Closes: #859974)
>
> As you coordinate with Matthias Klose, I assume uploading this large blob
of
> changes to unstable is ok.
>
> Looks good to me.
>
> --
> ⢀⣴⠾⠻⢶⣦⠀ Meow!
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
> ⠈⠳⣄ preimage for double rot13!
>
> -- Forwarded message --
> From: "Guo Yixuan (郭溢譞)" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 09 Apr 2017 23:44:03 -0400
> Subject: RFS: gcc-6-doc/6.3.0-1
> Package: sponsorship-requests
> Severity: normal
> Control: block 859974 by -1
>
> Dear mentors,
>
> I'm looking for a sponsor for my package gcc-6-doc.
>
> Changes for this upload:
>  gcc-6-doc (6.3.0-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Synced patches with gcc-6, 6.3.0-12.
>* Build manpages for gcov-tool/gcov-dump. (Closes: #859974)
>
> Package description:
>
> * Package name: gcc-6-doc
>   Version : 6.3.0-1
>   Upstream Author : FSF
> * URL : http://gcc.gnu.org/
> * License : GFDL-1.3+, with invariant sections
>   Programming Lang: Texinfo
>   Description : documentation for the GNU compilers (gcc, gobjc, g++)
>
> This package contains manual pages and documentation in info, html,
> and pdf format, for the GNU compilers.
>
> This documentation is licensed under the terms of the GNU Free
> Documentation License, and contains invariant sections, so it can't be
> part of Debian main.
>
> (See gcc-5-doc as an example.)
>
>   It builds those binary packages:
>
>  cpp-6-doc  - documentation for the GNU C preprocessor (cpp)
>  gcc-6-doc  - documentation for the GNU compilers (gcc, gobjc, g++)
>  gccgo-6-doc - documentation for the GNU Go compiler (gccgo)
>  gcj-6-doc  - documentation for the GNU Java tools (gcj, gij)
>  gfortran-6-doc - documentation for the GNU Fortran Compiler (gfortran)
>  gnat-6-doc - documentation for the GNU Ada Compiler (gnat)
>
>   To access further information about this package, please visit the
following URL:
>
>   https://mentors.debian.net/package/gcc-6-doc
>
>
>   Alternatively, one can download the package with dget using this
command:
>
> dget -x
https://mentors.debian.net/debian/pool/non-free/g/gcc-6-doc/gcc-6-doc_6.3.0-1.dsc
>
> Thanks,
> Yixuan
>



--
GUO Yixuan

Bug#860819: piuparts(.d.o): detect_network_issues always finds issues in systemd-sysv and upstart…

[Andreas Beckmann]

On 2017-04-20 17:45, Holger Levsen wrote:
> - both logs do not contain any of the above strings being grep'ed for
> 
> The 2nd problem actually puzzles and bothers me much more…

The list of patterns in the message is not kept in sync with the grep
commands ... (in detect_piuparts_issues as well)
This list in the message should be generated ... and ideally it should
also report which pattern matched in a logfile.


Andreas

Bug#860858: emacs24: missing Breaks: mell (<= 1.0.0-7)

[Andreas Beckmann]

Package: emacs24
Version: 24.5+1-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + mell

Hi,

despite of being removed from the archive in 2011, the mell package
may have survived from a long grown squeeze installation over several
generations of emacs. But it has finally become incompatible with
emacs24:

  Setting up emacs24 (24.5+1-8) ...
  Install emacsen-common for emacs24
  emacsen-common: Handling install of emacsen flavor emacs24
  Wrote /etc/emacs24/site-start.d/00debian-vars.elc
  Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
  Install mell for emacs24
  install/mell: Handling install for emacsen flavor emacs24...ERROR: install 
script from mell package failed
  dpkg: error processing package emacs24 (--configure):
   subprocess installed post-installation script returned error exit status 1

It's time to add a Breaks to get it removed, finally.


Andreas


mell_None.log.gz
Description: application/gzip

Bug#860859: emacs24: sss

[Andreas Beckmann]

Package: emacs24
Version: 24.5+1-8
Severity: normal

Content-Type: multipart/mixed; boundary="===6705751742237833690=="
MIME-Version: 1.0
From: Andreas Beckmann 
To: Debian Bug Tracking System 
Subject: emacs24: missing Breaks: mell (<= 1.0.0-7)
Message-ID: <20170420223923.8088.57008.report...@zam581.zam.kfa-juelich.de>
X-Mailer: reportbug 6.6.6~bpo8
Date: Fri, 21 Apr 2017 00:39:23 +0200

This is a multi-part MIME message sent by reportbug.


--===6705751742237833690==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Package: emacs24
Version: 24.5+1-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + mell

Hi,

despite of being removed from the archive in 2011, the mell package
may have survived from a long grown squeeze installation over several
generations of emacs. But it has finally become incompatible with
emacs24:

  Setting up emacs24 (24.5+1-8) ...
  Install emacsen-common for emacs24
  emacsen-common: Handling install of emacsen flavor emacs24
  Wrote /etc/emacs24/site-start.d/00debian-vars.elc
  Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
  Install mell for emacs24
  install/mell: Handling install for emacsen flavor emacs24...ERROR: install 
script from mell package failed
  dpkg: error processing package emacs24 (--configure):
   subprocess installed post-installation script returned error exit status 1

It's time to add a Breaks to get it removed, finally.


Andreas

--===6705751742237833690==
Content-Type: application/gzip
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="mell_None.log.gz"

H4sICBg3+VgCA21lbGxfTm9uZS5sb2cA7Dxpc9u4kt/1K1C1H5JUDIqHJMuq57cv1ySpSTLe2Hkz
u6kpF0SCFEYkwQFI2XJNvd++3QCpwyeUyNmtrVViCSTBvtDoA2zwtGaqnpDQDw6pP6DBiPiHk0E4
CQLy6s1Zr/dV/9lwfsV/752weM4yPiEFz/PeiRJSiXo5IbKqhSxZ3jvlMbYmhCeilkr33pe6ZnnO
E3oqruDGMAh7H5koa/jjakLeiYTXbM7I+wsmyN/qZbNs/pHwqWClJ5X3R/X33gsVz0QNgBsFAABY
759caYMl8HzPp4e917ziZaIBbcFiHQbkL9vi5QFhFc/J078fkwD7Bs96P4mcl6wAWJWUeb8ASvpF
HzkyX+ct0HPA5AElvY7wo9G49/H1UDfFhMR+GI3GbDSKuc+jKDhMB3GYhINkwIfDo4j1Tt+9CCZk
FCajo+k0mY6TgB0xP0mG/GiaHCbBeDgesYCHqT8cAFzoHg5HwNA4jYKADwY8SIfjaRRMhyz2kwGb
cj8I46OQR9NhOmbTwRHjw9F07IcBHyWH/tBP/WiQgCR0rETVDgLKgORCV/A1VUwtyQUMWM1LMl2C
6JVcNnNBfpYFq3XTI2czoUllx5jE0gySJoXQMciFlVw2+n6YvRtACfnb3Lb+AdCWbC5gWLO/ez0C
/798fj8hs7quJv3+xtV+74xlEyKKKucFL2tQHlFOJojzgOgGdGEyMWSAal7MQDOXv0PrD6614Niq
ua5FmUHzzSWPG2xP4L5EklLEnPByQU7+8+zdL59OXpy9O+5rtehXoqlgEug+8NSvlvVMlqF32E+E
rmkrEE1qUYAIakI1ef/pjNA5GRYkCPyCbMPQU9Co7ohQqueiornMlKxZzVNQP02RRrh0wVRJJfyv
Z6DTcKKUlLO6WCasZnirGUydCEX6vI43cNgL0AXUVF5Q7D9lmm/AzHlaywWApSytuaJVo2BYqbCQ
9AzGtMUYz3g8pwuWi4Q2ZS1yOF0pebnsBieXMctnUteTKAjHcLUQSklFnrTX07qCqeKt5m3Wt02C
k+sJ9K+LyvAAvyseDPEwtwkrktGA0Ol1MeZswfvIVJ1d9VsbdG46e2CxvOyK0IS057FpdQFbVhew
1eoCoS+J4ilXvIw58KukrGkBlgfl5sEX0lLVxq4df5Il7/kFWAEc6J9+mcDFfX62YZ9J8mcj4nm+
JBlMMlDQixnQcwGKDzNLlhnofKxknpNEXpSklgR0hUxlXcuCyBSOYNKCdqFeedugf3rxH4QtmMjZ
NOcEgOJwaRivCwEzbWO0VjKHO65RB7gMmFxLwi+r3JiEmbxAQoyJiGsCZkGUJEb1W8oGKSrnZDUB
gDzDh/fjZLrCvbCegvje4eG/0MH5gyDyI3/4LzgT0ejoCL6z8eEg5fGQRUSjK0R9aapr5L6SRcHK
BIxeCaJUWYOWCTzO/0/9/9tT/3NTlggF/ekHUTaXpFiiOMjAG2E8QS0L/xaQ048n5LXlHa9BIEWe
gsqNqH9Ig/EzcjkenY8GHfTXb15+eQtqpWDMORJbVNJ4UxAWxDoSWtsiw6Nf0+jn9OdrIL6U6KGQ
xp2FCHGYdEVz2k2N2M6ECfn6BE49OSBP6Cv8vguO6XF1mZo+O1L45HegIvAGa3m101DO/2fw3yaF
QsLMMVjMN0yfePP3Lrr6psP9DO4VtAPtCV+AaTHHEr9LfiEwgoepc1BKDuEU/EAIlhxkIjkeHhQy
4cf+KPQPqrq4bI9Go21Qd1IJXfrYZycZ/O8g8X5ZGsLAFSQusPtIl0NH6OQqqB+F30GjAEq6MVoa
kqnj0XAYjeZbV+/FrWfFbjryWEi1bFTMtQepSD3pEQKurvOT6M7E4jZH2LkpdIjXmWitfyVzES+p
ir2EIFPxDPQ0gQui9u64RXEt84UHIVjqOYyK9XsPmUnwgzTjpltTgWvkRgKRdwiwv3w8mRDg+S2v
J8HdXK/Y/cxzDpbVy6qMfA1A+uTl73D7+6x8UGT9DohJzsmZYiWYasxpKS9bEkJ3EsjXI3DVZG7w
473Rw/dazNa3n3QJ4NdxdNjB+QkiqRmMwxjSdziFAXCgydOhPzqEw75+Bn0+c5bgOHQpNaqN9jxv
JdPbVPn7R6qDWi0R+YNx5D0hgDnf9ut38Lfjog5KBTHRuaX9vDERyTV69qKVdGncuMnLmypTLOkY
P9pQ0TvlTsjLRuTmWmKWjCAmXJJacW6v+qQFmhxAGzwLJGWiW8HCUyArxQsIrc00hS6yXt3irejY
y7Dez+r3ylTPDI64Qxoz0GaSNEVlEkbyFykSXOoyKAcmDOykO2I+HyTRNIKsKYlHU+6HaTxMo6N0
mkbBaEQIXd3z7ZLYncB79BICvKa6RtS3y25zUqzBn+NIKTFt0E5tiO3bRfAtePbPVVMUy/NGQzJp
kA0fial70Oydp1SqqUjOZ7Lgj8nTfWgegydIb5tSs5RTIVuEwSPxdS+qvfNWiFIUEMM9JlN34tg7
N22EQafgnSDnr/VjsvUwsr3zd3V1/kNYuxfPY3AFcUDdbKLqPOJrroXiyfGXcl7Ki7LfPvTqfzah
Qv8EV9/672SeQN+/kDQAc/xJ1qZj/xWE8NQsDfbtUg5P+jOW/0Qxtu+/Y3lKMQbpg9HPKPuVibp/
hk2MXxBgn7xR6t+Pn5ay5M8AJ3amiv/ZIE3kqUV3AH0mEKpUXOE67fGUJRih/gV3f2IFJ66f9tGb
W+eNh1GA6/nz5/R4h8/jdf6eDzAiBCG4Yuj88b2xF/he9LydjcF9nV8kC1zLSEiqZFlDwgMtqUhS
zbMWNy5YWYVxwA2ZT4fVdxgwk7Ga1WS91DUvrj39M1g3yaiY1hfJw2RE3tALQ+KqNzfJYPCjiEEn
lc2SMyWb6jpJM+dRGXgBjVw743OQt5++kJeyUSUnLzJMD0/f4WPwFrVOICLLtRO0YBJ6waEX0iOH
zi+ZFjFB4KIWMOagFwUQP3h5+pp+EDVvCYil4s4UjL0hDVx5R74R+pqGFmWyi7h90AAwm/TQGzzc
+eSX0/e/gQEsqhw0oSbmkUWHlU/RMrphDQBnNPKCXfQOoYusUWbFATSvhBwSn/a0urhNBhXBuNwv
GWmT57g0z1XJbF2FuLK0aDDg4O6sQbD419QA6bRd0KBzvlTo/W7/hD7WQoy9cOxgkd6Wzclb0gIm
AFjbp468E1d7aYsQR0WMXHSh+3zc

Bug#860857: open-vm-tools-desktop should not recommend open-vm-tools-dkms

[Oliver Kurth]

Package: open-vm-tools-desktop
Version: 2:10.1.5-5055683-3


The package open-vm-tools-desktop recommends open-vm-tools-dkms:


~$ apt-cache show open-vm-tools-desktop
Package: open-vm-tools-desktop
Source: open-vm-tools
Version: 2:10.1.5-5055683-3
Installed-Size: 674
Maintainer: Bernd Zeimetz 
...
Recommends: open-vm-tools-dkms, xauth, xserver-xorg-input-vmmouse, 
xserver-xorg-video-vmware, fuse
Suggests: xdg-utils
Breaks: open-vm-tools (<< 2:10.0.0~)
...

There is no need for the -dkms package at all (not just the -desktop package), 
since vmhgfs is replaced with fuse, and all other modules are part of the 
kernel. With kernel 4.9, the only module installed by it is the vmxnet driver, 
which is deprecated (and this isn't specififc to -desktop anyway).

Note that in the future we will probably remove the source for kernel modules 
from open-vm-tools, so the -dkms package will be no longer of any use.

Bug#858579: /usr/share/man/man5/deb-changelog.5.gz: please support a comment syntax for Debian changelog files

[G. Branden Robinson]

At 2017-04-20T09:39:42+0200, Guillem Jover wrote:
> On Wed, 2017-04-12 at 11:00:20 -0400, G. Branden Robinson wrote:
> > The former.  You'll never see a C library interface manpage with
> > double-colons in the name, and C++ programmers never write manpages
> > because their programming language is completely intuitive. >cough<
> 
> Well, within the perl world, I'd go as far as considering missing
> documentation as malpractice. :)

Yes.  Unfortunately, POD is too, at least the last time I looked at it.

> Right, although given that the current markup is already mixed, and
> that I'm planning anyway to switch all man pages to use POD as source,

D'oh!

> because the unreadability of troff also affects translators, among
> other issues, this does not matter much, and in fact makes the
> conversion easier, so I've left it as is. :)

There is a subset of troff with the an macros that should be as easy for
translators as POD is.

>   

The list of reservations you have with pod2man here seems pretty
serious.

> Nah, adequate; IMO, there's never enough nitpicking! ;)

:-D

> Attached a revised patch.

Thanks!

> +Any line that consists entirely (i.e., no leading whitespace) of \fB#\fP
> +or \fB/* */\fP style comments, RCS keywords, Vim modelines or Emacs local
> +variables should be ignored.

I'll reiterate that that the an macro B would be better here, if I
persuade you to block out the siren song of POD. :P

One felicity that I just learned about today is that the only
actively-maintained alternative troff implementation, "Heirloom Troff",
has been extended to support a lot of groff's own extensions.  Of
particular interest:

Most groff extensions, like long names for requests, strings, and
number registers, are supported. A special groff compatibility mode
is also provided.[1]

An essential part of that long-name support is the vastly superior
syntax for character escapes, even for traditional short escape names.

So if you need "shaped" quotation marks, you can say:

 \[oq], \[cq], \[lq], \[rq]

instead of

 \(oq, \(cq, \(lq, \(rq.

This is far easier on the eye--especially so with lexical highlighting
that puts a nice bright color on closing brackets, and perhaps more
importantly, it makes the words immediately abutting these symbols
recognizable by spell checkers.  Vim's spell checker, for instance,
flags "lqprotected" in "\(lqprotected\(rq" as an unrecognized word.
(The spell checker still griefs you on the names of the escapes
themselves, of course, but there are relatively few of those that one
would want to use in a man page, and they can be disregarded, or put
onto an internal or external word list much more easily.)

What sort of help do you need to lower the *roff manpage burden enough
that you'll keep it?  I'm here for you. :)

Regards,
Branden

[1] http://heirloom.sourceforge.net/doctools.html


signature.asc
Description: PGP signature

Bug#860856: RM: live-f1/0.2.10-1.1

[Adrian Bunk]

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

#858109 live-f1 isn't working anymore due to changes on the data-providing side

Already removed from stretch, should also be removed from jessie.

Bug#859778: RFS: xtrs/4.9d-2

[Sean Whitton]

Hello Branden,

On Thu, Apr 20, 2017 at 04:58:03PM -0400, G. Branden Robinson wrote:
> Sure am.  In fact I have xtrs 4.9d-3 pretty much ready to go except for
> the official versioning and tagging.  I've also been in touch with
> upstream; he's been working on an xtrs 5.0 for quite some time.  :)
> 
> See attachments.  I've also pushed my work to alioth.

Please remove the moreinfo tag from the bug when it's ready to be
uploaded.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#859778: RFS: xtrs/4.9d-2

[G. Branden Robinson]

At 2017-04-20T15:58:04-0700, Sean Whitton wrote:
> Please remove the moreinfo tag from the bug when it's ready to be
> uploaded.

Will do!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#860855: linux: [arm64] Please add support for Allwinner boards (pine64)

[Vagrant Cascadian]

Package: linux
Version: 4.10.7-1~exp1
Severity: wishlist
Tags: patch

The following config options should enable support for basic SUNXI boards on 
arm64.

Tested on Pine64+ board with MMC, USB and serial console working.

Requires linux 4.11-rc+ for all of the features to work.

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index 27da44863..2106a32d8 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -847,3 +847,7 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
 CONFIG_SND_SOC_TEGRA_MAX98090=m
 CONFIG_SND_SOC_TEGRA_RT5677=m
 
+CONFIG_ARCH_SUNXI=y
+CONFIG_RTC_DRV_SUN6I=y
+CONFIG_MMC_SUNXI=m
+CONFIG_PHY_SUN4I_USB=m


signature.asc
Description: PGP signature

Bug#860805: beignet-opencl-icd: OpenCL fails with: drm_intel_gem_bo_context_exec() failed: Device or resource busy

[Rebecca N. Palmer]

Control: severity -1 serious

I have been working on this upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=100639

It appears to totally break beignet on Ivybridge/Haswell on recent 
(including sid/stretch) Linux.  (I didn't notice it before because I 
test in a chroot, i.e. with jessie's too-old-to-be-affected Linux.)


It's not yet entirely clear what to do about it:

The above patch works for me, but apparently not for everyone.

The other known partial fix is to disable softpin, but that also isn't a 
complete fix, and also disables OpenCL 2.0.

Bug#860602: ruby-net-ldap: FTBFS: ERROR: Test "ruby2.3" failed.

[Luca Capello]

tags 860602 + confirmed
tags 860602 + upstream
tags 860602 + patch
thanks

Hi,

On Wed, Apr 19, 2017 at 08:13:46AM +0200, Lucas Nussbaum wrote:
> Source: ruby-net-ldap
> Version: 0.12.1-1
> Severity: serious

Actually, this severity is questionable, the bug is not in the *build*
process, but in the *test* suite.  For the rationale, see:

  

> Tags: stretch sid

We tested this on a clean sid chroot as well with *no* network during
the GULL BSP:

  

> Relevant part (hopefully):
> > /usr/bin/ruby2.3 /usr/bin/gem2deb-test-runner
> > 
> > ┌──┐
> > │ Run tests for ruby2.3 from debian/ruby-test-files.yaml
> >│
> > └──┘
> > 
> > RUBYLIB=/<>/debian/ruby-net-ldap/usr/lib/ruby/vendor_ruby:. 
> > GEM_PATH=debian/ruby-net-ldap/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
> >  ruby2.3 -ryaml -e YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\ 
> > \{\ \|f\|\ require\ f\ \}
> > Loaded suite -e
> > Started
> > ..Deprecation warning: 
> > Net::LDAP::ConnectionRefused will be deprecated. Use Errno::ECONNREFUSED 
> > instead.
> > .Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > F
> > ===
> > Failure: test_unresponsive_host(TestLDAPConnection)
> > /<>/test/test_ldap_connection.rb:64:in `test_unresponsive_host'
> >  61:   end
> >  62: 
> >  63:   def test_unresponsive_host
> >   => 64: assert_raise Net::LDAP::Error do
> >  65:   Net::LDAP::Connection.new(:host => 'test.mocked.com', :port 
> > => 636)

test.mocked.com does not respond on port 636:
=
rescue@debian:~$ ldapsearch -x -H ldaps://test.mocked.com
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
rescue@debian:~$ 
=

There are different solutions:

1) uncomment "export DH_RUBY_IGNORE_TESTS=all" in debian/rules

2) add "export RES_OPTIONS=attempts:0" do debian/rules, as per

 

3) comment test/test_ldap_connection.rb in debian/ruby-test-files.yaml
   (this seems the best solution)

However, even with network access and DNS resolution, the test does not
behave the same if the connection to test.mocked.com is possible or not.
This can be tested via `iptables -I OUTPUT -p tcp -m tcp -d
test.mocked.com -j $ACTION`:

* DROP, the test does not fail
* REJECT, the test fails

Nevertheless, if no one replies in 7 days, I will upload an NMU with the
solution 3 above (Git patch attached).

Thx, bye,
Gismo / Luca
>From 5e1b2c167c4608110461b10d46c91ba8bf9ee63b Mon Sep 17 00:00:00 2001
From: Luca Capello 
Date: Thu, 20 Apr 2017 23:56:23 +0200
Subject: [PATCH] debian/ruby-test-files.yaml: (#860602) comment LDAP

Signed-off-by: Luca Capello 
---
 debian/changelog| 7 +++
 debian/ruby-test-files.yaml | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index d7c96dc..351daed 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ruby-net-ldap (0.12.1-2) UNRELEASED; urgency=medium
+
+  * debian/ruby-test-files:
++ comment test/test_ldap_connection.rb (Closes: #860602).
+
+ -- 
+
 ruby-net-ldap (0.12.1-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/ruby-test-files.yaml b/debian/ruby-test-files.yaml
index 1db6484..d5874e5 100644
--- a/debian/ruby-test-files.yaml
+++ b/debian/ruby-test-files.yaml
@@ -1,7 +1,8 @@
 --- 
 - test/test_entry.rb
 - test/test_filter.rb
-- test/test_ldap_connection.rb
+## 
+#- test/test_ldap_connection.rb
 - test/test_ldif.rb
 - test/test_password.rb
 - test/test_rename.rb
-- 
2.1.4

Bug#860854: yade FTBFS on mips/mipsel: This architecture is not supported, exiting

[Adrian Bunk]

Source: yade
Version: 2017.01a-8
Severity: important

https://buildd.debian.org/status/package.php?p=yade

...
make[1]: Entering directory '/<>'
dpkg-query: package 'python-sphinx' is not installed and no information is 
available
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
dpkg-query: package 'python-sphinx' is not installed and no information is 
available
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
echo 'This architecture is not supported, exiting'
This architecture is not supported, exiting
exit 2
debian/rules:30: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 2

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

[Brian Potkin]

On Fri 21 Apr 2017 at 06:05:02 +1000, Ben Finney wrote:

> On 20-Apr-2017, Brian Potkin wrote:
> > Ben - a request. Bug reports below a certain size come through to
> > debian-printing and I get them by SMTP. It is better to compress
> > log files, otherwise I have to go looking for the CC.
> 
> I'll try to remember that.
> 
> And while we're at it: Thank you for putting in the careful effort to
> troubleshoot this problem with me!
> 
> > More testing, I'm afraid.
> 
> Bring it on :-)
> 
> > Take the file in your $HOME produced by testq. The file utility should
> > identify it as "HP Printer Job Language data".
> 
> $ sudo file ~/testq-out
> /home/bignose/testq-out: HP Printer Job Language data
> 
> > Send it directly to the printer with
> > 
> >   cat  > /dev/usb/lp0
> 
> There is no such device node:
> 
> $ find /dev -name 'lp0'
> 
> $ ls /dev/usb/lp0
> ls: cannot access '/dev/usb/lp0': No such file or directory

We will come back to this in a moment.

> > Also send the same file with
> > 
> >   lp -d  -o raw 
> 
> =
> $ sudo systemctl restart cups
> 
> $ lpstat -a 'SCX-4623-Series'
> SCX-4623-Series accepting requests since Fri 21 Apr 2017 06:00:09 AEST
> 
> $ lp -d 'SCX-4623-Series' -o raw ~/testq-out
> request id is SCX-4623-Series-73 (1 file(s))
> 
> $ lpstat -a 'SCX-4623-Series'
> SCX-4623-Series accepting requests since Fri 21 Apr 2017 06:00:09 AEST
> 
> $ lpstat -o 'SCX-4623-Series'
> SCX-4623-Series-68  bignose   1024   Thu 20 Apr 2017 20:39:29 AEST
> SCX-4623-Series-71  bignose   1024   Thu 20 Apr 2017 20:51:12 AEST
> SCX-4623-Series-72  bignose  95232   Fri 21 Apr 2017 05:56:42 AEST
> SCX-4623-Series-73  bignose  95232   Fri 21 Apr 2017 06:00:24 AEST
> 
> $ sudo systemctl stop cups
> =
> 
> > Does it print?
> 
> No. The resulting error log (compressed) is attached.

The log is sprinkled with

 Waiting for printer to become available.

There are two basic reasons for the printing failure:

1. The usb backend (which uses libusb to send the file to the printer)
   has failed. We haven't seen this happen for a long time.

2. A hardware failure. Connecting cable or printer.

We need to send a job without using the usb backend to pin down the
cause. Back to 'cat  > /dev/usb/lp0'.

All four of my machines have a file put in /dev/usb/ when a printer is
plugged into a USB port. /dev/usb/ is often created to hold the file. I
am not a USB expert so am only going off a bit of experience. Maybe the
file is lp1. Please would you have a look amd repeat the command. Also,
do 'lpinfo -v' and look for a line beginning 'direct usb://...'.

Cheers,

Brian.

Bug#860834: u-boot-amlogic: u-boot.bin is not directly usable

[Heinrich Schuchardt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/20/2017 10:20 PM, Vagrant Cascadian wrote:
>> Furthermore the firmware is needed. The source is possibly
>> contained in 
>> http://openlinux.amlogic.com:8000/download/ARM/u-boot/uboot-2016-08-1
8-edd7f116ab.tar.gz
>
>> 
I don't see source code for the firmware in there. e.g. fip/gx* only
> includes binaries.
> 
> 
You have to look into these directories:
arch/arm/cpu/armv8/gx*/firmware/scp_task

Regards

Heinrich
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY+S73AAoJEMSB27wsBRrEnvQP/0YeWBztIQ42X/CxgpofrNZx
o//8OOv+r9XSkqJvw6fnIHIxPKBemmNJZInaU1CCVM4x4lESxVUVoxhekMazzjm7
ZI69rV5rQzfdtuaSWI/I31wp0kFCEfLJqhjtefFO2coOwKUJPmdxajrzEZ+tRuFC
eCappyqiX/phA2aQD6JAhi4Re1ODWuRh27kGzFZ1+ANSRRXaQsH9PiQgOy/ReXLP
k5lfKat+IIIGqybI0ma5z6GXAJJKjIgPtHX2P8bB+MLjOZMa/9VwGVaSInqxc972
iIpvC+oHhdd2V2l00MnsVc24iCc/b/44jo2P9mKPsYcxtciP1XX0+sfaUICWRYhf
+tMHzcfMq28YTLSSnqG+W6pOqsuAAxWq2JqhbfZsl68TQYnNrfHfrvo22vQWmw7A
+2BfGj+F+YZ/JF31G/N78SEYj3VnV+UtBbeuGysmiSG57kcJP00xEkFAUWTRkpbK
gHiIZxguBkYnfEua6+5Scc/CGjIMsAzVbqR4qMGs264h2OCxHUbqeCt7VwI+11/p
QM8gubP9vEyXxxgSYhZ+OitQVJVkysWE7e71AjGQOtfBRtttHuggEduPGh8Z1K4F
UON7tSq2khtdMkiaWvSA3/869EkunEEbsfinQWg7ZXIKo7OMrcpmU1jnFTNo7WAc
VTeVfVQzQ/bO2oIeSOIa
=nqbj
-END PGP SIGNATURE-

Bug#860853: open-coarrays FTBFS on armel/armhf: Can't rename module file '../../mod/opencoarrays.mod0' to '../../mod/opencoarrays.mod': No such file or directory

[Adrian Bunk]

Source: open-coarrays
Version: 1.8.6-1
Severity: serious

https://buildd.debian.org/status/package.php?p=open-coarrays&suite=sid

...
f951: Fatal Error: Can't rename module file '../../mod/opencoarrays.mod0' to 
'../../mod/opencoarrays.mod': No such file or directory
compilation terminated.
src/mpi/CMakeFiles/caf_mpi.dir/build.make:113: recipe for target 
'src/mpi/CMakeFiles/caf_mpi.dir/__/extensions/opencoarrays.F90.o' failed
make[3]: *** [src/mpi/CMakeFiles/caf_mpi.dir/__/extensions/opencoarrays.F90.o] 
Error 1
...

Bug#860851: unblock: swift/2.10.1-3

[Ondřej Nový]

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

Please unblock package swift 2.10.1-3. This new version fixies
FTBFS on i386 (#860638).

Debdiff attached.

Thanks.

unblock swift/2.10.1-3

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru swift-2.10.1/debian/changelog swift-2.10.1/debian/changelog
--- swift-2.10.1/debian/changelog   2017-01-13 10:05:12.0 +0100
+++ swift-2.10.1/debian/changelog   2017-04-20 22:51:28.0 +0200
@@ -1,3 +1,9 @@
+swift (2.10.1-3) unstable; urgency=medium
+
+  * d/patches/FTBFS_i386.patch: Fix FTBFS on i386 (Closes: #860638)
+
+ -- Ondřej Nový   Thu, 20 Apr 2017 22:51:28 +0200
+
 swift (2.10.1-2) unstable; urgency=medium
 
   * Don't start rsyslog during postinst/postrm if it's stopped
diff -Nru swift-2.10.1/debian/patches/FTBFS_i386.patch 
swift-2.10.1/debian/patches/FTBFS_i386.patch
--- swift-2.10.1/debian/patches/FTBFS_i386.patch1970-01-01 
01:00:00.0 +0100
+++ swift-2.10.1/debian/patches/FTBFS_i386.patch2017-04-20 
22:51:28.0 +0200
@@ -0,0 +1,26 @@
+From cc8ddf97b666ab91d48f6bc382f6bbdde52cc931 Mon Sep 17 00:00:00 2001
+From: Ondřej Nový 
+Date: Thu, 20 Apr 2017 16:57:15 +0200
+Subject: [PATCH] Fix unit tests on i386 and other archs
+Forwarded: https://review.openstack.org/#/c/458539/
+
+Change-Id: I4f84b725e220e28919570fd7f296b63b34d0375d
+---
+
+diff --git a/test/unit/common/test_utils.py b/test/unit/common/test_utils.py
+index c412b95..a00faf9 100644
+--- a/test/unit/common/test_utils.py
 b/test/unit/common/test_utils.py
+@@ -3591,6 +3591,12 @@
+ def _fake_syscall(*args):
+ called['syscall'] = args
+ 
++# Test if current architecture supports changing of priority
++try:
++utils.NR_ioprio_set()
++except OSError as e:
++return unittest.skip(e)
++
+ with patch('swift.common.utils._libc_setpriority',
+_fake_setpriority), \
+ patch('swift.common.utils._posix_syscall', _fake_syscall):
diff -Nru swift-2.10.1/debian/patches/series swift-2.10.1/debian/patches/series
--- swift-2.10.1/debian/patches/series  2017-01-13 10:05:12.0 +0100
+++ swift-2.10.1/debian/patches/series  2017-04-20 22:51:28.0 +0200
@@ -2,3 +2,4 @@
 syslog_log_name.patch
 Quarantine_malformed_database_schema_SQLite_errors.patch
 For_any_part_only_one_replica_can_move_in_a_rebalance.patch
+FTBFS_i386.patch

Bug#860852: qtcharts-opensource-src binary-all FTBFS: error: cannot find -lQt5Charts

[Adrian Bunk]

Source: qtcharts-opensource-src
Version: 5.7.1-2
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=qtcharts-opensource-src&arch=all&ver=5.7.1-2&stamp=1492693412&raw=0

...
g++ -Wl,-z,relro -Wl,--as-needed -Wl,-O1 -fuse-ld=gold -Wl,--enable-new-dtags 
-shared -o libqtchartsqml2.so .obj/chartsqml2_plugin.o .obj/declarativechart.o 
.obj/declarativexypoint.o .obj/declarativexyseries.o 
.obj/declarativelineseries.o .obj/declarativesplineseries.o 
.obj/declarativeareaseries.o .obj/declarativescatterseries.o 
.obj/declarativepieseries.o .obj/declarativebarseries.o 
.obj/declarativecategoryaxis.o .obj/declarativemargins.o .obj/declarativeaxes.o 
.obj/declarativepolarchart.o .obj/declarativeboxplotseries.o 
.obj/declarativechartnode.o .obj/declarativerendernode.o 
.obj/moc_declarativerendernode.o  -L/«PKGBUILDDIR»/lib -lQt5Charts -lQt5Quick 
-lQt5Widgets -lQt5Gui -lQt5Qml -lQt5Network -lQt5Core -lGL -lpthread  
/usr/bin/ld.gold: error: cannot find -lQt5Charts
collect2: error: ld returned 1 exit status
Makefile:134: recipe for target '../../qml/QtCharts/libqtchartsqml2.so' failed
make[2]: *** [../../qml/QtCharts/libqtchartsqml2.so] Error 1

Bug#860850: python-pgpy FTBFS: FAIL tests/test_05_actions.py

[Adrian Bunk]

Source: python-pgpy
Version: 0.4.1-2
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=python-pgpy&arch=all&ver=0.4.1-2&stamp=1492644100&raw=0

...
=== short test summary info 
FAIL 
tests/test_05_actions.py::TestPGPMessage::()::test_new_non_unicode_cleartext
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.TripleDES]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.CAST5]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.Blowfish]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.AES128]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.AES192]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.AES256]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.Camellia128]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.Camellia192]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/ecc.1.sec.asc-SymmetricKeyAlgorithm.Camellia256]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.TripleDES]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.CAST5]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.Blowfish]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.AES128]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.AES192]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.AES256]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.Camellia128]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.Camellia192]
FAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_decrypt_message[tests/testdata/keys/rsa.1.sec.asc-SymmetricKeyAlgorithm.Camellia256]
SKIP [12] 
/<>/.pybuild/pythonX.Y_3.5/build/tests/test_05_actions.py:829: 
Asymmetric encryption only implemented for RSA/ECDH currently
SKIP [18] 
/<>/.pybuild/pythonX.Y_3.5/build/tests/test_05_actions.py:847: 
Message not present; see test_encrypt_message skip or xfail reason
SKIP [1] 
/<>/.pybuild/pythonX.Y_3.5/build/tests/test_05_actions.py:505: not 
implemented yet
SKIP [1] 
/<>/.pybuild/pythonX.Y_3.5/build/tests/test_02_packets.py:51: not 
implemented yet
SKIP [1] 
/<>/.pybuild/pythonX.Y_3.5/build/tests/test_03_armor.py:315: not 
ready for file 'armoredfile.asc'
XFAIL 
tests/test_05_actions.py::TestPGPMessage::()::test_decrypt_passphrase_message[message.literal.nomdc.pass.cast5.asc]
  reason: BCPG encryption not yet handled correctly
XFAIL 
tests/test_05_actions.py::TestPGPMessage::()::test_decrypt_passphrase_message[message.nomdc.pass.asc]
  reason: BCPG encryption not yet handled correctly
XFAIL 
tests/test_05_actions.py::TestPGPKey_Management::()::test_add_subkey[RSAEncryptOrSign-ElGamal-1024]
  reason: Key algorithm ElGamal not yet supported
XFAIL 
tests/test_05_actions.py::TestPGPKey_Management::()::test_add_subkey[DSA-ElGamal-1024]
  reason: Key algorithm ElGamal not yet supported
XFAIL 
tests/test_05_actions.py::TestPGPKey_Management::()::test_add_subkey[ECDSA-ElGamal-1024]
  reason: Key algorithm ElGamal not yet supported
XFAIL 
tests/test_05_actions.py::TestPGPKey_Management::()::test_revoke_subkey[RSAEncryptOrSign-ElGamal-1024]
  reason: Key algorithm ElGamal not yet supported
XFAIL 
tests/test_05_actions.py::TestPGPKey_Management::()::test_revoke_subkey[DSA-ElGamal-1024]
  reason: Key algorithm ElGamal not yet supported
XFAIL 
tests/test_05_actions.py::TestPGPKey_Management::()::test_revoke_subkey[ECDSA-ElGamal-1024]
  reason: Key algorithm ElGamal not yet supported
XFAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_encrypt_message[ECDSA:EllipticCurveOID.NIST_P256-Plaintext]
  reason: Symmetric cipher 0 not supported for encryption
XFAIL 
tests/test_05_actions.py::TestPGPKey_Actions::()::test_encrypt_message[ECDSA:EllipticCurveOID.

Bug#860849: duplicity: Duplicity OOMs machines while processing backup chains (memleak?)

[Maarten Aertsen]

Package: duplicity
Version: 0.7.10-1~bpo8+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Using duplicity with a S3 remote for a while, until multiple backup chains 
exist.

   * What exactly did you do (or not do) that was effective (or ineffective)?
/usr/bin/duplicity full --s3-use-ia --asynchronous-upload --encrypt-key  
--encrypt-key  --include-filelist /etc/backup-targets / 

(same effect when substituting full for incremental or collection-status)

   * What was the outcome of this action?
Sudden spikes in CPU and memory consumption resulting in a machine that does 
not react to console or ssh logins until reboot. Screen displays kernel 
warnings for hung tasks / timeouts (unfortunately not recoverable from logging).

   * What outcome did you expect instead?
Normal completion of full and incremental backups

when run using a soft ulimit on memory use, I get the following error trace:

>8 snip >8
Reading globbing filelist /etc/backup-targets
Local and Remote metadata are synchronized, no sync needed.


Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1553, in 
with_tempdir(main)
  File "/usr/bin/duplicity", line 1547, in with_tempdir
fn()
  File "/usr/bin/duplicity", line 1398, in main
do_backup(action)
  File "/usr/bin/duplicity", line 1423, in do_backup
globals.archive_dir).set_values()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 710, 
in set_values
self.get_backup_chains(partials + backend_filename_list)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 836, 
in get_backup_chains
add_to_sets(f)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 830, 
in add_to_sets
if new_set.add_filename(filename):
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 101, 
in add_filename
self.set_manifest(filename)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 148, 
in set_manifest
self.set_files_changed()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 128, 
in set_files_changed
mf = self.get_manifest()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 250, 
in get_manifest
return self.get_local_manifest()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 224, 
in get_local_manifest
return manifest.Manifest().from_string(manifest_buffer)
  File "/usr/lib/python2.7/dist-packages/duplicity/manifest.py", line 215, in 
from_string
vi = VolumeInfo().from_string(match.group(1))
MemoryError
>8 snip >8

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

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

Versions of packages duplicity depends on:
ii  libc62.19-18+deb8u7
ii  librsync10.9.7-10
ii  python   2.7.9-1
ii  python-lockfile  1:0.8-2

Versions of packages duplicity recommends:
ii  python-oauthlib  0.6.3-1
ii  python-paramiko  1.15.1-1
ii  python-urllib3   1.9.1-3
ii  rsync3.1.1-3

Versions of packages duplicity suggests:
pn  lftp
pn  ncftp   
ii  python-boto 2.34.0-2
pn  python-cloudfiles   
pn  python-gdata
pn  python-swiftclient  
ii  tahoe-lafs  1.10.0-2

-- no debconf information

Bug#860848: osinfo-db: please make the build reproducible

[Chris Lamb]

Source: osinfo-db
Version: 0.20170225-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that osinfo-db could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/Reproducible-Build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/Reproducible-Build.patch   2017-04-20 22:40:45.831950626 
+0100
@@ -0,0 +1,19 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-04-20
+
+--- osinfo-db-0.20170225.orig/Makefile
 osinfo-db-0.20170225/Makefile
+@@ -1,7 +1,11 @@
+ 
+ VPATH = .
+ 
+-TODAY = $(shell date +"%Y%m%d")
++ifdef SOURCE_DATE_EPOCH
++TODAY = $(shell date --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y%m%d")
++else
++TODAY = $(shell date +"%Y%m%d")
++endif
+ 
+ OSINFO_DB_EXPORT = osinfo-db-export
+ OSINFO_DB_IMPORT = osinfo-db-import
--- a/debian/patches/series 2017-04-20 22:36:19.898842751 +0100
--- b/debian/patches/series 2017-04-20 22:40:45.007947191 +0100
@@ -1,2 +1,3 @@
 Debian-Jessie-Update-DVD-links.patch
 Add-Debian-Stretch-RCs.patch
+Reproducible-Build.patch

Bug#835654: [Pkg-net-snmp-devel] Orphaning net-snmp?

[Craig Small]

I tried taking over this but the alioth permissions were wrong and admin is
unresponsive.

- Craig

On Fri, 21 Apr. 2017, 02:12 Adrian Bunk,  wrote:

> Control: retitle -1 O: net-snmp -- SNMP configuration script, MIBs and
> documentation
>
> Thanks to everyone for answering, I hereby orphan net-snmp.
>
> On Mon, Feb 27, 2017 at 02:08:16PM +0100, Jochen Friedrich wrote:
> > Yes, +1
> >
> >
> > Am 22.01.2017 um 16:01 schrieb Noah Meyerhans:
> > > On Sun, Jan 22, 2017 at 11:19:46PM +0900, Hideki Yamane wrote:
> > > > > Since the #835654 RFH didn't result in new members joining the
> team,
> > > > > would it be OK if I orphan the package to make it clear that there
> > > > > is no maintainer and that anyone can make a QA upload without
> delay?
> > > >   I've already stepped down from uploaders, so if Jochen would agree
> > > >   with it, it should be orphaned.
> > > I'm listed in Uploaders but
> > >   a) I'm not using net-snmp actively anywhere; and
> > >   b) The only uploads I ever did were targeting stable-security, and I
> > >  was never active in general package maintenance.
> > >
> > > So, +1 to orphan.
> > >
> > > noah
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
>
> ___
> Pkg-net-snmp-devel mailing list
> pkg-net-snmp-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-net-snmp-devel
>
-- 
Craig Small (@smallsees)   http://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#860011: spim: diff for NMU version 8.0+dfsg-6.1

[Tim Retout]

Please find attached the NMU diff for spim 8.0+dfsg-6.1, which I have
uploaded as a zero-day NMU, as per devref 5.11.1:

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

Kind regards,

-- 
Tim Retout 
diff -Nru spim-8.0+dfsg/debian/changelog spim-8.0+dfsg/debian/changelog
--- spim-8.0+dfsg/debian/changelog  2013-11-09 18:56:54.0 +
+++ spim-8.0+dfsg/debian/changelog  2017-04-20 19:48:30.0 +0100
@@ -1,3 +1,11 @@
+spim (8.0+dfsg-6.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Add patch for flex 2.6 compatibility. (Closes: #860011)
+  * Urgency high for RC bug fix.
+
+ -- Tim Retout   Thu, 20 Apr 2017 19:48:30 +0100
+
 spim (8.0+dfsg-6) unstable; urgency=low
 
   * acknowledge NMU
diff -Nru spim-8.0+dfsg/debian/patches/flex-2.6-compat 
spim-8.0+dfsg/debian/patches/flex-2.6-compat
--- spim-8.0+dfsg/debian/patches/flex-2.6-compat1970-01-01 
01:00:00.0 +0100
+++ spim-8.0+dfsg/debian/patches/flex-2.6-compat2017-04-20 
19:38:52.0 +0100
@@ -0,0 +1,20 @@
+Description: Fix parsing when built with flex 2.6
+Origin: https://sourceforge.net/p/spimsimulator/code/679/
+Bug: https://sourceforge.net/p/spimsimulator/bugs/66/
+Bug-Debian: https://bugs.debian.org/860011
+Last-Update: 2017-04-20
+
+Index: spim-8.0+dfsg/CPU/scanner.l
+===
+--- spim-8.0+dfsg.orig/CPU/scanner.l
 spim-8.0+dfsg/CPU/scanner.l
+@@ -316,7 +316,8 @@ initialize_scanner (FILE *in_file)
+   yyin = in_file;
+ #ifdef FLEX_SCANNER
+   yyrestart(in_file);
+-#if (YY_FLEX_MAJOR_VERSION==2 && YY_FLEX_MINOR_VERSION==5 && 
YY_FLEX_SUBMINOR_VERSION>=33)
++#define YY_FLEX_VERSION (YY_FLEX_MAJOR_VERSION * 1000 + YY_FLEX_MINOR_VERSION 
* 100 + YY_FLEX_SUBMINOR_VERSION)
++#if YY_FLEX_VERSION >= 2533
+   /* flex 2.5.33 flipped the polarity of this flag (sigh) */
+   yy_init = 0;
+ #else
diff -Nru spim-8.0+dfsg/debian/patches/series 
spim-8.0+dfsg/debian/patches/series
--- spim-8.0+dfsg/debian/patches/series 2013-11-08 13:34:19.0 +
+++ spim-8.0+dfsg/debian/patches/series 2017-04-20 14:01:47.0 +0100
@@ -2,3 +2,4 @@
 hyphens
 configure-multiarch
 run-remove-mips.diff
+flex-2.6-compat

Bug#860834: u-boot-amlogic: u-boot.bin is not directly usable

[Heinrich Schuchardt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/20/2017 10:20 PM, Vagrant Cascadian wrote:
> On 2017-04-20, Heinrich Schuchardt wrote:
>> Unfortunately this package alone is insufficient to set up U-Boot
>> on the Odroid C2.
> 
> Right, the install process should be documented in:
> 
> /usr/share/doc/u-boot-amlogic/README
> 
> 
>> The following tools are missing: - fip_create from 
>> https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01
> 
>> - amlbootsig from https://github.com/afaerber/meson-tools
> 
> Ah, wasn't aware of this one, thanks!
> 
> 
>> Furthermore the firmware is needed. The source is possibly
>> contained in 
>> http://openlinux.amlogic.com:8000/download/ARM/u-boot/uboot-2016-08-1
8-edd7f116ab.tar.gz
>
>> 
> I don't see source code for the firmware in there. e.g. fip/gx*
> only includes binaries.

The hardkernel binaries are fip/gx based. I will try to understand the
details.

See also
https://github.com/hardkernel/u-boot_firmware/tree/odroidc2-bl301
with description in
http://odroid.com/dokuwiki/doku.php?id=en:c2_building_u-boot
Chapter "How to build u-boot with bl301 firmware"

> 
> 
>> The finished binaries are available from 
>> https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01
>> 
>> My idea is that we should create three packages: - fip_create
>> (BSD) - meson-tools (GPLv2+)
> 
> Both of those look feasible, sure, though fip_create could perhaps
> just be included with u-boot-tools.
> 

fip_create seems to be rather Amlogic specific.
So merging with meson-tools might be a better option?

> 
>> - odroidc2-firmware (BSD if built form source)
> 
> No source, no package...

I guess for non-free firmware package we would at least need a
specific license.

Regards

Heinrich
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY+ShhAAoJEMSB27wsBRrE2pMP/RUGQmnu1Lg36MA/uwH268Hz
EwdznSH7pWNLxGhobOB2hCOc5V0fFE/4emA1JY3EcGd5Jw0o57ROyOd3QLKgSlDP
Mabn/q4TUBkDStNjoByp+ma5KkXFVEgBxEavDZKGxtO4DIgn871iu1FGZTooIRoK
s4A5pUcmq7WL25EWUydpPoY4AtNaM8gxe9xxOqo65uzNxrRYkara75xWe27XjHaW
yvZrg5iAJ9WUGJGbWaV5mGK2VJ14jDFhva9c7m8k8yFWaadKeeTjHfQ1Y19C0wa1
Id0SdvJbu/LHu0xCr4PYyL6jFukwebwPMpgU58I+g5f9za28NBLBPSR4NNOnh6Tx
0Sc01DU4nzCmA/6a9bJY8qmumDoqLZLxgszYdUG51Eq9m/kmLKDgIuOPph3Ipkmd
JO76dQaRUBFzzpMnovgfeGN/VCyh5CUzH996vi1oj1Ce3uAMcDhbgF5TWBIX4vHk
qpoVdF2jNRRGIzekJ9Z3v1BW3OcToHcDUY4DT/mF6tKzIUWOZYS5slQTb5KfI+P3
5WUu8HxrY0oMgeLK91I47xp9DIWSwDjVasx2YcHr++mOJ1zV6gc1gbbXsNtkBd36
T8kd2kduv1zDyyfsII5t8KaVTCXvhdrXhMCkJkKNMXQVz7Xt2GZ5z+vORJ1meYjs
GD1PlPVmal4nbWRknWMb
=3zNd
-END PGP SIGNATURE-

Bug#860847: libbson FTBFS on mips/mipsel: test-atomic.c:38: undefined reference to `__sync_add_and_fetch_8'

[Adrian Bunk]

Source: libbson
Version: 1.6.1-1
Severity: serious

https://buildd.debian.org/status/package.php?p=libbson&suite=sid

...
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -O2 -g  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o 
test-libbson tests/test_libbson-TestSuite.o tests/test_libbson-test-libbson.o 
tests/test_libbson-test-atomic.o tests/test_libbson-test-bson.o 
tests/test_libbson-test-endian.o tests/test_libbson-test-clock.o 
tests/test_libbson-test-decimal128.o tests/test_libbson-test-error.o 
tests/test_libbson-test-iso8601.o tests/test_libbson-test-iter.o 
tests/test_libbson-test-json.o tests/test_libbson-test-oid.o 
tests/test_libbson-test-reader.o tests/test_libbson-test-string.o 
tests/test_libbson-test-type.o tests/test_libbson-test-utf8.o 
tests/test_libbson-test-value.o tests/test_libbson-test-version.o 
tests/test_libbson-test-writer.o tests/test_libbson-test-bcon-basic.o 
tests/test_libbson-test-bcon-extract.o tests/test_libbson-json-test.o  
libbson-1.0.la libbson.la -latomic 
libtool: link: gcc -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-fstack-protector-strong -Wformat -Werror=format-security -O2 -g -Wl,-z 
-Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -o .libs/test-libbson 
tests/test_libbson-TestSuite.o tests/test_libbson-test-libbson.o 
tests/test_libbson-test-atomic.o tests/test_libbson-test-bson.o 
tests/test_libbson-test-endian.o tests/test_libbson-test-clock.o 
tests/test_libbson-test-decimal128.o tests/test_libbson-test-error.o 
tests/test_libbson-test-iso8601.o tests/test_libbson-test-iter.o 
tests/test_libbson-test-json.o tests/test_libbson-test-oid.o 
tests/test_libbson-test-reader.o tests/test_libbson-test-string.o 
tests/test_libbson-test-type.o tests/test_libbson-test-utf8.o 
tests/test_libbson-test-value.o tests/test_libbson-test-version.o 
tests/test_libbson-test-writer.o tests/test_libbson-test-bcon-basic.o 
tests/test_libbson-test-bcon-extract.o tests/test_libbson-json-test.o  
./.libs/libbson-1.0.so ./.libs/libbson.a -latomic -pthread
tests/test_libbson-test-atomic.o: In function `test2':
./tests/test-atomic.c:38: undefined reference to `__sync_add_and_fetch_8'
./tests/test-atomic.c:38: undefined reference to `__sync_add_and_fetch_8'
collect2: error: ld returned 1 exit status
Makefile:1238: recipe for target 'test-libbson' failed
make[2]: *** [test-libbson] Error 1

Bug#850731: xorp: segfaults at initialization, linker flags

[Dhionel Díaz]

On 02/03/17 17:08, Ben Greear wrote:
> Just FYI, I pushed this change plus an additional null check
> in related code.  If fixes the crash I was seeing on my Fedora-24 systems,
> and it would appear to be the same bug earlier reported.
> 
> Thanks,
> Ben
> 
> On 01/10/2017 12:50 PM, Dhionel Díaz wrote:
>> El 10/01/17 a las 15:59, Jose M Calhariz escribió:
>>> Hi, I have contacted the upstream author, Ben Greear, about this
>>> problem.  And he requested
>>> if you have a back trace?
>>>
 I would be interested in seeing a backtrace if the user has
>>> it
>>>
 so I could better understand the problem.  Maybe the code should
>>> never
>>>
 actually be trying to call these methods if _root is NULL?
>>>
>>> Can you help the author?
>>>
>>> Kind regards
>>> Jose M Calhariz
>>>
>>>
>> (...)
>> Hi, attached you will find the requested backtrace. Thanks for your
>> attention.
>>
>> Regards,
>>
> 
> 
Hi, I can confirm that the changes have been working properly in our
router all this time. Thanks for your attention.

Regards,

-- 
Dhionel Díaz
Centro Nacional de Desarrollo e Investigación en Tecnologías Libres
Ministerio del Poder Popular para
Educación Universitaria, Ciencia y Tecnología



signature.asc
Description: OpenPGP digital signature

Bug#860846: spacefm: maintainer scripts call update-mime-database manually

[Luca Boccassi]

Package: spacefm
Version: 1.0.5-2
Severity: important

Dear Maintainer,

This package calls update-mime-database manually from a maintainer
script and depends on shared-mime-info. Both are unnecessary these
days, and are handled by dpkg triggers automatically, so they should be
dropped, as they could cause issues in some cases during upgrades.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859587 for an
example.

Thank you!

Kind regards,
Luca Boccassi

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

Bug#860845: tuxguitar: maintainer scripts call update-mime-database manually

[Luca Boccassi]

Package: tuxguitar
Version: 1.2-22
Severity: important

Dear Maintainer,

This package calls update-mime-database manually from a maintainer
script and depends on shared-mime-info. Both are unnecessary these
days, and are handled by dpkg triggers automatically, so they should be
dropped, as they could cause issues in some cases during upgrades.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859587 for an
example.

Thank you!

Kind regards,
Luca Boccassi

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

Bug#860844: rox-filer: maintainer scripts call update-mime-database manually

[Luca Boccassi]

Package: rox-filer
Version: 1:2.11-1
Severity: important

Dear Maintainer,

This package calls update-mime-database manually from a maintainer
script and depends on shared-mime-info. Both are unnecessary these
days, and are handled by dpkg triggers automatically, so they should be
dropped, as they could cause issues in some cases during upgrades.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859587 for an
example.

Thank you!

Kind regards,
Luca Boccassi

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

Bug#851066: flashplugin-nonfree: Mismatch between detected and available versions (Download file not available at people.debian.org)

[Leo L. Schwab]

Package: flashplugin-nonfree
Version: 1:3.7
Followup-For: Bug #851066

Dear Maintainer,

This note is more for followers of this bug than the maintainer.

I decided to spend some non-trivial time to try and craft a patch
that would skip downloading and checking the little information blobs from
~bartm's account, thereby removing the dependency on updates from ~bartm.
After a little while, I concluded that this approach would be nearly
impossible to solve in the general case.

The fundamental problem is that Adobe can't be relied upon to
provide a consistent URL for downloading the Flash tarball.  ~bartm's
solution to this issue appears to have been to extract crucial metadata from
the most current Linux download on Adobe's site (presumably by hand), place
them in a small text file along with some SHA512 hashes, and then GPG-sign
the file.

As a consequence, the files pulled from ~bartm's account contain
crucial metadata that the update-flashplugin-nonfree script needs to locate
and download the plugin from Adobe's site.  Obviously, it is impossible to
parse Adobe's Web pages at runtime, as they rely heavily (and unnecesarily)
on dynamic HTML and JavaScript; and Adobe's download directories don't
enumerate -- you either give it exactly the right URL, or you get a 404.

The next thing I'm going to try is to add an option to unpack and
install an already-downloaded Flash tar file.  Not nearly as seamless, but
far better than people doing it by hand.

Schwab


-- Package-specific info:
Debian version: 9.0
Architecture: amd64
Package version: 1:3.7
Adobe Flash Player version: LNX 24,0,0,186
MD5 checksums:
a618a20ef0bf4f463960134486a2ed7b  
/var/cache/flashplugin-nonfree/flash_player_npapi_linux.x86_64.tar.gz
29c85bc8504422120cf89702986ff8e1  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
82cd4f82b2023fad1d43092de8e002a7  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
52d5e951bafcdb493d1a980a62c0f80e  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
lrwxrwxrwx 1 root root 34 Aug  4  2016 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
/etc/alternatives/flash-mozilla.so

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

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

Versions of packages flashplugin-nonfree depends on:
ii  binutils   2.28-4
ii  ca-certificates20161130
ii  debconf [debconf-2.0]  1.5.60
ii  gnupg  2.1.18-6
ii  gnupg2 2.1.18-6
ii  libatk1.0-02.22.0-1
ii  libcairo2  1.14.8-1
ii  libcurl3-gnutls7.52.1-5
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.1
ii  libgcc11:6.3.0-14
ii  libglib2.0-0   2.50.3-2
ii  libgtk2.0-02.24.31-2
ii  libnspr4   2:4.12-6
ii  libnss32:3.26.2-1
ii  libpango1.0-0  1.40.5-1
ii  libstdc++6 6.3.0-14
ii  libx11-6   2:1.6.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxt6 1:1.1.5-1
ii  wget   1.19.1-3

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
pn  firefox-esr
ii  fonts-dejavu   2.37-1
pn  hal-flash  
pn  iceweasel  
pn  konqueror-nsplugins
ii  ttf-mscorefonts-installer  3.6
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#859778: RFS: xtrs/4.9d-2

[G. Branden Robinson]

At 2017-04-20T09:45:13-0700, Sean Whitton wrote:
> Hello Branden,

Hi Sean!

> On Wed, Apr 12, 2017 at 11:09:45PM -0400, G. Branden Robinson wrote:
> > Yeah, I didn't understand that at the time.  Subsequently I changed all
> > the 4.9d changelog entries to target experimental.
> > 
> > > Thus, it'd be better to target the new version at experimental instead
> > > (or refrain from updates for now -- but that goes against "release
> > > early, release often" and makes debdiffs far harder to read).
> > 
> > It sounds like I should maybe just forget about -2 and upload -3.  I had
> > one more thing I wanted to do for it but it's a big task, rather
> > involved, and not required.
> 
> What is the status of this RFS?  Are you still working on the upload to
> experimental?

Sure am.  In fact I have xtrs 4.9d-3 pretty much ready to go except for
the official versioning and tagging.  I've also been in touch with
upstream; he's been working on an xtrs 5.0 for quite some time.  :)

See attachments.  I've also pushed my work to alioth.

-- 
Regards,
Branden
Format: 3.0 (quilt)
Source: xtrs
Binary: xtrs
Architecture: any
Version: 4.9d-3~~unreleased
Maintainer: G. Branden Robinson 
Homepage: http://www.tim-mann.org/xtrs.html
Standards-Version: 3.9.8
Build-Depends: bsdmainutils, debhelper (>= 9), groff-base, html2text, 
libreadline-dev, libx11-dev, po-debconf
Package-List:
 xtrs deb contrib/otherosfs extra arch=any
Checksums-Sha1:
 42b1fc90246901456d29071421e838b545f39f0f 99 xtrs_4.9d.orig.tar.gz
 a346107dc33d28e66e440590edeb63c1e35fe679 100156 
xtrs_4.9d-3~~unreleased.debian.tar.xz
Checksums-Sha256:
 3985f2331e76198dfc027bc2afcd09a158d2bcad0348aeb4a4958a8fb99cf5c4 99 
xtrs_4.9d.orig.tar.gz
 702129c437c486a6b98d75b54ff1561aff16b1e59b96189e44c6c9a31a873163 100156 
xtrs_4.9d-3~~unreleased.debian.tar.xz
Files:
 93868bed769c038bfae907375316bb2d 99 xtrs_4.9d.orig.tar.gz
 f89963f7dc0155dd23eeb65f9d4d3f23 100156 xtrs_4.9d-3~~unreleased.debian.tar.xz
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package xtrs
dpkg-buildpackage: info: source version 4.9d-3~~unreleased
dpkg-buildpackage: info: source distribution experimental
dpkg-buildpackage: info: source changed by G. Branden Robinson 

 dpkg-source --before-build xtrs
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: applying prep-makefiles-for-debian.patch
dpkg-source: info: applying fix-compiler-warnings.patch
dpkg-source: info: applying ignore-alt-key-events.patch
dpkg-source: info: applying add-ifdef-guards-around-setuid.patch
dpkg-source: info: applying stop-ignoring-result-from-fread.patch
dpkg-source: info: applying make-plain-text-docs-from-html.patch
dpkg-source: info: applying debian-stop-clobbering-cflags-and-ldflags.patch
dpkg-source: info: applying mkdisk-document-d-option-in-usage-message.patch
dpkg-source: info: applying stop-mkdisk-from-overflowing-buffers.patch
dpkg-source: info: applying mkdisk-check-fopen-return-with-dmk-images.patch
dpkg-source: info: applying mkdisk-protect-against-overwrites.patch
dpkg-source: info: applying this-one-goes-to-c11.patch
dpkg-source: info: applying hex2cmd-idiomatize-manpage.patch
dpkg-source: info: applying cmddump-idiomatize-manpage.patch
dpkg-source: info: applying cassette-idiomatize-manpage.patch
dpkg-source: info: applying debian-cassette-manpage-del-paragraph.patch
dpkg-source: info: applying mkdisk-idiomatize-manpage.patch
dpkg-source: info: applying xtrs-idiomatize-manpage.patch
dpkg-source: info: applying makefile-generate-pdf-manpages.patch
dpkg-source: info: applying emtsafe-flag-on-by-default.patch
dpkg-source: info: applying write-online-help-to-stderr-if-small-window.patch
dpkg-source: info: applying kill-last-fprintf-stderr-stragglers.patch
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
make -j1 clean
make[1]: Entering directory '/home/branden/git/debian/xtrs'
rm -f z80.o main.o load_cmd.o load_hex.o trs_memory.o trs_keyboard.o error.o 
debug.o dis.o trs_io.o trs_cassette.o trs_xinterface.o trs_chars.o 
trs_printer.o trs_rom1.o trs_rom3.o trs_rom4p.o trs_disk.o trs_interrupt.o 
trs_imp_exp.o trs_hard.o trs_uart.o mkdisk.o compile_rom.o error.o load_cmd.o 
load_hex.o cmd.o error.o load_hex.o hex2cmd.o \
cmddump.o load_cmd.o trs_rom*.c *~ \
xtrs mkdisk hex2cmd cmddump compile_rom \
cpmutil.txt dskspec.txt
make[1]: Leaving directory '/home/branden/git/debian/xtrs'
   dh_clean
rm -f debian/debhelper-build-stamp
rm -f debian/xtrs.substvars
rm -f debian/xtrs.*.debhelper
rm -rf debian/xtrs/
rm -rf debian/.debhelper/
rm -f debian/*.debhelper.log
rm -f debian/files
rm -f -- debian/copyright-info.actual debian/no-copyright-info.actual
find .  \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path 
.\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
\( -name '#*#' -o -name 

Bug#860843: ITP: node-string-decoder -- The string_decoder module from Node core

[Bastien ROUCARIES]

package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: node-string-decoder
  Version : 0.10.25
  Upstream Author : Rod Vagg 
* URL : https://github.com/rvagg/string_decoder
* License : Expat
  Programming Lang: JavaScript
  Description : The string_decoder module from Node core

node-string-decoder provides the string_decoder module from Node.js core for
browsers.


node-string-decoder is required for node-readable-stream (#761442) which in
turn is required for node-decompress-zip (#779498).

The node-string-decoder package will be maintained in the JavaScript team.

This is a reintroduction due to browser needing verbatim for one
package of browserify

Bug#860842: silently exits on first run

[Antoine Beaupre]

Package: redshift-gtk
Version: 1.9.1-4
Severity: normal

I have recommended this tool to a friend that has this problem of
using the computer too late at night (bad boy, go to sleep! ;).

When we did the first setup, my friend naturally clicked on the
Redshift icon in the application menus, and the app at first seemed to
start fine, but then just disappeared.

I then realized I had tweaked my own app to hardcode my location and
promptly went around applying the same config (in
.config/redshift.conf) to my poor confused user. While this is
documented in the configuration file, there is little chance my user
would have (in order of skill level required):

 1. found the documentation

 2. read through it

 3. figured out how to create a configuration file

 4. figured out the exact coordinates where he is

 5. convert them from DD°MM'SS" to DD.DD°

Granted, levels 3-5 may vary. :) And yes, most skilled users can
figure that out, but a lot of Debian users cannot do that, and I would
argue they should not *have* to do this.

The GUI should provide them with a configuration menu, or at least a
popup explaining that the app is not configured, not silently fail.

I don't remember exactly why redshift failed to start. I remember it
was on a Jessie system, running in a regular Gnome session, which had
the added disadvantage of hiding the notification area so even when we
configured the app correctly, we still wouldn't see it.

We also tried running it in Cinnamon - there it was a little better
because the notification area is more visible.

Anyways - it would nice to improve the behavior in case of failure for
our less technical users.

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages redshift-gtk depends on:
ii  gir1.2-appindicator3-0.1  0.4.92-4
ii  python3-gi3.22.0-2
ii  python3-xdg   0.25-4
pn  python3:any   
ii  redshift  1.11-1

Versions of packages redshift-gtk recommends:
ii  at-spi2-core  2.22.0-5+b1

redshift-gtk suggests no packages.

-- no debconf information

Bug#860784: linux-image-4.9.0-2-amd64: Hauppage WinTV Aero-M no longer works in kernel 4.9

[Steve VanDevender]

Out of curiousity, I tried plugging my WinTV Aero-M into another system
I had just upgraded to stretch, and found that it was fully recognized.
The difference is that the other system uses the 686-pae kernel and
ehci-pci instead of xhci_hcd.

Apr 20 13:30:25 scuzzy kernel: [11823.736052] usb 3-6: new high-speed USB 
device number 3 using ehci-pci
Apr 20 13:30:25 scuzzy kernel: [11823.884874] usb 3-6: New USB device found, 
idVendor=2040, idProduct=c61b
Apr 20 13:30:25 scuzzy kernel: [11823.884881] usb 3-6: New USB device strings: 
Mfr=1, Product=2, SerialNumber=3
Apr 20 13:30:25 scuzzy kernel: [11823.884884] usb 3-6: Product: WinTV Aero-M
Apr 20 13:30:25 scuzzy kernel: [11823.884886] usb 3-6: Manufacturer: Hauppauge
Apr 20 13:30:25 scuzzy kernel: [11823.884888] usb 3-6: SerialNumber: 4034988989
Apr 20 13:30:25 scuzzy kernel: [11824.424407] usb 3-6: dvb_usb_v2: found a 
'Hauppauge WinTV-Aero-M' in warm state
Apr 20 13:30:25 scuzzy kernel: [11824.427956] usb 3-6: dvb_usb_v2: will pass 
the complete MPEG2 transport stream to the software demuxer
Apr 20 13:30:25 scuzzy kernel: [11824.433486] DVB: registering new adapter 
(Hauppauge WinTV-Aero-M)
Apr 20 13:30:26 scuzzy kernel: [11825.025553] MxL111SF detected, v8_200 (0x18)
Apr 20 13:30:26 scuzzy kernel: [11825.035446] usb 3-6: DVB: registering adapter 
0 frontend 0 (LG Electronics LGDT3305 VSB/QAM Frontend)...
Apr 20 13:30:26 scuzzy kernel: [11825.035727] usb 3-6: DVB: registering adapter 
0 frontend 1 (MaxLinear MxL111SF DVB-T demodulator)...
Apr 20 13:30:26 scuzzy kernel: [11825.040799] usb 3-6: DVB: registering adapter 
0 frontend 2 (LG Electronics LG2161 ATSC/MH Frontend)...
Apr 20 13:30:26 scuzzy kernel: [11825.088554] tveeprom 7-0050: Hauppauge model 
126001, rev F2G4, serial# 4034988989
Apr 20 13:30:26 scuzzy kernel: [11825.088563] tveeprom 7-0050: MAC address is 
00:0d:fe:81:0b:bd
Apr 20 13:30:26 scuzzy kernel: [11825.088567] tveeprom 7-0050: tuner model is 
MaxLinear 111 (idx 164, type 4)
Apr 20 13:30:26 scuzzy kernel: [11825.088569] tveeprom 7-0050: TV standards 
ATSC/DVB Digital (eeprom 0x80)
Apr 20 13:30:26 scuzzy kernel: [11825.088571] tveeprom 7-0050: audio processor 
is None (idx 0)
Apr 20 13:30:26 scuzzy kernel: [11825.088574] tveeprom 7-0050: has no radio, 
has IR receiver, has no IR transmitter
Apr 20 13:30:26 scuzzy kernel: [11825.088584] usb 3-6: dvb_usb_v2: 'Hauppauge 
WinTV-Aero-M' successfully initialized and connected
Apr 20 13:30:26 scuzzy kernel: [11825.088763] usbcore: registered new interface 
driver dvb_usb_mxl111sf
Apr 20 13:30:32 scuzzy kernel: [11831.064720] usb 3-6: USB disconnect, device 
number 3
Apr 20 13:30:32 scuzzy kernel: [11831.067881] usb 3-6: dvb_usb_v2: 'Hauppauge 
WinTV-Aero-M' successfully deinitialized and disconnected
^C
scuzzy:/home/stevev# uname -a
Linux scuzzy 4.9.0-2-686-pae #1 SMP Debian 4.9.18-1 (2017-03-30) i686 GNU/Linux

For comparision here is the output for a jessie kernel, also on 686-pae:

Apr 20 11:25:39 hexadecimal kernel: [3705894.940040] usb 6-5: new high-speed 
USB device number 7 using ehci-pci
Apr 20 11:25:39 hexadecimal kernel: [3705895.072918] usb 6-5: New USB device 
found, idVendor=2040, idProduct=c61b
Apr 20 11:25:39 hexadecimal kernel: [3705895.072923] usb 6-5: New USB device 
strings: Mfr=1, Product=2, SerialNumber=3
Apr 20 11:25:39 hexadecimal kernel: [3705895.072924] usb 6-5: Product: WinTV 
Aero-M
Apr 20 11:25:39 hexadecimal kernel: [3705895.072926] usb 6-5: Manufacturer: 
Hauppauge
Apr 20 11:25:39 hexadecimal kernel: [3705895.072928] usb 6-5: SerialNumber: 
4034988989
Apr 20 11:25:39 hexadecimal mtp-probe: checking bus 6, device 7: 
"/sys/devices/pci:00/:00:1d.7/usb6/6-5"
Apr 20 11:25:39 hexadecimal mtp-probe: bus: 6, device: 7 was not an MTP device
Apr 20 11:25:40 hexadecimal kernel: [3705896.407955] usb 6-5: dvb_usb_v2: found 
a 'Hauppauge WinTV-Aero-M' in warm state
Apr 20 11:25:40 hexadecimal kernel: [3705896.407995] usb 6-5: dvb_usb_v2: will 
pass the complete MPEG2 transport stream to the software demuxer
Apr 20 11:25:40 hexadecimal kernel: [3705896.408115] DVB: registering new 
adapter (Hauppauge WinTV-Aero-M)
Apr 20 11:25:41 hexadecimal kernel: [3705897.241179] MxL111SF detected, v8_200 
(0x18)
Apr 20 11:25:41 hexadecimal kernel: [3705897.247519] usb 6-5: DVB: registering 
adapter 0 frontend 0 (LG Electronics LGDT3305 VSB/QAM Frontend)...
Apr 20 11:25:41 hexadecimal kernel: [3705897.247589] usb 6-5: DVB: registering 
adapter 0 frontend 1 (MaxLinear MxL111SF DVB-T demodulator)...
Apr 20 11:25:41 hexadecimal kernel: [3705897.247728] usb 6-5: DVB: registering 
adapter 0 frontend 2 (LG Electronics LG2161 ATSC/MH Frontend)...
Apr 20 11:25:41 hexadecimal kernel: [3705897.270931] tveeprom 6-0050: Hauppauge 
model 126001, rev F2G4, serial# 8457149
Apr 20 11:25:41 hexadecimal kernel: [3705897.270934] tveeprom 6-0050: MAC 
address is 00:0d:fe:81:0b:bd
Apr 20 11:25:41 hexadecimal kernel: [3705897.270937] tveeprom 6-0050: tuner 
model is MaxLinear 111 (idx 164, type 4)
Apr 20 11

Bug#853722: I take it

[Bastien ROUCARIES]

control: owner -1 ro...@debian.org

Bug#667979: TokyoCabinet got endianness in DB wrong on both big- and little-endian architectures

[Josh Littlefield]

Just ran into this myself when I found TC DB files are not portable from
CentOS.

Really unsure why this change was added in the first place, since
configure script has always auto-detected endianness and added swapping
compile flags (-D_MYBIGEND) when needed. The TC file format
specification is clear that the files use little-endian.

But clearly a change now would break things.  What about a parallel
package suite (e.g, libtokyocabinet-le) which does the right thing and
generates/reads portable (little-endian) files? Then at least a choice
could be made by the user or by other packages with this dependency.

Bug#860841: gtk-redshift should hook into existing running process

[Antoine Beaupre]

Package: redshift-gtk
Version: 1.11-1
Severity: wishlist

If the systemd service is enabled (and works, see #827098) then a user
wanting GUI visbility on whatever redshift is doing might naturally
start the graphical application he/she sees in the menus.

In this case, both applications get into a heated power struggle over
the color of the monitor, obviously neither winning.

It would be nice if gtk-redshift:

 1. would notice his own partner running

 2. abort with a friendly error message

 3. eventually, instead of aborting, communicate with the running
process and report information, allow toggling the status and so
on

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages redshift-gtk depends on:
ii  gir1.2-appindicator3-0.1  0.4.92-4
ii  python3-gi3.22.0-2
ii  python3-xdg   0.25-4
pn  python3:any   
ii  redshift  1.11-1

Versions of packages redshift-gtk recommends:
ii  at-spi2-core  2.22.0-5+b1

redshift-gtk suggests no packages.

-- no debconf information

Bug#860496: RFS: drgeo/1.1.0-10.3 [NMU, RC]

[Adrian Bunk]

On Tue, Apr 18, 2017 at 08:19:35PM -0400, Patrick Hetu wrote:
> > > On Mon, Apr 17, 2017 at 05:59:11PM -0400, Patrick Hetu wrote:
> > > >   * Fixed compatibility with Guile 2.0. (Closes: #707903)
> > 
> > Thank you for your work to fix this bug.
> > 
> > What is the source of the patch you have added?
> 
> I did the patch myself.
>...

drgeo is not in jessie and won't be in stretch, so there is no need to 
hurry with patching this upstream version from 2005.

https://git.gnome.org/browse/archive/drgeo/log/
This looks very dead.

#736535 mentions an active fork (that seems to be quite different).

What drgeo needs is an active maintainer who packages code that is 
also maintained upstream.

Trying to revive 2005 code after it has already missed two Debian
releases doesn't make much sense.

> thanks,
> 
> Patrick

cu
Adrian

-- 

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

Bug#860840: git-bisect: fatal: BUG: attempt to snprintf into too-small buffer with some locales

[Michael Tokarev]

Package: git
Version: 1:2.11.0-2
Severity: important
Tags: upstream l10n

When doing any git bisect with current git and LANG=ru_RU.UTF8,
it fails with 100% cases with the following message:

 fatal: BUG: attempt to snprintf into too-small buffer

This is because bisect.c:bisect_next_all() contains
the following code:

int bisect_next_all(const char *prefix, int no_checkout)
{
..
char steps_msg[32];
..
xsnprintf(steps_msg, sizeof(steps_msg),
  Q_("(roughly %d step)", "(roughly %d steps)", steps),
  steps);
..

With for example russian locale (which uses utf8), the buffer
is 2 byte too small to fit translation of "(roughly %d steps)"
message, or more depending on the actual number of steps.

Setting locale to something else helps ofcourse.

I _guess_ this buffer was initially used to hold only actual
number without any extra words, words were added later and
translated to other languages even more later.. So here we
are.

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

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

Versions of packages git depends on:
ii  dpkg 1.18.23
ii  git-man  1:2.11.0-2
ii  libc62.24-9
ii  libcurl3-gnutls  7.52.1-4
ii  liberror-perl0.17024-1
ii  libexpat12.2.0-2
ii  libpcre3 2:8.35-3.3+deb8u4
ii  perl 5.24.1-2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages git recommends:
ii  less 481-2.1
ii  openssh-client [ssh-client]  1:7.4p1-10
ii  patch2.7.5-1+b2
ii  rsync3.1.2-1

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-2
pn  git-arch  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#854508: No activity

[Bastien ROUCARIES]

control: owner -1 ro...@debian.org

Hi,

Without ctivity I take this bug report

Bug#860839: vlc fails to start due to missing QT platform plugin xcb

[Sebastian Ramacher]

Control: reassign -1 src:qtbase-opensource-src 5.5.1+dfsg-13
Control: forcemerge -1 809989

On 2017-04-20 15:56:39, Harlan Lieberman-Berg wrote:
> Package: src:vlc
> Version: 2.2.5-1
> Severity: grave
> Justification: renders package unusable
> 
> Hello maintainer,
> 
> For vlc installed on stretch freshly after a `apt install vlc`, it refuses to 
> open while complaining 
> about a failure to find the xcb Qt module.

That's #809989. Please check with the Qt maintainers if the issue still
persists.

Cheers

> Attached `vlc -vvv`.
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages vlc depends on:
> ii  dpkg 1.18.23
> ii  vlc-bin  2.2.5-1
> ii  vlc-l10n 2.2.5-1
> ii  vlc-plugin-base  2.2.5-1
> ii  vlc-plugin-qt2.2.5-1
> ii  vlc-plugin-video-output  2.2.5-1
> 
> Versions of packages vlc recommends:
> ii  vlc-plugin-notify  2.2.5-1
> ii  vlc-plugin-samba   2.2.5-1
> ii  vlc-plugin-skins2  2.2.5-1
> ii  vlc-plugin-video-splitter  2.2.5-1
> ii  vlc-plugin-visualization   2.2.5-1
> 
> vlc suggests no packages.
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.24-9
> ii  libvlc5  2.2.5-1
> 
> Versions of packages libvlc5 depends on:
> ii  dpkg 1.18.23
> ii  libc62.24-9
> ii  libvlccore8  2.2.5-1
> 
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  2.2.5-1
> 
> Versions of packages libvlccore8 depends on:
> ii  dpkg 1.18.23
> ii  libc62.24-9
> ii  libdbus-1-3  1.10.18-1
> ii  libidn11 1.33-1
> 
> Versions of packages libvlccore8 recommends:
> ii  libproxy-tools  0.4.14-2
> 
> Versions of packages vlc-bin depends on:
> ii  libc6   2.24-9
> ii  libvlc-bin  2.2.5-1
> ii  libvlc5 2.2.5-1
> 
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4   0.7.4-19
> ii  libasound2 1.1.3-5
> ii  libass51:0.13.4-2
> ii  libavahi-client3   0.6.32-2
> ii  libavahi-common3   0.6.32-2
> ii  libavc1394-0   0.5.4-4+b1
> ii  libbasicusageenvironment1  2016.11.28-1
> ii  libbluray1 1:0.9.3-3
> ii  libbz2-1.0 1.0.6-8.1
> ii  libc6  2.24-9
> ii  libcairo2  1.14.8-1
> ii  libcddb2   1.3.2-5
> ii  libcdio13  0.83-4.3+b1
> ii  libchromaprint11.4.2-1
> ii  libcrystalhd3  1:0.0~git20110715.fdd2f19-12
> ii  libdbus-1-31.10.18-1
> ii  libdc1394-22   2.2.5-1
> ii  libdca00.0.5-10
> ii  libdirectfb-1.2-9  1.2.10.0-8
> ii  libdvbpsi101.3.0-5
> ii  libdvdnav4 5.0.3-3
> ii  libdvdread45.0.3-2
> ii  libebml4v5 1.3.4-1
> ii  libfaad2   2.8.0~cvs20161113-1
> ii  libflac8   1.3.2-1
> ii  libfontconfig1 2.11.0-6.7+b1
> ii  libfreetype6   2.6.3-3.1
> ii  libfribidi00.19.7-1+b1
> ii  libgcc11:6.3.0-12
> ii  libgcrypt201.7.6-1
> ii  libglib2.0-0   2.50.3-2
> ii  libgme00.6.0-4
> ii  libgnutls303.5.8-5
> ii  libgpg-error0  1.26-2
> ii  libgroupsock8  2016.11.28-1
> ii  libgsm11.0.13-4+b2
> ii  libjpeg62-turbo1:1.5.1-2
> ii  libkate1   0.4.1-7+b1
> ii  liblirc-client00.9.4c-9
> ii  liblivemedia57 2016.11.28-1
> ii  liblua5.2-05.2.4-1.1+b2
> ii  liblzma5   5.2.2-1.2+b1
> ii  libmad00.15.1b-8
> ii  libmatroska6v5 1.4.5-2
> ii  libmp3lame03.99.5+repack1-9+b2
> ii  libmpcdec6 2:0.1~r495-1+b1
> ii  libmpeg2-4 0.5.1-7+b2
> ii  libmtp91.1.12-1+b1
> ii  libncursesw5   6.0+20161126-1
> ii  libogg01.3.2-1
> ii  libopenmpt-modplug10.2.7386~beta20.3-3
> ii  libopus0   1.2~alpha2-1
> ii  libpng16-161.6.28-1
> ii  libpulse0  10.0-1
> ii  libraw1394-11  2.1.2-1+b1
> ii  libresid-builder0c2a   2.1.1-15
> ii  librsvg2-2 2.40.16-1+b1
> ii  librtmp1   2.4+20151223.gitfa8646d.1-1+b1
> ii  libsamplerate0 0.1.8-8+b2
> ii  libsdl-image1.21.2.12-5+b8
> ii  libsdl1.2debian1.2.15+dfsg1-4
> ii  libshine3  3.1.0-5
> ii  libshout3  2.3.1-3
> ii  libsidplay22.1.1-15
> ii  libsnappy1v5   1.1

Bug#860834: u-boot-amlogic: u-boot.bin is not directly usable

[Vagrant Cascadian]

On 2017-04-20, Heinrich Schuchardt wrote:
> Unfortunately this package alone is insufficient to set up U-Boot on the
> Odroid C2.

Right, the install process should be documented in:

  /usr/share/doc/u-boot-amlogic/README


> The following tools are missing:
> - fip_create from
>   https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01

> - amlbootsig from
>   https://github.com/afaerber/meson-tools

Ah, wasn't aware of this one, thanks!


> Furthermore the firmware is needed. The source is possibly contained in
> http://openlinux.amlogic.com:8000/download/ARM/u-boot/uboot-2016-08-18-edd7f116ab.tar.gz

I don't see source code for the firmware in there. e.g. fip/gx* only
includes binaries.


> The finished binaries are available from
> https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01
>
> My idea is that we should create three packages:
> - fip_create (BSD)
> - meson-tools (GPLv2+)

Both of those look feasible, sure, though fip_create could perhaps just
be included with u-boot-tools.


> - odroidc2-firmware (BSD if built form source)

No source, no package...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#860104: nvidia-kernel-dkms: The last three kernel update breaks nvidia module

[Luca Boccassi]

Control: reassign -1 nvidia-driver
Control: forcemerge 856355 -1

On Tue, 11 Apr 2017 15:51:39 +0200 =?utf-8?q?Nicolas_M=C3=A9nec?=  wrote:
> Package: nvidia-kernel-dkms
> Version: 375.39-1
> Severity: normal
> Tags: newcomer
> 
> Dear Maintainer,
> 
> Hi!
> 
> I have a amd64 sid system, built on UEFI, but it looks like the
nVidia driver
> have some troubles with the last kernel releases.
> 
> In my case, the issue manifested as not being able to make working
Xorg after
> upgrading linux kernel and headers.
> The system boots normally : before X starts, I am able to see boot
messages,
> but when Xorg starts, I see a black blink screen in place of gdm3.
> 
> As first workaround (no time to investigate, i apolize), I just
downgraded
> kernel packages (image, headers and others) to 4.9.0-2-amd64_4.9.10-
1_amd64.
> My system was OK: Xorg starts with gdm3.
> Since few weeks, I noticed troubles with kernel versions 4.9.13-1,
4.9.16-1 and
> the current 4.9.18-1.
> 
> As a secund workaround (more time to investigate ;-)), I upgraded my
kernel
> (image, headers, etc..) to version 4.9.18-1
> Xorg was broken again. A look in the /var/log/kern.log, I had this
message :
> Apr 11 11:41:07 mycomputer kernel: [   77.692226] nvidia: disagrees
about
> version of symbol module_layout
> 
> So, I decided to rebuild the nVidia driver module via dkms by the
command line.
> Just doing the commands as follow:
> # dkms remove -m nvidia-current -v 375.39 --all
> # dkms add -m nvidia-current -v 375.39
> # dkms rebuid -m nvidia-current -v 375.39
> # dkms install -m nvidia-current -v 375.39
> 
> After a complete reboot, the system works fine : Xorg starts with
gdm3.
> 
> In conclusion, the last kernel releases have changed kernel symbols
betwenn
> versions 4.9.10-1 and 4.9.13-1 without rebuilding the nvidia module
on the fly
> by dkms as usually.
> I think my secund workaround has definitely resolved my issue.
> So, I hope this report will help someone who have same troubles with
kernel
> updates on nvidia driver.
> 
> Please let me know if I can provide any additional
information.  Thanks very
> much!
> 
> Regards,
> 
> Nicolas.

Hello,

This is the same as 856355. In short:

The kernel headers packages have the name versioned after the ABI
version. DKMS understanding is that as long as the package name (and
thus the ABI version) does not change, then there is no need to rebuild
as the ABI is (assumed to be) compatible. When the headers packages
change name, then DKMS automatically rebuilds.

If the ABI change is not compatible but the package name does not
change, DKMS has no way to figure out that it needs to rebuild.

From the changelog it looks like the kernel maintainers are aware of
ABI breakages:

  * [powerpc*] Ignore ABI changes in cxl (fixes FTBFS) (Closes:
#858530)
and IOMMU setup
  * Ignore ABI changes in bpf, dccp, libiscsi
  * [x86] Ignore ABI changes in kvm

http://metadata.ftp-master.debian.org/changelogs/main/l/linux/linux_4.9
.18-1_changelog

There is nothing we can do unfortunately, and what you did by
rebuilding via dkms is the right workaround. Sorry for the
inconvenience. Once Stretch is released it shouldn't happen again.

Kind regards,
Luca Boccassi

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

Bug#860742: liferea: 'Update Monitor' dialog does not expand properly

[Paul Gevers]

On Thu, 20 Apr 2017 07:49:23 +0800 Paul Wise  wrote:
> On Wed, 2017-04-19 at 20:39 +0200, Paul Gevers wrote:
> 
> > Thanks for reporting the issue. However, this issue was already reported
> > and fixed upstream, but RC3 was released too late to make it into Stretch.
> 
> Would it be possible to get it at least into experimental?

Trivial.

> I notice that RC3 fixes a data loss bug (usually release-critical in
> Debian), considering that and that the other changes look low risk,
> I bet you could convince the release team to allow RC3 into stretch.

Hmm, the debdiff is 1.5 MB big. Do you really think I should try to
convince the RT? Did you actually look at the changes, or just at the
changelog?

(I could strip the translations from the debdiff (nearly all line number
changes), but an other huge part of the delta was already included in
the 0001-Removing-GtkDoc-warnings.patch. So when I create a diff of the
patched source tree, and not including the stripped patch, I am still
left with ~50KB of diff or approximately "34 files changed, 374
insertions(+), 278 deletions(-)")

> https://github.com/lwindolf/liferea/issues/208

Do you think this is an RC bug? Than cherry-picking only that fix is
more trivial than the full rc3.

Paul

paul@testavoira ~/liferea $ ll -h /tmp/liferea_1.12~rc3-1.debdiff
-rw-r--r-- 1 paul paul 1.5M apr 20 21:30 /tmp/liferea_1.12~rc3-1.debdiff

> 102 files changed, 11055 insertions(+), 14088 deletions(-)



signature.asc
Description: OpenPGP digital signature

Bug#860180: [d-i manual CSS stylesheet] icon file missing for tag

[Holger Wansing]

Control: tags -1 + pending


Holger Wansing  wrote:
> Hi,
> 
> Baptiste Jammet  wrote:
> > Hi, 
> > 
> > Dixit Holger Wansing, le 13/04/2017 :
> > 
> > >Control: tags -1 + patch
> > [...]
> > >For the first proposal:
> > >We could use the attached icon for  (a white i in a blue circle,
> > >from Tango icon project, as the others).
> > >Also attached is the needed changing in install.css and a screenshot,
> > >how it would look like.
> > >
> > >
> > >What do you think?
> > 
> > It looks good to me. Please go ahead.
> > 
> > Baptiste
> 
> Ok, will do soon, if noone objects.

Committed, set bug on pending.


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

[Ben Finney]

On 20-Apr-2017, Brian Potkin wrote:
> Ben - a request. Bug reports below a certain size come through to
> debian-printing and I get them by SMTP. It is better to compress
> log files, otherwise I have to go looking for the CC.

I'll try to remember that.

And while we're at it: Thank you for putting in the careful effort to
troubleshoot this problem with me!

> More testing, I'm afraid.

Bring it on :-)

> Take the file in your $HOME produced by testq. The file utility should
> identify it as "HP Printer Job Language data".

$ sudo file ~/testq-out
/home/bignose/testq-out: HP Printer Job Language data

> Send it directly to the printer with
> 
>   cat  > /dev/usb/lp0

There is no such device node:

$ find /dev -name 'lp0'

$ ls /dev/usb/lp0
ls: cannot access '/dev/usb/lp0': No such file or directory

> Also send the same file with
> 
>   lp -d  -o raw 

=
$ sudo systemctl restart cups

$ lpstat -a 'SCX-4623-Series'
SCX-4623-Series accepting requests since Fri 21 Apr 2017 06:00:09 AEST

$ lp -d 'SCX-4623-Series' -o raw ~/testq-out
request id is SCX-4623-Series-73 (1 file(s))

$ lpstat -a 'SCX-4623-Series'
SCX-4623-Series accepting requests since Fri 21 Apr 2017 06:00:09 AEST

$ lpstat -o 'SCX-4623-Series'
SCX-4623-Series-68  bignose   1024   Thu 20 Apr 2017 20:39:29 AEST
SCX-4623-Series-71  bignose   1024   Thu 20 Apr 2017 20:51:12 AEST
SCX-4623-Series-72  bignose  95232   Fri 21 Apr 2017 05:56:42 AEST
SCX-4623-Series-73  bignose  95232   Fri 21 Apr 2017 06:00:24 AEST

$ sudo systemctl stop cups
=

> Does it print?

No. The resulting error log (compressed) is attached.

-- 
 \   “Anger makes dull men witty, but it keeps them poor.” |
  `\  —Elizabeth Tudor |
_o__)  |
Ben Finney 


error_log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#860839: vlc fails to start due to missing QT platform plugin xcb

[Harlan Lieberman-Berg]

Package: src:vlc
Version: 2.2.5-1
Severity: grave
Justification: renders package unusable

Hello maintainer,

For vlc installed on stretch freshly after a `apt install vlc`, it refuses to 
open while complaining 
about a failure to find the xcb Qt module.

Attached `vlc -vvv`.

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

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

Versions of packages vlc depends on:
ii  dpkg 1.18.23
ii  vlc-bin  2.2.5-1
ii  vlc-l10n 2.2.5-1
ii  vlc-plugin-base  2.2.5-1
ii  vlc-plugin-qt2.2.5-1
ii  vlc-plugin-video-output  2.2.5-1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.2.5-1
ii  vlc-plugin-samba   2.2.5-1
ii  vlc-plugin-skins2  2.2.5-1
ii  vlc-plugin-video-splitter  2.2.5-1
ii  vlc-plugin-visualization   2.2.5-1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.24-9
ii  libvlc5  2.2.5-1

Versions of packages libvlc5 depends on:
ii  dpkg 1.18.23
ii  libc62.24-9
ii  libvlccore8  2.2.5-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  2.2.5-1

Versions of packages libvlccore8 depends on:
ii  dpkg 1.18.23
ii  libc62.24-9
ii  libdbus-1-3  1.10.18-1
ii  libidn11 1.33-1

Versions of packages libvlccore8 recommends:
ii  libproxy-tools  0.4.14-2

Versions of packages vlc-bin depends on:
ii  libc6   2.24-9
ii  libvlc-bin  2.2.5-1
ii  libvlc5 2.2.5-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4   0.7.4-19
ii  libasound2 1.1.3-5
ii  libass51:0.13.4-2
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libavc1394-0   0.5.4-4+b1
ii  libbasicusageenvironment1  2016.11.28-1
ii  libbluray1 1:0.9.3-3
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-9
ii  libcairo2  1.14.8-1
ii  libcddb2   1.3.2-5
ii  libcdio13  0.83-4.3+b1
ii  libchromaprint11.4.2-1
ii  libcrystalhd3  1:0.0~git20110715.fdd2f19-12
ii  libdbus-1-31.10.18-1
ii  libdc1394-22   2.2.5-1
ii  libdca00.0.5-10
ii  libdirectfb-1.2-9  1.2.10.0-8
ii  libdvbpsi101.3.0-5
ii  libdvdnav4 5.0.3-3
ii  libdvdread45.0.3-2
ii  libebml4v5 1.3.4-1
ii  libfaad2   2.8.0~cvs20161113-1
ii  libflac8   1.3.2-1
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.1
ii  libfribidi00.19.7-1+b1
ii  libgcc11:6.3.0-12
ii  libgcrypt201.7.6-1
ii  libglib2.0-0   2.50.3-2
ii  libgme00.6.0-4
ii  libgnutls303.5.8-5
ii  libgpg-error0  1.26-2
ii  libgroupsock8  2016.11.28-1
ii  libgsm11.0.13-4+b2
ii  libjpeg62-turbo1:1.5.1-2
ii  libkate1   0.4.1-7+b1
ii  liblirc-client00.9.4c-9
ii  liblivemedia57 2016.11.28-1
ii  liblua5.2-05.2.4-1.1+b2
ii  liblzma5   5.2.2-1.2+b1
ii  libmad00.15.1b-8
ii  libmatroska6v5 1.4.5-2
ii  libmp3lame03.99.5+repack1-9+b2
ii  libmpcdec6 2:0.1~r495-1+b1
ii  libmpeg2-4 0.5.1-7+b2
ii  libmtp91.1.12-1+b1
ii  libncursesw5   6.0+20161126-1
ii  libogg01.3.2-1
ii  libopenmpt-modplug10.2.7386~beta20.3-3
ii  libopus0   1.2~alpha2-1
ii  libpng16-161.6.28-1
ii  libpulse0  10.0-1
ii  libraw1394-11  2.1.2-1+b1
ii  libresid-builder0c2a   2.1.1-15
ii  librsvg2-2 2.40.16-1+b1
ii  librtmp1   2.4+20151223.gitfa8646d.1-1+b1
ii  libsamplerate0 0.1.8-8+b2
ii  libsdl-image1.21.2.12-5+b8
ii  libsdl1.2debian1.2.15+dfsg1-4
ii  libshine3  3.1.0-5
ii  libshout3  2.3.1-3
ii  libsidplay22.1.1-15
ii  libsnappy1v5   1.1.3-3
ii  libsndio6.11.1.0-3
ii  libspeex1  1.2~rc1.2-1+b2
ii  libspeexdsp1   1.2~rc1.2-1+b2
ii  libssh-gcrypt-40.7.3-2
ii  libssh2-1  1.7.0-1
ii  libstdc++6 6.3.0-12
ii  libtag1v5  1.11.1+dfsg.1-0.1
ii  libtheora0 1.1.1+dfsg.1-14+b1
ii  libtinfo5  6.0+20161126-1
ii  libtwolame00.3.13-2
ii  libudev1   232-22
ii  libupnp6   

Bug#860365: mutter: Graphical glitches on Intel GMA X4500 with SNA and Wayland

[Kevin Keijzer]

Apparently, this is not solved due to switching to UXA, but because UXA
also reverts to DRI2.

SNA does work without issues, as long as it's combined with DRI2 and the
xserver-xorg-video-intel driver.

So this configuration works as well, and is probably preferable:

/etc/X11/xorg.conf.d/20-intel.conf:

Section "Device"
   Identifier  "Intel Graphics"
   Driver  "intel"
   Option  "DRI" "2"
EndSection


However, removing the xserver-xorg-video-intel package and using the X
modesetting driver will trigger this bug again, even when you force DRI2
with LIBGL_DISABLE_DRI3=1. The same goes for Wayland.

-- 
With kind regards,

Kevin Keijzer
GNU/Linux systems administrator, LibrePractice
https://www.librepractice.org/

Bug#860837: dash: single quote does not protect \f from being converted to form feed

[Norman Ramsey]

Package: dash
Version: 0.5.7-4+b1
Severity: important

Dear Maintainer,

As it says on the man page and in the POSIX standard, the single quote
is supposed to prevent escape sequences from being expanded.  It's broken:

  nr@homedog ©105/c/lambda-solo> /bin/dash
  : nr@homedog ! ; echo '\f.\x.x'

  .\x.x

For comparison, here's how /bin/ksh handles the single quote:

  : nr@homedog ! ; 
  nr@homedog ©105/c/lambda-solo> /bin/ksh
  : nr@homedog 10010 ; echo '\f.\x.x'
  \f.\x.x
  : nr@homedog 10011 ; 

This one is a showstopper for me; I have infrastructure that depends
on /bin/sh handling this correctly.

Perhaps related to bug 837789.



-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (990, 'stable'), (1, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

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

Versions of packages dash depends on:
ii  debianutils  4.4+b1
ii  dpkg 1.17.27
ii  libc62.19-18+deb8u6

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#860836: appstream-glib: run dh --with gir for ${gir:Depends}

[Dan Nicholson]

Source: appstream-glib
Version: 0.6.8-1
Severity: normal
Tags: patch

Currently the gir1.2-appstreamglib-1.0 package has no dependencies.
This is because the ${gir:Depends} value used in the control file
never gets set since dh_girepository never runs. Pass --with gir to dh
to make that happen.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
diff -Nru appstream-glib-0.6.8/debian/changelog appstream-glib-0.6.8/debian/changelog
--- appstream-glib-0.6.8/debian/changelog	2017-02-05 09:09:19.0 -0600
+++ appstream-glib-0.6.8/debian/changelog	2017-04-20 14:26:29.0 -0500
@@ -1,3 +1,9 @@
+appstream-glib (0.6.8-2) UNRELEASED; urgency=medium
+
+  * debian/rules: Pass --with gir to calculate ${gir:Depends}.
+
+ -- Dan Nicholson   Thu, 20 Apr 2017 14:00:22 -0500
+
 appstream-glib (0.6.8-1) unstable; urgency=medium
 
   * New upstream version 0.6.8
diff -Nru appstream-glib-0.6.8/debian/rules appstream-glib-0.6.8/debian/rules
--- appstream-glib-0.6.8/debian/rules	2017-01-19 13:44:28.0 -0600
+++ appstream-glib-0.6.8/debian/rules	2017-04-20 14:25:32.0 -0500
@@ -13,7 +13,7 @@
 INSTALLDIR = $(CURDIR)/debian/tmp
 
 %:
-	dh $@ --with autoreconf
+	dh $@ --with autoreconf,gir
 
 override_dh_auto_configure:
 	dh_auto_configure -- $(AS_CONFIGURE_ARGS)

Bug#860835: flightgear: New upstream release

[Mateusz Kaduk]

Package: flightgear-data-models
Version: 1:2016.4.2+dfsg-1
Severity: wishlist
File: flightgear

Dear Maintainer,

Latest upstream is FlightGear 2017.1.3.
It would be great if Debian packages were updated.

Regards,
Mateusz

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

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

-- no debconf information

Bug#860792: fonts-lato: Hash Sum Mismatch on the packages

[Rafael Moreira]

I replied to Paul Wise on this message 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860792#24 that I 
followed his lead to try on another connection, and it worked. So it's 
on my end. Sorry for the trouble.


>I also see that fonts-lato not listed as dependency for vim-gtk. A 
fresh install of vim-gtk did not pull in fonts-lato.


Odd, this is a fresh install of Stretch that I did on a VM this morning 
to test on a different connection. This is the output for the `apt-get 
update` `apt-get install vim-gtk` and as you can see fonts-lato was 
pulled from a vim-gtk install.


root@mercury:/home/rmc# apt-get update
Hit:1 http://security.debian.org/debian-security stretch/updates InRelease
Hit:2 http://ftp.br.debian.org/debian stretch InRelease
Reading package lists... Done

root@mercury:/home/rmc# apt-get install vim-gtk
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  fonts-lato javascript-common libjs-jquery libruby2.3 rake ruby
  ruby-did-you-mean ruby-minitest ruby-net-telnet ruby-power-assert
  ruby-test-unit ruby2.3 rubygems-integration vim-gui-common 
vim-runtime zip

Suggested packages:
  apache2 | lighttpd | httpd ri ruby-dev bundler cscope vim-doc
The following NEW packages will be installed:
  fonts-lato javascript-common libjs-jquery libruby2.3 rake ruby
  ruby-did-you-mean ruby-minitest ruby-net-telnet ruby-power-assert
  ruby-test-unit ruby2.3 rubygems-integration vim-gtk vim-gui-common
  vim-runtime zip
0 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
Need to get 13.4 MB of archives.
After this operation, 59.9 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.br.debian.org/debian stretch/main amd64 fonts-lato all 
2.0-1 [2,684 kB]
Err:1 http://ftp.br.debian.org/debian stretch/main amd64 fonts-lato all 
2.0-1

  Hash Sum mismatch
  Hashes of expected file:
   - 
SHA256:50f3744423194f5f148f7d9e23fb4b4925664b7f2d1c6786ea17d1541cd626a5

   - MD5Sum:6affeda00b14169431579b76b8b16b25 [weak]
   - Filesize:2683912 [weak]
  Hashes of received file:
   - 
SHA256:b1e20241ee62f5efe8039290fc4420293bc1f99704953051321c075305bd037d

   - MD5Sum:7339c165848d6f3618fd815e60122238 [weak]
   - Filesize:2683912 [weak]
  Last modification reported: Mon, 21 Jul 2014 13:44:21 +
Get:2 http://ftp.br.debian.org/debian stretch/main amd64 
javascript-common all 11 [6,120 B]
Get:3 http://ftp.br.debian.org/debian stretch/main amd64 libjs-jquery 
all 3.1.1-2 [154 kB]
Get:4 http://ftp.br.debian.org/debian stretch/main amd64 
rubygems-integration all 1.11 [4,994 B]
Get:5 http://ftp.br.debian.org/debian stretch/main amd64 
ruby-did-you-mean all 1.0.0-2 [11.2 kB]
Get:6 http://ftp.br.debian.org/debian stretch/main amd64 ruby-minitest 
all 5.9.0-1 [51.1 kB]
Get:7 http://ftp.br.debian.org/debian stretch/main amd64 ruby-net-telnet 
all 0.1.1-2 [12.5 kB]
Get:8 http://ftp.br.debian.org/debian stretch/main amd64 
ruby-power-assert all 0.3.0-1 [7,902 B]
Get:9 http://ftp.br.debian.org/debian stretch/main amd64 ruby-test-unit 
all 3.1.7-2 [69.6 kB]
Get:10 http://ftp.br.debian.org/debian stretch/main amd64 libruby2.3 
amd64 2.3.3-1 [3,104 kB]
Get:11 http://ftp.br.debian.org/debian stretch/main amd64 ruby2.3 amd64 
2.3.3-1 [186 kB]
Get:12 http://ftp.br.debian.org/debian stretch/main amd64 ruby amd64 
1:2.3.3 [10.8 kB]
Get:13 http://ftp.br.debian.org/debian stretch/main amd64 rake all 
10.5.0-2 [49.4 kB]
Get:14 http://ftp.br.debian.org/debian stretch/main amd64 vim-gui-common 
all 2:8.0.0197-3 [159 kB]
Get:15 http://ftp.br.debian.org/debian stretch/main amd64 vim-runtime 
all 2:8.0.0197-3 [5,409 kB]
Get:16 http://ftp.br.debian.org/debian stretch/main amd64 zip amd64 
3.0-11+b1 [234 kB]
Get:17 http://ftp.br.debian.org/debian stretch/main amd64 vim-gtk amd64 
2:8.0.0197-3 [1,263 kB]

Fetched 13.4 MB in 9s (1,363 kB/s)
E: Failed to fetch 
http://ftp.br.debian.org/debian/pool/main/f/fonts-lato/fonts-lato_2.0-1_all.deb 
Hash Sum mismatch

   Hashes of expected file:
- 
SHA256:50f3744423194f5f148f7d9e23fb4b4925664b7f2d1c6786ea17d1541cd626a5

- MD5Sum:6affeda00b14169431579b76b8b16b25 [weak]
- Filesize:2683912 [weak]
   Hashes of received file:
- 
SHA256:b1e20241ee62f5efe8039290fc4420293bc1f99704953051321c075305bd037d

- MD5Sum:7339c165848d6f3618fd815e60122238 [weak]
- Filesize:2683912 [weak]
   Last modification reported: Mon, 21 Jul 2014 13:44:21 +
E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?



On 20-Apr-17 06:15, Vasudev Kamath wrote:

Control: severity -1 normal
Control: tag -1 +unreproducible +moreinfo

Hi Rafael,

I'm unable to reproduce the issue on my testing system. I also see
that fonts-lato not listed as dependency for vim-gtk. A fresh install
of vim-gtk did not pull in fonts-lato. I tried freshly install
fonts-lato and it installed without any issue.

This probably is some issue local to your system. Did you run a

Bug#860834: u-boot-amlogic: u-boot.bin is not directly usable

[Heinrich Schuchardt]

Package: u-boot-amlogic
Version: 2017.05~rc2+dfsg1-1
Severity: wishlist

Dear Vagrant,

thank you for creating this package.

Unfortunately this package alone is insufficient to set up U-Boot on the
Odroid C2.

The following tools are missing:
- fip_create from
  https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01
- amlbootsig from
  https://github.com/afaerber/meson-tools

Furthermore the firmware is needed. The source is possibly contained in
http://openlinux.amlogic.com:8000/download/ARM/u-boot/uboot-2016-08-18-edd7f116ab.tar.gz

The finished binaries are available from
https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01

My idea is that we should create three packages:
- fip_create (BSD)
- meson-tools (GPLv2+)
- odroidc2-firmware (BSD if built form source)

What are your thoughts about this?

Best regards

Heinrich Schuchardt

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.10.0-rc5-next-20170125-r000-arm64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#860792: [Pkg-fonts-devel] Bug#860792: fonts-lato: Hash Sum Mismatch on the packages

[Rafael Moreira]

>Do you have the same issue with other packages? Other fonts packages?
Just this package, I installed other font packages just to test, without 
any issue.



Could you try downloading over a VPN or a different Internet
connection, perhaps at a library or your workplace?


This is a desktop, so I did not had the chance to test on another 
connection. I just made a fresh install on a VM in my laptop, and with 
the same Internet Connection the problem persisted.
When I arrived to my office I tried again, this time with a different 
connection, and the package was installed without any issue on the VM.


I have no idea what is the cause of the problem, but I think it's on my 
end, and outside of the scope of this bug report. Thanks you very much 
for your help.


On 20-Apr-17 06:06, Paul Wise wrote:

Control: tags -1 unreproducible moreinfo

On Thu, Apr 20, 2017 at 3:00 PM, Rafael Moreira Cunha wrote:


I tried to install with apt-get and aptitude with the same results, and tried 
to change the sources.list to another mirror and all the same.

I am able to download the package without any issues, from both my
current mirror and from ftp.br.debian.org. I get the same SHA256 that
your apt is expecting.

Are you still experiencing the issue?

Do you have the same issue with other packages? Other fonts packages?

Could you try downloading over a VPN or a different Internet
connection, perhaps at a library or your workplace?

Bug#860832: Seems to work again

[Norbert Kiesel]

Not sure what happened but another round of `sudo aptitude update;
sudo aptitude full-upgrade` fixed the problem

Bug#860829: hledger: "unable to decommit memory" error

[Christian G. Warden]

It looks like this is related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847677

Bug#860832: firefox no longer starts

[nkiesel]

Package: firefox
Version: 53.0~b8-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrade firefox no longer starts and says

XPCOMGlueLoad error for file /usr/lib/firefox/libxul.so:
libhunspell-1.6.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

I have libhunspell-1.4-0:amd64 1.4.1-2+b2 installed



-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-10
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.18-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.1
ii  libgcc1   1:6.3.0-14
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.12-1
ii  libgtk2.0-0   2.24.31-2
pn  libhunspell-1.6-0 
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.5-1
ii  libsqlite3-0  3.16.2-3
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-14
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3
ii  zlib1g1:1.2.8.dfsg-5

firefox recommends no packages.

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-3
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15-1
pn  mozplugger 

-- no debconf information

Bug#860831: debian-archive-keyring: release key for stretch?

[Adam D. Barratt]

Source: debian-archive-keyring
Version: 2014.3
Control: found -1 2014.3~deb7u1
X-Debbugs-Cc: debian-rele...@lists.debian.org

Hi,

There was some debate a little while ago as to the merits of the release
signing keys, but if we're going to have one for stretch then we should
get it generated and include in d-a-k uploads in the near future.

Regards,

Adam

Bug#860829: more details

[Simon Michael]

Needs rebuilding against newer GHC I think, more details at 
https://github.com/simonmichael/hledger/issues/541 
.

Bug#860830: debian-archive-keyring: ftp-master key for stretch

[Adam D. Barratt]

Source: debian-archive-keyring
Version: 2014.3
Control: found -1 2014.3~deb7u1
X-Debbugs-Cc: ftpmas...@debian.org, debian-rele...@lists.debian.org

Hi,

Assuming I didn't miss an announcement already, we need new archive
signing keys for stretch, so we can include them in a
debian-archive-keyring upload before the release.

Regards,

Adam

Bug#795296: "You are not allowed to save the configuration" (both root and ordinary user)

[Willi Mann]

Hi Maxy,

Am 2017-04-06 um 19:24 schrieb Maximiliano Curia:

> El 2017-03-31 a las 21:25 +0200, Willi Mann escribió:
>> Am 2017-03-31 um 18:25 schrieb Maximiliano Curia:
> 
>>> Do you have another session started as root? Do you have another X
>>> session started with your user?
> 
>> There is no other session running as root, except for an SSH session.
>> And I have no keyboard or mouse attached to this machine, I'm using
>> synergy instead.
> 
> I've seen synergy do some weird things, but somehow I don't think we can
> blame synergy here.

Just to make sure, I tried it with a keyboard connected and synergy not
started. Does not change anything.

Bye
Willi

Bug#860829: hledger: "unable to decommit memory" error

[Christian G. Warden]

Package: hledger
Version: 1.0.1-1+b1
Severity: important

I'm getting an error, unable to decommit memory: Invalid argument, working with
the attached journal.

/tmp $ hledger -f /tmp/anon.journal print -p today
hledger: unable to decommit memory: Invalid argument
/tmp $ hledger -f anon.journal print -p today
/tmp $ hledger -f anon.journal reg -p today
hledger: unable to decommit memory: Invalid argument
/tmp $ hledger -f /tmp/anon.journal reg -p today
hledger: unable to decommit memory: Invalid argument
/tmp $ hledger -f anon.journal print
...
2017/03/07 faba7f2f
325566ed:cfc24db6:3c0d04e0$47.23
fac2dc17:f6f84467:b95464f5   $-47.23

hledger: unable to decommit memory: Invalid argument



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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages hledger depends on:
ii  libc6 2.24-8 GNU C Library: Shared libraries
ii  libffi6   3.2.1-4Foreign Function Interface library
ii  libgmp10  2:6.1.0+dfsg-2 Multiprecision arithmetic library
ii  libtinfo5 6.0+20151024-2 shared low-level terminfo library 

hledger recommends no packages.

hledger suggests no packages.

-- no debconf information
2016/01/03 49b79d32
ced6cffd:658143a9:6385cab5 $5.00
83b6895:35e6f3ce:6385cab5 $-5.00

2016/02/28 83a1c06e
ced6cffd:658143a9:6385cab5 $1.71
83b6895:35e6f3ce:6385cab5 $-1.71

2016/03/31 83a1c06e
ced6cffd:658143a9:6385cab5 $0.64
83b6895:35e6f3ce:6385cab5 $-0.64

2016/12/01 2d024300
325566ed:e1156532:a8e7691e$26.98
fac2dc17:f6f84467:4fea781a   $-26.98

2016/12/02 ef34249a
fac2dc17:f6f84467:4fea781a$-1,766.20
145180bb:22237e7f  $1,766.20

2016/12/02 8984bdac
325566ed:e1156532:a8e7691e$24.05
fac2dc17:f6f84467:4fea781a   $-24.05

2016/12/03 9f31d1c5
325566ed:e1156532:a8e7691e$11.25
fac2dc17:f6f84467:4fea781a   $-11.25

2016/12/03 e9cfa726
325566ed:e1156532:a8e7691e$15.47
fac2dc17:f6f84467:4fea781a   $-15.47

2016/12/03 5c2a4b14
325566ed:e1156532:a8e7691e$11.25
fac2dc17:f6f84467:4fea781a   $-11.25

2016/12/04 ebe6211e
325566ed:e85b084c:886abd93$34.26
fac2dc17:f6f84467:4fea781a   $-34.26

2016/12/04 93e4b9f2
325566ed:e1156532:ca487fc7   $167.65
fac2dc17:f6f84467:4fea781a  $-167.65

2016/12/04 fba69a77
325566ed:da6cd300 $41.60
fac2dc17:f6f84467:4fea781a   $-41.60

2016/12/06 c50967f1
325566ed:e1156532:a8e7691e$13.95
fac2dc17:f6f84467:4fea781a   $-13.95

2016/12/06 831db7b2
325566ed:e1156532:a8e7691e   $117.60
fac2dc17:f6f84467:4fea781a  $-117.60

2016/12/07 9041fbd2
fac2dc17:f6f84467:fa48e54$-3,592.94
145180bb:22237e7f $3,592.94

2016/12/07 93e4b9f2
325566ed:e1156532:ca487fc7   $-11.99
fac2dc17:f6f84467:4fea781a$11.99

2016/12/07 93e4b9f2
325566ed:e1156532:ca487fc7$94.31
fac2dc17:f6f84467:4fea781a   $-94.31

2016/12/08 da9f3724
325566ed:e85b084c   $323.46
fac2dc17:f6f84467:fa48e54  $-323.46

2016/12/09 e0bb21f7
325566ed:738bfd21$14.95
fac2dc17:f6f84467:fa48e54   $-14.95

2016/12/10 5c2a4b14
325566ed:e1156532:a8e7691e$11.25
fac2dc17:f6f84467:4fea781a   $-11.25

2016/12/10 5eed044
325566ed:e1156532:a8e7691e$39.00
fac2dc17:f6f84467:4fea781a   $-39.00

2016/12/10 fc957e9
325566ed:8e3bf0ad $10.18
fac2dc17:f6f84467:4fea781a   $-10.18

2016/12/11 6eae3fc3
325566ed:e1156532:ca487fc7$15.75
fac2dc17:f6f84467:4fea781a   $-15.75

2016/12/11 e3b8aae2
325566ed:da6cd300$134.50
fac2dc17:f6f84467:4fea781a  $-134.50

2016/12/12 444bc4d3
325566ed:72561ba4   $160.20
fac2dc17:f6f84467:fa48e54  $-160.20

2016/12/12 6d391e0
325566ed:a79b38a1:b944d516   $266.44
fac2dc17:f6f84467:fa48e54   $-266.44

2016/12/12 7fadf6b3
325566ed:a79b38a1:b944d516   $349.65
fac2dc17:f6f84467:fa48e54   $-349.65

2016/12/12 e3213d0e
325566ed:e1156532:a8e7691e$26.40
fac2dc17:f6f84467:fa48e54$-26.40

2016/12/12 b849385f
325566ed:e1156532:a8e7691e$31.79
fac2dc17:f6f84467:fa48e54$-31.79

2016/12/12 ae0babb5
325566ed:e85b084c$316.53
fac2dc17:f6f84467:4fea781a  $-316.53

2016/12/12 f00a473d
325566ed:e85b084c   $-316.53
fac2dc17:f6f84467:4fea781a   $316.53

2016/12/12 8249dd28
325566ed:e1156532:a8e7691e$52.00
fac2dc17:f6f84

Bug#860600: release.debian.org: Please unblock openlp

[Niels Thykier]

Control: tags -1 confirmed moreinfo

Raoul Snyman:
> Package: release.debian.org
> Severity: important
> 
> Hello Release Team,
> 
> I would like to file an unblock request for the openlp package. The
> openlp package currently is queued for removal from stretch due to
> a dependency being removed from stretch. Please see bug #734101. In
> order to do this, I removed the dependencies on libjs-jquery,
> libjs-jquery-mobile and libjs-jquery-migrate-1 since the upstream
> project already bundles these. I consulated Stefano Rivera with these
> changes.
> 
> Additionally, I have added a dependency which fixes bug #860061.
> 
> Please note that I have not yet uploaded this to unstable, as I
> am waiting for your approval to go ahead with this.
> 
> Attached is the diff.
> 
> Thank you.
> 
> [...]

Ack, please go ahead - minor nit: Please drop the changelog entry for
experimental as it appears to have been almost completely reverted (just
move that one relevant line into the 2.4.4-2 entry).

Please remove the moreinfo tag once the upload has been uploaded to
unstable and built on all relevant release architectures.

Thanks,
~Niels

Bug#844178: fixed in exim4 4.89~RC3-1

[Andreas Metzler]

Control: found -1 4.89-2

On 2017-02-10 Andreas Metzler  wrote:
> Source: exim4
> Source-Version: 4.89~RC3-1

> We believe that the bug you reported is fixed in the latest version of
[...]
> exim4, which is due to be installed in the Debian FTP archive.
>  + Add header "# pidfile: /var/run/exim4/exim.pid" for improved systemd
>interaction. systemd-sysv-generator uses this pseudoheader to set
>PIDFile in the generated service file and it also sets
>RemainAfterExit=no instead of yes if it is present. Thanks, Michael
>Biebl for suggestion and explanation. Closes: #844178


I needed to undo this, since it broke some supported setups:
 exim4 (4.89-2) unstable; urgency=medium

   * Revert addition of header "# pidfile: /var/run/exim4/exim.pid" to
 initscript (#844178). It breaks when the initscript does not start
 a daemon but only runs update-exim4.conf. (inetd or
 QUEUERUNNER='nodaemon').

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#857013: Fixing #857013

[Nis Martensen]

This might work, too? :

- conffiles = conffiles + [re.findall(r' (.+) ([0-9a-f]+).*$', line)[0]]
+ conffiles += re.findall(r' (.+) ([0-9a-f]+).*$', line)

Bug#860395: cppcheck: Missing reference to gui package.

[Joachim Reichel]

tag 860395 + pending
thanks

Bug#860828: gstreamer0.10-plugins-good should not depend on libtag1c2a

[Francois Gouget]

Package: gstreamer0.10-plugins-good
Version: 0.10.31-3+nmu4
Severity: normal

Dear Maintainer,

My understanding is that libtag1c2a has been replaced by libtag1v5:
lib1tagv5 conflicts and replaces libtag1c2a.

But gstreamer0.10-plugins-good still depends on libtag1c2a which leads
to installation conflicts with the packages that now depend on
libtag1v5.


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

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

Bug#860827: gnome-disk-image-mounter: Provide GUI option to mount image files read-write

[Matthew Gabeler-Lee]

Package: gnome-disk-utility
Version: 3.22.1-1
Severity: wishlist

gnome-disk-image-mounter provides a command line option to mount image files
read-write, but there's no way to do this in the GUI.

This would be particularly handy for e.g.  a disk image file containing an
encrypted (e.g.  LUKS) filesystem.

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

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

Versions of packages gnome-disk-utility depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libdvdread4  5.0.3-2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  liblzma5 5.2.2-1.2+b1
ii  libnotify4   0.7.7-1+b1
ii  libpango-1.0-0   1.40.4-1
ii  libpangocairo-1.0-0  1.40.4-1
ii  libpwquality11.3.0-1+b1
ii  libsecret-1-00.18.5-3.1
ii  libsystemd0  232-22
ii  libudisks2-0 2.1.8-1
ii  libx11-6 2:1.6.4-3
ii  udisks2  2.1.8-1

gnome-disk-utility recommends no packages.

gnome-disk-utility suggests no packages.

-- no debconf information

Bug#860826: Cannot build seabios from git repository

[jean-christophe manciot]

Package: seabios
Version: 1.10.2-1
Sources: https://anonscm.debian.org/git/pkg-qemu/seabios.git/
Branch: debian-unstable
Tag: debian/1.10.2-1

Building with:
echo 
echo Cleaning
echo 
cd git-seabios
sudo -u actionmystique -H git-reset-clean-pull-checkout.sh $branch
$tag

echo ---
echo Checking Build Dependencies
echo ---
dpkg-check-build-dependencies.sh

echo 
echo Building
echo 
sudo -u actionmystique -H dpkg-buildpackage --build=binary
-m"Jean-Christophe Manciot "

leads to:
...
dh_clean
 debian/rules build
[ ! -d .git ] || { echo "Directory .git exists, aborting" >&2; exit 1; }
*Directory .git exists, aborting*
debian/rules:55: recipe for target 'build/env-stamp' failed
make: *** [build/env-stamp] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2

What is the point of having a git repository if we cannot build from it?

-- 
Jean-Christophe

Bug#860395: cppcheck: Missing reference to gui package.

[Joachim Reichel]

tag 860935 + pending
thanks

Bug#860825: fglrx-driver does not work with backportkernel 4.9

[Marco Hutzfeld]

Package: fglrx-driver
Version: 1:15.12-2~bpo8+3

Package: linux-image-4.9.0-0.bpo.2-amd64
Version: 4.9.18-1~bpo8+1


During creation of an new kernelmodule via DKMS I get an error and the
module will not created.

linux-image-4.9.0-0.bpo.2-amd64 (4.9.18-1~bpo8+1) wird eingerichtet ...
/etc/kernel/postinst.d/dkms:
Error! Bad return status for module build on kernel: 4.9.0-0.bpo.2-amd64
(x86_64)
Consult /var/lib/dkms/fglrx/15.12/build/make.log for more information.


Here is the log.file:

DKMS make.log for fglrx-15.12 for kernel 4.9.0-0.bpo.2-amd64 (x86_64)
Mo 17. Apr 16:21:34 CEST 2017
make: Entering directory '/usr/src/linux-headers-4.9.0-0.bpo.2-amd64'
  LD  /var/lib/dkms/fglrx/15.12/build/built-in.o
  CC [M]  /var/lib/dkms/fglrx/15.12/build/firegl_public.o
In file included from /var/lib/dkms/fglrx/15.12/build/firegl_public.c:207:0:
/var/lib/dkms/fglrx/15.12/build/firegl_public.h:654:21: warning: extra
tokens at end of #ifndef directive
 #ifndef boot_cpu_has(X86_FEATURE_PGE)
 ^
/var/lib/dkms/fglrx/15.12/build/firegl_public.c: In function
‘KCL_LockUserPages’:
/var/lib/dkms/fglrx/15.12/build/firegl_public.c:3232:78: warning:
passing argument 7 of ‘get_user_pages_remote’ from incompatible pointer type
 ret = get_user_pages_remote(current, current->mm, vaddr, page_cnt,
1, 0, (struct page **)page_list, NULL);
 
^
In file included from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/scatterlist.h:7:0,
 from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/dmapool.h:14,
 from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/pci.h:1269,
 from /var/lib/dkms/fglrx/15.12/build/firegl_public.c:117:
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/mm.h:1298:6:
note: expected ‘struct vm_area_struct **’ but argument is of type
‘struct page **’
 long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
  ^
/var/lib/dkms/fglrx/15.12/build/firegl_public.c:3232:11: error: too many
arguments to function ‘get_user_pages_remote’
 ret = get_user_pages_remote(current, current->mm, vaddr, page_cnt,
1, 0, (struct page **)page_list, NULL);
   ^
In file included from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/scatterlist.h:7:0,
 from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/dmapool.h:14,
 from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/pci.h:1269,
 from /var/lib/dkms/fglrx/15.12/build/firegl_public.c:117:
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/mm.h:1298:6:
note: declared here
 long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
  ^
/var/lib/dkms/fglrx/15.12/build/firegl_public.c: In function
‘KCL_LockReadOnlyUserPages’:
/var/lib/dkms/fglrx/15.12/build/firegl_public.c:3254:78: warning:
passing argument 7 of ‘get_user_pages_remote’ from incompatible pointer type
 ret = get_user_pages_remote(current, current->mm, vaddr, page_cnt,
0, 0, (struct page **)page_list, NULL);
 
^
In file included from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/scatterlist.h:7:0,
 from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/dmapool.h:14,
 from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/pci.h:1269,
 from /var/lib/dkms/fglrx/15.12/build/firegl_public.c:117:
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/mm.h:1298:6:
note: expected ‘struct vm_area_struct **’ but argument is of type
‘struct page **’
 long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
  ^
/var/lib/dkms/fglrx/15.12/build/firegl_public.c:3254:11: error: too many
arguments to function ‘get_user_pages_remote’
 ret = get_user_pages_remote(current, current->mm, vaddr, page_cnt,
0, 0, (struct page **)page_list, NULL);
   ^
In file included from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/scatterlist.h:7:0,
 from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/dmapool.h:14,
 from
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/pci.h:1269,
 from /var/lib/dkms/fglrx/15.12/build/firegl_public.c:117:
/usr/src/linux-headers-4.9.0-0.bpo.2-common/include/linux/mm.h:1298:6:
note: declared here
 long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
  ^
/var/lib/dkms/fglrx/15.12/build/firegl_public.c: At top level:
/var/lib/dkms/fglrx/15.12/build/firegl_public.c:6493:12: warning:
‘KCL_fpu_save_init’ defined but not used [-Wunused-function]
 static int KCL_fpu_save_init(struct task_struct *tsk)
^
/usr/src/linux-headers-4.9.0-0.bpo.2-common/scripts/Makefile.build:298:
recipe for target '/var/lib/dkms/fglrx/15.12/build/firegl

Bug#829649: lintian: Spurious error: init.d-script-missing-dependency-on-remote_fs

[Niels Thykier]

Felipe Sateler:
> On Thu, Apr 20, 2017 at 11:12 AM, Niels Thykier  wrote:
>> [...]
>> Hi,
>>
>> Should we remap this as a check for "$local_fs" or can people assume
>> that /usr is always present?
> 
> I'd say yes.

That wasn't a "Yes/No" question! ;)

> The idea is that it should be guaranteed that /usr is
> mounted by the time the initramfs passes control to the init system.
> This means that most software (except things that survive past the
> init killing spree) can assume /usr is always available.
> 

Ok, so just drop the /usr check completely - will do.

>>  Currently, use of /var needs "$local_fs".
> 
> I'd say that use of /var requires $remote_fs. Remote-mounted /var is a
> supported configuration.
> 
> 

So far, I have only seen sources claiming that /var requires $local_fs.
 Notably, the (possibly dated) wiki page
https://wiki.debian.org/LSBInitScripts says $local_fs as well and I got
no reference/recent mail debate in the back of my head to claim
otherwise (unlike /usr, which I can remember seeing some debate about on
debian-devel).

I will leave /var for now as it is.  Feel free to bring up /var
requiring $remote_fs once stretch released.  I will be happy to
implement it given a consensus on debian-devel.

Thanks,
~Niels

Bug#860808: ocfs2 blocks jbd2

[Russell Mosemann]

Package: src:linux
Version: 4.9.13-1~bpo8+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 
Apr 20 12:03:24 vhost002 kernel: [ cut here ]
Apr 20 12:03:24 vhost002 kernel: WARNING: CPU: 1 PID: 19193 at 
/home/zumbi/linux-4.9.13/fs/jbd2/transaction.c:297 
start_this_handle+0x3fb/0x400 [jbd2]
Apr 20 12:03:24 vhost002 kernel: Modules linked in: vhost_net vhost macvtap 
macvlan tun ocfs2 quota_tree hmac veth iptable_filter ip_tables x_tables nfsd 
auth_rpcgss nfs_acl nfs lockd grace fscache ocfs2_dlmfs sunrpc ocfs2_stack_o2cb 
ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bridge stp llc bonding 
intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel ipmi_watchdog kvm ast irqbypass crct10dif_pclmul crc32_pclmul ttm 
ghash_clmulni_intel intel_cstate drm_kms_helper xhci_pci xhci_hcd iTCO_wdt drm 
igb intel_uncore iTCO_vendor_support ehci_pci e1000e mxm_wmi ehci_hcd dca 
i2c_algo_bit evdev i2c_i801 mei_me lpc_ich ptp usbcore intel_rapl_perf pcspkr 
mfd_core pps_core i2c_smbus shpchp mei sg usb_common fjes wmi tpm_tis 
tpm_tis_core acpi_power_meter tpm acpi_pad button ipmi_si ipmi_poweroff
Apr 20 12:03:24 vhost002 kernel:  ipmi_devintf ipmi_msghandler fuse drbd 
lru_cache libcrc32c crc32c_generic autofs4 ext4 crc16 jbd2 fscrypto mbcache 
dm_mod md_mod sd_mod crc32c_intel ahci libahci libata aesni_intel aes_x86_64 
glue_helper lrw gf128mul ablk_helper cryptd scsi_mod
Apr 20 12:03:24 vhost002 kernel: CPU: 1 PID: 19193 Comm: qemu-system-x86 Not 
tainted 4.9.0-0.bpo.2-amd64 #1 Debian 4.9.13-1~bpo8+1
Apr 20 12:03:24 vhost002 kernel: Hardware name: To Be Filled By O.E.M. To Be 
Filled By O.E.M./EPC612D4I, BIOS P2.10 03/31/2016
Apr 20 12:03:24 vhost002 kernel:   b6529cd5 
 
Apr 20 12:03:24 vhost002 kernel:  b62778a4 9c58aa658800 
9c58aa658800 9c587ee6f420
Apr 20 12:03:24 vhost002 kernel:   ffe4 
 c04807db
Apr 20 12:03:24 vhost002 kernel: Call Trace:
Apr 20 12:03:24 vhost002 kernel:  [] ? dump_stack+0x5c/0x77
Apr 20 12:03:24 vhost002 kernel:  [] ? __warn+0xc4/0xe0
Apr 20 12:03:24 vhost002 kernel:  [] ? 
start_this_handle+0x3fb/0x400 [jbd2]
Apr 20 12:03:24 vhost002 kernel:  [] ? 
jbd2__journal_start+0xe9/0x1f0 [jbd2]
Apr 20 12:03:24 vhost002 kernel:  [] ? 
ocfs2_start_trans+0xf8/0x1d0 [ocfs2]
Apr 20 12:03:24 vhost002 kernel:  [] ? 
ocfs2_dio_end_io_write+0x2fb/0x600 [ocfs2]
Apr 20 12:03:24 vhost002 kernel:  [] ? __schedule+0x245/0x6d0
Apr 20 12:03:24 vhost002 kernel:  [] ? 
ocfs2_allocate_extend_trans+0x180/0x180 [ocfs2]
Apr 20 12:03:24 vhost002 kernel:  [] ? 
ocfs2_dio_end_io+0x3b/0x60 [ocfs2]
Apr 20 12:03:24 vhost002 kernel:  [] ? dio_complete+0x7e/0x190
Apr 20 12:03:24 vhost002 kernel:  [] ? 
do_blockdev_direct_IO+0x2168/0x2860
Apr 20 12:03:24 vhost002 kernel:  [] ? 
ocfs2_write_end_nolock+0x550/0x550 [ocfs2]
Apr 20 12:03:24 vhost002 kernel:  [] ? 
ocfs2_direct_IO+0x83/0x90 [ocfs2]
Apr 20 12:03:24 vhost002 kernel:  [] ? 
generic_file_direct_write+0xb3/0x180
Apr 20 12:03:24 vhost002 kernel:  [] ? 
__generic_file_write_iter+0xb6/0x1e0
Apr 20 12:03:24 vhost002 kernel:  [] ? 
ocfs2_file_write_iter+0x44e/0xae0 [ocfs2]
Apr 20 12:03:24 vhost002 kernel:  [] ? wake_up_q+0x60/0x60
Apr 20 12:03:24 vhost002 kernel:  [] ? 
new_sync_write+0xde/0x130
Apr 20 12:03:24 vhost002 kernel:  [] ? vfs_write+0xb3/0x1a0
Apr 20 12:03:24 vhost002 kernel:  [] ? SyS_futex+0x83/0x180
Apr 20 12:03:24 vhost002 kernel:  [] ? SyS_pwrite64+0x86/0xb0
Apr 20 12:03:24 vhost002 kernel:  [] ? 
system_call_fast_compare_end+0xc/0x9b
Apr 20 12:03:24 vhost002 kernel: ---[ end trace 7c48549819590e08 ]---


-- Package-specific info:
** Version:
Linux version 4.9.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.9.13-1~bpo8+1 (2017-02-27)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-0.bpo.2-amd64 
root=UUID=00960d68-5f91-43de-9508-02f3b432cca3 ro console=tty0 
console=ttyS1,115200n8 quiet

** Tainted: W (512)
 * Taint on warning.

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

** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: P2.10
board_vendor: ASRockRack
board_name: EPC612D4I
board_version:

** Loaded modules:
vhost_net
vhost
macvtap
macvlan
tun
ocfs2
quota_tree
hmac
veth
iptable_filter
ip_tables
x_tables
nfsd
auth_rpcgss
nfs_acl
nfs
lockd
grace
fscache
ocfs2_dlmfs
sunrpc
ocfs2_stack_o2cb
ocfs2_dlm
ocfs2_nodemanager
ocfs2_stackglue
configfs
bridge
stp
llc
bonding
intel_rapl
sb_edac
edac_core
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
ipmi_watchdog
kvm
ast
irqbypass
crct10dif_pclmul
crc32_pclmul
ttm
ghash_clmulni_intel
intel_cstate
drm_kms