Bug#888733: hyantesite: test failures on most architectures

2019-05-20 Thread Andreas Tille
On Mon, May 20, 2019 at 08:05:09PM +0100, Rebecca N. Palmer wrote:
> On 19/05/2019 18:15, Andreas Tille wrote:
> > So what is the plan to fix this bug?  Create new references to craft
> > a valid test or ignore these tests?
> 
> ...or decide that something that's abandoned and doesn't follow its
> documentation (even after the above fixes) doesn't belong in Debian stable
> and let it be removed?  I have no strong opinion.
> 
> The above fix was written as part of an attempt to find fixes for all RC
> bugs in debian-science testing; I hadn't heard of the package before seeing
> this bug.

Same for me.  If nobody else might rise an opinion we probably let it go
and the package will be removed now from testing.  The real usage of
this package[1] is below 20 users (but anyway there are 20) and I'm
intentionally CCing Debian Science user list to possibly reach some of
these users.

Kind regards

   Andreas.

[1] 
https://qa.debian.org/popcon-graph.php?packages=libhyantes-dev+libhyantes0+hyantesite_vote=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1

-- 
http://fam-tille.de



Bug#929295: Acknowledgement (fstrim.service: fstrim -a (not -A) or add ConditionPathExists=/etc/fstab)

2019-05-20 Thread Trent W. Buck
> Why not use "fstrim --all --verbose" instead?

I knew there would be a reason, I just didn't know what it was.
The reason is to avoid trimming on ad-hoc mounted devices:

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/sys-utils/fstrim.service.in?id=0d73ea8bf96b036cc12fae6865158c936705238d
https://github.com/karelzak/util-linux/issues/673
https://bugs.debian.org/889668



Bug#914655: python-scipy: _flapack undefined symbol: ilaver_

2019-05-20 Thread Drew Parsons
Package: python-scipy
Followup-For: Bug #914655

Digging a bit deeper, I think this bug may be impacted by the presence
of /usr/lib/x86_64-linux-gnu/libopenblas.so provide by libopenblas-base

I think you will find your bug may be present in local builds of
scipy, but the official Debian builds will be fine.

Ultimately ilaver_ is a LAPACK symbol provided by liblapack.so.
The offical Debian scipy builds use a generic BLAS/LAPACK
implementation, so _flapack.x86_64-linux-gnu.so gets
  NEEDED liblapack.so.3
which can be fulfilled by any LAPACK implementation
(provided via python-scipy Depends: liblapack3 | liblapack.so.3)


But since libopenblas.so provides the same symbols as libblas.so and
liblapack.so, if you make a local build with openblas installed then
_flapack.x86_64-linux-gnu.so picks up 
  NEEDED libopenblas.so.0
instead.  But that does not get reflected in the python-scipy package
dependencis, since they have been configured to allow for alternatives
via libblas3 | libblas.so.3 and liblapack3 | liblapack.so.3.

It means if you have a python-scipy built against openblas then it
should run fine if libopenblas-base is installed.

If you then install one of the other LAPACK alternatives instead of
libopenblas-base (which you're supposed to be able to do), your
locally built scipy will complain with the error given in this bug,
becauses it will look for ilaver_ in libopenblas.so.0 which is no
longer present.

The /usr/lib/x86_64-linux-gnu/libopenblas.so seems to be the problem
here, so I've filed Bug#929296 to ask about it.



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

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

Versions of packages python-scipy depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-8
ii  libblas3 [libblas.so.3]3.8.0-2
ii  libc6  2.28-10
ii  libgcc11:8.3.0-7
ii  libgfortran5   8.3.0-7
ii  liblapack3 [liblapack.so.3]3.8.0-2
ii  libopenblas-base [liblapack.so.3]  0.3.5+ds-3
ii  libquadmath0   8.3.0-7
ii  libstdc++6 8.3.0-7
ii  python 2.7.16-1
ii  python-decorator   4.3.0-1.1
ii  python-numpy [python-numpy-abi9]   1:1.16.2-1

Versions of packages python-scipy recommends:
ii  g++   4:8.3.0-1
ii  g++-7 [c++-compiler]  7.4.0-9
ii  g++-8 [c++-compiler]  8.3.0-7
ii  python-dev2.7.16-1
ii  python-pil5.4.1-2

Versions of packages python-scipy suggests:
ii  python-scipy-doc  1.1.0-7

-- no debconf information



Bug#929287: e2scrub_reap.service fails to start

2019-05-20 Thread Theodore Ts'o
Package: e2fsprogs
Version: 1.45.1-3 

Fixed in the most recent upload of e2fsprogs.  (Sorry, I typo'ed the
Closes: number in the changelog.  I'll fix that up in a future release.)

   - Ted



Bug#929296: libopenblas-base: is libopenblas.so needed?

2019-05-20 Thread Drew Parsons
Package: libopenblas-base
Version: 0.3.5+ds-3
Severity: normal

This is more a Request For Clarification than a bug report.

Why is /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.5.so provided by
libopenblas-base?

We've got the alternatives mechanism for managing the different blas
implementations, placing the various libblas.so and liblapack.so in
the subdir
  /usr/lib/x86_64-linux-gnu/openblas
and then providing alternatives links to 
/usr/lib/x86_64-linux-gnu/libblas.so and
/usr/lib/x86_64-linux-gnu/liblapack.so

But libopenblas-base also provides
/usr/lib/x86_64-linux-gnu/libopenblas.so pointing at
/usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.5.so

The problem is that libopenblasp-r0.3.5.so contains exactly the same
symbols as libblas.so and liblapack.so.  This seems to be confusing
linkers, e.g. see Bug#914655 for python-scipy.

If libopenblasp-r0.3.5.so is present then it is used preferentially to
provide BLAS and LAPACK symbols, so the shared library
(_flapack.x86_64-linux-gnu.so in the case of python-scipy) ends up with 
  NEEDED libopenblas.so.0
instead of
  NEEDED liblapack.so.3
  NEEDED libblas.so.3

The official builds of scipy are fine since they build against the
generic BLAS. But local builds can become confused, which is what I
think happened with Bug#914655.  The package Depends: libblas3 |
libblas.so.3 where in this case it would need Depends: libopenblas-base.

So, is libopenblasp-r0.3.5.so really supposed to be provided in
/usr/lib/x86_64-linux-gnu by libopenblas-base, or this a bug which
should be fixed when the various BLAS flavours are being expanded?


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

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

Versions of packages libopenblas-base depends on:
ii  libc6 2.28-10
ii  libgfortran5  8.3.0-7

libopenblas-base recommends no packages.

libopenblas-base suggests no packages.

-- no debconf information



Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

2019-05-20 Thread sergio
On 26/04/2019 22:19, Ross Vandegrift wrote:

> 1) Application Theme -> Icons, choose Adwaita icon theme.
> 2) rm ~/.cache/efreet/icons_Adwaita_*
> 3) log out and back in
> 4) check pavucontrol icon in everything & menus

I can reproduce this with libefreet1a=1.21.1-5 from sid.


> With a fresh efreetd, I cannot reproduce this issue.

What is "a fresh efreetd"? Do you have deb that I can check?



Sorry for direct reply.

-- 
sergio.



Bug#929295: fstrim.service: fstrim -a (not -A) or add ConditionPathExists=/etc/fstab

2019-05-20 Thread Trent W. Buck
Package: util-linux
Version: 2.33.1-0.1
Severity: wishlist
File: /lib/systemd/system/fstrim.service

Currently fstrim.service runs "fstrim --fstab --verbose", so it silently ignores

  * Stuff mounted via hand-written systemd.mount units (e.g. 
/usr/share/systemd/tmp.mount);
  * ZFS datasets mounted via -o canmount and -o mountpoint properties.

Why not use "fstrim --all --verbose" instead?

Or, if you keep "fstrim --fstab --verbose", please consider adding

[Unit]
ConditionPathExists=/etc/fstab

so that it will NOP instead of erroring when fstab is completely absent:

systemd[1]: Condition check resulted in Discard unused blocks on 
filesystems from /etc/fstab being skipped.

Whereas currently it does this:

fstrim[5003]: fstrim: failed to parse /etc/fstab: No such file or directory
systemd[1]: fstrim.service: Main process exited, code=exited, status=32/n/a
systemd[1]: fstrim.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Discard unused blocks on filesystems from 
/etc/fstab.
systemd[1]: fstrim.service: Consumed 38ms CPU time, no IP traffic.

PS: fstrim.timer is disabled by default, so you only see errors if you
have no /etc/fstab *and* enable fstrim.timer or start fstrim.service.


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

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

Versions of packages util-linux depends on:
ii  fdisk  2.33.1-0.1
ii  libaudit1  1:2.8.4-3
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-10
ii  libcap-ng0 0.7.9-2
ii  libmount1  2.33.1-0.1
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.33.1-0.1
ii  libsystemd0241-3
ii  libtinfo6  6.1+20181013-2
ii  libudev1   241-3
ii  libuuid1   2.33.1-0.1
ii  login  1:4.5-1.1
ii  zlib1g 1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-4
ii  util-linux-locales  2.33.1-0.1

-- no debconf information



Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH

2019-05-20 Thread Theodore Ts'o
On Mon, May 20, 2019 at 08:17:09PM -0700, Noah Meyerhans wrote:
> At this point, I think it'd be worth revisiting, at the project level,
> the historical tradition of leaving the sbin directories out of non-root
> paths. Setting aside all the single user desktop and laptop systems,
> there are enough alternative ways to grant restricted root (file ACLs,
> etc), and to run in alternate filesystem namespaces (e.g.  containers),
> that the functional distinctions that lead to the original directory
> split are probably applicable in a minority of situations these days.

Sure, and I often use /sbin/mke2fs on create file system images on
plain files and then corrupt them using /sbin/debugfs to create
regression tests for e2fsck, and I do all of this w/o being root.  So
I have /sbin and /usr/sbin and /usr/local/sbin in my path.  Along with
a whole bunch of other customizations in my dot files, of course.

But my usage is an edge case, and asking Debian to make changes to
global changes to the defaults for people like me was never something
I thought was justifiable.  Ultimately, if we believe that someday
we'll have the year of the Linux Desktop, where the primary
applications used by users are things like Firefox, Open Office,
Tuxracer, etc., adding /sbin and /usr/sbin might not be doing those
users a favor --- and those of us who are more technical are perfectly
capable of customizing our dot files.  (Heck, I just pull a git repo
into ~/dotfiles, and then run "make install" and I get a custom set of
my dotfiles for that installation.  :-)

> This isn't something that I feel strongly about, though. Anybody who
> does should retitle this bug appropriately and reassign it to the
> 'general' pseudopackage, whereupon it can be discussed on debian-devel.
> Otherwise it should get tagged wontfix, unless someone thinks this is an
> appropriate change to introduce at the cloud image level (I would not
> agree with this).

I agree this should be a project-level decision, and not cloud-image
specific.  I personally am against changing the default.  That's
because if someone is installing Debian on student laptops / desktops
at an educational institution like MIT, most of those users really
don't need /sbin and /usr/sbin; Debian users include far more than
just system administrators, kernel developers, and devops types.

I don't feel very strongly about it, though, so if the project as a
whole thinks Debian should be optimized for technical users, it's not
something I'll lose any sleep over.  I replace all of the default
dotfiles for myself, anyway.  :-)

- Ted



Bug#894569: [Letsencrypt-devel] Bug#894569: acme-tiny: compatibility issues

2019-05-20 Thread sergio
Hello, Jean-Marc!

> Any information to add to this bug report ?
> Can you reproduce it ?

The only issue I've found in acme-tiny since this one is the wrong umask
handling:
https://github.com/diafygi/acme-tiny/issues/222

I'm not sure, but suspect this can be the same issue.


> In case you cannot reproduce the issue, can this bug be closed ?

Yep.


Sorry for previous direct answer.


-- 
sergio.



Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH

2019-05-20 Thread Noah Meyerhans
Control: severity -1 wishlist

> This is a historical convention, going back decades, that only the
> system administrators needs to run the programs in /sbin and
> /usr/sbin.  So to avoid users getting confused when they might run
> those programs and get "permission denied", historically normal users
> won't have /sbin and /usr/sbin in their path.  However many system
> administrators will have their own custom dot files which do include
> those directories in their paths.
> 
> That assumption is perhaps less likely to be true for servers running
> in cloud VM', but making things be different for cloud VM's as
> compared to standard Debian configurations also has downsides in terms
> of causing greater confusion.  So my suggestion would be for you to
> simply have your own custom dotfiles which can set a PATH different
> from the default.

At this point, I think it'd be worth revisiting, at the project level,
the historical tradition of leaving the sbin directories out of non-root
paths. Setting aside all the single user desktop and laptop systems,
there are enough alternative ways to grant restricted root (file ACLs,
etc), and to run in alternate filesystem namespaces (e.g.  containers),
that the functional distinctions that lead to the original directory
split are probably applicable in a minority of situations these days.

This isn't something that I feel strongly about, though. Anybody who
does should retitle this bug appropriately and reassign it to the
'general' pseudopackage, whereupon it can be discussed on debian-devel.
Otherwise it should get tagged wontfix, unless someone thinks this is an
appropriate change to introduce at the cloud image level (I would not
agree with this).

noah



signature.asc
Description: PGP signature


Bug#928948: hostapd: syslog is spammed every two seconds

2019-05-20 Thread sergio
On 13/05/2019 22:51, Andrej Shadura wrote:

> Could you please provide more details?

# l /etc/hostapd
ls: cannot access '/etc/hostapd': No such file or directory


# apt policy hostapd
hostapd:
  Installed: (none)
  Candidate: 2:2.7+git20190128+0c1e29f-5
  Version table:
 2:2.7+git20190128+0c1e29f-5 500
500 https://deb.debian.org/debian buster/main amd64 Packages


# apt policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 400 https://deb.debian.org/debian buster-proposed-updates/main amd64
Packages
 release
o=Debian,a=testing-proposed-updates,n=buster-proposed-updates,l=Debian,c=main,b=amd64
 origin deb.debian.org
 500 https://deb.debian.org/debian-security buster/updates/main amd64
Packages
 release o=Debian,a=testing,n=buster,l=Debian-Security,c=main,b=amd64
 origin deb.debian.org
 500 https://deb.debian.org/debian buster/non-free amd64 Packages
 release o=Debian,a=testing,n=buster,l=Debian,c=non-free,b=amd64
 origin deb.debian.org
 500 https://deb.debian.org/debian buster/contrib amd64 Packages
 release o=Debian,a=testing,n=buster,l=Debian,c=contrib,b=amd64
 origin deb.debian.org
 500 https://deb.debian.org/debian buster/main amd64 Packages
 release o=Debian,a=testing,n=buster,l=Debian,c=main,b=amd64
 origin deb.debian.org
Pinned packages:


# apt install hostapd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  hostapd
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 778 kB of archives.
After this operation, 2082 kB of additional disk space will be used.
Get:1 https://cdn-aws.deb.debian.org/debian buster/main amd64 hostapd
amd64 2:2.7+git20190128+0c1e29f-5 [778 kB]
Fetched 778 kB in 1s (700 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package hostapd.
(Reading database ... 42783 files and directories currently installed.)
Preparing to unpack .../hostapd_2%3a2.7+git20190128+0c1e29f-5_amd64.deb ...
Unpacking hostapd (2:2.7+git20190128+0c1e29f-5) ...
Setting up hostapd (2:2.7+git20190128+0c1e29f-5) ...
Created symlink /etc/systemd/system/hostapd.service → /dev/null.
Created symlink
/etc/systemd/system/multi-user.target.wants/hostapd.service →
/lib/systemd/system/hostapd.service.
Job for hostapd.service failed because the control process exited with
error code.
See "systemctl status hostapd.service" and "journalctl -xe" for details.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-3) ...
Scanning processes...

Scanning candidates...

Scanning processor microcode...

Scanning linux images...


Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

Restarting services...

Service restarts being deferred:
 systemctl restart libvirtd.service

No containers need to be restarted.

No user sessions are running outdated binaries.

# tail -f /var/log/syslog | grep hostap
systemd[1]: hostapd.service: Service RestartSec=2s expired, scheduling
restart.
systemd[1]: hostapd.service: Scheduled restart job, restart counter is
at 71.
hostapd[24428]: Configuration file: /etc/hostapd/hostapd.conf
hostapd[24428]: Could not open configuration file
'/etc/hostapd/hostapd.conf' for reading.
hostapd[24428]: Failed to set up interface with /etc/hostapd/hostapd.conf
hostapd[24428]: Failed to initialize interface
systemd[1]: hostapd.service: Control process exited, code=exited,
status=1/FAILURE
systemd[1]: hostapd.service: Failed with result 'exit-code'.
systemd[1]: hostapd.service: Service RestartSec=2s expired, scheduling
restart.
systemd[1]: hostapd.service: Scheduled restart job, restart counter is
at 72.
hostapd[24429]: Configuration file: /etc/hostapd/hostapd.conf
hostapd[24429]: Could not open configuration file
'/etc/hostapd/hostapd.conf' for reading.
hostapd[24429]: Failed to set up interface with /etc/hostapd/hostapd.conf
hostapd[24429]: Failed to initialize interface
systemd[1]: hostapd.service: Control process exited, code=exited,
status=1/FAILURE
systemd[1]: hostapd.service: Failed with result 'exit-code'.



> The postinst is set up in a way so that if /etc/hostapd/hostapd.conf
> is not readable or missing, the hostapd.service is masked during the
> package installation unless it was already running.

Looks like it's not masked.


> From what you wrote it sounds like the package hasn’t been installed
> before, but then it wouldn’t run by default.

The package was installed before, than purged, configs were removed.


-- 
sergio.



Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated

2019-05-20 Thread Sebastian Reichel
Hi Helmut,

On Mon, May 20, 2019 at 08:33:10PM +0200, Helmut Grohne wrote:
> On Mon, May 20, 2019 at 06:51:57PM +0200, Sebastian Reichel wrote:
> > Did you forgot to add the attachment? FWIW both changes are with me.
> 
> Yes, sorry. I intend to move foward with a "maintainer acknowledged NMU"
> if you lack time for doing the upload.

Instead of creating an extra patch for the config change I would
prefer to have config.php-dist.patch updated. Regarding the NMU:
Please go ahead.

-- Sebastian

> diff --minimal -Nru tt-rss-18.12+dfsg/debian/changelog 
> tt-rss-18.12+dfsg/debian/changelog
> --- tt-rss-18.12+dfsg/debian/changelog2019-02-06 00:04:47.0 
> +0100
> +++ tt-rss-18.12+dfsg/debian/changelog2019-05-20 17:53:54.0 
> +0200
> @@ -1,3 +1,11 @@
> +tt-rss (18.12+dfsg-1.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Cherry pick JShrink PHP 7.3 compatibility patch. (Closes: #923661)
> +  * Default to using syslog as log backend rather than sql.
> +
> + -- Helmut Grohne   Mon, 20 May 2019 17:53:54 +0200
> +
>  tt-rss (18.12+dfsg-1) unstable; urgency=medium
>  
>* New upstream release
> diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch 
> tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch
> --- tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch  1970-01-01 
> 01:00:00.0 +0100
> +++ tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch  2019-05-20 
> 17:53:47.0 +0200
> @@ -0,0 +1,11 @@
> +--- tt-rss-18.12+dfsg.orig/config.php-dist
>  tt-rss-18.12+dfsg/config.php-dist
> +@@ -166,7 +166,7 @@
> + // Disabling auth_internal in this list would automatically disable
> + // reset password link on the login form.
> + 
> +-define('LOG_DESTINATION', 'sql');
> ++define('LOG_DESTINATION', 'syslog');
> + // Error log destination to use. Possible values: sql (uses internal 
> logging
> + // you can read in Preferences -> System), syslog - logs to system log.
> + // Setting this to blank uses PHP logging (usually to http server
> diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 
> tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch
> --- tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 1970-01-01 
> 01:00:00.0 +0100
> +++ tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 2019-05-20 
> 17:49:53.0 +0200
> @@ -0,0 +1,32 @@
> +From 91105810dafedba0390608d7465abd602beb6410 Mon Sep 17 00:00:00 2001
> +From: Sergei Morozov 
> +Date: Fri, 14 Sep 2018 19:55:03 -0700
> +Subject: [PATCH] Fixed test failures on PHP 7.3
> +
> +1. continue in break shoud target the while loop directly 
> (php/php-src@04e3523).
> +2. strpos() doesn't longer accept non-string needles 
> (https://wiki.php.net/rfc/deprecations_php_7_3#string_search_functions_with_integer_needle).
> + src/JShrink/Minifier.php | 4 ++--
> + 2 files changed, 4 insertions(+), 3 deletions(-)
> +
> +diff --git a/src/JShrink/Minifier.php b/src/JShrink/Minifier.php
> +index 8103452..ad8157f 100644
> +--- a/vendor/JShrink/Minifier.php
>  b/vendor/JShrink/Minifier.php
> +@@ -183,7 +183,7 @@ protected function loop()
> + // new lines
> + case "\n":
> + // if the next line is something that can't stand alone 
> preserve the newline
> +-if (strpos('(-+{[@', $this->b) !== false) {
> ++if ($this->b !== false && strpos('(-+{[@', $this->b) 
> !== false) {
> + echo $this->a;
> + $this->saveString();
> + break;
> +@@ -231,7 +231,7 @@ protected function loop()
> + // check for some regex that breaks stuff
> + if ($this->a === '/' && ($this->b === '\'' || 
> $this->b === '"')) {
> + $this->saveRegex();
> +-continue;
> ++continue 3;
> + }
> + 
> + echo $this->a;
> diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/series 
> tt-rss-18.12+dfsg/debian/patches/series
> --- tt-rss-18.12+dfsg/debian/patches/series   2019-02-06 00:04:47.0 
> +0100
> +++ tt-rss-18.12+dfsg/debian/patches/series   2019-05-20 17:52:00.0 
> +0200
> @@ -1,3 +1,5 @@
>  config.php-dist.patch
>  remove-tt-rss-layer.patch
>  fix-db-updater-script.patch
> +jshrink_php7.3_fix.patch
> +default_to_syslog.patch



signature.asc
Description: PGP signature


Bug#929256: systemd lockdown for ntpsec-rotate-stats.service

2019-05-20 Thread Trent W. Buck
PS: one thing "systemd-analyze security" doesn't cover AT ALL is service denial 
attacks.

For example, one day I mounted a backup drive (full of snapshots) on
/mnt instead of /media, and the overnight mlocate updatedb cron job
tried to scan it, flushing all the real disk's blocks from the page
cache (thereby measurably reducing performance for everything else on
the system).

See also:

0)  The systemd reference is systemd.resource-control(5), but
it's a reference rather than a howto/guide/example.

1)  # These are equivalent to "nice ionice -c3 chrt --idle 0".  I think. --twb, 
Jun 2016
[Service]
Nice=10
IOSchedulingClass=idle
CPUSchedulingPolicy=idle

I habitually add these to anything that I think of as an "overnight 
background job".
Pretty much anything fired by cron or a .timer.

2)  mlocate uses "nocache" (an LD_PRELOAD hack that adds FADV_DONTNEED to I/O 
syscalls).
The nocache homepage (https://github.com/Feh/nocache) suggests on "modern" 
systems with cgroup v1 support, to set a per-unit memory limit instead.
I *think* under modern systemd, with cgroups v2, you actually do something 
like

MemoryHigh=128M

Which doesn't set a memory *limit*, but it helps the page cache
replacement algorithm decide which pages should be evicted first.

These articles explain that nocache (or equivalent) is needed as
workaround because Linux's current heuristics are old and crufty:

https://linux-mm.org/AdvancedPageReplacement
https://linux-mm.org/PageReplacementDesign

UNFORTUNATELY, I do not yet have enough experience to know what is
a "reasonable" MemoryHigh= number to set for a given unit.

systemd has memory accounting, but unlike CPU or network
accounting, when the unit ends, it will not report the "peak"
memory usage.

Instead, you have to poll systemd-cgls (or possibly systemctl
show) while the unit is running, to see the point-in-time value.

You can also shove /usr/bin/time in front of the command to see
*a* peak memory value, but (I think?) that doesn't include the
page cache (cache of HDD blocks in RAM).

$ /usr/bin/time gzip -k tmp.txt
… (… 1368maxresident)k



Bug#929294: xye: Garbage characters are displayed instead of hints

2019-05-20 Thread Ben Longbons
Package: xye
Version: 0.12.2+dfsg-8
Severity: normal

Dear Maintainer,

In xye.cpp, the following function:

const char* hint::GetActiveText()
{
string res;
if (active==(hint*)(1))
res = globaltext;
else if (active) 
res=active->text;

return res.c_str();
}

returns an invalidated pointer when compiled under the GCC 5 "new ABI".
This was safe on the old ABI, since it used CoW instead of SSO and the
strings the local was copied from are still alive.

Changing the return type to `string` is one fix, or you could
change both branches to `return existing_string.c_str();` directly.

Looking at the rest of the code, there are a lot of cases where a
borrowed pointer from a global or member is returned, both of which are
safe cases.

- Ben


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

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

Versions of packages xye depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libsdl-image1.2  1.2.12-10
ii  libsdl-ttf2.0-0  2.0.11-6
ii  libsdl1.2debian  1.2.15+dfsg2-4
ii  libstdc++6   8.3.0-6
ii  xye-data 0.12.2+dfsg-8

xye recommends no packages.

xye suggests no packages.

-- no debconf information



Bug#929272: nmap-common: executable distributed in nmap-common detected as malware

2019-05-20 Thread Hilko Bengen
* Dom Sekotill:

> /usr/share/nmap/nselib/data/psexec/nmap_service.exe is detected by
> Sophos AV as malware.

The antivirus installation is apparently misconfigured. In the local
filesystem context, the program is not even directly runnable. In the
context of .deb transfer by APT this should not matter either. I don't
see anything we can or should do about this.

The "offending" file nmap_service.exe and several Java class files that
might also be flagged by AV are included for a reason: They are used by
NSE scripts.

Users who run into problems because of this should make sure that their
AV product either ignores these packages -- or does not get to see them
in the first place. Using HTTPS for fetching packages is a sensible
solution, provided that no enterprise proxy product performs MITM
attacks against TLS connections.

> The nmap packages prior to 7.70 did not include the compiled binary.

This is technically not correct, nmap_service.exe has been shipped since
7.60+dfsg2-1. (Debian 9.0 shipped with nmap/7.40-1 which did not include
nmap_service.exe.)

Cheers,
-Hilko



Bug#929185: default soundfonts (was Re: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default)

2019-05-20 Thread Tim Colgate
The related bug/issue in fluidity is:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929182
(wrong reference earlier in this thread)

> Would users rather have no sound ... or bad sound

I vote for bad sound.

If there is no sound, there could be all sorts of reasons which can be very 
hard to track down, e.g. not in the correct audio group, no permission to 
access device, soundfont not installed, blocked by another program, daemon not 
running, unable to find library/plugin, volume too low etc. (These are not all 
relevant to gstreamer, but are problems I've had in the past that can be 
difficult to trace.)

If there is bad sound, then the system is basically working, so there are fewer 
things to check, e.g. poor audio file, poor soundfont, CPU too slow. It's then 
much easier to try a different audio file or soundfont, or nice the process.

The problem I had is that I wasn't getting errors reported, I just had no 
sound. It took quite a while to track down the problem, and the fix was nasty 
(I editted the plugin binary to change the directory searched from sounds/sf2 
to sounds/gst, then created that directory with a link in it to my preferred 
soundfont).



Bug#929293: e2fsprogs: e2scrub_all: illegal option -- C (from cronjob)

2019-05-20 Thread Thorsten Glaser
Package: e2fsprogs
Version: 1.45.1-2
Severity: normal

The cronjob already knows it, but the executable run doesn’t:

From: Cron Daemon 
Message-ID: <20190521011002.0272d220...@tglase.lan.tarent.de>
To: r...@tglase.lan.tarent.de
Date: Tue, 21 May 2019 03:10:01 +0200 (CEST)
Subject: Cron  test -e /run/systemd/system || /sbin/e2scrub_all -C 
-A -r

/sbin/e2scrub_all: illegal option -- C
Usage: /sbin/e2scrub_all [OPTIONS]
 -n: Show what commands e2scrub_all would execute.
 -r: Remove e2scrub snapshots.
 -A: Scrub all ext[234] filesystems even if not mounted.
 -V: Print version information and exit.


-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

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

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

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

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

-- no debconf information


Bug#929256: systemd lockdown for ntpsec-rotate-stats.service

2019-05-20 Thread Richard Laager
Here's what I have now, with your latest feedback incorporated:

--- a/debian/ntpsec.ntpsec-rotate-stats.service
+++ b/debian/ntpsec.ntpsec-rotate-stats.service
@@ -5,3 +5,35 @@ Requisite=ntpsec.service
 [Service]
 Type=simple
 ExecStart=/usr/lib/ntp/rotate-stats
+
+# These lock down this service to minimal privileges.
+# See also: systemd-analyze security
+CapabilityBoundingSet=
+IPAddressDeny=any
+LockPersonality=yes
+MemoryDenyWriteExecute=yes
+NoNewPrivileges=yes
+PrivateDevices=yes
+PrivateNetwork=yes
+PrivateTmp=yes
+PrivateUsers=yes
+ProtectControlGroups=yes
+ProtectHome=yes
+ProtectKernelModules=yes
+ProtectKernelTunables=yes
+ProtectSystem=strict
+ReadWritePaths=-/var/log/ntpsec/
+RemoveIPC=yes
+# AF_UNIX is probably not necessary, but there is no clear syntax for
+# disabling all address families.  An empty string clears the list.
+RestrictAddressFamilies=AF_UNIX
+RestrictNamespaces=yes
+RestrictRealtime=yes
+SystemCallArchitectures=native
+# Order is important here:
+SystemCallFilter=@system-service
+SystemCallFilter=~@privileged @resources
+# TODO: Can we use 077 and make ntpviz run as User=ntpsec?
+UMask=022
+User=ntpsec
+WorkingDirectory=/var/log/ntpsec

-- 
Richard



Bug#929256: systemd lockdown for ntpsec-rotate-stats.service

2019-05-20 Thread Trent W. Buck
Richard Laager wrote:
> As a side note that has nothing to do with you, it's too bad that
> systemd-analyze security does not work on a unit _file_, but only
> installed units. Otherwise, this would be a great thing for someone to
> hook into Lintian.

I 100% agree, and I mentioned that in #systemd, but they didn't seem terribly 
interested.
Also note that by default "systemd-analyze security" (with no argument) will 
not mention disabled/masked units (cf. "systemctl list-units -t service").

Lintian does have a basic systemd lockdown check currently, but it's looking 
for *any one* of a set of ~5 lockdown options.  Adding any of them is enough to 
silence lintian.

Another thing I haven't considered is what happens if you lock down a unit with 
Foo=bar, and then try to backport the unit to a systemd that *doesn't have* 
that option.
I *think* it will just trigger a warning message from PID 1 ("unknown key Foo 
in Service section"), but I have not tested this extensively.

> 3) Why do we want /var/log/ntpsec/temps.-MM-DD.gz to be
> world-readable? Is it just that, or everything that needs to be
> world-readable? Would this get better if the ntpviz services ran as the
> user ntpsec (i.e. could we then avoid them being world-readable)?

I don't know.

I found that those files were world-readable before I started, and
I figured that was probably intentional.

ntpviz may need them and may run as www-data/httpd user.

It makes sense to add a comment to this effect.

> 4) I re-ran systemd-analyze after adding these options. Do we really
> need local sockets? I see that systemd.exec's documentation suggests
> keeping it, e.g. for syslog, but is it actually used here?

I don't know.

For now I've been leaving AF_UNIX enabled in all my unit lockdowns, because

 * I'm just starting out,
 * AF_UNIX is classed as low-priority (0.1), and
 * it MIGHT be needed to report errors (syslog).

It makes sense to add a comment to this effect.

PS: IIRC I tried doing "RestrictAddressFamilies=" (i.e. allow *NO* families) 
early on, and
systemd interpreted it as "allow all families", but
I may have been confused.

> 5) Unless the order is critical (for humans; I realize it does not
> matter to systemd in most cases), I'd prefer to sort these.

The order in my paste was roughly the order in "systemd-analyze security".
I have no problem with sorting them lexicographically.

FYI, the order WITHIN a set of the the SAME key can matter to systemd:

Foo=bar
Foo=
Foo=baz

is different from

Foo=
Foo=bar
Foo=baz

> 6) I will have to wait until after the Buster release to accept and
> merge this, because of the code freeze.

No worries.

> So with them sorted, and making UMask explicit, here's what I have:
>
> [Unit]
> Description=Rotate ntpd stats
> Requisite=ntpsec.service
>
> [Service]

I just noticed, should this be Type=oneshot?
I'm never really sure when to use one or the other.

> Type=simple
> ExecStart=/usr/lib/ntp/rotate-stats
>
> # These lock down this service to minimal privileges.
 +# See also "systemd-analyze security".
> CapabilityBoundingSet=
> IPAddressDeny=any
> LockPersonality=yes
> MemoryDenyWriteExecute=yes
> NoNewPrivileges=yes
> PrivateDevices=yes

Remove duplicate record:

> PrivateNetwork=yes
> PrivateNetwork=yes
> PrivateTmp=yes
> PrivateUsers=yes
> ProtectControlGroups=yes
> ProtectHome=yes
> ProtectKernelModules=yes
> ProtectKernelTunables=yes
> ProtectSystem=strict
> ReadWritePaths=-/var/log/ntpsec/
> RemoveIPC=yes
 +# FIXME (minor): is AF_UNIX really needed?
> RestrictAddressFamilies=AF_UNIX
> RestrictNamespaces=yes
> RestrictRealtime=yes
> SystemCallArchitectures=native

Note that @system-service is broader than strictly necessary here.
First-party systemd units use it as a "good enough" list.

> # Order is important here:
> SystemCallFilter=@system-service
> SystemCallFilter=~@privileged @resources
> # We want /var/log/ntpsec/temps.-MM-DD.gz to be world-readable.

NOTE: it's UMask= not Umask=.  My original post had a typo.

 +# With safer UMask=077, /var/log/ntpsec/temps.-MM-DD.gz aren't group- or 
world-readable.
 +# FIXME: Do they need to be?  Use a permissive UMask= for now.
 +# FIXME: patch the script itself to "loosen" the umask only where needed?

> Umask=022
> User=ntpsec
> WorkingDirectory=/var/log/ntpsec



Bug#929256: systemd lockdown for ntpsec-rotate-stats.service

2019-05-20 Thread Richard Laager
Hey twb! I saw you pop into #ntpsec a couple of times, but you were
always gone by the time I was back at my computer.

I haven't had a chance to actually test this, outside of running
systemd-analyze on the modified unit.

Some comments:

1) In general, this is great! By all means, let's lock down the services
to minimum privileges. This systemd-analyze tool is new and I was not
previously aware of it. Thanks!

As a side note that has nothing to do with you, it's too bad that
systemd-analyze security does not work on a unit _file_, but only
installed units. Otherwise, this would be a great thing for someone to
hook into Lintian.

2) I agree that it would be nice to hit all the ntpsec services.

3) Why do we want /var/log/ntpsec/temps.-MM-DD.gz to be
world-readable? Is it just that, or everything that needs to be
world-readable? Would this get better if the ntpviz services ran as the
user ntpsec (i.e. could we then avoid them being world-readable)?

4) I re-ran systemd-analyze after adding these options. Do we really
need local sockets? I see that systemd.exec's documentation suggests
keeping it, e.g. for syslog, but is it actually used here?

5) Unless the order is critical (for humans; I realize it does not
matter to systemd in most cases), I'd prefer to sort these.

6) I will have to wait until after the Buster release to accept and
merge this, because of the code freeze.

So with them sorted, and making UMask explicit, here's what I have:

[Unit]
Description=Rotate ntpd stats
Requisite=ntpsec.service

[Service]
Type=simple
ExecStart=/usr/lib/ntp/rotate-stats

# These lock down this service to minimal privileges.
CapabilityBoundingSet=
IPAddressDeny=any
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateNetwork=yes
PrivateNetwork=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=strict
ReadWritePaths=-/var/log/ntpsec/
RemoveIPC=yes
RestrictAddressFamilies=AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
SystemCallArchitectures=native
# Order is important here:
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources
# We want /var/log/ntpsec/temps.-MM-DD.gz to be world-readable.
Umask=022
User=ntpsec
WorkingDirectory=/var/log/ntpsec

-- 
Richard



Bug#929292: autofs: lsstat errors on automounted NFS4.1 share

2019-05-20 Thread Matt Weatherford
Package: autofs
Version: 5.1.2-4
Severity: minor

Dear Maintainer,

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


I am seeing the following in the logs for autofs:


root@libra:~# cd /var/log
root@libra:/var/log# grep DESCRIP  *.log
daemon.log:May 20 14:32:47 libra automount[1399]: rmdir_path: lstat of 
/homes/DESCRIPTION failed

why is automount looking for this file?  It is quite frequent on Debian9 
systems.
I just updated everything on this debian 10 system to see if the issue is here 
also... apparently it is




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

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

Versions of packages autofs depends on:
ii  libc62.28-10
ii  libxml2  2.9.4+dfsg1-7+b3
ii  ucf  3.0038+nmu1

Versions of packages autofs recommends:
ii  e2fsprogs   1.44.5-1
ii  kmod26-1
ii  nfs-common  1:1.3.4-2.5

autofs suggests no packages.

-- no debconf information



Bug#929099: mlmmj-send fails when peer greeting is long and slow

2019-05-20 Thread Chris Knadle
Ian_Zimmerman:
> Package: mlmmj
> Version: 1.2.19.0-1
> Severity: normal
> Tags: upstream
> 
> When mlmmj-send injects mail into the MTA, it uses SMTP to 127.0.0.1 on port 
> 25.

Those are the defaults, but the "relayhost" and "smtpport" settings are tunable,
and there's also a "smtphelo" setting.

> Unfortunately, it doesn't correctly implement the SMTP standard: it sends an 
> EHLO
> command immediately after it gets the first line of the greeting, which in my 
> case
> starts with "220-" and is followed by additional lines.  The result is that it
> interprets these additional lines of the greeting as a response to the EHLO, 
> which
> of course fails.
> 
> I don't know if this wrong behavior is simply because it only waits for one 
> line
> (and, I'd guess, checks that the line starts with "2"), or because it is 
> confused
> by the several seconds the MTA waits before sending its greeting.  Both kinds 
> of
> behavior have been observed in many spamming tools which is precisely why I 
> have
> configured a multiline greeting and a delay.
> 
> In my opinion when mlmmj runs on the same host as the MTA, it should be at 
> least an
> option to inject mail directly via a pipe to /usr/sbin/sendmail; but I have 
> not found
> such an option.

There is a way of injecting mail directly with a pipe via entries in
/etc/alisases such as:

   example-list: "|/usr/bin/mlmmj-recieve -L /var/spool/mlmmj/example-list/"

(where "example-list" is the name of the mailing list)

Whether and how a this type of entry will work depends on the specific MTA being
used and how the MTA is configured.  For instance the provided upstream
instructions for Exim4 don't use entries like this in /etc/aliases, but the
instructions for Postfix do.

The MTA in the bug report shows 'equivs-mta' which I assume means that there's a
fake 'equivs-mta' package in use and the real MTA in use for this case is
something else.

Depending on the MTA you might be able to work around your normal multiline
greeting + delay if the originating sender it actually local (as opposed to a
remote sender spoofing that the sender is local).

I wasn't aware MLMMJ doesn't conform to proper SMTP EHLO, but it also won't
surprise me if I test to verify this and find that it's so.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



Bug#619409: insserv: /etc/init.d/.depend.* represent state, not configuration; please move to /lib

2019-05-20 Thread Jesse Smith
I brought this up in bug #601054 as well, but thought I'd mention it
here since this seems to be the same issue. Upstream we're experimenting
with using /var/lib/insserv/ as the location for storing boot-time
dependency data. However, I'm not sure we can rely on /var being mounted
when startpar runs. Which makes me this this bug, which requests the
data be placed under /lib/insserv/ might be the better approach.

Thoughts on this? I'm not sure it's safe to put boot-time configuration
data under /var, but I'm not sure if it's a practical concern or just a
theoretical one.

- Jesse



Bug#915845: pekwm: reproducible build (usrmerge): embeds path of tool found via PATH

2019-05-20 Thread Michael Biebl
Hi Andreas,

thanks for all the patches you sent regarding usr-merge, just a small
comment:

On Fri, 7 Dec 2018 11:48:12 +0100 Andreas Henriksson 
wrote:
> Package: pekwm
> Version: 0.1.17-3
> Severity: normal
> Tags: unreproducible patch

I find it a bit confusing to use the unreproducible tag for this purpose
as this tag has a different meaning.


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



signature.asc
Description: OpenPGP digital signature


Bug#601054: Move /etc/init.d/.depend.* files under /var

2019-05-20 Thread Jesse Smith
This has been done upstream and is now in the latest beta release [1].

Something I'm curious about is: what happens if /var is not mounted when
startpar runs? Let's say /var is on another disk, or mounted over NFS.
What then? I'm guessing some people are using a setup where /var is not
on the root file system, so what kind of fallback is in place to make
sure insserv and startpar work when their files are stored under /var
instead of /etc?

Another bug report against insserv suggested we use /lib/insserv/
instead of /var/lib/insserv/. Maybe we should switch the location before
the next stable release, since I'm pretty sure /lib needs to be part of
the root filesystem.

- Jesse


1 -
http://lists.nongnu.org/archive/html/sysvinit-devel/2019-05/msg2.html



Bug#237470: Can't reinstall coreutils and debianutils at the same time.

2019-05-20 Thread Andreas Beckmann
Version: 1.0.9.8.5

Hi,

I can reproduce this in jessie with systemd-sysv + systemd:

# apt-get --reinstall install systemd-sysv systemd
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not
upgraded.
Need to get 0 B/2593 kB of archives.
After this operation, 0 B of additional disk space will be used.
E: Couldn't configure systemd-sysv:amd64, probably a dependency cycle.

but not with the originally reported coreutils + debianutils:

# apt-get --reinstall install coreutils debianutils
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/2826 kB of archives.
After this operation, 0 B of additional disk space will be used.
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76, <> line 2.)
debconf: falling back to frontend: Readline
(Reading database ... 15138 files and directories currently installed.)
Preparing to unpack .../coreutils_8.23-4_amd64.deb ...
Unpacking coreutils (8.23-4) over (8.23-4) ...
Setting up coreutils (8.23-4) ...
(Reading database ... 15138 files and directories currently installed.)
Preparing to unpack .../debianutils_4.4+b1_amd64.deb ...
Unpacking debianutils (4.4+b1) over (4.4+b1) ...
Setting up debianutils (4.4+b1) ...


Andreas



Bug#929291: RFP: elpa-dockerfile -- emacs mode for handling Dockerfiles

2019-05-20 Thread Antoine Beaupre
Package: wnpp
Severity: wishlist

* Package name: elpa-dockerfile
  Version : 1.2
  Upstream Author : Spotify AB
* URL : https://github.com/spotify/dockerfile-mode/
* License : Apache 2
  Programming Lang: Elisp
  Description : emacs mode for handling Dockerfiles

Adds syntax highlighting as well as the ability to build the image
directly (C-c C-b) from the buffer.



This is very useful to edit Dockerfiles - without this, editing
Dockerfiles is just plain text and is slightly annoying.

The MELPA repo is broken so presumably some work is needed there:

https://github.com/spotify/dockerfile-mode/issues/44



Bug#929232: [Pkg-emacsen-addons] Bug#929232: flycheck: FTBFS (ValueError: Invalid placeholder in string)

2019-05-20 Thread Denis Danilov
Dear Santiago,

indeed conf.py for sphinxdoc has some problems due to enabled extensions...
I will prepare a fix.

Thanks,
Denis

On Sun, May 19, 2019 at 06:06:08PM +, Santiago Vila wrote:
> Package: src:flycheck
> Version: 31-2
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:



Bug#926180: scilab: FTBFS on all

2019-05-20 Thread Rebecca N. Palmer

Control: found -1 6.0.1-10

(I suggest opening a new bug for the 6.0.2 issues: as noted above, that 
probably won't be accepted for buster even if we do get it to build.)


Running what I think is the relevant step in a debugger:
* Go to the top level directory of a _built_ source tree (i.e. one that 
has had dpkg-buildpackage run on it; the same such tree can be used more 
than once)
* Open the script file scilab-bin, and at line 117 (in function 
func_exec_program_core), replace

-exec "$progdir/$program" ${1+"$@"}
+exec gdb --args "$progdir/$program" ${1+"$@"}
(or whatever debugging tool you want to use).
* Run:
LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1 
_JAVA_OPTIONS='-Djava.awt.headless=true' ./bin/scilab-adv-cli 
-noatomsautoload -nb -l en_US -nouserstartup -e "try 
xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);"


Results:
* no debugging tool: succeeds (for me), with the usual nonfatal 
IllegalStateException.
* qemu-x86_64-static -cpu Opteron_G3 (probably what x86-bm-01 has [0], 
but note that qemu *doesn't* reject instructions that the CPU model 
emulated doesn't have [1]): hangs using a full core of CPU.

* gdb: crashes with segfault and corrupt-stack backtrace,
Thread 1 "scilab-bin" received signal SIGSEGV, Segmentation fault.
0x7fffc096851b in ?? ()
(gdb) bt full
#0  0x7fffc096851b in ?? ()
No symbol table info available.
#1  0x0206 in ?? ()
No symbol table info available.
#2  0x7fffc0968280 in ?? ()
No symbol table info available.
#3  0x776c5034 in Abstract_VM_Version::_vm_major_version ()
   from /usr/lib/jvm/default-java/lib/server/libjvm.so
No symbol table info available.
#4  0x7fffbe10 in ?? ()
No symbol table info available.
#5  0x773317ca in VM_Version::get_processor_features ()
at ./src/hotspot/cpu/x86/vm_version_x86.cpp:565
use_avx_limit = 
buf = 
"P\372]UUU\000\000\000\000\000\000\000\000\000\000\004\f\000\000\000\000\000\000\320\335\062\367\377\177\000\000\001\000\000\000\004", 
'\000' , "\020", '\000' , 
"\310\235C\367\377\177\000\000\327\234C\367\377\177\000\000\001", '\000' 
, " 
vq\367\377\177\000\000\002\000\000\000\000\000\000\000S\000\000\000\032", 
'\000' , 
"p\372]UUU\000\000p\372]UUU\000\000\000\000\000\000\000\000\000\000"...

use_sse_limit = 
cache_line_size = 
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

* valgrind: reports a _lot_ of invalid memory accesses, then crashes 
with segfault
* (jvm doesn't work - .libs/scilab-bin is a native executable, not a 
Java file)


This suggests that it is memory corruption after all: the "illegal 
instruction" might be a corrupt stack returning to somewhere that was 
never meant to be executable code.


[0] https://lists.debian.org/debian-wb-team/2019/05/msg4.html
[1] https://bugs.launchpad.net/qemu/+bug/1818075



Bug#929289: xlog: [INTL:fr] French templates translation

2019-05-20 Thread Jean-Pierre Giraud

Package: xlog
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation updated, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege



fr.po.gz
Description: application/gzip


Bug#920373: default soundfonts (was Re: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default)

2019-05-20 Thread Thorsten Glaser
>On Sat, 18 May 2019 20:34:57 +0100 Tim Colgate > 
>wrote:

>> Unfortunately there doesn't seem to be a standard way in Linux of
>>setting a default soundfont to be used by all midi players; I was

This (#929185) may also affect timidity, which has its own format,
but with a trivial config file can support any SF2 (at least, did
not try SF3) soundfont:

tglase@tglase:~ $ cat /etc/timidity/ms_general.cfg
# this should suffice, for now
soundfont /usr/share/sounds/sf2/MuseScore_General_Full.sf2

I’ve opened #920373 against timidity to have sourcing this, commented
out, added to the stock timidity configuration (which already shows
commented-out entries for several other soundfonts).

Perhaps timidity could then default to just
soundfont /usr/share/sounds/default.sf2
and only list commented-out entries for other soundfonts that bring
their own timidity-specific configuration that’s not identical to
the trivial one?

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...



Bug#929260: apt-listbugs: not saving pinnings to disk

2019-05-20 Thread Francesco Poli
Control: tags -1 + moreinfo


On Mon, 20 May 2019 03:23:24 -0400 Boruch Baum wrote:

[...]
> For several upgrade procedures in the course of the recent few weeks,
> apt-listbugs has repeatedly been prompting me for the same bug (#915689
> rng-tools), and doesn't ever seem to update file
> /etc/apt/apt.conf.d/10apt-listbugs

Hello again Boruch,
thanks for this second bug report.

First of all, apt-listbugs is not supposed to update
file /etc/apt/apt.conf.d/10apt-listbugs

Quoting the apt-listbugs(1) man page:

[...]
|  /etc/apt/apt.conf.d/10apt-listbugs
| Configuration  file  fragment for APT containing options related
| to apt-listbugs: this is the recommended place where the  (root)
| user may tweak the behavior of apt-listbugs, but usually no cus‐
| tomization is required.
[...]

The file which is supposed to be automatically managed by apt-listbugs
is /etc/apt/preferences.d/apt-listbugs

Quoting the apt-listbugs(1) man page:

[...]
|   /etc/apt/preferences.d/apt-listbugs
| Version  preferences  file fragment for APT managed by apt-list‐
| bugs: this is where the package pins are added by the  apt-list‐
| bugs  program  and  removed  by its daily cron job. This file is
| managed automatically and there's normally no need to modify  it
| by hand.
[...]


Secondly, it's not clear to me exactly what you did, when prompted by
apt-listbugs.
Could you please send (to the bug e-mail address) a transcript of your
interaction with apt-listbugs during one of the package upgrades?

I mean something that starts as:

  Retrieving bug reports... Done
  Parsing Found/Fixed information... Done
  serious bugs of rng-tools (2-unofficial-mt.14-1 → 5-1) 
   b1 - #915689 - prevent from migrating to testing
  Summary:
   rng-tools(1 bug)
  Are you sure you want to install/upgrade the above packages? [Y/n/?/...]

but then goes and shows what you replied to the question and what
further output you obtained.

Please let me know, otherwise I cannot understand what went wrong (if
anything).


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgphif1RhDtSR.pgp
Description: PGP signature


Bug#929185: default soundfonts (was Re: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default)

2019-05-20 Thread Thorsten Glaser
Dixi quod…

>Hi Fabian and others,

>>Debian. If we add these to the alternatives system to provide

>Should we also make all packages providing an alternative for this
>Provides some virtual package, for others to depend on? I’d suggest
>sf2-soundfont and sf3-soundfont for naming, and SF3 soundfonts can
>Provides both of them.

Another point to think of: admins can locally install any¹ other
soundfont by just copying it into place, and those can also serve
as default soundfonts. This offers two questions:

• do we really need the virtual package outlined above (i.e. would
  it have any users in Depends)? Depending on it would make the
  local soundfont slightly more difficult. (If it’s just Recommends,
  no worries.)

• how easy is it for non-packaged things to be added to the
  Debian alternatives system? I think it’s just one command,
  which we could document in the consumers of soundfonts’ readmes.

① I know of several very well-liked but non-redistributable ones
  in the MuseScore forums scene alone.

bye,
//mirabilos
-- 
> Wish I had pine to hand :-( I'll give lynx a try, thanks.

Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine



Bug#929185: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default

2019-05-20 Thread Thorsten Glaser
Hi Fabian and others,

>I believe we have at least three soundfonts in SF2 format packaged in
>Debian. If we add these to the alternatives system to provide
>/usr/share/soundfonts/default.sf2, the effort would be manageable.

I’d be happy to add an /usr/share/sounds/sf2/default.sf2 alternative
to musescore-general-soundfont-lossless (which is about half a GiB
already and expected to grow). Please note the changed location, as
/usr/share/sounds/ is where soundfonts in Debian are expected to be
packaged, and we’ve been subdirectory’ing them by format.

Do we also wish a /usr/share/sounds/sf3/default.sf3 ? I’ve got four
providers for this…
- fluidr3mono-gm-soundfont (no longer updated)
- musescore-general-soundfont-small (actively developed)
- musescore-general-soundfont (actively developed)
- musescore-general-soundfont-lossless (see below)

Note that all SF2 soundfonts could also provide default.sf3, it’s
about the player capabilities which to choose.

On the other hand, putting them into /usr/share/sounds/sf?/ would
make the programs pick them up in soundfont listings, so perhaps
the different location (or just /usr/share/sounds/default.sf{2,3})
might make sense?

Should we also make all packages providing an alternative for this
Provides some virtual package, for others to depend on? I’d suggest
sf2-soundfont and sf3-soundfont for naming, and SF3 soundfonts can
Provides both of them.

Alternatives priorities could also be tricky. They can even differ
between default.sf2 and default.sf3…

As for SFZ soundfonts, I’m not aware of any already packaged, but
MuseScore lists stuff in /usr/share/sounds/sfz/ already, if extant.

Oh, and, one more question: what soundfonts are eligible?

• any honouring the SoundFont 2.00 (2.01, 2.04) standard
  (for SF3: with Vorbis sample compression)
• + the GS set
• + the GM set

This might be tricky. Would uses rather have no sound (e.g. if we
require GM) [or more soundfonts installed] or bad sound (e.g. if we
don’t require GM, and, say fluid-soundfont-gs is the only installed)?

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt



Bug#929287: Acknowledgement (e2scrub_reap.service fails to start)

2019-05-20 Thread Michael Biebl

Looks like a regression introduced by commit
9d41a057d9643505942628c919869a7019646276 which missed to add "C" to getopts



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



signature.asc
Description: OpenPGP digital signature


Bug#929288: ITP: ruby-inherited-resources -- Speeds up development by making controllers inherit all restful actions

2019-05-20 Thread Utkarsh Gupta
Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name : ruby-inherited-resources
  Version  : 1.9.0
  Upstream Author  : Jose Valim
* URL  : https://github.com/activeadmin/inherited_resources
* License  : Expat
  Programming Lang : Ruby
  Description  : Speeds up development by making controllers inherit
all restful actions

 Inherited Resources speeds up development by making your controllers
inherit
 all restful actions so you just have to focus on what is important. It
makes
 your controllers more powerful and cleaner at the same time.
 .
 In addition to making your controllers follow a pattern, it helps you to
write
 better code by following fat models and skinny controllers convention.


Bug#929287: e2scrub_reap.service fails to start

2019-05-20 Thread Michael Biebl
Package: e2fsprogs
Version: 1.45.1-2
Severity: serious
File: /lib/systemd/system/e2scrub_reap.service

During the latest update, I got this failure:

e2scrub_all.service is a disabled or a static unit not running, not starting it.
Job for e2scrub_reap.service failed because the control process exited with 
error code.
See "systemctl status e2scrub_reap.service" and "journalctl -xe" for details.
e2fsprogs-l10n (1.45.1-2) wird eingerichtet ...

Checking the status of the service, I get:
# systemctl status e2scrub_reap.service
● e2scrub_reap.service - Remove Stale Online ext4 Metadata Check Snapshots
   Loaded: loaded (/lib/systemd/system/e2scrub_reap.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-05-20 23:18:33 CEST; 32s 
ago
 Docs: man:e2scrub_all(8)
  Process: 24228 ExecStart=/sbin/e2scrub_all -C -A -r (code=exited, status=2)
 Main PID: 24228 (code=exited, status=2)

Mai 20 23:18:33 pluto systemd[1]: Starting Remove Stale Online ext4 Metadata 
Check Snapshots...
Mai 20 23:18:33 pluto e2scrub_reap[24228]: /sbin/e2scrub_all: illegal option -- 
C
Mai 20 23:18:33 pluto e2scrub_reap[24228]: Usage: /sbin/e2scrub_all [OPTIONS]
Mai 20 23:18:33 pluto e2scrub_reap[24228]:  -n: Show what commands e2scrub_all 
would execute.
Mai 20 23:18:33 pluto e2scrub_reap[24228]:  -r: Remove e2scrub snapshots.
Mai 20 23:18:33 pluto e2scrub_reap[24228]:  -A: Scrub all ext[234] filesystems 
even if not mounted.
Mai 20 23:18:33 pluto e2scrub_reap[24228]:  -V: Print version information and 
exit.
Mai 20 23:18:33 pluto systemd[1]: e2scrub_reap.service: Main process exited, 
code=exited, status=2/INVALIDARGUMENT
Mai 20 23:18:33 pluto systemd[1]: e2scrub_reap.service: Failed with result 
'exit-code'.
Mai 20 23:18:33 pluto systemd[1]: Failed to start Remove Stale Online ext4 
Metadata Check Snapshots.




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

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

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

Versions of packages e2fsprogs recommends:
ii  e2fsprogs-l10n  1.45.1-2

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
ii  fuse2fs1.45.1-2
ii  gpart  1:0.3-6
ii  parted 3.2-25

-- no debconf information


Bug#924591: flashing use case

2019-05-20 Thread Hans-Christoph Steiner
We'd like to support the complete toolset, but given the scope of the
work as compared to the number of contributions, we have to focus on
specific use cases.  For example, for fastboot, we've focused on the use
case of flashing ROMs.  Therefore, though this is a regression, I'm
categorizing this as wishlist.  Supporting the ext4 formatting feature
in fastboot was a byproduct of our effort, and the removal of that
feature from fastboot was entirely due to upstream code reorganization.



Bug#929259: apt-listbugs: should run before downloading packages

2019-05-20 Thread Francesco Poli
Control: forcemerge 192787 -1


On Mon, 20 May 2019 03:18:55 -0400 Boruch Baum wrote:

[...]
> Currently, the program runs after downloading packages, with the result
> that a user may needlessly be downloading packages that won't be
> installed.

Hello Boruch,
thanks for your bug report.

This report is actually a feature request (hence the proper severity is
"wishlist") and has already been reported a number of times.
Moreover, it is waiting for an appropriate feature to be implemented in
apt (bug #80123).

I am therefore merging your bug report with the other ones about the
same topic.

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp9Fjz7iOkRT.pgp
Description: PGP signature


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

2019-05-20 Thread Uwe Kleine-König
Hello,


On Sun, May 12, 2019 at 07:03:44PM +0200, etche...@tutanota.com wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,  I am looking for a sponsor for my package "heimdall-flash"

it is wrong to file a RFS in your situation. The package heimdal-flash
already exists in the archive. So please contact the current maintainer
(added to Cc:) with your work, e.g. by reporting a bug against
heimdal-flash.

> * Package name: heimdall-flash
>   Version : 1.4.2-1
>   Upstream Author : Benjamin Dobell (@glassechidna 
> )
> * URL : https://www.glassechidna.com.au/heimdall/ 
> 
> * License : MIT License (Expat)
>   Section : devel
> It builds those binary packages:
>   heimdall-flash - tool for flashing firmware on Samsung Galaxy S devices
>   heimdall-flash-frontend - tool for flashing firmware on Samsung Galaxy S 
> devices - Qt GUI
> To access further information about this package, please visit the following 
> URL:  https://mentors.debian.net/package/heimdall-flash 
> 
> Alternatively, one can download the package with dget using this command:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/h/heimdall-flash/heimdall-flash_1.4.2-1.dsc
>  
> 
> More information about heimdall-flash can be obtained from 
> https://www.example.com .
> Changes since the last upload:
>  * New upstream release.

Best regards
Uwe


signature.asc
Description: PGP signature


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

2019-05-20 Thread Moritz Mühlenhoff
severity 921952 serious
thanks

On Tue, Apr 16, 2019 at 04:51:52PM +0200, Jonas Smedegaard wrote:
> control: severity -1 important
> 
> Quoting Aljoscha Lautenbach (2019-04-09 23:03:06)
> > during the BSP in Gothenburg last weekend I discussed with Jonas how I 
> > could help to put libsass back on track regarding its security status. 
> > We agreed that the best move is to start with triaging the existing 
> > Debian bugs and by identifying the CVE status in upstream's issue 
> > tracker. [0]
> 
> @Aljoscha: Thanks for your initial work and - more so - for committing 
> to help generally looking after these security issues in libsaass.
> 
> Due to the expansion of the libsass team with Aljoscha, I am lowering 
> severity of this bugreport.
> 
> If the security team or others disagree, then please elaborate what you 
> consider is needed.

What's considered needed is that someone should actually look through
https://security-tracker.debian.org/tracker/source-package/libsass and
triage/fix.

The only visible action done in five weeks was to lower the severity, so
I'm reverting to RC status until there's some actual work happening.

Cheers,
Moritz



Bug#928053: Severity of bug #928053 is too high

2019-05-20 Thread Moritz Mühlenhoff
On Sat, May 11, 2019 at 06:45:13AM +0200, Christian Folini wrote:

Hi Christian,

Thanks for chiming in, much appreciated! But I need some further clarification.

> The Core Rule Set project explained the situation in
> https://coreruleset.org/20190425/regular-expression-dos-weaknesses-in-crs/
> 
> The CVEs were issues against the Regular Expression itself, not CRS running
> on ModSecurity.

CVEs are not assigned for regular expressions by itself. And the CVE description
explicitly refers to ModSecurity, so if those reports are not correct, the
CVE IDs should be rejected as MITRE.

> Debian Stable comes wtih ModSecurity 2.
> Debian Testing comes with ModSecurity 3.

Debian stable actually has 3.0.0, but it doesn't matter here.

> CVE-2019-11391
> Not affected.
> -> 
> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1357#issuecomment-487344464
>
> CVE-2019-11390
> Not affected.
> -> 
> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1358#issuecomment-487344517
> 
> CVE-2019-11389
> Not affected.
> -> 
> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1356#issuecomment-487073750
>   
> CVE-2019-11388
> Not affected.
> -> 
> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1354#issuecomment-487070518

So if there's no circumstance where this triggers in modsecurity-crs, the four 
CVE ID
should be rejected. Otherwise this will only cause confusion. Do you know who 
requested
these? Rejects can be requested via https://cveform.mitre.org -> Select a 
request type
-> Request an update to an existing CVE Entry.

> CVE-2019-11387
> ModSecurity 3 and thus NGINX 3 and thus Debian Unstable is affected at
> Paranoia Level 2 and above. The default setting is Paranoia Level 1.
> -> 
> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1359#issuecomment-487344654

I don't understand. What does Nginx 3 have to do with it? There's not even
such a version in unstable, the latest is 1.14.2?

Cheers,
Moritz



Bug#928959: papi: DFSG-unfree file in source

2019-05-20 Thread Xavier
Hi all,

papi embeds iozone in appio component. This software has been declared
non-DFSG (https://lists.debian.org/debian-legal/2000/03/msg00024.html
thread). Removing src/components/appio/tests/iozone in "Files-Excluded"
field (and repack) is enough: these files are not used during build
(tested locally).

Cheers,
Xavier



Bug#639225: NICE TO READ FROM YOU

2019-05-20 Thread michelle fernella
How are you doing today and hope you are in good health,I am so pleased and
overwhelmed with your kind response, I'm happy to hear back from you. I am
America citizen and also an Army officer as a Major and I am serving in the
US Army, I base in Miami Florida but right now I am leading a troop in
Afghanistan. I am serving in the military of the 3rd Infantry Division here
in afghanistan and also a nurse in the military base. I Love meeting
people, reading, traveling, sharing ideas and also I care about nature,
human being, I love arts, environment, social culture, etc. I am 41 years
of age. My full names are Michell Fernella, a Major in the American Army. I
am an America National and I am still in kabul in a peacekeeping mission.

It is my pleasure having you as my friend. I am here to build a strong
friendship based on mutual respect and love. We are living only once and I
don't want to spend the rest of my Life on dirty and unnecessary things,
like wasting time with someone who is not responsible and reliable. I know
what I want from life. Knowing one another is a gradual process and here
are few things I think you should know about me. I am American citizen and
also an Army officer as a Major and I am serving in the US Army, a Major in
the U.S.A Army.I Love meeting people, reading, traveling, sharing ideas and
also I care about nature, human being, I love arts, environment, social
culture, etc.

Actually I have a son and his name is Micheal, he is 11 years old he is in
Military Boarding Schools in Texas under the care of my Government since
the death of his late father as he died in a fetal accident. I am glad to
have you as a friend and I believe that we have so many things to share in
common. I have been a Soldier all through my life and now that I have seen
someone who is out of my profession, I am so pleased to have you in my life
as a friend and am sure that it a pleasure knowing me as well.
I would like you to tell me more about yourself and your country
Thanks and god bless you as I wait for your kind response.
Best Regards
Major Michelle Fernella


Bug#929286: kmail - can not print mails (get no content)

2019-05-20 Thread Hans-J. Ullrich
Package: kmail
Version: 4:18.08.3-1
Severity: normal

Dear Maintainer,

I tried to print a mail, but I got only an empty page. Also the preview for 
prints is showing an empty sheet.

When I imported the same e-mail into "evolution" (another mua), printing is 
working like a charm.

All other printings are working fine, except printing a mail out of kmail.

Thank you for reading this.

Best regards

Hans
  

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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.3-5
ii  kdepim-runtime   4:18.08.3-4
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgpgmepp6  1.12.0-6
ii  libkf5akonadiagentbase5  4:18.08.3-5
ii  libkf5akonadicontact54:18.08.3-1
ii  libkf5akonadicore5abi2   4:18.08.3-5
ii  libkf5akonadimime5   4:18.08.3-1
ii  libkf5akonadisearch-bin  4:18.08.3-1
ii  libkf5akonadisearch-plugins  4:18.08.3-1
ii  libkf5akonadisearchdebug54:18.08.3-1
ii  libkf5akonadisearchpim5  4:18.08.3-1
ii  libkf5akonadiwidgets5abi14:18.08.3-5
ii  libkf5bookmarks5 5.54.0-1
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5calendarutils5 4:18.08.3-2
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1
ii  libkf5configgui5 5.54.0-1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5followupreminder5  4:18.08.3-2
ii  libkf5grantleetheme-plugins  18.08.3-1
ii  libkf5gravatar5abi2  4:18.08.3-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5identitymanagement518.08.3-2
ii  libkf5itemmodels55.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5kontactinterface5  18.08.3-1
ii  libkf5ksieveui5  4:18.08.3-2
ii  libkf5libkdepim-plugins  4:18.08.3-2
ii  libkf5libkdepim5 4:18.08.3-2
ii  libkf5libkdepimakonadi5  4:18.08.3-2
ii  libkf5libkleo5   4:18.08.3-2
ii  libkf5mailcommon5abi24:18.08.3-2
ii  libkf5mailtransport5 18.08.3-2
ii  libkf5mailtransportakonadi5  18.08.3-2
ii  libkf5messagecomposer5abi1   4:18.08.3-2
ii  libkf5messagecore5abi1   4:18.08.3-2
ii  libkf5messagelist5abi1   4:18.08.3-2
ii  libkf5messageviewer5abi1 4:18.08.3-2
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5mimetreeparser5abi14:18.08.3-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5pimcommon5abi2 4:18.08.3-2
ii  libkf5pimcommonakonadi5abi1  4:18.08.3-2
ii  libkf5pimtextedit5abi2   18.08.3-1
ii  libkf5sendlater5 4:18.08.3-2
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5sonnetui5  5.54.0-1
ii  libkf5templateparser54:18.08.3-2
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5tnef5  4:18.08.3-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5webengineviewer5abi1   4:18.08.3-2
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libqgpgme7   1.12.0-6
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libqt5xml5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-6

Versions of packages kmail recommends:
ii  accountwizard   4:18.08.3-1
ii  gnupg   2.2.12-1
ii  kdepim-addons   18.08.3-2
ii  kdepim-themeeditors 4:18.08.3-1
pn  mbox-importer   
pn  pim-data-exporter   
pn  pim-sieve-editor
ii  pinentry-gnome3 [pinentry-x11]  1.1.0-2
ii  pinentry-gtk2 [pinentry-x11]

Bug#929285: akonadi with kmail - gets not correctly syncronized

2019-05-20 Thread Hans-J. Ullrich
Source: akonadi
Severity: important

Dear Maintainer,

since over 2 years there is a problem with kmail and akonadi and from version 
to version 
it got worse. 

The problem is this: When I want to delete mails in kmail (i.e. delete the 
whole inbox), it does not work, when I delete them fast. "Fast" means, either 
mark them all, then delete, or using the "del" key rapidly, to move the mails 
into the trash.

Doing this slowly, it might work, but not always. Sometimes it hangs and 
sometimes I have to click another foder, then go back and after this I can go 
on.

But this is not the only problem. Now I can empty the trash (and it looks like 
the mails are completely deleted), but after restart of kmail or sometimes a 
few days later, most of the mails I deleted in the "trash" folder appeared 
again.

This is either annoying and also a security hole. When mails are deleted, I 
want them deleted!

This last behaviour appear now for months (almost a year) and the hangings at 
the deleteion appear since kmail used akonadi. 

Obviously no one cared although I mentioned this before several times. Ah, and 
this bug
appears on every machine, 32-bit and 64-bit, in debian/stable as well as in 
debian/testing.

As this bug exists now for so long, I set this bugreport to "important". 
Besides, I am not sure, but I believe, it is not the fault of kmail, but a bug 
in akonadi. 

If you are sure, akonadi is working correctly, you may of course transfer this 
bugreport to
kmail.

Thank you very much for reading this mail. 

Best regards

Hans
  

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

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



Bug#928959: papi: DFSG-unfree file in source

2019-05-20 Thread Xavier
Le 20/05/2019 à 22:19, Xavier a écrit :
> Hi all,
> 
> papi embeds iozone in appio component. This software has been declared
> non-DFSG (https://lists.debian.org/debian-legal/2000/03/msg00024.html
> thread). Removing src/components/appio/tests/iozone in "Files-Excluded"
> field (and repack) is enough: these files are not used during build
> (tested locally).
> 
> Cheers,
> Xavier

Ready in
https://salsa.debian.org/hpc-team/papi/merge_requests/1

Cheers,
Xavier



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

2019-05-20 Thread Otto Kekäläinen
Hello!

ke 15. toukok. 2019 klo 13.33 Daniel Högele - adelphi
(hoeg...@adelphi.de) kirjoitti:
>
> Therefore it may be possible to reproduce the bug by repeating this update 
> sequence, at least for the steps from 8 to 9 (or maybe 7->8->9).

You need to produce me the exact steps. I am not going to spend time
doing such massive updates to _maybe_ be able to reproduce your issue.

> List of all installed packages for php, mysql and mariadb:
>
> apt list --installed | grep -E 'mysql|php|maria'
> dbconfig-mysql/stable,now 2.0.8 all [installed,automatic]
> default-mysql-server/stable,now 1.0.2 all [installed,automatic]
> libapache2-mod-php/stable,now 1:7.0+49 all [installed]
> libapache2-mod-php5/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
> libapache2-mod-php7.0/stable,stable,now 7.0.33-0+deb9u3 amd64 
> [installed,automatic]
> libdbd-mysql-perl/stable,now 4.041-2 amd64 [installed]
> libmariadbclient18/now 10.1.26-0+deb9u1 amd64 [installed,upgradable to: 
> 10.1.38-0+deb9u1]
> libmysqlclient-dev/now 5.5.55-0+deb8u1 amd64 [installed,local]
> libmysqlclient18/now 5.5.55-0+deb8u1 amd64 [installed,local]
> libphp-adodb/stable,now 5.20.9-1 all [installed]
> libphp-pclzip/now 2.8.2-3 all [installed,local]
> mariadb-client-10.1/stable,now 10.1.38-0+deb9u1 amd64 [installed,automatic]
> mariadb-client-core-10.1/stable,now 10.1.38-0+deb9u1 amd64 
> [installed,automatic]
> mariadb-common/stable,now 10.1.38-0+deb9u1 all [installed,automatic]
> mariadb-server-10.1/stable,now 10.1.38-0+deb9u1 amd64 [installed,automatic]
> mariadb-server-core-10.1/stable,now 10.1.38-0+deb9u1 amd64 
> [installed,automatic]
> mysql-common/stable,now 5.8+1.0.2 all [installed,automatic]
> mysql-server/stable,now 5.5.+default amd64 [installed]
> mysqltuner/stable,now 1.6.18-1 all [installed]
> php/stable,now 1:7.0+49 all [installed,automatic]
> php-apcu/stable,now 5.1.8+4.0.11-1 amd64 [installed]
> php-apcu-bc/stable,now 1.0.3-2 amd64 [installed,automatic]
> php-bz2/stable,now 1:7.0+49 all [installed,automatic]
> php-common/stable,now 1:49 all [installed,automatic]
> php-curl/stable,now 1:7.0+49 all [installed,automatic]
> php-fpm/stable,now 1:7.0+49 all [installed]
> php-gd/stable,now 1:7.0+49 all [installed,automatic]
> php-gettext/stable,now 1.0.12-0.1 all [installed,automatic]
> php-gmp/stable,now 1:7.0+49 all [installed]
> php-intl/stable,now 1:7.0+49 all [installed]
> php-mbstring/stable,now 1:7.0+49 all [installed,automatic]
> php-mysql/stable,now 1:7.0+49 all [installed,automatic]
> php-pclzip/stable,now 2.8.2-4 all [installed,automatic]
> php-pear/stable,stable,now 1:1.10.1+submodules+notgz-9+deb9u1 all 
> [installed,automatic]
> php-php-gettext/stable,now 1.0.12-0.1 all [installed,automatic]
> php-phpseclib/stable,now 2.0.4-1 all [installed,automatic]
> php-snmp/stable,now 1:7.0+49 all [installed]
> php-soap/stable,now 1:7.0+49 all [installed]
> php-tcpdf/stable,now 6.2.12+dfsg2-1 all [installed,automatic]
> php-xdebug/stable,now 2.5.0-1 amd64 [installed]
> php-xml/stable,now 1:7.0+49 all [installed,automatic]
> php-xmlrpc/stable,now 1:7.0+49 all [installed]
> php-zip/stable,now 1:7.0+49 all [installed,automatic]
> php5-apcu/now 4.0.7-1 amd64 [installed,local]
> php5-cli/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
> php5-common/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
> php5-curl/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
> php5-gd/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
> php5-imap/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
> php5-json/now 1.3.6-1 amd64 [installed,local]
> php5-ldap/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
> php5-mcrypt/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
> php5-mysql/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]

How about removing all php5-packages or at least the php5-mysql
package from your system? You cannot keep running these old packages
and expect everything to work. At minimum you should have only
packages that stem from Stretch if you file bugs against Stretch.



Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH

2019-05-20 Thread Theodore Ts'o
On Mon, May 20, 2019 at 01:02:25PM -0400, Noah Meyerhans wrote:
> On Mon, May 20, 2019 at 11:26:00AM +0200, Jorge Barata González wrote:
> >Vagrant image debian/stretch64 v9.6.0
> >/usr/sbin is not included by default in $PATH
> > 
> >```
> >vagrant@stretch:~$ service
> >-bash: service: command not found
> >vagrant@stretch:~$ /usr/sbin/service
> >Usage: service < option > | --status-all | [ service_name [ command |
> >--full-restart ] ]
> >vagrant@stretch:~$ echo $PATH
> >/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> >```
> 
> That path is set from /etc/profile, which is not modified by the vagrant
> images from the default that Debian installs. /usr/sbin is not in the
> default PATH in Debian normally.

Specifically, /usr/sbin and /sbin are not in the path for non-root
users, but they are included for root users:

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi

(And since you really don't want to be running /usr/games/nethack as
root, /usr/games and /usr/local games is not in root's path.  :-)

This is a historical convention, going back decades, that only the
system administrators needs to run the programs in /sbin and
/usr/sbin.  So to avoid users getting confused when they might run
those programs and get "permission denied", historically normal users
won't have /sbin and /usr/sbin in their path.  However many system
administrators will have their own custom dot files which do include
those directories in their paths.

That assumption is perhaps less likely to be true for servers running
in cloud VM', but making things be different for cloud VM's as
compared to standard Debian configurations also has downsides in terms
of causing greater confusion.  So my suggestion would be for you to
simply have your own custom dotfiles which can set a PATH different
from the default.

- Ted



Bug#929283: zookeeper: CVE-2019-0201: information disclosure vulnerability

2019-05-20 Thread Salvatore Bonaccorso
Source: zookeeper
Version: 3.4.13-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://issues.apache.org/jira/browse/ZOOKEEPER-1392
Control: found -1 3.4.9-3+deb9u1
Control: found -1 3.4.9-1

Hi,

The following vulnerability was published for zookeeper.

CVE-2019-0201[0]:
Information disclosure vulnerability

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-2019-0201
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0201
[1] https://issues.apache.org/jira/browse/ZOOKEEPER-1392
[2] https://www.openwall.com/lists/oss-security/2019/05/20/1

Regards,
Salvatore



Bug#929284: ITP: ruby-inherited-resources -- Speeds up development by making your controllers inherit actions

2019-05-20 Thread Samyak Jain
Package: wnpp
Severity: wishlist
Owner: Samyak Jain 

* Package name: ruby-inherited-resources
  Version : 1.10.0
  Upstream Author : José Valim 
* URL : https://github.com/activeadmin/inherited_resources
* License : Expat
  Programming Lang: Ruby
  Description : Speeds up development by making your controllers
inherit actions

 Inherited Resources speeds up development by making your controllers inherit
 all restful actions so you just have to focus on what is important. It makes
 your controllers more powerful and cleaner at the same time.
 In addition to making your controllers follow a pattern, it helps you to write
 better code by following fat models and skinny controllers convention.


It is a dependency for loomio and hence needs to be packaged.

Thanks,
Samyak Jain


Bug#923930: testsuite comes with built-in time-bomb

2019-05-20 Thread Giovanni Mascellani
Hi again,

On Mon, 20 May 2019 19:23:40 +0200 Giovanni Mascellani
 wrote:
> If we ignore this and just consider the bug as FTBFS, then it is easy to
> patch the package to that failing tests are ignored under 32 bit archs.
> Otherwise, the patch might be more complicated; I prodded upstream on
> the GitHub issue to understand their intentions.

Upstream confirms that an update that handles 32 bit archs is not on the
radar soon. I don't know what it is the best way forward now, but if it
is decided that it is ok the ignore the error for 32 bit archs, then I
can try to cook up the required patch.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature


Bug#929185: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default

2019-05-20 Thread Fabian Greffrath
Hi Tim, hi slomo, hi Thorsten,

On Sat, 18 May 2019 20:34:57 +0100 Tim Colgate  wrote:
> Unfortunately there doesn't seem to be a standard way in Linux of
setting a default soundfont to be used by all midi players; I was
wondering if it would be possible to use e.g. the /etc/alterntives
mechanism to choose between various Debian soundfonts e.g.
MuseScore_General_Full.sf2 and FluidR3_GM.sf2, and then modify the
gstreamer plugin to use that instead.

we are facing a similar issue in fluidsynth [1], i.e. the library is
looking for a default fall-back soundfont that is hard-coded as
/usr/share/soundfonts/default.sf2, but there is no package in Debian
providing that file.

I believe we have at least three soundfonts in SF2 format packaged in
Debian. If we add these to the alternatives system to provide
/usr/share/soundfonts/default.sf2, the effort would be manageable.
Then, we would have to adjust gstreamer to prefer this file before
falling back to searching through random directories. Could we agree to
do this after the next stable release, please?

Cheers,

 - Fabian


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


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


Bug#926412: unblock: gnutls28/3.6.7-2

2019-05-20 Thread Paul Gevers
Hi Andreas,

I am going to push back.

On 19-05-2019 10:33, Andreas Metzler wrote:
> I probably could try to pick the CVE related changes and other important
> bug-fixes, however I do not think it is the right choice. The changes
> will be smaller but the risk of breakage is higher.

Can you explain why do you believe that?

> Also 3.6.7 now has
> been tested in sid for almost two months now. 

Ack.

>> You bumped the debhelper compat level. That isn't a change we find
>> acceptable during the freeze.
> 
> I will immediately revert this if it helps.

I don't have enough experience yet with reviewing unblocks, that I feel
comfortable reviewing and unblocking the current package, so if your
insisting on the whole, somebody else will have to do the review. I am
sure this revert will be a requirement though.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#929262: libv4l-dev: pac207 cam(s) give frame decode errors

2019-05-20 Thread folkert
Hi,

> I strongly recommend that you buy a new webcam. This is ancient hardware.
> Even the cheapest UVC webcams you can buy today will have far better
> quality than a pac207. If you really, really need this to work, then I
> need the full dmesg output and you also need to check if you can reproduce
> this issue with the v4l2-ctl command:
> 
> v4l2-ctl -d /dev/videoX --stream-mmap
> (it keeps capturing frames until you press ctrl-X)

v4l2-ctl:
- raspberry pi 2 and 3b+: fail
- laptop: ok for at least a few minutes


> I should have one of these webcams, but won't be able to test until next
> week.

Thanks but it looks to be a raspberry pi problem.



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

2019-05-20 Thread Philipp Huebner
Hi,

I just ran into this very same issue.

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

Sounds good to me, I would like to see this fixed soon and can offer to
test fixed d-i images.


Best wishes,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature


Bug#929216: RM: algotutor/0.8.6-2

2019-05-20 Thread Paul Gevers
Hi Georges,

On 19-05-2019 12:22, Georges Khaznadar wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> Unmaintained upstream, not usable inside debian/buster, low popcon

I notice you are the maintainer. You don't have any bugs against this
package, so what makes it unusable, i.e. what is the problem of shipping
this with buster? Do you really only want it out of buster, or removed
from Debian unstable as well? In the later case, this bug should be
reassigned to the ftp.debian.org pseudo package.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928227: unblock: golang-golang-x-net-dev/1:0.0+git20181201.351d144+dfsg-3

2019-05-20 Thread Shengjing Zhu
On Tue, May 21, 2019 at 2:53 AM Paul Gevers  wrote:
[...]
> At this moment it's best to make unstable in line
> with testing again.

I could start to do this, but it would take some time.

> > 2. more packages need rebuild
>
> I don't understand why you say that. Only the reverse build dependencies
> of golang-golang-x-net-dev need to be rebuild and migrate to testing,
> no? That the packages in unstable aren't all build with the sources in
> unstable is normal right, so no big deal.

A Build-Depends golang-golang-x-net-dev and B;
B is divaricated in unstable and testing.

To make A migrate to testing after rebuilding in unstable, B needs
updating(revert), otherwise it is blocked by B.
Then B is updated and migrates to testing, now every package
Build-Depends B needs rebuilding, for out-dated Build-Using reason.

So eventually the rebuild set is {golang-golang-x-net-dev's reverse
Build-Depends, B's reverse Build-Depends}.
And this set is stable only when all Go related packages in unstable
and testing are aligned.

-- 
Shengjing Zhu



Bug#929282: efax-gtk FTCBFS: broken, outdated, embedded copy of PKG_CHECK_MODULES

2019-05-20 Thread Helmut Grohne
Source: efax-gtk
Version: 3.2.8-2.1
User: helm...@debian.org
Usertags: rebootstrap

efax-gtk fails to cross build from source, because it uses a broken,
outdated, embedded copy of PKG_CHECK_MODULES (shipped in acinclude.m4).
Please remove this copy and use the (fixed) system copy instead. Failing
that, please update your copy and register it with the security tracker.
This bug comes without a patch, because the actual bug is already fixed
in pkg-config. You just happen to have a copy of the bug.

Helmut



Bug#888733: hyantesite: test failures on most architectures

2019-05-20 Thread Rebecca N. Palmer

On 19/05/2019 18:15, Andreas Tille wrote:

So what is the plan to fix this bug?  Create new references to craft
a valid test or ignore these tests?


...or decide that something that's abandoned and doesn't follow its 
documentation (even after the above fixes) doesn't belong in Debian 
stable and let it be removed?  I have no strong opinion.


The above fix was written as part of an attempt to find fixes for all RC 
bugs in debian-science testing; I hadn't heard of the package before 
seeing this bug.




Bug#928026: Bug#928227: technical solutions enabling binNMUs in the security archive (support of golang packages)

2019-05-20 Thread Paul Gevers
Hi Ansgar,

On 20-05-2019 09:06, Ansgar wrote:
> I though about importing the full source to security-master already for
> a different reason: `Built-Using` leads to a similar problem as binNMUs
> in that uploads require source that is not already present in the
> archive.
> 
> It is not necessary to push all sources to the public mirrors.

Does this mean you think it is feasible to do/fix this in the near future?

>> Another solution already raised by Shengjing is to merge the archives. I
>> *guess* that is undesirable due to the fact that the security archive
>> often has embargoed sources and binaries. Am I right there?
> 
> That doesn't work as dak doesn't try to keep secrets.  There are various
> ways information would be leaked about embargoed issues (mails,
> database, web interface (rmadison), ...).
> 
> I personally also don't find it too bad to have a fallback: if one of
> the hosts is broken at the same time we have to release a critical
> update, we can still do so by publishing via the "wrong" archive.

Regarding my other direction with wanna-build, I learned yesterday via
another bug (#894441 binNMUs should be replaced by easy no-change
uploads) that wanna-build is not in the place to fix this because
uploads need to be signed.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928227: unblock: golang-golang-x-net-dev/1:0.0+git20181201.351d144+dfsg-3

2019-05-20 Thread Paul Gevers
Hi Shengjing,

On 19-05-2019 17:01, Shengjing Zhu wrote:
> On Sun, May 19, 2019 at 4:06 AM Paul Gevers  wrote:
>> On 18-05-2019 17:10, Shengjing Zhu wrote:
>>> On Sat, May 18, 2019 at 10:53 PM Paul Gevers  wrote:
>>> I'm sure most packages can't migrate to testing after binNMU in unstable.
>>> like etcd, nomad, snapd, umoci... which build-depends
>>> golang-golang-x-sys and/or golang-github-mattn-go-isatty(which are
>>> updated in unstable unexpectedly).
>>
>> Can those packages be reverted to have the content of buster, e.g. with
>> a +really version? Than we can schedule the binNMU's in unstable and
>> have them migrate with these changelog only change packages.
>>
> 
> This could cause another mess. Since we are close to buster release, I
> hope this can be avoid...

I fear this is part of the problem of the static linking in combination
with the freeze. Without major changes to the Debian infrastructure, the
golang ecosystem really needs to refrain from updating in unstable
during the freeze. At this moment it's best to make unstable in line
with testing again.

> 1. I'm not sure how many golang dev packages started a "trasition" in 
> unstable,
> 
> ```
> zhsj@coccia:~$ cat golang-divarication.sql

[...]

> (And please take another note that some leaf/binary packages, like
> hugo, influxdb, mtail.. already uploaded new version in unstable...)

They will need to be reverted as well if I understand correctly.

> 2. more packages need rebuild

I don't understand why you say that. Only the reverse build dependencies
of golang-golang-x-net-dev need to be rebuild and migrate to testing,
no? That the packages in unstable aren't all build with the sources in
unstable is normal right, so no big deal.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928406: [Pkg-matrix-maintainers] Bug#928406: revolt fails to show me the terms and conditions (doesn't have browsing tabs)

2019-05-20 Thread Hubert Chathi
forwarded 928406 https://github.com/aperezdc/revolt/issues/91
thanks

On Fri, 03 May 2019 16:50:15 -0400, Daniel Kahn Gillmor 
 said:

> I'm experimenting with revolt with a new account hosted on matrix.org.

> when i tried to chat with a different user, and the webapp shows me a
> dialog box about needing to agree to the terms and service.  When i
> click the button to do so, nothing happens.

This seems to have been reported by another user in the upstream bug
tracker.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368



Bug#924554: Bug#928108: unblock: unattended-upgrades/1.12 ?

2019-05-20 Thread Paul Gevers
Hi Jan, Bálint,

On 20-05-2019 09:02, Jan Wagner wrote:
> Am 12.05.19 um 12:41 schrieb Jan Wagner:
>>>* Skip sending email when no package had to be installed, upgraded
>> or removed
>>>  (LP: #1821103) (Closes: #924554)
>> I'm still considering this as a regression and thus RC.
> 
> DO we need to change severity to RC to get that fixed in buster?!?
> 
> Anyway, any statement from your side would be a beginning.

Sorry. The amount of changes that you propose to review is intimidating.
If you can prepare a targeted fix, that would be *much* appreciated by
us and much more likely end in a successful review. The sentence "If
omitting some of the fixes is desired please state which ones can go in
and which ones can't" probably achieved the opposite of what was wanted.
It's hard for us to make that call.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#929281: Buser install failure on Dell M610

2019-05-20 Thread Eli V
Package: installation-reports

Boot method: USB stick
Image version: debian-buster-DI-rc1-amd64-netinst.iso
Date: 2019-05-20

Machine: Dell M610
Processor: Duel Intel Xeon X5650
Memory: 96GB
Partitions: df -Tl
Filesystem  Type 1K-blocksUsed Available Use% Mounted on
udevdevtmpfs  49482952   0  49482952   0% /dev
tmpfs   tmpfs  98989529152   9889800   1% /run
/dev/mapper/os-root ext4   7622824 3358632   3857256  47% /
tmpfs   tmpfs 49494744   0  49494744   0% /dev/shm
tmpfs   tmpfs 5120   0  5120   0% /run/lock
tmpfs   tmpfs 49494744   0  49494744   0% /sys/fs/cgroup
/dev/sda2   ext2189403   37693149755  21% /boot
/dev/mapper/os-var  ext4   2817056  812544   1841696  31% /var
/dev/mapper/os-tmp  ext4 565598416   73760 559840024   1% /tmp
/dev/sda1   vfat486456 144486312   1% /boot/efi
tmpfs   tmpfs  9898948   0   9898948   0% /run/user/0


Output of lspci -knn (or lspci -nn): lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation 5500 I/O Hub to ESI Port
[8086:3403] (rev 13)
00:01.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI
Express Root Port 1 [8086:3408] (rev 13)
00:07.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI
Express Root Port 7 [8086:340e] (rev 13)
00:09.0 PCI bridge [0604]: Intel Corporation 7500/5520/5500/X58 I/O
Hub PCI Express Root Port 9 [8086:3410] (rev 13)
00:14.0 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub
System Management Registers [8086:342e] (rev 13)
00:14.1 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub GPIO
and Scratch Pad Registers [8086:3422] (rev 13)
00:14.2 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub
Control Status and RAS Registers [8086:3423] (rev 13)
00:16.0 System peripheral [0880]: Intel Corporation 5520/5500/X58
Chipset QuickData Technology Device [8086:3430] (rev 13)
00:16.1 System peripheral [0880]: Intel Corporation 5520/5500/X58
Chipset QuickData Technology Device [8086:3431] (rev 13)
00:16.2 System peripheral [0880]: Intel Corporation 5520/5500/X58
Chipset QuickData Technology Device [8086:3432] (rev 13)
00:16.3 System peripheral [0880]: Intel Corporation 5520/5500/X58
Chipset QuickData Technology Device [8086:3433] (rev 13)
00:16.4 System peripheral [0880]: Intel Corporation 5520/5500/X58
Chipset QuickData Technology Device [8086:3429] (rev 13)
00:16.5 System peripheral [0880]: Intel Corporation 5520/5500/X58
Chipset QuickData Technology Device [8086:342a] (rev 13)
00:16.6 System peripheral [0880]: Intel Corporation 5520/5500/X58
Chipset QuickData Technology Device [8086:342b] (rev 13)
00:16.7 System peripheral [0880]: Intel Corporation 5520/5500/X58
Chipset QuickData Technology Device [8086:342c] (rev 13)
00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #4 [8086:2937] (rev 02)
00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #5 [8086:2938] (rev 02)
00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB2 EHCI Controller #2 [8086:293c] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 1 [8086:2940] (rev 02)
00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #1 [8086:2934] (rev 02)
00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #2 [8086:2935] (rev 02)
00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #3 [8086:2936] (rev 02)
00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB2 EHCI Controller #1 [8086:293a] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev 92)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC
Interface Controller [8086:2918] (rev 02)
00:1f.5 IDE interface [0101]: Intel Corporation 82801I (ICH9 Family) 2
port SATA Controller [IDE mode] [8086:2926] (rev 02)
01:00.0 Ethernet controller [0200]: Broadcom Limited NetXtreme II
BCM5709S Gigabit Ethernet [14e4:163a] (rev 20)
01:00.1 Ethernet controller [0200]: Broadcom Limited NetXtreme II
BCM5709S Gigabit Ethernet [14e4:163a] (rev 20)
02:00.0 SCSI storage controller [0100]: LSI Logic / Symbios Logic
SAS1068E PCI-Express Fusion-MPT SAS [1000:0058] (rev 08)
05:03.0 VGA compatible controller [0300]: Matrox Electronics Systems
Ltd. MGA G200eW WPCM450 [102b:0532] (rev 0a)
fe:00.0 Host bridge [0600]: Intel Corporation Xeon 5600 Series
QuickPath Architecture Generic Non-core Registers [8086:2c70] (rev 02)
fe:00.1 Host bridge [0600]: Intel Corporation Xeon 5600 Series
QuickPath Architecture System Address Decoder [8086:2d81] (rev 02)
fe:02.0 Host bridge [0600]: Intel Corporation Xeon 5600 Series QPI
Link 0 [8086:2d90] (rev 02)
fe:02.1 Host bridge [0600]: Intel Corporation Xeon 5600 Series QPI
Physical 0 [8086:2d91] 

Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated

2019-05-20 Thread Helmut Grohne
Hi Sebastian,

On Mon, May 20, 2019 at 06:51:57PM +0200, Sebastian Reichel wrote:
> Did you forgot to add the attachment? FWIW both changes are with me.

Yes, sorry. I intend to move foward with a "maintainer acknowledged NMU"
if you lack time for doing the upload.

Helmut
diff --minimal -Nru tt-rss-18.12+dfsg/debian/changelog 
tt-rss-18.12+dfsg/debian/changelog
--- tt-rss-18.12+dfsg/debian/changelog  2019-02-06 00:04:47.0 +0100
+++ tt-rss-18.12+dfsg/debian/changelog  2019-05-20 17:53:54.0 +0200
@@ -1,3 +1,11 @@
+tt-rss (18.12+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry pick JShrink PHP 7.3 compatibility patch. (Closes: #923661)
+  * Default to using syslog as log backend rather than sql.
+
+ -- Helmut Grohne   Mon, 20 May 2019 17:53:54 +0200
+
 tt-rss (18.12+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch 
tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch
--- tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch1970-01-01 
01:00:00.0 +0100
+++ tt-rss-18.12+dfsg/debian/patches/default_to_syslog.patch2019-05-20 
17:53:47.0 +0200
@@ -0,0 +1,11 @@
+--- tt-rss-18.12+dfsg.orig/config.php-dist
 tt-rss-18.12+dfsg/config.php-dist
+@@ -166,7 +166,7 @@
+   // Disabling auth_internal in this list would automatically disable
+   // reset password link on the login form.
+ 
+-  define('LOG_DESTINATION', 'sql');
++  define('LOG_DESTINATION', 'syslog');
+   // Error log destination to use. Possible values: sql (uses internal 
logging
+   // you can read in Preferences -> System), syslog - logs to system log.
+   // Setting this to blank uses PHP logging (usually to http server
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 
tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch
--- tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch   1970-01-01 
01:00:00.0 +0100
+++ tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch   2019-05-20 
17:49:53.0 +0200
@@ -0,0 +1,32 @@
+From 91105810dafedba0390608d7465abd602beb6410 Mon Sep 17 00:00:00 2001
+From: Sergei Morozov 
+Date: Fri, 14 Sep 2018 19:55:03 -0700
+Subject: [PATCH] Fixed test failures on PHP 7.3
+
+1. continue in break shoud target the while loop directly 
(php/php-src@04e3523).
+2. strpos() doesn't longer accept non-string needles 
(https://wiki.php.net/rfc/deprecations_php_7_3#string_search_functions_with_integer_needle).
+ src/JShrink/Minifier.php | 4 ++--
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/JShrink/Minifier.php b/src/JShrink/Minifier.php
+index 8103452..ad8157f 100644
+--- a/vendor/JShrink/Minifier.php
 b/vendor/JShrink/Minifier.php
+@@ -183,7 +183,7 @@ protected function loop()
+ // new lines
+ case "\n":
+ // if the next line is something that can't stand alone 
preserve the newline
+-if (strpos('(-+{[@', $this->b) !== false) {
++if ($this->b !== false && strpos('(-+{[@', $this->b) !== 
false) {
+ echo $this->a;
+ $this->saveString();
+ break;
+@@ -231,7 +231,7 @@ protected function loop()
+ // check for some regex that breaks stuff
+ if ($this->a === '/' && ($this->b === '\'' || 
$this->b === '"')) {
+ $this->saveRegex();
+-continue;
++continue 3;
+ }
+ 
+ echo $this->a;
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/series 
tt-rss-18.12+dfsg/debian/patches/series
--- tt-rss-18.12+dfsg/debian/patches/series 2019-02-06 00:04:47.0 
+0100
+++ tt-rss-18.12+dfsg/debian/patches/series 2019-05-20 17:52:00.0 
+0200
@@ -1,3 +1,5 @@
 config.php-dist.patch
 remove-tt-rss-layer.patch
 fix-db-updater-script.patch
+jshrink_php7.3_fix.patch
+default_to_syslog.patch


Bug#924425: Patch

2019-05-20 Thread Michael Barkdoll
Ubuntu patched this, can Debian as well?  Package maintainer has been
unresponsive.

https://bugs.launchpad.net/debian/+source/libnfsidmap/+bug/1819197

Michael Barkdoll


Bug#929162: randtype FTCBFS: does not pass cross tools to make

2019-05-20 Thread Eugene V. Lyubimkin
Hello Helmut,

Helmut Grohne kirjoitti 18.5.2019 klo 14.11:
> randtype fails to cross build from source, because it does not pass
> cross tools to make. The easiest way of doing so - using dh_auto_build -
> makes randtype cross buildable. Please consider applying the attached
> patch.

Thank you for the patch, it looks good. I'll apply it in the next upload,
likely post-freeze.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer



Bug#929280: linux-image-4.19.0-5-powerpc-smp: warning when loading ecdh_generic: "alg: ecdh: Party A: generate public key test failed. Invalid output"

2019-05-20 Thread Daniel Kahn Gillmor
Package: src:linux
Version: 4.19.37-3
Severity: normal
Control: found -1 5.0.2-1~exp1

If, on this 32-bit powerpc machine, i do:

# modprobe -v ecdh_generic

then the kernel produces two lines of output:

alg: ecdh: Party A: generate public key test failed. Invalid output
alg: ecdh: test failed on vector 1, err=-22

This also happens on kernel 5.0.2-1~exp1 
(from linux-image-5.0.0-trunk-powerpc-smp).

I'm happy to run more tests on this machine if it would be useful.

fwiw, this report seems to come from crypto/testmgr.c

--dkg

-- Package-specific info:
** Version:
Linux version 4.19.0-5-powerpc-smp (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/boot/vmlinux-4.19.0-5-powerpc-smp root=/dev/mapper/vg_tyr0-root ro 
quiet radeon.modeset=1 video=radeonfb:off radeon.agpmode=1 init=/bin/systemd

** Not tainted

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

** Model information
revision: 1.2 (pvr 8003 0102)
platform: PowerMac
model   : PowerBook5,7
machine : PowerBook5,7
motherboard : PowerBook5,7 MacRISC3 Power Macintosh 
Device Tree model: PowerBook5,7

** Loaded modules:
ecdh_generic
uinput
binfmt_misc
hfs
arc4
b43
radeon
bcma
mac80211
ttm
drm_kms_helper
joydev
cfg80211
drm
rfkill
rng_core
drm_panel_orientation_quirks
yenta_socket
syscopyarea
appletouch
sysfillrect
sysimgblt
fb_sys_fops
evdev
pcmcia_rsrc
sg
rack_meter
therm_adt746x
snd_powermac
snd_pcm
snd_timer
snd
soundcore
loop
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
hid_apple
hid_generic
usbhid
hid
dm_mod
firewire_ohci
firewire_core
sungem
sungem_phy
crc_itu_t
sd_mod
ohci_pci
ehci_pci
ohci_hcd
ehci_hcd
usbcore
ssb
sr_mod
cdrom
usb_common
mmc_core
pcmcia
pcmcia_core

** PCI devices:
:00:0b.0 Host bridge [0600]: Apple Inc. UniNorth 2 AGP [106b:0034]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: agpgart-uninorth

:00:10.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] RV350/M10 / RV360/M11 [Mobility Radeon 9600 (PRO) / 9700] [1002:4e50] 
(prog-if 00 [VGA controller])
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RV350/M10 / RV360/M11 
[Mobility Radeon 9600 (PRO) / 9700] [1002:4e50]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: radeon
Kernel modules: radeonfb, radeon

0001:10:0b.0 Host bridge [0600]: Apple Inc. UniNorth 2 PCI [106b:0035]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- 
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb

0001:10:13.0 CardBus bridge [0607]: Texas Instruments PCI1510 PC card Cardbus 
Controller [104c:ac56]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
Capabilities: 
Kernel driver in use: yenta_cardbus
Kernel modules: yenta_socket

0001:10:17.0 Unassigned class [ff00]: Apple Inc. KeyLargo/Intrepid Mac I/O 
[106b:003e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

0001:10:1b.1 USB controller [0c03]: NEC Corporation OHCI USB Controller 
[1033:0035] (rev 43) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB Controller [1033:0035]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

0001:10:1b.2 USB controller [0c03]: NEC Corporation uPD72010x USB 2.0 
Controller [1033:00e0] (rev 04) (prog-if 20 [EHCI])
Subsystem: NEC Corporation uPD72010x USB 2.0 Controller [1033:00e0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

0002:24:0b.0 Host bridge [0600]: Apple Inc. UniNorth 2 Internal PCI [106b:0036]

Bug#905309: nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing

2019-05-20 Thread Dr. Larry D. Pyeatt
I am experiencing this bug with nvidia driver 418.56 on Gentoo.



Bug#929279: libmspack0: Request Buster freeze exception

2019-05-20 Thread David Palacio
Package: libmspack0
Version: 0.8-1
Severity: important

The current version available in testing of libmspack0 makes it unusable for
winetricks users because of bug #912687 (solved in unstable). I request that an
exception is made so that this package may migrate from unstable to testing.



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

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

Versions of packages libmspack0 depends on:
ii  libc6  2.28-10

libmspack0 recommends no packages.

libmspack0 suggests no packages.

-- no debconf information



Bug#886679: ITA: coccinelle -- semantic patching tool for C

2019-05-20 Thread eamanu15 .
Hello Євгеній,

I am working on the ITA coccinelle.
I will need permission on salsa to work on the package. I will write to the
team.
I am having some problems building the package :

dwz: Error mmapping multi-file temporary files
dh_dwz: dwz -q
-mdebian/coccinelle/usr/lib/debug/.dwz/x86_64-linux-gnu/coccinelle.debug
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/coccinelle.debug --
debian/coccinelle/usr/bin/spatch debian/coccinelle/usr/bin/spgen returned
exit code 1
make: *** [debian/rules:20: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -I -i.git/ -I.git failed
gbp:error: 'env QUILT_PATCHES=debian/patches quilt push -a; debuild
-i\.git/ -I.git' failed: it exited with 29

Do you had this problem?

Regards

-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest


Bug#929182: fluidsynth: no sound by default - soundfont location doesn't exist

2019-05-20 Thread Tim Colgate
On Monday, 20 May 2019 07:50:06 BST you wrote:
> According to the man page, you may give the soundfont on the command line.
> There is  even an example in the third paragraph: 'fluidsynth -ni
> soundfont.sf2 midifile1.mid midifile2.mid'
> 
> So, this is the "official" way of starting fluidsynth with a specific
> soundfont. 

I'm aware of the commandline option for specifying the soundfont, but wanted 
something that works out-of the-box and for all users. A global alias or a 
wrapper script would work in most cases, but wouldn't be linked to Debian 
updates so would need to be maintained separately if the soundfont name changed.

A similar issue was raised on the fluidity github a while ago, and a patch was 
even put forward, but was abandoned:
https://github.com/FluidSynth/fluidsynth/issues/453
https://github.com/FluidSynth/fluidsynth/pull/454

I haven't checked newer versions of fluidity to see if they work differently.

> Nevertheless, if /usr/share/soundfonts/default.sf2 is the
> hard-coded fallback, we should make sure this file can be found out-of
> the-box. Adding the packaged soundfonts to a set of alternatives might be
> a good idea to solve this.

I raised a similar issue about default soundfount with gstreamer. I hope it's 
possible to come up with a common approach in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929185


Bug#923930: testsuite comes with built-in time-bomb

2019-05-20 Thread Giovanni Mascellani
Hi,

On Sun, 7 Apr 2019 16:46:01 +0200 Andreas Henriksson 
wrote:
> The lazy solution here is to argue that we don't want time-bombs and
> just disable the test-suite. The better solution involves generating
> the certificates so that they align with what 32bit machines can handle,
> uuencoding the result and setting up debian/rules handling to "manually
> patch" the build.

It has to be decided whether the issue, Debian-wise, is the FTBFS or the
fact that heimdal does not properly handle dates beyond 2038 in 32 bit
archs. I do not have hard data, but I believe that sometimes CAs set
their expiration dates even decades in the future, so not verifying
certificates expiring after 2038 might be an issue right now, and even
more probably the buster's EOL.

If we ignore this and just consider the bug as FTBFS, then it is easy to
patch the package to that failing tests are ignored under 32 bit archs.
Otherwise, the patch might be more complicated; I prodded upstream on
the GitHub issue to understand their intentions.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature


Bug#929270: description uses "Golang" instead of "Go"

2019-05-20 Thread Dawid Dziurla
Change commited[1].

[1] 
https://salsa.debian.org/go-team/packages/termshark/commit/49ce3a14377411a0169c9949171f84cd83a669a2

pon., 20 maj 2019 o 15:08 Marvin Renich  napisał(a):
>
> Package: termshark
> Version: 1.0.0-1
> Severity: normal
>
> The package description says "Written in Golang".  The correct name of
> that computer language is "Go".  golang.org is the domain name where the
> official website is hosted, but that is not the name of the language.
>
> ...Marvin
>



Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH

2019-05-20 Thread Noah Meyerhans
On Mon, May 20, 2019 at 11:26:00AM +0200, Jorge Barata González wrote:
>Vagrant image debian/stretch64 v9.6.0
>/usr/sbin is not included by default in $PATH
> 
>```
>vagrant@stretch:~$ service
>-bash: service: command not found
>vagrant@stretch:~$ /usr/sbin/service
>Usage: service < option > | --status-all | [ service_name [ command |
>--full-restart ] ]
>vagrant@stretch:~$ echo $PATH
>/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
>```

That path is set from /etc/profile, which is not modified by the vagrant
images from the default that Debian installs. /usr/sbin is not in the
default PATH in Debian normally.

If you want to discuss changing this project-wide, we could certainly do
so, but that would be quite a bit broader in scope than
cloud.debian.org.

noah



Bug#918171: Broken with Thunderbird 60

2019-05-20 Thread Daniel Baumann
Hi Moritz,

sorry for the late response, your mail slipped through the cracks on my
end.. :(

re adoption: removal request sounds fine, I currently have not enough
time to take on more packages in Debian.

Regards,
Daniel



Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated

2019-05-20 Thread Sebastian Reichel
Hi,

On Mon, May 20, 2019 at 05:59:05PM +0200, Helmut Grohne wrote:
> Control: tags -1 + patch
> 
> Hi Sebastian and Marcelo,
> 
> On Sat, May 11, 2019 at 10:41:48AM +0200, Stefan Fritsch wrote:
> > Yes, using the Minifier.php from the above commit fixes the issue (and
> > another php warning that appeared in apache error log). In order to test it,
> > one needs to delete the files from /var/cache/tt-rss/js/* first, or the
> > minifier won't be called again.
> 
> Thank you, Stefan.
> 
> I've attached a .debdiff that fixes jshrink and changes the default log
> destination to syslog (as this avoids the other bug). What do you think?
> Only fix the jshrink part? Do both?

Did you forgot to add the attachment? FWIW both changes are with me.

-- Sebastian


signature.asc
Description: PGP signature


Bug#929278: vlc: Typo in man page: dashes

2019-05-20 Thread annadane
Package: src:vlc
Version: 3.0.6-0+deb9u1
Severity: minor

Dear Maintainer,

The man page for vlc says, under "options":

"VLC follows the usual GNU command line syntax, with long options start‐
   ing  with  two  dashes  (`-')."

This should, obviously, read "two dashes ('--')".

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA:en 
(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.25
ii  vlc-bin  3.0.6-0+deb9u1
ii  vlc-l10n 3.0.6-0+deb9u1
ii  vlc-plugin-base  3.0.6-0+deb9u1
ii  vlc-plugin-qt3.0.6-0+deb9u1
ii  vlc-plugin-video-output  3.0.6-0+deb9u1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  3.0.6-0+deb9u1
ii  vlc-plugin-samba   3.0.6-0+deb9u1
ii  vlc-plugin-skins2  3.0.6-0+deb9u1
ii  vlc-plugin-video-splitter  3.0.6-0+deb9u1
ii  vlc-plugin-visualization   3.0.6-0+deb9u1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.24-11+deb9u4
ii  libvlc5  3.0.6-0+deb9u1

Versions of packages libvlc5 depends on:
ii  dpkg 1.18.25
ii  libc62.24-11+deb9u4
ii  libvlccore9  3.0.6-0+deb9u1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.6-0+deb9u1

Versions of packages vlc-bin depends on:
ii  libc6   2.24-11+deb9u4
ii  libvlc-bin  3.0.6-0+deb9u1
ii  libvlc5 3.0.6-0+deb9u1

Versions of packages vlc-plugin-base depends on:
ii  dpkg 1.18.25
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-2+deb9u1
ii  libasound2   1.1.3-5
ii  libass5  1: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  libavcodec57 7:3.2.12-1~deb9u1
ii  libavformat577:3.2.12-1~deb9u1
ii  libavutil55  7:3.2.12-1~deb9u1
ii  libbasicusageenvironment12016.11.28-1+deb9u2
ii  libbluray1   1:0.9.3-3
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libcddb2 1.3.2-5
ii  libchromaprint1  1.4.2-1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.5-10
ii  libdvbpsi10  1.3.0-5
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.4-1
ii  libfaad2 2.8.0~cvs20161113-1+deb9u1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libfribidi0  0.19.7-1+b1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgcrypt20  1.7.6-2+deb9u3
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u4
ii  libgpg-error01.26-2
ii  libgroupsock82016.11.28-1+deb9u2
ii  libharfbuzz0b1.4.2-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.9.4c-9
ii  liblivemedia57   2016.11.28-1+deb9u2
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8+deb9u1
ii  libmatroska6v5   1.4.5-2
ii  libmicrodns0 0.0.3-3
ii  libmpcdec6   2:0.1~r495-1+b1
ii  libmpeg2-4   0.5.1-7+b2
ii  libmpg123-0  1.23.8-1+b1
ii  libmtp9  1.1.13-1
ii  libncursesw5 6.0+20161126-1+deb9u2
ii  libnfs8  1.11.0-2
ii  libogg0  1.3.2-1
ii  libopenmpt-modplug1  0.2.7386~beta20.3-3+deb9u3
ii  libopus0 1.2~alpha2-1
ii  libpng16-16  1.6.28-1+deb9u1
ii  libpostproc547:3.2.12-1~deb9u1
ii  libprotobuf-lite10   3.0.0-9
ii  libpulse010.0-1+deb9u1
ii  libraw1394-112.1.2-1+b1
ii  libresid-builder0c2a 2.1.1-15
ii  

Bug#928230: marked as pending in mariadb-10.3

2019-05-20 Thread Gregor Riepl
> Bug #928230 in mariadb-10.3 reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:

Are you going to do an upload for buster, or is this postponed until after
buster becomes stable?

If possible, I'd like to see this patch go into buster, so we may still be
able to sneak amarok back in.



Bug#712099: appears a feature not a bug

2019-05-20 Thread Ilguiz Latypov
I contacted the author and he pointed to the "-a" option that controls
the search behaviour.  I found the "-A" option to follow my expectation
of a forward and backward search,

   -a or --search-skip-screen
  By default, forward searches start at the top of the displayed
  screen and backwards searches start at the bottom of the
  displayed screen (except for repeated searches invoked by the n
  or N commands, which start after or before the "target" line
  respectively; see the -j op‐ tion for more about the target
  line).  The -a option causes forward searches to instead start at
  the bottom of the  screen and  backward searches to start at the
  top of the screen, thus skipping all lines displayed on the
  screen.

   -A or --SEARCH-SKIP-SCREEN
  Causes  all forward searches (not just non-repeated searches) to
  start just after the target line, and all backward searches to
  start just before the target line.  Thus, forward searches will
  skip part of the displayed screen (from the first line up to and
  including the target line).  Similarly backwards searches will
  skip the displayed screen from the last line up to and including
  the target line.  This was the default behavior in less versions
  prior to 441.

I don't understand why the default behaviour needed to change.

-- 



Bug#929277: elastalert: Does not build twice in a row

2019-05-20 Thread Santiago Vila
Package: src:elastalert
Version: 0.2.0b2-1
Tags: patch

Dear maintainer:

This package does not build twice in a row. Way to reproduce:

dpkg-buildpackage -uc -us
dpkg-buildpackage -uc -us

This is what will happen the second time:

dpkg-source: info: local changes detected, the modified files are:
 elastalert-0.2.0b2/.pytest_cache/README.md
 elastalert-0.2.0b2/.pytest_cache/v/cache/nodeids
 elastalert-0.2.0b2/.pytest_cache/v/cache/stepwise

Proposed patch below.

Note: This change was already in the package I put in people.debian.org.
Apparently, I forgot to document that it was required to be able to
build twice in a row.

Thanks.

--- a/debian/rules
+++ b/debian/rules
@@ -11,3 +11,6 @@ override_dh_auto_build:
dh_auto_build
PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml 
docs/source build/html # HTML generator
 
+override_dh_auto_clean:
+   dh_auto_clean
+   rm -rf .pytest_cache



Bug#927304: unblock: aptly/1.3.0+ds1-2.2

2019-05-20 Thread Shengjing Zhu
Control: tags -1 - moreinfo

On Sun, May 12, 2019 at 1:42 AM Jonathan Wiltshire  wrote:
> Please go ahead but use version 1.3.0+ds1-2.2~deb10u1 since this is
> backport of something in unstable, not a divergence of testing.
>

Sorry for the delay, it has been uploaded and built on all release
architectures.

--
Shengjing Zhu



Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated

2019-05-20 Thread Helmut Grohne
Control: tags -1 + patch

Hi Sebastian and Marcelo,

On Sat, May 11, 2019 at 10:41:48AM +0200, Stefan Fritsch wrote:
> Yes, using the Minifier.php from the above commit fixes the issue (and
> another php warning that appeared in apache error log). In order to test it,
> one needs to delete the files from /var/cache/tt-rss/js/* first, or the
> minifier won't be called again.

Thank you, Stefan.

I've attached a .debdiff that fixes jshrink and changes the default log
destination to syslog (as this avoids the other bug). What do you think?
Only fix the jshrink part? Do both?

Helmut



Bug#856234: upstream patch

2019-05-20 Thread Frédéric Bonnard
Please ignore fix-923592.patch in the previous message.

F.
Description: Fix FTBFS due to missing comment/description
 After that commit https://phabricator.kde.org/D16867, a description is
needed in .desktop files.
The keyword actually looked for by desktoptojson converter utility is
"Comment=" .

Author: Frédéric Bonnard 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: marble-17.08.3/src/plasma/wallpapers/worldmap/metadata.desktop
===
--- marble-17.08.3.orig/src/plasma/wallpapers/worldmap/metadata.desktop 
2017-10-20 03:52:49.0 +
+++ marble-17.08.3/src/plasma/wallpapers/worldmap/metadata.desktop  
2019-04-24 15:10:53.251732393 +
@@ -23,6 +23,7 @@
 Name[x-test]=xxWorld Mapxx
 Name[zh_CN]=世界地图
 Name[zh_TW]=世界地圖
+Comment=Shows a map of the world as wallpaper
 Type=Service
 Icon=marble
 
Index: marble-17.08.3/src/plasma/applets/worldclock/package/metadata.desktop
===
--- marble-17.08.3.orig/src/plasma/applets/worldclock/package/metadata.desktop  
2017-10-20 03:52:49.0 +
+++ marble-17.08.3/src/plasma/applets/worldclock/package/metadata.desktop   
2019-04-24 15:09:41.781959847 +
@@ -49,7 +49,7 @@
 Name[x-test]=xxWorld Clockxx
 Name[zh_CN]=世界时钟
 Name[zh_TW]=世界時鐘
-# not yet... Comment=Shows the time in different parts of the world
+Comment=Shows the time in different parts of the world
 
 Icon=marble
 Type=Service


pgpP6wOqNfX7o.pgp
Description: PGP signature


Bug#856234: upstream patch

2019-05-20 Thread Frédéric Bonnard
Control: tags -1 patch
Control: forwarded -1 https://github.com/GaloisInc/cryptol/issues/542

--

Hi,

Adrian opened a bug upstream about this issue : 
https://github.com/GaloisInc/cryptol/issues/542
Upstream committed a fix as Edmund explained : 
https://github.com/GaloisInc/cryptol/commit/3caa3a8e829ed2ce23cb1a734ecf37f4e74de659
I understand it's done a bit differently than what Adrian proposed.
At least, it compiles on ppc64el.

Regards,


F.
Description: Fix FTBFS due to missing comment/description
 After that commit https://phabricator.kde.org/D16867, a description is
needed in .desktop files.
The keyword actually looked for by desktoptojson converter utility is
"Comment=" .

Author: Frédéric Bonnard 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: marble-17.08.3/src/plasma/wallpapers/worldmap/metadata.desktop
===
--- marble-17.08.3.orig/src/plasma/wallpapers/worldmap/metadata.desktop 
2017-10-20 03:52:49.0 +
+++ marble-17.08.3/src/plasma/wallpapers/worldmap/metadata.desktop  
2019-04-24 15:10:53.251732393 +
@@ -23,6 +23,7 @@
 Name[x-test]=xxWorld Mapxx
 Name[zh_CN]=世界地图
 Name[zh_TW]=世界地圖
+Comment=Shows a map of the world as wallpaper
 Type=Service
 Icon=marble
 
Index: marble-17.08.3/src/plasma/applets/worldclock/package/metadata.desktop
===
--- marble-17.08.3.orig/src/plasma/applets/worldclock/package/metadata.desktop  
2017-10-20 03:52:49.0 +
+++ marble-17.08.3/src/plasma/applets/worldclock/package/metadata.desktop   
2019-04-24 15:09:41.781959847 +
@@ -49,7 +49,7 @@
 Name[x-test]=xxWorld Clockxx
 Name[zh_CN]=世界时钟
 Name[zh_TW]=世界時鐘
-# not yet... Comment=Shows the time in different parts of the world
+Comment=Shows the time in different parts of the world
 
 Icon=marble
 Type=Service


pgp1PCDihfMw3.pgp
Description: PGP signature


Bug#929276: remem FTCBFS: configures for the build architecture

2019-05-20 Thread Helmut Grohne
Source: remem
Version: 2.12-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

remem fails to cross build from source, because it does not pass --host
to ./configure. The easiest way of doing so - using dh_auto_configure -
makes remem cross buildable. Please consider applying the attached
patch.

Helmut
diff -u remem-2.12/debian/rules remem-2.12/debian/rules
--- remem-2.12/debian/rules
+++ remem-2.12/debian/rules
@@ -4,7 +4,7 @@
 
 build:
dh_testdir
-   ./configure --mandir='$${prefix}/share/man' --prefix='/usr' \
+   dh_auto_configure -- \
--with-lispdir='/usr/share/emacs/site-lisp'
make
touch build
diff -u remem-2.12/debian/control remem-2.12/debian/control
--- remem-2.12/debian/control
+++ remem-2.12/debian/control
@@ -2,7 +2,7 @@
 Section: misc
 Priority: optional
 Maintainer: Javier Fernandez-Sanguino Pen~a 
-Build-Depends: debhelper (>= 4.1.16), libpcre3-dev, flex, po-debconf
+Build-Depends: debhelper (>= 7), libpcre3-dev, flex, po-debconf
 Standards-Version: 3.7.2
 Homepage: http://www.remem.org
 
diff -u remem-2.12/debian/changelog remem-2.12/debian/changelog
--- remem-2.12/debian/changelog
+++ remem-2.12/debian/changelog
@@ -1,3 +1,10 @@
+remem (2.12-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 20 May 2019 17:15:40 +0200
+
 remem (2.12-7) unstable; urgency=low
 
   * Po-debconf translation updates:


Bug#929275: minimap2 FTBFS on armhf and arm64

2019-05-20 Thread Helmut Grohne
Source: minimap2
Version: 2.15+dfsg-1
Severity: important
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

minimap2 fails to build from source on armhf and arm64 due to supplying
-msse2. Unlike many other architectures, this is easily fixable for
armhf and arm64 using the attached patch. Please consider applying it.

Helmut
diff --minimal -Nru minimap2-2.15+dfsg/debian/changelog 
minimap2-2.15+dfsg/debian/changelog
--- minimap2-2.15+dfsg/debian/changelog 2019-01-11 22:40:39.0 +0100
+++ minimap2-2.15+dfsg/debian/changelog 2019-05-20 17:26:01.0 +0200
@@ -1,3 +1,10 @@
+minimap2 (2.15+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on armhf and arm64: pass relevant variable to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 20 May 2019 17:26:01 +0200
+
 minimap2 (2.15+dfsg-1) unstable; urgency=medium
 
   * New upstream version
diff --minimal -Nru minimap2-2.15+dfsg/debian/rules 
minimap2-2.15+dfsg/debian/rules
--- minimap2-2.15+dfsg/debian/rules 2019-01-11 22:40:39.0 +0100
+++ minimap2-2.15+dfsg/debian/rules 2019-05-20 17:26:01.0 +0200
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+include /usr/share/dpkg/architecture.mk
 
 %:
dh $@
@@ -9,8 +10,15 @@
dh_auto_clean
cd tex && make clean
 
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU)-$(DEB_HOST_ARCH_ABI),arm-eabihf 
arm64-base))
+build_vars += arm_neon=1
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU),arm64))
+build_vars += aarch64=1
+endif
+endif
+
 override_dh_auto_build:
-   dh_auto_build
+   dh_auto_build -- $(build_vars)
cd tex && make
 
 override_dh_auto_test:


Bug#929274: libzeep FTCBFS: does not pass cross tools to make

2019-05-20 Thread Helmut Grohne
Source: libzeep
Version: 3.0.2-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libzeep fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
almost fixes the build if it were not running strip directly. Doing so
not only breaks cross compilation, but also breaks
DEB_BUILD_OPTIONS=nostrip and generation of -dbgsym packages, so it is
best to remove the call. The attached patch fixes all of that. Please
consider applying it.

Helmut
diff --minimal -Nru libzeep-3.0.2/debian/changelog 
libzeep-3.0.2/debian/changelog
--- libzeep-3.0.2/debian/changelog  2018-10-26 08:07:31.0 +0200
+++ libzeep-3.0.2/debian/changelog  2019-05-20 17:36:30.0 +0200
@@ -1,3 +1,12 @@
+libzeep (3.0.2-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ nostrip.patch: Defer all stripping to dh_strip.
+
+ -- Helmut Grohne   Mon, 20 May 2019 17:36:30 +0200
+
 libzeep (3.0.2-7) unstable; urgency=medium
 
   [ Andreas Tille ]
diff --minimal -Nru libzeep-3.0.2/debian/patches/nostrip.diff 
libzeep-3.0.2/debian/patches/nostrip.diff
--- libzeep-3.0.2/debian/patches/nostrip.diff   1970-01-01 01:00:00.0 
+0100
+++ libzeep-3.0.2/debian/patches/nostrip.diff   2019-05-20 17:36:30.0 
+0200
@@ -0,0 +1,10 @@
+--- libzeep-3.0.2.orig/makefile
 libzeep-3.0.2/makefile
+@@ -78,7 +78,6 @@
+   install -d $(LIBDIR)
+   install $(LIB_NAME) $(LIBDIR)/$(LIB_NAME)
+   ln -Tfs $(LIB_NAME) $(LIBDIR)/$(SO_NAME)
+-  strip --strip-unneeded $(LIBDIR)/$(LIB_NAME)
+ 
+ install-dev:
+   install -d $(MANDIR) $(LIBDIR) $(INCDIR)/zeep/xml $(INCDIR)/zeep/http 
$(INCDIR)/zeep/http/webapp
diff --minimal -Nru libzeep-3.0.2/debian/patches/series 
libzeep-3.0.2/debian/patches/series
--- libzeep-3.0.2/debian/patches/series 2018-10-26 08:07:31.0 +0200
+++ libzeep-3.0.2/debian/patches/series 2019-05-20 17:36:30.0 +0200
@@ -5,3 +5,4 @@
 spelling.patch
 boost-1.65-compat.patch
 0007-Fix-for-Boost-version-1.67.patch
+nostrip.diff
diff --minimal -Nru libzeep-3.0.2/debian/rules libzeep-3.0.2/debian/rules
--- libzeep-3.0.2/debian/rules  2018-10-26 08:07:31.0 +0200
+++ libzeep-3.0.2/debian/rules  2019-05-20 17:36:29.0 +0200
@@ -8,7 +8,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) lib
+   dh_auto_build -- lib
 
 override_dh_auto_install:
$(MAKE) DESTDIR=$(CURDIR)/debian/libzeep3.0v5 install-libs


Bug#922061: Please package better ctop from https://github.com/bcicen/ctop

2019-05-20 Thread UAB "Bona Mens" paslaugos
It would be nice if better ctop from https://ctop.sh would be packaged in
Debian.
Why Debian maintainers still keep old, unmaintained ctop package instead
swtiching to better and active maintained implementation?

From: Antoine Beaupre 
Subject: unmaintained upstream, switch to other implementation

There are two "ctop" packages out there, this one, packaged in Debian:
https://github.com/yadutaf/ctop/

... and "ctop.sh", not yet packaged in Debian but occupying a similar
namespace:
https://ctop.sh/https://github.com/bcicen/ctop

>From what I understand, the latter is better maintained and less
confusig. The last commit on yadutaf's program date from 2017 and
there hasn't been an update of the Debian package since stretch, so I
wonder if we really want to ship it with buster or maybe replace it
with ctop.sh.


-- 

IT paslaugos įmonėms, prekyba kompiuteriais su Linux OS:
UAB „Bona Mens“  - http://bonamens.lt  http://tinklas.eu/prekyba
Tel.: +370-614-53085
Laisva programinė įranga verslui ir namams:http://baltix.lthttp://openoffice.lt


Bug#929034: evolvotron SEGV

2019-05-20 Thread Axel Beckert
Hi Jan,

what a pleasant surprise to hear from you and even with some very
helpful patch. Thanks!

Jan Nordholz wrote:
> I have tested that the program starts up now, but I have no time to
> test #1 as well.

Will test later this evening when I'm back home.

Thanks again!

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



Bug#929067: Support for MDS

2019-05-20 Thread Michael Tokarev

20.05.2019 16:07, Salvatore Bonaccorso wrote:

Hi

FTR, https://salsa.debian.org/qemu-team/qemu/merge_requests/6 for the
related changes in unstable (and to target buster).


Yeah, I comitted it the same day this issue popped up,
but forgot to push it (done now).

Thanks!

/mjt



Bug#929254: e2fsprogs: e2scrub cronjob spurious falure

2019-05-20 Thread Theodore Ts'o
merge 929186 929254
thanks

On Mon, May 20, 2019 at 04:53:29AM +0200, Marc Lehmann wrote:
> Package: e2fsprogs
> Version: 1.45.1-1
> Severity: normal
> 
> I just got this mail from cron:
> 
>So sorry, the automatic e2scrub of /db on host failed.
> 
>May 19 03:10:39 host systemd[1]: Starting Online ext4 Metadata Check for 
> /db...
>May 19 03:10:39 host e2scrub@-db[5246]: /db: Not connnected to a LVM 
> logical volume.
>May 19 03:10:39 host e2scrub@-db[5246]: Usage: /sbin/e2scrub [OPTIONS] 
> mountpoint | device

There is a fix coming soon; my apologies for this regression!

> (And, a very minor typo, it should be "an LVM", not "a LVM")

Good point, thanks.

- Ted



Bug#928141: "Pipe loop" errors in 1.6.5

2019-05-20 Thread Ondrej Zajicek
On Mon, May 20, 2019 at 04:19:32PM +0200, Marco d'Itri wrote:
> Do you want me to submit an unblock request for 1.6.6-1 on your behalf?
> I would hate to ship a broken package in the next stable.

Hi

Yes, if you could submit it, it would be glad.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."



Bug#923433: 0x51063B3: EncoderStrategy::Flush() (encoderstrategy.h:156)

2019-05-20 Thread Mathieu Malaterre
Gert,

On Mon, May 20, 2019 at 3:31 PM Andreas Tille  wrote:
>
> Hint, hint, hint: Feel free to do an NMU / team upload of RC buggy
> package.

What's your opinion on this ? Revert to charls 1.x as suggested or
investigated actual regression ?



Bug#844321: unison: Please update to latest upstream version

2019-05-20 Thread Stéphane Glondu
Le 20/05/2019 à 16:06, Christoph Groth a écrit :
> Unison 2.51.2 that has been released in January 2018 has a new feature
> that is very useful for synchronizing, for example, '.git' directories:
> 
>> Add a new preference, 'atomic', for specifying directories that should
>> be treated atomically.
> 
> It would be great to see this in Debian soon!

Indeed, this new feature looks interesting!

I will look into this when Buster is released.

Cheers,

-- 
Stéphane



Bug#929034: evolvotron SEGV

2019-05-20 Thread Jan Nordholz
Hi Abe,

if upstream doesn't respond fast enough, here's my contribution to the
bug hunt for this release cycle, I just had an hour to look through the
BTS.

This bug is a common problem when using STL containers (deleting the
element at the iterator).

The attached patch fixes the two critical cases (hunks #2 and #3, with
the crash backtrace belonging to the first of those) and one other
location (hunk #1) where upstream already noticed that there were
problems and creatively fixed it.

I have tested that the program starts up now, but I have no time to
test #1 as well.

Best regards!

Jan
Index: evolvotron-0.7.1/libevolvotron/mutatable_image_computer_farm.cpp
===
--- evolvotron-0.7.1.orig/libevolvotron/mutatable_image_computer_farm.cpp
+++ evolvotron-0.7.1/libevolvotron/mutatable_image_computer_farm.cpp
@@ -72,19 +72,20 @@ void MutatableImageComputerFarm::fasttra
 {
   QMutexLocker lock(&_mutex);
   
-  // \todo: Inefficient starting search again each time.  Some problem with erase otherwise though, but might have been task abort mem leak.
-  TodoQueue::iterator it;
-  while (
-	 (
-	  it=std::find_if(_todo.begin(),_todo.end(),predicate_aborted)
-	  )
-	 !=
-	 _todo.end()
-	 )
-{
-  _done[(*it)->display()].insert(*it);
-  _todo.erase(it);
-}  
+  TodoQueue::iterator it = _todo.begin();
+
+  while (it != _todo.end())
+{
+  if ((*it)->aborted())
+	{
+	  _done[(*it)->display()].insert(*it);
+	  it = _todo.erase(it);
+	}
+  else
+	{
+	  it++;
+	}
+}
 }
 
 void MutatableImageComputerFarm::push_todo(const boost::shared_ptr& task)
@@ -214,7 +215,9 @@ void MutatableImageComputerFarm::abort_f
   if ((*it)->display()==disp)
 	{
 	  (*it)->abort();
-	  _todo.erase(it);
+	  it = _todo.erase(it);
+	  if (it == _todo.end())
+	break;
 	}
 }
   
@@ -234,7 +237,9 @@ void MutatableImageComputerFarm::abort_f
 	  if ((*it1)->display()==disp)
 	{
 	  (*it1)->abort();
-	  q.erase(it1);
+	  it1 = q.erase(it1);
+	  if (it1 == q.end())
+		break;
 	}
 	}
 }


Bug#928141: "Pipe loop" errors in 1.6.5

2019-05-20 Thread Marco d'Itri
Do you want me to submit an unblock request for 1.6.6-1 on your behalf?
I would hate to ship a broken package in the next stable.

On Apr 28, Ondrej Zajicek  wrote:

> On Sun, Apr 28, 2019 at 10:23:26PM +0200, Marco d'Itri wrote:
> > Package: bird
> > Version: 1.6.5-1
> > Severity: important
> > Tags: upstream
> > 
> > Since upgrading from from 1.6.4-1 to 1.6.5-1, my IXP route server is 
> > logging errors like this one all the time:
> > 
> > bird[28976]: Pipe loop detected when sending 31.148.28.0/23 to table master
> > 
> > I have verified that upgrading to 1.6.6-1 from unstable fixes it, so 
> > I think that the package should just be migrated to testing since the 
> > new release only contains bug fixes anyway.
> 
> Hi
> 
> Yes, v1.6.6 is essentially a bugfix release, this is one bug that was
> fixed. It would be good if it could get into testing.
> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Bug#929273: deborphan: Can't add first keep entry: invalid seek

2019-05-20 Thread Matthew Gabeler-Lee
Package: deborphan
Version: 1.7.31
Severity: normal

Trying to use `deborphan --add-keep` with an empty or absent keep file fails:

deborphan: fseek on /var/lib/deborphan/keep: Invalid argument

strace says the failing seek is:

openat(AT_FDCWD, "/var/lib/deborphan/keep", O_RDWR|O_CREAT|O_APPEND, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(3, -4096, SEEK_SET)   = -1 EINVAL (Invalid argument)

Checking the source, this code in keep.c looks suspect:

// ... check if the final newline is missing ...
if (fseek(fp, -1L, SEEK_END) < 0) {
error(EXIT_FAILURE, errno, "fseek on %s", kfile);
}

That's not going to work on an empty file.

Editing the keep file by hand to put an entry, or just a blank line, in it
makes it work, but the default installation state of the package is
non-functional.

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

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

Versions of packages deborphan depends on:
ii  libc6  2.28-10

Versions of packages deborphan recommends:
ii  apt   1.8.1
ii  dialog1.3-20190211-1
ii  gettext-base  0.19.8.1-9

deborphan suggests no packages.

-- no debconf information



Bug#844321: unison: Please update to latest upstream version

2019-05-20 Thread Christoph Groth
Unison 2.51.2 that has been released in January 2018 has a new feature
that is very useful for synchronizing, for example, '.git' directories:

> Add a new preference, 'atomic', for specifying directories that should
> be treated atomically.

It would be great to see this in Debian soon!



  1   2   >