Bug#869201: RFS: etcd/3.1.8+dfsg-2+nmu1 [NMU]

2017-09-19 Thread Harish Sriram

Hi Andrey,

There are three RC Bugs for etcd.

The fix for #866194 is included here.
#857842 is raised on a amd and I am not sure if same set of tests fail on
ppc. And I do not have a amd setup to work with.
A partial fix which fixes few of the test fails is included here. Other
test failures occurs in upstream version of package as well.
For #857125, I do not have a ARM machine to work with.

Can you let know whether this RFS would be accepted with the available
fixes?

Thanks,
Harish


Bug#871469: transition: ocaml

2017-09-19 Thread Katsuhiko Nishimra
Hi.

While Build-Depends-Arch is supported since Standards-Version 4.0.0, the
transition seems to be running without build-depends-arch in the
"Affected:" pattern.

Is that OK?

If it's OK, sorry for the noise.


signature.asc
Description: PGP signature


Bug#854062: xournal: Hangs upon pressing Ctrl-S (for saving)

2017-09-19 Thread Carlo Segre


Thanks

On Tue, 19 Sep 2017, Ondřej Lhoták wrote:


I was experiencing the same issue. The file selection dialog for both
the Save As and Export to PDF actions did not appear, and Xournal would
hang.

I deselected Use XInput in the Options menu. That fixed the issue. Both
Save As and Export to PDF work for me when Use XInput is deselected.

This seems to be related to upstream bug 170:
https://sourceforge.net/p/xournal/bugs/170/



--
Carlo U. Segre -- Duchossois Leadership Professor of Physics
Interim Chair, Department of Chemistry
Director, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org

Bug#876243: debian-policy: virtual package: httpd-fastcgi

2017-09-19 Thread Xavier Guimard
Package: debian-policy
Version: 4.1.0.0
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

The authoritative list of virtual package provides:
 httpd   a HTTP server
 httpd-cgi   a CGI-capable HTTP server
 httpd-wsgi  a WSGI-capable HTTP server (python 2 API)
 httpd-wsgi3 a WSGI-capable HTTP server (python 3 API)

I would like to propose this:
 httpd-fastcgi   a FastCGI-capable HTTP server (or server
 plugin)

The  idea was to use this virtual package for webserver able to
establish the link between a browser and a FastCGI server (Nginx,
libapache2-mod-fcgid,...)

Best regards,
Xavier

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

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

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.5.6-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAlnB9UUSHHguZ3VpbWFy
ZEBmcmVlLmZyAAoJEPbXTKfJme7pIH8P/i7xsMlxJlZmUSudm/dTMk7hqhy9afYo
dN3W6BVo6fHlH0B35lgBSupNEEU8aHBEwiC9+zNn5eLE0vHqiqFgTMHrGXIxSS1N
DJCGm259sysQhSG3JhV+4wVJcey95eEcNQHKJlwX2ITUAlJeE5ZpOCg0QNi23VGb
M4UsQJveyt1u1IKlRL0lOiQkBRaF7fN1vUnJWOnw/0ClJ/DLJGf6pdcV/3enGPhi
KJEtsobVwElFsIU8OEZVryJr/9rS+KlC0DFxjeNFPmcnpw0AYRM34ApNhRvJhXNg
88z+TK56jp3Z+rSk4ItHKY8hbg1d7dL8iT7A+LemgruCK4zAs3Y6vWbPVCwDYrcV
y4Esi1BnpTviqDWyFvBAmdRXN0/86yC1vNgcHpq2OOLgMIxf7lunLXQRAqi3P2Gg
nZdOdLEFuAd5CrR4dIUulJK5qqbRterpBbnOGNen4aLOPKkNTAd2lXbbvuaxUMki
qMOGK8dPWLe0Tl/j5kMaptw0boxFPpbD6nDkxzsIYDhRPLVHLPOMvagxC9QhndMP
Lzp8f4/3WQ0nJAxsL0ROU5Am3mn60zhRfHlkHYd+QGJ7Moq+WxMUfPom7sNoSO0i
7a/yv8NXi8Cvyln9PxO9djnK5Xy7g3y0VxeZuVmLwCPmhTPj5jri2ko0yP4J7Zen
UBNoqf/kQeAX
=LnxH
-END PGP SIGNATURE-



Bug#875058: [mumble] Future Qt4 removal from Buster

2017-09-19 Thread Chris Knadle
Lisandro Damián Nicanor Pérez Meyer:
> On lunes, 18 de septiembre de 2017 05:37:03 -03 Chris Knadle wrote:
>> Lisandro Damián Nicanor Pérez Meyer:

[Got and understood your other comments]


>> And if all goes well, Qt 5.10 and mumble-1.3.x will both have stable
>> releases in time to upload them to Unstable before the freeze for
>> Buster. [Freeze sometime ~Jan 2019, I guess.]
> 
> I think either you or me are missing a point here. Right now both qt4 and qt5 
> use OpenSSL 1.0. So if mumbles uses OpenSSL 1.1 then it means that it is not 
> using Qt5's Network submodule, so it's not mixing OpenSSL versions (and if it 
> is, it has been lucky enough to avoid crashes).

Oh. :-( Yes, at minimum I think I missed something.

I had heard that Qt5 didn't work with OpenSSL 1.1, I didn't realize Qt4
was also using OpenSSL 1.0. :-( I believe Mumble /does/ use Qt4's SSL
submodule, so I think it /is/ mixing OpenSSL versions right now. That's
not optimal but I haven't seen problems using the package nor gotten new
bug reports related to SSL issues thusfar.

If I had known Qt4 was still using OpenSSL 1.0 I would have hardcoded a
build-depends for mumble-1.2.x to use the same for the Stretch release.
*shrug* Can't win 'em all, I suppose.

> If this is the case then there is nothing sotpping mumble from being ported 
> to 
> Qt5.

Sort of.

Mumble 1.2.x won't build with Qt5, 1.3.x will, but 1.3.x is still in
development and after the painful experience of a snapshot being in the
Wheezy release, upstream (I think rightfully) asked me not to upload
snapshots. I've been wanting to upload a snapshot to Experimental for
testing purposes, but right now the 1.3.x source tarballs contain
unreleasable files that would require building a -dfsg tarball. These
files are normally stripped out by upstream for stable releases, but the
script that builds the release tarballs needs updating after a lot of
development/changes in mumble 1.3.x.

Given how much time there is before the freeze for Buster I have hopes
that this will all work out. right now it seems like things are in the
"hurry up and wait" category. ;-)

   -- Chris

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



signature.asc
Description: OpenPGP digital signature


Bug#876238: gcc-cross-support: FTBFS, wants to regenerate debian/control with more and renamed packages

2017-09-19 Thread Helmut Grohne
Hi Andreas,

On Wed, Sep 20, 2017 at 02:37:38AM +0200, Andreas Beckmann wrote:
> gcc-cross-support FTBFS in experimental, tries to regenerate
> debian/control in order to rename several packages and add a bunch of
> new ones.

Yes. The problem essentially is that you can only upload
gcc-cross-support after a stable update of dpkg, because either it FTBFS
or dak rejects it, because dak's idea of valid architectures differs
from dpkg's.

> Given that the package hasn't seen any upload in the last two years,
> maybe it's not needed for the current cross compilers and should rather
> be removed than fixed :-)

Indeed the goal is to get it removed. Removing the package that is, not
removing the functionality. We have made significant progress by
introducing binutils-for-host and binutils-for build into src:binutils
now. The next step is introducing gcc-7-for-host and when gcc-defaults
takes over gcc-for-host, I want to remove the source package. Until
then, I'd like to keep it accessible to show where this work is heading.

So while there hasn't been any upload, progress is not stuck. I'd like
to keep the package (rc buggy as it is) in experimental for a while
though. I hope that doesn't cause too much pain to you.

Helmut



Bug#876242: exiv2: CVE-2017-12957

2017-09-19 Thread Salvatore Bonaccorso
Source: exiv2
Version: 0.26-1
Severity: grave
Tags: upstream security
Justification: user security hole

Hi,

the following vulnerability was published for exiv2.

CVE-2017-12957[0]:
| There is a heap-based buffer over-read in libexiv2 in Exiv2 0.26 that
| is triggered in the Exiv2::Image::io function in image.cpp. It will
| lead to remote denial of service.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-12957
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12957

Regards,
Salvatore



Bug#875535: closed by Matthias Klumpp <m...@debian.org> (Re: Bug#875878: ldc 1.3 doesn't build any of it's reverse dependencies)

2017-09-19 Thread Nobuhiro Iwamatsu
Hi,

sambamba package has not fixed this problem with ldc 1:1.4.0-1.
Also, I confirmed that diet-ng fixed this problem.

-
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package sambamba
dpkg-buildpackage: info: source version 0.6.6-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Andreas Tille 
 dpkg-source --before-build sambamba-0.6.6
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --buildsystem=meson
   dh_auto_clean -O--buildsystem=meson
   dh_autoreconf_clean -O--buildsystem=meson
   dh_clean -O--buildsystem=meson
 dpkg-source -b sambamba-0.6.6
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building sambamba using existing ./sambamba_0.6.6.orig.tar.gz
dpkg-source: info: building sambamba in sambamba_0.6.6-1.debian.tar.xz
dpkg-source: info: building sambamba in sambamba_0.6.6-1.dsc
 debian/rules build
dh build --buildsystem=meson
   dh_update_autotools_config -O--buildsystem=meson
   dh_autoreconf -O--buildsystem=meson
   dh_auto_configure -O--buildsystem=meson
meson .. --wrap-mode=nodownload --buildtype=plain
--prefix=/usr --sysconfdir=/etc --localstatedir=/var
--libdir=lib/x86_64-linux-gnu --libexecdir=lib/x86_64-linux-gnu
Warning: You are using 'ANSI_X3.4-1968' which is not a a
Unicode-compatible locale.
You might see errors if you use UTF-8 strings as filenames, as
strings, or as file contents.
Please switch to a UTF-8 locale for your platform.
The Meson build system
Version: 0.42.1
Source dir: /home/iwa/t3/sambamba-0.6.6
Build dir: /home/iwa/t3/sambamba-0.6.6/obj-x86_64-linux-gnu
Build type: native build
Project name: Sambamba
Native D compiler: ldc2 (llvm 1.4.0)
Appending DFLAGS from environment: '-O2 -g -release'
Appending LDFLAGS from environment: '-Wl,-z,relro'
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29)
Native dependency undead found: YES 1.0.7
Native dependency biod found: YES 0.1.0
Native dependency liblz4 found: YES 1.8.0
Native dependency htslib found: YES 1.5-1
Program ldmd2 found: YES (/usr/bin/ldmd2)
Program mkdir found: YES (/bin/mkdir)
Build targets in project: 2
   dh_auto_build -O--buildsystem=meson
ninja -j8 -v
[1/74] ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/
-I/usr/include/htslib -enable-color -O2 -g -release  -of
'sambamba@exe/main.d.o' -c ../main.d
../sambamba/utils/common/readstorage.d(22): Deprecation: module
std.c.stdlib is deprecated - Import core.stdc.stdlib or
core.sys.posix.stdlib instead
../sambamba/utils/common/readstorage.d(23): Deprecation: module
std.c.string is deprecated - Import core.stdc.string instead
../sambamba/utils/common/readstorage.d(23): Deprecation: module
std.c.string is deprecated - Import core.stdc.string instead
../sambamba/sort.d(45): Deprecation: module std.c.stdlib is deprecated
- Import core.stdc.stdlib or core.sys.posix.stdlib instead
../sambamba/sort.d(46): Deprecation: module std.c.string is deprecated
- Import core.stdc.string instead
../sambamba/markdup.d(37): Deprecation: module std.c.stdlib is
deprecated - Import core.stdc.stdlib or core.sys.posix.stdlib instead
../sambamba/depth.d(1154): Deprecation: Implicit string concatenation
is deprecated, use "mapping_quality > 0 and " ~ "not duplicate and "
instead
../sambamba/depth.d(1155): Deprecation: Implicit string concatenation
is deprecated, use "not duplicate and " ~ "not failed_quality_control"
instead
[2/74] ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/
-I/usr/include/htslib -enable-color -O2 -g -release  -of
'sambamba@exe/sambamba_index.d.o' -c ../sambamba/index.d
[3/74] ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/
-I/usr/include/htslib -enable-color -O2 -g -release  -of
'sambamba@exe/sambamba_fixbins.d.o' -c ../sambamba/fixbins.d
[4/74] ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/
-I/usr/include/htslib -enable-color -O2 -g -release  -of
'sambamba@exe/sambamba_depth.d.o' -c ../sambamba/depth.d
FAILED: sambamba@exe/sambamba_depth.d.o
ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/ -I/usr/include/htslib
-enable-color -O2 -g -release  -of 'sambamba@exe/sambamba_depth.d.o'
-c ../sambamba/depth.d
../sambamba/depth.d(1154): Deprecation: Implicit string concatenation
is deprecated, use "mapping_quality > 0 and " ~ "not duplicate and "
instead
../sambamba/depth.d(1155): Deprecation: Implicit string concatenation
is deprecated, use "not duplicate and " ~ "not failed_quality_control"
instead
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1a)[0x7fec38558cda]
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x56)[0x7fec38556fc6]
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1(+0x86e0e3)[0x7fec385570e3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fec376d10c0]
ldc2(+0x2d6242)[0x59e7bce242]
ldc2(+0x35b517)[0x59e7c53517]
ldc2(+0x35babb)[0x59e7c53abb]
ldc2(+0x31e1d0)[0x59e7c161d0]

Bug#873094: RFS: granite/0.4.1-1 [ITP]

2017-09-19 Thread yang
Hi,
Thank very much for your interest. I've fixed them.

2017-09-20 4:46 GMT+08:00 Jeremy Bicha :
> debian/control:
> - Please remove or update the Vcs fields
> - Please drop the Pre-Depends lines
> - Maybe https://github.com/elementary/granite is a better homepage?
>
> debian/rules:
> - Please drop the dh_builddeb rule. xz is already the default
> - Please use c4 for the makeshlibs rule
>
> debian/changelog:
> - I think it is appropriate to keep the old changelog entries since
> this package was only removed from Debian 6 months ago.
>
> debian/copyright:
> - Please update the Source line to point to github since that's where
> your watch file points
>
> Please use automatic debug packages. In particular, see the top
> section (before Summary) of
> https://wiki.debian.org/AutomaticDebugPackages
>
> Thanks,
> Jeremy Bicha



Bug#781051: php-wikidiff2: Not configured correctly when short_open_tag is false

2017-09-19 Thread Kunal Mehta
On Mon, 23 Mar 2015 20:59:36 +0100 Sebastien Koechlin
 wrote
> Can you switch to "https://anonscm.debian.org/cgit/collab-maint/wikidiff2.git/commit/?id=d83ceb2ff550ff0831738cda29477cbe46e64281>.

wikidiff2 1.4.1+ no longer includes a PHP file anyways.

-- Kunal



signature.asc
Description: OpenPGP digital signature


Bug#876241: debian-policy: Produce HTML output that doesn't try to load any JavaScript

2017-09-19 Thread Sean Whitton
Package: debian-policy
Version: 4.1.0.0
Severity: normal
Control: block 871944 by -1
User: debian-pol...@packages.debian.org
Usertags: packaging

Per the discussion in #871944, at least for now we intend the version of
Policy published on www.debian.org to be free of JavaScript.  So we need
to include a JavaScript-free version in our package.

Assuming that search is the only use made of JavaScript by Sphinx, here
is somewhere to start:
https://stackoverflow.com/questions/31951553/customizing-sphinx-to-avoid-generating-search-box

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

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

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.5.6-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#876240: libghc-xmonad-contrib-dev: unmet dependency libghc-x11-xft-dev-0.3.1-c557c

2017-09-19 Thread Sacha Delanoue

Package: libghc-xmonad-contrib-dev
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I tried to install libghc-xmonad-contrib-dev by doing
`apt install libghc-xmonad-contrib-dev` on an up-to-date 9.1 Debian.
The install failed with the following information:

The following packages have unmet dependencies:
 libghc-xmonad-contrib-dev : Depends: libghc-x11-xft-dev-0.3.1-c557c
E: Unable to correct problems, you have held broken packages.

I am no expert in Debian, but a search on the Internet lead me to this:
https://unix.stackexchange.com/a/392888 stating that this kind of errors
in expected in Sid. But since I am using stable I reported it.


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libghc-xmonad-contrib-dev depends on:
ii  ghc [libghc-unix-dev-2.7.2.0-220bd]  8.0.1-17+b1
ii  libc6 
2.24-11+deb9u1

pn  libghc-base-dev-4.9.0.0-5e731
pn  libghc-containers-dev-0.5.7.1-8be09  
pn  libghc-directory-dev-1.2.6.2-958b8   
ii  libghc-extensible-exceptions-dev [libghc-extensible-excepti  0.1.1.4-8
pn  libghc-filepath-dev-1.4.1.0-6e799
ii  libghc-mtl-dev [libghc-mtl-dev-2.2.1-3d1c9]  2.2.1-5
ii  libghc-old-locale-dev [libghc-old-locale-dev-1.0.0.7-38cd4]  1.0.0.7-5
pn  libghc-old-time-dev-1.1.0.3-cc184
pn  libghc-process-dev-1.4.2.0-e39cb 
pn  libghc-random-dev-1.1-84324  
ii  libghc-utf8-string-dev [libghc-utf8-string-dev-1.0.1.1-6f2d 
1.0.1.1-4+b1

ii  libghc-x11-dev [libghc-x11-dev-1.6.1.2-588a9]1.6.1.2-7
pn  libghc-x11-xft-dev-0.3.1-c557c   
ii  libghc-xmonad-dev [libghc-xmonad-dev-0.12-b943d] 0.12-5+b1
ii  libgmp10 
2:6.1.2+dfsg-1

ii  libx11-6 2:1.6.4-3
ii  libx11-dev   2:1.6.4-3
ii  libxext6 
2:1.3.3-1+b2

ii  libxft2  2.3.2-1+b2
ii  libxinerama-dev 
2:1.1.3-1+b3
ii  libxinerama1 
2:1.1.3-1+b3

ii  libxrandr2   2:1.5.1-1

libghc-xmonad-contrib-dev recommends no packages.

Versions of packages libghc-xmonad-contrib-dev suggests:
ii  libghc-xmonad-contrib-doc   0.12-3
pn  libghc-xmonad-contrib-prof  



Bug#876239: reproducible: re-deploy cbxi4a (disk failure)

2017-09-19 Thread Vagrant Cascadian
Package: jenkins.debian.org
Severity: normal
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

cbxi4a-armhf-rb.debian.net had a critical disk failure.

It's been reinstalled, so the ssh keys have changed:

256 SHA256:C8nL+YAOEhjWYH2tkeoP00sfiWi4bI2ZlI400idPBqU root@cbxi4a (ECDSA)
256 SHA256:oxxy+996R6nClC9ors/Py20vsJEjN2HrGgzvhsSwKfw root@cbxi4a (ED25519)
2048 SHA256:EDUXTiDwa7/W2WAooNdHJNTJJd+GJZypCsqcJ7axLEM root@cbxi4a (RSA)

hostname, ip address, ssh port should all be the same, and it hasn't
been removed from jenkins git... so everything just needs to be
re-deployed on the new install.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#876238: gcc-cross-support: FTBFS, wants to regenerate debian/control with more and renamed packages

2017-09-19 Thread Andreas Beckmann
Source: gcc-cross-support
Version: 3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

gcc-cross-support FTBFS in experimental, tries to regenerate
debian/control in order to rename several packages and add a bunch of
new ones.

Given that the package hasn't seen any upload in the last two years,
maybe it's not needed for the current cross compilers and should rather
be removed than fixed :-)

Build log is attached.


Andreas


gcc-cross-support_3.log.gz
Description: application/gzip


Bug#780606: Bug# [...]

2017-09-19 Thread Michael Lustfield
To be blunt, I struggled very hard to follow the text you wrote.. especially
true for the github bug report. I have done my best to understand what the
intended message was, but if I misunderstood then I apologize in advance.


On Mon, 18 Sep 2017 14:55:12 -0400
PICCORO McKAY Lenz  wrote:
> the insane amout of dependences make the work of this package a hard made..
> 
> but a way to do its:
> 
> 1) makde a package that only use the downloaded sources that ship all
> depends

This sounds like you're suggesting that we actually make use of content within
the vendor/ directories. If that's the case then we'll need to discuss DFSG in a
bit more depth because this will cause a clear violation.

In fact, I'm aware of sources within gogs/gitea that *DOES* *NOT* meet DFSG,
and some of it never will. If this is something you're not equally aware of, I
would encourage you to review the source code within a gitea/gogs release.

Each dependency needs to be individually packaged and reviewed for DFSG
standards. This work has revealed a lot of issues that have now been resolved
(in Gitea). Unfortunately, the author/owner of gogs has no interest in adopting
these changes. (details need not be repeated here)

> 2) in the way the depends get packaged in debian, so make it depends on gogs

I do not believe we will ever see Gogs made available within Debian, at least
not given present-day circumstances.

Regardless, it would be woefully inappropriate for a gitea package to depend on
a gogs package to find build dependencies. Besides, the two have different
dependencies (gitea requires more because of more features).

It could be considered fortunate that the packaging I've done for gitea
dependencies is available for gogs. If gogs ever becomes a suitable candidate
for inclusion in Debian, there will likely be a relatively complete set of
dependencies already in place.

> the other way its that do not make usage of thos depends pacakges that
> change too many in the time!

I didn't follow this at all.


On Mon, 18 Sep 2017 15:08:21 -0400
PICCORO McKAY Lenz  wrote:

> Debian packaging pretend to made a simple gogs virtual package provided by
> gitea..
> 
> the gitea package roadmap pretend to separate from gogs, and are complety
> different..

I don't understand the usage of "pretend" in this context. The current
packaging I have been working on offers a gogs meta package that selects gitea.
This does not mean gitea is pretending to be gogs. It is a
relatively-compatible alternative.

I have not decided if I will keep this or not, but I consider worrying about it
to be about the lowest thing on my priorities list.

> gogs are focused on simplicity, no new features and only security fixeds
> gitea are focused on new features and changes too many ..

This is very much *not* the difference between the two. Gitea is a fork of gogs
that was created for entirely different reasons. Many of those reasons are why
gogs is not likely to ever exist in Debian repos. 


>>> < re: your github bug report >

Conforming to Debian policy does not come later, it comes first. Until I have a
proper Debianized package, I will not release Gitea into Debian. I /do/
however, have a lot of progress made and only a few more new dependencies that
need to pass through NEW.

If you would like to help, check out the "(un)reproducible" column here:
https://udd.debian.org/dmd/?michael%40lustfield.net#versions

Those issues need to be resolved before introducing additional packages into
Debian. Additional dependencies are needed for gitea.

-- 
Michael Lustfield



Bug#876236: xmlelements: FTBFS with python3.6 as a supported version

2017-09-19 Thread Andreas Beckmann
Source: xmlelements
Version: 1.0~prerelease-1
Severity: serious
Justification: fails to build from source

Hi,

xmlelements FTBFS (at least) since python3.6 became a supported python3
version:

 debian/rules build
dh build --with=python2,python3
   dh_update_autotools_config
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/xmlelements-1.0~prerelease'
set -xe; \
for py in python2.7 python3.6 python3.5; do \
$py setup.py build; \
done
+ python2.7 setup.py build
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
copying xe.py -> build/lib.linux-x86_64-2.7
+ python3.6 setup.py build
/bin/sh: 3: python3.6: not found
debian/rules:10: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 127
make[1]: Leaving directory '/build/xmlelements-1.0~prerelease'
debian/rules:28: recipe for target 'build' failed
make: *** [build] Error 2


Andreas


xmlelements_1.0~prerelease-1.log.gz
Description: application/gzip


Bug#876222: Should be in "contrib", not "main"

2017-09-19 Thread Wookey
On 2017-09-19 12:27 -0700, Josh Triplett wrote:
> Package: mali-midgard-dkms
> Severity: serious
> 
> The package description says:
> 
> > This provides the kernel module for the ARM Mali 'midgard' GPU series
> > in dkms format. This covers the 6xx and 7xx GPU hardware devices. You
> > need this kernel module as well the binary drivers to make the
> > hardware work.
> 
> If that's the case, and this kernel module doesn't do any good without
> the binary drivers, then this package should go to "contrib", not
> "main".

That's a good point. The plan was always to upload it to contrib originally,
but clearly I have failed to actually do so.
 
> If this kernel module has uses without the binary drivers (e.g. if it
> can be made to work with the reverse-engineered driver instead), then
> the description should make that clear.

The mali reverse-engineering effort has recently restarted after being
moribund for a few years, (https://github.com/yuq/mesa-lima) and it's
possible that this driver will be useful there, but I don't know that
yet. I'll check with that project and unless there is a prospect of
this driver being used by free software I'll move it.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature


Bug#876235: python-autobahn: missing B-D: openstack-pkg-tools

2017-09-19 Thread Andreas Beckmann
Source: python-autobahn
Version: 17.7.1+dfsg1-1
Severity: serious
Justification: fails to build from source

Hi,

python-autobahn/experimental FTBFS with

dh: Unknown sequence /usr/share/openstack-pkg-tools/pkgos.make (choose
from: binary binary-arch binary-indep build build-arch build-indep clean
install install-arch install-indep)


Andreas


python-autobahn_17.7.1+dfsg1-1.log.gz
Description: application/gzip


Bug#876233: backuppc: Can't backup IPv6-only hosts due to IPv4-only DNS lookups

2017-09-19 Thread Axel Beckert
Package: backuppc
Severity: important
Version: 3.3.1-4
Tags: ipv6

I have more and more IPv6-only hosts. But if I add one of them to
hosts.cfg, I always get "host not found" as error message.

In the documentation under "How BackupPC Finds Hosts", it says:

> First DNS is used to lookup the IP address given the client's name
> using perl's gethostbyname() function. This should succeed for
> machines that have fixed IP addresses that are known via DNS. You can
> manually see whether a given host have a DNS entry according to perl's
> gethostbyname function with this command:
>
> perl -e 'print(gethostbyname("myhost") ? "ok\n" : "not found\n");'

Example:

→ host ipv6.google.com
ipv6.google.com is an alias for ipv6.l.google.com.
ipv6.l.google.com has IPv6 address 2a00:1450:4016:80a::200e
$ perl -e 'print(gethostbyname("ipv6.google.com") ? "ok\n" : "not found\n");'
not found

So I can't backup this host despite SSH has no problem at all to reach
that host.

BackupPC should probably move to use Socket.pm's getaddrinfo instead as
it is IP-version agnostic.

So far I found no configuration-only workaround (i.e. disabling DNS
lookups at all as SSH does that already.)

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

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



Bug#876232: quassel-irssi: FTBFS with GCC 7 thanks to usage of -Werror

2017-09-19 Thread Andreas Beckmann
Source: quassel-irssi
Version: 0~git20170114-1
Severity: serious
Justification: fails to build from source

Hi,

quassel-irssi FTBFS (at least) since GCC 7 was made the default compiler
(and added some new warnings):


   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/quassel-irssi-0~git20170114'
/usr/bin/make -C core
make[2]: Entering directory '/build/quassel-irssi-0~git20170114/core'
cc -std=gnu11 -Wall -Wextra -Werror -g -O2 -I/usr/include/irssi//src/ 
-I/usr/include/irssi//src/core/ -I/usr/include/irssi//src/fe-common/ 
-I/usr/include/irssi//src/fe-common/core/ -I/usr/include/irssi//src/fe-text/ 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-DUOFF_T_LONG -fPIC -DHAVE_OPENSSL -I/usr/include/quasselc -Wmissing-prototypes 
-Wmissing-declarations  -Wdate-time -D_FORTIFY_SOURCE=2  -c -o 
quasselc-connector.o quasselc-connector.c
quasselc-connector.c: In function 'handle_sync':
quasselc-connector.c:146:6: error: this statement may fall through 
[-Werror=implicit-fallthrough=]
if(!fnc)
  ^
quasselc-connector.c:148:3: note: here
   case Displayed:
   ^~~~
quasselc-connector.c:156:6: error: this statement may fall through 
[-Werror=implicit-fallthrough=]
if(!fnc)
  ^
quasselc-connector.c:158:3: note: here
   case TempRemoved:
   ^~~~
quasselc-connector.c:211:6: error: this statement may fall through 
[-Werror=implicit-fallthrough=]
if(!fnc)
  ^
...


Andreas


quassel-irssi_0~git20170114-1.log.gz
Description: application/gzip


Bug#871806: uscan: (dpkg, git-buildpackage) accept/mangle/store signed git tags in cases where upstream does not publish detached sigs on tarballs

2017-09-19 Thread Tomasz Buchert
On 16/08/17 21:01, Daniel Kahn Gillmor wrote:
> Hi Guillem--
>
> On Thu 2017-08-17 01:05:46 +0200, Guillem Jover wrote:
> > It seems to me like you are perhaps trying to reimplement dpkg source
> > format «3.0 (git)» (described in man dpkg-source)? :)
>
> Thanks for that pointer, it does seem similar.
>
> I was hoping that we could produce an actual orig.tar.gz (so that the
> rest of the tools could use it as they have traditionally) and then some
> extra thing outside of the orig.tar.gz that, combined with the tarball,
> could be used to recreate the .git/ repository well enough to be able to
> (a) recreate the tarball, and (b) cryptographically verify the tag.
>
> this would solve my use case (being able to record and ship upstream's
> cryptographic signatures, when upstream "releases" with signed tags)
> without requiring the rest of the debian infrastructure to cope with git
> bundles as "orig.tar.gz-equivalent" blobs.
>
> But if there's a plan for "3.0 (git)" to become acceptable in debian,
> then it does seem like that might be the simplest way to move forward.
>
> i'll play around with git-bundle to try to understand it better.  from a
> scan of dpkg-source(1) and the various git manpages that i'm used to
> reading, i don't understand what .gitshallow or .git/shallow are
> supposed to do.  Does it get shipped alongside the .git?  does
> .git/shallow have meaning for other tools that i should be aware of?
>
>  --dkg

Hey all,

one of pristine-tar maintainers here. Daniel's ideas made me think a
lot about this stuff recently. I've just found
https://github.com/cgwalters/git-evtag: it does not solve the problem
at hand, but the idea of solving the problem "upstream", i.e., in git,
seems reasonable to me.

So let's assume that git-archive can produce a reproducible,
uncompressed tarball, given a particular githash. Why not ask
interested upstream developers to do something like that:

  git tag -s TAGNAME -m "$(git archive --format tar HEAD | sha512sum)"

The tag proves:
  (1) the history in the git repository, as always
  (2) but also that a tar generated from this tag should have a particular 
sha512 hash

You can see how this works end-to-end: if we want to take a particular
git tag and release it in Debian, we just generate the tarball and
extract the associated tag as a crypto-proof.

Such tagging may be prohibitive for every commit, though, since it's
rather expensive to compute (or not, I just run the above command in a
fresh clone of linux kernel source and it took 9s with fs caches, and
interestingly the same with caches dropped, weird). But it should be
totally fine at least for "release tags". The cool thing is that it
could be upstreamed in git, as a flag to git-tag, or at least provided
as an extension, such as git-atag (aka git-archive-tag, you get the
idea).

What do you think?

Tomasz


signature.asc
Description: PGP signature


Bug#876231: ruby-nmatrix: FTBFS with GCC 7: error: call of overloaded 'abs(nm::Rational&)' is ambiguous

2017-09-19 Thread Andreas Beckmann
Package: ruby-nmatrix
Version: 0.1.0~rc3-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

ruby-nmatrix FTBFS (at least) since GCC 7 was made the default compiler:

In file included from math.cpp:125:0:
math/idamax.h: In instantiation of 'int nm::math::idamax(size_t, DType*, int) 
[with DType = nm::Rational; size_t = long unsigned int]':
math/getrf.h:153:44:   required from 'int nm::math::getrf_nothrow(int, int, 
DType*, int, int*) [with bool RowMajor = true; DType = nm::Rational]'
math/getrf.h:211:37:   required from 'int nm::math::getrf(CBLAS_ORDER, int, 
int, DType*, int, int*) [with DType = nm::Rational]'
math/getrf.h:234:22:   required from 'int nm::math::clapack_getrf(CBLAS_ORDER, 
int, int, void*, int, int*) [with DType = nm::Rational]'
math.cpp:1295:3:   required from here
math/idamax.h:60:15: error: call of overloaded 'abs(nm::Rational&)' 
is ambiguous
 dmax = abs(dx[0]);
~~~^~~
In file included from /usr/include/c++/7/cstdlib:75:0,
 from /usr/include/c++/7/bits/stl_algo.h:59,
 from /usr/include/c++/7/algorithm:62,
 from math.cpp:116:
/usr/include/stdlib.h:735:12: note: candidate: int abs(int)
 extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
In file included from /usr/include/c++/7/cstdlib:77:0,
 from /usr/include/c++/7/bits/stl_algo.h:59,
 from /usr/include/c++/7/algorithm:62,
 from math.cpp:116:
/usr/include/c++/7/bits/std_abs.h:56:3: note: candidate: long int std::abs(long 
int)
   abs(long __i) { return __builtin_labs(__i); }
   ^~~
/usr/include/c++/7/bits/std_abs.h:61:3: note: candidate: long long int 
std::abs(long long int)
   abs(long long __x) { return __builtin_llabs (__x); }
   ^~~
/usr/include/c++/7/bits/std_abs.h:70:3: note: candidate: constexpr double 
std::abs(double)
   abs(double __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:74:3: note: candidate: constexpr float 
std::abs(float)
   abs(float __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:78:3: note: candidate: constexpr long double 
std::abs(long double)
   abs(long double __x)
   ^~~


Full log attached.

Andreas


ruby-nmatrix_0.1.0~rc3-2.log.gz
Description: application/gzip


Bug#876230: ssh-askpass-fullscreen: FTBFS: undefined reference to symbol 'XUngrabServer'

2017-09-19 Thread Andreas Beckmann
Source: ssh-askpass-fullscreen
Version: 0.4-0.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

ssh-askpass-fullscreen/experimental FTBFS in a current
sid/experimental environment:

 debian/rules build
dh build
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
make -j1
make[1]: Entering directory '/build/ssh-askpass-fullscreen-0.4'
cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/build/ssh-askpass-fullscreen-0.4=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -o 
ssh-askpass-fullscreen ssh-askpass-fullscreen.c `pkg-config --libs gtk+-2.0` 
`pkg-config --cflags gtk+-2.0`
ssh-askpass-fullscreen.c: In function 'passphrase_dialog':
ssh-askpass-fullscreen.c:275:40: warning: passing argument 1 of 
'gdk_pixbuf_new_from_xpm_data' from incompatible pointer type 
[-Wincompatible-pointer-types]
  pixbuf = gdk_pixbuf_new_from_xpm_data(ocean_stripes);
^
In file included from /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf.h:34:0,
 from /usr/include/gtk-2.0/gdk/gdkpixbuf.h:37,
 from /usr/include/gtk-2.0/gdk/gdkcairo.h:28,
 from /usr/include/gtk-2.0/gdk/gdk.h:33,
 from /usr/include/gtk-2.0/gdk/gdkprivate.h:30,
 from /usr/include/gtk-2.0/gdk/gdkx.h:30,
 from ssh-askpass-fullscreen.c:43:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:351:12: note: expected 
'const char **' but argument is of type 'char **'
 GdkPixbuf *gdk_pixbuf_new_from_xpm_data (const char **data);
^~~~
/usr/bin/ld: /tmp/cc2IPa2e.o: undefined reference to symbol 'XUngrabServer'
//usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
Makefile:2: recipe for target 'all' failed
make[1]: *** [all] Error 1
make[1]: Leaving directory '/build/ssh-askpass-fullscreen-0.4'
dh_auto_build: make -j1 returned exit code 2
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 2


Andreas


ssh-askpass-fullscreen_0.4-0.1.log.gz
Description: application/gzip


Bug#876033: primusrun doesn't find libGL.so.1

2017-09-19 Thread Bernd Vaske

Hello,

the problem comes from the transition of mesa to glvnd.
A workaround is to link the missing libs from

/usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1

and
/usr/lib/i386-linux-gnu/libGL.so.1 to 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1


That will result in primusrun starting again but most likely resulting 
in a black window for the application which is started.


To get primusrun to work properly you have to start it with 
__GLVND_DISALLOW_PATCHING=1


example:

__GLVND_DISALLOW_PATCHING=1 primusrun glxgears

Best regards



Bug#841733: Transition Opencv 3.1

2017-09-19 Thread Nobuhiro Iwamatsu
Hi,

2017-09-19 17:55 GMT+09:00 Mattia Rizzolo :
> On Tue, Sep 19, 2017 at 12:37:54PM +0900, Nobuhiro Iwamatsu wrote:
>> The following packages can be migrated with OpenCV 3.2:
>
> I should check again whether something changed since I last did my
> rebuild in July, but:
>
>> freecad
>
> this is not involved in the transition AFAIK
>
>> ros-opencv-apps
>
> this one failed for me

If we build this correctly, we need to build ros-vision-opencv first.

>
>> visp
>
> this for me failed to build on armhf
>
>> caffe
>> Not yet check
>> NOTE:  #875723
>
> also fails on armhf

This package  has long been FTBFS on armhf.

>
>> caffe-contrib
>> Not yet check
>> NOTE:  #875723
>
> failed
>
>> digikam
>> FTBFS / #841412
>> NOTE:  FTBFS on unstable #876154
>
> it built fine in july
>
>> mldemos
>> FTBFS /  #861270
>> NOTE: no rdeps: could be removed from testing
>
> it's already out of testing, so really don't bother about it.
>
>> nomacs
>> FTBFS
>> NOTE:  FTBFS on unstable  #876153
>
> previous version (-8) built fine for me

876153 is not a bug related to opencv, it is a symbol bug.

>
>
>
> BTW, I can see some free time popping up in the near future, so I should
> be able to get back on working on this from where I left it on July.
>
> No, about whether going with OCV 3.2 or 3.3… I'd kind of prefer to go
> with 3.2, as we have been test building and worked on it for a while,
> rather than risk to find ourselves in yet more failures to handle, not
> to say it would need to pass NEW again, which is kind of crowded right
> now...
>

I did not understand the meaning of "NEW", but I agree to target the
first transition as 3.2.

> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Best regards,
  Nobuhiro


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



Bug#876229: apport: FTBFS: B-D: libglib2.0-0-dbg is no longer available

2017-09-19 Thread Andreas Beckmann
Source: apport
Version: 2.20.4-2
Severity: serious
Justification: fails to build from source

# apt-get build-dep apport
Reading package lists... Done
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:apport : Depends: libglib2.0-0-dbg but it is not installable
E: Unable to correct problems, you have held broken packages.


Andreas



Bug#875771: nmu: libnettle6_3.3-1+b1 liblzma5_5.2.2-1.2+b1 libdb5.35.3.28-12+b1 libselinux1_5.2.2-1.2+b1

2017-09-19 Thread Adam D. Barratt
On Tue, 2017-09-19 at 19:38 +0100, Adam D. Barratt wrote:
> Scheduled as:
> 
> nmu 4 lzma . ANY . -m "Rebuild with current sbuild to fix changelog
> date"
> nmu 3 lzma . ANY . stretch . -m "Rebuild with current sbuild to fix
> changelog date"
> nmu nettle db5.3 libselinux . ANY . stretch . -m "Rebuild with
> current sbuild to fix changelog date"

I forgot about the fun wanna-build feature of not exposing the binNMU
version for most suites, so rescheduled the last set as explicit +b2
(after the initial set got rejected for being +b1 and stable already
having that version).

> (The former being required because both unstable and stretch
> currently
> contain lzma 9.22-2+b2, and not fixing the issue in unstable seems
> silly.)
> 

Regards,

Adam



Bug#876053: Acknowledgement (Swedish fakeroot translation out of date.)

2017-09-19 Thread Sebastian Rasmussen
tags: patch l10n

I got some comments from the people on the debian-l10n-swedish mailing list.
The attached .po-file adresses those issues.

 / Sebastian
# Swedish translations for fakeroot.
# Copyright (C) 2017 Free Software Foundation, Inc.
# Sebastian Rasmussen , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: fakeroot 1.22-1\n"
"POT-Creation-Date: 2017-08-16 22:29-0400\n"
"PO-Revision-Date: 2017-09-20 00:22+0200\n"
"Last-Translator: Sebastian Rasmussen \n"
"Language-Team: Swedish \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"
"X-Generator: Poedit 2.0.3\n"

# type: TH
#. type: TH
#: ../doc/fakeroot.1:16
#, no-wrap
msgid "fakeroot"
msgstr "fakeroot"

#. type: TH
#: ../doc/fakeroot.1:16
#, no-wrap
msgid "5 October 2014"
msgstr "5:e oktober 2014"

# type: TH
#. type: TH
#: ../doc/fakeroot.1:16 ../doc/faked.1:16
#, no-wrap
msgid "Debian Project"
msgstr "Debian Project"

# type: TH
#. type: TH
#: ../doc/fakeroot.1:16
#, no-wrap
msgid "Debian manual"
msgstr "Debian manual"

# type: SH
#. Manpage by J.H.M. Dassen 
#. and Clint Adams
#. type: SH
#: ../doc/fakeroot.1:19 ../doc/faked.1:19
#, no-wrap
msgid "NAME"
msgstr "NAMN"

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:22
msgid ""
"fakeroot - run a command in an environment faking root privileges for file "
"manipulation"
msgstr ""
"fakeroot - utför ett kommando i en miljö som fejkar root-privilegier för "
"filmanipulation"

# type: SH
#. type: SH
#: ../doc/fakeroot.1:22 ../doc/faked.1:22
#, no-wrap
msgid "SYNOPSIS"
msgstr "SYNOPSIS"

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:38
msgid ""
"B B<[-l|--lib> I B<[--faked> IB<]> B<[-i> "
"IB<]> B<[-s> IB<]> B<[-u|--unknown-is-real ]> B<[-b|--"
"fd-base ]> B<[-h|--help ]> B<[-v|--version ]> B<[--]> B<[command]>"
msgstr ""
"B B<[-l|--lib> I B<[--faked> IB<]> B<[-"
"i> IB<]> B<[-s> IB<]> B<[-u|--unknown-is-real ]> B<[-b|--fd-"
"base ]> B<[-h|--help ]> B<[-v|--version ]> B<[--]> B<[kommando]>"

# type: SH
#. type: SH
#: ../doc/fakeroot.1:38 ../doc/faked.1:30
#, no-wrap
msgid "DESCRIPTION"
msgstr "BESKRIVNING"

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:49
msgid ""
"B runs a command in an environment wherein it appears to have root "
"privileges for file manipulation.  This is useful for allowing users to "
"create archives (tar, ar, .deb etc.) with files in them with root "
"permissions/ownership.  Without B one would need to have root "
"privileges to create the constituent files of the archives with the correct "
"permissions and ownership, and then pack them up, or one would have to "
"construct the archives directly, without using the archiver."
msgstr ""
"B utför ett kommando i en miljö där kommandot tror sig ha root-"
"privilegier för filmanipulering. Detta är användbart för att ge användare "
"möjlighet att skapa arkiv (tar, ar, .deb osv) som innehåller filer med root-"
"rättigheter/ägarskap. Utan B tvingas man att ha root-privilegier "
"för att skapa de filer arkivet består av med korrekt ägarskaps- och "
"rättighetsinformation, alternativt konstruera arkiven manuellt utan att "
"använda arkiveringsprogrammet."

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:61
msgid ""
"B works by replacing the file manipulation library functions "
"(chmod(2), stat(2) etc.) by ones that simulate the effect the real library "
"functions would have had, had the user really been root. These wrapper "
"functions are in a shared library B or similar "
"location on your platform.  The shared object is loaded through the "
"B mechanism of the dynamic loader. (See B(8))"
msgstr ""
"B arbetar genom att ersätta biblioteksfunktionerna för modifiering "
"av filrättigheter (chmod(2), stat(2), osv) med sådana som simulerar effekten "
"som de riktiga biblioteksfunktionerna skulle ha haft om användaren verkligen "
"varit root. Dessa funktioner finns samlade i biblioteket B som laddas genom B-mekanismen hos den "
"dynamiska länkaren. (Se B(8))"

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:71
msgid ""
"If you intend to build packages with B, please try building the "
"fakeroot package first: the \"debian/rules build\" stage has a few tests "
"(testing mostly for bugs in old fakeroot versions). If those tests fail (for "
"example because you have certain libc5 programs on your system), other "
"packages you build with fakeroot will quite likely fail too, but possibly in "
"much more subtle ways."
msgstr ""
"Om du planerar att bygga paket med hjälp av B, försök först att "
"bygga fakeroot-paketet: ”debian/rules build”-stadiet har ett par tester (som "
"mestadels testar efter buggar i gamla versioner av fakeroot).  Om dessa "
"tester misslyckas (till exempel på grund av att du har vissa libc5-program "
"på ditt system) så är det 

Bug#820119: [www.debian.org] validation errors: cannot convert character reference to number X because character not in internal character set

2017-09-19 Thread Laura Arjona Reina
Hello all
Now that we are using the more modern tool onsgmls instead of nsgmls in our
"validate" script:

https://anonscm.debian.org/cgit/debwww/cron.git/tree/scripts/validate

I've returned to this bug.

The output of the validate script for the files containing "emojis" didn't
change much:

 Errors validating
/srv/www.debian.org/www/international/l10n/po/en_GB.it.html: ***
Line 122, character 357:  cannot convert character reference to number
128513 because character not in internal character set

I was a bit surprised that we are still getting these errors, because if I pass
the online w3c validator https://validator.w3.org/ or even a manual onsgmls
command in the machine that builds the website:

onsgmls -E0 -s /path/to/dtd /path/to/file

in both cases I don't get any error.
So I've looked at the "validate" script and played a bit with the options set
there, and I'd like to bring to your attention the lines L363-376:

# Determine whether we're dealing with HTML or XHTML and set the SP
# environment accordingly.
if ($xhtml{$htmlLevel}) {
$ENV{'SGML_CATALOG_FILES'} = $xhtmlCatalog;
$ENV{'SP_ENCODING'} = 'xml';
} else {
$ENV{'SGML_CATALOG_FILES'} = $htmlCatalog;
if (defined $charset) {
$ENV{'SP_ENCODING'} = $charset;
} else {
$ENV{'SP_ENCODING'} = "ISO-8859-1";
}
}
$ENV{'SP_CHARSET_FIXED'} = 1

If I comment this last line (and thus, letting onsgmls run in not fixed mode), I
get no errors validating the file.

I've read the documentation about these options:

http://openjade.sourceforge.net/doc/charset.htm

but frankly I don't understand it very much.

I've done:

larjona@wolkenstein:~$ sudo -u debwww env | grep SP_

and it returns nothing, so I guess only the environment set in "validate" script
is taken into account, if we don't set the variables there, defaults rule.

I've modified and run a copy of the validate script, making it print some values
when checking a file, and document type is correctly detected (HTML 4.01
Strict), as well as charset (utf-8).

I'm not sure I can safely comment the line 376

$ENV{'SP_CHARSET_FIXED'} = 1;

to avoid the errors, or even comment the whole paragraph, and trust onsgmls to
do the right thing.

Anybody with more experience in this can help?

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



Bug#835120: lintian: false positive: virtual-package-depends-without-real-package-depends for bacula-director

2017-09-19 Thread Chris Lamb
Mattia Rizzolo wrote:

> trying to regenerate [the list] drops the bacula-director and
> bacula-sd-tools packages and adds bacula-director-database.

Is that incorrect?


Carsten Leonhardt wrote:

> Is there a reason to not update it during build?

(Yes; it downloads stuff from the internet.)


Regards,

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



Bug#876228: twm should recommend menu

2017-09-19 Thread Kacper Gutowski
Package: twm
Version: 1:1.0.9-1+b1
Severity: minor

Currently twm package has a hard dependency on the menu package
but twm can work just fine without it except not showing Debian
menu in default configuration.  I thinks it should use Recommends
field instead.

-k



Bug#835120: lintian: false positive: virtual-package-depends-without-real-package-depends for bacula-director

2017-09-19 Thread Chris Lamb
retitle 835120 lintian: false positive: 
virtual-package-depends-without-real-package-depends for bacula-director
thanks

Mattia Rizzolo wrote:

> > So it had nothing to do with experimental as I suspected first.
>
> Indeed it hasn't at all.

Retitling bug to match updated synopsis. :)


Regards,

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



Bug#848982: wpasupplicant fails to connect to WPA Enterprise network with 2.6-2

2017-09-19 Thread Daniel Reichelt
I'm suffering the very same problem than the OP with my employer's WiFi
network.


> If I downgrade libssl1.0.2 to 1.0.2j-1 then I can connect to the
> WPA-EAP network without problem.

Good catch downgrading openssl! I can confirm the WiFi connection to
work up to libssl1.0.2-4 [1], so I guess the fix for #736687 is to blame
for this [2]:

 * Mark RC4 and 3DES as weak which removes them from the SSL/TLS
protocol (Closes: #736687).



As a *dirty* workaround, I

- re-upgraded to libssl1.0.2ll-2/stretch
- renamed /sbin/wpa_supplicant and put a wrapper script in its place
- which sets LD_LIBRARY_PATH to a location containing libssl.so.1.0.2
from [1] and then starts the renamed wpa_supplicant binary with the
original command-line parameters.



HTH,

Daniel



[1]
http://snapshot.debian.org/package/openssl1.0/1.0.2j-4/#libssl1.0.2_1.0.2j-4

[2]
https://anonscm.debian.org/viewvc/pkg-openssl/openssl/branches/openssl1.0/debian/patches/Mark-3DES-and-RC4-ciphers-as-weak.patch?revision=865=markup=log



signature.asc
Description: OpenPGP digital signature


Bug#876227: release.debian.org: nmu: cheese, gnome-dvb-daemon, grilo-plugins, gstreamer-vaapi, webkit2gtk

2017-09-19 Thread Matteo F. Vescovi
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi team!

A new version of gst-plugins-bad1.0 was uploaded yesterday and all its
reverse dependencies are now in need of a binNMU to fix the wrong shlibs
versioning.

  nmu cheese_3.26.0-1 . ANY . -m 'Rebuild against new gst-plugins-bad1.0 
version'
  nmu gnome-dvb-daemon_1:0.2.91~git20170110-2 . ANY . -m 'Rebuild against new 
gst-plugins-bad1.0 version'
  nmu grilo-plugins_0.3.5-2 . ANY . -m 'Rebuild against new gst-plugins-bad1.0 
version'
  nmu gstreamer-vaapi_1.12.2-1 . ANY . -m 'Rebuild against new 
gst-plugins-bad1.0 version'
  nmu webkit2gtk_2.18.0-2 . ANY . -m 'Rebuild against new gst-plugins-bad1.0 
version'

Thanks.


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

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



Bug#873094: RFS: granite/0.4.1-1 [ITP]

2017-09-19 Thread Jeremy Bicha
debian/control:
- Please remove or update the Vcs fields
- Please drop the Pre-Depends lines
- Maybe https://github.com/elementary/granite is a better homepage?

debian/rules:
- Please drop the dh_builddeb rule. xz is already the default
- Please use c4 for the makeshlibs rule

debian/changelog:
- I think it is appropriate to keep the old changelog entries since
this package was only removed from Debian 6 months ago.

debian/copyright:
- Please update the Source line to point to github since that's where
your watch file points

Please use automatic debug packages. In particular, see the top
section (before Summary) of
https://wiki.debian.org/AutomaticDebugPackages

Thanks,
Jeremy Bicha



Bug#876226: yad: Please, update the version

2017-09-19 Thread Angela Ferreira
Package: yad
Version: 0.38.2-1
Severity: minor

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Nothing
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.10.15-1-pve (SMP w/2 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 yad depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1

yad recommends no packages.

yad suggests no packages.

-- no debconf information



Bug#854062: xournal: Hangs upon pressing Ctrl-S (for saving)

2017-09-19 Thread Ondřej Lhoták
I was experiencing the same issue. The file selection dialog for both
the Save As and Export to PDF actions did not appear, and Xournal would
hang.

I deselected Use XInput in the Options menu. That fixed the issue. Both
Save As and Export to PDF work for me when Use XInput is deselected.

This seems to be related to upstream bug 170:
https://sourceforge.net/p/xournal/bugs/170/



Bug#876224: dak: dak rm -nR throws "SAWarning: Textual SQL expression"-warnings on stretch

2017-09-19 Thread Niels Thykier
Package: dak
Severity: minor

Doing a dak rm -nR on respighi (upgraded to stretch) gave the
following warning:

"""
/usr/lib/python2.7/dist-packages/sqlalchemy/sql/elements.py:3795: SAWarning: 
Textual SQL expression '\nSELECT s.source,...' should be explicitly 
declared as text('\nSELECT s.source,...') (this warning may be 
suppressed after 10 occurrences)
  {"expr": util.ellipses_string(element)})
# Broken Build-Depends:
"""

(actually, I think the warning appeared twice; once for Depends and once for 
Build-Depends, but scroll back buffer wasn't large enough to hold both).

The command still appears to function and produce the proper output
and accordingly the severity is "minor".

Thanks,
~Niels



Bug#876225: Switch schroot to use overlay fs

2017-09-19 Thread Vagrant Cascadian
Package: jenkins.debian.org
Severity: normal
Tags: patch

Branch for jenkins.debian.net "schroot-overlay" available at:

  
https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git/log/?h=schroot-overlay

Patch included below for easy reference.

live well,
  vagrant

From e6fde8ffe8a01b594670e8dd1b9a9fd8a08a3f58 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 19 Sep 2017 13:15:19 -0700
Subject: [PATCH] Switch schroot to use overlay fs, as aufs is no longer
 supported out of the box in linux 4.x kernels.

---
 bin/schroot-create.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/schroot-create.sh b/bin/schroot-create.sh
index 5418b180..6c8bcb5b 100755
--- a/bin/schroot-create.sh
+++ b/bin/schroot-create.sh
@@ -275,7 +275,7 @@ sudo tee /etc/schroot/chroot.d/jenkins-"$TARGET" <<-__END__
type=directory
root-users=jenkins
source-root-users=jenkins
-   union-type=aufs
+   union-type=overlay
__END__
 
 echo "schroot $TARGET set up successfully in $SCHROOT_BASE/$TARGET - exiting 
now."
-- 
2.11.0



signature.asc
Description: PGP signature


Bug#867660: ball: FTBFS with sip 4.19.x: sip: File::CannotWrite has not been defined

2017-09-19 Thread Andreas Tille
On Tue, Sep 19, 2017 at 08:53:28PM +0300, Dmitry Shachnev wrote:
> Control: block 876205 by -1
> 
> On Tue, Sep 05, 2017 at 04:00:50PM +0300, Dmitry Shachnev wrote:
> > I just tested on a clean sid amd64 chroot (with sip 4.19 from experimental)
> > and all the tests pass for me:
> >
> >   100% tests passed, 0 tests failed out of 333
> >
> > Maybe it was some temporary issue?
> 
> I have just requested a transition slot for sip 4.19 upload, so this needs
> to be fixed soon, otherwise it will FTBFS.
> 
> At the same time, please call dh_sip helper after dh_install so that your
> package gets the right dependency on sip-abi-12.x.

I would love to upload as commited in Git (including the dh_sip call) but
when trying to build in a clean chroot I get:


...
99% tests passed, 4 tests failed out of 333

Total Test time (real) =  27.26 sec

The following tests FAILED:
 13 - Vector4_test (Failed)
 69 - Selectable_test (Failed)
159 - PTE_test (Failed)
160 - Atom_test (Failed)
Errors while running CTest
Makefile:95: recipe for target 'test' failed
...


Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#876223: yad: Table split lines are not showing

2017-09-19 Thread Angela Ferreira
Package: yad
Version: 0.38.2-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Nothing
   * What was the outcome of this action?
   * What outcome did you expect instead?
Dividers lines help in organizing a table. Content gets confusing 
without this split

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


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

Kernel: Linux 4.10.15-1-pve (SMP w/2 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 yad depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1

yad recommends no packages.

yad suggests no packages.

-- no debconf information



Bug#876222: Should be in "contrib", not "main"

2017-09-19 Thread Josh Triplett
Package: mali-midgard-dkms
Severity: serious

The package description says:

> This provides the kernel module for the ARM Mali 'midgard' GPU series
> in dkms format. This covers the 6xx and 7xx GPU hardware devices. You
> need this kernel module as well the binary drivers to make the
> hardware work.

If that's the case, and this kernel module doesn't do any good without
the binary drivers, then this package should go to "contrib", not
"main".

If this kernel module has uses without the binary drivers (e.g. if it
can be made to work with the reverse-engineered driver instead), then
the description should make that clear.

- Josh Triplett



Bug#876217: Pending fixes for bugs in the libwww-dict-leo-org-perl package

2017-09-19 Thread pkg-perl-maintainers
tag 876217 + pending
thanks

Some bugs in the libwww-dict-leo-org-perl package are closed in
revision 0d8065f53978e208444a6000970a6be072a6e680 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libwww-dict-leo-org-perl.git/commit/?id=0d8065f

Commit message:

New upstream release. Fixes "leo returns got HTTP error 301! at 
/usr/bin/leo line 250." (Closes: #876217)



Bug#786402: New repository on github

2017-09-19 Thread Elena ``of Valhalla''
More info.

The original author has left_ the project, it has been migrated over
to github_ and they are thinking to change_ the name.

.. _left: https://forum.valentina-project.org/t/i-am-leaving-the-project/1628
.. _github: https://github.com/valentina-project/vpo2
.. _change: https://forum.valentina-project.org/t/new-name-for-valentina/1839
-- 
Elena ``of Valhalla''



Bug#876221: log uninitialized stack in non-default configuration [CVE-2017-0380]

2017-09-19 Thread Peter Palfrader
Package: tor
Severity: serious
Version: 0.2.7.2-alpha-1
Control: forwarded -1 https://bugs.torproject.org/23490

tor could log uninitialized stack when a certain hidden service error occurred
while SafeLogging was disabled.

This is also tracked as TROVE-2017-008 and CVE-2017-0380.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/



Bug#876220: libglvnd0:amd64: KDE will not start due to undefined symbol

2017-09-19 Thread Matt Stamp
Package: libglvnd0
Version: 0.2.999+git20170802-4
Severity: normal

Dear Maintainer,

An upgrade of libgl1:amd64 broken XServer and it cannot start.

[32.012] (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: /
usr/lib/x86_64-linux-gnu/libGL.so.1: undefined symbol: _glapi_tls_Current
[32.012] (EE) Failed to load module "glx" (loader failed, 7)

root@fusion:/home/matt# ldd -r /usr/lib/x86_64-linux-gnu/libGL.so.1
linux-vdso.so.1 (0x7ffdc5b64000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 
(0x7f810f231000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 
(0x7f810ef63000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f810ed5f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f810eb42000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f810e7a5000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 
(0x7f810e465000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 
(0x7f810e253000)
/lib64/ld-linux-x86-64.so.2 (0x7f810f6ee000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 
(0x7f810e02b000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 
(0x7f810de27000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 
(0x7f810dc21000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f810da0c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f810d804000)
undefined symbol: _glapi_tls_Current(/usr/lib/x86_64-linux-gnu/libGL.so.1)

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

Kernel: Linux 4.12.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 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libglvnd0:amd64 depends on:
ii  libc6  2.24-17

libglvnd0:amd64 recommends no packages.

libglvnd0:amd64 suggests no packages.

-- no debconf information



Bug#876219: banshee: FTBFS: configure: error: missing required Mono 2.0 assembly: Mono.Posix.dll

2017-09-19 Thread Andreas Beckmann
Source: banshee
Version: 2.9.1-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

banshee/experimental FTBFS in sid/experimental with

...
checking for MONO_MODULE... yes
checking for dmcs... /usr/bin/mono-csc
checking for mono... /usr/bin/mono
checking for Mono 2.0 GAC for Mono.Posix.dll... not found
configure: error: missing required Mono 2.0 assembly: Mono.Posix.dll
...

Full log attached.


Andreas


banshee_2.9.1-5.log.gz
Description: application/gzip


Bug#874208: octave: audiodevinfo makes octave segfault when jackd is running

2017-09-19 Thread Mike Miller
On Tue, Sep 19, 2017 at 13:12:27 +0200, Peter P. wrote:
> Thank you Mike, switching to jackd2 does work for me as well! I am a bit
> hesitant to switch my system to jackd2 as there are some other
> applications that depend (more) on jackd1. I wonder if this workaround,
> for which I am very thankful, means that the crash with jackd1 will not
> me looked into further, or if it may be worked on nevertheless.

I also get success with jackd1:

$ jackd -r -d alsa -d hw:1 -D -r 44100 &
[1] 5042
jackd 0.125.0rc1
...
$ octave-cli -q
>> devs = audiodevinfo;  ## no crash
>> devs.output.Name
ans = HDA Intel HDMI: 0 (hw:0,3) (ALSA)
ans = HDA Intel HDMI: 1 (hw:0,7) (ALSA)
ans = HDA Intel HDMI: 2 (hw:0,8) (ALSA)
ans = HDA Intel HDMI: 3 (hw:0,9) (ALSA)
ans = HDA Intel HDMI: 4 (hw:0,10) (ALSA)
ans = hdmi (ALSA)
ans = default (ALSA)
ans = system (JACK Audio Connection Kit)
>> x = audioplayer (y, fs, nbits, 7);  ## jack ID == 7
>> play (x);  ## produces audio

I'm sorry but I use neither jackd1 nor jackd2, so this is probably as
far as I can investigate myself. And as far as I can tell they both work
with Octave. If you can investigate further and find what is causing
this on your system, please do report back. Or if you find that you can
reproduce this on a clean system and give instructions for how to do so,
someone may be able to help. But so far this looks unreproducible to me.

-- 
mike


signature.asc
Description: PGP signature


Bug#876218: libneo4j-client: FTBFS with "output truncated before the last format character"

2017-09-19 Thread Andreas Beckmann
Source: libneo4j-client
Version: 2.1.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

libneo4j-client/experimental FTBFS with GCC 7:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -Wpedantic -Wvla -g -O2 
-fdebug-prefix-map=/build/libneo4j-client-2.1.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -
std=gnu11 -fvisibility=hidden -pipe -Wall -W -Werror -Wno-unused-parameter 
-Wno-missing-field-initializers -Wpointer-arith -Wstrict-prototypes -Wcast-qual 
-Wcast-align -Wno-error=unused-function -Wno-error=unused-variable -Wn
o-error=deprecated-declarations -c render.c  -fPIC -DPIC -o 
.libs/libneo4j_client_la-render.o
render.c: In function 'render_field':
render.c:610:17: error: '__builtin___snprintf_chk' output truncated before the 
last format character [-Werror=format-truncation=]
 if (snprintf(buf, sizeof(buf), "\\U%08X", codepoint) < 0)
 ^~~~
In file included from /usr/include/stdio.h:938:0,
 from neo4j-client.h:27,
 from render.h:20,
 from render.c:18:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: note: 
'__builtin___snprintf_chk' output 11 bytes into a destination of size 10
   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
  ^~~~
__bos (__s), __fmt, __va_arg_pack ());
~
cc1: all warnings being treated as errors
Makefile:688: recipe for target 'libneo4j_client_la-render.lo' failed
make[4]: *** [libneo4j_client_la-render.lo] Error 1


Full log attached.


Andreas


libneo4j-client_2.1.2-1.log.gz
Description: application/gzip


Bug#862328: ping

2017-09-19 Thread Mario Lang
Hi.

I've just been bitten by the same problem.  It appears to still be an
issue even with libclang-5.0-dev.  find_package(Clang) doesn't work,
also if Clang_DIR is provided.

-- 
CYa,
  ⡍⠁⠗⠊⠕



Bug#876217: libwww-dict-leo-org-perl: leo returns got HTTP error 301! at /usr/bin/leo line 250.

2017-09-19 Thread Helge Kreutzmann
Package: libwww-dict-leo-org-perl
Version: 2.00-1
Severity: important

Whatever german or english word I try, I always get:
got HTTP error 301!
 at /usr/bin/leo line 250.

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

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

Versions of packages libwww-dict-leo-org-perl depends on:
ii  libxml-simple-perl  2.22-1
ii  perl5.24.1-3+deb9u1

libwww-dict-leo-org-perl recommends no packages.

libwww-dict-leo-org-perl suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature


Bug#876216: pyfeed: FTBFS with python3.6 as a supported version

2017-09-19 Thread Andreas Beckmann
Source: pyfeed
Version: 1.0~prerelease-1
Severity: serious
Justification: fails to build from source

Hi,

pyfeed/experimental FTBFS (at least) since python3.6 became a supported
version:

   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/pyfeed-1.0~prerelease'
set -xe; \
for py in python2.7 python3.6 python3.5; do \
$py setup.py build; \
done
+ python2.7 setup.py build
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/feed
copying feed/atom.py -> build/lib.linux-x86_64-2.7/feed
copying feed/rss.py -> build/lib.linux-x86_64-2.7/feed
copying feed/opml1.py -> build/lib.linux-x86_64-2.7/feed
copying feed/opml.py -> build/lib.linux-x86_64-2.7/feed
copying feed/__init__.py -> build/lib.linux-x86_64-2.7/feed
copying feed/tools.py -> build/lib.linux-x86_64-2.7/feed
creating build/lib.linux-x86_64-2.7/feed/date
copying feed/date/__init__.py -> build/lib.linux-x86_64-2.7/feed/date
copying feed/date/rfc822.py -> build/lib.linux-x86_64-2.7/feed/date
copying feed/date/tools.py -> build/lib.linux-x86_64-2.7/feed/date
copying feed/date/rfc3339.py -> build/lib.linux-x86_64-2.7/feed/date
+ python3.6 setup.py build
/bin/sh: 3: python3.6: not found
debian/rules:10: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 127


Full log attached.

Andreas


pyfeed_1.0~prerelease-1.log.gz
Description: application/gzip


Bug#876215: linux-base: typo in linux-update-symlinks.1

2017-09-19 Thread Sven Joachim
Package: linux-base
Version: 4.5
Tags: patch

I wanted to get rid of the /vmlinuz and /initrd symlinks.  It took me a
while to find out that they are managed by linux-update-symlinks, and
then a trivial but crucial typo in the manpage did cost me even more
time to figure out that the parameter I needed to set is called
do_symlinks rather than no_symlinks.  Patch attached.


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

Kernel: Linux 4.13.2-nouveau (SMP w/2 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 linux-base depends on:
ii  debconf  1.5.63

linux-base recommends no packages.

linux-base suggests no packages.


>From ca0c57a5213074261ce8e07a42533d79f8b0675d Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Tue, 19 Sep 2017 20:36:55 +0200
Subject: [PATCH] Fix typo in linux-update-symlinks.1

---
 man/linux-update-symlinks.1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/linux-update-symlinks.1 b/man/linux-update-symlinks.1
index 97754db..c6ea4dc 100644
--- a/man/linux-update-symlinks.1
+++ b/man/linux-update-symlinks.1
@@ -31,7 +31,7 @@ Specifies the directory in which to maintain symlinks
 .B link_in_boot
 If set to a true value, specifies that the directory is \fI/boot\fR
 .TP
-.B no_symlinks
+.B do_symlinks
 If set to a false value, disables maintenance of symlinks
 .PD 1
 .PP
-- 
2.14.1



Bug#876196: libpam-krb5: login/unlock-screen/sudo waits VERY long time for DNS response

2017-09-19 Thread Rafal Pietrak


W dniu 19.09.2017 o 19:41, Russ Allbery pisze:
> Rafal Pietrak  writes:
> 
>> I did attempt that, but without success.
> 
>> When I swapped krb5 entry with unix entry in common-password, nothing
>> changes. When I did that in common-auth I've go "bad password" response
>> from sudo command.
> 
> You want common-auth, not common-password.
> 
> Are you sure that you're using the password in the local system
> /etc/shadow and that you've set the pam_unix module as sufficient so that
> pam_krb5 doesn't run if it succeeds?  You want something like:

Yes I am. That was the initial configuration of the notebook. I've added
kerberos later to be able to access ActiveDirectory domain resources at
work.

> 
> auth  sufficient   pam_unix.so
> auth  required pam_krb5.so try_first_pass minimum_uid=1000

I have this (default on debian-9 .. I haven't touched it before):
auth[success=2 default=ignore]  pam_krb5.so minimum_uid=1000
auth[success=1 default=ignore]  pam_unix.so nullok_secure try_first_pass

which I've temporarily swapped ... and in consequence got the "bad
password" result. Apparently I haven't changed everything that's
necesary for it to work ... but I don't know what exactly.

[-]
> 
> Unless carefully configured to not be the default authentication option,
> and honestly even then, a Kerberos PAM module is not a good configuration
> for systems that have spotty network connectivity.  Have you considered
> removing the PAM module entirely, using local system authentication, and
> running kinit when you want Kerberos tickets?  That's what I do.

OK. This should be quite fine. If timeouts are gone, I think I can live
with that.

... and may be exactly this should be suggested as a warning during
libpam installation? Like accompained by an advice to install sssd instead?


-R



Bug#876214: pond: FTBFS cannot find package "appengine" "appengine/datastore" "github.com/agl/go-gtk/gdk" ...

2017-09-19 Thread Andreas Beckmann
Source: pond
Version: 0.1.1-4
Severity: serious
Justification: fails to build from source

Hi,

pond cannot be built any longer in a current sid/experimental
environment:

   dh_golang -O--buildsystem=golang
can't load package: package appengine: cannot find package "appengine" in any 
of:
/usr/lib/go-1.9/src/appengine (from $GOROOT)
/build/pond-0.1.1/obj-x86_64-linux-gnu/src/appengine (from $GOPATH)
can't load package: package appengine/datastore: cannot find package 
"appengine/datastore" in any of:
/usr/lib/go-1.9/src/appengine/datastore (from $GOROOT)
/build/pond-0.1.1/obj-x86_64-linux-gnu/src/appengine/datastore (from 
$GOPATH)
can't load package: package github.com/agl/go-gtk/gdk: cannot find package 
"github.com/agl/go-gtk/gdk" in any of:
/usr/lib/go-1.9/src/github.com/agl/go-gtk/gdk (from $GOROOT)
/build/pond-0.1.1/obj-x86_64-linux-gnu/src/github.com/agl/go-gtk/gdk 
(from $GOPATH)
can't load package: package github.com/agl/go-gtk/gdkpixbuf: cannot find 
package "github.com/agl/go-gtk/gdkpixbuf" in any of:
/usr/lib/go-1.9/src/github.com/agl/go-gtk/gdkpixbuf (from $GOROOT)

/build/pond-0.1.1/obj-x86_64-linux-gnu/src/github.com/agl/go-gtk/gdkpixbuf 
(from $GOPATH)
can't load package: package github.com/agl/go-gtk/glib: cannot find package 
"github.com/agl/go-gtk/glib" in any of:
/usr/lib/go-1.9/src/github.com/agl/go-gtk/glib (from $GOROOT)
/build/pond-0.1.1/obj-x86_64-linux-gnu/src/github.com/agl/go-gtk/glib 
(from $GOPATH)
can't load package: package github.com/agl/go-gtk/gtk: cannot find package 
"github.com/agl/go-gtk/gtk" in any of:
/usr/lib/go-1.9/src/github.com/agl/go-gtk/gtk (from $GOROOT)
/build/pond-0.1.1/obj-x86_64-linux-gnu/src/github.com/agl/go-gtk/gtk 
(from $GOPATH)
can't load package: package github.com/agl/go-gtk/gtkspell: cannot find package 
"github.com/agl/go-gtk/gtkspell" in any of:
/usr/lib/go-1.9/src/github.com/agl/go-gtk/gtkspell (from $GOROOT)

/build/pond-0.1.1/obj-x86_64-linux-gnu/src/github.com/agl/go-gtk/gtkspell (from 
$GOPATH)
dh_golang: go list -f '\
{{ .Dir }}/{{ index (or .GoFiles .CgoFiles .TestGoFiles .XTestGoFiles 
.IgnoredGoFiles) 0 }}' returned exit code 1
debian/rules:42: recipe for target 'binary' failed
make: *** [binary] Error 1


Full log attached.


Andreas


pond_0.1.1-4.log.gz
Description: application/gzip


Bug#875771: nmu: libnettle6_3.3-1+b1 liblzma5_5.2.2-1.2+b1 libdb5.35.3.28-12+b1 libselinux1_5.2.2-1.2+b1

2017-09-19 Thread Adam D. Barratt
Control: tags -1 + stretch

On Thu, 2017-09-14 at 14:18 +0200, Michael Prokop wrote:
> nmu libnettle6_3.3-1+b1 liblzma5_5.2.2-1.2+b1 libdb5.35.3.28-12+b1
> libselinux1_5.2.2-1.2+b1 . ALL . -m "fix wrong build date"

Thanks for the suggested command. However, it's broken in at least
three ways - wanna-build works (predictably) on source packages, not
binary packages, the magic for "all architectures" is ANY, not ALL, and
as given your command applies to unstable, not stretch.

(Oh, also a missing underscore in the db5.3 entry and the version for
libselinux is copy-n-wasted from lzma.)

> sbuild in versions older than 0.73.0-1 didn't use the build date as
> binnmu changelog date. The binNMUs of libdb5.3, liblzma5, libnettle6
> + libselinux1 as present in stretch are affected by this (wrong)
> behavior. (Related see #843773 + #873489.)

Scheduled as:

nmu 4 lzma . ANY . -m "Rebuild with current sbuild to fix changelog date"
nmu 3 lzma . ANY . stretch . -m "Rebuild with current sbuild to fix changelog 
date"
nmu nettle db5.3 libselinux . ANY . stretch . -m "Rebuild with current sbuild 
to fix changelog date"

(The former being required because both unstable and stretch currently
contain lzma 9.22-2+b2, and not fixing the issue in unstable seems
silly.)

Regards,

Adam



Bug#876196: libpam-krb5: login/unlock-screen/sudo waits VERY long time for DNS response

2017-09-19 Thread Russ Allbery
Rafal Pietrak  writes:

> I have this (default on debian-9 .. I haven't touched it before):
> auth  [success=2 default=ignore]  pam_krb5.so minimum_uid=1000
> auth  [success=1 default=ignore]  pam_unix.so nullok_secure try_first_pass

> which I've temporarily swapped ... and in consequence got the "bad
> password" result. Apparently I haven't changed everything that's
> necesary for it to work ... but I don't know what exactly.

You would need to change the success numbers as well so that the first
module skips two subsequent modules and the second skips one.

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



Bug#876213: RFP: libdearimgui -- Bloat-free Immediate Mode Graphical User interface for C++ with minimal dependencies

2017-09-19 Thread Federico Ceratto
Package: wnpp
Severity: wishlist

* Package name: libdearimgui
  Version : 1.51
  Upstream Author : Omar Cornut
* URL : https://github.com/ocornut/imgui
* License : MIT
  Programming Lang: C++
  Description : Bloat-free Immediate Mode Graphical User interface for C++ 
with minimal dependencies

Dear ImGui is a bloat-free graphical user interface library for C++. It outputs 
optimized vertex buffers that you can render anytime in your 3D-pipeline 
enabled application. It is fast, portable, renderer agnostic and self-contained 
(no external dependencies).

Dear ImGui is designed to enable fast iteration and empower programmers to 
create content creation tools and visualization/ debug tools (as opposed to UI 
for the average end-user). It favors simplicity and productivity toward this 
goal, and thus lacks certain features normally found in more high-level 
libraries.


The library is used in the Goxel voxel editor.



Bug#875951: pyjwt: new upstream version available

2017-09-19 Thread Salvatore Bonaccorso
Hello Daniele,

On Mon, Sep 18, 2017 at 02:35:05AM +0200, Daniele Tricoli wrote:
> Hello Salvatore,
> 
> On Saturday, September 16, 2017 3:19:51 PM CEST Salvatore Bonaccorso wrote:
> > There is a new upstream version availabe for pyjwt, could you consider
> > packaging it for unstable?
> 
> Sorry for the deplay. I plan to update pyjwt in a couple of days.
> 
> Thanks for your upload of pyjwt for Stretch.

Well actually I did not do that, but Moritz picked it up.

If you plan to upload new version soonish I can as well cancel my NMU
for unstable, or, preferably speed it up, by rescheduling and having
the NMU integrated into the changelog.

What you prefer, for now I leave it in the delayed queue.

Regards,
Salvatore



Bug#876212: reproducible: re-add armhf node ff64a

2017-09-19 Thread Vagrant Cascadian
Package: jenkins.debian.org
Severity: normal
Tags: patch
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Welcome back ff64a-armhf-rb.debian.net. Specs and fingerprints are
unchanged.

With the 4.14-rc1 kernel, the firefly-rk3399 boards have working cpufreq
support, and so the CPU can run at full speed (on most of the cores, at
least).

Branch for jenkins.debian.net "welcome-back-ff64a" available at:

  
https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git/log/?h=welcome-back-ff64a

Hopefully everything needed to enable these is in those commits.

Thanks for maintaining jenkins!

live well,
  vagrant


signature.asc
Description: PGP signature


Bug#825949: pam_systemd(su:session): Cannot create session: Already running in a session

2017-09-19 Thread Michael Biebl
Am 19.09.2017 um 09:36 schrieb Thomas D:
> Dear maintainers,
> 
> I can confirm this bug is present in an up-to-date Stretch as of today.
> Are there any plans on this being fixed in Stretch?

Not that I'm aware of. Do you want to work on it?


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



signature.asc
Description: OpenPGP digital signature


Bug#876211: RFP: libinih -- simple .INI file parser

2017-09-19 Thread Federico Ceratto
Package: wnpp
Severity: wishlist

* Package name: libinih
  Version : r40
  Upstream Author : Ben Hoyt
* URL : https://github.com/benhoyt/inih
* License : BSD
  Programming Lang: C
  Description : simple .INI file parser

inih (INI Not Invented Here) is a simple .INI file parser written in C.
It's only a couple of pages of code, and it was designed to be small and
simple, so it's good for embedded systems. It's also more or less
compatible with Python's ConfigParser style of .INI files, including
RFC 822-style multi-line syntax and name: value entries.

It is used by the Goxel 3D voxel editor.



Bug#876210: pktanon: FTBFS on non-Linux: missing headers required for raw sockets

2017-09-19 Thread Aaron M. Ucko
Source: pktanon
Version: 2~git20160407.0.2bde4f2+dfsg-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org

Builds of pktanon for hurd-i386 and kfreebsd-* (admittedly not release
architectures) have been failing:

  checking for linux/if_ether.h... no
  configure: error: "missing headers required for raw sockets"

Could you please take a look?  If support for other kernels won't be
forthcoming, please set the package's architecture to linux-any for
now so that non-Linux autobuilders don't bother trying to cover it.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#876209: libgd3:i386 conflicts with libgd3:amd64

2017-09-19 Thread Vincas Dargis
Package: libgd3
Version: 2.2.5-3
Severity: important

Dear Maintainer,

I have tried to install winehq-staging package from wineqh.org, but it
fails with this chain:

```
winehq-staging : Depends: wine-staging (= 2.16.0~buster)

wine-staging : Depends: wine-staging-i386 (= 2.16.0~buster)

wine-staging-i386:i386 : Depends: libgphoto2-6:i386 (>= 2.5.10) but it
 is not going to be installed

libgphoto2-6:i386 : Depends: libgd3:i386 (>= 2.1.0~alpha~) but it is not
going to be installed
```

Now, if I try to insalled that `libgd3:i386`, I get:

The following additional packages will be installed:
  libjbig0:i386 libtiff5:i386 libwebp6:i386 libxpm4:i386
Suggested packages:
  libgd-tools:i386
The following packages will be REMOVED:
  kamera libgd3 libgphoto2-6 libsane sane-utils
The following NEW packages will be installed:
  libgd3:i386 libjbig0:i386 libtiff5:i386 libwebp6:i386 libxpm4:i386

So it wants to remove libgd3 for some reason?


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

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

Versions of packages libgd3 depends on:
ii  libc62.24-17
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8-0.2
ii  libjpeg62-turbo  1:1.5.2-2
ii  libpng16-16  1.6.32-1
ii  libtiff5 4.0.8-5
ii  libwebp6 0.6.0-3
ii  libx11-6 2:1.6.4-3
ii  libxpm4  1:3.5.12-1
ii  zlib1g   1:1.2.8.dfsg-5

libgd3 recommends no packages.

Versions of packages libgd3 suggests:
pn  libgd-tools  

-- no debconf information



Bug#876184: pdfsam: Disable donation window, news, and ads for premiun features

2017-09-19 Thread Michael Weghorn
Hi Markus,

thank you you for your quick reply and the clarification.

As I said before, this is OK with me. (We'll then probably deploy an
adapted version of the package within our organisation to comply with
our security policies.)

Regards,
  Michael



signature.asc
Description: OpenPGP digital signature


Bug#868082: linux-image-4.11.0-1-686: fails to boot on i386 (Soekris net5501)

2017-09-19 Thread R.
Hello,

I'm experiencing the same problem on Soekris net5501, also with the latest
testing 4.12.0.1-686 kernel : the boot process gets stuck on "Loading
initial ramdisk".

The 4.9.0.3-686 boots correctly.

Regards

On Sat, 26 Aug 2017 13:02:18 +0200 Francesco Poli 
wrote:
> Control: found -1 linux/4.12.6-1
>
>
> On Mon, 17 Jul 2017 09:59:38 +0200 Francesco Poli wrote:
>
> > On Sun, 16 Jul 2017 22:27:10 +0100 Ben Hutchings wrote:
> >
> > [...]
> > > If you add 'earlyprintk=ttyS0' to the kernel command line and delete
> > > 'quiet', does it log anything?
> >
> > Hello Ben,
> > thanks for your follow up.
> >
> > I have just tried with 'earlyprintk=ttyS0' and without 'quiet', but the
> > result seems to be the same:
> >
> > Booting a command list
> >
> >   Loading Linux 4.11.0-1-686 ...
> >   Loading initial ramdisk ...
> >
> > and then nothing else.
>
> Hello again,
> I tested the new kernel version that has recently migrated to Debian
> testing.
>
> Unfortunately, I get the same exact boot failure.
>
> And no useful output on the serial console, even with
> 'earlyprintk=ttyS0' and without 'quiet':
>
> Booting a command list
>
>   Loading Linux 4.12.0-1-686 ...
>   Loading initial ramdisk ...
>
> and then nothing else.
>
>
> Please note that, after the test, I again booted the machine with the
> old Linux 4.9.0-3-686 and noticed "recovering journal" for the root
> partition among the boot messages.
> Hence, I suppose the root filesystem was mounted in read/write mode
> during the failed boot of Linux 4.12.0-1-686.
> I don't know whether this piece of information may be useful in order
> to pinpoint the issue...
>
> Please let me know, in case you need any further information and/or in
> case there's some progress on this bug.
>
> Thanks for your time!
>
> Bye.
>
>
> --
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!


Bug#863720: aiccu: SixXS will shutdown on 2017-06-06

2017-09-19 Thread Axel Beckert
Control: clone -1 -2
Control: severity -2 normal
Control: retitle -2 RM: aiccu -- ROM; SixXS has been shut down and no 
replacement popped up within 3 months
Control: reassign -2 ftp.debian.org

Hi,

Ansgar Burchardt wrote:
> SixXS will shutdown on 2017-06-06[1].  Unless there are other tunnel
> providers used with aiccu, it seems useless to include in stretch.
> >From a quick glance at [2], SixXS is the only provider using AYIYA and
> TIC which is what I believe aiccu implements.

What I've written in https://bugs.debian.org/864783 three months ago
is still valid:

> And unfortunately, neither
>
> * SixXS changed their mind, nor
> * did SixXS open-source the server implementation, nor
> * did someone else come up with an AYIYA(*) server implementation or a
>   comparable service.

Also citing from that mail:

> Mike and me agreed to keep it around in Debian Unstable for at least a
> few more months in the hope that any of the above mentioned events
> still happen. If neither of these events happen (within a year or so),
> we'll likely let aiccu also be removed from Debian Unstable.

3 months are now over and there's no sign of improvement of the
situation. So let's remove aiccu from unstable, too.

We'll definitely leave the git repo under collab-maint, in case
there's a reason to resume maintaining an aiccu package in Debian.

P.S.: I'm keeping the RC bug open for aiccu so that it doesn't
propagate to testing while waiting for being removed. Hence the clone
instead of just reassigning.

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



Bug#876207: /etc/cups/cups-files.conf: root not in JobPrivateAccess - cannot access jobs private attributes

2017-09-19 Thread Alban Browaeys
Package: cups-daemon
Version: 2.2.4-7
Severity: important
File: /etc/cups/cups-files.conf

Dear Maintainer,

Since cups 1.5 job-originating-user-name is a JobPrivateValues.
JobPrivateAccess gives access to @OWNER and @SYSTEM by default.
Since Debian cups /etc/cups/cups-files.conf set @SYSTEM to lpadmin only
root is not allowed.

And cups-pk-helper which gnome-control-center printers panel jobs-dialog
makes use of to edit job (stop/resume and purge) fails. Its job status
routine always ask as root for the job-originating-user-name attribute
and fails with invalid a status.

The cups-files.conf man page suggests default for SystemGroup to be:
"admin", "lpadmin", "root", "sys", and/or "system".
which would fix the issue.

A local workaround is to add root to lpadmin group.


Setting as important as it breaks unrelated packages.


Changelog tell "root" group should be added back when:
"As soon as bug #50620 gets fixed, I'll set up to add root to the
group," ... well this bug is nowadays fixed or at least closed.


Best regards
Alban

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

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

Versions of packages cups-daemon depends on:
ii  adduser  3.116
ii  bc   1.06.95-9+b3
ii  dpkg 1.18.24
ii  init-system-helpers  1.49
ii  libavahi-client3 0.7-3
ii  libavahi-common3 0.7-3
ii  libc62.24-17
ii  libcups2 2.2.4-7
ii  libcupsmime1 2.2.4-7
ii  libdbus-1-3  1.11.16+really1.10.22-1
ii  libgssapi-krb5-2 1.15.1-2
ii  libpam0g 1.1.8-3.6
ii  libpaper11.1.24+nmu5
ii  libsystemd0  234-3
ii  lsb-base 9.20170808
ii  procps   2:3.3.12-3
ii  ssl-cert 1.0.39

Versions of packages cups-daemon recommends:
ii  avahi-daemon  0.7-3
ii  colord1.3.3-2
ii  cups-browsed  1.16.4-1+b1

Versions of packages cups-daemon suggests:
ii  cups   2.2.4-7
ii  cups-bsd   2.2.4-7
ii  cups-client2.2.4-7
ii  cups-common2.2.4-7
ii  cups-filters [foomatic-filters]1.16.4-1+b1
ii  cups-ppdc  2.2.4-7
ii  cups-server-common 2.2.4-7
ii  foomatic-db-compressed-ppds [foomatic-db]  20170723-1
ii  ghostscript9.21~dfsg-1
ii  hplip  3.17.7+repack0-3
ii  poppler-utils  0.57.0-2
ii  printer-driver-cups-pdf [cups-pdf] 3.0.1-4
ii  printer-driver-gutenprint  5.2.13-1
ii  printer-driver-hpcups  3.17.7+repack0-3
ii  smbclient  2:4.6.7+dfsg-1
ii  udev   234-3

-- no debconf information



Bug#867660: ball: FTBFS with sip 4.19.x: sip: File::CannotWrite has not been defined

2017-09-19 Thread Dmitry Shachnev
Control: block 876205 by -1

On Tue, Sep 05, 2017 at 04:00:50PM +0300, Dmitry Shachnev wrote:
> I just tested on a clean sid amd64 chroot (with sip 4.19 from experimental)
> and all the tests pass for me:
>
>   100% tests passed, 0 tests failed out of 333
>
> Maybe it was some temporary issue?

I have just requested a transition slot for sip 4.19 upload, so this needs
to be fixed soon, otherwise it will FTBFS.

At the same time, please call dh_sip helper after dh_install so that your
package gets the right dependency on sip-abi-12.x.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#876205: transition: sip-api-12.x

2017-09-19 Thread Dmitry Shachnev
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team,

I would like to request transition for sip4 package, which has a new ABI
version, 12.x. It has been available in experimental since January.

For sip4, python-qt4 and pyqt5 I will do sourceful uploads.

Other packages build-depending on python-sip-dev or python3-sip-dev will
need binNMUs. All of them should build fine except ball, which is fixed in
Vcs and I hope will be uploaded soon (otherwise I can NMU it). See #867660.

Unfortunately there are some packages that do not use our dh_sip/dh_sip3
helpers. They do not get the dependency on virtual ABI packages and so will
show as unknown in the transition tracker. You can either include them in
binNMU list, or ignore; they will not block sip4 migration.

Ben file (hope I got it correct):

title = "sip-api-12";
is_affected = .build-depends ~ "/python3?-sip-dev/" | .depends ~ 
"/sip-(py3)?abi-/";
is_good = .depends ~ "/sip-(py3)?api-12.2/";
is_bad = .depends ~ "/sip-(py3)?api-11.[0123]/";

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#876196: libpam-krb5: login/unlock-screen/sudo waits VERY long time for DNS response

2017-09-19 Thread Russ Allbery
Rafal Pietrak  writes:

> I did attempt that, but without success.

> When I swapped krb5 entry with unix entry in common-password, nothing
> changes. When I did that in common-auth I've go "bad password" response
> from sudo command.

You want common-auth, not common-password.

Are you sure that you're using the password in the local system
/etc/shadow and that you've set the pam_unix module as sufficient so that
pam_krb5 doesn't run if it succeeds?  You want something like:

auth  sufficient   pam_unix.so
auth  required pam_krb5.so try_first_pass minimum_uid=1000

You may also have to change the account stack -- I don't recall off-hand.

> 1. provided, full fix is impossible due to its complexity, and a "hinted
> solution" does not work on first go ... may be an additional README
> coming with binary package would be doable.

It would be great to have tested documentation for how to do this, but I'm
not sure it's in the scope for a specific PAM module.  It's more of a
general PAM configuration question of how to stack multiple authentication
modules.

(I'm also extremely short on resources to even maintain the basic module
functionality, so can't promise much contribution on the more general PAM
configuration front.)

> 2. then again... may be it would be good to make the order that actually
> dos work and does not make those problems should be the default debian
> installation - may be this could be changed?

Most people using a Kerberos PAM module expect Kerberos to be tried first
since authentication that doesn't give them Kerberos tickets may not be
normally usable, and are using pam_unix only for root passwords and
similar local fallbacks.  So things are currently set up for the typical
use case.

> I'm pushing this a little, because it may be mo more common problem that
> currently perceived. Pls consider todays everyday situation of laptops
> and other portables getting to sleep mode and awakening somewhere else
> where (time consuming) network reconnect is due. So at leas some
> unnecesary delay will happen when the new connectivity is only partially
> set up.

Unless carefully configured to not be the default authentication option,
and honestly even then, a Kerberos PAM module is not a good configuration
for systems that have spotty network connectivity.  Have you considered
removing the PAM module entirely, using local system authentication, and
running kinit when you want Kerberos tickets?  That's what I do.

Even if you don't want to do that for general system login, you can
definitely do that for sudo.

Another possible approach would be to use sssd, which is a more complex
system that does local caching of the Kerberos authentication credentials
and is designed specifically to handle this use case.

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



Bug#876206: RM: libdpkg-log-perl -- ROM

2017-09-19 Thread Patrick Schönfeld
Package: ftp.debian.org
Severity: normal

Hi,

as the current maintainer of libdpkg-log-perl I'm in the process of
orphaning my packages, with this package being the only one where I am the
upstream author as well.

Since I'm not planning to maintain this library anymore and it actually
does have a very few users [1] I think it's better to remove the package
from Debian and thus I hereby request that.

I may note that back when I wrote this lib (for my purposes) there were a
request to include a-kind-of library (and its associated tool dpkg-report)
directly with dpkg. But the changes as requested by the dpkg maintainers
were basically a complete rewrite of the lib, so it probably doesn't even
serve as a starting point if anyone is interested in doing that. The
discussion of this changes can be seen in the bug report at [2].

Best Regards,

Patrick

[1] https://qa.debian.org/popcon.php?package=libdpkg-log-perl
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608930


Bug#876204: ITP: goxel -- 3D voxel editor

2017-09-19 Thread Federico Ceratto
Package: wnpp
Severity: wishlist
Owner: Federico Ceratto 

* Package name: goxel
  Version : 0.7.1
  Upstream Author : Guillaume Chereau 
* URL : https://github.com/guillaumechereau/goxel
* License : GPLv3
  Programming Lang: C
  Description : 3D voxel editor

Goxel is a 3D program that lets you create voxel volumes.
It supports 24 bits RGB colors, unlimited scene size and undo buffers.
Layers, procedural generation and Marching Cube rendering.
Exports to obj, pyl, magica voxel, png, qubicle, povray, and more

goxel is a popular editor and there are no similar applications in
Debian. The package will be maintained on collab-maint.



Bug#876203: O: xml2 - Convert between XML, HTML, CSV and a line-oriented format

2017-09-19 Thread Patrick Schönfeld
Package: wnpp
Severity: normal

Hi,

I'm no longer interested in maintaining this package and so I hereby orphan it.

Note to the prospective maintainer:
It seems to me as if the software is not actively maintained by its
upstream developer anymore and it has some serious issues like missing
utf8 support.

I'd probably request removal of the package if there weren't some
users that are still interested in the package (as indiciated in the
bug reports).

Nevertheless I would not recommend taking over maintenance of this
package without knowledge in C.

Best Regards,
Patrick



Bug#867316: News?

2017-09-19 Thread Eugen Dedu

So, no one interested in maintaining this package?

--
Eugen



Bug#876201: O: dnsproxy - proxy for DNS queries

2017-09-19 Thread Patrick Schönfeld
Package: wnpp
Severity: normal

Hi,

I'm now longer maintaining the above package and so I'm orphaning it.

Best Regards,
Patrick



Bug#876202: O: vimoutliner - script for building an outline editor on top of Vim

2017-09-19 Thread Patrick Schönfeld
Package: wnpp
Severity: normal

Hi,

I'm no longer interested in maintaining this package and so I'm orphaning it.

Best Regards,
Patrick



Bug#876183: libgdk-pixbuf2.0-dev: Please split the development binaries into a separate package

2017-09-19 Thread Michael Biebl
Am 19.09.2017 um 12:41 schrieb Hugh McMaster:
> Package: libgdk-pixbuf2.0-dev
> Version: 2.36.5-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> The package libgdk-pixbuf2.0-dev is not multi-arch compatible,
> as the binary files in /usr/bin differ across architectures.
> 
> Please split the binary file into a separate development package: libgdk-
> pixbuf2.0-dev-bin.
> 
> Doing this will allow libgdk-pixbuf2.0-dev to become Multi-Arch: same,
> and will satisfy the multi-arch build-dependencies of packages including
> libgtk2.0-dev.
> 

It's not quite as simple as that. We need to verify that the binaries
provided by libgdk-pixbuf2.0-dev-bin work as Multi-Arch: foreign, i.e.
their output needs to be arch independent.


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



signature.asc
Description: OpenPGP digital signature


Bug#876200: llvm-toolchain-4.0: Please backport upstream r299910 to fix FTBFS for rustc 1.19.0 on ppc64el

2017-09-19 Thread Ximin Luo
Package: llvm-toolchain-4.0
Version: 1:4.0.1-5
Severity: important
Tags: patch

Dear Maintainer,

rustc 1.19 FTBFS on ppc64el with this version 1:4.0.1-5:
https://buildd.debian.org/status/fetch.php?pkg=rustc=ppc64el=1.19.0%2Bdfsg3-2=1505822614=0
"Invalid PPC CTR loop!"

For some reason this did not happen with 1:4.0.1-3 but I can reproduce it on 
plummer with 1:4.0.1-5.

Luckily, upstream has already committed a fix:

https://bugs.llvm.org//show_bug.cgi?id=32485
https://reviews.llvm.org/rL299910
Raw diff: https://reviews.llvm.org/D31790?download=true

I tested it on top of 1:4.0.1-5 and it works well to fix the above rustc build 
failure.

X

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

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 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)



Bug#876184: pdfsam: Disable donation window, news, and ads for premiun features

2017-09-19 Thread Markus Koschany
Control: tags -1 wontfix

Am 19.09.2017 um 13:05 schrieb Michael Weghorn:
> Package: pdfsam
> Version: 3.3.2-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> PDFsam provides the possibility to enable or disable
> certain "features" in its options.
> 
> At the moment, the following functionality is enabled
> by default:
> 
> * "Show donation window"
> * "Check for news at startup"
> * "Show premium features"
> 
> In my opinion, it would be better to have those options
> disabled by default.
> (Currently, there is already a patch that disables
> the check for updates at startup.)
> 
> Of course, this is a "matter of taste", so please feel free
> to close this bug as invalid in case you see that differently.

Hello,

I almost expected such a bug report. I have thought about this myself
and the current behavior is intentional.

tl;dr

This is a wontfix bug for me. I will keep it open because I believe
there will be other people who will come up with a similar request in
the future. As you said this is a "matter of taste". I believe all of
these features can be easily disabled in the settings menu. There is no
need for Debian to diverge from upstream.

Here is the long version:

We disable checks for updates in Debian packages because they are not
useful for our users and might even confuse them or break our packages.
We try to produce a coherent experience across the distribution and a
lot of work goes into seamlessly integrating a specific piece of
software that is fully DFSG compliant, usable, buildable with only
packages from Debian main and installable with Debian's system tools. By
using Debian packages stable users will always get a well tested and
free (as in freedom) software package which also receives security
support for at least five years.

We cannot guarantee the same for software packages which are directly
downloaded from upstream without further checks. They are not integrated
into Debian and might be affected by security, freedom or other issues.
We don't know because we can't control it. Hence upstream updates are
disabled by default because we have tools like apt, dpkg,
unattended-upgrades, the Gnome Software Center, Synaptic, etc pp. which
can help keeping a system up-to-date. Using upstream's update mechanism
together with Debian's can affect the user experience negatively and
thus we recommend either to use the Debian package OR the upstream
package (if it exists) but not both at the same time (unless this use
case is specifically supported by the maintainer which is not true for
PDFsam)

* "Show donation window"


In my opinion the other features are fundamentally different from what I
have explained above. They won't mess up your system or break the Debian
package, they are either notifications or a means to ask the user to
help supporting the future development of the software. Free software
does not have to be gratis and software developers also need money to
pay their bills. It is not unethical to ask for donations. It is one way
to fund or support a free software project and that's fine for me.

* "Check for news at startup"
=

Some people will claim this is a privacy issue. I disagree. It is a way
to get in contact with users and as long as this feature can be easily
disabled I don't have any problems with it.

* "Show premium features"
=

Some people will claim this is unethical because those "premium
features" may not be free software. Whilst true this is not an issue for
PDFsam because the application itself is free and you don't have to buy
or use those extra features. This feature is just a hint or notification
to inform users that they can buy something extra but they don't have
to. This notification can be easily disabled. I don't find it obtrusive
and I want let the user decide if she needs it or not.

I hope that clarifies my point of view a little

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#866537: stretch-pu: package cross-gcc/113

2017-09-19 Thread Wookey
On 2017-07-28 20:35 +0200, Cyril Brulebois wrote:
> Wookey  (2017-07-28):
> > OK. I'll go ahead with a 9u1 update then.
> 
> You're supposed to wait for a green light (usually materialized by a
> +confirmed rather than with a +moreinfo)…

Cyril, Can I get an OK to upload this so I can tick it off my to-do list? 
I don't want to miss another stable-update push.

I'm working around the lack of a working cross-gcc in stable on a
daily basis. I'm probably not the only one.

I can't see any reason for wanting to keep the broken version in stable.

Are you waiting for anything before deciding?

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature


Bug#875618: closed by Sébastien Villemot <sebast...@debian.org> (Bug#875618: fixed in openblas 0.2.20+ds-4)

2017-09-19 Thread Graham Inggs
Thanks Sébastien!  I'm sorry it turned out not to be as simple as I 
originally thought.




Bug#872295:

2017-09-19 Thread H.-Dirk Schmitt
The problem has also another ugly effect in interactive shell usage
(here gnome-terminal).

I tried to rename a directory with utf-8 chars, but make a silly type
in the command. I tried to jump to the start of line with 'ctr+a'.
The cursors jumps some chars left of the command (inside the prompt
part).

example:
my Yirumav-Stay_in_Memory_기억에_머무르다/ Yiruma--Stay_in_Memory



Bug#876199: RFS: usbguard/0.7.0+ds1-2

2017-09-19 Thread Muri Nicanor
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : usbguard
  Version  : 0.7.0+ds1-2
  Upstream Author  : Daniel Kopeček 
* Url  : https://dkopecek.github.io/usbguard/
* Licenses : GPL-2+,GPL-3+,CC-BY-SA-3.0,FSFULLR,public-domain
  Programming Lang : C
  Section  : utils

 The USBGuard software framework helps to protect your computer against
 rogue USB devices (a.k.a. BadUSB) by implementing basic whitelisting
 and blacklisting capabilities based on device attributes.
 .
 This package contains the shared library

It builds those binary packages:

  * libusbguard0
  * usbguard
  * usbguard-applet-qt

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

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

Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/u/usbguard/usbguard_0.7.0+ds1-2.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://0xacab.org/muri/debian-usbguard

More information about usbguard can be obtained from
https://dkopecek.github.io/usbguard/


Changes since last upload:

  * Remove qt4 dependencies (Closes: #875220)
  * Backport patch for multiple applet instances
(Closes: #871997)
  * Backport patch to make UEventDeviceManager work
with kernel >= 4.13 (Closes: #875808)

Regards,
  Muri Nicanor



signature.asc
Description: OpenPGP digital signature


Bug#853635: closing #853635 qwtplot3d: ftbfs with GCC-7

2017-09-19 Thread Georges Khaznadar
Hello,

I uploaded a new version of qwtplot3d, with no change in the source
tree, but a new version number to prevent collisions with other variants
of the package like backports, when .symbols files are modified.
The package is in the queue DELAYED+10

I initialized the files debian/*.symbols, which allows me to build the
package with gcc-7.

Here is the lintian output, after a build in a fresh Sid chroot:

+++ lintian output +++
I: qwtplot3d source: vcs-field-uses-insecure-uri vcs-svn
svn://anonscm.debian.org/debian-science/packages/qwtplot3d/trunk/
I: qwtplot3d source: testsuite-autopkgtest-missing
W: libqwtplot3d-doc: embedded-javascript-library
usr/share/doc/libqwtplot3d-doc/html/jquery.js please use libjs-jquery
I: libqwtplot3d-qt4-0v5: no-symbols-control-file
usr/lib/libqwtplot3d-qt4.so.0.2.7
I: libqwtplot3d-qt5-0: no-symbols-control-file
usr/lib/libqwtplot3d-qt5.so.0.2.7
+++ end of lintian output +++

I made no changes in anonscm.debian.org/debian-science/packages/

If somebody wants to improve the packaging, there are 10 days left.
I need this package to enter Buster, since I maintain scidavis which
depends on it.

Best regards,   Georges.
-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature


Bug#597061: severity of 597061 is wishlist, retitle 597061 to Make unattended-upgrades work in testing/unstable

2017-09-19 Thread Balint Reczey
Control: reopen -1
Control: tags -1 confirmed

Hi,

On Mon, 26 Sep 2016 15:44:17 -0400 anarcat > wrote:
> Control: forwarded -1
https://github.com/mvo5/unattended-upgrades/issues/33

>
> I believe this bug report is identical to:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787945

>
> In the interest of sanity, I will close this old bug report in favor of
> that one.

I plan fixing this one in 0.98 with the other bug.
They are not completely identical IMO because in Ubuntu "stable" is
followed,but default while development releases are not at the moment.

IMO the right thing to do is following both stable and testing/unstable, as
requested in the Debian bugs.

Cheers,
Balint



Bug#875606: Debian mirror ftp-nyc.osuosl.org, ftp-chi.osuosl.org: does not sync correctly 4 times a day

2017-09-19 Thread Lance Albertson via RT
On Mon Sep 18 13:12:07 2017, ramereth wrote:
> I'm not sure what's causing this however they seem to be in sync as of right
> now. We've added nagios monitoring for the trace files on each host so we can
> hopefully have better insight into the issue. Please let us know if we start
> lagging behind again but I will do my best to check your mirror status site in
> the coming days.

Very strange. I just got in the office and noticed that chi and nyc were behind
again so I went looking to compare the trace files. After I ran 'cat' on the
files, I went to look at the mirror report again and suddenly it decides to
resolve itself at that point. I'm starting to wonder if this might be a
filesystem issue and I need to run a fsck on the volume. I'm going to keep an
eye on it later today and see if it does it again.

-- 
Lance Albertson
Director
Oregon State University | Open Source Lab 



Bug#871835: more speedup

2017-09-19 Thread Ben Hutchings
On Tue, 2017-09-19 at 17:24 +0200, Thomas Lange wrote:
> I could also add a test, to check if grep supports -P. If not, don't
> use it. Does a non-GNU grep use -P for other things?

If you use the long option (--perl-regexp) there should be no danger of
collision.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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


Bug#876028: Bug 876028

2017-09-19 Thread Jiri Palecek
This is just a matter of a simple rebuild, and all is well. Such things 
happen in experimental (I hope libqpdf won't change it's symbol version 
while in unstable).


Regards

    Jiri Palecek



Bug#871835: more speedup

2017-09-19 Thread Thomas Lange
I could also add a test, to check if grep supports -P. If not, don't
use it. Does a non-GNU grep use -P for other things?

-- 
regards Thomas



Bug#871702: I can confirm this bug too

2017-09-19 Thread alvarenga
I think the severity of this bug is very high. Any server upgraded to 
latest stable version of Debian system using Xen having Domu (pv not 
affected) will stop to work.




Bug#872257: I can confirm this bug too

2017-09-19 Thread alvarenga
I think the severity of this bug is very high. Any server upgraded to 
latest stable version of Debian system using Xen having Domu (pv not 
affected) will stop to work.




Bug#876198: libinput10: Can't initiate a touchpad motion near a corner

2017-09-19 Thread Tony Houghton
Package: libinput10
Version: 1.8.2-1
Severity: normal

When using GNOME on Wayland I can't move the pointer with the touchpad
if I initially start touching it near a corner. Even if I drag my finger
across the middle from the corner, the pointer doesn't move, and no
events are shown in libinput-debug-events. If I do the opposite, ie
start the motion near the middle of the touchpad, it continues to track
my finger correctly if I move it into the corners.

I only noticed this recently, so it's probably something in the most
recent version to enter Debian. GNOME on Xorg is not affected; AIUI
GNOME on Wayland uses libinput, and something else on Xorg, so I guessed
this is the culprit package.

The machine is a Lenovo Thinkpad Carbon X1 4th Generation. From
libinput-list-devices:

Device:   SynPS/2 Synaptics TouchPad
Kernel:   /dev/input/event1
Group:8
Seat: seat0, default
Size: 100x57mm
Capabilities: pointer
Tap-to-click: disabled
Tap-and-drag: enabled
Tap drag lock:disabled
Left-handed:  disabled
Nat.scrolling:disabled
Middle emulation: disabled
Calibration:  n/a
Scroll methods:   *two-finger edge
Click methods:*button-areas clickfinger
Disable-w-typing: enabled
Accel profiles:   none
Rotation: n/a

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

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 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: systemd (via /run/systemd/system)

Versions of packages libinput10 depends on:
ii  libc6 2.24-17
ii  libevdev2 1.5.7+dfsg-1
ii  libinput-bin  1.8.2-1
ii  libmtdev1 1.1.5-1+b1
ii  libudev1  234-3
ii  libwacom2 0.24-1

libinput10 recommends no packages.

libinput10 suggests no packages.

-- no debconf information



Bug#876197: RM: mpage -- RoQA; non-free license

2017-09-19 Thread Joao Eriberto Mota Filho
Package: ftp.debian.org
Severity: normal

This request is based on #805370.

mpage is out of testing since 2016-01-01. Its old license (up to 2.5.6 version)
said:

  -
  The main license used by mpage says:

   * Permission is granted to anyone to make or distribute verbatim
   * copies of this document as received, in any medium, provided
   * that this copyright notice is preserved, and that the
   * distributor grants the recipient permission for further
   * redistribution as permitted by this noti
   -

The current version (2.5.7) is GPL-2+. However, an essential file
(Encodings/encoding.h) is keeping the same old license:

   -
   encoding.h.PC850: * Copyright (c) 1994-2004 Marcel J.E. Mol, The Netherlands
   encoding.h.PC850: * Copyright (c) 1988 Mark P. Hahn, Herndon, Virginia
   encoding.h.PC850- *
   encoding.h.PC850- * Permission is granted to anyone to make or
   distribute verbatim
   encoding.h.PC850- * copies of this document as received, in any
   medium, provided
   encoding.h.PC850: * that this copyright notice is preserved, and that the
   encoding.h.PC850- * distributor grants the recipient permission for 
further
   encoding.h.PC850- * redistribution as permitted by this notice.
   encoding.h.PC850- *
   encoding.h.PC850- *  IBM international codepage 850 encoding for
   mpage filter
   encoding.h.PC850- * %
   encoding.h.PC850- * % Written by Tilmann Boess
   , 1996/04/06
   -

Some packages depends of the mpage:

   -
   $ apt-cache showpkg mpage
   Package: mpage
   Versions:
   2.5.6+dfsg-1 
(/var/lib/apt/lists/debian:3142_ftp.br.debian.org_debian_dists_sid_main_binary-amd64_Packages)

   [...]

   Reverse Depends:
 foomatic-filters,mpage
 printfilters-ppd,mpage
 magicfilter,mpage
 gjots2,mpage
   -

>From the quoted packages:

foomatic-filters: Recommends paps | cups | enscript | a2ps | mpage
printfilters-ppd: Depends: transfig, mpage, [...] (currently not in testing or 
stable)
magicfilter: Recommends: enscript | a2ps | mpage
gjots2: Recommends: gv, mpage, python-gtksourceview2

I think this package is no longer useful and can be removed.

Regards,

Eriberto



Bug#876173: libreswan: [INTL:pt] Updated Portuguese translation for debconf messages

2017-09-19 Thread Daniel Kahn Gillmor
On Tue 2017-09-19 10:00:52 +0100, Pedro 'm42' Ribeiro wrote:
> Package: libreswan
> Version: 3.20-7
> Tags: l10n, patch
> Severity: wishlist
>
> Updated Portuguese translation for libreswan's debconf messages.
> Feel free to use it.

I'm closing this bug report (#876173) because it seems you've translated
a part of upstream that doesn't exist in the debian packages.  This is
the same situation as https://bugs.debian.org/855475 and
https://bugs.debian.org/857525, which i also closed.

I think the fact that you did extra (unnecessary) labor was caused by a
bug in the l10n scripts tools (https://bugs.debian.org/748716), which
needs attention.

sorry that you did work that didn't need doing!

  --dkg



Bug#876147: [Debian-med-packaging] Bug#876147: camp: FTBFS on ppc64 and sparc64: FUNCTIONMAPPING/call error

2017-09-19 Thread Aaron M. Ucko
Flavien Bridault  writes:

> Thanks for your report. I wonder if the issue is not because of the cast
> to , whereas the function declared in
> function_mapping.cpp:55 uses .

Thanks for the quick reply!

AFAICT from testing on the ppc64 porter box pizzetti.debian.org,
addressing this formal discrepancy makes no difference.  (I would have
tested on sparc64 as well, but can't currently reach the relevant porter
box.)  FWIW, the result I got there fluctuated randomly between 21 and 22.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#876196: libpam-krb5: login/unlock-screen/sudo waits VERY long time for DNS response

2017-09-19 Thread Rafal Pietrak
Package: libpam-krb5
Version: 4.7-4
Severity: important

Dear Maintainer,


When connectivity is poor (like WiFi on the edge of range) checking of password
can take VERY long time. It happens no matter if I login through GDM, or if I'm
just unlocking the screen, or even if I'm just executing "sudo" command. This
does NOT happen, when there is no connectivity at all (like an offline
notebook).

To see this happening execute (in two separate windows /sessions):
(session one iptables-session)
# iptables -P INPUT DROP
(in other window/session)
$ sudo su
[jaksdl] password: 
...waiting ... wainting .. waiting
(back in the iptable window, execute)
# iptables -I OUTPUT -p udp --dport 53 -j REJECT
(again in the sudo window)
... tick tick, "sudo" completes almost immediately after iptables-REJECT
command

So, the sudo password checking completed almost immediately after TCP stack
starts returning REJECTs ... instead of accepting traffic for transmission and
in consequence giving an implression that it's worth waiting for an answere.

I'm posting this as libpam-krb5, as I've noticed that DNS queries being
emitting at that time do relate to kerberos realm name defined in my system.



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

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

Versions of packages libpam-krb5 depends on:
ii  krb5-config 2.6
ii  libc6   2.24-11+deb9u1
ii  libkrb5-3   1.15-1
ii  libpam-runtime  1.1.8-3.6
ii  libpam0g1.1.8-3.6

libpam-krb5 recommends no packages.

libpam-krb5 suggests no packages.

-- no debconf information



Bug#814856: debhelper: dh_install -X option is broken

2017-09-19 Thread James Cowgill
Hi,

On 19/09/17 10:24, Niels Thykier wrote:
> On Tue, 16 Feb 2016 01:29:09 + James Cowgill
>  wrote:
>> Source: debhelper
>> Version: 9.20160115
>> Severity: important
>> X-Debbugs-CC: Dmitry Shachnev 
>> Control: affects -1 src:codelite
>>
>> Hi,
>>
>> It seems the -X option of dh_install is either broken or its
>> behaviour has changed recently. With newer versions of debhelper
>> codelite fails to build with this error:
>>
>>>    debian/rules override_dh_install
>>> make[1]: Entering directory '/«BUILDDIR»/codelite-9.1+dfsg'
>>> dh_install  -Xcodelite-lldb -XLLDBDebugger.so
>>> dh_install: codelite-plugins missing files: usr/bin/codelite-lldb
>>> dh_install: codelite-plugins missing files: usr/lib/codelite/LLDBDebugger.so
[...]

> Sorry for the late reply to this bug.
> 
> Could you please test if this is still a problem in debhelper 10.8?  I
> recently rewrote most of the relevant parts of dh_install, so Dmitry's
> patch is no longer applicable.  At the same time, the current code looks
> like it should handle this case as you expect (i.e. expand glob; assert
> something matches and then filter out excluded paths)

I think it's still broken. This is with debhelper 10.8:
>debian/rules override_dh_install
> make[1]: Entering directory '/<>/codelite-10.0+dfsg'
> dh_install  -Xcodelite-lldb -XLLDBDebugger.so
> dh_install: Cannot find (any matches for) "usr/bin/codelite-lldb" (tried in 
> ., debian/tmp)
> 
> dh_install: codelite-plugins missing files: usr/bin/codelite-lldb
> dh_install: Cannot find (any matches for) "usr/lib/codelite/LLDBDebugger.so" 
> (tried in ., debian/tmp)
> 
> dh_install: codelite-plugins missing files: usr/lib/codelite/LLDBDebugger.so
> dh_install: missing files, aborting
> debian/rules:40: recipe for target 'override_dh_install' failed

However, looking at this bug again, I might have misunderstood the -X
option here. As you said, at the moment it will filter out excluded
files after checking that the glob matches something. I think I was
trying to exclude entire globs from being considered (ignoring missing
files in a specific case) as opposed to excluding files which would have
otherwise been installed.

With that, I think you can close the bug. After originally filing this
bug, I changed the codelite packaging to something which worked properly
and I'm fine with keeping that.

Thanks,
James



signature.asc
Description: OpenPGP digital signature


Bug#876195: ocfs2-tools: dist-upgrade to Stretch doesn't update runlevels

2017-09-19 Thread Roman Serbski
Package: ocfs2-tools
Version: 1.8.4-4
Severity: normal

Dist-upgrading Jessie to Stretch doesn't update/rebuild o2cb and ocfs2
runlevels.

-- Jessie System Information:
Debian Release: 8.9
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.43-2+deb8u3
ocfs2-tools: 1.6.4-3

$ ls -al /etc/rc*.d/*o2cb
lrwxrwxrwx 1 root root 14 May 18 09:15 /etc/rc0.d/K04o2cb -> ../init.d/o2cb
lrwxrwxrwx 1 root root 14 May 18 09:15 /etc/rc6.d/K04o2cb -> ../init.d/o2cb
lrwxrwxrwx 1 root root 14 May 18 09:15 /etc/rcS.d/S13o2cb -> ../init.d/o2cb

$ ls -al /etc/rc*.d/*ocfs2
lrwxrwxrwx 1 root root 15 May 18 09:15 /etc/rc0.d/K03ocfs2 -> ../init.d/ocfs2
lrwxrwxrwx 1 root root 15 May 18 09:15 /etc/rc6.d/K03ocfs2 -> ../init.d/ocfs2
lrwxrwxrwx 1 root root 15 May 18 09:15 /etc/rcS.d/S14ocfs2 -> ../init.d/ocfs2

-- Stretch System Information:
Debian Release: 9.1
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.30-2+deb9u3
ocfs2-tools: 1.8.4-4

Perform dist-upgrade to Stretch and runlevels will remain the same
causing o2cb and ocfs2 services to not start during boot time.

update-rc.d -f o2cb remove
update-rc.d -f ocfs2 remove
update-rc.d o2cb defaults
update-rc.d ocfs2 defaults

fixes the issue, hence corrected runlevels look like the following:

$ ls -al /etc/rc*.d/*o2cb
lrwxrwxrwx 1 root root 14 Sep 19 12:53 /etc/rc0.d/K02o2cb -> ../init.d/o2cb
lrwxrwxrwx 1 root root 14 Sep 19 12:53 /etc/rc1.d/K02o2cb -> ../init.d/o2cb
lrwxrwxrwx 1 root root 14 Sep 19 12:53 /etc/rc2.d/S02o2cb -> ../init.d/o2cb
lrwxrwxrwx 1 root root 14 Sep 19 12:53 /etc/rc3.d/S02o2cb -> ../init.d/o2cb
lrwxrwxrwx 1 root root 14 Sep 19 12:53 /etc/rc4.d/S02o2cb -> ../init.d/o2cb
lrwxrwxrwx 1 root root 14 Sep 19 12:53 /etc/rc5.d/S02o2cb -> ../init.d/o2cb
lrwxrwxrwx 1 root root 14 Sep 19 12:53 /etc/rc6.d/K02o2cb -> ../init.d/o2cb

$ ls -al /etc/rc*.d/*ocfs2
lrwxrwxrwx 1 root root 15 Sep 19 12:55 /etc/rc0.d/K01ocfs2 -> ../init.d/ocfs2
lrwxrwxrwx 1 root root 15 Sep 19 12:55 /etc/rc1.d/K01ocfs2 -> ../init.d/ocfs2
lrwxrwxrwx 1 root root 15 Sep 19 12:55 /etc/rc2.d/S05ocfs2 -> ../init.d/ocfs2
lrwxrwxrwx 1 root root 15 Sep 19 12:55 /etc/rc3.d/S05ocfs2 -> ../init.d/ocfs2
lrwxrwxrwx 1 root root 15 Sep 19 12:55 /etc/rc4.d/S05ocfs2 -> ../init.d/ocfs2
lrwxrwxrwx 1 root root 15 Sep 19 12:55 /etc/rc5.d/S05ocfs2 -> ../init.d/ocfs2
lrwxrwxrwx 1 root root 15 Sep 19 12:55 /etc/rc6.d/K01ocfs2 -> ../init.d/ocfs2

Thank you.



Bug#876194: libbson-dev: Please install the cmake package config file

2017-09-19 Thread Zhang Jingqiang
Package: libbson-dev
Version: 1.7.0-1
Severity: normal

Dear Maintainer,

The cmake package of libbson-1.0 is required from
/usr/lib/x86_64-linux-gnu/cmake/libmongoc-1.0/libmongoc-1.0-config.cmake,
so please install it.

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

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

Versions of packages libbson-dev depends on:
ii  libbson-1.0-0  1.7.0-1

libbson-dev recommends no packages.

libbson-dev suggests no packages.

-- no debconf information



  1   2   >