Bug#868459: stretch-pu: package libquicktime/2:1.2.4-10+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-07-16 at 21:15 +0200, Salvatore Bonaccorso wrote:
> Hi!
> 
> On Sun, Jul 16, 2017 at 07:16:56PM +0100, Adam D. Barratt wrote:
> > On Sun, 2017-07-16 at 18:41 +0200, Moritz Mühlenhoff wrote:
> > > On Sat, Jul 15, 2017 at 09:19:08PM +0100, Adam D. Barratt wrote:
> > > > Control: tags -1 + confirmed
> > > > 
> > > > On Sat, 2017-07-15 at 19:12 +0200, Moritz Muehlenhoff wrote:
> > > > > some minor security fixes for libquicktime, identical to what's
> > > > > already in unstable and also tested with reverse deps on stretch.
> > > > > 
> > > > > If it's too late for 9.1, 9.2 is also just fine.
> > > > 
> > > > Feel free to upload, we'll see if it makes it in time.
> > > 
> > > Thanks, uploaded.
> > 
> > Unfortunately, I've had to flag the upload for rejection - it's somehow
> > picked up a new dependency on "libschroedinger-1.0-0 (>= 1.0.0)", but
> > that binary package is not in stretch.
> 
> Hmm, could it be the building chroot was unclean (contained jessie
> packages? Because I see libschroedinger-1.0-0 only in
> jessie/oldstable). I took jmm's debdiff, and rebuilded in stretch and
> as well the debdiff against the resulting binary packages and those in
> the archive looked okay. I thus just re-uploaded Moritz's package.
> 
> Hope that was fine (and in the interest of the fixes getting into
> 9.1).

Flagged for acceptance, thanks.

Regards,

Adam

Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

[Graham Inggs]

Uploaded, please downgrade the severity of this bug once the builds
are successful.

Bug#867597: stretch-pu: package retext/6.0.2-2+deb9u1

[Dmitry Shachnev]

Hi Adam!

On Sat, Jul 15, 2017 at 11:38:24PM +0100, Adam D. Barratt wrote:
> > > On Jul 10th I have uploaded retext to stretch and even got an ACCEPTED 
> > > mail:
> > >
> > > retext_6.0.2-2+deb9u1_source.changes ACCEPTED into 
> > > proposed-updates->stable-new
>
> For reference, that mail says it was accepted into stable-new, /not/
> that it was accepted in to proposed-updates. (stable-new is a policy
> queue that sits in front of proposed-updates.)
>
> > You need to wait for someone from the Release Team to process it and 
> > accept it into proposed-updates. See 
> > https://release.debian.org/proposed-updates/stable.html
>
> Flagged for acceptance.

Thanks for the explanation and taking care of it!

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#851094: apache2 openssl transition has to go via experimental

[Stefan Fritsch]

reopen 851094
found 851094 2.4.27-2
thanks

Bug#868582: skimage: new upstream version

[Michael Hudson-Doyle]

Source: skimage
Severity: normal
Tags: patch
User: debian-pyt...@lists.debian.org
Usertags: python3.6

Dear Maintainer,

skimage fails tests with Python 3.6 so in Ubuntu I upgraded to 0.13.0. uscan +
uupdate + the attached patch to debian/ did the trick for me.

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (400, 'xenial-proposed'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-83-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru skimage-0.12.3/debian/changelog skimage-0.13.0/debian/changelog
--- skimage-0.12.3/debian/changelog	2017-06-08 11:32:15.0 +1200
+++ skimage-0.13.0/debian/changelog	2017-07-17 09:08:23.0 +1200
@@ -1,3 +1,18 @@
+skimage (0.13.0-0ubuntu1) artful; urgency=medium
+
+  * New upstream release.
+  * d/patches/:
+- changeset_6807f4ee8f5501703e447f95701190c836deaae1.diff,
+  dask-optional-dep.patch, fix_shape_type.patch, search-html.patch: dropped,
+  applied upstream.
+- fix-doc-links.patch: updated
+- skip_tests_failing_on_some_architectures.patch: split into more targetted
+  skip-failing-test-on-i386.patch & skip-failing-test-on-big-endian.patch.
+  * d/rules: CONTRIBUTING.txt has moved.
+  * d/control: add dependencies on python{3,}-pywt. python{3,}-numpydoc.
+
+ -- Michael Hudson-Doyle   Fri, 14 Jul 2017 12:34:25 +1200
+
 skimage (0.12.3-9build1) artful; urgency=medium
 
   * No change rebuild to add Python 3.6 support.
diff -Nru skimage-0.12.3/debian/control skimage-0.13.0/debian/control
--- skimage-0.12.3/debian/control	2017-04-28 21:23:39.0 +1200
+++ skimage-0.13.0/debian/control	2017-07-14 14:07:54.0 +1200
@@ -10,21 +11,25 @@
libjs-twitter-bootstrap,
python-all-dev (>= 2.6.6-3~),
python-matplotlib (>= 1.3.1),
+   python-networkx (>= 1.8),
python-nose,
python-numpy (>= 1.7.2),
+   python-numpydoc,
python-pil (>= 1.7.8) | python-imaging,
+   python-pywt,
python-scipy (>= 0.10),
-   python-networkx (>= 1.8),
python-setuptools,
python-six (>= 1.4),
python-sphinx (>= 1.3.0),
python3-all-dev,
python3-matplotlib (>= 1.3.1),
+   python3-networkx (>= 1.8),
python3-nose,
python3-numpy (>= 1.7.2),
+   python3-numpydoc,
python3-pil (>= 1.7.8) | python3-imaging,
+   python3-pywt,
python3-scipy,
-   python3-networkx (>= 1.8),
python3-setuptools,
python3-six (>= 1.3.0),
xauth,
@@ -38,17 +43,16 @@
 
 Package: python-skimage
 Architecture: all
-Depends: python-numpy,
+Depends: python-matplotlib (>= 1.3.1),
+ python-networkx (>= 1.8),
+ python-numpy,
+ python-pil (>= 1.7.8) | python-imaging,
  python-scipy (>= 0.10),
  python-six (>= 1.4),
- python-matplotlib (>= 1.3.1),
- python-pil (>= 1.7.8) | python-imaging,
- python-networkx (>= 1.8),
  python-skimage-lib (>= ${source:Version}),
  ${misc:Depends},
  ${python:Depends}
-Recommends: python-nose,
-python-qt4
+Recommends: python-nose, python-qt4
 Suggests: python-opencv, python-skimage-doc
 Description: Python modules for image processing
  scikit-image is a collection of image processing algorithms for
@@ -59,12 +63,12 @@
 
 Package: python3-skimage
 Architecture: all
-Depends: python3-numpy (>= 1.7.2),
+Depends: python3-matplotlib (>= 1.3.1),
+ python3-networkx (>= 1.8),
+ python3-numpy (>= 1.7.2),
+ python3-pil (>= 1.7.8) | python3-imaging,
  python3-scipy (>= 0.10),
  python3-six (>= 1.4),
- python3-matplotlib (>= 1.3.1),
- python3-pil (>= 1.7.8) | python3-imaging,
- python3-networkx (>= 1.8),
  python3-skimage-lib (>= ${source:Version}),
  ${misc:Depends},
  ${python3:Depends}
diff -Nru skimage-0.12.3/debian/patches/changeset_6807f4ee8f5501703e447f95701190c836deaae1.diff skimage-0.13.0/debian/patches/changeset_6807f4ee8f5501703e447f95701190c836deaae1.diff
--- skimage-0.12.3/debian/patches/changeset_6807f4ee8f5501703e447f95701190c836deaae1.diff	2017-04-28 21:04:03.0 +1200
+++ skimage-0.13.0/debian/patches/changeset_6807f4ee8f5501703e447f95701190c836deaae1.diff	1970-01-01 12:00:00.0 +1200
@@ -1,14 +0,0 @@
-From: Yaroslav Halchenko 
-Subject: BF: Initialize firstbg to the numels so if no bg value found, second loop is not executed
-
 

Bug#862432: game-data-packager: Drop .crc files from Doom 3 BFG

[Markus Koschany]

[Sorry for receiving this email multiple times]

Am 16.07.2017 um 22:56 schrieb Max:
> Hi Markus,
> 
> I tried to build doom3bfg-data with game-data-packager 53, but that bug
> is still not fixed. I had to move all .crc files to the CRC group and
> had to modify the SHA sums for ./base/strings/english.lang. After that
> it would build correctly. Files attached.
> 

Hi Max,

I am sorry to hear that. However I didn't deal with your bug report in
the end, I just forwarded it to Debian's bug tracker. I have reopened
the old bug report for you because you claim it has not been fixed yet.
Please reply to 862...@bugs.debian.org if you want to provide further
information in the future.

Regards,

Markus




files.tar.bz2
Description: application/bzip


signature.asc
Description: OpenPGP digital signature

Bug#867358: mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address

[Ben Hutchings]

On Thu, 2017-07-06 at 13:10 +0300, Adrian Bunk wrote:
> Control: reassign -1 src:linux 4.9.30-2
> Control: retitle -1 mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address
> Control: affects -1 src:golang-github-pelletier-go-toml 
> src:golang-github-nicksnyder-go-i18n gccgo-7
> 
> On Thu, Jul 06, 2017 at 02:11:00AM +0300, Adrian Bunk wrote:
> > Source: golang-github-pelletier-go-toml
> > Version: 1.0.0-1
> > Severity: serious
> > 
> > https://buildd.debian.org/status/package.php?p=golang-github-pelletier-go-toml=sid
> > 
> > ...
> >    dh_auto_test -a -O--buildsystem=golang
> > go test -v -p 4 github.com/pelletier/go-toml 
> > github.com/pelletier/go-toml/cmd github.com/pelletier/go-toml/cmd/tomljson 
> > github.com/pelletier/go-toml/cmd/tomll github.com/pelletier/go-toml/query
> > go build github.com/davecgh/go-spew/spew: /usr/bin/mips-linux-gnu-gccgo-7: 
> > waitid: bad address
> > FAILgithub.com/pelletier/go-toml [build failed]
> > ?   github.com/pelletier/go-toml/cmd[no test files]
> > ...
> 
> James Cowgill told me that this is actually a kernel bug:
>   https://www.linux-mips.org/archives/linux-mips/2017-03/msg00580.html

That's now a 404, strangely.  Did you mean "[PATCH 0/2] Fix indirect
syscall handler for syscalls with > 4 args"?

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.


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

Bug#868591: haskell-lens-aeson FTBFS: Failed to load interface for Data.Aeson.Encoding.Internal

[Adrian Bunk]

Source: haskell-lens-aeson
Version: 1.0.1-1
Severity: serious

https://buildd.debian.org/status/package.php?p=haskell-lens-aeson

...
[1 of 1] Compiling Data.Aeson.Lens  ( src/Data/Aeson/Lens.hs, 
dist-ghc/build/Data/Aeson/Lens.o )
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.0.2/aeson-1.0.2.1-CgbEAGwJWkq5wCUqDjmFHU/Data/Aeson.hi
Declaration for encode
Unfolding of encode:
  Failed to load interface for `Data.Aeson.Encoding.Internal'
  There are files missing in the `aeson-1.0.2.1' package,
  try running 'ghc-pkg check'.
  Use -v to see a list of the files searched for.
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.0.2/aeson-1.0.2.1-CgbEAGwJWkq5wCUqDjmFHU/Data/Aeson/Types/ToJSON.hi
Declaration for $fToJSONValue
Class ops for dfun $fToJSONValue:
  Can't find interface-file declaration for variable value
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.0.2/aeson-1.0.2.1-CgbEAGwJWkq5wCUqDjmFHU/Data/Aeson/Types/ToJSON.hi
Declaration for ToJSON
Class op toEncoding a -> Encoding ty:
  Can't find interface-file declaration for type constructor or class Encoding
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
Cannot continue after interface file error
/usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc-stamp' 
failed
make: *** [build-ghc-stamp] Error 1

Bug#868590: haskell-shakespeare FTBFS: undefined symbol: aesonzm1zi0zi2zi1zmCgbEAGwJWkq5wCUqDjmFHU_DataziAesonziEncodingziInternal_utcTime1_closure

[Adrian Bunk]

Source: haskell-shakespeare
Version: 2.0.13-1
Severity: serious

https://buildd.debian.org/status/package.php?p=haskell-shakespeare

...
[11 of 18] Compiling Text.Internal.CssCommon ( Text/Internal/CssCommon.hs, 
dist-ghc/build/Text/Internal/CssCommon.o )
: can't load .so/.DLL for: 
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.0.2/libHSaeson-1.0.2.1-CgbEAGwJWkq5wCUqDjmFHU-ghc8.0.2.so
 
(/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.0.2/libHSaeson-1.0.2.1-CgbEAGwJWkq5wCUqDjmFHU-ghc8.0.2.so:
 undefined symbol: 
aesonzm1zi0zi2zi1zmCgbEAGwJWkq5wCUqDjmFHU_DataziAesonziEncodingziInternal_utcTime1_closure)
/usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc-stamp' 
failed
make: *** [build-ghc-stamp] Error 1

Bug#868594: gnuplot: Link against GNU readline to insert non-ascii interactively

[Diogo F. S. Ramos]

Package: gnuplot
Version: 5.0.5+dfsg1-6
Severity: wishlist

Dear Maintainer,

As gnuplot is currently compiled, it is impossible to insert non-ascii
characters while using gnuplot interactively.

By linking against GNU readline, it is possible to insert non-ascii
characters while using gnuplot interactively

Bug#867701: Radeon HD 6450, black screen, cursor, no console

[Ivan Sergio Borgonovo]

On 07/16/2017 05:56 PM, Michel Dänzer wrote:

Hmm, the string "EGL search path is" and the corresponding code was 
removed upstream for Mesa 10.6. Look for instances of libEGL.so.1* other 
than /usr/lib/x86_64-linux-gnu/libEGL.so.1* on your system and see if 
removing those helps.


I'm not sure about what you're asking.

On the problematic system apparently there are no packages installed 
containing libEGL*.*


apt-file search libEGL.so
libegl1-glvnd-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1
libegl1-mesa: /usr/lib/x86_64-linux-gnu/libEGL.so.1
libegl1-mesa: /usr/lib/x86_64-linux-gnu/libEGL.so.1.0.0
libegl1-mesa-dev: /usr/lib/x86_64-linux-gnu/libEGL.so
libegl1-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1
libegl1-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.375.66
libegl1-nvidia-legacy-340xx: 
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libEGL.so.1
libegl1-nvidia-legacy-340xx: 
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libEGL.so.340.102

virtualbox-guest-x11: /usr/lib/virtualbox/additions/libEGL.so
virtualbox-guest-x11: /usr/lib/virtualbox/additions/libEGL.so.1

but none of these packages are installed.

But
find /usr/lib/x86_64-linux-gnu/ -name libEGL*.*
/usr/lib/x86_64-linux-gnu/libEGL.so.1
/usr/lib/x86_64-linux-gnu/libEGL.so.1.0.0

ls -l /usr/lib/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 15 Jul 17 00:57 
/usr/lib/x86_64-linux-gnu/libEGL.so.1 -> libEGL.so.1.0.0


aptitude reinstall glx-alternative-mesa
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/mesa-diverted because link group glx is broken


On the working box I get:
find /usr/lib/x86_64-linux-gnu/ -name libEGL*.*
/usr/lib/x86_64-linux-gnu/libEGL.so.1

ls -l /usr/lib/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 51 Jun 10  2016 
/usr/lib/x86_64-linux-gnu/libEGL.so.1 -> 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu



Does the same problem happen with 1:7.8.0-1+b1 with

 Option "AccelMethod" "glamor"

in /etc/X11/xorg.conf ?


Older xserver-xorg-video-radeon with that option DOESN'T WORK.
Black screen, text cursor at the top right corner ( _ ).


Right, as expected the problem is specific to glamor, which is the
default for your GPU in 7.9.0 but wasn't yet in 7.8.0. This means in the
worst case you can work around the problem with

Option"AccelMethod" "EXA"

in /etc/X11/xorg.conf.


Thanks, this solved the problem.

Could I suggest to add some notes in the changelog before closing the 
bug?


It's just a workaround. We don't know yet what the problem is, though 
it's likely specific to your system.


Are you saying it is something more related to the installation history 
of that box rather then to the specific hardware?

Or it cold be a mix of the two?

Could I exploit the fact that I've 2 nearly identical boxes to track 
down the problem?


thanks

--
Ivan Sergio Borgonovo
http://www.webthatworks.it http://www.borgonovo.net

Bug#786555: sudo: time stamp files no longer invalidated at boot

[Michael Biebl]

On Fri, 05 Jun 2015 11:35:57 -0400 Marc Deslauriers
 wrote:
> Package: sudo
> Version: 1.8.12-1
> Followup-For: Bug #786555
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu wily ubuntu-patch
> 
> 
> 
> *** /tmp/tmp8y8IwQ/bug_body
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Use tmpfs location to store timestamp files (LP: #1458031)
> - debian/rules: change --with-rundir to /var/run/sudo
> - debian/rules, debian/sudo.service, debian/sudo.sudo.init: stop
>   shipping init script and service file, as they are no longer
>   necessary.
> - debian/*.preinst, debian/*.postinst, debian/*.postrm: remove old init
>   script with dpkg-maintscript-helper.
> - debian/*.postinst: remove old /var/run/sudo to /var/lib/sudo
>   transition code, remove old /var/lib/sudo/ts timestamp directory.


It seems, sudo was originally using /var/run/sudo, but switched to
/var/lib/sudo because of #581393.
Moving back everything to /var/run/sudo will reopen this issue, i.e. the
users will get the lecture again upon reboots.

Imo, the best solution would be, if the "lectured" dir was on /var/lib
and the timestamp "ts" dir on /run. This way no init script / service
would be needed on reboots to clean up the timestamps and the lectured
messages would be preserved.
Building with
--with-rundir=/run/sudo \
--with-vardir=/var/lib/sudo \
seems to achieve that.

sudo creates /run/sudo/ts on demand, but it fails to apply the correct
selinux context. So if you care about selinux we should keep the
sysvinit script to run mkdir and restorecon. For systemd, a tmpfile
snippet could achieve that.

Bdale, would you be ok with that change? If so, I could prepare a patch
depending on whether you want to support selinux or not.

Regards,
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#868597: apertium-is-sv FTBFS: Error: Position on line 129 near `O Prop + Ant + Fem) ` - stand-alone o or O doesn't make sense - maybe you meant 0?

[Adrian Bunk]

Source: apertium-is-sv
Version: 0.1.0~r56030-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes apertium-is-sv FTBFS:

https://tests.reproducible-builds.org/debian/history/apertium-is-sv.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apertium-is-sv.html

...
cg-comp apertium-is-sv.is-sv.rlx is-sv.rlx.bin
apertium-is-sv.is-sv.rlx: Error: Position on line 129 near `O Prop + Ant + Fem) 
` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-is-sv.is-sv.rlx: Error: Position on line 130 near `O Prop + Ant + Fem) 
` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-is-sv.is-sv.rlx: Error: Position on line 146 near `O A) (O N) (-1C 
VVer` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-is-sv.is-sv.rlx: Error: Position on line 148 near `O A) (O N) (1C N) 
(0` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-is-sv.is-sv.rlx: Error: Position on line 149 near `O A) (O N) (1C N) 
(0` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-is-sv.is-sv.rlx: Error: Position on line 150 near `O A) (O N) (1C N) 
(0` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-is-sv.is-sv.rlx: Error: Position on line 151 near `O A) (O N) (1C N) 
(0` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-is-sv.is-sv.rlx: Error: Position on line 155 near `O Prop) (1 Prop); 
#I` - stand-alone o or O doesn't make sense - maybe you meant 0?
Error: Grammar could not be parsed - exiting!
Makefile:714: recipe for target 'is-sv.rlx.bin' failed
make[1]: *** [is-sv.rlx.bin] Error 1
make[1]: Leaving directory '/build/1st/apertium-is-sv-0.1.0~r56030'
dh_auto_build: make -j1 returned exit code 2
debian/rules:9: recipe for target 'build' failed
make: *** [build] Error 2

Bug#866376: [Pkg-utopia-maintainers] Bug#866376: network-manager: Network-Manager cause kernel panic

[Ben Hutchings]

Control: retitle -1 rtl8723be: Hangs in rtl8723_fw_free_to_go
Control: severity -1 important

On Fri, 2017-06-30 at 09:34 +0200, Dario Maiocchi wrote:
> Ciao Guys,
> 
> thx for prompt feedback. Since is my secondary workstation, i didn't 
> have access. (since wifi was broken, i had ethernet with a telephone)
> 
> If you need some other extra infos, just ping me, i will give you the 
> info next week.
> 
> @Ben is the driver needinfo still actual? Sorry, for kernel issue i'm 
> still a newbie :)

No, since I worked out what the driver is.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
- Carolyn Scheppner


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

Bug#868601: ganeti FTBFS: Can't find reST role named 'manpage': 'manpage'

[Adrian Bunk]

Source: ganeti
Version: 2.15.2-9
Severity: serious

https://buildd.debian.org/status/package.php?p=ganeti

...
PYTHONPATH=. ./autotools/run-in-tempdir /<>/./autotools/build-rpc 
lib/rpc_defs.py > lib/_generated_rpc.py
Checking man/ganeti-cleaner.rst for hardcoded paths...
set -e ; \
trap 'echo auto-removing man/ganeti-cleaner.gen; rm man/ganeti-cleaner.gen' 
EXIT; \
PYTHONPATH=. ./autotools/run-in-tempdir /<>/./autotools/docpp < 
man/ganeti-cleaner.rst > man/ganeti-cleaner.gen ;\
./autotools/check-man-references man/ganeti-cleaner.gen; \
trap - EXIT
Traceback (most recent call last):
  File "/<>/./autotools/docpp", line 39, in 
from ganeti.build import sphinx_ext
  File "/tmp/gntbuild.AeveSE6h/ganeti/build/sphinx_ext.py", line 56, in 
raise Exception("Can't find reST role named 'manpage': %s" % err)
Exception: Can't find reST role named 'manpage': 'manpage'
auto-removing man/ganeti-cleaner.gen
Makefile:4560: recipe for target 'man/ganeti-cleaner.gen' failed
make[2]: *** [man/ganeti-cleaner.gen] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/<>'
dh_auto_build: make -j4 returned exit code 2
debian/rules:82: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2

Bug#868602: bats FTBFS: test failures

[Adrian Bunk]

Source: bats
Version: 0.4.0-1.1
Severity: serious
Tags: buster sid

Some recent change in unstable makes bats FTBFS:

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

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/bats-0.4.0'
TERM=dumb bin/bats --tap test
1..43
ok 1 no arguments prints usage instructions
ok 2 -v and --version print version number
ok 3 -h and --help print help
ok 4 invalid filename prints an error
ok 5 empty test file runs zero tests
ok 6 one passing test
not ok 7 summary passing tests
# (in test file test/bats.bats, line 46)
#   `[ "${lines[1]}" = "1 test, 0 failures" ]' failed
not ok 8 summary passing and skipping tests
# (in test file test/bats.bats, line 52)
#   `[ "${lines[2]}" = "2 tests, 0 failures, 1 skipped" ]' failed
not ok 9 summary passing and failing tests
# (in test file test/bats.bats, line 58)
#   `[ "${lines[4]}" = "2 tests, 1 failure" ]' failed
not ok 10 summary passing, failing and skipping tests
# (in test file test/bats.bats, line 64)
#   `[ "${lines[5]}" = "3 tests, 1 failure, 1 skipped" ]' failed
ok 11 one failing test
ok 12 one failing and one passing test
ok 13 failing test with significant status
ok 14 failing helper function logs the test case's line number
ok 15 test environments are isolated
ok 16 setup is run once before each test
ok 17 teardown is run once after each test, even if it fails
ok 18 setup failure
ok 19 passing test with teardown failure
ok 20 failing test with teardown failure
ok 21 teardown failure with significant status
ok 22 failing test file outside of BATS_CWD
ok 23 load sources scripts relative to the current test file
ok 24 load aborts if the specified script does not exist
ok 25 load sources scripts by absolute path
ok 26 load aborts if the script, specified by an absolute path, does not exist
ok 27 output is discarded for passing tests and printed for failing tests
ok 28 -c prints the number of tests
ok 29 dash-e is not mangled on beginning of line
ok 30 dos line endings are stripped before testing
ok 31 test file without trailing newline
ok 32 skipped tests
ok 33 extended syntax
not ok 34 pretty and tap formats
# (in test file test/bats.bats, line 237)
#   `[ $status -eq 0 ]' failed
ok 35 pretty formatter bails on invalid tap
ok 36 single-line tests
ok 37 running a suite with no test files
ok 38 running a suite with one test file
ok 39 counting tests in a suite
ok 40 aggregated output of multiple tests in a suite
ok 41 a failing test in a suite results in an error exit code
ok 42 running an ad-hoc suite by specifying multiple test files
ok 43 extended syntax in suite
debian/rules:14: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#866190: linux-image-4.9.0-3-amd64: Kernel panics and locks up on heavy disk load

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Tue, 2017-06-27 at 22:15 -0700, jmol...@swoncology.net wrote:
> Package: src:linux
> Version: 4.9.30-2
> Severity: normal
> 
> Please see attached kernel messages collected from the /var/log/messages
> file post-reboot.

Have you seen multiple crashes with a warning logged referring to the
same file (fs/dcache.c)?  Or do you see different filenames or messages
every time?

> This is at least the third time this has happened in the last couple of
> months. Each and every event occured just after the system had just
> started an rsync backup from the local disks to a local USB3 drive. The
> backup job is nightly, so this only happens once every 1-2 months on
> average.
> 
> The system is a Dell Optiplex 3020 Haswell with 3x 1TB SATA drives
> (terribly slow) in a mdadm RAID5. The Dell BIOS is up to date.
>
> The problem first manifested itself after upgrading from old stable (Deb
> 8) to unstable maybe five-six months ago. Prior to that, the system had
> been very stable.

"Optiplex 3020" appears to refer to two desktop models that are both
physically small and possibly not designed for this number of drives. 
Are you sure that there is sufficient air flow to cool the hardware
(CPU, motherboard, drives)?

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
- Carolyn Scheppner



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

Bug#868497: debian-policy: Signed .dsc Files

[Paul Hardy]

Russ,

On Sun, Jul 16, 2017 at 10:56 AM, Russ Allbery  wrote:
> Paul Hardy  writes:
>
>> ...Debian Policy Manual, Section 5.4, "Debian source control files - .dsc",
>> states in the first sentence:
>
>> "This file consists of a single paragraph, possibly surrounded by a PGP
>> signature."
>
>> This does not state whether someone who is creating a package to be
>> uploaded by a sponsor can clearsign their own .dsc file, or if only the
>> sponsor is able to do that without causing upload problems.
>
>> What is permissible?  Can you clarify that in a future update to this
>> section?
>
> (I'm pretty sure the actual answer to this question is that nothing
> cares.)...

I was wondering if a maintainer signed a .dsc file in a package that
was uploaded (and hence signed) by a sponsor, that the FTP server
would reject the .dsc file for having an invalid signature.

Could the wording be changed to "...possibly surrounded by the
maintainer's PGP signature"?  The term "maintainer" is implicitly
defined in the Policy Manual through repeated mention.

Of course, out of context of this request someone might think "of
course the maintainer would sign the .dsc file--who else would do
that?"

Thanks,


Paul Hardy

Bug#868606: hol-light FTBFS: Error: This expression has type (MLast.loc * string Ploc.vala) Ploc.vala but an expression was expected of type MLast.loc * 'a

[Adrian Bunk]

Source: hol-light
Version: 20170109-1
Severity: serious
Tags: buster sid

Some recent change in unstable make hol-light FTBFS:

https://tests.reproducible-builds.org/debian/history/hol-light.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/hol-light.html

...
make
make[2]: Entering directory '/build/1st/hol-light-20170109'
if test `ocamlc -version | cut -c1-3` = "3.0" ; \
   then ocamlc -c -pp "camlp4r pa_extend.cmo q_MLast.cmo" -I 
`camlp4 -where` pa_j.ml ; \
   else if test `ocamlc -version | cut -c1-3` = "3.1" -o 
`ocamlc -version | cut -c1-4` = "4.00" -o `ocamlc -version | cut -c1-4` = 
"4.01"  -o `ocamlc -version | cut -c1-4` = "4.02" -o `ocamlc -version | cut 
-c1-4` = "4.03" ; \
then  ocamlc -c -pp "camlp5r pa_lexer.cmo pa_extend.cmo 
q_MLast.cmo" -I `camlp5 -where` pa_j.ml ; \
else ocamlc -safe-string -c -pp "camlp5r pa_lexer.cmo 
pa_extend.cmo q_MLast.cmo" -I `camlp5 -where` pa_j.ml ; \
fi \
   fi
File "pa_j.ml", line 359, characters 46-48:
Error: This expression has type (MLast.loc * string Ploc.vala) Ploc.vala
   but an expression was expected of type MLast.loc * 'a
Makefile:40: recipe for target 'pa_j.cmo' failed
make[2]: *** [pa_j.cmo] Error 2
make[2]: Leaving directory '/build/1st/hol-light-20170109'
debian/rules:31: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2

Bug#868605: libsnappy-dev lost static libraries

[Adrian Bunk]

Package: libsnappy-dev
Version: 1.1.6-1
Severity: serious
Control: affects -1 src:apitrace

1.1.4-3 -> 1.1.6-1 the following libraries disappeared:
/usr/lib/x86_64-linux-gnu/libsnappy-shared.a
/usr/lib/x86_64-linux-gnu/libsnappy.a

This is causing the following FTBFS in apitrace:

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

...
-- Using unsigned short
-- Check if the system is big endian - little endian
-- Using static SNAPPY
-- Found SNAPPY: /usr/lib/x86_64-linux-gnu/libsnappy.so  
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found suitable version 
"1.2.8", minimum required is "1.2.6") 
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8") 
-- Found PNG: /usr/lib/x86_64-linux-gnu/libpng.so (found version "1.6.30") 
-- Performing Test STATIC_LIBSTDCXX_PIC
-- Performing Test STATIC_LIBSTDCXX_PIC - Success
CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
SNAPPY_STATIC_LIBRARIES
linked by target "trace" in directory 
/build/1st/apitrace-7.1+git20170623.d38a69d6+repack/wrappers

-- Configuring incomplete, errors occurred!

Bug#868617: golang-github-dnephin-cobra FTBFS: test failures

[Adrian Bunk]

Source: golang-github-dnephin-cobra
Version: 1.5+git20161103.0.a3c0924-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes golang-github-dnephin-cobra FTBFS:

https://tests.reproducible-builds.org/debian/history/golang-github-dnephin-cobra.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-dnephin-cobra.html

...
--- FAIL: TestChildCommandFlags (0.00s)
cobra_test.go:646: Wrong error message displayed, 
 invalid argument "10E" for "-i, --intone" flag: 
strconv.ParseInt: parsing "10E": invalid syntax
...
--- FAIL: TestFlagsBeforeCommand (0.00s)
cobra_test.go:1066: Wrong error message displayed, 
 invalid argument "10E" for "-i, --intone" flag: 
strconv.ParseInt: parsing "10E": invalid syntax
...
FAIL
exit status 1
FAILgithub.com/spf13/cobra  0.054s
?   github.com/spf13/cobra/cobra[no test files]
...

Bug#757760: debian-policy: please document build profiles

[Ben Hutchings]

On Wed, 2017-06-21 at 16:01 -0700, Jonathan Nieder wrote:
[...]
> I'd like to restart this discussion.  My understanding is that all the
> relevant infrastructure for build profiles is in place, so what's left
> is to add some text to policy documenting it.
> 
> Is my understanding correct?  Any thoughts before I (or someone else)
> starts to port the change-based language from
> https://wiki.debian.org/BuildProfileSpec to current-state based
> language in policy?
> 
> Kernel team, any notes from your experience using build profiles?

So far as I can remember, I found the wiki page and dpkg manual pages
sufficient when I was adding support for build profiles in src:linux.

However, I can see it has changed since I last looked and now says that
"stage1" has been deprecated.  I don't understand why this is or how
we're supposed to give this hint to bootstrapping tools now.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
- Carolyn Scheppner



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

Bug#868615: python-pbr FTBFS: AttributeError: No such config value: man_pages

[Adrian Bunk]

Source: python-pbr
Version: 1.10.0-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes python-pbr FTBFS:

https://tests.reproducible-builds.org/debian/history/python-pbr.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-pbr.html

...
creating /tmp/tmpLv88bQ/tmpe_TKsh/testpackage/build/sphinx/man
Traceback (most recent call last):
  File "setup.py", line 21, in 
pbr=True,
  File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
  File "/build/1st/python-pbr-1.10.0/pbr/builddoc.py", line 196, in run
self._sphinx_run()
  File "/build/1st/python-pbr-1.10.0/pbr/builddoc.py", line 141, in _sphinx_run
if self.builder == 'man' and len(sphinx_config.man_pages) == 0:
  File "/usr/lib/python2.7/dist-packages/sphinx/config.py", line 275, in 
__getattr__
raise AttributeError('No such config value: %s' % name)
AttributeError: No such config value: man_pages
}}}

Traceback (most recent call last):
  File "pbr/tests/test_core.py", line 81, in test_setup_py_build_sphinx
self.assertEqual(return_code, 0)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 350, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 435, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 1 != 0


--
Ran 165 tests in 92.079s

FAILED (failures=1, skipped=20)
debian/rules:24: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#868616: seaborn FTBFS: ImportError: No module named pytest

[Adrian Bunk]

Source: seaborn
Version: 0.7.1-4
Severity: serious
Tags: buster sid

Some recent change in unstable makes seaborn FTBFS:

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

...
seaborn.tests.test_rcmod.TestPlottingContext.test_font_scale ... ok
seaborn.tests.test_rcmod.TestPlottingContext.test_key_usage ... ok
seaborn.tests.test_rcmod.TestPlottingContext.test_rc_override ... ok
seaborn.tests.test_rcmod.TestPlottingContext.test_set_context ... ok
Failure: ImportError (No module named pytest) ... ERROR

==
ERROR: Failure: ImportError (No module named pytest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 418, in 
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File 
"/build/1st/seaborn-0.7.1/.pybuild/pythonX.Y_2.7/build/seaborn/tests/test_utils.py",
 line 349, in 
@network(url="https://github.com/mwaskom/seaborn-data;)
  File "/usr/lib/python2.7/dist-packages/pandas/util/testing.py", line 2194, in 
dec
return decorator(f, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pandas/util/testing.py", line 2363, in 
network
from pytest import skip
ImportError: No module named pytest

--
Ran 394 tests in 176.699s

FAILED (SKIP=5, errors=1)
E: pybuild pybuild:283: test: plugin custom failed with: exit code=1: nosetests 
-s -v /build/1st/seaborn-0.7.1/.pybuild/pythonX.Y_2.7/build/
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:28: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25

Bug#868622: mathgl FTBFS: error: 'op_lshift' is not a member of 'octave_value'

[Adrian Bunk]

Source: mathgl
Version: 2.4-1
Severity: serious

https://buildd.debian.org/status/package.php?p=mathgl=sid

...
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx: In function 
'void SWIG_InstallBinaryOps(int, int)':
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:2099:46: 
error: 'op_lshift' is not a member of 'octave_value'
 if 
(!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \
  ^
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:2147:5: note: 
in expansion of macro 'swigreg_binary_op'
 swigreg_binary_op(lshift);
 ^
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:2100:43: 
error: 'op_lshift' is not a member of 'octave_value'
 
octave_value_typeinfo::register_binary_op(octave_value::op_##name,tid1,tid2,swig_binary_op_##name);
   ^
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:2147:5: note: 
in expansion of macro 'swigreg_binary_op'
 swigreg_binary_op(lshift);
 ^
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:2099:46: 
error: 'op_rshift' is not a member of 'octave_value'
 if 
(!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \
  ^
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:2148:5: note: 
in expansion of macro 'swigreg_binary_op'
 swigreg_binary_op(rshift);
 ^
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:2100:43: 
error: 'op_rshift' is not a member of 'octave_value'
 
octave_value_typeinfo::register_binary_op(octave_value::op_##name,tid1,tid2,swig_binary_op_##name);
   ^
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:2148:5: note: 
in expansion of macro 'swigreg_binary_op'
 swigreg_binary_op(rshift);
 ^
...
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx: In function 
'octave_value_list Fmathgl(const octave_value_list&, int)':
/<>/obj-aarch64-linux-gnu/lang/mathglOCTAVE_wrap.cxx:143179:27: 
error: 'octave_call_stack' has not been declared
 octave_function *me = octave_call_stack::current();
   ^
...

Bug#868623: RM: haskell-hashable-extras -- ROM; obsolete, deprecated in favor of haskell-hashable

[Clint Adams]

Package: ftp.debian.org
Severity: normal

haskell-hashable-extras has been subsumed into haskell-hashable is no
longer necessary or useful

Bug#838720: pager crashes when maildir is modified while viewing message

[Peter Colberg]

Hi Antonio,

On Tue, Dec 06, 2016 at 08:24:43AM +, Antonio Radici wrote:
> Peter, do you have time to try neomutt standard without Debian patches? That 
> at
> least will help us to undestand if it's a rogue patch or if the problem is in
> neomutt.

I built mutt 1.7.2-1 under Debian stretch amd64 disabling these patches:

# neomutt-20170113.patch
# neomutt-devel/832971-reset-xlabel.patch

I ran "quilt refresh" for all subsequent patches in debian/patches/series.

Following the procedure described in my previous message,

https://bugs.debian.org/838720#103

mutt no longer performs an "invalid read" (see attached valgrind log).

The culprit for the pager segfault is NeoMutt.

Regards,
Peter
==19224== Memcheck, a memory error detector
==19224== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==19224== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==19224== Command: mutt
==19224== Parent PID: 19031
==19224== 
==19224== Conditional jump or move depends on uninitialised value(s)
==19224==at 0x6E16009: re_compile_fastmap_iter.isra.24 (regcomp.c:328)
==19224==by 0x6E1E6A5: re_compile_fastmap (regcomp.c:280)
==19224==by 0x6E1ED3A: regcomp (regcomp.c:509)
==19224==by 0x1443F7: parse_attach_list (init.c:971)
==19224==by 0x1443F7: parse_attachments (init.c:1137)
==19224==by 0x144D46: mutt_parse_rc_line.part.11 (init.c:2378)
==19224==by 0x144F3F: mutt_parse_rc_line (init.c:2300)
==19224==by 0x144F3F: source_rc (init.c:2286)
==19224==by 0x14826E: mutt_init (init.c:3194)
==19224==by 0x11CCA3: main (main.c:798)
==19224== 
==19224== Conditional jump or move depends on uninitialised value(s)
==19224==at 0x6E16009: re_compile_fastmap_iter.isra.24 (regcomp.c:328)
==19224==by 0x6E1E6C7: re_compile_fastmap (regcomp.c:282)
==19224==by 0x6E1ED3A: regcomp (regcomp.c:509)
==19224==by 0x1443F7: parse_attach_list (init.c:971)
==19224==by 0x1443F7: parse_attachments (init.c:1137)
==19224==by 0x144D46: mutt_parse_rc_line.part.11 (init.c:2378)
==19224==by 0x144F3F: mutt_parse_rc_line (init.c:2300)
==19224==by 0x144F3F: source_rc (init.c:2286)
==19224==by 0x14826E: mutt_init (init.c:3194)
==19224==by 0x11CCA3: main (main.c:798)
==19224== 
==19224== Conditional jump or move depends on uninitialised value(s)
==19224==at 0x6E16009: re_compile_fastmap_iter.isra.24 (regcomp.c:328)
==19224==by 0x6E1E6A5: re_compile_fastmap (regcomp.c:280)
==19224==by 0x6E1ED3A: regcomp (regcomp.c:509)
==19224==by 0x150D56: mutt_parse_hook (hook.c:186)
==19224==by 0x144D46: mutt_parse_rc_line.part.11 (init.c:2378)
==19224==by 0x144F3F: mutt_parse_rc_line (init.c:2300)
==19224==by 0x144F3F: source_rc (init.c:2286)
==19224==by 0x145181: parse_source (init.c:2336)
==19224==by 0x144D46: mutt_parse_rc_line.part.11 (init.c:2378)
==19224==by 0x144F3F: mutt_parse_rc_line (init.c:2300)
==19224==by 0x144F3F: source_rc (init.c:2286)
==19224==by 0x145181: parse_source (init.c:2336)
==19224==by 0x144D46: mutt_parse_rc_line.part.11 (init.c:2378)
==19224==by 0x144F3F: mutt_parse_rc_line (init.c:2300)
==19224==by 0x144F3F: source_rc (init.c:2286)
==19224== 
==19224== Conditional jump or move depends on uninitialised value(s)
==19224==at 0x6E16009: re_compile_fastmap_iter.isra.24 (regcomp.c:328)
==19224==by 0x6E1E6C7: re_compile_fastmap (regcomp.c:282)
==19224==by 0x6E1ED3A: regcomp (regcomp.c:509)
==19224==by 0x150D56: mutt_parse_hook (hook.c:186)
==19224==by 0x144D46: mutt_parse_rc_line.part.11 (init.c:2378)
==19224==by 0x144F3F: mutt_parse_rc_line (init.c:2300)
==19224==by 0x144F3F: source_rc (init.c:2286)
==19224==by 0x145181: parse_source (init.c:2336)
==19224==by 0x144D46: mutt_parse_rc_line.part.11 (init.c:2378)
==19224==by 0x144F3F: mutt_parse_rc_line (init.c:2300)
==19224==by 0x144F3F: source_rc (init.c:2286)
==19224==by 0x145181: parse_source (init.c:2336)
==19224==by 0x144D46: mutt_parse_rc_line.part.11 (init.c:2378)
==19224==by 0x144F3F: mutt_parse_rc_line (init.c:2300)
==19224==by 0x144F3F: source_rc (init.c:2286)
==19224== 
==19231== Warning: invalid file descriptor 1024 in syscall close()
==19231== Warning: invalid file descriptor 1025 in syscall close()
==19231== Warning: invalid file descriptor 1026 in syscall close()
==19231== Warning: invalid file descriptor 1027 in syscall close()
==19231==Use --log-fd= to select an alternative log fd.
==19231== Warning: invalid file descriptor 1028 in syscall close()
==19231== Warning: invalid file descriptor 1029 in syscall close()
==19230== 
==19230== HEAP SUMMARY:
==19230== in use at exit: 1,440,290 bytes in 3,179 blocks
==19230==   total heap usage: 4,385 allocs, 1,206 frees, 1,639,162 bytes 
allocated
==19230== 
==19230== LEAK SUMMARY:
==19230==definitely lost: 0 bytes in 0 blocks
==19230==indirectly lost: 0 bytes in 0 blocks
==19230==  possibly lost: 0 

Bug#868624: geogebra FTBFS: error: unmappable character for encoding utf-8

[Adrian Bunk]

Source: geogebra
Version: 4.0.34.0+dfsg1-3
Severity: serious
Tags: buster sid

Some recent change in unstable makes geogebra FTBFS:

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

...
   debian/rules override_jh_build
make[1]: Entering directory '/build/1st/geogebra-4.0.34.0+dfsg1'
dh /usr/share/topgit/tg2quilt.mk --with javahelper
dh: Unknown sequence /usr/share/topgit/tg2quilt.mk (choose from: binary 
binary-arch binary-indep build build-arch build-indep clean install 
install-arch install-indep)
xsltproc -''-nonet -''-param man.charmap.use.subset "0" 
/usr/share/sgml/docbook/stylesheet/xsl/docbook-xsl/manpages/docbook.xsl 
debian/geogebra.man.xml
I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
debian/geogebra.man.xml:55: warning: failed to load external entity 
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
]>
  ^
Note: Writing geogebra.1
xsltproc -''-nonet -''-param man.charmap.use.subset "0" 
/usr/share/sgml/docbook/stylesheet/xsl/docbook-xsl/manpages/docbook.xsl 
debian/ggthumb.man.xml
I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
debian/ggthumb.man.xml:55: warning: failed to load external entity 
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
]>
  ^
Note: Writing ggthumb.1
jh_build -N -mgeogebra.GeoGebra -o'-encoding utf-8'
find src -name *.java -and -type f -print0 | xargs -s 512000 -0 
/usr/lib/jvm/default-java/bin/javac -g -cp 
/usr/share/java/mathpiper.jar:/usr/share/java/commons-math.jar:/usr/share/java/freehep-xml.jar:/usr/share/java/freehep-util.jar:/usr/share/java/freehep-graphics2d.jar:/usr/share/java/freehep-io.jar:/usr/share/java/freehep-graphicsio.jar:/usr/share/java/freehep-graphicsio-svg.jar:/usr/share/java/freehep-graphicsio-pdf.jar:/usr/share/java/freehep-graphicsio-emf.jar:/usr/share/icedtea-web/plugin.jar:/usr/share/java/jlatexmath.jar:/usr/share/java/commons-collections3.jar:/usr/share/java/jfugue.jar:/usr/share/java/js.jar:debian/_jh_build.geogebra
 -d debian/_jh_build.geogebra -source 1.7 -target 1.7 -encoding utf-8
warning: [options] bootstrap class path not set in conjunction with -source 1.7
src/geogebra/gui/DecorationAngleListRenderer.java:19: error: unmappable 
character for encoding utf-8
 * @author Lo?c Le Coq
 ^
src/geogebra/gui/DecorationListRenderer.java:16: error: unmappable character 
for encoding utf-8
 * @author Le Coq Lo?c
^
2 errors
1 warning
debian/rules:38: recipe for target 'override_jh_build' failed
make[1]: *** [override_jh_build] Error 123

Bug#868625: RM: haskell-fail -- ROM; obsolete

[Clint Adams]

Package: ftp.debian.org
Severity: normal

haskell-fail is obsolete and unnecessary

Bug#868626: libgarcon-1-0-dev is not installable

[Adrian Bunk]

Package: libgarcon-1-0-dev
Version: 0.6.1-1
Severity: serious

Package: libgarcon-1-0-dev
Version: 0.6.1-1
Depends: libgarcon-1-dev

Package: libgarcon-1-dev
Version: 0.6.1-1
Breaks: libgarcon-1-0-dev

Bug#868628: haskell-hledger build-depends libghc-megaparsec-dev (< 5.2) but 5.2.0-2+b3 is to be installed

[Adrian Bunk]

Source: haskell-hledger
Version: 1.1-2
Severity: serious

The following packages have unmet dependencies:
 builddeps:haskell-hledger : Depends: libghc-megaparsec-dev (< 5.2) but 
5.2.0-2+b3 is to be installed

Bug#868627: arbtt build-depends libghc-aeson-dev (< 0.12) but 1.0.2.1-3 is to be installed

[Adrian Bunk]

Source: arbtt
Version: 0.9.0.9-1
Severity: serious
Tags: buster sid

The following packages have unmet dependencies:
 builddeps:arbtt : Depends: libghc-aeson-dev (< 0.12) but 1.0.2.1-3 is to be 
installed

Bug#868629: haskell-werewolf: << build dependencies on packages with a more recent version

[Adrian Bunk]

Source: haskell-werewolf
Version: 1.5.1.1-6
Severity: serious

The following packages have unmet dependencies:
 builddeps:haskell-werewolf : Depends: libghc-aeson-dev (< 0.12) but 1.0.2.1-3 
is to be installed
  Depends: libghc-lens-dev (< 4.15) but 4.15.1-1 is 
to be installed

Bug#868630: mutt: segfault when paging through a message

[Ben Elliston]

Package: mutt
Version: 1.8.3+neomutt20170609-2
Severity: important

Dear Maintainer,

Mutt segfaults, intermittently, when paging through a message.  It happens
several times a week, so hardly a rare occurrence.

   * What outcome did you expect instead?

No segfault.

I upgraded to the latest version, but no improvement.


-- Package-specific info:
NeoMutt 20170609 (1.8.3)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0-3-686-pae (i686)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-19' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=i686-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-i386/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-i386 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-i386 
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--with-target-system-
 zlib --enable-objc-gc=auto --enable-targets=all --enable-multiarch 
--with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=i686-linux-gnu 
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 6.3.0 20170618 (Debian 6.3.0-19) 

Configure options: '--build=i686-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/i386-linux-gnu' 
'--libexecdir=\${prefix}/lib/i386-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-lua' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--enable-notmuch' 
'--disable-fmemopen' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' 
'--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' 
'--without-qdbm' '--with-tokyocabinet' 'build_alias=i686-linux-gnu' 'CFLAGS=-g 
-O2 -fdebug-prefix-map=/build/mutt-VYeE6A/mutt-1.8.3+neomutt20170609=. 
-fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,
 relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-VYeE6A/mutt-1.8.3+neomutt20170609=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-fno-delete-null-pointer-checks

Compile options:
  +attach_headers_color +bkgdset +color +compose_to_sender +compress +cond_date 
  +curs_set +debug +dotlock +encrypt_to_self -exact_address +fcntl -flock 
  -fmemopen +forgotten_attachments +forwref +futimens +getaddrinfo +getsid 
  +gnutls +gpgme +gss +hcache -homespool -iconv_nontrans +ifdef +imap 
  +index_color +initials +keywords +libidn +limit_current_thread +lmdb 
  -locales_hack +lua +meta +mixmaster +multiple_fcc +nested_if +new_mail +nls 
  +nntp +notmuch -openssl +pgp +pop +progress +quasi_delete +regcomp 
  +reply_with_xorig +resizeterm +sasl +sensible_browser -setgid +sidebar 
  +skip_quoted +smime +smtp +start_color +status_color +sun_attachment +timeout 
  +tls_sni +trash +typeahead +wc_funcs 
EXECSHELL="/bin/sh"
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/mutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: http://www.neomutt.org/
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 


-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_US:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mutt depends on:
ii  libassuan02.4.3-2

Bug#868631: sks FTBFS: No implementations provided for module Z referenced from cryptokit.cmxa

[Adrian Bunk]

Source: sks
Version: 1.1.6-4
Severity: serious
Tags: buster sid

Some recent change in unstable makes sks FTBFS:

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

...
ocamlopt -I lib -I bdb -I +cryptokit   -ccopt -g  -ccopt -O2  -ccopt 
-fstack-protector-strong  -ccopt -Wformat  -ccopt -Werror=format-security  
-ccopt -O3  -ccopt -Werror-implicit-function-declaration  -ccopt 
-I/usr/lib/ocaml  -ccopt -I  -ccopt .  -ccopt -Wdate-time  -ccopt 
-D_FORTIFY_SOURCE=2  -ccopt -Wl,-z,relro  -ccopt -Wl,-z,now -runtime-variant 
_pic -ccopt -Lbdb -dtypes  -inline 40 unix.cmxa str.cmxa bdb.cmxa nums.cmxa 
bigarray.cmxa cryptokit.cmxa -c sks.ml
ocamlopt -o sks -I lib -I bdb -I +cryptokit   -ccopt -g  -ccopt -O2  -ccopt 
-fstack-protector-strong  -ccopt -Wformat  -ccopt -Werror=format-security  
-ccopt -O3  -ccopt -Werror-implicit-function-declaration  -ccopt 
-I/usr/lib/ocaml  -ccopt -I  -ccopt .  -ccopt -Wdate-time  -ccopt 
-D_FORTIFY_SOURCE=2  -ccopt -Wl,-z,relro  -ccopt -Wl,-z,now -runtime-variant 
_pic -ccopt -Lbdb -dtypes  -inline 40 unix.cmxa str.cmxa bdb.cmxa nums.cmxa 
bigarray.cmxa cryptokit.cmxa crc.o pSet.cmx pMap.cmx utils.cmx heap.cmx 
mList.cmx mTimer.cmx mArray.cmx settings.cmx pstyle.cmx getfileopts.cmx 
common.cmx channel.cmx eventloop.cmx ehandlers.cmx bitstring.cmx 
meteredChannel.cmx number.cmx prime.cmx zZp.cmx rMisc.cmx linearAlg.cmx 
poly.cmx decode.cmx fqueue.cmx prefixTree.cmx msgContainer.cmx 
nbMsgContainer.cmx cMarshal.cmx reconMessages.cmx server.cmx client.cmx 
reconCS.cmx number_test.cmx decode_test.cmx poly_test.cmx Unique_time.cmx 
version.cmx packet.cmx parsePGP.cmx sStream.cmx bdbwrap.cmx key.cmx keyHa
 sh.cmx keyMerge.cmx fixkey.cmx fingerprint.cmx keydb.cmx armor.cmx 
dbMessages.cmx htmlTemplates.cmx wserver.cmx membership.cmx tester.cmx 
request.cmx stats.cmx index.cmx mRindex.cmx pTreeDB.cmx sendmail.cmx 
recvmail.cmx mailsync.cmx clean_keydb.cmx build.cmx fastbuild.cmx pbuild.cmx 
merge_keyfiles.cmx sksdump.cmx incdump.cmx dbserver.cmx reconComm.cmx 
recoverList.cmx catchup.cmx reconserver.cmx update_subkeys.cmx sks_do.cmx 
unit_tests.cmx sks.cmx
File "_none_", line 1:
Error: No implementations provided for the following modules:
 Z referenced from 
/usr/lib/ocaml/cryptokit/cryptokit.cmxa(CryptokitBignum)
Makefile:180: recipe for target 'sks' failed
make[2]: *** [sks] Error 2

Bug#868632: gitit: << build dependencies on packages with a more recent version

[Adrian Bunk]

Source: gitit
Version: 0.12.1.1+dfsg-6
Severity: serious
Tags: buster sid


The following packages have unmet dependencies:
 builddeps:gitit : Depends: libghc-aeson-dev (< 0.12) but 1.0.2.1-3 is to be 
installed
   Depends: libghc-http-client-tls-dev (< 0.3) but 0.3.5.1-1+b2 
is to be installed

Bug#868633: haskell-blogliterately build-depends on libghc-lens-dev (< 4.15) but 4.15.1-1 is to be installed

[Adrian Bunk]

Source: haskell-blogliterately
Version: 0.8.4-3
Severity: serious
Tags: buster sid

The following packages have unmet dependencies:
  Depends: libghc-lens-dev (< 4.15) but 4.15.1-1 is to be installed

Bug#868636: rss2irc build-depends on libghc-http-client-dev (< 0.5) but 0.5.7.0-1+b3 is to be installed

[Adrian Bunk]

Source: rss2irc
Version: 1.1-1
Severity: serious
Tags: buster sid

The following packages have unmet dependencies:
 builddeps:rss2irc : Depends: libghc-http-client-dev (< 0.5) but 0.5.7.0-1+b3 
is to be installed
 

Bug#868635: pkg-haskell-tools build-depends on libghc-optparse-applicative-dev (< 0.13) but 0.13.2.0-1+b1 is to be installed

[Adrian Bunk]

Source: pkg-haskell-tools
Version: 0.10.4
Severity: serious
Tags: buster sid

The following packages have unmet dependencies:
 builddeps:pkg-haskell-tools : Depends: libghc-optparse-applicative-dev (< 
0.13) but 0.13.2.0-1+b1 is to be installed

Bug#868634: haskell-yesod-auth-oauth2: << build dependencies on packages with a more recent version

[Adrian Bunk]

Source: haskell-yesod-auth-oauth2
Version: 0.2.2-2
Severity: serious
Tags: buster sid

The following packages have unmet dependencies:
 builddeps:haskell-yesod-auth-oauth2 : Depends: libghc-aeson-dev (< 0.12) but 
1.0.2.1-3 is to be installed
   Depends: libghc-http-client-dev (< 0.5) 
but 0.5.7.0-1+b3 is to be installed

Bug#868637: yi build-depends on libghc-yi-rope-dev (< 0.8) but 0.8-1 is to be installed

[Adrian Bunk]

Source: yi
Version: 0.12.6-4
Severity: serious

The following packages have unmet dependencies:
 builddeps:yi : Depends: libghc-yi-rope-dev (< 0.8) but 0.8-1 is to be installed

Bug#868638: heimdal-kdc: m-key installed by postinst apparently not used

[Ryan Tandy]

Package: heimdal-kdc
Version: 7.4.0.dfsg.1-1
Severity: normal

Dear maintainer,

heimdal-kdc.postinst runs kstash(8) to generate a master key. This key 
is written to /var/lib/heimdal-kdc/m-key. However, kadmin(8) and kdc(8) 
try to read the master key from /var/lib/heimdal-kdc/heimdal.mkey 
(strace confirms the comment in kdc.conf). I'm not certain but it seems 
the result is the database is silently stored unencrypted.


I was about to suggest 'kadmin -c /etc/heimdal-kdc/kdc.conf -l stash', 
but it seems this also doesn't use DBNAME.mkey as a default! I think 
I'll raise that upstream. Not to mention the lack of even a warning when 
the mkey file doesn't exist.


A possible solution would be to install the default mkey with an 
explicit 'kstash -k /var/lib/heimdal-kdc/heimdal.mkey' (until the 
default changes again, anyway).


thanks,
Ryan

Bug#868493: ifupdown: no match using mac/XXX/=foo

[Adam Borowski]

On Sun, Jul 16, 2017 at 01:44:35PM +0200, Guus Sliepen wrote:
> On Sun, Jul 16, 2017 at 05:21:15AM +0200, Adam Borowski wrote:
> 
> > allow-hotplug mac/00:e0:4c:11:7f:4e/=wl0
> > iface wl0 inet static
> > wpa-ssid mial
> > wpa-psk 
> > address 192.168.8.6
> > netmask 255.255.255.0
> > 
> > upgraded ifupdown to 0.8.20, and plugged the WiFi card back in.
> > 
> > It's sitting there under its old name and unconfigured as:
> > 
> > 5: wlan0:  mtu 1500 qdisc noop state DOWN group 
> > default qlen 1000
> > link/ether 00:e0:4c:11:7f:4e brd ff:ff:ff:ff:ff:ff
> 
> Fix is uploaded. However, note that ifupdown still doesn't rename
> interfaces. After the fix your wlan0 interface will be configured
> according to the info in the wl0 stanza, as if you'd typed:
> 
> ifup wlan0=wl0

With the new version, manually bringing it up with the above command works;
hotplug nor coldplug do not.


-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#868640: hdb_generate_key_set_password broke ABI

[Ryan Tandy]

Package: libhdb9-heimdal
Version: 7.4.0.dfsg.1-1
Severity: important
Control: affects -1 slapd-smbk5pwd

Dear maintainer,

In heimdal 7.2.0 the arguments to hdb_generate_key_set_password changed; 
see https://github.com/heimdal/heimdal/issues/246


I just updated openldap to build against the new (old) signature, but 
there was no library transition or symbols file update, so things still 
break in the event of a partial upgrade.


Old slapd-smbk5pwd with new libhdb simply segfaults when the function is 
called; I haven't tested the reverse but I suspect it would be the same.


thanks,
Ryan

Bug#868378: RFS: nlohmann-json/2.1.1-1

[Paul Wise]

On Mon, Jul 17, 2017 at 8:09 AM, Christian Seiler wrote:

> [1] This takes a _long_ time with this package as you have huge
> test data in JSON form within the package, and if you do
> run it, redirect its output into a file, otherwise your
> terminal will be swamped with messages.
> (Also note that check-all-the-things has some false
> positives in your case, e.g. it checks for correct JSON as
> one of its checks, and your package has some intentionally
> broken JSON as unit tests.)

You can avoid the second part by turning off individual checks or
groups of checks via the flags option. There isn't yet an option to
ignore certain subdirectories, but patches for that or other ideas to
speed things up would be welcome.

check-all-the-things -c '- isutf8' -f '- json'

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#866365: libbpp-phyl FTBFS with test failures

[Andreas Tille]

Hi Julien,

your last fix seems to have cured mipsel, but mips keeps
on failing and now armhf has trouble:

https://buildd.debian.org/status/package.php?p=libbpp-phyl



-- 
http://fam-tille.de

Bug#868641: libzim-dev: Upgrade libzim to 2.0.0

[Kunal Mehta]

Package: libzim-dev
Version: 1.4-2.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Please upgrade libzim to 2.0.0. 

- From the release announcement[1]:

Here are the major changes:
* Move to meson build system (instead of autotools)
* Move to C++11 standard.
* Embedded fulltext search using Xapian (optional).
* Remove bzip2 support.
* Remove Symbian support.
* Few API changes

I started working updating the packaging on this in a "wip/2.0.0"[2] branch
to help with the kiwix packaging effort.

[1] https://lists.wikimedia.org/pipermail/offline-l/2017-June/001409.html
[2] https://anonscm.debian.org/cgit/collab-maint/zimlib.git/log/?h=wip/2.0.0

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

Kernel: Linux 4.11.9-300.fc26.x86_64 (SMP w/4 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 libzim-dev depends on:
ii  liblzma-dev  5.2.2-1.3
ii  libzim0v51.4-2.1

libzim-dev recommends no packages.

libzim-dev suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAllsOQ0XHGxlZ29rdG1A
bWVtYmVyLmZzZi5vcmcACgkQUvyOe+23/KIaVg/8Df0kYhdVaEObCx5KGTUc4kPk
Pa9mVvtS/aTLSzyFSX03xcTWrPOGJqp90AewRCuI94s0VFUeEL5TMnzQfWZ78rmU
AlEJRbyMwZxgC6FxhANaEqCoCI0FHjScg4iXnksYc0EwYNG5QQX0BQ76/oiMD83g
YOy8w3GwobIfBwhGd0b1U8JRCUAEV3IEeaQSRS45jc0XwukIU5Q1q1yUoW5vXdzA
E7k0xcY5h+wbW6wGHcuqyCZHvmbcH1padTiKcj8DaidOUuREEkdsTW53tBLlavoS
+xNPApsw6T4BRH2ta5z4/9qa1k+uB5mkt18LBwQH8e592viaOXAnCdEZL2zQ7HRz
ApTZ7f/6PAyqPiN97h+tigkq/ej9KMWss926qwmRT4df9p0rJah+SSf/SwbhCud8
z6S+bmZsZxnkcnkecB8ICTxVXEoROkzx7QxQOZoGgbwia1kf29+r8rzkFz0vGx+Y
rDUTVg5e549pnTD4X4HnRIpWKN2RxtZ+NmjD62iXWvC2z3Epm1qFjsT8LBqdCRnW
wW4nKB/jOLKgtsAFLR6UZaiRrnpMdEBMEb120G7n4965XkzBElY/bHkgHftCpf3e
OLc+dIf6joBPOzQd/Gj+no5orsvcA8t/TrQ02eocVZrlMUFzIgY1mqEkzg8NZFtf
js2tKN25mx/dKtOllfI=
=K5Pw
-END PGP SIGNATURE-

Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts

[Paul Hardy]

Sean,

On Sun, Jul 16, 2017 at 5:42 PM, Sean Whitton  wrote:
> Hello Paul,
>
> On Sun, Jul 16, 2017 at 04:28:03PM -0700, Paul Hardy wrote:
>> My intention was to point someone new to packaging fonts in Debian in
>> the direction of an easy path, rather than leaving it up to that
>> person to find things out the hard way--or worse yet, doing things the
>> hard way.
>
> Right.  It would be good to have that somewhere ...
>
>> How about a footnote pointing to
>> https://wiki.debian.org/Fonts/PackagingPolicy?  That document is not
>> formal policy, but it would make life easier for someone if they are
>> new to packaging fonts.
>>
>> Alternatively, do you think this bug report should get reassigned to
>> the New Maintainer's Guide and be addressed as a request there?  The
>> scope of that guide is mainly to walk someone through creating a
>> simple binary package.
>
> ... and the new maintainer's guide seems like a decent place.
>
> How about adding a section to that guide listing links to packaging
> guides for specific types of packages, such as fonts?

I can certainly do that if the maintainer of that package would like
to add such a section.  I have filed a bug report with a set of
proposed patches for maint-guide, and would wait for that to get
processed first (with my patches accepted or rejected).

Take care,


Paul Hardy

Bug#868497: debian-policy: Signed .dsc Files

[Paul Hardy]

On Sun, Jul 16, 2017 at 5:46 PM, Sean Whitton  wrote:
> Hello Paul,
>
> On Sun, Jul 16, 2017 at 04:36:55PM -0700, Paul Hardy wrote:
>> I was wondering if a maintainer signed a .dsc file in a package that
>> was uploaded (and hence signed) by a sponsor, that the FTP server
>> would reject the .dsc file for having an invalid signature.
>
> The sponsor would probably unpack and then rebuild the source package
> for the upload.
>
> If they didn't, and directly signed the .dsc using debsign(1), it would
> strip the sponsee's signature, and then sign both the .dsc and the
> .changes.
>
> So I believe the problem case could not arise.

Okay, if debsign will strip off any existing signature before applying
the uploader's signature, then it sounds like the situation will not
arise.

That being the case, I will close this bug.

Thank you,


Paul

Bug#868639: cmake: error while loading shared libraries: libcrypto.so.1.0.0

[Augusto Fraga Giachero]

Package: cmake
Version: 3.7.2-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I've recently migrated my server from Debian 8 to Debian 9 and installed the 
last version of cmake available to Debian Stretch.

Every time I invoke cmake a get as result:
cmake: error while loading shared libraries: libcrypto.so.1.0.0: cannot open 
shared object file: No such file or directory 

And it imediately closes.

It seems that this package has been compiled with an older version of libssl 
than what is available in the Debian Stretch repository (libssl1.0.2 and 
libssl1.1).

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

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

Versions of packages cmake depends on:
ii  cmake-data3.7.2-1
ii  dpkg  1.18.24
ii  libarchive13  3.2.2-2
ii  libc6 2.24-11+deb9u1
ii  libcurl3  7.52.1-5
ii  libexpat1 2.2.0-2+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libjsoncpp1   1.7.4-3
ii  libstdc++66.3.0-18
ii  libuv11.9.1-3
ii  procps2:3.3.12-3
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages cmake recommends:
ii  gcc   4:6.3.0-4
ii  make  4.1-9.1

Versions of packages cmake suggests:
pn  codeblocks   
pn  eclipse  
pn  ninja-build  

-- no debconf information

Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

[Drew Parsons]

On Mon, 17 Jul 2017 10:21:03 +0800 Drew Parsons 
wrote:
> 
> For whatever reason, the build does not fail on the buildd (odd, my
> test ran 842 tests, buildd only runs 830). 

Ah I see, you uploaded -4 while we were testing :)  
The bugserver didn't send me the bug traffic.

> Adding my build log again, the first attachment appears corrupted.

Still comes out corrupted in the gnome Archive Manager, but extracts
fine on the command line.

Bug#868581: xserver-xorg-video-amdgpu doesn't start due to incompatibility to DRM in Debian 9.0

[Michel Dänzer]

On 16/07/17 04:56 PM, Wolf-Dieter Groll wrote:

Package: xserver-xorg-video-amdgpu
Version: 1.2.0-1+b1
Severity: normal
Tags: newcomer

Dear Maintainer,

I tried to switch from the "radeon" to the the "amdgpu" driver
by adding /etc/X11/xorg.conf.d/20-amdgpu.conf with the following lines:
 Section "Device"
 Identifier "AMD"
 Driver "amdgpu"
 EndSection


This is invalid configuration. The xserver-xorg-video-amdgpu/radeon 
drivers can only work with the corresponding kernel driver respectively, 
and Xorg will use the right driver by default automatically.



--
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

Bug#867701: Radeon HD 6450, black screen, cursor, no console

[Michel Dänzer]

On 16/07/17 07:04 PM, Ivan Sergio Borgonovo wrote:

On 07/16/2017 05:56 PM, Michel Dänzer wrote:

Hmm, the string "EGL search path is" and the corresponding code was 
removed upstream for Mesa 10.6. Look for instances of libEGL.so.1* 
other than /usr/lib/x86_64-linux-gnu/libEGL.so.1* on your system and 
see if removing those helps.


I'm not sure about what you're asking.

On the problematic system apparently there are no packages installed 
containing libEGL*.*


apt-file search libEGL.so
libegl1-glvnd-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1
libegl1-mesa: /usr/lib/x86_64-linux-gnu/libEGL.so.1
libegl1-mesa: /usr/lib/x86_64-linux-gnu/libEGL.so.1.0.0
libegl1-mesa-dev: /usr/lib/x86_64-linux-gnu/libEGL.so
libegl1-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1
libegl1-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.375.66
libegl1-nvidia-legacy-340xx: 
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libEGL.so.1
libegl1-nvidia-legacy-340xx: 
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libEGL.so.340.102

virtualbox-guest-x11: /usr/lib/virtualbox/additions/libEGL.so
virtualbox-guest-x11: /usr/lib/virtualbox/additions/libEGL.so.1

but none of these packages are installed.

But
find /usr/lib/x86_64-linux-gnu/ -name libEGL*.*
/usr/lib/x86_64-linux-gnu/libEGL.so.1
/usr/lib/x86_64-linux-gnu/libEGL.so.1.0.0

ls -l /usr/lib/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 15 Jul 17 00:57 
/usr/lib/x86_64-linux-gnu/libEGL.so.1 -> libEGL.so.1.0.0


aptitude reinstall glx-alternative-mesa
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/mesa-diverted because link group glx is broken


You don't need this package.

Does installing the libegl1-mesa package help?


--
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

Bug#868638: heimdal-kdc: m-key installed by postinst apparently not used

[Ryan Tandy]

On Sun, 16 Jul 2017 19:10:01 -0700 Ryan Tandy  wrote:
I was about to suggest 'kadmin -c /etc/heimdal-kdc/kdc.conf -l stash', 
but it seems this also doesn't use DBNAME.mkey as a default! I think 
I'll raise that upstream. Not to mention the lack of even a warning when 
the mkey file doesn't exist.


Filed upstream as #302 and #303 respectively.

Bug#868469: imagemagick: Incomplete fix for CVE-2017-9144

[Salvatore Bonaccorso]

Control: retitle -1 imagemagick: CVE-2017-11352 (Incomplete fix for 
CVE-2017-9144)

Hi

On Sat, Jul 15, 2017 at 09:43:14PM +0200, Salvatore Bonaccorso wrote:
> Source: imagemagick
> Version: 8:6.9.7.4+dfsg-11
> Severity: serious
> Tags: upstream patch security
> Justification: incomplete fix for previous security fix
> Forwarded: https://github.com/ImageMagick/ImageMagick/issues/502
> Control: fixed -1 8:6.9.7.4+dfsg-12
> Control: found -1 8:6.9.7.4+dfsg-9
> Control: found -1 8:6.8.9.9-5+deb8u9
> 
> As noted in the upstream bug [1] the original fix for CVE-2017-9144
> was incomplete.
> 
>  [1] https://github.com/ImageMagick/ImageMagick/issues/502
> 
> As the incomplete fix has security implications itself (DoS at least?)
> this might warrant a new CVE id.

This is CVE-2017-11352.

Regards,
Salvatore

Bug#868642: ITP: golang-github-mgutz-ansi -- Small, fast library to create ANSI colored strings and codes

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-mgutz-ansi
  Version : 0.0~git20170206.0.9520e82-1
  Upstream Author : Mario Gutierrez
* URL : https://github.com/mgutz/ansi
* License : Expat
  Programming Lang: Go
  Description : Small, fast library to create ANSI colored strings
and codes. [go, golang]


This is needed for gopass



signature.asc
Description: OpenPGP digital signature

Bug#867268: [pkg-gnupg-maint] Bug#867268: dirmngr: Can't set nameserver port

[Sandro Knauß]

Hey,
 
> FWIW, --use-tor forces the use of Tor for DNS lookups.  This does not
> use the limited Tor features for DNS but by default uses the DNS server
> 8.8.8.8.  If you want to use another DNS server you can set it with
> --namesever.  Make sure to use a high traffic public server and not some
> private or low-traffic server.

 that means, that google (the owner of 8.8.8.8) gets a log of all my gnupg 
activity by default, that's not very privacy oriented. But I see the problem, 
of a nameverser that is a good default for everyone. And I can overwrite the 
default nameserver...

On the other side I'm still puzzeld, how dirmngr can use of Tor for DNS 
lookups, if the Tor features for DNS are too limited? As DNS is UDP so that it 
can't routed through tor.

Best Regards,

sandro


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

Bug#868539: The BTS does not know that -dbgsym packages exist

[Adrian Bunk]

Package: bugs.debian.org
Severity: normal

Example:
The affects in #868537

The BTS does not know that these are from src:abiword
https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=abiword-dbgsym
https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=abiword-plugin-grammar-dbgsym

Bug#868538: File conflict between bind9-dbgsym lwresd-dbgsym

[Adrian Bunk]

Source: bind9
Version: 1:9.10.3.dfsg.P4-12.3
Severity: serious
Control: affects -1 bind9-dbgsym lwresd-dbgsym

# apt-get install bind9-dbgsym lwresd-dbgsym
...
dpkg: error processing archive 
/var/cache/apt/archives/lwresd-dbgsym_1%3a9.10.3.dfsg.P4-12.3_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/69/bfa43a691a466a05ec512f8316c88cdd98cbe1.debug', 
which is also in package bind9-dbgsym 1:9.10.3.dfsg.P4-12.3



The problem is that /usr/sbin/lwresd and /usr/sbin/named
are the same binary but shipped in different packages.

Bug#868540: transition: libprelude

[Thomas Andrejak]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

New upstream version of libprelude (3.1.0) changes its soname from 2 to 23 for
low level library (libprelude2 -> libprelude23) and form 0 to 2 for high level
library (libpreludecpp0 to libpreludecpp8). Can you please create a new
transition slot for this ?

Affected packages (test rebuild OK):
* audit
* libpreludedb
* nufw
* prelude-lml
* suricata
* prelude-manager
* samhain

Ben file:

title = "libprelude";
is_affected = .depends ~ "libprelude2" | .depends ~ "libpreludecpp0" |
.depends ~ "libprelude23" | .depends ~ "libpreludecpp8";
is_good = .depends ~ "libprelude23" | .depends ~ "libpreludecpp8";
is_bad = .depends ~ "libprelude2" | .depends ~ "libpreludecpp0";

Thanks

Regards

Thomas

Bug#868514: usbguard: unused dependency on nlohmann-json-dev

[Muri Nicanor]

Control: tag -1 + pending

Hi James,

thank you for the bug report, i've removed the build-dependency and
uploaded a new version to mentors

cheers,
muri



signature.asc
Description: OpenPGP digital signature

Bug#868546: File conflict between graphviz-dbgsym and libgvc6-dbgsym

[Adrian Bunk]

Source: graphviz
Version: 2.38.0-17
Severity: serious
Control: affects -1 graphviz-dbgsym libgvc6-dbgsym

# apt-get install graphviz-dbgsym libgvc6-dbgsym
...
dpkg: error processing archive 
/var/cache/apt/archives/libgvc6-dbgsym_2.38.0-17_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/c0/5291dc418c6c2e79cb3b80cccd072565f89cb4.debug', 
which is also in package graphviz-dbgsym 2.38.0-17


The problem is that /usr/bin/dot and /usr/sbin/libgvc6-config-update
are the same binary shipped in different packages.

If this is intentional, one possible solution would be to make dot
a symlink to libgvc6-config-update with the dependency of the graphviz
on libgvc6 becoming a strict = dependency on the same binary version.

Bug#868552: File conflict between libyade-dbgsym and python-yade-dbgsym

[Adrian Bunk]

Package: libyade
Version: 2017.01a-8
Severity: serious
Control: affects -1 libyade-dbgsym python-yade-dbgsym

# apt-get install libyade-dbgsym python-yade-dbgsym 
...
dpkg: error processing archive 
/tmp/apt-dpkg-install-hGWQht/38-python-yade-dbgsym_2017.01a-8_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/07/41978eab587a82e4bb3ea306f55c9760608126.debug', 
which is also in package libyade-dbgsym:amd64 2017.01a-8


The following are the same binaries:

python-yade:
/usr/lib/python2.7/dist-packages/yade/WeightedAverage2d.so
/usr/lib/python2.7/dist-packages/yade/_customConverters.so
/usr/lib/python2.7/dist-packages/yade/_packObb.so
/usr/lib/python2.7/dist-packages/yade/_packPredicates.so
/usr/lib/python2.7/dist-packages/yade/_packSpheres.so
/usr/lib/python2.7/dist-packages/yade/_polyhedra_utils.so
/usr/lib/python2.7/dist-packages/yade/_utils.so
/usr/lib/python2.7/dist-packages/yade/boot.so
/usr/lib/python2.7/dist-packages/yade/wrapper.so

libyade:
/usr/lib/x86_64-linux-gnu/yade/py/yade/WeightedAverage2d.so
/usr/lib/x86_64-linux-gnu/yade/py/yade/_customConverters.so
/usr/lib/x86_64-linux-gnu/yade/py/yade/_packObb.so
/usr/lib/x86_64-linux-gnu/yade/py/yade/_packPredicates.so
/usr/lib/x86_64-linux-gnu/yade/py/yade/_packSpheres.so
/usr/lib/x86_64-linux-gnu/yade/py/yade/_polyhedra_utils.so
/usr/lib/x86_64-linux-gnu/yade/py/yade/_utils.so
/usr/lib/x86_64-linux-gnu/yade/py/yade/boot.so
/usr/lib/x86_64-linux-gnu/yade/py/yade/wrapper.so


My first impression is that libyade should not ship these files.

Bug#868554: pehash: segmentation fault

[Jakub Wilk]

Package: pev
Version: 0.80-2

pehash seems to crash on every file:

  $ echo 'int main(int argc, char **argv) {}' | i686-w64-mingw32-gcc -x c - -o 
test.exe
  $ pehash test.exe
  Segmentation fault

Backtrace:

#0  output_open_scope (scope_name=0x5655add8 "file", 
scope_type=OUTPUT_SCOPE_TYPE_OBJECT) at output.c:293
#1  0x56556f42 in main (argc=, argv=) at 
pehash.c:557


-- System Information:
Architecture: i386

Versions of packages pev depends on:
ii  libc62.24-12
ii  libssl1.0.2  1.0.2l-2

--
Jakub Wilk

Bug#868551: File conflict between redis-server-dbgsym and redis-tools-dbgsym

[Chris Lamb]

Hi Adrian,

> The problem is that /usr/bin/redis-server in redis-server and
> /usr/bin/redis-check-rdb in redis-tools are the same binary.
> 
> If this is intentional, one possible solution would be to make
> redis-server a symlink to redis-check-rdb.

Seems funny making the server, but that might indeed be the solution.
Just pasting some history here for now (note that this bug is filed
against 3:3.2.6-1):


redis (3:3.2.6-3) unstable; urgency=medium

  * Don't ship a "duplicate" redis-server binary in redis-tools as
/usr/bin/redis-check-rdb (it checks argv to change its behaviour) by
replacing it with a symlink. Found by .

redis (3:3.2.8-3) unstable; urgency=medium

  * Revert the creation of the redis-tools:/usr/bin/redis-check-rdb ->
redis-server:/usr/bin/redis-server symlink to avoid a dangling symlink if
only the redis-tools binary package is installed.

This was a regression since 3:3.2.6-3 where we attempted to avoid shipping
duplicate file; the redis-server binary changes behaviour based on the
contents of argv.

One alternative would be to ship a symlink in redis-server but that would
mean users wishing to check RDB databases would have to install the server
package, so reverting to shipping a duplicate file seems justified.
(Closes: #858519)

 -- Chris Lamb   Thu, 23 Mar 2017 12:00:22 +


Regards,

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

Bug#863278: RFS: usbguard/0.7.0-1

[gustavo panizzo]

On Mon, Jul 10, 2017 at 03:52:12PM +0200, Muri Nicanor wrote:

On 06/29/2017 05:35 PM, gustavo panizzo wrote:

Hello, apologies for the late response


no worries, as you can see i'm not very fast myself

oke, so...

On 06/18/2017 11:23 AM, gustavo panizzo wrote:

d/copyright

- please set the years to include 2016, 2017. there are some files owned
by RH which are copyright 2016 but in d/copyright it only says 2015

fixed


- src/Tests/Makefile.in, src/Tests/test-driver are copyright FSF

added in d/copyright


- would be cool to run files-without-copyright.sh

you mean in d/rules?





- src/Tests/USB/data/0001.bin src/Tests/UseCase/DummyDevices/root.tar.xz
 what's the source of that file? please regenerate them at build time

i'm not sure how to deal with this- the 0001.bin is a copy of a binary
USB Descriptor of one of upstreams devices.

which device? is it a physical device? is it a virtual device?


upstream says:

This is a copy of a binary USB descriptor of one of my devices. I

don't think I know anymore which one

but i've removed those files from the archive for now, patched the
relevant testscripts and created a bug report to create the testdata
from source [0]

cool, excelent
please add a target gen-orig-xz (or gz, or bz2) to d/rules to generate
the source from upstream source. 




- please clarify copyright for src/Tests/custom.supp

done so in [1] and upstream added a public domain header [2]. i've added
a paragraph about that file to d/copyright, although it does not yet
contain that public domain header in this release (the file containing
the public domain header is not part of a relaese)


d/control

- You have a d/gbp.conf but not Vcs-* headers on d/control
 would be cool if you publish your git packaging, and documented it on
 d/control

fixed


please push tags to you repo so i can compare between your tags and
upstream tags




 if you do that, please use pristine-tar to publish the tarballs

oke, i've imported the tarballs using pristine-tar commit
../usbguard_0.7.0+ds1.orig.tar.gz and used --git-pristine-tar with gbp


d/changelog

- please fix spelling in 'neede kernek'

fixed


* New upstream version 0.7.0
 This release contains a backwards incompatible
 change because it changes how the device hash is
 computed for Linux root hub devices

Please create a NEWS.Debian file, also please make a note to add a
notice in the release manual for buster (i know, looong time)
Users hate when things change without notice (i'm an usbguard user :)

i've added a d/NEWS file (dch --create --news) and added the information
there. did you mean i should make a note for myself or did you mean a
note in d/NEWS and if the latter, what is the syntax?

I meant the latter (so users can read it and fix their configs)

the package fails to build with sbuild


please do the d/rules targe and/or the tag in the repo so i have a way
to validate the source you are providing before upload. i don't see anything 
else
missing in the package :)



new version is on mentors ;)

cheers,
muri

[0] https://github.com/dkopecek/usbguard/issues/188
[1] https://github.com/dkopecek/usbguard/issues/175
[2]
https://github.com/dkopecek/usbguard/commit/faa84a648a575db7d8e382729ea7dcea079afe3a






--
IRC: gfa
GPG: 0X44BB1BA79F6C6333



signature.asc
Description: Digital Signature

Bug#868560: post-el: install error in emacs25

[Boruch Baum]

Subject: post-el: install error in emacs25
Package: post-el
Severity: normal

Dear Maintainer,

The apt installion process for the package into emacs25 produced the
following error:

  #+BEGIN_SRC conf
  Preparing to unpack .../post-el_1%3a2.6-1_all.deb ...
  Unpacking post-el (1:2.6-1) ...
  Setting up post-el (1:2.6-1) ...
  ERROR: post-el is broken - called emacs-package-install as a new-style
  add-on, but has no compat file.
  #+END_SRC

Manually installing the post.el file from the github project page does
seem to work (I'm using it while writing this email bug report).

attach


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#868561: knot-resolver 1.2.0-1 occasionally fails to reply correctly to DS queries

[George Kargiotakis]

Package: knot-resolver
Version: 1.2.0-1
Severity: important

Dear Maintainer,

Under circumstances, when a zone is not signed, knot-resolver responds
to DS queries for a zone with SOA record of the zone in question
instead of the SOA record of the parent zone.
Sending wrong DS replies breaks DNSSEC validation.

Reproducing is quite easy, with a clean installation and cache.

Issuing an A query and then a DS query reproduces the bug.

An example:

# kdig a void.gr @localhost 
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 65070

;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; void.gr. IN  A

;; ANSWER SECTION:
void.gr.3600IN  A   83.212.168.30

;; Received 41 B
;; Time 2017-07-15 03:21:50 EEST
;; From ::1@53(UDP) in 444.8 ms

# kdig ds void.gr @localhost
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1335

;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0

;; QUESTION SECTION:
;; void.gr. IN  DS

;; AUTHORITY SECTION:
void.gr.3600IN  SOA empty.void.gr. 
dnsmaster.void.gr. 2017071401 10800 3600 604800 10800

;; Received 77 B
;; Time 2017-07-15 03:21:57 EEST
;; From ::1@53(UDP) in 64.4 ms

Another example:
# kdig a google.com @localhost  
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 14794

;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; google.com.  IN  A

;; ANSWER SECTION:
google.com. 300 IN  A   216.58.205.46

;; Received 44 B
;; Time 2017-07-15 03:29:13 EEST
;; From ::1@53(UDP) in 444.5 ms

# kdig ds google.com @localhost 
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 37953

;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0

;; QUESTION SECTION:
;; google.com.  IN  DS

;; AUTHORITY SECTION:
google.com. 60  IN  SOA ns2.google.com. 
dns-admin.google.com. 162019261 900 900 1800 60

;; Received 78 B
;; Time 2017-07-15 03:29:17 EEST
;; From ::1@53(UDP) in 75.6 ms


on knot-resolver from testing (1.3.0-2), the answers are correct:

# dig a void.gr @localhost  
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 56872

;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; void.gr. IN  A

;; ANSWER SECTION:
void.gr.3600IN  A   83.212.168.30

;; Received 41 B
;; Time 2017-07-15 03:19:21 EEST
;; From ::1@53(UDP) in 441.5 ms

# dig ds void.gr @localhost 
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32532

;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0

;; QUESTION SECTION:
;; void.gr. IN  DS

;; AUTHORITY SECTION:
gr. 1800IN  SOA grdns.ics.forth.gr. 
hmaster-info.ics.forth.gr. 1707142191 3600 180 5184000 1800

;; Received 90 B
;; Time 2017-07-15 03:19:23 EEST
;; From ::1@53(UDP) in 52.8 ms

# kdig a google.com @localhost  
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 61740

;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; google.com.  IN  A

;; ANSWER SECTION:
google.com. 300 IN  A   216.58.205.46

;; Received 44 B
;; Time 2017-07-15 03:31:16 EEST
;; From ::1@53(UDP) in 805.4 ms

# kdig ds google.com @localhost 
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 27072

;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0

;; QUESTION SECTION:
;; google.com.  IN  DS

;; AUTHORITY SECTION:
com.900 IN  SOA 
a.gtld-servers.net. nstld.verisign-grs.com. 1500078651 1800 900 604800 86400

;; Received 104 B
;; Time 2017-07-15 03:31:21 EEST
;; From ::1@53(UDP) in 620.7 ms

The order of queries matter

# kdig ds google.com @localhost 
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 55082

;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0

;; QUESTION SECTION:
;; google.com.  IN  DS

;; AUTHORITY SECTION:
com.900 IN  SOA a.gtld-servers.net. 
nstld.verisign-grs.com. 1500078726 1800 900 604800 86400

;; Received 104 B
;; Time 2017-07-15 03:32:23 EEST
;; From ::1@53(UDP) in 722.7 ms

# kdig a google.com @localhost  
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 16742

;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 

Bug#868554: pehash: segmentation fault

[Adrian Bunk]

Control: severity -1 serious

On Sun, Jul 16, 2017 at 04:55:24PM +0200, Jakub Wilk wrote:
> Package: pev
> Version: 0.80-2
> 
> pehash seems to crash on every file:
> 
>   $ echo 'int main(int argc, char **argv) {}' | i686-w64-mingw32-gcc -x c - 
> -o test.exe
>   $ pehash test.exe
>   Segmentation fault
> 
> Backtrace:
> 
> #0  output_open_scope (scope_name=0x5655add8 "file", 
> scope_type=OUTPUT_SCOPE_TYPE_OBJECT) at output.c:293
> #1  0x56556f42 in main (argc=, argv=) at 
> pehash.c:557

pehash is not the only program that segfaults:

$ pescan --version
pescan from pev 0.50  toolkit
Copyright (C) 2012 Fernando Mercês.
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.
$ pescan test.exe 
entrypoint:  normal
DOS stub:normal
TLS directory:   found - 2 function(s)
Sections:15 - suspicious
$ 

$ pescan --version
pescan from pev 0.80  toolkit
License GPLv2+: GNU GPL version 2 or later 
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ pescan test.exe 
file entropy:5.924796 (normal)
fpu anti-disassembly:no
imagebase:   normal
entrypoint:  normal
DOS stub:normal
TLS directory:   found - 1 function(s)
timestamp:   normal
section count:   15 (high)
Segmentation fault
$

Raising severity to keep the broken version out of buster.

> Jakub Wilk

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#864028: stretch-pu: package flatpak, maybe want debdiff against security?

[Simon McVittie]

On Sat, 15 Jul 2017 at 22:13:14 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: stretch-pu: package flatpak, maybe want debdiff 
> against security?"):
> > Yes, this update was proposed while stretch was still in freeze,
> > and I didn't want to annoy the release team with more pings if they
> > were deliberately leaving it dormant until after r1. Diff against
> > stretch-security attached (diffing patched tree against patched tree,
> > and excluding Autotools noise, translations, HTML docs, and the patches
> > that were dropped but not their effects).
> 
> Thanks.  This is IMO much better.  I looked at the diff and almost
> everything in it is covered by your changelog entries.  However:
> 
>  * document-portal/xdp-dbus.c was generated by a version of
>gdbus-codegen which seems to be only in Debian experimental. !

This is regenerated at build time. I sent patches upstream to exclude
it from the distributed orig.tar.gz, which were accepted, so this won't
be an issue in 0.9.x; but that patch isn't going to be included in the
0.8.x stable branch (unless someone from the stable release team asks
for it) because it isn't a fix for a user-observable bug.

I can exclude it from future diffs if desired.

>  * gtk-doc.make has some noise (which seems to be just whitespace
>changes but which is a bit hard to review as-is)

gtk-doc.make is copied in from gtk-doc-tools by gtkdocize during the
upstream autogen.sh run. It isn't currently replaced by dh_autoreconf.
I could re-run gtkdocize with Debian's gtk-doc-tools at dh_autoreconf
time if the release team want, but my assumption had been that this
non-minimal change would be rejected.

I can confirm that

git diff --ignore-space-change debian/stretch..debian/stretch-proposed -- 
gtk-doc.make

eliminates all the changes except for deletion of one blank line,
and the re-wrapping in the last patch band.

> This is a bit odd.  Are these generated files even though they are in
> the source package ?

Yes. Blame Autotools.

It's possible that Flatpak upstream will eventually follow GNOME into
using Meson instead of Autotools, at which point their source releases
will probably become a submodule-aware version of `git archive`; but I
don't think they are in any hurry to do so.

S

Bug#868379: Processed (with 4 errors): python-dateutil: makes calibre fail to start

[Manolo Díaz]

On Sunday, 16 Jul 2017 at 09:05 UTC
Guido Günther wrote:

> Hi,
> control: affects -1 calibre

[...]

> Starts here without problems. Does
> 
>  python -c "from six.moves import _thread"
> 
> work for you? If it does not work your python-six is broken. Maybe you
> have a local version of six lying around?
> Cheers,
>  -- Guido

Hi,

python -c "from six.moves import _thread" does apparently nothing and
exits with 0. Is this expected?

The version of python-six on my system is 1.10.0-4 (current testing)
and if it was broken I think calibre wouldn't start with only
downgrading python-dateutil.

-- 
Manolo Díaz

Bug#868507: libreoffice-writer: Crash after the last upgrade

[Nicolas Patrois]

Package: libreoffice-writer
Version: 1:5.3.4-4
Severity: important

Dear Maintainer,

LO crashes after the last upgrade:
X-Error: BadMatch (invalid parameter attributes)
Major opcode: 154
Minor opcode: 5
Resource ID:  0x5c00013
Serial No:227 (227)
These errors are reported asynchronously,
set environment variable SAL_SYNCHRONIZE to 1 to help debugging
Application Error

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/3 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.1-4
ii  libc6  2.24-12
ii  libe-book-0.1-10.1.2-4
ii  libetonyek-0.1-1   0.1.6-5
ii  libgcc11:7.1.0-9
ii  libicu57   57.1-6
ii  libmwaw-0.3-3  0.3.11-3
ii  libodfgen-0.1-10.1.6-2
ii  libreoffice-base-core  1:5.3.4-4
ii  libreoffice-core   1:5.3.4-4
ii  librevenge-0.0-0   0.0.4-6
ii  libstaroffice-0.0-00.0.3-3
ii  libstdc++6 7.1.0-9
ii  libwpd-0.10-10 0.10.1-5
ii  libwpg-0.3-3   0.3.1-3
ii  libwps-0.4-4   0.4.6-2
ii  libxml22.9.4+dfsg1-3
ii  uno-libs3  5.3.4-4
ii  ure5.3.4-4
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:5.3.4-4

Versions of packages libreoffice-writer suggests:
ii  default-jre [java6-runtime]2:1.8-59
ii  fonts-crosextra-caladea20130214-1
ii  fonts-crosextra-carlito20130920-1
ii  libreoffice-base   1:5.3.4-4
pn  libreoffice-gcj
ii  libreoffice-java-common1:5.3.4-4
ii  openjdk-8-jre [java6-runtime]  8u131-b11-2
ii  sun-java6-jre [java6-runtime]  6.26-3

Versions of packages libreoffice-core depends on:
ii  fontconfig2.12.3-0.2
ii  fonts-opensymbol  2:102.10+LibO5.3.4-4
ii  libboost-date-time1.62.0  1.62.0+dfsg-4+b1
ii  libc6 2.24-12
ii  libcairo2 1.14.10-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.4-2
ii  libcurl3-gnutls   7.52.1-5
ii  libdbus-1-3   1.10.20-1
ii  libdbus-glib-1-2  0.108-2
ii  libdconf1 0.26.0-2+b1
ii  libeot0   0.01-4+b1
ii  libepoxy0 1.3.1-3
ii  libexpat1 2.2.2-1
ii  libexttextcat-2.0-0   3.4.4-2+b1
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libgcc1   1:7.1.0-9
ii  libgl1-mesa-glx [libgl1]  17.1.4-1
ii  libglib2.0-0  2.52.3-1
ii  libgltf-0.1-1 0.1.0-2
ii  libgraphite2-31.3.10-2
ii  libharfbuzz-icu0  1.4.2-1
ii  libharfbuzz0b 1.4.2-1
ii  libhunspell-1.6-0 1.6.1-2
ii  libhyphen02.8.8-5
ii  libice6   2:1.0.9-2
ii  libicu57  57.1-6
ii  libjpeg62-turbo   1:1.5.1-2
ii  liblcms2-22.8-4
ii  libldap-2.4-2 2.4.44+dfsg-7
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-2
ii  libnspr4  2:4.15-1
ii  libnss3   2:3.31-1
ii  libodfgen-0.1-1   0.1.6-2
ii  liborcus-0.12-0   0.12.1-3
ii  libpcre3  2:8.39-3
ii  libpng16-16   1.6.30-2
ii  librdf0   1.0.17-1.1
ii  libreoffice-common1:5.3.4-4
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.2-1+b3
ii  libstdc++67.1.0-9
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxml2   2.9.4+dfsg1-3
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.29-2.1
ii  uno-libs3 5.3.4-4
ii  ure   5.3.4-4
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.24+nmu5

-- no debconf information

Bug#868506: zfs-dkms: installation fails

[Daniel Rieken]

Package: zfs-dkms
Version: 0.6.5.9-5
Severity: normal


Dear Maintainer,

when I install zfs-dkms on a fresh Debian Stretch install, I get the
following error messages:
   Building initial module for 4.9.0-3-amd64
   configure: error:
   *** Please make sure the kmod spl devel  package for your
   *** distribution is installed then try again.  If that fails you
   *** can specify the location of the spl objects with the
   *** '--with-spl-obj=PATH' option.
   Error! Bad return status for module build on kernel: 4.9.0-3-amd64 (x86_64)
   Consult /var/lib/dkms/zfs/0.6.5.9/build/make.log for more information.

The mentioned logfile /var/lib/dkms/zfs/0.6.5.9/build/make.log is not available.

Way to reproduce: apt-get install zfs-dkms


I found out there is no error message when I first install
linux-headers-$(uname -r) and then zfs-dkms.

I think this is a bug.

Regards,
Daniel


-- Here are the console-messages when installing zfs-dkms:
root@debian9test:~# cat /etc/apt/sources.list
deb http://ftp.de.debian.org/debian/ stretch main non-free contrib
deb-src http://ftp.de.debian.org/debian/ stretch main non-free contrib
deb http://security.debian.org/debian-security stretch/updates main
contrib non-free
deb-src http://security.debian.org/debian-security stretch/updates
main contrib non-free
# stretch-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ stretch-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ stretch-updates main contrib non-free
root@debian9test:~#
root@debian9test:~# apt-get install zfs-dkms
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  binutils cpp cpp-6 dkms fakeroot gcc gcc-6 libasan3 libatomic1
libc-dev-bin libc6-dev libcc1-0 libcilkrts5 libfakeroot libgcc-6-dev
libgomp1 libisl15 libitm1 liblsan0 libmpc3 libmpfr4 libmpx2
  libnvpair1linux libquadmath0 libtsan0 libubsan0 libuutil1linux
libzfs2linux libzpool2linux linux-compiler-gcc-6-x86
linux-headers-4.9.0-3-amd64 linux-headers-4.9.0-3-common
linux-headers-amd64
  linux-kbuild-4.9 linux-libc-dev make manpages-dev patch spl spl-dkms
sudo zfs-zed zfsutils-linux
Suggested packages:
  binutils-doc cpp-doc gcc-6-locales python3-apport menu gcc-multilib
autoconf automake libtool flex bison gdb gcc-doc gcc-6-multilib
gcc-6-doc libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg
  libasan3-dbg liblsan0-dbg libtsan0-dbg libubsan0-dbg libcilkrts5-dbg
libmpx2-dbg libquadmath0-dbg glibc-doc make-doc ed diffutils-doc
nfs-kernel-server samba-common-bin zfs-initramfs | zfs-dracut
The following NEW packages will be installed:
  binutils cpp cpp-6 dkms fakeroot gcc gcc-6 libasan3 libatomic1
libc-dev-bin libc6-dev libcc1-0 libcilkrts5 libfakeroot libgcc-6-dev
libgomp1 libisl15 libitm1 liblsan0 libmpc3 libmpfr4 libmpx2
  libnvpair1linux libquadmath0 libtsan0 libubsan0 libuutil1linux
libzfs2linux libzpool2linux linux-compiler-gcc-6-x86
linux-headers-4.9.0-3-amd64 linux-headers-4.9.0-3-common
linux-headers-amd64
  linux-kbuild-4.9 linux-libc-dev make manpages-dev patch spl spl-dkms
sudo zfs-dkms zfs-zed zfsutils-linux
0 upgraded, 44 newly installed, 0 to remove and 0 not upgraded.
Need to get 41.1 MB of archives.
After this operation, 189 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://security.debian.org/debian-security stretch/updates/main
amd64 libc-dev-bin amd64 2.24-11+deb9u1 [259 kB]
Get:2 http://ftp.de.debian.org/debian stretch/main amd64 libisl15
amd64 0.18-1 [564 kB]
Get:3 http://security.debian.org/debian-security stretch/updates/main
amd64 linux-libc-dev amd64 4.9.30-2+deb9u2 [1,252 kB]
Get:4 http://ftp.de.debian.org/debian stretch/main amd64 libmpfr4
amd64 3.1.5-1 [556 kB]
Get:5 http://ftp.de.debian.org/debian stretch/main amd64 libmpc3 amd64
1.0.3-1+b2 [39.9 kB]
Get:6 http://ftp.de.debian.org/debian stretch/main amd64 cpp-6 amd64
6.3.0-18 [6,579 kB]
Get:7 http://security.debian.org/debian-security stretch/updates/main
amd64 libc6-dev amd64 2.24-11+deb9u1 [2,365 kB]
Get:8 http://ftp.de.debian.org/debian stretch/main amd64 cpp amd64
4:6.3.0-4 [18.7 kB]
Get:9 http://ftp.de.debian.org/debian stretch/main amd64 libcc1-0
amd64 6.3.0-18 [30.6 kB]
Get:10 http://ftp.de.debian.org/debian stretch/main amd64 binutils
amd64 2.28-5 [3,770 kB]
Get:11 http://ftp.de.debian.org/debian stretch/main amd64 libgomp1
amd64 6.3.0-18 [73.2 kB]
Get:12 http://ftp.de.debian.org/debian stretch/main amd64 libitm1
amd64 6.3.0-18 [27.4 kB]
Get:13 http://ftp.de.debian.org/debian stretch/main amd64 libatomic1
amd64 6.3.0-18 [8,920 B]
Get:14 http://ftp.de.debian.org/debian stretch/main amd64 libasan3
amd64 6.3.0-18 [311 kB]
Get:15 http://ftp.de.debian.org/debian stretch/main amd64 liblsan0
amd64 6.3.0-18 [115 kB]
Get:16 http://ftp.de.debian.org/debian stretch/main amd64 libtsan0
amd64 6.3.0-18 [257 kB]
Get:17 http://ftp.de.debian.org/debian stretch/main amd64 libubsan0

Bug#868508: fedmsg: CVE-2017-1000001

[Salvatore Bonaccorso]

Source: fedmsg
Version: 0.9.3-1
Severity: important
Tags: upstream security

Hi,

the following vulnerability was published for fedmsg.

CVE-2017-101[0]:
| FedMsg 0.18.1 and older is vulnerable to a message validation flaw
| resulting in message validation not being enabled if configured to be
| on.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-101
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-101
[1] https://github.com/fedora-infra/fedmsg/commit/5c21cf88a

Regards,
Salvatore

Bug#868509: editra: Missing 'a' in description

[Hans Joachim Desserud]

Package: editra
Version: 0.7.20+dfsg.1-3
Severity: minor

Dear Maintainer,

The description of editra currently states:
"Currently it supports syntax highlighting and variety of other (..)"
Presumably this should be "and a variety of"

This has previously been reported in Ubuntu, but seems to be
present in the recent version in Sid.
(https://bugs.launchpad.net/ubuntu/+source/editra/+bug/910398)


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

Kernel: Linux 4.11.0-1-amd64 (SMP w/1 CPU core)
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)

Versions of packages editra depends on:
ii  python   2.7.13-2
ii  python-wxgtk3.0  3.0.2.0+dfsg-4

editra recommends no packages.

editra suggests no packages.

-- no debconf information

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#864028: stretch-pu: package flatpak, maybe want debdiff against security?

[Ian Jackson]

Simon McVittie writes ("Re: stretch-pu: package flatpak, maybe want debdiff 
against security?"):
> On Sat, 15 Jul 2017 at 22:13:14 +0100, Ian Jackson wrote:
> >  * document-portal/xdp-dbus.c was generated by a version of
> >gdbus-codegen which seems to be only in Debian experimental. !
> 
> This is regenerated at build time. I sent patches upstream to exclude
> it from the distributed orig.tar.gz, which were accepted, so this won't
> be an issue in 0.9.x; but that patch isn't going to be included in the
> 0.8.x stable branch (unless someone from the stable release team asks
> for it) because it isn't a fix for a user-observable bug.

Ah.  Indeed.  OK, I'm happy about that.

> I can exclude it from future diffs if desired.

I don't think that would be proper.

> >  * gtk-doc.make has some noise (which seems to be just whitespace
> >changes but which is a bit hard to review as-is)
> 
> gtk-doc.make is copied in from gtk-doc-tools by gtkdocize during the
> upstream autogen.sh run. It isn't currently replaced by dh_autoreconf.
> I could re-run gtkdocize with Debian's gtk-doc-tools at dh_autoreconf
> time if the release team want, but my assumption had been that this
> non-minimal change would be rejected.

It seems to me that this means that the source code for your proposed
updated package is not entirely within Debian.  That is, your source
code includes the source in gtk-doc-tools which produces gtk-doc.make.
If I wanted to rebuild your package with an altered gtk-doc.make, I
would need the source to the corresponding gtk-doc-tools.  But the
relevant gtk-doc-tools is not in Debian, because it's the one upstream
used to prepare their flatpak "source" package.

So this is, technically, a violation of the licence and of policy.

However, these files are functionally equivalent, because:

> I can confirm that
> 
> git diff --ignore-space-change debian/stretch..debian/stretch-proposed -- 
> gtk-doc.make
> 
> eliminates all the changes except for deletion of one blank line,
> and the re-wrapping in the last patch band.

Personally, I would manually rerun gtkdocize on the source package, on
stretch, and include the resulting change as a Debian patch.  Then the
resulting patched source tree in stretch-pu would be from Debian
stretch's gtk-doc-tools.

But maybe the release team have a different opinion.

> > This is a bit odd.  Are these generated files even though they are in
> > the source package ?
> 
> Yes. Blame Autotools.

I think that's unfair on autotools...

Regards,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#868522: openbmap-logger: The name org.freesmartphone.ogpsd was not provided by any .service files

[seb]

Package: openbmap-logger
Version: 0.4.0-7
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I cannot start openBmap as it fails with the following error:

$ openBmapGTK 
Try loading /usr/share/openBmap/Main.glade glade file.
Traceback (most recent call last):
  File "/usr/bin/openBmapGTK", line 356, in 
hwg = openBmapGTK()
  File "/usr/bin/openBmapGTK", line 130, in __init__
self._obmlogger = openbmap.logger.ObmLogger()
  File "/usr/lib/python2.7/dist-packages/openbmap/logger.py", line 826, in 
__init__
self._gps = Gps()
  File "/usr/lib/python2.7/dist-packages/openbmap/logger.py", line 763, in 
__init__
self._dbusobj = dbus.SystemBus().get_object('org.freesmartphone.ogpsd', 
'/org/freedesktop/Gypsy')
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object
follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in __init__
self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in 
activate_name_owner
self.start_service_by_name(bus_name)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in 
start_service_by_name
'su', (bus_name, flags)))
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The 
name org.freesmartphone.ogpsd was not provided by any .service files

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

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

Versions of packages openbmap-logger depends on:
ii  fso-frameworkd  0.10.1-3
ii  python  2.7.13-2
ii  python-glade2   2.24.0-5.1
ii  python-gtk2 2.24.0-5.1

openbmap-logger recommends no packages.

openbmap-logger suggests no packages.

-- no debconf information

Bug#868491: eth0 missing from /run/network/ifstate

[Vincent Blut]

On Sat, Jul 15, 2017 at 05:02:57PM -0700, John Eikenberry wrote:

Package: chrony
Version: 3.0-4
Severity: normal

Dear Maintainer,


Hello John,

After upgrading to stretch I noticed my network was not registering 
correctly.

By this I mean that even though the network (eth0) came up and worked, it
didn't have an entry in /run/network/ifstate (the ifstate file was empty).

This is using ifupdown + ifplugd in a setup that worked fine on jessie and
works fine now after removing chrony.


I’m sad to hear that upgrading to Stretch caused you some troubles!


It took me a while to nail down the problem, but I finally noticed this kept
showing up in my log.

   run-parts: /etc/network/if-up.d/chrony exited with return code 1

When I put an 'exit 0' at the top of that script my networking came up fine
and was added to /run/network/ifstate. So by exiting with an error that script
was preventing ifup from completing the ifstate registration.


I will try to reproduce this issue by setting up a similar network 
environment.


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#868515: dgit does not work in a "git worktree"

[Ian Jackson]

Package: dgit
Version: 3.11

$ dgit -wgf quilt-fixup
Format `3.0 (quilt)', need to check/update patch stack
mkdir .git: File exists at /usr/bin/dgit line 1709.
$

Fixing this is nontrivial.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#868150: imapproxy: fails to start

[Richard Laager]

With PIDFile=/run/imapproxy.pid, I get the following errors:

PID file /run/imapproxy.pid not readable (yet?) after start: No such
file or directory

Supervising process 824 which is not our child. We'll most likely not
notice when it exits.

>From my first testing, it worked fine without PIDFile. Unfortunately,
upon further testing, it seems to fail most of the time. Given that
those errors seem harmless, I think setting PIDFile is the lesser of the
two evils right now, so I'm sticking with that. I've sent the update to
my sponsor. (I'm not a DD.)

I should probably explore the idea of adding a command-line option to
imapproxy that sets foreground_mode. Then, I can use that in the systemd
unit, making this Type=simple instead of Type=forking.

-- 
Richard

Bug#868516: ITP: node-run-queue -- promise based dynamic priority queue runner

[icyfire]

Package: wnpp
Severity: wishlist
Owner: Rajeev R Menon 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-run-queue
  Version : 1.0.3
  Upstream Author : Rebecca Turner  (http://re-becca.org/)
* URL : https://npmjs.com/package/run-queue
* License : ISC
  Programming Lang: JavaScript
  Description : promise based dynamic priority queue runner

 A promise based, dynamic priority queue runner, with concurrency limiting.
 .
 The concurrency means that processes don't finish in order, because some take 
 longer than others. Each priority level must finish entirely before the 
 next priority level is run. Priorities essentially represent distinct job 
 queues. All jobs in a queue must complete before the next highest priority job 
 queue is executed. Lowest is executed first.  
 .
 Node.js is an event-based server-side JavaScript engine.

It is a dependency of npm.

Pirate Praveen has agreed to sponsor this package. I am interested to
join the Debian Javascript Maintainers Team.

Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts

[Andrey Rahmatullin]

On Sat, Jul 15, 2017 at 09:57:32PM -0700, Paul Hardy wrote:
> "Font packages must invoke update-fonts-dir on each directory into
> which they install fonts.  This invocation must occur in both the
> postinst (for all arguments) and postrm (for all arguments except
> upgrade) scripts."
> 
> Strictly speaking this is correct, but it could be taken to mean that
> a font packager must have postinst and postrm scripts in their
> package's debian directory.  That is no longer necessary.  I suggest
> appending the following to the above paragraph:
> 
> "Note: if your build scripts invoke dh_installxfonts, this is handled
> automatically and it is not necessary to create postinst or postrm
> files in your debian directory for this purpose.  See
> dh_installxfonts(1)."
No, the policy doesn't talk about dh_* and other helpers (except in
footnotes).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#868507: libreoffice-writer: Crash after the last upgrade

[Rene Engelhard]

tag 868507 + moreinfo
thanks

Hi,

On Sun, Jul 16, 2017 at 10:33:22AM +0200, Nicolas Patrois wrote:
> Package: libreoffice-writer
> Version: 1:5.3.4-4
> Severity: important
> 
> Dear Maintainer,
> 
> LO crashes after the last upgrade:

You you mean after the 5.2.7->5.3.4-4 update?

> X-Error: BadMatch (invalid parameter attributes)
>   Major opcode: 154
>   Minor opcode: 5
>   Resource ID:  0x5c00013
>   Serial No:227 (227)
> These errors are reported asynchronously,
> set environment variable SAL_SYNCHRONIZE to 1 to help debugging
> Application Error

Interesting, I would have assumed it crashing with Java issues (Stack Clash)
directly. Do you have the stack clash security fixes enabled? 

When does it crash?

Do you have a backtrace of this crash?

> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)

Sigh. Any reason you use this obsolee arch instead of amd64 (if you use -pae 
ways)?

Regards,

Rene

Bug#868379: Processed (with 4 errors): python-dateutil: makes calibre fail to start

[Guido Günther]

Hi,
control: affects -1 calibre

Hi,
On Sun, Jul 16, 2017 at 08:42:05AM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > reassign 868379 python-dateutil 2.6.0-1
> Bug #868379 [calibre] calibre: Fails to start with "ImportError: cannot 
> import name _thread"
> Bug reassigned from package 'calibre' to 'python-dateutil'.
> No longer marked as found in versions calibre/2.75.1+dfsg-1 and 
> calibre/3.1.1+dfsg-1.
> Ignoring request to alter fixed versions of bug #868379 to the same values 
> previously set
> Bug #868379 [python-dateutil] calibre: Fails to start with "ImportError: 
> cannot import name _thread"
> Marked as found in versions python-dateutil/2.6.0-1.
> > retitle 868379 python-dateutil: makes calibre fail to start
> Bug #868379 [python-dateutil] calibre: Fails to start with "ImportError: 
> cannot import name _thread"
> Changed Bug title to 'python-dateutil: makes calibre fail to start' from 
> 'calibre: Fails to start with "ImportError: cannot import name _thread"'.
> > Dear Maintainer,
> Unknown command or malformed arguments to command.
> > python-dateutil 2.6.0-1 makes calibre fail to start. Downgrading it to
> Unknown command or malformed arguments to command.
> > version 2.5.3-2 fixes this problem.
> Unknown command or malformed arguments to command.
> > Best Regards,
> Unknown command or malformed arguments to command.
> > --
> Stopping processing here.

Starts here without problems. Does

 python -c "from six.moves import _thread"

work for you? If it does not work your python-six is broken. Maybe you
have a local version of six lying around?
Cheers,
 -- Guido

Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts

[Paul Hardy]

Andrey,

On Sun, Jul 16, 2017 at 12:21 AM, Andrey Rahmatullin  wrote:
> On Sat, Jul 15, 2017 at 09:57:32PM -0700, Paul Hardy wrote:
>> "Font packages must invoke update-fonts-dir on each directory into
>> which they install fonts.  This invocation must occur in both the
>> postinst (for all arguments) and postrm (for all arguments except
>> upgrade) scripts."
>>
>> Strictly speaking this is correct, but it could be taken to mean that
>> a font packager must have postinst and postrm scripts in their
>> package's debian directory.  That is no longer necessary.  I suggest
>> appending the following to the above paragraph:
>>
>> "Note: if your build scripts invoke dh_installxfonts, this is handled
>> automatically and it is not necessary to create postinst or postrm
>> files in your debian directory for this purpose.  See
>> dh_installxfonts(1)."
> No, the policy doesn't talk about dh_* and other helpers (except in
> footnotes).

Then would you consider it acceptable to make some mention in a
footnote to the effect that with the latest "dh" build tools, it isn't
necessary to have postinst and postrm scripts in the debian directory
for this purpose?  Because otherwise, someone who did not already know
about this could misunderstand the implications of this requirement
and create redundant postinst and postrm scripts.

Thanks,


Paul Hardy

Bug#868499: osmose-emulator: No sound

[Diogo Martins Silva]

Package: osmose-emulator
Version: 1.0-4
Severity: important

Dear Maintainer,

Emulator correctly plays games, except with no sound.

Relevant Log entry:

cannot open audio device : plughw:0,0No such file or
directory

I don't use plugged in sound card, just a regular laptop hardware sound card.



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

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

Versions of packages osmose-emulator depends on:
ii  libasound21.1.3-5
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5opengl5 5.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  zlib1g1:1.2.8.dfsg-5

osmose-emulator recommends no packages.

osmose-emulator suggests no packages.

-- no debconf information

Bug#776658: lintian: Memory consumption of harness and html_reports

[Niels Thykier]

On Fri, 30 Jan 2015 17:38:40 -0800 Russ Allbery  wrote:
> Niels Thykier  writes:
> 
> > The html_reports process itself consumes up to 2GB while processing
> > templates.  It is possible that there is nothing we can do about that
> > as there *is* a lot of data in play.  But even then, we can free it as
> > soon as possible (so we do not keep it while running gnuplot at the
> > end of the run).
> 
> I think the code currently takes a very naive approach and loads the
> entire state of the world into memory, and Perl's memory allocation is
> known to aggressively trade space for speed.
> 
> If instead it stored the various things it cared about in a local SQLite
> database, it would be a bit slower, but it would consume much less
> memory.  I bet the speed difference wouldn't be too bad.  And this would
> have the possibly useful side effect of creating a SQLite database full of
> interesting statistics that one could run rich queries against.
> 
> -- 
> Russ Allbery (r...@debian.org)   
> 
> 

Hi Russ (and others),

I have been considering the expand the scope of the reporting framework
to include testing and to de-tangle suite-related data in the reports
(i.e. get a separate report for each suite).

If I am to add that, I think a database might be the only realistic way
forward for that with all the bells and whistles we currently have.
However, I do not really have a lot of experience with Perl database
frameworks, so I could use some help here.

I suspect it would make sense to obsolete the harness state cache as
well (the YAML file), so most tools only need to deal with the database.

FTR, I would probably ask for a postgres database on lindsay.d.o.  That
said, SQLite support would be great for local testing.

Thanks,
~Niels

Bug#868503: exim4-config: update-exim4.conf brokenness

[astian]

Package: exim4-config
Version: 4.89-3
Severity: normal

Dear maintainer,

Brokenness in the debconf part of the package has resulted in all local
email (sent from system daemons to users in the same host) to become
undeliverable and therefore frozen.

Background:

  Exim4 was automatically installed on the affected system, probably due
  to package recommendations.  It had been working "without apparent
  problems" (local email was being successfully delivered) since the
  operating system installation (about a month ago).

  As best as I recall, I was never presented with any debconf prompt of
  any kind for this package, not during the system installation, nor at
  any later time (including package upgrades, of which I think 2 took
  place).

  This week I noticed that no new email was being received.  After
  investigating I discovered that since at least 2 weeks ago all email
  was being frozen.

The reason for this was that Exim was using "(none" (sic) as value for
"qualify_domain" (from macro ETC_MAILNAME), while variable
"local_domains" had been set to "@:localhost:(none)" (from macro
MAIN_LOCAL_DOMAINS).  Therefore incoming messages using unqualified
local usernames as source and/or destination addresses were not
recognised as local:

  2017-07-10 06:26:20 1dUrQy-00032m-1m <= root@(none U=root P=local S=702
  2017-07-10 06:26:20 1dUrQy-00032m-1m ** root@(none R=nonlocal: Mailing to 
remote domains not supported
  2017-07-10 06:26:20 1dUrQy-00032o-5d Error while reading message with no 
usable sender address (R=1dUrQy-00032m-1m): at least one malformed recipient 
address: root@(none - domain missing or malformed
  2017-07-10 06:26:20 1dUrQy-00032m-1m Process failed (1) when writing error 
message to root@(none (frozen)

Notice that "(none)" is Linux's default hostname.  IIUC, systemd will
call sethostname early during boot to change it to something else (taken
either from /etc/hostname or a build-time fallback), so I don't quite
understand how the debconf scripts in exim4-config got that value from
the "hostname" command (which seems to be the only method used to learn
the hostname).  I believe my /etc/hostname was always properly set up
(and even if it wasn't, the fallback in systemd should have replaced
"(none)"; see function hostname_setup in systemd), so this has me
puzzled.

Possible leads
--

IIRC, the hostname of the system at installation time was simply
"localhost".  Some time ago I made two changes that may or may not have
caused the problem to surface:

  1. I changed the hostname using hostnamectl to a single word, say,
 "foohost" (both "transient" and "static").  I also added "foohost" to
 /etc/hosts as an alias.
  2. I changed the name of the administrator user ("oldusername", which
 appears below in some configuration dug up by reportbug).

Brokenness
--

The patch for bug #215319 (reported 2003, closed 2006) was supposed to
result in just the first word of /etc/mailname being used for macro
ETC_MAILNAME, but what it really did is to erase "non-word" characters
after the first span of (seemingly arbitrarily chosen) "word"
characters: the regex is not anchored; also, it probably wasn't meant to
allow backslashes, but it did.  This explains why "(none)" was turned
into "(none".

In 2007, the badly named filter "check_ascii_pipe" was introduced: it
didn't just "check", it also transformed; it didn't just filter
non-ASCII, it filtered anything outside an apparently arbitrary set of
characters; again it allowed probably unintended characters; missing
shell quoting, it could result in an incorrect error message; that error
message is as wrongly worded as the function name.  During 2007, the
maintainer kept increasing the set of allowed characters in the
mentioned filter, not because they were expected in /etc/mailname but
because the same filter was used in a bunch of places with different
requirements; this made the filter "loose".  Eventually he needed to add
square brackets: continuing to repeat the backslash mistake the regex
was broken, resulting in only filtering characters followed by "]".

(Looking at the code and Git log, it appears that the maintainer
struggled to write simple shell scripts; or RTFM.)

Conclusion
--

About update-exim4.conf: I was going to send a patch (it's trivial) but
after reading the script, I believe the best course of action here is
not a patch but a flamethrower.

About the weird configuration state observed in the affected system: I
don't understand how it happened; manually running "dpkg-reconfigure
exim4-config" was enough to clean things up, "apt purge exim4" further
cleaned things.

About the frozen messages: In case it could be useful to someone, I'll
mention that Exim seems perfectly capable of delivering messages to
"@(none)" addresses, as weird a domain as that seems.  So after manually
editing the configuration and thawing the frozen messages they will be
correctly delivered.

Thanks to the maintainer for 

Bug#868437: [pkg-gnupg-maint] Bug#868437: gnupg: does not work after installation

[Daniel Kahn Gillmor]

On Sat 2017-07-15 15:54:54 +0300, Teemu Likonen wrote:
> Axel Stammler [2017-07-15 14:23:48+02] wrote:
>
>> after installation, any call to GPG, e.g.
>>
>>gpg --search Stammler
>>
>> invariably produces the following messages:
>>
>> gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or 
>> directory
>> gpg: connecting dirmngr at '/run/user/1001/gnupg/S.dirmngr' failed: No such 
>> file or directory
>> gpg: error searching keyserver: No dirmngr
>> gpg: keyserver search failed: No dirmngr
>
> The error message says that /usr/bin/dirmngr is missing. Install package
> named dirmngr and your original command will work.
>
> apt install dirmngr
>
> The gnupg package recommends dirmngr but I don't know why it's not part
> of the default installation.

It *is* part of the default installation, since Recommends are installed
by default.  However, /usr/bin/gpg is usable for encryption, decryption,
signing, and verification without communicating with the network.
dirmngr is the component of the GnuPG suite which communicates with the
network, but it also pulls in more dependencies that some users might
not want, so it's possible to install gpg without it.

Anyway, i'm closing this bug report because it's currently behaving as
expected.

fwiw, I'm planning a reorganization of the GnuPG binary packages that
will eventually make dirmngr a full Dependency of the "gnupg" binary
package, but will still allow an admin who wants the most minimal
installation (without secret key support, without network access) to
install a narrowly-scoped "gpg" package.

--dkg


signature.asc
Description: PGP signature

Bug#868208: CVE-2017-11103: MitM attack, impersonation of the Kerberos client, know as Orpheus Lyre

[Brian May]

Salvatore Bonaccorso  writes:

> I just have prepared both and uploading to security-master for jessie-
> and stretch-security (the patch applied straightforward).

Thanks!
-- 
Brian May 

Bug#868409: verbiste: Please drop the (build-)dependency against gnome-vfs

[Tomasz Buchert]

On 15/07/17 13:40, bi...@debian.org wrote:
> Source: verbiste
> Version: 0.1.44-1
> Severity: wishlist
> Tags: sid buster
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gnome-vfs-removal oldlibs
>
> Dear maintainer,
>
> Your package is {build-}depending against gnome-vfs which is
> deprecated for quite some times now and has been replaced by gvfs.
>
> We are thinking about removing gnome-vfs for Buster if possible.
>
> Could you please verify that this dependency is mandatory and if it's
> not the case, could you please remove it?
>
> Don't hesitate to contact me if you have any questions.
>
> Kind regards,
>
> Laurent Bigonville

Hi Laurent,
verbiste depends on libgnomeui-2.0 which then depends on gnome-vfs. The package 
does not build
anymore if I remove the libgnomeui dependency, but if in the process of your 
transition you are
going to fix deps of libgnomeui, then this package will profit too.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#868208: CVE-2017-11103: MitM attack, impersonation of the Kerberos client, know as Orpheus Lyre

[Salvatore Bonaccorso]

Hi

On Sat, Jul 15, 2017 at 07:14:29PM +0200, Guido Günther wrote:
> Hi,
> On Sat, Jul 15, 2017 at 09:08:37PM +1000, Brian May wrote:
> > Guido Günther  writes:
> > 
> > > I've uploaded heimdal with the attached debdiff to delayed/2. Let me
> > > know if you're o.k. with it and I'll reuplod without delay.
> > 
> > Thanks a lot for this.
> > 
> > I just uploaded version 7.4.0 so your upload is not required.
> 
> Great. Are you going to handle stable and oldstable as well?

I just have prepared both and uploading to security-master for jessie-
and stretch-security (the patch applied straightforward).

Regards,
Salvatore

Bug#868504: xserver-xorg: intermittent/occasional flicker/artifiact after upgrade to Debian9 in i965

[Veek M]

To be absolutely precise it's around 00:04-00:05

Bug#868454: u-boot-menu: wrong path for fdtdir in extlinux.conf

[Diego Roversi]

On Sat, 15 Jul 2017 21:32:50 +0300
Riku Voipio  wrote:

Hello Riku,

> > But it should be /dtb-4.9.0-3-armmp-lpae
> 
> > This error make the menu unusable. No matter what entry you choose, file to 
> > load
> > dtb file and u-boot fallback to boot.scr for loading the images.
> 
> I think you have a partition setup where /boot is a separate
> partition. This is unfortunately
> not supported at the moment. You need to set up fdtdir setting in
> /etc/default/u-boot file to fit
> your setup.

A separate /boot is the standard layout used in debian-installer. So I think is 
important to support it.

Also, I see there is no /etc/default/u-boot, so can be useful to add it to the 
package as a empty template.

Thanks,
  Diego.
-- 
Diego Roversi 

Bug#868505: FTBFS: downloads hardcoded and missing MUMPS source

[Drew Parsons]

Source: sdpa
Version: 7.3.9+dfsg-1
Severity: serious
Justification: Policy 4.13 7.7

spda has 3 FTBFS problems.  Firstly, it hardcodes in the Makefile a reference 
to an
versioned external package (mumps 4.10), which is not available.
Secondly, no Build-Depends on mumps 4.10 is given.

Thirdly, it should not be pulling in mumps source anyway.  The mumps
library is available (now upgraded to 5.1), why is sdpa not using it?


-- 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.11.0-1-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)

Bug#868409: verbiste: Please drop the (build-)dependency against gnome-vfs

[Laurent Bigonville]

Le 16/07/17 à 09:31, Tomasz Buchert a écrit :

On 15/07/17 13:40, bi...@debian.org wrote:

Source: verbiste
Version: 0.1.44-1
Severity: wishlist
Tags: sid buster
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-vfs-removal oldlibs

Dear maintainer,

Your package is {build-}depending against gnome-vfs which is
deprecated for quite some times now and has been replaced by gvfs.

We are thinking about removing gnome-vfs for Buster if possible.

Could you please verify that this dependency is mandatory and if it's
not the case, could you please remove it?

Don't hesitate to contact me if you have any questions.

Kind regards,

Laurent Bigonville

Hi Laurent,
verbiste depends on libgnomeui-2.0 which then depends on gnome-vfs. The package 
does not build
anymore if I remove the libgnomeui dependency, but if in the process of your 
transition you are
going to fix deps of libgnomeui, then this package will profit too.

libgnome* (that has been deprecated for years) is also on the list of 
the packages that the GNOME team would be happy to remove.


Do you think you could see with upstream if he could remove these 
dependencies? libgnome seems to be used in only tree files, I literally 
see a maximum of 10 calls to functions of libgnome (configuration part 
that can be replaced by GSettings and setting the icon).


Regards,

Laurent Bigonville

Bug#868511: linux-image-4.11.0-1-amd64: Please enable CEC drivers

[Hans Verkuil]

Package: src:linux
Version: 4.11.6-1
Severity: normal

Dear Maintainer,

Starting with kernel 4.10 the HDMI CEC framework was mainlined in the linux
kernel. It would be very nice if this and the driver for the popular PulseEight
USB CEC adapter (https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter)
can be enabled in the 4.11 kernel config:

select CONFIG_MEDIA_CEC_SUPPORT=y and CONFIG_USB_PULSE8_CEC=m.
CONFIG_VIDEO_VIVID_CEC=y is also very useful and highly recommended as this
enables CEC emulation in this virtual video driver. This allows application
developers to test their CEC implementation without having CEC hardware.

In kernel 4.12 the RainShadow driver (similar to the popular PulseEight
USB CEC adapter) should also be enabled: CONFIG_USB_RAINSHADOW_CEC=m

Regards,

Hans Verkuil
CEC Framework & pulse8-cec driver maintainer

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

Kernel: Linux 4.11.0-1-amd64 (SMP w/56 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=C (charmap=ANSI_X3.4-1968) (ignored: 
LC_ALL set to C)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.11.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod24-1
ii  linux-base  4.5

Versions of packages linux-image-4.11.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.11.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02-2
pn  linux-doc-4.11  

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

-- debconf-show failed

Bug#868293: misguesses veth name in stretch

[Marc Haber]

On Sat, Jul 15, 2017 at 12:30:22PM -0700, Mike Miller wrote:
> On Fri, Jul 14, 2017 at 11:29:04 +0200, Marc Haber wrote:
> > in stretch the vpnc-script-sshd doesn't work any more. After a while of
> > debugging, I found out that the script expects the REMOTEDEV to be named
> > $TUNDEV-vpnssh1, which is no longer the case in stretch's iproute.
> > 
> > The following patch changes the name of REMOTEDEV to veth0, which fixes
> > the issue.
> 
> Hm, unable to reproduce here. I installed a fresh stretch system to test
> on. As expected, the script creates a veth pair named tun0-vpnssh0 and
> tun0-vpnssh1.
> 
> Are you using vpnc-script-sshd with openconnect or vpnc?

With vpnc.

> Is it possible your local kernel is incompatible with iproute2 4.9.0?
> Can you test with the stock stretch kernel, or install iproute2 4.12?

I am a quite active user of the lastest vanilla kernels and iproute, and
have never seen an incompatibility. What kernel option would be a
possible culprit?

Wouldn't it be a better idea to adapt the script to handle both cases?

Greetings
Marc

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

Bug#868513: tiff: CVE-2017-11335: tiff2pdf: heap based buffer write overflow

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.3-12.3
Severity: important
Tags: upstream security patch fixed-upstream
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2715

Hi,

the following vulnerability was published for tiff.

CVE-2017-11335[0]:
| There is a heap based buffer overflow in tools/tiff2pdf.c of LibTIFF
| 4.0.8 via a PlanarConfig=Contig image, which causes a more than one
| hundred bytes out-of-bounds write (related to the ZIPDecode function in
| tif_zip.c). A crafted input may lead to a remote denial of service
| attack or an arbitrary code execution attack.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-11335
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11335
[1] http://bugzilla.maptools.org/show_bug.cgi?id=2715
[2] 
https://github.com/vadz/libtiff/commit/69bfeec247899776b1b396651adb47436e5f1556

Regards,
Salvatore

Bug#868514: usbguard: unused dependency on nlohmann-json-dev

[James Cowgill]

Source: usbguard
Version: 0.6.2+ds1-2
Severity: minor

Hi,

usbguard seems to have an unused dependency on nlohmann-json-dev.
Removing it still allows the build to pass without losing any features.

James



signature.asc
Description: OpenPGP digital signature