Bug#905612: RFS: nsync/1.20.1-2

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: nsync
   Version : 1.20.1-2
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libnsync-cpp1 - C library that exports various synchronization primitives 
(C++ li
libnsync-dev - C library that exports various synchronization primitives 
(dev)
libnsync1  - C library that exports various synchronization primitives (C 
lib)

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/n/nsync/nsync_1.20.1-2.dsc

  More information about hello can be obtained from 

  
http://debomatic-amd64.debian.net/distribution#unstable/nsync/1.20.1-2/buildlog
  http://debomatic-i386.debian.net/distribution#unstable/nsync/1.20.1-2/buildlog

  Changes since the last upload:

nsync (1.20.1-2) UNRELEASED; urgency=medium

  * Add LDFLAG -Wl,--as-needed to strip unneeded shlibs depends.
  * Collect symbols patch from buildd.

Bug#904886: lintian: Support "debhelper-compat (= X)" B-D as replacement for "debhelper (>= X~)"

[Niels Thykier]

Chris Lamb:
> Dear Niels,
> 
>> debhelper-and-debhelper-compat-virtual-relation-with-unsupported-version
>> might be better worded as
>> "debhelper-build-dependency-implied-by-debhelper-compat-relation" and E
>> might too high for this.  There is not much harm in having the redundant
>> build-dependency.
>>
>> On a related note, the text for that tag saying  "However, this requires
>> a debhelper 11.3.6 or later." is incorrect.  Having debhelper-compat (=
>> X) implies debhelper (>= 11.3.6~) - i.e. you can rely on any feature in
>> debhelper up and including version 11.3.6~ without an explicit versioned
>> relation on debhelper (but I am fine with lintian not keeping track of
>> that).
> 
> Hm, perhaps I misunderstood what you wrote a few mails back - could you
> provide an example "good" and example "bad" case of a Build-Depends
> that uses both just to clarify? I think I've managed to confuse myself.
> 
> 
> Best wishes,
> 


# Good:

  Build-Depends: debhelper-compat (= 11)

  Build-Depends: debhelper-compat (= 11),
 debhelper (>= 11.2~)

The latter of the two also holds for any:

  debhelper-compat (= X), debhelper (>= Y)

Where X << Y.


# Bad:

  Build-Depends: debhelper-compat (= 11),
 debhelper (>= 10~)

The debhelper-compat would imply debhelper (>= 10) already.  This also
holds for any:

  debhelper-compat (= X), debhelper (>= Y)

Where X >= Y.

This is "bad" because the debhelper-compat relation makes the debhelper
relation redundant.  IOW you could delete the debhelper relation without
any loss in functionality/support/features from debhelper.

## The special case

Strictly speaking this also holds for any where X >= 9 and Y <= 11.3.6~
as the first version of debhelper to introduce debhelper-compat was
11.3.6~ (and accordingly, if apt can satisfy the debhelper-compat
relation, the debhelper relation is satisfied along with it).

However, I am not entirely convinced it makes sense for lintian to keep
track of this special-case.  Over time, the value of handling this
special case will decline.


I hope this clarifies the situation.

Thanks,
~Niels

Bug#881837: Re: Updating the h5py Uploaders list

[Lumin]

control: close -1

already fixed in dc5f260e393c87886582be111a0493e4d6981f90
https://salsa.debian.org/science-team/h5py

For some reason gbp-dch didn't include the commit message
into dch.

Bug#905611: xmedcon FTCBFS: abuses AC_CHECK_FILE

[Helmut Grohne]

Source: xmedcon
Version: 0.15.0+dfsg-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

xmedcon fails to cross build from source, because it abuses
AC_CHECK_FILE. The macro is meant for checking files on the host system,
not for checking files (such as includes) on the build system. For the
latter a simple test -f is ok. The attached patch fixes that part, but
it doesn't make xmedcon cross buildable: It later fails running
libs/dicom/parse, which is built with the host architecture compiler. As
a build tool it needs to be built with the build architecture compiler.
Fixing that likely involves using AX_CC_FOR_BUILD and possibly rewriting
parse.c to avoid relying on dicom.h. Please consider fixing the
AC_CHECK_FILE anyway and close this bug when doing so. It will allow
others to see the real failure.

Helmut
--- xmedcon-0.15.0+dfsg.orig/configure.ac
+++ xmedcon-0.15.0+dfsg/configure.ac
@@ -505,9 +505,9 @@
 ZNZ_LDFLAGS="-L$nifti_prefix/lib -lznz"
 NIFTI_LDFLAGS="-L$nifti_prefix/lib -lniftiio $ZNZ_LDFLAGS"
 NIFTI_CFLAGS=""
-AC_CHECK_FILE([$nifti_prefix/include/nifti/nifti1_io.h],
-  [NIFTI_CFLAGS="-I$nifti_prefix/include/nifti"],
-  [NIFTI_CFLAGS="-I$nifti_prefix/include"])
+AS_IF([test -f "$nifti_prefix/include/nifti/nifti1_io.h"],
+  [NIFTI_CFLAGS="-I$nifti_prefix/include/nifti"],
+  [NIFTI_CFLAGS="-I$nifti_prefix/include"])
 LDFLAGS="$LDFLAGS -lm $NIFTI_LDFLAGS $ZLIB_LDFLAGS"
 CPPFLAGS="$CPPFLAGS $NIFTI_CFLAGS $ZLIB_LDFLAGS"
 else

Bug#905610: nmapsi4 FTCBFS: fails finding the build architecture qt5

[Helmut Grohne]

Source: nmapsi4
Version: 0.5~alpha1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

nampsi4 fails to cross build from source. It actually builds nmapsi4
twice. Once via debhelper and once in the build/ folder. It's that
second build that fails configuring for the build architecture as it
fails finding qt5, which is only requested for the host architecture by
Build-Depends. I don't quite understand why nmapsi4 has to be built
twice. The attached patch removes the second, failing build though and
it makes nmapsi4 cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru nmapsi4-0.5~alpha1/debian/changelog 
nmapsi4-0.5~alpha1/debian/changelog
--- nmapsi4-0.5~alpha1/debian/changelog 2017-11-07 09:57:54.0 +0100
+++ nmapsi4-0.5~alpha1/debian/changelog 2018-08-07 06:18:25.0 +0200
@@ -1,3 +1,10 @@
+nmapsi4 (0.5~alpha1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build once only and let dh do it (Closes: #-1).
+
+ -- Helmut Grohne   Tue, 07 Aug 2018 06:18:25 +0200
+
 nmapsi4 (0.5~alpha1-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru nmapsi4-0.5~alpha1/debian/rules 
nmapsi4-0.5~alpha1/debian/rules
--- nmapsi4-0.5~alpha1/debian/rules 2017-11-06 19:04:28.0 +0100
+++ nmapsi4-0.5~alpha1/debian/rules 2018-08-07 06:18:22.0 +0200
@@ -3,23 +3,8 @@
 %:
dh $@

-override_dh_auto_clean:
-   dh_auto_clean
-   [ ! -f build/Makefile ] || $(MAKE) -C build/ clean
-   rm -rf build/
-   
 override_dh_auto_configure:
-   dh_auto_configure
-   cd tools ; ./cmake_verbose_script.sh
-
-
-override_dh_auto_build:
-   dh_auto_build
-   $(MAKE) -C build/
-   
-override_dh_auto_install:
-   dh_auto_install 
-   $(MAKE) -C build/ DESTDIR=$(CURDIR)/debian/nmapsi4 install
+   dh_auto_configure -- -DCMAKE_SKIP_RPATH=ON
 
 override_dh_installman:
dh_installman debian/nmapsi4-logr.1 debian/nmapsi4.1

Bug#892232: guile-2.2: FTBFS on alpha: test-conversion fails

[Rob Browning]

[Please preserve 892232-forwar...@bugs.debian.org in relevant replies.]

test-conversion appears to be failing on alpha hosts as reported below,
and seen here: 
https://buildd.debian.org/status/fetch.php?pkg=guile-2.2=alpha=2.2.4%2B1-1=1533027639=0

"Aaron M. Ucko"  writes:

> Source: guile-2.2
> Version: 2.2.3+1-3
> Severity: normal
> Tags: upstream
>
> Hi, Rob.
>
> Builds of guile-2.2 for alpha (admittedly not a release architecture)
> have been failing:
>
>   fail: scm_to_double (12) = -3.58805e+199
>   FAIL: test-conversion
>   [...]
>   ==
>   1 of 39 tests failed
>   Please report to bug-gu...@gnu.org
>   ==

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#813455: [dpkg] dpkg-maintscript-helper dir_to_symlink should be transparent to arch:all arch:any package

[Rob Browning]

See also: https://bugs.debian.org/90

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#905305: emacs-common: terrible mess

[Rob Browning]

Cristian Ionescu-Idbohrn  writes:

> Setting up emacs-goodies-el (40.0) ...
> Install emacsen-common for emacs24
> emacsen-common: Handling install of emacsen flavor emacs24
> Wrote /etc/emacs24/site-start.d/00debian-vars.elc
> Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
> Install emacsen-common for emacs25
> emacsen-common: Handling install of emacsen flavor emacs25
> Install emacs-goodies-el for emacs24
> install/emacs-goodies-el: Handling emacs24, logged in 
> /tmp/user/0/elc_bgxSVN.log
> Building autoloads for emacs24 in 
> /usr/share/emacs24/site-lisp/emacs-goodies-el
> ERROR: install script from emacs-goodies-el package failed
> dpkg: error processing package emacs-goodies-el (--configure):
>  installed emacs-goodies-el package post-installation script 
> subprocess returned error exit status 1

I don't know for sure, but I wouldn't be surprised if the testing
version of emacs-goodies-el doesn't support older emacsXY versions
anymore.  I believe the maintainers are in the process of breaking it up
with the eventual plan to remove it entirely.

> If I recall correctly, what I did on the unstable box was to purge all 
> emacs24 (and emacs23? can't remember) packages.  Is that the 
> maintainers' intention?

As far as emacs is concerned, it's intended to fully displace the
emacsXY packages, hence the conflicts with all of the emacsXY-common
pacakges in the new emacsen-common.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

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

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

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

  It builds those binary packages:

  runescape  - Multiplayer online game set in a fantasy world

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

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

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

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

  More information about Runescape can be obtained from 
https://gitlab.com/coringao/runescape.

  Changes since the last upload:

  runescape (0.3-1) unstable; urgency=medium

  * New upstream release
  * debian/compat: Switch to compat level 11
  * debian/control:
+ Changed homepage link to GitLab
+ Bump debhelper compat to 11
+ Declare compliance with Debian Policy: 4.1.5
+ Switch Vcs URLs to salsa.debian.org
  * Updated information in debian/upstream/metadata
  * Updated and added the disclaimer in d/copyright
  * Updated d/watch file upstream move to GitLab

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

Bug#905607: certain crash about a half an hour browsing Facebook with chromium

[積丹尼 Dan Jacobson]

Package: src:linux
Version: 4.17.8-1

Just wanted to let you know that after about a half an hour browsing
Facebook with chromium, (I didn't try other browsers) the kernel always crashes.

There are never any logs to send. The system just freezes for 10 seconds
and reboots. Nothing gets recorded about the crash.

Bug#905608: wmaker: Should build with Magick support

[Matthew Gabeler-Lee]

Package: wmaker
Version: 0.95.7-8
Severity: normal

wmaker ought to be built with support for imagemagick via libmagickwand, to
support more image types.

Notably, this would permit wmaker to, for example, use the default debian
theme images, which are only distributed in SVG form normally, which wmaker
can't read without libmagickwand.

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

Kernel: Linux 4.9.0-7-amd64 (SMP w/12 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 wmaker depends on:
ii  libc62.27-5
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.6.3-3.2
ii  libgif7  5.1.4-0.4
ii  libjpeg62-turbo  1:1.5.1-2
ii  libpng16-16  1.6.28-1
ii  libtiff5 4.0.8-2+deb9u2
ii  libwings30.95.7-8
ii  libwraster5  0.95.7-8
ii  libwutil50.95.7-8
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxinerama1 2:1.1.3-1+b3
ii  libxpm4  1:3.5.12-1
ii  wmaker-common0.95.7-8

wmaker recommends no packages.

Versions of packages wmaker suggests:
ii  desktop-base9.0.2+deb9u1
ii  lxterminal [x-terminal-emulator]0.3.0-2
ii  menu2.1.47+b1
ii  rxvt-unicode [x-terminal-emulator]  9.22-1+b1
ii  wmaker-data 0.9~3-4
pn  wmaker-utils
ii  x11-apps7.7+6+b1
ii  xterm [x-terminal-emulator] 327-2

-- no debconf information

Bug#901827: Your mail

[Ximin Luo]

On Thu, 2 Aug 2018 16:41:35 +0200 Nicolai Lissner  wrote:
> Found the reason for this bug.
> 
> On July 8th a package called librust-winapi-dev was accepted in sid
> 
> It comes with a complete common-sense breaking "Provides:" line of
> more than 57kB length, as it provides 1336 packages.
> IMHO this is insane. 
> 
> However, cdebootstrap uses
> libdebian-installer-0.116 to parse the package 
> list and in libdebian-installer-0.116/src/parser_rfc822.c
> I found:
> 
> #define READSIZE 16384
> 
> and I guess increasing this to 65536 will fix the problem
> until someone else encouraged by what the debian rust team did
> will use even longer lines :/
> 
> As the parser_rfc822.c is from the same author as cdebootstrap,
> I won't open a separated bug on that.
> 
> Please fix as soon as possible. Thanks a bunch.
> 

Sorry for the inconvenience. For context, the current Debian rust situation is 
a workaround for dpkg bug #901827.

In general though, arbitrary buffer sizes should be a thing of the past. Have 
you considered rewriting that code in Rust? :) Or perhaps less effort, just 
reusing whatever code dpkg itself uses to parse it.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#905606: RFP: node-asap -- node-asap

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-asap
  Version : 2.0.3
  Upstream Author : Kris Kowal
* URL : https://notabug.org/themusicgod1/asap
* License : MIT
  Programming Lang: javascript
  Description : node-asap

ASAP strives to schedule events to occur before yielding for IO, reflow, or 
redrawing. Each event
receives an independent stack, with only platform code in parent frames and the 
events run in the
order they are scheduled.  The asap function executes a task as soon as 
possible but not before it
returns, waiting only for the completion of the current event and previously 
scheduled tasks.

Bug#905578: Install script from emacs-goodies-el package failed

[Sean Whitton]

Hello,

On Mon 06 Aug 2018 at 09:18AM -0400, Nicholas D Steeves wrote:

> Thank you for not overriding the default apt behaviour of allowing
> upgrades to install additional recommended packages.  The Debian
> Emacsen team is in the process of transitioning emacs-goodies-el to a
> dummy transitional package that depends on a set of elpa-packages,
> which are more resistant to the type of issue [1] represents.

Just to be clear, as a package maintainer you may not assume that
recommends will be installed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Thu 02 Aug 2018 at 07:29PM -0700, Jonathan Nieder wrote:

>> Thanks.  Unfortunately, that wouldn't address Clément's concern about
>> maximal verbosity (1) not being consistent with reasonableness and (2)
>> not being concrete enough to easily act on as a packager.
[...]
> Hmm.  The original goal of the requirement might well have been not
> abbreviating build command lines, and I agree that package maintainers
> should avoid abbreviating those.  However, ISTM that a more general
> recommendation in favour of verbosity is also useful, and should not be
> removed.  An example that comes to mind is test suite output: you really
> do want that to be quite verbose in order to see what went wrong.
>
> We have to rely on maintainer judgement about what to include.

Thanks for explaining your point of view.  I agree with relying on
maintainer judgement, and the best way to do that is to avoid having a
requirement in policy at all in some areas.

I think it really does help to look at the motivating use cases.  If
we focus on what it would be a good idea for a packager to do, then
policy would become very long, and it would become much less useful as
a precise source of information about Debian's packaging policies.
Instead, I find it more useful to focus on the non-obvious bits where
having a documented policy can help.

If I understand correctly, you're saying that the following fall into
that category:

- don't abbreviate build commands unless DEB_BUILD_OPTIONS=terse
- don't abbreviate test commands and output unless
  DEB_BUILD_OPTIONS=terse

Do I understand correctly?  Are there more examples in that category,
or could we just document those two?

[...]
> 1) Add something like "In particular, build command lines should not be
>abbreviated."  Then we are not leaving that particular case up to
>maintainer judgement, without removing the general recommendation.

This wouldn't help Clément's motivating example, since it would not
clarify whether there is additional verbose output he needs to
provide.

> 2) Add some examples of what should usually not be included, or perhaps
>just say that if some output makes a build log tens of megabytes in
>size, it should not be included.

I feel that this is trying to solve a problem that doesn't need
solving: packagers generally have good taste, and for most purposes it
is obvious to packagers what outputs they need to include (after all,
the packager is the primary audience of these logs!)  Build command
lines really are a special case since they are important to the
toolchain maintainers.

The size threshold you mentioned would suggest that the Linux kernel
should not support unabbreviated build logs.

> 3) Deal with the 'maximally' problem with one of the rewordings I
>suggested in a previous message -- we want to include mention that
>it's debian/rules that does the work of enabling the reasonable
>verbosity.

Removing 'maximally' might help, but it doesn't significantly change
the basic problem of the current text not being tightly scoped or
providing clear guidance.

Thanks and hope that helps,
Jonathan

Bug#904817: lintian: Warn that depending on both Python 2 and Python 3 interpreters is unusual, likely a mistake?

[Chris Lamb]

tags 904817 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/51446673097e2a3f8e39f3ff6463db47ffc6bb52

  checks/python.desc   |  9 +
  checks/python.pm | 15 +++
  debian/changelog |  3 +++
  .../debian/debian/control.in | 16 
  t/tests/python-depends-python2-and-python3/desc  |  6 ++
  t/tests/python-depends-python2-and-python3/tags  |  1 +
  6 files changed, 50 insertions(+)


Regards,

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

Bug#905221: kicad: pcbnew immediately crashes after invocation without showing a GUI (failed assertion)

[Carsten Schoenert]

Hi,

On Mon, Aug 06, 2018 at 05:07:56PM -0700, Seth Hillbrand wrote:
> Hello Carsten and Werner-
> 
> I've committed a potential fix to this issue to the kicad tree (
> https://git.launchpad.net/kicad/commit/?id=edbf34c2b2965f63537e485d958f00166f01bc5a).
> However, it has only been seen to correct the similar behavior we observed
> earlier and I have been unable to recreate the current issue.
> 
> If you have a chance to apply/test this for the current issue, I'd greatly
> appreciate it.

sure, we can do this. But I'm currently have not the resources to make a
rebuild of the kicad package because I'm on vacation.  I will prepare
something for testing once I"m home again.

Regards
Carsten

Bug#905598: llvm-bcanalyzer diffs its own tempfile names

[Chris Lamb]

tags 905598 + pending
thanks

Thanks for the report. :)  Fixed in Git, pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/1599b01d1cc7f9aef47131ecb86b2db49b0154c1

  diffoscope/comparators/llvm.py | 5 +
  1 file changed, 5 insertions(+)


Regards,

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

Bug#905605: kicad: missing dependency on liboce-ocaf11

[Carsten Schoenert]

Package: kicad
Version: 5.0.0+dfsg1-1
Severity: important

The component editor is showing an error message about a missing
dependency within the latest version.

libTKBinXCAF.so.11 : can't open shared object file : No file or folder?

This looks like a missing dependency on the kicad package.

This issue was reported upstream:
https://bugs.launchpad.net/kicad/+bug/1785630

Maybe this denpendency needs to be added manually if dh_shlibdeps isn't
detecing this correctly.

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

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

Versions of packages kicad depends on:
ii  libc6   2.27-5
ii  libcairo2   1.15.10-3
ii  libcurl47.60.0-2
ii  libgcc1 1:8.2.0-1
ii  libglew2.0  2.0.0-6
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libglx0 1.0.0+git20180308-3
ii  libgomp18.2.0-1
ii  libopengl0  1.0.0+git20180308-3
ii  libpixman-1-0   0.34.0-2
ii  libpython2.72.7.15-3
ii  libssl1.1   1.1.0h-4
ii  libstdc++6  8.2.0-1
ii  libwxbase3.0-0v53.0.4+dfsg-4
ii  libwxgtk3.0-0v5 3.0.4+dfsg-4
ii  python  2.7.15-3
ii  python-wxgtk3.0 3.0.2.0+dfsg-8

Versions of packages kicad recommends:
ii  kicad-demos  5.0.0+dfsg1-1
ii  kicad-libraries  5.0.0+dfsg1-1
ii  xsltproc 1.1.32-2

Versions of packages kicad suggests:
pn  extra-xdg-menus   
ii  kicad-doc-ja  5.0.0+dfsg1-1
ii  kicad-packages3d  5.0.0-1

-- no debconf information

Bug#905221: kicad: pcbnew immediately crashes after invocation without showing a GUI (failed assertion)

[Seth Hillbrand]

Hello Carsten and Werner-

I've committed a potential fix to this issue to the kicad tree (
https://git.launchpad.net/kicad/commit/?id=edbf34c2b2965f63537e485d958f00166f01bc5a).
However, it has only been seen to correct the similar behavior we observed
earlier and I have been unable to recreate the current issue.

If you have a chance to apply/test this for the current issue, I'd greatly
appreciate it.

Best-
Seth

Bug#904886: lintian: Support "debhelper-compat (= X)" B-D as replacement for "debhelper (>= X~)"

[Chris Lamb]

Dear Niels,

> debhelper-and-debhelper-compat-virtual-relation-with-unsupported-version
> might be better worded as
> "debhelper-build-dependency-implied-by-debhelper-compat-relation" and E
> might too high for this.  There is not much harm in having the redundant
> build-dependency.
> 
> On a related note, the text for that tag saying  "However, this requires
> a debhelper 11.3.6 or later." is incorrect.  Having debhelper-compat (=
> X) implies debhelper (>= 11.3.6~) - i.e. you can rely on any feature in
> debhelper up and including version 11.3.6~ without an explicit versioned
> relation on debhelper (but I am fine with lintian not keeping track of
> that).

Hm, perhaps I misunderstood what you wrote a few mails back - could you
provide an example "good" and example "bad" case of a Build-Depends
that uses both just to clarify? I think I've managed to confuse myself.


Best wishes,

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

Bug#905604: version 10.3.0 is available

[Oliver Kurth]

Package: open-vm-tools
Version: 2:10.2.5-1

We have released open-vm-tools 10.3.0.

open-vm-tools 10.3.0 is available for download from GitHub:

https://github.com/vmware/open-vm-tools/tree/stable-10.3.0

For more details and changes, please refer to the release notes at

https://github.com/vmware/open-vm-tools/blob/stable-10.3.0/ReleaseNotes.md

or the ChangeLog at:

https://github.com/vmware/open-vm-tools/blob/stable-10.3.0/open-vm-tools/ChangeLog

Oliver

Bug#903383: wine-development: FTBFS with unicode-data 11

[Michael Gilbert]

This will be fixed by the package now in unstable when it transitions
to testing in 5 days.

Best wishes,
Mike

Bug#905603: libapache2-mod-perl2: crash when using EV::signal 'CHLD' and backtick operator at the same time

[Benoit Bolsee]

Package: libapache2-mod-perl2
Version: 2.0.10-2
Severity: important
Tags: patch upstream



-- Package-specific info:
-8<-- Start Bug Report 8<--
1. Problem Description:

  To reproduce the problem, start from a vanilla Debian server (I used 9.5).
  Install apache2, libapache2-mod-perl2, libev-perl
  Create 2 perl files with following content:
  handler1.pl:
#!/usr/bin/perl
my $pwd = `/bin/pwd`;
1;
  handler2.pl:
#!/usr/bin/perl
use EV;
my $w = EV::signal 'CHLD', sub {
print "SIGCHLD received\n";
};
1;
  Reference them in two PerlRequire directive, either in 
/etc/apache2/apache2.conf or in a separate conf file in 
/etc/apache2/conf-enabled:
   # order is important
   PerlRequire "/path/to/handler1.pl"
   PerlRequire "/path/to/handler2.pl"

  Apache will crash on startup.
  ===
  I did an in-depth analysis of this bug. What happens is the following:

  The backtick operator in handler1.pl internally calls waitpid, which  
internally waits for the SIGCHLD signal.
  EV::signal 'CHLD' installs a signal handler using sigaction (see 
libev-perl-4.22: libev/ev.c::ev_signal_start). There is no provision to remove 
this signal handler. The handler is located in EV.so, loaded by the XS loader.
  
  apache2 goes through 3 stages on startup: pre-config, destroy-config, 
create-config
  In the pre-config stage, the 2 PerlRequire commands are executed and the 
signal handler is installed at process level.
  In the destroy-config stage, all modules are removed, including mod_perl, 
which consists in removing all XS modules (see libapache2-mod-perl2-2.0.10: 
src/modules/perl/modperl_interp.c::modperl_interp_destroy())
  At this point the signal handler is still registered at process level but 
points to invalid memory!
  In the create-config stage, the config is recreated, handler1.pl is reloaded 
and the backtick operator triggers a SIGCHLD, which causes a SIGEV because the 
signal handler is not in memory (the EV.so library will only be loaded when the 
second PerlRequire is executed).
  
  I came to the conclusion that unloading the XS modules when mod_perl is 
unloaded is very harsh; the perl interpretor is clearly not designed for that. 
I tested a patch where the unloading of XS modules is simply skipped. It's 
working and it also fixes another bug that I will report separately:

--- a/src/modules/perl/modperl_interp.c 2018-08-03 20:49:54.0 +0200
+++ b/src/modules/perl/modperl_interp.c 2018-08-03 20:49:54.0 +0200
@@ -122,11 +122,11 @@
 MP_TRACE_i(MP_FUNC, "*error - still in use!*");
 }
 
-handles = modperl_xs_dl_handles_get(aTHX);
+/*handles = modperl_xs_dl_handles_get(aTHX);*/
 
 modperl_perl_destruct(interp->perl);
 
-modperl_xs_dl_handles_close(handles);
+/*modperl_xs_dl_handles_close(handles);*/
 
 free(interp);
 }

  

2. Used Components and their Configuration:

*** mod_perl version 2.10

*** using /usr/lib/x86_64-linux-gnu/perl5/5.24/Apache2/BuildConfig.pm

*** Makefile.PL options:
  MP_APR_CONFIG  => /usr/bin/apr-config
  MP_APR_LIB => aprext
  MP_APXS=> /usr/bin/apxs
  MP_CCOPTS  => -g -O2 
-fdebug-prefix-map=/build/libapache2-mod-perl2-go9ZTa/libapache2-mod-perl2-2.0.10=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall -fgnu89-inline
  MP_COMPAT_1X   => 1
  MP_GENERATE_XS => 1
  MP_LIBNAME => mod_perl
  MP_TRACE   => 0
  MP_USE_DSO => 1
  MP_USE_STATIC  => 0


*** The httpd binary was not found


*** (apr|apu)-config linking info

 -L/usr/lib/x86_64-linux-gnu -laprutil-1
 -L/usr/lib/x86_64-linux-gnu -lapr-1  



*** /usr/bin/perl -V
Summary of my perl5 (revision 5 version 24 subversion 1) configuration:
   
  Platform:
osname=linux, osvers=3.16.0, archname=x86_64-linux-gnu-thread-multi
uname='linux localhost 3.16.0 #1 smp debian 3.16.0 x86_64 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dcc=x86_64-linux-gnu-gcc 
-Dcpp=x86_64-linux-gnu-cpp -Dld=x86_64-linux-gnu-gcc -Dccflags=-DDEBIAN 
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/build/perl-N8J5tr/perl-5.24.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -Dldflags= -Wl,-z,relro -Dlddlflags=-shared 
-Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr 
-Dprivlib=/usr/share/perl/5.24 -Darchlib=/usr/lib/x86_64-linux-gnu/perl/5.24 
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 
-Dvendorarch=/usr/lib/x86_64-linux-gnu/perl5/5.24 -Dsiteprefix=/usr/local 
-Dsitelib=/usr/local/share/perl/5.24.1 
-Dsitearch=/usr/local/lib/x86_64-linux-gnu/perl/5.24.1 
-Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 
-Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 
-Dusesitecustomize -Duse64bitint -Dman1ext=1 -Dman3ext=3perl 
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm 

Bug#905595: qtwebengine-opensource-src: libav* build-dependencies should be (>= 7:3.3.2)

[Lisandro Damián Nicanor Pérez Meyer]

Hi Andreas!

El lun., 6 de ago. de 2018 17:45, Andreas Ferber <
af+debian-bugregpo...@chaos-agency.de> escribió:

> Source: qtwebengine-opensource-src
> Version: 5.11.1+dfsg-5
> Severity: normal
>
> Hi,
>
> when trying to build the package on stretch (with various backports), it
> fails with the following error:
>


Right. We are not able to provide official backports due to the backports
archive not supporting binNMUs for recoding necessary stuff, so we normally
drop this requirements when we know they are fulfilled in testing.

That being said it's good to know someone is doing it, believe me I would
love to provide non official backports of time allowed me.

So please keep filling this bugs, maybe with severity wishlist, but keep
them filling then non the less.

Kind regards, Lisandro

Bug#901405: systemd-shim: Please add a sysvinit service to create directories on /run at boot

[Niels Thykier]

On Tue, 12 Jun 2018 11:27:20 -0400 Felipe Sateler 
wrote:
> Package: systemd-shim
> Version: 10-3
> Severity: normal
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: shim-patches-removal
> 
> Hello Debian systemd-shim Maintainers,
> 
> The Debian systemd package is currently carrying two debian-specific patches
> to enable usage of systemd-shim on Debian systems. In particular, we patch
> some code to continue even if /run/systemd/machines/ and 
> /run/systemd/machines/
> don't exist[1][2].
> These two patches could be avoided if systemd-shim would create the relevant
> directories during early boot (sometime in rcS). Therefore we would like for
> systemd-shim to provide these directories so we can drop these patches.
> If you ship such a SysV init script, please make sure to mask that, so it is
> not accidentally run when systemd is the active PID 1 (assuming the SysV init
> script is called /etc/init.d/systemd-shim, the symlink would be
> /lib/systemd/system/systemd-shim.service → /dev/null).
> 
> We intend to drop the patches before buster is released in the not too distant
> future. When we do that, we will bump the severity of this bug report to 
> serious.
> 
> [1] 
> https://salsa.debian.org/systemd-team/systemd/blob/debian/238-1/debian/patches/debian/Start-logind-on-demand-via-libpam-systemd.patch
> [2] 
> https://salsa.debian.org/systemd-team/systemd/blob/debian/238-1/debian/patches/debian/Make-sd_login_monitor_new-work-for-logind-without-sy.patch
> 
> Saludos,
> Felipe Sateler
> 
> [...]

Hi,

I have marked this (and #901404) as buster-will-remove bugs because I
believe we will remove this package if these RC bugs are not fixed in
time for buster.

CC'ing Ian, because he is the last person to have uploaded this package
(it is currently orphaned AFAICT).

Thanks,
~Niels

Bug#905602: libjs-jquery-uploadify: Please drop libjs-jquery-uploadify or replace its libjs-swf* dependencies

[Niels Thykier]

Package: libjs-jquery-uploadify
Version: 12-1
Severity: serious
Control: block 900106 by -1

Hi,

The (part of the?) Flash player stack appears to be obsolete,
unmaintained and RC buggy.  To my knowledge, the only active plans are
to remove the flash tooling.  This brings us to libjs-jquery-uploadify
which depends on libjs-swf* and in turn mtasc.

Please remove the libjs-swf* dependencies from libjs-jquery-uploadify
(if possible) or remove the binary itself (AFAICT, nothing in testing
or unstable depends on it).  The alternative is that someone takes
over maintenance of the flash stack (presumably, also upstream).

Thanks,
~Niels

Bug#905574: linux-image-4.17.0-0.bpo.1-amd64: cryptsetup missing in intitramfs for kernel 4.17

[Guilhem Moulin]

On Mon, 06 Aug 2018 at 21:15:10 +0800, Ben Hutchings wrote:
> Sometimes driver modules have been reorganised and this has resulted
> in missing modules.  But this wouldn't explain other files being
> missing.

cryptsetup's initramfs boot scripts should be present either way, but
inclusion of the cryptsetup binaries (and crypto modules) depend on
whether the hook detected that some device has to be unlocked at
initramfs stage.  (Unless /etc/cryptsetup-initramfs/conf-hook contains
"CRYPTSETUP=y", which indeed forces initramfs integration.)

Dirk, which “cryptsetup related parts” are missing from the 4.17 bpo
initramfs with cryptsetup 2:1.7.3-4?  Does `update-initramfs -u` print
any warning about unknown module and/or root FS?  Can you confirm that
adding "CRYPTSETUP=y" to /etc/cryptsetup-initramfs/conf-hook (and
compiling your initramfs image with MODULES="most" — the default) fixes
the issue?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#905589: (no subject)

[Marcel Veldhuizen]

The issue was in the /etc/default/bind9 file indeed.

The culprit:
OPTIONS="-f -u bind"

I honestly can't remember why the -f option was there. It must have been 
needed for a (perhaps much) earlier version of bind9.
Up until now, it worked without problems, but I guess that the new 
method for signaling init changed that? I suppose running in the 
"foreground" is a strange option to use for a daemon.


In any case, reverting to the defaults solves the problem.

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Geoff Levand]

Hi All,

On 08/06/2018 06:29 AM, Riku Voipio wrote:
> Thanks indeed - unfortunately we seem to be endind up in 
> a dead end with the upstream developers:
> 
> https://www.spinics.net/lists/arm-kernel/msg669674.html
> 
> Considering HPE didn't actually release the firmware, I think we
> can go with just enabling the options and documenting the command line
> option.

Just to mention it, I went through and verified the info James Morse had
posted regarding m400 System ROM releases [1] and came to the same
conclusion; the latest official release of m400 System ROM did not support
ACPI HEST/AEPI.

[1]  https://www.spinics.net/lists/arm-kernel/msg670446.html

-Geoff

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[debian]

On 08/04/2018 02:04 PM, Горбешко Богдан wrote:
Unfortunately, I messed with it for several hours but couldn't reproduce 
the bug intentionally.


I've just launched a long living rsync job and streamed a video via. mpv 
and managed to crash my system this way.
Before the crash I managed to upload for a couple of minutes while 
watching a video via. Firefox.


(mpv downloads the entire video at full until it's done in comparison to 
Firefox which only caches sequences...)


So from my perspective crashes appear to be still showing up, but way 
less frequently.


I'm on 4.17.11-arch1 x86_64 right now.

Bug#905601: znc-dev: Depends on tcl8.5-dev (which is scheduled for removal per #896087)

[Niels Thykier]

Package: znc-dev
Version: 1.7.1-1
Severity: serious
Control: block 896087 by -1

Hi,

The znc-dev package Depends on tcl8.5-dev which is scheduled for
removal in Buster per #896087.  Kindly update the dependency to a
supported version of tcl.

Thanks,
~Niels

Bug#904045: enlightenment: no background image tiling

[enno]

> "Ross" == Ross Vandegrift  writes:
>  On Wed, Jul 18, 2018 at 10:22:52PM +0200, enno wrote:
>> I like to have my custom images tiled as background.  e17 as of
>> 0.17.6-1.1+b1 could do it, apparently 0.22.3-2 cannot.  Or I
>> couldn't find it in Settings.
> 
> You set this when the picture is imported.
> 
> Open Settings -> Wallpaper and click "Picture...".  Choose your
> image file and Enlightenment will open a dialog that lets you
> control setup the image, including tiling.
> 
> Ross

Thanks very much appreciate your time, tiling bg images works when I follow 
your advice, but all my screens get the same background, no matter if I check 
"only this desktop" or "only this screen".

I like to have my 0-0 and 1-0 with All-Good-People and my 0-1 and 1-1 with 
Enigmas_Oven.  Just a habit.

Brgds, enno.

-- 
  //   enno@gmx.net
/\\\   Mag. Enno Deimel
  .\o
 \\  \ _  \Wisely and slow; they stumble that run fast.
\\\ \_/
gpg-fp: eefe b049 6fe6 fc0b 0ec4  f39e af6a c178 eb98 909a

Bug#905600: britney: Crash in britney due to trigger

[Niels Thykier]

Subject: asd
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: britney
Severity: normal
X-Debbugs-CC: elb...@debian.org

Hi,

Britney crashed with the following error:

Cron Daemon:
> Traceback (most recent call last):
>   File "/srv/release.debian.org/britney/code/b2/britney.py", line 2873, in 
> 
> Britney().main()
>   File "/srv/release.debian.org/britney/code/b2/britney.py", line 388, in 
> __init__
> policy.initialise(self)
>   File 
> "/srv/release.debian.org/britney/code/b2/britney2/policies/autopkgtest.py", 
> line 178, in initialise
> self.add_trigger_to_results(trigger, src, ver, arch, stamp, 
> Result[status.upper()])
>   File 
> "/srv/release.debian.org/britney/code/b2/britney2/policies/autopkgtest.py", 
> line 669, in add_trigger_to_results
> (trigsrc, trigver) = trigger.split('/', 1)
> ValueError: not enough values to unpack (expected 2, got 1)
> 

It appears be due to an autopkgtest trigger that does not match
britney's expectations.

@elbrus: I noticed you had the following commit attempts to fix
something similar:
https://salsa.debian.org/elbrus/britney2/commit/e6a6e62abd04c7c0d5e844ce6cd45c5e6eb970e7

(though I am not entirely sure it is applicable here, because it does
not seem like the commit will fix this crash)

Thanks,
~Niels

Bug#905246: add usertag

[Nicholas D Steeves]

user debian-emac...@lists.debian.org
usertags 905246 elpafy
thanks


signature.asc
Description: PGP signature

Bug#905599: Review default config file contents, attempt to make them as small as possible

[Otto Kekäläinen]

Package: mariadb-10.1
Severity: wishlist

Go through all configs we have, and try to make them smaller. Ideally
we would not have any settings ourselves, but use all defaults as
upstream ships them.

First step is at least read all options we set in the default config
files, and check what their default value is via
https://mariadb.com/kb/en/library/xtradbinnodb-server-system-variables/
and similar pages. If the value we set equals what is the default in
10.1 anyway, then those stanzas could be disabled.

Bug#905353: reportbug: reports package on hold as not installed

[Nis Martensen]

control: tags 905353 patch

On 03 Aug 2018 Sven Joachim wrote:
> In the output of the last command, I would have expected emacsen-common
> to be reported as
> 
> hi  emacsen-common  2.0.8

Thank you for the nice report. This should fix it:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/5/diffs

Can you please test?

Bug#881835: mbr: diff for NMU version 1.1.11-5.2

[Niels Thykier]

Control: tags 881835 + pending


Dear maintainer,

I've prepared an NMU for mbr (versioned as 1.1.11-5.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

(Apologies for the noise; I managed to cancel the upload and
correct the missing Closes)

Regards.

diff -u mbr-1.1.11/debian/changelog mbr-1.1.11/debian/changelog
--- mbr-1.1.11/debian/changelog
+++ mbr-1.1.11/debian/changelog
@@ -1,3 +1,23 @@
+mbr (1.1.11-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Simon McVittie ]
+  * Only copy install-mbr to debian/mbr-udeb/sbin if we are going to
+build the mbr-udeb package, fixing FTBFS on non-x86 architectures.
+In recent debhelper versions, dh_installdirs does not create
+directories for binary packages that are not applicable to the
+current architecture.  (Closes: #881835)
+
+  [ Niels Thykier ]
+  * Set Rules-Requires-Root (R³) to no.
+  * Replace use of "Priority: extra" with "Priority: optional" as the
+former is now obsolete and replaced by the latter.
+  * Use Package-Type without the "XC-" prefix as it is no longer
+required.
+
+ -- Niels Thykier   Mon, 06 Aug 2018 18:53:12 +
+
 mbr (1.1.11-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u mbr-1.1.11/debian/control mbr-1.1.11/debian/control
--- mbr-1.1.11/debian/control
+++ mbr-1.1.11/debian/control
@@ -4,6 +4,7 @@
 Maintainer: Santiago Garcia Mantinan 
 Standards-Version: 3.9.3
 Build-Depends: debhelper(>= 7), bin86, util-linux (>= 2.13) | linux32, xxd
+Rules-Requires-Root: no
 
 Package: mbr
 Architecture: any
@@ -16,9 +17,8 @@
 Package: mbr-udeb
 Architecture: i386 amd64 lpia
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Priority: extra
 Section: debian-installer
-XC-Package-Type: udeb
+Package-Type: udeb
 XB-Installer-Menu-Item: 9
 Description: Master Boot Record for IBM-PC compatible computers
 
diff -u mbr-1.1.11/debian/rules mbr-1.1.11/debian/rules
--- mbr-1.1.11/debian/rules
+++ mbr-1.1.11/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+binaries := $(shell dh_listpackages)
+
 CC := gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
 
 CFLAGS := -g -Wall -W
@@ -38,7 +40,9 @@
dh_installdocs -p mbr debian/README-1st.Debian NEWS README AUTHORS
dh_installchangelogs
$(MAKE) install INSTALL_PROGRAM="$(INSTALL_PROGRAM)"
+ifneq ($(filter mbr-udeb,$(binaries)),)
cp `pwd`/debian/mbr/sbin/install-mbr `pwd`/debian/mbr-udeb/sbin/
+endif
 
 binary-indep: build
dh_testdir

Bug#905598: llvm-bcanalyzer diffs its own tempfile names

[Christoph Berg]

Package: diffoscope
Version: 99
Severity: normal

Hi,

just when postgresql-10 was almost reproducible (and I hope to really
weed the remaining `uname -m` bits in the upload on Thursday),
postgresql-11 came around which adds JIT for SQL queries via LLVM. For
this, LLVM bytecode (.bc) files are stored which are then compiled at
runtime.

Looking at
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/postgresql-11.html
I noticed that the diff of the .bc files (which differ because they
store the build paths), there's a bit there the `llvm-bcanalyzer -dump`
output itself introduces a path, which is then reported as difference:

Summary of 
/srv/reproducible-results/rbuild-debian/tmp.Xss3ZdRPQz/dbd-tmp-3DqxLmN/diffoscope_wmjtu2i8/tmpdktglxs6/0/8.bc:
Summary of 
/srv/reproducible-results/rbuild-debian/tmp.Xss3ZdRPQz/dbd-tmp-3DqxLmN/diffoscope_wmjtu2i8/tmpwintfm2m/0/8.bc:

Christoph

Bug#886756: [debian-mysql] Bug#886756: Regression: Specified key was too long; max key length is 767 bytes

[Otto Kekäläinen]

Hello!

I plan to have this commit included in the next upload of MariaDB
10.1.x into Debian:
https://salsa.debian.org/mariadb-team/mariadb-10.1/commit/89ae638d1d3b5a7157d086a9be2468cae764aae7


ti 9. tammik. 2018 klo 17.45 Jonas Meurer (jo...@freesources.org) kirjoitti:
>
> Package: mariadb-server-10.1
> Version: 1:10.1.29-6
> Severity: serious
> Tags: upstream
>
> Control: -1 forwarded https://jira.mariadb.org/browse/MDEV-14904
>
> Hello,
>
> I just discovered that MariaDB 10.1 packages in Sid, Buster and Stretch
> break applications that expect a maximum allowed size of 255 characters
> for VARCHAR fields. E.g.:
>
> > django.db.utils.OperationalError: (1071, 'Specified key was too long;
> > max key length is 767 bytes')
>
> This is due to the fact that MariaDB in Debian has `utf8mb4` set as
> default character since version 10.0.20-2 which raises the required
> amount of memory per character.
>
> To still allow fields with > 191 < 255 characters, `innodb_large_prefix`
> has to be enabled, which in turn requires the following settings:
>
> > innodb_file_format  = Barracuda
> > innodb_file_per_table   = On
> > innodb_large_prefix = On
>
> Unfortunately even that is not enough. Additionally, the row format for
> tables needs to be changed to `dynamic`.
>
> Starting with MariaDB 10.2, `innodb_default_row_format` was introduced,
> which allows to set the default row format for the whole MariaDB server.
> Unfortunately, this option is not available in MariaDB 10.1 yet. In
> other words, there's no way to configure MariaDB 10.1 in Debian in a way
> that it works with applications that expect things like VARCHAR(255) to
> be possible.
>
> This is a severe regression. I discussed this topic with MariaDB
> upstream developer Marko Mäkelä (dr-m) on IRC and he agreed that they
> can backport `innodb_default_row_format` for the next upstream release
> of MariaDB 10.1. I created an upstream bugreport to track this:
>
> https://jira.mariadb.org/browse/MDEV-14904
>
> I suggest that this fix should be backported to MariaDB 10.1 in Debian
> Stable as well as it is a severe regression compared to MySQL and
> earlier MariaDB versions (i.e. pre 10.0.20-2).
>
> PS: This problem doesn't exist with MariaDB >= 10.2 or MySQL 5.7 as
> both switched to `Barracudea` as default `innodb_file_format` along
> with `innodb_large_prefix` and `dynamic` as default row format.
>
> See the following bugreports and discussion threads for further details:
>
> * https://jira.mariadb.org/browse/MDEV-9646
> * https://code.djangoproject.com/ticket/18392
> * 
> https://stackoverflow.com/questions/30761867/mysql-error-the-maximum-column-size-is-767-bytes

Bug#905597: Debian 9.5 : "ip netns" does not work (iface ping test)

[peter.gasparovic]

Package: iproute2
Version: 4.9.0-1+deb9u1
 
Hi, I was doing very simple config of moving network physical interface into 
"test" network name-space, assigned it IP address, activated the interface in 
there... and simple pinging the iface does not work (so I can't progress). I'm 
quite in a hot need to have this working as it's excellent feature to save a 
lot resources (need to send various data among single-PC interfaces over 
external routed infrastructure, that's why I want to separate interfaces in 
namespaces)

sudo ip netns add test
sudo ip link set dev ens192 netns test
sudo ip -n test addr add 1.1.1.1/24 dev ens192
sudo ip netns exec test ping 1.1.1.1

peterg@debian:~$ sudo ip -n test link
[sudo] password for peterg: 
1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT group default 
qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens192:  mtu 1500 qdisc mq state UP mode 
DEFAULT group default qlen 1000
link/ether 00:50:56:00:49:01 brd ff:ff:ff:ff:ff:ff
peterg@debian:~$ sudo ip -n test route
1.1.1.0/24 dev ens192 proto kernel scope link src 1.1.1.1
peterg@debian:~$ sudo ip -n test add
1: lo:  mtu 65536 qdisc noop state DOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens192:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:50:56:00:49:01 brd ff:ff:ff:ff:ff:ff
inet 1.1.1.1/24 scope global ens192
   valid_lft forever preferred_lft forever

peterg@debian:~$ uname -a
Linux debian 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 GNU/Linux
inside a VM on VMware ESXI.

BR!
Peter Gasparovic


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#887593: More apparmor="ALLOWED" messages in syslog.

[Rene Engelhard]

Hi,

On Sat, Aug 04, 2018 at 05:50:35PM +0300, Vincas Dargis wrote:
> intrigeri, could we get opencl abstractions in 2.13, or we are expecting to 
> get AppArmor 3 in Buster?
> 
> BTW I have proposed update to use `dri-enumerate` abstraction and remove 
> backported rule:
> https://gerrit.libreoffice.org/#/c/58589/

As I said upstream I am not sure about this upstream.

But for Debian we could (we know the AA version) do that, sure.

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/5e887f9e973f448672befe428d81b0379a00a43c

Regards,

Rene
> 

Bug#905596: qtwebengine-opensource-src: build error with libicu-dev from stable

[Andreas Ferber]

Source: qtwebengine-opensource-src
Version: 5.11.1+dfsg-5
Severity: normal

Hi,

when building the package on stable (plus various backports), I got the
following error:

--
../../3rdparty/chromium/components/url_formatter/idn_spoof_checker.cc: In 
member function 'bool 
url_formatter::IDNSpoofChecker::SimilarToTopDomains(base::StringPiece16)':
../../3rdparty/chromium/components/url_formatter/idn_spoof_checker.cc:321:42: 
error: invalid conversion from 'UChar* {aka short unsigned int*}' to 
'char16_t*' [-fpermissive]
 char16_t* buffer = host_alt.getBuffer(-1);
~~^~~~
--

Between icu versions 57 (stable) and 60 (testing/unstable), there was a
change in the data type returned by the getBuffer method of
icu::UnicodeString.

This can either be fixed with the attached patch (note that a similar
reinterpret_cast<>() as introduced by the patch is done in a bunch of
other places within chromium where icu::UnicodeString is used), or you
should bump the libicu-dev build dependency to (>= 59), as icu 59 was
the upstream version that introduced the change.

Regards,
Andreas Ferber
--- a/src/3rdparty/chromium/components/url_formatter/idn_spoof_checker.cc
+++ b/src/3rdparty/chromium/components/url_formatter/idn_spoof_checker.cc
@@ -318,7 +318,7 @@
   if ((u04cf_pos = host.indexOf(0x4CF)) != -1) {
 icu::UnicodeString host_alt(host);
 size_t length = host_alt.length();
-char16_t* buffer = host_alt.getBuffer(-1);
+char16_t* buffer = reinterpret_cast(host_alt.getBuffer(-1));
 for (char16_t* uc = buffer + u04cf_pos ; uc < buffer + length; ++uc) {
   if (*uc == 0x4CF)
 *uc = 0x6C;  // Lowercase L

Bug#861553: [debian-mysql] Bug#861553: Please enable numa support

[Otto Kekäläinen]

Hello!

su 30. huhtik. 2017 klo 21.06 Laurent Bigonville (bi...@debian.org) kirjoitti:
> Shouldn't mariadb be built with numa support?

Upstream MariaDB 10.1 does not seem to build with numa. However 10.3
is doing so, and we will soon import 10.3 into Debian, and then build
it with libnuma as well.

mariadb-10.3$ grep numa debian/*
debian/control:   libnuma-dev [!armhf],

Bug#905559: Bug#902263: Bug#905559: Bug#902263: Affecting Qt transition

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 6 de agosto de 2018 17:26:59 -03 Lisandro Damián Nicanor Pérez Meyer 
escribió:
[snip]
> /me facepalms
> 
> Ah, indeed, my bad! It's frameworks, not PIM. Sorry about that.

Paul, RT: my most sincere apologies. I don't know how but I got to mix 
frameworks with PIM. Frameworks is indeed another thing.

I have just checked upstream's CI and they have not checked the tests against 
5.11 (which is odd), but I'll file the bug as appropriate.

Again, my apologies.

-- 
Sobre Argentina: "sé que es uno de los países mas hospitalarios del mundo"
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#905595: qtwebengine-opensource-src: libav* build-dependencies should be (>= 7:3.3.2)

[Andreas Ferber]

Source: qtwebengine-opensource-src
Version: 5.11.1+dfsg-5
Severity: normal

Hi,

when trying to build the package on stretch (with various backports), it
fails with the following error:

--
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.cc: In function 
'media::VideoCodec media::CodecIDToVideoCodec(AVCodecID)':
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.cc:192:10: error: 
'AV_CODEC_ID_AV1' was not declared in this scope
 case AV_CODEC_ID_AV1:
  ^~~
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.cc: In function 'AVCodecID 
media::VideoCodecToCodecID(media::VideoCodec)':
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.cc:217:14: error: 
'AV_CODEC_ID_AV1' was not declared in this scope
   return AV_CODEC_ID_AV1;
  ^~~
--

Looking at the git history of the ffmpeg debian package showed that the
first version containing the missing definition is version 7:3.3.2-1,
even though the FFmpeg upstream changelog itself first mentions AV1
support for version 4.0. This seems to be somewhat confirmed by the fact
that building against the FFmpeg packages from deb-multimedia.org (based
on FFmpeg 3.3.8) works.

Therefore I think the build-dependencies on libavcodec-dev,
libavformat-dev and libavutil-dev should be bumped to (>= 7:3.3.2)

Regards,
Andreas Ferber

Bug#903182: mtr: diff for NMU version 0.92-1.1

[Niels Thykier]

Control: tags 903182 + patch
Control: tags 903182 + pending


Dear maintainer,

I've prepared an NMU for mtr (versioned as 0.92-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru mtr-0.92/debian/changelog mtr-0.92/debian/changelog
--- mtr-0.92/debian/changelog   2017-11-02 02:48:40.0 +
+++ mtr-0.92/debian/changelog   2018-08-06 20:33:06.0 +
@@ -1,3 +1,14 @@
+mtr (0.92-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove redundant debian/*manpages files.  The upstream build
+system correctly installs the manpages by default and the
+manpages had incorrect path.  (Closes: #903182)
+  * Set Rules-Requires-Root to no as mtr does not need (fake)root
+during the binary targets.
+
+ -- Niels Thykier   Mon, 06 Aug 2018 20:33:06 +
+
 mtr (0.92-1) unstable; urgency=medium
 
   [ Samuel Henrique ]
diff -Nru mtr-0.92/debian/control mtr-0.92/debian/control
--- mtr-0.92/debian/control 2017-11-02 02:43:57.0 +
+++ mtr-0.92/debian/control 2018-08-06 20:17:03.0 +
@@ -12,6 +12,7 @@
libncurses-dev
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/mtr.git
 Vcs-Browser: https://anonscm.debian.org/git/collab-maint/mtr.git
+Rules-Requires-Root: no
 
 Package: mtr
 Architecture: any
diff -Nru mtr-0.92/debian/manpages mtr-0.92/debian/manpages
--- mtr-0.92/debian/manpages2017-11-02 02:43:57.0 +
+++ mtr-0.92/debian/manpages1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-mtr.8
diff -Nru mtr-0.92/debian/mtr.manpages mtr-0.92/debian/mtr.manpages
--- mtr-0.92/debian/mtr.manpages2017-11-02 02:45:23.0 +
+++ mtr-0.92/debian/mtr.manpages1970-01-01 00:00:00.0 +
@@ -1,2 +0,0 @@
-mtr/mtr.8
-mtr/mtr-packet.8
diff -Nru mtr-0.92/debian/mtr-tiny.manpages mtr-0.92/debian/mtr-tiny.manpages
--- mtr-0.92/debian/mtr-tiny.manpages   2017-11-02 02:45:32.0 +
+++ mtr-0.92/debian/mtr-tiny.manpages   1970-01-01 00:00:00.0 +
@@ -1,2 +0,0 @@
-mtr/mtr.8
-mtr/mtr-packet.8

Bug#902263: Bug#905559: Bug#902263: Affecting Qt transition

[Sandro Knauß]

Hey,

> That's totally understandable from your part. Now the test has clearly
> failed. The regression could either be in Qt or in some part of the KDE PIM
> stack (not the meta package).

ktexteditor is KDE Frameworks and not KDE PIM. For KDE PIM the argument of not 
being up-to-date and not being ready for Qt 5.11 may be/is valid. But 
Framworks is uptodate with 5.47 (released in June) and it should be Qt 5.11 
ready - So you should considering filing a bug about this regression upstream.

hefee



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

Bug#902263: Bug#905559: Bug#902263: Affecting Qt transition

[Lisandro Damián Nicanor Pérez Meyer]

El lun., 6 de ago. de 2018 17:23, Sandro Knauß  escribió:

> Hey,
>
> > That's totally understandable from your part. Now the test has clearly
> > failed. The regression could either be in Qt or in some part of the KDE
> PIM
> > stack (not the meta package).
>
> ktexteditor is KDE Frameworks and not KDE PIM. For KDE PIM the argument of
> not
> being up-to-date and not being ready for Qt 5.11 may be/is valid. But
> Framworks is uptodate with 5.47 (released in June) and it should be Qt
> 5.11
> ready - So you should considering filing a bug about this regression
> upstream.
>

/me facepalms

Ah, indeed, my bad! It's frameworks, not PIM. Sorry about that.

So yes, I'll file the bug.

>

Bug#898725: flex: diff for NMU version 2.6.4-6.2

[Niels Thykier]

Control: tags 898725 + pending


Dear maintainer,

I've prepared an NMU for flex (versioned as 2.6.4-6.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u flex-2.6.4/debian/changelog flex-2.6.4/debian/changelog
--- flex-2.6.4/debian/changelog
+++ flex-2.6.4/debian/changelog
@@ -1,3 +1,19 @@
+flex (2.6.4-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Ruben Undheim ]
+  * debian/rules:
+- Fix build with "dpkg-buildpackage -A" by checking if directory exists
+  first (Closes: #898725)
+
+  [ Niels Thykier ]
+  * debian/control:
+- Set Rules-Requires-Root (R³) to no as flex does not need/require
+  (fake)root during package build.
+
+ -- Niels Thykier   Mon, 06 Aug 2018 19:40:25 +
+
 flex (2.6.4-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u flex-2.6.4/debian/control flex-2.6.4/debian/control
--- flex-2.6.4/debian/control
+++ flex-2.6.4/debian/control
@@ -10,6 +10,7 @@
 Build-Depends-Indep: texlive-latex-base, texlive-fonts-recommended, 
cm-super-minimal
 Maintainer: Manoj Srivastava 
 Standards-Version: 4.1.3
+Rules-Requires-Root: no
 
 Package: flex
 Architecture: any
diff -u flex-2.6.4/debian/rules flex-2.6.4/debian/rules
--- flex-2.6.4/debian/rules
+++ flex-2.6.4/debian/rules
@@ -73,7 +73,9 @@
rm -f debian/flex/usr/share/doc/flex/flex.pdf
test ! -f debian/flex/usr/share/doc/flex/COPYING ||  \
 rm -f debian/flex/usr/share/doc/flex/COPYING
-   find debian/flex/usr/share/locale  -type d -empty -delete
+   if [ -d debian/flex/usr/share/locale ] ; then \
+ find debian/flex/usr/share/locale  -type d -empty -delete ; \
+   fi
dh_link
 
 

Bug#905111: gnome-shell-extension-autohidetopbar: global.screen is not available in GNOME Shell 3.29

[Simon McVittie]

On Tue, 31 Jul 2018 at 11:38:47 +0100, Simon McVittie wrote:
> According to codesearch.debian.net, this extension uses the MetaScreen
> via global.screen.

The attached patch seems to work. I've forwarded it to
.

smcv
>From 2c613f8ad920081df1f70e38a41292fcac435722 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 6 Aug 2018 20:37:40 +0100
Subject: [PATCH] Adapt to removal of MetaScreen in mutter 3.29.x

If running under GNOME Shell 3.29.x, use display, layout manager or
workspace manager (as appropriate) to replace uses of MetaScreen, which
was removed in mutter 3.29.x.

Closes: #905111
---
 debian/changelog  |  9 ++
 ...moval-of-MetaScreen-in-mutter-3.29.x.patch | 99 +++
 debian/patches/series |  1 +
 3 files changed, 109 insertions(+)
 create mode 100644 debian/patches/Adapt-to-removal-of-MetaScreen-in-mutter-3.29.x.patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index a8240c9..f7081f5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+gnome-shell-extension-autohidetopbar (20180511-1.1) UNRELEASED; urgency=medium
+
+  * d/p/Adapt-to-removal-of-MetaScreen-in-mutter-3.29.x.patch:
+If running under GNOME Shell 3.29.x, use display, layout manager or
+workspace manager (as appropriate) to replace uses of MetaScreen,
+which was removed in mutter 3.29.x (Closes: #905111)
+
+ -- Simon McVittie   Mon, 06 Aug 2018 20:35:26 +0100
+
 gnome-shell-extension-autohidetopbar (20180511-1) unstable; urgency=medium
 
   * New upstream git snapshot.
diff --git a/debian/patches/Adapt-to-removal-of-MetaScreen-in-mutter-3.29.x.patch b/debian/patches/Adapt-to-removal-of-MetaScreen-in-mutter-3.29.x.patch
new file mode 100644
index 000..8ba99a4
--- /dev/null
+++ b/debian/patches/Adapt-to-removal-of-MetaScreen-in-mutter-3.29.x.patch
@@ -0,0 +1,99 @@
+From: Simon McVittie 
+Date: Mon, 6 Aug 2018 20:34:59 +0100
+Subject: Adapt to removal of MetaScreen in mutter 3.29.x
+
+If running under GNOME Shell 3.29.x, use display, layout manager or
+workspace manager (as appropriate) to replace uses of MetaScreen, which
+was removed in mutter 3.29.x.
+
+Bug: https://github.com/mlutfy/hidetopbar/issues/162
+Bug-Debian: https://bugs.debian.org/905111
+Signed-off-by: Simon McVittie 
+Forwarded: https://github.com/mlutfy/hidetopbar/pull/163
+---
+ intellihide.js| 24 +---
+ panelVisibilityManager.js |  8 +++-
+ 2 files changed, 28 insertions(+), 4 deletions(-)
+
+diff --git a/intellihide.js b/intellihide.js
+index f992e28..b684b1c 100644
+--- a/intellihide.js
 b/intellihide.js
+@@ -75,6 +75,18 @@ var intellihide = new Lang.Class({
+ this._checkOverlapTimeoutContinue = false;
+ this._checkOverlapTimeoutId = 0;
+ 
++let stackingManager;
++if (global.screen)
++stackingManager = global.screen;// mutter < 3.29
++else
++stackingManager = global.display;   // mutter >= 3.29
++
++let monitorManager;
++if (global.screen)
++monitorManager = global.screen; // mutter < 3.29
++else
++monitorManager = Main.layoutManager;// mutter >= 3.29
++
+ // Connect global signals
+ this._signalsHandler.add([
+ // Listen for notification banners to appear or disappear
+@@ -93,7 +105,7 @@ var intellihide = new Lang.Class({
+ ], [
+ // triggered for instance when the window list order changes,
+ // included when the workspace is switched
+-global.screen,
++stackingManager,
+ 'restacked',
+ Lang.bind(this, this._checkOverlap)
+ ], [
+@@ -104,7 +116,7 @@ var intellihide = new Lang.Class({
+ Lang.bind(this, this._checkOverlap)
+ ], [
+ // update wne monitor changes, for instance in multimonitor when monitor are attached
+-global.screen,
++monitorManager,
+ 'monitors-changed',
+ Lang.bind(this, this._checkOverlap )
+ ]);
+@@ -270,7 +282,13 @@ var intellihide = new Lang.Class({
+ return false;
+ }
+ 
+-let currentWorkspace = global.screen.get_active_workspace_index();
++let workspaceManager;
++if (global.screen)
++workspaceManager = global.screen;   // mutter < 3.29
++else
++workspaceManager = global.workspace_manager;// mutter >= 3.29
++
++let currentWorkspace = workspaceManager.get_active_workspace_index();
+ let wksp = meta_win.get_workspace();
+ let wksp_index = wksp.index();
+ 
+diff --git a/panelVisibilityManager.js b/panelVisibilityManager.js
+index 5c187fe..a546d54 100644
+--- a/panelVisibilityManager.js
 b/panelVisibilityManager.js
+@@ -319,6 +319,12 @@ var PanelVisibilityManager 

Bug#905594: src:libtext-bibtex-perl: FTBFS with merged /usr (debootstrap 1.0.102+)

[Damyan Ivanov]

Package: src:libtext-bibtex-perl
Version: 0.85-1
Severity: important

libtext-bibtex-perl fails to build in a fresh chroot, created with debootstrap 
1.0.102+. That version of debootstrap creates /usr/lib64 directory and the 
build system of libtext-bibtex-perl installs libbtparse.so.1 there, leading to 
a failure during dh_install, which looks for /usr/lib/libbtparse.so.*. From the 
build log (attached):

...

** Preparing XS code
Files found in blib/arch: installing files in blib/lib into architecture 
dependent libr
ary tree

** WARNING **
It seems you are installing in a non standard path.
You might need to add /usr/lib64 to your library search path.
...
Installing /<>/debian/tmp/usr/lib64/libbtparse.so.1
...
   dh_install
dh_install: Cannot find (any matches for) "usr/lib/libbtparse.so.*" (tried in 
., debian/tmp)

dh_install: libbtparse1 missing files: usr/lib/libbtparse.so.*
dh_install: missing files, aborting
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2


This seems to be no problem at present, since the buildds don't have 
/usr/lib64, perhaps because they aren't created with a recent debootstrap. 
However, this will become a problem sooner or later.


-- dam
sbuild (Debian sbuild) 0.77.0 (06 July 2018) on pc1.creditreform.bg

+==+
| libtext-bibtex-perl 0.85-1 (amd64)   Mon, 06 Aug 2018 13:23:09 + |
+==+

Package: libtext-bibtex-perl
Version: 0.85-1
Source Version: 0.85-1
Distribution: sid
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid-amd64-sbuild-123cad98-13ee-4c6f-9257-b3801470fd42' 
with '<>'
I: NOTICE: Log filtering will replace 
'build/libtext-bibtex-perl-PdZX0m/resolver-fFTHPQ' with '<>'

+--+
| Update chroot|
+--+

Get:1 http://proxy:/debian sid InRelease [233 kB]
Get:2 http://proxy:/debian experimental InRelease [101 kB]
Get:3 http://perl.debian.net/test-repo perl-5.28 InRelease [2871 B]
Get:4 http://proxy:/debian sid/main amd64 Packages.diff/Index [27.9 kB]
Get:5 http://proxy:/debian sid/main amd64 Packages 2018-08-04-0814.44.pdiff 
[20.5 kB]
Get:6 http://proxy:/debian sid/main amd64 Packages 2018-08-04-1411.17.pdiff 
[9739 B]
Get:7 http://proxy:/debian sid/main amd64 Packages 2018-08-04-2013.33.pdiff 
[17.8 kB]
Get:8 http://proxy:/debian sid/main amd64 Packages 2018-08-05-0209.24.pdiff 
[15.5 kB]
Get:9 http://proxy:/debian sid/main amd64 Packages 2018-08-05-0806.31.pdiff 
[2966 B]
Get:10 http://proxy:/debian sid/main amd64 Packages 
2018-08-05-1409.33.pdiff [18.0 kB]
Get:11 http://proxy:/debian sid/main amd64 Packages 
2018-08-05-2014.01.pdiff [9558 B]
Get:12 http://proxy:/debian sid/main amd64 Packages 
2018-08-06-0208.11.pdiff [4773 B]
Get:13 http://proxy:/debian sid/main amd64 Packages 
2018-08-06-0809.42.pdiff [5408 B]
Get:13 http://proxy:/debian sid/main amd64 Packages 
2018-08-06-0809.42.pdiff [5408 B]
Get:14 http://proxy:/debian experimental/main amd64 Packages.diff/Index 
[27.8 kB]
Get:15 http://proxy:/debian experimental/main amd64 Packages 
2018-08-04-0814.44.pdiff [2751 B]
Get:16 http://proxy:/debian experimental/main amd64 Packages 
2018-08-04-2013.33.pdiff [1108 B]
Get:17 http://proxy:/debian experimental/main amd64 Packages 
2018-08-05-0209.24.pdiff [3252 B]
Get:18 http://proxy:/debian experimental/main amd64 Packages 
2018-08-05-0806.31.pdiff [33 B]
Get:19 http://proxy:/debian experimental/main amd64 Packages 
2018-08-05-2014.01.pdiff [2300 B]
Get:20 http://proxy:/debian experimental/main amd64 Packages 
2018-08-06-0208.11.pdiff [924 B]
Get:21 http://proxy:/debian experimental/main amd64 Packages 
2018-08-06-0809.42.pdiff [31 B]
Get:21 http://proxy:/debian experimental/main amd64 Packages 
2018-08-06-0809.42.pdiff [31 B]
Get:22 http://perl.debian.net/test-repo perl-5.28/main amd64 Packages [656 kB]
Fetched 1164 kB in 1s (1008 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  gzip make patch
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 585 kB of archives.
After this operation, 8192 B of additional disk space will be used.
Get:1 http://proxy:/debian sid/main amd64 gzip amd64 1.9-2 [119 kB]
Get:2 http://proxy:/debian sid/main amd64 make amd64 4.2.1-1.2 [341 kB]
Get:3 http://proxy:/debian sid/main amd64 patch amd64 2.7.6-3 [126 kB]
debconf: 

Bug#811269: Bug#871255: please consider two patches to allow smaller systems to be installed

[Marc Haber]

Sorry, I have been kind of moved away from things by two years of
deafening silence. I think that implementation of #811269 will probably
make it easier to work around the results of the two other bugs, but it
would be much easier to have all three bugs addressed properly.

I still fail to see why -k was added to tar in the first place. I would
prefer #811269 being addressed _and_ the -k option made optional.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#905593: [Pkg-utopia-maintainers] Bug#905593: network-manager: /etc/...*.service files should be considered as configuration files

[Michael Biebl]

Am 06.08.2018 um 21:43 schrieb Cyril Adrian:
> Package: network-manager
> Version: 1.12.2-1
> Severity: important
> Tags: newcomer
> 
> Follow-up of #905585.
> 
> It looks like I was not clear enough.
> 
> I am talking of 
> /etc/systemd/system/network-online.target.wants/NetworkManager-
> wait-online.service
> 
> This file is in /etc -- therefore unless I am mistaken it is in the
> configuration directory and should not be carelessly overwritten.

No, this is a symlink pointing to a file in /lib/systemd. If you edit
that file, you are effectively editing the file in /lib/systemd.

If you want to change the behaviour of
NetworkManager-wait-online.service, use either
systemctl edit NetworkManager-wait-online.service (which creates a drop-in)
or systemctl edit --full NetworkManager-wait-online.service (which
creates a full copy of the file in /etc)


-- 
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#902263: Affecting Qt transition

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 6 de agosto de 2018 15:34:02 -03 Paul Gevers escribió:
> Dear all,

Hi Paul :-)

> To be sure, I don't want to block/delay anything here, I just want
> autopkgtests to be taken seriously. If you as the maintainer of
> ktexteditor say please ignore my test for migration, who am I to say
> you're wrong. However, you have also added that test for a reason.

That's totally understandable from your part. Now the test has clearly failed. 
The regression could either be in Qt or in some part of the KDE PIM stack (not 
the meta package).

> On 06-08-18 15:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> > I used i, d, v, y, shift+p. I even retried them just now in case I missed
> > something.
> 
> What does idvyP (insert mode; add characters d v y P) have to do with
> the failing test case? Lot's of vim code seems to go all right, there is
> only 1 regression.
> 

With the above and...

> As long as this is the only thing, I agree with you, but if you don't
> know what's wrong you don't actually know. (Albeit the amount of passing
> tests says something, but once you let this one into testing, the whole
> autopkgtest of ktexteditor becomes worthless until this issue is fixed
> somehow).

... considering it seems happens only in a certain specific case for a certain 
specific option that can be easily overridden by using the editor in it's 
normal, default mode: yes, even if there is a regression it's negligible 
enough to delay things further.

So the autopkg tests did it's job, but the balance between pushing Qt or 
fixing the test/offending code makes it not worth the effort to wait.

[snip]

> I don't know which package you exactly mean with kdepim as that is a
> meta-package that is the same in unstable and testing since 2018-06-10.

KDE PIM is a big stack, which needs to be updated and possibly with a small 
transition involved. We do not want both things tangled together.

> All source packages with kdepim in the name are also the same in
> unstable and testing (haven't checked binary rebuilds). But if the
> package you are really referring to is the same in unstable and testing,
> it can't cause the regression. Is it the same? If so, than the
> regression isn't a bug there. If not, maybe we can investigate (by
> testing) and check if that needs its migration blocked or delayed.

There have been fixes in Qt for bugs that might have been used as features, 
it's not the first time this happens.

> > * If the bug is in kdepim then the best way to solve it would be to
> > psuh a
> > 
> >   new version, for which we need a transition.
> 
> And delay or prevent the version in unstable from migrating to testing?
> Depending on severity I guess.

Exactly, the severity of this bug is small enough to delay things further.

> > - No users have complained about this so far, and we do have lots of users
> > using unstable and reporting bugs. This has proven to be a nice regression
> > method so far ;-)
> 
> Of course.
> 
> > So I think the best way to go here is just let Qt migrate.
> 
> In 3 days that happens if we don't do anything. I'll let the RT judge if
> that is worth waiting for or if migration is more urgent.

Same here :-)


-- 
Geek Inside!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#905593: network-manager: /etc/...*.service files should be considered as configuration files

[Cyril Adrian]

Package: network-manager
Version: 1.12.2-1
Severity: important
Tags: newcomer

Follow-up of #905585.

It looks like I was not clear enough.

I am talking of /etc/systemd/system/network-online.target.wants/NetworkManager-
wait-online.service

This file is in /etc -- therefore unless I am mistaken it is in the
configuration directory and should not be carelessly overwritten.

Again, please consider making this file a configuration file so that I don't
have to fiddle with my conf every time the package is upgraded.



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

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

Versions of packages network-manager depends on:
ii  adduser3.117
ii  dbus   1.12.10-1
ii  libaudit1  1:2.8.3-1+b1
ii  libbluetooth3  5.50-1
ii  libc6  2.27-5
ii  libcurl3-gnutls7.60.0-2
ii  libglib2.0-0   2.56.1-2
ii  libgnutls303.5.19-1
ii  libjansson42.11-1
ii  libmm-glib01.7.990-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-5
ii  libnm0 1.12.2-1
ii  libpam-systemd 239-7
ii  libpolkit-agent-1-00.105-21
ii  libpolkit-gobject-1-0  0.105-21
ii  libpsl50.20.2-1
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0239-7
ii  libteamdctl0   1.27-1
ii  libudev1   239-7
ii  libuuid1   2.32-0.4
ii  lsb-base   9.20170808
ii  policykit-10.105-21
ii  udev   239-7
ii  wpasupplicant  2:2.6-17

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.79-1
ii  iptables 1.6.2-1
ii  isc-dhcp-client  4.3.5-4+b1
ii  modemmanager 1.7.990-1
ii  ppp  2.4.7-2+3

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#881835: mbr: diff for NMU version 1.1.11-5.2

[Niels Thykier]

Package: mbr
Version: 1.1.11-5.1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for mbr (versioned as 1.1.11-5.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

(Yes, it is missing a Closes; I will do that manually).

Regards.

diff -u mbr-1.1.11/debian/changelog mbr-1.1.11/debian/changelog
--- mbr-1.1.11/debian/changelog
+++ mbr-1.1.11/debian/changelog
@@ -1,3 +1,23 @@
+mbr (1.1.11-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Simon McVittie ]
+  * Only copy install-mbr to debian/mbr-udeb/sbin if we are going to
+build the mbr-udeb package, fixing FTBFS on non-x86 architectures.
+In recent debhelper versions, dh_installdirs does not create
+directories for binary packages that are not applicable to the
+current architecture.
+
+  [ Niels Thykier ]
+  * Set Rules-Requires-Root (R³) to no.
+  * Replace use of "Priority: extra" with "Priority: optional" as the
+former is now obsolete and replaced by the latter.
+  * Use Package-Type without the "XC-" prefix as it is no longer
+required.
+
+ -- Niels Thykier   Mon, 06 Aug 2018 18:53:12 +
+
 mbr (1.1.11-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u mbr-1.1.11/debian/control mbr-1.1.11/debian/control
--- mbr-1.1.11/debian/control
+++ mbr-1.1.11/debian/control
@@ -4,6 +4,7 @@
 Maintainer: Santiago Garcia Mantinan 
 Standards-Version: 3.9.3
 Build-Depends: debhelper(>= 7), bin86, util-linux (>= 2.13) | linux32, xxd
+Rules-Requires-Root: no
 
 Package: mbr
 Architecture: any
@@ -16,9 +17,8 @@
 Package: mbr-udeb
 Architecture: i386 amd64 lpia
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Priority: extra
 Section: debian-installer
-XC-Package-Type: udeb
+Package-Type: udeb
 XB-Installer-Menu-Item: 9
 Description: Master Boot Record for IBM-PC compatible computers
 
diff -u mbr-1.1.11/debian/rules mbr-1.1.11/debian/rules
--- mbr-1.1.11/debian/rules
+++ mbr-1.1.11/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+binaries := $(shell dh_listpackages)
+
 CC := gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
 
 CFLAGS := -g -Wall -W
@@ -38,7 +40,9 @@
dh_installdocs -p mbr debian/README-1st.Debian NEWS README AUTHORS
dh_installchangelogs
$(MAKE) install INSTALL_PROGRAM="$(INSTALL_PROGRAM)"
+ifneq ($(filter mbr-udeb,$(binaries)),)
cp `pwd`/debian/mbr/sbin/install-mbr `pwd`/debian/mbr-udeb/sbin/
+endif
 
 binary-indep: build
dh_testdir

Bug#904737: uwsgi: diff for NMU version 2.0.17.1-2.1

[gregor herrmann]

Control: tags 904737 + pending


Dear maintainer,

I've prepared an NMU for uwsgi (versioned as 2.0.17.1-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Supertramp: Try Again
diff -Nru uwsgi-2.0.17.1/debian/changelog uwsgi-2.0.17.1/debian/changelog
--- uwsgi-2.0.17.1/debian/changelog	2018-07-11 16:01:12.0 +0200
+++ uwsgi-2.0.17.1/debian/changelog	2018-08-06 21:23:33.0 +0200
@@ -1,3 +1,12 @@
+uwsgi (2.0.17.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS: unable to build gccgo plugin":
+change build dependency from gccgo-7 to gccgo-8.
+(Closes: #904737)
+
+ -- gregor herrmann   Mon, 06 Aug 2018 21:23:33 +0200
+
 uwsgi (2.0.17.1-2) unstable; urgency=medium
 
   * Fix revert broken parts of git commit af44874:
diff -Nru uwsgi-2.0.17.1/debian/control uwsgi-2.0.17.1/debian/control
--- uwsgi-2.0.17.1/debian/control	2018-07-11 15:37:06.0 +0200
+++ uwsgi-2.0.17.1/debian/control	2018-08-06 21:23:24.0 +0200
@@ -23,7 +23,7 @@
  apache2-dev | apache2-threaded-dev,
  cli-common-dev [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mipsel ppc64el s390x],
  dh-apache2 | apache2-dev,
- gccgo-7 [amd64 arm64 armel armhf hurd-i386 i386 mips mips64el mipsel ppc64el s390x],
+ gccgo-8 [amd64 arm64 armel armhf hurd-i386 i386 mips mips64el mipsel ppc64el s390x],
  glusterfs-common [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x],
  help2man,
  java-common,
diff -Nru uwsgi-2.0.17.1/debian/control.in uwsgi-2.0.17.1/debian/control.in
--- uwsgi-2.0.17.1/debian/control.in	2018-07-11 15:37:06.0 +0200
+++ uwsgi-2.0.17.1/debian/control.in	2018-08-06 21:23:25.0 +0200
@@ -12,7 +12,7 @@
  apache2-dev | apache2-threaded-dev,
  cli-common-dev [@mono_archs@],
  dh-apache2 | apache2-dev,
- gccgo-7 [@gccgo_archs@],
+ gccgo-8 [@gccgo_archs@],
  glusterfs-common [@glusterfs_archs@],
  help2man,
  java-common,
diff -Nru uwsgi-2.0.17.1/debian/rules uwsgi-2.0.17.1/debian/rules
--- uwsgi-2.0.17.1/debian/rules	2018-07-11 15:52:58.0 +0200
+++ uwsgi-2.0.17.1/debian/rules	2018-08-06 21:23:23.0 +0200
@@ -65,7 +65,7 @@
 $(shell sh debian/pkgarchs.sh openjdk-11-jdk > debian/ARCHS_openjdk11)
 $(shell sh debian/pkgarchs.sh libmono-2.0-dev | perl -pe 's/\bpowerpc\b//' > debian/ARCHS_mono)
 $(shell sh debian/pkgarchs.sh librados-dev > debian/ARCHS_rados)
-$(shell sh debian/pkgarchs.sh gccgo-7 > debian/ARCHS_gccgo)
+$(shell sh debian/pkgarchs.sh gccgo-8 > debian/ARCHS_gccgo)
 endif
 UWSGI_ARCHLISTS = glusterfs greenlet trollius openjdk11 \
 	mono rados gccgo


signature.asc
Description: Digital Signature

Bug#905116: [PATCH v2] scripts/kernel-doc: Escape all literal braces in regexes

[Jonathan Corbet]

On Sun, 5 Aug 2018 17:41:09 +0100
Ben Hutchings  wrote:

> Commit 720ac2ef479d ("PATCH scripts/kernel-doc") fixed the two
> instances of literal braces that Perl 5.28 warns about, but there are
> still more than it doesn't warn about.
> 
> Escape all left braces that are treated as literal characters.  Also
> escape literal right braces, for consistency and to avoid confusing
> bracket-matching in text editors.
> 
> Signed-off-by: Ben Hutchings 

Applied (with the commit hash corrected), thanks.

jon

Bug#905592: luajit FTCBFS: performs a native build and then fails dh_strip

[Helmut Grohne]

Source: luajit
Version: 2.1.0~beta3+dfsg-5.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

luajit fails to cross build from source, because it does a native build.
For cross builds one is supposed to pass $(CROSS) to make though that
also works for native builds. The attached patch implements that and
makes a cross build from amd64 to e.g. arm64 succeed. Please consider
applying it.

Helmut
diff --minimal -Nru luajit-2.1.0~beta3+dfsg/debian/changelog 
luajit-2.1.0~beta3+dfsg/debian/changelog
--- luajit-2.1.0~beta3+dfsg/debian/changelog2017-10-25 11:24:21.0 
+0200
+++ luajit-2.1.0~beta3+dfsg/debian/changelog2018-08-06 21:24:50.0 
+0200
@@ -1,3 +1,10 @@
+luajit (2.1.0~beta3+dfsg-5.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass toolchain prefix for the other tools. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 06 Aug 2018 21:24:50 +0200
+
 luajit (2.1.0~beta3+dfsg-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru luajit-2.1.0~beta3+dfsg/debian/rules 
luajit-2.1.0~beta3+dfsg/debian/rules
--- luajit-2.1.0~beta3+dfsg/debian/rules2017-10-11 10:48:09.0 
+0200
+++ luajit-2.1.0~beta3+dfsg/debian/rules2018-08-06 21:24:45.0 
+0200
@@ -12,7 +12,7 @@
dh $@
 
 override_dh_auto_build:
-   make amalg PREFIX=/usr CC=gcc MULTILIB=lib/$(DEB_HOST_MULTIARCH)
+   $(MAKE) amalg PREFIX=/usr MULTILIB=lib/$(DEB_HOST_MULTIARCH) 
CROSS=$(DEB_HOST_GNU_TYPE)-
 
 override_dh_auto_install:
make install PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmp/ 
MULTILIB=lib/$(DEB_HOST_MULTIARCH) LDCONFIG="/sbin/ldconfig -n"

Bug#905589: bind9 stops automatically 30 seconds after starting

[Ondřej Surý]

Control: severity -1 important

Marcel,

I can’t reproduce it, so it must be some local configuration that’s causing 
your bind to exit.

can you attach output of:

systemctl status bind9

and contents of

/etc/default/bind9

And perhaps full output of

journalctl —unit=bind9 -b

since the last:

systemd[1]: Starting BIND Domain Name Server...

entry?

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 6 Aug 2018, at 19:34, Marcel Veldhuizen  wrote:
> 
> Package: bind9
> Version: 1:9.11.4+dfsg-4
> Severity: grave
> Justification: renders package unusable
> 
> Dear maintainer,
> 
> Yesterday I upgraded 1:9.11.3+dfsg-2 to 1:9.11.4+dfsg-4, which appears
> to break something in the startup process of the service. Exactly 30 seconds
> after "service bind9 start" it is automatically shut down again.
> 
> For example, right after upgrading:
> 
> Aug 06 18:21:25 hellfire systemd[1]: Starting BIND Domain Name Server...
> Aug 06 18:21:25 hellfire systemd[1]: bind9.service: Control process exited, 
> code=exited status=1
> Aug 06 18:21:25 hellfire systemd[1]: bind9.service: Failed with result 
> 'exit-code'.
> Aug 06 18:21:25 hellfire systemd[1]: Failed to start BIND Domain Name Server.
> dpkg: error processing package bind9 (--configure):
> installed bind9 package post-installation script subprocess returned error 
> exit status 1
> 
> Nothing remarkable is logged; it appears to be a "normal" shutdown:
> 
> Aug  6 19:08:53 hellfire named[27030]: running
> Aug  6 19:08:54 hellfire named[27030]: managed-keys-zone: Key 19036 for zone 
> . acceptance timer complete: key now trusted
> Aug  6 19:08:54 hellfire named[27030]: managed-keys-zone: Key 20326 for zone 
> . acceptance timer complete: key now trusted
> Aug  6 19:08:54 hellfire named[27030]: resolver priming query complete
> Aug  6 19:10:23 hellfire named[27030]: shutting down
> Aug  6 19:10:23 hellfire named[27030]: stopping command channel on 
> 127.0.0.1#953
> Aug  6 19:10:23 hellfire named[27030]: stopping command channel on ::1#953
> Aug  6 19:10:23 hellfire named[27030]: no longer listening on ::#53
> Aug  6 19:10:23 hellfire named[27030]: no longer listening on 127.0.0.1#53
> Aug  6 19:10:23 hellfire named[27030]: no longer listening on 192.168.0.1#53
> Aug  6 19:10:23 hellfire named[27030]: exiting
> 
> I suspect it has something to do with this change:
> * Use systemd Type=forking to signal daemon init.
>  Thanks to Elie Roudninski (Closes: #900788)
> 
> I've tried reverting my config files to package defaults, but this makes
> no difference. Unfortunately I'm not sure what else I should check with
> regards to systemd configuration that might affect this, but I'd be
> happy to provide additional information.
> 
> 
> Regards,
> Marcel Veldhuizen
> 
> -- System Information:
> Debian Release: buster/sid
>  APT prefers testing
>  APT policy: (990, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.13.4 (SMP w/8 CPU cores)
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US 
> (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages bind9 depends on:
> ii  adduser3.117
> ii  bind9utils 1:9.11.4+dfsg-4
> ii  debconf [debconf-2.0]  1.5.69
> ii  dns-root-data  2018013001
> ii  libbind9-160   1:9.11.4+dfsg-4
> ii  libc6  2.27-5
> ii  libcap21:2.25-1.2
> ii  libcom-err21.44.3-1
> ii  libdns1102 1:9.11.4+dfsg-4
> ii  libfstrm0  0.3.0-1+b1
> ii  libgeoip1  1.6.12-1
> ii  libgssapi-krb5-2   1.16-2
> ii  libisc169  1:9.11.4+dfsg-4
> ii  libisccc1601:9.11.4+dfsg-4
> ii  libisccfg160   1:9.11.4+dfsg-4
> ii  libjson-c3 0.12.1-1.3
> ii  libk5crypto3   1.16-2
> ii  libkrb5-3  1.16-2
> ii  liblmdb0   0.9.22-1
> ii  liblwres1601:9.11.4+dfsg-4
> ii  libprotobuf-c1 1.2.1-2
> ii  libssl1.1  1.1.0h-4
> ii  libxml22.9.4+dfsg1-7+b1
> ii  lsb-base   9.20170808
> ii  net-tools  1.60+git20161116.90da8a0-3
> ii  netbase5.4
> ii  zlib1g 1:1.2.11.dfsg-1
> 
> bind9 recommends no packages.
> 
> Versions of packages bind9 suggests:
> pn  bind9-doc   
> pn  dnsutils
> pn  resolvconf  
> pn  ufw 
> 
> -- Configuration Files:
> /etc/bind/db.root changed [not included]
> 
> -- debconf information:
>  bind9/different-configuration-file:
>  bind9/run-resolvconf: false
>  bind9/start-as-user: bind
> 

Bug#905591: [pavucontrol] windows position is not save

[Fernando Toledo]

Package: pavucontrol
Version: 3.0-3.1
Severity: minor

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

I use xfce4, and launch pavucontrol from mixer/audio panel icon.

the popup window are small, and i resize it, and close, but this
geometry are not saved. It will start again at small size.

I found that i can launch pavucontrol with -t o -m to select tab or
start maximized. Maybe you can add aditional modifier like -g to set the
initial window size.

thanks!



--- System information. ---
Architecture: Kernel:   Linux 4.9.0-7-rt-amd64

Debian Release: 9.5
  500 unstablerepo.huayra.conectarigualdad.gob.ar   500 stable
   security.debian.org   500 stable  repo.skype.com   500
stable  repo.huayra.conectarigualdad.gob.ar   500 stable
 linux.teamviewer.com   500 stable  dl.google.com   500 stable
   deb.debian.org   500 sid linux.dropbox.com   500
preview linux.teamviewer.com   100 stretch-backports ftp.debian.org
--- Package information. ---
Depends   (Version) | Installed
===-+-
libatk1.0-0 (>= 1.12.4) | 2.22.0-1
libatkmm-1.6-1v5(>= 2.24.0) | 2.24.2-2
libc6 (>= 2.14) | libcairo-gobject2
(>= 1.10.0) | libcairo2(>= 1.2.4) |
libcairomm-1.0-1v5  (>= 1.12.0) | libcanberra-gtk3-0
(>= 0.25) | libcanberra0  (>= 0.16) | libgcc1
  (>= 1:3.0) | libgdk-pixbuf2.0-0  (>= 2.22.0) |
libglib2.0-0(>= 2.16.0) | libglibmm-2.4-1v5
(>= 2.50.0) | libgtk-3-0   (>= 3.0.0) | libgtkmm-3.0-1v5
   (>= 3.22.0) | libpango-1.0-0  (>= 1.14.0) |
libpangocairo-1.0-0 (>= 1.14.0) | libpangomm-1.4-1v5
(>= 2.40.0) | libpulse-mainloop-glib0 (>= 0.99.1) | libpulse0
  (>= 4.0) | libsigc++-2.0-0v5(>= 2.2.0) |
libstdc++6 (>= 5.2) | libx11-6
 |

Recommends  (Version) | Installed
=-+-===
pulseaudio| 10.0-1+deb9u1


Package's Suggests field is empty.
-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#905590: logrotate FTBFS: automake-1.15 not found

[Helmut Grohne]

Source: logrotate
Version: 3.11.0-0.2
Severity: serious
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

logrotate fails to build from source in unstable on amd64. A build ends
as follows:

|debian/rules override_dh_auto_build
| make[1]: Entering directory '/<>'
| /usr/bin/make RPM_OPT_FLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" WITH_SELINUX="yes" 
WITH_ACL="yes" 
| make[2]: Entering directory '/<>'
| CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /<>/missing 
aclocal-1.15 
| /<>/missing: line 81: aclocal-1.15: command not found
| WARNING: 'aclocal-1.15' is missing on your system.
|  You should only need it if you modified 'acinclude.m4' or
|  'configure.ac' or m4 files included by 'configure.ac'.
|  The 'aclocal' program is part of the GNU Automake package:
|  
|  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
|  
|  
|  
| make[2]: *** [Makefile:407: aclocal.m4] Error 127
| make[2]: Leaving directory '/<>'
| make[1]: *** [debian/rules:29: override_dh_auto_build] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:25: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The automake package now builds from automake-1.16 and no longer
provides automake-1.15. autoreconfing fixes the problem. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru logrotate-3.11.0/debian/changelog 
logrotate-3.11.0/debian/changelog
--- logrotate-3.11.0/debian/changelog   2017-01-07 19:54:50.0 +0100
+++ logrotate-3.11.0/debian/changelog   2018-08-06 20:54:00.0 +0200
@@ -1,3 +1,10 @@
+logrotate (3.11.0-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS: autoreconf. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 06 Aug 2018 20:54:00 +0200
+
 logrotate (3.11.0-0.1) unstable; urgency=low
 
   * Non-maintainer upload
diff --minimal -Nru logrotate-3.11.0/debian/control 
logrotate-3.11.0/debian/control
--- logrotate-3.11.0/debian/control 2017-01-04 21:46:16.0 +0100
+++ logrotate-3.11.0/debian/control 2018-08-06 20:53:56.0 +0200
@@ -2,7 +2,7 @@
 Section: admin
 Priority: important
 Maintainer: Paul Martin 
-Build-Depends: libpopt-dev, debhelper (>= 9),
+Build-Depends: libpopt-dev, debhelper (>= 9), dh-autoreconf,
  libselinux1-dev [linux-any], libacl1-dev [linux-any], automake
 Vcs-Svn: http://svn.fedorahosted.org/svn/logrotate/
 Homepage: https://github.com/logrotate/logrotate
diff --minimal -Nru logrotate-3.11.0/debian/rules logrotate-3.11.0/debian/rules
--- logrotate-3.11.0/debian/rules   2016-12-29 20:11:56.0 +0100
+++ logrotate-3.11.0/debian/rules   2018-08-06 20:53:48.0 +0200
@@ -22,7 +22,7 @@
 
 
 %:
-   dh $@
+   dh $@ --with=autoreconf
 
 override_dh_auto_build:
 ifeq ($(DEB_HOST_ARCH_OS),linux)

Bug#897724: collectd: diff for NMU version 5.8.0-5.2

[gregor herrmann]

Control: tags 897724 + patch
Control: tags 897724 + pending


Dear maintainer,

I've prepared an NMU for collectd (versioned as 5.8.0-5.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Peter Jones: Long way to go
diff -Nru collectd-5.8.0/debian/changelog collectd-5.8.0/debian/changelog
--- collectd-5.8.0/debian/changelog	2018-06-29 19:42:43.0 +0200
+++ collectd-5.8.0/debian/changelog	2018-08-06 20:43:05.0 +0200
@@ -1,3 +1,13 @@
+collectd (5.8.0-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "ftbfs with GCC-8":
+debian/rules: build with -Wno-error=format-truncation as a temporary
+workaround for the build failure with gcc-8 caused by a compiler warning.
+(Closes: #897724)
+
+ -- gregor herrmann   Mon, 06 Aug 2018 20:43:05 +0200
+
 collectd (5.8.0-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru collectd-5.8.0/debian/rules collectd-5.8.0/debian/rules
--- collectd-5.8.0/debian/rules	2018-06-18 19:05:12.0 +0200
+++ collectd-5.8.0/debian/rules	2018-08-06 20:36:32.0 +0200
@@ -18,6 +18,8 @@
 CPPFLAGS += -I$(CURDIR)/debian/include
 CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
 CFLAGS += -Wall -Wno-error=deprecated-declarations
+# 897724
+CFLAGS += -Wno-error=format-truncation
 
 # Upstream defaults to ${sysconfdir}/collectd.conf. Setting ${sysconfdir} to
 # /etc/collectd would be wrong though.


signature.asc
Description: Digital Signature

Bug#905340: stretch-pu: package linux/4.9.110-3

[Salvatore Bonaccorso]

Hi,

On Fri, Aug 03, 2018 at 07:50:07PM +0800, Ben Hutchings wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Please copy linux version 4.9.110-3 to the stretch-updates suite.
> It fixes several serious regressions in the latest point release.

The linux update for DSA-4266-1 was based on 4.9.110-3 so there is no
need anymore to schedule the fixes via stretch-updates.

Closing #905340!

Regards,
Salvatore

Bug#902263: Affecting Qt transition

[Paul Gevers]

Dear all,

To be sure, I don't want to block/delay anything here, I just want
autopkgtests to be taken seriously. If you as the maintainer of
ktexteditor say please ignore my test for migration, who am I to say
you're wrong. However, you have also added that test for a reason.

On 06-08-18 15:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> I used i, d, v, y, shift+p. I even retried them just now in case I missed 
> something.

What does idvyP (insert mode; add characters d v y P) have to do with
the failing test case? Lot's of vim code seems to go all right, there is
only 1 regression.

> I might be missing something, but at this point:
> 
> - If there is a regression:
> 
> * it would be small and can be worked around by using the normal editing
>   mode.

As long as this is the only thing, I agree with you, but if you don't
know what's wrong you don't actually know. (Albeit the amount of passing
tests says something, but once you let this one into testing, the whole
autopkgtest of ktexteditor becomes worthless until this issue is fixed
somehow).

> * odds are highly on the bug-on-kdepim side, as Qt 5.11.1 is just a patch
>   release of 5.11.0 which has been shipped in other distros for months
>   already (we skip even releases due to the fact that we need to do
>   transitions).

I don't know which package you exactly mean with kdepim as that is a
meta-package that is the same in unstable and testing since 2018-06-10.
All source packages with kdepim in the name are also the same in
unstable and testing (haven't checked binary rebuilds). But if the
package you are really referring to is the same in unstable and testing,
it can't cause the regression. Is it the same? If so, than the
regression isn't a bug there. If not, maybe we can investigate (by
testing) and check if that needs its migration blocked or delayed.

> * If the bug is in kdepim then the best way to solve it would be to psuh a
>   new version, for which we need a transition.

And delay or prevent the version in unstable from migrating to testing?
Depending on severity I guess.

> - No users have complained about this so far, and we do have lots of users 
> using unstable and reporting bugs. This has proven to be a nice regression 
> method so far ;-)

Of course.

> So I think the best way to go here is just let Qt migrate.

In 3 days that happens if we don't do anything. I'll let the RT judge if
that is worth waiting for or if migration is more urgent.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#648033: iputils crosscompilation - upstream

[Niels Thykier]

On Wed, 2 Aug 2017 07:13:34 -0700 Noah Meyerhans  wrote:
> On Wed, Aug 02, 2017 at 03:35:37PM +0200, David Heidelberg wrote:
> > Instead of keeping with Makefile, where I don't plan any new functionality,
> > would you be interested in extending/improving meson build system support?
> > It's right way, it's not going anywhere and it simplified iputils build.
> 
> Yay, another build system! :/
> 
> Not thrilled about it at all, honestly, but it's your decision.
> 
> 
> 

Hi Noah,

In the mean time, debhelper has gain native support for the meson build
system (including support for cross building with meson).  Most likely,
what you will need is:

  # instead of ./configure [--with-foo]
  dh_auto_configure --buildsystem=meson [-- --with-foo]
  # instead of $(MAKE)
  dh_auto_build --buildsystem=meson
  # instead of $(MAKE) test/check
  dh_auto_test --buildsystem=meson
  # instead of $(MAKE) install
  dh_auto_install --buildsystem=meson


Plus a Build-Depends: meson, ninja, debhelper (>= 10.3~)

Thanks,
~Niels

Bug#904886: lintian: Support "debhelper-compat (= X)" B-D as replacement for "debhelper (>= X~)"

[Niels Thykier]

Chris Lamb:
> tags 904886 + pending
> thanks
> 
> Fixed in Git, pending upload:
> 
>   
> https://salsa.debian.org/lintian/lintian/commit/f61be381930e8087b2d00cf85687b51eecc7d5ec
> 
>   checks/debhelper.desc  | 34 
> --
>   checks/debhelper.pm| 31 
>   debian/changelog   |  3 ++
>   .../debian/debian/control.in   | 16 ++
>   .../desc   |  7 +
>   .../pre_build  |  5 
>   .../tags   |  1 +
>   .../debian/debian/control.in   | 16 ++
>   .../debhelper-compat-virtual-relation-both/desc|  7 +
>   .../pre_build  |  5 
>   .../debhelper-compat-virtual-relation-both/tags|  0
>   .../debian/debian/control.in   | 16 ++
>   t/tests/debhelper-compat-virtual-relation/desc | 12 
>   .../debhelper-compat-virtual-relation/pre_build|  5 
>   t/tests/debhelper-compat-virtual-relation/tags |  2 ++
>   15 files changed, 151 insertions(+), 9 deletions(-)
> 
> 
> Regards,
> 

Thanks for implementing this. :)


debhelper-and-debhelper-compat-virtual-relation-with-unsupported-version
might be better worded as
"debhelper-build-dependency-implied-by-debhelper-compat-relation" and E
might too high for this.  There is not much harm in having the redundant
build-dependency.

On a related note, the text for that tag saying  "However, this requires
a debhelper 11.3.6 or later." is incorrect.  Having debhelper-compat (=
X) implies debhelper (>= 11.3.6~) - i.e. you can rely on any feature in
debhelper up and including version 11.3.6~ without an explicit versioned
relation on debhelper (but I am fine with lintian not keeping track of
that).

Thanks,
~Niels

Bug#905589: bind9 stops automatically 30 seconds after starting

[Marcel Veldhuizen]

Package: bind9
Version: 1:9.11.4+dfsg-4
Severity: grave
Justification: renders package unusable

Dear maintainer,

Yesterday I upgraded 1:9.11.3+dfsg-2 to 1:9.11.4+dfsg-4, which appears
to break something in the startup process of the service. Exactly 30 seconds
after "service bind9 start" it is automatically shut down again.

For example, right after upgrading:

Aug 06 18:21:25 hellfire systemd[1]: Starting BIND Domain Name Server...
Aug 06 18:21:25 hellfire systemd[1]: bind9.service: Control process exited, 
code=exited status=1
Aug 06 18:21:25 hellfire systemd[1]: bind9.service: Failed with result 
'exit-code'.
Aug 06 18:21:25 hellfire systemd[1]: Failed to start BIND Domain Name Server.
dpkg: error processing package bind9 (--configure):
 installed bind9 package post-installation script subprocess returned error 
exit status 1

Nothing remarkable is logged; it appears to be a "normal" shutdown:

Aug  6 19:08:53 hellfire named[27030]: running
Aug  6 19:08:54 hellfire named[27030]: managed-keys-zone: Key 19036 for zone . 
acceptance timer complete: key now trusted
Aug  6 19:08:54 hellfire named[27030]: managed-keys-zone: Key 20326 for zone . 
acceptance timer complete: key now trusted
Aug  6 19:08:54 hellfire named[27030]: resolver priming query complete
Aug  6 19:10:23 hellfire named[27030]: shutting down
Aug  6 19:10:23 hellfire named[27030]: stopping command channel on 127.0.0.1#953
Aug  6 19:10:23 hellfire named[27030]: stopping command channel on ::1#953
Aug  6 19:10:23 hellfire named[27030]: no longer listening on ::#53
Aug  6 19:10:23 hellfire named[27030]: no longer listening on 127.0.0.1#53
Aug  6 19:10:23 hellfire named[27030]: no longer listening on 192.168.0.1#53
Aug  6 19:10:23 hellfire named[27030]: exiting

I suspect it has something to do with this change:
* Use systemd Type=forking to signal daemon init.
  Thanks to Elie Roudninski (Closes: #900788)

I've tried reverting my config files to package defaults, but this makes
no difference. Unfortunately I'm not sure what else I should check with
regards to systemd configuration that might affect this, but I'd be
happy to provide additional information.


Regards,
Marcel Veldhuizen

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

Kernel: Linux 4.13.4 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bind9 depends on:
ii  adduser3.117
ii  bind9utils 1:9.11.4+dfsg-4
ii  debconf [debconf-2.0]  1.5.69
ii  dns-root-data  2018013001
ii  libbind9-160   1:9.11.4+dfsg-4
ii  libc6  2.27-5
ii  libcap21:2.25-1.2
ii  libcom-err21.44.3-1
ii  libdns1102 1:9.11.4+dfsg-4
ii  libfstrm0  0.3.0-1+b1
ii  libgeoip1  1.6.12-1
ii  libgssapi-krb5-2   1.16-2
ii  libisc169  1:9.11.4+dfsg-4
ii  libisccc1601:9.11.4+dfsg-4
ii  libisccfg160   1:9.11.4+dfsg-4
ii  libjson-c3 0.12.1-1.3
ii  libk5crypto3   1.16-2
ii  libkrb5-3  1.16-2
ii  liblmdb0   0.9.22-1
ii  liblwres1601:9.11.4+dfsg-4
ii  libprotobuf-c1 1.2.1-2
ii  libssl1.1  1.1.0h-4
ii  libxml22.9.4+dfsg1-7+b1
ii  lsb-base   9.20170808
ii  net-tools  1.60+git20161116.90da8a0-3
ii  netbase5.4
ii  zlib1g 1:1.2.11.dfsg-1

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc   
pn  dnsutils
pn  resolvconf  
pn  ufw 

-- Configuration Files:
/etc/bind/db.root changed [not included]

-- debconf information:
  bind9/different-configuration-file:
  bind9/run-resolvconf: false
  bind9/start-as-user: bind

Bug#905588: mitmproxy: Incorrect options documented in man page

[Kevin Locke]

Package: mitmproxy
Version: 4.0.4-1
Severity: normal

Dear Maintainer,

It appears that the command line options have changed since the
mitmproxy manual page was created and some options no longer match the
documentation in mitmproxy.1  For example:

-R aliases --replacements instead of --reverse
--reverse is now --mode reverse:
--read-flows has been renamed --rfile
-t is no longer supported
-u is no longer supported

And a whole lot more.

Thanks,
Kevin


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

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

Versions of packages mitmproxy depends on:
ii  dpkg  1.19.0.5+b1
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-1
ii  python3   3.6.5-3
ii  python3-blinker   1.4+dfsg1-0.1
ii  python3-brotli1.0.5-2
ii  python3-certifi   2018.4.16-1
ii  python3-click 6.7-5
ii  python3-cryptography  2.3-1
ii  python3-h23.0.1-4
ii  python3-hyperframe5.1.0-1
ii  python3-kaitaistruct  0.8-1
ii  python3-ldap3 2.4.1-1
ii  python3-openssl   18.0.0-1
ii  python3-passlib   1.7.1-1
ii  python3-pyasn10.4.2-3
ii  python3-pyparsing 2.2.0+dfsg1-2
ii  python3-pyperclip 1.6.0-2
ii  python3-ruamel.yaml   0.15.34-1+b1
ii  python3-sortedcontainers  2.0.4-1
ii  python3-tornado   5.0.2-1+b1
ii  python3-urwid 2.0.1-2+b1
ii  python3-wsproto   0.11.0-2

mitmproxy recommends no packages.

mitmproxy suggests no packages.

-- no debconf information

Bug#868346: python-pocketsphinx: Python doesn't recognize that a version of pocketsphinx is installed

[Samuel Thibault]

Hello,

Paul Gevers, le lun. 06 août 2018 19:37:58 +0200, a ecrit:
> On Wed, 1 Aug 2018 23:47:44 +0200 Samuel Thibault 
> wrote:
> > > I think that this is related to not having a, for example, 
> > > pocketsphinx-0.8.egg_info/ directory with a PKG-INFO file
> > > and other related informational files. However, I'm not entirely sure.
> > 
> > Probably something like that, yes.  Upstream however doesn't use
> > setuptools any more, and doesn't distribute eggs any more. I have
> > reported the issue upstream
> 
> Upstream reported it doesn't know what needs to be done. Maybe we should
> ask for help at one of the python teams?

Probably, yes.

Samuel

Bug#905029: xtrs: FTBFS with gcc-8

[Reiner Herrmann]

Control: tags -1 + patch
Control: forwarded -1 https://github.com/TimothyPMann/xtrs/pull/25

The attached patch fixes the warning and allows building it
successfully.

Kind regards,
   Reiner
From e76e83104e4dc8d71c9ab3adcfd9aa512dbc7fd0 Mon Sep 17 00:00:00 2001
From: Reiner Herrmann 
Date: Mon, 6 Aug 2018 19:38:50 +0200
Subject: [PATCH] Use snprintf for string padding

Recent gcc versions emit new warnings about string truncation:

cmddump.c:78:7: error: 'strncat' output truncated copying between 0 and 8 bytes from a string of length 8 [-Werror=stringop-truncation]
   strncat(pdsbuf, "", 8 - strlen(pdsbuf));
   ^~~

This can be prevented by using snprintf for string padding.

Bug-Debian: https://bugs.debian.org/905029
---
 cmddump.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/cmddump.c b/cmddump.c
index 174e72a..1b07bd8 100644
--- a/cmddump.c
+++ b/cmddump.c
@@ -76,9 +76,7 @@ main(int argc, char* argv[])
   isam = strtol(optarg, NULL, 0);
   break;
 case 'p':
-  strncpy(pdsbuf, optarg, 8);
-  pdsbuf[8] = '\000';
-  strncat(pdsbuf, "", 8 - strlen(pdsbuf));
+  snprintf(pdsbuf, sizeof(pdsbuf), "%s%8s", optarg, "");
   pds = pdsbuf;
   break;
 case 'x':
-- 
2.18.0



signature.asc
Description: PGP signature

Bug#893661: gthumb: 3.6.1 do not solve completely memory leakages issues

[luca]

Package: gthumb
Version: 3:3.6.1-1~bpo9+1
Followup-For: Bug #893661

Dear Maintainer,

I have 3.6.1 strecth-backports versionsa. Viewing photos is fine, memory grows
but remain stable (nearly 500Mb).

However it just keep growning if I use the editing mode like "automatic
contrast adjustment" and "rotate". From 500 Mb it grows till all my 8 Gb RAM
are occupied and the computer freezes.

3 images of the growing RAM at

https://framapic.org/gallery#QBIeDre7TwPd/lSvbbGcCRI89.png,wASqo9ngppES/vdvI9IjcvrsQ.png,hDsAq6I2hCvG/iQCMxqx4omOW.png

Thanks
Luca



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

Kernel: Linux 4.9.0-7-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 gthumb depends on:
ii  gsettings-desktop-schemas   3.22.0-1
ii  gthumb-data 3:3.6.1-1~bpo9+1
ii  libatk1.0-0 2.22.0-1
ii  libbrasero-media3-1 3.12.1-4
ii  libc6   2.24-11+deb9u3
ii  libcairo-gobject2   1.14.8-1
ii  libcairo2   1.14.8-1
ii  libclutter-1.0-01.26.0+dfsg-3
ii  libclutter-gtk-1.0-01.8.2-2
ii  libcogl-pango20 1.22.2-2
ii  libcogl-path20  1.22.2-2
ii  libcogl20   1.22.2-2
ii  libdrm2 2.4.74-1
ii  libegl1-mesa [libegl1-x11]  13.0.6-1+b2
ii  libexiv2-14 0.25-3.1+deb9u1
ii  libgbm1 13.0.6-1+b2
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libgl1-mesa-dri 13.0.6-1+b2
ii  libglib2.0-02.50.3-2
ii  libgstreamer-plugins-base1.0-0  1.10.4-1
ii  libgstreamer1.0-0   1.10.4-1
ii  libgtk-3-0  3.22.11-1
ii  libjavascriptcoregtk-4.0-18 2.18.6-1~deb9u1.0
ii  libjpeg62-turbo 1:1.5.1-2
ii  libjson-glib-1.0-0  1.2.6-1
ii  liblcms2-2  2.8-4
ii  libpango-1.0-0  1.40.5-1
ii  libpangocairo-1.0-0 1.40.5-1
ii  libpng16-16 1.6.28-1
ii  libraw150.17.2-6+deb9u1
ii  librsvg2-2  2.40.16-1+b1
ii  libsecret-1-0   0.18.5-3.1
ii  libsoup2.4-12.56.0-2+deb9u2
ii  libstdc++6  6.3.0-18+deb9u1
ii  libtiff54.0.8-2+deb9u2
ii  libwayland-client0  1.12.0-1
ii  libwayland-cursor0  1.12.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  13.0.6-1+b2
ii  libwayland-server0  1.12.0-1
ii  libwebkit2gtk-4.0-372.18.6-1~deb9u1.0
ii  libwebp60.5.2-1
ii  libx11-62:1.6.4-3
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-2+b3
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-1
ii  libxi6  2:1.7.9-1
ii  libxkbcommon0   0.7.1-2~deb9u1
ii  libxrandr2  2:1.5.1-1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages gthumb recommends:
ii  libgphoto2-6   2.5.12-1
ii  libgphoto2-port12  2.5.12-1

gthumb suggests no packages.

-- no debconf information

Bug#905587: mitmproxy: Fails to start due to missing python3-h11 dependency

[Kevin Locke]

Package: mitmproxy
Version: 4.0.4-1
Severity: normal

Dear Maintainer,

mitmproxy 4.0.4-1 dropped the dependency on python3-h11.  If python3-h11
is not installed, mitmproxy fails to start with the following output:

Traceback (most recent call last):
  File "/usr/bin/mitmproxy", line 11, in 
load_entry_point('mitmproxy==4.0.4', 'console_scripts', 'mitmproxy')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 476, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2700, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2318, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2324, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/main.py", line 22, in 

from ._main import *  # noqa
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/_main.py", line 13, in 

from mitmproxy.tools import cmdline  # noqa
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/cmdline.py", line 3, in 

from mitmproxy.addons import core
  File "/usr/lib/python3/dist-packages/mitmproxy/addons/__init__.py", line 11, 
in 
from mitmproxy.addons import onboarding
  File "/usr/lib/python3/dist-packages/mitmproxy/addons/onboarding.py", line 2, 
in 
from mitmproxy.addons.onboardingapp import app
  File "/usr/lib/python3/dist-packages/mitmproxy/addons/onboardingapp/app.py", 
line 8, in 
from mitmproxy.proxy import config
  File "/usr/lib/python3/dist-packages/mitmproxy/proxy/__init__.py", line 2, in 

from .root_context import RootContext
  File "/usr/lib/python3/dist-packages/mitmproxy/proxy/root_context.py", line 
4, in 
from mitmproxy.proxy import protocol
  File "/usr/lib/python3/dist-packages/mitmproxy/proxy/protocol/__init__.py", 
line 33, in 
from .http import UpstreamConnectLayer
  File "/usr/lib/python3/dist-packages/mitmproxy/proxy/protocol/http.py", line 
10, in 
from mitmproxy.proxy.protocol.websocket import WebSocketLayer
  File "/usr/lib/python3/dist-packages/mitmproxy/proxy/protocol/websocket.py", 
line 8, in 
from wsproto.connection import ConnectionType, WSConnection
  File "/usr/lib/python3/dist-packages/wsproto/connection.py", line 16, in 

import h11
ModuleNotFoundError: No module named 'h11'

Thanks,
Kevin


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

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

Versions of packages mitmproxy depends on:
ii  dpkg  1.19.0.5+b1
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-1
ii  python3   3.6.5-3
ii  python3-blinker   1.4+dfsg1-0.1
ii  python3-brotli1.0.5-2
ii  python3-certifi   2018.4.16-1
ii  python3-click 6.7-5
ii  python3-cryptography  2.3-1
ii  python3-h23.0.1-4
ii  python3-hyperframe5.1.0-1
ii  python3-kaitaistruct  0.8-1
ii  python3-ldap3 2.4.1-1
ii  python3-openssl   18.0.0-1
ii  python3-passlib   1.7.1-1
ii  python3-pyasn10.4.2-3
ii  python3-pyparsing 2.2.0+dfsg1-2
ii  python3-pyperclip 1.6.0-2
ii  python3-ruamel.yaml   0.15.34-1+b1
ii  python3-sortedcontainers  2.0.4-1
ii  python3-tornado   5.0.2-1+b1
ii  python3-urwid 2.0.1-2+b1
ii  python3-wsproto   0.11.0-2

mitmproxy recommends no packages.

mitmproxy suggests no packages.

-- no debconf information

Bug#868346: python-pocketsphinx: Python doesn't recognize that a version of pocketsphinx is installed

[Paul Gevers]

Control: tags -1 help

Hi,

On Wed, 1 Aug 2018 23:47:44 +0200 Samuel Thibault 
wrote:
> > I think that this is related to not having a, for example, 
> > pocketsphinx-0.8.egg_info/ directory with a PKG-INFO file
> > and other related informational files. However, I'm not entirely sure.
> 
> Probably something like that, yes.  Upstream however doesn't use
> setuptools any more, and doesn't distribute eggs any more. I have
> reported the issue upstream

Upstream reported it doesn't know what needs to be done. Maybe we should
ask for help at one of the python teams?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905586: lxc: CVE-2018-6556: lxc-user-nic allows unprivileged users to open arbitrary files

[Salvatore Bonaccorso]

Source: lxc
Version: 1:2.0.9-1
Severity: grave
Tags: patch security upstream
Forwarded: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591

Hi,

The following vulnerability was published for lxc.

CVE-2018-6556[0]:
lxc-user-nic allows unprivileged users to open arbitrary files

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-2018-6556
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6556
[1] https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591
[2] 
https://lists.linuxcontainers.org/pipermail/lxc-devel/2018-August/018336.html

Regards,
Salvatore

Bug#905584: xtrs: new upstream release

[Reiner Herrmann]

Source: xtrs
Version: 4.9c-4
Severity: wishlist

Dear maintainer,

a new upstream version of xtrs is available (4.9d).
Please also set the homepage field to:
 http://www.tim-mann.org/xtrs.html

And the development is now happening on Github:
 https://github.com/TimothyPMann/xtrs

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#905585: network-manager: *.service files should be considered as configuration files

[Cyril Adrian]

Package: network-manager
Version: 1.12.2-1
Severity: important
Tags: newcomer

I modified the "NetworkManager-wait-online.service" file to fix the timeout
(30s is way too long).
The file is reverted at each package upgrade.

I think it should be considered as a configuration file. I know some Debian
packages do that, so that the package manager ASKS when it wants to revert a
file. Please consider doing so here.

Thanks



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

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

Versions of packages network-manager depends on:
ii  adduser3.117
ii  dbus   1.12.10-1
ii  libaudit1  1:2.8.3-1+b1
ii  libbluetooth3  5.50-1
ii  libc6  2.27-5
ii  libcurl3-gnutls7.60.0-2
ii  libglib2.0-0   2.56.1-2
ii  libgnutls303.5.19-1
ii  libjansson42.11-1
ii  libmm-glib01.7.990-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-5
ii  libnm0 1.12.2-1
ii  libpam-systemd 239-7
ii  libpolkit-agent-1-00.105-21
ii  libpolkit-gobject-1-0  0.105-21
ii  libpsl50.20.2-1
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0239-7
ii  libteamdctl0   1.27-1
ii  libudev1   239-7
ii  libuuid1   2.32-0.4
ii  lsb-base   9.20170808
ii  policykit-10.105-21
ii  udev   239-7
ii  wpasupplicant  2:2.6-17

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.79-1
ii  iptables 1.6.2-1
ii  isc-dhcp-client  4.3.5-4+b1
ii  modemmanager 1.7.990-1
ii  ppp  2.4.7-2+3

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#872278: setResponseTimeout Nothing has silently changed behavior with http-client 0.5.0

[Joey Hess]

Could this please get fixed? Is there some problem with the patch I
provided almost a year ago?

This is affecting git-annex: 
http://git-annex.branchable.com/bugs/could_webdav_be_more_resilient_to_timeouts__63__/

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#905408: libreoffice-writer: Confirming missing radio buttons and checkbox

[Rene Engelhard]

On Mon, Aug 06, 2018 at 08:47:27AM +0100, Henry Bremridge wrote:
[ missing text ... yes, I knw ot's in the subject but ...]
> As an example: format | paragraph | Alignment
> 
> There are no check boxes to select left justify right etc

And https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904598

> This is common.

I know, see above..

Let's see what upstream replies to my mail to the upstream mailing list.

Regards,

Rene

Bug#905583: ITP: golang-github-cavaliercoder-grab -- download manager package for Go

[Aron Xu]

Package: wnpp
Severity: wishlist

* Package name: golang-github-cavaliercoder-grab
  Version : 2.0.0
  Upstream Author : Ryan Armstrong 
* URL : https://github.com/cavaliercoder/grab
* License : BSD-3-clause
  Programming Lang: Go
  Description : download manager package for Go

Bug#905574: linux-image-4.17.0-0.bpo.1-amd64: cryptsetup missing in intitramfs for kernel 4.17

[Ian Campbell]

On Mon, 2018-08-06 at 23:47 +0800, Ben Hutchings wrote:
> On Mon, 2018-08-06 at 14:40 +0100, Ian Campbell wrote:
> > On Mon, 2018-08-06 at 21:15 +0800, Ben Hutchings wrote:
> > > > Inspecting the initramfs shows that the cryptsetup related
> > > > parts are
> > > > missing for 4.17, but still in the 4.16 kernel.
> > > > 
> > > > I was able to mitigate the issue by use the cryptsetup packages
> > > > from
> > > > buster.
> > > 
> > > This is strange.  Kernel packages do not determine what goes into
> > > the
> > > initramfs.
> > 
> > Possibly the cryptsetup package changed (and become broken). Then
> > the
> > 4.17 initramfs was (re)built (due to the install/upgrade of that
> > kernel) while the 4.16 initramfs wasn't rebuilt.
> 
> In stable?  (There's no backport of cryptsetup.)

Ah, sorry, I didn't read close enough and somehow thought this was in
unstable.

For stable/bpo s/the cryptsetup package/some package/.

> > I expected that there were be triggers in place which should have
> > caused the 4.16 initramfs (in fact, all initramfses) to be updated
> > if a
> > relevant package (e.g. cryptsetup) was changed, but perhaps that
> > was
> > more in hope than expectation and it's only an initramfs-tools
> > update
> > which would trigger that?
> 
> Installing or upgrading cryptsetup will trigger an update of the newest
> installed kernel version's initramfs.

Thanks, that would potentially explain why 4.16 continues to work (it
has an older working initramfs).

Ian.

Bug#905392: openvpn: systemd generator ignores overrides in /etc/systemd/system

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hallo Bernhard,
hello Gerben,


Am Montag, den 06.08.2018, 14:16 +0200 schrieb Bernhard Schmidt:
> On 04.08.2018 15:28, Jörg Frings-Fürst wrote:
> 
> Hi Jörg, hi Gerben,
> 
> > tags 905392 + pending
> > thanks
> > 
> > 
> > Hello Gerben,
> > 
> > thank you for spending your time helping to make Debian better with
> > this bug report. 
> > 
> > I have changed the script to test if a service file exist at
> > /etc/systemd/system.
> 
> Are you both sure this is necessary?
> 

Yes, I think so. 

On[1] is /etc/systemd/... the directory for customized files.

So it is good to use this directory too.


> To my knowledge the symlink tells systemd to start openvpn@.service
> with
> the service definition in memory. It does not tell it to start
> openvpn@.service with the service definition in the file returned by
> readlink(). AFAIK, unless it's /dev/null, the target of the symlink
> is
> irrelevant.
> 
> Bernhard
> 

CU
Jörg

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-Managing_Services_with_systemd-Unit_Files#sect-Managing_Services_with_systemd-Unit_File_Modify
- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAltodIsACgkQCfifPIyh
0l0ScA//ZNKOCSLeRK01qM/yAUsF3PxF8KLSAB5xyfP0zeMrRYETSc3NmJLnsJq5
e+9L7Mcs7RRDdLUCIad1vvaWvgF3RcBUY3TGfGSTA6gR2DUMPDeRXWRY3MBP0gbk
rwTDhpPlM3gkIUGgIiuRCYKAIHD9/R0dhmrsaWqECLQlY9tUyyvB8k6qGNbYnpa2
SpSLhVjlia7rdYc+8//t9olJQmd3wNTlHAGqTI2qY/LYskPqDT7weBWXVnGJy1tK
ftXhoiBdCzL4DKmNTPDJ4AGcKmsTHz9rFR/us5WAq4raREM0NdkSwhd5oJYRdzP4
IEXlX7fMrJcrj0Dxwr7RLxlJlPOHsCe2ijEJgyCMD4FtMiZv/NxDTI5SAnM8IJ9i
pDgM3t4if7o5HSAY7s6lY+IxgJMiD1RXYF/vtpj5Js1VWIjBP3wr+qJOWLTFElWY
4V4n4LIW930gt8qUCNXRxfQgzH9DWbAndXcolSQHh9lpXD9rnDahuuOKceiCX8nn
Ew2FzesK9TUexCMX8r+6+H9+4vUjLM/v7GRT3cNCVcdbrjInA/gFm7p1XhdN5jtl
hocPjdKVqSmxJ7YXILAG7Bc2YSA/4K3RqUNpfKa1jAAFLrf1im1zX4aojbgL597p
nK2Y/6k+TTzCl/YeZwv8ueIhC0A/8FI+IgU4IoLyxVSCn//5E4s=
=bFVz
-END PGP SIGNATURE-

Bug#905582: RFS: nsync/1.20.1-1 [ITP] -- tensorflow dependency

[Lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

  Dear mentors,

  I am looking for a sponsor for my package "nsync", which is a
  tensorflow dependency.

 * Package name: nsync
   Version : 1.20.1-1
   Upstream Author : google
 * URL : [fill in URL of upstreams web site]
 * License : Apache-2
   Section : science

  It builds those binary packages:

libnsync-cpp1 - C library that exports various synchronization primitives 
(C++ li
libnsync-dev - C library that exports various synchronization primitives 
(dev)
libnsync1  - C library that exports various synchronization primitives (C 
lib)

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/n/nsync/nsync_1.20.1-1.dsc

  More information about hello can be obtained fro

  
http://debomatic-amd64.debian.net/distribution#unstable/nsync/1.20.1-1/buildlog

  Changes since the last upload:

nsync (1.20.1-1) unstable; urgency=low

  * Initial release. (Closes: #904440)

Bug#854840: sl-modem-dkms FTBFS at kernel version 4.9

[أحمد المحمودي]

On Fri, Feb 10, 2017 at 07:17:18PM -0500, Stephen Powell wrote:
> Building for 4.9.2-1custom01-686-pae
> Building initial module for 4.9.2-1custom01-686-pae
> Error!  Build of slusb.ko failed for: 4.9.2-1custom01-686-pae (i686)
> Consult the make.log in the build directory
> /var/lib/dkms/sl-modem/2.9.11~20110321/build/ for more information.
> 
> DKMS make.log for sl-modem-2.9.11~20110321 for kernel 4.9.2-1custom01-686-pae 
> (i686)
> Fri Feb 10 19:07:40 EST 2017
> make: Entering directory 
> '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
> doing %.o: %.c
> cc -Wall -pipe -O3 -fomit-frame-pointer -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB 
> `test -f 
> /lib/modules/4.9.2-1custom01-686-pae/build/include/linux/modversions.h && 
> echo -DMODVERSIONS --include 
> /lib/modules/4.9.2-1custom01-686-pae/build/include/linux/modversions.h 
> -I/lib/modules/4.9.2-1custom01-686-pae/build/include`  -I. -I./../modem   -o 
> amrmo_init.o -c amrmo_init.c
> amrmo_init.c:57:26: fatal error: linux/module.h: No such file or directory
---end quoted text---

It seems that you don't have the headers package installed for your 
custom kernel: 4.9.2-1custom01-686-pae

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#871621: ITP for virt-bootstrap.

[Guido Günther]

On Mon, Aug 06, 2018 at 05:21:09PM +0200, Bas Zoetekouw wrote:
>Hi Guido,
>Are you still interested in packaging virt-bootstrap? It seems
>virt-manager requires this package to be able to create LXC environments.

You can grab it.
 -- Guido

Bug#905527: `apt show` fails to parse record for librust-winapi-dev (while `apt-cache show` succeeds)

[David Kalnischkies]

Control: tags -1 confirmed
Control: fixed -1 1.7.0~alpha1

On Sun, Aug 05, 2018 at 12:20:54PM -0300, Antonio Terceiro wrote:
> ~$ apt-cache show librust-winapi-dev
> [... stuff ...]
> ~$ apt show librust-winapi-dev
> E: Unable to parse package file 
> /var/lib/apt/lists/ftp.br.debian.org_debian_dists_unstable_main_binary-amd64_Packages
>  (2)
> E: Internal Error, Unable to parse a package record
> 
> librust-winapi-dev as a massing Provides: field, which could be causing this.

That is indeed some very short field… 

I can reproduce this problem on 1.6, but not 1.7 which includes some
rework on the show code, so on a first look it seems like I accidentally
fixed this, but given that our parser is involved I think this deserves
a second look to figure out what exactly I fixed by accident – or if
I just hide the problem under another pile.

Hence tagging as fixed, but not closed for now & claiming ownership
until some time later this week.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#902989: python3-pyatspi: fresh installation breaks

[Paul Gevers]

Control: severity -1 important
Control: retitle -1 python3-pyatspi: not compatible with python3.7

On Wed, 1 Aug 2018 23:50:44 +0200 Samuel Thibault 
wrote:
> Hello,
> 
> Control: severity -1 important

^^  Control: lines should be on the first line(s) for the BTS to pick it up.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905574: linux-image-4.17.0-0.bpo.1-amd64: cryptsetup missing in intitramfs for kernel 4.17

[Ben Hutchings]

On Mon, 2018-08-06 at 14:40 +0100, Ian Campbell wrote:
> On Mon, 2018-08-06 at 21:15 +0800, Ben Hutchings wrote:
> > > Inspecting the initramfs shows that the cryptsetup related parts are
> > > missing for 4.17, but still in the 4.16 kernel.
> > > 
> > > I was able to mitigate the issue by use the cryptsetup packages from
> > > buster.
> > 
> > This is strange.  Kernel packages do not determine what goes into the
> > initramfs.
> 
> Possibly the cryptsetup package changed (and become broken). Then the
> 4.17 initramfs was (re)built (due to the install/upgrade of that
> kernel) while the 4.16 initramfs wasn't rebuilt.

In stable?  (There's no backport of cryptsetup.)

> I expected that there were be triggers in place which should have
> caused the 4.16 initramfs (in fact, all initramfses) to be updated if a
> relevant package (e.g. cryptsetup) was changed, but perhaps that was
> more in hope than expectation and it's only an initramfs-tools update
> which would trigger that?

Installing or upgrading cryptsetup will trigger an update of the newest
installed kernel version's initramfs.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.



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

Bug#905116: [PATCH v2] scripts/kernel-doc: Escape all literal braces in regexes

[Ben Hutchings]

On Mon, 2018-08-06 at 07:14 -0600, Jonathan Corbet wrote:
> On Sun, 5 Aug 2018 17:41:09 +0100
> Ben Hutchings  wrote:
> 
> > Commit 720ac2ef479d ("PATCH scripts/kernel-doc") fixed the two
> > instances of literal braces that Perl 5.28 warns about, but there are
> > still more than it doesn't warn about.
> 
> So where can I find this commit of which you speak?  I can't find it in
> mainline, -next, or -stable...  
> 
> The patch looks good, I'd like to get it in this coming merge window if
> possible.

Sorry, that was the wrong commit hash.  I mean commit 701b3a3c0ac4.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.


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

Bug#905568: linux-image-4.17.0-1-amd64: Enable CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE to prevent trashing cheap EFI flash storage chips

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2018-08-06 at 10:51 +0100, Sam Morris wrote:
> Package: src:linux
> Version: 4.17.8-1
> Severity: normal
> 
> fwupd is unable to update the firmware on my Lenovo P50.
> 
> lstat("/sys/firmware/efi/efivars/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e-0-0abba7dc-e516-4167-bbf5-4d9d1c739416",
>  {st_mode=S_IFREG|0644, st_size=230, ...}) = 0
> openat(AT_FDCWD, 
> "/sys/firmware/efi/efivars/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e-0-0abba7dc-e516-4167-bbf5-4d9d1c739416",
>  O_RDONLY) = 22
> lseek(22, 0, SEEK_CUR)  = -1 ESPIPE (Illegal seek)
> ioctl(22, FS_IOC_GETFLAGS, 0x7ffd48365c14) = 0
> close(22)   = 0
> openat(AT_FDCWD, 
> "/sys/firmware/efi/efivars/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e-0-0abba7dc-e516-4167-bbf5-4d9d1c739416",
>  O_WRONLY) = 22
> lseek(22, 0, SEEK_CUR)  = -1 ESPIPE (Illegal seek)
> poll([{fd=22, events=POLLOUT}], 1, -1)  = 1 ([{fd=22, revents=POLLOUT}])
> write(22, 
> "\7\0\0\0\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 230) = 
> -1 ENOSPC (No space left on device)
> 
> While searching for a solution I came across
> .[...]

That is from 2013.  The EFI variable support code was subsequently
changed to work around common bugs in EFI implementations.  If you
still don't want efi-pstore, you can put efi-pstore.pstore_disable=Y on
the kernel command line.  But I don't think we're likely to change the
default again.

Older messages logged to EFI variables will be deleted automatically.

However I notice that your report says:

[...]
> ** Tainted: W (512)
>  * Taint on warning.

If this warning, or warnings, are logged at every boot, that might mean
that the variable space always gets filled up again before fwupd can
run.

Can you look back through the system log (dmesg or /var/log/messages)
to find the warning message?  We would need to see everything from
"WARNING" down to "end trace".

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.


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

Bug#868783: synaptic: screenshots should be versioned as on packages.debian.org

[Christoph Haas]

I will fix the sort order of screenshots in the next release of
screenshots.debian.net. Thanks for the hint.

Bug#905409: Please document

[Helge Kreutzmann]

Hello maintainers,
this change (requiring a DISPLAY=:0) is really suprising. I'v used su
for ages and a simple xhost + (yes, I know that this has security
implications) was sufficient.

Plese document this in a public place, the best would be the man page
as that is where users are looking for (a NEWS entry would only catch
administrators once).

I suggest putting it under NOTES. If you like, I can draft up a patch.

Greetings

Helge

-- 
  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#871621: ITP for virt-bootstrap.

[Bas Zoetekouw]

Hi Guido,

Are you still interested in packaging virt-bootstrap?  It seems virt-
manager requires this package to be able to create LXC environments.

Gr,
Bas.

Bug#904014: Runtime directory not created on boot, trafficserver fails to start

[Jean Baptiste Favre]

Hello David,
Thanks for your bug report.
Trafficserver 7.1.3+ds-4~bpo9+1, which includes tmpfile config file, has
been uploaded to stretch-backport.
Could you please test and report wether it works or not ?

Cheers,
Jean Baptiste

On Wed, 18 Jul 2018 09:18:39 + David Brodin  wrote:
> Package: trafficserver
> Version: 7.1.2+ds-3~bpo9+1
> X-Debbugs-CC: debian-backpo...@lists.debian.org, a...@debian.org, 
> deb...@jbfavre.org
> 
> Hi all,
> 
> After having a memory leak (~2MB/min) in stable/trafficserver I installed 
> stretch-backports/trafficserver and the memory leak seems fixed, only cached 
> memory is increasing, not used real.
> However, when rebooting, trafficserver was not able to start normally:
> > Jul 18 09:09:59 host systemd[1]: Started Apache Traffic Server is a fast, 
> > scalable and extensible caching proxy server..
> > Jul 18 09:09:59 host traffic_cop[3019]: binpath is bin
> > Jul 18 09:09:59 host traffic_cop[3019]: unable to locate local state 
> > directory '/var/run/trafficserver'
> > Jul 18 09:09:59 host traffic_cop[3019]:  please try setting correct root 
> > path in either env variable TS_ROOT
> > Jul 18 09:09:59 host systemd[1]: trafficserver.service: Main process 
> > exited, code=exited, status=1/FAILURE
> > Jul 18 09:09:59 host systemd[1]: trafficserver.service: Unit entered failed 
> > state.
> > Jul 18 09:09:59 host systemd[1]: trafficserver.service: Failed with result 
> > 'exit-code’.
> 
> Upon investigation (googling) I found a CentOS 7 post 
> (http://apache-traffic-server.24303.n7.nabble.com/Traffic-server-fails-to-start-Centos-7-td3574.html)
>  about the same issue, the thread recommended using 
> RuntimDirectory=trafficserver and RunTimeDirectoryPreserve=restart in 
> trafficservers service-file.
> This did not work either as the directory was created with a sid/gid of 
> root/root and not trafficserver/trafficserver.
> I then tried using PermissionsStartOnly=True and setting User=,Group= to 
> trafficserver, but as trafficserver chroots(?) itself I got this error 
> instead:
> > Jul 18 09:51:46 host traffic_manager[4268]: Fatal: failed to acquire 
> > privileged capabilities: Operation not permitted
> 
> I tried another thing, which I can’t remember now of course, but I got the 
> following error for that:
> > Jul 18 09:55:21 host traffic_manager[4464]: Fatal: 
> > [LocalManager::initMgmtProcessServer] failed to bind socket at 
> > /var/run/trafficserver/processerver.sock
> 
> Either way, I ended up using tmpfiles.d:
> > root@host:~# cat /etc/tmpfiles.d/trafficserver.conf
> > #Type   PathModeUID GID 
> > Age Argument
> > d   /run/trafficserver  0755trafficserver   trafficserver   -
> 
> Which after another reboot worked just fine. I’m sure there is a more elegant 
> fix for this, but shy of ExecStartPre=mkdir … I wasn’t able to figure out any 
> other way.
> Seeing as trafficserver can’t start after a normal reboot, I thought I should 
> report this.
> I’ve also tested this on a fresh install of Debian 9.5 with the same error.
> 
> -- System Information:
> > root@host:~# uname -a
> > Linux host 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 
> > GNU/Linux
> > root@host:~# lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Debian
> > Description:Debian GNU/Linux 9.5 (stretch)
> > Release:9.5
> > Codename:   stretch
> 
> Thanks,
> David
> —
> David Brodin
> Sveriges Radio AB
> Phone: +46 (0)8 784 2329
> Email: david.bro...@sr.se
> https://sr.se/

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Riku Voipio]

On Thu, Jun 14, 2018 at 09:58:56AM +0100, Ian Campbell wrote:
> On Wed, 2018-06-13 at 12:25 -0700, Geoff Levand wrote:
> > On 06/09/2018 05:15 AM, Ian Campbell wrote:
> > 
> > > I think this is probably something for the arch (or perhaps
> > > platform)
> > > code to deal with. See for example all the various platform quirks
> > > in
> > > arch/x86/kernel/acpi/boot.c, which fixup various wrongness and/or
> > > disable features.
> > 
> > I followed your advice and created a fix in the arm64 acpi init
> > code of arch/arm64/kernel/acpi.c.  Here's the submission:
> > 
> >   https://marc.info/?l=linux-acpi=152891415600796=2
> >   https://www.spinics.net/lists/linux-acpi/msg82887.html
> 
> Thanks!

Thanks indeed - unfortunately we seem to be endind up in 
a dead end with the upstream developers:

https://www.spinics.net/lists/arm-kernel/msg669674.html

Considering HPE didn't actually release the firmware, I think we
can go with just enabling the options and documenting the command line
option.

Riku

Bug#905553: libdbus-glib-1-dev: install dbus-binding-tool into a Multi-Arch: foreign package

[Helmut Grohne]

Hi Simon,

On Mon, Aug 06, 2018 at 12:19:39PM +0100, Simon McVittie wrote:
> [ discussion on what deprecated means ]

Experience from python2 has shown that deprecation is difficult. You can
announce it early and still everyone ignores it. I even try to move
packages off deprecated technology where I can (e.g. xmkmf), but
converting dbus-glib users is beyond my skills and time budget. Sorry.

> not mean people have actually stopped using it, and does not mean that
> it can be removed from Debian in a finite time.

I think this is key. What I really want is a way forward in finite time.
For instance with qt4, there is a deadline (buster). So I don't bother
fixing qt4 packages and simply track the individual qt4 removal bugs.
Once they move to qt5, I'll notice immediately and try cross building
them. For dbus-glib, I waited for your mbf and nothing happened.
Presumably, the time is not ripe yet. That's ok.

If you see a different way forward, I'm all ears. Long term, the effort
is likely better spent at converting the remaining (many) users.

> dbus-glib already has a versioned Depends on a better D-Bus implementation
> (part of libglib2.0-0). Next time I do an upstream release I'm seriously
> tempted to add __attribute__((deprecated("use GDBus instead"))) to
> every symbol.

Sounds useful to me. It seems that very many downstreams are not fully
aware.

> If it's sufficiently important to you to justify a trip through NEW,
> then I'd prefer to do a MU fixing this and #873617 (there seems little
> reason to fix this one but not #873617). Thanks for the patch, I'll use
> it as a base.

That's not a boolean, but a non-trivial trade-off. When fixing
deprecated technology I consider:
 * How long does it take to get rid of it?
 * How many users does it have?
For dbus-glib the respective answers appear to be "long" and "many".
Having many users also means that failures due to dbus-glib shadow other
failures. I'm not that much after fixing this bug for its own sake, but
for getting a better picture of the remaining failures.

So yes, I have come to the conclusion that fixing this is worth the trip
through NEW. That's why I sat down, wrote the patch and kindly offered
the NMU, not as a threat, but as potential way forward. I gladly honour
your preference for doing a MU. I don't even have much urgency here, but
I know that a number of people use stable for cross building, so please
try to fix it in buster.

Thank you for your cooperation in a matter that doesn't look productive
to you.

Helmut

Bug#905528: mount: nofail

[Phillip Susi]

sysvinit called mount -a to handle mounting devices at boot.  Unless you
are still refusing to move to systemd, mount is on longer responsible
for this so the problem must be in systemd.

On 8/5/2018 11:44 AM, Seamus de Mora wrote:
> Package: mount
> Version: 2.29.2-1+deb9u1
> Severity: normal
> 
> Dear Maintainer,
> 
> I have modified the file at `/etc/fstab` to add instructions to `mount` for
> mounting a "USB thumb drive" (LABEL=SANDISK16GB); please see the file
> contents below. Note the use of the `nofail` option. When I omit this
> option, and that USB thumb drive is not plugged in, my system will no
> longer complete the boot process. This behavior is contrary to the



signature.asc
Description: OpenPGP digital signature

Bug#904843: boinc-manager: boincmgr does not properly start, exit code 0377

[Christian Lins]

I rebuild the package with debug information from experimental but 
unfortunately I could not reproduce the error. Thus, I consider this 
issue as fixed ;-)


Am 02.08.2018 um 12:51 schrieb Gianfranco Costamagna:

control: tags -1 moreinfo
Hello,


on my workstation (Debian Testing) I sometimes use boincmgr, but after an
upgrade a few weeks(?) ago, boincmgr does no longer start. I cannot recall the
exact upgrade number as I do not use boincmgr regularily, but for now it does
not properly start:



what does the apt log shows? did you upgrade virtualbox? are you using the home 
directory?
now boinc forbids home directory usage, because of security, so this might be 
the reason

maybe removing
"ProtectHome=true" from boinc-client.service makes it work?

G.

Bug#905259: im-config 0.38-1: Bug#905264, #905259, #905260 ... future proof

[Osamu Aoki]

Hi,

Thanks to Boyuan Yang, this bug was quickly fixed in 0.37-1.

I thought I checked by looking at contributed patch.  But these typos
were so easy to overlook ;-(

I realized, this could have been prevented by introducing build time
automatic syntax check just like we do for devscripts.  Thus I uploaded
0.38-1 to prevent any future problem.

I hope sh --> bash change for im-config should not cause problem.

Regards,

Osamu