Bug#922139: Typo fixes

2019-02-12 Thread Martin Bagge / brother
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2019-02-12 21:53, Anders Jonsson wrote:
> Hi Martin, attached file fixes two typos in the translation
> (applkation -> applikation; fortfande->fortfarande )

Thnx!


- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlxjyUQACgkQOIRDexPY
/4szcBAAqfBtbXIK0luXPt0bdLiwvbfaEiqnXAWgU8d33dbFLQVpF4LzdkG0glJp
CTotkNMP/l/zAMdk+nUMZyN2IndEW3on1cRotF8I8BzwDdqPVJGMVZYacKh4msSL
mTimIDIJrhimkMsHsPkeN1kCDjkuLhO4WUuMHSFcx/hTrijrWs8OePtwcWM/hvLD
w/G0oU1fV7XlG6IZ3cB4MXzqi5gs/dcgOfjU9fle6dZXTqmgP3BYfsMR6VrLszQW
dRcoZqDLv9BVFt8r8/DhJKY6rHNGAY9dxzfELQ6mEnpTrt23I/lkHekMmB2UJzox
GtJNhHM12gC8PpZebjMtNtGgCS6AbpeoXnBQ8b2LInQXDe7xB7rEYY0EaB1zUq4R
IO+YSVHYhRQP7x4TP36B+Z4IiUP85szFrvrCglQb+ZT0pV9qU5irjzAoJUYxmdFi
ke2hs01QkPAWGHRQnmFuhO9BonE7NIYxWhGUpzc2jHKZIFQ4M1TyYakW0/bEqJVG
UObyqzQkrNHT8aPHv47htHeKjgPyAFe7ctrxcCLi3lDk1D2QnoREX/A8PIg54ciD
7c01RshbSqLmgQwtFZfgkMd1EyRo8WShGdBc/Ysvgsm54zBmvTyTGvBjfqIEzvNw
In3wuJZQeZI7mNsAvVVpm+DWfpmRyO40UyAO+vUT6+afIMD45sY=
=3XMs
-END PGP SIGNATURE-



Bug#918206: Pandas new version (not?)

2019-02-12 Thread Rebecca N. Palmer
Given the soft freeze, the new upstream version is probably no longer an 
option for buster.


Just setting __array_priority__ fails, but with a message that suggests 
also including the test_analytics part of that upstream commit would 
work; I haven't yet had time to try this.



left = one   two
0 -1.365296  1.088132
1 -1.668353  3.025582
2  0.343140 -0.260306
right = array([[-1.36529629,  1.08813166],
   [-1.66835336,  3.02558216],
   [ 0.34314   , -0.26030576]])
cls = 

def _check_isinstance(left, right, cls):
"""
Helper method for our assert_* methods that ensures that
the two objects being compared have the right type before
proceeding with the comparison.

Parameters
--
left : The first object being compared.
right : The second object being compared.
cls : The class type to check against.

Raises
--
AssertionError : Either `left` or `right` is not an instance of 
`cls`.

"""

err_msg = "{name} Expected type {exp_type}, found {act_type} 
instead"

cls_name = cls.__name__

if not isinstance(left, cls):
raise AssertionError(err_msg.format(name=cls_name, 
exp_type=cls,

act_type=type(left)))
if not isinstance(right, cls):
raise AssertionError(err_msg.format(name=cls_name, 
exp_type=cls,

>   act_type=type(right)))
E   AssertionError: DataFrame Expected type 'pandas.core.frame.DataFrame'>, found  instead


../debian/tmp/usr/lib/python3/dist-packages/pandas/util/testing.py:296: 
AssertionError




Bug#922200: courier-imap: /usr/bin/mkdir is invoked directly, failing on non-usrmerge'd systems

2019-02-12 Thread Julian Calaby
Package: courier-imap
Version: 5.0.5+1.0.5-2
Severity: important

Dear Maintainer,

/usr/lib/courier/imapd and /usr/lib/courier/imapd-ssl invoke /usr/bin/mkdir
which doesn't exist on non-usrmerge'd systems, rendering the package unusable.

My understanding is that mkdir is a sufficiently low-level binary that it can
be invoked without a full path like chown, touch and chgrp.

Thanks,

Julian Calaby



Bug#686044: Do not work for me (Was: works for me)

2019-02-12 Thread Alexander Gerasiov
On Tue, 12 Feb 2019 19:05:23 +0100
Petter Reinholdtsen  wrote:

> Control: found -1 1.1.6+dfsg-1
> 
> [Mathieu Malaterre]
> > Could you please check this is still the case for you with current
> > minidlna release ?
> > 
> > It is working for me.  
> 
> I see the same problem in Debian Stable with this AVI file (info from
> file(1)):
> 
>   videos/cleanternet.avi: RIFF (little-endian) data, AVI, 1280 x 720,
> 25.00 fps, video:, audio: uncompressed PCM (stereo, 44100 Hz)

Please try 1.2.1 from stretch-backports. I'm quite sure the problem is
fixed there.

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1



Bug#922199: courier-imap: Upgrade broken on non-systemd installations

2019-02-12 Thread Julian Calaby
Package: courier-imap
Version: 5.0.5+1.0.5-2
Severity: important

Dear Maintainer,

Upgrading to courier-imap 5.0.5+1.0.5-2 on systems that use the traditional
sysvinit is broken.

I have an older server which has been upgraded over the years to Buster and has
managed to avoid being switch to use systemd as it's init system.

Upgrading Courier from 4.17.2+0.76.3-5+b1 to 5.0.5+1.0.5-2 failed with errors
in the postinst script.

For some reason, running invoke-rc.d to restart the services through dpkg
failed where running the exact same commands outside of it worked fine.

I was able to complete the upgrade by disabling both services using update-rc.d
however this isn't a particularly nice upgrade experience.

I understand that non-systemd systems are a historical curiosity these days,
but I'd appreciate it if you'd investigate why your package fails to configure
on them.

Thanks,

Julian Calaby



Bug#922160: lightdm: Add elogind support

2019-02-12 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2019-02-12 at 20:05 +, Mark Hindley wrote:
> As /etc/pam.d/lightdm-greeter doesn't source common-session (should it?), the
> extra line is required.

To be honest, I'm definitely not a PAM expert, so maybe it would be better to
do it like this. As far as I remember, I debianized the pam configuration by
taking a look at gdm or gdm3 (at the time) so maybe there are some things
missing.

I'd rather not add too much package-specific stuff, so if there is a generic
solution (virtual package dependency and generic config file inclusion) it
might be best.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxjxXAACgkQ3rYcyPpX
RFtZ0QgAuERnG9owWbb1DAi3qijklC1eI78Hkc3FCg7uNB7I0KWBv1BmODvSXgKX
R7xyYrYtHbRxr9R7+tDD/j7bhuQjnxKzQKiH9nQdNnQB+VcflOoAmtFp/lh26IDr
4MMs1nAjgPbmPeI8ygSnKK7Gh5tL3dFOeRELAvi3vuiFl3QzncX6yARb7+X0mv5K
FD9mvqlXw3z1UB4TMLeN0ZVfEXiQ9w+O6xNfBmUVKDE98nbmpHkG4EWuhhIJeurH
Nb8S59meV6vIhiNTSKI3p4vCPr8q59wOA7tQuL1ORFIvEmDPjK5h9MZi73JvQGst
48kWViwJbJ2SZd1+dZGxJ3pg1JOMYQ==
=1YNo
-END PGP SIGNATURE-



Bug#922196: t-coffee FTCBFS: confuses C/C++ compilers

2019-02-12 Thread Andreas Tille
Dear Helmut,

thanks a lot for your QA work about cross-building.

On Wed, Feb 13, 2019 at 06:44:05AM +0100, Helmut Grohne wrote:
> Source: t-coffee
> Version: 12.00.7fb08c2-3
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> Hi Andreas,
> 
> thank you for quickly removing the -i flag.

You are welcome.  I try to get things that can be quickly solved as fast
as possible from my desk - so it is natural to fix this quickly. ;-)


> Now diagnosing why t-coffee
> fails to cross build became a lot easier. As it happens, the upstream
> Makefile stores g++ in CC, but for cross compilation dh_auto_build
> overrides that with a C cross compiler. That doesn't work well. All we
> need to do here is store the C++ compiler in CC. Please consider
> applying the attached patch (possibly after buster).

I admit I do not see any reason to wait for after buster with this.  Do
you see any problem your patch might cause?
 
Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#922198: lme4 breaks r-cran-lmertest and r-cran-mlmrev

2019-02-12 Thread Graham Inggs
Control: tags -1 = patch
Control: notforwarded -1
Control: reassign 921938 r-cran-lmertest 3.0-1-2

Hi Dirk

On Wed, 13 Feb 2019 at 01:15, Dirk Eddelbuettel  wrote:
> By now both these packages have been updated
>   https://packages.debian.org/sid/r-cran-lmertest
>   https://packages.debian.org/sid/r-cran-mlmrev
> and there is still no bug in my package r-cran-lme4. We "merely" have to wait
> for testing to receive the newer packages. And then r-cran-lme4 will migrate.
> Until there is nothing for me to day, just as there was nothing for me to
> five days ago.  It really was an issue in r-cran-{lmertest,mlmrev}.

Now that the affected packages have been fixed, it would be great if
you would add the appropriate breaks to lme4 as per the patch below.
This lets dpkg know of the breakage so only the correct versions are
installed together.  This helps avoid deadlocks where a package is
unable to migrate to testing because its autopkgtests need to be
tested against a new version of another package, which is also unable
to migrate to testing.

--- a/debian/control
+++ b/debian/control
@@ -11,6 +11,7 @@
 Package: r-cran-lme4
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${R:Depends},
r-cran-matrix (>= 1.0-1), r-cran-lattice, r-cran-nlme, r-cran-mass,
r-cran-rcppeigen (>= 0.3.2.0.2-2), r-cran-minqa (>= 1.2.2-2),
r-cran-nloptr
+Breaks: r-cran-lmertest (<< 3.1-0-1~), r-cran-mlmrev (<< 1.0-7-1~)
 Description: GNU R package for linear mixed effects model fitting
  This CRAN package provides S4 classes and methods for fitting and
  examining linear mixed effects models (also called multilevel models,


Regards
Graham



Bug#810964: [Pkg-xen-devel] Bug#810964: EDAC bug #810964 effects 4.8 too

2019-02-12 Thread Elliott Mitchell
On Tue, Feb 12, 2019 at 12:11:11AM +0100, Hans van Kranenburg wrote:
> This means you will have to do things like hop on the upstream
> development mailing list, build a reproducable failure case, search for
> a developer that has similar hardware and wants to spend time on it,
> donate hardware to someone to reproduce the error scenarios or learn how
> to do it yourself, or whatever it takes. :)

I had hopes of avoiding doing such.  Problem is there are so many pieces
of software I have to use that if I jumped on the mailing lists of each
of them would be akin to trying to read all of Usenet.  I may not be able
to avoid that here, but...


Looks like Xen's MCE support is in near-useless shape.  The code in the
git repository mention documentation for family 10h, problem is that is
almost entirely decade-old processors.  The last apparently significant
change was in 2014.  The copyright is to AMD, so I guess that means they
need more funding.

Looks like Intel has been offering more support to Xen.  :-(

I'm surprised at Xen's handling of MCE.  Given Xen's approach to things I
would expect MCE handling to be done more by Domain 0.  Let Domain 0
handle talking to the memory controller and merely have Xen map the
physical address to a domain and domain address.  Domain 0 can log all
correctable memory errors to a single location, and in case of an
uncorrectable error it can panic the machine.  (plus Linux's MCE support
is in better shape)

Handling MCE errors in non-Domain 0 only seems to make sense in HVM where
you want to simulate memory errors.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



Bug#922187: libreoffice: please enable libreoffice-help-id package

2019-02-12 Thread Rene Engelhard
Hi,

On Wed, Feb 13, 2019 at 08:06:13AM +0700, Andika Triwidada wrote:
> Recent translation activities preceeding upstream 6.2 release has pushed
> LibreOffice Indonesian Help translation to reach around 90%.
> 
> Afterward, most new help translation to 6.2 was backported to 6.1.
> 
> We would like to propose enabling libreoffice-help-id package starting
> in 6.1.

Given it needs a trip over NEW (waiting time undefined) and we are the soft
freeze, probably definitely too late for 6.1.x, unfortunately.

6.2.x can probably be done, though, yes...

Regards,

Rene



Bug#922197: RFS: worklog/2.0-1 -- Keep Track of Time worked on Projects

2019-02-12 Thread Mo Zhou
Please send additional information to @bugs.debian.org
instead of creating new bugs on every update.

On Wed, Feb 13, 2019 at 06:57:43AM +0100, Adam Bilbrough wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "worklog"
> 
> Package name: worklog
> Version: 2.0-1
> Upstream Author: Adam Bilbrough 
> URL: https://github.com/atsb/worklog
> License: Public Domain
> Section: misc
> 
> It builds these binary packages:
> 
> worklog - Keep Track of Time worked on Projects
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/worklog
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/w/worklog/worklog_2.0-1.dsc
> 
> More information about worklog can be obtained from
> https://github.com/atsb/worklog.
> 
> Changes since the last upload:
> 
>   * Changed abs in source to fabs.
>   * Removed redundant code that was unused.
>   * Worklog survives reasonable resizing. (Closes: #639281)
> 
> Regards,
> Adam
> 



Bug#922197: RFS: worklog/2.0-1 -- Keep Track of Time worked on Projects

2019-02-12 Thread Adam Bilbrough
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

Package name: worklog
Version: 2.0-1
Upstream Author: Adam Bilbrough 
URL: https://github.com/atsb/worklog
License: Public Domain
Section: misc

It builds these binary packages:

worklog - Keep Track of Time worked on Projects

To access further information about this package, please visit the
following URL:

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

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/w/worklog/worklog_2.0-1.dsc

More information about worklog can be obtained from
https://github.com/atsb/worklog.

Changes since the last upload:

  * Changed abs in source to fabs.
  * Removed redundant code that was unused.
  * Worklog survives reasonable resizing. (Closes: #639281)

Regards,
Adam



Bug#922196: t-coffee FTCBFS: confuses C/C++ compilers

2019-02-12 Thread Helmut Grohne
Source: t-coffee
Version: 12.00.7fb08c2-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Andreas,

thank you for quickly removing the -i flag. Now diagnosing why t-coffee
fails to cross build became a lot easier. As it happens, the upstream
Makefile stores g++ in CC, but for cross compilation dh_auto_build
overrides that with a C cross compiler. That doesn't work well. All we
need to do here is store the C++ compiler in CC. Please consider
applying the attached patch (possibly after buster).

Helmut
diff --minimal -Nru t-coffee-12.00.7fb08c2/debian/changelog 
t-coffee-12.00.7fb08c2/debian/changelog
--- t-coffee-12.00.7fb08c2/debian/changelog 2019-02-12 19:37:40.0 
+0100
+++ t-coffee-12.00.7fb08c2/debian/changelog 2019-02-13 06:40:44.0 
+0100
@@ -1,3 +1,10 @@
+t-coffee (12.00.7fb08c2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass C++ compiler as CC. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 13 Feb 2019 06:40:44 +0100
+
 t-coffee (12.00.7fb08c2-3) unstable; urgency=medium
 
   * Do not use -i flag to ignore build failures
diff --minimal -Nru t-coffee-12.00.7fb08c2/debian/rules 
t-coffee-12.00.7fb08c2/debian/rules
--- t-coffee-12.00.7fb08c2/debian/rules 2019-02-12 19:37:40.0 +0100
+++ t-coffee-12.00.7fb08c2/debian/rules 2019-02-13 06:40:43.0 +0100
@@ -11,7 +11,7 @@
dh $@ --sourcedirectory=t_coffee_source
 
 override_dh_auto_build:
-   dh_auto_build -- USER_BIN=../bin/ FCC="$(FCC)" all
+   dh_auto_build -- USER_BIN=../bin/ FCC="$(FCC)" 'CC=$$(CXX)' all
 
 override_dh_auto_clean:
rm -rf t_coffee_source/*.o t_coffee_source/t_coffee bin/t_coffee 
$(shell find example/ -size 0) bin/t_coffee


Bug#922195: dar: new upstream version

2019-02-12 Thread Christoph Anton Mitterer
Package: dar
Version: 2.6.1-1
Severity: wishlist


Hi.

A new upstream version (2.6.2) hast been released :-)

Cheers,
Chris.



Bug#922194: unblock: matplotlib2/2.2.3-6

2019-02-12 Thread Sandro Tosi
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package matplotlib2

the fix in unstable addresses a DeprecationWarning (due to numpy 1.16) that
caused FTBFS on other packages + it allows matplotlib2 to build with sphinx/1.8

attached is the debdiff, the package -although just uploaded- is already built
successfully on all release archs (except for mips, for now).

unblock matplotlib2/2.2.3-6

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru matplotlib2-2.2.3/debian/changelog matplotlib2-2.2.3/debian/changelog
--- matplotlib2-2.2.3/debian/changelog  2018-12-28 11:46:51.0 -0500
+++ matplotlib2-2.2.3/debian/changelog  2019-02-12 17:51:04.0 -0500
@@ -1,3 +1,18 @@
+matplotlib2 (2.2.3-6) unstable; urgency=medium
+
+  * debian/control
+- update Vcs-* fields
+  * debian/patches/bts918819-numpy-deprecates-asscalar-gh12508.patch
+- fix DeprecationWarnings with Numpy 1.16; Closes: #918819
+  * debian/patches/bts918896-doc-backports-for-2.2.x-gh13258.patch
+- import upstream doc backports patches for 2.2.x branch; Closes: #918896
+  * debian/control
+- bump Standards-Version to 4.3.0 (no changes needed)
+  * debian/copyright
+- extend packaging copyright years
+
+ -- Sandro Tosi   Tue, 12 Feb 2019 17:51:04 -0500
+
 matplotlib2 (2.2.3-5) unstable; urgency=medium
 
   * install the default matplotlib config file at /etc/matplotlibrc2;
diff -Nru matplotlib2-2.2.3/debian/control matplotlib2-2.2.3/debian/control
--- matplotlib2-2.2.3/debian/control2018-12-28 11:46:51.0 -0500
+++ matplotlib2-2.2.3/debian/control2019-02-12 17:51:04.0 -0500
@@ -60,10 +60,10 @@
xvfb,
zlib1g-dev
 XS-Python-Version: all
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Homepage: http://matplotlib.org/
-Vcs-Git: https://salsa.debian.org/python-team/modules/matplotlib.git
-Vcs-Browser: https://salsa.debian.org/python-team/modules/matplotlib
+Vcs-Git: https://salsa.debian.org/python-team/modules/matplotlib2.git
+Vcs-Browser: https://salsa.debian.org/python-team/modules/matplotlib2
 
 Package: python-matplotlib
 Architecture: any
diff -Nru matplotlib2-2.2.3/debian/copyright matplotlib2-2.2.3/debian/copyright
--- matplotlib2-2.2.3/debian/copyright  2018-12-28 11:46:51.0 -0500
+++ matplotlib2-2.2.3/debian/copyright  2019-02-12 17:51:04.0 -0500
@@ -62,7 +62,7 @@
  Agreement.
 
 Files: debian/*
-Copyright: Copyright (C) 2008-2018 Sandro Tosi 
+Copyright: Copyright (C) 2008-2019 Sandro Tosi 
 License: same as upstream
 
 Files: lib/matplotlib/backends/backend_wxagg.py
diff -Nru 
matplotlib2-2.2.3/debian/patches/bts918819-numpy-deprecates-asscalar-gh12508.patch
 
matplotlib2-2.2.3/debian/patches/bts918819-numpy-deprecates-asscalar-gh12508.patch
--- 
matplotlib2-2.2.3/debian/patches/bts918819-numpy-deprecates-asscalar-gh12508.patch
  1969-12-31 19:00:00.0 -0500
+++ 
matplotlib2-2.2.3/debian/patches/bts918819-numpy-deprecates-asscalar-gh12508.patch
  2019-02-12 17:51:04.0 -0500
@@ -0,0 +1,26 @@
+--- a/lib/matplotlib/colors.py
 b/lib/matplotlib/colors.py
+@@ -98,7 +98,7 @@ def _sanitize_extrema(ex):
+ if ex is None:
+ return ex
+ try:
+-ret = np.asscalar(ex)
++ret = ex.item()
+ except AttributeError:
+ ret = float(ex)
+ return ret
+--- a/lib/matplotlib/image.py
 b/lib/matplotlib/image.py
+@@ -421,9 +421,9 @@ class _ImageBase(martist.Artist, cm.Scal
+ 
+ A_scaled -= a_min
+ # a_min and a_max might be ndarray subclasses so use
+-# asscalar to avoid errors
+-a_min = np.asscalar(a_min.astype(scaled_dtype))
+-a_max = np.asscalar(a_max.astype(scaled_dtype))
++# item to avoid errors
++a_min = a_min.astype(scaled_dtype).item()
++a_max = a_max.astype(scaled_dtype).item()
+ 
+ if a_min != a_max:
+ A_scaled /= ((a_max - a_min) / 0.8)
diff -Nru 
matplotlib2-2.2.3/debian/patches/bts918896-doc-backports-for-2.2.x-gh13258.patch
 
matplotlib2-2.2.3/debian/patches/bts918896-doc-backports-for-2.2.x-gh13258.patch
--- 
matplotlib2-2.2.3/debian/patches/bts918896-doc-backports-for-2.2.x-gh13258.patch
1969-12-31 19:00:00.0 -0500
+++ 
matplotlib2-2.2.3/debian/patches/bts918896-doc-backports-for-2.2.x-gh13258.patch
2019-02-12 17:51:04.0

Bug#922193: debarchiver: [INTL:fr] French program translation update

2019-02-12 Thread Alban Vidal
Package: debarchiver
Version: 0.11.3
Severity: wishlist
Tags: patch l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Dear Maintainer,

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

This file should be put as fr.po in the appropriate place in
your package build tree:
po4a/po/

Best regards,

Alban Vidal

-BEGIN PGP SIGNATURE-

iQJLBAEBCAA1FiEErkjA9ZsZmKBikqaZlr1P9k5wn94FAlxjqWQXHGFsYmFuLnZp
ZGFsQHpvcmRoYWsuZnIACgkQlr1P9k5wn95rKA/8CBs/lUNuJQ7Qaj3/XKFZZZ6W
tJwGULXLrig4k88TzHSt7YdJSgYTkqYk5/ONslk55OlWBTv74IQikuXHvSWIF3CQ
kKP+pN1+F7jvjl9G6uLLAV01DUf8/MkQa3PQtau3I3kZrwo7NIS2LacDmHDoKQhN
EyD2IfAWSgUlBBZs2pwDg+WVoe9OU+ZB5d0NMSU0BEGcCuH7fFLK7DEdSmXswayw
VUqejpCbUD8oFUktEWJDZLCRGI/18HmtXeUJOUMrcEMTUqwKDWF0M66t31YnK1Mm
36jg9rtWIaVeV2SzIjWZVaSsrEn9ZgmEUNm1pK/fBDPC90NW2PjHdT/oITVjIwYT
UgcJqq9UedtSjY8zMkKXiLrpgnOlKY8luZTE82wifMFHJ1PzZgq+qEBmkB0r0qjF
jM9gicU+sxnam+35I1sT+A0NVUb59e+1fq3RQjOgPSAQwaG9Xo0y4GxjFXvaNosr
rmB/bWvnjf2l5qzGgMVOrYd5n+aBRutHhpDhZzw4K0J9+ZQ91Be8Dnd9r97TXcSv
/NkAG55nxOrQ0Gr3JySOH6cN7dc8NwnJYva+gJnyZF2rgMqc8w5NFaReVuIm2Lw9
b3cGhugUwWcsjVhfy0F9rriq1J1hOX2VrOZN9FXgkpYYeMllkprmXCg/WrRIBTiV
t4kGNz1qjPk4UX4K5hc=
=R7hg
-END PGP SIGNATURE-
# Translation of debarchiver manpage to French
# Copyright (C) 2005, 2006, 2010 Free Software Foundation, Inc.
# Copyright (C) 2017-2019, French l10n team 

# This file is distributed under the same license as the debarchiver package.
#
# Translators:
# Valery Perrin , 2005, 2006, 2010, 2011.
# Alban Vidal , 2017, 2019.
msgid ""
msgstr ""
"Project-Id-Version: debarchiver 0.11.3\n"
"POT-Creation-Date: 2018-12-28 22:12+0100\n"
"PO-Revision-Date: 2019-01-27 15:00+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

# type: =head1
#. type: =head1
#: debarchiver.pod:1
msgid "NAME"
msgstr "NOM"

# type: textblock
#. type: textblock
#: debarchiver.pod:3
msgid "debarchiver - Tool to sort debian packages into a package archive."
msgstr ""
"debarchiver - Outil de gestion des paquets Debian au sein d'une archive de "
"paquet."

# type: =head1
#. type: =head1
#: debarchiver.pod:5
msgid "SYNOPSIS"
msgstr "SYNOPSIS"

# type: textblock
#. type: textblock
#: debarchiver.pod:7
msgid "debarchiver [options]"
msgstr "debarchiver [options]"

# type: =head1
#. type: =head1
#: debarchiver.pod:9
msgid "DESCRIPTION"
msgstr "DESCRIPTION"

# type: textblock
#. type: textblock
#: debarchiver.pod:11
msgid ""
"The debian archiver is a tool that installs debian packages into a file "
"structure suitable for apt-get, aptitude, dselect and similar tools. This "
"can be used for updating the Debian system. It is meant to be used by local "
"administrators that need special packages, or tweaked versions to ease "
"administration."
msgstr ""
"L'archiveur Debian (debarchiver) est un outil qui installe les paquets "
"Debian dans une structure de fichiers exploitable par apt-get, aptitude, "
"dselect et d'autres outils semblables. Il peut être utilisé pour la mise à "
"jour des systèmes Debian. Il est destiné à être employé par des "
"administrateurs locaux qui ont besoin de paquets spéciaux, ou de versions "
"particulières, afin d'en faciliter la gestion."

# type: textblock
#. type: textblock
#: debarchiver.pod:13
msgid ""
"The file structure is based on the potato file structure and does not "
"support package pools."
msgstr ""
"La structure de fichiers est basée sur celle de potato et ne reconnaît pas "
"la structure de paquets en « pools ». (NdT : Structure utilisée à partir de "
"woody)."

# type: =head1
#. type: =head1
#: debarchiver.pod:15
msgid "OPTIONS"
msgstr "OPTIONS"

# type: =item
#. type: =item
#: debarchiver.pod:19
msgid "B<-a | --autoscan>"
msgstr "B<-a | --autoscan>"

# type: textblock
#. type: textblock
#: debarchiver.pod:21
msgid "Does both --autoscanpackages and --autoscansources."
msgstr "Exécute « --autoscanpackages » et « --autoscansources »."

# type: =item
#. type: =item
#: debarchiver.pod:23
msgid "B<--autoscanall>"
msgstr "B<--autoscanall>"

# type: textblock
#. type: textblock
#: debarchiver.pod:25
msgid "Same as --scanall --autoscan."
msgstr "Identique à « --scanall --autoscan »."

# type: =item
#. type: =item
#: debarchiver.pod:27
msgid "B<--autoscanpackages>"
msgstr "B<--autoscanpackages>"

# type: textblock
#. type: textblock
#: debarchiver.pod:29
msgid ""
"Automatically run dpkg-scanpackages after all new packages are installed."
msgstr ""
"Démarre automatiquement « dpkg-scanpackages » après l'installation de tous "
"les nouveaux paquets."

# type: =item
#. type: =item
#: debarchiver.pod:31
msgid "B<--autoscansources>"
msgstr "B<--autoscansources>"

# type: textblock
#. type: textblock
#: debarchiver.pod:33
msgid ""
"Automatically run dpkg-scansources after all new packages are installe

Bug#898202: Current state

2019-02-12 Thread Scott Hardin

Hello!

Just wanted to drop a line and say that I'm still working on this. 🙂 
Sorry, I'm a little bit of a sloth sometimes.


All of the patches that were previously being applied by the last 
maintainer have since been merged into upstream. Also, mp3gain has since 
seemingly abandoned its own fork of mpg123, making things wy easier. 
I was able to get mp3gain to compile against Debian's own mpg123 package.


Next will be making any updates necessary to manpages/documentation and 
other package-related stuff.


Scott



Bug#911133: Debian Installer assumes serial console on arm64

2019-02-12 Thread Wookey
Here is a patch to debian-installer to enable it to run D-I on all available 
consoles. 

This is one part of making arm64 machines work 'just like PCs' in the installer.

I have also done some work on getting the graphical installer
working. I have enabled that, but input is not working yet, so 'more
later' on that.

The multiple-console support involves a major revamp of
'reopen-consoles-linux' in rootskel in debian-installer, to get rid of
a load of old cruft, and use /proc/consoles (i.e. the kernel's list)
to choose the set of enabled consoles, running the startup rc scripts
on just one console (to avoid doing things twice), then running
debian-installer itself on all the consoles that are enabled and have
device files.

More details are available in the thread steve linked to on debian-boot.

It seems like there is actually a cleaner way to do this, by getting
init to do the heavy process/session/parallel-tasks lifting (instead
of reopen-consoles and steal-ctty). I have a proof-of-concept patch
for that, but it's not actually working right yet. I'll send that in
when it does if I don't hit any roadblocks.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux
index a7b8a23..437e208 100644
--- a/src/etc/inittab-linux
+++ b/src/etc/inittab-linux
@@ -5,7 +5,7 @@
 ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
 
 # main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
+::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer
 
 # convenience shells
 tty2::askfirst:-/bin/sh
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 3287dd0..e13bfa3 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -1,74 +1,68 @@
 #!/bin/sh
 
 # In order to give proper access to the tty, we need to locate the device
-# corresponding to the console we are actually using.
+# corresponding to each console we are actually using.
+
+# This script is run twice, once at sysinit to run the debian-installer-startup
+# rc scripts, and once to start the installer itself.
+# The first time it parses the consoles used, the second time they are read from files
+# The startup scripts need to be run just once (on one console) (not idempotent)
+# The installer is run on all the enabled consoles (using the --all-consoles option)
+
 
 NL="
 "
 
-console=
-if ! [ -f /var/run/console-device ]; then
-	# If the kernel emitted a "handover" message, then it's the one
-	case $(uname -r) in
-	2.6.2*|2.6.3[01]*)
-		console="$(dmesg -s 262143 |
-			sed -n -r -e 's/(.*\])? *console handover: boot \[.*\] -> real \[(.*)\]$/\2/p')"
-		;;
-	2.6.3[234567]*)
-		console="$(dmesg -s 262143 |
-			sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled, bootconsole disabled$/\2/p')"
-		;;
-	*) # >= 2.6.38
-		console_major_minor="$(get-real-console-linux)"
-		console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
-		console="${console_raw##*/}"
-		;;
-	esac
-
-	# Except if it is the wrong type...
-	if [ "$console" ] && [ "$(console-type)" = serial ] && \
-	   expr "$console" : "tty[0-9]" >/dev/null; then
-		console=
-	fi
+if ! [ -f /var/run/console-devices ]; then
 
 	consoles=
-	if [ -z "$console" ]; then
-		# Retrieve all enabled consoles from boot log; ignore those
-		# for which no device file exists
-		for cons in $(dmesg -s 262143 |
-			sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled/\2/p')
-		do
-			if [ -e "/dev/$cons" ]; then
-consoles="${consoles:+$consoles$NL}$cons"
-			fi
-		done
-		# Only one console? Then we are good.
-		if [ $(echo "$consoles" | wc -l) -eq 1 ]; then
-			console="$consoles"
+	preferred=
+	# Retrieve all enabled consoles from kernel; ignore those
+	# for which no device file exists
+
+	kernelconsoles="$(cat /proc/consoles)"
+	for cons in $(echo "$kernelconsoles" | sed -n -r -e 's/(^.*)  .*\((.*)\).*$/\1/p' )
+	do
+		status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e 's/(^.*) *.*\((.*)\).*$/\2/p' )
+		if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ]; then
+			consoles="${consoles:+$consoles$NL}$cons"
 		fi
-	fi
+		# 'C' console is 'most prefered'.
+		if [ $(echo "$status" | grep -o 'C') ]; then
+			preferred="$cons"
+		fi
+	done
 
-	if [ -z "$console" ]; then
-		# Locate the last enabled console present on the command line
-		for arg in $(cat /proc/cmdline); do
-			case $arg in
-			console=*)
-arg=${arg#console=}
-cons=${arg%%,*}
-if echo "$consoles" | grep -q "^$cons$"; then
-	console=$cons
-fi
-;;
-			esac
-		done
+	if [ -z "$consoles" ]; then
+		# Nothing found? Default to /dev/console.
+		consoles=console
 	fi
-
-	if [ -z "$console" ]; then
-		# Still nothing? Default to /dev/console.
-		console=console
+	if [ -z "$preferred" ]; then
+		#None marked preferred? Use the first one
+		preferred=$(echo "$consoles" | head -n 1) 
 	fi
-	echo /dev/$console > /var/run/console-device
+	
+	

Bug#922192: epcr FTCBFS: builds for the wrong architecture

2019-02-12 Thread Do Thanh Trung

Source: epcr
Version: 2.3.12-1-6
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

epcr fails to cross build because it does not pass cross build tools to 
make. Using "dh_auto_build" instead of "$(MAKE)" can solve this problem.


diff -Nru epcr-2.3.12-1/debian/rules epcr-2.3.12-1/debian/rules
--- epcr-2.3.12-1/debian/rules  2018-10-14 05:23:48.0 +0700
+++ epcr-2.3.12-1/debian/rules  2018-10-14 05:23:48.0 +0700
@@ -23,7 +23,7 @@
rm -f e-PCR famap fahash re-PCR
 
 override_dh_auto_build:
-   $(MAKE) links depend all OPTIMIZE=6
+   dh_auto_build -- links depend all OPTIMIZE=6
 
 override_dh_auto_install:
# do nothing
-- 
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com


Bug#922191: mirror listing update for debian.xtdv.net

2019-02-12 Thread Ta Xuan Truong
Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debian.xtdv.net
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Ta Xuan Truong 
Country: VN Vietnam
Location: Ho Chi Minh city
Sponsor: XTDV Group http://www.xtdv.group
Comment: This server is connected to 3 internet provides (2 activate and 1 
backup). Maximum bandwidth is 100Mbps.




Trace Url: http://debian.xtdv.net/debian/project/trace/
Trace Url: http://debian.xtdv.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.xtdv.net/debian/project/trace/debian.xtdv.net



Bug#921705: gnome: Please do not override debian-xterm.desktop file

2019-02-12 Thread Laurent Bigonville
On Fri, 08 Feb 2019 00:24:58 -0800 Ben Wong  
wrote:


> Dear Maintainer,

Hello,

[...]
>
> It turns out that some part of Gnome is creating a *second* desktop
> file which disables the first one by setting NoDisplay = True. This is
> extremely frustrating and unnecessary. The file is
> /usr/share/gnome/applications/debian-xterm.desktop
>
> I would like to tell you which part of Gnome is the culprit, but
> `dpkg -S` on the file says it doesn't belong to any packages.
>
> I can understand that certain distributions derived from Debian —
> those which believe minimalism equates to simplicity — may wish to
> hide "redundant" functionality like `xterm`. However, it doesn't make
> sense to hide xterm from Debian users. And if it did, it certainly
> should not be implemented in such a hard to discover way.

[...]

The preferred solution to fix this is to modify the 
/etc/gnome/menus.blacklist (that file controls the mechanism applying 
the blacklisting) and then run the gnome-menus-blacklist command.


There is not real consensus in the team about changing this ATM

Kind regards,

Laurent Bigonville



Bug#922190: netbeans: Illegal reflective access by org.netbeans.core.windows.view.ui.MainWindow

2019-02-12 Thread Gustavo Castro
Package: netbeans
Version: 10.0-2
Severity: normal

Dear Maintainer,

netbeans has a failure at the beginning

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.netbeans.core.windows.view.ui.MainWindow
(jar:file:/usr/share/netbeans/10.0/platform/modules/org-netbeans-core-windows.jar!/)
to field sun.awt.X11.XToolkit.awtAppClassName
WARNING: Please consider reporting this to the maintainers of
org.netbeans.core.windows.view.ui.MainWindow
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release

It didn't help to wipe out everything in /.netbeans/10.?/ and there were no
obvious clues in netbeans' var/log/messages.log.

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

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

Versions of packages netbeans depends on:
ii  default-jdk [java8-sdk] 2:1.11-71
ii  libnb-apisupport3-java  10.0-2
ii  libnb-ide14-java10.0-2
ii  libnb-java5-java10.0-2
ii  libnb-platform18-java   10.0-2
ii  openjdk-10-jdk [java8-sdk]  10.0.2+13-2
ii  openjdk-11-jdk [java8-sdk]  11.0.2+9-3
ii  openjdk-8-jdk [java8-sdk]   8u191-b12-2

netbeans recommends no packages.

netbeans suggests no packages.

-- no debconf information


Bug#922189: cups: HP LJ 3320 reports paper out on next print job

2019-02-12 Thread tom
Package: cups
Version: 2.2.1-8+deb9u2
Severity: normal

If the HP LJ 3320 printer runs out of paper during a print job,
the error is correctly relayed to the computer in a dialog box.

But if the error occurs between print jobs, such as changing 
the paper, and the error is no longer there, it still reports
it in a dialog box on the subsequent print job.

I always have to check if there is enough paper. I apologize 
if this is a hplip bug. I rerally don't know

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

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

Versions of packages cups depends on:
ii  cups-client2.2.1-8+deb9u2
ii  cups-common2.2.1-8+deb9u2
ii  cups-core-drivers  2.2.1-8+deb9u2
ii  cups-daemon2.2.1-8+deb9u2
ii  cups-filters   1.11.6-3
ii  cups-ppdc  2.2.1-8+deb9u2
ii  cups-server-common 2.2.1-8+deb9u2
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript9.26a~dfsg-0+deb9u1
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc-bin   2.24-11+deb9u3
ii  libc6  2.24-11+deb9u3
ii  libcups2   2.2.1-8+deb9u2
ii  libcupscgi12.2.1-8+deb9u2
ii  libcupsimage2  2.2.1-8+deb9u2
ii  libcupsmime1   2.2.1-8+deb9u2
ii  libcupsppdc1   2.2.1-8+deb9u2
ii  libgcc11:6.3.0-18+deb9u1
ii  libstdc++6 6.3.0-18+deb9u1
ii  libusb-1.0-0   2:1.0.21-1
ii  poppler-utils  0.48.0-2+deb9u2
ii  procps 2:3.3.12-3+deb9u1

Versions of packages cups recommends:
ii  avahi-daemon 0.6.32-2
ii  colord   1.3.3-2
ii  cups-filters [ghostscript-cups]  1.11.6-3
ii  printer-driver-gutenprint5.2.11-1+b2

Versions of packages cups suggests:
ii  cups-bsd   2.2.1-8+deb9u2
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20161201-1
ii  hplip  3.16.11+repack0-3
ii  printer-driver-hpcups  3.16.11+repack0-3
pn  smbclient  
ii  udev   232-25+deb9u8

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true



Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work

2019-02-12 Thread Hans van Kranenburg
On 2/13/19 2:17 AM, Marek Marczykowski-Górecki wrote:
> On Wed, Feb 13, 2019 at 02:07:22AM +0100, Hans van Kranenburg wrote:
>> xen-utils-common 4.11 does not depend on xen-utils 4.11, so it can be
>> missing.
> 
> Oh... so maybe search for latest one and error out if none is there?
> Or, create yet another binary package which depends on both, intended to
> be installed in guest (description of xen-utils-common says it's for
> dom0 only), and ship xendriverdomain service there?

I have never used Xen stuff inside a domU, but only the idea that
xen-utils-common with all the dom0 stuff is also supposed to be
installed inside a domU while trying these things has only frightened
me. And it seems that feeling wasn't completely misguided.

>> What if you try running /usr/lib/xen-4.8/bin/xl directly instead, for fun?
> 
> 4.8 is not there, but 4.11 is and it works.

Eh, yeah, 4.11, obviously.

> After printing some errors
> which I believe are unrelated to Debian packaging:
> 
> root@d10test:/home/user# /usr/lib/xen-4.11/bin/xl devd
> libxl: error: libxl.c:363:libxl_get_physinfo: getting physinfo: 
> Permission denied
> libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to 
> retrieve the maximum number of cpus
> libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to 
> retrieve the maximum number of cpus
> libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to 
> retrieve the maximum number of cpus
> root@d10test:/home/user# ps aux|grep xl\ devd
> root 25841  0.0  0.1  72144  2228 ?Ssl  20:09   0:00 
> /usr/lib/xen-4.11/bin/xl devd

It does something! \o/

Creating new binary packages etc... is not an option anymore during the
Buster freeze.

At some point Ian will probably look at this in the next days, to see
what we still can do for Buster. Any testing you can do and anything you
can find out in the meantime is of course useful.

Thanks,

K



Bug#922188: ITP: gatsby -- Blazing fast modern site generator for React

2019-02-12 Thread Utkarsh Gupta
Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name :gatsby
  Version  : 2.0.119
  Upstream Author  : Kyle Mathews
* URL  : https://github.com/gatsbyjs/gatsby
* License  : Expat
  Programming Lang : Javascript
  Description  : Blazing fast modern site generator for React

Gatsby is a modern framework for blazing fast websites.

Best,
Utkarsh


Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work

2019-02-12 Thread Marek Marczykowski-Górecki
On Wed, Feb 13, 2019 at 02:07:22AM +0100, Hans van Kranenburg wrote:
> xen-utils-common 4.11 does not depend on xen-utils 4.11, so it can be
> missing.

Oh... so maybe search for latest one and error out if none is there?
Or, create yet another binary package which depends on both, intended to
be installed in guest (description of xen-utils-common says it's for
dom0 only), and ship xendriverdomain service there?

> What if you try running /usr/lib/xen-4.8/bin/xl directly instead, for fun?

4.8 is not there, but 4.11 is and it works. After printing some errors
which I believe are unrelated to Debian packaging:

root@d10test:/home/user# /usr/lib/xen-4.11/bin/xl devd
libxl: error: libxl.c:363:libxl_get_physinfo: getting physinfo: Permission 
denied
libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve 
the maximum number of cpus
libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve 
the maximum number of cpus
libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve 
the maximum number of cpus
root@d10test:/home/user# ps aux|grep xl\ devd
root 25841  0.0  0.1  72144  2228 ?Ssl  20:09   0:00 
/usr/lib/xen-4.11/bin/xl devd


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature


Bug#921617: mumble: Mumble memory use increases over time to unreasonable amounts

2019-02-12 Thread Chris Knadle
retitle 921617 Mumble echo canceler leaks memory
forwarded 921617 https://github.com/mumble-voip/mumble/issues/3379
thanks

Colomban Wendling:
> Le 08/02/2019 à 16:54, Chris Knadle a écrit :
>> Colomban Wendling:
>>> Le 07/02/2019 à 16:56, Chris Knadle a écrit :
 […]

 Just to mention: this isn't the first report of "memory leak" on Mumble -- 
 see
 Debian bug #683827.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683827

 I wasn't able to reproduce #683827 on newer versions of Mumble 1.2.x but 
 wasn't
 sure what the underlying cause/issue was there, or what version of Mumble 
 may
 have fixed that bug.
>>>
>>> The links you have there are interesting; for example
>>> https://github.com/mumble-voip/mumble/issues/1074#issuecomment-20316
>>> suggests that it might be due to echo canceller and other apps "messing"
>>> with PulseAudio.  I do have echo canceller enabled (that I should
>>> actually be able to disable as I'm using push-to-talk with a headset),
>>> and am running at least one virtual machine which could be doing
>>> something with PulseAudio.
>>>
>>> I'll try and do some tests next chance I get (probably next week).
>>
>> *nod*  Okay.  Yeah the echo canceler would be part of the Mumble binary, so 
>> if
>> the canceler is misbehaving memory-wise then that would make sense.
> 
> I tried without the echo canceller and it's behaving reasonably so far,
> after 5 hours: it's using 109M resident memory, and peaked at 123M.
> So it seems it's indeed the echo canceller that's leaking a lot.

Okay.  Thank you very much for testing and finding this, as it helps narrow down
where the problem is.

I'm re-titling the bug so that it will be easier for others to find when looking
to find information about it.

>>  However if
>> another virtual machine were causing issues with PulseAudio then that 
>> shouldn't
>> cause memory expansion/leaking in the Mumble client binary (AFAIK).
> 
> IIUC from the report I linked, some software alter the input sinks in a
> way that confused the echo canceller.  It'd say it's still a bug on the
> canceller part, but it might be triggered only on some conditions that
> don't normally happen, but that some software doing their own audio
> input trigger -- not quite sure.

*nod*  Hmm.  So I think the theory there is that the because other VMs interact
with PulseAudio that it changes the interaction between PulseAudio and the
Mumble echo canceler such that the echo canceler uses increasing memory.  It
feels like that "shouldn't happen", but then again that's the definition of a
"bug" and this is a bug, so... maybe it's possible.

I had a look at the open issues for mumble and found #3379 which is about Mumble
echo cancellation on Windows:

   https://github.com/mumble-voip/mumble/issues/3379

also issue #3406 which shows the memory leak to be intermittent (if true that
would be annoying, because that makes the root cause harder to find):

   https://github.com/mumble-voip/mumble/issues/3406

I'm marking this bug as related to Mumble issue #3379 upstream and adding an
entry to the upstream bug pointing to this one so that upstream can see that
this is likely affecting other OSes than Windows.

Thanks

   -- Chris

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



Bug#922187: libreoffice: please enable libreoffice-help-id package

2019-02-12 Thread Andika Triwidada
Package: libreoffice
Version: 6.1.5~rc1
Severity: wishlist

Dear Maintainer,

Recent translation activities preceeding upstream 6.2 release has pushed
LibreOffice Indonesian Help translation to reach around 90%.

Afterward, most new help translation to 6.2 was backported to 6.1.

We would like to propose enabling libreoffice-help-id package starting
in 6.1.

Regards,
Andika



Bug#922186: apt-listchanges: hard-codes paths instead of using apt Dir options

2019-02-12 Thread Paul Wise
Package: apt-listchanges
Version: 3.18
Severity: normal
Usertags: hardcoding

apt-listchanges hard-codes /var/lib/dpkg/status instead of using the
apt Dir::State::status option, which means if that option has been
customised, possibly by setting the APT_CONFIG variable to a config file that 
has a Dir::State::status option that points at a location that is not the 
Debian rootfs, then apt-listchanges will return results
for the Debian rootfs instead of the custom location.

status = DebianFiles.ControlParser()
status.readfile('/var/lib/dpkg/status')
status.makeindex('Package')

Likewise, apt-listchanges hard-codes /etc/apt instead of using the apt
Dir::Etc option to locate the apt-listchanges.conf file.

config.read('/etc/apt/listchanges.conf')

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

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

Versions of packages apt-listchanges depends on:
ii  apt1.8.0~rc2
ii  debconf [debconf-2.0]  1.5.70
ii  python33.7.2-1
ii  python3-apt1.8.3
ii  python3-debconf1.5.70
ii  sensible-utils 0.0.12
ii  ucf3.0038+nmu1

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  dillo [www-browser]3.0.5-5
ii  exim4-daemon-light [mail-transport-agent]  4.92~RC5-2
ii  firefox [www-browser]  65.0-1
ii  firefox-esr [www-browser]  60.5.0esr-1
ii  gnome-terminal [x-terminal-emulator]   3.30.2-2
ii  lynx [www-browser] 2.8.9rel.1-3
ii  netsurf [www-browser]  3.6-3.2
ii  netsurf-gtk [www-browser]  3.6-3.2
ii  python3-gi 3.30.4-1
ii  w3m [www-browser]  0.5.3-37
ii  xterm [x-terminal-emulator]343-1

-- debconf information:
* apt-listchanges/which: both
* apt-listchanges/save-seen: true
* apt-listchanges/frontend: pager
* apt-listchanges/email-format: text
* apt-listchanges/headers: false
* apt-listchanges/no-network: false
* apt-listchanges/email-address: root
* apt-listchanges/confirm: true
* apt-listchanges/reverse: false

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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


Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work

2019-02-12 Thread Hans van Kranenburg
Hi,

On 2/13/19 1:53 AM, Marek Marczykowski-Górecki wrote:
> Preliminary test results of something based on debian-xen master branch:
> Xen version detection seems fundamentally wrong when talking about domU
> side. I've installed relevant packages in buster-based domU, then tried
> manually `xl devd`. The result:
> 
> ERROR:  Can't find version 4.8 of xen utils, bailing out!

That message is from /usr/lib/xen-common/bin/xen-dir. xl is not actually
xl, but it's the wrapper script which tries to run xl for the current
running hypervisor version. Bweuh...

> Yes, the hypervisor (and dom0 tools) are 4.8. But it should not matter
> for domU, since it use only stable ABI.
> The detection logic should be used only in dom0. On domU side I think it
> should take version of xen-utils-common package (the one shipping
> detection script) - so xen-utils-common_4.11* will use xen-utils_4.11.

xen-utils-common 4.11 does not depend on xen-utils 4.11, so it can be
missing.

And indeed, doing things based on running hypervisor does not make sense
here.

What if you try running /usr/lib/xen-4.8/bin/xl directly instead, for fun?

Hans



Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work

2019-02-12 Thread Marek Marczykowski-Górecki
Preliminary test results of something based on debian-xen master branch:
Xen version detection seems fundamentally wrong when talking about domU
side. I've installed relevant packages in buster-based domU, then tried
manually `xl devd`. The result:

ERROR:  Can't find version 4.8 of xen utils, bailing out!

Yes, the hypervisor (and dom0 tools) are 4.8. But it should not matter
for domU, since it use only stable ABI.
The detection logic should be used only in dom0. On domU side I think it
should take version of xen-utils-common package (the one shipping
detection script) - so xen-utils-common_4.11* will use xen-utils_4.11.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature


Bug#922185: less: crash (SIGABRT) when pressing random keys

2019-02-12 Thread Paul Wise
Package: less
Version: 487-0.1+b1
Severity: normal
Usertags: crash

I just got a crash (SIGABRT) after pressing random keys due to not
being awake enough to type properly while viewing the apt-listchanges
manual page. Based on the backtrace below, I seem to have toggled some
sort of option and passed \\ as a command, which caused the crash.

If the backtrace below is not useful, please close this bug.

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core /var/crash/1000/13130-1000-1000-6-1550017848-chianamo--bin-less.core 
/bin/less
[New LWP 13130]
Core was generated by `less'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f8d76b44535 in __GI_abort () at abort.c:79
#2  0x7f8d76b9b778 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f8d76ca628d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f8d76ba1e6a in malloc_printerr (str=str@entry=0x7f8d76ca443b 
"free(): invalid pointer") at malloc.c:5341
#4  0x7f8d76ba5d7e in free_check (mem=, caller=) at hooks.c:254
#5  0x5584b493f360 in lglob (filename=0x5584b529e360 "", 
filename@entry=0x5584b4b59ac0  "\\") at filename.c:811
#6  0x5584b4944318 in opt_o (type=, s=0x5584b4b59ac0 
 "\\") at optfunc.c:109
#7  0x5584b4945a70 in toggle_option (o=0x5584b4b58900 , 
lower=, s=, how_toggle=1) at option.c:443
#8  0x5584b493b05d in exec_mca () at command.c:240
#9  0x5584b493c74c in mca_char (c=10) at command.c:597
#10 commands () at command.c:1069
#11 0x5584b49351c5 in main (argc=, argv=0x7fff29729320) at 
main.c:283

Thread 1 (LWP 13130):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {65536, 0 }}
pid = 
tid = 
ret = 
#1  0x7f8d76b44535 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, 
sa_mask = {__val = {532575944815, 0, 4096, 94028463467232, 100, 94028463467232, 
94028463465376, 94028453691348, 140245559039858, 4096, 140245558958506, 12, 
702811210, 1, 140733888761696, 140733888761952}}, sa_flags = 695373664, 
sa_restorer = 0x1000}
sigs = {__val = {32, 0 }}
#2  0x7f8d76b9b778 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f8d76ca628d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
ap = {{gp_offset = 24, fp_offset = 0, overflow_arg_area = 
0x7fff29729070, reg_save_area = 0x7fff29729000}}
fd = 2
list = 
nlist = 
cp = 
written = 
#3  0x7f8d76ba1e6a in malloc_printerr (str=str@entry=0x7f8d76ca443b 
"free(): invalid pointer") at malloc.c:5341
No locals.
#4  0x7f8d76ba5d7e in free_check (mem=, caller=) at hooks.c:254
p = 
#5  0x5584b493f360 in lglob (filename=0x5584b529e360 "", 
filename@entry=0x5584b4b59ac0  "\\") at filename.c:811
gfilename = 0x5584b529e3a0 ""
ofilename = 0x5584b529e680 "\\"
#6  0x5584b4944318 in opt_o (type=, s=0x5584b4b59ac0 
 "\\") at optfunc.c:109
parg = {p_string = 0x0, p_int = 0, p_linenum = 0}
#7  0x5584b4945a70 in toggle_option (o=0x5584b4b58900 , 
lower=, s=, how_toggle=1) at option.c:443
num = 
no_prompt = 0
err = 0
parg = {p_string = 0x0, p_int = 0, p_linenum = 0}
#8  0x5584b493b05d in exec_mca () at command.c:240
cbuf = 
#9  0x5584b493c74c in mca_char (c=10) at command.c:597
ret = 
ret = 
#10 commands () at command.c:1069
c = 10
action = 
cbuf = 
newaction = 101
save_search_type = 
extra = 0x5584b4b5838c  "o"
tbuf = "s"
parg = {p_string = 0x0, p_int = 0, p_linenum = 0}
old_ifile = 
new_ifile = 
tagfile = 
#11 0x5584b49351c5 in main (argc=, argv=0x7fff29729320) at 
main.c:283
ifile = 0x0
s = 

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

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

Versions of packages less depends on:
ii  debianutils  4.8.6.1
ii  libc62.28-6
ii  libtinfo66.1+20181013-1

less recommends no packages.

less suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/P

Bug#922164: fetchmail: With buster :fetchmail: Erreur de login ou d'identification inconnue pour xx...@pop.free.fr

2019-02-12 Thread Gérard ROBIN
With fetchmail 6.3.26-3 now:

Old UID list from pop.free.fr: 

Scratch list of UIDs: 
fetchmail: 6.3.26 querying pop.free.fr (protocol POP3) at Wed Feb 13 01:28:06 
2019: poll started
Trying to connect to 2a01:e0c:1::110/110...connected.
fetchmail: POP3< +OK POP3 ready <597237147.1550017686@popn1>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< UIDL
fetchmail: POP3< SASL LOGIN PLAIN
fetchmail: POP3< .
fetchmail: POP3> USER x
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK server ready
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for  at pop.free.fr
fetchmail: POP3> QUIT
fetchmail: POP3< +OK pop.free.fr Zimbra POP3 server closing connection
fetchmail: 6.3.26 querying pop.free.fr (protocol POP3) at Wed Feb 13 01:28:06 
2019: poll completed
New UID list from pop.free.fr: 
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)


-- 
Gerard
_
*
*  Created with "mutt 1.10.1-2"
*  under Debian Linux BUSTER 10
*  Registered Linux User #388243
*  https://Linuxcounter.net
*



Bug#922164: fetchmail: With buster :fetchmail: Erreur de login ou d'identification inconnue pour xx...@pop.free.fr

2019-02-12 Thread Gérard ROBIN
Ok László,

Old UID list from pop.free.fr:
 

fetchmail: 6.4.0.beta4 querying pop.free.fr (protocol POP3) at Wed Feb 13 
01:13:20 2019: poll started
Trying to connect to 2a01:e0c:1::110/110...connected.
fetchmail: POP3< +OK POP3 ready <528846432.1550016800@popn1>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< UIDL
fetchmail: POP3< SASL LOGIN PLAIN
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< -ERR invalid command
fetchmail: invalid command
fetchmail: pop.free.fr: upgrade to TLS failed.
fetchmail: Unknown login or authentication error on g.rob...@pop.free.fr
fetchmail: socket error while fetching from x...@pop.free.fr
fetchmail: 6.4.0.beta4 querying pop.free.fr (protocol POP3) at Wed Feb 13 
01:13:20 2019: poll completed
Merged UID list from pop.free.fr:
 
fetchmail: Query status=2 (SOCKET)

and twice the same thing ...

cordially.

-- 
Gerard
_
*
*  Created with "mutt 1.10.1-2"
*  under Debian Linux BUSTER 10
*  Registered Linux User #388243
*  https://Linuxcounter.net
*



Bug#922184: Stretch-backports linux-image-cloud-amd64 broken

2019-02-12 Thread Dean Hamstead

Package: linux-image-cloud-amd64
Severity: critical

In stretch-backports the  linux-image-cloud-amd64 package depends upon  
linux-image-4.19.0-0.bpo.2-cloud-amd64 however that package is not available

See https://packages.debian.org/stretch-backports/linux-image-cloud-amd64

There does seem to be an unsigned version at 
https://packages.debian.org/stretch-backports/linux-image-4.19.0-0.bpo.2-cloud-amd64-unsigned






Bug#922087: runescape: please remove the unnecessary p7zip-full dependency

2019-02-12 Thread Carlos Donizete Froes
Hi Linda,

> currently, src/runescape.sh downloads a .dmg file and extracts it with
> 7z for the jagexappletviewer.jar file. The 7z executable comes from the
> p7zip-full package.
> 
> It would be preferable if the .jar file would be downloaded directly
> from https://www.runescape.com/downloads/jagexappletviewer.jar instead.

Replaced the link to download the .jar file directly from the official website.

Removed the p7zip-full package to extract the .dmg file and also the zenity
command will no longer be useful.

The p7zip-full and zenity packages were removed from the debian/control
dependencies.

Available in the new version of the package[1].

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

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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


Bug#922178: /lib/security/pam_unix.so: cannot open shared object file: No such file or directory

2019-02-12 Thread GSR
Package: libpam-runtime
Version: 1.3.1-1
Followup-For: Bug #922178

Hi:

Same thing. "/etc/init.d/cron restart" seems to get things back to
normal.

Just after upgrade:
---8<---
CRON[12874]: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: 
cannot open shared object file: No such file or directory
CRON[12874]: PAM adding faulty module: pam_unix.so
CRON[12874]: Authentication failure
--->8---

After restarting cron, things work again:
---8<---
CRON[26043]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[26043]: pam_unix(cron:session): session closed for user root
--->8---

Upgrading a package should automatically restart services that depend
on it, like it happens with ssh server.

Thanks,
GSR
 

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libpam-runtime depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  libpam-modules 1.3.1-1

libpam-runtime recommends no packages.

libpam-runtime suggests no packages.

-- debconf information:
  libpam-runtime/conflicts:
  libpam-runtime/title:
  libpam-runtime/override: false
* libpam-runtime/no_profiles_chosen:
  libpam-runtime/you-had-no-auth:
* libpam-runtime/profiles: unix, capability



Bug#922182: linux-image-4.19.0-2-cloud-amd64: Kernel call trace when testing NVME on Azure

2019-02-12 Thread Stephen A. Zarkos
Package: src:linux
Version: 4.19.16-1
Severity: normal

The Azure team ran into the following call trace with the Debian 4.19 kernel 
while validating NVME devices on Microsoft Azure.
The following call trace was observed while running fio on Standard_L64s_v2 
size:

[  651.652598] rcu: INFO: rcu_sched self-detected stall on CPU
[  651.656617] rcu:   8-: (5250 ticks this GP) 
idle=4ce/1/0x4004 softirq=4630/4630 fqs=2527 
[  651.656617] rcu:(t=5256 jiffies g=69713 q=8089)
[  651.684600] Sending NMI from CPU 8 to CPUs 0:
[  651.694277] NMI backtrace for cpu 0
[  651.694278] CPU: 0 PID: 10 Comm: ksoftirqd/0 Not tainted 
4.19.0-0.bpo.1-cloud-amd64 #1 Debian 4.19.12-1~bpo9+1
[  651.694279] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090007  05/18/2018
[  651.694279] RIP: 0010:cpumask_next+0x16/0x20
[  651.694281] Code: 38 22 75 97 eb d4 90 90 90 90 90 90 90 90 90 90 90 90 90 
90 8d 57 01 48 89 f0 be 00 02 00 00 48 89 c7 48 63 d2 e8 2a 51 d8 ff  c3 0f 
1f 84 00 00 00 00 00 55 ba ff ff ff ff 53 48 89 fd 89 f3
[  651.694282] RSP: 0018:9a6adf803ac0 EFLAGS: 0046
[  651.694283] RAX: 0200 RBX: 0002 RCX: 0200
[  651.694284] RDX:  RSI:  RDI: 9a6adf803b10
[  651.694284] RBP: 9a6adf803b10 R08:  R09: 
[  651.694285] R10: 9a6adf803ad0 R11:  R12: 00fd
[  651.694285] R13: 9a6adf803bc0 R14: 0046 R15: 000211c0
[  651.694286] FS:  () GS:9a6adf80() 
knlGS:
[  651.694286] CS:  0010 DS:  ES:  CR0: 80050033
[  651.694286] CR2: 7f215b3d6220 CR3: 00307f486000 CR4: 003406b0
[  651.694287] Call Trace:
[  651.694287]  
[  651.694287]  __send_ipi_mask+0x11e/0x310
[  651.694288]  __send_ipi_one+0x34/0x50
[  651.694288]  hv_send_ipi+0x10/0x30
[  651.694288]  check_preempt_curr+0x4e/0x90
[  651.694289]  ttwu_do_wakeup+0x19/0x140
[  651.694289]  try_to_wake_up+0x1ce/0x4a0
[  651.694289]  autoremove_wake_function+0x11/0x50
[  651.694290]  __wake_up_common+0x96/0x180
[  651.694290]  __wake_up_common_lock+0x7c/0xc0
[  651.694290]  aio_complete+0x17a/0x250
[  651.694291]  blkdev_bio_end_io+0x71/0x140
[  651.694291]  blk_update_request+0x91/0x2d0
[  651.694291]  blk_mq_end_request+0x1a/0xd0
[  651.694292]  nvme_irq+0x119/0x1d0 [nvme]
[  651.694293]  __handle_irq_event_percpu+0x81/0x190
[  651.694297]  handle_irq_event_percpu+0x30/0x80
[  651.694297]  handle_irq_event+0x3c/0x60
[  651.694298]  handle_edge_irq+0x94/0x1f0
[  651.694298]  handle_irq+0x1f/0x30
[  651.694298]  do_IRQ+0x49/0xe0
[  651.694299]  common_interrupt+0xf/0xf


We think this issue can be resolved with the following four upstream patches. I 
think these made it into the 4.20 kernel, but not 4.19:

  git cherry-pick 8ffe4e61c06a48324cfd97f1199bb9838acce2f2
  git cherry-pick 76f99ae5b54d48430d1f0c5512a84da0ff9761e0
  git cherry-pick b82592199032bf7c778f861b936287e37ebc9f62
  git cherry-pick e8da8794a7fd9eef1ec9a07f0d4897c68581c72b





-- Package-specific info:
** Kernel log: boot messages should be attached


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

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

Versions of packages linux-image-4.19.0-2-cloud-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod25-2
ii  linux-base  4.5

Versions of packages linux-image-4.19.0-2-cloud-amd64 recommends:
ii  apparmor 2.13.2-7
ii  firmware-linux-free  3.4
ii  irqbalance   1.5.0-3

Versions of packages linux-image-4.19.0-2-cloud-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02+dfsg1-10
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-2-cloud-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information



Bug#922183: libpam0g: upgrade to 1.3.1-1 breaks running xscreensaver, locking user out of session

2019-02-12 Thread Ben Caradoc-Davies
Package: libpam0g
Version: 1.3.1-1
Severity: grave
Justification: causes non-serious data loss

Dear Maintainer,

after upgrading:

libpam-modules (1.1.8-4 => 1.3.1-1)
libpam-modules-bin (1.1.8-4 => 1.3.1-1)
libpam-runtime (1.1.8-4 => 1.3.1-1)
libpam0g (1.1.8-4 => 1.3.1-1)
libpam0g-dev (1.1.8-4 => 1.3.1-1)

a running xscreensaver instance can no longer authenticate:

Feb 13 10:46:22 ripley xscreensaver[977]: PAM unable to dlopen(pam_unix.so):
/lib/security/pam_unix.so: cannot open shared object file: No such file or
directory
Feb 13 10:46:22 ripley xscreensaver[977]: PAM adding faulty module: pam_unix.so
Feb 13 10:46:22 ripley xscreensaver[977]: FAILED LOGIN 1 ON DISPLAY ":0.0", FOR
"ben"

Workaround is using remote access to kill xscreensaver. After a system restart,
xscreensaver works normally.

In the absence of remote access, a system reset may be required, which may
result in the loss of unsaved user data.

libpam0g upgrade should test for a running xscreensaver instance and require it
to be stopped before upgrade.

Kind regards,
Ben.



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

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

Versions of packages libpam0g depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  libaudit1  1:2.8.4-2
ii  libc6  2.28-7

libpam0g recommends no packages.

Versions of packages libpam0g suggests:
pn  libpam-doc  

-- debconf information:
  libpam0g/restart-services:
* libraries/restart-without-asking: false
  libpam0g/xdm-needs-restart:
  libpam0g/restart-failed:



Bug#908779: bro: CVE-2018-17019: Fix IRC names command parsing

2019-02-12 Thread Hilko Bengen
* Hilko Bengen:

>>> | In Bro through 2.5.5, there is a DoS in IRC protocol names command
>>> | parsing in analyzer/protocol/irc/IRC.cc.
>>
>> ping, can we get this one (and CVE-2018-16807) uploaded still in time
>> for buster?
>
> Working on 2.6.1, but I need to get broker (and a new upstream versio
> nof actor-framework) into unstable first. Working on that, too.

So that didn't work out -- bro/2.6.1 is still sitting in NEW, along with
some of its build-dependencies. :-(

I don't know yet if or when I'll be able to backport fixes for the
outstanding CVE-worthy bugs.

Cheers,
-Hilko



Bug#922084: runescape: ratelimits download speed to 200 kB/s

2019-02-12 Thread Carlos Donizete Froes
Hi Linda,

> src/runescape.sh sets `--limit-rate 200k` on line 27. I have a
> high-speed fiber connection and would like to use it to the full extent,
> as I have previously done with rsu-client (not available in Debian yet).
> This arbitrary limit has not been well explained in the download script.
> 
> Would you consider removing this wget option flag, please? Thanks.

Flag with speed limit removed in wget option. Available in the new version of
the package[1].

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

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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


Bug#922083: runescape: missing wget dependency (debian/control)

2019-02-12 Thread Carlos Donizete Froes
Hi Linda,

> src/runescape.sh calls into wget on line 27. This dependency is not
> listed in the debian/control file.
> 
> wget is installed by default even from the most minimal Debian 9 netinst
> images, but it is not essential to the base operating system and can be
> removed by a system administrator.

Thanks for the alert, it was an oversight where I made a new version of the
package[1] adding that dependency in d/control.

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

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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


Bug#922178: Try reboot

2019-02-12 Thread 積丹尼 Dan Jacobson
Advise users to try rebooting...



Bug#921938: lme4 breaks r-cran-lmertest autopkgtest

2019-02-12 Thread Dirk Eddelbuettel


Paul,

It so happens that I know the R stack pretty well, and I happen to know how
CRAN operates. Getting a new upstream package from CRAN almost always means
that nothing is broken, or that (a rare case) a change affects a downstream
package -- as all this is tested well at CRAN. I am pretty close to that
ecosystem, and there is mutual trust between them and me.

Hence an autopkgtest failing was likely an indication of _our_ downstream
dependencies of this package failing.

And so it was, and that I demonstrated.

By now both these packages have been updated
  https://packages.debian.org/sid/r-cran-lmertest
  https://packages.debian.org/sid/r-cran-mlmrev
and there is still no bug in my package r-cran-lme4. We "merely" have to wait
for testing to receive the newer packages. And then r-cran-lme4 will migrate.
Until there is nothing for me to day, just as there was nothing for me to
five days ago.  It really was an issue in r-cran-{lmertest,mlmrev}.

Hope this helps.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#896189: update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc

2019-02-12 Thread Ivo De Decker
Control: reopen -1

Hi,

On Fri, Apr 20, 2018 at 06:56:24PM +0300, Adrian Bunk wrote:
[...]
> Setting up openmpi-bin (3.0.1-6) ...
> update-alternatives: using /usr/bin/mpirun.openmpi to provide /usr/bin/mpirun 
> (mpirun) in auto mode
> update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave 
> link same as main link /usr/bin/mpicc
> dpkg: error processing package openmpi-bin (--configure):
>  installed openmpi-bin package post-installation script subprocess returned 
> error exit status 2

It seems this issue is back in builds for netpipe:

https://buildd.debian.org/status/fetch.php?pkg=netpipe&arch=amd64&ver=3.7.2-7.4%2Bb5&stamp=1550010019&raw=0

Setting up openmpi-bin (3.1.3-10) ...
update-alternatives: using /usr/bin/mpirun.openmpi to provide /usr/bin/mpirun 
(mpirun) in auto mode
update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link 
same as main link /usr/bin/mpicc
dpkg: error processing package openmpi-bin (--configure):
 installed openmpi-bin package post-installation script subprocess returned 
error exit status 2


Ivo



Bug#922181: RFS: runescape/0.5-1 -- Multiplayer online game set in a fantasy world

2019-02-12 Thread Carlos Donizete Froes
Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: runescape
   Version : 0.5-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/runescape
 * License : BSD-2-Clause
   Section : non-free/games

  It builds those binary packages:

  runescape - Multiplayer online game set in a fantasy world

  To access further information about this package, please visit the following 
URL:

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

  Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/non-free/r/runescape/runescape_0.5-1.dsc

  More information about Old School RuneScape can be obtained from 
https://oldschool.runescape.com.

  Changes since the last upload:

  runescape (0.5-1) unstable; urgency=medium

  * New upstream release
  * Switch to compat level 12
  * debian/control:
+ Declare compliance with Debian Policy 4.3.0
- Removed 'p7zip-full' and 'zenity' in Depends
+ Added 'wget' in Depends
  * Updated name and copyright years in d/upstream/metadata
  * Updated d/watch file

  Regards,
   Carlos Donizete Froes [a.k.a coringao]



Bug#922180: img2pdf: the manpage should refer to img2pdf, not img2pdf.py

2019-02-12 Thread Julian Gilbey
Package: img2pdf
Version: 0.3.3-1
Severity: normal
Tags: patch

Four times in the first 6 lines of img2pdf.1.gz, it says img2pdf.py,
though it is installed in Debian as img2pdf.  So the manpage should be
patched to reflect this.

Something like the following works (in debian/rules, replacing the
existing line):

help2man --no-info --name="lossless conversion of raster images to pdf" 
./src/img2pdf.py | sed -e 's/\.py//ig;' > img2pdf.1

Best wishes,

   Julian



Bug#880245: New version of statsmodels is out possibly fixing important bug - any volunteer

2019-02-12 Thread Stuart Prescott
Hi Andreas,

> Currently the package in Git does not build due to #921779. I admit I
> have no idea why #917754 occures but my comparison with python-cycler
> (which is able to find the module named
> 'matplotlib.sphinxext.only_directives') Gave me some hope that switching
> back from python3-sphinx to python-sphinx will solve this.

matplotlib.sphinxext.only_directives was removed from  matplotlib but you 
should be fairly easily able to fix up the documentation build, for example:

https://sources.debian.org/src/python-periodictable/sid/debian/patches/sphinx-only-directive.patch/

cheers
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#922179: shim-signed depends on packages not repos

2019-02-12 Thread Matthew Crews
Package: shim-signed
Version: 1.28+nmu1+0.9+1474479173.6c180c6-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Attempted to install shim-signed, it depends on:

* shim 0.9+1474479173.6c180c6-1, however version 15+1533136590.3beb971-2 is the 
one in the repos
* secureboot-db, however that package is not in the sid repos at all.

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

N/A

   * What was the outcome of this action?

Failed to install

   * What outcome did you expect instead?

I expected shim-signed to be installable.


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

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

Versions of packages shim-signed depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  grub-efi-amd64-bin 2.02+dfsg1-11
ii  grub2-common   2.02+dfsg1-11
pn  mokutil
ii  shim   15+1533136590.3beb971-2

Versions of packages shim-signed recommends:
pn  secureboot-db  

shim-signed suggests no packages.



Bug#922178: /lib/security/pam_unix.so: cannot open shared object file: No such file or directory

2019-02-12 Thread 積丹尼 Dan Jacobson
Package: libpam-runtime
Version: 1.3.1-1

User does aptitude upgrade.
Upgrade finishes normally.
But user notes cronjobs no longer fire on time...

Looking in the logs,

Feb 13 05:59:01 jidanni5 cron[485]: Authentication failure
Feb 13 05:59:01 jidanni5 CRON[5596]: Authentication failure
Feb 13 06:09:01 jidanni5 CRON[5919]: PAM unable to dlopen(pam_unix.so): 
/lib/security/pam_unix.so: cannot open shared object file: No such file or 
directory
Feb 13 06:09:01 jidanni5 CRON[5919]: PAM adding faulty module: pam_unix.so
Feb 13 06:09:01 jidanni5 cron[485]: Authentication failure
Feb 13 06:09:01 jidanni5 CRON[5919]: Authentication failure



Bug#922168: debian-handbook: FTBFS randomly (dh-strip-nondeterminism fails to handle a PNG file)

2019-02-12 Thread Chris Lamb
tags 922168 + patch
thanks

Hi Santiago,

> > Glancing very quickly at this package, I suspect the PNG is
> > generated correctly (otherwise the PNG handler would typically not
> > be called), but then strip-nondeterminism's parallel executation is
> > choking at the hardlinks that rdfind(1) creates in debian/rules.
> > 
> > If that sounds sensible, please feel free to reassign to dh-strip-
> > nondeterminism (and add an affects to taste).
> 
> Yes, I think it makes sense. Incidentally, I'm currently using
> machines with one core and machines with two cores, but this package
> only failed to build for me on the machines having two cores.

I've got a hacky testcase locally that confirms this. Does this make
sense as a patch, perhaps?

  diff --git a/bin/dh_strip_nondeterminism b/bin/dh_strip_nondeterminism
  index 5c82b16..6f7d693 100755
  --- a/bin/dh_strip_nondeterminism
  +++ b/bin/dh_strip_nondeterminism
  @@ -45,7 +45,7 @@ things to exclude.
   
   init();
   
  -my @nondeterministic_files;
  +my (@nondeterministic_files, %seen);
   
   sub testfile {
return if -l $_ or -d $_; # Skip directories and symlinks always.
  @@ -57,6 +57,11 @@ sub testfile {
return if ($fn=~m/\Q$f\E/);
}
   
  + # Deduplicate hardlinks to avoid issues under parallelism
  + my ($dev, $inode, undef, $nlink) = stat($_);
  + return if defined $nlink && $nlink > 1 && $seen{"$inode.$dev"};
  + $seen{"$inode.$dev"} = 1;
  +
my $normalizer = File::StripNondeterminism::get_normalizer_for_file($_);
if ($normalizer) {
push @nondeterministic_files, [$fn, $normalizer];


Regards,

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



Bug#921938: lme4 breaks r-cran-lmertest autopkgtest

2019-02-12 Thread Paul Gevers
Hi Dirk,

On 10-02-2019 15:20, Dirk Eddelbuettel wrote:
> | Currently this regression is blocking the migration of lme4 to testing
> | [1]. Due to the nature of this issue, I filed this bug report against
> | both packages. Can you please investigate the situation and reassign the
> | bug to the right package? If needed, please change the bug's severity.
> 
> Sorry I don't really have the time for this. I maintain r-cran-lme4; it
> passes.

Although I understand your emotions, this isn't really constructive in
Debian. *Your* package lme4 isn't migrating to testing due to these
regressions. If you want your package in buster, it is better to at
least communicate with your reverse dependencies with regressing
autopkgtests.

> The relevant page for me is
> 
>https://cloud.r-project.org/web/checks/check_results_lme4.html

Well, for me it is https://qa.debian.org/excuses.php?package=lme4 and
your package will not migrate if it remains like that.

> The package has MANY reverse dependencies but I am responsible for
> those. Talk to _their_ maintainers.  Thanks for your understandind.

I do talk to their maintainers by filing this bug report against your
package and their package at the same time. Without inside knowledge of
the r stack I can't judge the situation and I can only assume that you
may have to discuss together how to resolve this issue. Me understanding
you isn't going to have your package migrate, fixing the regression is.

Paul

PS: due to the tone of your response, it took me some days to reply.



signature.asc
Description: OpenPGP digital signature


Bug#921343: nextcloud-desktop: Synchronisation fails with "PROPFIND Reply is not XML Formatted"

2019-02-12 Thread Sandro Knauß
Control: severity -1 normal
Control: forwarded https://github.com/nextcloud/desktop/issues/1025

Hey,
 
> Nextcloud client fails to synchronize files on an up to date Nextcloud
> server (15.0.2.0) with this error:

I can't reproduce this error with Nextcloud 15.0.4.0. This is surely not an 
client error it is a server one. That's why lowering the severity.

> This completely breaks the client and makes it unusable, as
> synchronization simply doesn't happen. It seems earlier versions of this
> package didn't have this problem, as users online report downgrading to
> 2.4.X successfully fixed the problem.

There is no nextcloud desktop 2.4.X, before 2.5.0 there was only owncloud-
client, that was themed for Nextcloud.

regards,

hefee



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


Bug#922177: ubuntu-keyring: postinst script loop loops only once (SC2066)

2019-02-12 Thread Linda Lapinlampi
Source: ubuntu-keyring
Version: 2018.09.18.1-4
Severity: normal

Dear Maintainer,

I noticed ShellCheck was raising an error in debian/*.postinst scripts.

if [ -n "$RET" ]; then
->for keyring in "$RET"
  do
rm -f /etc/apt/trusted.gpg.d/"$keyring".gpg
ln -sf /usr/share/keyrings/"$keyring".gpg /etc/apt/trusted.gpg.d/
  done
fi

The error at pointed arrow is:

> SC2066: Since you double quoted this, it will not word split, and the
> loop will only run once.

I believe this means only one key will be ever installed from debconf
template choice, if multiple answers are given from the multiselect
templates. Removing double quotes should fix the issue.

See: https://github.com/koalaman/shellcheck/wiki/SC2066


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

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



Bug#922176: ubuntu-keyring: apt-config(8)'s Dir::Etc::trustedparts option is ignored

2019-02-12 Thread Linda Lapinlampi
Source: ubuntu-keyring
Version: 2018.09.18.1-4
Severity: important

Dear Maintainer,

in debian/*.postinst files, there is the following line:

ln -sf /usr/share/keyrings/"$keyring".gpg /etc/apt/trusted.gpg.d/

I believe this should actually be:

TRUSTEDPARTS="/etc/apt/trusted.gpg.d/" # fallback if not configured
eval "$(apt-config shell TRUSTEDPARTS Dir::Etc::trustedparts/d)"
ln -sf /usr/share/keyrings/"$keyring".gpg "$TRUSTEDPARTS"


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

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



Bug#921987: mysqld-akonadi: Could not open required defaults file

2019-02-12 Thread Sandro Knauß
Hey,

> I have the same problem and it didn't go away.
> Using the version from testing solved the problem.
> Using the version from sid and the problem reappeared.
> Strace showed the message ACCESS DENIED on
> ~/.local/share/akonadi/mysql.conf. Now, I'm using the version from testing.

do you use mysql or mariadb? Can you debug more into this issue? I can't 
reproduce this issue on sid with mariadb-server 1:10.3.12-2 and apparmor 
2.13.2-7.

hefee


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


Bug#922044: [emacsen-common] dist-upgrade removes emacs-nox due to emacsen-common version in backports

2019-02-12 Thread Martijn de Gouw

Hi Sean,

Thanks a lot for the fast response!

Gr, Martijn

Op 11-02-2019 om 22:22 schreef Sean Whitton:

Hello Martijn,

On Mon 11 Feb 2019 at 03:26PM +01, Martijn de Gouw wrote:


Package: emacsen-common
Version: 3.0.4~bpo9+1
Severity: normal

--- Please enter the report below this line. ---
Hi,

After Debian 9.7 was released I started to dist-upgrade our machines,
but it started to remove all emacs packages. I traced this behaviour
back to the emacsen-common package in stretch-backports.

All emacs packages depend on emacsen-common one way or the other, but
the package in stretch-backports is conflicting with most of them:
emacs19, emacs20, emacs21-common, emacs22-common, emacs23-common,
emacs24-common, emacs25-common, xemacs21-support.

Since there are no other emacs packages in stretch-backports, besides
emacsen-common, I pinned the emacsen-common to version 2.0.8 as a
work-around.


This package shouldn't be in stretch-backports; it was a mistake.  I
have requested removal.

It is possible that there is something wrong with your apt config, as
dist-upgrade shouldn't have caused something like this to happen, but I
can't immediately see how it could have happened.



--
Martijn de Gouw
Designer
Prodrive Technologies
Mobile: +31 63 17 76 161
Phone:  +31 40 26 76 200



Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files

2019-02-12 Thread Reinhard Tartler
Thanks for the review, I've just uploaded it to unstable.

-rt

On 2/12/19 8:13 AM, eamanu15 wrote:
> Oh thanks! I can see now
> 
> Take care that the d/changelog entry is on UNRELEASED;
> 
> Regards
> 
> El mar., 12 de feb. de 2019 a la(s) 09:57, Reinhard Tartler 
> (siret...@tauware.de ) escribió:
> 
> 
> 
> On 2/12/19 7:17 AM, eamanu15 wrote:
> > Hi,
> >
> > The salsa repo is empty.
> >
> > Something is wrong?
> 
> The train station arrived sooner than I could push to salsa. I've just 
> rectified this, the repository is now populated.
> 
> https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz
> 
> Thanks for your interest!
> -rt
> 
> 
> 
> -- 
> Arias Emmanuel
> http://eamanu.com
> Github/Gitlab; @eamanu
> Debian: @eamanu-guest



Bug#922174: arctica-greeter-theme-debian-futureprototype: Typo in package description

2019-02-12 Thread Thomas Vincent
Package: arctica-greeter-theme-debian-futureprototype
Severity: minor

Dear Maintainer,

I noticed a typo in the long description of the package. Indeed, there's an 
extra 'r' at "furturePrototype", which should be spelled "futurePrototype" 
instead.

Thanks a lot for maintaining the arctica-greeter* packages!

Cheers,
Thomas


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

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



Bug#922175: iipimage-server systemd support

2019-02-12 Thread Ruven
Package: iipimage-server
Version: 1.0-1+deb9u1
Severity: wishlist


It would be nice to have systemd support for the iipimage-server
package. I've attached a service file (iipsrv.service) for
/lib/systemd/system/ and an environment file (iipsrv) for /etc/default/
containing runtime parameters for iipsrv.

These allow the iipsrv process to be started independently of a web
server via systemd.

[Install]
WantedBy=multi-user.target

[Unit]
Description=IIPImage server
After=network.target
Documentation=https://iipimage.sourceforge.io man:iipsrv(8)

[Service]
User=www-data
Group=www-data
EnvironmentFile=/etc/default/iipsrv
ExecStart=/usr/lib/iipimage-server/iipsrv.fcgi --bind 0.0.0.0:9000 --backlog 1024
Restart=on-failure

VERBOSITY=1
LOGFILE=/var/log/iipsrv.log
MAX_IMAGE_CACHE_SIZE=10
JPEG_QUALITY=90
MAX_CVT=5000
MEMCACHED_SERVERS=localhost



Bug#918623: dizzy: Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT

2019-02-12 Thread Florian Schlichting
> > It's probably a bit late in the release cycle to "just find out" by
> > uploading a -2 with that modified patch.
> 
> ... but its even worse to do nothing since this is an RC bug and this
> package as well as its rdepends would be excluded from next release if
> the bug is not fixed.

I'm coming to the same conclusion, so here we go - upload coming
shortly...

Florian



Bug#919356: Licensing of include/linux/hash.h

2019-02-12 Thread Ben Finney
Jens Axboe  writes:

> On 2/11/19 11:27 PM, Ben Finney wrote:
> > If, on the other hand, the file is to be free software, there would need
> > to be a clear grant of some free software license to that work.
>
> FWIW, fio.c includes the following mention:
>
>  * The license below covers all files distributed with fio unless otherwise
>  * noted in the file itself.
>
> followed by the GPL v2 license.

Great! That does appear to be a positive assertion from the copyright
holder, that we have a grant to use that work under GPLv2.

That written grant of license can be used in the Debian package to
demonstrate our license to the work.

> I'll go through and add SPDX headers to everything to avoid wasting
> anymore time on this nonsense.

Not necessary from my point of view for this specific case, because we
have the clear explicit grant of license. Don't let me stop you from
doing the good work of documenting more clearly :-)

-- 
 \   “Come on Milhouse, there’s no such thing as a soul! It’s just |
  `\  something they made up to scare kids, like the Boogie Man or |
_o__)  Michael Jackson.” —Bart, _The Simpsons_ |
Ben Finney



Bug#922173: pkg-config: upgrade pkg-config to version 0.29.2

2019-02-12 Thread Jochen Sprickerhof
Package: pkg-config
Version: 0.29-6
Severity: wishlist

Dear maintainer,

could you please upgrade pkg-config to the latest upstream version
0.29.2?

you could use this debian/watch file to easy finding (and integrating)
new versions:

version=4
https://pkg-config.freedesktop.org/releases/ \
pkg-config-([\d\.]+)\.tar\.gz debian uupdate


Thanks!

Jochen

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

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

Versions of packages pkg-config depends on:
ii  libc6 2.28-7
ii  libdpkg-perl  1.19.4
ii  libglib2.0-0  2.58.3-1

pkg-config recommends no packages.

Versions of packages pkg-config suggests:
ii  dpkg-dev  1.19.4

-- no debconf information



Bug#922171: autopkgtest-build-lxc: Network availability test fails

2019-02-12 Thread Christian Kastner
On Tue, 12 Feb 2019 22:29:00 +0100 Christian Kastner  wrote:
> see attached patch.

I was a bit too hasty. Here's a patch that works for both old and new
option names.
>From 20746a2b3a323bac12c8bcfe9b9206f8474b0268 Mon Sep 17 00:00:00 2001
From: Christian Kastner 
Date: Tue, 12 Feb 2019 22:18:27 +0100
Subject: [PATCH] lxc/default.conf: lxc.network.type is now lxc.net.0.type

This was introduced to package lxc by commit ba9e2543.
---
 tools/autopkgtest-build-lxc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/autopkgtest-build-lxc b/tools/autopkgtest-build-lxc
index c63c945..8b9d9d1 100755
--- a/tools/autopkgtest-build-lxc
+++ b/tools/autopkgtest-build-lxc
@@ -32,10 +32,12 @@ if [ -z "$1" ] || [ -z "$2" ]; then
 fi
 
 # check that LXC config has networking
-if grep -q 'lxc.network.type *= *empty' /etc/lxc/default.conf; then
+if grep -q 'lxc.net.0.type *= *empty' /etc/lxc/default.conf ||
+   grep -q 'lxc.network.type *= *empty' /etc/lxc/default.conf; then
 cat <&2
 ERROR: autopkgtest containers need networking; please set it up and adjust
-lxc.network.type in /etc/lxc/default.conf
+lxc.net.0.type in /etc/lxc/default.conf (or lxc.network.type in earlier
+versions)
 EOF
 exit 1
 fi
-- 
2.20.1



Bug#921382: kineticstools: autopkgtest needs update for new version of h5py

2019-02-12 Thread Paul Gevers
Hi Andreas,

On 12-02-2019 14:29, Andreas Tille wrote:
> thanks a lot for this bug report.  I'd love to fix this but I have no
> idea what to do.  Any hint from h...@packages.debian.org ?

I don't want to offend you, but did you look at the error message? I
think it tells you what to do: "dataset.value has been deprecated. Use
dataset[()] instead". I assume you should replace calls like
dataset.value() with dataset[()].

If you really don't know how to fix the issue, I guess you could reduce
the log-level in your test cases.

Remember, you are blocking h5py from migrating with your autopkgtest.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#922168: debian-handbook: FTBFS randomly (dh-strip-nondeterminism fails to handle a PNG file)

2019-02-12 Thread Santiago Vila
reassign 922168 dh-strip-nondeterminism
affects 922168 src:debian-handbook
found 922168 1.1.0-1
thanks

On Tue, Feb 12, 2019 at 10:26:58PM +0100, Chris Lamb wrote:

> Glancing very quickly at this package, I suspect the PNG is
> generated correctly (otherwise the PNG handler would typically not
> be called), but then strip-nondeterminism's parallel executation is
> choking at the hardlinks that rdfind(1) creates in debian/rules.
> 
> If that sounds sensible, please feel free to reassign to dh-strip-
> nondeterminism (and add an affects to taste).

Yes, I think it makes sense. Incidentally, I'm currently using
machines with one core and machines with two cores, but this package
only failed to build for me on the machines having two cores.

So, reassigning as suggested.

Thanks a lot.



Bug#922171: autopkgtest-build-lxc: Network availability test fails

2019-02-12 Thread Paul Gevers
Hi Christian,

On 12-02-2019 22:29, Christian Kastner wrote:
> autopkgtest-build-lxc checks for an empty lxc.network.type in
> /etc/lxc/default.conf, but this has been renamed to lxc.net.0.type in
> lxc 3.0.2, see attached patch.

How about the lxc in stable (we provide backport support)? I assume the
patch need to be adapted to check for both in a smart way.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#922172: [src:knot-resolver] autopkgtest fails with knot 2.7.6-1

2019-02-12 Thread Maximilian Engelhardt
Package: src:knot-resolver
Version: 3.2.0-1
Severity: important
Tags: patch
Control: affects -1 knot

I'm nut sure about the correct severity, so I'm filing this as important. Feel 
free to adjust.

With knot   2.7.6-1 (currently in unstable) autopkgtest for knot-resolver 
fails:

https://ci.debian.net/data/autopkgtest/testing/amd64/k/knot-resolver/1912888/log.gz

The problem is a change in behavior of kdig. A patch for the autopkgtest of 
knot-resolver can be found here:

https://salsa.debian.org/dns-team/knot-resolver/merge_requests/1

Thanks,
Maxi

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


Bug#880638: release-notes: Document apt sandbox support [buster]

2019-02-12 Thread Niels Thykier
On Fri, 03 Nov 2017 07:37:12 +0100 Niels Thykier  wrote:
> Package: release-notes
> Severity: wishlist
> 
> --- News for apt (libapt-pkg5.0 libapt-inst2.0) ---
> apt (1.6~alpha1) unstable; urgency=medium
> 
>   All methods provided by apt except for cdrom, gpgv, and rsh now
>   use seccomp-BPF sandboxing to restrict the list of allowed system
>   calls, and trap all others with a SIGSYS signal. Three options
>   can be used to configure this further:
> 
> APT::Sandbox::Seccomp is a boolean to turn it on/off
> APT::Sandbox::Seccomp::Trap is a list of names of more syscalls to trap
> APT::Sandbox::Seccomp::Allow is a list of names of more syscalls to allow
> 
>   Also, sandboxing is now enabled for the mirror method.
> 
>  -- Julian Andres Klode   Mon, 23 Oct 2017 01:58:18 +0200
> 
> 
> Seems like it would be prudent to mention that in the release-notes
> for buster.
> 
> Thanks,
> ~Niels
> 
> 

Note tos self/update: The feature is (now) *off* by default (see #890489).

Thanks,
~Niels



Bug#920643: mariadb-server-10.3: mariadb won't start when running inside an lxc container when running on debian testing

2019-02-12 Thread Matthew Darwin

Hello Faustin,

I am unfamiliar with how libvirt works, so I cannot say.

I have debian testing running on the hardware and inside the 
container.  Everything is from official repo.  I can get mariadb to 
start by messing around with the systemd startup script.


This may entirely be a an apparmor/systemd issue and nothing to to 
with mariadb.  But I'm not clear if mariadb systemd configuration is 
doing something unexpected or not.


It works, if I create /var/run/mysqld by hand, and then use this 
/lib/systemd/system/mariadb.service:


[Unit]
Description=MariaDB 10.3.12 database server
Documentation=man:mysqld(8)
Documentation=https://mariadb.com/kb/en/library/systemd/
After=network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service
Alias=mysqld.service

[Service]
Type=notify
PrivateNetwork=false
User=mysql
Group=mysql
CapabilityBoundingSet=CAP_IPC_LOCK
PermissionsStartOnly=true
ExecStartPre=/bin/sh -c "systemctl unset-environment 
_WSREP_START_POSITION"

ExecStartPre=/bin/sh -c "[ ! -e /usr/bin/galera_recovery ] && VAR= || \
 VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] \
 && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1"
ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER 
$_WSREP_START_POSITION

ExecStartPost=/etc/mysql/debian-start
ExecStartPost=/bin/sh -c "systemctl unset-environment 
_WSREP_START_POSITION"

KillSignal=SIGTERM
SendSIGKILL=no
Restart=on-abort
RestartSec=5s
UMask=007
PrivateTmp=false
LimitNOFILE=16364


On 2019-02-11 11:35 a.m., Faustin Lammler wrote:

Hi Matthew,
Thanks for your report!

I have no platform setup to test this so I have to install one but I am
not a LXC expert. Do you think this could be tested into a libvirt VM?

If I understand correctly, you have a Debian testing host and you are
running an LXC container with 10.3 mariadb version (everything from
official Debian repositories?).

This (https://github.com/lxc/lxc/pull/2758) seems to indicate that
problem may rather come from apparmor/systemd but I will try to
reproduce your issue.

Regards,
Faustin


Bug#897919: Solution now possible?

2019-02-12 Thread Dr. Tobias Quathamer
Am 12.02.2019 um 19:32 schrieb Helge Kreutzmann:
> Hallo Tobias,
> with the recent redesign of the upstream layout I think this bug could
> be solved. In you next backport upload could you check this and close
> this bug? 
> 
> If you don't have the possibility to check I can check it once the
> package hits the backport archive.
> 
> If it's not possible or feasibly to close (this) bug in a backport
> upload, this can be done manually later of course.
> 
> Thanks and greetings
> 
> Helge

Hi Helge,

yes, this bug has finally been solved. The new upload for backports just
hit the archive.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature


Bug#922168: debian-handbook: FTBFS randomly (dh-strip-nondeterminism fails to handle a PNG file)

2019-02-12 Thread Chris Lamb
Hi Santiago,

> My theory is that the PNG is generated incorrectly, but on the other
> hand, dh_strip_nondeterminism should not fail when it sees something
> which is not able to "strip".

Glancing very quickly at this package, I suspect the PNG is
generated correctly (otherwise the PNG handler would typically not
be called), but then strip-nondeterminism's parallel executation is
choking at the hardlinks that rdfind(1) creates in debian/rules.

If that sounds sensible, please feel free to reassign to dh-strip-
nondeterminism (and add an affects to taste).


Regards,

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



Bug#922171: autopkgtest-build-lxc: Network availability test fails

2019-02-12 Thread Christian Kastner
Package: autopkgtest
Version: 5.8
Severity: normal
Tags: patch

autopkgtest-build-lxc checks for an empty lxc.network.type in
/etc/lxc/default.conf, but this has been renamed to lxc.net.0.type in
lxc 3.0.2, see attached patch.

autopkgtest-build-lxc thus continues on and errors out when attempting
apt stuff.

Regards,
Christian
>From b4834e41736131a3889c964c60f468a4c42d49e1 Mon Sep 17 00:00:00 2001
From: Christian Kastner 
Date: Tue, 12 Feb 2019 22:18:27 +0100
Subject: [PATCH] lxc/default.conf: lxc.network.type is now lxc.net.0.type

This was introduced to package lxc by commit ba9e2543.
---
 tools/autopkgtest-build-lxc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/autopkgtest-build-lxc b/tools/autopkgtest-build-lxc
index c63c945..787e814 100755
--- a/tools/autopkgtest-build-lxc
+++ b/tools/autopkgtest-build-lxc
@@ -32,7 +32,7 @@ if [ -z "$1" ] || [ -z "$2" ]; then
 fi
 
 # check that LXC config has networking
-if grep -q 'lxc.network.type *= *empty' /etc/lxc/default.conf; then
+if grep -q 'lxc.net.0.type *= *empty' /etc/lxc/default.conf; then
 cat <&2
 ERROR: autopkgtest containers need networking; please set it up and adjust
 lxc.network.type in /etc/lxc/default.conf
-- 
2.20.1



Bug#922170: nmu: Four packages for golang

2019-02-12 Thread Moritz Muehlenhoff
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

These packages need to be rebuilt to pick up the recent golang DSA:

nmu acmetool_0.0.58-5 . ANY . stretch . -m "rebuilt against current golang"
nmu chasquid_0.01+git20161124.6479138-2 . ANY . stretch . -m "rebuilt against 
current golang"
nmu heartbleeder_0.1.1-5 . ANY . stretch . -m "rebuilt against current golang"
nmu mongo-tools_3.2.11-1 . ANY . stretch . -m "rebuilt against current golang"

Cheers,
Moritz



Bug#821397: sway 1.0-rc2

2019-02-12 Thread Sean Whitton
Hello Birger,

On Tue 12 Feb 2019 at 07:56PM +01, Birger Schacht wrote:

> I've now removed the sed line alltogether- I didn't find a solution
> without adding a patch that would have to be updated with every release.
> Maybe there is a way to override the project_version with meson command
> line flag, but i wasn't able to find anything. And I'm not sure how much
> value it adds if sway --version adds the ~rc2 to the output and if so,
> that should probably be fixed upstream.

I think it adds quite a bit of value, and of course it should be fixed
upstream at some point, if not immediately.

Could you file an upstream bug, please?

Uploaded to DELAYED/1.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#922139: Typo fixes

2019-02-12 Thread Anders Jonsson

Hi Martin,
attached file fixes two typos in the translation (applkation -> 
applikation; fortfande->fortfarande )



Regards,
Anders Jonsson
# Translation of minissdpd debconf template to Swedish
# Copyright (C) 2019 Martin Bagge 
# This file is distributed under the same license as the minissdpd package.
#
# Martin Bagge , 2019
msgid ""
msgstr ""
"Project-Id-Version: minissdpd\n"
"Report-Msgid-Bugs-To: miniss...@packages.debian.org\n"
"POT-Creation-Date: 2019-01-31 14:58+0800\n"
"PO-Revision-Date: 2019-02-12 21:49+0100\n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: debian-l10n-swed...@lists.debian.org\n"
"X-Generator: Poedit 2.2.1\n"

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid "MiniSSDP daemon configuration"
msgstr "Inställningar för MiniSSDP-tjänsten"

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"The MiniSSDP daemon is being installed (perhaps as a dependency for UPnP "
"support) but will not function correctly until it is configured."
msgstr ""
"Tjänsten MiniSSDP installeras (kanske som beroende för UPnP-stöd) men kommer "
"inte fungera korrekt innan den fått inställningar angivna."

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"MiniSSDP is a daemon used by MiniUPnPc to speed up device discovery. For "
"security reasons, no out-of-box default configuration can be provided, so it "
"requires manual configuration."
msgstr ""
"MiniSSDP är en tjänst som används av MiniUPnPc för att snabba upp "
"upptäckandet av enheter. Av säkerhetsskäl finns ingen standardinställning så "
"allt behöver hanteras manuellt."

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"Alternatively you can simply override the recommendation and remove "
"MiniSSDP, or leave it unconfigured - it won't work, but MiniUPnPc (and UPnP "
"applications) will still function properly despite some performance loss."
msgstr ""
"Alternativt så kan du avvisa rekommendationen och ta bort MiniSSDP, eller "
"lämna den utan inställningar - då kommer den inte fungera men MiniUPnPc (och "
"UPnP-applikationer) kommer fortfarande fungera med viss prestandaförlust."

#. Type: boolean
#. Description
#: ../minissdpd.templates:3001
msgid "Start the MiniSSDP daemon automatically?"
msgstr "Starta MiniSSDP-tjänsten automatiskt?"

#. Type: boolean
#. Description
#: ../minissdpd.templates:3001
msgid ""
"Choose this option if the MiniSSDP daemon should start automatically, now "
"and at boot time."
msgstr ""
"Välj detta alternativ om MiniSSDP-tjänsten ska starta automatiskt - nu och "
"vid uppstart."

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid "Interfaces to listen on for UPnP queries:"
msgstr "Gränssnitt att lyssna på UPnP-förfrågningar:"

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid ""
"The MiniSSDP daemon will listen for requests on one interface, and drop all "
"queries that do not come from the local network. Please enter the LAN "
"interfaces or IP addresses of those interfaces (in CIDR notation) that it "
"should listen on, separated by space."
msgstr ""
"MiniSSDP-tjänsten kommer att lyssna på förfrågningar på ett gränssnitt och "
"slänga alla förfrågningar som inte kommer från det lokala nätverket. Ange "
"LAN-gränssnitt och IP-adresser (i CIDR) som tjänsten ska lyssna på."

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid ""
"Interface names are highly preferred, and required if you plan to enable "
"IPv6 port forwarding."
msgstr ""
"Namn på gränssnitt är att föredra och krävs för att stödja portförmedling i "
"IPv6."

#. Type: boolean
#. Description
#: ../minissdpd.templates:5001
msgid "Enable IPv6 listening?"
msgstr "Lyssna på IPv6?"

#. Type: boolean
#. Description
#: ../minissdpd.templates:5001
msgid ""
"Please specify whether the MiniSSDP daemon should listen for IPv6 queries."
msgstr "Ange om MiniSSDP-tjänsten ska lyssna på förfrågningar på IPv6."


Bug#922141: [Pkg-freeipa-devel] Bug#922141: ipa-client-install: Joining realm failed: HTTP response code is 500, not 200

2019-02-12 Thread Timo Aaltonen
On 12.2.2019 17.39, jvermeulen wrote:
> HTTP response code is 500, not 200

what's your server?

this should be fixed since a few years ago:
https://pagure.io/freeipa/issue/5653

and is a server bug, not client

-- 
t



Bug#922167: kwalletcli FTCBFS: use build arch build tools

2019-02-12 Thread Thorsten Glaser
tags 922167 + pending
thanks

Hi Helmut,

>kwalletcli fails to cross build from source, because it hard codes build
>architecture build tools in a number of places. The attached patch fixes
>all of them and makes kwalletcli cross buildable. Please consider

thanks for the patch! I’ll apply something like it post-buster.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999



Bug#922168: debian-handbook: FTBFS randomly (dh-strip-nondeterminism fails to handle a PNG file)

2019-02-12 Thread Santiago Vila
Package: debian-handbook,dh-strip-nondeterminism
Tags: ftbfs

Dear maintainer:

I tried to build "debian-handbook" in buster but it failed:

-
 dh_strip_nondeterminism
 dh_strip_nondeterminism:
debian/debian-handbook/usr/share/doc/debian-handbook/html/en-US/Common_Content/images/stock-go-back.png:
debian/debian-handbook/usr/share/doc/debian-handbook/html/en-US/Common_Content/images/stock-go-back.png:
does not appear to be a PNG at
/usr/share/perl5/File/StripNondeterminism/handlers/png.pm line 83.

dh_strip_nondeterminism: Aborting due to earlier error
make: *** [debian/rules:8: binary] Error 29
-

I've put two build logs here, from my own autobuilders:

https://people.debian.org/~sanvila/build-logs/debian-handbook/

but this randomness also happens here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/debian-handbook.html

My theory is that the PNG is generated incorrectly, but on the other
hand, dh_strip_nondeterminism should not fail when it sees something
which is not able to "strip".

If you can determine that this is both a bug in debian-handbook and a
bug in dh-strip-nondeterminism, please use "clone" and "affects".

Also, if for whatever reason you could not reproduce the randomness,
please contact me privately and I will gladly offer ssh access to a
system where this randomness happens.

Thanks.



Bug#922169: lxc: rexec callers as memfd

2019-02-12 Thread Salvatore Bonaccorso
Source: lxc
Version: 1:3.1.0+really3.0.3-2
Severity: important
Tags: patch security upstream

Hi

LXC is similarly impacted as runC for the CVE-2019-5736 issue. Though,
as explained in the commit message of the upstream commit[1], "LXC is
also impacted in a similar manner by this vulnerability, however as
the LXC project considers privileged containers to be unsafe no CVE
has been assigned for this issue for LXC."

Ideally still to be adressed in time for buster.

Regards,
Salvatore

 [1] https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d



Bug#922112: Fwd: Re: Bug#919356: Licensing of include/linux/hash.h

2019-02-12 Thread Martin Steigerwald
If bouncing does not work, this will do.
-- 
Martin--- Begin Message ---
On 2/11/19 11:27 PM, Ben Finney wrote:
> Martin Steigerwald  writes:
> 
>> Well the file has in its header:
>>
>> /* Fast hashing routine for a long.
>>(C) 2002 William Lee Irwin III, IBM */
>>
>> /*
>>  * Knuth recommends primes in approximately golden ratio to the maximum
>>  * integer representable by a machine word for multiplicative hashing.
>>  * Chuck Lever verified the effectiveness of this technique:
>>  * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf
>>  *
>>  * These primes are chosen to be bit-sparse, that is operations on
>>  * them can use shifts and additions instead of multiplications for
>>  * machines where multiplications are slow.
>>  */
>>
>> It has been quite a while ago. I bet back then I did not regard this
>> as license information since it does not specify a license. Thus I
>> assumed it to be GPL-2 as the other files which have no license boiler
>> plate. I.e.: Check file is it has different license, if not, then
>> assume it has license as specified in COPYING.
>>
>> Not specifying a license can however also mean in this context that it
>> has no license as the file contains copyright information from another
>> author.
> 
> If a work (even one file) “has no license”, that means no special
> permissions are granted and normal copyright applies: All rights
> reserved, i.e. not redistributable. So, no license is grounds to
> consider a work non-free and non-redistributable.
> 
> If, on the other hand, the file is to be free software, there would need
> to be a clear grant of some free software license to that work.
> 
> Given the confusion over this file, I would consider it a significant
> risk to just assume we have GPLv2 permissions without being told that
> explicitly by the copyright holder. Rather, the reason we are seeking a
> clearly-granted free license for this one file, is because we are trying
> to replace a probably non-free file with the same code in it.
> 
> It seems we need to keep looking, and in the meantime assume we have no
> free license in this file.

FWIW, fio.c includes the following mention:

 * The license below covers all files distributed with fio unless otherwise
 * noted in the file itself.

followed by the GPL v2 license. I'll go through and add SPDX headers to
everything to avoid wasting anymore time on this nonsense.
 
-- 
Jens Axboe

--- End Message ---


Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

2019-02-12 Thread Jonas Smedegaard
Quoting Jonas Smedegaard (2019-02-12 19:38:57)
> [ adding d-devel@ to the discussion ]
> 
> Quoting Linda Lapinlampi (2019-02-12 18:51:39)
> > The Matrix.org Debian package repository distributes digitally signed 
> > releases of Matrix.org related packages. This package contains the 
> > archive key used to verify those files, required by apt(8).
> 
> I believe this package belongs in contrib, as its only use-case is with 
> together with software outside of Debian main.

...and now posting to the actual bugreport as well.

 - Jonas

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

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


signature.asc
Description: signature


Bug#919356: dwarves-dfsg: Copyright/licensing is unclear

2019-02-12 Thread Martin Steigerwald
Sorry, last mail should have gone to bug 922112 and have been a real 
bounce so that it is clear that it is from Jens. Somehow the initial 
bounce did not appear on bug 922112 so far.

Sorry for the noise.
-- 
Martin



Bug#922164: fetchmail: With buster :fetchmail: Erreur de login ou d'identification inconnue pour xx...@pop.free.fr

2019-02-12 Thread GCS
Control: tags -1 +moreinfo

Hi Gérard,

On Tue, Feb 12, 2019 at 9:24 PM Gérard ROBIN  wrote:
> I use buster (testing) and after last upgrade I get :
>
> fetchmail: pop.free.fr: passage au TLS raté.
> fetchmail: Erreur de login ou d'identification inconnue pour x...@pop.free.fr
 Can you please try the following and post the result?
$ env LC_ALL=C fetchmail -v -v -v  --nodetach --nosyslog -b 2

> I just installed fetchmail 6.3.26-3 (stretch) and  now it works fine.
 Can you try the same with that version as well?

Thanks,
Laszlo/GCS



Bug#919356: Licensing of include/linux/hash.h

2019-02-12 Thread Martin Steigerwald
Jens Axboe - 12.02.19, 17:16:
> On 2/11/19 11:27 PM, Ben Finney wrote:
> > Martin Steigerwald  writes:
> >> Well the file has in its header:
> >> 
> >> /* Fast hashing routine for a long.
> >> 
> >>(C) 2002 William Lee Irwin III, IBM */
> >> 
> >> /*
> >> 
> >>  * Knuth recommends primes in approximately golden ratio to the
> >>  maximum * integer representable by a machine word for
> >>  multiplicative hashing. * Chuck Lever verified the effectiveness
> >>  of this technique:
> >>  * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf
> >>  *
> >>  * These primes are chosen to be bit-sparse, that is operations on
> >>  * them can use shifts and additions instead of multiplications for
> >>  * machines where multiplications are slow.
> >>  */
> >> 
> >> It has been quite a while ago. I bet back then I did not regard
> >> this
> >> as license information since it does not specify a license. Thus I
> >> assumed it to be GPL-2 as the other files which have no license
> >> boiler plate. I.e.: Check file is it has different license, if
> >> not, then assume it has license as specified in COPYING.
> >> 
> >> Not specifying a license can however also mean in this context that
> >> it has no license as the file contains copyright information from
> >> another author.
> > 
> > If a work (even one file) “has no license”, that means no special
> > permissions are granted and normal copyright applies: All rights
> > reserved, i.e. not redistributable. So, no license is grounds to
> > consider a work non-free and non-redistributable.
> > 
> > If, on the other hand, the file is to be free software, there would
> > need to be a clear grant of some free software license to that
> > work.
> > 
> > Given the confusion over this file, I would consider it a
> > significant
> > risk to just assume we have GPLv2 permissions without being told
> > that
> > explicitly by the copyright holder. Rather, the reason we are
> > seeking a clearly-granted free license for this one file, is
> > because we are trying to replace a probably non-free file with the
> > same code in it.
> > 
> > It seems we need to keep looking, and in the meantime assume we have
> > no free license in this file.
> 
> FWIW, fio.c includes the following mention:
> 
>  * The license below covers all files distributed with fio unless
> otherwise * noted in the file itself.
> 
> followed by the GPL v2 license. I'll go through and add SPDX headers
> to everything to avoid wasting anymore time on this nonsense.

Thank you, Jens, for settling this. I did not remember that one. It may 
very well be that I have seen this note as I initially packaged fio as my 
first package for Debian about 10 years ago.

I forwarded your mail and the one from Domenico with the SPDX patch to 
Debian bug

#922112 fio: hash.h is not DFSG compliant
https://bugs.debian.org/922112

which I closed before as you told already that hash.c is GPL-2.

Thanks,
-- 
Martin



Bug#919356: Licensing of include/linux/hash.h

2019-02-12 Thread Martin Steigerwald
On 2/11/19 11:27 PM, Ben Finney wrote:
> Martin Steigerwald  writes:
> 
>> Well the file has in its header:
>>
>> /* Fast hashing routine for a long.
>>(C) 2002 William Lee Irwin III, IBM */
>>
>> /*
>>  * Knuth recommends primes in approximately golden ratio to the 
maximum
>>  * integer representable by a machine word for multiplicative 
hashing.
>>  * Chuck Lever verified the effectiveness of this technique:
>>  * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf
>>  *
>>  * These primes are chosen to be bit-sparse, that is operations on
>>  * them can use shifts and additions instead of multiplications for
>>  * machines where multiplications are slow.
>>  */
>>
>> It has been quite a while ago. I bet back then I did not regard this
>> as license information since it does not specify a license. Thus I
>> assumed it to be GPL-2 as the other files which have no license boiler
>> plate. I.e.: Check file is it has different license, if not, then
>> assume it has license as specified in COPYING.
>>
>> Not specifying a license can however also mean in this context that 
it
>> has no license as the file contains copyright information from another
>> author.
> 
> If a work (even one file) “has no license”, that means no special
> permissions are granted and normal copyright applies: All rights
> reserved, i.e. not redistributable. So, no license is grounds to
> consider a work non-free and non-redistributable.
> 
> If, on the other hand, the file is to be free software, there would 
need
> to be a clear grant of some free software license to that work.
> 
> Given the confusion over this file, I would consider it a significant
> risk to just assume we have GPLv2 permissions without being told that
> explicitly by the copyright holder. Rather, the reason we are seeking 
a
> clearly-granted free license for this one file, is because we are 
trying
> to replace a probably non-free file with the same code in it.
> 
> It seems we need to keep looking, and in the meantime assume we have 
no
> free license in this file.

FWIW, fio.c includes the following mention:

 * The license below covers all files distributed with fio unless 
otherwise
 * noted in the file itself.

followed by the GPL v2 license. I'll go through and add SPDX headers to
everything to avoid wasting anymore time on this nonsense.
 
-- 
Jens Axboe



Bug#922167: kwalletcli FTCBFS: use build arch build tools

2019-02-12 Thread Helmut Grohne
Source: kwalletcli
Version: 3.02-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

kwalletcli fails to cross build from source, because it hard codes build
architecture build tools in a number of places. The attached patch fixes
all of them and makes kwalletcli cross buildable. Please consider
applying it.

Helmut
diff --minimal -Nru kwalletcli-3.02/debian/changelog 
kwalletcli-3.02/debian/changelog
--- kwalletcli-3.02/debian/changelog2019-01-05 11:48:02.0 +0100
+++ kwalletcli-3.02/debian/changelog2019-02-12 21:22:46.0 +0100
@@ -1,3 +1,10 @@
+kwalletcli (3.02-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Seed tools from dpkg's buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 12 Feb 2019 21:22:46 +0100
+
 kwalletcli (3.02-1) unstable; urgency=medium
 
   * New upstream release, compatible with recent GNU groff in sid
diff --minimal -Nru kwalletcli-3.02/debian/patches/cross.patch 
kwalletcli-3.02/debian/patches/cross.patch
--- kwalletcli-3.02/debian/patches/cross.patch  1970-01-01 01:00:00.0 
+0100
+++ kwalletcli-3.02/debian/patches/cross.patch  2019-02-12 21:22:46.0 
+0100
@@ -0,0 +1,19 @@
+--- kwalletcli-3.02.orig/GNUmakefile
 kwalletcli-3.02/GNUmakefile
+@@ -47,7 +47,7 @@
+ LDADD+=   -lkdeui -lkdecore -lQtCore
+ else
+ ifeq (${KDE_VER},5)
+-KDE_INCS?=$(shell pkg-config --cflags Qt5Gui) -I/usr/include/KF5/KI18n \
++KDE_INCS?=$(shell $(PKG_CONFIG) --cflags Qt5Gui) -I/usr/include/KF5/KI18n 
\
+   -I/usr/include/KF5/KCoreAddons -I/usr/include/KF5/KWallet
+ SRCS+=kwif5.cc
+ OBJS+=kwif5.o
+@@ -62,6 +62,7 @@
+ 
+ CC?=  gcc
+ CXX?= g++
++PKG_CONFIG?=  pkg-config
+ 
+ CFLAGS?=  -O2
+ CXXFLAGS?=${CFLAGS}
diff --minimal -Nru kwalletcli-3.02/debian/patches/series 
kwalletcli-3.02/debian/patches/series
--- kwalletcli-3.02/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ kwalletcli-3.02/debian/patches/series   2019-02-12 21:22:46.0 
+0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru kwalletcli-3.02/debian/rules kwalletcli-3.02/debian/rules
--- kwalletcli-3.02/debian/rules2019-01-05 11:39:09.0 +0100
+++ kwalletcli-3.02/debian/rules2019-02-12 21:22:46.0 +0100
@@ -14,8 +14,10 @@
 shellescape='$(subst ','\'',$(1))'
 shellexport=$(1)=$(call shellescape,${$(1)})
 
+-include /usr/share/dpkg/buildtools.mk
 CC?=   gcc
 CXX?=  g++
+PKG_CONFIG?=   pkg-config
 EXTRA_CFLAGS=  -Wall
 EXTRA_CXXFLAGS=-Wall
 EXTRA_LDFLAGS= -Wl,--as-needed
@@ -52,8 +54,8 @@
 
 .build_done:
dh_testdir
-   $(foreach i,CC CXX CPPFLAGS CFLAGS CXXFLAGS LDFLAGS,$(call 
shellexport,$i)); \
-   export CC CXX CPPFLAGS CFLAGS CXXFLAGS LDFLAGS; \
+   $(foreach i,CC CXX CPPFLAGS CFLAGS CXXFLAGS LDFLAGS PKG_CONFIG,$(call 
shellexport,$i)); \
+   export CC CXX CPPFLAGS CFLAGS CXXFLAGS LDFLAGS PKG_CONFIG; \
exec ${MAKE_INVOCATION}
@:>$@
 


Bug#922166: linux-image-4.19.0-0.bpo.2-amd64-unsigned: [regression] Touchpad doesn't work unless set to 'Basic' from BIOS

2019-02-12 Thread N G
Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: normal

Dear Maintainer,

After upgrading to linux 4.19.16 my touchpad it's no longer working, the
following was found in dmesg:

elan_i2c i2c-ELAN0501:00: i2c-ELAN0501:00 supply vcc not found, using dummy
regulator
elan_i2c i2c-ELAN0501:00: Linked as a consumer to regulator.0
elan_i2c i2c-ELAN0501:00: Elan Touchpad: Module ID: 0x005c, Firmware: 0x0003,
Sample: 0x0003, IAP: 0x000d
input: Elan Touchpad as
/devices/platform/AMD0010:03/i2c-0/i2c-ELAN0501:00/input/input7
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)
elan_i2c i2c-ELAN0501:00: invalid report id data (0)

Touchpad it's set to 'Advanced' in BIOS during this bug, if set to 'Basic, it
works correctly.
Touchpad set to 'Advanced' was/is working correctly with kernel 4.18.20, and
4.19.12. Before that, touchpad had to be set to 'Basic' to get it working on
every kernel version (at least with Debian, it's been working OK with fedora
since kernel 4.16).




-- Package-specific info:
** Version:
Linux version 4.19.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.16-1~bpo9+1 
(2019-02-07)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-0.bpo.2-amd64 root=/dev/mapper/firebolt-root ro 
amdgpu.dc=0 amdgpu.dpm=0 quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

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

** Model information
sys_vendor: Acer
product_name: Aspire A515-41G
product_version: V1.08
chassis_vendor: Acer
chassis_version: V1.08
bios_vendor: Insyde Corp.
bios_version: V1.08
board_vendor: BR
board_name: Wartortle_BS
board_version: V1.08

** Loaded modules:
rfcomm(E)
pci_stub(E)
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
fuse(E)
ctr(E)
ccm(E)
hid_generic(E)
usbhid(E)
ebtable_filter(E)
ebtables(E)
ip6table_filter(E)
ip6_tables(E)
iptable_filter(E)
bnep(E)
arc4(E)
amdkfd(E)
btusb(E)
btrtl(E)
amdgpu(E)
btbcm(E)
btintel(E)
bluetooth(E)
uvcvideo(E)
drbg(E)
videobuf2_vmalloc(E)
rtsx_pci_sdmmc(E)
ath10k_pci(E)
ath10k_core(E)
mmc_core(E)
videobuf2_memops(E)
ansi_cprng(E)
rtsx_pci_ms(E)
ecdh_generic(E)
joydev(E)
ath(E)
memstick(E)
videobuf2_v4l2(E)
videobuf2_common(E)
videodev(E)
mac80211(E)
media(E)
edac_mce_amd(E)
kvm_amd(E)
snd_hda_codec_realtek(E)
ccp(E)
snd_hda_codec_generic(E)
rng_core(E)
cfg80211(E)
snd_hda_codec_hdmi(E)
kvm(E)
snd_hda_intel(E)
snd_hda_codec(E)
r8169(E)
snd_hda_core(E)
snd_hwdep(E)
snd_pcm_oss(E)
libphy(E)
chash(E)
irqbypass(E)
gpu_sched(E)
i2c_hid(E)
hid(E)
ttm(E)
rfkill(E)
crct10dif_pclmul(E)
crc32_pclmul(E)
snd_mixer_oss(E)
rtsx_pci(E)
snd_pcm(E)
drm_kms_helper(E)
xhci_pci(E)
ghash_clmulni_intel(E)
fam15h_power(E)
snd_timer(E)
elan_i2c(E)
sg(E)
k10temp(E)
battery(E)
ac(E)
snd(E)
drm(E)
xhci_hcd(E)
i2c_piix4(E)
button(E)
soundcore(E)
i2c_algo_bit(E)
video(E)
pcc_cpufreq(E)
acpi_cpufreq(E)
parport_pc(E)
ppdev(E)
lp(E)
parport(E)
ip_tables(E)
x_tables(E)
autofs4(E)
ext4(E)
crc16(E)
mbcache(E)
jbd2(E)
crc32c_generic(E)
fscrypto(E)
ecb(E)
dm_crypt(E)
dm_mod(E)
sd_mod(E)
crc32c_intel(E)
evdev(E)
ahci(E)
aesni_intel(E)
aes_x86_64(E)
libahci(E)
ehci_pci(E)
crypto_simd(E)
cryptd(E)
glue_helper(E)
ehci_hcd(E)
libata(E)
serio_raw(E)
usbcore(E)
scsi_mod(E)
usb_common(E)

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 60h-6fh) Processor Root Complex [1022:1576]
Subsystem: Acer Incorporated [ALI] Device [1025:1201]
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Wani [Radeon R5/R6/R7 Graphics] [1002:9874] (rev c8) (prog-if 00 [VGA 
controller])
Subsystem: Acer Incorporated [ALI] Carrizo [1025:1201]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: amdgpu
Kernel modules: amdgpu

00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Kabini 
HDMI/DP Audio [1002:9840]
Subsystem: Acer Incorporated [ALI] Kabini HDMI/DP Audio [1025:1201]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Statu

Bug#922112: fio: hash.h is not DFSG compliant

2019-02-12 Thread Martin Steigerwald
Martin Steigerwald - 12.02.19, 21:08:
> I am going to bounce two mails from Jens to this bug report, to
> further clarify that hash.c is GPL-2.
> 
> 1) Re: Bug#919356: Licensing of include/linux/hash.h
> 
> 2) [PATCH] Add the SPDX header to include/linux/hash.h

This second mail is from Domenico Andreoli. Sorry for attributing it to 
Jens.
-- 
Martin



Bug#922165: new upstream release (1.3.16)

2019-02-12 Thread Antoine Beaupre
Source: umatrix
Version: 1.3.14+dfsg-2
Severity: wishlist

There's a new upstream release of uMatrix that's not packaged in
Debian (1.3.16 at the time of writing).

Plus, the watch file fails to find the new package, as reported on the
dashboard:

https://tracker.debian.org/pkg/umatrix

uscan had problems while searching for a new upstream version:

In debian/watch no matching files for watch line
  https://addons.mozilla.org/en-US/firefox/addon/umatrix/versions/ 
.*/umatrix-(\d[\d\.]+)-.*\.xpi\?src=.*

A.

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

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



Bug#922164: fetchmail: With buster :fetchmail: Erreur de login ou d'identification inconnue pour xx...@pop.free.fr

2019-02-12 Thread Gérard ROBIN
Package: fetchmail
Version: 6.3.26-3
Severity: normal

Dear Maintainer,
I use buster (testing) and after last upgrade I get :

fetchmail: pop.free.fr: passage au TLS raté.
fetchmail: Erreur de login ou d'identification inconnue pour x...@pop.free.fr
fetchmail: erreur socket durant la réception de x...@pop.free.fr
fetchmail: État de la requête=2 (SOCKET)
fetchmail: pop.free.fr: passage au TLS raté.
fetchmail: Erreur de login ou d'identification inconnue pour x...@pop.free.fr
fetchmail: erreur socket durant la réception de x...@pop.free.fr
fetchmail: État de la requête=2 (SOCKET)
fetchmail: pop.free.fr: passage au TLS raté.
fetchmail: Erreur de login ou d'identification inconnue pour x...@pop.free.fr
fetchmail: erreur socket durant la réception de x...@pop.free.fr
fetchmail: État de la requête=2 (SOCKET)

This is with fetchmail 6.4.0

I just installed fetchmail 6.3.26-3 (stretch) and  now it works fine.

Gerard

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

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

Versions of packages fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.8.6.1
ii  libc6 2.28-6
ii  libcomerr21.44.5-1
ii  libgssapi-krb5-2  1.17-1
ii  libk5crypto3  1.17-1
ii  libkrb5-3 1.17-1
ii  libssl1.1 1.1.1a-1
ii  lsb-base  10.2018112800

Versions of packages fetchmail recommends:
ii  ca-certificates  20190110

Versions of packages fetchmail suggests:
pn  fetchmailconf   
ii  postfix [mail-transport-agent]  3.3.2-1+b1
pn  resolvconf  

-- no debconf information


Bug#922112: Add the SPDX header to include/linux/hash.h

2019-02-12 Thread Domenico Andreoli
From: Domenico Andreoli 

It is unlikely that who contributes to this file is unaware of the kernel
licensing but bringing the license statement into the file itself makes
it properly reusable in different contexts.

CC: Daniel Borkmann 
CC: Francesco Fusco 
CC: George Spelvin 
CC: Hannes Frederic Sowa 
CC: Ian Campbell 
CC: Jay Vosburgh 
CC: Jens Axboe 
CC: Linus Torvalds 
CC: Masami Hiramatsu 
CC: Matthew Wilcox 
CC: Nadia Yvette Chambers 
CC: Pavel Emelyanov 
Signed-off-by: Domenico Andreoli 

---
 include/linux/hash.h |2 ++
 1 file changed, 2 insertions(+)

Index: b/include/linux/hash.h
===
--- a/include/linux/hash.h
+++ b/include/linux/hash.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
 #ifndef _LINUX_HASH_H
 #define _LINUX_HASH_H
 /* Fast hashing routine for ints,  longs and pointers.



Bug#916594: webext-umatrix: Can not load configuration from backup

2019-02-12 Thread Antoine Beaupre
Package: webext-umatrix
Version: 1.3.14+dfsg-2
Followup-For: Bug #916594

Control: severity 916594 grave

I think this is serious enough to forbid this package from being
shipped with buster. It makes it impossible, for example, for a user
to switch from the extension shipped from addons.mozilla.org to the
Debian package, which was my use case.

Also note that the rules cannot be modified by hand either, nor do
they persist when modified through the normal UI.

Thefore I'm marking this as "grave", as it "makes the package in
question unusable or mostly so" and "causes data loss".

Thank you for your attention,

A.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.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 webext-umatrix depends on:
ii  fonts-font-awesome   5.0.10+really4.7.0~dfsg-1
ii  fonts-roboto-hinted  2:0~20170802-1
ii  libjs-codemirror 5.19.0-1
ii  libjs-punycode   1.3.2-2
ii  publicsuffix 20190128.1516-1

Versions of packages webext-umatrix recommends:
ii  firefox-esr  60.4.0esr-1

webext-umatrix suggests no packages.

-- debconf-show failed



Bug#922112: fio: hash.h is not DFSG compliant

2019-02-12 Thread Martin Steigerwald
I am going to bounce two mails from Jens to this bug report, to further 
clarify that hash.c is GPL-2.

1) Re: Bug#919356: Licensing of include/linux/hash.h

2) [PATCH] Add the SPDX header to include/linux/hash.h

I may clarify this in copyright file, in case it would be required, but 
for now I think that will suffice.

Thanks,
-- 
Martin

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


Bug#922160: lightdm: Add elogind support

2019-02-12 Thread Mark Hindley
On Tue, Feb 12, 2019 at 08:27:40PM +0100, Ansgar wrote:
> Mark Hindley writes:
> > diff --git a/debian/control b/debian/control
> > index fff913a..88aebb8 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -33,7 +33,7 @@ Package: lightdm
> >  Architecture: any
> >  Depends: adduser,
> >   dbus,
> > - libpam-systemd [linux-any] | consolekit,
> > + libpam-systemd [linux-any] | logind | consolekit,
> 
> If a package "runlogind" is introduced it would satisfy this
> dependency, but...
> 
> > +@@ -15,3 +16,4 @@
> > + # Setup session
> > + session   required pam_unix.so
> > + session   optional pam_systemd.so
> > ++session   optional pam_elogind.so
> 
> ... pam_runlogind.so would be missing here.  So it looks like arbitrary
> providers of logind are not supported, only those listed in the PAM
> configuration.
> 
> Shouldn't the dependency list `elogind [linux-any]` instead of a virtual
> package then?

Actually it would be libpam-elogind [linux-any], but your point is still well 
made.

There appears to be a desire to have a virtual pacakge available for all
providers of the Dbus login1 API. See #917431 and #915407.

For packages which utilise PAM @common-session adding the virtual logind
dependency will suffice as libpam-elogind provides a pam-auth module.

As /etc/pam.d/lightdm-greeter doesn't source common-session (should it?), the
extra line is required.

Thanks

Mark



Bug#922163: mark lemon Multi-Arch: foreign

2019-02-12 Thread Helmut Grohne
Package: lemon
Version: 3.26.0+fossilbc891ac6b-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:qevercloud

qevercloud fails to cross build from source, because it fails running
lemon. Since lemon's input and output formats are textual it is eligible
to be marked Multi-Arch: foreign. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru sqlite3-3.26.0+fossilbc891ac6b/debian/changelog 
sqlite3-3.26.0+fossilbc891ac6b/debian/changelog
--- sqlite3-3.26.0+fossilbc891ac6b/debian/changelog 2019-01-26 
08:19:44.0 +0100
+++ sqlite3-3.26.0+fossilbc891ac6b/debian/changelog 2019-02-12 
20:57:44.0 +0100
@@ -1,3 +1,10 @@
+sqlite3 (3.26.0+fossilbc891ac6b-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark lemon Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 12 Feb 2019 20:57:44 +0100
+
 sqlite3 (3.26.0+fossilbc891ac6b-2) unstable; urgency=medium
 
   * Backport upstream fix for a problem with bytecode generation when a
diff --minimal -Nru sqlite3-3.26.0+fossilbc891ac6b/debian/control 
sqlite3-3.26.0+fossilbc891ac6b/debian/control
--- sqlite3-3.26.0+fossilbc891ac6b/debian/control   2019-01-26 
08:19:44.0 +0100
+++ sqlite3-3.26.0+fossilbc891ac6b/debian/control   2019-02-12 
20:57:42.0 +0100
@@ -9,6 +9,7 @@
 
 Package: lemon
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: LALR(1) Parser Generator for C or C++
  Lemon is an LALR(1) parser generator for C or C++. It does the same


Bug#922162: mesa: Assertion triggered in texcompress_etc.c: _mesa_texstore_etc2_rgba8_eac from glGenerateMipmap()

2019-02-12 Thread ccaccb
Source: mesa
Version: 18.3.2-1
Severity: normal

Dear Maintainer,

After updating my bgfx-based renderer throws assertions.

src/mesa/main/texcompress_etc.c:1130: _mesa_texstore_etc2_rgba8_eac:
Assertion `0' failed.

from glGenerateMipmap() for any of the following texture formats:
GL_ETC1_RGB8_OES
GL_COMPRESSED_RGB8_ETC2
GL_COMPRESSED_RGBA8_ETC2_EAC
GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2

Code roughly, look at (or better execute)
https://github.com/bkaradzic/bgfx/blob/7464fd16ab689a3bd736b6808a3ce9fbbeae3412/src/renderer_gl.cpp#L1461
```cpp
glGenTextures(1, &id);
glBindTexture(target, id);
glTexStorage3D(target, ...);
glCompressedTexImage3D(target, ...);
glGenerateMipmap(target); /* ASSERT TRIGGERED */
```

[bgfx]: https://github.com/bkaradzic/bgfx

I guess the simplest way to replicate is to check out and run any of
the bgfx examples.

Might this be related to the change of the used assert macro in

https://gitlab.freedesktop.org/mesa/mesa/commit/bfcdb843830bba0190e00e35e3c5c18c4bdb5de1
(although that is 3 years old)

-- 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-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#922008: wct4xxp: fails to initialize card, Unknown symbols

2019-02-12 Thread Ilya Demyanov

12.02.2019 21:02, Jakob Haufe wrote:



I just did a quick test on a buster box which revealed to following
problem: dahdi-dkms is building BUT NOT INSTALLING oct612x.ko which is
containing those symbols. OTOH dahdi-source via module-assistant is
installing it, making it possible to load wct4xxp.

So it seems oct612x (and maybe others, didn't verify) need to be added
to dkms.conf to make it on-par with dahdi-source.



It looks like it is:

# grep oct612x 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/4.19.0-2-amd64/x86_64/log/make.log 

  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_adpcm_chan.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_channel.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_chip_open.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_chip_stats.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_conf_bridge.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_debug.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_events.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_interrupts.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_memory.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_miscellaneous.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_mixer.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_phasing_tsst.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_playout_buf.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_remote_debug.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tlv.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tone_detection.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tsi_cnct.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tsst.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/apilib/bt/octapi_bt0.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/apilib/largmath/octapi_largmath.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/apilib/llman/octapi_llman.o
  CC [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/oct612x-user.o
  LD [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/oct612x.o
  CC 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/oct612x.mod.o
  LD [M] 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-5/build/drivers/dahdi/oct612x/oct612x.ko


# ls -1 /usr/lib/modules/4.19.0-2-amd64/updates/dkms/ | grep oct612x | wc -l
0



Bug#922160: lightdm: Add elogind support

2019-02-12 Thread Ansgar
Mark Hindley writes:
> diff --git a/debian/control b/debian/control
> index fff913a..88aebb8 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -33,7 +33,7 @@ Package: lightdm
>  Architecture: any
>  Depends: adduser,
>   dbus,
> - libpam-systemd [linux-any] | consolekit,
> + libpam-systemd [linux-any] | logind | consolekit,

If a package "runlogind" is introduced it would satisfy this
dependency, but...

> +@@ -15,3 +16,4 @@
> + # Setup session
> + session   required pam_unix.so
> + session   optional pam_systemd.so
> ++session   optional pam_elogind.so

... pam_runlogind.so would be missing here.  So it looks like arbitrary
providers of logind are not supported, only those listed in the PAM
configuration.

Shouldn't the dependency list `elogind [linux-any]` instead of a virtual
package then?

Ansgar



Bug#922161: grub2: null src bitmap error while trying to drop background image

2019-02-12 Thread Samuel Thibault
Source: grub2
Version: 2.02+dfsg1-11
Severity: normal
Tags: d-i

Hello,

As can be seen on the latest installer image 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
the boot menu now had a dark theme entry which drops the background
image and sets white on black colors. When entering a submenu, however,
we get an error:

error: null src bitmap in grub_video_bitmap_create_scaled.

and grub continues, so no real harm, but it's odd. I have attached the
grub.cfg being used. I also tried to drop the duplicate background_image
call (attached grub2.cfg) with the same result.

Samuel

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

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

-- 
Samuel
"c'est pas nous qui sommes à la rue, c'est la rue qui est à nous"
if loadfont $prefix/font.pf2 ; then
  set gfxmode=800x600
  set gfxpayload=keep
  insmod efi_gop
  insmod efi_uga
  insmod video_bochs
  insmod video_cirrus
  insmod gfxterm
  insmod png
  terminal_output gfxterm
fi

if background_image /isolinux/splash.png; then
  set color_normal=light-gray/black
  set color_highlight=white/black
elif background_image /splash.png; then
  set color_normal=light-gray/black
  set color_highlight=white/black
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi

insmod play
play 960 440 1 0 4 440 1
set theme=/boot/grub/theme/1
menuentry --hotkey=g 'Graphical install' {
set background_color=black
linux/install.amd/vmlinuz vga=788 --- quiet 
initrd   /install.amd/gtk/initrd.gz
}
menuentry --hotkey=i 'Install' {
set background_color=black
linux/install.amd/vmlinuz vga=788 --- quiet 
initrd   /install.amd/initrd.gz
}
submenu --hotkey=a 'Advanced options ...' {
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
set theme=/boot/grub/theme/1-1
menuentry '... Graphical expert install' {
set background_color=black
linux/install.amd/vmlinuz priority=low vga=788 --- 
initrd   /install.amd/gtk/initrd.gz
}
menuentry '... Graphical rescue mode' {
set background_color=black
linux/install.amd/vmlinuz vga=788 rescue/enable=true --- quiet  
initrd   /install.amd/gtk/initrd.gz
}
menuentry '... Graphical automated install' {
set background_color=black
linux/install.amd/vmlinuz auto=true priority=critical vga=788 --- 
quiet 
initrd   /install.amd/gtk/initrd.gz
}
menuentry --hotkey=x '... Expert install' {
set background_color=black
linux/install.amd/vmlinuz priority=low vga=788 --- 
initrd   /install.amd/initrd.gz
}
menuentry --hotkey=r '... Rescue mode' {
set background_color=black
linux/install.amd/vmlinuz vga=788 rescue/enable=true --- quiet 
initrd   /install.amd/initrd.gz
}
menuentry --hotkey=a '... Automated install' {
set background_color=black
linux/install.amd/vmlinuz auto=true priority=critical vga=788 --- 
quiet 
initrd   /install.amd/initrd.gz
}
submenu --hotkey=s '... Speech-enabled advanced options ...' {
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
set theme=/boot/grub/theme/1-1-1
menuentry --hotkey=x '... Expert speech install' {
set background_color=black
linux/install.amd/vmlinuz priority=low vga=788 
speakup.synth=soft --- 
initrd   /install.amd/gtk/initrd.gz
}
menuentry --hotkey=r '... Rescue speech mode' {
set background_color=black
linux/install.amd/vmlinuz vga=788 rescue/enable=true 
speakup.synth=soft --- quiet  
initrd   /install.amd/gtk/initrd.gz
}
menuentry --hotkey=a '... Automated speech install' {
set background_color=black
linux/install.amd/vmlinuz auto=true priority=critical vga=788 
speakup.synth=soft --- quiet 
initrd   /install.amd/gtk/initrd.gz
}
}
}
submenu --hotkey=d 'Dark theme installer menu ...' {
set menu_color_normal=white/black
set menu_color_highlight=yellow/black
set color_normal=white/black
set color_highlight=yellow/black
background_image
set theme=/boot/grub/theme/dark-1-2
  

  1   2   3   >