Bug#908961: closed by Vasudev Kamath (Bug#908961: fixed in cargo 0.30.0-1~exp1)

[Helmut Grohne]

Control: reopen -1

On Sun, Oct 07, 2018 at 05:36:04AM +, Debian Bug Tracking System wrote:
>* debian/rules:
>  + Use DEB_BUILD_OPTIONS to disable tests on powerpc and powerpcspe
>architecture.
>Closes: bug#908961, Thanks to Helmut Grohne.

This is broken. Now building e.g. with DEB_BUILD_OPTIONS=nostrip no
longer works on powerpc. You must not set either DEB_BUILD_OPTIONS or
DEB_BUILD_PROFILES for any supported debian/rules target.

The one place where you should have set it is in the sbuild invocation
line where you violate the build profile specification by not adding
nocheck to DEB_BUILD_OPTIONS when you add nocheck to DEB_BUILD_PROFILES.

Helmut

Bug#910487: ITP: r-cran-eaf -- GNU R plots of the empirical attainment function

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-eaf
  Version : 1.8
  Upstream Author : Manuel López-Ibáñez
* URL : https://cran.r-project.org/package=eaf
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R plots of the empirical attainment function
 This GNU R package supports plots of the empirical attainment function
 for two objectives.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-eaf

Bug#908961: cargo: debian/rules overrides DEB_BUILD_PROFILES

[Helmut Grohne]

On Sun, Oct 07, 2018 at 10:33:24AM +0530, Vasudev Kamath wrote:
> So setting nocheck to DEB_BUILD_OPTIONS  should be the right approach
> right?.

No, DEB_BUILD_OPTIONS is also supposed to be supplied by a user. The
packaging should not modify it either. Refer to Debian policy section
4.9.1 for details.

Of course, you should check whether the user supplied nocheck in
DEB_BUILD_OPTIONS, but you should not change its value.

Helmut

Bug#908961: cargo: debian/rules overrides DEB_BUILD_PROFILES

[Vasudev Kamath]

Hi Helmut,

Helmut Grohne  writes:

> Source: cargo
> Version: 0.29.0-1
>
> debian/rules sets DEB_BUILD_PROFILES. The variable is not meant to be
> changed during build. Changing it can lead to inconsistency between
> tools run by debian/rules and tools run outside debian/rules, but it
> also overrides a user configuration. Please use a different variable for
> skipping tests for certain architectures.
>
> Note that you don't have to check for the nocheck profile. Checking the
> nocheck option is sufficient, because the spec requires that nocheck is
> added to DEB_BUILD_OPTIONS whenever it is present in DEB_BUILD_PROFILES.
> Simply setting DEB_BUILD_PROFILES=nocheck without setting
> DEB_BUILD_OPTIONS is a build profile specification violation.

So setting nocheck to DEB_BUILD_OPTIONS  should be the right approach
right?.

Cheers,

Bug#910485: libpsm2-2: times out on /dev/hfi1_0 device and causes test errors

[Drew Parsons]

Package: libpsm2-2
Version: 11.2.68-1
Severity: serious
Justification: causes other packages to fail tests; interferes with efficient 
execution; regression

Programs running with libpsm2-2 11.2.68-1 now emit the warning:
> ci-1538433288.12336hfi_wait_for_device: The /dev/hfi1_0 device failed to 
> appear after 15.0 seconds: Connection timed out

which registers as an error in tests (I presume the warning is sent
to stdout)

This causes some tests and debci tests to fail, for instance petsc
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/petsc/1080389/log.gz

I think it must fail because of the new involvement of stderr. Some
other tests still pass, e.g. dolfin
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dolfin/1080544/log.gz


In any case, this bug holds up execution for 15 secs or more, which
itself is not good and is a regression from 10.3.58-2




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

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

Versions of packages libpsm2-2 depends on:
ii  libc6 2.27-6
ii  libnuma1  2.0.12-1

libpsm2-2 recommends no packages.

libpsm2-2 suggests no packages.

-- no debconf information

Bug#910134: RFS: dmidecode/3.2-1

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Herbert,


many thanks for your review.

Am Samstag, den 06.10.2018, 08:59 -0300 schrieb Herbert Fortes:
> Hi,
> 
> On 10/3/18 3:58 AM, Jörg Frings-Fürst wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> >I am looking for a sponsor for my package "dmidecode"
> 
> There are two changes made by Jean Delvare that is not
> in debian/copyright:
> 

Sorry, that I have don't see this. 


> +++ dmidecode-3.2/dmidecode.c 2018-09-14 10:52:12.0 -0300
> @@ -2,7 +2,7 @@
>* DMI Decode
>*
>*   Copyright (C) 2000-2002 Alan Cox 
> - *   Copyright (C) 2002-2017 Jean Delvare 
> + *   Copyright (C) 2002-2018 Jean Delvare 
> --
> +++ dmidecode-3.2/util.c  2018-09-14 10:52:12.0 -0300
> @@ -2,7 +2,7 @@
>* Common "util" functions
>* This file is part of the dmidecode project.
>*
> - *   Copyright (C) 2002-2017 Jean Delvare 
> + *   Copyright (C) 2002-2018 Jean Delvare 
> 
> 
> debian/copyright:
> 
> Files: *
> Copyright: 2002-2017 Jean Delvare 
> 
> 
> Can you please update it?
> 

Done and uploaded to mentors and into git.
> 
> 
> Regards,
> Herbert
> 
[..] 

CU
Jörg


- -- 
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+AHX8jUOrs1qzDuCfifPIyh0l0FAlu5im4ACgkQCfifPIyh
0l0PXg/9GcDwGB/Z4TN4Tji67mFkWhQE+DkMPEnS3ER2C5atJN5H4p94tC7/wcp7
hu7iFNQ81Rq0JXnCgHr9gM9BKUSFFo+iHAy/Z7TbpEzB19k/JRWp/bR2hFZtwz70
qzS3tGbTKWYA5kcFRWbbxZ5R70UMMK2RpNVamjlTrh7j3JVKymY6mVavWhOZ6LAK
e8Gv6NS54KYLYTYTfglub1tFgJeyCBsUJqA3Ss32Z+lSGohibE1+IufTeM9545pK
2NLAZ2lJYxBlvUZyRJ3FT2rmkGomZ18ujIEkfUF0A4QZ3P6wNxtvwW0M9zCaNY3e
HjVAMjgaQWiOq7bgW7uEatE+q0IbEwbhTNHCC8tQHV7WI6WHOOOLEqjsSbVFXDXd
emiESVY+S6EL7kB7m6uKmkCMMha6+KC9PX3KbBU9sVKT8ADSm5O+SAtbHEUC3WS3
gai4faz30d64Tv49ZnftmAkC99DuB9zEC/an4criu1tdcgNsTA8NpuHZQoGbqV1R
NuuKUk//YTnaIxb1BjX+iz/2CGDJ7CdAnEo3FBvX20F0wsoIfn9J/nGeVLe2SLlD
tl9/E0HJMLPZ4dDKwA2Y2Vd6IgJzMTvqTJJDAyre0XI1EQAjolI3DcdhXkd9OoGs
dFM9SjzUh1wD7iwmjlited4J0ZesdxMH0bZwITQv2raDQpgqbjY=
=Wi4Z
-END PGP SIGNATURE-

Bug#910484: ITP: python-backports.csv -- Backport of the Python 3 CSV module for Python 2

[Stuart Prescott]

Package: wnpp
Severity: wishlist
Owner: Stuart Prescott 

* Package name: python-backports.csv
  Version : 1.0.6
  Upstream Author : Python Software Foundation
* URL : https://github.com/ryanhiebert/backports.csv
* License : Python Software Foundation License v 2
  Programming Lang: Python
  Description : Backport of the Python 3 CSV module for Python 2

This package contains a backport of the Python 3 stdlib module 'csv' bringing
new features to Python 2. Packaging this module makes it easier to write code
that works with both Python 2 and Python 3, also permitting upstreams to
take advantage of the new features in the CSV module.

python-backports.csv is a dependency of the current translate-toolkit
release (2.3.1).

python-backports.csv will presumably be part of buster but not bullseye.

Bug#910483: ttf-mscorefonts-installer infinite loop if SourceForge.net CA-chain isn't trusted

[Tim Chase]

Package: ttf-mscorefonts-installer
Version: 3.6
File: ttf-ms
Severity: normal

Dear Maintainer,

> What led up to the situation?

$ sudo dpkg-reconfigure ca-certificates

and disable "mozilla/DST_Root_CA_X3.crt" (by default I disable the
majority of CAs) then

$ sudo apt-get install ttf-mscorefonts-installer

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

$ sudo dpkg-reconfigure ca-certificates

and re-enable "mozilla/DST_Root_CA_X3.crt" to get it working again.

> What was the outcome of this action?

Attempting an install without the DST_Root_CA_X3 enabled led to an
infinite loop in the installer.

Reenabling the (previously-revoked) trust in the CA install proceeded
properly.

> What outcome did you expect instead?

If the curl/wget command fails because the root CA is not trusted, it
should abort/fail the install, preferrably with a message about the CA
chain-of-trust it was expecting, and a suggestion to "dpkg-reconfigure
ca-certificates" (or export $CURL_CA_BUNDLE to an appropriate value
for the process or whatever the analog would be for `wget`).

But certainly not an infinite loop.

Thanks,

-Tim



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

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

Versions of packages ttf-mscorefonts-installer depends on:
ii  cabextract 1.6-1+b1
ii  debconf [debconf-2.0]  1.5.61
ii  wget   1.18-5+deb9u2
ii  xfonts-utils   1:7.7+4

Versions of packages ttf-mscorefonts-installer recommends:
ii  fonts-liberation  1:1.07.4-2

ttf-mscorefonts-installer suggests no packages.

-- debconf-show failed

Bug#910482: libmagickcore-6.q16-6-extra: SVG error messages and/or rendering errors if inkscape not installed

[Alan W. Irwin]

Package: libmagickcore-6.q16-6-extra
Version: 8:6.9.10.8+dfsg-1
Severity: normal

Dear Maintainer,

With libmagickcore-6.q16-6-extra installed, "display" (symlinked to
display-im6.q16) renders validated SVG files incorrectly or not at all
(exited with

"display-im6.q16: non-conforming drawing primitive definition `path' @ 
error/draw.c/DrawImage/4216."

) if inkscape is not installed.  Therefore, since inkscape is so
essential for processing SVG files I suggest that inkscape be promoted from 
"Suggests:"
to "Recommends:" for libmagickcore-6.q16-6-extra or else the package 
description should
mention that inkscape is essential to SVG success.

Alan

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
compare:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
convert:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
composite:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
conjure:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
display:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
identify:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
import:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
mogrify:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
montage:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org
stream:  ImageMagick 6.9.10-8 Q16 x86_64 20180723 https://www.imagemagick.org

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

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

Versions of packages libmagickcore-6.q16-6-extra depends on:
ii  libc6  2.27-6
ii  libcairo2  1.15.12-1
ii  libdjvulibre21 3.5.27.1-9
ii  libglib2.0-0   2.58.1-2
ii  libmagickcore-6.q16-6  8:6.9.10.8+dfsg-1
ii  libmagickwand-6.q16-6  8:6.9.10.8+dfsg-1
ii  libopenexr23   2.2.1-4
ii  libpango-1.0-0 1.42.4-3
ii  libpangocairo-1.0-01.42.4-3
ii  libwmf0.2-70.2.8.4-12
ii  libxml22.9.4+dfsg1-7+b1

Versions of packages libmagickcore-6.q16-6-extra recommends:
ii  libjxr-tools  1.1-6+b1

Versions of packages libmagickcore-6.q16-6-extra suggests:
ii  inkscape  0.92.3-3

-- no debconf information

Bug#898705: #898705 android-platform-libcore FTBFS with debhelper v11

[Dmitry Smirnov]

It would be great to fix this bug in "unstable" to prevent auto-removal of 
Zabbix from "testing"...

Thanks.

-- 
All the best,
 Dmitry Smirnov

---

Moral courage is the most valuable and usually the most absent
characteristic in men.
-- George S. Patton


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

Bug#902759:

[Nicholas D Steeves]

Hello,

On Thu, Aug 02, 2018 at 09:22:12PM +1200, Michael Hudson-Doyle wrote:
>I cherry picked the attached patch from upstream to fix this in Ubuntu
>(it's just regenerating the .c files with a newer cython).

> From f4811786a50b95699b315169596a6090f4be3d65 Mon Sep 17 00:00:00 2001
> From: tomis007 
> Date: Tue, 3 Jul 2018 20:01:32 -0400
> Subject: [PATCH] regenerated with cython 0.28.3
> 
> ---
>  http_parser/parser.c | 10470 
> -
>  1 file changed, 6972 insertions(+), 3498 deletions(-)
> 

Just to confirm, none of the following is useful for the Debian
package, nor for correct DebCI functioning, right?
  
https://github.com/douban/pymesos/pull/109/commits/6ebaf93c2e76f49586faf1e6d5f7ca2cc9c7ee03

I'd like to see the patch Michael cherry picked applied to resolve
this bug :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#910226: closed by Georges Khaznadar (Bug#910226: fixed in expeyes 4.4.4+dfsg-2)

[Andreas Beckmann]

Control: found -1 4.4.4+dfsg-2

On 2018-10-05 17:54, Debian Bug Tracking System wrote:
>* added confilcts/replaces for python3-expeyes << 4.3. Closes: #910226

I don't see how this was supposed to fix the buggy maintainer script in
this package ...

Andreas

Bug#910481: stretch-pu: package magicmaze/1.4.3.6+dfsg-3~deb9u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

let's fix the wrong font path (buggy since jessie) in stretch, too.
This is a rebuild of the package I just uploaded to unstable.
The bug is old, but only got the severity adjusted recently.

The game now loads and opens a graphical window, but I won't
figure out the gameplay :-)


Andreas
diff -Nru magicmaze-1.4.3.6+dfsg/debian/changelog 
magicmaze-1.4.3.6+dfsg/debian/changelog
--- magicmaze-1.4.3.6+dfsg/debian/changelog 2013-06-30 03:33:39.0 
+0200
+++ magicmaze-1.4.3.6+dfsg/debian/changelog 2018-10-07 01:50:06.0 
+0200
@@ -1,3 +1,22 @@
+magicmaze (1.4.3.6+dfsg-3~deb9u1) stretch; urgency=medium
+
+  * Rebuild for stretch.
+
+ -- Andreas Beckmann   Sun, 07 Oct 2018 01:50:06 +0200
+
+magicmaze (1.4.3.6+dfsg-3) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * QA upload.
+  * Set Maintainer to Debian QA Group.  (See: #869294)
+
+  [ Hans Joachim Desserud ]
+  * Depend on fonts-isabella now that ttf-isabella is a virtual package.
+  * Update isabella path in patch to new location,
+closes: #747046, LP: #1360075.
+
+ -- Andreas Beckmann   Sat, 06 Oct 2018 16:18:35 +0200
+
 magicmaze (1.4.3.6+dfsg-2) unstable; urgency=low
 
   * fix crash when pausing the game
diff -Nru magicmaze-1.4.3.6+dfsg/debian/control 
magicmaze-1.4.3.6+dfsg/debian/control
--- magicmaze-1.4.3.6+dfsg/debian/control   2013-06-24 15:59:56.0 
+0200
+++ magicmaze-1.4.3.6+dfsg/debian/control   2018-10-06 15:49:13.0 
+0200
@@ -1,14 +1,14 @@
 Source: magicmaze
 Section: games
 Priority: extra
-Maintainer: Joe Nahmias 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.4
 Homepage: http://magicmaze.rubyforge.org/
 
 Package: magicmaze
 Architecture: all
-Depends: ruby | ruby-interpreter, ruby-sdl, ttf-isabella, ${misc:Depends}
+Depends: ruby | ruby-interpreter, ruby-sdl, fonts-isabella, ${misc:Depends}
 Description: rescue the maiden while avoiding the monsters
  This is a simple game where you are a wizard searching the evil demon's
  tower to try and rescue the beautiful maiden.  Inspired by Gauntlet II,
diff -Nru magicmaze-1.4.3.6+dfsg/debian/patches/20_isabella_path.patch 
magicmaze-1.4.3.6+dfsg/debian/patches/20_isabella_path.patch
--- magicmaze-1.4.3.6+dfsg/debian/patches/20_isabella_path.patch
2013-06-24 14:59:56.0 +0200
+++ magicmaze-1.4.3.6+dfsg/debian/patches/20_isabella_path.patch
2018-10-06 15:12:04.0 +0200
@@ -8,7 +8,7 @@
rescue SDL::Error => err
# Debian font
 -  fontfile = "/usr/share/fonts/truetype/Isabella.ttf"
-+  fontfile = "/usr/share/fonts/truetype/ttf-isabella/Isabella.ttf"
++  fontfile = "/usr/share/fonts/truetype/isabella/Isabella.ttf"
fontsize = [12, 28]
if tries < 1 then 
  tries += 1 # to avoid loop.

Bug#910480: ghc: missing Breaks+Replaces+Provides for newly bundled libraries

[Andreas Beckmann]

Package: ghc
Version: 8.4.3+dfsg1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: block 910008 with -1
Control: block 910202 with -1

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

See the blocked bugs for the full logs, here are only excerpts:

---
  Preparing to unpack .../libghc-mtl-dev_2.2.2-2_amd64.deb ...
  Unpacking libghc-mtl-dev (2.2.2-2) over (2.2.2-1) ...
  Preparing to unpack .../gcc_4%3a8.2.0-1_amd64.deb ...
  Unpacking gcc (4:8.2.0-1) over (4:8.1.0-1) ...
  Preparing to unpack .../cpp_4%3a8.2.0-1_amd64.deb ...
  Unpacking cpp (4:8.2.0-1) over (4:8.1.0-1) ...
  Preparing to unpack .../ghc_8.4.3+dfsg1-2_amd64.deb ...
  Unpacking ghc (8.4.3+dfsg1-2) over (8.2.2-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/ghc_8.4.3+dfsg1-2_amd64.deb (--unpack):
   trying to overwrite '/var/lib/ghc/package.conf.d/mtl-2.2.2.conf', which is 
also in package libghc-mtl-dev 2.2.2-2
  update-alternatives: using /usr/bin/runghc to provide /usr/bin/runhaskell 
(runhaskell) in auto mode
  update-alternatives: using /usr/bin/ghc to provide /usr/bin/haskell-compiler 
(haskell-compiler) in auto mode
  There are problems in package mtl-2.2.2:
dependency "base-4.11.1.0" doesn't exist
dependency "transformers-0.5.5.0" doesn't exist
  
  The following packages are broken, either because they have a problem
  listed above, or because they depend on a broken package.
  mtl-2.2.2
  Preparing to unpack .../libgnutls30_3.5.19-1+b1_amd64.deb ...
  Unpacking libgnutls30:amd64 (3.5.19-1+b1) over (3.5.19-1) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/ghc_8.4.3+dfsg1-2_amd64.deb
---
  Selecting previously unselected package libghc-parsec3-dev.
  (Reading database ... 
(Reading database ... 10244 files and directories currently installed.)
  Preparing to unpack .../libghc-parsec3-dev_3.1.13.0-3_amd64.deb ...
  Unpacking libghc-parsec3-dev (3.1.13.0-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libghc-parsec3-dev_3.1.13.0-3_amd64.deb (--unpack):
   trying to overwrite '/var/lib/ghc/package.conf.d/parsec-3.1.13.0.conf', 
which is also in package ghc 8.4.3+dfsg1-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libghc-parsec3-dev_3.1.13.0-3_amd64.deb
---


I think these bugs actually belong to ghc which started bundling more
libraries with the recent upload to unstable. 


I would suggest to add the following:

Breaks:
 libghc-mtl-dev (<< 2.2.2+),
 libghc-parsec3-dev (<< 3.1.13.0+),
Replaces:
 libghc-mtl-dev (<< 2.2.2+),
 libghc-parsec3-dev (<< 3.1.13.0+),
Provides:
 libghc-mtl-dev,
 libghc-parsec3-dev,

There may be more packages affected, but testing them is probably
blocked by libghc-mtl-dev

I used "${current_upstream_version}+" as version bound, since e.g.
"1.2.3+" sorts before new upstream versions like
  1.2.3+dfsg, 1.2.3.1
in addition to
  1.2.4, 1.5.3


cheers,

Andreas

Bug#910479: hpanel: Sometimes busy and unresponsive

[Paul Szabo]

Package: hpanel
Version: 0.3.2-4
Severity: normal

Dear Maintainer,

On occasions, I observe hpanel to be busy, and unresponsive: seems that
the panel icons are "flashing" (in sequence maybe?), and clicking on
them has no immediate effect (to raise or lower the window); waiting a
minute or so, hpanel will quieten and then act on the clicks that were
done during its busy stage.

I do not know how to reproduce or elicit this "busy and unresponsive"
state, nor have ideas on checking what it is doing during that time.

Thanks, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia


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

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

Versions of packages hpanel depends on:
ii  libc6 2.24-11+deb9u3
ii  libx11-6  2:1.6.4-3
ii  libxft2   2.3.2-1+b2
ii  libxpm4   1:3.5.12-1

hpanel recommends no packages.

hpanel suggests no packages.

-- no debconf information

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 07.10.18 um 01:06 schrieb Michael Biebl:

> We change the init script as follows:
> - We revert most the changes from #791944, we only keep the stop
> symlinks for rc0 and rc6 and the cleanup of /run/udev/control file on stop.
> - We tweak the LSB headers to make sure the udev init script is called
> before sendsigs on shutdown. This is important!
> 
> This should ensure that udevd is properly killed and the control file
> removed, i.e. there should be (almost) no time window where the udevd
> daemon is not running but the control file exists.
> 
> On the other hand, this would mean we again stop udevd earlier during
> shutdown, but we mostly had this behaviour already in previous releases
> where udevd is killed by sendsigs.

I have to add, that this change has the potential to significantly
change the shutdown order or cause a conflicting ordering, in case there
are other init scripts which declare an explicit shutdown dependency.

This will need someone to further investigate and test it.

Looking at https://codesearch.debian.net/ and searching for packages
which declare a Should-Stop or Required-Stop on udev and checking if any
late shutdown services are involved.

Michael


-- 
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#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 05.10.18 um 10:25 schrieb Trek:
> On Thu, 4 Oct 2018 21:58:38 +0200
> Michael Biebl  wrote:
> 
>>> 1) revert the 791944 patch, create a new init.d/udev-clear script to
>>> remove the control file and run it just after sendsigs (this will
>>> restore the old well tested behavior) 
>>
>> The removal of the control file should be bound to the live time of
>> the udev service, so splitting it off into a separate init script is
>> not a good idea.
> 
> yes, to be sure, we should call udev-clear before sendsigs
> 
> this will mimic the old behavior, where the control file doesn't exists
> after sendsigs
> 
> I think this is the first step we should do to restore the
> functionality, then we have more time to find the proper solution, but
> at least we will not miss another stable release without a functioning
> udev + sysvinit + dmsetup/cryptdisks

Tbh, I'm not interested in a quick hack, which we later have to clean up
again and is likely to break in other slightly odd ways.
And a new, separate init script feels like this.

>> A proper solution might (emphasis on might, as I haven't checked this)
>> be to teach start-stop-daemon about daemons using the sd-notify
>> interface. This is a more elaborate fix, for sure, but everything else
>> feels like an incomplete hack.
> 
> yes, probably this is a good solution
> 
> as start-stop-daemon is called in parallel, it could be required to
> create a different notify socket per instance, but luckily the client
> library manage the NOTIFY_SOCKET environment variable

Would you be willing to talk to the dpkg/start-stop-daemon maintainer to
gather his input on this matter?
Someone else willing/interested in doing this?

> another possible solution is to add an option to udev to remove the
> control file on exit, as it was in the past

Changing systemd-udevd to unlink the control file itself would work.
This would require someone to talk to upstream though and convince them
to make this change. We've been tirelessly working on reducing the
amount of downstream patches and I don't want to add a downstream patch
which we'd never get rid off again.

So, aside from these two options (providing sd-notify support in s-s-d,
unlinking the control in systemd-udevd directly), what you said above
got me thinking:

We change the init script as follows:
- We revert most the changes from #791944, we only keep the stop
symlinks for rc0 and rc6 and the cleanup of /run/udev/control file on stop.
- We tweak the LSB headers to make sure the udev init script is called
before sendsigs on shutdown. This is important!

This should ensure that udevd is properly killed and the control file
removed, i.e. there should be (almost) no time window where the udevd
daemon is not running but the control file exists.

On the other hand, this would mean we again stop udevd earlier during
shutdown, but we mostly had this behaviour already in previous releases
where udevd is killed by sendsigs.

I hope the idea is clear, if not, please don't hesitate to ask.


Trek, would you be willing to work on an patch for this?


-- 
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#910478: Please drop usage of SYSTEMCTL_SKIP_REDIRECT from init scripts

[Michael Biebl]

Source: dogtag-pki
Version: 10.6.6-2
Severity: important

The dogtag-pki packages uses SYSTEMCTL_SKIP_REDIRECT in various init
scripts:

- dogtag-pki_10.6.6-2/base/tps-client/etc/init.d/pki-tpsd
# Avoid using 'systemctl' for now
SYSTEMCTL_SKIP_REDIRECT=1
export SYSTEMCTL_SKIP_REDIRECT

- dogtag-pki_10.6.6-2/debian/pki-server.pki-tomcatd.init

# Avoid using 'systemctl' for now
SYSTEMCTL_SKIP_REDIRECT=1
export SYSTEMCTL_SKIP_REDIRECT


- dogtag-pki_10.6.6-2/debian/pki-server.pki-tomcatd.init

# Avoid using 'systemctl' for now
SYSTEMCTL_SKIP_REDIRECT=1
export SYSTEMCTL_SKIP_REDIRECT


- dogtag-pki_10.6.6-2/base/tps-client/etc/init.d/pki-tpsd

# Avoid using 'systemctl' for now
SYSTEMCTL_SKIP_REDIRECT=1
export SYSTEMCTL_SKIP_REDIRECT



This is an internal implementation detail of the systemd LSB hook and
should not be set in init scripts directly. The name of the variable is
not guaranteed to be stable as well.

Skipping the redirection can have undesired side effects.
If you boot with systemd, then restart the service via
/etc/init.d/$service restart, the process will no longer be
tracked properly.

Therefor please drop the usage of SYSTEMCTL_SKIP_REDIRECT from the init
scripts.

Regards,
Michael

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

Kernel: Linux 4.18.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

Bug#910477: RFP: node-nyc -- Istanbul's state of the art command line interface

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-nyc
  Version : adb310ca9e
  Upstream Author : Benjamin E. Coe ( @benjamin...@twitter.com )
* URL : https://notabug.org/themusicgod1/nyc
* License : ISC
  Programming Lang: javascript
  Description : Istanbul's state of the art command line interface

CLI for node-istanbul.  Has Support for applications that spawn subprocesses, 
ES2015 transforms (via babel-plugin-istanbul), or source-maps.
Helps produce accurate stack traces using source-maps.
node-nyc has support for custom require hooks (babel, typescript, etc.), and 
more.

node-nyc is a dependency of over 256 other projects (possibly as dev-dependency)
including (newer versions of?) node-mysql.

Bug#851877: fails every time

[Adam Borowski]

On Sat, Oct 06, 2018 at 11:38:59PM +0200, Santiago Vila wrote:
> I'd like to clarify that most probably there was only one bug here
> after all, namely, the one in schroot (#842634).

Well, that one hasn't been fixed, yet I can't seem to reproduce any of the
failures in sslh on any of my build machines anymore.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Bug#910476: Please drop usage of _SYSTEMCTL_SKIP_REDIRECT from init script

[Michael Biebl]

Package: ovn-controller-vtep
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-3
Severity: important

The init script /etc/init.d/ovn-controller-vtep uses
_SYSTEMCTL_SKIP_REDIRECT=true

This is an internal implementation detail of the systemd LSB hook and
should not be set in init scripts.

As a matter of fact, this variable was renamed in the mean time.

Skipping the redirection can have undesired side effects.
If you boot with systemd, then restart the service via
/etc/init.d/ovn-controller-vtep restart, the process will no longer be
tracked properly.

Therefor please drop the usage of _SYSTEMCTL_SKIP_REDIRECT from the init
script.

Regards,
Michael


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

Kernel: Linux 4.18.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 ovn-controller-vtep depends on:
ii  lsb-base9.20170808
pn  openvswitch-common  

ovn-controller-vtep recommends no packages.

ovn-controller-vtep suggests no packages.

Bug#908226: Unicode input does not actually input the selected symbol

[Gergely Nagy]

An additional data point: I upgraded to the latest Kitty in testing
today, and noticed a thing in the changelog:

 + Add support for IME via IBus, enabled by setting GLFW_IM_MODULE=ibus

So I exported that variable before starting kitty, and inputting unicode
works now. It does not pop up the symbol selection kitten, but lets me
enter the code (which is perfect, this is the same behaviour
gnome-terminal has).

As far as I'm concerned, this issue can be closed.

-- 
|8]

Bug#910475: Please drop usage of _SYSTEMCTL_SKIP_REDIRECT from init script

[Michael Biebl]

Package: ovn-host
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-3
Severity: important


The init script /etc/init.d/ovn-host uses
_SYSTEMCTL_SKIP_REDIRECT=true

This is an internal implementation detail of the systemd LSB hook and
should not be set in init scripts.

As a matter of fact, this variable was renamed in the mean time.

Skipping the redirection can have undesired side effects.
If you boot with systemd, then restart the service via
/etc/init.d/ovn-host restart, the process will no longer be tracked
properly.

Therefor please drop the usage of _SYSTEMCTL_SKIP_REDIRECT from the init
script.

Regards,
Michael


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

Kernel: Linux 4.18.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 ovn-host depends on:
ii  lsb-base9.20170808
pn  openvswitch-common  
pn  openvswitch-switch  

ovn-host recommends no packages.

ovn-host suggests no packages.

Bug#910474: Please drop usage of (_)SYSTEMCTL_SKIP_REDIRECT from init script

[Michael Biebl]

Package: openvswitch-switch
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-3
Severity: important

The init script /etc/init.d/openvswitch-switch uses
_SYSTEMCTL_SKIP_REDIRECT=true
SYSTEMCTL_SKIP_REDIRECT=true

This is an internal implementation detail of the systemd LSB hook and
should not be set in init scripts directly.

Skipping the redirection can have undesired side effects.
If you boot with systemd, then restart the service via
/etc/init.d/openvswitch-switch restart, the process will no longer be
tracked properly.

Therefor please drop the usage of (_)SYSTEMCTL_SKIP_REDIRECT from the init
script.

Regards,
Michael


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

Kernel: Linux 4.18.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 openvswitch-switch depends on:
ii  kmod25-1
ii  lsb-base9.20170808
ii  netbase 5.4
pn  openvswitch-common  
ii  procps  2:3.3.15-2
ii  python  2.7.15-3
ii  uuid-runtime2.32.1-0.1

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

Bug#910472: Please drop usage of _SYSTEMCTL_SKIP_REDIRECT from init script

[Michael Biebl]

Package: ovn-central
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-3
Severity: important

The init script /etc/init.d/ovn-central uses
_SYSTEMCTL_SKIP_REDIRECT=true

This is an internal implementation detail of the systemd LSB hook and
should not be set in init scripts.

As a matter of fact, this variable was renamed in the mean time.

Skipping the redirection can have undesired side effects.
If you boot with systemd, then restart the service via
/etc/init.d/ovn-central restart, the process will no longer be tracked
properly.

There please drop the usage of _SYSTEMCTL_SKIP_REDIRECT from the init
script.

Regards,
Michael


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

Kernel: Linux 4.18.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 ovn-central depends on:
ii  lsb-base9.20170808
pn  openvswitch-common  
pn  openvswitch-switch  

ovn-central recommends no packages.

ovn-central suggests no packages.

Bug#910473: firefox: Firefox crash error 6 in libxul.so

[Javier Barroso]

Package: firefox
Version: 62.0.3-1
Severity: important

Dear Maintainer (thank you maintaining firefox in Debian),

Time to time firefox crash, at dmesg it
[dom oct  7 00:16:05 2018] Chrome_~dThread[8853]: segfault at 0 ip
7fffedb315c1 sp 7fffeb952ad0 error 6
[dom oct  7 00:16:05 2018] Chrome_~dThread[8887]: segfault at 0 ip
7fffedb315c1 sp 7fffeb952ad0 error 6 in
libxul.so[7fffedb1d000+3b99000]
[dom oct  7 00:16:05 2018]  in libxul.so[7fffedb1d000+3b99000]
[dom oct  7 00:16:05 2018] Code:
[dom oct  7 00:16:05 2018] Code: 15 84
[dom oct  7 00:16:05 2018] 15 84 80
[dom oct  7 00:16:05 2018] 80 7d 04
[dom oct  7 00:16:05 2018] 7d 04 48
[dom oct  7 00:16:05 2018] 48 89 10
[dom oct  7 00:16:05 2018] 89 10
[dom oct  7 00:16:05 2018] c7
[dom oct  7 00:16:05 2018] c7 04
[dom oct  7 00:16:05 2018] 04 25 00
[dom oct  7 00:16:05 2018] 25 00 00
[dom oct  7 00:16:05 2018] 00 00
[dom oct  7 00:16:05 2018] 00
[dom oct  7 00:16:05 2018] 00 6e 09
[dom oct  7 00:16:05 2018] 00 6e 09
[dom oct  7 00:16:05 2018] 00 00 e8 71 5d ff ff 90 48 8b 05 61 d6 b4
05 48 8d 0d ca 80 7d 04 48 89
[dom oct  7 00:16:05 2018] 00 00 e8
[dom oct  7 00:16:05 2018] 08  04
[dom oct  7 00:16:05 2018] 71 5d ff
[dom oct  7 00:16:05 2018] 25 00
[dom oct  7 00:16:05 2018] ff
[dom oct  7 00:16:05 2018] 00 00
[dom oct  7 00:16:05 2018] 90
[dom oct  7 00:16:05 2018] 00 f4
[dom oct  7 00:16:05 2018] 48
[dom oct  7 00:16:05 2018] 09 00 00
[dom oct  7 00:16:05 2018] 8b 05 61
[dom oct  7 00:16:05 2018] e8 4f 5d
[dom oct  7 00:16:05 2018] d6 b4 05
[dom oct  7 00:16:05 2018] ff ff
[dom oct  7 00:16:05 2018] 48
[dom oct  7 00:16:05 2018] e8 2a f3
[dom oct  7 00:16:05 2018] 8d 0d ca
[dom oct  7 00:16:05 2018] ff ff 48
[dom oct  7 00:16:05 2018] 80 7d 04
[dom oct  7 00:16:05 2018] 48 89 08  04 25 00 00 00 00 f4 09 00 00
e8 4f 5d ff ff e8 2a f3 ff ff 48



After installing firefox-dbgsym, and running gdb:
$ gdb --args /usr/lib/firefox/firefox -safe-mode
GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/firefox/firefox...Reading symbols from
/usr/lib/debug/.build-id/f4/fd19976a4fd26bd5f254fad8f8e40f1e8e512f.debug...done.
done.
(gdb) set pagination off
(gdb) run
Starting program: /usr/lib/firefox/firefox -safe-mode
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb954700 (LWP 8591)]
[Thread 0x7fffeb954700 (LWP 8591) exited]
[New Thread 0x7fffeb954700 (LWP 8594)]
[New Thread 0x7fffeacff700 (LWP 8595)]
[New Thread 0x7fffe95a3700 (LWP 8596)]
[New Thread 0x7fffe5aff700 (LWP 8597)]
[New Thread 0x7fffe52fe700 (LWP 8598)]
[New Thread 0x7fffe4afd700 (LWP 8599)]
[New Thread 0x7fffe42fc700 (LWP 8600)]
[New Thread 0x7fffe3afb700 (LWP 8601)]
[New Thread 0x7fffe38fa700 (LWP 8602)]
[New Thread 0x7fffe36f9700 (LWP 8603)]
[New Thread 0x7fffe34f8700 (LWP 8604)]
[New Thread 0x7fffe2cff700 (LWP 8605)]
[New Thread 0x7fffe2afe700 (LWP 8606)]
[New Thread 0x7fffe1749700 (LWP 8607)]
[New Thread 0x7fffe0f48700 (LWP 8608)]
[New Thread 0x7fffe0747700 (LWP 8609)]
[New Thread 0x7fffe324f700 (LWP 8610)]
[New Thread 0x7fffdff46700 (LWP 8611)]

(firefox:8582): Gtk-WARNING **: 00:10:13.907: Theme parsing error:
:1:34: Expected ')' in color definition

(firefox:8582): Gtk-WARNING **: 00:10:13.907: Theme parsing error:
:1:77: Expected ')' in color definition
[New Thread 0x7fffdf5ff700 (LWP 8612)]
[New Thread 0x7fffdedfe700 (LWP 8613)]
[New Thread 0x7fffde5fd700 (LWP 8614)]
[New Thread 0x7fffdddfc700 (LWP 8615)]
[New Thread 0x7fffdd5fb700 (LWP 8616)]
[New Thread 0x7fffdcbff700 (LWP 8617)]
[New Thread 0x7fffdc3fe700 (LWP 8618)]
[Thread 0x7fffdcbff700 (LWP 8617) exited]
[New Thread 0x7fffdcbff700 (LWP 8619)]
[Thread 0x7fffdc3fe700 (LWP 8618) exited]
[New Thread 0x7fffdf745700 (LWP 8620)]
[New Thread 0x7fffdcdfa700 (LWP 8621)]
[New Thread 0x7fffdcdb9700 (LWP 8622)]
[New Thread 0x7fffdc3fe700 (LWP 8623)]
[Thread 0x7fffdddfc700 (LWP 8615) exited]
[Thread 0x7fffde5fd700 (LWP 8614) exited]
[Thread 0x7fffdedfe700 (LWP 8613) exited]
[Thread 0x7fffdc3fe700 (LWP 8623) exited]
[Thread 0x7fffe0747700 (LWP 8609) exited]
[Thread 0x7fffe0f48700 (LWP 8608) exited]
[Thread 0x7fffdd5fb700 (LWP 8616) exited]
[Thread 0x7fffe324f700 (LWP 8610) exited]
[Thread 0x7fffdff46700 (LWP 8611) exited]
[Thread 0x7fffdcbff700 (LWP 8619) exited

Bug#907539: gimp-python is required

[Eduardo M KALINOWSKI]

The same happened here, but installing gimp-python fixed this and made
the plugins available again.

I guess gimp-plugin-registry should depend on gimp-python.


-- 
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Bug#909288: transition: kdepim 18.08

[Sandro Knauß]

Hey,

> kmailtransport and other packages are in bd-uninst and outdated on several
> architectures because they need libkgapi which is blocked on the lack of
> qtwebengine5. So either one of those get an optional build-dep so things can
> build, or we'll need partial removals from the affected architectures. Can
> you look into it?

Okay so far as I followed the dependency graphs [1,2] thos bd-unist camoe from 
the new dependency between libkgapi ->  kmailtransport. I think it is save to 
remove the parts in kmailptransport that are libkgapi dependent, as this only 
handles the cases, when use want to send a mail via gmail/XAUTH2, where you 
really need libkgapi.

I'll try to upload a patch the next days. But I'm busy next week with sowing 
rye. But it should not be that difficult to make two blocks optional in 
plugins/smtp/smtpjob.cpp.

hefee

[1] https://qt-kde-team.pages.debian.net/images/pim-build-deps-17.12.png
[2] https://qt-kde-team.pages.debian.net/images/pim-build-deps-18.08.png


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

Bug#910471: Please drop usage of _SYSTEMCTL_SKIP_REDIRECT from init script

[Michael Biebl]

Package: galera-arbitrator-3
Version: 25.3.23-1
Severity: important

The init script /etc/init.d/garb uses
_SYSTEMCTL_SKIP_REDIRECT=true

This is an internal implementation detail of the systemd LSB hook and
should not be set in init scripts.

As a matter of fact, this variable was renamed in the mean time.

Please drop it in a future upload.

Thanks,
Michael


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

Kernel: Linux 4.18.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 galera-arbitrator-3 depends on:
pn  libboost-program-options1.62.0  
ii  libc6   2.27-6
ii  libgcc1 1:8.2.0-7
ii  libssl1.1   1.1.1-1
ii  libstdc++6  8.2.0-7
ii  lsb-base9.20170808

galera-arbitrator-3 recommends no packages.

galera-arbitrator-3 suggests no packages.

Bug#889890: firefox: unable to start running firefox in gdb even with firefox-dbgsym installed

[javibarroso]

On Thu, 8 Feb 2018 18:19:57 +0530 
=?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?= wrote:


> at bottom :-
>
> On 08/02/2018, Sylvestre Ledru wrote:
> > On 08/02/2018 12:08, shirish शिरीष wrote:
> >> Package: firefox
> >> Version: 58.0.1-1
> >> Severity: important
> >>
> >> Dear Maintainer,
> >>
> >> I am unable to run firefox under gdb, it gives out an error saying -
> >>
> >> Type "apropos word" to search for commands related to "word"...
> >> "/usr/bin/firefox": not in executable format: File format not 
recognized

> >>
> >> This is when firefox-esr is not running, only firefox running and have
> >> debug symbols of both versions .
> > firefox is a script, firefox-esr is a binary.
> > I guess this is the normal behavior of gdb here.
> >
> > (or I am missing the point)
> >
> > S
> >
>

> In that case, how do I get/run a session of gdb for firefox-58 ?

Test

gdb /usr/lib/firefox/firefox

(gdb) run

Regards,

Bug#842634: Bug#851877: fails every time

[Santiago Vila]

On Mon, 15 May 2017, Adam Borowski wrote:

> > Looking at /etc/hosts within the schroot, I see:
> > 127.0.0.1   localhost
> > 127.0.0.1   localhost ip6-localhost ip6-loopback
> > 172.28.17.11abel.debian.org abel
> > 
> > Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in being able
> > to reproduce the issue on other machines as well.
> 
> So it's a fully _reproducible_ bug, with a well-defined immediate cause
> (even if we haven't identified the indirect cause yet) -- unlike the
> original report by Santiago Villa.  Thus, it looks we have two different
> bugs that just happen to trigger the same failure mode.
> 
> And thus, even if we fix the schroot issue, Santiago's bug likely won't be
> fixed.

Hello everybody.

I'd like to clarify that most probably there was only one bug here
after all, namely, the one in schroot (#842634).

I initially reported this as "random" because I had a mix of
successful builds and failed builds, but most probably the
autobuilders in which it failed were always the same, the ones in
which the build succeeded were always the same, and I just failed to
recognize the pattern.

Fortunately you have found the real reason for the bug (while I was
missing from the discussion :-), and I believe this was the only
reason it failed for me last year.

Now a simple question: Do you think the workaround you prepared could
still be useful at all (I personally don't think so), or should I just
reassign this to schroot and use "affects"?

Thanks.

Bug#910470: parallel: Crashes on empty input when --shuf is used

[Etienne Dechamps]

Package: parallel
Version: 20161222-1
Severity: normal

Dear Maintainer,

To reproduce:

$ : | parallel --will-cite --shuf echo
Modification of non-creatable array value attempted, subscript -1 at
/usr/bin/parallel line 6359.

Basically, if there is no input (i.e. nothing to do) and --shuf is
used, parallel crashes. If the --shuf option isn't used, it correctly
does nothing and exits successfully.

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

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

Versions of packages parallel depends on:
ii  perl 5.26.2-7
ii  procps   2:3.3.15-2
ii  sysstat  12.0.1-1

parallel recommends no packages.

parallel suggests no packages.

-- no debconf information

Bug#824520: Just don't

[David Bremner]

Philippe Cerfon  writes:

> Hey Salvo.
>
>
> Well I've seen that discussion and upstream seems to be pretty hostile
> against distributions (and apparently security as well). :-(
>
> On the other hand, Debian now unfortunately lacks subsurface packages
> (while other distros have them, or at least more well integrating
> repos). So people may simply use the questionable packages provided by
> upstream (which are for the average user only secured by worthless
> https), which in turn may again decrease security for people.
>
> As you've said, libdivecomputer is probably not the problem, while
> it's already packaged for Debian, that version seems to be used by at
> least no package.
>
> And marble and libgit2: isn't libgit only used locally for storing the
> logs? Marble is of course an issue. it would be very sad if one could
> not longer see the dive sites on the globe. But better than nothing at
> all.
> Do you think it's difficult to get subsurface working with the
> official marble libs?
>

AFAIU, the current subsurface does not require libmarble.

I have packaged subsurface for my own use, using system git2, and
without the googleearth support. The only embedded library is
libdivecomputer.

I haven't had time to look carefully at how far from policy compliant
the package is, but there's obviously a few problems yet. And I don't
have any idea how hard it is to get the googlearth plugin working; it's
not a priority for me.

My work in progress is at

   https://salsa.debian.org/bremner/subsurface.git

For now, it works well enough for my needs. I'm happy to take merge
requests, and maybe consider uploading it to debian if it gets to a
decent state.

If you have dgit, devscripts and sbuild installed, you can build a
package with

git clone  https://salsa.debian.org/bremner/subsurface.git
cd subsurface
git deborig
dgit sbuild

d

Bug#910311: elpy FTBFS randomly: test elpy-promise-wait-should-return-early-for-resolved-promise fails

[Nicholas D Steeves]

Update 2: elpy-promise-wait-should-return-early-for-resolved-promise
fails 30% to 40% of the time in an schroot with Python 3.6.7rc1 as
/usr/bin/python3.  I changed the symlink to point to
/usr/bin/python3.7 (Python 3.7.1rc1) and this test passed 100% of the
time.  I ran the test 50 times.

I believe python3.6/3.6.7~rc1-1 is at fault (released Thu, 27 Sep 2018
11:51:25 +0200), because this test passes with 3.6.6-4 (from Sat, 01
Sep 2018 03:05:25 +0200).  This is the thing that changed in sid
(after Sept 4th) leading to the failure of
elpy-promise-wait-should-return-early-for-resolved-promise.

I'm contacting #debian-python about how to proceed.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#910443: gir-to-d FTBFS: Error: Expected argument to '-I'

[Helmut Grohne]

On Sat, Oct 06, 2018 at 08:35:44PM +0200, Matthias Klumpp wrote:
> This looks like a bug in Meson... I will take a look.

That wouldn't be the first one...

Though when comparing with the most recent logs from buildds, you spot:

... -I. -I.. -I../source/ -I -enable-color ...

This looks like meson recently added the = between flag and path and it
looks like you were trying to use ./-enable-color as an include
directory. So maybe it was buggy already, but it wasn't fatal until now.

If you reassign to meson, please don't forget "affects -1 +
src:gir-to-d".

Helmut

Bug#906315: spice: diff for NMU version 0.14.0-1.1

[Salvatore Bonaccorso]

Control: tags 906315 + pending


Dear maintainer,

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

Regards,
Salvatore
diff -Nru spice-0.14.0/debian/changelog spice-0.14.0/debian/changelog
--- spice-0.14.0/debian/changelog	2017-10-19 08:35:54.0 +0200
+++ spice-0.14.0/debian/changelog	2018-09-15 09:15:28.0 +0200
@@ -1,3 +1,10 @@
+spice (0.14.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix flexible array buffer overflow (CVE-2018-10873) (Closes: #906315)
+
+ -- Salvatore Bonaccorso   Sat, 15 Sep 2018 09:15:28 +0200
+
 spice (0.14.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru spice-0.14.0/debian/patches/Fix-flexible-array-buffer-overflow.patch spice-0.14.0/debian/patches/Fix-flexible-array-buffer-overflow.patch
--- spice-0.14.0/debian/patches/Fix-flexible-array-buffer-overflow.patch	1970-01-01 01:00:00.0 +0100
+++ spice-0.14.0/debian/patches/Fix-flexible-array-buffer-overflow.patch	2018-09-15 09:15:28.0 +0200
@@ -0,0 +1,68 @@
+From: Frediano Ziglio 
+Date: Fri, 18 May 2018 11:41:57 +0100
+Subject: Fix flexible array buffer overflow
+Origin: https://gitlab.freedesktop.org/spice/spice-common/commit/bb15d4815ab586b4c4a20f4a565970a44824c42c
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-10873
+Bug-Debian: https://bugs.debian.org/906315
+
+This is kind of a DoS, possibly flexible array in the protocol
+causes the network size check to be ignored due to integer overflows.
+
+The size of flexible array is computed as (message_end - position),
+then this size is added to the number of bytes before the array and
+this number is used to check if we overflow initial message.
+
+An example is:
+
+message {
+uint32 dummy[2];
+uint8 data[] @end;
+} LenMessage;
+
+which generated this (simplified remove useless code) code:
+
+{ /* data */
+data__nelements = message_end - (start + 8);
+
+data__nw_size = data__nelements;
+}
+
+nw_size = 8 + data__nw_size;
+
+/* Check if message fits in reported side */
+if (nw_size > (uintptr_t) (message_end - start)) {
+return NULL;
+}
+
+Following code:
+- data__nelements == message_end - (start + 8)
+- data__nw_size == data__nelements == message_end - (start + 8)
+- nw_size == 8 + data__nw_size == 8 + message_end - (start + 8) ==
+  8 + message_end - start - 8 == message_end -start
+- the check for overflow is (nw_size > (message_end - start)) but
+  nw_size == message_end - start so the check is doing
+  ((message_end - start) > (message_end - start)) which is always false.
+
+If message_end - start < 8 then data__nelements (number of element
+on the array above) computation generate an integer underflow that
+later create a buffer overflow.
+
+Add a check to make sure that the array starts before the message ends
+to avoid the overflow.
+
+Signed-off-by: Frediano Ziglio 
+Signed-off-by: Christophe Fergeau 
+[Salvatore Bonaccorso: Drop generated diff from commit messages causing
+ problem when applying with quilt. Remove addition to testsuite]
+---
+
+--- a/spice-common/python_modules/demarshal.py
 b/spice-common/python_modules/demarshal.py
+@@ -318,6 +318,7 @@ def write_validate_array_item(writer, co
+ writer.assign(nelements, array.size)
+ elif array.is_remaining_length():
+ if element_type.is_fixed_nw_size():
++writer.error_check("%s > message_end" % item.get_position())
+ if element_type.get_fixed_nw_size() == 1:
+ writer.assign(nelements, "message_end - %s" % item.get_position())
+ else:
diff -Nru spice-0.14.0/debian/patches/series spice-0.14.0/debian/patches/series
--- spice-0.14.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ spice-0.14.0/debian/patches/series	2018-09-15 09:15:28.0 +0200
@@ -0,0 +1 @@
+Fix-flexible-array-buffer-overflow.patch

Bug#910448: mgetty: CVE-2018-16741

[Andreas Barth]

* Salvatore Bonaccorso (car...@debian.org) [181006 21:21]:
> FTR, I think if feasible best would be to go for unstable (and thus
> buster) directly to 1.2.1, which will adress as well the other CVEs
> (which were no-dsa or unimportant).

That's the plan, yes.


Andi

Bug#907998: gimp: Gimp does not load or crashes quickly

[Luis Mochan]

Package: gimp
Version: 2.10.6-3
Followup-For: Bug #907998

I rebooted my system (several update/upgrade cycles since previous
reboot) and my problem seems to have disappeared. I do get the same warnings
messages related to some missing blab conversions, but now gimp seems to
proceed with it's work. Sorry for the noise.

Regards,
Luis


-- 

  o
W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
Apdo. Postal 48-3, 62251 |   (*)/\/  \
Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

Bug#910252: ITP: libnbcompat -- NetBSD compatibility library

[John Goerzen]

On Sat, Oct 06 2018, Guillem Jover wrote:

> I see the packages have already gone through NEW, so I've taken a
> look. And I've almost got mtree-netbsd building using just libmd and
> libbsd. I'll be releasing new upstream versions fixing or adding the
> missing stuff:
>
>   - libmd had bogus compat macros for SHA512, and missing ones for
> SHA384.

Hah - I was wondering about SHA512_File.  Looked odd to me, but I
figured something else must have that interface.

>   - libbsd is missing the pwcache modules from the BSDs, which I'll
> be adding.
>   - libbsd is missing a  that implicitly includes
> , I'll be adding that.
>
> Then I've got some minimal patches for mtree-netbsd, which fix or improve
> things there, that I'll be sending your way once I've finished with the
> above. At which point I think it would be nice to drop libnbcompat
> completely?

That would be great, especially if the mtree patches really are
minimal.

> I really think libnbcompat should be completely unnecessary. :) And if
> there'd be new features required my mtree-netbsd in the future I'm
> always happy to consider new additions to these libraries if they make
> sense!

Sounds great.  Appreciate it!

- John

>
> Thanks,
> Guillem

Bug#910448: mgetty: CVE-2018-16741

[Salvatore Bonaccorso]

Hi,

FTR, I think if feasible best would be to go for unstable (and thus
buster) directly to 1.2.1, which will adress as well the other CVEs
(which were no-dsa or unimportant).

Regards,
Salvatore

Bug#910469: fdupes 1.61 kernel panic segfaults version 1.51 is ok amd+intel 64bit

[Linuxonlinehelp]

Package: fdupes
Version: 1.51-1
Severity: important
Tags: lfs

Dear Maintainer,

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

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

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


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

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

Versions of packages fdupes depends on:
ii  libc6  2.27-6

fdupes recommends no packages.

fdupes suggests no packages.

-- no debconf information

Bug#910467: www.debian.org: security/2018/dsa-4309.wml points twice to CVE-2018-16151

[Salvatore Bonaccorso]

Hi,

On Sat, Oct 06, 2018 at 08:11:48PM +0200, Rafa wrote:
> Package: www.debian.org
> Severity: minor
> 
> Dear Maintainers,
> 
> Page security/2018/dsa-4309.wml points twice to CVE-2018-16151. It probably
> should point to CVE-2018-16151 and to CVE-2018-16152, instead.

Yes that is right, I have commited the following change:

https://salsa.debian.org/webmaster-team/webwml/commit/a5b7ec0c0184954ce50a1cba985b7f783185f781

Regards,
Salvatore

Bug#907998: gimp: Gimp does not load or crashes quickly

[Luis Mochan]

Package: gimp
Version: 2.10.6-3
Followup-For: Bug #907998

It seems I have the same problem. Gimp seems to hang forever when I
start it either from a terminal or from the menu. I read about
removing my personal GIMP configuration directory, but it didn't change
anything, and about removing libopenblas, but I don't have openblas
installed. I do have blas, though:
$ aptitude search blas|grep -E ^i
i A libblas-dev - Basic Linear Algebra Subroutines 3, static library
i A libblas3 - Basic Linear Algebra Reference implementations, shared library
i A libgslcblas0 - GNU Scientific Library (GSL) -- blas library package

Regards,
Luis


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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.6-3
ii  libaa1   1.4p5-44+b2
ii  libbabl-0.1-01:0.1.56-dmo1
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libfontconfig1   2.13.1-1
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-7
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgegl-0.4-01:0.4.8-dmo2
ii  libgexiv2-2  0.10.8-1
ii  libgimp2.0   2.10.6-3
ii  libglib2.0-0 2.58.1-2
ii  libgs9   9.25~dfsg-2
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b1.9.0-1
ii  libheif1 1.3.2-1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.2-1.3
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1:1.3.0-dmo6
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpangoft2-1.0-01.42.4-3
ii  libpng16-16  1.6.34-2
ii  libpoppler-glib8 0.63.0-2
ii  librsvg2-2   2.40.20-3
ii  libstdc++6   8.2.0-7
ii  libtiff5 4.0.9-6
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-12
ii  libx11-6 2:1.6.6-1
ii  libxcursor1  1:1.1.15-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.25~dfsg-2

Versions of packages gimp suggests:
pn  gimp-data-extras  
ii  gimp-help-en [gimp-help]  2.8.2-0.1
pn  gimp-python   
ii  gvfs-backends 1.38.0-2
ii  libasound21.1.6-1

-- no debconf information

-- 

  o
W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
Apdo. Postal 48-3, 62251 |   (*)/\/  \
Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

Bug#764678: dh-systemd: Please support systemd user services

[Daniele Nicolodi]

On 10/09/2018 09:07, Michael Biebl wrote:
> Am 10.09.18 um 16:47 schrieb Daniel Kahn Gillmor:
>> On Mon 2018-09-10 14:07:44 +0100, Simon McVittie wrote:
>>> It might be a reasonable middle ground for sockets and other
>>> auto-activation mechanisms to be statically enabled on the user bus, so
>>> that the services are not started eagerly, but are started on-demand?
>>
>> For the record, this is what the gpg-agent and dirmngr packages do.  It
>> would be great if it was well-supported by dh-systemd, instead of being
>> done manually in debian/dirmngr.links and debian/gpg-agent.links.
> 
> Work is being done on dh_installsystemduser
> Some bits have already landed in init-system-helpers [1] and there is an
> open MR for debhelper [2].
> Once that MR lands in debhelper, picking a package like gpg-agent and
> converting it to the new helper might be a good idea to give it some
> real world testing and shake out any bugs.
> 
> CCed Daniele, as he's been the one driving this effort.

Hello all,

I just found the time to rebase the debhelper patch [1]. It should be
ready to be merged now. As soon as a debhlper version with the patch
incorporated is release I will re-upload my dbus-broker package to
mentors.d.n to give the thing some real world exposure.

[1] https://salsa.debian.org/debian/debhelper/merge_requests/5

Cheers,
Dan

Bug#910468: pluto-sat-code: FTBFS: dh_installdocs: Cannot find (any matches for) "README.Debian" (tried in .)

[Andreas Beckmann]

Source: pluto-sat-code
Version: 0.0~git20180301-1
Severity: serious
Justification: fails to build from source

Hi,

pluto-sat-code FTBFS in an up-to-date sid+experimental pbuilder
environment, probably due to some changes in debhelper:

[...]
   dh_auto_test
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary
dh binary
   dh_testroot
   dh_prep
   dh_installdirs
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/pluto-sat-code-0.0~git20180301'
Not invoking makefile's install target
make[1]: Leaving directory '/build/pluto-sat-code-0.0~git20180301'
   dh_install
   dh_installdocs
dh_installdocs: Cannot find (any matches for) "README.Debian" (tried in .)

make: *** [debian/rules:10: binary] Error 2


Andreas


pluto-sat-code_0.0~git20180301-1.log.gz
Description: application/gzip

Bug#910443: gir-to-d FTBFS: Error: Expected argument to '-I'

[Matthias Klumpp]

Am Sa., 6. Okt. 2018 um 14:45 Uhr schrieb Helmut Grohne :
>
> Source: gir-to-d
> Version: 0.16.1-1
> Severity: serious
> Tags: ftbfs
>
> gir-to-d fails to build from source in sbuild on unstable/amd64. A build
> log ends with:
>
> | dh build --buildsystem=meson
> |dh_update_autotools_config -O--buildsystem=meson
> |dh_autoreconf -O--buildsystem=meson
> |dh_auto_configure -O--buildsystem=meson
> | cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
> --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
> --localstatedir=/var --libdir=lib/x86_64-linux-gnu 
> --libexecdir=lib/x86_64-linux-gnu
> | The Meson build system
> | Version: 0.48.0
> | Source dir: /<>
> | Build dir: /<>/obj-x86_64-linux-gnu
> | Build type: native build
> | Project name: GIR-to-D
> | Project version: 0.16.0
> | Appending DFLAGS from environment: '-O -g -release -wi'
> | Appending LDFLAGS from environment: '-Wl,-z,relro'
> | Native D compiler: ldc2 (llvm 1.11.0 "LDC - the LLVM D compiler (1.11.0):")
> | Build machine cpu family: x86_64
> | Build machine cpu: x86_64
> | Build targets in project: 2
> | Found ninja-1.8.2 at /usr/bin/ninja
> |dh_auto_build -O--buildsystem=meson
> | cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v
> | [1/20] /usr/bin/meson --internal vcstagger ../VERSION.in VERSION 0.16.0 
> /<> @VCS_TAG@ '(.*)' /<>/git describe --dirty=+ 
> --tags
> | [2/20] ldc2 -I=girtod@exe -I=. -I=.. -I=../source/ -I= -enable-color 
> -J/<>/obj-x86_64-linux-gnu -O -g -release -wi   
> -of='girtod@exe/source_girtod.d.o' -c ../source/girtod.d
> | FAILED: girtod@exe/source_girtod.d.o
> | ldc2 -I=girtod@exe -I=. -I=.. -I=../source/ -I= -enable-color 
> -J/<>/obj-x86_64-linux-gnu -O -g -release -wi   
> -of='girtod@exe/source_girtod.d.o' -c ../source/girtod.d
> | Error: Expected argument to '-I'
> | ninja: build stopped: subcommand failed.
> | dh_auto_build: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v 
> returned exit code 1
> | make: *** [debian/rules:8: build] Error 1
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2

This looks like a bug in Meson... I will take a look.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#904430: thunderbird: Saved passwords lost after upgrading from 1:52.9.1-1 to 60.0~b10-1 and Thunderbird won't ask password it needs

[intrigeri]

Hi,

FTR I've "solved" this by disabling the "GNOME Keyring integration"
add-on. Then I got asked for the missing passwords, which was not the
best upgrade path ever, but at least I have a working Thunderbird
again :)

Cheers,
-- 
intrigeri

Bug#909848: lame: symbol lookup error: lame: undefined symbol: lame_get_maximum_number_of_samples

[Marc Lehmann]

On Sat, Sep 29, 2018 at 05:21:14PM +0300, Adrian Bunk  wrote:
> > Versions of packages lame depends on:
> >...
> > ii  libmp3lame0  1:3.99.5-dmo6
> >...
> 
> Fix:
>   apt-get install libmp3lame0=3.100-2+b1

Maybe I am confused, but shouldn't debian packages declare proper
dependencies? The above command only fixes this on my system (where it is
already fixed), not in the actual package which didn't have the proper
dependency (assuming I didn't hit an apt-get bug).

Greetings,

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#910467: www.debian.org: security/2018/dsa-4309.wml points twice to CVE-2018-16151

[Rafa]

Package: www.debian.org
Severity: minor

Dear Maintainers,

Page security/2018/dsa-4309.wml points twice to CVE-2018-16151. It probably
should point to CVE-2018-16151 and to CVE-2018-16152, instead.

Regards,

Rafa.



signature.asc
Description: PGP signature

Bug#910466: quassel-irssi: FTBFS with gcc-8

[Andreas Beckmann]

Source: quassel-irssi
Version: 0~git20180408-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

quassel-irssi FTBFS in an up-to-date sid+experimental pbuilder environment,
probably due to the switch of the default compiler to gcc-8.

 debian/rules build
dh build
   dh_update_autotools_config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/quassel-irssi-0~git20180408'
/usr/bin/make -C core
make[2]: Entering directory '/build/quassel-irssi-0~git20180408/core'
cc -std=gnu11 -Wall -Wextra -Werror -g -O2 -I/usr/include/irssi//src/ 
-I/usr/include/irssi//src/core/ -I/usr/include/irssi//src/fe-common/ 
-I/usr/include/irssi//src/fe-common/core/ -I/usr/include/irssi//src/fe-tex
t/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-DUOFF_T_LONG -fPIC -DHAVE_OPENSSL -I/usr/include/quasselc -Wmissing-prototypes 
-Wmissing-declarations  -Wdate-time -D_FORTIFY_SOURCE=2  -c -
o quasselc-connector.o quasselc-connector.c
cc -std=gnu11 -Wall -Wextra -Werror -g -O2 -I/usr/include/irssi//src/ 
-I/usr/include/irssi//src/core/ -I/usr/include/irssi//src/fe-common/ 
-I/usr/include/irssi//src/fe-common/core/ -I/usr/include/irssi//src/fe-tex
t/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-DUOFF_T_LONG -fPIC -DHAVE_OPENSSL -I/usr/include/quasselc -Wmissing-prototypes 
-Wmissing-declarations  -Wdate-time -D_FORTIFY_SOURCE=2  -c -
o quassel-core.o quassel-core.c
cc -std=gnu11 -Wall -Wextra -Werror -g -O2 -I/usr/include/irssi//src/ 
-I/usr/include/irssi//src/core/ -I/usr/include/irssi//src/fe-common/ 
-I/usr/include/irssi//src/fe-common/core/ -I/usr/include/irssi//src/fe-text/ 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-DUOFF_T_LONG -fPIC -DHAVE_OPENSSL -I/usr/include/quasselc -Wmissing-prototypes 
-Wmissing-declarations  -Wdate-time -D_FORTIFY_SOURCE=2  -c -o quassel-net.o 
quassel-net.c
quassel-net.c: In function 'sig_connected':
quassel-net.c:110:8: error: cast between incompatible function types from 'void 
(*)(Quassel_SERVER_REC *)' {aka 'void (*)(struct Quassel_SERVER_REC_s *)'} to 
'void (*)(void *, GIOChannel *, int)' {aka 'void (*)(void *, struct _GIOChannel 
*, int)'} [-Werror=cast-function-type]
(GInputFunction) quassel_parse_incoming, r);
^
In file included from /usr/include/irssi//src/core/commands.h:4,
 from quassel-net.c:25:
quassel-net.c: In function 'quassel_net_init':
quassel-net.c:161:39: error: cast between incompatible function types from 
'void (*)(Quassel_SERVER_REC *)' {aka 'void (*)(struct Quassel_SERVER_REC_s 
*)'} to 'void (*)(const void *, const void *, const void *, const void *, const 
void *, const void *)' [-Werror=cast-function-type]
  signal_add_first("server connected", (SIGNAL_FUNC) sig_connected);
   ^
/usr/include/irssi//src/core/signals.h:23:78: note: in definition of macro 
'signal_add_first'
  signal_add_full(MODULE_NAME, SIGNAL_PRIORITY_HIGH, (signal), (SIGNAL_FUNC) 
(func), NULL)
  
^~~~
cc1: all warnings being treated as errors
make[2]: *** [: quassel-net.o] Error 1
make[2]: Leaving directory '/build/quassel-irssi-0~git20180408/core'
make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2
make[1]: Leaving directory '/build/quassel-irssi-0~git20180408'
make: *** [debian/rules:12: build] Error 2


Andreas


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

Bug#909848: lame: symbol lookup error: lame: undefined symbol: lame_get_maximum_number_of_samples

[Adrian Bunk]

On Sat, Oct 06, 2018 at 08:02:18PM +0200, Marc Lehmann wrote:
> On Sat, Sep 29, 2018 at 05:21:14PM +0300, Adrian Bunk  wrote:
> > > Versions of packages lame depends on:
> > >...
> > > ii  libmp3lame0  1:3.99.5-dmo6
> > >...
> > 
> > Fix:
> >   apt-get install libmp3lame0=3.100-2+b1
> 
> Maybe I am confused, but shouldn't debian packages declare proper
> dependencies? The above command only fixes this on my system (where it is
> already fixed), not in the actual package which didn't have the proper
> dependency (assuming I didn't hit an apt-get bug).

The dependencies are correct.

What you say is only true for packages that are (or were) in Debian.

Debian has no control over packages and their versions in 3rd party 
repositories hosted elsewhere, and problems that are caused by by 
installing such 3rd party packages are out of scope of what is supported 
by Debian.

> Greetings,

cu
Adrian

-- 

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

Bug#682369: firefox-esr disobeys "until I close Firefox" cookie setting

[Sven Joachim]

On 2016-12-12 19:52 -0500, Robert Munyer wrote:

> Control: retitle -1 firefox-esr disobeys "until I close Firefox" cookie 
> setting
> Control: reassign -1 firefox-esr 45.5.1esr-1
>
> Bug still present in firefox-esr 45.5.1esr-1, in Debian "stretch".
> To replicate:
>
> Open Firefox ESR.
>
> Configure Firefox thus:
>   ≡
> Preferences
>   Privacy
> History
>   Firefox will: Use custom settings for history
> Accept cookies from sites
>   Keep until: I close Firefox
>
> Browse to http://noscript.net/features .
>
> Click the "Go back one page" button.
>
> Close Firefox.
>
> After the preceding steps, the cookie must not exist.
> To see that it does exist, continue with the following steps:
>
> Open Firefox ESR.
>
> Click "Restore Previous Session".
>
> View cookies:
>   ≡
> Preferences
>   Privacy
> History
>   Show Cookies...

Basically that's the way session restore works, and I have always seen
this as a feature rather than a bug, although that is certainly
debatable.  Some upstream discussions:

https://bugzilla.mozilla.org/show_bug.cgi?id=443354
https://bugzilla.mozilla.org/show_bug.cgi?id=529644
https://bugzilla.mozilla.org/show_bug.cgi?id=530594
https://bugzilla.mozilla.org/show_bug.cgi?id=1286748

Cheers,
   Sven

Bug#910465: makedumpfile: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: makedumpfile
Version: 1_1.6.4-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for makedumpfile's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


makedumpfile_1_1.6.4-2_pt.po.gz
Description: application/gzip

Bug#903656: stretch-pu: package publicsuffix/20180523.2326-0+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2018-07-12 at 12:27 -0400, Daniel Kahn Gillmor wrote:
> On Thu 2018-07-12 11:25:58 -0400, d...@fifthhorseman.net wrote:
> > Please consider an update to publicsuffix in debian stretch.
> > 
> > This package reflects the state of the network, and keeping it
> > current is useful for all the packages that depend on it.
> > 
> > The debdiff from the previous version in stretch is not attached
> > because it was being rejected as spam.
> > 
> > This proposed release is also available at the
> > "publicsuffix_debian/20180523.2326-0+deb9u1" tag on the
> > "debian/stretch" branch at
> > the git repo for publicsuffix packaging:
> > 
> > https://salsa.debian.org/debian/publicsuffix
> > 
> > Please followup on this ticket to confirm whether I should upload
> > this
> > revision to stretch.
> 
> I've tried multiple times now to attach the debdiff to this bug
> report,
> and it continues to be rejected as spam by bugs.debian.org with this
> message:
> 
>  <903...@bugs.debian.org>: host buxtehude.debian.org[209.87.16.39]
> said: 550
>  malware detected: Sanesecurity.Jurlbl.db3039.UNOFFICIAL: message
> rejected
>  (in reply to end of DATA command)

I'd be interested to know if that's still the case. Does changing the
compression format help?

Please go ahead.

Regards,

Adam

Bug#910276: mksh does never execute an "EXIT trap", if it is created with the "trap" command in a sub shell

[Thorsten Glaser]

Hello Bernd,

> So this means for me, I will not support mksh in my library.
>
> If you think this bug does not help to improve mksh, it's probably the best if
> you close the bug.

you seem to have completely misunderstood my last eMail.

I said:

1. I cannot say yet if it’s a bug or not.
2. I will change mksh to work like the other shells,
   independent of whether it’s a bug or not,
   which means you *will* be able to support it.

Does this help or do we need to switch languages? ;-)

bye,
//mirabilos
-- 
17:57 < jtsn> Der 25C3 ist lustig. Deutsche Vortragende brechen sich vor
deutschen Zuhörern auf Englisch einen ab. ;-)  18:01 < jtsn> Adolfs Werk
war sehr nachhaltig. ;-)18:01 < jtsn> Das gab's nichtmal in der DDR,
das Deutsche mit Deutschen auf Russisch reden. ;-)  (10x cnuke@)

Bug#908388: ublock-origin 1.16.14+dfsg-2~deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ublock-origin
Version: 1.16.14+dfsg-2~deb9u1

Explanation: backport new upstream version, for compatibility with Firefox ESR 
60

Bug#908389: https-everywhere 2018.8.22-1~deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: https-everywhere
Version: 2018.8.22-1~deb9u1

Explanation: backport new upstream version, for compatibility with Firefox ESR 
60

Bug#908388: ublock-origin 1.16.14+dfsg-1~deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ublock-origin
Version: 1.16.14+dfsg-1~deb9u1

Explanation: backport new upstream version, for compatibility with Firefox ESR 
60

Bug#893749: stretch-pu: package easytag/2.4.3-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2018-09-25 at 10:11 +0100, James Cowgill wrote:
> Control: tags -1 - moreinfo
> 
> Hi,
> 
> Sorry for the delay. I completely forgot about this bug!
> 
> I've attached v2 of the patch to fix #855251. After submitting the
> original stretch-pu bug, I discovered (after someone mentioned this
> on
> the upstream bug report) the root cause and reverted the relevant
> upstream commit. This fix has been in unstable since 2.4.3-4 (about 7
> months) without any issues. I've done some brief testing of in a
> stretch
> build and it seems to work fine there as well.
> 

Please go ahead.

Regards,

Adam

Bug#893439: stretch-pu: package gnucash/1:2.6.15-1+deb9u1

[Adam D. Barratt]

László: ping?

On Mon, 2018-04-02 at 15:20 +0200, Julien Cristau wrote:
> On Mon, Apr  2, 2018 at 14:51:54 +0300, Adrian Bunk wrote:
> 
> > Control: tags -1 -moreinfo
> > 
> > On Mon, Apr 02, 2018 at 01:05:39PM +0200, Julien Cristau wrote:
> > > Control: tag -1 moreinfo
> > > 
> > > On Sun, Mar 18, 2018 at 22:07:25 +0200, Adrian Bunk wrote:
[...]
> > > libdbi 0.9.0-4+deb9u1 broke gnucash tests, runtime issues
> > > > with this backend were so far not reported but are not
> > > > unlikely.
[...]
> So the other option here would be to revert the libdbi change.  As
> far as I can tell from #880896 it wasn't prompted by a specific
> problem, so a revert there might be the safest course of action and
> sidesteps the gnucash issue.  László, any thoughts?
> 
> Cheers,
> Julien

Bug#910458: gnome-user-docs FTBFS: 'NoneType' object has no attribute '__getitem__'

[Jeremy Bicha]

On Sat, Oct 6, 2018 at 11:27 AM Adrian Bunk  wrote:
> touch "zh_CN/zh_CN.stamp"
> Error: Could not merge translations:
> 'NoneType' object has no attribute '__getitem__'
> make[2]: *** [Makefile:851: ta/ta.stamp] Error 1

Could you request a give-back? Maybe there's a parallel building problem?

It's weird because we never used to have a problem here.

Thanks,
Jeremy Bicha

Bug#891566: stretch-pu: package fastforward/1:0.51-3.1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-02-26 at 20:09 +0200, Adrian Bunk wrote:
>    * Add patch from Harry Sintonen to fix segfaults on 64bit.
>  (Closes: #859327)

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#884561: stretch-pu: package pam-krb5-migrate/0.0.11-4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-04-02 at 12:35 +0200, Julien Cristau wrote:
> On Sat, Mar 31, 2018 at 20:53:05 +0200, Dominik George wrote:
> 
> > > Also, when did this break?
> > 
> > I do not know. I adopted the package after the stretch release.
> > 
> 
> So it looks to me like the libpam-krb5-migrate-heimdal package in
> oldoldstable has that file in the right place, then it moved
> somewhere between then and oldstable.

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#886146: stretch-pu: package sqlcipher/3.2.0-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2018-04-18 at 14:29 +0200, Gianfranco Costamagna wrote:
> > Can you please also describe what if any testing was done on the
> > proposed update, and why this breakage wasn't caught before
> > release?
> 
> this has been explained in this bug, message 29, do you think it is
> enough or
> do you want any more testing? (also testing has been performed in
> 863530#25 )

Well, it's not exactly extensive testing for regressions, which is what
we're more interested in for cases such as this.

On the presumption that no issues have been reported since the relevant
unstable upload, please go ahead.

Regards,

Adam

Bug#909119: stretch-pu: package vagrant/1.9.1+dfsg-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2018-09-18 at 10:22 -0700, Antonio Terceiro wrote:
> vagrant from stretch currently refuses to work with VirtualBox 5.2
> from
> stretch-backports. This update just backports the few changes needed
> to
> make it work. The changes are pretty trivial.
> 
> VirtualBox is not in stretch, so users are getting it either from
> stretch-backports or from upstream's .deb package; without this
> update
> vagrant will most likely be broken for most VirtualBox users. It
> would
> be nice if we can release this update.
> 

Please go ahead.

Regards,

Adam

Bug#893033: bsdmainutils: "look" can't look in block devices or files bigger than 2GiB

[Tomaž Šolc]

Hi

I stumbled upon the same file size limitation of "look" today
(incidentally, doing a similar thing as Stephane).

I believe the bug in the file size check can be fixed by patching the
Makefile so that the correct define is used. SIZE_MAX was introduced in
C99 for this purpose:

--- a/usr.bin/look/Makefile 2017-12-29 10:02:09.0 +0100
+++ b/usr.bin/look/Makefile 2018-10-06 17:36:49.010093578 +0200
@@ -1,6 +1,6 @@
 PROG = look
 LIBS += -lbsd
-FLAGS = -include bsd/err.h -DSIZE_T_MAX=INT_MAX
+FLAGS = -include bsd/err.h -DSIZE_T_MAX=SIZE_MAX

 topdir=../..
 include $(topdir)/config.mk

After a quick look at the code I couldn't find any problems with that.
All relevant variables indeed seem to be using size_t, not int.

"look" from bsdmainutils 11.1.2 with this patch applied on Debian
Stretch seems to work as expected on a file roughly 22 GiB in size. It
will correctly find lines at the start as well as at the end of the file.

Best regards
Tomaž

Bug#910065: stretch-pu: package libmail-deliverystatus-bounceparser-perl/1.542-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2018-10-02 at 11:10 +0200, Xavier Guimard wrote:
> libmail-deliverystatus-bounceparser-perl contains some viruses in its
> tests files (#864800). This update proposes to clean sources.
> 
> Since debdiff contains virus signatures, it can not be embedded here
> (rejected by SMTP server). I put it on qa.debian.org server:
> /home/yadd/libmail-deliverystatus-bounceparser-perl_1.542-1.debdiff

+libmail-deliverystatus-bounceparser-perl (1.542+deb9u1-1) stable-
proposed-updates; urgency=medium

The version there is odd. Normally it would be 1.5242-1+deb9u1. Is this
an attempt to indicate that the source tarball has changed, i.e. a  new
"upstream" version? If so, I'd prefer 1.542+repacked-1~deb9u1, as a
backport from unstable, with the changes that don't immediately look
appropriate reverted:

   * Declare compliance with policy 4.2.1
   * Remove dependency to libtest-simple-perl (>= 0.94)
   * Bump debhelper compatibility to 10

As an additional note, the preferred changelog distribution is simply
"stretch".

Regards,

Adam

Bug#910432: xserver-xorg-video-amdgpu: Cannot rebuild using dpkg-buildpackage

[Teppo Maenpaa]

On Sat, Oct 06, 2018 at 11:10:12AM +0200, Sven Joachim wrote:


Note that you can obtain debugging symbols from the debug mirror, e.g. put
deb http://debug.mirrors.debian.org/debian-debug/ unstable-buster main
in /etc/apt/sources.list.


Thanks.


I cannot reproduce that.


Motivated by that, I upgraded another one to buster and cannot reproduce 
either on the other PC. The bug description of this ticket must be wrong.


Now I can continue with both issues (=the "X wont start" part, and what prevents 
building).


I vote for closing this ticket as stupid user error.

Regards and thanks for the quick response,


Teppo

Bug#910464: octave-interval FTBFS: Makefile.am: error: required file './depcomp' not found

[Adrian Bunk]

Source: octave-interval
Version: 3.2.0-2
Severity: serious
Tags: ftbfs

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

...
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
(cd src/crlibm ; autoreconf)
Makefile.am: error: required file './depcomp' not found
Makefile.am:   'automake --add-missing' can install 'depcomp'
autoreconf: automake failed with exit status: 1
make[1]: *** [debian/rules:41: override_dh_auto_configure] Error 1

Bug#910459: [Pkg-openssl-devel] Bug#910459: Bug#910459: openssl: broken autopkgtest

[Kurt Roeckx]

On Sat, Oct 06, 2018 at 06:19:32PM +0200, Kurt Roeckx wrote:
> On Sat, Oct 06, 2018 at 12:36:44PM -0300, Antonio Terceiro wrote:
> > Source: openssl
> > Version: 1.1.1-1
> > Severity: normal
> > Tags: patch
> > 
> > The autopkgtests for openssl are currently broken due to a set of typos:
> 
> This should already be fixed in git.

But this fix was:
diff --git a/debian/tests/25-test-verify.t b/debian/tests/25-test_verify.t
similarity index 100%
rename from debian/tests/25-test-verify.t
rename to debian/tests/25-test_verify.t
diff --git a/debian/tests/run-25-test_verify b/debian/tests/run-25-test-verify
similarity index 100%
rename from debian/tests/run-25-test_verify
rename to debian/tests/run-25-test-verify

I think a _ is not allowed in the name or something.


Kurt

Bug#910276: mksh does never execute an "EXIT trap", if it is created with the "trap" command in a sub shell

[bernd]

Thank You Thorsten,

I hoped, it would be obvious that this is a bug and mksh could be fixed.
It is strange, that mksh lets me define an exit trap without error,  
but then ignores the trap.

But things seem not to be so easy.

I think the use case of the "subshell_exit" is obvious.
But I will describe it in one sentence, to explain, why I think this  
bug matters.

The use case: If a subshell does something, that requires a temporary file,
it should also define an EXIT trap, to make sure the temporary file is  
deleted,

if the script ends unexpected.

The problem is, I see no easy workaround.
So this means for me, I will not support mksh in my library.

If you think this bug does not help to improve mksh, it's probably the  
best if you close the bug.


Thank you for your help. You have also added some other shells to your  
tests, that I did not try before.

And I will try to support some of those shells instead of mksh.

Regards
Bernd


Zitat von Thorsten Glaser :


Bernd Schumacher dixit:


Please confirm, that this is a bug and not the expected behaviour of mksh.


I still cannot confirm either way, but some preliminary research
with an extended test script:

$ cat script
fkt()
{
  trap -- "echo $1 >&2" EXIT
}
fkt shell_exit
$(fkt fn_exit)
$(trap -- "echo comsub_exit >&2" EXIT)
(trap -- "echo subshell_exit >&2" EXIT)

$ mksh script
shell_exit

$ bash2.05b script
subshell_exit
shell_exit

$ ksh93 script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ bash4 script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ nbsh script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ dash script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ yash script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ zsh script
shell_exit
fn_exit
comsub_exit
subshell_exit

$ zsh --emulate sh script
fn_exit
comsub_exit
subshell_exit
shell_exit


With the addition of subshell_exit (I renamed yours in fn_exit),
it’s consistent with no other shell I have, not even GNU bash 2.05b
(Heirloom Shell doesn’t know of the EXIT trap, and I’m ignoring
the C shell). zsh is a notable outlyer but easily fixed.

The manual page has something to say about EXIT traps defined in
functions declared using “function foo { … }” (Korn Shell syntax),
but that’s not used here.

I think that I’ll adapt it to the other shells independent of
whether it’s really a bug or not, for the sake of consistency.
If you’re still interested in semantics, I can continue the
research, though.

bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2





binSUznWKU4Zn.bin
Description: Öffentlicher PGP-Schlüssel

Bug#910459: [Pkg-openssl-devel] Bug#910459: openssl: broken autopkgtest

[Kurt Roeckx]

On Sat, Oct 06, 2018 at 12:36:44PM -0300, Antonio Terceiro wrote:
> Source: openssl
> Version: 1.1.1-1
> Severity: normal
> Tags: patch
> 
> The autopkgtests for openssl are currently broken due to a set of typos:

This should already be fixed in git.


Kurt

Bug#910462: inspircd: New upstream release 2.0.26

[Christoph Biedl]

Source: inspircd
Version: 2.0.24-1.1
Severity: wishlist

Dear Maintainer,

upstream made another release recently, so Debian is now two releases
behind. Unless there's good reason against it, I'm asking you to upload
an updated Debian package, before buster freeze the latest. If you need
help with that, let me know.

Only for the sake of closing the gap to upstream I might also "salvage"
inspircd in a few weeks, the new process as described in
https://wiki.debian.org/PackageSalvaging

All the best,

Christoph

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

Kernel: Linux 4.18.11 (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: unable to detect



signature.asc
Description: PGP signature

Bug#910463: os-autoinst FTBFS on !x86/ppc64{,el}: test failure

[Adrian Bunk]

Source: os-autoinst
Version: 4.5.1527308405.8b586d5-2
Severity: serious
Tags: ftbfs

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

...
ok 1 - test executed fine
ok 2 - Snapshots are enabled
ok 3 - Wait idle waits for a second.
ok 4 - test type string and do not wait
ok 5 - test type string and wait for 5 seconds
ok 6 - test type string and wait for 10 seconds
ok 7 - test type string and wait for 20 seconds
ok 8 - get_test_data test
not ok 9 - save_tmp_file test
#   Failed test 'save_tmp_file test'
#   at ./99-full-stack.t line 68.
#  got: '256'
# expected: '0'
not ok 10 - Result in testresults/result-boot.json is ok
#   Failed test 'Result in testresults/result-boot.json is ok'
#   at ./99-full-stack.t line 73.
#  got: 'fail'
# expected: 'ok'
Bail out!  testresults/result-boot.json failed
FAIL 99-full-stack.t (exit status: 255)


Testsuite summary for os-autoinst 1.1.0

# TOTAL: 18
# PASS:  17
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See t/test-suite.log
Please report to https://github.com/os-autoinst/os-autoinst

make[5]: *** [Makefile:530: test-suite.log] Error 1

Bug#910461: ITP: r-cran-paramhelpers -- GNU R helpers for parameters in black-box optimization and tuning

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-paramhelpers
  Version : 1.11
  Upstream Author : Bernd Bischl,
* URL : https://cran.r-project.org/package=ParamHelpers
* License : BSD-2-clause
  Programming Lang: GNU R
  Description : GNU R helpers for parameters in black-box optimization and 
tuning
 Functions for parameter descriptions and operations in black-box
 optimization, tuning and machine learning. Parameters can be described
 (type, constraints, defaults, etc.), combined to parameter sets and can in
 general be programmed on. A useful OptPath object (archive) to log function
 evaluations is also provided.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-paramhelpers

Bug#902507: node-multiparty: FTBFS in buster/sid (TypeError: mime.lookup is not a function)

[Petter Reinholdtsen]

I had a closer look, and became more confused.  First some background
information: The mime library renamed lookup() to getType, while the
mime-types library in sid seem to still provide the lookup() method.

This build problemseem to be caused by a test depending on form-data.js in
the node-form-data package, which expect a mime library with the lookup()
function.  One way to fix this would be to convince form-data.js to use
the mime-types library, but I am unable to find out which library is
actually used and how it is pulled in.

A fix would be to change the code in node-form-data to use getType()
instead of lookup(), but it make more sense if a dependency of
node-form-data could be updated to reflect the changed requirement, to
version 2 of the node-mime library. The problem is that node-form-data
do not (build-)depend on any node-mime* library I can see.  What is
going on here?  What is the best fix for this?

In any case, I suspect this bug should be reassigned node-form-data or
split in two, one for node-multiparty and one for node-form-data.
But given that I have not been able to figure out exactly where
a mime* library is loaded, I do not know where the bug really is
located.

-- 
Happy hacking
Petter Reinholdtsen

Bug#910460: ITP: r-cran-parallelmap -- GNU R unified interface to parallelization back-ends

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-parallelmap
  Version : 1.3
  Upstream Author : Bernd Bischl , Michel Lang
* URL : https://cran.r-project.org/package=parallelMap
* License : BSD-2-clause
  Programming Lang: GNU R
  Description : GNU R unified interface to parallelization back-ends
 Unified parallelization framework for multiple back-end,
 designed for internal package and interactive usage.
 The main operation is a parallel "map" over lists.
 Supports local, multicore, mpi and BatchJobs mode.
 Allows "tagging" of the parallel operation
 with a level name that can be later selected by the user to
 switch on parallel execution for exactly this operation.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-parallelmap

Bug#910459: openssl: broken autopkgtest

[Antonio Terceiro]

Source: openssl
Version: 1.1.1-1
Severity: normal
Tags: patch

The autopkgtests for openssl are currently broken due to a set of typos:

blame: openssl
badpkg: debian/tests/run-25-test-verify does not exist
autopkgtest [15:01:50]: ERROR: erroneous package: 
debian/tests/run-25-test-verify does not exist

The attached patch fixes the issue.

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

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

-- no debconf information
diff -ru openssl-1.1.1.orig/debian/tests/control openssl-1.1.1/debian/tests/control
--- openssl-1.1.1.orig/debian/tests/control	2018-10-06 12:20:35.478677306 -0300
+++ openssl-1.1.1/debian/tests/control	2018-10-06 12:20:43.282657838 -0300
@@ -1,3 +1,3 @@
-Tests: run-25-test-verify
+Tests: run-25-test_verify
 Depends: openssl, perl
 Restrictions: rw-build-tree, allow-stderr
diff -ru openssl-1.1.1.orig/debian/tests/run-25-test_verify openssl-1.1.1/debian/tests/run-25-test_verify
--- openssl-1.1.1.orig/debian/tests/run-25-test_verify	2018-10-06 12:20:35.478677306 -0300
+++ openssl-1.1.1/debian/tests/run-25-test_verify	2018-10-06 12:21:18.102557968 -0300
@@ -5,4 +5,4 @@
 export BIN_D=/usr/bin/
 export SRCTOP=../../
 export BLDTOP=./aa
-exec perl -I. 25-test_verify.t
+exec perl -I. 25-test-verify.t


signature.asc
Description: PGP signature

Bug#910454: Acknowledgement (mysql-server: Restoring backup hangs for a large database)

[Matthew Toseland]

Sorry, bug is a -EPEBCAK. The disk was full, as can be seen in 
/var/log/daemon.log. Thanks Oleg!

Bug#910433: thunderbird: Open hyperlink and attachments in system default applications not working

[Johannes Rohr]

It is not just an issue of the web browser. It is that all file type
associations are being ignored.

If you go to "Settings/Attachments" (Einstellungen/Attachments/Empfang),
the window is empty.

And this remains the case with a virgin profile.

Bug#910433: thunderbird: Open hyperlink and attachments in system default applications not working

[Carsten Schoenert]

Am 06.10.18 um 16:12 schrieb Johannes Rohr:
> Now I tested the same profile on a recent Ubuntu with TB 52, and there 
> is no problem, so this seems to be a Debian specific issue, unrelated to 
> the user's configuration.

Yes and no.
For me this is just indicating that this is not a problem of Thunderbird
on Debian itself. Also comparing TB 52 with 60 doesn't say much.
As long as you don't have any special setting in your profile settings
Thunderbird is doing a "fallback' to the system defaults.

You seems to have more problem of your global configuration.

Please have a look at

https://wiki.debian.org/HOWTO/DefaultWebBrowser

Or you have some manual entries within your mimeTyps.rdf file within
your profile somehow.

Try

  $ thunderbird --fixmime

But there shouldn't be anything as you say you can use the profile on
another system.

-- 
Regards
Carsten Schoenert

Bug#909267: library-not-linked-against-libc: downgrade from error

[Guillem Jover]

Hi!

On Thu, 2018-09-20 at 17:19:02 -0700, Russ Allbery wrote:
> Jeremy Bicha  writes:
> > On Thu, Sep 20, 2018 at 6:18 PM Russ Allbery  wrote:
> >> Maybe exclude shared libraries linked with glib (and whatever the Qt
> >> equivalent is)?
> 
> > One package that triggers this tag a lot is samba and it doesn't use
> > glib or qt.
> 
> > https://lintian.debian.org/maintainer/pkg-samba-ma...@lists.alioth.debian.org.html#samba
> 
> I wonder if we would get all of the utility out of the tag if instead it
> looked for shared libraries with no NEEDED metadata.  I think it's only
> catching libraries that aren't linked with anything else, so maybe just
> check for that explicitly?

Yeah probably better than the status-quo. Any kind of plugin would need
to be excluded though, because it might simply be using symbols from the
loading binary (via -rdynamic). It would still emit false-positives for
any library that implements language run-times or does syscall wrapping.
This might include any new language implementing their own lib.so
and not basing that on libc.so, or even things like libaio.so, which for
a while did not need to be linked against libc! (Although for probably
bad reasons, because reimplementing syscall(2) is not very sane, or
even using _syscall(2) which might have not pulled the dep. :)

So, I'd say the trade-off is worth it, as there's definitely going to
be way less false-positives on language run-time libraries, than the
current false-positives.

Thanks,
Guillem

Bug#910383: RM: spdy-indicator/2.2-1

[Moritz Mühlenhoff]

On Sat, Oct 06, 2018 at 11:16:00AM +0200, Emilio Pozuelo Monfort wrote:
> On 05/10/2018 21:04, Moritz Muehlenhoff wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: rm
> > 
> > Broken with Firefox ESR 60, filed for removal from unstable in 910382.
> 
> Is this for stretch? If so, it should be tagged appropriately.

Yeah, that's for stretch, now tagged.

Cheers,
Moritz

Bug#910458: gnome-user-docs FTBFS: 'NoneType' object has no attribute '__getitem__'

[Adrian Bunk]

Source: gnome-user-docs FTBFS: Error: Could not merge translations: 
Version: 3.30.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=gnome-user-docs&arch=all&ver=3.30.1-1&stamp=1538768364&raw=0

...
mo="zh_CN/zh_CN.mo"; \
if test -f "${mo}"; then mo="../${mo}"; else 
mo="/<>/gnome-help/${mo}"; fi; \
(cd "zh_CN/" && itstool -m "${mo}" ${d}/C/legal.xml ${d}/C/a11y-bouncekeys.page 
${d}/C/a11y-braille.page ${d}/C/a11y-contrast.page ${d}/C/a11y-dwellclick.page 
${d}/C/a11y-font-size.page ${d}/C/a11y-icon.page ${d}/C/a11y-mag.page 
${d}/C/a11y.page ${d}/C/a11y-right-click.page ${d}/C/a11y-screen-reader.page 
${d}/C/a11y-slowkeys.page ${d}/C/a11y-stickykeys.page 
${d}/C/a11y-visualalert.page ${d}/C/about-this-guide.page 
${d}/C/accounts-add.page ${d}/C/accounts-disable-service.page 
${d}/C/accounts-provider-not-available.page ${d}/C/accounts-remove.page 
${d}/C/accounts-which-application.page ${d}/C/accounts-whyadd.page 
${d}/C/accounts.page ${d}/C/backup-check.page ${d}/C/backup-frequency.page 
${d}/C/backup-how.page ${d}/C/backup-restore.page ${d}/C/backup-thinkabout.page 
${d}/C/backup-what.page ${d}/C/backup-where.page ${d}/C/backup-why.page 
${d}/C/bluetooth.page ${d}/C/bluetooth-connect-device.page 
${d}/C/bluetooth-problem-connecting.page 
${d}/C/bluetooth-remove-connection.page ${d}/C/bluetooth-send-file.page 
${d}/C/bluetooth-turn-on-off.page ${d}/C/bluetooth-visibility.page 
${d}/C/clock-calendar.page ${d}/C/clock-set.page ${d}/C/clock-timezone.page 
${d}/C/clock-world.page ${d}/C/clock.page ${d}/C/color.page 
${d}/C/color-assignprofiles.page ${d}/C/color-calibrate-camera.page 
${d}/C/color-calibrate-printer.page ${d}/C/color-calibrate-scanner.page 
${d}/C/color-calibrate-screen.page 
${d}/C/color-calibrationcharacterization.page 
${d}/C/color-calibrationdevices.page ${d}/C/color-calibrationtargets.page 
${d}/C/color-canshareprofiles.page ${d}/C/color-gettingprofiles.page 
${d}/C/color-howtoimport.page ${d}/C/color-missingvcgt.page 
${d}/C/color-notifications.page ${d}/C/color-notspecifiededid.page 
${d}/C/color-testing.page ${d}/C/color-whatisprofile.page 
${d}/C/color-whatisspace.page ${d}/C/color-why-calibrate.page 
${d}/C/color-whyimportant.page ${d}/C/contacts-add-remove.page 
${d}/C/contacts.page ${d}/C/contacts-connect.page 
${d}/C/contacts-edit-details.page ${d}/C/contacts-link-unlink.page 
${d}/C/contacts-search.page ${d}/C/contacts-setup.page 
${d}/C/disk-benchmark.page ${d}/C/disk-capacity.page ${d}/C/disk-check.page 
${d}/C/disk-format.page ${d}/C/disk-partitions.page ${d}/C/disk-repair.page 
${d}/C/disk-resize.page ${d}/C/disk.page ${d}/C/display-blank.page 
${d}/C/display-brightness.page ${d}/C/display-dual-monitors.page 
${d}/C/display-night-light.page ${d}/C/files-autorun.page 
${d}/C/files-browse.page ${d}/C/files-copy.page ${d}/C/files-delete.page 
${d}/C/files-disc-write.page ${d}/C/files-hidden.page ${d}/C/files-lost.page 
${d}/C/files-open.page ${d}/C/files-preview.page ${d}/C/files-recover.page 
${d}/C/files-removedrive.page ${d}/C/files-rename.page ${d}/C/files-search.page 
${d}/C/files-select.page ${d}/C/files-share.page ${d}/C/files-sort.page 
${d}/C/files-templates.page ${d}/C/files-tilde.page ${d}/C/files.page 
${d}/C/get-involved.page ${d}/C/gnome-classic.page ${d}/C/gnome-version.page 
${d}/C/hardware-auth.page ${d}/C/hardware-cardreader.page 
${d}/C/hardware-driver.page ${d}/C/hardware-problems-graphics.page 
${d}/C/hardware.page ${d}/C/help-irc.page ${d}/C/help-mailing-list.page 
${d}/C/index.page ${d}/C/keyboard-cursor-blink.page 
${d}/C/keyboard-key-menu.page ${d}/C/keyboard-key-super.page 
${d}/C/keyboard-layouts.page ${d}/C/keyboard-nav.page ${d}/C/keyboard-osk.page 
${d}/C/keyboard-repeat-keys.page ${d}/C/keyboard-shortcuts-set.page 
${d}/C/keyboard.page ${d}/C/look-background.page ${d}/C/look-display-fuzzy.page 
${d}/C/look-resolution.page ${d}/C/media.page ${d}/C/more-help.page 
${d}/C/mouse-doubleclick.page ${d}/C/mouse-lefthanded.page 
${d}/C/mouse-middleclick.page ${d}/C/mouse-mousekeys.page 
${d}/C/mouse-problem-notmoving.page ${d}/C/mouse-sensitivity.page 
${d}/C/mouse-touchpad-click.page ${d}/C/mouse-wakeup.page ${d}/C/mouse.page 
${d}/C/music-cantplay-drm.page ${d}/C/music-player-ipodtransfer.page 
${d}/C/music-player-newipod.page ${d}/C/nautilus-behavior.page 
${d}/C/nautilus-bookmarks-edit.page ${d}/C/nautilus-connect.page 
${d}/C/nautilus-display.page ${d}/C/nautilus-file-properties-basic.page 
${d}/C/nautilus-file-properties-permissions.page ${d}/C/nautilus-list.page 
${d}/C/nautilus-prefs.page ${d}/C/nautilus-preview.page 
${d}/C/nautilus-views.page ${d}/C/net-antivirus.page ${d}/C/net-browser.page 
${d}/C/net-default-browser.page ${d}/C/net-default-email.page 
${d}/C/net-email-virus.page ${d}/C/net-email.page ${d}/C/net-findip.page 
${d}/C/net-firewall-on-off.page ${d}/C/net-firewall-ports.page 
${d}/C/net-fixed-ip-address.page ${d}/C/net-general.page 
${d}/C/net-install-flash.page ${d}/C/net-macaddress.page ${d}/C/net-m

Bug#910457: syncany: FTBFS: dh_installman: Cannot find (any matches for) "/build/syncany-0.4.9~alpha/build/debian/syncany/debian/man/sy-cleanup.1" (tried in .)

[Andreas Beckmann]

Source: syncany
Version: 0.4.9~alpha-1
Severity: serious
Justification: fails to build from source

Hi,

syncany cannot be built in a current sid+experimental environment any
more:

[...]
 fakeroot debian/rules binary
dh binary --with bash-completion
   dh_testroot
   dh_prep
   dh_auto_install
   debian/rules override_dh_install
make[1]: Entering directory '/build/syncany-0.4.9~alpha'
rm -f build/install/syncany/bin/*.bat
dh_install
make[1]: Leaving directory '/build/syncany-0.4.9~alpha'
   dh_installdocs
   debian/rules override_dh_installchangelogs
make[1]: Entering directory '/build/syncany-0.4.9~alpha'
dh_installchangelogs build/install/syncany/CHANGELOG.md
make[1]: Leaving directory '/build/syncany-0.4.9~alpha'
   dh_installman
dh_installman: Cannot find (any matches for) 
"/build/syncany-0.4.9~alpha/build/debian/syncany/debian/man/sy-cleanup.1" 
(tried in .)

dh_installman: Aborting due to earlier error
make: *** [debian/rules:4: binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2


Andreas


syncany_0.4.9~alpha-1.log.gz
Description: application/gzip

Bug#910451: bs1770gain segfaults on MP3 files

[Etienne Dechamps]

Same outcome with 0.5.0 manually built from upstream. Stack trace with 0.5.0:

#0  0x555d78b0 in  ()
#1  0x77da900e in av_buffer_unref () at
/usr/lib/x86_64-linux-gnu/libavutil.so.56
#2  0x76a0d4c5 in av_packet_unref
(pkt=pkt@entry=0x555bd300) at src/libavcodec/avpacket.c:595
#3  0x76a930f8 in decode_simple_internal
(frame=0x555bd480, avctx=0x555bb640) at
src/libavcodec/decode.c:377
#4  0x76a930f8 in decode_simple_receive_frame
(frame=, avctx=) at
src/libavcodec/decode.c:594
#5  0x76a930f8 in decode_receive_frame_internal
(avctx=avctx@entry=0x555bb640, frame=frame@entry=0x555bd480)
at src/libavcodec/decode.c:612
#6  0x76a95bbb in avcodec_receive_frame (avctx=0x555bb640,
frame=0x555bd480) at src/libavcodec/decode.c:726
#7  0x76a95e7b in compat_decode (avctx=0x555bb640,
frame=0x555bd480, got_frame=0x7fffd910, pkt=0x555ba9a0)
at src/libavcodec/decode.c:782
#8  0xf3a4 in frame_reader_run (n=0x555ba960) at
ffsox_frame_reader.c:277
#9  0xf633 in ffsox_engine_run (e=0x7fffd9a0,
node=0x555ba960) at ffsox_engine.c:33
#10 0x5556147d in ffsox_sox_reader_read (sa=0x55599410,
buf=0x555c91c0, len=8192) at ffsox_sox_reader.c:117
#11 0x55561a0c in drain (e=0x555bdb90,
obuf=0x555c91c0, osamp=0x7fffda98) at
ffsox_sox_read_handler.c:56
#12 0x763bd933 in drain_effect (n=0, chain=0x555963e0) at
effects.c:352
#13 0x763bd933 in sox_flow_effects (chain=,
callback=0x0, client_data=0x0) at effects.c:445
#14 0xdae4 in ffsox_analyze (ac=0x7fffdda0, ai=-1,
vi=-1) at ffsox_analyze.c:164
#15 0xa77a in bs1770gain_tree_analyze
(tree=0x7fffde60, odirname=0x0, options=0x7fffdeb0) at
bs1770gain_tree.c:155
#16 0x8f96 in main (argc=2, argv=0x7fffe0e8) at
bs1770gain.c:1053


On Sat, 6 Oct 2018 at 15:58, Etienne Dechamps  wrote:
>
> Package: bs1770gain
> Version: 0.4.12-3+b1
> Severity: important
>
> --- Please enter the report below this line. ---
> bs1770gain segfaults when running on most MP3 files. (Other formats,
> like FLAC, appear to work fine.)
>
> Steps to reproduce:
> $ sox -n sine.wav synth 1 sine 1000
> ...
> $ ffmpeg -i sine.wav sine.mp3
> ...
> $ bs1770gain sine.mp3
> analyzing ...
>   [1/1] "sine.mp3": Segmentation fault (core dumped)
>
> GDB stacktrace with debug symbols:
>
> analyzing ...
>   [1/1] "sine.mp3":
> Program received signal SIGSEGV, Segmentation fault.
> 0x555d08b0 in ?? ()
> (gdb) bt
> #0  0x555d08b0 in  ()
> #1  0x77da900e in av_buffer_unref () at
> /usr/lib/x86_64-linux-gnu/libavutil.so.56
> #2  0x76a0d4c5 in av_packet_unref
> (pkt=pkt@entry=0x555b6300) at src/libavcodec/avpacket.c:595
> #3  0x76a930f8 in decode_simple_internal
> (frame=0x555b6480, avctx=0x555b4640) at
> src/libavcodec/decode.c:377
> #4  0x76a930f8 in decode_simple_receive_frame
> (frame=, avctx=) at
> src/libavcodec/decode.c:594
> #5  0x76a930f8 in decode_receive_frame_internal
> (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480)
> at src/libavcodec/decode.c:612
> #6  0x76a95bbb in avcodec_receive_frame (avctx=0x555b4640,
> frame=0x555b6480) at src/libavcodec/decode.c:726
> #7  0x76a95e7b in compat_decode
> (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480,
> got_frame=got_frame@entry=0x7fffd964,
> pkt=pkt@entry=0x555b39a0) at src/libavcodec/decode.c:782
> #8  0x76a9624d in avcodec_decode_audio4
> (avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480,
> got_frame_ptr=got_frame_ptr@entry=0x7fffd964,
> avpkt=avpkt@entry=0x555b39a0) at src/libavcodec/decode.c:838
> #9  0xd5e2 in frame_reader_run (n=0x555b3960) at
> ffsox_frame_reader.c:172
> #10 0xdb0c in ffsox_machine_run (m=m@entry=0x7fffd9d0,
> node=, node@entry=0x55592410)
> at ffsox_machine.c:30
> #11 0xf4be in ffsox_sox_reader_read
> (sa=sa@entry=0x55592410, buf=, len=)
> at ffsox_sox_reader.c:117
> #12 0xf5a2 in drain (e=, obuf= out>, osamp=0x7fffdac8) at ffsox_sox_read_handler.c:56
> #13 0x763bd933 in drain_effect (n=0, chain=0x5558f3e0) at
> effects.c:352
> #14 0x763bd933 in sox_flow_effects
> (chain=chain@entry=0x5558f3e0, callback=callback@entry=
> 0x0, client_data=client_data@entry=0x0) at effects.c:445
> #15 0xc704 in ffsox_analyze (ac=ac@entry=0x7fffdde0,
> ai=, vi=) at ffsox_analyze.c:159
> #16 0xa6ae in bs1770gain_tree_analyze (tree= out>, odirname=0x0, options=0x7fffdef0) at bs1770gain_tree.c:141
> #17 0x808a in main (argc=,
> argv=0x7fffe118) at bs1770gain.c:970
>
> --- System information. ---
> Architecture:
> Kernel:   Linux 4.18.0-1-amd64
>
> Debian Release: buster/sid
>   500 unstable-debug  deb.debian.

Bug#910454: [debian-mysql] Bug#910454: mysql-server: Restoring backup hangs for a large database

[Olaf van der Spek]

Hi Matthew,

What does mytop or "show processlist" say?

> mysqldump --databases mythconverg > dump.myth

mysqldump mythconverg is simpler, the name of the database won't be
included in the file so you can more easily restore it to a different
name.

Gr,

Olaf

On Sat, Oct 6, 2018 at 4:59 PM, Matthew Toseland  wrote:
> Package: mysql-server
> Version: 5.5.+default
> Severity: normal
>
> Dear Maintainer,
>
> I am unable to restore a backup of a large database. Here I was
> attempting to copy it by backing it up and restoring it.
>
> What I did:
>
> $ mysqldump --databases mythconverg > dump.myth
> $ vi dump.myth
> # Change the first few lines to change the name of the database from
> # mythconverg to mythcopy and not fail if it already exists
> $ mysql
> MariaDB [(none)]> create database mythcopy;
> MariaDB [(none)]> use mythcopy;
> MariaDB [(none)]> source dump.myth;
> ...
> Query OK, 21749 rows affected (0.22 sec)
> Records: 21749  Duplicates: 0  Warnings: 0
> ...
> Query OK, 21767 rows affected (0.20 sec)
> Records: 21767  Duplicates: 0  Warnings: 0
>
> There are lots of query records like the above, then it just stops, and
> hangs for at least half an hour, probably forever.
>
> I am able to use the mysql command line client on other databases, but not
> on mythcopy. mysqld is not using any significant CPU or disk I/O according
> to top and iotop. And /var/lib/mysql is on an SSD.
>
> Googling shows a few bugs in the MySQL bug tracker, but nothing obvious
> w.r.t. MariaDB, so there may be an upstream fix in MySQL but not
> necessarily in  MariaDB.
>
> -- System Information:
> Debian Release: 9.5
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-8-amd64 (SMP w/6 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/bash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mysql-server depends on:
> ii  default-mysql-server  1.0.2
>
> mysql-server recommends no packages.
>
> mysql-server suggests no packages.
>
> -- debconf-show failed
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint



-- 
Olaf

Bug#910456: miniupnpd: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: miniupnpd
Version: 2.1-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for miniupnpd's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


miniupnpd_2.1-2_pt.po.gz
Description: application/gzip

Bug#910455: bitcoin FTBFS on 32bit: test failure

[Adrian Bunk]

Source: bitcoin
Version: 0.17.0~dfsg-1
Severity: serious
Tags: ftbfs

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

...
make[5]: Leaving directory '/<>/src'
Running tests: compress_tests from test/compress_tests.cpp
test/test_bitcoin -l test_suite -t "`cat test/compress_tests.cpp | grep -E 
"(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | 
cut -d ',' -f 1 | cut -d ')' -f 1`" > test/compress_tests.cpp.log 2>&1 || (cat 
test/compress_tests.cpp.log && false)
Running tests: crypto_tests from test/crypto_tests.cpp
test/test_bitcoin -l test_suite -t "`cat test/crypto_tests.cpp | grep -E 
"(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | 
cut -d ',' -f 1 | cut -d ')' -f 1`" > test/crypto_tests.cpp.log 2>&1 || (cat 
test/crypto_tests.cpp.log && false)
Running tests: cuckoocache_tests from test/cuckoocache_tests.cpp
test/test_bitcoin -l test_suite -t "`cat test/cuckoocache_tests.cpp | grep -E 
"(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | 
cut -d ',' -f 1 | cut -d ')' -f 1`" > test/cuckoocache_tests.cpp.log 2>&1 || 
(cat test/cuckoocache_tests.cpp.log && false)
Running tests: denialofservice_tests from test/denialofservice_tests.cpp
test/test_bitcoin -l test_suite -t "`cat test/denialofservice_tests.cpp | grep 
-E "(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | 
cut -d ',' -f 1 | cut -d ')' -f 1`" > test/denialofservice_tests.cpp.log 2>&1 
|| (cat test/denialofservice_tests.cpp.log && false)
Running tests: descriptor_tests from test/descriptor_tests.cpp
test/test_bitcoin -l test_suite -t "`cat test/descriptor_tests.cpp | grep -E 
"(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | 
cut -d ',' -f 1 | cut -d ')' -f 1`" > test/descriptor_tests.cpp.log 2>&1 || 
(cat test/descriptor_tests.cpp.log && false)
Running tests: getarg_tests from test/getarg_tests.cpp
test/test_bitcoin -l test_suite -t "`cat test/getarg_tests.cpp | grep -E 
"(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | 
cut -d ',' -f 1 | cut -d ')' -f 1`" > test/getarg_tests.cpp.log 2>&1 || (cat 
test/getarg_tests.cpp.log && false)
Running tests: hash_tests from test/hash_tests.cpp
test/test_bitcoin -l test_suite -t "`cat test/hash_tests.cpp | grep -E 
"(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | 
cut -d ',' -f 1 | cut -d ')' -f 1`" > test/hash_tests.cpp.log 2>&1 || (cat 
test/hash_tests.cpp.log && false)
Running tests: key_io_tests from test/key_io_tests.cpp
test/test_bitcoin -l test_suite -t "`cat test/key_io_tests.cpp | grep -E 
"(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | 
cut -d ',' -f 1 | cut -d ')' -f 1`" > test/key_io_tests.cpp.log 2>&1 || (cat 
test/key_io_tests.cpp.log && false)
Running 11 test cases...
Entering test module "Bitcoin Test Suite"
test/crypto_tests.cpp(23): Entering test suite "crypto_tests"
test/crypto_tests.cpp(217): Entering test case "ripemd160_testvectors"
test/crypto_tests.cpp(217): Leaving test case "ripemd160_testvectors"; testing 
time: 346645us
test/crypto_tests.cpp(233): Entering test case "sha1_testvectors"
test/crypto_tests.cpp(233): Leaving test case "sha1_testvectors"; testing time: 
555499us
test/crypto_tests.cpp(249): Entering test case "sha256_testvectors"
test/crypto_tests.cpp(249): Leaving test case "sha256_testvectors"; testing 
time: 550873us
test/crypto_tests.cpp(271): Entering test case "sha512_testvectors"
test/crypto_tests.cpp(271): Leaving test case "sha512_testvectors"; testing 
time: 1591096us
test/crypto_tests.cpp(308): Entering test case "hmac_sha256_testvectors"
test/crypto_tests.cpp(308): Leaving test case "hmac_sha256_testvectors"; 
testing time: 46886us
test/crypto_tests.cpp(361): Entering test case "hmac_sha512_testvectors"
test/crypto_tests.cpp(361): Leaving test case "hmac_sha512_testvectors"; 
testing time: 62095us
test/crypto_tests.cpp(429): Entering test case "aes_testvectors"
test/crypto_tests.cpp(429): Leaving test case "aes_testvectors"; testing time: 
39761us
test/crypto_tests.cpp(445): Entering test case "aes_cbc_testvectors"
test/crypto_tests.cpp(445): Leaving test case "aes_cbc_testvectors"; testing 
time: 40189us
test/crypto_tests.cpp(497): Entering test case "chacha20_testvector"
test/crypto_tests.cpp(497): Leaving test case "chacha20_testvector"; testing 
time: 39479us
test/crypto_tests.cpp(527): Entering test case "countbits_tests"
test/crypto_tests.cpp(527): Leaving test case "countbits_tests"; testing time: 
91719us
test/crypto_tests.cpp(549): Entering test case "sha256d64"
test/crypto_tests.cpp(561): error: in "crypto_tests/sha256d64": check 
memcmp(out1, out2, 32 * i) == 0 has failed
test/crypto_tests.cpp(561): error: in "crypto_tests/sha256d64": check 
memcmp(out1, out2, 32 * i) == 0 has failed
test/crypto_tests.cpp(561): error: in "crypto_tests/sha256d64": check 
memcmp(out1, out2, 32 * i) == 0 has failed
test/crypto_tests.cpp(561

Bug#910454: mysql-server: Restoring backup hangs for a large database

[Matthew Toseland]

Package: mysql-server
Version: 5.5.+default
Severity: normal

Dear Maintainer,

I am unable to restore a backup of a large database. Here I was
attempting to copy it by backing it up and restoring it.

What I did:

$ mysqldump --databases mythconverg > dump.myth
$ vi dump.myth
# Change the first few lines to change the name of the database from
# mythconverg to mythcopy and not fail if it already exists
$ mysql
MariaDB [(none)]> create database mythcopy;
MariaDB [(none)]> use mythcopy;
MariaDB [(none)]> source dump.myth;
...
Query OK, 21749 rows affected (0.22 sec)
Records: 21749  Duplicates: 0  Warnings: 0
...
Query OK, 21767 rows affected (0.20 sec)
Records: 21767  Duplicates: 0  Warnings: 0

There are lots of query records like the above, then it just stops, and
hangs for at least half an hour, probably forever.

I am able to use the mysql command line client on other databases, but not
on mythcopy. mysqld is not using any significant CPU or disk I/O according
to top and iotop. And /var/lib/mysql is on an SSD.

Googling shows a few bugs in the MySQL bug tracker, but nothing obvious
w.r.t. MariaDB, so there may be an upstream fix in MySQL but not
necessarily in  MariaDB.

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/6 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/bash
Init: systemd (via /run/systemd/system)

Versions of packages mysql-server depends on:
ii  default-mysql-server  1.0.2

mysql-server recommends no packages.

mysql-server suggests no packages.

-- debconf-show failed

Bug#833906: Xorg random crashes

[Friedhelm Mehnert]

I have the same problem. Exactly like described here. Tried several
different kernels. No change.  Lenovo T410 with Debian Stretch and
fvwm2.  Screen goes black with yellow bar at left side. Then machine
just
switches off. About 1 to 2 times an hour.

Sorry, that I can't give more details. Nothing in the logs.

Best Regards
Friedhelm

Bug#910453: lintian: false positive for package-does-not-use-debhelper-or-cdbs when using blends-dev

[Holger Levsen]

Package: lintian
Version: 2.5.108
Severity: normal
affects: blends-dev

Dear Maintainer,

since very recently lintian emits the pedantic tag 
'package-does-not-use-debhelper-or-cdbs' when testing the src:debian-edu 
package, which build-depends on blends-dev, which depends on debhelper, which 
is then also used to build src:debian-edu. So this is a false positive, please 
fix.

Thanks for maintaining lintian and making it better all the time!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#910451: bs1770gain segfaults on MP3 files

[Etienne Dechamps]

Package: bs1770gain
Version: 0.4.12-3+b1
Severity: important

--- Please enter the report below this line. ---
bs1770gain segfaults when running on most MP3 files. (Other formats,
like FLAC, appear to work fine.)

Steps to reproduce:
$ sox -n sine.wav synth 1 sine 1000
...
$ ffmpeg -i sine.wav sine.mp3
...
$ bs1770gain sine.mp3
analyzing ...
  [1/1] "sine.mp3": Segmentation fault (core dumped)

GDB stacktrace with debug symbols:

analyzing ...
  [1/1] "sine.mp3":
Program received signal SIGSEGV, Segmentation fault.
0x555d08b0 in ?? ()
(gdb) bt
#0  0x555d08b0 in  ()
#1  0x77da900e in av_buffer_unref () at
/usr/lib/x86_64-linux-gnu/libavutil.so.56
#2  0x76a0d4c5 in av_packet_unref
(pkt=pkt@entry=0x555b6300) at src/libavcodec/avpacket.c:595
#3  0x76a930f8 in decode_simple_internal
(frame=0x555b6480, avctx=0x555b4640) at
src/libavcodec/decode.c:377
#4  0x76a930f8 in decode_simple_receive_frame
(frame=, avctx=) at
src/libavcodec/decode.c:594
#5  0x76a930f8 in decode_receive_frame_internal
(avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480)
at src/libavcodec/decode.c:612
#6  0x76a95bbb in avcodec_receive_frame (avctx=0x555b4640,
frame=0x555b6480) at src/libavcodec/decode.c:726
#7  0x76a95e7b in compat_decode
(avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480,
got_frame=got_frame@entry=0x7fffd964,
pkt=pkt@entry=0x555b39a0) at src/libavcodec/decode.c:782
#8  0x76a9624d in avcodec_decode_audio4
(avctx=avctx@entry=0x555b4640, frame=frame@entry=0x555b6480,
got_frame_ptr=got_frame_ptr@entry=0x7fffd964,
avpkt=avpkt@entry=0x555b39a0) at src/libavcodec/decode.c:838
#9  0xd5e2 in frame_reader_run (n=0x555b3960) at
ffsox_frame_reader.c:172
#10 0xdb0c in ffsox_machine_run (m=m@entry=0x7fffd9d0,
node=, node@entry=0x55592410)
at ffsox_machine.c:30
#11 0xf4be in ffsox_sox_reader_read
(sa=sa@entry=0x55592410, buf=, len=)
at ffsox_sox_reader.c:117
#12 0xf5a2 in drain (e=, obuf=, osamp=0x7fffdac8) at ffsox_sox_read_handler.c:56
#13 0x763bd933 in drain_effect (n=0, chain=0x5558f3e0) at
effects.c:352
#14 0x763bd933 in sox_flow_effects
(chain=chain@entry=0x5558f3e0, callback=callback@entry=
0x0, client_data=client_data@entry=0x0) at effects.c:445
#15 0xc704 in ffsox_analyze (ac=ac@entry=0x7fffdde0,
ai=, vi=) at ffsox_analyze.c:159
#16 0xa6ae in bs1770gain_tree_analyze (tree=, odirname=0x0, options=0x7fffdef0) at bs1770gain_tree.c:141
#17 0x808a in main (argc=,
argv=0x7fffe118) at bs1770gain.c:970

--- System information. ---
Architecture:
Kernel:   Linux 4.18.0-1-amd64

Debian Release: buster/sid
  500 unstable-debug  deb.debian.org
  500 unstabledeb.debian.org
  500 stretch packagecloud.io
  500 stable  www.ubnt.com
1 experimental-debug deb.debian.org
1 experimentaldeb.debian.org

--- Package information. ---
Depends   (Version) | Installed
===-+-=
libavcodec58(>= 7:4.0)  | 7:4.0.2-2
 OR libavcodec-extra58   (>= 7:4.0) |
libavformat58(>= 7:4.0) | 7:4.0.2-2
libavutil56  (>= 7:4.0) | 7:4.0.2-2
libc6 (>= 2.14) | 2.27-6
libsox3(>= 14.4.2~) | 14.4.2-3
libswresample3   (>= 7:4.0) | 7:4.0.2-2


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#910452: No report or readable logs

[Karsten]

Package: snort
Version: 2.9.7.0-5
Severity: normal

Hello,

i did use snort before and i always get an nice daily email with an report.
But in debian stretch i get nothing and in /var/log/snort i only get an 
unreadable logfile.
How can i read the logfile?

It seems that this entries in /etc/snort/snort.debian.conf/ are useless:
DEBIAN_SNORT_SEND_STATS="true"
DEBIAN_SNORT_STATS_RCPT="root"
DEBIAN_SNORT_STATS_THRESHOLD="1"

What must be done to get an daily report as email?

Thanks for any tip!
karsten


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

Bug#805401: /bin/ping6: ping6 does not correctly handle avahi .local addresses

[Benjamin Peter]

Package: iputils-ping
Version: 3:20180629-2
Followup-For: Bug #805401

Dear Maintainer,

cool that I found someone already described the problem.

It still exists in 2018.

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

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

Versions of packages iputils-ping depends on:
ii  libc6   2.27-6
ii  libcap2 1:2.25-1.2
ii  libidn2-0   2.0.5-1
ii  libnettle6  3.4-1

Versions of packages iputils-ping recommends:
ii  libcap2-bin  1:2.25-1.2

iputils-ping suggests no packages.

-- no debconf information

Bug#805401: /bin/ping6: ping6 does not correctly handle avahi .local addresses

[Benjamin Peter]

Package: iputils-ping
Version: 3:20180629-2
Followup-For: Bug #805401

Dear Maintainer,

just a moment after writing I found an article, saying to modify
nsswitch.conf as follows

hosts:  files mdns_minimal [NOTFOUND=return] dns mdns
#hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4

Maybe this could be a setting for everyone?

https://debian-administration.org/article/655/Running_IPv6_in_practice


thanks

Ben

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

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

Versions of packages iputils-ping depends on:
ii  libc6   2.27-6
ii  libcap2 1:2.25-1.2
ii  libidn2-0   2.0.5-1
ii  libnettle6  3.4-1

Versions of packages iputils-ping recommends:
ii  libcap2-bin  1:2.25-1.2

iputils-ping suggests no packages.

-- no debconf information

Bug#910276: mksh does never execute an "EXIT trap", if it is created with the "trap" command in a sub shell

[Thorsten Glaser]

Bernd Schumacher dixit:

>Please confirm, that this is a bug and not the expected behaviour of mksh.

I still cannot confirm either way, but some preliminary research
with an extended test script:

$ cat script
fkt()
{
  trap -- "echo $1 >&2" EXIT
}
fkt shell_exit
$(fkt fn_exit)
$(trap -- "echo comsub_exit >&2" EXIT)
(trap -- "echo subshell_exit >&2" EXIT)

$ mksh script
shell_exit

$ bash2.05b script
subshell_exit
shell_exit

$ ksh93 script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ bash4 script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ nbsh script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ dash script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ yash script
fn_exit
comsub_exit
subshell_exit
shell_exit

$ zsh script
shell_exit
fn_exit
comsub_exit
subshell_exit

$ zsh --emulate sh script
fn_exit
comsub_exit
subshell_exit
shell_exit


With the addition of subshell_exit (I renamed yours in fn_exit),
it’s consistent with no other shell I have, not even GNU bash 2.05b
(Heirloom Shell doesn’t know of the EXIT trap, and I’m ignoring
the C shell). zsh is a notable outlyer but easily fixed.

The manual page has something to say about EXIT traps defined in
functions declared using “function foo { … }” (Korn Shell syntax),
but that’s not used here.

I think that I’ll adapt it to the other shells independent of
whether it’s really a bug or not, for the sake of consistency.
If you’re still interested in semantics, I can continue the
research, though.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

Hi!

On Sat, 2018-10-06 at 15:16:07 +0800, Yangfl wrote:
> Yangfl  于2018年9月22日周六 上午9:22写道：
> > Guillem Jover  于2018年9月22日周六 上午8:30写道：
> > > The attached is what I'd include.
> >
> > $ ./a.out --test
> > md5 self-test completed successfully.
> > $ ldd ./a.out
> > linux-vdso.so.1 (0x7ffc941d6000)
> > libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x7f0388a58000)
> > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f03888c4000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0388707000)
> > /lib64/ld-linux-x86-64.so.2 (0x7f0388c8b000)
> >
> > Looks great. Thanks!

> Any plan to release a new libmd version?

Yes, had this in mind, and was planning on a release during this week,
just got entangled with other stuff. I'll probably release today or
tomorrow.

Thanks,
Guillem

Bug#910450: clang-8: Segfaults compiling dpkg/src/remove.c

[Guillem Jover]

Hi!

On Sat, 2018-10-06 at 15:58:45 +0200, Sylvestre Ledru wrote:
> Le 06/10/2018 à 15:44, Guillem Jover a écrit :
> > Package: clang-8
> > Version: 1:8~svn343154-1
> > Severity: normal

> > I tend to check whether dpkg compiles with latest clang from time to
> > time. And this time around I got a segfault. Here's the stack dump,
> > and attached are the two other files, where I've replaced the absolute
> > path to the source tree with :

> Does it also occur with clang-7 ?

Right, sorry, should have mentioned that explicitly. clang-7 does work
fine, this looks like a regression in clang-8.

Thanks,
Guillem

Bug#910252: ITP: libnbcompat -- NetBSD compatibility library

[Guillem Jover]

Hi!

On Thu, 2018-10-04 at 08:28:57 -0500, John Goerzen wrote:
> On Thu, Oct 04 2018, Guillem Jover wrote:
> > Hmm, what does this library provide that is required by mtree-netbsd not
> > available in glibc, libbsd and libmd? Perhaps even freebsd-glue?
> >
> > I've skimmed over the functionality and it seems most of it is already
> > covered by those. If there's still stuff needed I'm always happy to add
> > it to libbsd or libmd as required!

> You are correct that the functionality is generally available.  The
> problem is that the interfaces are different.  nbconfig.h, for instance,
> defines a number of HAVE_* macros that are used while building mtree.
> nbconfig.h includes a number of system header files (stdio.h, etc.) that
> cause *numerous* build errors if missing.  There are also functions for
> things like hashing files that take different numbers of parameters,
> etc.

I see the packages have already gone through NEW, so I've taken a
look. And I've almost got mtree-netbsd building using just libmd and
libbsd. I'll be releasing new upstream versions fixing or adding the
missing stuff:

  - libmd had bogus compat macros for SHA512, and missing ones for
SHA384.
  - libbsd is missing the pwcache modules from the BSDs, which I'll
be adding.
  - libbsd is missing a  that implicitly includes
, I'll be adding that.

Then I've got some minimal patches for mtree-netbsd, which fix or improve
things there, that I'll be sending your way once I've finished with the
above. At which point I think it would be nice to drop libnbcompat
completely?

The point of creating libmd and libbsd and switching projects to use
those, was to have such BSD compatibility library in a single place
which can be fixed centrallly, and to reduce embedded code copies. So
adding yet similar library would make the situation confusing and
might distract from such unifiying efforts. :)

> I also considered, for a bit, whether to even make libnbcompat be a
> separate package.  I concluded yes, because:
> 
> 1) It has its own standalone configure,
> 
> 2) It must be configured and built before mtree can be configured,
> 
> 3) Even on NetBSD, mtree requires libnbcompat to build (the #include
>  is not wrapped inside any conditional macro)
> 
> Because of #1 and #2, just including it in mtree itself would cause the
> build system to somewhat violate the usual principles of how to build.

I really think libnbcompat should be completely unnecessary. :) And if
there'd be new features required my mtree-netbsd in the future I'm
always happy to consider new additions to these libraries if they make
sense!

Thanks,
Guillem