Bug#855441: tigervnc-xorg-extension redraw issues

[Martin Dorey]

Package: tigervnc-xorg-extension
Version: 1.7.0+dfsg-2
Severity: normal

Dear Maintainer,

I'd really like to be able to connect to :0 on my work computer from
home.  I used to do that with vino and gnome-fallback on Wheezy.  The
full Gnome 3 experience is slow and generates several Mbit/s of network
traffic with vino.  TigerVNC seems like the way of the future.  If I
start a dedicated TigerVNC server on :1, then it works great.  But I
think I need tigervnc-xorg-extension to connect to my Nvidia-based :0.
When I connect to :0, however, my client display often isn't completely
updated when the server display changes.  I have to play games dragging
selections, moving windows or asking the client to ask for a complete
refresh to see what's going on.

I initially tried TigerVNC 1.6.0 on Jessie, as Jessie is what I really
need to work.  Antipating that you won't care about that smelly old
lashup, I then tried TigerVNC 1.7.0 on Stretch, again with Nvidia's
proprietary driver.  Same behavior.  Now I've also tried a cleaner
install of Stretch with Intel integrated graphics, again Gnome 3, again
TigerVNC 1.7.0.  I think I'm seeing the same behavior, although here I
don't have the same sort of clients.  Connecting back to the same system
with tigervncviewer gets me:

 CConn:   End of stream

On the second and subsequent attempts, that's prefixed by:

Server sent us an invalid screen layout

I tried - and succeeded in - connecting with Chicken of the VNC, an
ancient Mac OS VNC client.  I think I had the cursor stuck in the top
left bug there, but also I wasn't seeing output that I initiated on
the server.  I tried - and again succeeded - in connecting with a
RealVNC client on iPhone, probably both reasonably uptodate.  Again,
server-initiated changes were not displayed on the client.

I had previously suggested that I'd try with "nouveau" instead of nvidia
drivers but there seems little point when I see what's probably the same
behavior on this other system with Intel graphics.  Now I'm at something
of a loss.  I skimmed through the titles of everything in upstream's
issue tracker without seeing anything that grabbed me as relevant (and
obviously Googled too).

-- 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=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 tigervnc-xorg-extension depends on:
ii  libaudit1  1:2.6.7-1
ii  libc6  2.24-8
ii  libgcc11:6.2.1-5
ii  libpam0g   1.1.8-3.5
ii  libstdc++6 6.2.1-5
ii  xserver-xorg-core  2:1.19.0-3

Versions of packages tigervnc-xorg-extension recommends:
ii  tigervnc-common  1.7.0+dfsg-2

tigervnc-xorg-extension suggests no packages.

-- no debconf information

Bug#855439: RFS: cvm/0.97

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : cvm
  Version  : 0.97
  Upstream Author  : Bruce Guenter 
* Url  : http://untroubled.org/cvm/
* Licenses : LGPL-2+,GPL-2+,LGPL-2.1+
  Programming Lang : C
  Section  : libs

 CVM is a framework for validating a set of credentials against a database
 using a filter program.  The modules act as a filter, taking a set of
 credentials as input and writing a set of facts as output if those
 credentials are valid.  Optional input is given to the module through
 environment variables.
 .
 Some of the ideas for CVM came from experience with PAM (pluggable
 authentication modules), the checkpassword interface used by qmail-pop3d,
 and the "authmod" interface used by Courier IMAP and POP3.  This framework
 places fewer restrictions on the invoking client than checkpassword does,
 and is much simpler to implement on both sides than PAM and the authmod
 framework.

Note, that this is not full-scale modernization of package. It is just a
NMU, required for libbg1 -> libbg2 transition. There is still a lot of
Lintian warnings, I know.

It builds those binary packages:

  * cvm
  * cvm-mysql
  * cvm-pgsql
  * libcvm1
  * libcvm1-dev

Please note, that package is maintained with dgit(1) tool using
dgit-maint-merge(7) workflow. In particular, it means that quilt patches
are squashed in source package and are not intended for review. For more
information about how to sponsor this package, see dgit-sponsorship(7).

  Git repository: https://anonscm.debian.org/cgit/users/kaction-guest/bglibs.git
  Git branch: master
  Orig tar.gz: from tag upstream/0.97

With /bin/sh following commands should suffice:

  $ git clone https://anonscm.debian.org/cgit/users/kaction-guest/bglibs.git 
bglibs
  $ cd bglibs
  $ git archive -o ../cvm_0.97.orig.tar.xz upstream/0.97
  $ dgit sbuild

Changes since last upload:

  * Non-maintainer upload.
  * New upstream release (compatible with bglibs >= 2.03)
  * Write watch file and verify GPG signature
  * Upgrade dependendency on bglibs (libbg1-dev -> libbg-dev >= 2.03)
  * Drop rpath related patch (fixed upstream)
  * Adjust debian/rules to changed upstream Makefile
  * Add ldconfig trigger

Regards,
  Dmitry Bogatov

Bug#855440: RFS: bglibs/2.03+dfsg-2

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : bglibs
  Version  : 2.03+dfsg-2
  Upstream Author  : Bruce Guenter 
* Url  : http://untroubled.org/bglibs/
* Licenses : GPL-2+,LGPL-2+,LGPL-2.1+
  Programming Lang : C
  Section  : libs

 ${S:Long-Desc}
 .
 This package contains the shared libraries.

It builds those binary packages:

  * libbg2
  * libbg-dev
  * libbg2-doc

Please note, that package is maintained with dgit(1) tool using
dgit-maint-merge(7) workflow. In particular, it means that quilt
patches are squashed in source package and are not intended for
review. For more information about how to sponsor this package,
see dgit-sponsorship(7).

  Git repository: https://anonscm.debian.org/cgit/users/kaction-guest/bglibs.git
  Git branch: master
  Orig tar.gz: from tag 2.03+dfsg

With /bin/sh following commands should suffice:

  $ git clone https://anonscm.debian.org/cgit/users/kaction-guest/bglibs.git 
bglibs
  $ cd bglibs
  $ git archive -o ../bglibs_2.03+dfsg.orig.tar.xz 2.03+dfsg
  $ dgit sbuild

Changes since last upload:

  * QA upload
  * Remove Conflict field from libbg-dev.
  * Install build tools into libbg-dev package, since they are required
for building other packages of same upstream.
  * Fix spelling error in cli-generate.1

Regards,
  Dmitry Bogatov

Bug#854837: Package dicompyler does not work

[Andreas Tille]

Hi Vojtech,

I followed your hint and commited the following change to the packaging
SVN:

Index: changelog
===
--- changelog   (Revision 23672)
+++ changelog   (Arbeitskopie)
@@ -1,3 +1,11 @@
+dicompyler (0.4.2-4) UNRELEASED; urgency=medium
+
+  * Fix Open Patient dialog (Thanks for the patch to Vojtech Kulvait
+)
+may be close: #854837
+
+ -- Andreas Tille   Sat, 18 Feb 2017 08:11:47 +0100
+
 dicompyler (0.4.2-3) unstable; urgency=medium
 
   * Fix title of citation
Index: patches/fix_DicomImporterDialog.patch
===
--- patches/fix_DicomImporterDialog.patch   (nicht existent)
+++ patches/fix_DicomImporterDialog.patch   (Arbeitskopie)
@@ -0,0 +1,16 @@
+Author: Vojtech Kulvait 
+Last-Update: Tue, 14 Feb 2017 14:18:44 +0100
+Bug-Debian: https://bugs.debian.org/854837
+Description: Fix Open Patient dialog
+
+--- a/dicompyler/dicomgui.py
 b/dicompyler/dicomgui.py
+@@ -50,6 +50,8 @@ class DicomImporterDialog(wx.Dialog):
+ pre = wx.PreDialog()
+ # the Create step is done by XRC.
+ self.PostCreate(pre)
++self.path = "/tmp"
++self.import_location_setting = "Remember Last Used"
+ 
+ def Init(self, res):
+ """Method called after the panel has been initialized."""

My question is now: Is this according to your opinion an appropriate
fix for your problem and has dicompyler now some value for the user?

As I said I can not do any sensible test since I have no data files
and need your confirmation.

Thanks a lot for the patch

 Andreas.

On Tue, Feb 14, 2017 at 02:18:44PM +0100, Vojtech Kulvait wrote:
> Whoewer will be solving this issue. Quick fix should be to edit
> /usr/share/dicompyler/dicompyler/dicomgui.py such that after the line 46
> there will be edit adding these two lines
> 
> 
> class DicomImporterDialog(wx.Dialog):
> """Import DICOM RT files and return a dictionary of data."""
> 
> def __init__(self):
> pre = wx.PreDialog()
> # the Create step is done by XRC.
> self.PostCreate(pre)
> 
> 
> 
> *path = "/tmp"import_location_setting = "Remember Last Used"*
> 
> def Init(self, res):
> 
> 
> After doing that program seems to be able to read RT data and even seem to
> be importing them. However the program is unable to show these data,
> without warnings or errors in the console.
> 
> Vojtech.
> 
> 
> 
> 2017-02-12 22:51 GMT+01:00 Andreas Tille :
> 
> > tags 854837 help
> > severity 854837 grave
> > thanks
> >
> > I can confirm Vojtech's observation that "Open patient" button throws
> > this exception.  I've tagged this bug "help", raised its severity to
> > grave and added upstream developer in CC.  As I said there are no
> > commits on Github for quite some time and there are several open issues
> > which report about disfunctionality.  I have some slight hope that
> > somebody from the Debian team might pick up this issue since it seems to
> > be reproducible.  If it turns out that it can not be fixed until the
> > next release we will not distribute this package inside the next stable
> > release.
> >
> > Thanks for the bug report and sorry for not beeing more helpful
> >
> > Andreas.
> >
> > On Sun, Feb 12, 2017 at 10:30:20PM +0100, Vojtech Kulvait wrote:
> > > Hi,
> > > the package you provided to me does not work either. It shows main
> > > application dialog but when I click on Open patient button it does not
> > open
> > > dialog but in console there is
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *ERROR: Unhandled exception: Traceback (most recent call last):  File
> > > "/usr/share/dicompyler/dicompyler/main.py", line 314, in OnOpenPatient
> > > dicomgui.ImportDicom(self)  File
> > > "/usr/share/dicompyler/dicompyler/dicomgui.py", line 31, in ImportDicom
> > > dlgDicomImporter.Init(res)  File
> > > "/usr/share/dicompyler/dicompyler/dicomgui.py", line 129, in Init
> > > self.OnDirectorySearch()  File
> > > "/usr/share/dicompyler/dicompyler/dicomgui.py", line 188, in
> > > OnDirectorySearchargs=(self, self.path,
> > > self.import_search_subfolders,AttributeError: 'DicomImporterDialog'
> > object
> > > has no attribute 'path'*
> > > Which is the same behavior as when I solved that matplotlib problem by
> > > editing that file.
> > >
> > > I was lucky enough to run windows version today. I was able to view ct
> > data
> > > and radiotherapy data and doses data. It seems in the package you
> > provided
> > > to me there is even no button for importing these data and import dialog
> > is
> > > gray.
> > > Vojtech.
> > >
> > >
> > > 2017-02-12 15:46 GMT+01:00 Andreas Tille :
> > >
> > > > Hi Vojtech,
> > > >
> > > > please make sure you send your mails to 854...@bugs.debian.org and not
> > > > my private e-mail address.  Thanks.
> > > >
> > > > On Sun, Feb 12, 2017 at 08:50:05AM +, Vojtech Kulvait wrote:
> > > > > Andreas,

Bug#855350: tigervnc-xorg-extension: Loading the tigervnc the extension makes the x server practically unusable

[Martin Dorey]

> i could not find a way to actually pass options

I eventually managed to get a default configured Stretch box to accept a
remote connection using:

mad@shuttle:~$ cat /usr/share/X11/xorg.conf.d/75-vnc-mad.conf
Section "Device"
Identifier "Device"
EndSection
Section "Screen"
Identifier "Screen"
Device "Device"
Option "PasswordFile" "/u2/home/mad/.vnc/passwd"
EndSection
mad@shuttle:~$

It seems, from the source, that the PasswordFile Option is only looked for
in the Screen section and the Screen section has to have an Identifier and
a Device, which has to refer to a Device section, which needs an
Identifier.  Argh, but, OK, whatever.  Then I have other problems, both
keeping the connection up and with redraw, but I fear that elaborating them
here would be a hijack of the OP's bug, the main symptom of which - a
horrible-sounding performance issue - I don't see with Gnome 3.

Bug#855436: [Pkg-e-devel] Bug#855436: e17: Newer version of Enlightenment in Debian/testing

[Andreas Metzler]

On 2017-02-18 Adrian Immanuel Kiess  wrote:
> Package: e17
> Version: 0.17.6-1.1
> Severity: wishlist

> Dear Maintainer,

> would it be possible to have a newer version of Enlightenment in
> Debian/testing?

> I already suggested this once.

> The V17 of Enlightenment is quite outdated and it would be nice to
> have a newer version in the repositories.

Hello,

it is not possible currently, Debian/testing has been in transition
freeze since November 5th 2016.

Newer packages are available in Debian/experimental.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#847311: reduce severity

[Brian May]

gustavo panizzo  writes:

> If the bug is not amavisd-new but perl/DBI, shouldn't this bug be 
> reassigned and its severity lowered?

Unfortunately this bug may not be caused by any errors in amavisd-new,
however it still affects user's of amavisd-new. So I think it still
applies here.

> I ask because I won't maintain amavisd-new on stretch, but as a user of 
> it I'd like to have it

Agreed.

For the record, the justification given for this being grave is "causes
non-serious data loss". By "data loss" I assume they mean
"mis-classifies large numbers of emails as spam on some systems".

However I don't consider this to be data loss. By data loss I think
policy means "deletes/currupts random files". Hence I don't think this
should be an RC bug.

It is also worth mentioning that many people use amavisd-new without
mysql support (which is completely optional) and are not affected by
this bug.

> I volunteer to fill the unblock request if the maintainer agrees.  It is 
> too late but i'd try anyway, the debdiff between  2.10.1-2~deb8u1 and 
> 2.10.1-4 shouldn't be big

I think a best recommendation would be to ask the release team for
recommendations on how to proceed. I suspect the best way to contact
them might be via an unblock request.

I don't expect amavisd-new will be allowed back into testing, now that
it has been removed. "After 5th January 2017, removed packages will not
be permitted to re-enter testing." However maybe they might allow
amavisd-new to reenter via the next point release.

I would like to see the Perl bug fixed. There hasn't been any patches
yet, let alone feedback from Perl upstream. So it is not possible to be
certain if the bug is in Perl or libdbd-mysql-perl, or how intrusive the
fix might be.

One thing certain however, I don't believe this bug can be fixed (or
worked around even) by changing amavisd-new.
-- 
Brian May 

Bug#855438: monodevelop: crash on creating Gtk# project into existing folder

[nitrux]

Package: monodevelop
Version: 5.10.0.871-2
Severity: important

Dear Maintainer,

Monodevelop starts normally, but upon creating a Gtk# project into an existing 
folder, the program crashes. I'll attach the log where the error occurs.

-- 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/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages monodevelop depends on:
ii  gnome-icon-theme  3.12.0-2
ii  gnome-terminal [x-terminal-emulator]  3.22.1-1
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libfontconfig12.11.0-6.7
ii  libgconf2.0-cil   2.24.2-4
ii  libglade2.0-cil   2.12.40-1
ii  libglib2.0-0  2.50.2-2
ii  libglib2.0-cil2.12.40-1
ii  libgnome-vfs2.0-cil   2.24.2-4
ii  libgnome2.24-cil  2.24.2-4
ii  libgtk2.0-0   2.24.31-2
ii  libgtk2.0-cil 2.12.40-1
ii  libgtkspell0  2.0.16-1.1
ii  libmono-cairo4.0-cil  4.6.2.7+dfsg-1
ii  libmono-corlib4.5-cil 4.6.2.7+dfsg-1
ii  libmono-microsoft-build-engine4.0-cil 4.6.2.7+dfsg-1
ii  libmono-microsoft-build-framework4.0-cil  4.6.2.7+dfsg-1
ii  libmono-microsoft-build-utilities-v4.0-4.0-cil4.6.2.7+dfsg-1
ii  libmono-microsoft-csharp4.0-cil   4.6.2.7+dfsg-1
ii  libmono-posix4.0-cil  4.6.2.7+dfsg-1
ii  libmono-sharpzip4.84-cil  4.6.2.7+dfsg-1
ii  libmono-system-componentmodel-dataannotations4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-configuration4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-data-services-client4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-data4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-design4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-drawing4.0-cil 4.6.2.7+dfsg-1
ii  libmono-system-numerics4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-runtime-serialization4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-runtime4.0-cil 4.6.2.7+dfsg-1
ii  libmono-system-security4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-servicemodel4.0a-cil   4.6.2.7+dfsg-1
ii  libmono-system-web-mvc3.0-cil 4.6.2.7+dfsg-1
ii  libmono-system-web-razor2.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-web-services4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-web-webpages-razor2.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-web4.0-cil 4.6.2.7+dfsg-1
ii  libmono-system-windows-forms4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-xaml4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-xml-linq4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil 4.6.2.7+dfsg-1
ii  libmono-system4.0-cil 4.6.2.7+dfsg-1
ii  libmono-windowsbase4.0-cil4.6.2.7+dfsg-1
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libwebkitgtk-1.0-02.4.11-3
ii  mate-terminal [x-terminal-emulator]   1.16.1-2
ii  mono-runtime  4.6.2.7+dfsg-1
ii  mono-runtime-sgen 4.6.2.7+dfsg-1
ii  mono-xbuild   4.6.2.7+dfsg-1
ii  monodoc-base  4.6.2.7+dfsg-1
ii  monodoc-manual4.6.2.7+dfsg-1
ii  pkg-config0.29-4

Versions of packages monodevelop recommends:
ii  libglade2.0-cil-dev  2.12.40-1
ii  libgtk2.0-cil-dev2.12.40-1
ii  mono-devel   4.6.2.7+dfsg-1

Versions of packages monodevelop suggests:
pn  exuberant-ctags 
ii  gcc 4:6.3.0-1
pn  gettext 
ii  make4.1-9
pn  mono-vbnc   
pn  mono-xsp | mono-xsp4
pn  monodevelop-database
pn  monodevelop-debugger-gd

Bug#855437: g-brief2.cls: Error on compile with LyX

[Adrian Immanuel Kiess]

Package: texlive-latex-extra
Version: 2016.20170123-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Compile g-brief2 letter with LyX
   * What exactly did you do (or not do) that was effective (or
 In LyX: Document->View as pdflatex
 ineffective)?
   * What was the outcome of this action?
 LaTeX error: No counter blockzahl defined
   * What outcome did you expect instead?
 Working compile of g-brief2 letter

in the current texlive-latex-extra package of Debian/testing there is still a
bogous version of g-brief2.cls in the repositories.

Trying to compile a g-bief2 letter with LyX results in this error:

LaTeX error: No counter blockzahl defined

I attached a fixed version of g-brief2.cls as g-brief2.cls.adrian to this
report.

Thank you very much.

Sincerely,

Adrian Immanuel Kieß
http://www.immanuelK.net





-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 4135 Feb 18 06:46 /var/lib/texmf/ls-R
-rw-rw-r-- 1 root staff 80 Apr 16  2015 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jan 17 03:45 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Feb 12 12:04 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Feb 12 12:04 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 1293 Jan 28 08:04 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 12 12:04 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb 12 12:04 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3300 Feb 18 06:46 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root  283 Nov 10  2008 mktex.cnf
-rw-r--r-- 1 root root 1293 Jan 28 08:04 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf
d588a08518f705d06ac262acd78f2bc4  /etc/texmf/texmf.d/20xmltex.cnf
055e06548bac99958d8ab2dd1248f2b4  /etc/texmf/texmf.d/80tex4ht.cnf

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
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 texlive-latex-extra depends on:
ii  preview-latex-style11.90-1
ii  tex-common 6.06
ii  texlive-base   2016.20170123-3
ii  texlive-binaries   2016.20160513.41080.dfsg-1
ii  texlive-latex-recommended  2016.20170123-3
ii  texlive-pictures   2016.20170123-3

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2016.20170123-3
ii  texlive-generic-extra  2016.20170123-3
ii  texlive-latex-extra-doc2016.20170123-3

Versions of packages texlive-latex-extra suggests:
ii  libfile-which-perl  1.21-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments

Bug#855436: e17: Newer version of Enlightenment in Debian/testing

[Adrian Immanuel Kiess]

Package: e17
Version: 0.17.6-1.1
Severity: wishlist

Dear Maintainer,

would it be possible to have a newer version of Enlightenment in
Debian/testing?

I already suggested this once.

The V17 of Enlightenment is quite outdated and it would be nice to have a newer
version in the repositories.

Thank you very much for your time.

Sincerely,

Adrian Immanuel Kieß
http://www.immanuelK.net



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
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 e17 depends on:
ii  dbus-x11   1.10.14-1
ii  e17-data   0.17.6-1.1
ii  libasound2 1.1.3-4
ii  libc6  2.24-9
ii  libdbus-1-31.10.14-1
ii  libecore-con1  1.8.6-2.5+b1
ii  libecore-evas1 1.8.6-2.5+b1
ii  libecore-file1 1.8.6-2.5+b1
ii  libecore-imf1  1.8.6-2.5+b1
ii  libecore-input11.8.6-2.5+b1
ii  libecore-ipc1  1.8.6-2.5+b1
ii  libecore-x11.8.6-2.5+b1
ii  libecore1  1.8.6-2.5+b1
ii  libedbus1  1.7.10-1
ii  libedje-bin1.8.6-2.5+b1
ii  libedje1   1.8.6-2.5+b1
ii  libeet11.8.6-2.5+b1
ii  libeeze1   1.8.6-2.5+b1
ii  libefreet-bin  1.8.6-2.5+b1
ii  libefreet1a1.8.6-2.5+b1
ii  libeina1   1.8.6-2.5+b1
ii  libeio11.8.6-2.5+b1
ii  libevas1   1.8.6-2.5+b1
ii  libevas1-engines-x [libevas1-engine-software-x11]  1.8.6-2.5+b1
ii  libpam0g   1.1.8-3.5
ii  libxcb-keysyms10.4.0-1
ii  libxcb-shape0  1.12-1
ii  libxcb11.12-1

Versions of packages e17 recommends:
ii  pm-utils  1.4.1-17

e17 suggests no packages.

-- no debconf information

Bug#855261: Epiphany crashes when browsing sechat.org

[Ильдар Ахметгалеев]

Attching valgrind log.
`--> valgrind epiphany24m 28s 11:27
==20246== Memcheck, a memory error detector
==20246== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==20246== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==20246== Command: epiphany
==20246==
==22324==
==22324== HEAP SUMMARY:
==22324== in use at exit: 1,088,346 bytes in 17,116 blocks
==22324==   total heap usage: 210,032 allocs, 192,916 frees, 7,953,879 bytes allocated
==22324==
==22324== LEAK SUMMARY:
==22324==definitely lost: 4,359 bytes in 12 blocks
==22324==indirectly lost: 6,824 bytes in 15 blocks
==22324==  possibly lost: 1,364 bytes in 24 blocks
==22324==still reachable: 1,031,191 bytes in 16,418 blocks
==22324==   of which reachable via heuristic:
==22324== length64   : 56 bytes in 1 blocks
==22324== newarray   : 3,068 bytes in 120 blocks
==22324== suppressed: 0 bytes in 0 blocks
==22324== Rerun with --leak-check=full to see details of leaked memory
==22324==
==22324== For counts of detected and suppressed errors, rerun with: -v
==22324== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==20246== Thread 9:
==20246== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==20246==at 0x9430264: sendmsg (sendmsg.c:30)
==20246==by 0x50A105F: IPC::Connection::sendOutgoingMessage(std::unique_ptr >) (ConnectionUnix.cpp:506)
==20246==by 0x4E28B2A: IPC::Connection::sendOutgoingMessages() (Connection.cpp:759)
==20246==by 0x4E28BBA: operator() (Connection.cpp:375)
==20246==by 0x4E28BBA: WTF::Function::CallableWrapper >, WTF::OptionSet)::{lambda()#1}>::call() (Function.h:101)
==20246==by 0x7EEA3BA: operator() (Function.h:50)
==20246==by 0x7EEA3BA: WTF::RunLoop::performWork() (RunLoop.cpp:122)
==20246==by 0x7F148B7: operator() (RunLoopGLib.cpp:66)
==20246==by 0x7F148B7: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:68)
==20246==by 0x930B39A: g_main_dispatch (gmain.c:3203)
==20246==by 0x930B39A: g_main_context_dispatch (gmain.c:3856)
==20246==by 0x930B788: g_main_context_iterate.isra.29 (gmain.c:3929)
==20246==by 0x930BB38: g_main_loop_run (gmain.c:4125)
==20246==by 0x7F15368: WTF::RunLoop::run() (RunLoopGLib.cpp:94)
==20246==by 0x7F13BA5: operator() (WorkQueueGeneric.cpp:58)
==20246==by 0x7F13BA5: std::_Function_handler::_M_invoke(std::_Any_data const&) (functional:1731)
==20246==by 0x7EEAE9F: operator() (functional:2127)
==20246==by 0x7EEAE9F: WTF::threadEntryPoint(void*) (Threading.cpp:60)
==20246==  Address 0x12602de9 is on thread 9's stack
==20246==  in frame #1, created by IPC::Connection::sendOutgoingMessage(std::unique_ptr>) (ConnectionUnix.cpp:406)
==20246==
==20246== Syscall param sendmsg(msg.msg_iov[2]) points to uninitialised byte(s)
==20246==at 0x9430264: sendmsg (sendmsg.c:30)
==20246==by 0x50A105F: IPC::Connection::sendOutgoingMessage(std::unique_ptr >) (ConnectionUnix.cpp:506)
==20246==by 0x4E28B2A: IPC::Connection::sendOutgoingMessages() (Connection.cpp:759)
==20246==by 0x4E28BBA: operator() (Connection.cpp:375)
==20246==by 0x4E28BBA: WTF::Function::CallableWrapper >, WTF::OptionSet)::{lambda()#1}>::call() (Function.h:101)
==20246==by 0x7EEA3BA: operator() (Function.h:50)
==20246==by 0x7EEA3BA: WTF::RunLoop::performWork() (RunLoop.cpp:122)
==20246==by 0x7F148B7: operator() (RunLoopGLib.cpp:66)
==20246==by 0x7F148B7: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:68)
==20246==by 0x930B39A: g_main_dispatch (gmain.c:3203)
==20246==by 0x930B39A: g_main_context_dispatch (gmain.c:3856)
==20246==by 0x930B788: g_main_context_iterate.isra.29 (gmain.c:3929)
==20246==by 0x930BB38: g_main_loop_run (gmain.c:4125)
==20246==by 0x7F15368: WTF::RunLoop::run() (RunLoopGLib.cpp:94)
==20246==by 0x7F13BA5: operator() (WorkQueueGeneric.cpp:58)
==20246==by 0x7F13BA5: std::_Function_handler::_M_invoke(std::_Any_data const&) (functional:1731)
==20246==by 0x7EEAE9F: operator() (functional:2127)
==20246==by 0x7EEAE9F: WTF::threadEntryPoint(void*) (Threading.cpp:60)
==20246==  Address 0xd7de0a8 is in a rw- anonymous segment
==20246==
==23132==
==23132== HEAP SUMMARY:
==23132== in use at exit: 11,228,145 bytes in 439,819 blocks
==23132==   total heap usage: 789,626 allocs, 349,807 frees, 27,733,439 bytes allocated
==23132==
==23132== LEAK SUMMARY:
==23132==definitely lost: 30,541 bytes in 69 blocks
==23132==indirectly lost: 31,183 bytes in 1,433 blocks
==23132==  possibly lost: 3,609 bytes in 66 blocks
==23132==still reachable: 10,922,652 bytes in 435,115 blocks
==23132==   of which reachable via heuristic:
==23132== length64

Bug#847311: reduce severity

[gustavo panizzo]

Hello

If the bug is not amavisd-new but perl/DBI, shouldn't this bug be 
reassigned and its severity lowered? 

I ask because I won't maintain amavisd-new on stretch, but as a user of 
it I'd like to have it


I volunteer to fill the unblock request if the maintainer agrees.  It is 
too late but i'd try anyway, the debdiff between  2.10.1-2~deb8u1 and 
2.10.1-4 shouldn't be big


thanks

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

keybase: https://keybase.io/gfa

Bug#855202: RFS: binaryornot/0.4.0+dfsg-0.1 [RC][NMU] -- check if a file is binary or text

[Roger Shimizu]

On Sat, Feb 18, 2017 at 1:04 AM, Sean Whitton  wrote:
>
> You need to submit the nmudiff to #854851.

Followed your advice.
Please kindly helpt to sponsor. Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#854851: binaryornot: diff for NMU version 0.4.0+dfsg-0.1

[rogershimizu]

Control: tags 854851 + patch

Dear maintainer,

I've prepared an NMU for binaryornot (versioned as 0.4.0+dfsg-0.1) and
uploaded it to mentors. Please feel free to tell me if I should stop.

Regards.
diff -Nru binaryornot-0.4.0/debian/changelog 
binaryornot-0.4.0+dfsg/debian/changelog
--- binaryornot-0.4.0/debian/changelog  2015-11-16 07:05:20.0 +0900
+++ binaryornot-0.4.0+dfsg/debian/changelog 2017-02-15 21:07:15.0 
+0900
@@ -1,3 +1,17 @@
+binaryornot (0.4.0+dfsg-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Ondřej Nový ]
+  * Fixed VCS URL (https)
+
+  [ Roger Shimizu ]
+  * Remove non-free image files, and repack as +dfsg.
+  * Add patch to remove tests regarding to non-free image files.
+(Closes: #854851)
+
+ -- Roger Shimizu   Wed, 15 Feb 2017 21:07:15 +0900
+
 binaryornot (0.4.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru binaryornot-0.4.0/debian/control binaryornot-0.4.0+dfsg/debian/control
--- binaryornot-0.4.0/debian/control2015-11-16 07:05:20.0 +0900
+++ binaryornot-0.4.0+dfsg/debian/control   2017-02-15 21:01:09.0 
+0900
@@ -10,7 +10,7 @@
python-hypothesis, python3-hypothesis
 Standards-Version: 3.9.6
 Homepage: https://github.com/audreyr/binaryornot
-Vcs-Git: git://anonscm.debian.org/python-modules/packages/binaryornot.git
+Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/binaryornot.git
 Vcs-Browser: 
https://anonscm.debian.org/cgit/python-modules/packages/binaryornot.git
 
 Package: python-binaryornot
diff -Nru 
binaryornot-0.4.0/debian/patches/0001-Remove-tests-regarding-to-non-free-image-lena.patch
 
binaryornot-0.4.0+dfsg/debian/patches/0001-Remove-tests-regarding-to-non-free-image-lena.patch
--- 
binaryornot-0.4.0/debian/patches/0001-Remove-tests-regarding-to-non-free-image-lena.patch
   1970-01-01 09:00:00.0 +0900
+++ 
binaryornot-0.4.0+dfsg/debian/patches/0001-Remove-tests-regarding-to-non-free-image-lena.patch
  2017-02-15 21:07:15.0 +0900
@@ -0,0 +1,26 @@
+From: Roger Shimizu 
+Date: Wed, 15 Feb 2017 21:14:30 +0900
+Subject: Remove tests regarding to non-free image lena
+
+See Bug #854851
+---
+ tests/test_check.py | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/tests/test_check.py b/tests/test_check.py
+index 338119e..fbe32d1 100755
+--- a/tests/test_check.py
 b/tests/test_check.py
+@@ -49,12 +49,6 @@ class TestIsBinary(unittest.TestCase):
+ def test_png(self):
+ self.assertTrue(is_binary('tests/files/logo.png'))
+ 
+-def test_gif(self):
+-self.assertTrue(is_binary('tests/files/lena.gif'))
+-
+-def test_jpg(self):
+-self.assertTrue(is_binary('tests/files/lena.jpg'))
+-
+ def test_tiff(self):
+ self.assertTrue(is_binary('tests/files/palette-1c-8b.tiff'))
+ 
diff -Nru binaryornot-0.4.0/debian/patches/series 
binaryornot-0.4.0+dfsg/debian/patches/series
--- binaryornot-0.4.0/debian/patches/series 1970-01-01 09:00:00.0 
+0900
+++ binaryornot-0.4.0+dfsg/debian/patches/series2017-02-15 
21:07:15.0 +0900
@@ -0,0 +1 @@
+0001-Remove-tests-regarding-to-non-free-image-lena.patch
Binary files /tmp/jwrjax7x2k/binaryornot-0.4.0/tests/files/lena.gif and 
/tmp/o2Z1tbw9iN/binaryornot-0.4.0+dfsg/tests/files/lena.gif differ
Binary files /tmp/jwrjax7x2k/binaryornot-0.4.0/tests/files/lena.jpg and 
/tmp/o2Z1tbw9iN/binaryornot-0.4.0+dfsg/tests/files/lena.jpg differ

Bug#855355: RFS: nasm/2.12.02-1 [ITA]

[Paul Wise]

On Fri, 17 Feb 2017 07:50:21 + (UTC) Gianfranco Costamagna wrote:

> side note: the reproducible patch might be changed in something little 
> different
> -const char nasm_date[] = __DATE__;
> +const char nasm_date[] = __DATE_DEBIAN__;

It is far better to just remove build dates, they are very pointless.

> and then use dpkg-parsechangelog to feed that value on CFLAGS
> this way you will get the date from the latest changelog entry.

That isn't necessary because Debian has implemented SOURCE_DATE_EPOCH:

https://reproducible-builds.org/specs/source-date-epoch/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#855239: diffoscope: Tests that call xxd fail on jessie due to output change

[Chris Lamb]

tags 855239 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=46d9c87391fe40eb978244675b43b4bc82abd033


Regards,

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

Bug#855435: do not repeat the name in the NAME section of the man pages

[積丹尼 Dan Jacobson]

Package: gdal-bin
Version: 2.1.2+dfsg-2+b1
Severity: minor

Please do not repeat the name(.py):
$ apropos gdal
gdal_utilities (1)   - GDAL Utilities A collection of GDAL related programs.
gdal2tiles (1)   - gdal2tiles.py generates directory with TMS tiles, KMLs 
and simple web viewers
gdal_calc (1)- gdal_calc.py Command line raster calculator with numpy 
syntax
gdal_contour (1) - gdal_contour builds vector contour lines from a raster 
elevation model
gdal_edit (1)- gdal_edit.py Edit in place various information of an 
existing GDAL dataset
gdal_fillnodata (1)  - gdal_fillnodata.py fill raster regions by interpolation 
from edges
gdal_grid (1)- gdal_grid creates regular grid from the scattered data
gdal_merge (1)   - gdal_merge.py mosaics a set of images
gdal_pansharpen (1)  - gdal_pansharpen.py Perform a pansharpen operation.
gdal_polygonize (1)  - gdal_polygonize.py produces a polygon feature layer from 
a raster
gdal_proximity (1)   - gdal_proximity.py produces a raster proximity map
gdal_rasterize (1)   - gdal_rasterize burns vector geometries into a raster
gdal_retile (1)  - gdal_retile.py gdal_retile.py retiles a set of tiles 
and/or build tiled pyramid levels
gdal_sieve (1)   - gdal_sieve.py removes small raster polygons
gdal_translate (1)   - gdal_translate converts raster data between different 
formats
gdaladdo (1) - gdaladdo builds or rebuilds overview images
gdalbuildvrt (1) - gdalbuildvrt Builds a VRT from a list of datasets. 
(compiled by default since GDAL 1.6.1)
gdalcompare (1)  - gdalcompare.py compare two images
gdaldem (1)  - gdaldem Tools to analyze and visualize DEMs. (since GDAL 
1.7.0)
gdalinfo (1) - gdalinfo lists information about a raster dataset
gdallocationinfo (1) - gdallocationinfo raster query tool
gdalmanage (1)   - gdalmanage Identify, delete, rename and copy raster data 
files
gdalmove (1) - gdalmove.py Transform georeferencing of raster file in 
place
gdalsrsinfo (1)  - gdalsrsinfo lists info about a given SRS in number of 
formats (WKT, PROJ.4, etc.)
gdaltindex (1)   - gdaltindex Builds a shapefile as a raster tileindex
gdaltransform (1)- gdaltransform transforms coordinates
gdalwarp (1) - gdalwarp image reprojection and warping utility
raster2pgsql (1) - loads GDAL supported raster formats into a PostGIS 
raster table

Bug#855434: chromium: Invalid SSL connection failure

[Ian Maxon]

Package: chromium
Version: 56.0.2924.76-3
Severity: important

For some sites, namely google.com, Chromium will fail to connect with
ERR_SSL_PROTOCOL_ERROR ( $SITE sent an invalid response ). Some sites will
still work over SSL, I am not sure what is the differentiator between these.
The site works fine on chrome so it is not the site itself or a MITM or
similar.



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

Kernel: Linux 4.9.0-1-amd64 (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 chromium depends on:
ii  libasound2   1.1.3-4
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.2.4-1
ii  libavformat577:3.2.4-1
ii  libavutil55  7:3.2.4-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8
ii  libdbus-1-3  1.10.14-1
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libexpat12.2.0-2
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.3.0-6
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-2
ii  libharfbuzz0b1.4.2-1
ii  libicu57 57.1-5
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.3.0-6
ii  libvpx4  1.6.1-2
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#855433: devscripts: wrap-and-sort: Add missing build dependency fields

[Guillem Jover]

Package: devscripts
Version: 2.17.1
Severity: wishlist
User: devscri...@packages.debian.org
Usertags: wrap-and-sort
Tags: patch

Hi!

Attached a patch adding several missing fields.

Thanks,
Guillem
From 832804f583e596c06ea94c4226ec5ade899a7bf8 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 18 Feb 2017 01:51:11 +0100
Subject: [PATCH] wrap-and-sort: Add missing build dependency fields

---
 scripts/wrap-and-sort | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/wrap-and-sort b/scripts/wrap-and-sort
index 666c732b..4d1d24de 100755
--- a/scripts/wrap-and-sort
+++ b/scripts/wrap-and-sort
@@ -27,8 +27,12 @@ from devscripts.control import Control
 CONTROL_LIST_FIELDS = (
 "Breaks",
 "Build-Conflicts",
+"Build-Conflicts-Arch",
+"Build-Conflicts-Indep",
 "Build-Depends",
+"Build-Depends-Arch",
 "Build-Depends-Indep",
+"Built-Using",
 "Conflicts",
 "Depends",
 "Enhances",
-- 
2.11.0.483.g087da7b7c

Bug#855336: make hangs when synchronizing output and redirecting to null

[James Cowgill]

Hi,

On 17/02/17 18:08, Norbert Lange wrote:
> Hello,
> 
> Tried reproducing it at work (where it first happened on a build server).
> On my PC at home with 4 cores / 12 thread the bug reproduces always
> On a 6 core / 12 threads Xeon Server  the bug reproduces always
> On my work PC with 4 cores / 4 threads running in a VMware Instance it
> doesnt reproduce.
> All running Debian Stretch with current updates.
> 
> Maybe you want to add infos about your system?
> From the sample of 3: Hyperthreading or >= 8 threads or runnin on bare
> metal instead of in a VM could provoke the bug.

Originally the system I tried it on has 8 cores (can't remember number
of threads), but I tried it on machines with 2 cores and one with 16 and
it worked on all of them. I don't think the number of cores is relevant
here.

> Further make 4.1 was uploaded to Debian Stretch on 16h january, the
> issue appeared on 19th january on the server.
> So disregard what I said about this not being an upstream issue - its
> actually quite possible.

Have you muddled years up here? 4.1 was uploaded on 16th Jan *2016*.

> Heres a dump via attached gdb (step wont do anything so it seems that
> the thread is blocked):
> 
> (gdb) thread apply all bt
> 
> Thread 1 (process 12177):
> #0  0x7f476c156962 in do_fcntl (fd=1, cmd=7, arg=0x5595eae95ea0)
> at ../sysdeps/unix/sysv/linux/fcntl.c:31

This is fcntl(stdout = /dev/null, F_SETLKW, )

It seems that "make -O" attempts to lock stdout before writing to it so
that multiple make processes can cooperate on who gets to write any
output. If it's hanging here, then someone must already be holding the lock.

Please can you give the output of "lslocks" on the machines that fail.
There might be an entry for /dev/null which will point at the culprit.
Failing that, an "strace -f" would be useful so we can see all the calls
made to fcntl.

> I`ll have to compile make with debuginfo if you need more (gonna take
> a few days)

I don't need any debug information, but you may be interested in this:
https://wiki.debian.org/AutomaticDebugPackages

So if you add this apt source:
deb http://deb.debian.org/debian-debug/ unstable-debug main

You can then install make-dbgsym to get the debug symbols for make
without recompiling anything.

Thanks,
James

> 2017-02-17 15:24 GMT+01:00 James Cowgill :
>> On 16/02/17 21:52, Norbert Lange wrote:
>>> Package: make
>>> Version: 4.1-9
>>> Severity: important
>>>
>>> Dear Maintainer,
>>>
>>> running the attached Makefile will hang the process,
>>> if multiple jobs are used then the process wont respond to a
>>> TERM and has to be killed.
>>>
>>> The very same issue is observed with make-guile.
>>>
>>> I believe this to not be an upstream bug, since I observed this
>>> only a couple weeks ago after an upgrade.
>>> Unfortunatly I can`t pinpoint a date or version.
>>
>> I cannot reproduce this bug.
>>
>> Also, make has not been updated in testing for almost a year so if it
>> only started happening recently, something else probably caused it.
>>
>> Running 'make -d -O' (although this may be difficult if the bug requires
>> redirection to /dev/null) or the output or running make inside gdb and
>> finding where it hangs might help in diagnosing this.
>>
>> Thanks,
>> James



signature.asc
Description: OpenPGP digital signature

Bug#855017: [PATCH] ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419

[Ben Hutchings]

The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals).  Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.

Reported-by: g...@gazeta.pl
Tested-by: g...@gazeta.pl
References: https://bugs.debian.org/855017
Cc: sta...@vger.kernel.org # 3.15+
Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419")
Signed-off-by: Ben Hutchings 
---
 arch/arm/boot/dts/kirkwood-ts419.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-ts419.dtsi 
b/arch/arm/boot/dts/kirkwood-ts419.dtsi
index 02bd53762705..532506cb0f4a 100644
--- a/arch/arm/boot/dts/kirkwood-ts419.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts419.dtsi
@@ -73,3 +73,11 @@
phy-handle = <ðphy1>;
};
 };
+
+&pmx_sata0 {
+   marvell,pins = "mpp15";
+};
+
+&pmx_sata1 {
+   marvell,pins = "mpp16";
+};


signature.asc
Description: Digital signature

Bug#853110: [PATCH] [media] dvb-usb-dibusb-mc-common: Add MODULE_LICENSE

[Ben Hutchings]

dvb-usb-dibusb-mc-common is licensed under GPLv2, and if we don't say
so then it won't even load since it needs a GPL-only symbol.

Reported-by: Dominique Dumont 
References: https://bugs.debian.org/853110
Cc: sta...@vger.kernel.org # 4.9+
Fixes: e91455a1495a ("[media] dvb-usb: split out common parts of dibusb")
Signed-off-by: Ben Hutchings 
---
 drivers/media/usb/dvb-usb/dibusb-mc-common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb/dibusb-mc-common.c 
b/drivers/media/usb/dvb-usb/dibusb-mc-common.c
index c989cac9343d..0c2bc97436d5 100644
--- a/drivers/media/usb/dvb-usb/dibusb-mc-common.c
+++ b/drivers/media/usb/dvb-usb/dibusb-mc-common.c
@@ -11,6 +11,8 @@
 
 #include "dibusb.h"
 
+MODULE_LICENSE("GPL");
+
 /* 3000MC/P stuff */
 // Config Adjacent channels  Perf -cal22
 static struct dibx000_agc_config dib3000p_mt2060_agc_config = {


signature.asc
Description: Digital signature

Bug#855017: linux-image-4.9.0-1-marvell: eth1 not detected/available on QNAP TS-419pII

[Ben Hutchings]

On Fri, 2017-02-17 at 22:30 +0100, g...@gazeta.pl wrote:
> On 17.02.2017 02:57, Ben Hutchings wrote:
> > This seems to be a bug in the device tree for the TS419 - it doesn't
> > quite match the board code it replaced.  Should be easy to fix.
> 
> After applying patch, eth1 is recognized, but it behaves strange. It
> looks like it is using a correct MAC during DHCP phase, but after
> getting IP from DHCP it clones(?) eth0 MAC.

I don't think so.

[...]
> Here is an relevant output from dmesg:
> 
> [0.045321] [Firmware Info]:
> /ocp@f100/ethernet-controller@72000/ethernet0-port@0:
> local-mac-address is not set
> [0.045412] [Firmware Info]:
> /ocp@f100/ethernet-controller@76000/ethernet1-port@0:
> local-mac-address is not set
> [   60.981436] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> [   61.917900] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
> address 00:08:9b:cb:ae:be
> [   62.441157] mv643xx_eth_port mv643xx_eth_port.1 eth1: port 0 with MAC
> address 00:08:9b:cb:ae:bf

OK, so this worked.

[...]
> And here is an output from arp on router:
> 
> IP address   HW type Flags   HW addressMask
> Device
> 192.168.1.1010x1 0x2 00:08:9b:cb:ae:be *
> br-lan
> 192.168.1.1000x1 0x2 00:08:9b:cb:ae:be *
> br-lan
> 
> both IP addresses have same MAC (from eth0).
>
> I'm not sure what is going here...

This is not a driver issue.  See:
https://serverfault.com/questions/22253/ubuntu-linux-multiple-nics-same-lan-arp-responses-always-go-out-a-single-n
(which has two possible solutions).

(I do wonder whether having two links to the same VLAN without bonding
is at all sensible, anyway.)

> BTW. Is this .dtsi file responsible for GPIO configuration?

All model-specific stuff is now defined by device trees.  The
definition for this model is spread across kirkwood-ts419-6282.dts and
four other files you can see listed at the top of it.

> I've also noticed a strange behavior with qcontrol:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795558

So far as I can remember, device trees do not have a way to request
that a GPIO should be automatically exported to userland.  That will
have to be done by qcontrol.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


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

Bug#855169: diffoscope: use BSD-style stat on FreeBSD

[Chris Lamb]

tags 855169 + pending
thanks

Applied; many thanks. :)


Regards,

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

Bug#855432: unblock: openssl/1.1.0e-1

[Kurt Roeckx]

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

Hi,

There was a new upstream release fixing a high severity security
issue.

The changelog entry is:
openssl (1.1.0e-1) unstable; urgency=high

  * New upstream version
- Fixes CVE-2017-3733
- Remove patches that are applied upstream.

 -- Kurt Roeckx   Thu, 16 Feb 2017 18:57:58 +0100

I've attached the full debdiff between the version in testing and
unstable.


Kurt

diff -Nru openssl-1.1.0d/apps/openssl.c openssl-1.1.0e/apps/openssl.c
--- openssl-1.1.0d/apps/openssl.c	2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/openssl.c	2017-02-16 12:58:20.0 +0100
@@ -58,7 +58,6 @@
 static void list_disabled(void);
 char *default_config_file = NULL;
 
-static CONF *config = NULL;
 BIO *bio_in = NULL;
 BIO *bio_out = NULL;
 BIO *bio_err = NULL;
@@ -248,8 +247,6 @@
  end:
 OPENSSL_free(copied_argv);
 OPENSSL_free(default_config_file);
-NCONF_free(config);
-config = NULL;
 lh_FUNCTION_free(prog);
 OPENSSL_free(arg.argv);
 
diff -Nru openssl-1.1.0d/apps/req.c openssl-1.1.0e/apps/req.c
--- openssl-1.1.0d/apps/req.c	2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/req.c	2017-02-16 12:58:20.0 +0100
@@ -121,7 +121,7 @@
 {"multivalue-rdn", OPT_MULTIVALUE_RDN, '-',
  "Enable support for multivalued RDNs"},
 {"days", OPT_DAYS, 'p', "Number of days cert is valid for"},
-{"set_serial", OPT_SET_SERIAL, 'p', "Serial number to use"},
+{"set_serial", OPT_SET_SERIAL, 's', "Serial number to use"},
 {"extensions", OPT_EXTENSIONS, 's',
  "Cert extension section (override value in config file)"},
 {"reqexts", OPT_REQEXTS, 's',
diff -Nru openssl-1.1.0d/apps/s_cb.c openssl-1.1.0e/apps/s_cb.c
--- openssl-1.1.0d/apps/s_cb.c	2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/s_cb.c	2017-02-16 12:58:20.0 +0100
@@ -922,6 +922,7 @@
 BIO_printf(bio_err, "%s: Error adding xcert\n", opt_getprog());
 goto err;
 }
+*pexc = exc;
 exc->certfile = opt_arg();
 break;
 case OPT_X_KEY:
diff -Nru openssl-1.1.0d/apps/ts.c openssl-1.1.0e/apps/ts.c
--- openssl-1.1.0d/apps/ts.c	2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/ts.c	2017-02-16 12:58:20.0 +0100
@@ -890,9 +890,15 @@
 goto err;
 f = TS_VFY_VERSION | TS_VFY_SIGNER;
 if (data != NULL) {
+BIO *out = NULL;
+
 f |= TS_VFY_DATA;
-if (TS_VERIFY_CTX_set_data(ctx, BIO_new_file(data, "rb")) == NULL)
+if ((out = BIO_new_file(data, "rb")) == NULL)
 goto err;
+if (TS_VERIFY_CTX_set_data(ctx, out) == NULL) {
+BIO_free_all(out);
+goto err;
+}
 } else if (digest != NULL) {
 long imprint_len;
 unsigned char *hexstr = OPENSSL_hexstr2buf(digest, &imprint_len);
diff -Nru openssl-1.1.0d/CHANGES openssl-1.1.0e/CHANGES
--- openssl-1.1.0d/CHANGES	2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/CHANGES	2017-02-16 12:58:20.0 +0100
@@ -2,6 +2,19 @@
  OpenSSL CHANGES
  ___
 
+ Changes between 1.1.0d and 1.1.0e [16 Feb 2017]
+
+  *) Encrypt-Then-Mac renegotiation crash
+
+ During a renegotiation handshake if the Encrypt-Then-Mac extension is
+ negotiated where it was not in the original handshake (or vice-versa) then
+ this can cause OpenSSL to crash (dependant on ciphersuite). Both clients
+ and servers are affected.
+
+ This issue was reported to OpenSSL by Joe Orton (Red Hat).
+ (CVE-2017-3733)
+ [Matt Caswell]
+
  Changes between 1.1.0c and 1.1.0d [26 Jan 2017]
 
   *) Truncated packet could crash via OOB read
diff -Nru openssl-1.1.0d/Configurations/unix-Makefile.tmpl openssl-1.1.0e/Configurations/unix-Makefile.tmpl
--- openssl-1.1.0d/Configurations/unix-Makefile.tmpl	2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/Configurations/unix-Makefile.tmpl	2017-02-16 12:58:20.0 +0100
@@ -285,6 +285,7 @@
 	-$(RM) `find . -name '*{- $objext -}' -a \! -path "./.git/*"`
 	$(RM) core
 	$(RM) tags TAGS
+	$(RM) test/.rnd
 	$(RM) openssl.pc libcrypto.pc libssl.pc
 	-$(RM) `find . -type l -a \! -path "./.git/*"`
 	$(RM) $(TARFILE)
diff -Nru openssl-1.1.0d/crypto/aes/asm/aesv8-armx.pl openssl-1.1.0e/crypto/aes/asm/aesv8-armx.pl
--- openssl-1.1.0d/crypto/aes/asm/aesv8-armx.pl	2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/crypto/aes/asm/aesv8-armx.pl	2017-02-16 12:58:20.0 +0100
@@ -59,9 +59,12 @@
 .text
 ___
 $code.=".arch	armv8-a+crypto\n"			if ($flavour =~ /64/);
-$code.=".arch	armv7-a\n.fpu	neon\n.code	32\n"	if ($flavour !~ /64/);
-		#^^ this is done to simplify adoption by not depending
-		#	on latest binutils.
+$code.=<<___		if ($flavour !~ /64/);
+.arch	armv7-a	// don't confuse not-so-latest binutils with argv8 :-)
+.fpu	neon
+.code	32
+#undef	__thumb2__
+___
 
 # 

Bug#853834: Ccache storing and restoring file paths that may no longer be correct

[Ben Hutchings]

Control: tag -1 upstream fixed-upstream

On Fri, 2017-02-17 at 16:41 +, Ben Hutchings wrote:
> On Fri, 2017-02-17 at 14:12 +, Ben Hutchings wrote:
> [...]
> > I also just hit this with the linux package.  On some architectures it
> > builds kernels with and without the PREEMPT_RT patches.  I found that a
> > dependency list generated from a PREEMPT_RT build may be reused for a
> > standard build; this caused a build failure because the patched source
> > directory had not yet been created.
> > 
> > The two commands are:
> > 
> >   gcc -Wp,-MD,scripts/genksyms/.parse.tab.o.d -Iscripts/genksyms -Wall 
> > -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer 
> > -std=gnu89  -I/build/linux-4.9.10/scripts/genksyms -c -o 
> > scripts/genksyms/parse.tab.o scripts/genksyms/parse.tab.c
> >   gcc -Wp,-MD,scripts/genksyms/.parse.tab.o.d -Iscripts/genksyms -Wall 
> > -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer 
> > -std=gnu89  -I/build/linux-4.9.10/debian/build/source_rt/scripts/genksyms 
> > -c -o scripts/genksyms/parse.tab.o scripts/genksyms/parse.tab.c
> 
> [...]
> 
> By the way, these two commands are run with different working
> directories.  At first glance the documentation seems to say that the
> working directory is included in the hash by default, but actually it's
> only included when generating debug info and there's no debug prefix
> map.

I've also found that disabling direct mode (CCACHE_NODIRECT=1) is a
workaround, at least in this case.

The problem seems to be that a direct mode manifest contains a hash of
the source and object files, but not any other associated output files.
  It seems to be assumed that if the object files are identical then so
any other output files will also be identical, and that's not the case.

I'm attaching a patch that adds a test case for this bug.

However, having checked upstream, I've now verified that upstream
version 3.3.4 fixes the bug (at least, it passes this test case).  This
appears to have only bug fixes and documentation improvements, so I
think it should be eligible for a freeze exception.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.
Author: Ben Hutchings 
Description: Add test case for direct mode and extra output files
Bug-Debian: https://bugs.debian.org/853834

--- a/test.sh
+++ b/test.sh
@@ -2231,6 +2231,27 @@ EOF
 if [ -n "$data" ]; then
 test_failed "$manifest contained ignored header: $data"
 fi
+
+# -
+TEST "Identical source and object files, different dependencies"
+
+mkdir -p a/include b/include
+echo '#include "header.h"' > a/source.c
+backdate a/include/header.h
+ln a/source.c b/source.c
+ln a/include/header.h b/include/header.h
+
+(cd a && $CCACHE_COMPILE -MD -I$PWD/include -c source.c)
+(cd b && $CCACHE_COMPILE -MD -I$PWD/include -c source.c)
+expect_equal_object_files a/source.o b/source.o
+if cmp -s a/source.d b/source.d; then
+	test_failed "Dependencies unexpectedly identical"
+fi
+(cd a && $CCACHE_COMPILE -MD -I$PWD/include -c source.c)
+expect_equal_object_files a/source.o b/source.o
+if cmp -s a/source.d b/source.d; then
+	test_failed "Wrong dependencies restored from cache"
+fi
 }
 
 # =


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

Bug#855431: po4a does not fail on broken PO files

[Robert Luberda]

Package: po4a
Version: 0.47-2
Severity: normal

Hi,

po4a (or actually po4a-translate I guess) does not check if msgid and msgstr 
either both end, or both do not end with a new line character. 

This might lead to an incorrectly translated documentation. Please see the 
attached example of a very simple testman.1 that is displayed as:

  testman(1)General Commands Manual   testman(1)

 1.
 Item 1

 2.
 Item 2

  testman(1)

Running po4a on the attached po4a.cfg file generates testman.en.1 that
man displays as following:

  testtman(1)   General Commands Manual   testman(1)

 1.
 Item 1.IP 2.
 Item 2

  testman(1)

When the '-v' option is used, po4a shows errors from msgmft:

  testman.en.po:35: 'msgid' and 'msgstr' entries do not both end with '\n'
  testman.en.po:47: 'msgid' and 'msgstr' entries do not both end with '\n'
  msgfmt: found 2 fatal errors

but still generates the translated document.


It would be nice if po4a (with or without the '-v' option) could fail in
such a case to make the tranaslator or maintainer aware of the issue.


Rgards,
robert


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

Kernel: Linux 4.9.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages po4a depends on:
ii  gettext   0.19.8.1-2
ii  libsgmls-perl 1.03ii-36
ii  opensp1.5.2-13
ii  perl  5.24.1-1
ii  perl-modules-5.24 [perl-modules]  5.24.1-1

Versions of packages po4a recommends:
ii  liblocale-gettext-perl 1.07-3+b1
ii  libterm-readkey-perl   2.37-1
ii  libtext-wrapi18n-perl  0.06-7.1
ii  libunicode-linebreak-perl  0.0.20160702-1+b1

po4a suggests no packages.

-- no debconf information
.TH testman 1 
.IP 1.
 Item 1
.IP 2.
 Item 2
[po4a_langs] en
[po4a_paths] testman.pot $lang:testman.$lang.po
[type:man] testman.1 $lang:testman.$lang.1 
# English translations for PACKAGE package
# Copyright (C) 2017 Free Software Foundation, Inc.
# This file is distributed under the same license as the PACKAGE package.
# Automatically generated, 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2017-02-17 23:56+0100\n"
"PO-Revision-Date: 2017-02-17 23:30+0100\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: en\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=ASCII\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. type: TH
#: testman.1:1
#, no-wrap
msgid "testman"
msgstr "testman"

#. type: IP
#: testman.1:2
#, no-wrap
msgid "1."
msgstr "1."

#. type: Plain text
#: testman.1:4
#, no-wrap
msgid " Item 1\n"
msgstr " Item 1"

#. type: IP
#: testman.1:4
#, no-wrap
msgid "2."
msgstr "2."

#. type: Plain text
#: testman.1:5
#, no-wrap
msgid " Item 2\n"
msgstr " Item 2"

Bug#854494: execnet: FTBFS randomly (failing tests)

[Rebecca N. Palmer]

There's actually at least two different tests that sometimes fail: the 
other is ( 
https://people.debian.org/~sanvila/build-logs/execnet/execnet_1.4.1-3_amd64-20170207T152032Z 
):


=== FAILURES 
===
___ TestMakegateway.test_popen_nice 



self = 
makegateway = >

@pytest.mark.skipif("not hasattr(os, 'nice')")
def test_popen_nice(self, makegateway):
gw = makegateway("popen")

def getnice(channel):
import os
if hasattr(os, 'nice'):
channel.send(os.nice(0))
else:
channel.send(None)
remotenice = gw.remote_exec(getnice).receive()
gw.exit()
if remotenice is not None:
gw = makegateway("popen//nice=5")
remotenice2 = gw.remote_exec(getnice).receive()
>   assert remotenice2 == remotenice + 5
E   assert 0 == (0 + 5)

testing/test_xspec.py:136: AssertionError
 pytest-warning summary 



If they are single-CPU-only problems, a potential workaround (warning: 
untested) is
@pytest.mark.skipif(len(os.sched_getaffinity(0))==1,"unreliable on 
single-CPU systems")

Bug#855429: unblock: python-irc/8.5.3+dfsg-4

[Ben Finney]

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

Please unblock package python-irc.

Version “8.5.3+dfsg-4” resolves bug#854539 by patching some unit tests.

unblock python-irc/8.5.3+dfsg-4

-- 
 \   “Nothing exists except atoms and empty space; everything else |
  `\  is opinion.” —Democritus |
_o__)  |
Ben Finney 
diff -Nru python-irc-8.5.3+dfsg/debian/changelog 
python-irc-8.5.3+dfsg/debian/changelog
--- python-irc-8.5.3+dfsg/debian/changelog  2016-12-29 08:41:09.0 
+1100
+++ python-irc-8.5.3+dfsg/debian/changelog  2017-02-18 06:48:31.0 
+1100
@@ -1,3 +1,11 @@
+python-irc (8.5.3+dfsg-4) unstable; urgency=medium
+
+  * The “Faisal Arefin Dipan” release.
+  * Patch the unit tests to use a fake system clock.
+Closes: bug#854539.
+
+ -- Ben Finney   Sat, 18 Feb 2017 06:48:31 +1100
+
 python-irc (8.5.3+dfsg-3) unstable; urgency=medium
 
   * The “Mukto-Mona” release.
diff -Nru python-irc-8.5.3+dfsg/debian/patches/02-fake-clock-for-tests.patch 
python-irc-8.5.3+dfsg/debian/patches/02-fake-clock-for-tests.patch
--- python-irc-8.5.3+dfsg/debian/patches/02-fake-clock-for-tests.patch  
1970-01-01 10:00:00.0 +1000
+++ python-irc-8.5.3+dfsg/debian/patches/02-fake-clock-for-tests.patch  
2017-02-18 06:48:31.0 +1100
@@ -0,0 +1,57 @@
+Description: Use a fake system clock for unit tests.
+ .
+ This removes a non-deterministic dependency on the real system clock.
+Bug-Debian: http://bugs.debian.org/854539
+Author: Ben Finney 
+Last-Update: 2017-02-18
+
+
+diff --git i/irc/tests/test_client.py w/irc/tests/test_client.py
+index 1e2a8ddb..fd6fb9bf 100644
+--- i/irc/tests/test_client.py
 w/irc/tests/test_client.py
+@@ -44,6 +44,44 @@ class TestHandlers(object):
+   assert not handler1 < handler2
+   assert not handler2 < handler1
+ 
++
++class FakeClock(object):
++  """ A fake clock that is under control of test cases. """
++
++  _default_initial_seconds = 145000.0
++  _default_tick_duration = 0.0005
++
++  def __init__(
++  self,
++  seconds=_default_initial_seconds,
++  tick_duration=_default_tick_duration,
++  ):
++  self._tick_duration = tick_duration
++  self.reset(seconds)
++
++  def reset(self, seconds):
++  """ Reset the clock time to `seconds`. """
++  self._seconds = seconds
++
++  def advance(self, seconds):
++  """ Advance the clock by `seconds`. """
++  self._seconds += max(0, seconds)
++
++  def tick(self):
++  """ Advance the clock by its tick duration. """
++  self.advance(self._tick_duration)
++
++  def time(self):
++  """ Get the current time, as seconds since epoch. """
++  self.tick()
++  return self._seconds
++
++
++fake_clock = FakeClock()
++
++
++@mock.patch.object(time, 'time', new=fake_clock.time)
++@mock.patch.object(time, 'sleep', new=fake_clock.advance)
+ class TestThrottler(object):
+   def test_function_throttled(self):
+   """
diff -Nru python-irc-8.5.3+dfsg/debian/patches/series 
python-irc-8.5.3+dfsg/debian/patches/series
--- python-irc-8.5.3+dfsg/debian/patches/series 2016-12-29 08:41:09.0 
+1100
+++ python-irc-8.5.3+dfsg/debian/patches/series 2017-02-18 06:48:31.0 
+1100
@@ -1 +1,2 @@
 01-setup.patch
+02-fake-clock-for-tests.patch


signature.asc
Description: PGP signature

Bug#855430: examl: FTBFS on non-x86: unrecognized command line option ‘-msse3’

[Aaron M. Ucko]

Source: examl
Version: 3.0.18-1
Severity: important
Justification: fails to build from source

Builds of examl for non-x86 architectures have been failing with

  gcc: error: unrecognized command line option ‘-msse3’

or similar errors.  Please remove this flag altogether, as it limits
the portability of the resulting binaries even on x86.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#834514: [PATCH 1/6] use --pinentry-mode loopback for 2.1.x and later

[Daniel Kahn Gillmor]

If the user specifies an explicit passphrase rather than relying on
the gpg-agent for granting access, then we should try to pass the
passphrase to the agent.  In 2.1.x, passing a passphrase to the agent
is done with "--pinentry-mode loopback", so we add that here.
---
 gnupg.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnupg.py b/gnupg.py
index 1d32a48..bc9d4a8 100644
--- a/gnupg.py
+++ b/gnupg.py
@@ -783,6 +783,8 @@ class GPG(object):
 cmd.extend(['--secret-keyring', no_quote(fn)])
 if passphrase:
 cmd.extend(['--batch', '--passphrase-fd', '0'])
+if self.version >= (2,1):
+cmd.extend(['--pinentry-mode', 'loopback'])
 if self.use_agent:  # pragma: no cover
 cmd.append('--use-agent')
 if self.options:
-- 
2.11.0

Bug#834514: [PATCH 3/6] always use --fixed-list-mode and --batch and --with-colons

[Daniel Kahn Gillmor]

gpg is being invoked programmatically, so it should always use
--batch.

--fixed-list-mode is also the standard, since we have no intention of
ever using the non-fixed mode and modern versions of GnuPG don't even
have the option of doing so.

we also want --with-colons: for any output, are going to be parsing it
directly, so we don't want the human-readable form.
---
 gnupg.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/gnupg.py b/gnupg.py
index 6d820f1..71f5500 100644
--- a/gnupg.py
+++ b/gnupg.py
@@ -733,6 +733,7 @@ class GPG(object):
 a passphrase will be sent to GPG, else False.
 """
 cmd = [self.gpgbinary, '--status-fd', '2', '--no-tty']
+cmd.extend(['--fixed-list-mode', '--batch', '--with-colons'])
 if self.gnupghome:
 cmd.extend(['--homedir',  no_quote(self.gnupghome)])
 if self.keyring:
@@ -743,7 +744,7 @@ class GPG(object):
 for fn in self.secret_keyring:
 cmd.extend(['--secret-keyring', no_quote(fn)])
 if passphrase:
-cmd.extend(['--batch', '--passphrase-fd', '0'])
+cmd.extend(['--passphrase-fd', '0'])
 if self.version >= (2,1):
 cmd.extend(['--pinentry-mode', 'loopback'])
 if self.use_agent:  # pragma: no cover
@@ -874,7 +875,7 @@ class GPG(object):
 "If writing to a file which exists, avoid a confirmation message."
 if os.path.exists(output):
 # We need to avoid an overwrite confirmation message
-args.extend(['--batch', '--yes'])
+args.extend(['--yes'])
 args.extend(['--output', no_quote(output)])
 
 def sign_file(self, file, keyid=None, passphrase=None, clearsign=True,
@@ -1069,7 +1070,7 @@ class GPG(object):
 fingerprints = [no_quote(s) for s in fingerprints]
 else:
 fingerprints = [no_quote(fingerprints)]
-args = ['--batch', '--delete-%s' % which]
+args = ['--delete-%s' % which]
 args.extend(fingerprints)
 result = self.result_map['delete'](self)
 p = self._open_subprocess(args)
@@ -1148,9 +1149,8 @@ class GPG(object):
 which='keys'
 if secret:
 which='secret-keys'
-args = ['--list-%s' % which, '--fixed-list-mode',
-'--fingerprint', '--fingerprint',   # get subkey FPs, too
-'--with-colons']
+args = ['--list-%s' % which,
+'--fingerprint', '--fingerprint'] # get subkey FPs, too
 if keys:
 if isinstance(keys, string_types):
 keys = [keys]
@@ -1188,7 +1188,7 @@ class GPG(object):
 query = query.strip()
 if HEX_DIGITS_RE.match(query):
 query = '0x' + query
-args = ['--fixed-list-mode', '--fingerprint', '--with-colons',
+args = ['--fingerprint',
 '--keyserver', no_quote(keyserver), '--search-keys',
 no_quote(query)]
 p = self._open_subprocess(args)
@@ -1225,7 +1225,7 @@ class GPG(object):
 >>> assert not result
 
 """
-args = ["--gen-key", "--batch"]
+args = ["--gen-key"]
 result = self.result_map['generate'](self)
 f = _make_binary_stream(input, self.encoding)
 self._handle_io(args, f, result, binary=True)
-- 
2.11.0

Bug#834514: [PATCH 4/6] Avoid risky scan_keys() operation on modern GnuPG.

[Daniel Kahn Gillmor]

Please see comments from Werner Koch at:

https://bugs.gnupg.org/gnupg/issue2942
---
 gnupg.py | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/gnupg.py b/gnupg.py
index 71f5500..189fa7c 100644
--- a/gnupg.py
+++ b/gnupg.py
@@ -1163,10 +1163,19 @@ class GPG(object):
 List details of an ascii armored or binary key file
 without first importing it to the local keyring.
 
-The function achieves this by running:
+The function achieves this on modern GnuPG by running:
+
+$ gpg --dry-run --import-options import-show --import
+
+On older versions, it does the *much* riskier:
+
 $ gpg --with-fingerprint --with-colons filename
 """
-args = ['--with-fingerprint', '--with-colons']
+if self.version >= (2, 1, 14):
+args = ['--dry-run', '--import-options', 'import-show', '--import']
+else:
+logger.warning('Warning! trying to list packets, but if the file 
is not a keyring, might accidentally decrypt')
+args = ['--with-fingerprint']
 args.append(no_quote(filename))
 p = self._open_subprocess(args)
 return self._get_list_output(p, 'scan')
-- 
2.11.0

Bug#834514: [PATCH 6/6] Switch back to gpg itself (away from gpg1)

[Daniel Kahn Gillmor]

The "modern" GnuPG suite (2.1.x) has the most developer and maintainer
support. Debian should not rely on the "classic" suite (1.4.x, aka
gnupg1) where we can avoid it.  With the preceding patch series, we
can avoid all dependencies on gnupg1.  This patch adjusts the debian
packaging accordingly.
---
 debian/bin/gpg  | 7 +++
 debian/bin/gpg1 | 7 ---
 debian/control  | 6 +++---
 debian/rules| 2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)
 create mode 100644 debian/bin/gpg
 delete mode 100755 debian/bin/gpg1

diff --git a/debian/bin/gpg b/debian/bin/gpg
new file mode 100644
index 000..8c3206d
--- /dev/null
+++ b/debian/bin/gpg
@@ -0,0 +1,7 @@
+#!/bin/sh
+GPG=`which -a gpg | uniq | tail -n+2 | head -n1`
+if echo "$*" | grep -q gen-key; then
+exec "$GPG" --debug-quick-random "$@"
+else
+exec "$GPG" "$@"
+fi
diff --git a/debian/bin/gpg1 b/debian/bin/gpg1
deleted file mode 100755
index 9a41f14..000
--- a/debian/bin/gpg1
+++ /dev/null
@@ -1,7 +0,0 @@
-#!/bin/sh
-GPG=`which -a gpg1 | uniq | tail -n+2 | head -n1`
-if echo "$*" | grep -q gen-key; then
-exec "$GPG" --quick-random "$@"
-else
-exec "$GPG" "$@"
-fi
diff --git a/debian/control b/debian/control
index 055f263..3669a30 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Maintainer: Elena Grandi 
 Uploaders: Debian Python Modules Team 

 Section: python
 Priority: optional
-Build-Depends: python-all (>= 2.6.6-3~), python3-all (>= 3.1.2-7~), debhelper 
(>= 9), dh-python, gnupg1
+Build-Depends: python-all (>= 2.6.6-3~), python3-all (>= 3.1.2-7~), debhelper 
(>= 9), dh-python, gnupg
 Standards-Version: 3.9.8
 Homepage: https://bitbucket.org/vinay.sajip/python-gnupg
 Vcs-Git: 
https://anonscm.debian.org/git/python-modules/packages/python-gnupg.git
@@ -13,7 +13,7 @@ X-Python3-Version: >= 3.2
 
 Package: python-gnupg
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, gnupg1
+Depends: ${misc:Depends}, ${python:Depends}, gnupg
 Description: Python wrapper for the GNU Privacy Guard (Python 2.x)
  Python-GnuPG allows easy and well-documented access to basic GnuPG
  functionality such as generating and managing keys, encrypting and
@@ -23,7 +23,7 @@ Description: Python wrapper for the GNU Privacy Guard (Python 
2.x)
 
 Package: python3-gnupg
 Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}, gnupg1
+Depends: ${misc:Depends}, ${python3:Depends}, gnupg
 Description: Python wrapper for the GNU Privacy Guard (Python 3.x)
  Python-GnuPG allows easy and well-documented access to basic GnuPG
  functionality such as generating and managing keys, encrypting and
diff --git a/debian/rules b/debian/rules
index d484d82..51d77f9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ export PYBUILD_NAME=gnupg
 
 override_dh_auto_test:
 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
-   chmod 755 $(CURDIR)/debian/bin/gpg1
+   chmod 755 $(CURDIR)/debian/bin/gpg
set -ex; for py in $(shell pyversions -r -v); do \
PATH=$(CURDIR)/debian/bin:$$PATH 
PYTHONPATH=$(CURDIR)/build/lib.*-$$py python$$py test_gnupg.py ;\
done
-- 
2.11.0

Bug#834514: [PATCH 2/6] Avoid exceptions on unknown status keywords

[Daniel Kahn Gillmor]

in upstream GnuPG, doc/DETAILS says:

-
* Format of the --status-fd output

  Every line is prefixed with "[GNUPG:] ", followed by a keyword with
  the type of the status line and some arguments depending on the type
  (maybe none); an application should always be willing to ignore
  unknown keywords that may be emitted by future versions of GnuPG.
  Also, new versions of GnuPG may add arguments to existing keywords.
  Any additional arguments should be ignored for forward-compatibility.
-

This set of changes ensures that any time we're looking for status
messages it is only to look for them positively -- if we encounter an
unknown or other status message, we'll just let it slide by without an
error.
---
 gnupg.py | 47 ---
 1 file changed, 4 insertions(+), 43 deletions(-)

diff --git a/gnupg.py b/gnupg.py
index bc9d4a8..6d820f1 100644
--- a/gnupg.py
+++ b/gnupg.py
@@ -240,14 +240,6 @@ class Verify(object):
 if key in self.TRUST_LEVELS:
 self.trust_text = key
 self.trust_level = self.TRUST_LEVELS[key]
-elif key in ("RSA_OR_IDEA", "NODATA", "IMPORT_RES", "PLAINTEXT",
- "PLAINTEXT_LENGTH", "POLICY_URL", "DECRYPTION_INFO",
- "DECRYPTION_OKAY", "INV_SGNR", "FILE_START", "FILE_ERROR",
- "FILE_DONE", "PKA_TRUST_GOOD", "PKA_TRUST_BAD", "BADMDC",
- "GOODMDC", "NO_SGNR", "NOTATION_NAME", "NOTATION_DATA",
- "PROGRESS", "PINENTRY_LAUNCHED", "NEWSIG",
- "KEY_CONSIDERED"):
-pass
 elif key == "BADSIG":  # pragma: no cover
 self.valid = False
 self.status = 'signature bad'
@@ -286,12 +278,6 @@ class Verify(object):
 self.valid = False
 self.key_id = value
 self.status = 'no public key'
-elif key in ("KEYEXPIRED", "SIGEXPIRED", "KEYREVOKED"):  # pragma: no 
cover
-# these are useless in verify, since they are spit out for any
-# pub/subkeys on the key, not just the one doing the signing.
-# if we want to check for signatures with expired key,
-# the relevant flag is EXPKEYSIG or REVKEYSIG.
-pass
 elif key in ("EXPKEYSIG", "REVKEYSIG"):  # pragma: no cover
 # signed with expired or revoked key
 self.valid = False
@@ -309,8 +295,6 @@ class Verify(object):
 else:
 # N.B. there might be other reasons
 self.status = 'incorrect passphrase'
-else:
-raise ValueError("Unknown status message: %r" % key)
 
 class ImportResult(object):
 "Handle status messages for --import"
@@ -385,8 +369,6 @@ class ImportResult(object):
 elif key == "SIGEXPIRED":  # pragma: no cover
 self.results.append({'fingerprint': None,
 'problem': '0', 'text': 'Signature expired'})
-else:  # pragma: no cover
-raise ValueError("Unknown status message: %r" % key)
 
 def summary(self):
 l = []
@@ -552,14 +534,8 @@ class Crypt(Verify, TextHandler):
 __bool__ = __nonzero__
 
 def handle_status(self, key, value):
-if key in ("ENC_TO", "USERID_HINT", "GOODMDC", "END_DECRYPTION",
-   "BEGIN_SIGNING", "NO_SECKEY", "ERROR", "NODATA", "PROGRESS",
-   "CARDCTRL", "BADMDC", "SC_OP_FAILURE", "SC_OP_SUCCESS",
-   "PINENTRY_LAUNCHED"):
-# in the case of ERROR, this is because a more specific error
-# message will have come first
-if key == "NODATA":
-self.status = "no data was provided"
+if key == "NODATA":
+self.status = "no data was provided"
 elif key in ("NEED_PASSPHRASE", "BAD_PASSPHRASE", "GOOD_PASSPHRASE",
  "MISSING_PASSPHRASE", "DECRYPTION_FAILED",
  "KEY_NOT_CREATED", "NEED_PASSPHRASE_PIN"):
@@ -604,13 +580,8 @@ class GenKey(object):
 return self.fingerprint or ''
 
 def handle_status(self, key, value):
-if key in ("PROGRESS", "GOOD_PASSPHRASE", "NODATA", "KEY_NOT_CREATED",
-   "PINENTRY_LAUNCHED"):
-pass
-elif key == "KEY_CREATED":
+if key == "KEY_CREATED":
 (self.type,self.fingerprint) = value.split()
-else:
-raise ValueError("Unknown status message: %r" % key)
 
 class ExportResult(GenKey):
 """Handle status messages for --export[-secret-key].
@@ -643,8 +614,6 @@ class DeleteResult(object):
 if key == "DELETE_PROBLEM":  # pragma: no cover
 self.status = self.problem_reason.get(value,
   "Unknown error: %r" % value)
-else:  # pragma: no cover
-raise ValueError("Unknown status message: %r" % key)
 
 def __nonzero__(self):
 return self.status == 'ok'
@@ -666,13 +6

Bug#834514: [PATCH 5/6] Avoid spurious test suite failures due to socket removal race.

[Daniel Kahn Gillmor]

When gpg-agent notices that its primary socket has been removed, it
shuts down.  When it shuts down, it closes and unlinks its other
sockets as well.

These rmtree invocations look like they might be getting the list of
files to delete and then unlinking them one at a time.

The result is a lot of errors like:

File "/home/dkg/src/python-gnupg/python-gnupg/gnupg.py", line 1157, in 
gnupg.GPG.list_keys
Failed example:
shutil.rmtree("keys")
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.5/doctest.py", line 1321, in __run
compileflags, 1), test.globs)
  File "", line 1, in 
shutil.rmtree("keys")
  File "/usr/lib/python3.5/shutil.py", line 480, in rmtree
_rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.5/shutil.py", line 438, in _rmtree_safe_fd
onerror(os.unlink, fullname, sys.exc_info())
  File "/usr/lib/python3.5/shutil.py", line 436, in _rmtree_safe_fd
os.unlink(name, dir_fd=topfd)
FileNotFoundError: [Errno 2] No such file or directory: 'S.gpg-agent.extra'

Simply making rmtree ignore errors (as this patch does) is enough to
make the tests pass cleanly with GnuPG 2.1.18-6 and Python 3.5.3-1 on
Debian stretch (testing).
---
 gnupg.py  | 8 
 test_gnupg.py | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gnupg.py b/gnupg.py
index 189fa7c..d1285b1 100644
--- a/gnupg.py
+++ b/gnupg.py
@@ -1027,7 +1027,7 @@ class GPG(object):
 """Import a key from a keyserver
 
 >>> import shutil
->>> shutil.rmtree("keys")
+>>> shutil.rmtree("keys", ignore_errors=True)
 >>> gpg = GPG(gnupghome="keys")
 >>> os.chmod('keys', 0x1C0)
 >>> result = gpg.recv_keys('keyserver.ubuntu.com', '92905378')  # 
doctest: +SKIP
@@ -1130,7 +1130,7 @@ class GPG(object):
 """ list the keys currently in the keyring
 
 >>> import shutil
->>> shutil.rmtree("keys")
+>>> shutil.rmtree("keys", ignore_errors=True)
 >>> gpg = GPG(gnupghome="keys")
 >>> input = gpg.gen_key_input()
 >>> result = gpg.gen_key(input)
@@ -1184,7 +1184,7 @@ class GPG(object):
 """ search keyserver by query (using --search-keys option)
 
 >>> import shutil
->>> shutil.rmtree('keys')
+>>> shutil.rmtree('keys', ignore_errors=True)
 >>> gpg = GPG(gnupghome='keys')
 >>> os.chmod('keys', 0x1C0)
 >>> result = gpg.search_keys('')  # doctest: 
+SKIP
@@ -1329,7 +1329,7 @@ class GPG(object):
 
 >>> import shutil
 >>> if os.path.exists("keys"):
-... shutil.rmtree("keys")
+... shutil.rmtree("keys", ignore_errors=True)
 >>> gpg = GPG(gnupghome="keys")
 >>> input = gpg.gen_key_input(passphrase='foo')
 >>> result = gpg.gen_key(input)
diff --git a/test_gnupg.py b/test_gnupg.py
index 806a7bf..8c6cf2b 100644
--- a/test_gnupg.py
+++ b/test_gnupg.py
@@ -153,7 +153,7 @@ class GPGTestCase(unittest.TestCase):
 if os.path.exists(hd):
 self.assertTrue(os.path.isdir(hd),
 "Not a directory: %s" % hd)
-shutil.rmtree(hd)
+shutil.rmtree(hd, ignore_errors=True)
 self.homedir = hd
 self.gpg = gpg = gnupg.GPG(gnupghome=hd, gpgbinary=GPGBINARY)
 v = gpg.version
@@ -691,7 +691,7 @@ class GPGTestCase(unittest.TestCase):
 decfname = os.path.join(d, 'decrypted file')
 self.do_file_encryption_and_decryption(encfname, decfname)
 finally:
-shutil.rmtree(d)
+shutil.rmtree(d, ignore_errors=True)
 logger.debug("test_filename_with_spaces ends")
 
 @unittest.skip('requires network')
@@ -727,7 +727,7 @@ class GPGTestCase(unittest.TestCase):
 files = os.listdir(workdir)
 self.assertEqual(files, ["'ab?'"])
 finally:
-shutil.rmtree(workdir)
+shutil.rmtree(workdir, ignore_errors=True)
 
 def disabled_test_signing_with_uid(self):  # pragma: no cover
 "Test that signing with uids works. On hold for now."
-- 
2.11.0

Bug#855428: not architecture aware

[積丹尼 Dan Jacobson]

Package: apt-show-versions
Version: 0.22.7

Apparently apt-show-versions is looking into different architectures'
archives which happen to be on the same disk. It shouldn't.

# set libgdk-pixbuf2.0-common
# apt-show-versions -i
# apt-show-versions -a $@
libgdk-pixbuf2.0-common:all 2.36.5-2 install ok installed
No stable version
libgdk-pixbuf2.0-common:all 2.36.4-1 unstable free.nchc.org.tw
libgdk-pixbuf2.0-common:all 2.36.5-1 experimental free.nchc.org.tw
libgdk-pixbuf2.0-common:all 2.36.5-2 newer than version in archive
# apt-cache policy $@
libgdk-pixbuf2.0-common:
  Installed: 2.36.5-2
  Candidate: 2.36.5-2
  Version table:
 *** 2.36.5-2 500
500 http://free.nchc.org.tw/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
# grep -l $@ *Packages
free.nchc.org.tw_debian_dists_experimental_main_binary-i386_Packages
free.nchc.org.tw_debian_dists_unstable_main_binary-amd64_Packages
free.nchc.org.tw_debian_dists_unstable_main_binary-i386_Packages
# for i in *Packages; do echo $i ; grep-dctrl -P $@ -s version $i; done
free.nchc.org.tw_debian_dists_experimental_contrib_binary-amd64_Packages 
free.nchc.org.tw_debian_dists_experimental_contrib_binary-i386_Packages 
free.nchc.org.tw_debian_dists_experimental_main_binary-amd64_Packages 
free.nchc.org.tw_debian_dists_experimental_main_binary-i386_Packages 
Version: 2.36.5-1
free.nchc.org.tw_debian_dists_experimental_non-free_binary-amd64_Packages 
free.nchc.org.tw_debian_dists_experimental_non-free_binary-i386_Packages 
free.nchc.org.tw_debian_dists_unstable_contrib_binary-amd64_Packages 
free.nchc.org.tw_debian_dists_unstable_contrib_binary-i386_Packages 
free.nchc.org.tw_debian_dists_unstable_main_binary-amd64_Packages 
Version: 2.36.5-2
free.nchc.org.tw_debian_dists_unstable_main_binary-i386_Packages 
Version: 2.36.4-1
free.nchc.org.tw_debian_dists_unstable_non-free_binary-amd64_Packages 
free.nchc.org.tw_debian_dists_unstable_non-free_binary-i386_Packages 

This explains the many
$ apt-show-versions|grep -c 'i386 not installed'
1214
vs. useful
$ apt-show-versions|grep -cv 'i386 not installed'
1724

Bug#853834: Ccache storing and restoring file paths that may no longer be correct

[Joel Rosdahl]

Hi,

Upstream release 3.3.4 contains a fix for this problem. I uploaded a Debian
package of it to unstable just now and will look into requesting a freeze
unblock.

Regards,
-- Joel

Bug#855427: quicktun: Does not work

[cloos]

Package: quicktun
Version: 2.2.6-1
Severity: grave
Justification: renders package unusable

As packaged, this is unusable.

It did not depend on daemon, but the scripts rely on that.

/etc/network/if-up.d/quicktun calls quicktun.debian but that is not installed.
That script should call /usr/sbin/quicktun instead.

Even after editing if-up.d/quicktun and installing daemon nothing works.

It is a great idea, but plean make it work.

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

Kernel: Linux 4.5.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: sysvinit (via /sbin/init)

Versions of packages quicktun depends on:
ii  libc62.24-9
ii  libsodium18  1.0.11-1

quicktun recommends no packages.

quicktun suggests no packages.

-- Configuration Files:
/etc/network/if-up.d/quicktun changed [not included]

-- no debconf information

Bug#855426: fritzing-parts: please make the build reproducible

[Chris Lamb]

Source: fritzing-parts
Version: 0.9.3b-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/fzp2copyright  2017-02-18 10:18:03.162168309 +1300
--- b/debian/fzp2copyright  2017-02-18 10:22:48.202174594 +1300
@@ -9,6 +9,7 @@
 for file in files:
 if file.endswith(".fzp"):
 result.append(os.path.join(root, file))
+result.sort()
 return result
 
 class Author:

Bug#855425: Purge-Unused does not act for Breaks

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.5-1
Severity: minor

Despite
APT::Default-Release "experimental";
APT::AutoRemove::RecommendsImportant false;
APT::AutoRemove::SuggestsImportant false;
APT::Cache::AllVersions false;
APT::Clean-Installed false;
APT::Get::Fix-Missing true;
APT::Get::List-Cleanup false;
APT::Get::Purge true;
APT::Install-Recommends false;
APT::Keep-Downloaded-Packages true;
Aptitude::Purge-Unused true;
if the user has obsolete package android-tools-adb installed,
and then installs adb, which breaks it, when android-tools-adb is
removed, it is not also purged.

Bug#855017: linux-image-4.9.0-1-marvell: eth1 not detected/available on QNAP TS-419pII

[gmbh]

On 17.02.2017 02:57, Ben Hutchings wrote:
> This seems to be a bug in the device tree for the TS419 - it doesn't
> quite match the board code it replaced.  Should be easy to fix.

After applying patch, eth1 is recognized, but it behaves strange. It
looks like it is using a correct MAC during DHCP phase, but after
getting IP from DHCP it clones(?) eth0 MAC.

---

Here is an output from flashing:

kirkwood-qnap: machine: QNAP TS419 family
Using DTB: kirkwood-ts419-6282.dtb
Installing /usr/lib/linux-image-4.9.0-1-marvell/kirkwood-ts419-6282.dtb
into /boot/dtbs/4.9.0-1-marvell/kirkwood-ts419-6282.dtb
Taking backup of kirkwood-ts419-6282.dtb.
Installing new kirkwood-ts419-6282.dtb.
Installing /usr/lib/linux-image-4.9.0-1-marvell/kirkwood-ts419-6282.dtb
into /boot/dtbs/4.9.0-1-marvell/kirkwood-ts419-6282.dtb
Taking backup of kirkwood-ts419-6282.dtb.
Installing new kirkwood-ts419-6282.dtb.
flash-kernel: installing version 4.9.0-1-marvell
flash-kernel: appending
/usr/lib/linux-image-4.9.0-1-marvell/kirkwood-ts419-6282.dtb to kernel
Generating kernel u-boot image... done.
Flashing kernel (using 2056012/2097152 bytes)... done.
Flashing initramfs (using 4777366/9437184 bytes)... done.

---

Here is an relevant output from dmesg:

[0.045321] [Firmware Info]:
/ocp@f100/ethernet-controller@72000/ethernet0-port@0:
local-mac-address is not set
[0.045412] [Firmware Info]:
/ocp@f100/ethernet-controller@76000/ethernet1-port@0:
local-mac-address is not set
[   60.981436] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[   61.917900] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
address 00:08:9b:cb:ae:be
[   62.441157] mv643xx_eth_port mv643xx_eth_port.1 eth1: port 0 with MAC
address 00:08:9b:cb:ae:bf

---

Configuration /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The secondary network interface
allow-hotplug eth1
iface eth1 inet dhcp

---

ifconfig output, note that MAC and IP addresses are correct:

eth0: flags=4163  mtu 1500
inet 192.168.1.100  netmask 255.255.255.0  broadcast 192.168.1.255
inet6 fe80::208:9bff:fecb:aebe  prefixlen 64  scopeid 0x20
ether 00:08:9b:cb:ae:be  txqueuelen 1000  (Ethernet)
RX packets 1693441  bytes 2370511659 (2.2 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 386537  bytes 63194040 (60.2 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 41

eth1: flags=4163  mtu 1500
inet 192.168.1.101  netmask 255.255.255.0  broadcast 192.168.1.255
inet6 fe80::208:9bff:fecb:aebf  prefixlen 64  scopeid 0x20
ether 00:08:9b:cb:ae:bf  txqueuelen 1000  (Ethernet)
RX packets 412  bytes 58481 (57.1 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 48  bytes 4776 (4.6 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 42

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1  (Local Loopback)
RX packets 376  bytes 24942 (24.3 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 376  bytes 24942 (24.3 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

---

And here is an output from arp on router:

IP address   HW type Flags   HW addressMask
Device
192.168.1.1010x1 0x2 00:08:9b:cb:ae:be *
br-lan
192.168.1.1000x1 0x2 00:08:9b:cb:ae:be *
br-lan

both IP addresses have same MAC (from eth0).

I'm not sure what is going here...

BTW. Is this .dtsi file responsible for GPIO configuration? I've also
noticed a strange behavior with qcontrol:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795558

Best Regards,
Marek

Bug#853902: icinga-web: Can't locate CGI/Util.pm in @INC during installation

[Florian Schlichting]

Hi,

On Sat, Feb 18, 2017 at 10:08:07AM +1300, Chris Lamb wrote:
> Florian Schlichting wrote:
> 
> > icinga-web needs a Depends: libcgi-pm-perl
> 
> Do you mean Build-Depends?

no, I see it only used in postinst of four of the binary packages built
by src:incinga-web

> Also seems to be missing:
> 
>  - phing

not sure if that's essential, configure contains the line

# Check for phing - not required in normal non-dev installations

>  - php7.0-xsl (the existing php-xsl doesn't seem to install this)

I believe this is #852916 - in unstable, that dependency causes
php7.1-xml to be installed along with php7.0-cli, but that shouldn't
happen in Stretch which doesn't have php7.1

Florian

Bug#855415: installation-reports: Debian-Testing fails to reboot after installation.

[Michael Siemmeister]

On Fri, 17 Feb 2017 14:14:08 -0500 lsore...@csclub.uwaterloo.ca (Lennart 
Sorensen) wrote:
> On Fri, Feb 17, 2017 at 07:14:11PM +0100, Michael Siemmeister wrote:
> > Last week I tried to install Debian in a virtual-box. Currently I use
> > Debian 8.7 for running the virtual-box program. I managed to install
> > Debian stable without any problems. Then I cloned the virtual-box and
> > tried an upgrade to Debian-testing. I think, it worked. After a while
> > I shut down the virtual-machine. When trying to reboot, it did not
> > start properly. I just got some messages like 'Created slice User
> > Slice of Debian-gdm.', 'Starting User Manager ofr UID 117.', and
> > finally 'Started Daily apt activities.'. Then the virtual display just
> > starts blinking. Nothing else happens. After three minutes or so the
> > display freezes.
> > 
> > Then I thought, okay, maybe the virtualbox program has got a bug. So,
> > I downloaded the Debian-Testing-DVD-1 via jigdo-lite and copied it to
> > a USB drive. I tried to install Debian-Testing on an old laptop, a
> > Toshiba Satellite from 2009. Unfortunately I don' remember the exact
> > model number. I had already installed Debian Stable without any
> > problems on that laptop some months ago. The Debian-Testing installer
> > worked fine and finally, it asked me to reboot the PC. After rebooting
> > similar problems occured. There was a message about the graphics card
> > and after 30 seconds the display started blinking. Nothing else
> > happened.
> > 
> > As I have written above these errors only occured with Debian-Testing.
> > Debian-Stable worked fine on Virtualbox and the Toshiba laptop. So, I
> > don't think there are some hardware problems.
> 
> If you are running virtualbox on jessie, that would be version 4.3.36.
> I do find a lot of problems reported with gnome 3 and virtual box 4.x.
> 
> I wonder if virtualbox 5.1.8 in jessie-backports would solve the problem.
> 
> I also wonder if having virtualbox 4.x as host with 5.x guest utilities
> installed could cause problems (I suspect the guest utilities are
> automatically installed and for stretch they would be version 5.x,
> not 4.x).
> 
> After all gnome3 mandates 3D accaleration, and having drivers that don't
> match the hardware (virtualbox in this case) could be a problem.
> 
> -- 
> Len Sorensen
> 
> 
Thanks for your answer, Len!

I am sorry for having caused confusion. Actually, I only wanted to
report a bug for the problems encountered during the installation on the
Toshiba laptop. I know that virtualbox won't be in Debian Stretch, so
therefore I don't want to report this bug. As you can read in the
mailing-list entries I tried it with the latest virtualbox version
without success. Unfortunately, I used Oracle's repository, not the one
in jessie-backports. Actually, I don't know whether or not I am going to
try that. I think I will move to qemu since it is completely open
source.

-Michael

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Samuel Wolf]

@ Allen,
thanks for try the patch.

@ Markus,
thank you for the help.
Can't build tomcat7 at the moment, but guess it will fix my issue as well.

2017-02-17 21:20 GMT+01:00 Allen Hadden :

> > Thanks for confirming that the last revision is not working as expected.
> > Now we are back at the beginning. Could you apply this patch [1] and
> > report back if it resolves your issue please?
>
> Yes!  That fixed it for us.
>
> Sorry again for the run around.
>
> Allen
>

Bug#851304: tomcat8 use 100% cpu time

[Markus Koschany]

On 17.02.2017 22:09, Salvatore Bonaccorso wrote:
> Hi Markus, hi Emmanuel,
> 
> On Mon, Feb 13, 2017 at 10:48:20AM +0100, Markus Koschany wrote:
>> On 13.02.2017 08:34, Moritz Mühlenhoff wrote:
>>> On Sun, Feb 12, 2017 at 09:38:31PM +0100, Markus Koschany wrote:
 Hi,

 a bug was reported against tomcat8 and tomcat7 in Jessie and it seems
 the issue is related to our latest security updates. We would like to
 address this regression as soon as possible because this one can be
 triggered remotely and cause a denial-of-service.

 I have attached the debdiffs for tomcat8 and tomcat7 to this email. I
 will update the changelogs later.
>>>
>>> Thanks, please upload.
>>
>> Thanks. Uploaded.
> 
> Btw, I requested a CVE for this issue and it got assigned
> CVE-2017-6056.

Hi Salvatore,

Thank you. However apparently the fix was not complete. We received two
reports that the server returns 400 errors under certain circumstances. [1]
We need to prepare a regression update and the suggested fix is [2].
Sorry for the inconvenience.

Regards,

Markus


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854551#59
[2]
https://github.com/apache/tomcat80/commit/534d62075f8c03cc3e77f301e53be53acdefd1c9.patch




signature.asc
Description: OpenPGP digital signature

Bug#851304: tomcat8 use 100% cpu time

[Salvatore Bonaccorso]

Hi Markus, hi Emmanuel,

On Mon, Feb 13, 2017 at 10:48:20AM +0100, Markus Koschany wrote:
> On 13.02.2017 08:34, Moritz Mühlenhoff wrote:
> > On Sun, Feb 12, 2017 at 09:38:31PM +0100, Markus Koschany wrote:
> >> Hi,
> >>
> >> a bug was reported against tomcat8 and tomcat7 in Jessie and it seems
> >> the issue is related to our latest security updates. We would like to
> >> address this regression as soon as possible because this one can be
> >> triggered remotely and cause a denial-of-service.
> >>
> >> I have attached the debdiffs for tomcat8 and tomcat7 to this email. I
> >> will update the changelogs later.
> > 
> > Thanks, please upload.
> 
> Thanks. Uploaded.

Btw, I requested a CVE for this issue and it got assigned
CVE-2017-6056.

Regards,
Salvatore

Bug#853902: icinga-web: Can't locate CGI/Util.pm in @INC during installation

[Chris Lamb]

Florian Schlichting wrote:

> icinga-web needs a Depends: libcgi-pm-perl

Do you mean Build-Depends? Also seems to be missing:

 - phing
 - php7.0-xsl (the existing php-xsl doesn't seem to install this)


Regards,

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

Bug#852916: icinga-web: FTBFS: checking if php has xsl module... configure: error: not found

[Florian Schlichting]

Control: tags -1 + sid

As can be seen from the build log, the resolver installs both php7.0 and
php7.1 dependencies (namely php7.1-common and php7.1-xml), resulting in
a php cli environment based on 7.0 that does not have the xml/xsl
modules available. This also happens in my sbuild chroot. It cannot
happen in Stretch, though, because php7.1-xml is only available in
unstable. So this bug does not affect Stretch.

I suspect the cause for this peculiar behaviour of the apt resolver has
to do with the Build-Depends on php-xsl, which is a purely virtual
package currently provided by both php7.0-xml and php7.1-xml. It goes
away when I change the Build-Dependency to php-xml.

Bug#855134: installation-guide: mips related cleanups and updates

[Ben Hutchings]

On Fri, 2017-02-17 at 20:50 +0100, Holger Wansing wrote:
[...]
> Additionally, I would like to propose a changing to the supported archs table,
> which currently looks this (the mips part):
> 
> ├┼──┼──┼──┤
> ││  │MIPS Malta (32 bit)   │4kc-malta 
> │
> │32bit MIPS  │  
> ├──┼──┤
> │(big-endian)│mips  │MIPS Malta (64 bit)   │5kc-malta 
> │
> ││  
> ├──┼──┤
> ││  │Cavium Octeon │octeon
> │
> ├┼──┼──┼──┤
> ││  │MIPS Malta│5kc-malta 
> │
> │64bit MIPS  │  
> ├──┼──┤
> │(little-endian) │mips64el  │Cavium Octeon │octeon
> │
> ││  
> ├──┼──┤
> ││  │Loongson 3
> │loongson-3│
> ├┼──┼──┼──┤
> ││  │MIPS Malta (32 bit)   │4kc-malta 
> │
> ││  
> ├──┼──┤
> │32bit MIPS  │  │MIPS Malta (64 bit)   │5kc-malta 
> │
> │(little-endian) │mipsel
> ├──┼──┤
> ││  │Cavium Octeon │octeon
> │
> ││  
> ├──┼──┤
> ││  │Loongson 3
> │loongson-3│
> ├┼──┼──┼──┤
> 
> 
> I would propose to delete the "Mips Malta (64 bit)" entries from the 32bit 
> MIPS
> lines (mips and mipsel), since they are contained in the "MIPS Malta" entry
> within the 64bit MIPS line.
[...]

There seems to have been some confusion about whether this table lists
kernel or installer flavours.  As this is the installation manual, I
think it makes sense to document the latter.

Not only is there no 5kc-malta installer flavour for mips or mipsel,
there is also no armmp-lpae flavour of the installer for armel.  Please
delete that as well.

Also, the versatile flavour for armel was dropped after we accidentally
broke the kernel configuration and yet received no bug reports about
it.  Please delete that as well.

Finally, two of the architectures are missing documentation of their
installer flavours:

- For i386 there are default and xen installer flavours.  The xen
 
installer flavour is needed for Xen PV domains only.
- For powerpc there are powerpc and powerpc64 installer flavours.
  I believe powerpc64 is needed on all systems with 64-bit
  OpenFirmware.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.



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

Bug#855424: mutt: don't check errno if read/write didn't error

[Edward Betts]

Package: mutt
Version: 1.7.2-1
Severity: normal
Tags: patch

The code in raw_socket_read function invokes the read system call and
checks if there was an error, indicated by a return value of -1.

If read doesn't return an error, but the global variable errno is set
to EINTR then error handling runs. This is incorrect, error handling
should only happen if read returns -1. When read doesn't result in an
error it doesn't set errno.

The same is true for raw_socket_write and the write sytem call.

This makes mutt close to unusable when interacting with a non-SSL IMAP
server. Mutt gives this message "Error talking to localhost (Interrupted
system call)" and closes the mailbox.

There is a patch to fix this problem.

--- mutt-1.7.2/mutt_socket.c2017-02-17 20:34:41.0 +
+++ new/mutt_socket.c   2017-02-17 20:34:31.791530257 +
@@ -397,46 +397,36 @@
 int raw_socket_read (CONNECTION* conn, char* buf, size_t len)
 {
   int rc;
 
   mutt_allow_interrupt (1);
   if ((rc = read (conn->fd, buf, len)) == -1)
   {
 mutt_error (_("Error talking to %s (%s)"), conn->account.host,
strerror (errno));
 mutt_sleep (2);
-  } else if (errno == EINTR) {
-rc = -1;
-mutt_error (_("Error talking to %s (%s)"), conn->account.host,
-   strerror (errno));
-mutt_sleep (2);
-   }
+  }
   mutt_allow_interrupt (0);
 
   return rc;
 }
 
 int raw_socket_write (CONNECTION* conn, const char* buf, size_t count)
 {
   int rc;
 
   mutt_allow_interrupt (1);
   if ((rc = write (conn->fd, buf, count)) == -1)
   {
 mutt_error (_("Error talking to %s (%s)"), conn->account.host,
strerror (errno));
 mutt_sleep (2);
-  } else if (errno == EINTR) {
-rc = -1;
-mutt_error (_("Error talking to %s (%s)"), conn->account.host,
-   strerror (errno));
-mutt_sleep (2);
   }
   mutt_allow_interrupt (0);
 
   return rc;
 }
 
 int raw_socket_poll (CONNECTION* conn)
 {
   fd_set rfds;
   struct timeval tv = { 0, 0 };

Bug#855208: runc: 1.0 release candidate breaks docker 1.11 - oci runtime error: flag provided but not defined: -bundle

[Chris Lamb]

Hi,

> runc: 1.0 release candidate breaks docker 1.11 - oci
> runtime error: flag provided but not defined: -bundle

… and anyone seeing "bad listen address format 
/var/run/docker/libcontainerd/docker-containerd.sock, expected proto://address" 
will temporarily need to downgrade containerd too. :)


Regards,

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

Bug#836567: [Aptitude-devel] Bug#836567: aptitude: [PATCH] aborts on encountering new DepCompareOp flags

[Manuel A. Fernandez Montecelo]

2017-02-17 3:34 GMT+01:00 Aaron M. Ucko :
> "Manuel A. Fernandez Montecelo"  writes:
>
>> In practice the %-operation would probably achieve the same, but I think
>> that this way is easier to understand.
>
> That's fair, and I agree that it should be equivalent in practice.
> As a matter of style, though, I might declare comp_mask as
>
> static const int comp_mask;

OK, I will do that.


>> Patch attached.  I will try to get it into the next release.
>
> Sounds good.
>
>> Aaron, it would be great if you could test it and check that it fixes
>> the problem.  I never stumbled upon this problem, even if I use
>> multi-arch in most of my systems.
>
> I'm not sure what specifically about my installation triggered this
> behavior.  FWIW, when aptitude 0.8.5-1 hit testing three weeks ago, I
> decided to try switching back to a stock build, and haven't seen any
> trouble on this front since.  However, it's probably still best to
> defend against the possibility, so please do proceed here.

Yeah, that's my feeling as well.  I haven't experience it either at
any point in time, but it must happen in some combinations, which will
be annoying for users if they happen in stable systems and don't get
updates for months/years...


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#837946: crash still present in aptitude-0.8.5-1

[Manuel A. Fernandez Montecelo]

Control: tags -1 - moreinfo + pending


2017-02-02 10:39 Marcel Partap:

also occurs when I issue `aptitude safe-upgrade` f.e.
similar backtrace:


I believe that this is the same as #849370 and #836567.  There's a patch
attached to the last one, which you can try, and I would be grateful of
any feedback.

In any case, if I get this patch to stable or the new version and this
keeps happening to you when the fix is released, please reopen the bug.


Cheers.

--
Manuel A. Fernandez Montecelo 

Bug#855423: collectd: package should be compiled against linux-libc-dev >= 4.6 for jessie-backports

[Jimmy DALLMAN]

Package: collectd
Version: 5.7.0-3~bpo8+1

Hello,

I have a jessie server using kernel version 4.8.0-0.bpo.2-amd64 from 
jessie-backports. I am receiving the same error present in bug #829634.
Feb 15 01:02:18 host collectd[22891]: netlink plugin: link_filter_cb: 
IFLA_STATS64 mnl_attr_validate2 failed.
Feb 15 01:02:18 host collectd[22891]: netlink plugin: ir_read: 
mnl_socket_recvfrom failed.
Feb 15 01:02:18 host collectd[22891]: read-function of plugin `netlink' failed. 
Will suspend it for 120.000 seconds.

The changelog entry which resolves the previous ticket states:
* Rebuild with linux-libc-dev >= 4.6 (now in testing and unstable)  to
accommodate a change to rtnl_link_stats64. Thanks to Gábor Gombás for
reporting this (Closes: #829634).

I believe collectd in jessie-backports should also be rebuilt with 
linux-libc-dev >= 4.6 to remain in sync with the latest backports kernels.

Thanks,
Jimmy

Bug#849811: ITP: fonts-apropal -- Sans-serif font for decorative signs, one of the Warsaw Types

[Dominik Danelski]

Thank you for your reply. Would you be so kind and help me to release
this package?
Dominik

On Sat, 31 Dec 2016 23:25:19 +0800 Paul Wise  wrote:
> On Sat, Dec 31, 2016 at 8:00 PM, Dominik Danelski wrote:
>
> > * URL : https://github.com/warszawskie-kroje/apropal
>
> I think this will have to go to contrib since it relies on the
> non-free MacOS app Glyphs for building from source.
>
> https://glyphsapp.com/
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
>

Bug#855419: [pkg-gnupg-maint] Bug#855419: gnupg: Cannot use --gen-key on pl_PL.UTF-8 locale.

[Witold Baryluk]

BTW. It is likely that "w", is from "Wyjdź" / "Wyjście", meaning "Exit /
Quit" in Polish.

N - Nazwisko (Name)
A or E - adress email (poczty elektronicznej)  (Email)
A or Z - Akceptuj, Zaakceptuj  (Accept)
K - Kontynuj (Continue).

Just some ideas.

It is likely that the key "Change (N)ame, (E)mail, or (O)kay/(Q)uit? " is
not translated, but the expected key letters in keyboard handling got
translated.




2017-02-17 21:03 GMT+01:00 Daniel Kahn Gillmor :

> Control: tags 855419 + confirmed
> Control: forwarded 855419 https://bugs.gnupg.org/gnupg/issue2966
>
> On Fri 2017-02-17 14:36:13 -0500, Witold Baryluk wrote:
> > gnupg: Cannot use --gen-key on pl_PL.UTF-8 locale.
> […]
> > Change (N)ame, (E)mail, or (O)kay/(Q)uit? O
> > Change (N)ame, (E)mail, or (O)kay/(Q)uit? Q
> > Change (N)ame, (E)mail, or (O)kay/(Q)uit? N
> > Change (N)ame, (E)mail, or (O)kay/(Q)uit? E
> > Adres poczty elektronicznej: witold.bary...@gmail.com
> > Twój identyfikator użytkownika będzie wyglądał tak:
> > "Witold Baryluk "
>
> I can confirm this misbehavior by enabling pl_PL.UTF-8 via
> "dpkg-reconfigure locales" and repeating this step.  I think it's an
> upstream bug, and i've reported it there at the URL above.
>
> hope to get a fix to you soon!
>
>  --dkg
>



-- 
Witold Baryluk
My PGP keys:
https://keys.mailvelope.com/pks/lookup?op=get&search=0x16D96FA220A8F130

Bug#855422: Chromebook C740 media/function keys inverted

[Hans-Christoph Steiner]

Package: xkb-data
Version: 2.19-1

All Chromebooks since the beginning have a standard keyboard layout that
uses media keys by default instead of function keys.  The keys are not
even labeled as function keys, but only as media keys.  With some
Chromebooks, this is working fine without extra configuration.  For
example, with the Toshiba Chromebook CB35.  I just installed stretch
using the RC2 installer image, and the media keys are outputting
function key symbols.  I did a "Full ROM" update of coreboot, and this
is running only Debian.

Here is a good post that shows pictures of the layout, as well as a way
to correct the mapping:
http://www.fascinatingcaptain.com/howto/remap-keyboard-keys-for-ubuntu/

GalliumOS has been fixing lots of things for Chromebooks, it would be
awesome to have that stuff upstreamed:

It would be great if this happened out of box!  I'm happy to provide
extra info as needed, just ask.

Bug#854912: unblock: shotwell/0.25.4-0.1

[Richard B. Kreckel]

I've NMUed shotwell 0.25.4+really0.24.5-0.1, containing 0.24.5, the
latest stable release. It's now three days old.

How to proceed?

  -richy.
-- 
Richard B. Kreckel

Bug#853902: icinga-web: Can't locate CGI/Util.pm in @INC during installation

[Florian Schlichting]

Hi,

> icinga-web: Can't locate CGI/Util.pm in @INC during installation

in debian/icinga-web.postinst, I see

uriescape() {
echo "$(perl -MCGI::Util -e 'print CGI::Util::escape($ARGV[0]);' "$1")"
}

and further investigation reveals

$ corelist CGI::Util
CGI::Util was first released with perl v5.6.1, deprecated (will be 
CPAN-only) in v5.19.7 and removed from v5.21.0

$ apt-file search CGI/Util.pm
libcgi-pm-perl: /usr/share/perl5/CGI/Util.pm

icinga-web needs a Depends: libcgi-pm-perl

Bug#843777: temporarily loosen new nginx modules ban until separate module compilation available?

[Mark Van den Borre]

Hello,

(My below request is certainly a wishlist bug. I hope I pulled the
right levers so it comes across like so...)
> Both of these bugs are being merged with our no-new-modules bucket. We
> are working to allow any number of new modules, in the future; we're
> not there, yet. When we do get there, these bugs will be expected to
> be filed as ITP/RFP's. ;)

At https://fosdem.org , we are using the nginx rtmp module
intensively. It seems it is becoming a de facto standard when an
in-house streaming server is preferred, as opposed to an external
streaming platform. It combines excellently with ffmpeg, the recently
pacakged voctomix and several components of the gstreamer framework,
to create an excellent FOSS video streaming stack. Some debconf video
people too seem to be interested...

I've watched upstream nginx development for a bit. Dynamically loaded
modules are supported since 1.9.11, but separate module compilation
doesn't look like it is going to happen anytime soon.

Would you be willing to temporarily reconsider the ban on the
inclusion of a small set of new nginx modules into Debian until this
situation changes? If it helps, it seems like at least the rtmp module
could be done as a dynamically loaded module at least...

https://www.nginx.com/resources/wiki/extending/converting/
https://www.nginx.com/blog/dynamic-modules-development/

Thank you for your work on Debian!

Kind regards,

Mark
--
Mark Van den Borre
https://fosdem.org staff

Bug#855419: [pkg-gnupg-maint] Bug#855419: gnupg: Cannot use --gen-key on pl_PL.UTF-8 locale.

[Daniel Kahn Gillmor]

Control: tags 855419 + confirmed
Control: forwarded 855419 https://bugs.gnupg.org/gnupg/issue2966

On Fri 2017-02-17 14:36:13 -0500, Witold Baryluk wrote:
> gnupg: Cannot use --gen-key on pl_PL.UTF-8 locale.
[…]
> Change (N)ame, (E)mail, or (O)kay/(Q)uit? O
> Change (N)ame, (E)mail, or (O)kay/(Q)uit? Q
> Change (N)ame, (E)mail, or (O)kay/(Q)uit? N
> Change (N)ame, (E)mail, or (O)kay/(Q)uit? E
> Adres poczty elektronicznej: witold.bary...@gmail.com
> Twój identyfikator użytkownika będzie wyglądał tak:
> "Witold Baryluk "

I can confirm this misbehavior by enabling pl_PL.UTF-8 via
"dpkg-reconfigure locales" and repeating this step.  I think it's an
upstream bug, and i've reported it there at the URL above.

hope to get a fix to you soon!

 --dkg


signature.asc
Description: PGP signature

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

> Thanks for confirming that the last revision is not working as expected.
> Now we are back at the beginning. Could you apply this patch [1] and
> report back if it resolves your issue please?

Yes!  That fixed it for us.

Sorry again for the run around.

Allen

Bug#855415: installation-reports: Debian-Testing fails to reboot after installation.

[Ben Hutchings]

On Fri, 2017-02-17 at 14:14 -0500, Lennart Sorensen wrote:
[...]
> After all gnome3 mandates 3D accaleration, and having drivers that don't
> match the hardware (virtualbox in this case) could be a problem.

GNOME 3 can also use software rendering if Mesa is built with llvmpipe
(which we do on x86), and will use simpler animations in this case. 
Works for me in KVM/QEMU.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.



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

Bug#855405: pcre3: CVE-2017-6004

[Salvatore Bonaccorso]

Hi Matthew,

On Fri, Feb 17, 2017 at 07:29:44PM +, Matthew Vernon wrote:
> Hi,
> 
> > Attached would be the proposed debdiff for a NMU in case needed (I
> > will use in any case a delayed queue if I upload).
> > 
> > Let me know if you would appreciate the NMU or prefer to do the upload
> > on your own if you agree.
> 
> Thanks for this; given you've done the necessary work (that was quick!), why
> don't you go ahead.

Thanks. I just have uploaded then my NMU (without delay).

Regards and thanks for your quick followup,
Salvatore

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Markus Koschany]

On 17.02.2017 20:50, Allen Hadden wrote:
>> Let's recapitulate: You are currently running +deb7u4 from April 2016
>> which is the last good version for you and you see 400 errors when you
>> use +deb7u5 or any later version up to +deb7u10, correct? Then this is a
>> different issue because Samuel reported that the 400 errors occurred
>> when he upgraded from 7.0.56-3+deb8u7 to 7.0.56-3+deb8u8 in Jessie
> 
> I just ran through the various 7.0.28-4+deb7 versions from u4 through
> u10 (it's a
> quick test to run so I just went through them sequentially).  
> 
> The only one that fails is 7.0.28-4+deb7u10.  All other builds work for us.
> 
> So at least Samuel's and my results are consistent (+deb8u8 and +deb7u10
> both
> include the "infinite loop patch").

Thanks for confirming that the last revision is not working as expected.
Now we are back at the beginning. Could you apply this patch [1] and
report back if it resolves your issue please?

https://github.com/apache/tomcat80/commit/534d62075f8c03cc3e77f301e53be53acdefd1c9.patch




signature.asc
Description: OpenPGP digital signature

Bug#847652: nvidia-kernel-dkms fails to compile for rt-kernel 4.8.0-1-rt

[Luca Boccassi]

Control: -1 severity wishlist
Control: -1 tags patch
Control: -1 retitle rt_mutex_destroy is GPL_ONLY unlike mutex_destroy, breaks 
non-GPL modules
Control: -1 reassign linux-image-4.9.0-1-rt-amd64

On Fri, 2017-02-17 at 20:54 +0100, Norbert Lange wrote:
> On Tue, 13 Dec 2016 17:59:31 + Luca Boccassi
>  wrote:
> > Control: tags -1 upstream
> > 
> > On Sat, 2016-12-10 at 12:40 +0100, Andreas Beckmann wrote:
> > > On 2016-12-10 12:16, Luca Boccassi wrote:
> > > > Didn't even know Nvidia driver supported running on the RT
> > > > kernel.
> > > 
> > > IIRC this wasn't supported long ago. Maybe things have changed. I
> > > never
> > > tried it myself.
> > > At least the kernel modules always built without issues against
> > > the -rt
> > > kernels so far.
> > > 
> > > > Is this a regression, or is it the first time you are trying
> > > > this?
> > > 
> > > This is a regression introduced in 370.
> > > 
> > > 
> > > Andreas
> > 
> > This is a problem in the kernel code, see this patch:
> > 
> > https://patchwork.kernel.org/patch/9395795/
> > 
> > I don't think there's anything we can do unless that patch is
> > merged in
> > the kernel.
> > 
> > Kind regards,
> > Luca Boccassi
> 
> This is still a problem with 4.9, any chance of pushing this patch in
> the kernel before stretch is released?
> 
> Kind regards, Norbert

Sorry, but there's nothing the pkg-nvidia team can do about this
problem.

I am reassigning so that we can kindly ask the kernel team if they
would be willing to merge the patch linked in patchwork [1], even
though it's not yet merged upstream.

Kind regards,
Luca Boccassi

[1] https://patchwork.kernel.org/patch/9395795/

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

Bug#855258: unblock: spice/0.12.8-2.1

[Salvatore Bonaccorso]

Hi Moarkus, hi Emilio,

On Thu, Feb 16, 2017 at 10:50:34PM +0100, Markus Koschany wrote:
> On 16.02.2017 22:23, Emilio Pozuelo Monfort wrote:
> > Control: tags -1 moreinfo
> > 
> > On 16/02/17 06:06, Salvatore Bonaccorso wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian@packages.debian.org
> >> Usertags: unblock
> >>
> >> Hi
> >>
> >> Please unblock package spice
> [...]
> > That failed to build on mips(64)el:
> > 
> > https://buildd.debian.org/status/package.php?p=spice
> 
> Hi,
> 
> I think this is unrelated to our security fix. The package already
> failed on mips64el last month (2017/01/06) with the same build failure.

FTR, yes I think this is true, that the failure is *not* related to
the security fixes. I built both 0.12.8-2 and 0.12.8-2.1 on eller.d.o,
and it failed both there. I have not futher investigated.

Regards,
Salvatore

Bug#855405: pcre3: CVE-2017-6004

[Matthew Vernon]

Hi,


Attached would be the proposed debdiff for a NMU in case needed (I
will use in any case a delayed queue if I upload).

Let me know if you would appreciate the NMU or prefer to do the upload
on your own if you agree.


Thanks for this; given you've done the necessary work (that was quick!), 
why don't you go ahead.


Regards,

Matthew

Bug#855421: src:linphone: Vcs-Browser points to wrong package

[Dara Adib]

Source: linphone
Version: 3.6.1-3
Severity: minor
Tags: patch

Dear Maintainer,

The Vcs-Browser field in debian/control points to asterisk. It should
point to linphone.

Thanks!

diff --git a/debian/control b/debian/control
index 9e954fa..5611967 100644
--- a/debian/control
+++ b/debian/control
@@ -64,7 +64,7 @@ Build-Depends: autoconf,
 Standards-Version: 3.9.6
 Homepage: http://www.linphone.org/
 Vcs-Git: https://anonscm.debian.org/git/pkg-voip/linphone.git
-Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/asterisk.git
+Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/linphone.git

 Package: linphone

Bug#855353: python-selenium: chromedriver is now a transitional package

[Sascha Girrulat]

Hi Rogério,

thx for all the bugs. I will update the package asap.

Regards
Sascha

Am 17.02.2017 um 05:14 schrieb Rogério Brito:
> Package: python-selenium
> Version: 2.53.2+dfsg1-1
> Severity: wishlist
> 
> Hi.
> 
> The chromedriver package now is a transitional package to the chrome-driver
> package and python-selenium depends only on chromedriver.
> 
> It would be nice to put an alternative dependency on chrome-driver in the
> next upload of the package to avoid having spurious packages.
> 
> BTW, the same comments apply to python3-selenium.
> 
> 
> Thanks in advance,
> 
> Rogério Brito.
> 
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
> 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=pt_BR.utf-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages python-selenium depends on:
> pn  python:any  
> 
> Versions of packages python-selenium recommends:
> ii  phantomjs  2.1.1+dfsg-2
> 
> Versions of packages python-selenium suggests:
> ii  firefoxdriver  2.53.2-3
> 
> -- no debconf information
> 



signature.asc
Description: OpenPGP digital signature

Bug#847652: nvidia-kernel-dkms fails to compile for rt-kernel 4.8.0-1-rt

[Norbert Lange]

On Tue, 13 Dec 2016 17:59:31 + Luca Boccassi
 wrote:
> Control: tags -1 upstream
>
> On Sat, 2016-12-10 at 12:40 +0100, Andreas Beckmann wrote:
> > On 2016-12-10 12:16, Luca Boccassi wrote:
> > > Didn't even know Nvidia driver supported running on the RT kernel.
> >
> > IIRC this wasn't supported long ago. Maybe things have changed. I never
> > tried it myself.
> > At least the kernel modules always built without issues against the -rt
> > kernels so far.
> >
> > > Is this a regression, or is it the first time you are trying this?
> >
> > This is a regression introduced in 370.
> >
> >
> > Andreas
>
> This is a problem in the kernel code, see this patch:
>
> https://patchwork.kernel.org/patch/9395795/
>
> I don't think there's anything we can do unless that patch is merged in
> the kernel.
>
> Kind regards,
> Luca Boccassi

This is still a problem with 4.9, any chance of pushing this patch in
the kernel before stretch is released?

Kind regards, Norbert

Bug#855134: installation-guide: mips related cleanups and updates

[Holger Wansing]

Hi,

Samuel Thibault  wrote:
> Holger Wansing, on jeu. 16 févr. 2017 19:08:23 +0100, wrote:
> > James Cowgill  wrote:
> > > I've done a bit of cleaning up on the MIPS related part of the
> > > installation guide. Mostly I have removed some old platforms which will
> > > no longer be supported in Stretch and rewritten the supported platforms
> > > section.
> > 
> > Someone already working on this?
> > Shall I look into committing it?
> 
> I'd say feel free to :)
> 
> Ideally along the way the few .xml translations should at least get the
> dropping of text. The po translations should be getting very fine.

I have committed most of the changings and synced translations where possible.

But I did not commit patch #2:


Subject: [PATCH 02/11] Add full MIPS arch names to d/archlist

---
 debian/archlist | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/archlist b/debian/archlist
index 581f225..7c41b5a 100644
--- a/debian/archlist
+++ b/debian/archlist
@@ -10,9 +10,9 @@ armel ARM softfloat
 armhf  ARM harffloat
 #hppa  PA-RISC (hppa)
 #ia64  IA-64
-mips   Mips
-mips64el   Mipsel 64
-mipsel Mipsel
+mips   32-bit MIPS (big-endian)
+mips64el   64-bit MIPS (little-endian)
+mipsel 32-bit MIPS (little-endian)
 #powerpc   PowerPC
 ppc64elPowerPC
 s390x  S/390


... since I'm unsure where these changings influence. Where are these names
used?




Additionally, I would like to propose a changing to the supported archs table,
which currently looks this (the mips part):

├┼──┼──┼──┤
││  │MIPS Malta (32 bit)   │4kc-malta │
│32bit MIPS  │  ├──┼──┤
│(big-endian)│mips  │MIPS Malta (64 bit)   │5kc-malta │
││  ├──┼──┤
││  │Cavium Octeon │octeon│
├┼──┼──┼──┤
││  │MIPS Malta│5kc-malta │
│64bit MIPS  │  ├──┼──┤
│(little-endian) │mips64el  │Cavium Octeon │octeon│
││  ├──┼──┤
││  │Loongson 3│loongson-3│
├┼──┼──┼──┤
││  │MIPS Malta (32 bit)   │4kc-malta │
││  ├──┼──┤
│32bit MIPS  │  │MIPS Malta (64 bit)   │5kc-malta │
│(little-endian) │mipsel├──┼──┤
││  │Cavium Octeon │octeon│
││  ├──┼──┤
││  │Loongson 3│loongson-3│
├┼──┼──┼──┤


I would propose to delete the "Mips Malta (64 bit)" entries from the 32bit MIPS
lines (mips and mipsel), since they are contained in the "MIPS Malta" entry
within the 64bit MIPS line.
That would lead to something like this:


├┼──┼──┼──┤
││  │Mips Malta│4kc-malta │
│32bit MIPS  │mips  ├──┼──┤
│(big-endian)│  │Cavium Octeon │octeon│
├┼──┼──┼──┤
││  │MIPS Malta│5kc-malta │
│64bit MIPS  │  ├──┼──┤
│(little-endian) │mips64el  │Cavium Octeon │octeon│
││  ├──┼──┤
││  │Loongson 3│loongson-3│
├┼──┼──┼──┤
││  │Mips Malta│4kc-malta │
│32bit MIPS  │mipsel├──┼──┤
│(little-endian) │  │Cavium Octeon │octeon│
││  ├──┼──┤
││  │Loongson 3│Loongson-3│
├┼──┼──┼──┤



Any objections?


Holger


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered 

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

> Let's recapitulate: You are currently running +deb7u4 from April 2016
> which is the last good version for you and you see 400 errors when you
> use +deb7u5 or any later version up to +deb7u10, correct? Then this is a
> different issue because Samuel reported that the 400 errors occurred
> when he upgraded from 7.0.56-3+deb8u7 to 7.0.56-3+deb8u8 in Jessie

I just ran through the various 7.0.28-4+deb7 versions from u4 through u10 
(it's a 
quick test to run so I just went through them sequentially). 

The only one that fails is 7.0.28-4+deb7u10.  All other builds work for 
us.

So at least Samuel's and my results are consistent (+deb8u8 and +deb7u10 
both
include the "infinite loop patch").

Allen

Bug#855420: wammu: Assertion failure in feedback

[Simon Richter]

Package: wammu
Version: 0.43-1
Severity: minor

Hi,

when I select the "Choose Features" button in the feedback dialog, I get an
exception

PyAssertionError: C++ assertion "Assert failure" failed at
../src/common/sizer.cpp(1401) in DoInsert(): too many items (4 > 1*3) in
grid sizer (maybe you should omit the number of either rows or columns?)

My phone is a 6230i using bluephonet.

   Simon

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

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

Versions of packages wammu depends on:
ii  python-gammu 2.7-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-3
pn  python:any   

Versions of packages wammu recommends:
ii  notification-daemon  3.20.0-1
ii  python-bluez [python-bluetooth]  0.22-1
ii  python-dbus  1.2.4-1
pn  timidity 

Versions of packages wammu suggests:
pn  gmobilemedia  

Versions of packages python-gammu depends on:
ii  libc6   2.24-9
ii  libgammu8   1.38.1-1
ii  libgsmsd8   1.38.1-1
ii  python  2.7.13-2
pn  python:any  

-- no debconf information

Bug#855419: gnupg: Cannot use --gen-key on pl_PL.UTF-8 locale.

[Witold Baryluk]

Package: gnupg
Version: 2.1.18-6
Severity: important

Hello.

$ gpg --gen-key
gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Note: Use "gpg --full-generate-key" for a full featured key generation dialog.

GnuPG musi utworzyć identyfikator użytkownika do identyfikacji klucza.

Imię i nazwisko: Witold Baryluk
Adres poczty elektronicznej: witold.bary...@gmail.com
Twój identyfikator użytkownika będzie wyglądał tak:
"Witold Baryluk "

Change (N)ame, (E)mail, or (O)kay/(Q)uit? O
Change (N)ame, (E)mail, or (O)kay/(Q)uit? Q
Change (N)ame, (E)mail, or (O)kay/(Q)uit? N
Change (N)ame, (E)mail, or (O)kay/(Q)uit? E
Adres poczty elektronicznej: witold.bary...@gmail.com
Twój identyfikator użytkownika będzie wyglądał tak:
"Witold Baryluk "

Change (N)ame, (E)mail, or (O)kay/(Q)uit? 
Change (N)ame, (E)mail, or (O)kay/(Q)uit? 
Change (N)ame, (E)mail, or (O)kay/(Q)uit? 
Change (N)ame, (E)mail, or (O)kay/(Q)uit? O
Change (N)ame, (E)mail, or (O)kay/(Q)uit? Okey
Change (N)ame, (E)mail, or (O)kay/(Q)uit? Ok
Change (N)ame, (E)mail, or (O)kay/(Q)uit? Y
Change (N)ame, (E)mail, or (O)kay/(Q)uit? N
Change (N)ame, (E)mail, or (O)kay/(Q)uit? C
Change (N)ame, (E)mail, or (O)kay/(Q)uit? E
Adres poczty elektronicznej: witold.bary...@gmail.com
Twój identyfikator użytkownika będzie wyglądał tak:
"Witold Baryluk "

Change (N)ame, (E)mail, or (O)kay/(Q)uit? N
Change (N)ame, (E)mail, or (O)kay/(Q)uit? N
Change (N)ame, (E)mail, or (O)kay/(Q)uit? Name
Change (N)ame, (E)mail, or (O)kay/(Q)uit? 
gpg: signal Interrupt caught ... exiting


It works if I force LC_ALL=C


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

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

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.18-6
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-9
ii  libgcrypt201.7.6-1
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-2
ii  libsqlite3-0   3.16.2-2
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnupg recommends:
ii  dirmngr 2.1.18-6
ii  gnupg-l10n  2.1.18-6

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

Bug#855418: graphviz: Uses wrong DEB_HOST_* vars in d/rules - causes cross-building on some architectures (e.g. i386)

[Niels Thykier]

Package: graphviz
Version: 2.38.0-16.1
Severity: important

There is a bug in the d/rules where the wrong DEB_HOST_* var for
./configure in the 2.38.0-16.1 upload:

diff -Nru graphviz-2.38.0/debian/rules graphviz-2.38.0/debian/rules
--- graphviz-2.38.0/debian/rules2016-10-20 17:43:26.0 +
+++ graphviz-2.38.0/debian/rules2017-01-28 13:26:14.0 +
@@ -63,7 +63,7 @@
 
# Configure the package
dh_autoreconf
-   ./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
+   ./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_MULTIARCH) \
--disable-silent-rules \
--prefix=/usr \
--datadir=\$${prefix}/share \
@@ -258,8 +258,8 @@


I don't think that "--host" value should have been changed.  On i386
(and possibly other ports) this causes a cross-compile.

~Niels

Bug#855417: e2fsprogs: tune2fs does not properly enable quota tracking (regression)

[Theodore Y. Ts'o]

Package: e2fsprogs
Version: 1.43.4-2
Severity: important

The tune2fs program no longer properly enables quotas due to a
regression introduced in 1.43.4.  The problem commit is 5c2a665afa:
"Avoid dereferencing beyond allocated memory in quota handling".

This causes xfstests generic/383, generic/384, and generic/385 and
generic/386 to fail to run properly.

This fix is upstream, in commit 5f82cc95b31: "tune2fs: fix quota
enablement regression".

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

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

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.43.4-2
ii  libblkid1   2.29.1-1
ii  libc6   2.24-9
ii  libcomerr2  1.43.4-2
ii  libss2  1.43.4-2
ii  libuuid12.29.1-1
ii  util-linux  2.29.1-1

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
ii  e2fsck-static  1.43.4-2
ii  fuse2fs1.43.4-2
pn  gpart  
ii  parted 3.2-17

-- no debconf information

Bug#854925: closed by Michael Gilbert (Re: Bug#854925: chromium: Chromium does not start -- execv failed: No such file or directory)

[Alexei Gonçalves de Oliveira]

HI, Michael,

Thank you for your answer. The problem is I have deleted the 
corresponding Chromium profile from /etc/apparmor.d/, restarted apparmor 
service and it still does not work. Please, check the output of 
aa-status below: there is no active Chromium-related profile!


alex@PCDELL:~$ sudo aa-status
[sudo] password for alex:
apparmor module is loaded.
68 profiles are loaded.
42 profiles are in enforce mode.
   /bin/netstat
   /bin/ping
   /home/alex/tor-browser_en-US/Browser/firefox
   /usr/bin/dbus-daemon//sanitized_helper
   /usr/bin/gimp-2.8
   /usr/bin/gsettings
   /usr/bin/gsettings-data-convert
   /usr/bin/gwenview
   /usr/bin/gwenview//sanitized_helper
   /usr/bin/irssi
   /usr/bin/jondo
   /usr/bin/jondo//browser_java
   /usr/bin/jondo//browser_openjdk
   /usr/bin/liferea
   /usr/bin/liferea//sanitized_helper
   /usr/bin/okular
   /usr/bin/pidgin
   /usr/bin/pidgin//launchpad_integration
   /usr/bin/pidgin//sanitized_helper
   /usr/bin/pulseaudio
   /usr/bin/skype
   /usr/bin/totem
   /usr/bin/totem-audio-preview
   /usr/bin/totem-video-thumbnailer
   /usr/bin/transmission-qt
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/firefox-esr/firefox-esr
   /usr/lib/firefox-esr/firefox-esr//sanitized_helper
   /usr/lib/icedove/icedove
   /usr/lib/libvirt/virt-aa-helper
   /usr/sbin/apt-cacher-ng
   /usr/sbin/avahi-daemon
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/dnsmasq
   /usr/sbin/ntpd
   /usr/sbin/tcpdump
   /usr/{sbin/traceroute,bin/traceroute.db}
   firejail-default
   gst_plugin_scanner
   system_tor
26 profiles are in complain mode.
   /sbin/klogd
   /sbin/syslog-ng
   /sbin/syslogd
   /usr/bin/dbus-daemon
   /usr/bin/dbus-daemon//null-1
   /usr/bin/dbus-daemon//null-1//null-2
   /usr/bin/dbus-daemon//null-3
   /usr/bin/dbus-daemon//null-4
   /usr/bin/dbus-daemon//null-4//null-5
   /usr/bin/dbus-daemon//null-4//null-5//null-6
   /usr/bin/dbus-daemon//null-7
   /usr/bin/dbus-daemon//null-8
   /usr/bin/dbus-daemon//null-9
   /usr/bin/dbus-daemon//null-a
   /usr/bin/dbus-daemon//null-b
   /usr/bin/dbus-daemon//null-c
   /usr/bin/dbus-daemon//null-d
   /usr/lib/gvfs/gvfsd
   /usr/sbin/dovecot
   /usr/sbin/identd
   /usr/sbin/mdnsd
   /usr/sbin/nmbd
   /usr/sbin/nscd
   /usr/sbin/smbd
   /usr/sbin/smbldap-useradd
   /usr/sbin/smbldap-useradd///etc/init.d/nscd
27 processes have profiles defined.
10 processes are in enforce mode.
   /usr/bin/jondo//browser_openjdk (1635)
   /usr/bin/liferea (1894)
   /usr/bin/skype (1674)
   /usr/lib/firefox-esr/firefox-esr (24538)
   /usr/lib/icedove/icedove (25537)
   /usr/sbin/avahi-daemon (764)
   /usr/sbin/avahi-daemon (839)
   /usr/sbin/cups-browsed (846)
   /usr/sbin/cupsd (845)
   /usr/sbin/ntpd (837)
17 processes are in complain mode.
   /usr/bin/dbus-daemon (767)
   /usr/bin/dbus-daemon (1234)
   /usr/bin/dbus-daemon (5992)
   /usr/bin/dbus-daemon (6935)
   /usr/bin/dbus-daemon (21295)
   /usr/bin/dbus-daemon//null-3 (1342)
   /usr/bin/dbus-daemon//null-4 (1898)
   /usr/bin/dbus-daemon//null-4//null-5 (1902)
   /usr/bin/dbus-daemon//null-4//null-5//null-6 (1905)
   /usr/bin/dbus-daemon//null-7 (1920)
   /usr/bin/dbus-daemon//null-8 (5962)
   /usr/bin/dbus-daemon//null-9 (5969)
   /usr/bin/dbus-daemon//null-a (5973)
   /usr/bin/dbus-daemon//null-b (5978)
   /usr/bin/dbus-daemon//null-c (5982)
   /usr/bin/dbus-daemon//null-d (31853)
   /usr/lib/gvfs/gvfsd (1926)
0 processes are unconfined but have a profile defined.

Also, I have created apparmor profiles for many other applications in 
Jessie from scratch -- including Akregator, Dropbox, Filezilla, 
Firefox-ESR, Icedove, JonDo, Liferea, Owncloud Client, Skype, Tor 
Browser Bundle, Transmission-Qt, among others -- and I have always 
managed to make them work after a little effort of study and review. 
This definitely does not seem a simple profile bug issue.


Thank you again for your attention,

Alexei

Às 01:00 de 17-02-2017, Debian Bug Tracking System escreveu:

This is an automatic notification regarding your Bug report
which was filed against the chromium package:

#854925: chromium: Chromium does not start -- execv failed: No such file or 
directory

It has been closed by Michael Gilbert .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Michael Gilbert 
 by
replying to this email.

Bug#846002: About the internal and external view of Blends

[Tollef Fog Heen]

]] Andreas Tille 

Hi,

first of all, sorry for taking a while to get back to you on this.

> Hi,
> 
> On Sun, Feb 05, 2017 at 12:38:59AM +0100, Tollef Fog Heen wrote:
> > > Would it be a sensible compromise to reassign this bug to d-i tagging it
> > > RC for buster to make sure a Blends menu will exist in the buster
> > > installer.
> > 
> > While I think it's important to get it fixed for buster, I don't think
> > it's RC.  If the d-i folks and/or the release team disagrees, I'm happy
> > for them to decide otherwise, though. 
> 
> May be this is the right time to clarify the role of Blends inside
> Debian and I'd like to adjust my probably biased opinion.  Do you
> consider Blends as
> 
>A) Assemblage of low popcon packages of very specific fields
> 
>B) Strategy to establish Debian in different workfields that
>   could cover a wide range of applications

No, I don't think either of those are a good description of what blends
are today, nor a sufficient description of what they could, and maybe
should be.

I think Blends are at least two things: They are a focal point for work
on packages in a specific area.  I imagine packages focusing on medical
applications for instance will encounter some of the same challenges,
and having somewhere to hold the more specialised conversations around
those challenges is useful.

They're also curated selections of packages.  Having a blend that is
«every single medical package under the sun» does not sound particularly
useful if it's pulled in as a single metapackage.

> As I said the outer view from users of Debian it is hard to distinguish
> between a derivative and a Blend.  From my experiences from DebConfs
> talks (which I'm holding since 2003) are not attracting many people
> which makes me consider that A is a widely spread inner view inside the
> Debian developers.

I don't see how this follows at all.  People generally scratch their own
itches.  I personally have little interest in, say medical applications
which means I'm not going to spend time and effort on that.  It doesn't
mean that I don't think people who are interested in it shouldn't work
on it: I quite think they should.  At the same time, making a
distribution and getting a release out is about balancing goals,
priorities and sometimes making those hard choices.  It is to say «no,
I'm sorry, this is too late» to somebody who is enthusiastic about a
change.  The flipside is that we get fairly regular releases out so if
you miss a release, it's not the end of the world.

[…]

> To not extend this mail to much I just want to address two points.  In
> the video[1] starting at minute 3 I'm presenting numbers how many Debian
> developers confirmed that they are DDs only for the reason that the
> Debian Med project exists.  In my summary for the Debian Med sprint I
> have updated numbers[2] that the trend continues and the Debian Med
> project attracted 1 developer per year and several of them are doing
> other things than only Debian Med work now.  This means a small topic
> like medicine and live science which makes a small fraction of Debian
> usage and is honestly speaking in the end irrelevant for the overall
> importance of Debian in general was able to gather more than 1% of
> the active Debian developers.

This is great, and it's a pretty common story: people come to scratch
their itch and some then migrate into helping out with other parts of
Debian that catch their interest, be it packages, the installer,
documentation, web pages, release team, translations or something else.

> I could give a lot of other examples and reasons why I think the active
> support of Blends inside the Debian infrastructure could have a positive
> effekt onto the acceptance of Debian inside these workfields *and*
> beyond.  Blends have the power to bump the maintainer-package relation
> to a team-topic relation and - provided if done right (we also have
> somehow orphaned Blends like Debian Junior) - can enhance the quality of
> packages covering a whole topic (see for instance Debian Med advent
> calendar[3] to squash bugs and many others).

Orphaned blends is something we need to figure out how to handle, yes,
and I think that we have them shows that teams are not a panacea.  Teams
require active effort to maintain too

> In short:  If you voted for A above please dive a bit into the topic to
> consider B as an option.  When voting B I think it becomes evident that
> the bug is RC (at least for Buster).

I still don't think it is, not even for buster.  If it's RC, it means
that we fix the bug or one of remove the component from the release
(which I don't think anybody suggests) or that we delay the release
until it's fixed.

I don't think we should do either of those.  Severity is not the same as
priority, we can have super-important bugs which have a low severity.  I
think we should just fix the bug (for Buster) instead.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends a

Bug#855415: installation-reports: Debian-Testing fails to reboot after installation.

[Lennart Sorensen]

On Fri, Feb 17, 2017 at 07:14:11PM +0100, Michael Siemmeister wrote:
> Last week I tried to install Debian in a virtual-box. Currently I use
> Debian 8.7 for running the virtual-box program. I managed to install
> Debian stable without any problems. Then I cloned the virtual-box and
> tried an upgrade to Debian-testing. I think, it worked. After a while
> I shut down the virtual-machine. When trying to reboot, it did not
> start properly. I just got some messages like 'Created slice User
> Slice of Debian-gdm.', 'Starting User Manager ofr UID 117.', and
> finally 'Started Daily apt activities.'. Then the virtual display just
> starts blinking. Nothing else happens. After three minutes or so the
> display freezes.
> 
> Then I thought, okay, maybe the virtualbox program has got a bug. So,
> I downloaded the Debian-Testing-DVD-1 via jigdo-lite and copied it to
> a USB drive. I tried to install Debian-Testing on an old laptop, a
> Toshiba Satellite from 2009. Unfortunately I don' remember the exact
> model number. I had already installed Debian Stable without any
> problems on that laptop some months ago. The Debian-Testing installer
> worked fine and finally, it asked me to reboot the PC. After rebooting
> similar problems occured. There was a message about the graphics card
> and after 30 seconds the display started blinking. Nothing else
> happened.
> 
> As I have written above these errors only occured with Debian-Testing.
> Debian-Stable worked fine on Virtualbox and the Toshiba laptop. So, I
> don't think there are some hardware problems.

If you are running virtualbox on jessie, that would be version 4.3.36.
I do find a lot of problems reported with gnome 3 and virtual box 4.x.

I wonder if virtualbox 5.1.8 in jessie-backports would solve the problem.

I also wonder if having virtualbox 4.x as host with 5.x guest utilities
installed could cause problems (I suspect the guest utilities are
automatically installed and for stretch they would be version 5.x,
not 4.x).

After all gnome3 mandates 3D accaleration, and having drivers that don't
match the hardware (virtualbox in this case) could be a problem.

-- 
Len Sorensen

Bug#855416: check_running_kernel: don't search /boot/lost+found

[Jonas Meurer]

Package: nagios-plugins-contrib
Version: 20.20170118
Severity: normal
Tags: patch

Hello,

recent changes to check_running_kernel introduced a find on /boot, which
includes /boot/lost+found on ext2/3/4 partitions and in turn produces an
error message if the check is run by a non-root user:

# sudo -u nagios /usr/lib/nagios/plugins/check_running_kernel 
find: ‘/boot/lost+found’: Permission denied
WARNING: Running kernel does not match on-disk kernel image: [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) != Linux version 
4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170124 
(Debian 6.3.0-5) ) #1 SMP Debian 4.9.6-3 (2017-01-28)]

This can easily be fixed by excluding /boot/lost+found in the find
command.

Instead of

$([ -f "/boot/vmlinuz-$(uname -r)" ] && find /boot/ -name 'vmlinuz*' -and -name 
"vmlinuz-$(uname -r)" -or -name 'vmlinuz*' -and -newer "/boot/vmlinuz-$(uname 
-r)" | sort)

do

$([ -f "/boot/vmlinuz-$(uname -r)" ] && find /boot/ -not \( -path 
/boot/lost+found -prune \) -name 'vmlinuz*' -and -name "vmlinuz-$(uname -r)" 
-or -name 'vmlinuz*' -and -newer "/boot/vmlinuz-$(uname -r)" | sort)

In my opinion, this would be a good thing as there's no need to run
check_running_kernel as user root. For security reasons, as few checks
as possible should be executed with root permissions.

Cheers,
 jonas

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- /usr/lib/nagios/plugins/check_running_kernel.orig   2017-01-18 
21:18:18.0 +
+++ /usr/lib/nagios/plugins/check_running_kernel2017-02-17 
19:08:16.425332437 +
@@ -185,8 +185,8 @@
 
 searched=""
 for on_disk in \
-   $([ -f "/boot/vmlinuz-$(uname -r)" ] && find /boot/ -name 'vmlinuz*' 
-and -name "vmlinuz-$(uname -r)" -or -name 'vmlinuz*' -and -newer 
"/boot/vmlinuz-$(uname -r)" | sort) \
-   $([ -f "/boot/kfreebsd-$(uname -r).gz" ] && find /boot/ -name 
'kfreebsd*' -and -name "kfreebsd-$(uname -r).gz" -or -name 'kfreebsd*' -and 
-newer "/boot/kfreebsd-$(uname -r).gz" | sort); do
+   $([ -f "/boot/vmlinuz-$(uname -r)" ] && find /boot/ -not \( -path 
/boot/lost+found -prune \) -name 'vmlinuz*' -and -name "vmlinuz-$(uname -r)" 
-or -name 'vmlinuz*' -and -newer "/boot/vmlinuz-$(uname -r)" | sort) \
+   $([ -f "/boot/kfreebsd-$(uname -r).gz" ] && find /boot/ -not \( -path 
/boot/lost+found -prune \) -name 'kfreebsd*' -and -name "kfreebsd-$(uname 
-r).gz" -or -name 'kfreebsd*' -and -newer "/boot/kfreebsd-$(uname -r).gz" | 
sort); do
 
if [ -e "$on_disk" ]; then
if [ -z "$STRINGS" ]; then

Bug#855398: unblock: thunar/1.6.11-1

[Niels Thykier]

Control: tags -1 moreinfo

Yves-Alexis Perez:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi, this is a pre-approval/pre-upload request for Thunar. The last two
> uploads (1.6.10-5 and 1.16.10-6) have included various fixes for
> crashes. These fixes have been cherry-picked from upstream git, and now
> there's an official release (1.6.11) included these fixes as well as
> translations.
> 
>  [...]
> 
> The diffstat might be a bit huge because of autogenerated files and
> translations. I've removed those from the attached diff, which ends up with:
> 
>  24 files changed, 8230 insertions(+), 7063 deletions(-)
> 
> I didn't yet do the upload, so this is really a pre-approval request.
> 
> Regards,
> 

Missing the promised attachment :)

Thanks,
~Niels

Bug#855415: installation-reports: Debian-Testing fails to reboot after installation.

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2017-02-17 at 19:14 +0100, Michael Siemmeister wrote:
[...]
> Last week I tried to install Debian in a virtual-box. Currently I use
> Debian 8.7 for running the virtual-box program. I managed to install
> Debian stable without any problems. Then I cloned the virtual-box and
> tried an upgrade to Debian-testing. I think, it worked. After a while
> I shut down the virtual-machine. When trying to reboot, it did not
> start properly. I just got some messages like 'Created slice User
> Slice of Debian-gdm.', 'Starting User Manager ofr UID 117.', and
> finally 'Started Daily apt activities.'. Then the virtual display just
> starts blinking. Nothing else happens. After three minutes or so the
> display freezes.

It seems that the X or Wayland server is not starting because something
is wrong with a graphics driver.  gdm will try to start it several
times before giving up.  This can cause the blinking that you see.  Try
switching to another VT (e.g. press Alt-F2).  You should get a text
login prompt that you can use to start a shell.

You should be able to find some information about what went wrong with
this command:

sudo grep gdm /var/log/messages

I hope you can work out how to copy that text into a file and then an
email; if not then ask about this on debian-user.

[...]
> Nevertheless, as written in my first mail, I got problems with
> installing Debian-Testing on my old Toshiba laptop. I just checked the
> model number. It's a Toshiba Satellite P300-1BB. Model No.:
> PSPCCE-01K001GR. Debian-Stable Jessie 8.5 worked fine without any
> problems during the installation. So I think the hardware is okay.
> 
>  I tried to install Debian-Testing on this laptop directly to the
> harddisk without virtualbox. During the installation there were no
> problems. But after the first boot, I keep getting these messages:
> 
> [drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel modesetting for
> R600 or later requires firmware-amd-graphics.
> kvm: disabled by bios
> 
> Then the display starts blinking and nothing else happens.
[...]

You need to log in (as explained above), enable non-free packages (see
https://wiki.debian.org/SourcesList), and install the firmware-amd-
graphics package.  Then you should probably reboot.

Alternately, reinstall using an installer built with non-free firmware
included:
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


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

Bug#855208: [pkg-go] Bug#855208: runc: 1.0 release candidate breaks docker 1.11 - oci runtime error: flag provided but not defined: -bundle

[Evgeni Golov]

Hi Tim,

On Wed, Feb 15, 2017 at 10:52:22PM +, Potter, Tim wrote:
> > I can reproduce this. Downgrading to 0.1.1+dfsg1-2 fixed this for me.
> 
> Hi everyone.  This upload is part of updated build dependencies for Docker 
> 1.13.0.
> Currently the pipeline is stalled while a few things sit in the NEW queue.  
> When
> that's all sorted out everything should build again.

Can we in the meantime have proper Breaks in place, so that people don't 
accidentally update runc without docker/containerd/etc?

Thanks
Evgeni

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

First off, thanks for your patience.  The thing I was missing was that the 
build procedure for Debian includes applying patches to the code.  I was 
following the build instructions from the BUILDING.txt file, which doesn't 
include the Debian-specific instructions.  That completely explains what I 
was seeing with inconsistent JAR file contents.

I will test each version from +deb7u5 until the problem occurs again and 
report my results.

Thanks!

Allen

Bug#855288: aptitude internal error

[Manuel A. Fernandez Montecelo]

Hi,

2017-02-16 13:55 Harald Dunkel:

Package: aptitude
Version: 0.8.5-1

If a package with broken postinst is marked for reinstall,
and if the deb file has been removed from /var/cache/apt/\
archives, then aptitude throws an internal error popup
instead of downloading the file again.


Thanks for the report.  Do you know the exact error string?  It would be
easier to track that way.

--
Manuel A. Fernandez Montecelo 

Bug#851578: python-numba: fails to install: SyntaxError: invalid syntax

[Daniel Stender]

... in.

I'm going to upload this already.

There are a couple of problems left, I'll file bug reports on them so that they 
could be
discussed, focused on if wanted.

DS

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
http://www.danielstender.com/

Bug#855415: installation-reports: Debian-Testing fails to reboot after installation.

[Michael Siemmeister]

Package: installation-reports
Severity: important

Dear Maintainer,

* What led up to the situation?
I first tried the mailing-list: 
https://lists.debian.org/debian-user/2017/02/msg00602.html

---just copied from the mailing-list---
Last week I tried to install Debian in a virtual-box. Currently I use
Debian 8.7 for running the virtual-box program. I managed to install
Debian stable without any problems. Then I cloned the virtual-box and
tried an upgrade to Debian-testing. I think, it worked. After a while
I shut down the virtual-machine. When trying to reboot, it did not
start properly. I just got some messages like 'Created slice User
Slice of Debian-gdm.', 'Starting User Manager ofr UID 117.', and
finally 'Started Daily apt activities.'. Then the virtual display just
starts blinking. Nothing else happens. After three minutes or so the
display freezes.

Then I thought, okay, maybe the virtualbox program has got a bug. So,
I downloaded the Debian-Testing-DVD-1 via jigdo-lite and copied it to
a USB drive. I tried to install Debian-Testing on an old laptop, a
Toshiba Satellite from 2009. Unfortunately I don' remember the exact
model number. I had already installed Debian Stable without any
problems on that laptop some months ago. The Debian-Testing installer
worked fine and finally, it asked me to reboot the PC. After rebooting
similar problems occured. There was a message about the graphics card
and after 30 seconds the display started blinking. Nothing else
happened.

As I have written above these errors only occured with Debian-Testing.
Debian-Stable worked fine on Virtualbox and the Toshiba laptop. So, I
don't think there are some hardware problems.
---END of copied text---

---ANOTHER MAIL---
Nevertheless, as written in my first mail, I got problems with
installing Debian-Testing on my old Toshiba laptop. I just checked the
model number. It's a Toshiba Satellite P300-1BB. Model No.:
PSPCCE-01K001GR. Debian-Stable Jessie 8.5 worked fine without any
problems during the installation. So I think the hardware is okay.

 I tried to install Debian-Testing on this laptop directly to the
harddisk without virtualbox. During the installation there were no
problems. But after the first boot, I keep getting these messages:

[drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel modesetting for
R600 or later requires firmware-amd-graphics.
kvm: disabled by bios

Then the display starts blinking and nothing else happens.
---END of copied text---


* What exactly did you do (or not do) that was effective (or
 ineffective)?
As suggested in the mailing list I tried 'nomodeset':
---copied from mailing list---
I just tried it. Since I did not know anything about 'nomodeset', I
looked for it on the internet. I found this link:

https://support.reliablesite.net/kb/a240/how-to-set-nomodeset-into-the-grub-bootloader-debian-and-ubuntu-intel-core-i7-3770.aspx

and followed it until step 5, so I did: 
"""
2. After completion reboot the server as normal but interrupt the
default boot in GRUB by hitting the arrow keys.
 
3. Highlight the very first, top option and hit 'e'
 
4. Scroll down on the editor and look for the line that starts with
'linux'. Once found append to the end of the line with 'nomodeset'
 
5. Press 'F10' to boot. The server should boot and not disconnect if
done correctly.
"""

I am not sure if I have done it correctly. The 'linux' line looked as
follows before pressing 'F10'.


linux /boot/vmlinuz-4.9.0-1-amd64 root=UUID= ro quiet
nomodeset
(it is one line originally, despite being two in this mail)

The result was:

[drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!
kvm: disabled by bios
kvm: disabled by bios

Then the screen started blinking again.
---END of copied text---





-- Package-specific info:

Boot method: USB-drive
Image version: Debian-Testing, 2017-02-06 (I think so)
Date: 2017-02-15 

Machine: Toshiba Satellite P-300-1BB
Partitions: I don't know. Just selected automatic partitioning or something 
like this. 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:
The installation process went smoothly. The first problems occured after the 
suggested reboot(after GRUB installation it asks you to reboot). I have written 
about my problems above.

---
Michael

Bug#841527: reportbug-ng: Missing installed packages versions in the reports

[Andrey Gursky]

Hi,

looking for a quick (scriptable) way to obtain the exact versions of
package dependencies [1] I've noticed the same bug. Would be nice if
such function could be implemented in dpkg instead of a huge python
function, that then would be duplicated in bugreport / bugreport-ng.

Regards,
Andrey

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824603#37

Bug#855336: make hangs when synchronizing output and redirecting to null

[Norbert Lange]

Hello,

Tried reproducing it at work (where it first happened on a build server).
On my PC at home with 4 cores / 12 thread the bug reproduces always
On a 6 core / 12 threads Xeon Server  the bug reproduces always
On my work PC with 4 cores / 4 threads running in a VMware Instance it
doesnt reproduce.
All running Debian Stretch with current updates.

Maybe you want to add infos about your system?
>From the sample of 3: Hyperthreading or >= 8 threads or runnin on bare
metal instead of in a VM could provoke the bug.

Further make 4.1 was uploaded to Debian Stretch on 16h january, the
issue appeared on 19th january on the server.
So disregard what I said about this not being an upstream issue - its
actually quite possible.


Heres a dump via attached gdb (step wont do anything so it seems that
the thread is blocked):

(gdb) thread apply all bt

Thread 1 (process 12177):
#0  0x7f476c156962 in do_fcntl (fd=1, cmd=7, arg=0x5595eae95ea0)
at ../sysdeps/unix/sysv/linux/fcntl.c:31
#1  0x7f476c156a29 in __GI___libc_fcntl (fd=,
cmd=) at ../sysdeps/unix/sysv/linux/fcntl.c:71
#2  0x5595eac795a7 in output_dump ()
#3  0x5595eac753b1 in reap_children ()
#4  0x5595eac76224 in new_job ()
#5  0x5595eac81a7d in ?? ()
#6  0x5595eac8035e in ?? ()
#7  0x5595eac80b3e in ?? ()
#8  0x5595eac81d9f in update_goal_chain ()
#9  0x5595eac67719 in main ()

further it has a few file handles open (apart from the 3 basic ones):
one pipe
two temp files which don't exist anymore

I`ll have to compile make with debuginfo if you need more (gonna take
a few days)

Kind Regards. Norbert

2017-02-17 15:24 GMT+01:00 James Cowgill :
> Hi,
>
> On 16/02/17 21:52, Norbert Lange wrote:
>> Package: make
>> Version: 4.1-9
>> Severity: important
>>
>> Dear Maintainer,
>>
>> running the attached Makefile will hang the process,
>> if multiple jobs are used then the process wont respond to a
>> TERM and has to be killed.
>>
>> The very same issue is observed with make-guile.
>>
>> I believe this to not be an upstream bug, since I observed this
>> only a couple weeks ago after an upgrade.
>> Unfortunatly I can`t pinpoint a date or version.
>
> I cannot reproduce this bug.
>
> Also, make has not been updated in testing for almost a year so if it
> only started happening recently, something else probably caused it.
>
> Running 'make -d -O' (although this may be difficult if the bug requires
> redirection to /dev/null) or the output or running make inside gdb and
> finding where it hangs might help in diagnosing this.
>
> Thanks,
> James
>
>

Bug#855414: python-pyvmomi-doc: include sample code

[Ben Harris]

Package: python-pyvmomi-doc
Version: 5.5.0-2014.1.1-3
Severity: wishlist

The upstream pyVmomi distribution includes a couple of example Python 
scripts in the "samples" directory.  Could you please include them in 
the python-pyvmomi-doc package, probably in 
/usr/share/doc/python-pyvmomi-doc/examples?  That would make it rather 
easier for a beginner like me to know where to start.


--
Ben Harris, University of Cambridge Information Services.

Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Markus Koschany]

On 17.02.2017 14:24, Allen Hadden wrote:
>> That is strange. You have mentioned in your previous email that you
>> downgraded tomcat7 in Wheezy to version 7.0.28-4+deb7u4. Are you sure
>> that you are not comparing this version with 7.0.28-4+deb7u10? Why
>> didn't you downgrade to 7.0.28-4+deb7u9 in the first place? This would
>> explain the diff output because we had to make some bigger changes to
>> the http parser classes in one of the previous security updates before
>> +deb7u9 in Wheezy.
> 
> We downgraded to +deb7u4 because it was the last known good version on
> the system where we first noticed the problem.  +deb8u9 is not available
> on the security update server:

You can download previous versions of Tomcat 7 from snapshots.debian.org

http://snapshot.debian.org/package/tomcat7/

Let's recapitulate: You are currently running +deb7u4 from April 2016
which is the last good version for you and you see 400 errors when you
use +deb7u5 or any later version up to +deb7u10, correct? Then this is a
different issue because Samuel reported that the 400 errors occurred
when he upgraded from 7.0.56-3+deb8u7 to 7.0.56-3+deb8u8 in Jessie

> 
> http://security.debian.org/pool/updates/main/t/tomcat7/
> 
> I guess we can distill my last email down a little.  Let's focus on
> PermissionCheck.class.  It is definitely in the +deb7u10 package.  You
> can use the following steps to confirm:

[...]

> The find command finds shows nothing, but the official package contains
> the class file.  Can you explain why?

Sure, the original tarball does not contain PermissionCheck.java but in
order to resolve CVE-2016-6794 we had to patch Tomcat 7 again and
applied this patch:

https://anonscm.debian.org/cgit/pkg-java/tomcat7.git/diff/debian/patches/CVE-2016-6794.patch?h=wheezy&id=b0a66d829f152186b8e260dfcffa919b0b694cf4

This was done for +deb7u7. The class is present in debian/patches.

[...]
> 
> As I see it, these are the possibilities:
> 
> a) The build was done from a tag other than debian/7.0.28-4+deb7u10.
> b) It was done from that tag, but there were other .class files
> present in the output directory (i.e. it wasn't a clean build).
> 
> Any thoughts?

I think none of the above happened and the error is not caused because
of an unclean environment.





signature.asc
Description: OpenPGP digital signature

Bug#854938: RFS: wxmaxima/16.12.2-2

[Sean Whitton]

On Fri, Feb 17, 2017 at 10:31:15PM +0500, Andrey Rahmatullin wrote:
> On Fri, Feb 17, 2017 at 10:01:55AM -0700, Sean Whitton wrote:
> > Secondly, you should revert the compat change in order to be sure of
> > getting a freeze exception for the fix of the important bug.
> Too late, as the previous wxmaxima upload was done after the freeze.

Thank you for noticing this, Andrey.

Gunter: I can upload this to unstable for you if you fix the changelog
terminology.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#824603: Same here, unusable meld due to python error

[Andrey Gursky]

Hi Massimo,

On Fri, 17 Feb 2017 16:55:15 +0100 Massimo Corà wrote:

> Attached is the stack trace

Please tell us what versions of packages
   libgtk-3-0
   gir1.2-gtk-3.0
   libgtksourceview-3.0-1
   gir1.2-gtksource-3.0
are you using by running, e.g.:
dpkg -l | grep -e libgtk-3-0 -e gir1.2-gtk-3.0 -e libgtksourceview-3.0-1 -e 
gir1.2-gtksource-3.0

Regards,
Andrey

P.S. I'm wondering, how to gather "Version of packages meld depends on"
without using reportbug...

Bug#855413: xautolock: Typo in xautolock man page

[Alexander Bliskovsky]

Package: xautolock
Version: 1:2.2-5.1
Severity: minor

Dear Maintainer,

There is a typo in the documentation of --detectsleep in xautolock's man page:

This option is typically used to avoid locker program to be
launched when awaking a laptop computer.

I suggest the following change:

This  option is typically used to prevent the locker program from
being launched when awaking a laptop computer

Thanks!

-- 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/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 xautolock depends on:
ii  libc6 2.24-9
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1
ii  libxss1   1:1.2.2-1

Versions of packages xautolock recommends:
ii  i3lock  2.8-1
ii  suckless-tools  42-2

xautolock suggests no packages.

-- no debconf information

Bug#855337: please add vgauth service to open-vm-tools

[Oliver Kurth]

Hi Bernd,


vgauth is a service that allows authentication in the guest using SAML tokens. 
It's actually more useful in guests running under vSphere than in guests 
running under Workstation/Fusion, and can be used for guest operations 
initiated from the datacenter. It has nothing to do with having a desktop or 
not.


Oliver



From: Bernd Zeimetz 
Sent: Friday, February 17, 2017 2:07:31 AM
To: Oliver Kurth; 855...@bugs.debian.org
Subject: Re: Bug#855337: please add vgauth service to open-vm-tools

Hi,

> open-vm-tools now includes the vgauth service. This is installed by the
> open-vm-tools package, however the service is not running.

what is this service needed for? Should it run on servers without
desktop, too?


thanks,

bernd

>
>
> I created this simple service file:
>
>
> [Unit]
> Description=Authentication service for virtual machines hosted on VMware
> Documentation=https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_vmware_open-2Dvm-2Dtools&d=DwICJg&c=uilaK90D4TOVoH58JNXRgQ&r=oHeYwLSPkRE9YQPISb_awkWjWigW3oPkIDc-ePsrBjY&m=Hxt7uHiOJgW0Q5cEfi-Mc7VYoTG3CtEVq62h2y86bLk&s=Uqb5kaRdZs_hThVXZlQxryHbsTgSF8OYHf4A5DcWiNc&e=
> ConditionVirtualization=vmware
> PartOf=open-vm-tools.service
>
> [Service]
> ExecStart=/usr/bin/VGAuthService
> TimeoutStopSec=5
>
> [Install]
> RequiredBy=open-vm-tools.service
>
> I started the service, and checked that it is running:
>
>
> vmware@debian:~$ sudo systemctl start open-vm-tools-vgauth.service
> vmware@debian:~$ sudo systemctl status open-vm-tools-vgauth.service
> ● open-vm-tools-vgauth.service - Authentication service for virtual
> machines hosted on VMware
>Loaded: loaded (/etc/systemd/system/open-vm-tools-vgauth.service;
> disabled; vendor preset: enabled)
>Active: active (running) since Thu 2017-02-16 13:52:08 PST; 5s ago
>  Docs: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_vmware_open-2Dvm-2Dtools&d=DwICJg&c=uilaK90D4TOVoH58JNXRgQ&r=oHeYwLSPkRE9YQPISb_awkWjWigW3oPkIDc-ePsrBjY&m=Hxt7uHiOJgW0Q5cEfi-Mc7VYoTG3CtEVq62h2y86bLk&s=Uqb5kaRdZs_hThVXZlQxryHbsTgSF8OYHf4A5DcWiNc&e=
>  Main PID: 2112 (VGAuthService)
> Tasks: 1 (limit: 19660)
>CGroup: /system.slice/open-vm-tools-vgauth.service
>└─2112 /usr/bin/VGAuthService
>
> Thanks,
>
> Oliver
>
>

--
 Bernd ZeimetzDebian GNU/Linux Developer
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__bzed.de&d=DwICJg&c=uilaK90D4TOVoH58JNXRgQ&r=oHeYwLSPkRE9YQPISb_awkWjWigW3oPkIDc-ePsrBjY&m=Hxt7uHiOJgW0Q5cEfi-Mc7VYoTG3CtEVq62h2y86bLk&s=mE4KA0PFOv4UVWZxujKhRo9sj0D1zTirs-e-KpKRq_4&e=
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.debian.org&d=DwICJg&c=uilaK90D4TOVoH58JNXRgQ&r=oHeYwLSPkRE9YQPISb_awkWjWigW3oPkIDc-ePsrBjY&m=Hxt7uHiOJgW0Q5cEfi-Mc7VYoTG3CtEVq62h2y86bLk&s=tlaz6I2HFDE08xZtoHKT4vLF8Kj7Nt-1PcKNu4nx_h4&e=
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#848523: More info

[Maximiliano Curia]

Control: severity -1 normal

¡Hola Ben!

El 2017-01-23 a las 09:54 -0800, Ben Longbons escribió:
Sorry, I've since upgraded my *entire* system from testing to 
unstable, and the problem went away at some point.


If it wasn't a bug in some dependency, my guess is that something had 
migrated to testing without all of its true dependencies having 
migrated. There are a lot of ways that that can happen - plugins, 
changes in the *use* of some already-existing library call (e.g. 
accepting new enum values).


You can debootstrap from 
http://snapshot.debian.org/archive/debian/20161219T152404Z/ to 
investigate the underlying cause, since if it's a missing dependency 
problem, it *will* cause problems again sooner or later.



But here's the information you requested, for what it's worth:


kwin hasn't entered into testing because of this bug and the #848524 report, 
this package was installed from sid, bringing only a small part of it's 
dependencies, from the original report:


ii  libkwinglutils9   4:5.8.2-1+b1
ii  libkwinxrenderutils9  4:5.8.2-1+b1

There are some parts in your kwin-x11 that weren't correctely upgraded, I'll 
bump this runtime dependencies.


Happy hacking,
--
"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do it blows your whole leg off."
-- Bjarne Stroustrup
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#854938: RFS: wxmaxima/16.12.2-2

[Andrey Rahmatullin]

On Fri, Feb 17, 2017 at 10:01:55AM -0700, Sean Whitton wrote:
> Secondly, you should revert the compat change in order to be sure of
> getting a freeze exception for the fix of the important bug.
Too late, as the previous wxmaxima upload was done after the freeze.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#848524: kwin-wayland: rapid memory leak

[Maximiliano Curia]

Control: severity -1 normal

¡Hola Ben!

El 2016-12-17 a las 20:19 -0800, Ben Longbons escribió:
Package: kwin-wayland 
Version: 4:5.8.4-1 
Severity: grave 
Justification: renders package unusable


Since kwin-x11 was being even crashier than usual, I tried the other 
Plasma (wayland) entry for a change.



To my great joy, it worked flawlessly ... for the first several minutes.


After that, however, everything became nonresponsive, and I observed 
kwin-wayland using over 2GB each of both RAM and SWAP as I killed it.



I'm not desperate enough to use GNOME, so I'm stuck on the CLI for now.


kwin-wayland and the Plasma (wayland) desktop sessions are work in progress 
versions. Packaged to be tested, but not (currently) real alternatives. I'll 
add this information to the package descriptions of kwin-wayland and 
plasma-workspace-wayland.



Versions of packages kwin-wayland depends on:
ii  kwayland-integration 5.8.4-1 
ii  kwin-common  4:5.8.4-1 
ii  kwin-wayland-backend-drm [kwin-wayland-backend]  4:5.8.2-1+b1


Your kwin was not completely upgraded. I guess this shows a missing stronger 
runtime dependency.


Happy hacking,
--
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense."
-- Edsger W. Dijkstra
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature