Bug#845784: RFS: dropwizard-metrics [ITP]

[Christopher Hoskin]

Dear Tobias and Tim,

Tobias, thank you very much for your response - I'm afraid I've only just
become aware of it. 

> > Did you contact Tim? (CC'ed him with this mail; he still owns the ITP)

No - as Tim placed this package under the maintainance of the pkg-java team
I was following the pkg-java procedure [1]. Appologies if that wasn't the
correct procedure to follow in this case.

Since filing the RFS I've completed the DD application process, and now have
upload rights. Prior to receiving Tim's e-mail, I went ahead and uploaded my
package to the NEW queue [2]. However, as a new DD I still consider myself
inexperienced, so any suggestions or corrections are gratefully received.

> I got seriously stuck packaging up dropwizard 

Tim, do you recall what you got stuck with? Your package looked in good shape
to my (inexperienced) eyes so I was surprised that it hadn't been uploaded. Did
you find some show-stopper that I've overlooked? (I haven't attempted to build
all of the modules, but I think it's considered acceptable for a pkg-java
package to omit some tricky non-essential modules.)

Thanks for your time.

[1] https://pkg-java.alioth.debian.org/
[2] https://ftp-master.debian.org/new/dropwizard-metrics_3.1.2-1.html

Christopher





signature.asc
Description: PGP signature

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

[Stefan Weil]

On 01/04/17 08:03, Graham Inggs wrote:

On 3 January 2017 at 20:24, Jeff Breidenbach  wrote:

Tesseract 4 is known to not work on big endian. Stefan (on CC) is excited to
take a look if someone can give him access to a big endian machine.


It is possible for non-DDs to request temporary access to porterboxes,
see https://dsa.debian.org/doc/guest-account/



"People who are not yet DMs or NMs will need to find a DD who is willing 
to sponsor their request". That's what I tried to do.


Stefan

Bug#794890: npm install --save-dev intern fails

[Mihail Dakov]

Package: npm
Version: 1.4.21+ds-2
Followup-For: Bug #794890

Dear Maintainer,

As per subject, "npm install --save-dev intern" fails. npm packages seems to be 
outdated
and does not support dependencies of type @module/names.

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

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

Versions of packages npm depends on:
ii  node-abbrev   1.0.9-1
ii  node-ansi 0.3.0-2
ii  node-ansi-color-table 1.0.0-1
ii  node-archy1.0.0-1
ii  node-block-stream 0.0.9-1
ii  node-fstream  1.0.10-1
ii  node-fstream-ignore   0.0.6-2
ii  node-github-url-from-git  1.4.0-1
ii  node-glob 7.1.1-1
ii  node-graceful-fs  4.1.11-1
ii  node-gyp  3.4.0-1
ii  node-inherits 2.0.3-1
ii  node-ini  1.1.0-1
ii  node-lockfile 0.4.1-1
ii  node-lru-cache4.0.2-1
ii  node-minimatch3.0.3-1
ii  node-mkdirp   0.5.0-1
ii  node-nopt 3.0.6-3
ii  node-npmlog   0.0.4-1
ii  node-once 1.4.0-2
ii  node-osenv0.1.0-1
ii  node-read 1.0.7-1
ii  node-read-package-json1.2.4-1
ii  node-request  2.26.1-1
ii  node-retry0.6.0-1
ii  node-rimraf   2.5.4-2
ii  node-semver   5.3.0-1
ii  node-sha  1.2.3-1
ii  node-slide1.1.4-1
ii  node-tar  2.2.1-1
ii  node-underscore   1.8.3~dfsg-1
ii  node-which1.2.11-1
ii  nodejs4.6.1~dfsg-1

npm recommends no packages.

npm suggests no packages.

-- no debconf information

Bug#844294: gnome-shell-extensions: Please re-enable nautilus-classic in gnome-classic.session

[intrigeri]

Hi,

Michael Biebl:
> I'll keep this bug report open for further feedback. Maybe users of the
> Classic mode can comment here.

Thank you for caring!

So, Tails 2.x (Jessie) is using Classic mode, but Tails 3.x (Stretch)
switches to regular GNOME Shell + the places-menu extension.

We enable show-desktop-icons with a snippet in /etc/dconf/db/local.d/.
It works fine for us (desktop icons are displayed) with the snapshot
of testing from December 20, that we're currently using as our
development basis (it has gnome-shell-extensions 3.22.2-1).

> Without this patch, nautilus-desktop is started by default for the GNOME
> Classic session and draws the icons on the desktop. The downside is,
> that the user can no longer override this setting via
> gsettings set org.gnome.desktop.background show-desktop-icons false.

If this patch was dropped, would it still work to set
show-desktop-icons via dconf system-wide?

Cheers,
-- 
intrigeri

Bug#640765: screen: -U even with UTF-8 locale results in garbled ncurses apps

[folkert]

Hi,

Please close the report: I have no (longer an) idea when this problem
happened. Probably under putty.

On Wed, Nov 30, 2016 at 11:53:40PM +0100, Axel Beckert wrote:
> Control: tag -1 + moreinfo
> 
> Hi,
> 
> Daniel Dickinson wrote:
> > Package: screen
> > Version: 4.0.3-14
> > 
> > Use of screen -U results in corrupted screen for ncurses apps, even if 
> > locale is UTF-8.
> 
> This is a very general description of an issue, so it's difficult to
> check if the issue is still present.
> 
> Can you check with either a current Debian Stable (i.e. Jessie) or
> Debian Testing/Unstable if this is still happening for you.
> 
> I know there are still known issues with screen
> 4.1.0~20120320gitdb59704-7 in Wheezy (currently oldstable) which are
> no more present in Debian Unstable (and others which are still there).
> 
> Folkert van Heusden wrote:
> > I can confirm this problem.
> > Directly on the ssh prompt, things run fine. Then when i invoke screen
> > and run a program, then all lines are garbled.
> > See for example this:
> > http://keetweej.vanheusden.com/~folkert/fi-screen.png
> 
> Can't access that URL anymore. Can you please sent the picture to the
> bug report (if the issue still appears for you in Debian Stable,
> Testing or Unstable) instead?
> 
>   Regards, Axel
> -- 
>  ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


Folkert van Heusden

-- 
Curious about the inner workings of your car? Then check O2OO: it'll
tell you all that there is to know about your car's engine!
http://www.vanheusden.com/O2OO/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Bug#850110: network-manager: can't enable only one WiFi interface

[Xavier Bestel]

Package: network-manager
Version: 1.4.4-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Trying to enable an USB WiFi dongle while disabling the onboard PCI
   WiFi.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Click on the "0/1" widget for the WiFi networks
   * What was the outcome of this action?
 Disabling one adapter disables both, enabling one adapter enables
 both.
   * What outcome did you expect instead?
 I expected only the adapter I selected to be enabled/disabled.


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

Kernel: Linux 4.8.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 network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.14-1
ii  init-system-helpers1.46
ii  libaudit1  1:2.6.7-1
ii  libbluetooth3  5.43-1
ii  libc6  2.24-8
ii  libglib2.0-0   2.50.2-2
ii  libgnutls303.5.7-3
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.6.4-1
ii  libndp01.6-1
ii  libnewt0.520.52.19-1
ii  libnl-3-2003.2.27-1
ii  libnm0 1.4.4-1
ii  libpam-systemd 232-8
ii  libpolkit-agent-1-00.105-17
ii  libpolkit-gobject-1-0  0.105-17
ii  libreadline7   7.0-1
ii  libselinux12.6-3
ii  libsoup2.4-1   2.56.0-2
ii  libsystemd0232-8
ii  libteamdctl0   1.26-1
ii  libuuid1   2.29-1
ii  lsb-base   9.20161125
ii  policykit-10.105-17
ii  udev   232-8
ii  wpasupplicant  2.5-2+v2.4-3+b1

Versions of packages network-manager recommends:
ii  crda 3.13-1+b2
ii  dnsmasq-base 2.76-5
ii  iptables 1.6.0+snapshot20161117-4
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-1
ii  modemmanager 1.6.4-1
ii  ppp  2.4.7-1+4

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

-- no debconf information

Bug#850111: lldb-4.0: keypresses from STDIN shown as \U+XXXXX, unusable

[Philipp Marek]

Package: lldb-4.0
Version: 1:4.0~svn290810-1
Severity: normal

lldb-4.0 is unusable for me. While it can be started,
I can't enter any commands.

This is me typing "help...":

$ lldb-4.0 /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) \U+5F068\U+5F065\U+5F06C\U+5F070\U+5F00A^C
(lldb) \U+95904^C
(lldb) \U+95904^C

Looks like an uninitialized variable.


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

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

Versions of packages lldb-4.0 depends on:
ii  libc6 2.24-8
ii  libedit2  3.1-20160903-2
ii  libffi6   3.2.1-6
ii  libgcc1   1:6.2.1-5
ii  liblldb-4.0   1:4.0~svn290810-1
ii  libllvm4.01:4.0~svn290810-1
ii  libncurses5   6.0+20161126-1
ii  libpython2.7  2.7.13-1
ii  libstdc++66.2.1-5
ii  libtinfo5 6.0+20161126-1
ii  llvm-4.0-dev  1:4.0~svn290810-1
ii  zlib1g1:1.2.8.dfsg-4

lldb-4.0 recommends no packages.

Versions of packages lldb-4.0 suggests:
pn  python-lldb-4.0  

-- no debconf information

Bug#849958: openmolar: Does not start; missing QtWebkit

[Andreas Tille]

Hi Dominik,

thanks for reporting this issue.  I tried to upgrade openmolar to its
latest upstream version but I failed for very strange reasons[1].  Since
I did not managed to solve this and its probably to late to inject a
new upstream version in freeze time we probably can not ship openmolar
with Stretch after the removal of QtWebKit 4.

Dmitry, if you have any better idea that's perfectly welcome and
uploading the new version to unstable might not harm in any case but
I do not feel able to do this myself in a short time frame.

Kind regards

   Andreas.


[1] https://lists.debian.org/debian-python/2016/12/msg00050.html

On Mon, Jan 02, 2017 at 05:50:05PM +0100, Dominik George wrote:
> Package: openmolar
> Version: 0.6.2-2
> Severity: grave
> Justification: renders package unusable
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Traceback (most recent call last):
>   File "/usr/bin/openmolar", line 30, in 
> main.run()
>   File "/usr/share/openmolar/openmolar/main.py", line 122, in run
> chosen_func()
>   File "/usr/share/openmolar/openmolar/main.py", line 65, in main
> from openmolar.qt4gui import maingui
>   File "/usr/share/openmolar/openmolar/qt4gui/maingui.py", line 49, in 
> 
> from openmolar.qt4gui.fees import fees_module
>   File "/usr/share/openmolar/openmolar/qt4gui/fees/fees_module.py", line 49, 
> in 
> from openmolar.qt4gui.printing import om_printing
>   File "/usr/share/openmolar/openmolar/qt4gui/printing/om_printing.py", line 
> 63, in 
> from openmolar.qt4gui.dialogs.print_record_dialog import PrintRecordDialog
>   File 
> "/usr/share/openmolar/openmolar/qt4gui/dialogs/print_record_dialog.py", line 
> 26, in 
> from PyQt4 import QtGui, QtCore, QtWebKit
> ImportError: cannot import name QtWebKit
> 
> 
> I also cannot find QtWebkit from PyQt4 for Python 2 in Debian.
> 
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.8.0-2-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 /usr/bin/lksh
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages openmolar depends on:
> ii  python  2.7.13-1
> ii  python-mysqldb  1.3.7-1+b1
> ii  python-qscintilla2  2.9.3+dfsg-4
> ii  python-qt4  4.11.4+dfsg-2
> pn  python:any  
> ii  xdg-utils   1.1.1-1
> 
> openmolar recommends no packages.
> 
> Versions of packages openmolar suggests:
> pn  mysql-server | mariadb-server  
> 
> - -- no debconf information
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlhqhL0xGmh0dHBzOi8v
> d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
> dHVyYWxuZXQuZGUACgkQt5o8FqDE8pblQRAAoWuhLnQwud7CUzVh2t9nFtKFaWFR
> ZGbSNj2qGZmh6AK3uRmKTycstXORY5v7Em2B9FCausjKxhdcXagiOpSAxwxw+YHv
> AfNE1qrPlLqVC3Y0obE5tCsbw4tpDHQ6eHB2zzSTeJwNJSZvZ1SNG3FH1C+BBllh
> uRZ3uAVQHG1ZSWIwR5HkQlGLrOIChhGVtRhxJwC0BOMjBp88tl573fQw2HjKKMwn
> 2uX+OrKN5XjgQmnRRfieP03yQEVhWJx1nJz0sXFGje9R685Z/VUJoUzXuYS20pr8
> XDLSo3/IMARxfHAy6m12SyWLwvMkMjj7UhsfzBMLN0N2MVKwB+D/i3xHq27azRwQ
> FWQEZGrdspGdbW8CY+tcdaw0op4rBtlLVXHaAFsQlqcOjx020i0uNkw3B1pDltaH
> hTeubUw//yxx4kQCwhFLy2oZnH+mxBGSWZLVy7briz26Udo0UfywP9Ka20R1PUuc
> AkzdfZkQq3J3KxZFj9o+0r4R4UjtqE+zqDlpcZ2naT+wynAG/IlQBQ6501v6zAxO
> Ldjn38u5dwEuR6IEaAh4HLGW2R8ABeRvVRWCdPUZCIFK9oMh7iitJbtu+86qUkn/
> WSRr8ZJyKRUVT5E+6oxs7WwUk59vXlw1zItWnzSJwiRMuj62ecEXIu/AUEVW1CI8
> e+mz3luLiQnS0uY=
> =tZjD
> -END PGP SIGNATURE-
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#732382: doesnt work in debian stretch either

[David Schmidt]

same package version

pcsxr 1.9.92-4

Bug#800385: tor: systemd .service granting too much capabilities?

[Laurent Bigonville]

reopen 800385
thanks

Le 04/01/17 à 08:15, Peter Palfrader a écrit :

Thanks for your help!

On Wed, 04 Jan 2017, Laurent Bigonville wrote:


I just tried with the following hardening features, and the daemon is
starting (I kept the old value in comment):

# Hardening
AppArmorProfile=system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectControlGroups=yes #added
ProtectKernelTunables=yes #added

Maybe.


#ProtectSystem=full
ProtectSystem=strict

Maybe.  That's new in sid/testing.


#ReadOnlyDirectories=/


I understand better why you choose the ReadOnlyDirectories=/ instead of 
ProtectSystem=strict now



#ReadWriteDirectories=-/proc

Maybe.


ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
#ReadWriteDirectories=-/var/run
ReadWriteDirectories=-/var/run/tor

Can we still create the directory if it isn't there yet?


Yes it's working, if I'm commenting it out completely the daemon fails. 
I think that it only apply to the main process and not the Pre one (maybe?)





#CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE 
CAP_DAC_OVERRIDE
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE

No, that breaks hidden services.  See https://bugs.debian.org/847598


I see. Do you know what were the owner/group of 
/var/lib/tor/hidden_service/ in that bug?



torify wget http://www.perdu.com returns the expected content

I think other useful tests would be
  - can Tor start when a hidden service is configured?
  - can Hidden services read/write to backend sockets in
/var/lib/tor-onion-sockets/?
  - does transparent proxying still work (TransPort)?
  - can we log to syslog?


I'll try to see when I can test that. Don't expect a reply tomorrow though.

For the syslog part, I see stuffs being logged in journald, so it's OK I 
guess.


Laurent Bigonville

Bug#850006: also sorta depends on #826214

[Russell Coker]

If you are running systemd and start sddm with "/etc/init.d/sddm start" then 
it won't use systemctl and will start in the same "session" as your shell and 
thus give this error message even if you have removed the pam_systemd lines 
from /etc/pam.d/sddm*.

Until #826214 you have to use "systemctl start sddm.service" if you are using 
systemd.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#850112: atool: when extracting archive.tar.* with multiple files in root, incorrect dirname archive.tar

[Vincent Lefevre]

Package: atool
Version: 0.39.0-5
Severity: minor

When extracting an archive that has multiple files in root, atool
creates a directory. The chosen name is not consistent. For instance,
for archive.txz, the directory name is "archive" (if it does not exist
yet), but for archive.tar.xz, it is "archive.tar", while .tar.xz and
.txz are regarded as equivalent extensions:

   tar+xz (.tar.xz, .txz)
  All commands are supported.

It should be "archive" in both cases.

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, 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 atool depends on:
pn  perl:any  

Versions of packages atool recommends:
ii  bash-completion  1:2.1-4.3
ii  binutils 2.27.90.20161231-1
ii  bzip21.0.6-8
ii  file 1:5.29-2
ii  lbzip2   2.5-2
ii  unzip6.0-21
ii  zip  3.0-11

Versions of packages atool suggests:
pn  arc  
pn  arj  
ii  cpio 2.11+dfsg-6
ii  lzip 1.18-4
pn  lzop 
pn  nomarch  
ii  p7zip-full   16.02+dfsg-2
pn  rar  
pn  rpm  
pn  unace
pn  unalz
pn  unrar
ii  xz-utils [lzma]  5.2.2-1.2

-- no debconf information

Bug#850113: vim-youcompleteme: 'KeyError's on every key press flooding vim

[Maximilian Stein]

Package: vim-youcompleteme
Version: 0+20160327+git1b76af4-2
Severity: important

Dear Maintainer,

since the last update of vim-youcompleteme essentially every key press
in vim (e.g., cursor move) triggers a python exception and the whole
stack trace is dumped into vim's error log.

Using vim's option '-V1' I destilled the following stack trace:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/share/vim-youcompleteme/python/ycm/youcompleteme.py", line
508, in HandleFileParseRequest
self.NativeFiletypeCompletionUsable() ):
  File "/usr/share/vim-youcompleteme/python/ycm/youcompleteme.py", line
255, in NativeFiletypeCompletionUsable
self.NativeFiletypeCompletionAvailable() )
  File "/usr/share/vim-youcompleteme/python/ycm/youcompleteme.py", line
250, in NativeFiletypeCompletionAvailable
vimsupport.CurrentFiletypes() ] )
  File "/usr/share/vim-youcompleteme/python/ycm/youcompleteme.py", line
249, in 
return any( [ self.FiletypeCompleterExistsForFiletype( x ) for x in
  File "/usr/share/vim-youcompleteme/python/ycm/youcompleteme.py", line
240, in FiletypeCompleterExistsForFiletype
exists_completer = SendCompleterAvailableRequest( filetype )
  File
"/usr/share/vim-youcompleteme/python/ycm/client/completer_available_request.py",
line 57, in SendCompleterAvailableRequest
request.Start()
  File
"/usr/share/vim-youcompleteme/python/ycm/client/completer_available_request.py",
line 45, in Start
'semantic_completion_available' )
  File "/usr/share/vim-youcompleteme/python/ycm/client/base_request.py",
line 81, in PostDataToHandler
timeout ) )
  File "/usr/share/vim-youcompleteme/python/ycm/client/base_request.py",
line 174, in JsonFromFuture
_ValidateResponseObject( response )
  File "/usr/share/vim-youcompleteme/python/ycm/client/base_request.py",
line 203, in _ValidateResponseObject
their_hmac = ToBytes( b64decode( response.headers[ _HMAC_HEADER ] ) )
  File "/usr/lib/python3/dist-packages/requests/structures.py", line 54,
in __getitem__
return self._store[key.lower()][1]
KeyError: 'x-ycm-hmac'

Unfortunately, as this stack trace is dumped every time I move the cursor,
this error renders vim useless for me when youcompleteme is turned on.


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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 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 vim-youcompleteme depends on:
ii  python3-future0.15.2-4
ii  python3-requests  2.12.4-1
ii  python3-requests-futures  0.9.7-1
pn  python3:any   
ii  vim-gtk [vim-python]  2:8.0.0134-1
ii  ycmd  0+20160327+gitc3e6904-1+b1

Versions of packages vim-youcompleteme recommends:
ii  vim-addon-manager  0.5.6

vim-youcompleteme suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#847477: Bug#800385: tor: systemd .service granting too much capabilities?

[Peter Palfrader]

On Wed, 04 Jan 2017, Laurent Bigonville wrote:

> reopen 800385

Don't, let's take it to #847477.

> >># Hardening
> >>AppArmorProfile=system_tor
> >>NoNewPrivileges=yes
> >>PrivateTmp=yes
> >>PrivateDevices=yes
> >>ProtectHome=yes
> >>ProtectControlGroups=yes #added
> >>ProtectKernelTunables=yes #added
> >Maybe.
> >
> >>#ProtectSystem=full
> >>ProtectSystem=strict
> >Maybe.  That's new in sid/testing.
> >
> >>#ReadOnlyDirectories=/
> 
> I understand better why you choose the ReadOnlyDirectories=/ instead of
> ProtectSystem=strict now
> 
> >>#ReadWriteDirectories=-/proc
> >Maybe.
> >
> >>ReadWriteDirectories=-/var/lib/tor
> >>ReadWriteDirectories=-/var/log/tor
> >>#ReadWriteDirectories=-/var/run
> >>ReadWriteDirectories=-/var/run/tor
> >Can we still create the directory if it isn't there yet?
> 
> Yes it's working, if I'm commenting it out completely the daemon fails. I
> think that it only apply to the main process and not the Pre one (maybe?)

Does it also work if /var/run/tor is *not* there yet when you try to
start the service?  At least at some point in history the Pre commands
were subject to the same restrictions.

> >>#CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE 
> >>CAP_DAC_OVERRIDE
> >>CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
> >No, that breaks hidden services.  See https://bugs.debian.org/847598
> 
> I see. Do you know what were the owner/group of /var/lib/tor/hidden_service/
> in that bug?

They were debian-tor:, go-rwx, but the check is run when tor is still
root, thus DAC_OVERRIDE is required.

> >>torify wget http://www.perdu.com returns the expected content
> >I think other useful tests would be
> >  - can Tor start when a hidden service is configured?
> >  - can Hidden services read/write to backend sockets in
> >/var/lib/tor-onion-sockets/?
> >  - does transparent proxying still work (TransPort)?
> >  - can we log to syslog?
> 
> I'll try to see when I can test that. Don't expect a reply tomorrow though.
> 
> For the syslog part, I see stuffs being logged in journald, so it's OK I
> guess.

Don't guess, test :)

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

Bug#849481: amanda-common: Amanda::Changer::robot::Interface::MTX calls confess but does not use Carp

[jose]

Just to tell that the patch was submitted to the authors of amanda and 
accepted.

This means your fix is relevant to all the versions I have talked about.
Thank you.

Kind regards
Jose M Calhariz

On 2016-12-27 16:54, Will Aoki wrote:

Package: amanda-common
Version: 1:3.3.8-1
Severity: normal
Tags: patch

I've been getting occasional failures that leave the following in the 
report:


  FAILURE DUMP SUMMARY:
taper: FATAL Undefined subroutine
&Amanda::Changer::robot::Interface::MTX::confess called at
/usr/lib/amanda/perl/Amanda/Changer/robot.pm line 2563.
backup1.nhmu.utah.edu pool/burp lev 0  FAILED [out of holding
space in degraded mode]
backup1.nhmu.utah.edu pool/burp lev 0  FAILED [data write: Broken 
pipe]


The cause of the failure seems to be a fork failing, but a bug in 
AMANDA's
error-handling code is masking the first problem. This module calls 
confess(),

but it doesn't use Carp first or otherwise declare &confess.

--- /tmp/robot.pm   2016-12-27 09:41:57.285488949 -0700
+++ /usr/lib/amanda/perl/Amanda/Changer/robot.pm2016-12-27
09:41:34.045222046 -0700
@@ -2359,6 +2359,7 @@
 use Amanda::Debug qw( debug warning );
 use Amanda::MainLoop qw( :GIOCondition synchronized make_cb
define_steps step );
 use Amanda::Device qw( :constants );
+use Carp;

 sub new {
 my $class = shift;

Bug#848001: supertuxkart: Fix credits for Boom-boom-boom song

[Vincent Cheng]

On Tue, Jan 3, 2017 at 2:56 AM, James Cowgill  wrote:
> On 02/01/17 22:03, Vincent Cheng wrote:
>> On Thu, Dec 15, 2016 at 7:08 AM, Legimet  wrote:
>>> Just to be clear, this affects the credits that show up after clicking the
>>> "About" button in the lower-right corner of the start screen. To fix it, the
>>> file data/CREDITS needs to be changed.
>>>
>>> On Monday, December 12, 2016 9:39:30 PM EST Legimet wrote:
 Package: supertuxkart
 Severity: normal

 In the credits (data/CREDITS), the Boom-boom-boom song should be
 credited to its author, Keith Baylis aka Vim, rather than Matt Thomas.
>>
>> diff recognizes data/CREDITS as a binary file instead of a plain-text
>> ASCII file or similar; I can't generate a quilt patch to fix this. The
>> only way to fix this bug right now would be to repack the orig tarball
>> yet again, which I would rather not do. Given that this has already
>> been fixed upstream [1], I'm inclined to just wait for a new upstream
>> release instead.
>
> Couldn't you just install a new CREDITS file manually (overwriting the
> old one after dh_install)? I'm not saying that's the best idea, but you
> don't have to repack the tarball for this.

Ack, that's true. I suppose the only problem with that approach is if
I forget to remove the CREDITS file I added once a new upstream
release is made. I'd rather not have yet another thing on my todo list
to keep track of. ;)

Regards,
Vincent

Bug#850114: kscd: Only play first trackon all modes(loop track, loop ,and no loop and random and no random mode)

[Pere Nubiola Radigales]

Package: kscd
Version: 4:16.08.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,


is a problem when you want to listen a CD whenwhile you aredoing other tasks. 

the tracj list is show corrrectly.and when you selecct one from the list it 
plays and affter return to the first song.


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

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

Versions of packages kscd depends on:
ii  kde-runtime   4:16.08.3-1
ii  libc6 2.24-8
ii  libdiscid00.6.1-6
ii  libgcc1   1:6.3.0-2
ii  libkdecore5   4:4.14.26-1
ii  libkdeui5 4:4.14.26-1
ii  libkio5   4:4.14.26-1
ii  libmusicbrainz5cc2v5  5.1.0+git20150707-6
ii  libphonon44:4.9.0-4
ii  libqt4-dbus   4:4.8.7+dfsg-11
ii  libqt4-svg4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libsolid4 4:4.14.26-1
ii  libstdc++66.3.0-2
ii  phonon4:4.9.0-4

kscd recommends no packages.

Versions of packages kscd suggests:
ii  kde-config-cddb  4:16.08.3-1

-- no debconf information

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Ansgar Burchardt]

Control: retitle -1 release-notes: recommend installing usrmerge on upgrade to 
buster
Control: tag -1 - stretch + buster

The change in debootstrap to enable merged-/usr has been temporarily
reverted due to issues reported.  As it was only fixed quite late, we
won't re-enable merged-/usr for stretch.

As my recommendation to install usrmerge tries to keep newly-installed
and upgraded systems more in sync, I believe we should delay
recommending so until debootstrap goes back to merged-/usr, that is
until buster.

Ansgar

Bug#849598: [Pkg-kde-extras] Bug#849598: amarok: FTBFS (cannot find -lmysqlclient)

[Pino Toscano]

severity 849598 important
thanks

Temporarly downgrading to important as
a) I want amarok in testing, and not having it here by tomorrow means it
   won't be in stretch
b) it looks like something due to MySQL/MariaDB, and possibly it will be
   sorted once the MariaDB version mess is over

-- 
Pino Toscano

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

Bug#847477: Bug#800385: tor: systemd .service granting too much capabilities?

[Laurent Bigonville]

Le 04/01/17 à 10:13, Peter Palfrader a écrit :

On Wed, 04 Jan 2017, Laurent Bigonville wrote:




ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
#ReadWriteDirectories=-/var/run
ReadWriteDirectories=-/var/run/tor

Can we still create the directory if it isn't there yet?

Yes it's working, if I'm commenting it out completely the daemon fails. I
think that it only apply to the main process and not the Pre one (maybe?)

Does it also work if /var/run/tor is *not* there yet when you try to
start the service?  At least at some point in history the Pre commands
were subject to the same restrictions.


Yes I tried that, deleting the /var/run/tor directory completely and 
then restarting the service and the directory is created. A side note is 
that we should maybe use a tmpfiles config here, that way is more 
"systemd'ish" and then we are sure the directory is created at boot.

#CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE 
CAP_DAC_OVERRIDE
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE

No, that breaks hidden services.  See https://bugs.debian.org/847598

I see. Do you know what were the owner/group of /var/lib/tor/hidden_service/
in that bug?

They were debian-tor:, go-rwx, but the check is run when tor is still
root, thus DAC_OVERRIDE is required.


OK




torify wget http://www.perdu.com returns the expected content

I think other useful tests would be
  - can Tor start when a hidden service is configured?
  - can Hidden services read/write to backend sockets in
/var/lib/tor-onion-sockets/?
  - does transparent proxying still work (TransPort)?
  - can we log to syslog?

I'll try to see when I can test that. Don't expect a reply tomorrow though.

For the syslog part, I see stuffs being logged in journald, so it's OK I
guess.

Don't guess, test :)

Bug#822604: scanmem: depends on gksu which is deprecated

[Sebastian Parschauer]

On 02.01.2017 22:55, Vincent Bernat wrote:
> OK. In debian/control, ${python:Depends} already expands to python (>=
> 2.7), so you don't need to put it a second time (but that's really
> nitpicking). Also, I just noticed that gameconqueror is "Architecture:
> any" while it should be "Architecture: all" (there is nothing
> architecture-dependant in it). In this case, you should also replace the
> dependency on scanmem by:
> 
>  Depends: scanmem (>= ${source:Version}), scanmem (<< 
> ${source:Upstream-Version}.0~)
> 
> And the suggestion for gameconqueror by:
> 
>  Suggests: gameconqueror (= ${source:Version}
> 
> The reasons are explained here:
>  https://wiki.debian.org/binNMU

Thanks, that hint was crucial. I've implemented all that and updated the
source branch. Should be ready for upload now.

https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc

> I don't see any other problem. As per policy, there is a whole procedure
> to take over a package. However, Lu and Kartik were in copy of your
> intent to take over the package since April and didn't say a thing, I
> suppose they are fine with it.

Yep, they are fine with it. They both don't have the time to care for
this package any more. With the scanmem upstream on GitHub and new
contributors also upstream achieves faster progress and better stability
now. I took over upstream maintenance from Lu Wang in 2015.

Cheers,
Sebastian

Bug#850112: atool: inconsistencies in file extensions

[Vincent Lefevre]

Control: retitle -1 atool: inconsistencies in file extensions

On 2017-01-04 10:11:25 +0100, Vincent Lefevre wrote:
> When extracting an archive that has multiple files in root, atool
> creates a directory. The chosen name is not consistent. For instance,
> for archive.txz, the directory name is "archive" (if it does not exist
> yet), but for archive.tar.xz, it is "archive.tar", while .tar.xz and
> .txz are regarded as equivalent extensions:
> 
>tar+xz (.tar.xz, .txz)
>   All commands are supported.
> 
> It should be "archive" in both cases.

Actually this problem may be specific to .tar.xz as I see that it is
missing from sub stripext.

But there are other inconsistencies. The atool(1) man page says:

   tar+lzop (.tar.lzo, .tzo)
  All commands are supported.

and sub stripext contains:

  return $file if ($file =~ s/(\.tar\.lzo|\.lzo)$//);

It should be:

  return $file if ($file =~ s/(\.tar\.lzo|\.tzo)$//);

and .lzo should be on its own.

Inconsistencies with lzma too and maybe others.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#847477: Bug#800385: tor: systemd .service granting too much capabilities?

[Peter Palfrader]

On Wed, 04 Jan 2017, Laurent Bigonville wrote:

> Yes I tried that, deleting the /var/run/tor directory completely and then
> restarting the service and the directory is created. A side note is that we
> should maybe use a tmpfiles config here, that way is more "systemd'ish" and
> then we are sure the directory is created at boot.

Works for me.


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

Bug#845851: NMU: gnustep-sqlclient: switch to build depend on the metapackage default-libmysqlclient-dev

[Gert Wollny]

Dear maintainers, 

since this is an RC bug and affects packages in debian-med, I've
prepared an NMU and uploaded with with 2 days delay. 

Attached you will find the according diff.

best, 
Gert 

diff --git a/debian/changelog b/debian/changelog
index 541f09e..945a150 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+gnustep-sqlclient (1.7.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build depend on default-libmysqlclient-dev, Closes: #845851
+
+ -- Gert Wollny   Wed, 04 Jan 2017 09:27:59 +
+
 gnustep-sqlclient (1.7.3-2) unstable; urgency=low
 
   * debian/rules (override_dh_auto_test): Explicitly set the permissions
diff --git a/debian/control b/debian/control
index fef2942..e2aab77 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Uploaders: Yavor Doganov 
 Build-Depends: debhelper (>= 9),
 	   libgnustep-base-dev,
 	   libperformance-dev,
-	   libmysqlclient-dev,
+	   default-libmysqlclient-dev,
 	   libecpg-dev,
 	   libsqlite3-dev
 Standards-Version: 3.9.5

Bug#734688: Call for testers: logrotate 3.11.0-0.1~exp1

[Matthias Klose]

On 04.01.2017 00:23, Christoph Biedl wrote:
> Hi there,
> 
> as the stretch freeze approaches, I'm getting concerned about the
> status of logrotate, most notably #734688. The maintainer (CC'ed)
> hasn't shown any sign of activity for a while, also no response to a
> private message (I admit, it's been just a few days).
> 
> Since the fix includes switching to a new upstream version, I refrained
> from doing a simple NMU. Instead I've uploaded a new version to
> experimental (as 3.11.0-0.1~exp1) and would appricate tests and
> feedback in the hope major breakage gets gets detected early.
> 
> My plan is to upload to unstable+2 during to weekend.
> 
> From the changelog (more extensive than I'd usually do, to ease review):
> 
>  logrotate (3.11.0-0.1~exp1) experimental; urgency=medium
>  .
>* Non-maintainer upload to experimental
>* New upstream version 3.11.0  Closes: #734688
>* Refresh patch queue
>  - Now upstream:
>+ datehack.patch
>+ mktime-718332.patch
>+ man-su-explanation-729315.patch
>  - deb-config-h.patch: New way to enforce status file location
>* Update watch file. Closes: #844578
>* Update Homepage: information
>* Allow failure in the clean target
>* Fix broken test suite runner

fyi, I NMUed logrotate yesterday to fix #849743, currently in delayed.  Please
add this fix to your upload.

Matthias

Bug#850115: samba: create mask = 0700

[Olaf van der Spek]

Package: samba
Version: 2:4.5.2+dfsg-2
Severity: minor

Dear Maintainer,

With create mask = 0700, files created via Windows have the executable bit 
set.. I doubt this is desired. Could you set create mask to 0600?

Gr,
Olaf


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

Kernel: Linux 4.8.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages samba depends on:
ii  adduser  3.115
ii  dpkg 1.18.18
ii  init-system-helpers  1.46
ii  libbsd0  0.8.3-1
ii  libc62.24-8
ii  libldb1  2:1.1.27-1
ii  libpam-modules   1.1.8-3.4
ii  libpam-runtime   1.1.8-3.4
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.13-1
ii  libtalloc2   2.1.8-1
ii  libtdb1  1.3.11-2
ii  libtevent0   0.9.31-1
ii  libwbclient0 2:4.5.2+dfsg-2
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3
ii  python   2.7.13-1
ii  python-dnspython 1.15.0-1
ii  python-samba 2:4.5.2+dfsg-2
pn  python2.7:any
ii  samba-common 2:4.5.2+dfsg-2
ii  samba-common-bin 2:4.5.2+dfsg-2
ii  samba-libs   2:4.5.2+dfsg-2
ii  tdb-tools1.3.11-2
ii  update-inetd 4.43

Versions of packages samba recommends:
ii  attr1:2.4.47-2
ii  logrotate   3.8.7-2
ii  samba-dsdb-modules  2:4.5.2+dfsg-2
ii  samba-vfs-modules   2:4.5.2+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
pn  ntp
pn  smbldap-tools  
pn  ufw
pn  winbind

-- no debconf information

Bug#849312: apt: dist-upgrade removes pkgs instead of upgrading them

[David Kalnischkies]

On Tue, Jan 03, 2017 at 10:29:19AM +0100, Olaf van der Spek wrote:
> 2016-12-25 13:12 GMT+01:00 David Kalnischkies :
> >> Can't it detect mariadb-server-10.1 being a proper upgrade of
> >> mariadb-server-10.0 and hence scoring this as neutral or positive?
> >
> > In general no, because that isn't a positive upgrade: It involves the
> 
> 10.1 declares replaces on 10.0 doesn't it?
> Doesn't apt use this information?

It doesn't because the 'Replaces' is only there to tell dpkg that it is
okay that this package overrides some files of another package. That
frequently happens then a single package is split into a bunch (like
foo, foo-data, foo-plugins-extra). It does also happen then two packages
'fight' over a particalur path in the filesystem and that fight was
resolved: like in the git, chromium or node cases just to name a few big
and popular ones. I somehow doubt you consider a spaceshooter an upgrade
to a browser (or well, actually the other way around – which was the
chromium case).

See Debian policy §7.6.1 for details. See also §7.6.2 – but don't get
your hopes up in terms of upgrades: You wouldn't like apt to constantly
flip between postfix and exim4 either…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#850116: gdm3: gnome-session-f called from gdm3 SEGVs when run with SE Linux enforcing

[Russell Coker]

Source: gdm3
Severity: normal

gdm3 fails to start when SE Linux is enforcing and the kernel message log has
many messages like the ones below.

To reproduce this, have a system running gdm3 and run the following commands:
apt-get install selinux-policy-default selinux-basics
selinux-activate
reboot
selinux-config-enforcing
reboot

Then you should have the SEGVs.

I don't expect you to fix this for Stretch.  Anyone who wants an X login
program running with SE Linux will just have to use sddm or xdm.

[81568.555619] gnome-session-f[18771]: segfault at 0 ip 7f42969f8d39 sp 
7ffc25d41600 error 4 in libgtk-3.so.0.2200.5[7f4296716000+6fe000]
[81571.051691] gnome-session-f[18804]: segfault at 0 ip 7f55c7a42d39 sp 
7ffd7033a450 error 4 in libgtk-3.so.0.2200.5[7f55c776+6fe000]
[81574.131269] gnome-session-f[18847]: segfault at 0 ip 7fa86c064d39 sp 
7fff88d7ef00 error 4 in libgtk-3.so.0.2200.5[7fa86bd82000+6fe000]
[81577.329807] gnome-session-f[18885]: segfault at 0 ip 7f951567cd39 sp 
7ffca644e670 error 4 in libgtk-3.so.0.2200.5[7f951539a000+6fe000]
[81580.502957] gnome-session-f[18927]: segfault at 0 ip 7fec99f30d39 sp 
7ffc5d79c460 error 4 in libgtk-3.so.0.2200.5[7fec99c4e000+6fe000]
[81583.586522] gnome-session-f[18971]: segfault at 0 ip 7f596695cd39 sp 
7fff455aeef0 error 4 in libgtk-3.so.0.2200.5[7f596667a000+6fe000]
[81586.712827] gnome-session-f[19004]: segfault at 0 ip 7f0a5d94ed39 sp 
7ffd452eed80 error 4 in libgtk-3.so.0.2200.5[7f0a5d66c000+6fe000]

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

Kernel: Linux 4.8.0-2-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/bash
Init: systemd (via /run/systemd/system)

Bug#781779: sddm

[Russell Coker]

I have sddm working and have checked the basic policy into git.  Later today I 
will add some extra rules that are needed for full operation (such as deleting 
temporary files on user logout), but the basics work.

I still can't get gdm3 to work, I've filed a bug report against it.  If anyone 
here would like to look at gdm3 then that would be a good thing to do.  But I 
think that sddm and xdm are both good options so I'm not too bothered.  I'm 
thinking of making selinux-policy-default just conflict with gdm3.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#728955: libatomic-ops: diff for NMU version 7.4.2-1.2

[John Paul Adrian Glaubitz]

Hi!

The current version 7.4.4-3 of libatomic-ops builds fine on all architectures 
[1].
Can we close this or am I missing something?

Adrian

> [1] https://buildd.debian.org/status/package.php?p=libatomic-ops

-- 
 .''`.  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#850119: ITP: node-binary-extensions -- List of binary file extensions

[Vivek Bhave]

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

* Package name: node-binary-extensions
  Version : 1.8.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/binary-extensions#readme
* License : Expat
  Programming Lang: JavaScript
  Description : List of binary file extensions

Bug#850121: ITP: node-tough-cookie -- RFC6265 Cookies and Cookie Jar for node.js

[Roshan]

Package: wnpp
Severity: wishlist
Owner: Roshan Nalawade 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-tough-cookie
  Version : 2.3.2
  Upstream Author : Jeremy Stashewsky 
* URL : https://github.com/salesforce/tough-cookie
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : RFC6265 Cookies and Cookie Jar for node.js

Bug#850117: ITP: node-common-path-prefix -- Computes the longest prefix string that is common to each path, excluding the base component

[Ameya Apte]

Package: wnpp
Severity: wishlist
Owner: Ameya Apte 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-common-path-prefix
  Version : 1.0.0
  Upstream Author : Mark Wubben (https://novemberborn.net/)
* URL :
https://github.com/novemberborn/common-path-prefix#readme
* License : ISC
  Programming Lang: JavaScript
  Description : Computes the longest prefix string that is common to
each path, excluding the base component

Bug#850118: ITP: node-slice-ansi -- Slice a string with ANSI escape codes

[Sumedh Pendurkar]

Package: wnpp
Severity: wishlist
Owner: Sumedh Pendurkar 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-slice-ansi
  Version : 0.0.4
  Upstream Author : David Caccavella 
* URL : https://github.com/chalk/slice-ansi#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Slice a string with ANSI escape codes

Bug#850120: ITP: node-clean-yaml-object -- Clean up an object prior to serialization

[Prathamesh Mane]

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

* Package name: node-clean-yaml-object
  Version : 0.1.0
  Upstream Author : James Talmage  (
github.com/jamestalmage)
* URL : https://github.com/tapjs/clean-yaml-object#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Clean up an object prior to serialization

Bug#850126: ITP: node-aproba -- A rediculously light-weight argument validator

[Tushar Agey]

Package: wnpp
Severity: wishlist
Owner: Tushar Agey 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-aproba
  Version : 1.0.4
  Upstream Author : Rebecca Turner 
* URL : https://github.com/iarna/aproba
* License : ISC
  Programming Lang: JavaScript
  Description : A rediculously light-weight argument validator

Bug#850123: ITP: node-has-unicode -- Try to guess if your terminal supports unicode

[Yogiraj Kulkarni]

Package: wnpp
Severity: wishlist
Owner: Yogiraj Kulkarni 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-has-unicode
  Version : 2.0.1
  Upstream Author : Rebecca Turner 
* URL : https://github.com/iarna/has-unicode
* License : ISC
  Programming Lang: JavaScript
  Description : Try to guess if your terminal supports unicode

Bug#850125: ITP: node-ci-info -- Get details about the current Continuous Integration environment

[Siddhesh Rane]

Package: wnpp
Severity: wishlist
Owner: Siddhesh Rane 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-ci-info
  Version : 1.0.0
  Upstream Author : Thomas Watson Steen  (
https://twitter.com/wa7son)
* URL : https://github.com/watson/ci-info
* License : Expat
  Programming Lang: JavaScript
  Description : Get details about the current Continuous Integration
environment

Bug#850127: ITP: node-aws4 -- Signs and prepares requests using AWS Signature Version 4

[Vinay Desai]

Package: wnpp
Severity: wishlist
Owner: Vinay Desai 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-aws4
  Version : 1.5.0
  Upstream Author : Michael Hart  (
http://github.com/mhart)
* URL : https://github.com/mhart/aws4#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Signs and prepares requests using AWS Signature Version
4

Bug#850122: ITP: node-buf-compare -- Node.js `Buffer.compare()` ponyfill

[nikhil gawande]

Package: node-buf-compare
Severity: wishlist
Owner: Nikhil Gawande 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-buf-compare
  Version : 1.0.1
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/buf-compare#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js `Buffer.compare()` ponyfill

Bug#850129: ITP: node-onetime -- Ensure a function is only called once

[Tejas Nayak]

Package: wnpp
Severity: wishlist
Owner: Tejas Nayak 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-onetime
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/onetime#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Ensure a function is only called once

Bug#850122: ITP: node-buf-compare -- Node.js `Buffer.compare()` ponyfill

[Mattia Rizzolo]

Control: reassign -1 wnpp

On Wed, Jan 04, 2017 at 05:56:40AM -0500, nikhil gawande wrote:
> Package: node-buf-compare

ITPs are against 'wnpp', not the name of the prospective package.

-- 
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#850130: ITP: node-is-generator-fn -- Check if something is a generator function

[Aarti Kashyap]

Package: wnpp
Severity: wishlist
Owner: Aarti Kashyap 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-is-generator-fn
  Version : 1.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/is-generator-fn
* License : Expat
  Programming Lang: JavaScript
  Description : Check if something is a generator function

Bug#850133: ITP: node-fn-name -- Get the name of a named function

[Shirish Togarla]

Package: wnpp
Severity: wishlist
Owner: Shirish Togarla 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-fn-name
  Version : 2.0.1
  Upstream Author : Sindre Sorhus  (
http://sindresorhus.com)
* URL : https://github.com/sindresorhus/fn-name
* License : Expat
  Programming Lang: JavaScript
  Description : Get the name of a named function

Bug#850131: ITP: node-is-obj -- Check if a value is an object

[Gaurav Juvekar]

Package: wnpp
Severity: wishlist
Owner: Gaurav Juvekar 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-is-obj
  Version : 1.0.1
  Upstream Author : Sindre Sorhus  
(sindresorhus.com)

* URL : https://github.com/sindresorhus/is-obj#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Check if a value is an object

 .
 Node.js is an event-based server-side JavaScript engine.

Bug#850132: ITP: aws-sign2 -- AWS signing. Originally pulled from LearnBoost/knox, maintained as vendor in request, now a standalone module.

[Srushti Chaudhari]

Package: wnpp
Severity: wishlist
Owner: Srushti Chaudhari 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-aws-sign2
  Version: 0.6.0
  Upstream Author: Mikeal Rogers  (
http://www.futurealoof.com)
* URL: http://github.com/mikeal/aws-sign#readme
* License: Apache-2.0
  Programming Lang: JavaScript
  Description: AWS signing. Originally pulled from LearnBoost/knox,
maintained as vendor in request, now a standalone module.

Bug#822604: scanmem: depends on gksu which is deprecated

[Sebastian Parschauer]

On 04.01.2017 10:33, Sebastian Parschauer wrote:
> Thanks, that hint was crucial. I've implemented all that and updated the
> source branch. Should be ready for upload now.
> 
> https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc

Andrea Stacchiotti (in CC) reported that the upload would fix all three
pending Debian bugs for the scanmem package.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=scanmem

It also fixes most issues seen here:

https://tracker.debian.org/pkg/scanmem

And of cause all four Ubuntu package bugs.

All bugs are fixed by the new upstream version.

Should I append the following lines to the new upstream release entry in
debian/changelog?

   + Closes #618464
   + Closes #689057
   + Closes #822604

This should auto-close these bugs, right?

Cheers,
Sebastian

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Evgeni Golov]

Hey,

On Wed, Jan 04, 2017 at 01:04:12AM +0100, Toni Mueller wrote:
> On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote:
> > Unfortunately, we don't build ansible off of the git repository, but
> > rather from the released tarballs.
> 
> I found them only on PyPI. Did you find them elsewhere?

http://releases.ansible.com/ansible/

> > It's been a while since we made the decision not to pull from upstream's
> > git; Toni, I'd be happy to work with you on seeing if it's doable now.
> 
> Let's get the -doc package into stretch first if it's not too late
> already.

I fear that is too late :(
It would have to be in stretch (not sid) tomorrow, which is not possible
given a 10day migration period.

Regards
Evgeni

Bug#850135: ITP: node-asn1 -- Contains parsers and serializers for ASN.1 (currently BER only)

[akshay kemekar]

Package: wnpp
Severity: wishlist
Owner: akshay kemekar 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-asn1
  Version : 0.2.3
  Upstream Author : Mark Cavage 
* URL : https://github.com/mcavage/node-asn1
* License : Expat
  Programming Lang: JavaScript
  Description : Contains parsers and serializers for ASN.1 (currently
BER only)

Bug#850136: ITP: node-asynckit -- Minimal async jobs utility library, with streams support

[Aditya Neralkar]

Package: wnpp
Severity: wishlist
Owner:  Aditya Neralkar 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-asynckit
  Version : 0.4.0
  Upstream Author : Alex Indigo 
* URL : https://github.com/alexindigo/asynckit#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Minimal async jobs utility library, with streams support

Bug#849602: not a bug

[Patrick Mutwiri]

thats how fonts are installed.


this is not a bug.




*Kind Regards,*


Patrick Mutwiri / _dev

+254 727 542 899

Nairobi, Kenya

http://patric.xyz

[image: Twitter]  [image: Facebook]
 [image: Google +]
 [image: LinkedIn]
 [image: Instagram]
 [image: Github]
 [image: Stack Overflow]

Bug#850137: ITP: node-stringstream -- Encode and decode streams into string streams

[Rushi Bhadane]

Package: wnpp
Severity: wishlist
Owner: Rushikesh Bhadane 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-stringstream
  Version : 0.0.5
  Upstream Author : Michael Hart  (
http://github.com/mhart)
* URL : https://github.com/mhart/StringStream#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Encode and decode streams into string streams

Bug#850139: ITP: node-assert-plus -- Extra assertions on top of node;s assert module

[saurabhagrawal]

Package: wnpp
Severity: wishlist
Owner: Saurabh Agrawal 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-assert-plus
  Version : 1.0.0
  Upstream Author : Mark Cavage 
* URL : https://github.com/mcavage/node-assert-plus#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Extra assertions on top of node's assert module

Bug#834531: pan: Crash when closing/quitting

[Dominique Dumont]

This issue has been found upstream: 
* http://lists.nongnu.org/archive/html/pan-users/2016-12/msg4.html

This issue could be solved by disabling gnome keyring.

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#850140: ITP: node-delegates -- delegate methods and accessors to another property

[Nupur Malpani]

Package: wnpp
Severity: wishlist
Owner: Nupur Malpani 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-delegates
  Version : 1.0.0
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/node-delegates#readme
* License : Expat
  Programming Lang: JavaScript
  Description : delegate methods and accessors to another property

Bug#845818: flash-kernel: Add support for Hardkernel Odroid-C2

[Heinrich Schuchardt]

The prerequisite patch fixing #845779 has been applied to the
flash-kernel git.

Bug#850142: libmariadb-dev: mariadb_config emits trailing binary bullshit on mips64el

[Andreas Beckmann]

Package: libmariadb-dev
Version: 2.3.1-1
Severity: important
Control: affects -1 + src:rmysql

(severity should be serious, will raise after the next britney run)

(sid_mips64el-dchroot)anbe@eller:~$ mariadb_config
Copyright 2011-2015 MariaDB Corporation AB
Get compiler flags for using the MariaDB Connector/C.
Usage: mariadb_config [OPTIONS]
  --cflags[-I/usr/include/mariadb -I/usr/include/mariadb/mysql -g -O2 
-fdebug-prefix-map=/build/mariadb-connector-c-dopxmU/mariadb-connector-c-2.3.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wunused -Wno-uninitialized]
  --include   [-I/usr/include/mariadb -I/usr/include/mariadb/mysql]
  --libs  [-L/usr/lib/mips64el-linux-gnuabi64 -lmariadb]
  --libs_r[-L/usr/lib/mips64el-linux-gnuabi64 -lmariadb]
  --version   [5.5.1]
  --socket[/var/run/mysqld/mysqld.sock]
  --port  [3306]
  --plugindir [/usr/lib/mips64el-linux-gnuabi64/mariadb/plugin]
  --plugindir [/usr/lib/mips64el-linux-gnuabi64/mariadb/plugin]
ql]
g -O2 
-fdebug-prefix-map=/build/mariadb-connector-c-dopxmU/mariadb-connector-c-2.3.1=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wunused -Wno-uninitialized]
�

Looks like some buffer is printed twice (starting at the second --plugindir)
and this includes all *bytes* from the buffer, ignoring zero termination.
Redirecting this to a file (or piping through hd) does not give the the 
duplicate
--plugindir setting, but a lot of \0 bytes (and three non-\0 bytes) at the end.
Running mariadb_config with some arguments emits similar trailing binary crap.


(sid_mips64el-dchroot)anbe@eller:~$ mariadb_config | hd | tail -n 20
0540  75 73 72 2f 6c 69 62 2f  6d 69 70 73 36 34 65 6c  |usr/lib/mips64el|
0550  2d 6c 69 6e 75 78 2d 67  6e 75 61 62 69 36 34 20  |-linux-gnuabi64 |
0560  2d 6c 6d 61 72 69 61 64  62 5d 0a 20 20 2d 2d 76  |-lmariadb].  --v|
0570  65 72 73 69 6f 6e 20 20  20 20 20 20 20 5b 35 2e  |ersion   [5.|
0580  35 2e 31 5d 0a 20 20 2d  2d 73 6f 63 6b 65 74 20  |5.1].  --socket |
0590  20 20 20 20 20 20 20 5b  2f 76 61 72 2f 72 75 6e  |   [/var/run|
05a0  2f 6d 79 73 71 6c 64 2f  6d 79 73 71 6c 64 2e 73  |/mysqld/mysqld.s|
05b0  6f 63 6b 5d 0a 20 20 2d  2d 70 6f 72 74 20 20 20  |ock].  --port   |
05c0  20 20 20 20 20 20 20 5b  33 33 30 36 5d 0a 20 20  |   [3306].  |
05d0  2d 2d 70 6c 75 67 69 6e  64 69 72 20 20 20 20 20  |--plugindir |
05e0  5b 2f 75 73 72 2f 6c 69  62 2f 6d 69 70 73 36 34  |[/usr/lib/mips64|
05f0  65 6c 2d 6c 69 6e 75 78  2d 67 6e 75 61 62 69 36  |el-linux-gnuabi6|
0600  34 2f 6d 61 72 69 61 64  62 2f 70 6c 75 67 69 6e  |4/mariadb/plugin|
0610  5d 0a 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |]...|
0620  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
1310  00 f1 0f 02 00 00 00 00  00 00 00 00 00 00 00 00  ||
1320  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00022309


This breaks the rmysql configure script.


While you are it it, please filter out -fdebug-prefix-map=* from the cflags.


Andreas

Bug#850143: phpmd reports exponentiation with double asterisks as 'Unexpected token'

[Carsten Kosthorst]

Package: phpmd
Version: 2.4.3-1
Severity: important

Dear Maintainer,

phpmd reports exponentiation with double asterisks as 'Unexpected
token'. Double asterisks are a valid arithmetic operator since PHP 5.6:
.

~$ cat foo.php && php foo.php && phpmd foo.php text cleancode

Bug#850144: please update to a new upstream snapshot and build with LLVM 3.9

[Matthias Klose]

Source: ycmd
Version: 0+20160327+gitc3e6904-1
Tags: stretch sid

Looks like upstream now supports LLVM 3.9.

Bug#850146: tmux: "send-keys -X" in a bind-key no longer working

[Philipp Marek]

Package: tmux
Version: 2.4~git20161210-1
Severity: normal

In my ~/.tmux.conf I've got these settings (among others):

bind-key M-, copy-mode \; send-keys -X 0 Left Left ^ Space E Enter \; 
paste-buffer
bind-key M-. copy-mode \; send-keys -X 0 Left Left Space B Enter \; 
paste-buffer
bind-key M-Enter copy-mode \; send-keys -X 0 Left Left Space ^ Enter \; 
paste-buffer

These select the first word, the last word, or the whole line in the line 
above the cursor.

For example, when doing a "du -sk X" command I was able to copy the number 
out via these keypresses.


Now this doesn't work any more.
"tmux" goes into copy-mode; I can see the [0/X] position in the top-right 
corner, but the "send-keys -X" doesn't seem to be active, and the keys just 
vanish.
After pressing Enter (a few times) or Ctrl-C (once) to get out of 
copy-mode, the buffer contents are pasted, though; so it's just the 
"send-keys" that's not working.


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

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

Versions of packages tmux depends on:
ii  libc6   2.24-8
ii  libevent-2.0-5  2.0.21-stable-2.1
ii  libtinfo5   6.0+20161126-1
ii  locales 2.24-8

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

Bug#728955: libatomic-ops: diff for NMU version 7.4.2-1.2

[Breno Leitao]

Hi Adrian,

On 01/04/2017 08:50 AM, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> The current version 7.4.4-3 of libatomic-ops builds fine on all architectures 
> [1].
> Can we close this or am I missing something?

I understand that they are building because the tests are being bypassed as
an workaround.

Take a look at debian/rules that says:

  ifeq (,$(findstring $(DEB_BUILD_ARCH), powerpc ppc64 ppc64el armel))
DEB_MAKE_CHECK_TARGET := check
  endif

Bug#850147: mariadb-10.0: stretch should be released with mariadb-10.1 only

[Andreas Beckmann]

Source: mariadb-10.0
Version: 10.0.28-2
Severity: serious

Hi,

the remaining bits needed for the transition from mariadb-10.0 to
mariadb-10.1 are updates to the dependencies in mysql-defaults
(and this RC bug to get 10.0 removed at some point).


Andreas

Bug#850145: RFS: rdma-core [ITP] rdma-core -- RDMA Core Userspace Libraries and Daemons

[Talat Batheesh]

Package: sponsorship-requests
Severity: normal

Dear mentors,

 I am looking for a sponsor for my package "rdma-core"

* Package name: rdma-core
  Version : 12-1.1
  Upstream Author : Doug Ledford , Leon Romanovsky 

* URL : https://github.com/linux-rdma/rdma-core
* License : GPLv2+ and BSD
  Section : net

 It builds those binary packages:

   ibacm - InfiniBand Communication Manager Assistant (ACM)
ibverbs-providers - User space provider drivers for libibverbs
ibverbs-utils - Examples for the libibverbs library
iwpmd - Userspace component for iWarp RDMA services
libibcm-dev - Development files for the libibcm library
libibcm1   - InfiniBand Communication Manager (CM) library
libibcm1-dbg - InfiniBand Communication Manager (CM) library
libibumad-dev - Development files for libibumad
libibumad3 - InfiniBand Userspace Management Datagram (uMAD) library
libibumad3-dbg - InfiniBand Userspace Management Datagram (uMAD) library
libibverbs-dev - Development files for the libibverbs library
libibverbs1 - Library for direct userspace use of RDMA (InfiniBand/iWARP)
libibverbs1-dbg - Debugging symbols for the libibverbs library
librdmacm-dev - Development files for the libr:dmacm library
librdmacm1 - Library for managing RDMA connections
librdmacm1-dbg - Debugging symbols for the librdmacm library
rdma-core  - RDMA core userspace infrastructure and documentation.
rdmacm-utils - Examples for the librdmacm library
srptools   - Tools for Infiniband attached storage (SRP)

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

 https://mentors.debian.net/package/rdma-core

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

   dget -x 
https://mentors.debian.net/debian/pool/main/r/rdma-core/rdma-core_12-1.1.dsc

 Regards,
  Talat Batheesh

Bug#850148: phpmd: Fatal error when using anonymous classes

[Carsten Kosthorst]

Package: phpmd
Version: 2.4.3-1
Severity: important

Dear Maintainer,

phpmd does not seem to work with anonymous classes:

~$ cat foo.php && php foo.php && phpmd foo.php text cleancode
say("bar");
bar
PHP Fatal error:  Uncaught TypeError: Argument 1 passed to 
PDepend\Source\AST\AbstractASTNode::addChild() must implement interface 
PDepend\Source\AST\ASTNode, instance of PDepend\Source\AST\ASTAnonymousClass 
given, called in 
/usr/share/php/PDepend/Source/Language/PHP/PHPParserVersion70.php on line 214 
and defined in /usr/share/php/PDepend/Source/AST/AbstractASTNode.php:367
Stack trace:
#0 /usr/share/php/PDepend/Source/Language/PHP/PHPParserVersion70.php(214): 
PDepend\Source\AST\AbstractASTNode->addChild(Object(PDepend\Source\AST\ASTAnonymousClass))
#1 /usr/share/php/PDepend/Source/Language/PHP/PHPParserVersion70.php(188): 
PDepend\Source\Language\PHP\PHPParserVersion70->parseAnonymousClassDeclaration(Object(PDepend\Source\AST\ASTAllocationExpression))
#2 /usr/share/php/PDepend/Source/Language/PHP/AbstractPHPParser.php(1475): 
PDepend\Source\Language\PHP\PHPParserVersion70->parseAllocationExpressionTypeReference(Object(PDepend\Source\AST\ASTAllocationExpression))
#3 /usr/share/php/PDepend/Source/Language/PHP/AbstractPHPParser.php in 
/usr/share/php/PDepend/Source/AST/AbstractASTNode.php on line 367

Carsten

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

Kernel: Linux 4.8.0-2-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 phpmd depends on:
ii  pdepend   2.2.4-1
ii  php-cli   1:7.0+47
ii  php-common1:47
ii  php7.0-cli [php-cli]  7.0.14-2

phpmd recommends no packages.

phpmd suggests no packages.

-- no debconf information

Bug#850149: shotwell: Freezes when trying to open an image in fullscreen mode

[Alberto Garcia]

Package: shotwell
Version: 0.25.1-1
Severity: normal

Hello,

when I open Shotwell and I double click on one of the images from the
"Photos" library (I have tens of thousands) in order to display it in
fullscreen mode then the app freezes more often than not.

After a while I get the "Shotwell is not responding" dialog, with
the "Force Quit" and "Wait" options. If I wait then I finally get
the image in fullscreen mode after ~30 seconds and the app behaves
normally again. After that I can double click on any other image from
the library and Shotwell responds normally.

If instead of opening an image from the main "Photos" library I choose
one event and double click on a photo from there then app also behaves
normally.

I believe this started to happen recently (maybe after Shotwell
0.24.0).

I'm attaching the backtrace of the moment when Shotwell is frozen.

Regards,

Berto

-- Package-specific info:

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

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

Versions of packages shotwell 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-cli 0.26.0-2
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-7
ii  libcairo-gobject2 1.14.6-1.1
ii  libcairo2 1.14.6-1.1
ii  libexif12 0.6.21-2
ii  libgck-1-03.20.0-3
ii  libgcr-base-3-1   3.20.0-3
ii  libgcr-ui-3-1 3.20.0-3
ii  libgdk-pixbuf2.0-02.36.2-1
ii  libgee-0.8-2  0.18.1-1
ii  libgexiv2-2   0.10.4-1
ii  libglib2.0-0  2.50.2-2
ii  libgomp1  6.2.1-5
ii  libgphoto2-6  2.5.11-1
ii  libgphoto2-port12 2.5.11-1
ii  libgstreamer-plugins-base1.0-01.10.2-1
ii  libgstreamer1.0-0 1.10.2-1
ii  libgtk-3-03.22.4-1
ii  libgudev-1.0-0230-3
ii  libjavascriptcoregtk-4.0-18   2.14.2-1
ii  libjson-glib-1.0-01.2.2-1
ii  liblcms2-22.7-1
ii  libp11-kit0   0.23.2-5
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libraw15  0.17.2-6
ii  librsvg2-common   2.40.16-1
ii  libsoup2.4-1  2.56.0-1
ii  libsqlite3-0  3.15.2-1
ii  libstdc++66.2.1-5
ii  libwebkit2gtk-4.0-37  2.14.2-1
ii  libxml2   2.9.4+dfsg1-2.1
ii  shotwell-common   0.25.1-1

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information
Thread 29 (Thread 0x7fff93fff700 (LWP 20434)):
#0  0x7fffef17f119 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7fffef91326a in g_cond_wait_until (cond=cond@entry=0x55bce698, 
mutex=mutex@entry=0x55bce690, end_time=end_time@entry=146184007185)
at ././glib/gthread-posix.c:1442
#2  0x7fffef8a1e89 in g_async_queue_pop_intern_unlocked 
(queue=queue@entry=0x55bce690, wait=wait@entry=1, 
end_time=end_time@entry=146184007185)
at ././glib/gasyncqueue.c:422
#3  0x7fffef8a24ac in g_async_queue_timeout_pop (queue=0x55bce690, 
timeout=timeout@entry=1500) at ././glib/gasyncqueue.c:543
#4  0x7fffef8f5e0d in g_thread_pool_thread_proxy () at 
././glib/gthreadpool.c:167
#5  0x7fffef8f5e0d in g_thread_pool_thread_proxy (data=) at 
././glib/gthreadpool.c:364
#6  0x7fffef8f5345 in g_thread_proxy (data=0x7fffb0037cf0) at 
././glib/gthread.c:784
#7  0x7fffef440464 in start_thread (arg=0x7fff93fff700) at 
pthread_create.c:333
#8  0x7fffef1839df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 14 (Thread 0x7fffca2fb700 (LWP 20376)):
#0  0x7fffef17a56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fffca8d5bd1 in  () at /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x7fffef440464 in start_thread (arg=0x7fffca2fb700) at 
pthread_create.c:333
#3  0x7fffef1839df in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone

Bug#849266: [Pkg-lirc-maint] Bug#849266: lirc: does not work with update 0.9.4c-4 to 0.9.4c-5

[Alec Leamas]

On Sun, 25 Dec 2016 16:42:10 +0100 Thomas Renard  wrote:


> Because I did not find out how (and with wich lib) kodi connects to lirc
> I need some time to investigate. Please stand by - I will give you more
> information if I find out the problem from my point of view.

Ping? I have an update pending,  but it's not likely to resolve these 
issues. Any new information would be appreciated


--alec

Bug#792205: fusioninventory-agent: modifies conffiles (policy 10.7.3): /etc/fusioninventory/agent.cfg

[Guillaume Bougard]

Hi Andreas,

from my point of view, this is not a bug.

fusioninventory-agent package uses ucf to handle such case and between
v2.2.3 (wheezy version) & v2.3.10 (jessie version), the default
installed agent.cfg configuration has been changed a little (mostly
commented new config value and few minor updates).

So I think the agent.cfg upgrade and change is just the expected
comportment when no user has updated it between distro upgrades.

As another point, fusioninventory-agent is useless and will really do
nothing if the configuration file isn't updated by system admin. And
thanks to ucf support in package, the agent.cfg file won't be
overwritten during distro upgrade.

As I'm currently working on fusioninventory-agent packaging to have it
updated to last upstream version in unstable. I'm still confused if we
really need or not to fix something in the package regarding our case.
Maybe we are not using ucf in the right way ? But I studied the problem
for a long time, made tests and I just think this issue is not a bug
for the moment.

What the best way in our case to avoid this upgrade issue report ?

Regards,

Guillaume Bougard
Upstream fusioninventory-agent maintainer
Fusioninventory team


pgpj9sa9JlgbE.pgp
Description: Signature digitale OpenPGP

Bug#850150: freemat ftbfs with LLVM 3.9

[Matthias Klose]

Package: src:freemat
Version:
Severity: important
Tags: sid stretch

[100%] Linking CXX executable FreeMat
cd /home/packages/tmp/freemat-4.2+dfsg1/debian/build/src && /usr/bin/cmake -E
cmake_link_script CMakeFiles/FreeMat.dir/link.txt --verbose=1
/usr/bin/x86_64-linux-gnu-g++   -g -O2
-fdebug-prefix-map=/home/packages/tmp/freemat-4.2+dfsg1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -
D_FORTIFY_SOURCE=2 -O3 -DNDEBUG  -Wl,-Bsymbolic-functions -Wl,-z,relro
CMakeFiles/FreeMat.dir/application.moc.cpp.o
CMakeFiles/FreeMat.dir/application.cpp.o
CMakeFiles/FreeMat.dir/FuncMode.moc.cpp.o
CMakeFiles/FreeMat.dir/ScriptMode.moc.cpp.o
CMakeFiles/FreeMat.dir/FuncMode.cpp.o CMakeFiles/FreeMat.dir/ScriptMode.cpp.o
CMakeFiles/FreeMat.dir/FuncTerminal.cpp.o
CMakeFiles/FreeMat.dir/MainApp.moc.cpp.o CMakeFiles/FreeMat.dir/MainApp.cpp.o
CMakeFiles/FreeMat.dir/main.cpp.o CMakeFiles/FreeMat.dir/DumbTerminal.moc.cpp.o
CMakeFiles/FreeMat.dir/DumbTerminal.cpp.o
CMakeFiles/FreeMat.dir/Terminal.moc.cpp.o CMakeFiles/FreeMat.dir/Loader.cpp.o
CMakeFiles/FreeMat.dir/Terminal.cpp.o CMakeFiles/FreeMat.dir/qrc_FreeMat.cxx.o
CMakeFiles/FreeMat.dir/dummy.f.o  -o FreeMat  -L/usr/lib/llvm-3.9/lib -rdynamic
../libs/libCore/libCore.a ../libs/libFN/libFN.a
../libs/libGraphics/libGraphics.a ../libs/libFreeMat/libFreeMatlib.a
../libs/libXP/libXP.a ../libs/libMex/libMex.a ../libs/libMatC/libMatC.a
../libs/libFN/levmar-2.3/liblevmar.a ../libs/libMath/libLAPACK_C/liblapack_c.a
../libs/libMath/libDynBlas/libdynblas.a ../libs/libMath/libBLAS_C/libblasref.a
-lQtCore -lQtGui -lQtNetwork -lQtOpenGL -lQtXml -lQtSvg -lGLU -lGL -lncurses
-lpcre -lfftw3 -lfftw3f -lz -larpack ../libs/libMath/libLAPACK_C/liblapack_c.a
-lffi -lportaudio -lboost_math_c99 -lclang -lclangAnalysis
-lclangApplyReplacements -lclangARCMigrate -lclangAST -lclangASTMatchers
-lclangBasic -lclangCodeGen -lclangDriver -lclangDynamicASTMatchers -lclangEdit
-lclangFormat -lclangFrontend -lclangFrontendTool -lclangIndex -lclangLex
-lclangParse -lclangQuery -lclangRename -lclangRewrite -lclangRewriteFrontend
-lclangSema -lclangSerialization -lclangStaticAnalyzerCheckers
-lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend -lclangTidy
-lclangTidyGoogleModule -lclangTidyLLVMModule -lclangTidyMiscModule
-lclangTidyReadabilityModule -lclangTidyUtils -lclang
/usr/lib/llvm-3.9/lib/libLLVMExecutionEngine.a
/usr/lib/llvm-3.9/lib/libLLVMOption.a /usr/lib/llvm-3.9/lib/libLLVMIRReader.a
/usr/lib/llvm-3.9/lib/libLLVMLTO.a /usr/lib/llvm-3.9/lib/libLLVMInterpreter.a
/usr/lib/llvm-3.9/lib/libLLVMX86CodeGen.a /usr/lib/llvm-3.9/lib/libLLVMX86Desc.a
/usr/lib/llvm-3.9/lib/libLLVMX86Info.a /usr/lib/llvm-3.9/lib/libLLVMAsmParser.a
/usr/lib/llvm-3.9/lib/libLLVMBitReader.a
/usr/lib/llvm-3.9/lib/libLLVMBitWriter.a /usr/lib/llvm-3.9/lib/libLLVMCodeGen.a
/usr/lib/llvm-3.9/lib/libLLVMipo.a /usr/lib/llvm-3.9/lib/libLLVMLinker.a
/usr/lib/llvm-3.9/lib/libLLVMSelectionDAG.a
/usr/lib/llvm-3.9/lib/libLLVMInstrumentation.a -lclangAnalysis
-lclangApplyReplacements -lclangARCMigrate -lclangAST -lclangASTMatchers
-lclangBasic -lclangCodeGen -lclangDriver -lclangDynamicASTMatchers -lclangEdit
-lclangFormat -lclangFrontend -lclangFrontendTool -lclangIndex -lclangLex
-lclangParse -lclangQuery -lclangRename -lclangRewrite -lclangRewriteFrontend
-lclangSema -lclangSerialization -lclangStaticAnalyzerCheckers
-lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend -lclangTidy
-lclangTidyGoogleModule -lclangTidyLLVMModule -lclangTidyMiscModule
-lclangTidyReadabilityModule -lclangTidyUtils
/usr/lib/llvm-3.9/lib/libLLVMIRReader.a /usr/lib/llvm-3.9/lib/libLLVMAsmParser.a
/usr/lib/llvm-3.9/lib/libLLVMVectorize.a
/usr/lib/llvm-3.9/lib/libLLVMObjCARCOpts.a
/usr/lib/llvm-3.9/lib/libLLVMExecutionEngine.a
/usr/lib/llvm-3.9/lib/libLLVMRuntimeDyld.a -lffi
/usr/lib/llvm-3.9/lib/libLLVMObject.a
/usr/lib/llvm-3.9/lib/libLLVMMCDisassembler.a
/usr/lib/llvm-3.9/lib/libLLVMAsmPrinter.a /usr/lib/llvm-3.9/lib/libLLVMCodeGen.a
/usr/lib/llvm-3.9/lib/libLLVMBitReader.a
/usr/lib/llvm-3.9/lib/libLLVMBitWriter.a
/usr/lib/llvm-3.9/lib/libLLVMInstrumentation.a
/usr/lib/llvm-3.9/lib/libLLVMScalarOpts.a
/usr/lib/llvm-3.9/lib/libLLVMInstCombine.a /usr/lib/llvm-3.9/lib/libLLVMTarget.a
/usr/lib/llvm-3.9/lib/libLLVMTransformUtils.a
/usr/lib/llvm-3.9/lib/libLLVMAnalysis.a
/usr/lib/llvm-3.9/lib/libLLVMProfileData.a
/usr/lib/llvm-3.9/lib/libLLVMMCParser.a
/usr/lib/llvm-3.9/lib/libLLVMDebugInfoCodeView.a
/usr/lib/llvm-3.9/lib/libLLVMX86AsmPrinter.a /usr/lib/llvm-3.9/lib/libLLVMMC.a
/usr/lib/llvm-3.9/lib/libLLVMX86Utils.a /usr/lib/llvm-3.9/lib/libLLVMCore.a
/usr/lib/llvm-3.9/lib/libLLVMSupport.a -lrt -ldl -ltinfo -lpthread -lz -lm
-lgfortran -lquadmath
/usr/lib/llvm-3.9/lib/libclangCodeGen.a(CoverageMappingGen.cpp.o): In function
`(anonymous
namespace)::CounterCoverageMappingBuilder::addCounters(llvm::coverage::Counter,
llvm::coverage::Counter, llvm::coverage::Counter)':
(.text.unlikely._ZN12_GLOBAL__N_129CounterCoverageMappingBuilder11addCounters

Bug#850025: Problem replicated (+ proposed patch)

[Sebastian Ramacher]

On 2017-01-03 13:07:38, Zed Pobre wrote:
> I'm also having this problem.  Some searching shows that the pycrypto
> folks believe that this should be fixed in paramiko:
> 
>   https://github.com/dlitz/pycrypto/issues/149
> 
> A fellow who found a workaround on the paramiko side notes that the
> pycrypto comments in AES.py are wrong now:
> 
>   
> http://uucode.com/blog/2015/02/20/workaround-for-ctr-mode-needs-counter-parameter-not-iv/
> 
> Despite that, I think I agree that paramiko needs to change.  The
> problem is that this is a stable distribution, and the patch that
> causes this problem, used to fix #849495, is really just attempting to
> prevent bad usage by other programs, not inherently fixing a security
> flaw.  In addition, the CTR component isn't actually dangerous, just
> "confusing".
> 
> I propose that you remove the following from src/block_template.c:
> 
> ++  if (IVlen != 0 && mode == MODE_CTR)
> ++  {
> ++  PyErr_Format(PyExc_ValueError,
> ++  "CTR mode needs counter parameter, not IV");
> ++  return NULL;
> ++  }

No, dropping thas would open up the vulnerability again. For jessie the
exception was downgraded to a warning and IVlen set to 0.

For wheezy LTS I sent the updated patch to Chris Lamb (CCed). I'd expect an
update there soon.

Regards

> Leave the rest.  That will still force it to die on the more dangerous
> ECB misuse, but doesn't cause unexpected breakage in other packages
> that are relying on being able to take shortcuts sending an IV string
> even where one isn't needed.
> 
> Regards,
> Zed

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#844294: gnome-shell-extensions: Please re-enable nautilus-classic in gnome-classic.session

[Michael Biebl]

Am 04.01.2017 um 09:29 schrieb intrigeri:

> If this patch was dropped, would it still work to set
> show-desktop-icons via dconf system-wide?

If this patch was dropped, GNOME Classic mode would always show icons on
the desktop. There is no way to override it anymore via the gsettings key.

For the normal GNOME Shell mode, the gsettings key is still read.



-- 
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#835071: openbve: New homepage URL?

[Enrico Zini]

Package: openbve
Version: 1.4.0.10-3
Followup-For: Bug #835071

Hello,

The current Homepage: http://trainsimframework.org/ is not just pointing to a
placeholder page, but to a cybersquatted domain.

Please change it with http://openbve-project.net/ when you can: keeping this
Homepage: field is currently feeding criminals with advertisement revenue.

Enrico


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

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

Bug#850151: emacs-goodies-el: up-to-date version of diminish-el is packaged outside of emacs-goodies-el

[Lev Lamberov]

Source: emacs-goodies-el
Version: 36.3
Severity: minor

Dear Maintainer,

up-to-date version of diminish-el, containing in emacs-goodies-el, was packaged
outside of the emacs-goodies-el package, see [1]. It is team maintained by
Emacs Addons Packaging team. Please, consider removing diminish-el from the
emacs-goodies-el package. Thanks!

Cheers!
Lev Lamberov

[1] https://tracker.debian.org/pkg/diminish-el

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

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

Bug#850152: ITP: node-tweetnacl -- Port of TweetNaCl cryptographic library to JavaScript

[Yashashree Kolhe]

Package: tweetnacl
Severity: wishlist
Owner: Yashashree Kolhe 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-tweetnacl
  Version : 0.14.5
  Upstream Author : TweetNaCl-js contributors
* URL : https://tweetnacl.js.org
* License : Unlicense
  Programming Lang: JavaScript
  Description : Port of TweetNaCl cryptographic library to JavaScript

Bug#848859: FTBFS randomly (failing tests)

[Santiago Vila]

On Wed, Jan 04, 2017 at 08:44:17AM +0100, Ole Streicher wrote:

> > It's in Release Policy: Packages *must* autobuild *without* failure.
> > 
> > If a package fails to build from time to time, that's a failure.
> 
> Packages actually *do* fail from time to time, when I look into my
> autobuilder. Not due to the package, but due to glitches within the
> buildd infrastructure. Would you consider this a failure?

If the package is not to blame, of course not.

I'm speaking about packages which intrinsically fail with a
probability p such that 0 < p < 1. Funny example of what
I call "instrinsically":

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

No matter how much glitch-free is the autobuilder you use to build the
above package, it will fail to build 1 every 147 times on average,
mathematically, because the test is wrongly designed.

> >> I totally agree that catching random failures
> >> is a good quality measure, but this is IMO severity "important" at maximum.
> > 
> > Well, would you say it's RC if it fails 99% of the time?
> > I guess you would.
> 
> I would consider a bug RC if it actually doesn't build on our buildds.

Aha! But *that* is what is not written in policy anywhere.

Not only it's not written anywhere, it's invalidated by current practice
every day. Examples here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lamby%40debian.org

or here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lucas%40debian.org

or even here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=sanvila%40debian.org


Are you proposing that Lucas Nussbaum, Chris Lamb or myself stop
reporting FTBFS bugs as serious unless we can point to a failed build
log at buildd.debian.org?

That restricted way of reporting bugs surely may not be right.

> [...]
> Doing release QA just before the release leads to quick hacks to keep
> things there, while a continious QA really solves them.

Well, I started doing QA more than a year ago, to check for
"dpkg-buildpackage -A". As a side effect, I started to report each
and every package which FTBFS for whatever reason.

Really, we need more people doing QA, and not stop doing it "because
we are near the freeze".

Thanks.

Bug#841089: wrong file type recognized for J2K and WEBP images (and most likely SGI, EXR, JP2, PFM, PICT, RAW, JXR)

[Boris Lesner]

Hi,

I am not a FreeImage dev at all, just a user who encountered a bug and 
tried to fix it.
Maybe my patch wasn't the best way to solve this issue, it passed a very 
basic unit test

but was merely a suggestion.

The real problem here is that a previous debian patch in FreeImage, 
disabled the support

for the Fax G3 format in FreeImage.

Long story short: this is the patch at the root of this issue. FreeImage 
is not meant to be

used with only part of its image support.

The longer version:
This previous patch also baldy broke some client code
(in my case, using FreeImage to save a Jpeg2000 image actually saved it 
as an OpenEXR,
this problem happened for many other formats). I short, the problem was 
that some
enums (from FREE_IMAGE_FORMAT) naming image formats did no longer had 
the intended meaning.


My patch fixed this issue but at the cost of NULL checking the return of 
some API functions, or

calling FreeImage_FIFSupportsReading ().
However this may or may not be an API breakage since the FreeImage 
documentation does not
says the returned pointers (at least for FreeImage_GetFIFExtensionList) 
are not NULL (but
a quick code review *seems* to show that in practice they can be NULL 
[1], even tough it is not
specified so). This may possibly break many clients (like OGRE) since 
they relied on

unspecified behavior (and thus were not correct in the first place).

The best solution - I believe - is to put back the support for the G3 
format. Since my patch and
the previous one both introduce some kind of API breakage. This is 
mostly due to a badly designed
image format plugin system in FreeImage, I don't believe we can remove 
support for a format

without changing the API.

As a side note, the first patch maybe already broke some clients of OGRE 
as the G3 format is no

longer supported.

Best Regards,

-- Boris

[1] There are quite a few conditions that can cause this function to 
return NULL but I'm not sure

  they are ever fulfilled.

On 03/01/2017 12:50, James Cowgill wrote:

Hi Boris,

Your patch to fix this bug broke OGRE (completely - nothing that uses it
will start) because it dereferences the NULL pointer now returned by
FreeImage_GetFIFExtensionList. See https://bugs.debian.org/849696.

Did you consider this when you wrote your patch? Who's right here - your
patch or OGRE? I am concerned about this patch because it effectively
changes the freeimage API and potentially forces a number of
reverse-dependencies of freeimage to change their code.

Thanks,
James

Bug#850153: icedove crash when resizing window

[Eric Smith]

Package: icedove
Version: 1:45.5.1-1~deb8u1
Severity: important

Dear Maintainer,

Icedove has been extremely unstable for me since the 1.45.5 update.
There seem to be a number of situations which cause crashes, some of
which I think others have reported. I haven't seen a report for this
particular crash though. In this case I attempted to resize the mail
window and the program crashed. I was running in safe mode and with
the debugger active, so I was able to obtain a gdb trace, which I've
included below.

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

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3+deb8u1
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u6
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.32.6-3
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.5.1-1~deb8u1

Versions of packages icedove suggests:
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u2

-- no debconf information

MOZILLA_FIVE_HOME=/usr/lib/icedove
  
LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove:/usr/lib/nx/X11/Xinerama:/usr/lib/nx/X11
DISPLAY=:50.0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin --safe-mode
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from 
/usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.
(gdb) run
Starting program: /usr/lib/icedove/icedove-bin --safe-mode
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe7eaa700 (LWP 26762)]
[Thread 0x7fffe7eaa700 (LWP 26762) exited]
[New Thread 0x7fffe7eaa700 (LWP 26774)]
[New Thread 0x7fffe0eff700 (LWP 26775)]
[New Thread 0x77fd3700 (LWP 26776)]
[New Thread 0x7fffe06fe700 (LWP 26777)]
[New Thread 0x7fffdfbff700 (LWP 26778)]
[New Thread 0x7fffdf9fe700 (LWP 26779)]
[New Thread 0x7fffdf7fd700 (LWP 26780)]
[New Thread 0x7fffdf5fc700 (LWP 26781)]
[New Thread 0x7fffdf3fb700 (LWP 26782)]
[New Thread 0x7fffdf1fa700 (LWP 26783)]
[New Thread 0x7fffdeff9700 (LWP 26784)]
[New Thread 0x7fffdedf8700 (LWP 26785)]
[New Thread 0x7fffdebf7700 (LWP 26786)]
[New Thread 0x7fffde9f6700 (LWP 26787)]
[New Thread 0x7fffde7f5700 (LWP 26788)]
[New Thread 0x7fffde5f4700 (LWP 26789)]
[New Thread 0x7fffde3f3700 (LWP 26790)]
[New Thread 0x7fffde1f2700 (LWP 26791)]
[New Thread 0x7fffdceff700 (LWP 26792)]
[New Thread 0x7fffdc2ff700 (LWP 26

Bug#846352: jessie-pu: package nvidia-graphics-drivers/340.98-1

[Andreas Beckmann]

Control: retitle -1 jessie-pu: package nvidia-graphics-drivers/340.101-1

On 2016-12-31 18:36, Adam D. Barratt wrote:
> On Wed, 2016-11-30 at 15:53 +0100, Andreas Beckmann wrote:
>> again we have some CVEs in the proprietary nvidia driver:
>> CVE-2016-7382, CVE-2016-7389: #846331

> Please go ahead; apologies for the delay.

I just uploaded the next upstream release 340.101 fixing another CVE:

  * New upstream legacy 340xx branch release 340.101 (2016-12-14).
* Fixed CVE-2016-8826.  (Closes: #848195)
* Improved compatibility with recent Linux kernels.

Some patches added/removed, but no further packaging changes over the
big lot in 340.98.

Andreas

Bug#849569: spice: Please package 0.13 branch to experimental

[Erik Adler]

... crickets from their devs. Its a judgment call from Debian not RedHat
when and where this goes in. Users can still use Spice 0.13.x without
actually enabling gl=on if they want. I don’t see how it would brake
anything. If people want to punch holes into their vm with unix sockets
it should be up to them imho. Some have been waiting years for this
feature. Maybe it is about time. What do you guys think?

All the best

Erik Adler
GPG/PGP key ID: 0x2B4B58FE
gpg --keyserver pgp.mit.edu --recv-keys 0x2B4B58FE

Bug#850013: vim-youcompleteme: Please provide a newer version, the current one doesn't work any more

[Reiner Herrmann]

Control: severity -1 grave

Raising severity as the package is unusable currently.


signature.asc
Description: Digital signature

Bug#849312: apt: dist-upgrade removes pkgs instead of upgrading them

[Olaf van der Spek]

2017-01-04 11:33 GMT+01:00 David Kalnischkies :
> On Tue, Jan 03, 2017 at 10:29:19AM +0100, Olaf van der Spek wrote:
>> 2016-12-25 13:12 GMT+01:00 David Kalnischkies :
>> >> Can't it detect mariadb-server-10.1 being a proper upgrade of
>> >> mariadb-server-10.0 and hence scoring this as neutral or positive?
>> >
>> > In general no, because that isn't a positive upgrade: It involves the
>>
>> 10.1 declares replaces on 10.0 doesn't it?
>> Doesn't apt use this information?
>
> It doesn't because the 'Replaces' is only there to tell dpkg that it is
> okay that this package overrides some files of another package. That
> frequently happens then a single package is split into a bunch (like
> foo, foo-data, foo-plugins-extra). It does also happen then two packages

In this case it'd be fine to use the info right?

> 'fight' over a particalur path in the filesystem and that fight was
> resolved: like in the git, chromium or node cases just to name a few big
> and popular ones. I somehow doubt you consider a spaceshooter an upgrade
> to a browser (or well, actually the other way around – which was the
> chromium case).

So exactly what are we trying to prevent here?
Apparently apt is already happy to propose the removal of packages..

> See Debian policy §7.6.1 for details. See also §7.6.2 – but don't get
> your hopes up in terms of upgrades: You wouldn't like apt to constantly
> flip between postfix and exim4 either…

Do exim and postfix declare Replaces on each other?



-- 
Olaf

Bug#850113: vim-youcompleteme: 'KeyError's on every key press flooding vim

[Reiner Herrmann]

Control: severity -1 grave

Raising severity as the package is not usable currently.


signature.asc
Description: Digital signature

Bug#849569: spice: Please package 0.13 branch to experimental

[Michael Tokarev]

04.01.2017 16:00, Erik Adler wrote:
> ... crickets from their devs. Its a judgment call from Debian not RedHat
> when and where this goes in.

Yes. And if my opinion as a debian developer weights anything, I'd
like to hear what the developers actually think, before making any
decision. I wrote some software too, and I knew when I think it is
ready or when it is full of security holes which needs fixing before
going to production. In this case I didn't wrote spice so I can't
know this, and I don't even know why it is still called beta, with
odd-numbered release number.

>  Users can still use Spice 0.13.x without
> actually enabling gl=on if they want. I don’t see how it would brake
> anything. If people want to punch holes into their vm with unix sockets

Besides gl, there were other changes in other areas. Protocol
changes (to enable gl) were introduced too. If we're to package
software with wire protocol which will be changed before stable
release, we'll have to support our users with that protocol for
some time, even if upstream developers don't support it anymore.
We'll have to ensure that different versions of different components
work together, despite they using different protocol. This is
just insane. If you don't believe me, try it out yourself first.
We've been there, done that, and I for one don't want to repeat
that experiment.

Again, that's why I want to hear from developers, at least, how
stable the protocol is, are there any plans to change it before
0.14 (stable) version or not. And for other changes which were
made, how good these parts are.

> it should be up to them imho. Some have been waiting years for this
> feature. Maybe it is about time. What do you guys think?

It's time when it's ready, not when users want it, unfortunately.
We can't give anything to users before it is actually ready.

Thanks,

/mjt

Bug#528058: ADMIN SUPPORT

[Travis Champion]

From: Travis Champion
Sent: Wednesday, January 04, 2017 4:27 AM
Subject: ADMIN SUPPORT

Your mail account has been moved to a new server on our network. You are to 
verify your account please click 
here:

ADMIN SUPPORT TEAM

Bug#850154: jessie-pu: package nvidia-graphics-modules/340.101+3.16.0+1

[Andreas Beckmann]

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

As a followup to updating nvidia-graphics-drivers to a new upstream
release, we also need to update the prebuilt kernel modules.


Andreas
diff -Nru nvidia-graphics-modules-340.96+3.16.0+1/debian/changelog nvidia-graphics-modules-340.101+3.16.0+1/debian/changelog
--- nvidia-graphics-modules-340.96+3.16.0+1/debian/changelog	2015-12-15 23:41:22.0 +0100
+++ nvidia-graphics-modules-340.101+3.16.0+1/debian/changelog	2017-01-04 14:13:07.0 +0100
@@ -1,3 +1,10 @@
+nvidia-graphics-modules (340.101+3.16.0+1) jessie; urgency=medium
+
+  * Use nvidia-kernel-source 340.101.
+  * Upload to jessie.
+
+ -- Andreas Beckmann   Wed, 04 Jan 2017 14:13:07 +0100
+
 nvidia-graphics-modules (340.96+3.16.0+1) jessie; urgency=medium
 
   * Use nvidia-kernel-source 340.96.
diff -Nru nvidia-graphics-modules-340.96+3.16.0+1/debian/control nvidia-graphics-modules-340.101+3.16.0+1/debian/control
--- nvidia-graphics-modules-340.96+3.16.0+1/debian/control	2015-12-15 23:41:22.0 +0100
+++ nvidia-graphics-modules-340.101+3.16.0+1/debian/control	2017-01-04 14:13:07.0 +0100
@@ -8,7 +8,7 @@
  Vincent Cheng 
 Build-Depends: debhelper (>= 9),
  linux-headers-3.16.0-4-amd64 [i386 amd64], linux-headers-3.16.0-4-586 [i386], linux-headers-3.16.0-4-686-pae [i386],
- nvidia-kernel-source (>= 340.96), nvidia-kernel-source (<< 340.96.~),
+ nvidia-kernel-source (>= 340.101), nvidia-kernel-source (<< 340.101.~),
 Standards-Version: 3.9.6
 Homepage: http://www.nvidia.com/
 Vcs-Git: git://anonscm.debian.org/pkg-nvidia/nvidia-graphics-modules.git -b jessie
@@ -18,7 +18,7 @@
 Package: nvidia-kernel-dummy
 Architecture: amd64
 Priority: extra
-Depends: nvidia-kernel-source (>= 340.96), ${misc:Depends}
+Depends: nvidia-kernel-source (>= 340.101), ${misc:Depends}
 Description: NVIDIA kernel module for Linux (dummy package)
  This dummy package exists solely to ensure that the prebuilt modules do not
  migrate to testing before the corresponding driver is available. Nothing is
@@ -39,7 +39,7 @@
 
 Package: nvidia-kernel-amd64
 Architecture: i386 amd64
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-amd64 (>= 340.96)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-amd64 (>= 340.101)
 Conflicts: nvidia-kernel-2.6-amd64
 Replaces: nvidia-kernel-2.6-amd64
 Description: NVIDIA kernel module for Linux (amd64 flavor)
@@ -57,7 +57,7 @@
 
 Package: nvidia-kernel-586
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-586 (>= 340.96)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-586 (>= 340.101)
 Conflicts: nvidia-kernel-2.6-586
 Replaces: nvidia-kernel-2.6-586
 Description: NVIDIA kernel module for Linux (586 flavor)
@@ -75,7 +75,7 @@
 
 Package: nvidia-kernel-686-pae
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-686-pae (>= 340.96)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-686-pae (>= 340.101)
 Conflicts: nvidia-kernel-2.6-686-pae
 Replaces: nvidia-kernel-2.6-686-pae
 Description: NVIDIA kernel module for Linux (686-pae flavor)
diff -Nru nvidia-graphics-modules-340.96+3.16.0+1/debian/control.md5sum nvidia-graphics-modules-340.101+3.16.0+1/debian/control.md5sum
--- nvidia-graphics-modules-340.96+3.16.0+1/debian/control.md5sum	2015-12-15 23:41:22.0 +0100
+++ nvidia-graphics-modules-340.101+3.16.0+1/debian/control.md5sum	2017-01-04 14:13:07.0 +0100
@@ -1,7 +1,7 @@
-c1e0284ab90035ad346ff9ae821183b4  debian/control
+6599e95d0f55c17f3f1cdf4adf6b1cc1  debian/control
 cebaad312eecf5eb135ccc2acc8525aa  debian/control.source
 fffd77960b50d626b720a23ee441a9ed  debian/control.flavor
 3fb001417b44d7fcc3af963390d49a9f  debian/rules
 11f3f9885d447eb0c3968882ecd33c68  debian/rules.defs
-#UPSTREAM_VERSION=340.96#
+#UPSTREAM_VERSION=340.101#
 #KERNEL_VERSION=3.16.0-4#

Bug#835071: openbve: New homepage URL?

[Paul Sladen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

tags 835071 + patch easy
thanks

https://anonscm.debian.org/cgit/pkg-cli-apps/packages/openbve.git/commit/?id=b04d4dc
https://anonscm.debian.org/cgit/pkg-cli-apps/packages/openbve-data.git/commit/?id=aba6

A grep shows lots of additional instances, so I'm wondering whether
it's worth introducing a patch to update the links in the
documentation and user-interface too.

-Paul
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFYbPQjc444tukM+iQRAgkkAJ9/rwx3g88cjBNNfOD4Oofd5CwuYQCeKbiv
Rs905RejK/qpqw98TGIgl/0=
=oZvS
-END PGP SIGNATURE-

Bug#821333: snapshot.debian.org: should advertise source-specific [check-valid-until=false] in preference to system-wide flag

[Jochen Sprickerhof]

Package: snapshot.debian.org
Followup-For: Bug #821333

Please find a patch attached.
Thanks for the really useful service.

Cheers Jochen
>From 263d34e0b8abf7d06b16242672c6d37b179b7503 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Wed, 4 Jan 2017 14:30:29 +0100
Subject: [PATCH] Use check-valid-until option in source

---
 web/app/snapshot/templates/description.mako | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/web/app/snapshot/templates/description.mako 
b/web/app/snapshot/templates/description.mako
index db3495a..5c1dc72 100644
--- a/web/app/snapshot/templates/description.mako
+++ b/web/app/snapshot/templates/description.mako
@@ -54,10 +54,10 @@ If you want to add a specific date's archive to your apt 
sources.list
 
-deb http://snapshot.debian.org/archive/debian/20091004T111800Z/
 lenny main
-deb-src http://snapshot.debian.org/archive/debian/20091004T111800Z/
 lenny main
-deb http://snapshot.debian.org/archive/debian-security/20091004T121501Z/
 lenny/updates main
-deb-src http://snapshot.debian.org/archive/debian-security/20091004T121501Z/
 lenny/updates main
+deb [check-valid-until=no] http://snapshot.debian.org/archive/debian/20091004T111800Z/
 lenny main
+deb-src [check-valid-until=no] http://snapshot.debian.org/archive/debian/20091004T111800Z/
 lenny main
+deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-security/20091004T121501Z/
 lenny/updates main
+deb-src [check-valid-until=no] http://snapshot.debian.org/archive/debian-security/20091004T121501Z/
 lenny/updates main
 
 
 To learn which snapshots exist, i.e. which date strings are valid, simply
@@ -69,9 +69,7 @@ available timestamp which is before the time you specified.
 
 To access snapshots of suites using Valid-Until that are older than a dozen 
days,
 it is necessary to ignore the Valid-Until header within Release files, in order
-to prevent apt from disregarding snapshot entries ("Release file expired").  
Use
-aptitude -o Acquire::Check-Valid-Until=false update or
-apt-get -o Acquire::Check-Valid-Until=false update for this 
purpose.
+to prevent apt from disregarding snapshot entries ("Release file expired").
 
 
 
-- 
2.11.0

Bug#849505: nodejs 6.9 in unstable, manual transition, schedule

[Emilio Pozuelo Monfort]

On 04/01/17 12:02, Jérémy Lal wrote:
> 2017-01-04 11:56 GMT+01:00 Jonas Smedegaard :
>> Quoting Jérémy Lal (2017-01-04 10:12:44)
>>> 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin :
 On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote:
> i really think it would be best to have nodejs 6.9 in next debian release.
> That version is currently in experimental and i was about to upload it
> to unstable, but i tried to do things right and prepared the addons
> that need to be rebuilt and binNMUed, then opened a transition bug
> #849505.
> No answer yet, people are busy, and the number of concerned packages
> is low (a dozen or so), should i just rebuild and upload them myself ?
 The transition freeze was on Nov 5.
>>>
>>> This is not very smart - i'm talking about something that will make
>>> future maintenance and security patches easier, something that is easy
>>> to do and that i can even do alone.
>>> Contrast this with an openssl 1.1 upload few days before the
>>> transition freeze. I don't get it.
>>
>> libssl transition was coordinated with the release team well before the
>> freeze.
>> Apart from giving up and let things rest as they are (or fall apart and
>> get kicked out), I believe there is also the option of asking the
>> release team for permission to do the transition even if late.
> 
> Oh, i thought transition bugs were read by release team.
> Please, release team ?

Sorry but this is way too late. Shipping the latest upstream release always
makes it easier to backport fixes, but at some point we need to stop accepting
transitions in order to stabilise and prepare for the release. That point was
two months ago.

Cheers,
Emilio

Bug#850155: keystone: postinst throws error

[Bjoern Boschman]

Package: keystone
Version: 2:9.0.0-2~bpo8+1
Severity: normal

Dear Maintainer,

during installation of keystone on a plain host the following error occurs:

Setting up keystone (2:9.0.0-2~bpo8+1) ...
PKG-Openstack now calling: dbc_go keystone configure
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/keystone.conf
keystone already exists and has privileges on keystonedb.
creating database keystonedb: already exists.
dbconfig-common: flushing administrative password
Unknown suffix ':' used for variable 'port' (value ':3306')
mysql: Error while setting value ':3306' to 'port'
dpkg: error processing package keystone (--configure):
 subprocess installed post-installation script returned error exit status 9
Errors were encountered while processing:
 keystone
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

Kernel: Linux 3.16.0-4-amd64 (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/dash
Init: systemd (via /run/systemd/system)

Versions of packages keystone depends on:
ii  adduser 3.113+nmu3
ii  dbconfig-common 2.0.6~bpo8+1
ii  debconf [debconf-2.0]   1.5.56
ii  init-system-helpers 1.22
ii  lsb-base4.1+Debian13+nmu1
ii  python  2.7.9-1
ii  python-keystone 2:9.0.0-2~bpo8+1
ii  python-q-text-as-data [q-text-as-data]  1.4.0-1~bpo8+1
ii  sqlite3 3.8.7.1-1+deb8u2
ii  ssl-cert1.0.35

keystone recommends no packages.

Versions of packages keystone suggests:
pn  apparmor  

-- debconf information:
* keystone/admin-password: (password omitted)
  keystone/mysql/admin-pass: (password omitted)
* keystone/admin-password-confirm: (password omitted)
  keystone/app-password-confirm: (password omitted)
  keystone/pgsql/admin-pass: (password omitted)
  keystone/password-confirm: (password omitted)
* keystone/auth-token: (password omitted)
  keystone/pgsql/app-pass: (password omitted)
  keystone/mysql/app-pass: (password omitted)
* keystone/configure_db: true
  keystone/region-name: regionOne
  keystone/pgsql/admin-user: postgres
  keystone/pgsql/manualconf:
* keystone/endpoint-ip: 172.22.190.217
  keystone/passwords-do-not-match:
  keystone/missing-db-package-error: abort
  keystone/remote/newhost:
  keystone/internal/reconfiguring: false
  keystone/purge: false
  keystone/admin-email: root@localhost
  keystone/db/dbname: keystonedb
  keystone/remove-error: abort
  keystone/remote/port:
  keystone/dbconfig-upgrade: true
  keystone/dbconfig-reinstall: false
  keystone/admin-user: admin
  keystone/db/basepath: /var/lib/keystone
* keystone/dbconfig-install: true
  keystone/pgsql/method: TCP/IP
  keystone/db/app-user: keystone@localhost
  keystone/pgsql/authmethod-admin: ident
  keystone/admin-tenant-name: admin
  keystone/internal/skip-preseed: false
  keystone/upgrade-error: abort
  keystone/install-error: abort
* keystone/register-endpoint: true
  keystone/admin-role-name: admin
  keystone/pgsql/authmethod-user: password
* keystone/database-type: mysql
  keystone/mysql/method: Unix socket
  keystone/dbconfig-remove: true
* keystone/create-admin-tenant: true
  keystone/pgsql/changeconf: false
  keystone/remote/host: localhost
  keystone/pgsql/no-empty-passwords:
  keystone/upgrade-backup: true
* keystone/mysql/admin-user: debian-sys-maint

-- 
Mit freundlich Grüßen / Kind regards
Björn Boschman

Bug#843998: plymouth theme missing for softwaves

[Michael Biebl]

Hi Aurélien,

nice work. Thanks a lot!

Do you know what is missing to have fsck progress support in plymouth?
Is that a theme issue or something which needs to be supported by
plymouth (or both)?

I know, SSDs are more popular these days so long fsck times are not that
common anymore. Would still be nice to have support for that in
plymouth, otherwise it's rather pointless to ship fsckd in systemd [1].

CCed Laurent and Laurent, maybe they have some input on this. Would be
great if we can fix this for stretch

Regards,
Michael


[1]
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/debian/fsckd-daemon-for-inter-fsckd-communication.patch

-- 
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#849505: nodejs 6.9 in unstable, manual transition, schedule

[Jérémy Lal]

2017-01-04 14:32 GMT+01:00 Emilio Pozuelo Monfort :
> On 04/01/17 12:02, Jérémy Lal wrote:
>> 2017-01-04 11:56 GMT+01:00 Jonas Smedegaard :
>>> Quoting Jérémy Lal (2017-01-04 10:12:44)
 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin :
> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote:
>> i really think it would be best to have nodejs 6.9 in next debian 
>> release.
>> That version is currently in experimental and i was about to upload it
>> to unstable, but i tried to do things right and prepared the addons
>> that need to be rebuilt and binNMUed, then opened a transition bug
>> #849505.
>> No answer yet, people are busy, and the number of concerned packages
>> is low (a dozen or so), should i just rebuild and upload them myself ?
> The transition freeze was on Nov 5.

 This is not very smart - i'm talking about something that will make
 future maintenance and security patches easier, something that is easy
 to do and that i can even do alone.
 Contrast this with an openssl 1.1 upload few days before the
 transition freeze. I don't get it.
>>>
>>> libssl transition was coordinated with the release team well before the
>>> freeze.
>>> Apart from giving up and let things rest as they are (or fall apart and
>>> get kicked out), I believe there is also the option of asking the
>>> release team for permission to do the transition even if late.
>>
>> Oh, i thought transition bugs were read by release team.
>> Please, release team ?
>
> Sorry but this is way too late. Shipping the latest upstream release always
> makes it easier to backport fixes, but at some point we need to stop accepting
> transitions in order to stabilise and prepare for the release. That point was
> two months ago.

That's too bad for debian stable, especially considering the high
level of compatibility
between the two versions, the transition could have been quick and painless.

Jérémy

Bug#850156: Please firmly deprecate vendor-specific series files

[Ian Jackson]

Package: dpkg-dev, debian-policy
Version: 1.17.27, 3.9.8.0

dpkg-source has a surprising and not-very-well-documented feature,
that it is possible to have in a `3.0 (quilt)' package a
vendor-specific series file, which is used only if the vendor matches
that of the running host.[1]

This feature is a very bad idea.  I can see why people thought it
might be nice: it means you can use the same (or very similar) .dsc
(and perhaps vcs history) on different distros.

But it is quite wrong, because it means that the same source package
has different "contents" on different computers.

For example, if I am a Debian contributor and I download the Ubuntu
version of the package and build it to see how it works, I actually
get the Debian version.  And vice versa.

The version of the package you get should depend on where you got the
package from, not where you are looking at it.

There are only a handful of packages in current Debian that use this
feature.[2]

Concretely, I would like the following changes made:

 In dpkg-source:

 * Remove all traces of this feature from the documentation, except to
   mention it in the source format 3.0 description as a deprecated
   feature.

 * Whenever a package is being extracted has a non-default series
   file, print a big warning (regardless of whether the non-default
   series file is going to be used).

 * Warn that dpkg-source in buster will refuse to generate a `3.0
   (quilt)' source package containing non-default series files.

 * Warn that dpkg-source in buster will never apply anything other
   than the default series file (reestablishing a uniform meaning of
   all source packages on all computers).

 In policy:

 * Say that a package MUST NOT contain a non-default series file.
   (obviously with an expectation that these newly-declared RC bugs
   will not be fixed in stretch)

 (And the consequential lintian change.)

I am not yet supplying patches for dpkg-source and for policy, because
I think deprecating this feature will involve some discussion.

Ian.

PS: Of course I have an angle.  dgit depends on the assumption that a
source package means a particular tree.  This feature breaks that
assumption, and as a result dgit must always fail on packages where
this feature is in use.

[1]
 in dpkg.git, 4fa01b70df1dc4458daee306cfa1f987b69da58c
 "dpkg-source: correctly create .pc/.quilt_series with alternate series files"

[2] In private email, Guillem wrote to me:

 It seems it is "documented" (not very explicitly though, search for
 /debian\.series/ in dpkg-source(1)). And several (but not many)
 packages at least in Debian use this:

 ,---
 $ apt-file -x -I dsc search 'debian/patches/.*\.series'
 ddccontrol: /debian/patches/ubuntu.series
 deluge: /debian/patches/ubuntu.series
 fail2ban: /debian/patches/neurodebian-backport.series
 hexchat: /debian/patches/ubuntu.series
 libfreenect: /debian/patches/neurodebian-backport.series
 libxbean-java: /debian/patches/bootstrap.series
 libxbean-java: /debian/patches/full.series
 libxfce4util: /debian/patches/ubuntu.series
 lilo: /debian/patches/ubuntu.series
 mixxx: /debian/patches/ubuntu.series
 packagekit: /debian/patches/ubuntu.series
 qjackctl: /debian/patches/ubuntu.series
 smuxi: /debian/patches/ubuntu.series
 xfce4-smartbookmark-plugin: /debian/patches/ubuntu.series
 zlib: /debian/patches/debian.series
 `---

 Not sure if this is more widespread in other derivatives.

-- 
Ian JacksonThese 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#821051: [PATCH v3 3/3] dak.conf: add packages that trigger byhand-code-sign

[Helen Koike]

On 2016-12-12 07:35 PM, Joerg Jaspert wrote:

On 14519 March 1977, Ben Hutchings wrote:


We offer the archives, including security, by rsync too.
And that should stay. Mirrors of security do exist, for good
reasons.[1]
Why does it need to be in the archive?

[...]
I don't know of any other way of getting files back out of dak.


So my first thought it will be. Some random structure on some random
place. Possibly an apache run by DSA or so, but nothing relying on our
mirrors.


Should we request DSA team to setup this then? What is the next step?



As "getting files back out of dak" is simple. dak writes files where we
tell it to, see for example our changelog/metadata exports, buildd
queues, etc which don't live on the usual mirror network.

Bug#850157: Please deprecate all ad-hoc patch systems

[Ian Jackson]

Package: debian-policy
Version: 3.9.8.0

The policy section "Source package handling: debian/README.source"
should be entirely replaced with a requirement that

  Running dpkg-source -x on a source package MUST produce the source
  of the package, ready for editing, and allow one to make changes,
  and run dpkg-buildpackage to produce a modified package, without
  taking any additional steps.

  If the upstream or Debian source code maintenance practices applying
  to the package are nontrivial (for example, if the uploaded source
  package is itself generated from a metarepository), this should be
  documented in debian/README.source.

And one could probably add

  Previously, packages which had ad-hoc patch systems would document
  their source code management practices in debian/README.source.
  Source packages now MUST NOT use in-source-package patch systems
  other than `3.0 (quilt)'.

Ian.

-- 
Ian JacksonThese 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#822604: scanmem: depends on gksu which is deprecated

[Vincent Bernat]

 ❦  4 janvier 2017 12:08 +0100, Sebastian Parschauer  :

>> Thanks, that hint was crucial. I've implemented all that and updated the
>> source branch. Should be ready for upload now.
>> 
>> https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc
>
> Andrea Stacchiotti (in CC) reported that the upload would fix all three
> pending Debian bugs for the scanmem package.
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=scanmem
>
> It also fixes most issues seen here:
>
> https://tracker.debian.org/pkg/scanmem
>
> And of cause all four Ubuntu package bugs.
>
> All bugs are fixed by the new upstream version.
>
> Should I append the following lines to the new upstream release entry in
> debian/changelog?
>
>+ Closes #618464
>+ Closes #689057
>+ Closes #822604
>
> This should auto-close these bugs, right?

Yes. You can compress to: "Closes #618464, #689057, #822604."
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#844568: jack: diff for NMU version 3.1.1+cvs20050801-29.2

[Mattia Rizzolo]

Control: tags 844568 + pending

Dear maintainer,

I've prepared an NMU for jack (versioned as 3.1.1+cvs20050801-29.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

BTW, I did this NMU using dgit, and it's the first time I use it, I hope
nothing went wrong.

Regards.

-- 
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  `-
diffstat for jack_3.1.1+cvs20050801-29.1 jack_3.1.1+cvs20050801-29.2

 debian/patches/99b_eyed07_compat.patch  |  188 
 jack-3.1.1+cvs20050801/debian/changelog |9 +
 jack-3.1.1+cvs20050801/debian/control   |2 
 3 files changed, 198 insertions(+), 1 deletion(-)

diff -u jack-3.1.1+cvs20050801/debian/changelog jack-3.1.1+cvs20050801/debian/changelog
--- jack-3.1.1+cvs20050801/debian/changelog
+++ jack-3.1.1+cvs20050801/debian/changelog
@@ -1,3 +1,12 @@
+jack (3.1.1+cvs20050801-29.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Gaetano Guerriero  to be compatible
+with eyed3 0.7.x.  Closes: #844568
+  * Require python-eyed3 >= 0.7.
+
+ -- Mattia Rizzolo   Wed, 04 Jan 2017 14:36:45 +0100
+
 jack (3.1.1+cvs20050801-29.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u jack-3.1.1+cvs20050801/debian/control jack-3.1.1+cvs20050801/debian/control
--- jack-3.1.1+cvs20050801/debian/control
+++ jack-3.1.1+cvs20050801/debian/control
@@ -7,7 +7,7 @@
 
 Package: jack
 Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, python-cddb, python-eyed3, python-pyvorbis (>= 0.5) | python-mutagen, cdparanoia | cdda2wav, vorbis-tools | flac | lame
+Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, python-cddb, python-eyed3 (>= 0.7), python-pyvorbis (>= 0.5) | python-mutagen, cdparanoia | cdda2wav, vorbis-tools | flac | lame
 Description: Rip and encode CDs with one command
  Jack has been developed with one main goal: making OGGs (or MP3s)
  without having to worry. There is nearly no way that an incomplete rip
only in patch2:
unchanged:
--- jack-3.1.1+cvs20050801.orig/debian/patches/99b_eyed07_compat.patch
+++ jack-3.1.1+cvs20050801/debian/patches/99b_eyed07_compat.patch
@@ -0,0 +1,188 @@
+Description: compatibility with eyed3 0.7.x
+Author: Gaetano Guerriero 
+Bug-Debian: https://bugs.debian.org/844568
+
+
+diff --git a/jack_globals.py b/jack_globals.py
+index 35fe371..1fbb8db 100644
+--- a/jack_globals.py
 b/jack_globals.py
+@@ -17,11 +17,11 @@
+ ### along with this program; if not, write to the Free Software
+ ### Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ 
+-from jack_constants import *
+ from jack_config import cf
+-from jack_init import eyeD3
++from jack_constants import *
++from jack_generic import debug, error, expand, info, warning
++from jack_init import eyed3
+ 
+-from jack_generic import info, warning, debug, error, expand
+ #import jack_generic
+ #error = jack_generic.error
+ 
+@@ -43,5 +43,4 @@ def debug(x):
+ revision = 0# initial revision of freedb data
+ is_submittable = 0  # well-formed freedb-file?
+ 
+-id3genres = eyeD3.genres
+-
++id3genres = eyed3.id3.ID3_GENRES
+diff --git a/jack_init.py b/jack_init.py
+index b968428..b317738 100644
+--- a/jack_init.py
 b/jack_init.py
+@@ -16,11 +16,12 @@
+ ### along with this program; if not, write to the Free Software
+ ### Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ 
++import os
+ import string
+ import sys
+-import os
+-from jack_globals import *
++
+ from jack_generic import *
++from jack_gl

Bug#850158: Use of uninitialized memory in unserialize()

[Henri Salo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: php7.0
Version: 7.0.14-2
Severity: important
Tags: security, upstream, fixed-upstream

There was found a bug showing that PHP uses uninitialized memory during calls to
`unserialize()`. As the following report shows, the payload supplied to
`unserialize()` may control this uninitialized memory region and thus may be
used to trick PHP into operating on faked objects and calling attacker
controlled destructor function pointers. The supplied proof of concept exploit
practically demonstrates the issue by executing arbitrary code solely by passing
a specially crafted string to `unserialize()`. Even though this particular demo
exploit only works locally this flaw is very likely to also allow for remote
code execution.

Upstream bug report for additional details: 
https://bugs.php.net/bug.php?id=73832
Fix: https://gist.github.com/anonymous/9fbe5ccbe8e18659bec11ac963fd07a3

- -- 
Henri Salo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYbP5hAAoJECet96ROqnV0rmIP/j0HpcNDEpNJTeR+JN75jC90
quuTqH98Neibb3WZEHHHksFVbKohmDm/KVQ1E7AWe6+zZ4FfEoPOsBkhoK2Swfv0
VTB7NVKFhlqmPwnVaB3l/6fc58mtyy6ljPcd/KIr1n3DCRbHgo13QmsgHBFSoqMs
WhJ0CB4NR87/qGqmuHabT1wkzwIB90uApbwBlDRpPTA54XWLRPoIZNlb3roh8RGD
lVb9Nb5vUZMGbrL376r6PkL+sZ6QcKemrGF3ZZqiirKcCfstYzhuftPgGLIGc0B2
Ud3IcH5wjxd/h4s4DA9SjZwnYbOlt76e3kcZbUZ4rJF1SEUAr0hfjRcbrEEj/0Ni
5B/z5H+miK4xAy+gyYemKELWhyrjSE5n2f5rN0SEJtTiaoF2XESLFP8HsuVzZyox
KOte7ekNIX0Ev+UvmEGeXawlqKRR+xuIYfS9obpgtbWYOZa1zdKMJz8VFfSun2MQ
9aK5B6icbeGTjB+ilKINv7UqLXArZw4WokAVBKRFXRpdAOjBBdGp9u0lIp2vNcru
hM6wc/lXShs7JlpQ3Rx0OMSv48u94NwwUw+otJcBg7lc5BoGlQSTqIObIUk4uuyY
abCYVpGBQN/qzGB/lULpt4ExxHEzDHC3pRimBGM6vGdThXOHKFi4VwlMf39UXaLl
rxvwtgdjnNAafVGc/H4g
=lHoz
-END PGP SIGNATURE-

Bug#843998: plymouth theme missing for softwaves

[Aurélien COUDERC]

Hi Michael,

my pleasure. :-)
And also it's Juliette Belin's fault that we have such a nice theme proposal 
for Stretch, I don't take credit for that.

For fsck/others I think the support is to be done… everywhere else !
Basically we've taken inspiration (read blindly copied) what Ubuntu does, so 
Plymouth and the Debian theme support fsck display since wheezy.
The missing part is that init/fsck/whoever else actually sends information to 
plymouthd to display.


Cheers,
--Aurélien

Le 4 janvier 2017 14:37:25 GMT+01:00, Michael Biebl  a écrit :
>Hi Aurélien,
>
>nice work. Thanks a lot!
>
>Do you know what is missing to have fsck progress support in plymouth?
>Is that a theme issue or something which needs to be supported by
>plymouth (or both)?
>
>I know, SSDs are more popular these days so long fsck times are not
>that
>common anymore. Would still be nice to have support for that in
>plymouth, otherwise it's rather pointless to ship fsckd in systemd [1].
>
>CCed Laurent and Laurent, maybe they have some input on this. Would be
>great if we can fix this for stretch
>
>Regards,
>Michael
>
>
>[1]
>https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/debian/fsckd-daemon-for-inter-fsckd-communication.patch
>
>-- 
>Why is it that all of the instruments seeking intelligent life in the
>universe are pointed away from Earth?

--Envoyé d'un téléphone libre

Bug#809997: emscripten: neither in stable nor testing

[Xavier Bestel]

Package: emscripten
Version: 1.22.1-1
Followup-For: Bug #809997

Dear Maintainer,

I can't seem to be able to install emscripten in jessie, nor in testing.

Regards,
Xav

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

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

Bug#850159: dgit: support to simple-patchsys.mk

[Mattia Rizzolo]

Package: dgit

So I just did an NMU of src:jack, which uses cdbs as build system, and
simple-patchsys.mk as patch system.

The tree I got by `dgit clone jack` was without the patches applied,
probably because dgit didn't even realize there were patches.

Note that this patch format is being deprecated (#624201) and only a
very low number of packages in the archive use it, so I'm not sure how
important this support would be.

-- 
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#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

[Daniel Kahn Gillmor]

Control: severity 849845 grave

Hi all--

I've been able to replicate the problems described by intrigeri in
https://bugs.debian.org/849845; i'm preparing an update to gpg with
cherry-picked patches that resolves most of them for me.  This issue is
bad enough that it basically makes dirmngr unusable, afaict.

The remaining problem for me ws that when i use tor, if i get back 
records, the connections fail, but the IPv6 records are not marked as
dead, so they fail repeatedly.

here's an example:


Jan 03 15:48:37 alice dirmngr[11194]: DBG: chan_5 <- KS_GET -- 
0x4FA73DE89ADE75998AC24E97B8C1D523FE7AAA84
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2a02:898:31:0:48:4558:73:6b73]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2a00:14b0:4200:3000:27::27]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:738:0:600:216:3eff:fe02:42]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:720:418:caf1::8]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:610:1108:5011::70]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '216.66.15.2'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '212.12.48.27'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '193.224.163.43'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '192.94.109.73'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '131.155.141.70'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '130.206.1.8'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '94.142.242.225'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '51.15.53.138'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '37.191.238.78'
Jan 03 15:48:42 alice dirmngr[11194]: resolve_dns_addr for 
'hkps.pool.sks-keyservers.net': '18.9.60.141'
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L3: ASSERT: 
mpi.c[_gnutls_x509_read_uint]:246
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d240086b0]: 
Allocating epoch #0
Jan 03 15:48:42 alice dirmngr[11194]: can't connect to 
'2a02:898:31:0:48:4558:73:6b73': Invalid argument
Jan 03 15:48:42 alice dirmngr[11194]: error connecting to 
'https://[2a02:898:31:0:48:4558:73:6b73]:443': Invalid argument
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d240086b0]: 
Start of epoch cleanup
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d240086b0]: End 
of epoch cleanup
Jan 03 15:48:42 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d240086b0]: 
Epoch #0 freed
Jan 03 15:48:42 alice dirmngr[11194]: command 'KS_GET' failed: Invalid argument
Jan 03 15:48:42 alice dirmngr[11194]: DBG: chan_5 -> ERR 167804976 Invalid 
argument 
Jan 03 15:48:42 alice dirmngr[11194]: DBG: chan_5 <- BYE
Jan 03 15:48:42 alice dirmngr[11194]: DBG: chan_5 -> OK closing connection
Jan 03 15:48:42 alice dirmngr[11194]: handler for fd 5 terminated
Jan 03 15:49:11 alice dirmngr[11194]: handler for fd 5 started
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> # Home: /home/dkg/.gnupg
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> # Config: 
/home/dkg/.gnupg/dirmngr.conf
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> OK Dirmngr 2.1.17 at your 
service
Jan 03 15:49:11 alice dirmngr[11194]: connection from process 11200 (1000:1000)
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 <- GETINFO version
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> D 2.1.17
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 -> OK
Jan 03 15:49:11 alice dirmngr[11194]: DBG: chan_5 <- KS_GET -- 
0x4FA73DE89ADE75998AC24E97B8C1D523FE7AAA84
Jan 03 15:49:11 alice dirmngr[11194]: DBG: gnutls:L3: ASSERT: 
mpi.c[_gnutls_x509_read_uint]:246
Jan 03 15:49:11 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d2400c090]: 
Allocating epoch #0
Jan 03 15:49:11 alice dirmngr[11194]: can't connect to 
'2a02:898:31:0:48:4558:73:6b73': Invalid argument
Jan 03 15:49:11 alice dirmngr[11194]: error connecting to 
'https://[2a02:898:31:0:48:4558:73:6b73]:443': Invalid argument
Jan 03 15:49:11 alice dirmngr[11194]: DBG: gnutls:L5: REC[0x7f6d2400c090]: 
Start of epoch cleanup
Jan 03 15:49:11 alice dirmngr[11194]: DBG: gnutls:L5: RE