Bug#854024: ITP: python-perf -- Toolkit to run Python benchmarks

[gustavo panizzo]

Package: wnpp
Severity: wishlist
Owner: gustavo panizzo 

* Package name: python-perf
  Version : 0.9.3
  Upstream Author : Victor Stinner 
* URL : http://perf.readthedocs.io/en/latest/
* License : MIT/X
  Programming Lang: Python
  Description : Toolkit to run Python benchmarks

The Python perf module is a toolkit to write, run, analyze and modify 
benchmarks.

Features:

-JSON format to store benchmark results
-pyperf (or python3 -m perf) command line tool to display, compare, analyze 
and modify benchmark results
-Statistical tools to analyze the distribution of benchmark results
-compare command supports comparison between multiple benchmark suites 
(made of multiple benchmarks)
-timeit command for quick but reliable Python microbenchmarks

python-perf is a dependency of tuned.

I'll maintain this package under collab-main, using git

Bug#851667: shifted bug in openjdk-8 8u121-b13-1

[Jesse Lopez]

This update has completely broken the installation of openjdk-8-j* on
Jessie via backports.

The bug report needs to be reopened.

Bug#854009: soundmodem: starts kiss device with incorrect permissions

[Thomas Osterried]

Hello,

I'd like to argue that this is not the right approach.

group tty's default permissions are 0620.
That is so, in order to allow programs like write(1) or wall(1) writing to the
users terminal. These programs are set-gid-bit tty.
For soundmodem, those programs also should not be allowed to write to
/dev/soundmodem. Thus considered, not 0660 as suggested, but 0600 should
be the correct permission.

The patch suggests to add a user who's allowed operate with soundmodem
to the group tty. This would lead to an security risk by design, because
a normal user is user now able to read devices like /dev/vcs (virtual console
memory / screen dump).

The correct and non-harmful ownership would be the group "dialout", and then ok
with permission 0660. That goes along with the unix security design for modem
access permissions for users.
An even  better approach would be a group ownership for ham-radio-operators
(like ax25-apps/-tools suggest, with gid "hams" or "ax25"), but since there's
no standard and no defualt group currently in /etc/group, I suppose group
"dialout" would be sufficient.

vy 73,
- Thomas  dl9sau


On Fri, Feb 03, 2017 at 12:39:01AM +, Dave Hibberd wrote:
> Package: soundmodem
> Version: 0.20-5
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> Running soundmodem creates a kiss serial device with permissions that render 
> it 
> inaccessible to normal users, or users in the tty group.
> 
> Upon starting soundmodem with Channel "Packet IO" Mode set as KISS, 
> soundmodem 
> creates a pty and a link to that file, /dev/soundmodem*.
> 
> Normal users, and users in the tty group cannot access this device - this 
> means 
> packet programs, such as Xastir, have to be run as root. 
> 
> Listing the file permissions of the created devices shows:
> 
> → ls -al /dev/soundmodem0
> lrwxrwxrwx 1 root root 10 Feb  3 00:18 /dev/soundmodem0 -> /dev/pts/6
> 
> → ls -al /dev/pts/6
> crw--w 1 root tty 136, 6 Feb  3 00:18 /dev/pts/6
> 
> While root has rw on /dev/pts/6, group tty only has w. Applications cannot 
> read 
> the terminal and show accessing it has failed.
> 
> I have included a very minor patch which details a proposed fix below. The 
> patch 
> allows members of the 'tty' group to read and write to the pty device.
> 
> This has been committed to in the debian git server and can be viewed at:
> https://anonscm.debian.org/cgit/pkg-hamradio/soundmodem.git/ however it can 
> be 
> discarded as per maintainer's choice. 
> 
> 
> Descriptions: Allow group to read/write the created pty
> Author: Dave Hibberd 
> Last-Updated: 2017-02-24
> 
> --- a/soundcard/kisspkt.c
> +++ b/soundcard/kisspkt.c
> @@ -758,7 +758,7 @@
>  tm.c_cflag = CS8 | CREAD | CLOCAL;
>  if (tcsetattr(slave, TCSANOW, ))
>  logerr(MLOG_FATAL, "slave: tcsetattr");
> - //fchmod(slave, 0600);
> + fchmod(slave, 0660);
>   if (dounlink)
>   unlink(file);
>   if (symlink(ttyname, file))
> 
> 
> -- System Information:
> Debian Release: 9.0
>   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=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages soundmodem depends on:
> ii  libasound2  1.1.2-1
> ii  libatk1.0-0 2.22.0-1
> ii  libaudiofile1   0.3.6-3
> ii  libc6   2.24-8
> ii  libgdk-pixbuf2.0-0  2.36.3-1
> ii  libglib2.0-02.50.2-2
> ii  libgtk2.0-0 2.24.31-1
> ii  libhamlib2  3.0.1-1+b1
> ii  libpango-1.0-0  1.40.3-3
> ii  libxml2 2.9.4+dfsg1-2.1
> 
> soundmodem recommends no packages.
> 
> soundmodem suggests no packages.
> 
> -- Configuration Files:
> /etc/ax25/soundmodem.conf changed:
> 
> 
>   
>  txtail="10"/>
>  capturechannelmode="Mono"/>
> 
> 
>   
>   
>netmask="255.255.255.224" broadcast="44.131.6.63" file="/dev/soundmodem0" 
> unlink="1"/>
> 
>   
> 
> 
> 
> -- no debconf information

Bug#853974: unblock: src:texlive-base/2016.20170123-1

[Niels Thykier]

Control: tags -1 confirmed

Norbert Preining:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear release managers,
> 
> I would like to ask for an unblock of 
>   src:texlive-base
>   src:texlive-extra
> of the versions in sid: 2016.20170123-1
> 
> It was planned that these packages enter testing together,
> but as missing dependency (see bug 853119) of texlive-base
> onto fonts-lmodern created an RC bug as some (one?) package
> now fails to build from source.
> 
> [...]
>
> I propose to *first* let current texlive-{base,extra} go into
> testing to unbreak the current complete hang, and after that
> I will upload fixed dependency packages to sid and ask for
> another unblock of these new packages, where the only changes
> are dependency changes.
> 
> Thanks a lot
> 
> Norbert
> 
> [...]

Deal, I have asked Britney to ignore #853119 for
texlive-base/2016.20170123-1.  It should migrate on the next britney run
(but please confirm that before uploading the next version).

Once migrated, please upload the fixes for #853119.

Thanks,
~Niels

Bug#853865: Wrong package

[Nicolas Damgaard Larsen]

Hello.

Seems I made a mistake. Bug report probably should have been associated
with openjdk-8-jre v. 8u121-b13-1~bpo8+1 from jessie-backports instead. My
mistake.

Bug#852865: unblock: gnome-orca/3.22.2-2

[Samuel Thibault]

Niels Thykier, on Fri 03 Feb 2017 07:23:00 +, wrote:
> Samuel Thibault:
> > Niels Thykier, on Sat 28 Jan 2017 10:25:00 +, wrote:
> >> Upload, make sure it has no regressions (RC bugs, builds, etc. etc.)
> >> and let us know when it is just needs aging to migrate.  If that time
> >> is before 04/02, it will be accepted.
> > 
> > This looks good so far.  The bug is confirmed to be gone, and the users
> > haven't reported any regression.  It is an arch:all package, so no
> > arch-specific build issue :)
> 
> Thanks for confirming. :) The package has been unblocked by jmw, so now
> it just need to wait. :)

Thanks!

Samuel

Bug#852865: unblock: gnome-orca/3.22.2-2

[Niels Thykier]

Samuel Thibault:
> Hello,
> 
> Niels Thykier, on Sat 28 Jan 2017 10:25:00 +, wrote:
>> Upload, make sure it has no regressions (RC bugs, builds, etc. etc.)
>> and let us know when it is just needs aging to migrate.  If that time
>> is before 04/02, it will be accepted.
> 
> This looks good so far.  The bug is confirmed to be gone, and the users
> haven't reported any regression.  It is an arch:all package, so no
> arch-specific build issue :)
> 
> Samuel
> 

Thanks for confirming. :) The package has been unblocked by jmw, so now
it just need to wait. :)

~Niels

Bug#854023: unblock: gdal/2.1.2+dfsg-3

[Bas Couwenberg]

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

Please unblock package gdal

The only change is the fix for #853900 _gdal_array ImportError with
Python 3.

unblock gdal/2.1.2+dfsg-3

Kind Regards,

Bas
diff -Nru gdal-2.1.2+dfsg/debian/changelog gdal-2.1.2+dfsg/debian/changelog
--- gdal-2.1.2+dfsg/debian/changelog2016-11-09 18:38:03.0 +0100
+++ gdal-2.1.2+dfsg/debian/changelog2017-02-02 20:15:59.0 +0100
@@ -1,3 +1,10 @@
+gdal (2.1.2+dfsg-3) unstable; urgency=medium
+
+  * Add upstream patch to fix _gdal_array ImportError with Python 3.
+(closes: #853900)
+
+ -- Bas Couwenberg   Thu, 02 Feb 2017 20:15:59 +0100
+
 gdal (2.1.2+dfsg-2) unstable; urgency=medium
 
   * Add upstream patch to fix crash on URLs that are not DODS servers.
diff -Nru gdal-2.1.2+dfsg/debian/patches/python3-import-gdal_array.patch 
gdal-2.1.2+dfsg/debian/patches/python3-import-gdal_array.patch
--- gdal-2.1.2+dfsg/debian/patches/python3-import-gdal_array.patch  
1970-01-01 01:00:00.0 +0100
+++ gdal-2.1.2+dfsg/debian/patches/python3-import-gdal_array.patch  
2017-02-02 20:14:31.0 +0100
@@ -0,0 +1,28 @@
+Description: Python bindings: fix 'import osgeo.gdal_array' with python3 and 
SWIG 3.0.10
+Author: Even Rouault
+Origin: https://trac.osgeo.org/gdal/changeset/37277
+Bug: https://trac.osgeo.org/gdal/ticket/6801
+Bug-Debian: https://bugs.debian.org/853900
+
+--- a/swig/include/gdal_array.i
 b/swig/include/gdal_array.i
+@@ -994,7 +994,7 @@ retStringAndCPLFree* GetArrayFilename(Py
+ 
+ %pythoncode %{
+ import numpy
+-import _gdal_array
++from . import _gdal_array
+ 
+ import gdalconst
+ import gdal
+--- a/swig/python/osgeo/gdal_array.py
 b/swig/python/osgeo/gdal_array.py
+@@ -145,7 +145,7 @@ def RATValuesIONumPyRead(*args, **kwargs
+   return _gdal_array.RATValuesIONumPyRead(*args, **kwargs)
+ RATValuesIONumPyRead = _gdal_array.RATValuesIONumPyRead
+ import numpy
+-import _gdal_array
++from . import _gdal_array
+ 
+ import gdalconst
+ import gdal
diff -Nru gdal-2.1.2+dfsg/debian/patches/series 
gdal-2.1.2+dfsg/debian/patches/series
--- gdal-2.1.2+dfsg/debian/patches/series   2016-11-09 18:31:25.0 
+0100
+++ gdal-2.1.2+dfsg/debian/patches/series   2017-02-02 20:15:40.0 
+0100
@@ -11,3 +11,4 @@
 sort-files-in-static-library.patch
 spelling-errors.patch
 svn-r36175-DODS-fix-crash-on-URL-that-are-not-DODS-servers.patch
+python3-import-gdal_array.patch

Bug#854019:

[Xie Xun]

The version is actually 2.2-6.

Bug#854022: Not able anymore to contact debian bts

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: reportbug
Version: 7.1.4
Severity: important

Reportbug is not able to contact bts and download already fieled bugs.

The error is:
Unable to connect to Debian BTS (error: "SSLError(1, '[SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:720)')");
continue [y|N|?]?

- -- Package-specific info:
** Environment settings:
EDITOR="vim"
PAGER="less"
VISUAL="vim"
EMAIL="Klaus Ethgen "
DEBFULLNAME="Klaus Ethgen"
INTERFACE="text"

** /home/klaus/.reportbugrc:
reportbug_version "2.20"
mode expert
ui text
realname "Klaus Ethgen"
email "kl...@ethgen.de"

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

Kernel: Linux 4.9.1 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages reportbug depends on:
ii  apt1.4~beta4
ii  python3-reportbug  7.1.4
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf-utils  1.5.60
ii  debsums2.2
ii  dlocate1.07+nmu1
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.89~RC1-1
ii  exim4-daemon-light [mail-transport-agent]  4.89~RC1-1
ii  file   1:5.29-3
ii  gir1.2-gtk-3.0 3.22.7-2
pn  gir1.2-vte-2.91
ii  gnupg  2.1.18-3
ii  python3-gi 3.22.0-2
ii  python3-gi-cairo   3.22.0-2
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4~beta4
ii  file   1:5.29-3
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1
pn  python3:any

python3-reportbug suggests no packages.

- -- Configuration Files:
/etc/reportbug.conf changed:
submit
mutt
query-bts
cc
config-files
compress
sign gpg
verify
mode expert
mbox_reader_cmd "mutt -f %s"


- -- no debconf information

- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAliULWwACgkQpnwKsYAZ
9qxfFAv9FjcJXlTZn6juZVOBSNsjg7AgDFWHEKowbWmDb8w2ka389g+bn4uN3fiA
7oJubaUUdY8uTk18xTtg4Vkj15WAI8c/WrY7UiwqvjVe0lg5SmpDLqIWH93LosqF
o5ujjQw8zFOprantqOJD5nJJoQwCEQ3BwI66ACJSoqHeC0AX4uTNmcMPURrkXUgl
nPR+KGN0mSaPAJnXoJiIiNtejvA9M5LJhX6nNIksKZiugBrSMApqk/7YJp4VZzT5
TJ/HnKPtsK0QwSlAIBN/Rfj6CaWV8SxFEv7rlsPK81woqTf4HXiMH0wOVdth3asM
ay46P//q/psCUx9zvodfAAxKn5YLIYhKWnlHrVQ8KHl6yd+HV8NGjtYGmpF5Oz4p
InPS6PJTSgeF1HikhRsof5SGBQ2KDsM613pnWVqoA/hkvwtu6aJv5YfL9SqOZlBK
WFJclcg01daKlbwn9wWdEfWGbp8Moqj3tyh9pnRYoMhOWH9GKrDiLIPQWgMMnw2V
Sew/ZiZL
=STz+
-END PGP SIGNATURE-

Bug#854021: fwbuilder: Consider following fork / new upstream https://github.com/fwbuilder/

[Matthew Gabeler-Lee]

Package: fwbuilder
Version: 5.1.0-4+b2
Severity: wishlist

There seems to be a new upstream, or at least an actively maintained fork:
https://github.com/fwbuilder/fwbuilder, while the existing upstream has not
shown any signs of life for several years.

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_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 fwbuilder depends on:
ii  fwbuilder-common  5.1.0-4
ii  libc6 2.24-8
ii  libgcc1   1:6.3.0-5
ii  libqt4-network4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libsnmp30 5.7.3+dfsg-1.7
ii  libssl1.0.2   1.0.2j-5
ii  libstdc++66.3.0-5
ii  libxml2   2.9.4+dfsg1-2.1
ii  libxslt1.11.1.29-2
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages fwbuilder recommends:
ii  fwbuilder-doc  5.1.0-4
pn  rcs

fwbuilder suggests no packages.

-- no debconf information

Bug#854020: Wine does not longer work with OSS

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: wine64-development
Version: 2.0-3
Severity: grave

The newest package does not work anymore with OSS sound system. That
renders Wine nearly unusable as the only think where I need wine is to
play WoW.

OSS is the only sound system working. (Currently oss4 4.2-build2010-5)

- -- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

Kernel: Linux 4.9.1 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages wine64-development depends on:
ii  libc62.24-9
ii  libwine-development  2.0-3

Versions of packages wine64-development recommends:
ii  wine-development2.0-3
ii  wine32-development  2.0-3

Versions of packages wine64-development suggests:
pn  libwine-gecko-2.47
pn  wine64-development-preloader  

Versions of packages wine64-development is related to:
ii  fonts-wine  1.8.6-5
ii  wine-development2.0-3
ii  wine32-development  2.0-3
ii  wine64-development  2.0-3

- -- no debconf information

- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAliULKUACgkQpnwKsYAZ
9qy8Ggv/RRCF9rqxSJpHwlrcxd4086Gz44KJAST8PTErCpXVLNj17siMrT74LAT1
jbb8fNzQhqQWhYCKOSVfnDrnyR/Xz86TQAmehSNlQk5+QOaUJq6NtrZ7es6eYOCp
ljJoEDa7g9oK/gNKU34C9H2OxUDsyDdsr34xYcEB7NAQZbkYJOZe4qYybkbMg5E9
wR6x4a63rPD8pvOrXp0QlJqx+1IAwIUyC3LNrtUsQIWxysgdWOH1BkpoW17KjBWf
vT5zfLSShCilAZSPijWlAvaRWb1GskcCEztJJwUc7zUfV1QkCmvKw4FHD43yN1UQ
uLpz833LKnrjIagTJq9jp/PPtdbPz+Mv+LvaIkjGYqiC4z5+oCiYgijQNKdMWqqZ
fNSX5SrozK5Utd+Au8cUSRUFzgZ3OlRDyjIb6VEzZE8/FLk6LLZmeqyU96ImS/86
1AYA2V4Wl1f3lJ4hNsIGRTskrPHOnxSAUwvBKbEZhsNzO+IOBozr1qH+A1ALOTEj
8cc2nHiX
=c8Np
-END PGP SIGNATURE-

Bug#854019: lunar: unmatched time when query solar 2017 01 28 22 and 2017 01 28 23

[Xie Xun]

Package: lunar
Version: 2.2-4
Severity: important
Tags: patch

The bug was reported by . However, it seems that
he/she's not reported the bug to the bug tracking system.
Below is a copy of his/her email:

___
Hi, Xie Xun
lunar datetime goback from 2017年 2月24日22时2017年 2月23日23时
when query the solar  from 2017 01 28 22  to 2017 01 28 23
thanks
lunar -u -s -i 2017 01 28 22
Lunar Version 2.2-6 (Debian) (January 2, 2017)

阳历：　2017年 2月24日22时　星期五
阴历：　2017年 1月28日亥时　生肖属鸡
干支：　丁酉年　壬寅月　壬午日　辛亥时　
用四柱神算推算之时辰八字：　丁酉年　壬寅月　壬午日　辛亥

lunar -u -s -i 2017 01 28 23
Lunar Version 2.2-6 (Debian) (January 2, 2017)

阳历：　2017年 2月23日23时　星期四
阴历：　2017年 1月28日子时　生肖属鸡
干支：　丁酉年　壬寅月　壬午日　庚子时　
用四柱神算推算之时辰八字：　丁酉年　壬寅月　壬午日　庚子
__

and his/her patch:

__
Hi, Xie Xun
This is the patch for lunar about not continue datetime from lunar to solar
query:
--- lunar/lunar.orig2001-10-29 13:55:39.0 +0800
+++ lunar/lunar.c2017-02-03 06:22:18.957411341 +0800
@@ -250,7 +250,7 @@
offset = Solar2Day();
solar.weekday = (offset + SolarFirstDate.weekday) % 7;

-/* A lunar day begins at 11 p.m. */
+/* A lunar day begins at 11 p.m. of lastday */
if (solar.hour == 23)
offset++;

@@ -271,8 +271,8 @@
int adj;
Date *d;

-/* A solar day begins at 12 a.m. */
-adj = (lunar.hour == 23)? -1 : 0;
+/* A solar day begins at 12 a.m. (00 a.m.) */
+adj = (lunar.hour == 0)? -1 : 0;
offset = Lunar2Day();
solar.weekday = (offset+ adj + SolarFirstDate.weekday) % 7;
Day2Solar(offset + adj, );

thanks


USV seems to use an invalid email address, so I can't contact with him/her
directly.
Nevertheless, thank usv for his/her report.



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

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

Versions of packages lunar depends on:
ii  libc6  2.19-18+deb8u7

lunar recommends no packages.

lunar suggests no packages.

-- no debconf information

Bug#854018: ITP : node-is-npm -- Check if your code is running as an npm script

[Juhani Numminen]

Control: forcemerge 850251 854018

This is a duplicate of https://bugs.debian.org/850251

To check for existing ITPs before filing one, you can use wnpp-check
from the devscripts package:

$ wnpp-check node-is-npm
(ITP - #850251) http://bugs.debian.org/850251 node-is-npm

Cheers,
Juhani

Bug#539201: cannot explicitly specify rpc.nfsd options via /etc/default/nfs-kernel-server

[Nye Liu]

In addition, it means NFSv2 cannot be enabled, since the latest rpc.nfsd
seems to have NFSv2 disabled, and there is no way to pass "-V 2" to 
rpc.nfsd

Please accept the patch.

This should probably be merged with 738063

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

No, this is not fixed upstream, since the problem is in the debian init
scripts

Bug#854018: ITP : node-is-npm -- Check if your code is running as an npm script

[Shirish Togarla]

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

* Package name: node-is-npm
  Version : 1.0.0
  Upstream Author : Sindre Sorhus  (
http://sindresorhus.com)
* URL : https://github.com/sindresorhus/is-npm
* License : Expat
  Programming Lang: JavaScript
  Description : Check if your code is running as an npm script

Bug#771441: tftpd-hpa fails to start properly if network is unavailable

[Ron]

On Thu, Feb 02, 2017 at 02:25:25PM +, Mike Crowe wrote:
> On Friday 27 January 2017 at 09:48:22 +0100, Uwe Kleine-König wrote:
> > Independent of this changing the default TFTP_ADDRESS to ":69" to get
> > ipv6 connectivity would be nice. Or maybe still better to ":tftp".
> 
> Indeed. As I wrote in message #95, the debconf question for TFTP_ADDRESS
> even implies that the current default value will support IPv6, when it does
> not.

That's most probably just an oversight from between when that prompt
was first written and when IPv6 support was actually added.  But that
predates my involvement here, so I can't say for sure.

That said, it also doesn't seem entirely unreasonable for anyone
configuring a service like this to know that 0.0.0.0 is an IPv4
address ...  which might be related to how it got overlooked ...


> If Ron will accept it, then I can update the patch in Message #100 to say
> ":tftp" rather than ":69".

It's ok, I don't need a patch to change the default.  The real question
for this bug (as I think I've said a few times now), is *what* it should
be changed to if we change it.

You've been unambiguous about your preference being that the default
should match your preferred use case - but given that we've now got
people saying they are running this on laptops, I think there's also
a strong case to be made that the default should actually be *more*
restrictive than it currently is.

Historically, TFTP was only ever used on trusted LAN ports, to provide
boot and configuration files for bare and dumb devices.  So binding
to all interfaces and assuming they are trusted wasn't an unreasonable
default.

But given that these days, those files can increasingly contain
sensitive data, like plaintext admin passwords for dumb embedded
devices - and that there is no other access control aside from what
ports you bind this to and how that machine is firewalled - it does
seem irresponsible to open that by default, for naive users who
might carry their laptop around and use it on random untrusted
networks.

Real admins with real servers are going to know how to preseed this
to use their own preference, or are going to be using other tools
to maintain their system configuration anyway.  So maybe we should
err on the side of 'forcing' naive users to explicitly make it more
permissive if that's what they really want, rather than just opening
it to everyone before they've even had a chance to read the man page.


> Is there any chance we can get this into Stretch?

Given that it's increasingly clear that there isn't actually a 'bug'
in this software, just the minor question of whether the default
configuration is still appropriate for expected use(r)s in 2017, it
doesn't seem all that likely that the release team would want to
accept such a change now even if I was convinced we certainly knew
the definitively right answer and pushed it.

If you want to fix the symptom for Stretch, you'd be better off
filing an RC bug against NM for the issue affecting it.

If you really want :69 as your local config for other reasons, you
can already do that today.


Right now, I'm basically seeing 3 options for how to 'close' this
issue here now:

 - Make the default more restrictive, raise the priority of the
   debconf question so more people actually see it, and include
   some explanation of why it's restrictive, and what you might
   want to change it to for particular use cases.

 - Leave the default as is, but tweak the prompt text to be a
   bit clearer (and maybe still raise the priority).

 - Make the default completely permissive as you're suggesting
   and just let anyone who gets burned by that learn their
   mistake The Hard Way.

And if I had to rank them by the amount of (potentially justified)
vitriol that the hate mail I'll get from people who don't like the
new default because it somehow inconvenienced them will contain ...

... then the first one starts looking like a pretty attractive
option ...  and I'm not really sure what arguments to the contrary
might change that.

I'm willing to listen to any that we haven't already heard (I haven't
forgotten them, there's no need to repeat them), and I'm far from
being completely convinced that's a Great Answer.  But it might
really be the Least Worst one for today, all things considered.


  Cheers,
  Ron

Bug#738063: nfs-kernel-server: option to disable NFSv4 in /etc/default/nfs-kernel-server not working properly

[Nye Liu]

This bug is still not fixed.

In addition, it doesn't appear as though "-V 2" will enable NFSv2, which seems 
to
be disabled by default now.

Bug#658303: Re.Interested in Services

[hoze grey]

Hi,

Greetings,

I hope it's exactly what you are looking for and helps to give your business a 
boost by designing a new website or refurbish your existing website.

We are top leading Software Development Company having our registered office in 
India. We are having an experienced and dedicated team who is always ready to 
provide the any type of website designing and development services.

I appreciate if you let me know about your interest in our services and I would 
be happy to share our past work and client testimonials and prices.

Looking forward to hearing from you.

Thanks and Regards,
Hoze

Bug#853998: CVE-2017-3250 / CVE-2017-3249 / CVE-2017-3247 / CVE-2016-5528 / CVE-2016-5519

[Emmanuel Bourg]

Le 2/02/2017 à 23:08, Moritz Muehlenhoff a écrit :

> So Oracle has these lovely, unspecified vulnerabilities reported against 
> Glassfish,
> but it's my understanding that the Debian package only provides a minor subset
> what usually constitutes Java, so could you have a look, which of 
> 
> http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
> 
> might possibly affect the Debian package?

I think this is unlikely to affect our packages. We only have two
specification packages (glassfish-javaee and glassfish-jmac-api) and an
Object/Relational mapper (glassfish-toplink-essentials) that is never
used at runtime.

Emmanuel Bourg

Bug#771441: [syslinux] Bug#771441: [PATCH tftpd-hpa] tftpd: don't use AI_CANONNAME and AI_ADDRCONFIG to resolve addresses for bind

[Ron]

On Thu, Feb 02, 2017 at 02:22:47PM +0100, Uwe Kleine-König wrote:
> On Thu, Feb 02, 2017 at 04:08:49PM +1030, Ron via Syslinux wrote:
>
> > The use of AI_PASSIVE here is a placebo.  That flag has no effect unless
> > address was NULL, and if that was true, neither of the hunks here would
> > actually be executed in the first place.
> 
> Right. Today it only has an effect if the first argument to getaddrinfo
> is NULL. The intension (IIUC) is that it should be used when you plan to
> feed the result to bind (opposed to connect).

What do you mean by "Today"?  Both SuSv4 and the Linux man page are
unequivocal about the _only_ use of that flag being to special case
a NULL address (meaning 'this machine') to return either the wildcard
address or the LOOPBACK address.

That you'd use the wildcard address to bind a service to all addresses
of 'this machine', or the loopback address to connect to a service on
'this machine' is illustrative.  There's no deeper distinction or
fundamental difference related to what functions you might later pass
the address(es) you obtain to.


> > Using AI_CANONNAME here should be harmless at worst.  So the only actual
> > change is to drop AI_ADDRCONFIG - the flag which limits getaddrinfo to
> > returning only the address families that are actually supported by the
> > configured interfaces on the system.  And ordinarily that would seem to
> > be a fairly uncontroversially Good Thing to do, for both connecting and
> > listening sockets.
> 
> The downside of using AI_ADDRCONFIG is that it makes binding to 0.0.0.0
> (or ::) fail when no interface is up yet.

That seems to be where we disagree.  I don't see it as a 'downside' that
if you explicitly say "I want to bind to IPv4 addresses" (or IPv6), and
you don't actually have any, that this should fail early and loudly to
warn you about either misconfiguration, or some other more serious
failure, occurring.

If you passed a name instead of a numeric address, you'd only get the
address families the machine actually supported.  If you pass a numeric
address in a particular family, you get a sanity check that it's valid.

If you (personally) don't care about that, just don't pass an explicit
address.

The downsides of not using AI_ADDRCONFIG can't be remedied so easily.


> If we can agree in principle I can rework the patch to make one change
> per patch:

I'm far less concerned about the format of the patch, than the details
of what it's actually hoping to achieve.

If all of the reasons for doing this are just different ways of saying
"if we do less sanity checking, then misconfiguration and broken tools
won't annoy me as often" - that's not very compelling.

Doubly not so when there already is a way you can configure this for
your own use which does already bypass them.  Simply disabling that
for everyone and every configuration isn't a good answer.


> > So unless upstream sees this differently, I still think we'd need to see
> > some stronger rationale for why that isn't a Good Thing in this particular
> > case than just "Dropping that flag hides a real bug in NetworkManager".
> 
> This is not the (only) reason for me. This is mostly only how it showed
> up for some people, but still there are more IMHO good reasons to fix
> it:
> 
>  - inconsistent behaviour when no interface is up: -a 0.0.0.0 fails,
>-a :: fails, not passing -a doesn't fail and makes tftpd bind to all
>interfaces.

I don't see how that is 'inconsistent'?  If you ask for an explicit
address (family) you get a sanity check that (support for it) is
available.  If you say you don't care, then tftpd doesn't either.

>  - The "no interface is up" also happens with ifupdown with no auto
>interface is used (only hotplug)

Not defaulting to auto (and systemd not respecting it for a while) were
both bugs that broke lots of services on lots of people's machine.

And I already explained to you in #d-d that the established 'solution'
for that, for services which don't monitor netlink events, is to add a
hook which restarts them when interfaces appear or disappear, if you
really want them to bind to interfaces which might genuinely be expected
to be hotplugged.

Because if you're not actually using wildcard addresses, then this will
_still_ fail, even with your patch, if that interface isn't already up.

>  - The "no interface is up" also happens if your laptop has no network
>connection during boot

This doesn't need a link up state to work, it just needs a local
interface to be brought up with the needed address (family) assigned
to it.  If your only address is assigned by DHCP or something similar,
and you aren't blocking waiting on that - then as above lots of services
are going to fail to start if your boot sequence blindly tries to start
them anyway.

That isn't the fault of, or a bug in, those services.  Your system is
just misconfigured for what you actually want it to do.

>  - It's more robust to try what the admin requested. It is possible even
>

Bug#854017: udev kernel DEATHFUL bug.

[王 懋昕]

Package: udev

Version: 175-7.2


My system is testing version.After run "apt-get upgrade",my udev upgrade to 
175-7.2.but when I reboot.I can't boot up.

the term show:

A starting job running  for udev.

Then it failed to start.

Bug#849684: python-matplotlib: adequate reports broken symlink for python-matplotlib at jquery-ui.min.css

[Ryan Tandy]

Control: reassign -1 libjs-jquery-ui 1.12.1+dfsg-1

Hi Paul,

(I found a link to this bug on the submitter's blog, via planet.d.o.)

On Fri, Jan 27, 2017 at 08:38:24PM +0100, Paul Gevers wrote:

I also checked on my system, the link is there.
paul@testavoira ~ $ COLUMNS=80 dpkg -l libjs-jquery-ui | grep ^ii
ii  libjs-jquery-u 1.12.1+dfsg- all  JavaScript UI library for
dynamic

paul@testavoira ~ $ dpkg-query -S
/usr/share/javascript/jquery-ui/css/smoothness
libjs-jquery-ui: /usr/share/javascript/jquery-ui/css/smoothness

paul@testavoira ~ $ ls -al /usr/share/javascript/jquery-ui/css/smoothness
lrwxrwxrwx 1 root root 14 okt 16 16:44
/usr/share/javascript/jquery-ui/css/smoothness -> ../themes/base


This is the case for clean installs, but if one upgrades from a previous 
version, the directory is not converted to a symlink. A call to 
dpkg-maintscript-helper should be all that is needed to resolve it. 

The attached patch contains an attempt at that. Tested by installing 
libjs-jquery-ui in a jessie chroot and upgrading to sid.


before:

# ls -ld /usr/share/javascript/jquery-ui/css/smoothness/
drwxr-xr-x 3 root root 4096 Feb  3 03:14 
/usr/share/javascript/jquery-ui/css/smoothness/

after:

# ls -ld /usr/share/javascript/jquery-ui/css/smoothness
lrwxrwxrwx 1 root root 43 Feb  3 03:20 
/usr/share/javascript/jquery-ui/css/smoothness -> ../themes/base

Hope this helps,
Ryan
>From e15caf0ad1125656ad294b68225caa2c6d49914c Mon Sep 17 00:00:00 2001
From: Ryan Tandy 
Date: Thu, 2 Feb 2017 19:22:21 -0800
Subject: [PATCH] Add dir to symlink conversion for css/smoothness

---
 debian/changelog   | 7 +++
 debian/libjs-jquery-ui.maintscript | 1 +
 2 files changed, 8 insertions(+)
 create mode 100644 debian/libjs-jquery-ui.maintscript

diff --git a/debian/changelog b/debian/changelog
index d0ca0ca..8fae77a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+jqueryui (1.12.1+dfsg-4) UNRELEASED; urgency=medium
+
+  * Convert /usr/share/javascript/jquery-ui/css/smoothness to a symlink upon
+upgrade from older versions. (Closes: #849684)
+
+ -- Ryan Tandy   Thu, 02 Feb 2017 19:01:15 -0800
+
 jqueryui (1.12.1+dfsg-3) unstable; urgency=medium
 
   * Provide node-jquery-ui (Closes: #847353)
diff --git a/debian/libjs-jquery-ui.maintscript b/debian/libjs-jquery-ui.maintscript
new file mode 100644
index 000..12f3bbc
--- /dev/null
+++ b/debian/libjs-jquery-ui.maintscript
@@ -0,0 +1 @@
+dir_to_symlink /usr/share/javascript/jquery-ui/css/smoothness ../themes/base 1.12.1+dfsg-4~
-- 
2.1.4

Bug#847967: [pkg-lynx-maint] Bug#847967: Bug#847967: lynx: Fix links containing divs

[Andrew Valencia]

>> > 
>> > http://www.debian.org/;>Debian
>> > 

I'm having a hard time trying to figure out why you would want an anchor across
an entire div.  span, yes, and Lynx already gets it right.  I guess
the idea is to have
an entire table, and a click anywhere on the table moves you to the href?

Kinda crazy.  I'll be interested to see what upstream does with it.

Andy

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

[Adam Bolte]

On closer inspection, the error from netstat is different. I missed
the "Reason: [Errno 2] No such file or directory: 'netstat'" line from
the original report, so I'm seeing a different bug.

If the netstat command isn't doing anything critical (as implied by
cloud-init otherwise working just fine without it), perhaps references
to it can simply be removed from cloud-init to address both problems?
Otherwise, I guess I'll open a new bug report.


signature.asc
Description: Digital signature

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

[Adam Bolte]

On Thu, Feb 02, 2017 at 02:22:12PM +0100, Thomas Goirand wrote:
> I don't see how Jessie would be affected, as there, net-base is
> still an essential package.

You are correct, and it certainly is installed into the AMIs in
question. I think the suggested cause is incorrect.


From the debug log:

Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.7 
running 'init' at Fri, 03 Feb 2017 02:41:13 +. Up 6.61 seconds.
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Writing to 
/var/log/cloud-init.log - ab: [420] 0 bytes
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Changing the ownership of 
/var/log/cloud-init.log to 0:4
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Running command 
['ifconfig', '-a'] with allowed return codes [0] (shell=False, capture=True)
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Running command 
['netstat', '-rn'] with allowed return codes [0] (shell=False, capture=True)
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[WARNING]: Route info failed: 
Unexpected error while running command.#012Command: ['netstat', '-rn']#012Exit 
code: 1#012Reason: -#012Stdout: 'Kernel IP routing table\nDestination 
Gateway Genmask Flags   MSS Window  irtt Iface\n'#012Stderr: ''
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Route info failed: 
Unexpected error while running command.#012Command: ['netstat', '-rn']#012Exit 
code: 1#012Reason: -#012Stdout: 'Kernel IP routing table\nDestination 
Gateway Genmask Flags   MSS Window  irtt Iface\n'#012Stderr: 
''#012Traceback (most recent call last):#012  File 
"/usr/lib/python3/dist-packages/cloudinit/netinfo.py", line 199, in 
route_pformat#012routes = route_info()#012  File 
"/usr/lib/python3/dist-packages/cloudinit/netinfo.py", line 99, in 
route_info#012(route_out, _err) = util.subp(["netstat", "-rn"])#012  File 
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 1684, in subp#012
cmd=args)#012cloudinit.util.ProcessExecutionError: Unexpected error while 
running command.#012Command: ['netstat', '-rn']#012Exit code: 1#012Reason: 
-#012Stdout: 'Kernel IP routing table\nDestination Gateway Genmask  
   Flags   MSS Window  irtt Iface\n'#012Stderr: ''


Standard output:

Cloud-init v. 0.7.7 running 'init-local' at Fri, 03 Feb 2017 02:41:12 +. Up 
5.69 seconds.
Cloud-init v. 0.7.7 running 'init' at Fri, 03 Feb 2017 02:41:13 +. Up 6.61 
seconds.
2017-02-03 13:41:13,763 - util.py[WARNING]: Route info failed: Unexpected error 
while running command.
Command: ['netstat', '-rn']
Exit code: 1
Reason: -
Stdout: 'Kernel IP routing table\nDestination Gateway Genmask   
  Flags   MSS Window  irtt Iface\n'
Stderr: ''
ci-info: +++Net device 
info
ci-info: 
++--++---+---+---+
ci-info: | Device |  Up  |  Address   |Mask   | Scope | 
Hw-Address|
ci-info: 
++--++---+---+---+
ci-info: |   lo   | True | 127.0.0.1  | 255.0.0.0 |   .   | 
. |
ci-info: |   lo   | True |  ::1/128   | . |  host | 
. |
ci-info: |  eth0  | True | .  | . |   .   | 
**:**:**:**:**:** |
ci-info: |  eth0  | True | ::**:::/** | . |  link | 
**:**:**:**:**:** |
ci-info: 
++--++---+---+---+
ci-info: !!!Route info 
failed

-Adam


signature.asc
Description: Digital signature

Bug#549279: initscripts: mountall.sh uses locale before mounting /usr

[Ben Hutchings]

Control: tag -1 wheezy jessie

Starting with stretch, any separate /usr partition must be mounted by
an initramfs.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.



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

Bug#854014: Pending fixes for bugs in the prometheus-postgres-exporter package

[pkg-go-maintainers]

tag 854014 + pending
thanks

Some bugs in the prometheus-postgres-exporter package are closed in
revision 0e0ed60b23a0ccdb18378cc8e3d4a7593b96b706 in branch
'debian/sid' by Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/prometheus-postgres-exporter.git/commit/?id=0e0ed60

Commit message:

Initial packaging. (Closes: #854014).

Bug#854016: ITP: kubernetes-addon-dns -- DNS service addon for Kubernetes

[Potter, Tim]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: kubernetes-addon-dns
  Version : 1.13+git20170201.0.da9d641
  Upstream Author : Bowei Du, Zihong Zheng
* URL : https://github.com/kubernetes/dns
* License : Apache-2.0
  Programming Lang: Go
  Description : DNS service addon for Kubernetes

 The Kubernetes DNS addon is a service launched automatically using
 the Kubernetes cluster manager. The DNS addon schedules a DNS Pod and
 Service on the cluster, and configures the kubelets to tell
 individual containers to use the DNS Service’s IP to resolve DNS
 names.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#854015: ITP: python-hupper -- Integrated process monitor for developing servers

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: python-hupper
  Version : 0.4.2
  Upstream Author : Michael Merickel
* URL or Web page : https://github.com/Pylons/hupper
* License : MIT
  Description :
 hupper is an integrated process monitor that will track changes to any
 imported Python files in sys.modules as well as custom paths. When files
 are changed the process is restarted.

Bug#847967: [pkg-lynx-maint] Bug#847967: lynx: Fix links containing divs

[Thomas Dickey]

On Mon, Dec 12, 2016 at 06:15:39PM +0100, Axel Beckert wrote:
> Control: forwarded -1 
> https://lists.nongnu.org/archive/html/lynx-dev/2016-05/msg6.html
> Control: tag -1 + confirmed
> 
> Hi Samuel,
> 
> thanks for the bug report. This seems to be a known issue upstream...
> 
> Samuel Thibault wrote:
> > More and more websites use nice-looking links thanks to css, using code
> > like this:
> > 
> > 
> > http://www.debian.org/;>Debian
> > 
> 
> It seems as if that was invalid HTML for a long time and is valid
> under HTML5 or so.
> 
> > In lynx 2.8.9dev11, the Debian word does not appear as a link at
> > all, actually the link is not reachable at all! This is really
> > not usable at all, see for instance http://rue89bordeaux.com/ or

lynx shows 50 links (plus 160 links).  Use 'L' to see the available links.

> > https://2017.rmll.info/ which do not contain any link...

only 28 links here.
 
> Both URLs do contain some links for me. Anyways, there seem to be less
> links than expected. But at least pressing Ctrl-V as suggested on
> https://lists.nongnu.org/archive/html/lynx-dev/2016-05/msg6.html
> seems to unhide the remaining ones.

Going back to the original report,

https://validator.w3.org/nu/?doc=http%3A%2F%2Frue89bordeaux.com%2F

shows a few problems.  I'd rather spend time fixing problems where
the w3 validator says the page is correct, while lynx doesn't render
it in an accessible manner.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#854014: ITP: prometheus-postgres-exporter -- Prometheus exporter for PostgresSQL server metrics

[Martín Ferrari]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Mart=C3=ADn_Ferrari?= 

* Package name: prometheus-postgres-exporter
  Version : 0.1.1
  Upstream Author : Will Rouesnel
* URL : https://github.com/wrouesnel/postgres_exporter
* License : Apache-2.0
  Programming Lang: Golang
  Description : Prometheus exporter for PostgresSQL server metrics

Prometheus exporter for PostgresSQL server metrics, written in Go.
Supportes Postgres versions 9.1 and up.

Bug#853926: Retitle cloud-init net-base -> net-tools

[gustavo panizzo]

Control: retitle -1 cloud-init depends on net-tools
thanks

On Thu, Feb 02, 2017 at 02:50:45PM +0100, Thomas Goirand wrote:
> There's no such package as net-base. Did you mean net-tools?

yes, i meant to say net-tools. the retitle email never came through

Zigo, sorry if you get this email twice

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa

Bug#853917: ttx and grep result for DroidSansFallback(Full)?.ttf

[Cyril Brulebois]

[ Adding Kenshi Muto to recipients for having suggested the switch to
fonts-android-udeb. ;) Context: We have no glyphs for Korean right now.
Quoting in full my previous mail on that topic. ]

Hi,

Cyril Brulebois  (2017-02-03):
> victory  (2017-02-03):
> > added testing src apt line, apt update, apt-get source ..., tar zxf ...
> > $ ttx DroidSansFallback.ttf
> > $ ttx DroidSansFallbackFull.ttf
> > these 2 generate [filename].ttx
> > 
> > (just FYI, used letters (in ko) other than 7-bit are in 0xac00-0xd790 range)
> > 
> > $ grep Hangul DroidSansFallback.ttx prints 22344 lines
> >   
> >   
> >   
> >   
> >   
> >   
> > ...
> >   
> >   
> >   
> >   
> >   
> >   
> > 
> > $ grep Hangul DroidSansFallbackFull.ttx prints only 6 lines:
> >   
> >   
> >   
> >   
> >   
> >   
> > 
> > so, the latter has only 1 Hangul glyph (0xac00, 가) to be used in d-i
> > (0xd7a2 and 0xd7a3 are not used in d-i)
> 
> I think this matches what happened upstream (warning, big repository:
> https://android.googlesource.com/platform/frameworks/base):
> | commit 562c45cc841681ed80d4e94515b23c28eb60eae4
> | Author: Bart Sears 
> | Date:   Mon Sep 24 00:32:57 2012 -0700
> | 
> | Updated versions of DroidSansFallback
> | 
> | Latest versions of DroidSansFallback from Monotype.
> | 
> | The DroidSansFallback.ttf file has some additional glyphs and
> | glyph fixes (including a fix for bug 6723057 and will likely fix
> | bug 6629748).  It continues to cover Korean Hangul but does not
> | cover CJK Ext A (for space reasons on small system image devices).
> | The DroidSansFallbackFull.ttf file has the bug fixes listed and
> | also removes the Korean Hangul because we are now going to use
> | NanumGothic for Korean (NanumGothic.ttf is added in a separate
> | CL in the external/naver-fonts directory).
> | 
> | The falback_fonts.xml file has been modified to add NanumGothic.ttf
> | before DroidSansFallback.
> | 
> | Bug: 4531601
> | Bug: 6723057
> | Bug: 6629748
> | Change-Id: I670d33078b4a97c4eda00fc2323be187696e927a
> 
> even if how tags/versions in that repository match fonts-android's isn't
> too clear to me.
> 
> Anyway, inspired by the commit message above, I've just built a d-i
> image with an extra /usr/share/fonts/truetype/nanum/NanumGothic.ttf
> taken from the fonts-nanum package, and it seems to work fine! (For
> someone who only knows what Korean glyphs can look like…) I've attached
> a screenshot, feel free to double check.
> 
> I think I'll send a patch against src:fonts-nanum to request a udeb
> addition, then add it to src:debian-installer. And close the bug report
> against src:fonts-android.
> 
> Any comment/objection?

Another possibility would be to update the fonts-android-udeb package to
ship DroidSansFallback.ttf instead of DroidSansFallbackFull.ttf, which
seems to do the job for Korean. But I don't really want to risk
triggering regressions for other languages, so adding a fonts-nanum-udeb
package would seem like my preferred path right now. Nevertheless,
having checked the file size now, that means adding a 4.2 MB file, which
doesn't seem too good either. :(

Comments/suggestions most welcome…


KiBi.


signature.asc
Description: Digital signature

Bug#853947: [Swan-dev] Bug#853947: libreswan FTBFS on mips and mipsel: error: "_ABI64" is not defined [-Werror=undef]

[Paul Wouters]

On Thu, 2 Feb 2017, Daniel Kahn Gillmor wrote:


Over on https://bugs.debian.org/853947 you wrote:



Package libreswan_3.19-1 FTBFS on mips and mipsel with following error:


In file included from /usr/include/nspr/prtypes.h:26:0,
 from /usr/include/nspr/plarena.h:15,
 from /usr/include/nss/cert.h:13,
 from /«PKGBUILDDIR»/lib/libswan/nss_copies.c:6:
/usr/include/nspr/prcpucfg.h:511:18: error: "_ABI64" is not defined 
[-Werror=undef]
 #if _MIPS_SIM == _ABI64
  ^~
cc1: all warnings being treated as errors
../../../mk/depend.mk:28: recipe for target 'nss_copies.o' failed
make[5]: *** [nss_copies.o] Error 1



I appreciate the patch, but i think excluding the warning is probably
not a great idea -- presumably, upstream should be doing something
differently there.

I'm cc'ing upstream on this.



If this is something you can fix upstream, i'm happy to pull the patch
into debian's packaging directly.


Can you try the attached patch?

Totally untested, because I don't have that build environment, and based
on some random googling :)

Pauldiff --git a/lib/libswan/nss_copies.c b/lib/libswan/nss_copies.c
index b90bbf0..16976db 100644
--- a/lib/libswan/nss_copies.c
+++ b/lib/libswan/nss_copies.c
@@ -3,6 +3,10 @@
  * file, You can obtain one at http://mozilla.org/MPL/2.0/.
  */
 
+#ifdef _MIPS_SIM
+# include 
+#endif
+
 #include 
 #include 
 #include "nss_copies.h"

Bug#854013: grub-common: GRUB_DEFAULT=saved/GRUB_SAVEDEFAULT=true does not save default in usable way

[Jameson Graef Rollins]

Package: grub-common
Version: 2.02~beta3-3
Severity: normal

Grub on this machine has been configured to boot into the previously selected 
entry:

GRUB_DEFAULT=saved
GRUB_SAVEDDEFAULT=true

However, grub is not booting into the saved entry.  The entry being
selected is the fourth entry in the first submenu, i.e.:

submenu 'Advanced options for Debian GNU/Linux'
menuentry 'Debian GNU/Linux, with Linux 3.2.0-rts-amd64'

What is being stored in the grubenv is:

controls@eve:~ 0$ grub-editenv list
saved_entry=4
controls@eve:~ 0$ 

It appears that '4' is not a valid number to map to the correct
menuentry, so grub is therefore falling back to first menuentry.
If GRUB_DEFAULT is set to:

GRUB_DEFAULT='Advanced options for Debian GNU/Linux>Debian GNU/Linux, with 
Linux 3.2.0-rts-amd64'

Then it does boot correctly.

Thanks for maintaining.

jamie.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 
rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/usb-_USB_FLASH_DRIVE_1981160802E3-0:0
(hd1)   /dev/disk/by-id/ata-Hitachi_HUA722010CLA330_JPW9K0N13RUV4L
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd1,msdos1'  
225dc4b7-fd01-4d1c-8312-b28b03a58281
else
  search --no-floppy --fs-uuid --set=root 225dc4b7-fd01-4d1c-8312-b28b03a58281
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=1280x1024
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-225dc4b7-fd01-4d1c-8312-b28b03a58281' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd1,msdos1'  
225dc4b7-fd01-4d1c-8312-b28b03a58281
else
  search --no-floppy --fs-uuid --set=root 
225dc4b7-fd01-4d1c-8312-b28b03a58281
fi
echo'Loading Linux 3.16.0-4-amd64 ...'
linux   /boot/vmlinuz-3.16.0-4-amd64 
root=UUID=225dc4b7-fd01-4d1c-8312-b28b03a58281 ro  quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-3.16.0-4-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-225dc4b7-fd01-4d1c-8312-b28b03a58281' {
menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-3.16.0-4-amd64-advanced-225dc4b7-fd01-4d1c-8312-b28b03a58281' {
load_video

Bug#854012: libproxy-tools: Not working with MATE in Stretch

[Ivan Baldo]

Package: libproxy-tools
Version: 0.4.13-1.1
Severity: important

$ echo http://www.example.com/ | proxy
direct://

But in MATE in the network proxy settings I have setup my proxy in 
multiple ways, none of which

works.
Please, if someone is using MATE with current Stretch, try configuring a 
proxy, even a fake or non

existent one, and run that command to check that it says to use it.
Ideas of things to try are welcome too.
Thanks!!!

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

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

Versions of packages libproxy-tools depends on:
ii  libc62.24-8
ii  libproxy1v5  0.4.13-1.1

libproxy-tools recommends no packages.

libproxy-tools suggests no packages.

-- no debconf information

Bug#853125: [PATCH] fix typos in dgit documentation

[Nicholas D Steeves]

On Mon, Jan 30, 2017 at 10:54:35AM +, Ian Jackson wrote:
> 
> Hi.  Thanks for the fixes.  FYI those documents were written by me:
> Sean's seem to have fewer typos :-).

:-)  Sean is amazing with details!

> FYI I hope to get RM approval for a bugfix upload for stretch, and
> would probably want to include these changes in it.

Brilliant!  For future reference, is RM approval needed during
soft-freeze?

Sincerely,
Nicholas


signature.asc
Description: Digital signature

Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible

[Michael Biebl]

Am 03.02.2017 um 02:12 schrieb Michael Biebl:

> 
> I wouldn't change anything for stretch and keep the status quo.
> 

And as already said, once we have support for user services in i-s-h,
this can be revisited post stretch.

-- 
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#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible

[Michael Biebl]

Am 03.02.2017 um 02:08 schrieb Daniel Kahn Gillmor:
> Hi Yuri--
> 
> On Wed 2017-02-01 17:25:44 -0500, Yuri D'Elia wrote:
>> Package: gnupg-agent
>> Version: 2.1.18-3
>> Severity: normal
>>
>> According to upstream, it's incorrect to ship user/sockets.target.wants/* 
>> files
>> directly, as those cannot be disabled by the administrator.
>>
>> Quote:
>>
>>   ... should instead ship this with an [install] section and enable it at
>>   package install time with "systemctl preset --global gpg-agent.socket" ...
>>   that you way can "systemctl disable --global gpg-agent.socket" whenever you
>>   like.
>>
>> See: https://github.com/systemd/systemd/issues/5179#issuecomment-276797851
> 
> Thanks for this suggestion, however, Michael Biebl (one of debian's
> systemd maintainers, cc'ed here) explicitly suggested shipping the
> symlink there:
> 
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678#51
> 
> If i've misunderstood that comment, i'm happy to be corrected.
> 
> I'm open to concrete suggestions for how this should change for stretch
> that won't cause future problems, though by now we'd need to ask for a
> freeze exception to get any such update included.

I wouldn't change anything for stretch and keep the status quo.

-- 
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#853921: ttx and grep result for DroidSansFallback(Full)?.ttf

[Cyril Brulebois]

Hi,

victory  (2017-02-03):
> added testing src apt line, apt update, apt-get source ..., tar zxf ...
> $ ttx DroidSansFallback.ttf
> $ ttx DroidSansFallbackFull.ttf
> these 2 generate [filename].ttx
> 
> (just FYI, used letters (in ko) other than 7-bit are in 0xac00-0xd790 range)
> 
> $ grep Hangul DroidSansFallback.ttx prints 22344 lines
>   
>   
>   
>   
>   
>   
> ...
>   
>   
>   
>   
>   
>   
> 
> $ grep Hangul DroidSansFallbackFull.ttx prints only 6 lines:
>   
>   
>   
>   
>   
>   
> 
> so, the latter has only 1 Hangul glyph (0xac00, 가) to be used in d-i
> (0xd7a2 and 0xd7a3 are not used in d-i)

I think this matches what happened upstream (warning, big repository:
https://android.googlesource.com/platform/frameworks/base):
| commit 562c45cc841681ed80d4e94515b23c28eb60eae4
| Author: Bart Sears 
| Date:   Mon Sep 24 00:32:57 2012 -0700
| 
| Updated versions of DroidSansFallback
| 
| Latest versions of DroidSansFallback from Monotype.
| 
| The DroidSansFallback.ttf file has some additional glyphs and
| glyph fixes (including a fix for bug 6723057 and will likely fix
| bug 6629748).  It continues to cover Korean Hangul but does not
| cover CJK Ext A (for space reasons on small system image devices).
| The DroidSansFallbackFull.ttf file has the bug fixes listed and
| also removes the Korean Hangul because we are now going to use
| NanumGothic for Korean (NanumGothic.ttf is added in a separate
| CL in the external/naver-fonts directory).
| 
| The falback_fonts.xml file has been modified to add NanumGothic.ttf
| before DroidSansFallback.
| 
| Bug: 4531601
| Bug: 6723057
| Bug: 6629748
| Change-Id: I670d33078b4a97c4eda00fc2323be187696e927a

even if how tags/versions in that repository match fonts-android's isn't
too clear to me.

Anyway, inspired by the commit message above, I've just built a d-i
image with an extra /usr/share/fonts/truetype/nanum/NanumGothic.ttf
taken from the fonts-nanum package, and it seems to work fine! (For
someone who only knows what Korean glyphs can look like…) I've attached
a screenshot, feel free to double check.

I think I'll send a patch against src:fonts-nanum to request a udeb
addition, then add it to src:debian-installer. And close the bug report
against src:fonts-android.

Any comment/objection?


KiBi.


signature.asc
Description: Digital signature

Bug#853858: /usr/bin/apt-key: cannot add gpg keys due to their large size

[Daniel Kahn Gillmor]

Hi Kim Yeon-Soo--

On Thu 2017-02-02 01:34:12 -0500, Kim Yeon-Soo wrote:
> Thank you. It is hard to search "Singed-By:" option on the forums.

Sorry about that!  I didn't mean to be obscure.  When i wrote "(see
sources.list(5))" i meant "see the documentation about sources.list in
section 5 of the system manual", which can be done from the command line
with :

 man 5 sources.list

Or you can also see that online here:

 
https://manpages.debian.org/testing/apt/sources.list.5.en.html#THE_DEB_AND_DEB-SRC_TYPES:_OPTIONS

If you search within there, you'll see documentation for Signed-By and
related options.

> I solved the problem in Synaptic Package Manager by
>
>  menu -> Setting -> Repository -> Authentication -> Import Key File.
>
> I guess it imports the keys into /etc/apt/trusted.gpg.
>
> Using "Signed-By:" option seems better solution than this.

agreed, it would be better to use Signed-By than to import these
external keys into /etc/apt/trusted.gpg.

Regards,

--dkg

PS Also, sorry for greeting you as "? ??" earlier, i can only assume
   that your name was mangled by some mail transfer agent that processed
   this bug report.  Those were the only characters i had in the
   original headers. :(


signature.asc
Description: PGP signature

Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible

[Daniel Kahn Gillmor]

Hi Yuri--

On Wed 2017-02-01 17:25:44 -0500, Yuri D'Elia wrote:
> Package: gnupg-agent
> Version: 2.1.18-3
> Severity: normal
>
> According to upstream, it's incorrect to ship user/sockets.target.wants/* 
> files
> directly, as those cannot be disabled by the administrator.
>
> Quote:
>
>   ... should instead ship this with an [install] section and enable it at
>   package install time with "systemctl preset --global gpg-agent.socket" ...
>   that you way can "systemctl disable --global gpg-agent.socket" whenever you
>   like.
>
> See: https://github.com/systemd/systemd/issues/5179#issuecomment-276797851

Thanks for this suggestion, however, Michael Biebl (one of debian's
systemd maintainers, cc'ed here) explicitly suggested shipping the
symlink there:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678#51

If i've misunderstood that comment, i'm happy to be corrected.

I'm open to concrete suggestions for how this should change for stretch
that won't cause future problems, though by now we'd need to ask for a
freeze exception to get any such update included.

Regards,

   --dkg

PS the unit is still maskable in its current setup, as noted in
README.Debian.


signature.asc
Description: PGP signature

Bug#853935: [pkg-gnupg-maint] Bug#853935: rephrase: No more works with gpg2 and causes one pinentry popup per guess

[Daniel Kahn Gillmor]

Control: affects 853935 + src:gnupg2

Hi folks--

On Thu 2017-02-02 05:37:30 -0500, Axel Beckert wrote:
> It seems that rephrase is incompatible or at least not yet ported to
> GnuPG 2.x.
>
> Trying to use it on Sid or Stretch causes one pinentry window popup per
> guessed try (i.e. potentially thousands). And since pinentry usually
> grabs the keyboard, I can't press Ctrl-C or similar on rephrase itself.
>
> Pressing Cancel or the Escape key in the pinentry window does not end
> the rephrase session either but just makes the next pinentry window pop
> up. This makes the X session unusable until either:
>
> * No more tries are left
> * gpg is killed from outside the X session (e.g. text console or via SSH)
>
> I then tried to see if it at least works in general and tried it with
> only very few variants (2 variants, hence 4 tries), but even if the
> correct passphrase was under those very few tries (tried with 2 and 4
> tries), rephrase fails to recognize the correct passphrase and always
> ends with the following message:
>
>   Passphrase doesn't match pattern (or no such key/file/device)
>
> I think to solve this issue for Debian Stretch in the short term,
> rephrase needs to
>
> 1) depend on "gnupg1" instead of "gnupg", and
> 2) replace all calls to "gpg" with "gpg1".
>
> The following patch fixes the issue for me and also reports the correct
> passphrase if it was under the given variants.

I don't think this is a sensible change, given the purpose of rephrase.

the 2.1.x version of GnuPG (which is what will offer /usr/bin/gpg in
debian stretch) stores its secret key material in a different way
(~/.gnupg/private-keys-v1.d) than gpg1 does (~/.gnupg/secring.gpg).  If
you want rephrase to recover a partially-known passphrase against gpg
2.1.x, having one that "works" against gpg1 isn't going to be useful at
all.

A better short-term fix would be to add "--pinentry-mode", "loopback" to
the arguments passed to the gpg invocations in rephrase.c.

A slightly more robust fix would be to only add those extra arguments
conditionally, if the version of gpg is known to be >= 2.1 (for debian,
we could ignore this and just set a versioned dependency on the gnupg
package).

An even better fix, if the secret is stored in the 2.1.x way, would be
to connect to gpg-agent directly and never need to launch a new process,
but that would be a pretty large overhaul.

--dkg


signature.asc
Description: PGP signature

Bug#854011: soundmodem: does not have systemd unit

[Dave Hibberd]

Package: soundmodem
Version: 0.20-5
Severity: wishlist
Tags: patch

Dear Maintainer,

Soundmodem currently has no SystemD unit in Debian for startup with the system.
This feature would be helpful for standalone packet systems to boot/reboot and 
come back to normal service automatically.

Please find below a suggested unit file, which has been tested on my systems 
and 
I am satisfied works.

This has a slight variation on the description from what I preemptively 
committed to debian git repo at:
https://anonscm.debian.org/cgit/pkg-hamradio/soundmodem.git

I hope this is helpful!

Thanks,
DH

=

[Unit]
Description=Soundmodem SystemD service file
After=sound.target network.target multi-user.target

[Service]
Type=forking
ExecStart=/usr/sbin/soundmodem --daemonize -s
Group=tty

[Install]
WantedBy=multi-user.target

-- System Information:
Debian Release: 9.0
  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=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages soundmodem depends on:
ii  libasound2  1.1.2-1
ii  libatk1.0-0 2.22.0-1
ii  libaudiofile1   0.3.6-3
ii  libc6   2.24-8
ii  libgdk-pixbuf2.0-0  2.36.3-1
ii  libglib2.0-02.50.2-2
ii  libgtk2.0-0 2.24.31-1
ii  libhamlib2  3.0.1-1+b1
ii  libpango-1.0-0  1.40.3-3
ii  libxml2 2.9.4+dfsg1-2.1

soundmodem recommends no packages.

soundmodem suggests no packages.

-- Configuration Files:
/etc/ax25/soundmodem.conf changed [not included]

-- no debconf information


signature.asc
Description: PGP signature

Bug#854010: ubuntu-dev-tools: pull-lp-source not getting source pkg for binary name

[Dan Streetman]

Package: ubuntu-dev-tools
Version: 0.158
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

Calling pull-lp-source with the name of a binary package fails to get the
corresponding source package.

In Ubuntu, this is tracked with bug 1453330:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1453330

This patch corrects that so pull-lp-source will correctly lookup the source
package name for any binary package name provided.

Thanks for considering the patch.
diff -Nru ubuntu-dev-tools-0.157/pull-lp-source ubuntu-dev-tools-0.158/pull-lp-source
--- ubuntu-dev-tools-0.157/pull-lp-source	2016-05-09 00:56:05.0 -0400
+++ ubuntu-dev-tools-0.158/pull-lp-source	2017-02-02 16:52:52.0 -0500
@@ -40,25 +40,36 @@
 from ubuntutools.logger import Logger
 from ubuntutools.misc import split_release_pocket
 
+from launchpadlib.launchpad import Launchpad as LP
 
-def source_package_for(binary, release):
-"""Query DDE to find the source package for a particular binary
-Should really do this with LP, but it's not possible LP: #597041
-"""
-url = ('http://dde.debian.net/dde/q/udd/dist/d:ubuntu/r:%s/p:%s/?t=json'
-   % (release, binary))
-data = None
-try:
-data = json.load(urllib2.urlopen(url))['r']
-except urllib2.URLError, e:
-Logger.error('Unable to retrieve package information from DDE: '
- '%s (%s)', url, str(e))
-except ValueError, e:
-Logger.error('Unable to parse JSON response from DDE: '
- '%s (%s)', url, str(e))
-if not data:
+
+def getSPPH(lp, archive, package, version, series, pocket, try_binary=True):
+params = { 'exact_match': True, 'order_by_date': True, }
+if pocket:
+params['pocket'] = pocket
+if series:
+params['distro_series'] = series()
+else:
+params['version'] = version
+spphs = archive.getPublishedSources(source_name=package, **params)
+if spphs:
+return spphs[0]
+if not try_binary:
 return None
-return data[0]['source']
+
+# Didn't find any, maybe the package is a binary package name
+if series:
+del params['distro_series']
+archs = lp.load(series().architectures_collection_link).entries
+params['distro_arch_series'] = archs[0]['self_link']
+bpphs = archive.getPublishedBinaries(binary_name=package, **params)
+if bpphs:
+bpph_build = lp.load(bpphs[0].build_link)
+source_package = bpph_build.source_package_name
+return getSPPH(lp, archive, source_package, version, series, pocket,
+   try_binary=False)
+
+return None
 
 
 def main():
@@ -85,6 +96,7 @@
 
 # Login anonymously to LP
 Launchpad.login_anonymously()
+lp = LP.login_anonymously("pull-lp-source", "production")
 
 package = str(args[0]).lower()
 
@@ -106,29 +118,25 @@
 (release, pocket) = split_release_pocket(version, default=None)
 except PocketDoesNotExistError, e:
 pass
+
+distro = Distribution('ubuntu')
+archive = distro.getArchive()
+
+series = None
 if release in ubuntu_info.all:
-archive = Distribution('ubuntu').getArchive()
-try:
-spph = archive.getSourcePackage(package, release, pocket)
-except SeriesNotFoundException, e:
-Logger.error(str(e))
-sys.exit(1)
-except PackageNotFoundException, e:
-source_package = source_package_for(package, release)
-if source_package is not None and source_package != package:
-try:
-spph = archive.getSourcePackage(source_package, release,
-pocket)
-package = source_package
-except PackageNotFoundException:
-Logger.error(str(e))
-sys.exit(1)
-else:
-Logger.error(str(e))
-sys.exit(1)
+series = distro.getSeries(release)
 
-version = spph.getVersion()
-component = spph.getComponent()
+spph = getSPPH(lp, archive, package, version, series, pocket)
+if not spph:
+Logger.error("Package %s not found in %s", package, release)
+sys.exit(1)
+
+if package != spph.source_package_name:
+Logger.normal("Using source package %s for %s",
+  spph.source_package_name, package);
+package = spph.source_package_name
+version = spph.source_package_version
+component = spph.component_name
 
 Logger.normal('Downloading %s version %s', package, version)
 srcpkg = UbuntuSourcePackage(package, version, component=component,

Bug#854004: live-config: keyboard configuration in live-build image now working

[sp113438]

On Thu, 02 Feb 2017 23:49:15 +0100
Dieter Scholz  wrote:

Hello,

keyboard-layouts=de ?
keyboard-layout=de
perhaps, just a guess?

greetings

> Package: live-config
> Version: 5.20170112
> Severity: normal
> Tags: l10n
> 
> Hello,
> 
> I tried to build a customized live image with live-build. To
> configure my keyboard I'm using the following boot append options:
> 
> locales=de_DE.UTF-8 timezone=Europe/Berlin keyboard-model=pc105
> keyboard-layouts=de
> 
> I found these options in the man page.
> 
> They have no effect when I boot my CD. If I execute
> 
> dpkg-reconfigure -f noninteractive console-tools
> 
> my keyboard is working. I additionally booted a stock live CDs using
> the above params - without success either. So I think it's a bug.
> 
> Kind regards
> 
> Dieter
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-1-amd64 (SMP w/1 CPU core)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages live-config depends on:
> ii  live-config-systemd [live-config-backend]  5.20170112
> 
> Versions of packages live-config recommends:
> ii  iproute24.9.0-1
> ii  keyboard-configuration  1.158
> ii  live-config-doc 5.20170112
> ii  live-tools  1:20151214+nmu1
> ii  locales 2.24-8
> ii  sudo1.8.19p1-1
> ii  user-setup  1.67
> 
> Versions of packages live-config suggests:
> ii  pciutils  1:3.5.2-1
> ii  wget  1.18-4
> 
> -- no debconf information
> 

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

[NIIBE Yutaka]

Hello,

Thanks to dkg to explicitly CC me.

On Thu 2017-02-02 17:54:26 -0500, Wouter Verhelst wrote:
> Since a recent upgrade, gnupg-agent no longer finds the authentication
> (SSH) key on my OpenPGP smartcard:
>
> wouter@gangtai:~$ gpg --card-status

It should be an issue of scdaemon.  For 2.1.18, I added multiple card
reader support.  This might be a possible cause.  Please let me know, if
2.1.17 worked fine or not.

Daniel Kahn Gillmor  wrote:
> is the key you expect to use listed in ~/.gnupg/sshcontrol ?  I'd expect
> it to be listed by its keygrip, which i think is:
>
> 40277D42041E8A6E9AC9206FB335DDBA4B57A505

No, this line is not needed for card; It is automatically available for
auth key on card.

I'm now at NRT airport to BRU.  So, I won't be available for 12 hours or
so.
-- 

Bug#853947: libreswan FTBFS on mips and mipsel: error: "_ABI64" is not defined [-Werror=undef]

[Daniel Kahn Gillmor]

Hi Radovan--

Over on https://bugs.debian.org/853947 you wrote:

On Thu 2017-02-02 07:02:59 -0500, Radovan Birdic wrote:
> Package: libreswan
> Version: 3.19-1
> Severity: important
> Tags: sid + patch
> Justification: FTBFS
> User: debian-m...@lists.debian.org
> Usertags: mips-patch
>
>
> Package libreswan_3.19-1 FTBFS on mips and mipsel with following error:
>
>> In file included from /usr/include/nspr/prtypes.h:26:0,
>>  from /usr/include/nspr/plarena.h:15,
>>  from /usr/include/nss/cert.h:13,
>>  from /«PKGBUILDDIR»/lib/libswan/nss_copies.c:6:
>> /usr/include/nspr/prcpucfg.h:511:18: error: "_ABI64" is not defined 
>> [-Werror=undef]
>>  #if _MIPS_SIM == _ABI64
>>   ^~
>> cc1: all warnings being treated as errors
>> ../../../mk/depend.mk:28: recipe for target 'nss_copies.o' failed
>> make[5]: *** [nss_copies.o] Error 1
>
> Full build log:
> https://buildd.debian.org/status/fetch.php?pkg=libreswan=mips=3.19-1=1485409760=0
>
> On 32-bit mips (ABIO32) _ABI64 is not defined so using -Wundef flag causes 
> build failure.
>
> I have created and attached a patch that exclude this flag for mips/mipsel.
> With this patch package builds successfully on mips, mipsel and  mips64el.
>
> Regards,
> Radovan
> --- libreswan-3.19_orig/debian/rules  2017-01-25 23:37:04.0 +
> +++ libreswan-3.19/debian/rules   2017-02-02 20:01:47.654502204 +
> @@ -1,5 +1,12 @@
>  #!/usr/bin/make -f
>  
> +DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
> +ifneq (,$(filter $(DEB_BUILD_ARCH),mips mipsel))
> +   ADDITIONAL_WARNING_CFLAGS = -Wall -Wextra -Wformat 
> -Wformat-nonliteral -Wformat-security -Wmissing-declarations 
> -Wredundant-decls -Wnested-externs
> +else
> +   ADDITIONAL_WARNING_CFLAGS = -Wall -Wextra -Wformat 
> -Wformat-nonliteral -Wundef -Wformat-security -Wmissing-declarations 
> -Wredundant-decls -Wnested-externs
> +endif
> +
>  %:
>   dh $@ --with systemd
>  
> @@ -17,7 +24,8 @@ override_dh_auto_build:
>   USE_LIBCAP_NG=true \
>   USE_LABELED_IPSEC=false \
>   USE_KLIPS=false \
> - USE_DNSSEC=true
> + USE_DNSSEC=true \
> + WARNING_CFLAGS="$(ADDITIONAL_WARNING_CFLAGS)"
>  
>  override_dh_auto_install-arch:
>   # Add here commands to install the package into debian/libreswan

I appreciate the patch, but i think excluding the warning is probably
not a great idea -- presumably, upstream should be doing something
differently there.

I'm cc'ing upstream on this.

upstream folks, you can see build logs for 3.1.19-1 on debian over here:

  https://buildd.debian.org/status/logs.php?pkg=libreswan=3.19-1=sid

The failing mips build log is here:

  
https://buildd.debian.org/status/fetch.php?pkg=libreswan=mips=3.19-1=1485409760=0

and the failing mipsel build log is here:

  
https://buildd.debian.org/status/fetch.php?pkg=libreswan=mipsel=3.19-1=1485507191=0

If this is something you can fix upstream, i'm happy to pull the patch
into debian's packaging directly.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#854009: soundmodem: starts kiss device with incorrect permissions

[Dave Hibberd]

Package: soundmodem
Version: 0.20-5
Severity: normal
Tags: patch

Dear Maintainer,

Running soundmodem creates a kiss serial device with permissions that render it 
inaccessible to normal users, or users in the tty group.

Upon starting soundmodem with Channel "Packet IO" Mode set as KISS, soundmodem 
creates a pty and a link to that file, /dev/soundmodem*.

Normal users, and users in the tty group cannot access this device - this means 
packet programs, such as Xastir, have to be run as root. 

Listing the file permissions of the created devices shows:

→ ls -al /dev/soundmodem0
lrwxrwxrwx 1 root root 10 Feb  3 00:18 /dev/soundmodem0 -> /dev/pts/6

→ ls -al /dev/pts/6
crw--w 1 root tty 136, 6 Feb  3 00:18 /dev/pts/6

While root has rw on /dev/pts/6, group tty only has w. Applications cannot read 
the terminal and show accessing it has failed.

I have included a very minor patch which details a proposed fix below. The 
patch 
allows members of the 'tty' group to read and write to the pty device.

This has been committed to in the debian git server and can be viewed at:
https://anonscm.debian.org/cgit/pkg-hamradio/soundmodem.git/ however it can be 
discarded as per maintainer's choice. 


Descriptions: Allow group to read/write the created pty
Author: Dave Hibberd 
Last-Updated: 2017-02-24

--- a/soundcard/kisspkt.c
+++ b/soundcard/kisspkt.c
@@ -758,7 +758,7 @@
 tm.c_cflag = CS8 | CREAD | CLOCAL;
 if (tcsetattr(slave, TCSANOW, ))
 logerr(MLOG_FATAL, "slave: tcsetattr");
-   //fchmod(slave, 0600);
+   fchmod(slave, 0660);
if (dounlink)
unlink(file);
if (symlink(ttyname, file))


-- System Information:
Debian Release: 9.0
  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=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages soundmodem depends on:
ii  libasound2  1.1.2-1
ii  libatk1.0-0 2.22.0-1
ii  libaudiofile1   0.3.6-3
ii  libc6   2.24-8
ii  libgdk-pixbuf2.0-0  2.36.3-1
ii  libglib2.0-02.50.2-2
ii  libgtk2.0-0 2.24.31-1
ii  libhamlib2  3.0.1-1+b1
ii  libpango-1.0-0  1.40.3-3
ii  libxml2 2.9.4+dfsg1-2.1

soundmodem recommends no packages.

soundmodem suggests no packages.

-- Configuration Files:
/etc/ax25/soundmodem.conf changed:


  




  
  
  

  



-- no debconf information


signature.asc
Description: PGP signature

Bug#851842: [Pkg-tigervnc-devel] Bug#851842: Bug#851842: tigervnc-xorg-extension - libvnc.so fails to load with undefined symbol: gnutls_bye

[Joachim Falk]

Hi all,

Am 30.01.2017 um 03:45 schrieb Martin Dorey:
> On Fri, 20 Jan 2017 22:10:29 +0100 Ola Lundqvist  > wrote:
>> I have now been able to reproduce the problem. It is not solved by
>> merely adding more dependencies. I have to look further to find the
>> cause of the problem.
> 
> Hey Ola,
> 
> I think I can help.  First, though, I'm delighted to see that your ITP for 
> tigervnc went through for Stretch.  But is that still a default -depth of 32 
> I see - how are the poor users going to work out that they need to try -depth 
> 24, per the warning in man xtigervnc, to get their, eg Java, text rendered 
> properly?  Anyway, I think the problem here has the same cause as the similar 
> one described by:
I have tested -depth 32 with some applications and it really is a problem, 
i.e., VMware workstation bugs out with this setting.
I think we should switch the default to -depth 24.

> 
> https://github.com/TigerVNC/tigervnc/issues/294: unable to load libvnc.so 
> after installing 1.5.x or 1.6.0
> 
> I had another great experience with tigervnc-standalone-server this weekend, 
> which lets me connect to Gnome 3 over a metro area as if I were in the 
> office, in contrast to vino, where I have to tolerate several megabits per 
> second of background traffic when idle, making interactivity unusably slow.  
> Thus I wanted to replace vino with tigervnc-xorg-extension on the :0 of my 
> just-upgraded-to-Jessie server.  I faced:
> 
> [238863.164] (EE) Failed to load /usr/lib/xorg/modules/extensions/libvnc.so: 
> /usr/lib/xorg/modules/extensions/libvnc.so: undefined symbol: 
> gnutls_transport_set_ptr2
> 
> ... which looks exactly like part of upstream's problem.  On a Stretch 
> system, with Debian's (yay!) native packaging, I see the gnutls_bye symptom 
> instead.  If I rebuild your Sid packaging, from apt-get source tigervnc, with:
> 
> mad@shuttle:~/tigervnc-1.7.0+dfsg$ dpkg-buildpackage -nc -uc -us
> 
> ... then apply upstream's patch, in my so very crude fashion, using what I 
> think, having looked it up, is the shiniest flavor of Ubuntu that upstream 
> supports:
> 
> mad@shuttle:~/tigervnc-1.7.0+dfsg$ (cd unix/xserver && patch -p1 < 
> ../../contrib/packages/deb/ubuntu-xenial/debian/xorg-source-patches/debian_libtool.patch)
> checking file ltmain.sh
> Hunk #1 succeeded at 7893 (offset 3 lines).
> checking file ltmain.sh
> Hunk #1 succeeded at 7571 (offset 3 lines).
> checking file m4/libtool.m4
> Hunk #1 succeeded at 4947 (offset 11 lines).
> Hunk #2 succeeded at 5009 (offset 14 lines).
> Hunk #3 succeeded at 5784 (offset 17 lines).
> mad@shuttle:~/tigervnc-1.7.0+dfsg$ 
> 
> As you see, I get a reasonably clean application, but libvnc.so didn't 
> rebuild when I repeated the dpkg-buildpackage command.  Oh, for the simple 
> days, when dependencies were complete and "make" was all you needed!  Just 
> removing the .so got me a build failure, causing more sadly grey-bearded 
> head-shaking, but removing the .la and .lai files too:
> 
> mad@shuttle:~/tigervnc-1.7.0+dfsg$ find . -name libvnc.* | xargs rm
> mad@shuttle:~/tigervnc-1.7.0+dfsg$
> 
> ... then repeating the dpkg-buildpackage command got me a 
> ./debian/tigervnc-xorg-extension/usr/lib/xorg/modules/extensions/libvnc.so 
> that, when used to replace 
> /usr/lib/xorg/modules/extensions/libvnc.so, effaces the (EE) error from 
> wherever ls -l /proc/$(pidof Xorg)/fd told me that the squirrels had buried 
> Xorg.0.log.  xdpyinfo now happily reports:
> 
> mad@shuttle:~$ xdpyinfo | grep VNC
> VNC-EXTENSION
> mad@shuttle:~$ 
> 
> Sorry to make such a meal of such a trivial nugget, but I want to convey how 
> little I understand.  Now, if you'll excuse me, I'm off to try to similarly 
> brutalize the old Jessie packaging of tigervnc 1.6.0, if I still have it 
> lying around, to see if I can get back in to :0 on the server that I actually 
> care about...
> 
> 
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
> 




signature.asc
Description: OpenPGP digital signature

Bug#827061: transition: openssl

[Holger Levsen]

On Thu, Feb 02, 2017 at 09:49:15PM +0100, Sebastian Andrzej Siewior wrote:
> what is wrong with passing -j16 to sbuild? Other packages, that do not
> support parallel building, don't do it.

yeah, exactly.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#854008: kstars-data-extra-tycho2: deepstars.dat installed in wrong directory

[Jan Echternach]

Package: kstars-data-extra-tycho2
Version: 1.1r1-9
Severity: grave
Justification: renders package unusable

The current testing version of kstars, version 4:16.08.3-1, expects
deepstars.dat to reside in /usr/share/kstars along with its other data files.
However, the current testing version of kstars-data-extra-tycho2 installs it
in /usr/share/kde4/apps/kstars where it is ignored by kstars.

A short snippet from the kstars startup messages:

  Opened the User DB. Ready.
  Processing  "unnamedstars.dat" , HTMesh Level 3
Sky Mesh Size:  512
  Loaded DSO catalog file:  "unnamedstars.dat"
  "Star HD61421 not found."
  "Star HD10700 not found."

After I created a symlink from /usr/share/kde4/apps/kstars/deepstars.dat to
/usr/share/kstars/deepstars.dat:

  Opened the User DB. Ready.
  Processing  "unnamedstars.dat" , HTMesh Level 3
Sky Mesh Size:  512
  Loaded DSO catalog file:  "unnamedstars.dat"
  Processing  "deepstars.dat" , HTMesh Level 3
Sky Mesh Size:  512
  Loaded DSO catalog file:  "deepstars.dat"
  "Star HD61421 not found."
  "Star HD10700 not found."


-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (813, 'stable'), (812, 'oldstable'), (600, 'unstable-debug'), 
(600, 'unstable'), (550, 'testing-debug'), (550, 'testing'), (510, 
'experimental-debug'), (510, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kstars-data-extra-tycho2 depends on:
ii  debconf [debconf-2.0]  1.5.56

kstars-data-extra-tycho2 recommends no packages.

kstars-data-extra-tycho2 suggests no packages.

-- debconf information excluded

Bug#852865: unblock: gnome-orca/3.22.2-2

[Samuel Thibault]

Hello,

Niels Thykier, on Sat 28 Jan 2017 10:25:00 +, wrote:
> Upload, make sure it has no regressions (RC bugs, builds, etc. etc.)
> and let us know when it is just needs aging to migrate.  If that time
> is before 04/02, it will be accepted.

This looks good so far.  The bug is confirmed to be gone, and the users
haven't reported any regression.  It is an arch:all package, so no
arch-specific build issue :)

Samuel

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

[Daniel Kahn Gillmor]

Control: reassign 854005 scdaemon

Hi Wouter--

On Thu 2017-02-02 17:54:26 -0500, Wouter Verhelst wrote:
> Since a recent upgrade, gnupg-agent no longer finds the authentication
> (SSH) key on my OpenPGP smartcard:
>
> wouter@gangtai:~$ gpg --card-status
>
> Reader ...: ACS ACR38U 00 00
> Application ID ...: D27600012401020100054736
> Version ..: 2.1
> Manufacturer .: ZeitControl
> Serial number : 4736
> Name of cardholder: Wouter Verhelst
> Language prefs ...: nl
> Sex ..: male
> URL of public key :
> http://pgp.surfnet.nl:11371/pks/lookup?op=get=0x9B69FDF3F0DA0948066129F72DFC519954181296
> Login data ...: [not set]
> Signature PIN : forced
> Max. PIN lengths .: 32 32 32
> PIN retry counter : 3 0 3
> Signature counter : 116
> Signature key : 9B69 FDF3 F0DA 0948 0661  29F7 2DFC 5199 5418 1296
>   created : 2016-04-11 11:46:27
> Encryption key: B057 2256 DD3D 8275 A1F2  3015 EBC4 535B 0557 DB14
>   created : 2016-04-11 11:46:27
> Authentication key: B7D1 52E7 6233 6135 DBEF  6435 965E 159D 1F28 844B
>   created : 2016-04-11 11:46:27
> General key info..: pub  rsa4096/2DFC519954181296 2016-04-11 Wouter
> Verhelst 
> sec>  rsa4096/2DFC519954181296  created: 2016-04-11  expires: never 
> card-no: 0005 4736
> ssb>  rsa4096/965E159D1F28844B  created: 2016-04-11  expires: never 
> card-no: 0005 4736
> ssb>  rsa4096/EBC4535B0557DB14  created: 2016-04-11  expires: never 
> card-no: 0005 4736
> wouter@gangtai:~$ echo "foo bar" | gpg -r 54181296 -e | gpg
> gpg: please do a --check-trustdb
> gpg: 54181296: skipped: public key already present
> gpg: encrypted with 4096-bit RSA key, ID EBC4535B0557DB14, created
> 2016-04-11
>   "Wouter Verhelst "
> foo bar
> wouter@gangtai:~$ echo $SSH_AUTH_SOCK 
> /run/user/1000/gnupg/S.gpg-agent.ssh
> wouter@gangtai:~$ ssh-add -l
> The agent has no identities.
>
> The interesting part of the above is that the last command (the "ssh-add
> -l" bit) actually reads from the card (I can see the cardreader LED
> flash).  It just doesn't find anything.
>
> Note: I removed the "90gpg-agent" file from Xsession.d, since it messes
> up some other SSH key setup that I have, very much in the same way that
> gnome-keyring messes up gpg-agent. With the previous version of
> gpg-agent, it was enough to just run "gpg --card-status" to start the
> agent and make the ssh key stuff work.
>
> Having to fight with all of that is pretty ironic, given that ssh-agent
> actually supports external modules through PKCS#11. Ah well.

i don't have such a device to test with, so i'm not sure how to debug
this with you, but it sounds like it may be an issue with scdaemon
itself, so i'm reassigning it there and cc'ing gniibe in the hopes that
he can provide some insight.

is the key you expect to use listed in ~/.gnupg/sshcontrol ?  I'd expect
it to be listed by its keygrip, which i think is:

40277D42041E8A6E9AC9206FB335DDBA4B57A505

thanks for the report!

--dkg


signature.asc
Description: PGP signature

Bug#852514: libpetsc3.7-dev: leaves alternatives after purge: /usr/lib/petscdir/{3.7, 3.7-real}

[Drew Parsons]

On Wed, 25 Jan 2017 02:42:20 +0100 Andreas Beckmann 
wrote:
> Package: libpetsc3.7-dev
> Version: 3.7.5+dfsg1-3
...
> 
> >From the attached log (scroll to the bottom...):
> 
> 2m18.4s INFO: Warning: Package purging left files on system:
>   /etc/alternatives/petsc3.7 -> /usr/lib/petscdir/3.7.4/x86_64-linux-
gnu-real not owned
>   /etc/alternatives/petsc3.7-real -> /usr/lib/petscdir/3.7.4/x86_64-
linux-gnu-real   not owned
>   /usr/lib/petscdir/   owned by: libpetsc3.7.5-dev:amd64,
libpetsc3.7.4-dev:amd64


Thanks Andreas. Looks like something went awry in libpetsc3.7.4-dev
3.7.4+dfsg1-9. I should be able to track it down.

Drew

Bug#853937: [package:tex-common] dist-upgrade fails on ann error of updmap-sys, teaving tex-common unconfigured

[Norbert Preining]

severity 853937 serious
merge 853970 853937
thanks

> Move to the package.

Already there ..., in fact at texlive-lang-japanese.

Norbert

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

Bug#853150: kalarm.autostart.desktop missing OnlyShowIn=KDE

[David Jarvie]

There is a fix for this issue in KDE Applications 16.08.1 (see  
https://cgit.kde.org/kdepim.git/commit/?h=Applications/16.08=cc2d8bb39417b186bfe40470eba921a64ef6c6c8)

Adding OnlyShowIn=KDE is the wrong solution, since that could prevent KAlarm 
from starting even when the user wants to use it under Gnome or other 
desktops.

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm

Bug#457930: [bug #22095] Possibly wrong code on hppa/ia64

[Bruno Haible]

Update of bug #22095 (project libffcall):

  Status:None => Not a Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you for the notice.

It may be true that on HPPA, there exists two kinds of function pointers:
pointers to code, marked with a bit 1 set, and pointer to a two-word
structure, marked with bit 1 clear.

But the alloc_trampoline_r function allocates one of the first kind; therefore
it is sufficient to test for a function pointer of the first kind in
is_trampoline_r.

If a bug in this area would show up, the unit test would show it. "make check"
would fail.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#848945: Patch to fix empty pool name

[Chris Dos]

I had this same issue: https://github.com/zfsonlinux/pkg-zfs/issues/182

I wrote a patch the requires the setting of the "zpool bootfs" parameter which 
I think should be a requirement anyway.  The other solutions did not seem to 
work in every situation and I was still having issues with some systems.

That patch also checks against multiple "zpool bootfs" parameters or a missing 
entry all together.


Patch START:

*** /tmp/10_linux.orig2017-02-02 08:02:36.926542777 -0700
--- /etc/grub.d/10_linux2017-02-02 15:26:02.138285042 -0700
***
*** 77,85 
  GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} 
${GRUB_CMDLINE_LINUX}"
  fi;;
  xzfs)
! rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 
2>/dev/null || true`
! bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
! LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
  ;;
  esac
 
--- 77,96 
  GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} 
${GRUB_CMDLINE_LINUX}"
  fi;;
  xzfs)
! zfsbootfs=`zpool get bootfs | sed '2,100!d' |  grep -v "-" | awk {'print 
$3'} 2>/dev/null || true`
! if [ "${zfsbootfs}" = "" ]
! then
! echo "zpool bootfs parameter not set.  System will fail to boot!" 1>&2
! elif [ "$(echo ${zfsbootfs} | wc -w)" -gt "1" ]
! then
! echo "Multiple zpool bootfs parameters detected:" 1>&2
! echo ${zfsbootfs} 1>&2
! echo 1>&2
! zfsbootfs=`echo ${zfsbootfs} | awk {'print $1'}`
! echo "Using the first bootfs listed: ${zfsbootfs}" 1>&2
! echo "Final LINUX_ROOT_DEVICE=ZFS=${zfsbootfs}" 1>&2
! fi
! LINUX_ROOT_DEVICE="ZFS=${zfsbootfs}"
  ;;
  esac

Patch END

Save the patch as /tmp/grub_10_linux.patch and apply it to the 
/etc/grub.d/10_linux file:
patch -p1 /etc/grub.d/10_linux /tmp/grub_10_linux.patch


*** /tmp/10_linux.orig	2017-02-02 08:02:36.926542777 -0700
--- /etc/grub.d/10_linux	2017-02-02 15:26:02.138285042 -0700
***
*** 77,85 
  	GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
  	fi;;
  xzfs)
! 	rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 2>/dev/null || true`
! 	bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
! 	LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
  	;;
  esac
  
--- 77,96 
  	GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
  	fi;;
  xzfs)
! 	zfsbootfs=`zpool get bootfs | sed '2,100!d' |  grep -v "-" | awk {'print $3'} 2>/dev/null || true`
! 	if [ "${zfsbootfs}" = "" ]
! 	then
! 		echo "zpool bootfs parameter not set.  System will fail to boot!" 1>&2 
! 	elif [ "$(echo ${zfsbootfs} | wc -w)" -gt "1" ]
! 	then
! 		echo "Multiple zpool bootfs parameters detected:" 1>&2
! 		echo ${zfsbootfs} 1>&2
! echo 1>&2
! 		zfsbootfs=`echo ${zfsbootfs} | awk {'print $1'}`
! 		echo "Using the first bootfs listed: ${zfsbootfs}" 1>&2
! 		echo "Final LINUX_ROOT_DEVICE=ZFS=${zfsbootfs}" 1>&2
! 	fi
! 	LINUX_ROOT_DEVICE="ZFS=${zfsbootfs}"
  	;;
  esac
  

Bug#854007: libc6: crash during thread exit when using thread local storage

[Mike Gulick]

Package: libc6
Version: 2.19-18+deb8u7
Severity: normal
Tags: upstream patch

Dear Maintainer,

An application we develop crashes on exit with:
*** Error in `foo': free(): invalid pointer: 0x09309bc0 ***

This issue occurs when there are a large number of threads running which use
thread local storage.  We have identified the issue as an existing upstream
glibc bug, #13862.  This bug was fixed in glibc-2.21.  See
https://sourceware.org/bugzilla/show_bug.cgi?id=13862.  The upstream bug report
has a reproducer which reliably reproduces the problem.

I have backported the upstream patch to glibc 2.19, based on the patch made by
Red Hat and CentOS for their bug
https://bugzilla.redhat.com/show_bug.cgi?id=1238778.  I additionally applied the
patch for upstream TLS-related glibc bugs 17090, 17620, 17621, and 17628, which
is the same set of patches Red Hat backported for their fix to glibc-2.17.

After rebuilding glibc-2.19-18+deb8u7 with the attached patches, the issue no
longer occurs.  Given that Debian 8 still has several years of support left, can
these patches be added to Debian's build?

Thanks,
Mike

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

Kernel: Linux 4.4.0-0.bpo.tmw1-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 439e927dd88e2cd0d2b4b956d5db4f4a13b9f8d7 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Fri, 28 Nov 2014 07:54:07 -0800
Subject: [PATCH] Resize DTV if the current DTV isn't big enough

This patch changes _dl_allocate_tls_init to resize DTV if the current DTV
isn't big enough.  Tested on X86-64, x32 and ia32.

	[BZ #13862]
	* elf/dl-tls.c: Include .
	(oom): Remove #ifdef SHARED/#endif.
	(_dl_static_dtv, _dl_initial_dtv): Moved before ...
	(_dl_resize_dtv): This.  Extracted from _dl_update_slotinfo.
	(_dl_allocate_tls_init): Resize DTV if the current DTV isn't
	big enough.
	(_dl_update_slotinfo): Call _dl_resize_dtv to resize DTV.
	* nptl/Makefile (tests): Add tst-stack4.
	(modules-names): Add tst-stack4mod.
	($(objpfx)tst-stack4): New.
	(tst-stack4mod.sos): Likewise.
	($(objpfx)tst-stack4.out): Likewise.
	($(tst-stack4mod.sos)): Likewise.
	(clean): Likewise.
	* nptl/tst-stack4.c: New file.
	* nptl/tst-stack4mod.c: Likewise.

(cherry picked from commit d8dd00805b8f3a011735d7a407097fb1c408d867)
* Modified to avoid use of atomic_load_acquire, based on RH glibc
  patch glibc-rh1189278.patch.
---
 ChangeLog|  20 +++
 elf/dl-tls.c | 105 +-
 nptl/Makefile|  17 +-
 nptl/tst-stack4.c| 159 +++
 nptl/tst-stack4mod.c |  28 +
 5 files changed, 286 insertions(+), 43 deletions(-)
 create mode 100644 nptl/tst-stack4.c
 create mode 100644 nptl/tst-stack4mod.c

diff --git a/ChangeLog b/ChangeLog
index 92b8a2e..a1861d1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,23 @@
+2014-11-28  H.J. Lu  
+
+	[BZ #13862]
+	* elf/dl-tls.c: Include .
+	(oom): Remove #ifdef SHARED/#endif.
+	(_dl_static_dtv, _dl_initial_dtv): Moved before ...
+	(_dl_resize_dtv): This.  Extracted from _dl_update_slotinfo.
+	(_dl_allocate_tls_init): Resize DTV if the current DTV isn't
+	big enough.
+	(_dl_update_slotinfo): Call _dl_resize_dtv to resize DTV.
+	* nptl/Makefile (tests): Add tst-stack4.
+	(modules-names): Add tst-stack4mod.
+	($(objpfx)tst-stack4): New.
+	(tst-stack4mod.sos): Likewise.
+	($(objpfx)tst-stack4.out): Likewise.
+	($(tst-stack4mod.sos)): Likewise.
+	(clean): Likewise.
+	* nptl/tst-stack4.c: New file.
+	* nptl/tst-stack4mod.c: Likewise.
+
 2015-01-28  Adhemerval Zanellla  
 
 	[BZ #16576]
diff --git a/elf/dl-tls.c b/elf/dl-tls.c
index dbaea0a..c148c54 100644
--- a/elf/dl-tls.c
+++ b/elf/dl-tls.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -34,14 +35,12 @@
 
 
 /* Out-of-memory handler.  */
-#ifdef SHARED
 static void
 __attribute__ ((__noreturn__))
 oom (void)
 {
   _dl_fatal_printf ("cannot allocate memory for thread-local data: ABORT\n");
 }
-#endif
 
 
 size_t
@@ -370,6 +369,56 @@ _dl_allocate_tls_storage (void)
 }
 
 
+#ifndef SHARED
+extern dtv_t _dl_static_dtv[];
+# define _dl_initial_dtv (&_dl_static_dtv[1])
+#endif
+
+static dtv_t *
+_dl_resize_dtv (dtv_t *dtv)
+{
+  /* Resize the dtv.  */
+  dtv_t *newp;
+  /* Load GL(dl_tls_max_dtv_idx) atomically since it may be written to by
+ other threads concurrently.  -- We don't have the required atomic
+ infrastructure to load dl_tls_max_dtv_idx atomically, but on all the
+ architectures we care about it should load atomically. If this had
+ an atomic_load_acquire we would still be missing the releases for
+ the writes.  */
+  size_t newsize = 

Bug#849932: libindicate: FTBFS (Fields cannot have void type)

[Gilles Filippini]

Control: reassign -1 gtk-sharp2-gapi
Control: affects -1 src:libindicate
Control: retitle -1 gtk-sharp2-gapi: gapi2-codegen generates fields with void 
type

Gilles Filippini a écrit le 01/02/2017 à 00:05 :
> On Mon, 02 Jan 2017 12:01:41 + Santiago Vila  wrote:
>> I tried to build this package in stretch with "dpkg-buildpackage -A"
>> (which is what the "Arch: all" autobuilder would do to build it)
>> but it failed:
[snip]
>> /usr/bin/mono-csc  
>> -keyfile:/<>/./bindings/mono/indicate/indicate.snk 
>> -nowarn:0169,0612,0618 -unsafe -out:indicate-sharp.dll -target:library 
>> -r:/usr/lib/pkgconfig/../../lib/cli/pango-sharp-2.0/pango-sharp.dll 
>> -r:/usr/lib/pkgconfig/../../lib/cli/atk-sharp-2.0/atk-sharp.dll 
>> -r:/usr/lib/pkgconfig/../../lib/cli/gdk-sharp-2.0/gdk-sharp.dll 
>> -r:/usr/lib/pkgconfig/../../lib/cli/gtk-sharp-2.0/gtk-sharp.dll 
>> -r:/usr/lib/pkgconfig/../../lib/cli/glib-sharp-2.0/glib-sharp.dll 
>> ./generated/*.cs AssemblyInfo.cs
>> ./generated/ListenerServer.cs(62,10): error CS0670: Fields cannot have void 
>> type
>> ./generated/ListenerServer.cs(62,28): error CS1547: Keyword `void' cannot be 
>> used in this context
[snip]
> 
> This is caused by gtk-sharp2 2.12.40 generating this line in file 
> ListenerServer.cs:
> static void _gtype = new void 
> (indicate_listener_server_get_type(listener == null ? IntPtr.Zero : 
> listener.Handle, server == null ? IntPtr.Zero : server.Handle, 
> cb_wrapper.NativeDelegate, IntPtr.Zero));
> 
> This line doesn't appear when building against the previous gtk-sharp2 
> release from snapshot.d.o (2.12.10). According to [1] it works with 
> gtk-sharp2 2.12.29 as well. A bisect between releases 2.12.29 and 2.12.40 of 
> gtk-sharp2 might give something.
> 
> [1] https://github.com/chenxiaolong/Unity-for-Arch/issues/243

I've setup a simple testcase (xml file attached) to run with:
$ gapi2-codegen --generate indicate-api.xml --outdir=.

I've used it to bisect gtk-sharp2 releases, and I've found out that the error 
is introduced by gtk-sharp2 upstream commit dd4c742 [1].

[1] 
https://github.com/mono/gtk-sharp/commit/dd4c74292e9a91461a778f1759b64facf7cf68ac

Then reassigning this bug to gtk-sharp2-gapi.

Thanks,

_g.


  

  

  


  

  



signature.asc
Description: OpenPGP digital signature

Bug#848944: Issues with /dev/disk/by-id as well

[Chris Dos]

This problem also exists for grub on Jessie (2.02~beta2-22+deb8) and sid 
(2.02~beta3-3).

I've ended up having to put a line in rc.local to make symlinks for the devices 
in /dev:
for I in /dev/disk/by-id/wwn-*;do ln -s $I /dev/;done

Bug#854006: gcp: doesn't work at all

[Sandro Pratesi]

Package: gcp
Version: 0.1.3-2
Severity: normal

Dear Maintainer,

gcp fails with this error:

Traceback (most recent call last):
  File "/usr/bin/gcp", line 678, in 
gcp = GCP()
  File "/usr/bin/gcp", line 190, in __init__
sessions_bus = dbus.SessionBus()
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__
mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoServer: Failed to 
connect to socket /tmp/dbus-Hgk6lD7Ddd: Connection refused



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

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

Versions of packages gcp depends on:
ii  python  2.7.13-1
ii  python-dbus 1.2.4-1
ii  python-gobject  3.22.0-2

Versions of packages gcp recommends:
ii  python-progressbar  2.3-4

gcp suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#751339: RFP: ath9k-htc-firmware -- free firmware for Atheros AR7010/AR9271 wireless adapters

[Francesco Poli]

On Thu, 2 Feb 2017 06:35:00 +0300 Paul Fertser wrote:

> Hello,
> 
> On Wed, Feb 01, 2017 at 10:29:11PM +0100, Francesco Poli wrote:
> > Is there any progress in properly packaging these two DFSG-free
> > firmware files for inclusion in Debian main?
> 
> It's sitting in the NEW queue for 2 months already.
> 
> https://ftp-master.debian.org/new/open-ath9k-htc-firmware_1.4.0-81-gf206e56+dfsg-1.html

Excellent!  :-)
Does this mean that bugs #751339 and #711470 should be tagged as "pending"?

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpoci4EBEdc3.pgp
Description: PGP signature

Bug#854005: ssh-agent no longer works

[Wouter Verhelst]

Package: gnupg-agent
Version: 2.1.18-3
Severity: normal

Hi,

Since a recent upgrade, gnupg-agent no longer finds the authentication
(SSH) key on my OpenPGP smartcard:

wouter@gangtai:~$ gpg --card-status

Reader ...: ACS ACR38U 00 00
Application ID ...: D27600012401020100054736
Version ..: 2.1
Manufacturer .: ZeitControl
Serial number : 4736
Name of cardholder: Wouter Verhelst
Language prefs ...: nl
Sex ..: male
URL of public key :
http://pgp.surfnet.nl:11371/pks/lookup?op=get=0x9B69FDF3F0DA0948066129F72DFC519954181296
Login data ...: [not set]
Signature PIN : forced
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 116
Signature key : 9B69 FDF3 F0DA 0948 0661  29F7 2DFC 5199 5418 1296
  created : 2016-04-11 11:46:27
Encryption key: B057 2256 DD3D 8275 A1F2  3015 EBC4 535B 0557 DB14
  created : 2016-04-11 11:46:27
Authentication key: B7D1 52E7 6233 6135 DBEF  6435 965E 159D 1F28 844B
  created : 2016-04-11 11:46:27
General key info..: pub  rsa4096/2DFC519954181296 2016-04-11 Wouter
Verhelst 
sec>  rsa4096/2DFC519954181296  created: 2016-04-11  expires: never 
card-no: 0005 4736
ssb>  rsa4096/965E159D1F28844B  created: 2016-04-11  expires: never 
card-no: 0005 4736
ssb>  rsa4096/EBC4535B0557DB14  created: 2016-04-11  expires: never 
card-no: 0005 4736
wouter@gangtai:~$ echo "foo bar" | gpg -r 54181296 -e | gpg
gpg: please do a --check-trustdb
gpg: 54181296: skipped: public key already present
gpg: encrypted with 4096-bit RSA key, ID EBC4535B0557DB14, created
2016-04-11
  "Wouter Verhelst "
foo bar
wouter@gangtai:~$ echo $SSH_AUTH_SOCK 
/run/user/1000/gnupg/S.gpg-agent.ssh
wouter@gangtai:~$ ssh-add -l
The agent has no identities.

The interesting part of the above is that the last command (the "ssh-add
-l" bit) actually reads from the card (I can see the cardreader LED
flash).  It just doesn't find anything.

Note: I removed the "90gpg-agent" file from Xsession.d, since it messes
up some other SSH key setup that I have, very much in the same way that
gnome-keyring messes up gpg-agent. With the previous version of
gpg-agent, it was enough to just run "gpg --card-status" to start the
agent and make the ssh key stuff work.

Having to fight with all of that is pretty ironic, given that ssh-agent
actually supports external modules through PKCS#11. Ah well.

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

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

Versions of packages gnupg-agent depends on:
ii  libassuan0  2.4.3-2
ii  libc6   2.24-9
ii  libgcrypt20 1.7.6-1
ii  libgpg-error0   1.26-2
ii  libnpth01.3-1
ii  libreadline77.0-2
ii  pinentry-curses [pinentry]  1.0.0-1
ii  pinentry-gnome3 [pinentry]  1.0.0-1

Versions of packages gnupg-agent recommends:
ii  gnupg  2.1.18-3

Versions of packages gnupg-agent suggests:
ii  dbus-user-session  1.10.14-1
ii  libpam-systemd 232-15
ii  pinentry-gnome31.0.0-1
ii  scdaemon   2.1.18-3

-- Configuration Files:
/etc/X11/Xsession.d/90gpg-agent changed:


-- no debconf information

Bug#854004: live-config: keyboard configuration in live-build image now working

[Dieter Scholz]

Package: live-config
Version: 5.20170112
Severity: normal
Tags: l10n

Hello,

I tried to build a customized live image with live-build. To
configure my keyboard I'm using the following boot append options:

locales=de_DE.UTF-8 timezone=Europe/Berlin keyboard-model=pc105 
keyboard-layouts=de

I found these options in the man page.

They have no effect when I boot my CD. If I execute

dpkg-reconfigure -f noninteractive console-tools

my keyboard is working. I additionally booted a stock live CDs using the above 
params -
without success either. So I think it's a bug.

Kind regards

Dieter

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

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

Versions of packages live-config depends on:
ii  live-config-systemd [live-config-backend]  5.20170112

Versions of packages live-config recommends:
ii  iproute24.9.0-1
ii  keyboard-configuration  1.158
ii  live-config-doc 5.20170112
ii  live-tools  1:20151214+nmu1
ii  locales 2.24-8
ii  sudo1.8.19p1-1
ii  user-setup  1.67

Versions of packages live-config suggests:
ii  pciutils  1:3.5.2-1
ii  wget  1.18-4

-- no debconf information

Bug#843474: ruby-ethon: FTBFS: [BUG] Segmentation fault at 0x007f2767e0d800

[Chris Lamb]

Christian Hofstaedtler wrote:

> Control: severity -1 normal
> Control: tags -1 + unreproducible moreinfo
> 
> > ruby-ethon fails to build from source in unstable/amd64:
> 
> Builds for me just fine in sbuild (multiple builds). More info needed.

Same here; closing in BCC.


Regards,

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

Bug#854003: bedops: please avoid underlinking when linking with --as-needed

[Graham Inggs]

Source: bedops
Version: 2.4.20+dfsg-1
Severity: wishlist

Hi maintainer

Please consider applying the attached diff against
debian/patches/use_debian_libs.
It adds -ljansson -lz -lbz2 to LIBRARIES instead of SFLAGS to avoid
underlinking when bedops is linked with --as-needed, as is the default
in Ubuntu.

Regards
Graham
--- a/debian/patches/use_debian_libs
+++ b/debian/patches/use_debian_libs
@@ -14,10 +14,10 @@
 -LIBRARIES   = ${LOCALJANSSONLIB} ${LOCALBZIP2LIB} ${LOCALZLIBLIB}
 +INCLUDES= -iquote$(HEAD)
 +LIBLOCATION =
-+LIBRARIES   =
++LIBRARIES   = -ljansson -lz -lbz2
  BLDFLAGS= -Wall -pedantic -O3 -std=c++11
 -SFLAGS  = -static
-+SFLAGS  = -ljansson -lz -lbz2
++SFLAGS  =
  
  dependency_names= NaN starchConstants starchFileHelpers starchHelpers 
starchMetadataHelpers unstarchHelpers starchSha1Digest starchBase64Coding
  dependencies= $(addprefix $(OBJDIR)/, $(addsuffix .o, 
$(dependency_names)))
@@ -43,10 +43,10 @@
 -LIBRARIES   = ${LOCALJANSSONLIB} ${LOCALBZIP2LIB} ${LOCALZLIBLIB}
 +INCLUDES= -iquote$(HEAD)
 +LIBLOCATION =
-+LIBRARIES   =
++LIBRARIES   = -ljansson -lz -lbz2
  BLDFLAGS= -Wall -pedantic -O3 -std=c++11
 -SFLAGS  = -static
-+SFLAGS  = -ljansson -lz -lbz2
++SFLAGS  =
  
  dependency_names= NaN starchConstants starchFileHelpers starchHelpers 
starchMetadataHelpers unstarchHelpers starchSha1Digest starchBase64Coding
  dependencies= $(addprefix $(OBJDIR)/, $(addsuffix .o, 
$(dependency_names)))
@@ -68,10 +68,10 @@
 -LIBRARIES   = ${LOCALJANSSONLIB} ${LOCALBZIP2LIB} ${LOCALZLIBLIB}
 +INCLUDES= -iquote${HEAD}
 +LIBLOCATION =
-+LIBRARIES   =
++LIBRARIES   = -ljansson -lz -lbz2
  BLDFLAGS= -Wall -pedantic -O3 -std=c++11 
 -SFLAGS  = -static
-+SFLAGS  = -ljansson -lz -lbz2
++SFLAGS  =
  
  dependency_names= NaN starchConstants starchFileHelpers starchHelpers 
starchMetadataHelpers unstarchHelpers starchSha1Digest starchBase64Coding
  dependencies= $(addprefix $(OBJDIR)/, $(addsuffix .o, 
$(dependency_names)))
@@ -112,10 +112,10 @@
 -LIBRARIES   = ${LOCALJANSSONLIB} ${LOCALBZIP2LIB} ${LOCALZLIBLIB}
 +INCLUDES= -iquote$(HEAD)
 +LIBLOCATION =
-+LIBRARIES   =
++LIBRARIES   = -ljansson -lz -lbz2
  BLDFLAGS= -Wall -pedantic -O3 -std=c++11
 -SFLAGS  = -static
-+SFLAGS  = -ljansson -lz -lbz2
++SFLAGS  =
  
  dependency_names= NaN starchConstants starchFileHelpers starchHelpers 
starchMetadataHelpers unstarchHelpers starchSha1Digest starchBase64Coding
  dependencies= $(addprefix $(OBJDIR)/, $(addsuffix .o, 
$(dependency_names)))
@@ -148,7 +148,7 @@
 -LIBLOCATION = -L${LOCALJANSSONLIBDIR} -L${LOCALBZIP2LIBDIR} 
-L${LOCALZLIBDIR}
 -LIBRARIES   = ${LOCALJANSSONLIB} ${LOCALBZIP2LIB} ${LOCALZLIBLIB}
 +LIBLOCATION =
-+LIBRARIES   =
++LIBRARIES   = -ljansson -lz -lbz2
  
  PROG= sort-bed
  BINDIR  = ../bin
@@ -156,7 +156,7 @@
  WARNINGS= -Wall -Wextra -pedantic
  BLDFLAGS= ${WARNINGS} -O3 -std=c++11
 -SFLAGS  = -static
-+SFLAGS  = -ljansson -lz -lbz2
++SFLAGS  =
  
  dependency_names= starchConstants starchFileHelpers starchHelpers 
starchMetadataHelpers unstarchHelpers starchSha1Digest starchBase64Coding 
SortDetails Sort CheckSort
  dependencies= $(addprefix $(OBJDIR)/, $(addsuffix .o, 
$(dependency_names)))
@@ -169,7 +169,7 @@
 -INCLUDES  = -iquote${MAIN} -iquote${HEAD} -iquote${PARTY3} 
-I${LOCALJANSSONINCDIR} -I${LOCALBZIP2INCDIR} -I${LOCALZLIBINCDIR}
 -LIBRARIES = ${LOCALJANSSONLIB} ${LOCALBZIP2LIB} 
${LOCALZLIBLIB}
 +INCLUDES  = -iquote${MAIN} -iquote${HEAD}
-+LIBRARIES =
++LIBRARIES = -ljansson -lz -lbz2
  ARCH_VERSION  = v2.1
  BIN_VERSION   = v2.4.16
  TEST  = ../test
@@ -177,10 +177,28 @@
  TEST_OSX_BINDIR   = ${TEST}/binaries/osx/${ARCH_VERSION}/bin
  AR= ar
 -SFLAGS= -static
-+SFLAGS= -ljansson -lz -lbz2
++SFLAGS=
  CXXFLAGS  = -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE64_SOURCE=1 -DUSE_ZLIB -DUSE_BZLIB -O2 -Wformat -Wall -Wextra 
-Wswitch-enum -std=c++11 ${SFLAGS} -s
  CXXDFLAGS = -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE64_SOURCE=1 -DUSE_ZLIB -DUSE_BZLIB -O0 -g -Wformat -Wall -Wextra 
-Wswitch-enum -std=c++11 -DDEBUG_VERBOSE=1 ${SFLAGS}
  CXXGFLAGS = -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 

Bug#853999: RFS: psensor/1.1.5-2

[Adam Borowski]

Control: tags -1 +moreinfo

On Thu, Feb 02, 2017 at 11:10:33PM +0100, jea...@gmail.com wrote:
>   I am looking for a sponsor for my package "psensor"
> 
>  * Package name: psensor
>Version : 1.1.5-2

>   Changes since the last upload:
> 
>   * debian/control
>   + build dependency to asciidoctor-base. (Closes: #850369)
>   + use the secure URLs for the GIT repositories.
>   * debian/watch
>   + use the secure URL.

The bug you're attempting to fix is not RC -- it's not even open anymore, as
it was fixed elsewhere already.  Thus, are you sure you want an upload to
unstable while we're frozen?  For non-NEW packages this disturbs the release
team's work, and thus is strongly unrecommended.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#853940: systemd: RestrictAddressFamilies causes services to fail to start on powerpc

[Phil Armstrong]

On 02/02/17 21:50, Michael Biebl wrote:

Am 02.02.2017 um 20:58 schrieb Phil Armstrong:

On 02/02/17 16:04, Phil Armstrong wrote:


On Feb 2 2017, Michael Biebl wrote:


I guess it would be worthwile testing 232-1 from snapshot.d.o [1]


Downgrading systemd, udev, libudev1 & libsystemd0 to 232-1 doesn't help:

 [190930.425521] systemd[2789]: systemd-udevd.service: Failed at step
ADDRESS_FAMILIES spawning /lib/systemd/systemd-udevd: File exists



Are you absolutely sure? We had another bug report who said that
downgrading systemd+udev to 232-1 did fix the problem on ppc(64).


This is a ppc32 system, so maybe that makes the difference? I’ll test it 
again over the weekend.


Phil

Bug#854002: auto-complete-el: ac-dictionary-directories set to debian location

[Kevin Ryde]

Package: auto-complete-el
Version: 1.3.1-2
Severity: wishlist
File: /etc/emacs/site-start.d/50auto-complete-el.el

50auto-complete-el.el could helpfully set `ac-dictionary-directories' to
/usr/share/auto-complete/dict which is the packaged dict directory.

(setq ac-dictionary-directories '("/usr/share/auto-complete/dict/"))

This would be per the "Installation" instructions in the auto-complete
manual, but here a setq since before auto-complete.el loads.


Incidentally, in 50auto-complete-el.el the (symbol-name flavor) might
better be (symbol-name debian-emacs-flavor) since the latter is the
documented flavour variable and the former I think only a dynamic
binding out of the startup code.



-- System Information:
Debian Release: 9.0
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages auto-complete-el depends on:
ii  emacs46.1
ii  emacs23-lucid [emacs23]  23.4+1-4.1+b1

Bug#852250: [lua-socket] luasocket was not compiled with UNIX sockets support

[Mathieu Parent]

2017-02-02 21:36 GMT+01:00 Mathieu Parent :
> 2017-02-02 20:36 GMT+01:00 Michael Meskes :
>>> Sorry, my patch was wrong
>>>
>>> local _, unix = pcall(require, "socket.unix");
>>> if unix then
>>>socket.unix = unix.stream or unix.tcp;
>>> end
>>>
>>
>> This one seems to work. Great, thank you so much.
>>
>>> Unfortunately I can't really test the patches I propose, so I beg
>>> your
>>> pardon if they are wrong.
>>
>> No worries, I'm more than willing to test. Not speaking lua myself I
>> cannot create a patch. All the more reason to be thankful for your
>> work.
>>
>>> And the patches are really for the upstream of prosody-modules, not
>>> for
>>> Debian.
>>
>> Sure, I'll forward.
>
> Thanks Enrico. I've done a similar patch (attached). Note that with
> your patch unix will always be not nil: if there is an error "_" will
> be false, and unix will be the error string.
>
> Michael, can you test my patch?

Here is an updated version of the patch, targeting upstream.

Can you try the attached patch with both lua-socket versions?
- 3.0~rc1+git+321c0c9-2
- 3.0~rc1+git+ac3201d-3

Regards
-- 
Mathieu
From 2fc74451bb344ea6dec8cbd0126b7dfc315b91a0 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Wed, 25 Jan 2017 20:42:56 +0100
Subject: [PATCH] Fix compatibility problems with Unix domain sockets in newer
 versions of luasocket

---
 mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua b/mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua
index a6f1958..5747b8e 100644
--- a/mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua
+++ b/mod_auth_dovecot/auth_dovecot/sasl_dovecot.lib.lua
@@ -26,7 +26,14 @@ local m_random = math.random;
 local tostring, tonumber = tostring, tonumber;
 
 local socket = require "socket"
-pcall(require, "socket.unix");
+local ok, unix = pcall(require, "socket.unix")
+if ok then
+if type(unix) == "function" then
+   socket.unix = unix
+else
+   socket.unix = unix.stream or unix.tcp
+end
+end
 local base64 = require "util.encodings".base64;
 local b64, unb64 = base64.encode, base64.decode;
 local jid_escape = require "util.jid".escape;
-- 
2.11.0

Bug#852380: Proposed ekeyd fix

[Mathieu Parent]

Hi,

Can you try the attached patch with both lua-socket versions?
- 3.0~rc1+git+321c0c9-2
- 3.0~rc1+git+ac3201d-3

Thanks

-- 
Mathieu Parent
From 7ae3639338b643a42e3a7dd9672ab00f514debc0 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Thu, 2 Feb 2017 23:26:03 +0100
Subject: [PATCH] Fix compatibility with changed UNIX socket API

---
 host/control.lua | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/host/control.lua b/host/control.lua
index 7b9b1b8..feeae60 100644
--- a/host/control.lua
+++ b/host/control.lua
@@ -41,13 +41,16 @@ local dos_callcount = 0
 require "socket"
 
 local have_unix_domain_sockets = false
-function tryload_unix()
-   require "socket.unix"
-   have_unix_domain_sockets = true
+local ok, unix = pcall(require, "socket.unix")
+if ok then
+   if type(unix) == "function" then
+  socket.unix = unix
+   else
+  socket.unix = unix.stream or unix.tcp
+   end
+   have_unix_domain_sockets = socket.unix ~= nil
 end
 
-pcall(tryload_unix)
-
 local protectedenv = {}
 
 -- Control socket interface
-- 
2.11.0

Bug#854001: python2.7: python mail creashes with oversized header input

[=]

Package: python2.7
Version: 2.7.9-2+deb8u1
Severity: normal

Dear Maintainer,

steps to reproduce:

#!/usr/bin/env python
import sys
import email

mail = email.message_from_string(
"""From: 
To: 
Subject: demo
X-Overlong-Header-Name-causes-python-mail-to-crash-in-re-serialization-example:

Hello
""")
message = mail.as_string()
sys.stdout.write(message)




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

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

Versions of packages python2.7 depends on:
ii  libpython2.7-stdlib  2.7.9-2+deb8u1
ii  mime-support 3.58
ii  python2.7-minimal2.7.9-2+deb8u1

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.25-5
pn  python2.7-doc  

-- no debconf information

Bug#854000: CVE-2017-5834 CVE-2017-5835 CVE-2017-5836

[Moritz Muehlenhoff]

Source: libplist
Severity: grave
Tags: security

CVE-2017-5834: heap-buffer-overflow in parse_dict_node
https://github.com/libimobiledevice/libplist/issues/89

CVE-2017-5835: memory allocation error
https://github.com/libimobiledevice/libplist/issues/88

CVE-2017-5836 issue in plist_free_data plist.c:185
https://github.com/libimobiledevice/libplist/issues/86

Bug#853999: RFS: psensor/1.1.5-2

[jea...@gmail.com]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: psensor
   Version : 1.1.5-2
   Upstream Author : Jean-Philippe Orsini 
 * URL : https://wpitchoune.net/psensor
 * License : GPLv2
   Section : utils

  It builds those binary packages:

 psensor- display graphs for monitoring hardware temperature
 psensor-common - common files for Psensor and Psensor server
 psensor-server - Psensor server for monitoring hardware sensors remotely

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/psensor/psensor_1.1.5-2.dsc

  More information about psensor can be obtained from
https://wpitchoune.net/psensor.

  Changes since the last upload:

  * debian/control
  + build dependency to asciidoctor-base. (Closes: #850369)
  + use the secure URLs for the GIT repositories.
  * debian/watch
  + use the secure URL.



  Regards,
  JeanFI.

Bug#794466: VIrtualBox future in Debian

[Moritz Muehlenhoff]

On Mon, Jan 30, 2017 at 02:36:11PM +, Gianfranco Costamagna wrote:
> fully agree, but I'm not in the position to revert this change
> >Why can't the Security Team treat VirtualBox like how it's been
> >treating WebKit1? Still have it in the archives but with a prominent
> >notice that Debian does not provide security updates.

The usual expectation is that everything in Debian is covered by
reasonable security support. We need to make some exceptions for
technical reasons (as like in webkit, where it's simply not
feasible to backport). Security support for vbox would be feasible,
but fails entirely due to Oracle's policy. If up for them to fix
that.

Cheers,
Moritz

Bug#853990: Add prompt for iSCSI initiator name in installer

[Geert Stappers]

Control: tags -1 patch

On Thu, Feb 02, 2017 at 04:22:22PM -0500, Kevin Otte wrote:
> 
> I have included a patch based on Ubuntu's modifications to the package
> that appears to achieve this.
> 

tagged

Bug#846002: Congratulation:Benjamin_Eligibility for Fresh Start Tax Program F3pe198.9.78.72.9.148.37221.123.0.5F3pe

[Asusena Hernandez]

On Jan 17, 2017 12:40 PM, "Bjørn Mork"  wrote:

> dfhg
>
> Benjamin_Qualify_for_Tax_Debt_ Relief?
>
> Check_Your_Eligibility
>
>
>
>
> 
> 
> 
> asdf
> asdf
> asdf
>
>

Bug#852532: Acknowledgement (olvwm: source code not 64-bit clean, SIGSEGV everywhere)

[Benjamin Moody]

Unless there is an automated way to identify all the cases of
integer/pointer confusion, I don't expect there'll ever be a way to
make libxview work on LP64 systems.  I am less familiar with
olwm/olvwm, but this report is not encouraging.

It seems to me that the most sensible thing to do would be to drop the
amd64 and other LP64 architectures; for folks who are using olwm/olvwm
on amd64, I would recommend installing the i386 version instead (or
x32, when that becomes possible.)

Benjamin

Bug#853998: CVE-2017-3250 / CVE-2017-3249 / CVE-2017-3247 / CVE-2016-5528 / CVE-2016-5519

[Moritz Muehlenhoff]

Source: glassfish
Severity: grave
Tags: security

So Oracle has these lovely, unspecified vulnerabilities reported against 
Glassfish,
but it's my understanding that the Debian package only provides a minor subset
what usually constitutes Java, so could you have a look, which of 

http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html

might possibly affect the Debian package?

Cheers,
Moritz

Bug#853997: CVE-2017-5849

[Moritz Muehlenhoff]

Source: netpbm-free
Severity: grave
Tags: security

Please see http://www.openwall.com/lists/oss-security/2017/02/02/2

Cheers,
Moritz

Bug#853996: CVE-2017-5667 / CVE-2017-5856 / CVE-2017-5857

[Moritz Muehlenhoff]

Source: qemu
Severity: important
Tags: security

CVE-2017-5667:
https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg06191.html
https://bugzilla.redhat.com/show_bug.cgi?id=1417559
http://www.openwall.com/lists/oss-security/2017/01/30/2

CVE-2017-5856:
http://www.openwall.com/lists/oss-security/2017/02/01/19
http://git.qemu.org/?p=qemu.git;a=commit;h=765a707000e838c30b18d712fe6cb3dd8e0435f3
https://bugzilla.redhat.com/show_bug.cgi?id=1418342

CVE-2017-5857:
https://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg04615.html
https://bugzilla.redhat.com/show_bug.cgi?id=1418382
http://www.openwall.com/lists/oss-security/2017/02/01/21c

Cheers,
Moritz

 

Bug#853995: libopenscap8: missing dependency resulting in missing OVAL objects support

[Alan Guan]

Package: libopenscap8
Version: openscap/1.2.9-1
Severity: wishlist

Dear Maintainer,

The "libdbus-1-dev" package is missing from the "Build-Depends" in the
"debian/control" file, and as a result, the OVAL object support for
"systemdunitproperty" and "systemdunitdependency" is missing. About 10~15%
of the SCAP content based on CIS benchmark relies on these two OVAL objects
- they are important and should be supported. Simply adding the missing
dependency will enable these OVAL objects for OpenSCAP.

A patch related to this bug is available here:
https://launchpadlibrarian.net/304927569/openscap-1.2.8.patch

Thank you for your consideration!
Alan

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

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

Versions of packages libopenscap8 depends on:
ii  libapt-pkg5.0  1.2.18
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.23-0ubuntu5
ii  libcap21:2.24-12
ii  libcurl3   7.47.0-1ubuntu2.2
ii  libgcc11:6.0.1-0ubuntu1
ii  libgcrypt201.6.5-2ubuntu0.2
ii  libldap-2.4-2  2.4.42+dfsg-2ubuntu3.1
ii  libpcre3   2:8.38-3.1
ii  libselinux12.4-3build2
ii  libstdc++6 5.4.0-6ubuntu1~16.04.4
ii  libxml22.9.3+dfsg1-1ubuntu0.1
ii  libxslt1.1 1.1.28-2.1

libopenscap8 recommends no packages.

libopenscap8 suggests no packages.

-- no debconf information

Bug#782329:

[Dylan]

Hi Andreas,
Do you still have these issues with the last version of the package
(1:0.5.0-3) of openchrome in unstable (it should be migrate to Stretch
in few days)?

Best,
Dylan

Bug#853940: systemd: RestrictAddressFamilies causes services to fail to start on powerpc

[Michael Biebl]

Am 02.02.2017 um 20:58 schrieb Phil Armstrong:
> On 02/02/17 16:04, Phil Armstrong wrote:
> 
>> On Feb 2 2017, Michael Biebl wrote:
>>
>>> I guess it would be worthwile testing 232-1 from snapshot.d.o [1]
>>
>> Downgrading systemd, udev, libudev1 & libsystemd0 to 232-1 doesn't help:
>>
>>  [190930.425521] systemd[2789]: systemd-udevd.service: Failed at step
>> ADDRESS_FAMILIES spawning /lib/systemd/systemd-udevd: File exists
>>

Are you absolutely sure? We had another bug report who said that
downgrading systemd+udev to 232-1 did fix the problem on ppc(64).


-- 
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#843474: ruby-ethon: FTBFS: [BUG] Segmentation fault at 0x007f2767e0d800

[Christian Hofstaedtler]

Control: severity -1 normal
Control: tags -1 + unreproducible moreinfo

> ruby-ethon fails to build from source in unstable/amd64:

Builds for me just fine in sbuild (multiple builds). More info needed.

Best,
-ch

Bug#853251: gitlab: git push fail - GitLab: API is not accessible

[Emmanuel Boudreault]

I can confirm that this bug affects our production servers as well.
Unfortunately the suggested temporary fix (commenting out) doesn't seem
to work. This might be because we are setting our DB to postgres in the
gitlab-debian.conf.


Regards,
Emmanuel

On Mon, 30 Jan 2017 12:50:21 -0700 "Justin F. Hallett"  wrote:
> Package: gitlab
> Version: 8.13.11+dfsg-1
> Severity: important
> 
> The issue is with 0300-git-2-11-support.patch and missing files in
the
> deb.
> 
> 1) 0300-git-2-11-support.patch only half implements things, it does
> create the proper files and adds parts of
> https://gitlab.com/gitlab-org/gitlab-ce/commit/f82d549d26af89cba5
e1a1c9b721c076f7a0
> but it's missing some important parts, mainly it's missing
> https://gitlab.com/gitlab-org/gitlab-ce/commit/1c994dbc05c14771447928
8126742f3fee158fd8#6e60f94696b534ed16ff1d4f8ca1a742242805bf_6_6
> where it's loads teh helper before using it.
> 
> 2) the patch creates lib/api/helpers/internal_helpers.rb but does not
> include it in the deb. So even if 1 is corrected it will fail to load
> the missing file.
> 
> As a temp fix you can just comment out "env:
> parse_allowed_environment_variables)" from lib/api/internal.rb and
> things work again, but the right fix would be to add the missing
lines
> to the patch and include the helper file in the deb.
> 
> Hope this helps others as it took me a bit to track it on my
production
> servers.
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-1-amd64 (SMP w/24 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 gitlab depends on:
> ii  adduser   3.115
> ii  apache2 [httpd]   2.4.25-2
> ii  asciidoctor   1.5.4-2
> ii  bc1.06.95-9+b2
> ii  bundler   1.13.6-2
> ii  debconf [debconf-2.0] 1.5.59
> ii  git   1:2.11.0-2
> ii  gitlab-shell  3.6.6-2
> ii  gitlab-workhorse  0.8.5+debian-3
> ii  init-system-helpers   1.47
> ii  libjs-chartjs 1.0.2-1
> ii  libjs-clipboard   1.4.2-1
> ii  libjs-fuzzaldrin-
plus 0.3.1+git.20161008.da2cb58+dfsg-4
> ii  libjs-graphael0.5+dfsg-1
> ii  libjs-jquery-cookie   11-3
> ii  libjs-jquery-history  11-3
> ii  libjs-jquery-nicescroll   3.6.6-1
> ii  lsb-base  9.20161125
> ii  nodejs4.7.2~dfsg-1
> ii  openssh-client1:7.4p1-5
> ii  postfix [mail-transport-agent]3.1.4-3
> ii  postgresql-client 9.6+178

Bug#853993: xorg: Thunderbird running over ssh X forwarding opens popup window on X host machine

[Rafael Diniz]

Package: xorg
Version: 1:7.7+18
Severity: normal

Dear Maintainer,

I always run thunderbird over ssh X forwarding in previous Debian version, like 
Jessie. It always
worked as expected: all popups, enigmail gpg passwd windows, and so on, always 
opened correctly in the
same computer I was using.

Now, I installed Debian Stretch, and the first day of use, when I logged via 
ssh to my private computer in the lab (X forwarding 
enabled), and opened thunderbird a very weird thing happened: when sending an 
email, enigmail pops up a window in order I can 
entry the passwd to unblock my private gpg key, but the window appeared in my 
private PC, in not in the PC I was using!


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
Integrated Graphics Controller [8086:0046] (rev 02)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 (2017-01-12)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 74027 Jan 21 22:41 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 76287 Jan 23 18:04 /var/log/Xorg.0.log
-rw-r--r-- 1 rafael2k rafael2k 28638 Feb  2 18:41 
/home/rafael2k/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/rafael2k/.local/share/xorg/Xorg.0.log):
-
[   190.353] (--) Log file renamed from 
"/home/rafael2k/.local/share/xorg/Xorg.pid-1539.log" to 
"/home/rafael2k/.local/share/xorg/Xorg.0.log"
[   190.353] 
X.Org X Server 1.19.0
Release Date: 2016-11-15
[   190.353] X Protocol Version 11, Revision 0
[   190.353] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[   190.353] Current Operating System: Linux darkboia 4.9.0-1-amd64 #1 SMP 
Debian 4.9.2-2 (2017-01-12) x86_64
[   190.353] Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-1-amd64 
root=/dev/mapper/vgroup-root_crypt ro
[   190.353] Build Date: 16 December 2016  07:30:27PM
[   190.353] xorg-server 2:1.19.0-3 (https://www.debian.org/support) 
[   190.353] Current version of pixman: 0.34.0
[   190.353]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   190.353] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   190.354] (==) Log file: "/home/rafael2k/.local/share/xorg/Xorg.0.log", 
Time: Thu Feb  2 17:00:29 2017
[   190.386] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   190.413] (==) No Layout section.  Using the first Screen section.
[   190.413] (==) No screen section available. Using defaults.
[   190.413] (**) |-->Screen "Default Screen Section" (0)
[   190.413] (**) |   |-->Monitor ""
[   190.416] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   190.416] (==) Automatically adding devices
[   190.416] (==) Automatically enabling devices
[   190.416] (==) Automatically adding GPU devices
[   190.416] (==) Max clients allowed: 256, resource mask: 0x1f
[   190.416] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   190.416]Entry deleted from font path.
[   190.416] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   190.416] (==) ModulePath set to "/usr/lib/xorg/modules"
[   190.416] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   190.416] (II) Loader magic: 0x55a23c188e00
[   190.416] (II) Module ABI versions:
[   190.416]X.Org ANSI C Emulation: 0.4
[   190.416]X.Org Video Driver: 23.0
[   190.416]X.Org XInput driver : 24.1
[   190.416]X.Org Server Extension : 10.0
[   190.418] (++) using VT number 2

[   190.421] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_32
[   190.422] (II) xfree86: Adding drm device (/dev/dri/card0)
[   190.426] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0
[   190.428] (--) PCI:*(0:0:2:0) 8086:0046:17aa:215a rev 2, Mem @ 
0xf200/4194304, 0xd000/268435456, I/O @ 0x1800/8, BIOS @ 
0x/131072
[   190.428] (II) LoadModule: "glx"
[   

Bug#853994: initramfs parameters invalid for IPv6 portal

[Kevin Otte]

Package: partman-iscsi

Version: 44

Tags: ipv6


In init.d/iscsi the portal address is collected thusly:
echo "$(cat "$connectiondev/persistent_address"):$(cat
"$connectiondev/persistent_port"),$(cat "/sys/$sessiondev/tpgt")"
>iscsi_portal

resulting in an iscsi_portal file looking like
2606:a000:a449:5900::4:3260,1

In finish.d/iscsi_settings, this string is then picked apart:
group="${portal##*,}"
portal="${portal%,*}"
ip="${portal%%:*}"
port="${portal#*:}"

These variables are then used to populate iscsi.initramfs, which ends up
looking like this:
ISCSI_TARGET_NAME="iqn.2016-11.net.nivex:storage.istest"
ISCSI_TARGET_IP="2606"
ISCSI_TARGET_PORT="a000:a449:5900::4:3260"
ISCSI_TARGET_GROUP="1"
ISCSI_USERNAME="istest"
ISCSI_PASSWORD="123456789012"

I think the easiest fix would be to switch the greed of the matching, as in:
ip="${portal%:*}"
port="${portal##*:}"
though I worry about naively splitting on colon when dealing with IPv6
addresses like this.

(This bug originally filed in Ubuntu
[https://bugs.launchpad.net/ubuntu/+source/partman-iscsi/+bug/1641656].)

--- iscsi_settings	2015-12-02 11:26:47.0 -0500
+++ iscsi_settings-fixed	2016-11-17 02:12:24.609586718 -0500
@@ -61,8 +61,8 @@
 if [ "$portal" ]; then
 	group="${portal##*,}"
 	portal="${portal%,*}"
-	ip="${portal%%:*}"
-	port="${portal#*:}"
+	ip="${portal%:*}"
+	port="${portal##*:}"
 	mkdir -p /target/etc/iscsi
 	get_default_interface
 	if [ -f "/sys/class/net/$default_interface/address" ]; then

Bug#853767: installation-guide_20161031_welcome: [INTL:nl] Dutch po file

[Cyril Brulebois]

Hi,

Holger Wansing  (2017-02-02):
> it's fine to see a d-i manual translation update for Dutch, after
> Dutch being orphaned for a long time.
> 
> I have activated the build for i386 in Dutch on
> http://d-i.alioth.debian.org/manual/. Might help for proofreading or
> such.
> 
> It would be great if you could work on the Dutch d-i manual further.
> (It's probably to late for Stretch, but maybe a target for Buster?)

I'm fine with receiving translation updates at this stage, especially if
possible side effects are virtually non-existent for a doc-only package
like the installation guide.


KiBi.


signature.asc
Description: Digital signature

Bug#853992: xul-ext-requestpolicy: update requestpolicy to 1.0 beta12.4 - compatibility with web extensions

[shirish शिरीष]

Package: xul-ext-requestpolicy
Version: 1.0.0~beta12.3+dfsg-1
Severity: normal

Dear Maintainer,
First of all thank you for taking care of xul-ext-requestpolicy for so
long. Was just browsing today and saw that 1.0beta12.4 was introduced
few months back. The only addition according to the changelog
https://github.com/RequestPolicyContinued/requestpolicy/blob/dev-1.0/ChangeLog.md

is being compatible with WebExtensions which Mozilla is going to come
up in the next few releases.

https://wiki.mozilla.org/WebExtensions

If possible, please update it so we are ready when the new Firefox arrives.

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

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

Versions of packages xul-ext-requestpolicy depends on:
ii  firefox   50.1.0-1
ii  firefox-esr   45.7.0esr-1
ii  iceweasel 45.7.0esr-1
ii  libjs-jquery  3.1.1-2

xul-ext-requestpolicy recommends no packages.

xul-ext-requestpolicy suggests no packages.

-- no debconf information


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

Bug#853991: bts: Patches for smtp+starttls:// & Net::SMTP::TLS

[Pali Rohár]

Package: devscripts

Hi! I'm sending two patches for bts to bugs as Mattia Rizzolo wanted. 
Originally I sent those patches to devscripts-devel mailing list.

-- 
Pali Rohár
pali.ro...@gmail.com
From 3178362c639d35c95682b822618d7d1361b9c8e1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pali=20Roh=C3=A1r?= 
Date: Wed, 7 Dec 2016 14:41:34 +0100
Subject: [PATCH] bts: Use scheme smtp+starttls:// to enfore STARTTLS
 encryption on smtp host

Net::SMTPS with doSSL => 'starttls' does not enforce STARTTLS. It enable it
only if supported by smtp server. Verification can be done by method call
supports('STARTTLS').
---
 scripts/bts.pl |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/scripts/bts.pl b/scripts/bts.pl
index 2a650d1..b0af235 100755
--- a/scripts/bts.pl
+++ b/scripts/bts.pl
@@ -2627,13 +2627,26 @@ sub send_mail {
 	} else {
 		die "$progname: Unable to establish SMTPS connection: $smtps_broken\n";
 	}
+	} elsif ($smtphost =~ m%^smtp\+starttls://(.*)$%) {
+	my ($host, $port) = split(/:/, $1);
+	$port ||= '587';
+
+	if (have_smtps) {
+		$smtp = Net::SMTPS->new($host, Port => $port,
+		Hello => $smtphelo, doSSL => 'starttls') # NOTE: doSSL => 'starttls' does not enforce TLS
+		or die "$progname: failed to open SMTP connection to $smtphost\n($@)\n";
+		$smtp->supports('STARTTLS') # verify that TLS is enabled
+		or die "$progname: failed to issue STARTTLS command to $smtphost: Server does not support it\n";
+	} else {
+		die "$progname: Unable to establish SMTPS connection: $smtps_broken\n";
+	}
 	} else {
 	my ($host, $port) = split(/:/, $smtphost);
 	$port ||= '25';
 
 	if (have_smtps) {
 		$smtp = Net::SMTPS->new($host, Port => $port,
-		Hello => $smtphelo, doSSL => 'starttls')
+		Hello => $smtphelo, doSSL => 'starttls') # NOTE: doSSL => 'starttls' does not enforce TLS
 		or die "$progname: failed to open SMTP connection to $smtphost\n($@)\n";
 	} else {
 		$smtp = Net::SMTP->new($host, Port => $port, Hello => $smtphelo)
-- 
1.7.9.5

From d8a7763b00c6a55334f75e14a86a9eb829823500 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pali=20Roh=C3=A1r?= 
Date: Wed, 7 Dec 2016 14:57:05 +0100
Subject: [PATCH] bts: Try to use Net::SMTP::TLS when Net::SMTPS is not
 available

Net::SMTPS is provided by libnet-smtps-perl package which is not available
on older systems. Also in some cases Net::SMTP::TLS can be already
installed but Net::SMTPS not.
---
 scripts/bts.pl |   57 ++--
 1 file changed, 47 insertions(+), 10 deletions(-)

diff --git a/scripts/bts.pl b/scripts/bts.pl
index b0af235..98d2224 100755
--- a/scripts/bts.pl
+++ b/scripts/bts.pl
@@ -75,6 +75,7 @@ my $it = undef;
 my $last_user = '';
 my $lwp_broken = undef;
 my $smtps_broken = undef;
+my $smtp_tls_broken = undef;
 my $authen_sasl_broken;
 my $ua;
 
@@ -115,6 +116,23 @@ sub have_smtps() {
 return $smtps_broken ? 0 : 1;
 }
 
+sub have_smtp_tls() {
+return ($smtp_tls_broken ? 0 : 1) if defined $smtp_tls_broken;
+eval {
+   require Net::SMTP::TLS;
+};
+
+if ($@) {
+   if ($@ =~ m%^Can\'t locate Net/SMTP/TLS%) {
+   $smtp_tls_broken="the libnet-smtp-tls-perl package is not installed";
+   } else {
+   $smtp_tls_broken="couldn't load Net::SMTP::TLS: $@";
+   }
+}
+else { $smtp_tls_broken=''; }
+return $smtp_tls_broken ? 0 : 1;
+}
+
 sub have_authen_sasl() {
 return ($authen_sasl_broken ? 0 : 1) if defined $authen_sasl_broken;
 eval {
@@ -2637,8 +2655,17 @@ sub send_mail {
 		or die "$progname: failed to open SMTP connection to $smtphost\n($@)\n";
 		$smtp->supports('STARTTLS') # verify that TLS is enabled
 		or die "$progname: failed to issue STARTTLS command to $smtphost: Server does not support it\n";
+	} elsif (have_smtp_tls) {
+		if ($smtpuser) {
+		$smtppass = getpass() if not $smtppass;
+		}
+		$smtp = Net::SMTP::TLS->new($host, Port => $port,
+		Hello => $smtphelo, User => $smtpuser, Password => $smtppass)
+		or die "$progname: failed to open SMTP connection to $smtphost\n($@)\n";
+		$smtpuser = undef;
+		$smtppass = undef;
 	} else {
-		die "$progname: Unable to establish SMTPS connection: $smtps_broken\n";
+		die "$progname: Unable to establish SMTPS connection: $smtps_broken $smtp_tls_broken\n";
 	}
 	} else {
 	my ($host, $port) = split(/:/, $smtphost);
@@ -2662,18 +2689,28 @@ sub send_mail {
 		die "$progname: failed to authenticate to $smtphost: $authen_sasl_broken\n";
 	}
 	}
-	$smtp->mail($fromaddress)
-	or die "$progname: failed to set SMTP from address $fromaddress\n($@)\n";
 	my @addresses = extract_addresses($to);
 	push @addresses, extract_addresses($cc);
-	foreach my $address (@addresses) {
-	$smtp->recipient($address)
-	or die "$progname: failed to set SMTP recipient $address\n($@)\n";
+	if ($smtp->isa('Net::SMTP::TLS')) {
+	

Bug#853753: gitlab-shell: fails after update - git auth ?

[TheSin]

I have the same issue

remote: GitLab: The project you were looking for could not be found.

using 

http://snapshot.debian.org/archive/debian/20161031T154133Z/pool/main/g/gitlab-shell/gitlab-shell_3.6.6-1_all.deb

Fixes the issue, but breaks apt

You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 gitlab : Depends: gitlab-shell (>= 3.6.6-2~) but 3.6.6-1 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).

It looks like the patch for git 2.11 breaks it for everything bellow 2.11?

Bug#853990: Add prompt for iSCSI initiator name in installer

[Kevin Otte]

Package: partman-iscsi
Version: 44

The installer should prompt for the desired iSCSI initiator name before
starting the initiator. Many iSCSI targets require the specification of
the IQN as part of their ACLs. It is useful for the administrator to be
able to set this.

I have included a patch based on Ubuntu's modifications to the package
that appears to achieve this.

--- iscsi-base.sh	2011-07-24 21:01:40.0 -0400
+++ /tmp/iscsi-base.sh	2017-02-02 16:17:27.583471157 -0500
@@ -1,5 +1,22 @@
 . /usr/share/debconf/confmodule
 
+iscsi_start () {
+	db_input critical partman-iscsi/initiatorname || true
+	db_go || true
+	db_get partman-iscsi/initiatorname
+	if [ -n "$RET" ]; then
+	echo "## DO NOT EDIT OR REMOVE THIS FILE!" > /etc/iscsi/initiatorname.iscsi
+	echo "## If you remove this file, the iSCSI daemon will not start." >> /etc/iscsi/initiatorname.iscsi
+	echo "## If you change the InitiatorName, existing access control lists" >> /etc/iscsi/initiatorname.iscsi
+	echo "## may reject this initiator.  The InitiatorName must be unique">> /etc/iscsi/initiatorname.iscsi
+	echo "## for each iSCSI initiator.  Do NOT duplicate iSCSI InitiatorNames." >> /etc/iscsi/initiatorname.iscsi
+	printf "InitiatorName=$RET\n"  >> /etc/iscsi/initiatorname.iscsi
+	chmod 600 /etc/iscsi/initiatorname.iscsi
+	fi
+
+	iscsi-start
+}
+
 iscsi_login () {
 	local portal discovery targets target
 	local state=0

Bug#851810: xcalib: "Error - unsupported ramp size 0" when trying to invert screen

[Rinat Ibragimov]

Hi.

I have a similar issue with xcalib. I use it to apply color profile,
but it fails with the same error message:

   Error - unsupported ramp size 0

It started just after X.org was updated to 1.19.0, and most probably
was caused by changes related to "modesetting" driver, since moving
back to "intel" makes xcalib work again. (I have Intel i7-3632QM (Ivy
Bridge) CPU with integrated GPU.)

Still doesn't work with X.org 1.19.1.


---
Rinat

Bug#853356: cppcheck: ftbfs with GCC-7

[Joachim Reichel]

tag 853356 + upstream pending patch
forwarded 853356 http://trac.cppcheck.net/ticket/7910#ticket
thanks

Bug#851909: Problems disappear after downgrade

[Roger Kalt]

Yes, I can confirm I was able to reproduce and it was the patch which was not
correctly backported for deb8u1.

Please test the UNRELEASED deb8u2 version available from here and give feedback:
https.//www.helferplan.ch/debian/

Kind regards
  Roger

On 02/02/2017 02:22 PM, Christopher Huhn wrote:
> OK, after downgrading to 2.9.2+2014.05.11git44800a7-2 elog starts to work 
> again.
> So this is definitely a regression.
> 
> Kind regards,
> Christopher

Bug#843959: [debian-mysql] Bug#843959: So I have to enable it, but don't need to run it, before each upgrade

[Lars Tangvald]

- jida...@jidanni.org wrote:

> So I have to enable it, but don't need to run it, before each
> upgrade.
> Not very logical.
> 
Yeah, I'm working on fixing the maintainer script to not rely on the service 
being enabled to work (and maybe give a nicer error than "exit code 1" if 
there's a running daemon it can't stop.

--
Lars
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint