Bug#841401: Cannot update Signal plugin

[Alex Dănilă]

Hi,

Did you follow any special steps? I installed Chromium from experimental 
and still have the problem, Signal doesn't update:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851927#54

Thank you,
Alex

Bug#853119: texlive-luatex: basic lualatex document does not compile anymore without additionnal dependencies

[Julian Wollrath]

Hi Norbert,

yes, the crash is unrelated, but it was the only log I had; sorry, I
should have used a better example. Lets make the same point I tried to
make in a different way:
\documentclass{article}

\usepackage[osf,sc,slantedGreek]{mathpazo}
\linespread{1.08}

\begin{document}
Test
\end{document}

% cat test.log 
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)  (format=lualatex
2017.2.6)  6 FEB 2017 08:45 restricted system commands enabled.
**test.tex
(./test.tex
LaTeX2e <2017/01/01>
Lua module: luaotfload-main 2016/06/16 2.70003 OpenType layout system.
Lua module: lualibs 2016-04-06 2.4 ConTeXt Lua standard libraries.
Lua module: lualibs-extended 2016-04-06 2.4 ConTeXt Lua libraries --
extended co llection.(using write
cache: /home/wolle/.texlive2016/texmf-var/luatex-cache/gen eric)(using
read cache: /var/lib/texmf/luatex-cache/generic /home/wolle/.texlive
2016/texmf-var/luatex-cache/generic) luaotfload | conf : Root cache
directory is /home/wolle/.texlive2016/texmf-var/l
uatex-cache/generic/names. luaotfload | init : Loading fontloader
“fontloader-2016-06-16.lua” from kpse -resolved path
“/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader
-2016-06-16.lua”. Lua-only attribute luaotfload@state = 1
Lua-only attribute luaotfload@noligature = 2
Lua-only attribute luaotfload@syllabe = 3
luaotfload | init : Context OpenType loader version “3.023”
Inserting `luaotfload.node_processor' at position 1 in
`pre_linebreak_filter'. Inserting `luaotfload.node_processor' at
position 1 in `hpack_filter'. Inserting `luaotfload.define_font' at
position 1 in `define_font'. Lua-only attribute
luaotfload_color_attribute = 4 luaotfload | conf : Root cache directory
is /home/wolle/.texlive2016/texmf-var/l uatex-cache/generic/names.
Inserting `luaotfload.aux.set_sscale_dimens' at position 1 in
`luaotfload.patch_ font'.
Inserting `luaotfload.aux.patch_cambria_domh' at position 2 in
`luaotfload.patch _font'.
Inserting `luaotfload.aux.fixup_fontdata' at position 1 in
`luaotfload.patch_fon t_unsafe'.
Inserting `luaotfload.aux.set_capheight' at position 3 in
`luaotfload.patch_font '.
Inserting `luaotfload.rewrite_fontname' at position 4 in
`luaotfload.patch_font' .
luaotfload | main : initialization completed in 0.105 seconds
Babel <3.9r> and hyphenation patterns for 1 language(s) loaded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
File: size10.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
luaotfload | db : Font names database loaded
from /home/wolle/.texlive2016/texmf
-var/luatex-cache/generic/names/luaotfload-names.luc(compiling
luc: /var/lib/tex
mf/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)(load
luc: /home/wolle/.
texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc))
\c@part=\count79 \c@section=\count80 \c@subsection=\count81
\c@subsubsection=\count82 \c@paragraph=\count83
\c@subparagraph=\count84
\c@figure=\count85
\c@table=\count86
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
) (/usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
Package: mathpazo 2005/04/12 PSNFSS-v9.2a Palatino w/ Pazo Math
(D.Puga, WaS) \symupright=\mathgroup4
) (./test.aux)
\openout1 = test.aux

LaTeX Font Info:Checking defaults for OML/cmm/m/it on input line 10.
LaTeX Font Info:... okay on input line 10.
LaTeX Font Info:Checking defaults for T1/cmr/m/n on input line 10.
LaTeX Font Info:... okay on input line 10.
LaTeX Font Info:Checking defaults for OT1/cmr/m/n on input line 10.
LaTeX Font Info:... okay on input line 10.
LaTeX Font Info:Checking defaults for OMS/cmsy/m/n on input line 10.
LaTeX Font Info:... okay on input line 10.
LaTeX Font Info:Checking defaults for TU/lmr/m/n on input line 10.
LaTeX Font Info:... okay on input line 10.
LaTeX Font Info:Checking defaults for OMX/cmex/m/n on input line 10.
LaTeX Font Info:... okay on input line 10.
LaTeX Font Info:Checking defaults for U/cmr/m/n on input line 10.
LaTeX Font Info:... okay on input line 10.
LaTeX Font Info:Try loading font information for TU+pplj on input
line 10. LaTeX Font Info:No file TUpplj.fd. on input line 10.

LaTeX Font Warning: Font shape `TU/pplj/m/n' undefined
(Font)  using `TU/lmr/m/n' instead on input line 10.

\big@size=\dimen103
[1

{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./test.aux)

LaTeX Font Warning: Some font shapes were not available, defaults
substituted.

)

Here is how much of LuaTeX's memory you used:
 305 strings out of 494611
 10,89155 words of node,token memory allocated
 369 words of node memory still in use:
   2 hlist, 1 vlist, 1 rule, 6 glue, 5 attribute, 41 glue_spec, 5
attribute_list , 1 write nodes
   avail lists: 2:17,3:2,4:1,5:11,6:6,7:22,8:1,9:6
 4408 multiletter control sequences out of 65536+60
 15 fonts using 723615 

Bug#839261: hexchat-otr: establishing OTR connection fails

[Petter Reinholdtsen]

Hi, and thank you for your report.

[Joonas Kylmälä]
> After I installed hexchat-otr and someone else tried to establish an OTR
> connection with me I got the following error and establishing the
> connection failed:
> 
>  OTR: Error saving instance tags: No such file or directory (gcrypt)
> 
> 
> I expected the connection to work. Well, I figured a workaround for
> this: installing libgcrypt20-dev package. After that the connection
> could be made.

Interesting.  Not quite sure what went wrong there, but perhaps some
directory is missing?  An alternative could be that there is a missing
dependency, but I suspect I would have discovered that during testing.
Anyone got any idea what went wrong?

-- 
Happy hacking
Petter Reinholdtsen

Bug#854338: unblock: petsc/3.7.5+dfsg1-4

[Drew Parsons]

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

Please unblock package petsc

A late bug report came in (#852514) noting that libpetsc3.7-dev was
leaving stray alternatives behind. Release 3.7.5+dfsg1-4 fixes the
problem. The bug was marked important, but I would actually treat it
as serious for violating policy.  This release should go into stretch,
or upgrades from stretch later on will be messier than they should be.

This release also tidies up recommended packages.

petsc 3.7.5+dfsg1-4 is built on all tier 1 architectures.

Bugs fixed:   #852514  important ("serious")

debdiff attached

unblock petsc/3.7.5+dfsg1-4

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru petsc-3.7.5+dfsg1/debian/changelog petsc-3.7.5+dfsg1/debian/changelog
--- petsc-3.7.5+dfsg1/debian/changelog  2017-01-22 12:13:55.0 +0800
+++ petsc-3.7.5+dfsg1/debian/changelog  2017-02-06 05:03:51.0 +0800
@@ -1,3 +1,15 @@
+petsc (3.7.5+dfsg1-4) unstable; urgency=medium
+
+  * Don't duplicate -dev dependencies. -lhdf5 and -lsuperlu are
+invoked in PETSc.pc, so we Depend on their dev packages, we don't
+simply Recommend them.
+  * Move petsc3.7 and petsc3.7-real alternatives handling from
+libpetsc3.7-dev to libpetsc3.7.5-dev. Similarly petsc3.7-complex. 
+Otherwise alternatives for older patch versions are left unowned. 
+Closes: #852514.
+
+ -- Drew Parsons   Mon, 06 Feb 2017 05:03:51 +0800
+
 petsc (3.7.5+dfsg1-3) unstable; urgency=medium
 
   * Update libgfortran-5-dev dependency to gfortran to ensure 
diff -Nru petsc-3.7.5+dfsg1/debian/control petsc-3.7.5+dfsg1/debian/control
--- petsc-3.7.5+dfsg1/debian/control2017-01-22 12:13:55.0 +0800
+++ petsc-3.7.5+dfsg1/debian/control2017-02-06 05:03:51.0 +0800
@@ -45,12 +45,11 @@
 Depends: libpetsc3.7.5 (= ${binary:Version}), ${MPI:Depends}, 
libsuitesparse-dev, libspooles-dev,
  libhypre-dev (>= 2.0.0.dfsg-7), libptscotch-dev, libblacs-mpi-dev, 
libscalapack-mpi-dev,
  libmumps-dev, libfftw3-dev, libfftw3-mpi-dev, libssl-dev, gfortran,
- libhdf5-mpi-dev,
+ libhdf5-mpi-dev (>= 1.8.8), libsuperlu-dev (>= 5.2),
  ${misc:Depends}, ${python:Depends}
 Conflicts: libpetsc3.6.3-dev (<< 3.6.3.dfsg2-2), libpetsc-complex-3.6.3-dev 
(<< 3.6.3.dfsg2-2),
  libpetsc3.6.2-dev (<= 3.6.2.dfsg1-3), libpetsc-complex-3.6.2-dev (<= 
3.6.2.dfsg1-3)
-Recommends: libhdf5-mpi-dev (>= 1.8.8), libsuperlu-dev (>= 5.2),
- tcsh | csh | c-shell, ksh | mksh | pdksh | zsh
+Recommends: tcsh | csh | c-shell, ksh | mksh | pdksh | zsh
 Suggests: petsc-dev (= ${binary:Version}), libpetsc3.7.5-dbg (= 
${binary:Version}), petsc3.7.5-doc (= ${binary:Version}), libluminate-dev
 Description: Static libraries, shared links, header files for PETSc
  PETSc is the "Portable Extensible Toolkit for Scientific Computation", a suite
@@ -168,12 +167,11 @@
 Depends: libpetsc-complex-3.7.5 (= ${binary:Version}), ${MPI:Depends}, 
libsuitesparse-dev, libspooles-dev,
  libhypre-dev (>= 2.0.0.dfsg-7), libptscotch-dev, libblacs-mpi-dev, 
libscalapack-mpi-dev,
  libmumps-dev, libfftw3-dev, libfftw3-mpi-dev, libssl-dev, gfortran,
- libhdf5-mpi-dev,
+ libhdf5-mpi-dev (>= 1.8.8), libsuperlu-dev (>= 5.2),
  ${misc:Depends}, ${python:Depends}
 Conflicts: libpetsc-complex-3.6.3-dev (<< 3.6.3.dfsg2-2), libpetsc3.6.3-dev 
(<< 3.6.3.dfsg2-2),
  libpetsc3.6.2-dev (<= 3.6.2.dfsg1-3), libpetsc-complex-3.6.2-dev (<= 
3.6.2.dfsg1-3)
-Recommends: libhdf5-mpi-dev (>= 1.8.8), libsuperlu-dev (>= 5.2),
- tcsh | csh | c-shell, ksh | mksh | pdksh | zsh
+Recommends: tcsh | csh | c-shell, ksh | mksh | pdksh | zsh
 Suggests: petsc-dev (= ${binary:Version}), libpetsc-complex-3.7.5-dbg (= 
${binary:Version}), petsc3.7.5-doc (= ${binary:Version}), libluminate-dev
 Description: Static libraries, shared links, header files for PETSc
  PETSc is the "Portable Extensible Toolkit for Scientific Computation", a suite
diff -Nru petsc-3.7.5+dfsg1/debian/libpetsc3.7.5-dev.postinst 
petsc-3.7.5+dfsg1/debian/libpetsc3.7.5-dev.postinst
--- petsc-3.7.5+dfsg1/debian/libpetsc3.7.5-dev.postinst 2017-01-22 
12:13:55.0 +0800
+++ petsc-3.7.5+dfsg1/debian/libpetsc3.7.5-dev.postinst 2017-02-06 
05:03:51.0 +0800
@@ -2,6 +2,8 @@
 
 DEB_HOST_MULTIARCH=__DEB_HOST_MULTIARCH__
 
+SONAME=__PETSC_SONAME_VERSION__
+
 PETSC_VERSION=__PETSC_VERSION__
 PETSC_ARCH=${DEB_HOST_MULTIARCH}
 PETSC_REAL_ARCH=${PETSC_ARCH}-real
@@ -35,6 +37,13 @@
 # alternative base version of petsc real
 update-alternatives --install /usr/lib/${DEB_HOST_MULTIARCH}/libpetsc_real.so 
libpetsc_real.so 
/usr/lib/${DEB_HOST_MULTIARCH}/libpetsc_real.so.${PETSC_VERSION} 

Bug#854186: network-manager: DHCP connection stopped working (however, it works perfectly by using the console)

[Sami Erjomaa]

I have this problem too with network-manager 1.6.0. For some reason
the dhcp offer is rejected by dhclient when using network-manager.

Feb  5 16:25:12 erebor systemd[1]: Started Network Manager Wait Online.
Feb  5 16:25:12 erebor dhclient[13084]: DHCPREQUEST of 192.168.1.35 on
eth0 to 255.255.255.255 port 67
Feb  5 16:25:12 erebor dhclient[13084]: DHCPACK of 192.168.1.35 from 192.168.1.1
Feb  5 16:25:12 erebor dhclient[13084]: no expiry time on offered lease.
Feb  5 16:25:12 erebor dhclient[13084]: Server added to list of
rejected servers.
Feb  5 16:25:13 erebor dhclient[13084]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 8
Feb  5 16:25:13 erebor dhclient[13084]: DHCPOFFER from 192.168.1.1
rejected by rule 192.168.1.1 mask 255.255.255.255.

If I run dhclient on terminal the dhcp offer is accepted. The only
difference I can see when running dhclient on terminal and when it's
initiated by network-manager is the use of
/usr/lib/NetworkManager/nm-dhcp-helper.

I got the network-manager to work by changing the dhcp method to
internal by adding line "dhcp=internal" to
/etc/NetworkManager/NetworkManager.conf.

IP addresses in my network are assigned by ZyWall 5.

Bug#854337: unblock: git-buildpackage/0.8.12.1

[Guido Günther]

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

Please unblock package git-buildpackage

This is basically an "I'm 1 day late" request:

  $ grep-excuses git-buildpackage
  git-buildpackage (0.8.10 to 0.8.12.1)
  Maintainer: Guido Günther
  Too young, only 9 of 10 days old
  Piuparts tested OK - 
https://piuparts.debian.org/sid/source/g/git-buildpackage.html
  Not considered

It would be great if gbp could be unblocked (and just handled as if it
would have been uploaded 1 day earlier). This would make it possible for
me to fix #854333 and other things coming up during the freeze as
targeted fixes (otherwise I'd have to somehow revert to 0.8.10 in sid).

unblock git-buildpackage/0.8.12.1

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

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

Bug#854336: CVE-2016-9577 CVE-2016-9578

[Moritz Muehlenhoff]

Source: spice
Severity: grave
Tags: security

Please see
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-9577
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-9578

Cheers,
Moritz

Bug#854335: python-websockets: Non-determistically FTBFS due to unreliable timing in tests

[Chris Lamb]

Source: python-websockets
Version: 3.2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

python-websockets's testsuite appears to use method timing/benchmarking in such 
a way that it will non-deterministically FTBFS:

  […]
  
  ==
  FAIL: test_eof_received_timeout (websockets.test_protocol.ClientTests)
  --
  Traceback (most recent call last):
File 
"/build/1st/python-websockets-3.2/.pybuild/pythonX.Y_3.5/build/websockets/test_protocol.py",
 line 792, in test_eof_received_timeout
  self.loop.run_until_complete(self.protocol.close(reason='close'))
File "/usr/lib/python3.5/contextlib.py", line 66, in __exit__
  next(self.gen)
File 
"/build/1st/python-websockets-3.2/.pybuild/pythonX.Y_3.5/build/websockets/test_protocol.py",
 line 249, in assertCompletesWithin
  dt, max_time, "Too slow: {} >= {}".format(dt, max_time))
  AssertionError: 0.022619478404521942 not less than 0.019 : Too slow: 
0.022619478404521942 >= 0.019
  
  ==
  FAIL: test_remote_close_race_with_failing_connection 
(websockets.test_protocol.ClientTests)
  --
  Traceback (most recent call last):
File 
"/build/1st/python-websockets-3.2/.pybuild/pythonX.Y_3.5/build/websockets/test_protocol.py",
 line 716, in test_remote_close_race_with_failing_connection
  self.assertConnectionClosed(1011, '')
File 
"/build/1st/python-websockets-3.2/.pybuild/pythonX.Y_3.5/build/websockets/test_protocol.py",
 line 237, in assertConnectionClosed
  self.assertEqual(self.protocol.close_code, code)
  AssertionError: 1000 != 1011
  
  ==
  FAIL: test_close_handshake_timeout (websockets.test_protocol.ServerTests)
  --
  Traceback (most recent call last):
File 
"/build/1st/python-websockets-3.2/.pybuild/pythonX.Y_3.5/build/websockets/test_protocol.py",
 line 761, in test_close_handshake_timeout
  self.loop.run_until_complete(self.protocol.close(reason='close'))
File "/usr/lib/python3.5/contextlib.py", line 66, in __exit__
  next(self.gen)
File 
"/build/1st/python-websockets-3.2/.pybuild/pythonX.Y_3.5/build/websockets/test_protocol.py",
 line 249, in assertCompletesWithin
  dt, max_time, "Too slow: {} >= {}".format(dt, max_time))
  AssertionError: 0.0209119264036417 not less than 0.019 : Too slow: 
0.0209119264036417 >= 0.019
  
  --
  Ran 235 tests in 2.067s
  
  FAILED (failures=3, skipped=29)
  E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: cd 
«BUILDDIR»/.pybuild/pythonX.Y_3.5/build; python3.5 -m unittest discover -v 
  dh_auto_test: pybuild --test -i python{version} -p 3.5 returned exit code 13
  debian/rules:5: recipe for target 'build' failed
  make: *** [build] Error 25
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  […]

The full build log is attached.


Regards,

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


python-websockets.3.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#853912: python-testfixtures: please make the build reproducible

[Chris Lamb]

tags 853912 + fixed-upstream
thanks

https://github.com/Simplistix/testfixtures/pull/56#issuecomment-277600278

:)


Regards,

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

Bug#583938: [git-buildpackage/master] On a patch-queue branch tag the corresponding debian branch instead.

[Guido Günther]

tag 583938 pending
thanks

Date:   Mon Feb 6 08:21:50 2017 +0100
Author: Guido Günther 
Commit ID: d31fb0b47bb0fc6c25f159caa4c3e2068d9ccbd5
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=d31fb0b47bb0fc6c25f159caa4c3e2068d9ccbd5
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=d31fb0b47bb0fc6c25f159caa4c3e2068d9ccbd5

On a patch-queue branch tag the corresponding debian branch instead.

Eases building and tagging of source format 3.0 (quilt) packages since
one can build from a (throw away) patch-queue branch that has the quilt
patches applied (i.e. patch-queue/master) while the tag is created at
the branch point where the patch-queue branch diverged from master.
(usually the tip).

Closes: #583938

  

Bug#851277: [pkg-gnupg-maint] Bug#851277: gnugpg: gpg --key-gen only asks for the passphrase once during the creation, no retyping required

[Daniel Kahn Gillmor]

Control: reassign 851277 pinentry-gnome3
Control: severity 851277 important
Control: tags 851277 - moreinfo unreproducible

On Sun 2017-02-05 04:18:20 -0500, Daniel Kahn Gillmor wrote:
> I've tested this with "gpg --gen-key" in a clean GNUPGHOME, using each
> of pinentry-gnome3, pinentry-qt, and pinentry-gtk-2, and i have not been
> able to replicate the problem.  They all show a dual passphrase entry
> prompt upon key creation.

I take it back.  With pinentry-gnome3 1.0.0-1, i can replicate the
misbehavior.

It looks like there's a patch in pinentry upstream
b0e0bdeac5d40ca645afc9017778b39a26303523 which resolves this problem.

This should get fixed shortly.

If you were seing this with a different pinentry besides
pinentry-gnome3, please either open a new issue here in the BTS, or
clone this one and explain what the details are.

thanks,

   --dkg


signature.asc
Description: PGP signature

Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued

[Aurelien Jarno]

On 2017-02-06 00:50, Cyril Brulebois wrote:
> Hi,
> 
> Aurelien Jarno  (2017-02-06):
> > Well this kind of patch is not mergeable upstream, so we will have to
> > keep it forever.
> 
> Or just for stretch given the following points?

No, I don't think the freeze is an excuse for fixing bugs the wrong way.

> > What would be wrong in using a supported value for the debian-installer
> > locale? It should only be a dozen of lines to change.
> 
> A couple of things:
>  1. I don't know anything about locales.

Understandable.

>  2. Nobody moved a finger on this RC bug for months, so I'm not sure we
> have anyone else able/willing to fix this.

Or maybe people able/willing to fix this were not aware of the bug?

>  3. The freeze is here and I'm not too thrilled about changing code/data
> I don't have a clue about.

These strings only changes LC_IDENTIFICATION, so there is no risk to
replace them by "i18n:2012". We have done that for a few additional
locales we have in the glibc, including for the C.UTF-8 locale [1].

If you don't want to fix that yourself, I can just do the upload.

Aurelien

[1] 
https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=12fabca5b6fccdf47b3f147a40d00f9149ef345a

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#854328: dehydrated: wrong path to example config

[Mattia Rizzolo]

Control: tag -1 pending

On Mon, Feb 06, 2017 at 02:24:39AM +, Adam Borowski wrote:
> /etc/dehydrated/config says:
> # This is the default configuration for the Debian package. #
> # To see a more comprehensive example, see  #
> # /usr/share/doc/dehydrated/examples/config.example #
> 
> but "dpkg -L dehydrated":
> /usr/share/doc/dehydrated/examples/config
> 
> Please s/\.example$//

https://anonscm.debian.org/git/letsencrypt/dehydrated.git/commit/?id=b541d613fee6457d0b18c2a1c20c93aa7cd71794

Thanks for reporting.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

Daniel Kahn Gillmor  wrote:
> To be concrete, i believe the two proposed solutions for users are:
[...]
> Do not use CCID
> ---
>
> echo disable-ccid:0:1 | gpgconf --change-options scdaemon
>

Correct.

The things for PCSC is a bit complicated.  Let me describe.

> Do not use PCSC
> ---
>
> Either system-wide:
>
> apt purge pcscd

This works.  Actually, this is not mandatory.  It is OK to have pcscd
package installed **if not used**.

The order of usage by scdaemon is:

 (1) First, try internal ccid-driver.
 (2) Then, try PC/SC service.

I enbugged in 2.1.18 and the transition (1)->(2) doesen't work well now.

When pcscd is not running, ccid-driver just works well even if pcscd
package is installed.

Internal ccid-driver fails when pcscd service is running and it tries to
open USB devices which are now under the control of pcscd.

And when pcscd is running on a system,

> or per-user:
>
> echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon

... this does not work.  A user need to kill pcscd service.

>> However, the gnupg package maintainers might want to think about how
>> to best document this issue.
>
> aiui, CCID is the preferred method for scdaemon to access smartcards.

For GNU/Linux system, yes.  However, there are users (especially in
Eurpoe), who want to use other smcartcards like citizen ID card
simultaneously/interchangeably on a system.  scdaemon is not a system-
wide service for all smartcards, but it's specific to OpenPGP card and
it's per user service for gpg-agent.

> Would it make sense instead to just change the defaults for pcsc-driver
> to be the empty string?

The problem is pcscd holds the access to device, which prevents
ccid-driver's access.

Current order makes some sense.  Specific one first, then catch-all one
second.  However, in future implementation of scdaemon, perhaps,
changing the order of access (pcscd first, ccid-driver second) would
also make sense for some use cases.
-- 

Bug#854334: apt: Please add a common prefix to the "X is maintained in the Y version control system" messages

[Chris Lamb]

Source: apt
Version: 1.4~beta4
Severity: wishlis
Tags: patch

Hi,

I think it would look nicer and be more readable if the "X is maintained
in the Y" messages had a common line prefix.

For example:

  NOTICE: 'apt' packaging is maintained in the 'Git' version control system at:
  https://anonscm.debian.org/git/apt/apt.git
  Please use:
  git clone https://anonscm.debian.org/git/apt/apt.git
  to retrieve the latest (possibly unreleased) updates to the package.

.. would look like:

  I: 'apt' packaging is maintained in the 'Git' version control system at:
  I: https://anonscm.debian.org/git/apt/apt.git
  I: Please use:
  I: git clone https://anonscm.debian.org/git/apt/apt.git
  I: to retrieve the latest (possibly unreleased) updates to the package.

This would separate it better from the rest of the status messages.

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/apt-private/private-source.cc b/apt-private/private-source.cc
index 96344d7..ae6c943 100644
--- a/apt-private/private-source.cc
+++ b/apt-private/private-source.cc
@@ -370,9 +370,9 @@ bool DoSource(CommandLine )
 pos += vcs.length()+2;
 std::string::size_type epos = srec.find("\n", pos);
 std::string const uri = srec.substr(pos,epos-pos);
-ioprintf(c1out, _("NOTICE: '%s' packaging is maintained in "
+ioprintf(c1out, _("I: '%s' packaging is maintained in "
  "the '%s' version control system at:\n"
- "%s\n"),
+ "I: %s\n"),
   Src.c_str(), vcs.c_str(), uri.c_str());
 std::string vcscmd;
 if (vcs == "Bzr")
@@ -381,8 +381,8 @@ bool DoSource(CommandLine )
vcscmd = "git clone " + uri;
 
 if (vcscmd.empty() == false)
-   ioprintf(c1out,_("Please use:\n%s\n"
-"to retrieve the latest (possibly unreleased) "
+   ioprintf(c1out,_("I: Please use:\nI: %s\n"
+"I: to retrieve the latest (possibly unreleased) "
 "updates to the package.\n"),
  vcscmd.c_str());
 break;

Bug#854332: cloud-sptheme: please make the build reproducible

[Chris Lamb]

forwarded 854332 
https://bitbucket.org/ecollins/cloud_sptheme/pull-requests/22/please-make-the-build-reproducible/diff
thanks

I've sent this upstream.


Regards,

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

Bug#854333: git-buildpackage: fails to import native packages with large debian/changelog

[Chris Lamb]

Source: git-buildpackage
Version: 0.8.12.1
Severity: important
Tags: patch

Hi,

Pretty certain this a regression from #577810 but it is no
longer possible to import various Debian native packages such
as apt and git-buildpackage itself:

$ gbp import-dsc --verbose --download apt
gbp:warning: Passing --download explicitly is deprecated.
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:info: Downloading 'apt' using 'apt-get'...
gbp:debug: apt-get ['--download-only', '-qq', 'source', 'apt'] []
gbp:debug: Debian Native Package
gbp:debug: Version: 1.4~beta4
gbp:debug: Debian tarball: /tmp/tmp85CXa3/apt_1.4~beta4.tar.xz
gbp:info: No git repository found, creating one.
gbp:debug: ['git', 'init']
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'config', 'user.name', 'Chris Lamb']
gbp:debug: ['git', 'config', 'user.email', 'la...@debian.org']
gbp:debug: tar ['-C', 
'/home/lamby/temp/cdt.20170206182054.hYM5Oha2O3/tmpisHWRy', '-a', '-xf', 
'/tmp/tmp85CXa3/apt_1.4~beta4.tar.xz'] []
gbp:debug: ['git', 'tag', '-l', 'debian/1.4_beta4']
gbp:debug: ['git', 'tag', '-l', 'debian/1.4.beta4']
gbp:debug: ['git', 'tag', '-l', 'debian/1.4_beta4']
gbp:debug: ['git', 'tag', '-l', 'debian/1.4.beta4']
gbp:info: Tag debian/1.4_beta4 not found, importing Debian tarball
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'commit-tree', '046e88c2658cb144ce0968b3ebd280c4d3153ed3']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: Import Debian version 
1.4~beta4\n\napt (1.4~beta4) unstable; urgency=med

gbp:error: Git command failed: Error running git update-ref: [Errno 7] Argument 
list too long
gbp:debug: rm ['-rf', 
'/home/lamby/temp/cdt.20170206182054.hYM5Oha2O3/tmpisHWRy'] []
gbp:debug: rm ['-rf', '/tmp/tmp85CXa3'] []

$ echo $?
1

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/gbp/scripts/import_dsc.py b/gbp/scripts/import_dsc.py
index 280be43..02ae343 100644
--- a/gbp/scripts/import_dsc.py
+++ b/gbp/scripts/import_dsc.py
@@ -446,10 +446,16 @@ def main(argv):
 if src.native:
 author = get_author_from_changelog(upstream.unpacked)
 committer = get_committer_from_author(author, options)
-commit_msg = "Import %s\n%s" % (msg, 
get_changes(upstream.unpacked,
- repo,
- is_empty,
- 
options.debian_branch))
+changes = get_changes(upstream.unpacked,
+  repo,
+  is_empty,
+  options.debian_branch)
+# Truncate debian/changelog if necessary to avoid the
+# command-line argument list becoming too long.
+max_len = 1
+if len(changes) > max_len:
+changes = "%s\n\n[changelog truncated at %d bytes]" % 
(changes[:max_len], max_len)
+commit_msg = "Import %s\n%s" % (msg, changes)
 else:
 author = committer = {}
 commit_msg = "Import %s" % msg

Bug#854079: firefox-esr: firefox dies immediately on arm64

[Mike Hommey]

On Sun, Feb 05, 2017 at 07:35:08AM +0900, Mike Hommey wrote:
> On Fri, Feb 03, 2017 at 09:10:10PM +0200, Aaro Koskinen wrote:
> > Package: firefox-esr
> > Version: 45.7.0esr-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Firefox crashes right after startup:
> > 
> > $ time firefox
> > Xlib:  extension "RANDR" missing on display ":0".
> > Segmentation fault
> > 
> > real0m12.336s
> > user0m10.940s
> > sys 0m0.703s
> > 
> > $ time firefox-esr -safe-mode
> > Xlib:  extension "RANDR" missing on display ":0".
> > Segmentation fault
> > 
> > real0m21.269s
> > user0m11.961s
> > sys 0m0.678s
> > 
> > $ MOZILLA_DISABLE_PLUGINS=1 firefox-esr
> > Xlib:  extension "RANDR" missing on display ":0".
> > Segmentation fault
> > 
> Chances are this is the same problem that causes the random build
> failures, cf. bug 825355, and I'm going to fix that one in next upload.

That's fixed in 47.5.0esr-3. Can you check if you still get crashes with
that version?

Mike

Bug#854291: debian-installer: Installer does not map English / Denmark to en_DK.xxx locale.

[Christian PERRIER]

reassign 854291 localechooser
tags 854291 wontfix
thanks

Quoting Thomas Rosted Jensen (tho...@rosted.net):
> Package: debian-installer
> Version: 20170127_amd64
> 
> I have installed Debian test image from 1. Feb 2017:
> http://cdimage.debian.org/cdimage/stretch_di_rc2/amd64/iso-cd/debian-stretch-DI-rc2-amd64-netinst.iso
> 
> 
> During installation i select English for Language, and Denmark for the
> locale.
> 
> However the install fails to map English language / Denmark locale to the
> "en_DK.UTP-8" locale definition.
> 
> The expert install allows me to select "en_DK.UTP-8" definition manually, so
> that installed system works fine.
> 
> Attached files.
> - /etc/default/locale
> - /etc/locale.gen
> - /var/log/installer/syslog
> 
> Screenshots with descriptions in file "Debian9_select_en_DK_locale.pdf"
> 
> /Thomas

This is frequently reported.and, as usual, plain wrong. en_DK is a
longstanding locale in glibc that is indeed a tweak and that shouldn't
exist.

By design, locales are meant to represent real use cases, which is why
they're nearly always limited to language/country combinations that
indeed *really* exist.

English has no specific status in Denmark (except by being spoken by
many peoplebut that's also the case in most countries) and the
fact that a en_DK locale existts is only historical.

For that reason, d-i does not directly support tthe en_DK locale and
does it only exactly as you did, through the expert install. Whichis
logical as nobody would choose such combination in normal installs

This is commonly argued by a few people, from time to time.and
none of them managed to convince the D-I team to do something
else..:-)

So, well, reassigning and tagging accordingly




signature.asc
Description: PGP signature

Bug#854280: matplotlib: contains image with non-free color calibration profile

[Sandro Tosi]

control: tags -1 +moreinfo

also, could you specify how to verify your claim? like: what command
to use, etc etc

On Sun, Feb 5, 2017 at 1:03 PM, Sandro Tosi  wrote:
> to what version of matplotlib does this apply to?
>
> On Sun, Feb 5, 2017 at 12:50 PM, Jonas Smedegaard  wrote:
>> Source: matplotlib
>> Severity: serious
>> Tags: upstream
>> Justification: Policy 2.1
>>
>> The file lib/matplotlib/mpl-data/sample_data/necked_tensile_specimen.png
>> is an image with an embedded color calibration profile copyright Apple,
>> which lacks DFSG-compatible license.
>>
>>  - Jonas
>
>
>
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> G+: https://plus.google.com/u/0/+SandroTosi



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#854332: cloud-sptheme: please make the build reproducible

[Chris Lamb]

Source: cloud-sptheme
Version: 1.8.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that cloud-sptheme could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0004-reproducible-build.patch  1970-01-01 
12:00:00.0 +1200
--- b/debian/patches/0004-reproducible-build.patch  2017-02-06 
16:56:35.851016445 +1300
@@ -0,0 +1,24 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-02-06
+
+--- cloud-sptheme-1.8.0.orig/setup.py
 cloud-sptheme-1.8.0/setup.py
+@@ -16,6 +16,7 @@ import re
+ from setuptools import setup, find_packages
+ import subprocess
+ import time
++import datetime
+ #=
+ #inspection
+ #=
+@@ -31,7 +32,8 @@ if os.environ.get("CLOUD_SETUP_TAG_RELEA
+ raise subprocess.CalledProcessError(1, [])
+ stamp = stamp.decode("ascii")
+ except (OSError, subprocess.CalledProcessError):
+-stamp = time.strftime("%Y%m%d%H%M%S")
++build_date = 
datetime.datetime.utcfromtimestamp(int(os.environ.get('SOURCE_DATE_EPOCH', 
time.time(
++stamp = build_date.strftime("%Y%m%d%H%M%S")
+ version += ".post" + stamp
+ 
+ #=
--- a/debian/patches/series 2017-02-06 16:43:03.444740709 +1300
--- b/debian/patches/series 2017-02-06 16:56:33.73168 +1300
@@ -1,3 +1,4 @@
 0001-move-themes-to-usr-share.patch
 0002-add-missing-table_styling.css.patch
 0003-Remove-cookies-and-tracking.patch
+0004-reproducible-build.patch

Bug#854111: aprx: please make the build reproducible

[Chris Lamb]

tags 854111 + fixed-upstream
thanks

Chris Lamb wrote:

> aprx: please make the build reproducible

This appears to have been fixed upstream:

   
https://github.com/PhirePhly/aprx/commit/55adc20a9a3e32e99d533a4749fd773549eb3e52


Regards,

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

Bug#854112: pnmixer: please make the build reproducible

[Chris Lamb]

forwarded 854112 https://github.com/nicklan/pnmixer/pull/153
thanks

Sent upstream.


Regards,

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

Bug#854112: pnmixer: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> pnmixer: please make the build reproducible

Re-attaching patch without useless "Makefile.am.orig" hunk. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 12:00:00.0 
+1200
--- b/debian/patches/reproducible-build.patch   2017-02-04 22:08:44.12557 
+1300
@@ -0,0 +1,29 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-02-04
+
+--- pnmixer-0.7.orig/man/Makefile.am
 pnmixer-0.7/man/Makefile.am
+@@ -1,5 +1,10 @@
+ .0.1:
+-  @sed -e "s/!VERSION!/@PACKAGE_VERSION@/g" -e "s/!DATE!/`date '+%B 
%Y'`/g" < $*.0 > $@
++  @sed -e "s/!VERSION!/@PACKAGE_VERSION@/g" < $*.0 > $@
++if WITH_SOURCE_DATE_EPOCH
++  @sed -e "s/!DATE!/`LC_ALL=C date --utc --date="@$(SOURCE_DATE_EPOCH)" 
'+%B %Y'`/g" < $*.0 > $@
++else
++  @sed -e "s/!DATE!/`date '+%B %Y'`/g" < $*.0 > $@
++endif
+   @echo Built $*.1 from template
+ 
+ manpages_in_files = $(wildcard *.0)
+--- pnmixer-0.7.orig/configure.ac
 pnmixer-0.7/configure.ac
+@@ -7,6 +7,8 @@ AM_INIT_AUTOMAKE([foreign])
+ AM_MAINTAINER_MODE
+ AC_CONFIG_HEADERS([src/config.h])
+ 
++AM_CONDITIONAL([WITH_SOURCE_DATE_EPOCH], [test "$SOURCE_DATE_EPOCH" != ""])
++
+ # = #
+ #  Basic compiler settings  #
+ # = #
--- a/debian/patches/series 1970-01-01 12:00:00.0 +1200
--- b/debian/patches/series 2017-02-04 21:49:56.928890444 +1300
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#725350: chromium: Windows jump to front when opening new tabs

[Michael Gilbert]

control: found -1 37.0.2062.120-1
control: reopen -1

Upstream changes reintroduced this problem.

Best wishes,
Mike

Bug#854331: postfix.postinst trying to start postfix daemon before postfix user created

[Johannes Schilling]

Package: postfix
Version: 3.1.4-4
X-Debbugs-Cc: probl...@cip.cs.fau.de
Tags: patch

hi,


when i install postfix to a freshly installed (with our custom
debootstrap+saltstack process, but as far as i can tell that doesn't
make a difference here), the postinst script fails to start because the
"posfix" user doesn't exist on the system yet:

# apt install postfix
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libcdb-dev libcdb1 liblmdb-dev libsasl2-dev linux-image-amd64
Use 'apt autoremove' to remove them.
Suggested packages:
  postfix-mysql postfix-pgsql postfix-ldap postfix-pcre postfix-lmdb sasl2-bin 
dovecot-common resolvconf postfix-cdb ufw postfix-doc
The following NEW packages will be installed:
  postfix
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,435 kB of archives.
After this operation, 4,010 kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package postfix.
(Reading database ... 918427 files and directories currently installed.)
Preparing to unpack .../postfix_3.1.4-4_amd64.deb ...
Unpacking postfix (3.1.4-4) ...
Processing triggers for systemd (232-15) ...
Processing triggers for man-db (2.7.6.1-2) ...
Processing triggers for rsyslog (8.24.0-1) ...
Setting up postfix (3.1.4-4) ...
Created symlink /etc/systemd/system/multi-user.target.wants/postfix.service → 
/etc/systemd/system/postfix.service.
Job for postfix.service failed because the control process exited with error 
code.
See "systemctl status postfix.service" and "journalctl -xe" for details.
invoke-rc.d: initscript postfix, action "start" failed.
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/etc/systemd/system/postfix.service; enabled; vendor preset: 
enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2017-02-06 
03:25:57 CET; 7ms ago
  Process: 16928 ExecStart=/usr/sbin/postfix start (code=exited, 
status=1/FAILURE)
  Process: 16924 ExecStartPre=/bin/cp /etc/services 
/var/spool/postfix/etc/services (code=exited, status=0/SUCCESS)
  Process: 16916 ExecStartPre=/bin/cp /etc/resolv.conf 
/var/spool/postfix/etc/resolv.conf (code=exited, status=0/SUCCESS)

Feb 06 03:25:57 faui03m systemd[1]: Failed to start Postfix Mail Transport 
Agent.
Feb 06 03:25:57 faui03m systemd[1]: postfix.service: Unit entered failed state.
Feb 06 03:25:57 faui03m systemd[1]: postfix.service: Failed with result 
'exit-code'.
dpkg: error processing package postfix (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (232-15) ...
Processing triggers for rsyslog (8.24.0-1) ...
Errors were encountered while processing:
 postfix
E: Sub-process /usr/bin/dpkg returned an error code (1)


# getent passwd postfix
# getent group postfix



steps to reproduce: debootstrap stretch; install postfix
expected outcome: postfix creating appropriate users+cfg files
actual outcome: postfix fails in postinst before creating user/group

the problem seems to be that the "#DEBHELPER#" magic inserted at line
200f. of postfix.postinst contains the following snippet:


# Automatically added by dh_installinit
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
if [ -x "/etc/init.d/postfix" ]; then
update-rc.d postfix defaults >/dev/null
invoke-rc.d postfix start || exit $?
fi
fi
# End automatically added section

which tries to start the postfix daemon before all the config setup is
finished.

the attached patch moves the "#DEBHELPER#" line all the way to the
bottom of postfix.postinst, which does fix the problem for us, but i'm
not certain enough to understand the .postinst and especially the
debhelper magic to know this simple fix doesn't introduce new problems.



regards,
   johannes schilling
diff --git a/postfix.postinst b/postfix.postinst
index b413a50..43f4500 100644
--- a/postfix.postinst
+++ b/postfix.postinst
@@ -197,8 +197,6 @@ umask 022
 
 # postinst processing
 
-#DEBHELPER#
-
 case "$1" in
 configure)
OLDVERSION="$2"
@@ -674,3 +672,5 @@ if [ "$mailer" != "No configuration" ] || [ -f /etc/postfix/main.cf ]; then
fi
 fi
 fi
+
+#DEBHELPER#

Bug#854330: dvbstream: New upstream location with updates

[David Liontooth]

Package: dvbstream
Severity: normal

The dvbstream utility has useful updates for satellite signal support here: 
https://github.com/linuxstb/dvbtools/tree/master/dvbstream

linuxstb was one of the two original developers on the SourceForge site, so it 
seems safe to assume the project has migrated to this github location.

The enhancements date from 2013 and have still not been merged. The patch I 
submitted here years ago was merged into linuxstb's repository on github 
(#604103).

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

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

Versions of packages dvbstream depends on:
ii  libc6  2.19-18+deb8u6

dvbstream recommends no packages.

Versions of packages dvbstream suggests:
pn  dvbtune  
ii  mpg123   1.20.1-2

Bug#854328: dehydrated: wrong path to example config

[Adam Borowski]

Package: dehydrated
Version: 0.3.1-2
Severity: minor

/etc/dehydrated/config says:
# This is the default configuration for the Debian package. #
# To see a more comprehensive example, see  #
# /usr/share/doc/dehydrated/examples/config.example #

but "dpkg -L dehydrated":
/usr/share/doc/dehydrated/examples/config

Please s/\.example$//


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

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

Versions of packages dehydrated depends on:
ii  ca-certificates  20161130
ii  curl 7.52.1-2
ii  openssl  1.1.0d-2

dehydrated recommends no packages.

dehydrated suggests no packages.

-- no debconf information

Bug#834088: What's up with mongrel2?

[Andreas Beckmann]

On 2017-02-05 16:42, Jan Niehusmann wrote:
> Andreas, you cloned #832656 and reassigned one of the clones to
> mongrel2-run. Do you still remember if you verified that mongrel2 was
> actually affected?

There was a install failure at that time ... but I haven't seen any
recent failures.

> And even if mongrel2 was affected, as far as I understand the bug, it's
> probably been fixed by the following change in runit 2.1.2-7:
> 
>   * Create /etc/runit/runsvdir/default directory and /etc/service directories
> as part of binary package, not in maintainer scripts. Empty directories 
> are
> not pretty, but usually user installs some runscripts with 'runit' binary
> package, and will not notice issue.

Looks like a good candidate for fixing what I observed at that time.


Andreas

Bug#852458: steam: missing dependencies

[Michael Gilbert]

On Sun, Feb 5, 2017 at 8:32 PM, Michael Gilbert wrote:
> There something else to this that needs to be figured out.  Have you
> tried searching the steam forums?

Does installing the nvidia-driver-libs-i386 package as suggested in
#839592 help?

If so, the problem was not installing the right driver packages.

Best wishes,
Mike

Bug#854327: pulseaudio: default configuration depends on consolekit

[Michael Gilbert]

package: pulseaudio
severity: important
version: 10.0-1

Pulseaudio's default settings require the consolekit package to be
installed, but the package has no relationship to consolekit.

Without consolekit:
$ pulseaudio
[...]
E: [pulseaudio] module.c: Failed to load module "module-console-kit"
(argument: ""): initialization failed
E: [pulseaudio] main.c: Module load failed.
E: [pulseaudio] main.c: Failed to initialize daemon.

To fix this, either the "load-module module-console-kit" line can be
commented in /etc/pulse/default.pa.  Or the consolekit package can be
installed, but there are a lot of setups where it's not needed or
wanted.

Best wishes,
Mike

Bug#854326: For Linux OS in btrfs subvolume, boot failure from menu entry made by /etc/grub.d/os-prober script

[dg1727]

Package: grub-common
Version: 2.02~beta2-22+deb8u1

Steps to reproduce:
-

1. Hard drive (EFI mode) has Btrfs "/" partitions of two Debian-derived Linux 
OSes:
/dev/sda2 Xubuntu 13.04 with GRUB package version 2.00-13ubuntu3
- Hereinafter, "Ubuntu" refers to this _specific_ install and *NOT* to Ubuntu 
OSes generally.
/dev/sda3 Linux Mint Debian Edition 2 "Betsy" with GRUB package version as 
noted in "Version" pseudo-header of this bug report (from Debian Jessie)
- Hereinafter known as "LMDE".
The Ubuntu install is in subvolume "@" of the Btrfs filesystem. I believe this 
partition was installed by a vendor who sells a lot of Linux PCs, and/or using 
subvolume "@" was recommended at one time as a best practice (although I wasn't 
able to find it on the Web recently), so a high percentage of Btrfs users is 
likely to be using subvolume "@" like this.

2. Run "update-grub" in LMDE.

3. Reboot the PC and select Ubuntu option from GRUB menu.

4. GRUB is unable to boot Linux, and halts with an error message that's 
something like the following:

Unable to find /boot/vmlinuz-3.blah.blah
alloc magic is broken at 0x (0x).
Aborted. Press any key

If I alter the folders in the EFI system partition so that Ubuntu's .efi file 
(instead of LMDE's) is the one that boots, then the Ubuntu-generated GRUB menu 
can successfully boot either Ubuntu or LMDE.

Comments on possible fix:
-
In /boot/grub/grub.cfg in the 2 OS installs, I compared the section that boots 
Ubuntu. The Ubuntu grub.cfg (section made by the /etc/grub.d/linux script) 
contains 3 things that are missing from the LMDE grub.cfg (section made by the 
/etc/grub.d/os-prober script):

* The filename parameter to the "linux" and "initrd" commands has a /@ prefix 
(i.e., it looks like /@/boot/vmlinuz...)
* After the "root=" partition spec, there is "rootflags=subvol=@"
* Finally, there are kernel command-line parameters (e.g., "quiet splash") - 
not relevant to the boot failure, but probably should still be fixed.

Manually updating LMDE's grub.cfg with these differences causes Ubuntu to boot 
successfully when the LMDE-generated "Ubuntu" GRUB menu option is chosen. I 
know that grub.cfg isn't normally supposed to be updated manually; I did this 
for troubleshooting only.

I stated the Ubuntu GRUB package version only to document that the 
/etc/grub.d/linux script in that GRUB version seems to have correct logic that 
maybe can be ported to /etc/grub.d/os-prober in the current GRUB version. 
Specifically, there appears to be a function called 
"make_system_path_relative_to_its_root" which seems to detect that 
/boot/vmlinuz is really at /@/boot/vmlinuz.

Thanks in advance for reviewing this.

-dg1727

Bug#852458: steam: missing dependencies

[Michael Gilbert]

control: tag -1 unreproducible

> I just did a fresh install of Debian Sid on my computer,
> and I tried to install Steam
> - libxtst6:i386
> - libxrandr2:i386
> - libglib2.0-0:i386
> - libpulse0:i386

Hi, I'm not able to reproduce this from a fresh install.  Steam
launches fine for me without any of these packages.

There something else to this that needs to be figured out.  Have you
tried searching the steam forums?

Best wishes,
Mike

Bug#854318: gnome-keyring: Attempts to provide ssh-agent

[Michael Biebl]

Am 06.02.2017 um 00:43 schrieb Mark Brown:
> Package: gnome-keyring
> Version: 3.20.0-3
> Severity: important
> 
> A recent upgrade to gnome-keyring appears to have resulted in it once
> again trying to provide a SSH agent.  Since I use a gnupg smartcard to
> store my authentication keys for SSH (which is supported by GnuPG but
> not by gnome-keyring) this breaks my ability to SSH into most remote
> systems, including things like preventing me from doing anything on
> kernel.org.
> 
> I have previously removed /etc/xdg/autostart/gnome-keyring-ssh.desktop
> (which is still removed) but it appears that this is now triggred by
> systemd somehow.

Might this be a gnupg-agent issue?
I see it enables
/usr/lib/systemd/user/sockets.target.wants/gpg-agent-ssh.socket by default.

What happens if you run
systemctl --user mask gpg-agent-ssh.socket
systemctl --user stop gpg-agent-ssh.socket


-- 
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#854325: ifupdown2: missing Conflicts: ifupdown

[Andreas Beckmann]

Package: ifupdown2
Version: 1.0~git20170114-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts


Hi,

despite of all the diversion magic being performed, ifupdown2
comes with
  Provides+Replaces: ifupdown
but without a corresponding Breaks or Conflicts: ifupdown.
This causes files to disappear after the sequence:

  install ifupdown
  install ifupdown2
  remove+purge ifupdown2

and ifupdown is no longer functional (but dpkg still thinks
it is correctly installed).


>From the attached log (scroll to the bottom...):

0m28.7s ERROR: FAIL: After purging files have disappeared:
  /etc/default/networkingowned by: ifupdown2
  /etc/systemd/system/multi-user.target.wants/   not owned
  /etc/systemd/system/multi-user.target.wants/networking.service -> 
/lib/systemd/system/networking.service   not owned
  /etc/systemd/system/network-online.target.wants/   not owned
  /etc/systemd/system/network-online.target.wants/networking.service -> 
/lib/systemd/system/networking.service   not owned
  /lib/systemd/system/networking.service owned by: ifupdown2
  /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/   not 
owned
  
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/networking.service
 not owned
  /var/lib/systemd/deb-systemd-helper-enabled/network-online.target.wants/  
 not owned
  
/var/lib/systemd/deb-systemd-helper-enabled/network-online.target.wants/networking.service
 not owned
  /var/lib/systemd/deb-systemd-helper-enabled/networking.service.dsh-also   
 not owned

(note that "owned by: ifupdown2" is misleading - the ownership was only
recorded after ifupdown2 was installed and had taken over these files)

Diversions cannot be used for /etc/default/networking!

To allow switching back from ifupdown2 to ifupdown, ifupdown will
probably need a matching Provides+Replaces+Conflicts: ifupdown,
(against the virtual ifupdown package, not against ifupdown2)
but I haven't tested that.


Andreas


ifupdown=0.8.19_ifupdown2=1.0~git20170114-1.log.gz
Description: application/gzip

Bug#854324: RFP: Lis -- Library of Iterative Solvers for linear systems

[Upadhaya Brijesh]

Package: lis
Version: 1.7.25
URL: http://www.ssisc.org/lis/
License: New BSD License
Severity: wishlist


Lis is a numerical library that provides iterative solver for large linear 
systems. Lis can also be used  for parallel computation, and also solving 
eigenvalue problems that arise in the numerical solution of the partial 
differential equations using iterative methods.


With kind regards,

Brijesh Upadhaya
-
Doctoral Student
Department of Electrical Engineering and Automation
School of Electrical Engineering, Aalto University
P. O. Box 13000, FI-00076 AALTO,
FINLAND

Bug#854317: piuparts: adequate reports obsolete conffile for piuparts

[shirish शिरीष]

at bottom :-

On 06/02/2017, Andreas Beckmann  wrote:
> Control: tag -1 pending
>
> On 2017-02-06 01:06, Andreas Beckmann wrote:
>> My fault: it was a symlink in the repository, but a regular conffile was
>> shipped in the package. Will clean this up as well.
>
> Andreas Beckmann (1):
>   rm_conffile /etc/piuparts/scripts/post_setup_experimental
>
>
> Andreas
>
> PS: @Holger: you should apply the log-alternatives-changes patch, too
>

Hi all,
Sorry was not able to reply you back. For some reason gmail decided
that you and the whole thread was spam. Just saw it while cleaning my
digital house :(

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#854323: RFP: FGSL -- A Fortran interface to the GNU Scientific Library

[Upadhaya Brijesh]

Package: fgsl
Version: 1.2.0
URL: https://www.lrz.de/services/software/mathematik/gsl/fortran/
License: GPL
Severity: wishlist


FGSL is a numerical library that provides a Fortran interface to the GNU 
Scientific Library (GSL). FGSL is actively maintained by Leibniz Super 
Computing Center. The FGSL package will be very useful to those who want to use 
the GSL, and are more familiar to Fortran than C programming language.


With kind regards,

Brijesh Upadhaya
-
Doctoral Student
Department of Electrical Engineering and Automation
School of Electrical Engineering, Aalto University
P. O. Box 13000, FI-00076 AALTO,
FINLAND

Bug#854322: xserver-xorg-legacy: depend or recommend libinput

[Michael Gilbert]

package: xserver-xorg-legacy
severity: wishlist
version: 2:1.19.1-4

It is possible to install xserver-xorg-legacy without
xserver-xorg-input-libinput, but when launched there is, of course, no
mouse/input handling.  It could be helpful if there was a depends or
recommends relationship.

Best wishes,
Mike

Bug#854317: piuparts: adequate reports obsolete conffile for piuparts

[Andreas Beckmann]

Control: tag -1 pending

On 2017-02-06 01:06, Andreas Beckmann wrote:
> My fault: it was a symlink in the repository, but a regular conffile was
> shipped in the package. Will clean this up as well.

Andreas Beckmann (1):
  rm_conffile /etc/piuparts/scripts/post_setup_experimental


Andreas

PS: @Holger: you should apply the log-alternatives-changes patch, too

Bug#853119: texlive-luatex: basic lualatex document does not compile anymore without additionnal dependencies

[Norbert Preining]

Hi Julian,

> for me, just installing lmodern did not fix the issue with the
[...]
> \documentclass{standalone}
...
> \sa@placebox ->\newpage \global \pdfpagewidth 
>   =\wd \sa@box \global

This is a completely unrelated issue, the "standalone" class is
not adapted to work with newer luatex, that was the case already
since long.

You need to use a different class, or add
\RequirePackage{luatex85}
*before* the \documentclass call. 

There are actually several stack exchange entries related to exactly this
problem.

Thanks.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#854317: [Piuparts-devel] Bug#854317: piuparts: adequate reports obsolete conffile for piuparts

[Andreas Beckmann]

On 2017-02-06 01:02, Andreas Beckmann wrote:
> On 2017-02-06 00:33, shirish शिरीष wrote:
>> piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental
> 
> That was a symlink before it was removed recently ... maybe it has been
> a conffile in the ancient past?

My fault: it was a symlink in the repository, but a regular conffile was
shipped in the package. Will clean this up as well.


Andreas

Bug#854321: kmymoney: CSV import to liability account not possible

[Andrew Goodbody]

Package: kmymoney
Version: 4.8.0-2
Severity: normal
Tags: upstream

When using the CSV import tool only asset accounts are listed for
import, other types such as liability accounts are not listed.

https://bugs.kde.org/show_bug.cgi?id=364425

There is a bug fix in the next unreleased version of kmymoney.

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

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

Versions of packages kmymoney depends on:
ii  kde-runtime 4:16.08.3-1
ii  kdepim-runtime  4:16.04.2-2
ii  kmymoney-common 4.8.0-2
ii  libakonadi-kde4 4:4.14.10-7
ii  libalkimia5 5.0.0-3
ii  libaqbanking35  5.6.12-1
ii  libaqbanking35-plugins  5.6.12-1
ii  libc6   2.24-9
ii  libgcc1 1:6.3.0-5
ii  libgmp102:6.1.2+dfsg-1
ii  libgpgme++2v5   4:4.14.10-7
ii  libgwengui-cpp0 4.15.3-5
ii  libgwengui-qt4-04.15.3-5
ii  libgwenhywfar60 4.15.3-5
ii  libical22.0.0-0.5+b1
ii  libkabc44:4.14.10-7
ii  libkcmutils44:4.14.26-1
ii  libkdecore5 4:4.14.26-1
ii  libkdeui5   4:4.14.26-1
ii  libkfile4   4:4.14.26-1
ii  libkholidays4   4:4.14.10-7
ii  libkhtml5   4:4.14.26-1
ii  libkio5 4:4.14.26-1
ii  libkpimidentities4  4:4.14.10-7
ii  libkrosscore4   4:4.14.26-1
ii  libofx6 1:0.9.10-2
ii  libqt4-dbus 4:4.8.7+dfsg-11
ii  libqt4-declarative  4:4.8.7+dfsg-11
ii  libqt4-network  4:4.8.7+dfsg-11
ii  libqt4-sql  4:4.8.7+dfsg-11
ii  libqt4-svg  4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libstdc++6  6.3.0-5

Versions of packages kmymoney recommends:
ii  gnupg-agent   2.1.18-3
ii  pinentry-qt4  1.0.0-1

kmymoney suggests no packages.

-- no debconf information

Bug#854317: piuparts: adequate reports obsolete conffile for piuparts

[Andreas Beckmann]

On 2017-02-06 00:33, shirish शिरीष wrote:
> piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental

That was a symlink before it was removed recently ... maybe it has been
a conffile in the ancient past?

What is the upgrade history leading to this?

Since dpkg-maintscript-helper rm_conffile does not work properly when
used on symlinks (#852468), this is probably a wontfix bug.


Andreas

Bug#854320: pm-utils: Notebook can't resume from Hibernate and Suspend

[Alexandre Lymberopoulos]

Package: pm-utils
Version: 1.4.1-17
Severity: important

Dear Maintainer,

Everytime I try to resume from a hibernate or a suspend the computer
locks up. When on console I see the following message after image
loading is done and the displaying of speed of image reading:

Suspending console(s) (use no_console_suspend to debug)

The obvious attitude was to use no_console_suspend to debug. I would
love to do that to provide further information but I don't know where
I should use and how. It this is really important to fix the bug I do
it under guidance.

I can provide any further information upon request.

Thanks in advance,
Alexandre.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages pm-utils depends on:
ii  powermgmt-base  1.31+nmu1

Versions of packages pm-utils recommends:
pn  ethtool  
ii  hdparm   9.50+ds-1
ii  kbd  2.0.3-2
ii  procps   2:3.3.12-3
ii  vbetool  1.1-4

Versions of packages pm-utils suggests:
ii  cpufrequtils008-1
pn  radeontool  
ii  wireless-tools  30~pre9-12

-- no debconf information

Bug#854319: unblock: jackson-jaxrs-providers/2.8.5-2

[tony mancill]

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

Dear Release Team,

Please consider an unblock for the package jackson-jaxrs-providers.

The upstream build system for this package is coupled to the version of
src:jackson-core and related, which were updated from 2.8.5 -> 2.8.6 via
this [1] and related uploads.  This patch updates the version and
build-dependencies for 2.8.6.  The debdiff is attached.

unblock jackson-jaxrs-providers/2.8.5-2

Thank you for taking the time to look at this.
Cheers,
tony

[1] https://tracker.debian.org/news/835725
diff -Nru jackson-jaxrs-providers-2.8.5/debian/changelog jackson-jaxrs-providers-2.8.5/debian/changelog
--- jackson-jaxrs-providers-2.8.5/debian/changelog	2016-12-21 06:01:56.0 -0800
+++ jackson-jaxrs-providers-2.8.5/debian/changelog	2017-02-05 14:39:06.0 -0800
@@ -1,3 +1,11 @@
+jackson-jaxrs-providers (2.8.5-2) unstable; urgency=medium
+
+  * Team upload.
+  * Modify buildsystem patch for jackson-core 2.8.6 and build-depend
+on this version in debian/control.  Addresses FTBFS (Closes: #852919).
+
+ -- tony mancill   Sun, 05 Feb 2017 14:39:06 -0800
+
 jackson-jaxrs-providers (2.8.5-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru jackson-jaxrs-providers-2.8.5/debian/control jackson-jaxrs-providers-2.8.5/debian/control
--- jackson-jaxrs-providers-2.8.5/debian/control	2016-12-21 06:01:12.0 -0800
+++ jackson-jaxrs-providers-2.8.5/debian/control	2017-02-05 14:39:06.0 -0800
@@ -7,12 +7,12 @@
  debhelper (>= 10),
  default-jdk,
  libbuild-helper-maven-plugin-java,
- libjackson2-core-java (>= 2.8.5),
- libjackson2-databind-java (>= 2.8.5),
+ libjackson2-core-java (>= 2.8.6),
+ libjackson2-databind-java (>= 2.8.6),
  libjackson2-dataformat-cbor (>= 2.7.3),
  libjackson2-dataformat-smile (>= 2.7.3),
- libjackson2-dataformat-xml-java (>= 2.8.5),
- libjackson2-dataformat-yaml (>= 2.8.5),
+ libjackson2-dataformat-xml-java (>= 2.8.6),
+ libjackson2-dataformat-yaml (>= 2.8.6),
  libjackson2-module-jaxb-annotations-java (>= 2.4),
  libjaxrs-api-java,
  libjsr311-api-java,
diff -Nru jackson-jaxrs-providers-2.8.5/debian/patches/fix-bundle-dependencies.patch jackson-jaxrs-providers-2.8.5/debian/patches/fix-bundle-dependencies.patch
--- jackson-jaxrs-providers-2.8.5/debian/patches/fix-bundle-dependencies.patch	2016-12-21 06:01:12.0 -0800
+++ jackson-jaxrs-providers-2.8.5/debian/patches/fix-bundle-dependencies.patch	2017-02-05 14:39:06.0 -0800
@@ -77,3 +77,14 @@
test
  

+--- a/pom.xml
 b/pom.xml
+@@ -33,7 +33,7 @@
+   
+ UTF-8 
+ 
+-2.8.5
++2.8.6
+ ${version.jackson.core}
+ 
+ ${version.dataformats}


signature.asc
Description: PGP signature

Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued

[Cyril Brulebois]

Hi,

Aurelien Jarno  (2017-02-06):
> Well this kind of patch is not mergeable upstream, so we will have to
> keep it forever.

Or just for stretch given the following points?

> What would be wrong in using a supported value for the debian-installer
> locale? It should only be a dozen of lines to change.

A couple of things:
 1. I don't know anything about locales.
 2. Nobody moved a finger on this RC bug for months, so I'm not sure we
have anyone else able/willing to fix this.
 3. The freeze is here and I'm not too thrilled about changing code/data
I don't have a clue about.

> Alternatively would it make sense to install the C.UTF-8 locale from
> libc-bin in libc6-udeb?

Maybe…


KiBi.


signature.asc
Description: Digital signature

Bug#367058: problems with misconfigured gnupg-agent and /etc/X11/Xsession.d/90gpg-agent

[Daniel Kahn Gillmor]

Version: 2.1.13-3

On Fri 2014-09-26 17:31:50 -0400, Daniel Kahn Gillmor wrote:
> Reviewing bugs in GnuPG packages, i'm a little worried about
> https://bugs.debian.org/367058 -- it hasn't been resolved in years, and
> it's pretty simple:
>
> On a machine that uses the standard X11 session startup scripts in
> /etc/X11/Xsession.d (this is chosen by
> /etc/alternatives/x-session-manager, i think, and does not include
> gnome-session, but does include openbox-session), a user can lock
> themselves out of X11 entirely with the following changes to their home
> directory:
>
>  echo use-agent >> ~/.gnupg/gpg.conf
>  echo no-such-option >> ~/.gnupg/gpg-agent.conf
>
> I just tried this on a debian unstable system with gdm3 as the display
> manager and x-session-manager pointing to openbox-session.

I'm happy to say that i think this has been resolved in recent versions
of gnupg-agent.  Since the adoption of the standard socket and the
systemd user services (and upstream's auto-launching for non-systemd
machines) were introduced in version 2.1.13-3, the Xsession.d snippet no
longer needs to launch the daemon.

The remaining business of the Xsession.d snippet is to set environment
variables, but those can be pulled directly from gpgconf (which doesn't
return non-zero even when the underlying program it queries does fail
(see the error handling logic in retrieve_options_from_program(), around
line 2156 of tools/gpgconf-comp.c).

So i don't think that a misconfigured gpg-agent.conf file will cause the
same types of login failures as it used to.

 --dkg


signature.asc
Description: PGP signature

Bug#854318: gnome-keyring: Attempts to provide ssh-agent

[Mark Brown]

Package: gnome-keyring
Version: 3.20.0-3
Severity: important

A recent upgrade to gnome-keyring appears to have resulted in it once
again trying to provide a SSH agent.  Since I use a gnupg smartcard to
store my authentication keys for SSH (which is supported by GnuPG but
not by gnome-keyring) this breaks my ability to SSH into most remote
systems, including things like preventing me from doing anything on
kernel.org.

I have previously removed /etc/xdg/autostart/gnome-keyring-ssh.desktop
(which is still removed) but it appears that this is now triggred by
systemd somehow.

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

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

Versions of packages gnome-keyring depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.14-1
ii  dbus-x11 [dbus-session-bus]   1.10.14-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.0-2
ii  gcr   3.20.0-3
ii  libc6 2.24-9
ii  libcap-ng00.7.7-3
ii  libcap2-bin   1:2.25-1
ii  libgck-1-03.20.0-3
ii  libgcr-base-3-1   3.20.0-3
ii  libgcrypt20   1.7.6-1
ii  libglib2.0-0  2.50.2-2
ii  p11-kit   0.23.3-5
ii  pinentry-gnome3   1.0.0-1

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.20.0-3

gnome-keyring suggests no packages.

-- Configuration Files:
/etc/xdg/autostart/gnome-keyring-ssh.desktop [Errno 2] No such file or 
directory: '/etc/xdg/autostart/gnome-keyring-ssh.desktop'

-- no debconf information

Bug#854287: putty: ed25519 key not recognized

[Jacob Nevins]

Demetris Demetriou writes:
> Package: putty
> Version: 0.67-2
  [...]
> Using puttygen to generate an ed25519 key.
  [...]
> Using that key file in putty results in:
> Unable to load private key file "[REDACTED]" (file format error)

You've reported this bug against PuTTY 0.67, which predates ED25519
support (that hasn't been released yet).

PuTTYgen 0.67 can't generate ED25519 keys. Was the version of PuTTYgen
you used to generate the key newer than 0.67 (i.e., development code)?

Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued

[Aurelien Jarno]

On 2017-02-04 23:45, Cyril Brulebois wrote:
> Hi,
> 
> Lucas Nussbaum  (2016-09-07):
> > Source: installation-locale
> > Version: 1.6
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20160906 qa-ftbfs
> > Justification: FTBFS on amd64
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> > 
> > Relevant part (hopefully):
> > > make[1]: Entering directory '/<>'
> > > localedef -i C.UTF-8.in -f "UTF-8" ./C.UTF-8
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_CTYPE'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > > `LC_NUMERIC'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_TIME'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > > `LC_COLLATE'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > > `LC_MONETARY'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > > `LC_MESSAGES'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_PAPER'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_NAME'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > > `LC_ADDRESS'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > > `LC_TELEPHONE'
> > > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > > `LC_IDENTIFICATION'
> > > no output file produced because warnings were issued
> > > Makefile:4: recipe for target 'C.UTF-8' failed
> > > make[1]: *** [C.UTF-8] Error 4
> 
> I think this is due to the following commit, first released with 2.24:
> | commit 900f59f084bfe35cb389bbe0dc464413a1a38e90
> | Author: Mike Frysinger 
> | Date:   Wed Apr 13 18:38:56 2016 -0400
> | 
> | localedef: check LC_IDENTIFICATION.category values
> | 
> | Currently localedef accepts any value for the category keyword.  This 
> has
> | allowed bad values to propagate to the vast majority of locales (~90%).
> | Add some logic to only accept a few standards.
> 
> I suppose it makes sense to add a Debian-specific patch to the glibc
> package to accept “our extra standard”. I've successfully tested the
> attached patch on top of glibc master, even if I had to disable the
> testsuite because of this:
> | FAIL: rt/tst-shm
> | original exit status 1
> | --
> | +-+
> | | Encountered regressions that don't match expected failures. |
> | +-+
> | FAIL: rt/tst-shm
> | debian/rules.d/build.mk:115: recipe for target 
> '/home/kibi/hack/glibc/glibc-debian.git/stamp-dir/check_libc' failed
> 
> With upgraded libc packages, installation-locale builds fine again.
> 
> glibc maintainer: if you agree with this proposed path and patch, please
> steal this bug report awawy from src:installation-locale.

Well this kind of patch is not mergeable upstream, so we will have to
keep it forever. What would be wrong in using a supported value for 
the debian-installer locale? It should only be a dozen of lines to
change.

Alternatively would it make sense to install the C.UTF-8 locale from
libc-bin in libc6-udeb?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#854316: unblock: pgplot5/5.2.2-19.3

[Andreas Beckmann]

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

Please unblock package pgplot5

fixes a FTBFS recently introduced by zlib1g-dev moving around zconf.h,
again.

unblock pgplot5/5.2.2-19.3


Andreas
diff -Nru pgplot5-5.2.2/debian/changelog pgplot5-5.2.2/debian/changelog
--- pgplot5-5.2.2/debian/changelog	2016-01-07 13:47:52.0 +0100
+++ pgplot5-5.2.2/debian/changelog	2017-02-03 15:07:35.0 +0100
@@ -1,3 +1,12 @@
+pgplot5 (5.2.2-19.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Search zconf.h in non-multiarch and multiarch locations. (Closes: #853898)
+  * Drop obsolete override for lintian false-positive.
+  * Drop superfluous prerm and postinst script.
+
+ -- Andreas Beckmann   Fri, 03 Feb 2017 15:07:35 +0100
+
 pgplot5 (5.2.2-19.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pgplot5-5.2.2/debian/dirs pgplot5-5.2.2/debian/dirs
--- pgplot5-5.2.2/debian/dirs	2007-04-21 20:24:55.0 +0200
+++ pgplot5-5.2.2/debian/dirs	2017-02-01 21:43:12.0 +0100
@@ -3,5 +3,3 @@
 usr/bin
 usr/include
 usr/share/doc/pgplot5
-usr/share/lintian/overrides/
-
diff -Nru pgplot5-5.2.2/debian/overrides pgplot5-5.2.2/debian/overrides
--- pgplot5-5.2.2/debian/overrides	2007-04-21 20:20:49.0 +0200
+++ pgplot5-5.2.2/debian/overrides	1970-01-01 01:00:00.0 +0100
@@ -1,4 +0,0 @@
-# The name PGPLOT in the debian/copyright file causes lintian to assume that
-# this package has a GPL license.
-pgplot5 binary: copyright-should-refer-to-common-license-file-for-gpl
-
diff -Nru pgplot5-5.2.2/debian/patches/linker-specific-changes pgplot5-5.2.2/debian/patches/linker-specific-changes
--- pgplot5-5.2.2/debian/patches/linker-specific-changes	2015-09-10 18:36:43.0 +0200
+++ pgplot5-5.2.2/debian/patches/linker-specific-changes	2017-02-01 21:31:05.0 +0100
@@ -75,7 +75,7 @@
  grtv00.o : $(DRVDIR)/imdef.h
  pgxwin.o : $(DRVDIR)/pgxwin.h
 -pndriv.o : ./png.h ./pngconf.h ./zlib.h ./zconf.h
-+pndriv.o : /usr/include/png.h /usr/include/pngconf.h /usr/include/zlib.h /usr/include/$(DEB_HOST_MULTIARCH)/zconf.h
++pndriv.o : /usr/include/png.h /usr/include/pngconf.h /usr/include/zlib.h $(or $(wildcard /usr/include/zconf.h),/usr/include/$(DEB_HOST_MULTIARCH)/zconf.h)
  
  x2driv.o figdisp_comm.o: $(DRVDIR)/commands.h
  
diff -Nru pgplot5-5.2.2/debian/postinst pgplot5-5.2.2/debian/postinst
--- pgplot5-5.2.2/debian/postinst	2006-07-15 20:18:19.0 +0200
+++ pgplot5-5.2.2/debian/postinst	1970-01-01 01:00:00.0 +0100
@@ -1,18 +0,0 @@
-#!/bin/sh
-set -e
-
-#DEBHELPER#
-
-# Automatically added by dh_installdocs
-if [ "$1" = "configure" ]; then
-#if [ -d /usr/doc -a ! -e /usr/doc/pgplot5 -a -d /usr/share/doc/pgplot5 ]; then
-#ln -sf ../share/doc/pgplot5 /usr/doc/pgplot5
-#	fi
-ldconfig	
-fi
-# End automatically added section
-# Automatically added by dh_installmenu
-#if test -x /usr/bin/update-menus ; then update-menus ; fi
-# End automatically added section
-
-
diff -Nru pgplot5-5.2.2/debian/prerm pgplot5-5.2.2/debian/prerm
--- pgplot5-5.2.2/debian/prerm	2006-07-15 20:18:19.0 +0200
+++ pgplot5-5.2.2/debian/prerm	1970-01-01 01:00:00.0 +0100
@@ -1,10 +0,0 @@
-#!/bin/sh
-set -e
-
-#DEBHELPER#
-
-# Automatically added by dh_installdocs
-if [ \( "$1" = "upgrade" -o "$1" = "remove" \) -a -L /usr/doc/pgplot5 ]; then
-rm -f /usr/doc/pgplot5
-fi
-# End automatically added section
diff -Nru pgplot5-5.2.2/debian/rules pgplot5-5.2.2/debian/rules
--- pgplot5-5.2.2/debian/rules	2011-11-19 07:30:49.0 +0100
+++ pgplot5-5.2.2/debian/rules	2017-02-01 21:43:27.0 +0100
@@ -89,7 +89,7 @@
 install-stamp: build-stamp $(64-BIT_CLEAN_STAMP)
 	dh_testdir	
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 	$(INSTALL_DATA) $(bdir)/libpgplot.a  $(packagedir)/usr/lib/
 	$(INSTALL_DATA) $(bdir)/libcpgplot.a  $(packagedir)/usr/lib/
@@ -112,8 +112,6 @@
 	$(INSTALL_DATA) $(bdir)/grexec.f $(packagedir)/usr/lib/$(npackage)
 	$(INSTALL_DATA) $(bdir)/rgb.txt $(packagedir)/usr/lib/$(npackage)
 	$(INSTALL_DATA) $(bdir)/grpckg1.inc $(packagedir)/usr/lib/$(npackage)
-# Install the overrides file for lintian
-	cp -a debian/overrides $(packagedir)/usr/share/lintian/overrides/pgplot5
 
 	#dh_movefiles
 	touch install-stamp

Bug#854317: piuparts: adequate reports obsolete conffile for piuparts

[shirish शिरीष]

Package: piuparts
Version: 0.75
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

Dear Maintainer,
Adequate reports broken obsolete-conffile -

[$] adequate piuparts

piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental

Maybe you could use what pabs (Paul Wise) did in #815563, in that the
proper thing to do would be -

Use the dpkg-maintscript-helper support provided by dh_installdeb to
remove such similar obsolete conffiles on upgrade

Also https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

You can also see manpage of dh_installdeb vid debhelper package which
is the same thing.

I ran the same command as he did -

[$] pkg=piuparts ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n'
$pkg | grep obsolete

piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental
 /etc/piuparts/scripts/pre_remove_40_find_obsolete_conffiles
dce83ee504ba336d8a2930fb6053635c
 /etc/piuparts/scripts/post_setup_experimental
f7a1f3d45dc43106d1cd9b124b7c1ca8 obsolete

Please fix the above.

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

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

Versions of packages piuparts depends on:
ii  debootstrap  1.0.87
ii  debsums  2.2
ii  dpkg 1.18.18
ii  lsb-release  9.20161125
ii  lsof 4.89+dfsg-0.1
ii  piuparts-common  0.75
ii  python-debian0.1.30
pn  python:any   

Versions of packages piuparts recommends:
ii  adequate  0.15.1

Versions of packages piuparts suggests:
ii  schroot  1.6.10-3

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#854315: okular: Annotation data loss after closing, when same document was open two times

[Maria]

Package: okular
Version: 4:16.08.2-1
Severity: normal

Dear Maintainer,

when I am working with books I often need to have the same book open in two
different windows to look at the end notes in the second window.
Here often occurs a dataloss of annotations:

If I made annotations in the endnotes and in the main text, after closing both
windows, one of the annotations is lost. It is not possible to get them back,
as only the annotations of one of the windows is saved.

If I work only in one window and use the second just for reading, the data is
also lost, when accidentally closing the main text window with the annotations
first.

Saving as an *.okular archive has other negative sideeffects in my working
scheme, so thats not an option unluckily.

I would expect okular to to do either of these things:
* Regular Backup of the annotation files, to enable restoring manually
* synchronize the annotations of the two windows

Thanks alot for your great work!



-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages okular depends on:
ii  kde-runtime 4:16.08.3-1
ii  libc6   2.24-9
ii  libfreetype62.6.3-3+b1
ii  libjpeg62-turbo 1:1.5.1-2
ii  libkdecore5 4:4.14.26-1
ii  libkdeui5   4:4.14.26-1
ii  libkexiv2-114:15.04.3-1
ii  libkio5 4:4.14.26-1
ii  libkparts4  4:4.14.26-1
ii  libkprintutils4 4:4.14.26-1
ii  libkpty44:4.14.26-1
ii  libokularcore7  4:16.08.2-1
ii  libphonon4  4:4.9.0-4
ii  libpoppler-qt4-40.48.0-2
ii  libqca2 2.1.1-4
ii  libqimageblitz4 1:0.0.6-4
ii  libqmobipocket1 4:16.08.0-1
ii  libqt4-dbus 4:4.8.7+dfsg-11
ii  libqt4-declarative  4:4.8.7+dfsg-11
ii  libqt4-svg  4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libsolid4   4:4.14.26-1
ii  libspectre1 0.2.8-1
ii  libstdc++6  6.3.0-5
ii  phonon  4:4.9.0-4
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages okular recommends:
ii  cups-bsd  2.2.1-6

Versions of packages okular suggests:
ii  ghostscript9.20~dfsg-2
ii  jovie  4:16.08.0-1
ii  okular-extra-backends  4:16.08.2-1
ii  poppler-data   0.4.7-8
ii  texlive-binaries   2016.20160513.41080.dfsg-1
ii  unrar  1:5.3.2-1

-- no debconf information

Bug#665199: slapd: fails to install, remove, distupgrade, and install again

[Ryan Tandy]

Hi Niels,

On Sun, Feb 05, 2017 at 09:57:00AM +, Niels Thykier wrote:

Ping on this - we would like to see this fixed properly for stretch.


ACK. It's been around too long already.

Unfortunately, life being what it is, I may not have time to deliver a 
proper fix until late March. I will of course do my best to deal with it 
earlier than that.


Notes to aid others in triaging/working on this bug:

The failure reported is actually not reproducible without editing the 
source, because the database format did not change between jessie and 
stretch, while it did in all of the previous three releases.


However the original bug is still there, reproducible by updating 
database_format_changed() in debian/slapd.scripts-common.


For the jessie->stretch upgrade the same problem exists for the config 
database if the ppolicy overlay is active. To reproduce this:


- install slapd/jessie
- add the ppolicy schema
- add the ppolicy overlay to a database
- remove slapd
- install slapd/stretch

Currently there is a message like:

 Saved configuration not found at 
/var/backups/slapd-2.4.40+dfsg-1+deb8u2/cn=config.ldif. Skipping configuration 
updates.

and the new slapd fails to start since the config has not been updated.

(That's odd. I expected it to try to dump the config but fail because of 
slapcat not being there yet...)


The fix is the same for all cases: dump the databases in prerm, 
including the config database; but also be prepared to do it in preinst 
as well, so upgrading from an unfixed version is still possible.

Bug#854295: brltty-espeak: crashes while emitting speech

[Samuel Thibault]

Hello,

Could you install:

Sebastian Humenda, on Sun 05 Feb 2017 21:02:37 +0100, wrote:
> #1  0x5653f0d0437c in asyncExecuteIoCallback ()

brltty-dbgsym

> #0  0x7f3fec3c7540 in  () at /usr/lib/x86_64-linux-gnu/libasound.so.2

and libasound2-dbgsym

Samuel

Bug#826614: CONFIG_MAC_SCSI and CONFIG_MAC8390 are set to 'y'

[Finn Thain]

I checked the kernel builds in snapshot.debian.org, and all of the Linux 
builds that were archived since this bug report was opened 8 months ago 
still exhibit the same problem.

If the BTS is the wrong way to have this issue addressed, would someone 
please refer me to some instructions for bringing this sort of issue to 
the attention of the appropriate developers, i.e. someone willing to 
consider both the problem and the solution and then respond?

Thanks in advance.

Bug#854314: youtube-dl: 'Signature extraction failed' on some YouTube videos

[The Wanderer]

Package: youtube-dl
Version: 2016.12.01-1
Severity: normal

Dear Maintainer,

Today, in attempting to download videos from YouTube with youtube-dl, I
have seen some download normally and others produce errors.
(Unfortunately, this happened late enough that the release-freeze
announcement came in while I was testing it.)

Specifically, I have seen the following:

$ youtube-dl https://www.youtube.com/watch?v=4pbMUEHvoAo --verbose
[debug] System config: []
[debug] User config: ['-f', 'best']
[debug] Command-line args:
['https://www.youtube.com/watch?v=4pbMUEHvoAo', '--verbose']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.12.01
[debug] Python version 3.5.3 - Linux-4.8.0-2-amd64-x86_64-with-debian-9.0
[debug] exe versions: rtmpdump 2.4
[debug] Proxy map: {}
[youtube] 4pbMUEHvoAo: Downloading webpage
[youtube] 4pbMUEHvoAo: Downloading video info webpage
[youtube] 4pbMUEHvoAo: Extracting video information
[youtube] {43} signature length 42.43, html5 player en_US-vflkk7pUE
[youtube] 4pbMUEHvoAo: Downloading player
/yts/jsbin/player-en_US-vflkk7pUE/base.js
ERROR: Signature extraction failed: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 919, in _extract_signature_function
errnote='Download of %s failed' % player_url)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 517, in _download_webpage
res = self._download_webpage_handle(url_or_request, video_id, note,
errnote, fatal, encoding=encoding, data=data, headers=headers, query=query)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 424, in _download_webpage_handle
urlh = self._request_webpage(url_or_request, video_id, note,
errnote, fatal, data=data, headers=headers, query=query)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 404, in _request_webpage
return self._downloader.urlopen(url_or_request)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line
2000, in urlopen
req = sanitized_Request(req)
  File "/usr/lib/python3/dist-packages/youtube_dl/utils.py", line 513,
in sanitized_Request
return compat_urllib_request.Request(sanitize_url(url), *args, **kwargs)
  File "/usr/lib/python3.5/urllib/request.py", line 269, in __init__
self.full_url = url
  File "/usr/lib/python3.5/urllib/request.py", line 295, in full_url
self._parse()
  File "/usr/lib/python3.5/urllib/request.py", line 324, in _parse
raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: '/yts/jsbin/player-en_US-vflkk7pUE/base.js'
 (caused by ValueError("unknown url type:
'/yts/jsbin/player-en_US-vflkk7pUE/base.js'",)); please report this
issue on https://yt-dl.org/bug . Make sure you are using the latest
version; see  https://yt-dl.org/update  on how to update. Be sure to
call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 919, in _extract_signature_function
errnote='Download of %s failed' % player_url)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 517, in _download_webpage
res = self._download_webpage_handle(url_or_request, video_id, note,
errnote, fatal, encoding=encoding, data=data, headers=headers, query=query)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 424, in _download_webpage_handle
urlh = self._request_webpage(url_or_request, video_id, note,
errnote, fatal, data=data, headers=headers, query=query)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 404, in _request_webpage
return self._downloader.urlopen(url_or_request)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line
2000, in urlopen
req = sanitized_Request(req)
  File "/usr/lib/python3/dist-packages/youtube_dl/utils.py", line 513,
in sanitized_Request
return compat_urllib_request.Request(sanitize_url(url), *args, **kwargs)
  File "/usr/lib/python3.5/urllib/request.py", line 269, in __init__
self.full_url = url
  File "/usr/lib/python3.5/urllib/request.py", line 295, in full_url
self._parse()
  File "/usr/lib/python3.5/urllib/request.py", line 324, in _parse
raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: '/yts/jsbin/player-en_US-vflkk7pUE/base.js'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",

Bug#852846: forensics-all: Depends on conflicting packages: crack vs crack-md5

[Eriberto Mota]

2017-01-27 17:36 GMT-02:00 Axel Beckert :
> Package: forensics-all
> Version: 1.5
> Severity: important
>
> Dear Debian Forensics Metapackages Maintainers,
>
> forensics-all depends on both, crack and crack-md5. But crack and
> crack-md5 conflict with each other.
>
> forensics-all is though still installable, but only because crack-md5
> also "Provides: crack". (Hence not "Severity: serious".) But once
> crack-md5 decides to drop that Provides, forensics-all will become
> uninstallable.
>
> So please change the dependency on "crack, crack-md5" to "crack |
> crack-md5". IMHO that's the only variant which makes sense.


Hi Axel,

Thanks a lot for your message. I will wait for Stretch release and fix
this issue.

Cheers,

Eriberto

Bug#642021: closing #642021 since gpg-agent is using the standard socket now

[Daniel Kahn Gillmor]

Version: 2.1.0-1

Since GnuPG on the 2.1.x branch uses the "standard socket" location, i
think #642021 is no longer relevant.  I'm closing this bug report, but
feel free to reopen (or open a new one) if you think it's still a
concern.

Bug#851819: Fail on installation

[Charles Samborski]

Hi,
I also encountered the same error:

```
Setting up flashplugin-nonfree (1:3.7) ...
ERROR: wget failed to download 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.24.0.0.194.sha512.amd64.pgp.asc

More information might be available at:
  http://wiki.debian.org/FlashPlayer
```

It broke my test environment so I reverted to an older version in the 
meantime, but it took some time to locate the issue.


What bothers me the most is that it prints an error message to the 
standard output but the installation continues as if it worked instead 
of failing. The exit code is 0! Would it be possible to fix the handling 
of failures to be more explicit ?

Bug#854313: bleygraph needs python-matplotlib, cannot handle dbconfig-common.conf

[Sascha Silbe]

Package: bley
Version: 2.0.0-2
Severity: normal

Dear Maintainer,

tried to run bleygraph; ran into two issues:

1. bleygraph needs python-matplotlib, but the bley package doesn't
   depend on (or even just suggest) it:

   sascha@outpost:~$ sudo -u bley bleygraph -d /tmp/bley
   Traceback (most recent call last):
 File "/usr/bin/bleygraph", line 92, in 
   import matplotlib
   ImportError: No module named matplotlib

2. bleygraph apparently doesn't cope with the database config being
   split out to dbconfig-common.conf. Depending on how it's invoked,
   it either uses the (incorrect) database configuration from
   bley.conf or chokes trying to parse dbconfig-common.conf:

   sascha@outpost:~$ sudo -u bley bleygraph -d /tmp/bley
   Traceback (most recent call last):
 File "/usr/bin/bleygraph", line 103, in 
   db = database.connect(**dbsettings)
   sqlite3.OperationalError: unable to open database file

   sascha@outpost:~$ sudo -u bley bleygraph -d /tmp/bley -c /etc/bley/bley.conf 
-c /etc/bley/dbconfig-common.conf
   Traceback (most recent call last):
 File "/usr/bin/bleygraph", line 97, in 
   dnswl_threshold  = config.getint('bley', 'dnswl_threshold')
 File "/usr/lib/python2.7/ConfigParser.py", line 359, in getint
   return self._get(section, int, option)
 File "/usr/lib/python2.7/ConfigParser.py", line 356, in _get
   return conv(self.get(section, option))
 File "/usr/lib/python2.7/ConfigParser.py", line 618, in get
   raise NoOptionError(option, section)
   ConfigParser.NoOptionError: No option 'dnswl_threshold' in section: 'bley'

   sascha@outpost:~$ sudo -u bley bleygraph -d /tmp/bley -c 
/etc/bley/dbconfig-common.conf -c /etc/bley/bley.conf 
   Traceback (most recent call last):
 File "/usr/bin/bleygraph", line 103, in 
   db = database.connect(**dbsettings)
   sqlite3.OperationalError: unable to open database file

   sascha@outpost:~$ sudo -u bley ls -l /var/lib/bley 
   total 736
   -rw-r- 1 bley bley 749568 Feb  5 23:32 bley
   -rw-r--r-- 1 bley bley  0 Feb  5 23:38 bley.db

   After modifying bley.conf to match dbconfig-common.conf and
   changing to the database directory first (it apparently ignores
   the dbpath setting), I finally got bleygraph to work:

   sascha@outpost:~$ sudo -u bley sh -c 'cd /var/lib/bley && bleygraph -d 
/tmp/bley -c /etc/bley/bley.conf '
   plotting 12h:
- /tmp/bley/ar-12h.png
- /tmp/bley/ch-12h.png
   plotting 24h:
- /tmp/bley/ar-24h.png
- /tmp/bley/ch-24h.png
   plotting 7d:
- /tmp/bley/ar-7d.png
- /tmp/bley/ch-7d.png
   plotting 28d:
- /tmp/bley/ar-28d.png
- /tmp/bley/ch-28d.png
   plotting 365d:
- /tmp/bley/ar-365d.png
- /tmp/bley/ch-365d.png
   

Sascha

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (100, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#853926: cloud-init depends on net-base

[Adam Bolte]

On Sun, Feb 05, 2017 at 08:56:58PM +0100, Thomas Goirand wrote:
> On 02/03/2017 04:15 AM, Adam Bolte wrote:
> > On closer inspection, the error from netstat is different. I missed
> > the "Reason: [Errno 2] No such file or directory: 'netstat'" line from
> > the original report, so I'm seeing a different bug.
> > 
> > If the netstat command isn't doing anything critical (as implied by
> > cloud-init otherwise working just fine without it), perhaps references
> > to it can simply be removed from cloud-init to address both problems?
> > Otherwise, I guess I'll open a new bug report.
> 
> Considering what you just wrote, you don't even know if you are
> experiencing a bug or otherwise. In such case, please investigate before
> reporting.

It was easy to overlook that these are not the same issue because of
the exact same command in cloud-init failing, because I didn't have
"net-base" installed (because the original reporter got the package
name wrong) and because I experienced the issue around the same time
the bug was opened. For that mistake, I apologize.

In what possible way would such an error not be a bug? Can you clarify
what you mean with an example? Surely even if netstat is being called
before the interface is ready (which is the only other possibility I
can imagine causing this right now), shouldn't that be an expected
possibility by the code and handled gracefully.


signature.asc
Description: Digital signature

Bug#854312: ITP: basenji -- #838224

[Canberk Koç]

Package: wnpp
Owner: Canberk Koç 
Severity: wishlist
*  Package name: basenji
  Version : 1.0.2
  Upstream Author : Patrick Ulbrich 
 * URL : https://github.com/pulb/basenji
 * License : GPL-3+
  Programming Lang: C#
  Description : Cross-platform media indexing/search tool
 Basenji is an indexing and search tool designed for easy and fast indexing
 of media collections. Once indexed, removable media such as CDs and
 USB sticks can be browsed and searched for specific files very quickly,
 without actually being connected to the computer. Besides file hierarchies
 and audio track listings, Basenji also presents extracted metadata
 (image dimensions, mp3 tags etc.) and content previews of indexed media in
a
 clean and straightforward user interface.

Bug#811576: tpm-tools: diff for NMU version 1.3.9-0.1

[John Paul Adrian Glaubitz]

Hi Sebastian!

On 02/05/2017 11:32 PM, Sebastian Andrzej Siewior wrote:
> I've prepared an NMU for tpm-tools (versioned as 1.3.9-0.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Thanks a lot for your patch to address these two bugs!

However, I'm afraid your patch currently has no chance to get merged into
the Debian package as it involves too many changes and will therefore
rejected by the release team for Debian Stretch.

Also, your patch contains unrelated changes to the formatting like:

@@ -421,23 +394,23 @@
 # MiNT.  But MiNT is downward compatible to TOS, so this should
 # be no problem.
 atarist[e]:*MiNT:*:* | atarist[e]:*mint:*:* | atarist[e]:*TOS:*:*)
-   echo m68k-atari-mint${UNAME_RELEASE}
+echo m68k-atari-mint${UNAME_RELEASE}
exit ;;
 atari*:*MiNT:*:* | atari*:*mint:*:* | atarist[e]:*TOS:*:*)
echo m68k-atari-mint${UNAME_RELEASE}
-   exit ;;
+exit ;;

These changes should be removed, so that your patch contains actual
functional changes only. I also recommend splitting your patch up
into smaller, logical chunks.

If upstream is dead, I'd suggest put your changes in a repo on github
and point the Homepage field of the Debian package to that repo.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#852639: [Pkg-tigervnc-devel] Bug#852639: Bug#852639: tigervnc-standalone-server: mouse pointer stuck in upper left corner

[Joachim Falk]

Hi Ola,

Am 05.02.2017 um 22:39 schrieb Ola Lundqvist:
> Hi
> 
|| For context:
>> So, it seems to be a regression with the combination of Xorg 1.19 in stretch
>> and the VNC patch to it. Ola, where did you get this patch? If I remember
>> correctly, Xorg 1.19 is not officially supported for TigerVNC 1.7.
> I think it was from this source:
> https://lists.x.org/archives/xorg-devel/2016-October/051482.html
I have just checked. We have the same patch as is provided by
tigervnc master. We also seem to apply all patches from tigervnc
master intending to get Xorg 1.19 going. Next, one should check
if this is also a regression with tigervnc master concerning
buggy remote cursor support with the Xorg 1.19 server.

Regards,
Joachim Falk



signature.asc
Description: OpenPGP digital signature

Bug#851927: Cannot upgrade Signal

[Jean-Francois Pirus]

As well as blocking extensions, the package now also silently block 
updates, see bug 841401 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841401


I have given up on chromium, while I appreciate the work of the 
maintainers, the silently and arbitrary breaking of functionality on 
purpose make this package unusable.

Bug#854258: firefox-esr: firefox crashes every few seconds or minutes with a crash handler dialog since last update

[Pierre Ynard]

I would like to confirm the issue. The only plugin I installed is flash,
and it's disabled by default and wasn't active during the crashes.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Bug#854311: unblock: lcmaps-plugins-jobrep/1.5.3-4

[Dennis van Dok]

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

Please unblock package lcmaps-plugins-jobrep

Package no longer FTBFS with the introduction of OpenSSL 1.1.


diff -Nru lcmaps-plugins-jobrep-1.5.3/debian/changelog 
lcmaps-plugins-jobrep-1.5.3/debian/changelog
--- lcmaps-plugins-jobrep-1.5.3/debian/changelog2016-12-19 
12:12:50.0 +0100
+++ lcmaps-plugins-jobrep-1.5.3/debian/changelog2017-01-27 
12:33:38.0 +0100
@@ -1,3 +1,9 @@
+lcmaps-plugins-jobrep (1.5.3-4) unstable; urgency=medium
+
+  * Update to build against OpenSSL 1.1
+
+ -- Dennis van Dok   Fri, 27 Jan 2017 12:33:38 +0100
+
 lcmaps-plugins-jobrep (1.5.3-3) unstable; urgency=medium
 
   * Update dependency of lcmaps-plugins-jobrep-admin to
diff -Nru lcmaps-plugins-jobrep-1.5.3/debian/control 
lcmaps-plugins-jobrep-1.5.3/debian/control
--- lcmaps-plugins-jobrep-1.5.3/debian/control  2016-12-19 12:11:24.0 
+0100
+++ lcmaps-plugins-jobrep-1.5.3/debian/control  2017-01-27 12:33:38.0 
+0100
@@ -5,7 +5,7 @@
 Uploaders: Mischa Salle 
 Build-Depends: cdbs, debhelper (>= 7.0.50~), dh-autoreconf, autotools-dev,
  lcmaps-basic-interface, unixodbc-dev, libssl-dev, pkg-config
-Standards-Version: 3.9.5
+Standards-Version: 3.9.8
 Homepage: https://wiki.nikhef.nl/grid/LCMAPS
 Vcs-Svn: 
https://ndpfsvn.nikhef.nl/repos/mwsec/packaging/debian/trunk/lcmaps-plugins-jobrep
 Vcs-Browser: 
http://ndpfsvn.nikhef.nl/viewvc/mwsec/packaging/debian/trunk/lcmaps-plugins-jobrep
diff -Nru lcmaps-plugins-jobrep-1.5.3/debian/patches/openssl1.1.patch 
lcmaps-plugins-jobrep-1.5.3/debian/patches/openssl1.1.patch
--- lcmaps-plugins-jobrep-1.5.3/debian/patches/openssl1.1.patch 1970-01-01 
01:00:00.0 +0100
+++ lcmaps-plugins-jobrep-1.5.3/debian/patches/openssl1.1.patch 2017-01-27 
12:33:38.0 +0100
@@ -0,0 +1,111 @@
+From: Micha Sallé 
+Subject: Fixes for compatibility with OpenSSL 1.1
+
+--- a/src/jobrep/jobrep_data_handling.c
 b/src/jobrep/jobrep_data_handling.c
+@@ -1134,7 +1134,7 @@
+ char*subject_DN = NULL, *issuer_DN = NULL, *not_before_str = NULL, 
*not_after_str = NULL;
+ time_t   not_before = 0, not_after = 0;
+ X509*cert = NULL;
+-unsigned char *serialnr = NULL;
++char *serialnr = NULL;
+ 
+ if ((db_handle == NULL) || (px509_chain == NULL)) {
+ return -1;
+@@ -1231,27 +1231,25 @@
+ return -1;
+ }
+ 
+-unsigned char *
++char *
+ jobrep_get_serialnumber_as_string(X509 *cert) {
+-ASN1_INTEGER   *cert_Serial = NULL;
+-unsigned char  *serialNumberDER = NULL, *temp = NULL, *serialStr = NULL;
++ASN1_INTEGER   *serial = NULL;
+ char   *subject_DN = NULL;
+-size_t  len;
+-int j,serialLen;
++BIGNUM *bn_serial;
++char   *serialStr = NULL;
+ 
+ if (cert == NULL)
+ return NULL;
+ 
+-cert_Serial = X509_get_serialNumber(cert);
+-if (cert_Serial == NULL) {
++if ( (serial = X509_get_serialNumber(cert)) == NULL) {
+ /* For debugging purposes extract the Subject DN */
+ subject_DN = X509_NAME_oneline(X509_get_subject_name(cert),NULL,0);
+ if (subject_DN) {
+-lcmaps_log(LOG_DEBUG, "%s: certificate passed with subject DN 
\"%s\" didn't contain a serial number.\n",
++lcmaps_log(LOG_WARNING, "%s: certificate passed with subject DN 
\"%s\" didn't contain a serial number.\n",
+__func__, subject_DN);
+ free(subject_DN);
+ } else {
+-lcmaps_log(LOG_DEBUG, "%s: certificate passed doesn't have a 
serialnumber and also lacks a subject DN. " \
++lcmaps_log(LOG_WARNING, "%s: certificate passed doesn't have a 
serialnumber and also lacks a subject DN. " \
+   "This is completely weird and doesn't even 
look like a certificate. " \
+   "Are you a waiter because you seem to be 
feeding me soup?\n",
+   __func__);
+@@ -1259,44 +1257,15 @@
+ return NULL;
+ }
+ 
+-serialLen = i2c_ASN1_INTEGER(cert_Serial, NULL);
+-if (serialLen <= 0) {
+-lcmaps_log(LOG_INFO, "%s: Conversion of a certificate serial number 
from ASN1_INTEGER to DER failed\n",
+- __func__);
+-return NULL;
+-}
+-
+-/* Note: serialLen is int and >0 */
+-temp = serialNumberDER = malloc((size_t)serialLen);
+-if (serialNumberDER == NULL) {
+-lcmaps_log(LOG_DEBUG, "%s: Could not allocate %d bytes\n", serialLen);
+-return NULL;
+-}
+-/* Warning, the temp variable will be displaced, use the serialNumberDER 
instead. */
+-serialLen = i2c_ASN1_INTEGER(cert_Serial, );
+-
+-/* Allocate as a Hex decimal + null-terminator */
+-len = (size_t)serialLen * 2 + 1;
+-serialStr = malloc(len);
+-if (serialStr == NULL) {
+- 

Bug#854310: RFP: libprotocol-http2-client-perl -- Protocol::HTTP2::Client - HTTP/2 client module for perl

[Stefan Fritsch]

Package: wnpp
Severity: wishlist

* Package name: libprotocol-http2-client-perl
  Version : 1.08
  Upstream Author : Vladimir Lettiev  
* URL : https://metacpan.org/pod/Protocol::HTTP2::Client
* License : perl_5
  Programming Lang: perl
  Description : Protocol::HTTP2::Client - HTTP/2 client module for perl


Protocol::HTTP2::Client is HTTP/2 client library. It's intended to make
http2-client implementations on top of your favorite event-loop.


Some tests in the test suite of Apache HTTPD (apache2 package) require
this module. It would be nice if one could install it with apt-get. And
it sounds like a useful module for other programs, too. I don't have the
time to maintain it myself, though.

Bug#820818: partman is not able to resize nvme0n1p3 in d-i

[Ben Hutchings]

On Sat, 2017-02-04 at 05:12 +0100, Cyril Brulebois wrote:
> > Cyril Brulebois  (2017-02-04):
> > It would be helpful if you could dig up the logs to confirm you had the
> > "get_real_device: strange device name $bdev" line.
> 
> This is still welcome but probably not necessary given other bits of
> your bug report. I've just pushed a totally untested patch to the
> pu/resize-nvme-820818 branch:
>   
> https://anonscm.debian.org/cgit/d-i/partman-partitioning.git/commit/?h=pu/resize-nvme-820818=348a501524e7a2cdd3e04d5ec1c9f9d2aead3743

Please don't do this.  The rule for Linux partition device names is
very simple and there is no need to match specific prefixes:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/block/partition-generic.c?h=v4.9#n35

Please instead use the following patch:

--- a/lib/resize.sh
+++ b/lib/resize.sh
@@ -18,15 +18,12 @@ get_real_device () {
num=$(sed 's/^[^0-9]*\([0-9]*\)[^0-9].*/\1/' 
$backupdev/$oldid/view)
bdev=$(cat $backupdev/device)
case $bdev in
-   */disc)
-   bdev=${bdev%/disc}/part$num
+   /dev/*[0-9])
+   bdev=${bdev}p$num
;;
-   /dev/[hsv]d[a-z]|/dev/xvd[a-z])
+   /dev/*)
bdev=$bdev$num
;;
-   
/dev/cciss/c[0-9]d[0-9]|/dev/cciss/c[0-9]d[0-9][0-9]|/dev/ida/c[0-9]d[0-9]|/dev/ida/c[0-9]d[0-9][0-9]|/dev/mmcblk[0-9])
-   bdev=${bdev}p$num
-   ;;
*)
log "get_real_device: strange device name $bdev"
return
--- END ---

Ben.

> Would you be interested in testing an image with such an update?
> 
> 
> KiBi.
-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai
Stevenson



signature.asc
Description: Digital signature

Bug#852908: mako: FTBFS: Test failures

[Piotr Ożarowski]

> The failure is caused by the recent upload of pygments 2.2.0. With this new
> release the 'u' prefix is omitted from the rendered utf8 strings, as in:
>  
> while pygments 2.1.3 gives:
>  u

hmmm... that's weird as my first thought was it was due to new pygnents
so I tested it with old one and it failed as well... I probably messed
it somehow. Thanks for the patch!

Bug#854308: compass-h5bp-plugin: unusable with compass: undefined local variable or method `base_directory'

[Jonas Smedegaard]

Package: compass-h5bp-plugin
Version: 1.0.0-3
Severity: important

Recent changes to patch 2001 broke use with compass.

Points to wrong path for sass content on first line of patched file.

Additionally uses wrong logic to register the path with compass.

Bug#854309: unblock: lcas-lcmaps-gt4-interface/0.3.0-3

[Dennis van Dok]

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

Please unblock package lcas-lcmaps-gt4-interface

The package no longer FTBFS with the fixing of #828374.

diff -Nru lcas-lcmaps-gt4-interface-0.3.0/debian/changelog 
lcas-lcmaps-gt4-interface-0.3.0/debian/changelog
--- lcas-lcmaps-gt4-interface-0.3.0/debian/changelog2014-01-20 
16:02:08.0 +0100
+++ lcas-lcmaps-gt4-interface-0.3.0/debian/changelog2017-01-27 
14:01:07.0 +0100
@@ -1,3 +1,9 @@
+lcas-lcmaps-gt4-interface (0.3.0-3) unstable; urgency=medium
+
+  * Fix for OpenSSL 1.1 compatibility. (Closes: 828374)
+
+ -- Dennis van Dok   Fri, 27 Jan 2017 14:01:07 +0100
+
 lcas-lcmaps-gt4-interface (0.3.0-2) unstable; urgency=low
 
   [ Logan Rosen ]
diff -Nru lcas-lcmaps-gt4-interface-0.3.0/debian/control 
lcas-lcmaps-gt4-interface-0.3.0/debian/control
--- lcas-lcmaps-gt4-interface-0.3.0/debian/control  2014-01-14 
16:33:10.0 +0100
+++ lcas-lcmaps-gt4-interface-0.3.0/debian/control  2017-01-27 
13:57:11.0 +0100
@@ -6,7 +6,7 @@
  lcmaps-globus-interface, lcas-interface,
  libglobus-gridmap-callout-error-dev,
  pkg-config
-Standards-Version: 3.9.5
+Standards-Version: 3.9.8
 Section: libs
 Homepage:  https://wiki.nikhef.nl/grid/Site_Access_Control
 Vcs-Svn: 
https://ndpfsvn.nikhef.nl/repos/mwsec/packaging/debian/trunk/lcas-lcmaps-gt4-interface
diff -Nru lcas-lcmaps-gt4-interface-0.3.0/debian/patches/openssl1.1.patch 
lcas-lcmaps-gt4-interface-0.3.0/debian/patches/openssl1.1.patch
--- lcas-lcmaps-gt4-interface-0.3.0/debian/patches/openssl1.1.patch 
1970-01-01 01:00:00.0 +0100
+++ lcas-lcmaps-gt4-interface-0.3.0/debian/patches/openssl1.1.patch 
2017-01-27 14:01:07.0 +0100
@@ -0,0 +1,25 @@
+From: Micha Sallé 
+Subject: Fix for compatibility with OpenSSL 1.1
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828374
+--- a/src/llgt_globus_internal.h
 b/src/llgt_globus_internal.h
+@@ -83,6 +83,19 @@
+ OM_uint32   req_flags;
+ OM_uint32   ctx_flags;
+ int cred_obtained;
++#if OPENSSL_VERSION_NUMBER >= 0x1100L
++/** For GCM ciphers, sequence number of next read MAC token */
++uint64_tmac_read_sequence;
++/** For GCM ciphers, sequence number of next write MAC token */
++uint64_tmac_write_sequence;
++/** For GCM ciphers, key for MAC token generation/validation */
++unsigned char * mac_key;
++/**
++ * For GCM ciphers, fixed part of the IV for MAC token
++ * generation/validation
++ */
++unsigned char * mac_iv_fixed;
++#endif
+ SSL *   gss_ssl; 
+ BIO *   gss_rbio;
+ BIO *   gss_wbio;
diff -Nru lcas-lcmaps-gt4-interface-0.3.0/debian/patches/series 
lcas-lcmaps-gt4-interface-0.3.0/debian/patches/series
--- lcas-lcmaps-gt4-interface-0.3.0/debian/patches/series   2014-01-14 
13:40:21.0 +0100
+++ lcas-lcmaps-gt4-interface-0.3.0/debian/patches/series   2017-01-27 
13:54:02.0 +0100
@@ -1,2 +1,3 @@
 setup-plugin-subdir.patch
 setup-no-flavor.patch
+openssl1.1.patch


unblock lcas-lcmaps-gt4-interface/0.3.0-3

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-dvdrt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[Daniel Kahn Gillmor]

On Sun 2017-02-05 06:20:38 -0500, Wouter Verhelst wrote:
> I concur; the workaround is relatively easy (choose one option, where
> "CCID" is probably the most common and certainly the most tested by
> the developers themselves, and disable the other method), and after
> that the problem is gone.

To be concrete, i believe the two proposed solutions for users are:

Do not use PCSC
---

Either system-wide:
   
apt purge pcscd

or per-user:

echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon
 
Do not use CCID
---

echo disable-ccid:0:1 | gpgconf --change-options scdaemon

> However, the gnupg package maintainers might want to think about how
> to best document this issue.

aiui, CCID is the preferred method for scdaemon to access smartcards.

Would it make sense instead to just change the defaults for pcsc-driver
to be the empty string?

In that case, people who have pcsc-specific devices (that won't be
available via ccid directly) would do:

printf 'pcsc-driver:0:"libpcsclite.so.1\n' | gpgconf --change-options 
scdaemon

(this enables both pcsc and ccid, returning to the current default)

And the people who need to use devices that can be used via both
mechanisms (and therefore need to disable ccid) can instead do:

printf 'pcsc-driver:0:"libpcsclite.so.1\ndisable-ccid:0:1\n' | gpgconf 
--change-options scdaemon

(this enables pcsc and disables ccid)

gniibe, what do you think of this proposed change to the defaults?

--dkg


signature.asc
Description: PGP signature

Bug#854306: mirror listing update for debian.redlibre.cl

[Pablo Umanzor]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debian.redlibre.cl
Type: leaf
Archive-architecture: amd64 i386 
Archive-http: /debian/
IPv6: no
Archive-upstream: mirrors.kernel.org
Updates: four
Maintainer: Pablo Umanzor 
Country: CL Chile
Location: Santiago - Las Condes

Bug#852756: gnome-logs crashes after starting

[Emilio Pozuelo Monfort]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=776818

On 04/02/17 19:02, Emilio Pozuelo Monfort wrote:
> Control: severity -1 serious
> 
> On 27/01/17 02:00, Marc Bonnor wrote:
>> The program starts but no log contents are visible.
>>
>> Then after selecting any menu picks with the mouse the program crashes.
> 
> I can reproduce this.
> 
> This may be related to the fact that I am not in the systemd-journal group, 
> and
> thus I can't access journals directly. Since that is the default configuration
> (afaik), I think this should be RC.
> 
> gnome-logs shouldn't crash if it can't access the logs due to permissions.

So this happens if gnome-logs can't access any journal. So if you don't have the
right permissions to access the system journal, and persistent logging isn't set
up, then you're out of luck and gnome-logs crashes.

That's fixed now. gnome-logs shouldn't crash in that situation anymore.

Emilio

Bug#854307: mirror submission for debian.redlibre.cl

[Pablo Umanzor]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.redlibre.cl
Type: leaf
Archive-architecture: amd64 i386 
Archive-http: /debian/
IPv6: no
Archive-upstream: mirrors.kernel.org
Updates: four
Maintainer: Pablo Umanzor 
Country: CL Chile
Location: Santiago - Las Condes

Bug#854234:

[cc . carlchen]

Hi, 

thanks for answer me. 

No, I have tried a upgrade from my last Debian 8 Jessie stable to Debian 9 
Stretch testing. The upgrade works fine, I think. But in the next few days, I 
will do a clean fresh install of Debian 9 Stretch to my new computer. I have 
purged SABnzbdplus and have did a new install. But this error nothing solved. 

No, I did not use my own ssl certificates. I use these what SAB is doing for me 
on the installation. 

The ssl certificate begins at 18.12.2016 and it ends at 16.12.2026. This shows 
my firefox in the certificates section. 

--

carlchen@carlchen-rechner:~$ ls -la ~/.sabnzbd/admin/*.{key,cert}
-rw-r--r-- 1 carlchen carlchen 631 Dez 18 15:39 
/home/carlchen/.sabnzbd/admin/server.cert
-rw-r--r-- 1 carlchen carlchen 912 Dez 18 15:39 
/home/carlchen/.sabnzbd/admin/server.key

--

Hope these help you a bit?

Bug#852639: [Pkg-tigervnc-devel] Bug#852639: Bug#852639: tigervnc-standalone-server: mouse pointer stuck in upper left corner

[Ola Lundqvist]

Hi

I think it was from this source:
https://lists.x.org/archives/xorg-devel/2016-October/051482.html

// Ola

On 5 February 2017 at 15:56, Joachim Falk  wrote:
> Hi all,
>
> Am 04.02.2017 um 20:42 schrieb Aaro Koskinen:
>> Hi,
>>
>> On Sat, Feb 04, 2017 at 03:31:27PM +0100, Joachim Falk wrote:
>>> I have investigated this some more. I assume you used the code from
>>> https://github.com/zohead/fbvnc for fbvnc.
>>
>> Yes, with some local fixes.
>>
>>> With this code, I can reproduce the bug. I assume the problem is that fbvnc
>>> does not support a vncviewer local cursor and Xtigervnc needs local cursor
>>> handling by the VNC client application. I do not know if this is a 
>>> regression
>>> in Xtigervnc.
>>
>> I don't think RFB 3.3 clients need to implement any local cursor support.
> I also don't think so. Moreover, it does work for the TigerVNC backport
> to debian jessie.
>
>  Am 04.02.2017 um 21:05 schrieb Joachim Falk: ===
> Hi all,
>
> Am 09.01.2017 um 17:50 schrieb Joachim Falk:
>> Hi all,
>>
>> Am 09.01.2017 um 16:33 schrieb Yaroslav Halchenko:
>>>
>>> On Sat, 07 Jan 2017, Ola Lundqvist wrote:
>>>
 Hi all TigerVNC maintainers
>>>
 I just want you to know that I have now uploaded a vnc4 and tightvnc
 source package that are just transitional packages to tigervnc.
>>>
 So now there is no going back.
>>>
>>> Linus bless us all!  thank you Ola.  That is a pity that we don't have
>>> an easy backport of tigervnc for e.g. jessie ATM -- I can't really give
>>> it a "real life" testing since most of the servers I am using VNC on run
>>> on debian stable
>> I might take a look at a backport.
> I just finished the backport to jessie.
>
> Am 30.01.2017 um 03:45 schrieb Martin Dorey:
>>
>> Sorry to make such a meal of such a trivial nugget, but I want to convey how 
>> little I understand.
>> Now, if you'll excuse me, I'm off to try to similarly brutalize the old 
>> Jessie packaging of tigervnc 1.6.0,
>> if I still have it lying around, to see if I can get back in to :0 on the 
>> server that I actually care about...
> Maybe try the backport
>
> I have mirrored my debs to https://xamane.jfalk.de/dists/homebrew-jessie
>
> Regards,
> Joachim Falk
> =
>
> So, it seems to be a regression with the combination of Xorg 1.19 in stretch
> and the VNC patch to it. Ola, where did you get this patch? If I remember
> correctly, Xorg 1.19 is not officially supported for TigerVNC 1.7.
>
>> What's interesting that server is chaging/drawing the cursor shape properly
>> e.g. when moving the mouse over uxterm or doing other actions, it's just that
>> the location is frozen.
>>
 This works fine with tightvnc on both arm64 and armhf using older Debian
 rootfs. But unfortunately that does not seem to be an option anymore.
>>> However, I can not even get this working with tightvncserver under stretch.
>>> Here the connection from fbvnc gets a garbled image from the Xtightvnc 
>>> server.
> Maybe you can post the changes to fbvnc somewhere, so that we test with the 
> same code?
>
>> I have it working fine.
>>
>> A.
>>
>
> Regards,
> Joachim Falk
>
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel

Bug#789275: [pkg-gnupg-maint] Bug#789275: gnupg2: [INTL:nl] Dutch po file for the gnupg2 package

[Daniel Kahn Gillmor]

On Fri 2015-06-19 08:54:54 -0400, Frans Spiesschaert wrote:
> Please find attached the Dutch po file for the gnupg2 package. 
> It has been submitted for review to the debian-l10n-dutch mailing list. 
> Please add it to your next package revision. 
> It should be put as "po/nl.po" in your package build tree. 

This was adopted upstream last year, but somehow didn't make it into the
2.1.x branch.  I've just pushed it upstream, so some variant of it
should ship by 2.1.19 at the latest.

Thanks for your contributions!

sorry for the delay,

   --dkg


signature.asc
Description: PGP signature

Bug#854304: compass-slickmap-plugin: breaks compass: unknown regexp options - har (SyntaxError)

[Jonas Smedegaard]

Package: compass-slickmap-plugin
Version: 0.5.1.1-4
Severity: important

The recently added patch 2001 had a syntax error - missing quotes around
path string.

This causes Compass to throw this error:

/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': 
/usr/lib/ruby/vendor_ruby/compass-slickmap.rb:1: unknown regexp options - har 
(SyntaxError)
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/compass/frameworks.rb:161:in `block in 
discover_gem_extensions!'
from /usr/lib/ruby/vendor_ruby/compass/frameworks.rb:159:in `each'
from /usr/lib/ruby/vendor_ruby/compass/frameworks.rb:159:in 
`discover_gem_extensions!'
from /usr/lib/ruby/vendor_ruby/compass/frameworks.rb:180:in 
`discover_extensions!'
from /usr/lib/ruby/vendor_ruby/compass/commands.rb:14:in `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/compass/exec.rb:7:in `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/bin/compass:21:in `block in '
from /usr/bin/compass:8:in `fallback_load_path'
from /usr/bin/compass:19:in `'

Fix is to add singlequotes around the path on first line of the patched
file.

 - Jonas

Bug#854305: mirror listing update for debian.redlibre.cl

[Pablo Umanzor]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debian.redlibre.cl
Type: leaf
Archive-architecture: amd64 i386 
Archive-http: /debian/
IPv6: no
Archive-upstream: mirrors.kernel.org
Updates: four
Maintainer: Pablo Umanzor 
Country: CL Chile
Location: Santiago - Las Condes

Bug#834922: [PATCH] g10: Skip signing keys where no secret key is available.

[Daniel Kahn Gillmor]

From: Simon Arlott 

* g10/getkey.c (finish_lookup): When requiring PUBKEY_USAGE_SIG, skip
over keys where no signing key is available.

--

This should only be relevant when gpg is required to choose which key
to sign with -- if verifying signatures, we already know which subkey
to look at, and indeed gpg doesn't seem to have a problem with this.

This patch comes from
https://bugs.gnupg.org/gnupg/file793/sign-fix.patch

I (dkg) have reviewed and tested it with missing local keys, and it
makes sense to me as the default behavior.  If the user has the secret
key for a signing-capable subkey available and the command is --sign,
it should be used.

If the user has explicitly specified a subkey that happens to be
missing (e.g. with the trailing ! for --default-key 0x${FPR}!) then
this does not override that behavior (the signature will still fail).

GnuPG-bug-id: 1967
Debian-bug-id: 834922

Signed-off-by: Daniel Kahn Gillmor 
---
 g10/getkey.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/g10/getkey.c b/g10/getkey.c
index e39de28ae..d2349ee6c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -3523,6 +3523,13 @@ finish_lookup (kbnode_t keyblock, unsigned int 
req_usage, int want_exact,
  continue;
}
 
+ if ((req_usage & PUBKEY_USAGE_SIG) && agent_probe_secret_key (NULL, 
pk))
+   {
+ if (DBG_LOOKUP)
+   log_debug ("\tno secret key for signing\n");
+ continue;
+   }
+
  if (DBG_LOOKUP)
log_debug ("\tsubkey might be fine\n");
  /* In case a key has a timestamp of 0 set, we make sure
-- 
2.11.0

Bug#854303: burp: Incompatibility between v1.3.48 client and v2.0.54 server

[Antoine Sirinelli]

Package: burp
Version: 2.0.54-1
Severity: important

Hi,

Burp package shipped with testing (and soon Stretch) cannot work as a client
connecting to a server running Debian stable (Jessie). On a machine running
Debian testing, since the burp package has been updated to v2.0.54, I cannot
perform my backups anymore on a Debian jessie server running burp v1.3.48. This
has been confirmed on the burp-users mailing list [1].

I believe this is going to be an issue in the migration between Jessie and
Stretch and this should be noted somewhere in the release notes.

Antoine

[1]: 
https://sourceforge.net/p/burp/mailman/burp-users/thread/20170205204625.gq22...@mail.ziirish.info/

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

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

Versions of packages burp depends on:
ii  libacl1  2.2.52-3
ii  libc62.24-9
ii  libncurses5  6.0+20161126-1
ii  librsync10.9.7-10
ii  libssl1.11.1.0c-2
ii  libtinfo56.0+20161126-1
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages burp recommends:
ii  openssl  1.1.0c-2

burp suggests no packages.

Bug#853935: rephrase: No more works with gpg2 and causes one pinentry popup per guess

[Eriberto Mota]

Hi guys,

Axel, thanks a lot for your patch. I have a special interest over this
bug because it will affect forensics-all and forensics-full packages.

Tiago, I did a Team upload and I sent it to 5-day/delay queue now. If
you want, I can cancel it. Otherwise, I will wait rephrase enter in
unstable and ask to Release Team for unblock.

The changelog is:

rephrase (0.2-2) unstable; urgency=medium

  * Team upload.
  * debian/control:
  - Bumped Standards-Version to 3.9.8.
  - Updated the Vcs-Git field to use https instead of git.
  * debian/patches/02_minimal_gpg2_support.patch: added to unconditionally
call gpg with "--pinentry-mode loopback", allowing rephrase work with
GPG2. Thanks to Axel Beckert . (Closes: #853935)

I attached a debdiff.

Cheers,

Eriberto


rephrase.debdiff
Description: Binary data

Bug#853244: ruby-sshkit: Non-determistically FTBFS due to unreliable timing in tests

[Chris Lamb]

Christian Hofstaedtler wrote:

> Thing is, upstream thought these tests provide value, even if they
> depend on a certain base performance of the machine they are running
> on.

Fair. On the other hand, upstreams can do some crazy things!

> > Would the idea that they interfere with running QA efforts across the
> > archive change your mind? :)
> 
> I can see that, but the reality is that there's only so many people
> looking at bugs. (Assuming "interfere" means you file a note in
> reproducible notes git and move on.)

I think "interfere" was the wrong word, sorry.

The problem is that this package would need a *specific* note/mention
that it should be ignored. Whilst we could certainly add that for
Reproducible Builds, what happens, for example, when the next person
runs a rebuild across the archive to test for something else (etc. etc.)

Better to fix them once and for all IMHO :)


Regards,

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

Bug#845199: additional info

[Jean-Marc]

Hi,

Last week, I was testing a dist-upgrade scenario from Jessie to Strech to see 
how mysql-like packages will behave
(see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852267).

I took this opportunity to also check what happen with migrating from PHP5 tp 
PHP7.

And after the dist-upgrade, an  left my dolibarr in a 
not-working state because of the removing of the Apache link in 
/etc/apache2/mods-enabled/ enabling PHP5.

Just a question : all PHP app in Debian are supposed to be PHP7 compliant, 
aren't they ?

So, in this case, why not directly removing PHP5 and enabling PHP7 ?

Regards,

Jean-Marc 


pgpuYmr5YD1Mf.pgp
Description: PGP signature

Bug#854066: Severitiy set to non-rc

[Ben Hutchings]

On Sun, 2017-02-05 at 19:07 +0100, Patrick Matthäi wrote:
> Hi Ben,
> 
> first thanks for your good work for Debian especially for the Linux kernel!
> 
> But with #854066 I have to disagree / argue with you. You lowered the
> severity to a non rc bug, but it is in my eyes.

You claimed this was RC due to "data loss", but that depends on having
a reasonable expectation that the data was persistent.  As you only
described a crash/hang, and not corruption of persistent storage, you
did not justify the RC status.

> At the moment we have got a project: Linux instead of Windows on Desktops
> for Developers.
> 
> So we switched many of our employe to Debian stretch (jessie would be
> too old) and I have got an eye on the daily updates. With 4.9.x one
> desktop (individual) does not boot at all, have to acc. it again. All
> other desktopts do not wake up anymore (kernel panic?) if they fall in
> sleep.
> 
> This is rc for me, if you think not, why? Many different hardware types
> are affected

You said "All PCs do have got the same GPU", so it sounds like this
does not affect a very large range of systems.  But if this is a very
common GPU then this could be RC.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai
Stevenson


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

Bug#851927: Cannot upgrade Signal

[Alex Dănilă]

Hi,

Signal extension still does not update, how to did trigger updating your 
extensions?


I upgraded chromium to experimental ( 56.0.2924.76 built on Debian 9.0, 
running on Debian 9.0 (64-bit)) and added to /etc/chromium.d/default-flags:

#Allow upgrade of extensions
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"

Then:
go to chrome://extensions/
check "Developer mode"
press "Update extensions now"
But nothing happens, and Signal stays at an old version, which is no 
longer compatible with newer ones.


Thank you,
Alex

Bug#854234:

[JCF Ploemen]

Control: retitle -1 SSL error on startup: 'ca md too weak'

Thanks for the info. Couple of follow-up questions:

* Is this a fresh debian and sabnzbd install or an updated system with
  a re-used configuration? If updated, from what previous versions?

* Did you setup the program to use your own ssl certificates or those
  generated automatically by sabnzbd?

* How old are the ssl certificates? If you don't know, try running the
  following command to find out:
  ls -la ~/.sabnzbd/admin/*.{key,cert}


pgpjcHb2gdlHa.pgp
Description: OpenPGP digital signature

Bug#852908: mako: FTBFS: Test failures

[Gilles Filippini]

Control: tags -1 + patch

On Sat, 4 Feb 2017 14:37:33 +0500 Andrey Rahmatullin  wrote:
> Looks like the problem is caused by something in Pygments but apart from
> making sure the version used is the same I don't know how to proceed.

The failure is caused by the recent upload of pygments 2.2.0. With this new
release the 'u' prefix is omitted from the rendered utf8 strings, as in:
 
while pygments 2.1.3 gives:
 u

Then I think the two failing tests have to be patched to remove the 'u' prefix
from the assertion (patch attached).

Hope This helps,

_g.
Index: mako-1.0.6+ds1/test/test_exceptions.py
===
--- mako-1.0.6+ds1.orig/test/test_exceptions.py
+++ mako-1.0.6+ds1/test/test_exceptions.py
@@ -91,7 +91,7 @@ ${u'привет'}
 assert "".encode(sys.getdefaultencoding(),
 'htmlentityreplace') in html_error
 else:
-assert 'u'\
+assert ''\
 ''\
 '}'.encode(
 sys.getdefaultencoding(),
@@ -220,7 +220,7 @@ ${foobar}
 assert 'привет' in \
 l.get_template("foo.html").render().decode('utf-8')
 else:
-assert 'u'\
+assert ''\
 '' in \
 l.get_template("foo.html").render().decode('utf-8')
 


signature.asc
Description: OpenPGP digital signature

Bug#812127: login: wrong German error message

[Bálint Réczey]

Hi Helge,

2017-01-21 17:15 GMT+01:00 Helge Kreutzmann :
> Hello Holger,
> On Sat, Jan 21, 2017 at 11:41:43AM +0100, Holger Wansing wrote:
>> Helge Kreutzmann  wrote:
>> > On Fri, Jan 20, 2017 at 09:19:34PM +0100, Balint Reczey wrote:
>> > > My wife says the proposed solution does not sound good and I don't speak
>> > > German thus I can't make a decision here. :-)
>> >
>> > The incorrect translation is probably caused by a misunderstanding of
>> > the translator (I put him explicitly in CC).
>> >
>> > I believe you mean:
>> > Under no cirumstance work is possible without effective root.
>>
>> This means, the english version is incorrect too, right?
>> Since in english it says "Cannot possibly work ...", and that means
>> something like "möglicherweise" or "eventuell" or "unter Umständen".
>
> No. In this place »possibly« does not mean »perhaps«. It rather means
> »at all«.
>
> This is, if the text was produced by a good or native speaker. Thus my
> uncertainty.
>
>> What do you think, is the correct english meaning, which is intended here?
>
> As stated, I (rather firmly) believe
>> Under no cirumstance work is possible without effective root.

IMO this is the correct interpretation.

The place where the message is emitted is here:
http://sources.debian.net/src/shadow/1:4.4-3/src/login.c/?hl=567#L567

Cheers,
Balint

>
> But let's wait what Balint says.
>
> Greetings
>
>Helge
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>Dipl.-Phys.   http://www.helgefjell.de/debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/

Bug#851697: aptget orig handling not pending

[Ian Jackson]

Control: tags -1 pending
Control: tags -1 wishlist

I wrote:
> I probably won't implement that soon I'm afraid.

The pending upload referred to the stub implementation, which was
uploaded some time ago. 

This bug now refers to the lack of the automatic orig inclusion
feature with the aptget archive method I think this is a wishlist
item.  It would be much better for archives that want to support dgit
push to implement a suitable query api.

Thanks,
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#854302: libc6: AI_ADDRCONFIG is not in all situations a useful default

[Uwe Kleine-König]

Package: libc6
Version: 2.24-8
Severity: normal
Tags: upstream

Hello,

quoting getaddrinfo(3):

   According  to  POSIX.1-2001,  specifying  hints  as  NULL  should cause
   ai_flags to be assumed as 0.  The GNU C library instead assumes a value
   of  (AI_V4MAPPED | AI_ADDRCONFIG)  for  this  case, since this value is
   considered an improvement on the specification.

On an offline host trying to connect a service via 127.0.0.1 (or ::1)
should work. If however the application uses

getaddrinfo("127.0.0.1", "http", NULL, ...);

it fails to connect because of the above "improvement", while it would
just work if getaddrinfo implemented the POSIX specification.

(Note, currently this is not a problem because of a bug in
getaddrinfo(), see https://bugs.debian.org/854301.)

Best regards
Uwe

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable'), (500, 'testing-debug'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#771441: tftpd: don't use AI_ADDRCONFIG to resolve addresses to bind(2)

[Uwe Kleine-König]

Hello Ron,

On Sun, Feb 05, 2017 at 05:05:16PM +1030, Ron wrote:
> On Sat, Feb 04, 2017 at 11:28:08PM +0100, Uwe Kleine-König wrote:
> > On Sat, Feb 04, 2017 at 03:46:46PM +1030, Ron wrote:
> > > > [...]
> > > That would seem to be a pretty good summation of how we're failing to
> > > converge here ...
> > 
> > I mixed too many things that IMHO improve the code but actually only
> > care about one of those. So I suggest we restart the discussion with
> > focusing on that one thing only.
> 
> Just repeating the same things, while ignoring the options I've shown
> you that do properly fix the problem(s) you're claiming to care about,
> isn't actually advancing this toward a workable solution in any way.

Note I repeated less than before. I hope this will simplify the
discussion and stop both of us arguing about stuff that doesn't matter
much.

> My previous replies to you were already focussed on the part of your
> patch that removed AI_ADDRCONFIG, and why it was not needed at best,
> and harmful at worst.

Yes, you told me in the situations you care about the modification
doesn't help you. I seem to care about different situations where the
patch is beneficial. So if the patch doesn't make things worse for you
(and all others out there) and it improves the situation for me, IMHO we
should apply the patch.

I didn't understand yet, in which situations it is harmful as you claim
above. The best claim matching this is: It papers over other problems.
Is it that why you want to keep AI_ADDRCONFIG? I don't understand though
what this buys for you. Consider you have a network problem on the
machine tftpd is supposed to run at. The result is that eth0 doesn't
have an ipv4 address. You notice that because a tftp-client tries to
contact the tftpd server and doesn't get an answer. So what to do next?
I assume your next step is logging into the tftpd-machine and check if
tftpd is running. (If instead you try ping $tftpdmachine, or check the
network config of the tftpd-machine, it doesn't actually help you that
tftpd isn't running as it is already obvious then that the network
configuration is at fault and not tftpd.) You see it doesn't run, check
the log and see

cannot resolve local IPv4 bind address: 0.0.0.0, Name or service not 
known

. Is it obvious now what the problem is? Maybe yes if the network is
still broken. But if not, it's harder to understand.

If instead tftpd would have started successfully, you see this after
login and the IMHO obvious next step is to check the network config.
If you ask me, that's not any harder to debug.

> I can read the actual code, and understand how gai works, and I'm pretty
> sure Mike understood all of that too when he first reported this bug.

I'm not sure about Mike, but that doesn't matter here.

> I'd already long ago checked that there wasn't a real bug being triggered
> somewhere here, and that the code itself really was working as expected,
> and you haven't indicated anything to the contrary here.

I did. I showed two examples where the use of AI_ADDRCONFIG breaks more
than necessary or expected.

> In the subset of cases where gai is used to resolve a string into a
> (set of) network address(es), it is not wrong to tell it that it's
> useless to return any address (family) which can't possibly work with
> the current machine configuration/state.

Using AI_ADDRCONFIG suppresses options that actually work. After all I
can bind to 0.0.0.0 even if no interface but lo has an ipv4 address.
After that I can connect to 127.0.0.1:69 and talk to tftpd. Or I can
hotplug a network interface, configure that and talk to tftpd from a
remote machine.

I understood that none of these is a scenario you depend on. But with
your refusal to see this patch as useful you assume that the above is
not a use case for anybody.

> That doesn't become less wrong if your expectation or interpretation of
> how it should work is different to reality and the specification of how
> it is defined to work.  If you explicitly say "bind to 0.0.0.0", you're
> saying you want to service global IPv4 requests.

The semantic of binding to 0.0.0.0 is not only "serve on global ipv4
addresses that currently exist". The semantic also includes: "serve on
lo" and "serve on interfaces that come up after the socket is bound".

> If you have no global IPv4 interfaces, that should fail and warn the
> admin of a problem, not silently ignore that what they explicitly
> requested isn't going to work.

The admin has a problem if a server that is supposed to serve files via
tftp to the world doesn't have a ipv4 address. That alone is a problem
big enough to notice. It doesn't help the admin that tftpd isn't running
or there is a cryptic error message in the log. If the network interface
is ready only later in the boot process everything works as expected as
soon as the interface is up. You say it's bad in this situation that the
admin doesn't notice there is a problem. I wonder if it's not a valid
approach to claim 

Bug#852633: [Pkg-tigervnc-devel] Bug#852633: tigervnc-standalone-server: The -once option is no more honored

[Christophe Lohr]

  
  
Le 05/02/2017 à 19:07, Joachim Falk a
  écrit :


  
The recent issue I'm facing is not due to the -once option but more probably caused by the -inetd option (I use both for the typical "inetd" scenario).

  
  this should now be fixed. Please test the preview debs under the following URL:
  https://xamane.jfalk.de/dists/homebrew-stretch/selfmade/binary-amd64
The fix should be in tigervnc-standalone-server_1.7.0+dfsg-6_amd64.deb.


I
just tested it. This works well. 
Thank you.

Best regards
Christophe
  

  

Bug#854234: sabnzbdplus: On my Debian 9 Stretch machine the sabnzbdplus crashes everytime at try to start it. I can't open it anymore.

[cc . carlchen]

Hello, 

I am so sorry, this was my very first time to use the reportbug on my Debian 
machine. My english is not so good. 
I hope these output can help you?

--

carlchen@carlchen-rechner:~$ sabnzbdplus -l2
2017-02-05 21:48:06,764::INFO::[sabnzbdplus:1218] 

2017-02-05 21:48:06,764::INFO::[sabnzbdplus:1219] sabnzbdplus-1.1.1 
(rev=33a7874416d8a8cc6a0d1e3f8d1e4042f2762d81)
2017-02-05 21:48:06,764::INFO::[sabnzbdplus:1220] Full executable path = 
/usr/bin/sabnzbdplus
2017-02-05 21:48:06,765::INFO::[sabnzbdplus:1232] Platform = posix
2017-02-05 21:48:06,765::INFO::[sabnzbdplus:1233] Python-version = 2.7.13 
(default, Jan 19 2017, 14:48:08) 
[GCC 6.3.0 20170118]
2017-02-05 21:48:06,765::INFO::[sabnzbdplus:1234] Arguments = 
/usr/bin/sabnzbdplus -l2
2017-02-05 21:48:06,765::INFO::[sabnzbdplus:1236] Preferred encoding = UTF-8
2017-02-05 21:48:06,765::DEBUG::[sabnzbdplus:1246] My local IPv4 address = 
192.168.178.20
2017-02-05 21:48:07,111::DEBUG::[sabnzbdplus:1252] My public IPv4 address = 
37.138.46.63
2017-02-05 21:48:07,112::DEBUG::[sabnzbdplus:1260] Could not determine my IPv6 
address
2017-02-05 21:48:07,130::DEBUG::[sabnzbdplus:1266] CPU Pystone available 
performance is 80710
2017-02-05 21:48:07,130::DEBUG::[sabnzbdplus:1271] CPU model name is Pentium(R) 
Dual-Core  CPU  E5700  @ 3.00GHz
2017-02-05 21:48:07,130::INFO::[sabnzbdplus:1284] Read INI file 
/home/carlchen/.sabnzbd/sabnzbd.ini
2017-02-05 21:48:07,136::INFO::[__init__:946] Loading data for queue9.sab from 
/home/carlchen/.sabnzbd/admin/queue9.sab
2017-02-05 21:48:07,138::DEBUG::[__init__:1163] Test IPv6: Cannot reach IPv6 
test host. Disabling IPv6
2017-02-05 21:48:07,138::DEBUG::[__init__:285] External IPv6 test result: False
2017-02-05 21:48:07,139::INFO::[__init__:946] Loading data for rss_data.sab 
from /home/carlchen/.sabnzbd/admin/rss_data.sab
2017-02-05 21:48:07,139::INFO::[__init__:946] Loading data for totals10.sab 
from /home/carlchen/.sabnzbd/admin/totals10.sab
2017-02-05 21:48:07,139::INFO::[__init__:949] 
/home/carlchen/.sabnzbd/admin/totals10.sab missing
2017-02-05 21:48:07,139::INFO::[__init__:946] Loading data for totals9.sab from 
/home/carlchen/.sabnzbd/admin/totals9.sab
2017-02-05 21:48:07,139::DEBUG::[bpsmeter:158] Setting default BPS meter values
2017-02-05 21:48:07,207::INFO::[postproc:89] Loading postproc queue
2017-02-05 21:48:07,207::INFO::[__init__:946] Loading data for postproc2.sab 
from /home/carlchen/.sabnzbd/admin/postproc2.sab
2017-02-05 21:48:07,207::INFO::[__init__:949] 
/home/carlchen/.sabnzbd/admin/postproc2.sab missing
2017-02-05 21:48:07,208::INFO::[__init__:946] Loading data for queue10.sab from 
/home/carlchen/.sabnzbd/admin/queue10.sab
2017-02-05 21:48:07,208::INFO::[__init__:949] 
/home/carlchen/.sabnzbd/admin/queue10.sab missing
2017-02-05 21:48:07,208::INFO::[__init__:946] Loading data for queue9.sab from 
/home/carlchen/.sabnzbd/admin/queue9.sab
2017-02-05 21:48:07,210::DEBUG::[downloader:154] Initializing downloader/decoder
2017-02-05 21:48:07,211::INFO::[__init__:946] Loading data for 
watched_data2.sab from /home/carlchen/.sabnzbd/admin/watched_data2.sab
2017-02-05 21:48:07,211::INFO::[__init__:949] 
/home/carlchen/.sabnzbd/admin/watched_data2.sab missing
2017-02-05 21:48:07,211::INFO::[__init__:946] Loading data for Rating.sab from 
/home/carlchen/.sabnzbd/admin/Rating.sab
2017-02-05 21:48:07,211::INFO::[__init__:949] 
/home/carlchen/.sabnzbd/admin/Rating.sab missing
2017-02-05 21:48:07,212::DEBUG::[scheduler:168] Scheduling RSS interval task 
every 60 min (delay=25)
2017-02-05 21:48:07,212::INFO::[scheduler:180] Setting schedule for midnight 
BPS reset
2017-02-05 21:48:07,212::DEBUG::[__init__:536] PAUSED_ALL inactive
2017-02-05 21:48:07,224::INFO::[__init__:330] All processes started
2017-02-05 21:48:07,225::INFO::[sabnzbdplus:343] Web dir is 
/usr/share/sabnzbdplus/interfaces/Plush
2017-02-05 21:48:07,226::INFO::[sabnzbdplus:343] Web dir is 
/usr/share/sabnzbdplus/interfaces/Config
2017-02-05 21:48:07,259::DEBUG::[newsunpack:149] UNRAR binary version 5.30
2017-02-05 21:48:07,259::INFO::[sabnzbdplus:458] _yenc module... found!
2017-02-05 21:48:07,259::INFO::[sabnzbdplus:466] par2 binary... found 
(/usr/bin/par2)
2017-02-05 21:48:07,259::INFO::[sabnzbdplus:471] par2cmdline binary... found 
(/usr/bin/par2)
2017-02-05 21:48:07,260::INFO::[sabnzbdplus:474] UNRAR binary... found 
(/usr/bin/unrar)
2017-02-05 21:48:07,260::INFO::[sabnzbdplus:480] unzip binary... found 
(/usr/bin/unzip)
2017-02-05 21:48:07,260::INFO::[sabnzbdplus:485] 7za binary... found 
(/usr/bin/7za)
2017-02-05 21:48:07,260::INFO::[sabnzbdplus:491] nice binary... found 
(/usr/bin/nice)
2017-02-05 21:48:07,260::INFO::[sabnzbdplus:495] ionice binary... found 
(/usr/bin/ionice)
2017-02-05 21:48:07,260::INFO::[sabnzbdplus:500] pyOpenSSL... found (True)
2017-02-05 21:48:07,260::INFO::[sabnzbdplus:1345] SSL version OpenSSL 1.1.0c  
10 Nov 2016
2017-02-05 

Bug#854301: libc6: getaddrinfo with AF_UNSPEC and AI_ADDRCONFIG should not return results on offline machine

[Uwe Kleine-König]

Package: libc6
Version: 2.24-8
Severity: normal
Tags: upstream patch

Hello,

for ease of reproducibility I show my examples in Python, but I verified
that the problem is in glibc and not in Python:

On a machine without network access I get:

>>> import socket
>>> socket.getaddrinfo("0.0.0.0", "http", family=socket.AF_INET, 
flags=socket.AI_ADDRCONFIG)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.5/socket.py", line 733, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, 
flags):
socket.gaierror: [Errno -2] Name or service not known

as expected. If however I use AF_UNSPEC instead of AF_INET I get:

>>> socket.getaddrinfo("0.0.0.0", "http", family=socket.AF_UNSPEC, 
flags=socket.AI_ADDRCONFIG)
[(, , 6, '', 
('0.0.0.0', 80))]

while it should fail in the same way as above instead.

Quoting getaddrinfo(3):

If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4
addresses are returned in the list pointed to by res only if the
local system has at least one IPv4 address configured [...].

The following patch should fix this:

--- a/sysdeps/posix/getaddrinfo.c
+++ b/sysdeps/posix/getaddrinfo.c
@@ -2351,7 +2351,8 @@
}
}
   else if ((hints->ai_family == PF_INET && ! seen_ipv4)
-  || (hints->ai_family == PF_INET6 && ! seen_ipv6))
+  || (hints->ai_family == PF_INET6 && ! seen_ipv6)
+  || (hints->ai_family == PF_UNSPEC))
{
  /* We cannot possibly return a valid answer.  */
  __free_in6ai (in6ai);

Best regards
Uwe

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable'), (500, 'testing-debug'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#854258: firefox-esr: firefox crashes every few seconds or minutes with a crash handler dialog since last update

[advocatux]

I'm suffering those same kind of crashes after updating to Firefox 
45.7.0esr-2 but I've found they stop when I deactivate the NoScript plugin.


Cheers
--
advocatux