Bug#883653: lintian: Fails to process preseed/1.90

[Niels Thykier]

Package: lintian
Version: 2.5.60
Severity: normal

Hi,

Lintian fails to process preseed/1.90 with the following error:

"""
ERROR: xgettext failed to generate PO template file because there is non-ASCII
   string marked for translation. Please make sure that all strings marked
   for translation are in uniform encoding (say UTF-8), then 
ESC[1m*prepend*ESC[0m the
   following line to POTFILES.in and rerun intltool-update:

   [encoding: UTF-8]

Command /usr/share/intltool-debian/intltool-update --gettext-package=test --pot 
returned: 1
internal error: cannot run po-debconf check on package source:preseed/1.90
warning: skipping check of source:preseed/1.90
"""

(Related bug #849912).

That means we only publish partial results for preseed and we may fail
to trigger an auto-reject if preseed has a more serious issue hidden
behind it (runtime errors in lintian does not trigger an auto-reject
in dak).

Thanks,
~Niels

Bug#883652: RM: cliofetion -- RoQA; Service provider stopped; Orphaned; Upstream dead

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: levin...@gmail.com a...@debian.org asias.he...@gmail.com

Hello all,

As the continuation of Bug #882673 and Bug #882675, I'm filing RM bugs against 
package cliofetion for the same reasons.

* Upstream dead for more than 5 years;
* Popcon approaching zero;
* Package orphaned already;
* RC-buggy (openssl 1.1 migration; see also Bug#859053)
* As a plugin library to provide IM integration into pidgin, its service
 provider, China Mobile, has stopped the old fetion service and heads to a new 
 one focusing on enterprise use with different web API. This effectively made 
 the library useless.

CC-ing original packaging maintainers (before orphaning) and original software 
author.

Regards,
Boyuan Yang

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

Bug#883053: dependency-on-python-version-marked-for-end-of-life doesn't match python:any dependency

[Niels Thykier]

On Wed, 29 Nov 2017 20:43:05 +0900 Chris Lamb  wrote:
> Hi Matthias,
> 
> > As seen with the dput-ng binary, the
> > dependency-on-python-version-marked-for-end-of-life doesn't match the 
> > python:any
> > dependency.
> 
> As I understand the code, the following should work:
> 
>   --- a/checks/python.pm
>   +++ b/checks/python.pm
>   @@ -83,7 +83,7 @@ sub _run_binary {
>for my $dep (@PYTHON2) {
>tag 'dependency-on-python-version-marked-for-end-of-life',
>  "($field: $dep)"
>   -  if $info->relation($field)->implies($dep);
>   +  if 
> $info->relation($field)->restriction_less->implies($dep);
>}
>}
>}
> 
> However, it still does not match. (NB. there is no relation_noarch for
> Binary.pm, which might be a symptom of the root cause..)
> 
> My testcase is:
> 
> [...]
> 
> 
> Any pointers, Niels et al.? :)
> 
> 
> [...]

I think it would just be a question of using "python2:any" instead of
"python2" in the @PYTHON2 list.  As I recall, Lintian knows that "X:any"
implies "X" (but "X" does not imply "X:any" as X:any is a superset of X).

Thanks,
~Niels

Bug#880590: RFS: webmin/1.860-1 [ITP]

[Chris Knadle]

> Hmm, I'm sure I dput it, but I haven't got mentor.d.n reply yet, too.
> Maybe I'll retry later.

In order to make a new upload to Mentors, it's necessary to first log
into the Mentors website, visit the page for the uploaded package, and
*delete* it using the "Delete this package" link within the 'Details
about package "webmin"' section.

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

I believe uploads eventually "time out" and are auto-removed from the
Mentors website -- offhand I don't recall what the timeout period is,
but it's fairly long. (> 1 month, I think.)

Thanks for your work on packaging Webmin.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

Le 6 déc. 2017 07:24, "Julien Aubin"  a écrit :



2017-12-06 7:07 GMT+01:00 Julien Aubin :

>
>
> 2017-12-06 3:34 GMT+01:00 Julien Aubin :
>
>>
>>
>> Le 5 déc. 2017 23:08, "Luca Boccassi"  a écrit :
>>
>> On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote:
>> > To help debugging, could you provide me please some link to a newer
>> > NVidia
>> > driver release built for stretch please (and some notice to install
>> > it) ?
>>
>> Unfortunately I don't think we have anything that can be used in
>> Stretch - IIRC both 384 and 387 dependencies are structured for the
>> glvnd transition, so they can't be installed on Stretch.
>>
>> > Thus :
>> > - If I disable from a custom xorg.conf file module glx everything
>> > loads
>> > fine (as long as I use lightdm as a login manager)
>> >
>> > Thanks a lot.
>>
>> Could you clarify what this means? You are manually blacklisting glx?
>>
>>
>>
> The fact driver 38x cannot be installed on Stretch is very bad as it
> prevents newer GPUs from working w/ Debian stable. Newer low-end NVidia
> MX1** are already impacted.
>
> FYI here's what I get in kern.log when enabling glx in xorg :
>
> ec  6 06:59:44 pccorei7-4770 kernel: [ 3682.820990] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:53 pccorei7-4770 kernel: [ 3691.431679] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:53 pccorei7-4770 kernel: [ 3691.753169] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:54 pccorei7-4770 kernel: [ 3692.545921] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:54 pccorei7-4770 kernel: [ 3692.866820] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:55 pccorei7-4770 kernel: [ 3693.542921] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:55 pccorei7-4770 kernel: [ 3693.864460] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:56 pccorei7-4770 kernel: [ 3694.539028] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:56 pccorei7-4770 kernel: [ 3694.860824] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:57 pccorei7-4770 kernel: [ 3695.536803] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:57 pccorei7-4770 kernel: [ 3695.876240] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:55 pccorei7-4770 kernel: [ 3873.365928] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:55 pccorei7-4770 kernel: [ 3873.706339] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:56 pccorei7-4770 kernel: [ 3874.563884] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:56 pccorei7-4770 kernel: [ 3874.885761] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:57 pccorei7-4770 kernel: [ 3875.562088] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:57 pccorei7-4770 kernel: [ 3875.901835] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:58 pccorei7-4770 kernel: [ 3876.809216] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:58 pccorei7-4770 kernel: [ 3877.130778] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:59 pccorei7-4770 kernel: [ 3877.807965] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:59 pccorei7-4770 kernel: [ 3878.144767] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:03:37 pccorei7-4770 kernel: [ 3915.290650] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:03:37 pccorei7-4770 kernel: [ 3915.611177] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:03:38 pccorei7-4770 kernel: [ 3916.320719] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:03:38 pccorei7-4770 kernel: [ 3916.641984] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:03:39 

Bug#883651: RFS: qtdbusextended/0.0.3-1 [ITP] -- Extended DBus interface for Qt

[Boyuan Yang]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org

Dear mentors,

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

 * Package name: qtdbusextended
   Version : 0.0.3-1
   Upstream Author : Nemo Mobile / Jolla Ltd.
 * URL : https://github.com/nemomobile/qtdbusextended
 * License : LGPL-2.1+
   Section : misc

  It builds those binary packages:

libdbusextended-qt5-1 - Extended DBus interface for Qt
 libdbusextended-qt5-dev - Extended DBus interface for Qt (development files)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/q/qtdbusextended/qtdbusextended_0.0.3-1.dsc

  Git packaging repository:

http://anonscm.debian.org/git/collab-maint/qtdbusextended.git

  Changes since the last upload:

 qtdbusextended (0.0.3-1) unstable; urgency=medium
 .
   * Initial release. Closes: #883646

Regards,
Boyuan Yang


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

Bug#883650: libev: please update libev's homepage url

[Boyuan Yang]

Source: libev
Severity: minor

The canonical upstream homepage url has switched to
http://software.schmorp.de/pkg/libev.html, though the website is not available
temporarily now.

Regards,
Boyuan Yang



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

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

Bug#883648: vcdimager: FTBFS with libcdio 1.0.0

[Steve Langasek]

Package: vcdimager
Version: 0.7.24+dfsg-0.3
Severity: serious
Tags: patch sid
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Nicolas,

With the upload of libcdio 1.0.0-1 to unstable, vcdimager now fails to build
because it references deprecated compatibility names that have been dropped
from the libcdio API in this release.

I have uploaded the attached patch to Ubuntu, which fixes the build failure. 
Please consider applying it in Debian as well.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru vcdimager-0.7.24+dfsg/debian/control 
vcdimager-0.7.24+dfsg/debian/control
--- vcdimager-0.7.24+dfsg/debian/control2017-12-05 18:53:31.0 
-0800
+++ vcdimager-0.7.24+dfsg/debian/control2017-12-05 20:50:31.0 
-0800
@@ -1,8 +1,7 @@
 Source: vcdimager
 Section: otherosfs
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Nicolas Boullis 
+Maintainer: Nicolas Boullis 
 Build-Depends: debhelper (>= 9), libxml2-dev, libpopt-dev, texinfo, 
libcdio-dev (>= 0.76), libiso9660-dev, dpkg-awk, pkg-config, dh-autoreconf
 Build-Conflicts: libpopt0 (= 1.7-1) [m68k], libpopt0 (= 1.7-2) [m68k], 
libpopt0 (= 1.7-3) [m68k]
 Standards-Version: 4.1.1
diff -Nru vcdimager-0.7.24+dfsg/debian/patches/cdio-1.0-compat 
vcdimager-0.7.24+dfsg/debian/patches/cdio-1.0-compat
--- vcdimager-0.7.24+dfsg/debian/patches/cdio-1.0-compat1969-12-31 
16:00:00.0 -0800
+++ vcdimager-0.7.24+dfsg/debian/patches/cdio-1.0-compat2017-12-05 
20:50:31.0 -0800
@@ -0,0 +1,237 @@
+Description: compatibility with libcdio 1.0.0
+ The libcdio 1.0.0 release drops various deprecated aliases.  Fix vcdimager
+ for compatibility.
+Author: Steve Langasek 
+Last-Update: 2017-12-05
+Forwarded: no
+
+Index: vcdimager-0.7.24+dfsg/include/libvcd/info.h
+===
+--- vcdimager-0.7.24+dfsg.orig/include/libvcd/info.h
 vcdimager-0.7.24+dfsg/include/libvcd/info.h
+@@ -455,12 +455,12 @@
+   /*!
+ Get the VCD info list.
+   */
+-  CdioList *vcdinfo_get_offset_list(const vcdinfo_obj_t *p_vcdinfo);
++  CdioList_t *vcdinfo_get_offset_list(const vcdinfo_obj_t *p_vcdinfo);
+ 
+   /*!
+ Get the VCD info extended offset list.
+   */
+-  CdioList *vcdinfo_get_offset_x_list(const vcdinfo_obj_t *p_vcdinfo);
++  CdioList_t *vcdinfo_get_offset_x_list(const vcdinfo_obj_t *p_vcdinfo);
+ 
+   /*!
+ Get the VCD info offset multiplier.
+Index: vcdimager-0.7.24+dfsg/lib/data_structures.h
+===
+--- vcdimager-0.7.24+dfsg.orig/lib/data_structures.h
 vcdimager-0.7.24+dfsg/lib/data_structures.h
+@@ -28,7 +28,7 @@
+ 
+ CdioListNode_t *_vcd_list_at (CdioList_t *list, int idx);
+ 
+-void _vcd_list_sort (CdioList_t *p_list, _cdio_list_cmp_func cmp_func);
++void _vcd_list_sort (CdioList_t *p_list, _cdio_list_cmp_func_t cmp_func);
+ 
+ /* n-way tree */
+ 
+Index: vcdimager-0.7.24+dfsg/lib/mpeg.h
+===
+--- vcdimager-0.7.24+dfsg.orig/lib/mpeg.h
 vcdimager-0.7.24+dfsg/lib/mpeg.h
+@@ -103,7 +103,7 @@
+   unsigned vbvsize;
+   bool constrained_flag;
+ 
+-  CdioList *aps_list; /* filled up by vcd_mpeg_source */
++  CdioList_t *aps_list; /* filled up by vcd_mpeg_source */
+   double last_aps_pts; /* temp, see ->packet */
+   
+ } shdr[3];
+Index: vcdimager-0.7.24+dfsg/lib/info_private.c
+===
+--- vcdimager-0.7.24+dfsg.orig/lib/info_private.c
 vcdimager-0.7.24+dfsg/lib/info_private.c
+@@ -136,7 +136,7 @@
+   ret &= vcdinf_visit_pbc (obj, n + 1, tmp, true);
+ 
+   _vcd_list_sort (obj->extended ? obj->offset_x_list : obj->offset_list, 
+-  (_cdio_list_cmp_func) vcdinf_lid_t_cmp);
++  (_cdio_list_cmp_func_t) vcdinf_lid_t_cmp);
+ 
+   /* Now really complete the offset table with LIDs.  This routine
+  might obviate the need for vcdinf_visit_pbc() or some of it which is
+Index: vcdimager-0.7.24+dfsg/lib/dict.h
+===
+--- vcdimager-0.7.24+dfsg.orig/lib/dict.h
 vcdimager-0.7.24+dfsg/lib/dict.h
+@@ -88,7 +88,7 @@
+   vcd_assert (key != NULL);
+ 
+   node = _cdio_list_find (obj->buffer_dict_list,
+-(_cdio_list_iterfunc) _dict_key_cmp,
++(_cdio_list_iterfunc_t) _dict_key_cmp,
+ (char *) key);
+   
+   if (node)
+@@ -106,7 +106,7 @@
+   

Bug#883649: libev: Please package latest libev version (4.24)

[Boyuan Yang]

Source: libev
Severity: minor

It would be great if libev 4.24 could enter Debian sooner or later.

Regards,
Boyuan Yang



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

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

Bug#808847: more spam

[Daniel Pocock]

On 06/12/17 02:45, Scott Kitterman wrote:
> 
> 
> On December 5, 2017 10:35:50 AM EST, Daniel Pocock  wrote:
>>
>> I received feedback from somebody that my mail server wasn't accepting
>> messages from one of their servers because of this issue.
>>
>> I manually changed my settings to the new value and I notice that
>> additional spam is now getting through.
>>
>> Maybe it is better to be strict and expect non-spammers to use SPF
>> correctly.
> 
> This is fixed in stable, so not sure why you unarchived the bug.
> 
> Personally, I thought the old default was reasonable, but too many people 
> whined.
> 
> What is it you want to have happen?
> 

The old default (in jessie) was stricter and potentially reduces the
amount of spam.

The old default also reduces the number of good messages that are
received, but the sender receives a bounce telling them why their
message couldn't be delivered with a helpful link to help them
understand how to fix their SPF entry in DNS.

If it went back to a stricter default, the people who whined can
manually whitelist senders with bad/missing SPF records or override the
default.

At this stage, I'm not asking to reopen the bug or change the default
again immediately, I think it may be useful to gather more data on the
issue to see if there are other opinions and also compare against other
distributions and public mail services.

Regards,

Daniel

Bug#883647: Updated Russian debconf translation

[Sergey Alyoshin]

Package: courier
Version: 0.78.0-2
Priority: wishlist
Tags: l10n patch


ru.po.gz
Description: GNU Zip compressed data

Bug#883521: texlive-bin: FTBFS with poppler 0.61.1

[Hilmar Preuße]

On 06.12.2017 02:05, Norbert Preining wrote:

Hi,

> (strange enough this bug report didn't arrive at my inbox)
> 
Didn't get it either; I just got noticed b/c the bug was manipulated later.
I guess the reason is the size limitation in Debian mailing lists. The
bug reporter attached the full uncompressed build log, which gave us a
mail size of 800KB.

Emilio: please don't send uncompressed logs.

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#883580: debian-installer: arm64: please ship dtb files

[Andre Heider]

On Tue, 5 Dec 2017 14:07:46 + Leif Lindholm 
 wrote:

Please don't ship dtb files at all, including the kernel images.

If firmware does not come with hardware description, that is a
shortcoming of the firmware. If a newer kernel cannot be booted with
an existing device tree, then that is a bug and the kernel should be
patched.


Ok, so in your world a distribution should not ship any dtb files, 
because the manufacturer's firmware is bug-free and feature complete on 
day one.


That's nice, but doesn't sound like the real world at all.

> By all means, put a tree of verified actually working device trees
> somewhere for platforms known to be provided with bad versions from
> their manufacturer.

That tree is the sum of the dtb files of the corresponding kernel, which 
this bug report is about. Those may not adhere to your definition of 
verified, but please don't forget that there're two separate worlds out 
there: upstream and downstream. Debian's current way of booting a kernel 
release with its dtb ensures those world never collide, and I think that 
is a very wise choice.


I don't know what devices you work on, but I have a couple of different 
consumer armhf and arm64 devices, spread out over different 
architectures. All their device trees are updated every single kernel 
release. Often it's for new drivers like mmc, pci, net, dri etc., which 
obviously the installer could make use of. Bindings are merged with the 
driver, so of course I want the dtb matching its kernel!

Bug#883646: ITP: qtdbusextended -- Extended DBus interface for Qt

[Boyuan Yang]

Package: wnpp
Severity: wishlist
Owner: Boyuan Yang <073p...@gmail.com>
X-Debbugs-CC: debian-de...@lists.debian.org 
pkg-deepin-de...@lists.alioth.debian.org

* Package name: qtdbusextended
  Version : 0.0.3
  Upstream Author : Nemo Mobile / Jolla Ltd.
* URL : https://github.com/nemomobile/qtdbusextended
* License : LGPL-2.1
  Programming Lang: C++/Qt
  Description : Extended DBus interface for Qt

 Qtdbusextended library provides several additional features to the original
 QDbusAbstractInterface class, includes:
 - Handling of PropertiesChanged signal in DBus Properties Interface
 - the GetAll method in DBus Properties Interface
 - asynchronous alternative to original synchronous QtDBus properties mechanism
 - an alternative cache mechanism for Qt DBus traffic

This library is the build-dependency to several Deepin [1] softwares. Instead
of bundling them, we decided to package and maintain it inside Debian pkg-deepin
group [2].

Upstream Nemo Mobile hasn't seen activities in this project recently but still
keeps it maintained. Staff from Deepin Tech. are also willing to fork it [3] and
continue maintenance of the library were there any bugs found in it.

Regards,
Boyuan Yang

[1] https://www.deepin.org/en/
[2] https://alioth.debian.org/projects/pkg-deepin/
[3] http://github.com/linuxdeepin/qtdbusextended

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

Bug#883634: telegram-desktop: Segmentation fault

[Коля Гурьев]

Hello!

06.12.2017 03:21, Jiaxun Yang пишет:
> There is a segmentation fault happened during the start of telegram-desktop:
> 
> QApplication: invalid style override passed, ignoring it.
> 
> (telegram-desktop:1827): GLib-GObject-WARNING **: cannot register
> existing type 'GdkDisplayManager'
> 
> (telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
> 'result != 0' failed
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
> failed
> 
> (telegram-desktop:1827): GLib-GObject-WARNING **: invalid (NULL) pointer
> instance
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> 
> (telegram-desktop:1827): GLib-GObject-WARNING **: invalid (NULL) pointer
> instance
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> 
> (telegram-desktop:1827): GLib-GObject-WARNING **: cannot register
> existing type 'GdkDisplay'
> 
> (telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
> 'result != 0' failed
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_type_register_static: assertion 'parent_type > 0' failed
> 
> (telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
> 'result != 0' failed
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
> failed

This is very similar to Bug#859172.

> Versions of packages telegram-desktop recommends:
> ii  libappindicator1  0.4.92-5

Try to install the libappindicator3-1 package instead (or in addition
to) already installed libappindicator1.

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

2017-12-06 7:07 GMT+01:00 Julien Aubin :

>
>
> 2017-12-06 3:34 GMT+01:00 Julien Aubin :
>
>>
>>
>> Le 5 déc. 2017 23:08, "Luca Boccassi"  a écrit :
>>
>> On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote:
>> > To help debugging, could you provide me please some link to a newer
>> > NVidia
>> > driver release built for stretch please (and some notice to install
>> > it) ?
>>
>> Unfortunately I don't think we have anything that can be used in
>> Stretch - IIRC both 384 and 387 dependencies are structured for the
>> glvnd transition, so they can't be installed on Stretch.
>>
>> > Thus :
>> > - If I disable from a custom xorg.conf file module glx everything
>> > loads
>> > fine (as long as I use lightdm as a login manager)
>> >
>> > Thanks a lot.
>>
>> Could you clarify what this means? You are manually blacklisting glx?
>>
>>
>>
> The fact driver 38x cannot be installed on Stretch is very bad as it
> prevents newer GPUs from working w/ Debian stable. Newer low-end NVidia
> MX1** are already impacted.
>
> FYI here's what I get in kern.log when enabling glx in xorg :
>
> ec  6 06:59:44 pccorei7-4770 kernel: [ 3682.820990] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:53 pccorei7-4770 kernel: [ 3691.431679] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:53 pccorei7-4770 kernel: [ 3691.753169] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:54 pccorei7-4770 kernel: [ 3692.545921] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:54 pccorei7-4770 kernel: [ 3692.866820] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:55 pccorei7-4770 kernel: [ 3693.542921] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:55 pccorei7-4770 kernel: [ 3693.864460] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:56 pccorei7-4770 kernel: [ 3694.539028] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:56 pccorei7-4770 kernel: [ 3694.860824] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 06:59:57 pccorei7-4770 kernel: [ 3695.536803] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 06:59:57 pccorei7-4770 kernel: [ 3695.876240] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:55 pccorei7-4770 kernel: [ 3873.365928] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:55 pccorei7-4770 kernel: [ 3873.706339] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:56 pccorei7-4770 kernel: [ 3874.563884] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:56 pccorei7-4770 kernel: [ 3874.885761] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:57 pccorei7-4770 kernel: [ 3875.562088] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:57 pccorei7-4770 kernel: [ 3875.901835] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:58 pccorei7-4770 kernel: [ 3876.809216] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:58 pccorei7-4770 kernel: [ 3877.130778] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:02:59 pccorei7-4770 kernel: [ 3877.807965] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:02:59 pccorei7-4770 kernel: [ 3878.144767] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:03:37 pccorei7-4770 kernel: [ 3915.290650] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:03:37 pccorei7-4770 kernel: [ 3915.611177] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:03:38 pccorei7-4770 kernel: [ 3916.320719] nvidia-modeset:
> Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
> PCI::01:00.0
> Dec  6 07:03:38 pccorei7-4770 kernel: [ 3916.641984] nvidia-modeset: Freed
> GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> Dec  6 07:03:39 pccorei7-4770 kernel: [ 3917.300914] nvidia-modeset:
> Allocated GPU:0 

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

2017-12-06 3:34 GMT+01:00 Julien Aubin :

>
>
> Le 5 déc. 2017 23:08, "Luca Boccassi"  a écrit :
>
> On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote:
> > To help debugging, could you provide me please some link to a newer
> > NVidia
> > driver release built for stretch please (and some notice to install
> > it) ?
>
> Unfortunately I don't think we have anything that can be used in
> Stretch - IIRC both 384 and 387 dependencies are structured for the
> glvnd transition, so they can't be installed on Stretch.
>
> > Thus :
> > - If I disable from a custom xorg.conf file module glx everything
> > loads
> > fine (as long as I use lightdm as a login manager)
> >
> > Thanks a lot.
>
> Could you clarify what this means? You are manually blacklisting glx?
>
>
>
The fact driver 38x cannot be installed on Stretch is very bad as it
prevents newer GPUs from working w/ Debian stable. Newer low-end NVidia
MX1** are already impacted.

FYI here's what I get in kern.log when enabling glx in xorg :

ec  6 06:59:44 pccorei7-4770 kernel: [ 3682.820990] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 06:59:53 pccorei7-4770 kernel: [ 3691.431679] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 06:59:53 pccorei7-4770 kernel: [ 3691.753169] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 06:59:54 pccorei7-4770 kernel: [ 3692.545921] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 06:59:54 pccorei7-4770 kernel: [ 3692.866820] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 06:59:55 pccorei7-4770 kernel: [ 3693.542921] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 06:59:55 pccorei7-4770 kernel: [ 3693.864460] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 06:59:56 pccorei7-4770 kernel: [ 3694.539028] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 06:59:56 pccorei7-4770 kernel: [ 3694.860824] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 06:59:57 pccorei7-4770 kernel: [ 3695.536803] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 06:59:57 pccorei7-4770 kernel: [ 3695.876240] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:02:55 pccorei7-4770 kernel: [ 3873.365928] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 07:02:55 pccorei7-4770 kernel: [ 3873.706339] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:02:56 pccorei7-4770 kernel: [ 3874.563884] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 07:02:56 pccorei7-4770 kernel: [ 3874.885761] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:02:57 pccorei7-4770 kernel: [ 3875.562088] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 07:02:57 pccorei7-4770 kernel: [ 3875.901835] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:02:58 pccorei7-4770 kernel: [ 3876.809216] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 07:02:58 pccorei7-4770 kernel: [ 3877.130778] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:02:59 pccorei7-4770 kernel: [ 3877.807965] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 07:02:59 pccorei7-4770 kernel: [ 3878.144767] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:03:37 pccorei7-4770 kernel: [ 3915.290650] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 07:03:37 pccorei7-4770 kernel: [ 3915.611177] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:03:38 pccorei7-4770 kernel: [ 3916.320719] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 07:03:38 pccorei7-4770 kernel: [ 3916.641984] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:03:39 pccorei7-4770 kernel: [ 3917.300914] nvidia-modeset:
Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @
PCI::01:00.0
Dec  6 07:03:39 pccorei7-4770 kernel: [ 3917.621818] nvidia-modeset: Freed
GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
Dec  6 07:03:40 pccorei7-4770 kernel: [ 

Bug#883645: Coq.Arith.PeanoNat missing from coq-theories

[Stewart Wilcox]

Package: coq-theories
Version: 8.4pl3dfsg-1

The package does not contain the following file:

/usr/lib/coq/theories/Arith/PeanoNat.vo

(see https://packages.debian.org/jessie/all/coq-theories/filelist)

I assume this file should be present since Coq.Arith.PeanoNat still appears
in the coq standard library documentation (
https://coq.inria.fr/library/Coq.Arith.PeanoNat.html) and in the source (
https://github.com/coq/coq/tree/master/theories/Arith).

Bug#883602: OPENAFS-SA-2017-001: Rx assertion failure from insufficient input validation

[Salvatore Bonaccorso]

Control: retitle -1 openafs: CVE-2017-17432: OPENAFS-SA-2017-001: Rx assertion 
failure from insufficient input validation

Hi Ben,

On Tue, Dec 05, 2017 at 10:01:14AM -0600, Benjamin Kaduk wrote:
> Source: openafs
> Version: 1.6.1-3+deb7u7
> Tags: security upstream fixed-upstream pending
> Severity: important
> 
> Upstream OpenAFS released security advisory OPENAFS-SA-2017-001
> today; insufficient validation of data contained in Rx ack packets
> leads to the use of an invalid MTU value, ultimately leading to an
> assertion failure and application crash or kernel BUG.

This issue has been assigned CVE-2017-17432. Can you foward this
information to upstream?

Regards,
Salvatore

Bug#883644: ITP: papirus-icon-theme -- Papirus Icon Theme

[Yangfl]

Package: wnpp
Severity: wishlist
Owner: Yangfl 

* Package name: papirus-icon-theme
  Version : 20171124
  Upstream Author : PapirusDevelopmentTeam
* URL : https://github.com/PapirusDevelopmentTeam/papirus-icon-theme
* License : LGPL3
  Programming Lang: na
  Description : Papirus Icon Theme


Papirus is a SVG-based icon theme, drawing inspiration from Material Design
and flat design.
.
This package contains the following icon themes:
 - ePapirus
 - Papirus
 - Papirus-Adapta
 - Papirus-Adapta-Nokto
 - Papirus-Dark
 - Papirus-Light

Bug#845297: Website transition from CVS to Git - now with cvs-revisions file

[Paul Wise]

On Tue, Dec 5, 2017 at 12:08 PM, Paul Wise wrote:

> I haven't tried it on the full webwml CVS repository.

I started the cvs2git script yesterday and it completed overnight. The
results look fine, here is an example commit log from one of the
recent CVS commits:

Add link to  non official images for some more ports

CVS version numbers

english/ports/index.wml: 1.133 -> 1.134

If people want to change how the CVS part looks that should be easy by
customising the sed commands in the script.

I didn't get the authors file before starting the script though, so it
doesn't have full author names in the commit meta-data.

I think the remaining things to add to the script are:

The authors file.

Any tweaks needed to the CVS version numbers part of the commit logs.

After the repo has been converted, use the cvs-revisions file to add a
git commit automatically rewriting all the translation-check headers
to the git-based system Laura proposed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#883643: linux-image-4.13.0-1-amd64: HP Compaq LA1951g monitor: USB hub only works after reconnecting USB cable after startup

[Adrian Immanuel Kiess]

Package: src:linux
Version: 4.13.13-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 Using the built in USB hub of an HP Compaq LA1951g monitor
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Starting up the system
   * What was the outcome of this action?
 USB hub of the HP Compaq LA1951g monitor only connected if pulling in and
out the USB cable after startup
   * What outcome did you expect instead?
 Working USB hub

in Debian/testing this bug is very old. Using an HP Compaq LA1951g monitor, the
built in USB hub only get's connected after startup if pulling in and out the
USB jack.

Thanks in advance.

Yours sincerely,

Adrian Immanuel Kieß



-- Package-specific info:
** Version:
Linux version 4.13.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
6.4.0 20171112 (Debian 6.4.0-10)) #1 SMP Debian 4.13.13-1 (2017-11-16)

** Command line:
BOOT_IMAGE=/vmlinuz-4.13.0-1-amd64 
root=UUID=96d5fdb9-5d4e-46f2-89e3-34fcfc7bfe14 ro 
resume=UUID=3d740914-57bc-440c-843f-d15812ee3903 splash vga=795 splash vga=775

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: HP
product_name: ProLiant ML110 G6
product_version:
chassis_vendor: HP
chassis_version: N/A
bios_vendor: HP
bios_version: O27   
board_vendor: Wistron Corporation
board_name: ProLiant ML110 G6
board_version:

** Loaded modules:
uinput
xt_CHECKSUM
iptable_mangle
ipt_MASQUERADE
nf_nat_masquerade_ipv4
iptable_nat
nf_nat_ipv4
nf_nat
nf_conntrack_ipv4
nf_defrag_ipv4
xt_conntrack
nf_conntrack
libcrc32c
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
tun
bridge
stp
llc
rfcomm
ebtable_filter
ebtables
ip6table_filter
ip6_tables
iptable_filter
devlink
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
quota_v2
quota_tree
usblp
cmac
bnep
btusb
btrtl
btbcm
btintel
joydev
bluetooth
drbg
ansi_cprng
wacom
ecdh_generic
uas
rfkill
usb_storage
snd_usb_audio
snd_usbmidi_lib
snd_rawmidi
snd_seq_device
binfmt_misc
iTCO_wdt
iTCO_vendor_support
evdev
cuse
fuse
intel_powerclamp
loop
coretemp
ipmi_watchdog
kvm_intel
kvm
irqbypass
intel_cstate
intel_uncore
snd_hda_codec_hdmi
pcspkr
snd_hda_intel
snd_hda_codec
snd_hda_core
snd_hwdep
snd_pcm
amdgpu
snd_timer
snd
lpc_ich
sg
soundcore
mfd_core
shpchp
button
acpi_cpufreq
dm_mod
ipmi_si
ipmi_poweroff
ipmi_devintf
ipmi_msghandler
parport_pc
ppdev
lp
parport
nfsd
auth_rpcgss
nfs_acl
lockd
grace
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
crypto_simd
cryptd
glue_helper
aes_x86_64
btrfs
crc32c_generic
xor
raid6_pq
uhci_hcd
sr_mod
cdrom
sd_mod
hid_generic
usbhid
hid
ahci
libahci
libata
radeon
xhci_pci
i2c_algo_bit
ehci_pci
tg3
ptp
xhci_hcd
ehci_hcd
crc32c_intel
scsi_mod
i2c_i801
drm_kms_helper
pps_core
libphy
ttm
usbcore
usb_common
drm


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

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

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

Versions of packages linux-image-4.13.0-1-amd64 recommends:
pn  apparmor 
ii  firmware-linux-free  3.4
ii  irqbalance   1.2.0-0.2

Versions of packages linux-image-4.13.0-1-amd64 suggests:
ii  debian-kernel-handbook  1.0.18
ii  extlinux3:6.03+dfsg1-2
ii  grub-pc 2.02-2
pn  linux-doc-4.13  

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

-- no debconf information

Bug#883611: RFS: auter/0.11 (ITP: Bug#880600)

[Paul Wise]

On Wed, Dec 6, 2017 at 1:54 AM, Paolo Gigante wrote:

>   auter - Automatic updates for Redhat and Debian based Linux servers

Please compare and contrast auter with the other packages in Debian
for this task: unattended-upgrades cron-apt packagekit

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#839071: Patch

[Antonio Russo]

The proposed patch has been included upstream, and should be reflected in the 
current package.

Because mtab has "always" been linked to /proc/self/mounts, I'm not sure if
this report was "theoretical" or represented an observed problem that may
have a different root cause.

Could you please clarify if upstream's response is adequate?

Bug#843985: (no subject)

[Antonio Russo]

Control: fixed -1 zfs-linux/0.7.3-1


I think support for this was added. The manual page lists
the -o and -x options under zfs receive (though I have not
tested it).

Please reopen this bug if the package still lacks this
functionality.

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

Le 5 déc. 2017 23:08, "Luca Boccassi"  a écrit :

On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote:
> To help debugging, could you provide me please some link to a newer
> NVidia
> driver release built for stretch please (and some notice to install
> it) ?

Unfortunately I don't think we have anything that can be used in
Stretch - IIRC both 384 and 387 dependencies are structured for the
glvnd transition, so they can't be installed on Stretch.

> Thus :
> - If I disable from a custom xorg.conf file module glx everything
> loads
> fine (as long as I use lightdm as a login manager)
>
> Thanks a lot.

Could you clarify what this means? You are manually blacklisting glx?


Hi

Yes I used nvidia-xconfig to generate an xorg.conf file and in it I
disabled the glx module


> 2017-12-05 22:14 GMT+01:00 Julien Aubin :
>
> > GLX crashes here :
> >
> > #0  0x7588ad01 in __GI_strtol_l_internal
> > (nptr=0x7fffe2b1
> > "001 GLX", endptr=0x7fffe2a8, base=10, group=,
> > loc=0x55ad3620) at ../stdlib/strtol_l.c:293
> > #1  0x555cd0cb in ?? ()
> > #2  0x555bbeb0 in AddExtension ()
> > #3  0x7381d7b2 in ?? () from
> > /usr/lib/xorg/modules/linux/libglx.so
> >
> > #4  0x555bc040 in ?? ()
> > #5  0x001d in ?? ()
> > #6  0x0200 in ?? ()
> > #7  0x in ?? ()
> >
> >
> > 2017-12-05 21:47 GMT+01:00 Julien Aubin :
> >
> > > Hi,
> > >
> > > I reinstalled NVidia driver several times and the problem is
> > > still the
> > > same. Trying your method still results in the same issue.
> > >
> > > Now if I fully blacklist the nvidia driver I get a "better" black
> > > screen
> > > w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log
> > > does not
> > > hang on the GLX stuff.
> > >
> > > Looks like this issue targets GeForce 10xx GPUs (as my 970 does
> > > seem
> > > unaffected as well).
> > >
> > > Rgds
> > >
> > >
> > >
> > > 2017-12-05 21:13 GMT+01:00 Luca Boccassi :
> > >
> > > > On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote:
> > > > > Looks like the culprit is NVidia modeset. Thus the issue does
> > > > > not
> > > > > happen w/
> > > > > a Maxwell GPU.
> > > > >
> > > > > [  542.167979] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > >
> > > > >
> > > > > [  542.490521] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  544.081034] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  544.385426] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  546.079744] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  546.399641] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  548.091421] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  548.395724] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  550.088731] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  550.392898] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > >
> > > > Didn't see any issue with my 780 (Kepler?).
> > > >
> > > > Are you sure the kernel modules is correctly rebuilt? I've seen
> > > > that
> > > > there was a kernel point release, and not all ABI changes are
> > > > reverted.
> > > > Which means DKMS won't rebuild the modules automatically.
> > > >
> > > > Try to remove it and rebuild it with:
> > > >
> > > > sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64
> > > > sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64
> > > > > 2017-12-05 20:51 GMT+01:00 Julien Aubin  > > > > om>:
> > > > >
> > > > > > Driver hangs just here :
> > > > > > --->
> > > > > > [32.680] (II) Initializing extension GLX
> > > > > > [32.680] (II) Indirect GLX disabled.
> > > > > > >
> > > > > >
> > > > > > Normally I should get then [34.659] (II) config/udev:
> > > > > > Adding
> > > > > > input
> > > > > > device Power Button (/dev/input/event5)
> > > > > >
> > > > > > But here it crashes without log.
> > > > > >
> > > > > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System <
> > > > > > ow...@bugs.debian.org>:
> > > > > >
> > > > > > > Thank you for filing a new Bug report with Debian.
> > > > > > >
> > > > > > > You can follow progress on this Bug here: 883615:
> > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615.
> > > > > > >
> > > > > > > This is an 

Bug#780606: (no subject)

[Michael Lustfield]

For anyone interested, I hit a pretty sizeable roadblock with javascript
packaging. I haven't been able to find anyone that can help me deal with these
issues so gitea packaging is dropping pretty low on my priorities list.

If anyone wants to help and knows anything about javascript packaging, I would
love (and very much need) some help.

-- 
Michael Lustfield

Bug#883642: python-networking-mlnx: uninstallable in sid: Depends: python-sqlalchemy (< 1.1.0) but 1.1.11+ds1-1 is to be installed

[Andreas Beckmann]

Package: python-networking-mlnx
Version: 1:11.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 python-networking-mlnx : Depends: python-sqlalchemy (< 1.1.0) but 1.1.11+ds1-1 
is to be installed
E: Unable to correct problems, you have held broken packages.


Cheers,

Andreas

Bug#848890: public safety risk alert bT

[Sandra Narron]

Quit emailing me

Sent from my iPhone

> On Dec 5, 2017, at 10:55 AM, kids live safe  wrote:
> 
> public safety risk alert
> 
> 
>
> 
>   
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 2017-12-05 04:12 AM, Yves-Alexis Perez wrote: > On Tue, 2017-12-05 at 
> 08:31 +0100, Christian Ehrhardt wrote: >> On Mon, Dec 4, 2017 at 9:56 PM, 
> Yves-Alexis Perez wr= ote: >>> On Thu, 2017-11-30 at 16:31 +0100, Christian 
> Ehrhardt wrote:  Pushed it to the same debian-submission-nov2017 branch 
> as before. >>> >>> Thanks, >>> >>> I don't really have good news though. I 
> took a look and first, it seems >>> that >>> the git commit entries aren't 
> really good. git log --format=3Doneline i= s >>> barely >>> readable, for 
> example. >> >> Yeah the format was meant for another tool which made 
> debian/changelog >> entries out of it. >> I could rewrite them the next time 
> we talk about this topic in >> probably 6 months :-) >=20 > Ok :) >> >>> For 
> the commit contents: >>> >>> 1aa409a5 (mass plugin enable): NACK again; I 
> won't enable that many stu= ff >>> (and >>> especially not in one go) >> >> I 
> can understand, this all is just a suggestion. >> Things came up (way before 
> my time) due to user requests and if I did >> history research correctly at 
> that point it was decided to enable a >> few more to not get requests for 
> extra plugins all the time. >> You are not taking all - that is fine, if you 
> take a few that is good >> enough. >=20 > It might help to do one commit per 
> feature (maybe one commit for consiste= nt > groups) too so I can cherry-pick 
> commits. >=20 >> Since I wasn't part of that old enabling activity I wanted 
> to sync >> with you here and even considered dropping a bunch of them next 
> (post >> LTS) cycle. >> Nobody remembers the particular reasons for some of 
> them, so for all >> that make no sense to you in a hard enough way to not 
> even enable them >> for "-extra-plugins I'd consider triggering bug reports 
> in Ubuntu if >> somebody really used them. >=20 > Yes, that could make sense. 
> If no one asks for them, I prefer to keep the= m > disabled in order to 
> reduce attack surface, because strongSwan is really = a > beast. Even if 
> there's the plugin architecture, plugins are default-enabl= ed > and that 
> means a lot of exposed stuff. >=20 > For stuff like algorithms, there's also 
> the security tradeoffs of default > config. I don't want to endorse stuff 
> that's too young for my test (like = the > various PQ bits) or too exotic. 
> That's one reason why it would be great to have AES-GCM available like 
> ChaCha20/Poly1305. Those are the 2 most reputable AEAD ciphers available 
> today. >> I'm fine either way - all I request is that we look and discuss 
> about >> things every half year or so. >> So far we benefitted both each time 
> we did, so it isn't wasted time. >=20 > Indeed :) >> >>> d83c243b (duplicheck 
> disable): one good reason for the NACK just above: >>> it's >>> not enabled 
> in Debian, you just enabled it in 1aa409a5 :) >> >> That is a bummer, at the 
> time I saw it the first time I thought it was >> enabled in Debian and since 
> then carried on. >> /me feels ashamed and obviously drops that part :-) >=20 
> > No problem :) >> >>> 766d4f0d (ha disable): not really sure; it's way 
> easier to have a custo= m >>> kernel than a custom strongSwan >> >> Ok, so 
> you had real cases where you or a Debian user used that? >> Very interesting 
> POV, I think neither is easier than the other but I >> see your point. >=20 > 
> I didn't, but I know for sure that building and using a custom kernel is = 
> way > easier than using a custom strongSwan package. >> >>> 85150f06 
> (kernel-libipsec enable): for reference, this is #739641 and I= 'm >>> still 
> not sure I like it. I might pick it but end up disabling it befor= e >>> 
> release >> >> It is disabled by default as Simon already outlined for the 
> reason to >> be an opt-in. >=20 > Yes, by =E2=80=9Cdisabling=E2=80=9D I meant 
> more disabling at build time. >> >>> a587dc11 (TNC move): I might pick this 
> one because TNC is pretty >>> standalone >>> per-se and it might make sense 
> to split it, but really that's a lot of = new >>> binary packages. >> >> I 
> understand the new-queue fight, but it really came handy for users >> who 
> wanted it standalone. >=20 > Do you have pointers on people asking for it? I 
> would appreciate not having the TNC bits pulled unless I really need them. I 
> never had to deal with TNC so I don't know if a standalone package 
> (cb55e029b7) make sense. On the other hand, I routinely need EAP-MSCHAPv2 and 
> XAUTH and in such cases we don't want the TNC bits that comes from 
> libcharon-extra-plugins. I think that Christian's proposal of having 
> libcharon-standard-plugins (0ef9c2ad736) 

Bug#883554: cups keeps breaking network printer with implicitclass:

[David Fries]

On Tue, Dec 05, 2017 at 01:52:53PM +, Brian Potkin wrote:
> On Mon 04 Dec 2017 at 23:47:04 -0600, David Fries wrote:
> 
> > Package: cups
> > Version: 2.2.1-8
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > It seems to be every day or so the /etc/cups/printers.conf DeviceURI is
> > modified to replace the version that works with a version that doesn't.
> 
> Knowing "...the version that works..." would be useful.

Doesn't work:
DeviceURI implicitclass:Canon_BJC-2100
web job state
held since Tue Dec 5 19:00:56 2017 "No suitable destination host found by 
cups-browsed."

works (after replacing in server name) was in there since 2015:
DeviceURI ipps://.local:631/printers/Canon_BJC-2100

That is it works for about a day until it changes to the one that
doesn't.

> > This is printing to a cups system on the local network.
> > Was working with the cups in Debian jessie.
> 
> What is the cups version on the server? Can you print from the server?

Both the serve and client were running Debian jessie prior to
Thanksgiving, both were upgraded to stretch.  On the client I see in
aptitude.1.gz
[UPGRADE] cups:amd64 1.7.5-11+deb8u1 -> 2.2.1-8
Both client and server lists cups as version 2.2.1-8

Yes the server was printing before and after the upgrade.

> > It doesn't matter if I use a dnssd (auto detected), ipps, ipp, it gets
> > replaced by,
> > DeviceURI implicitclass:Canon_BJC-2100
> > and that doesn't allow it to print.  I've even gone so far as deleting
> > the printer, the detecting it through the ipp web configuration
> > interface and after a day or so it goes back to the implicitclass.
> 
> I do not understand the existence of the time lag.

It doesn't make any sense to me either when I'm using the cups browser
interface and letting it write out the file that it works for a while
and then it fails..

After the upgrade I can configure the client with that ipps and it
is able to print, for about a day, and then printing fails and I check
printers.conf and it is replaced with,
DeviceURI implicitclass:Canon_BJC-2100
and it can no longer print.  This is one of the files that cups keeps
modifying.  I've been using the web configuration interface when
modifying it, and have used the "Discovered Network Printers:" option
which fills in a long dnssd://Canon%20BJC-2100%20%40%20... but while
it initially prints it doesn't matter that will be replaced by
implicitclass:Canon_BJC-2100 the next day.

> > Any ideas?
> 
> There will be a PPD for the BCJ-2100 in /etc/cups/ppd. Please do

>  /usr/sbin/cupsfilter -p  -m printer/foo -e --list-filters /etc/services

/usr/sbin/cupsfilter -p /etc/cups/ppd/Canon_BJC-2100.ppd -m printer/foo -e 
--list-filters /etc/services

That gives no output at all.  I have a different version from 2015 in
that directory with the following output.

cupsfilter: File "/usr/lib/cups/filter/rastertogutenprint.5.2" permissions OK 
(040755/uid=0/gid=0).
texttopdf
pdftopdf
gstoraster
rastertogutenprint.5.2

The majority seems to be different page sizes, dithering, and such.
The header and cupsFilter might be of interest, so included here.

--- Canon_BJC-2100.ppd  2017-12-05 09:35:07.689792328 -0600
+++ Canon_BJC-2100_remote.ppd 2015-11-29 00:33:04.432331311 -0600
@@ -15,7 +15,7 @@
 *% Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 *%
 *FormatVersion:"4.3"
-*FileVersion:  "5.2.11"
+*FileVersion:  "5.2.10"
 *LanguageVersion: English
 *LanguageEncoding: ISOLatin1
 *PCFileName:   "STP00011.PPD"
@@ -23,17 +23,17 @@
 *Product:  "(Canon BJC-2100)"
 *ModelName: "Canon BJC-2100"
 *ShortNickName: "Canon BJC-2100"
-*NickName:  "Remote printer: Canon BJC-2100 - CUPS+Gutenprint v5.2.11"
+*NickName:  "Canon BJC-2100 - CUPS+Gutenprint v5.2.10"
 *PSVersion:"(3010.000) 0"
 *LanguageLevel:"3"
 *ColorDevice:  True
 *DefaultColorSpace:RGB
-*cupsManualCopies: True
 *FileSystem:   False
 *LandscapeOrientation: Plus90
 *TTRasterizer: Type42
 *cupsVersion:  1.2
-*cupsFilter: "*/* 0 -"
+*cupsManualCopies: True
+*cupsFilter:   "application/vnd.cups-raster 100 rastertogutenprint.5.2"
 *1284DeviceID: "MFG:Canon;MDL:BJC-2100;DES:Canon BJC-2100;"
 *cupsLanguages: "ca cs da de el en_GB es fi fr gl hu it ja nb nl pl pt ru sk 
sl sv tr uk vi zh_CN zh_TW"

> and post its output and the outputs of
> 
>  systemctl status cups-browsed

cups-browsed.service - Make remote CUPS printers available locally
   Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Tue 2017-12-05 09:34:59 CST; 9h ago
 Main PID: 447 (cups-browsed)
Tasks: 3 (limit: 4915)
   CGroup: /system.slice/cups-browsed.service
   447 /usr/sbin/cups-browsed

>  lpstat -t

lpstat -t
scheduler is running
system default destination: Canon_BJC-2100
device for Canon_BJC-2100: implicitclass:Canon_BJC-2100
Canon_BJC-2100 accepting requests since Tue Dec  5 19:19:12 2017
printer Canon_BJC-2100 is idle.  enabled 

Bug#883641: php-phpdocumentor-reflection: uninstallable in sid: Depends: php-parser (< 2~~) but 3.1.2-2 is to be installed

[Andreas Beckmann]

Package: php-phpdocumentor-reflection
Version: 1.1.0-1
Severity: serious
Tags: sid buster
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 php-phpdocumentor-reflection : Depends: php-parser (< 2~~) but 3.1.2-2 is to 
be installed
Depends: php-phpdocumentor-reflection-docblock 
(< 3~~) but 4.2.0-2 is to be installed
E: Unable to correct problems, you have held broken packages.


Cheers,

Andreas

Bug#808847: more spam

[Scott Kitterman]

On December 5, 2017 10:35:50 AM EST, Daniel Pocock  wrote:
>
>I received feedback from somebody that my mail server wasn't accepting
>messages from one of their servers because of this issue.
>
>I manually changed my settings to the new value and I notice that
>additional spam is now getting through.
>
>Maybe it is better to be strict and expect non-spammers to use SPF
>correctly.

This is fixed in stable, so not sure why you unarchived the bug.

Personally, I thought the old default was reasonable, but too many people 
whined.

What is it you want to have happen?

Scott K

Bug#883640: civicrm-common: uninstallable in sid: Depends: php-symfony-* (< 3~~) but 3.4.0+dfsg-1 is to be installed

[Andreas Beckmann]

Package: civicrm-common
Version: 4.7.24+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 civicrm-common : Depends: php-symfony-config (< 3~~) but 3.4.0+dfsg-1 is to be 
installed
  Depends: php-symfony-dependency-injection (< 3~~) but 
3.4.0+dfsg-1 is to be installed
  Depends: php-symfony-event-dispatcher (< 3~~) but 
3.4.0+dfsg-1 is to be installed
  Depends: php-symfony-filesystem (< 3~~) but 3.4.0+dfsg-1 is 
to be installed
  Depends: php-symfony-process (< 3~~) but 3.4.0+dfsg-1 is to 
be installed
  Depends: php-symfony-finder (< 3~~) but 3.4.0+dfsg-1 is to be 
installed
E: Unable to correct problems, you have held broken packages.


Cheers,

Andreas

Bug#883639: RM: libunwind8-dev -- RoQA; NBS; provided by libunwind-dev

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please decruft libunwind. The obsolete transitional package
libunwind8-dev is no longer built, but still provided by libunwind-dev,
therefore no dependency will be broken.


Andreas

Bug#883521: texlive-bin: FTBFS with poppler 0.61.1

[Norbert Preining]

Last thing...

> There is already a patch checked in from my side that is much simpler
> ... This is the one that is in TL subversion.

I included and activated your patch, plus bumping the build-deps, in the
experimental branch of the git repository of texlive-bin.

Thanks for your work

Norbert

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

Bug#883637: xserver-xorg-video-nvidia-legacy-340xx: No alternative/symlink created for nvidia_drv.so

[Andreas Beckmann]

On 2017-12-06 01:43, Jayen Ashar wrote:
> lrwxrwxrwx 1 root root   23 Dec  4 09:10 /etc/alternatives/nvidia -> 
> /usr/lib/nvidia/current

You have both the current and the 340xx legacy driver installed. The
alternatives by default select the newer driver.

You can either uninstall the current driver or reconfigure the nvidia
alternative this with

  update-glx --config nvidia

and select the legacy driver there.


Andreas

Bug#883521: texlive-bin: FTBFS with poppler 0.61.1

[Norbert Preining]

Hilmar,

one more thing ...

> >   Attached is the archlinux patch, which contains still the

There is already a patch checked in from my side that is much simpler
... This is the one that is in TL subversion.

Probably a mixture of modifications my Han and the minimal changes to
get it working with poppler>=0.59

Norbert

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

Bug#883521: texlive-bin: FTBFS with poppler 0.61.1

[Norbert Preining]

Hi all

(strange enough this bug report didn't arrive at my inbox)

> > Your package fails to build with poppler 0.61.1 from experimental. This

Please provide a clear plan on when you will upload to unstable. We
cannot upload a package that does not work with poppler << 0.59 to
unstable now.

Please add respective Breaks statements to your upload to unstable to
guarantee that full updates are only done after all packages have been
updated.

Thanks

>   Attached is the archlinux patch, which contains still the

Thanks Hilmar, that is great.

All the best

Norbert

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

Bug#883638: add warning about how to write -d option

[積丹尼 Dan Jacobson]

Package: procps
Version: 2:3.3.12-3
Severity: minor
File: /usr/share/man/man1/watch.1.gz

Man page says:

   -d, --differences [permanent]
  Highlight the differences between successive updates.  Option 
will read optional argument that changes highlight to be permanent, allowing  
to  see
  what has changed at least once since first iteration.

   -n, --interval seconds
  Specify  update interval.  The command will not allow quicker 
than 0.1 second interval, in which the smaller values are converted. Both '.' 
and ','
  work for any locales.

Please add a note at -d:

   Note that unlike -n, the options to -d must be glued to it:
   -d permanent, --differences=permanent .
   with -n one can get away with all of
   -n 1, --interval 1
   -n1,  --interval=1 .

Bug#883637: xserver-xorg-video-nvidia-legacy-340xx: No alternative/symlink created for nvidia_drv.so

[Jayen Ashar]

Package: xserver-xorg-video-nvidia-legacy-340xx
Version: 340.102-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Installing xserver-xorg-video-nvidia-legacy-340xx

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Removed xserver-xorg-video-nvidia and manually creating a symlink from 
/usr/lib/xorg/modules/ to /usr/lib/nvidia/legacy-340xx/nvidia_drv.so

   * What was the outcome of this action?

xorg was able to successfuly located and load the nvidia driver.  No change to 
my xorg.conf was needed.

   * What outcome did you expect instead?

I expected the package to create this symlink, like xserver-xorg-video-nvidia 
does.

Thanks,
Jayen

-- Package-specific info:
uname -a:
Linux eeyore 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux

/proc/version:
Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.102  Mon Jan 16 13:06:29 
PST 2017
GCC version:  gcc version 6.3.0 20170516 (Debian 6.3.0-18) 

lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT216GLM [Quadro 
FX 880M] [10de:0a3c] (rev a2) (prog-if 00 [VGA controller])
Subsystem: Lenovo GT216GLM [Quadro FX 880M] [17aa:2145]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video 226,   0 Dec  4 10:08 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Dec  4 10:08 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Dec  4 10:08 /dev/nvidiactl
video:x:44:jayen

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 1369 Dec  4 09:00 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root   15 Dec  4 09:10 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Dec  4 09:10 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   51 Dec  4 09:10 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   46 Dec  8  2013 
/etc/alternatives/glx--libGL.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   46 Dec  8  2013 
/etc/alternatives/glx--libGL.so-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Dec  4 09:10 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 Dec  4 09:10 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Dec  4 09:10 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Dec  4 09:10 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   55 Dec  4 09:10 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   55 Dec  4 09:10 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   52 Dec  4 09:10 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   52 Dec  4 09:10 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   42 Dec  4 09:10 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   28 Dec  4 09:10 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Dec  4 09:10 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   22 Dec  8  2013 /etc/alternatives/libGL.so-master 
-> /usr/lib/mesa-diverted
lrwxrwxrwx 1 root root   23 Dec  4 09:10 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Dec  4 09:10 
/etc/alternatives/nvidia--libcuda.so-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libcuda.so
lrwxrwxrwx 1 root root   51 Dec  4 09:10 
/etc/alternatives/nvidia--libcuda.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libcuda.so.1
lrwxrwxrwx 1 root root   57 Dec  4 09:10 
/etc/alternatives/nvidia--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libnvidia-cfg.so.1

Bug#883636: ShowQ doesn't start

[trebmuh]

Package: showq
Version: 0.4.1+git20161215~dfsg0-2

Dear debian maintainers,

trying to launch showq (debian stretch here) doesn't work at all.
When ran from a terminal, it tells:
$ showq
ShowQ:out_1 # system:playback_1
ShowQ:out_2 # system:playback_2
ShowQ:out_3 # PulseAudio JACK Source:front-left
ShowQ:out_4 # PulseAudio JACK Source:front-right

Then a pop up windows appears telling:

Show Q encountered an unknown error.
Please report this error to the developers of the program.


Pushing the "OK" button, and it stops.

I've already reported this to upstream : 
https://github.com/evandelisle/showq/issues/29


Cheers,
Olivier

Bug#883397: kstars-data: upgrade of Kstars-data From 4:16.08.3-2 to 4:17.08.3-1 not possible

[Andreas Beckmann]

Followup-For: Bug #883397

Hi,

this also affects kde-l10n-nds:

  Selecting previously unselected package kstars-data.
  Preparing to unpack .../91-kstars-data_4%3a17.08.3-1_all.deb ...
  Unpacking kstars-data (4:17.08.3-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-P2cD0o/91-kstars-data_4%3a17.08.3-1_all.deb (--unpack):
   trying to overwrite '/usr/share/kstars/nds/info_url.dat', which is also in 
package kde-l10n-nds 4:16.04.3-6
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-P2cD0o/91-kstars-data_4%3a17.08.3-1_all.deb


Andreas

Bug#883635: debhelper: [INTL:pt] Updated Portuguese translation of documentation.

[Américo Monteiro]

Package: debhelper
Version: 10.10.10
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for debhelper's documentation.
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator'


-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

debhelper_10.10.10_pt.po.gz
Description: application/gzip

Bug#883633: kturtle: file conflicts with kde-l10n-XX: /usr/share/katepart/syntax/logohighlightstyle.XX.xml

[Andreas Beckmann]

Package: kturtle
Version: 4:17.08.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

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

  Selecting previously unselected package kturtle.
  Preparing to unpack .../330-kturtle_4%3a17.08.3-1_amd64.deb ...
  Unpacking kturtle (4:17.08.3-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-PXwbXH/330-kturtle_4%3a17.08.3-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/katepart/syntax/logohighlightstyle.ru.xml', 
which is also in package kde-l10n-ru 4:16.04.3-6
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-PXwbXH/330-kturtle_4%3a17.08.3-1_amd64.deb

Similar problems were detected with the following packages:

kde-l10n-engb=4:16.04.3-6
kde-l10n-nb=4:16.04.3-6
kde-l10n-nds=4:16.04.3-6
kde-l10n-nl=4:16.04.3-6
kde-l10n-ru=4:16.04.3-6


cheers,

Andreas


kde-l10n-ru=4%16.04.3-6_kturtle=4%17.08.3-1.log.gz
Description: application/gzip

Bug#883634: telegram-desktop: Segmentation fault

[Jiaxun Yang]

Package: telegram-desktop
Version: 1.1.23-2
Severity: normal

Dear Maintainer,

There is a segmentation fault happened during the start of telegram-desktop:

QApplication: invalid style override passed, ignoring it.

(telegram-desktop:1827): GLib-GObject-WARNING **: cannot register
existing type 'GdkDisplayManager'

(telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
'result != 0' failed

(telegram-desktop:1827): GLib-GObject-CRITICAL **:
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
failed

(telegram-desktop:1827): GLib-GObject-WARNING **: invalid (NULL) pointer
instance

(telegram-desktop:1827): GLib-GObject-CRITICAL **:
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(telegram-desktop:1827): GLib-GObject-WARNING **: invalid (NULL) pointer
instance

(telegram-desktop:1827): GLib-GObject-CRITICAL **:
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(telegram-desktop:1827): GLib-GObject-WARNING **: cannot register
existing type 'GdkDisplay'

(telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
'result != 0' failed

(telegram-desktop:1827): GLib-GObject-CRITICAL **:
g_type_register_static: assertion 'parent_type > 0' failed

(telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
'result != 0' failed

(telegram-desktop:1827): GLib-GObject-CRITICAL **:
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
failed


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

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

Versions of packages telegram-desktop depends on:
ii  libavcodec57 7:3.4-4
ii  libavformat57    7:3.4-4
ii  libavutil55  7:3.4-4
ii  libc6    2.25-2
ii  libgcc1  1:7.2.0-16
ii  libglib2.0-0 2.54.1-1
ii  libminizip1  1.1-8+b1
ii  libopenal1   1:1.17.2-4+b2
ii  libqt5core5a [qtbase-abi-5-9-2]  5.9.2+dfsg-4
ii  libqt5gui5   5.9.2+dfsg-4
ii  libqt5network5   5.9.2+dfsg-4
ii  libqt5widgets5   5.9.2+dfsg-4
ii  libssl1.1    1.1.0g-2
ii  libstdc++6   7.2.0-16
ii  libswresample2   7:3.4-4
ii  libswscale4  7:3.4-4
ii  libtgvoip1.0 1.0~git20170704.445433f-4
ii  libx11-6 2:1.6.4-3
ii  qt5-image-formats-plugins    5.9.2-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages telegram-desktop recommends:
ii  libappindicator1  0.4.92-5

telegram-desktop suggests no packages.

Bug#883632: maxima: Maintainer unreachable

[Thorsten Glaser]

Source: maxima
Version: 5.40.0-3
Severity: serious
Justification: Policy v4.1.2.0 §3.3

The only Maintainer of the maxima source package is not reachable.
There are no Uploaders, either.

Proof follows:


From mailer-dae...@mailly.debian.org Tue Dec  5 23:26:54 2017
From: Mail Delivery System 
Message-ID: 
To: t...@mirbsd.de
Date: Tue, 05 Dec 2017 23:15:54 +
Subject: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  c...@maguirefamily.org
retry timeout exceeded

[ Part 2: "Delivery Status" ]

Reporting-MTA: dns; mailly.debian.org

Action: failed
Final-Recipient: rfc822;c...@maguirefamily.org
Status: 5.0.0


[ Part 3: "Included Message" ]

From: Thorsten Glaser 
Message-ID: 
To: c...@debian.org
Date: Tue, 5 Dec 2017 23:12:35 + (UTC)
Subject: Re: Log for attempted build of maxima_5.40.0-3 on m68k (dist=unstable)

fail

2 tests failed out of 11,185 total tests.

cf. 
https://buildd.debian.org/status/fetch.php?pkg=maxima=m68k=5.40.0-3=1512458062=0

Bug#883631: ibus-libpinyin should use python3

[Bryan Quigley]

Source: ibus-libpinyin
Version: 1.7.3-2

According to the upstream changelog version 1.7.0 and above have been migrated
(or enabled) to python3.

I came across this as part of looking at options for the Ubuntu
desktop to remove python2[2]
from our default livecd.

If it indeed possible, please switch to python3.  Thanks!

[1] https://github.com/libpinyin/ibus-libpinyin/blob/master/ChangeLog
[2] https://lists.ubuntu.com/archives/ubuntu-desktop/2017-November/005286.html
[3] Debian also has a similar no python2 by default goal -
https://wiki.debian.org/Python/StretchRoadmap

Bug#883630: python3.5: do not release with buster

[Mattia Rizzolo]

Source: python3.5
Version: 3.5.4-4
Severity: serious

Filing this bug to prevent testing migration until src:python3.5 can be
removed from sid as well.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#883604: ntfs-3g: The changelog.gz doesn't any mention from 2014 onwards

[shirish शिरीष]

at bottom :-

On 06/12/2017, Jean-Pierre André  wrote:
>  > so it seems better to switch back following the AR releases, right?
>
> This is not really a decision by me, I suppose you have
> to follow some Debian guidelines.
>
> I can only add that, if no distribution is interested in
> the AR releases, the Tuxera versions will be less tested
> before they are released. IMHO through its progressive
> release steps (unstable, experimental, etc) Debian has a
> better policy than most distributions to detect defects
> in new versions before they reach unexperienced users.
>
>

Dear all,

While it might seem strange (or not) there is a reason behind that
query. From what I have been able to ascertain (please let me know if
I'm correct in my assumptions or not) MS-Windows put NTFS 3.1 in
Windows XP and after whatever iterations of the filesystems have been
done, they all have been called NTFS 3.1 only.

I have an external hdd which works flawlessely under Debian and
GNU/Linux but under MS-Windows it shows 3.1  and sometimes I have to
correct tt

> sudo ntfsfix -d /dev/sdb1 
>[95%]
Mounting volume... $MFTMirr does not match $MFT (record 28).
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 28...OK
Correcting differences in $MFTMirr record 29...OK
Correcting differences in $MFTMirr record 30...OK
Correcting differences in $MFTMirr record 31...OK
Correcting differences in $MFTMirr record 32...OK
Correcting differences in $MFTMirr record 33...OK
Correcting differences in $MFTMirr record 34...OK
Correcting differences in $MFTMirr record 35...OK
Correcting differences in $MFTMirr record 36...OK
Correcting differences in $MFTMirr record 37...OK
Correcting differences in $MFTMirr record 38...OK
Correcting differences in $MFTMirr record 39...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdb1 was processed successfully.

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

Bug#883596: Wron exit code of dhcp_release6

[Simon Kelley]

On 05/12/17 15:00, Gaudenz Steinlin wrote:
> 
> Hi
> 
> Sorry for the incomplete bug report. I wanted to resume a reported I did
> not finish with reportbug, but it decided to send the backup copy as is
> instead of letting me edit it before sending.
> 
> Looking at the code the wrong error code results from the return code of
> the parse_packet function which is passed through via
> send_release_packet to main and used as exit code there. Returning -1
> from main results in an exit code of 255 in the shell.
> 
> Gaudenz
> 


Are  sure that this isn't a real error? From a quick look, successfully
doing the release results in a reply with a STATUS_CODE structure
containing a SUCCESS status value, which is zero. This is returned via
parse_packet and send_release_packet to main, and results in a zero
return code. A -1 return from parse_packet implies no STATUS_CODE or
IA_NA in the reply, which is an error.

Cheers,

Simon.




signature.asc
Description: OpenPGP digital signature

Bug#883629: Acknowledgement (netcat6: Please remove from Debian.)

[Witold Baryluk]

Actually,

I think this package is already removed from stable and testing.

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

It appears I had it installed on my system, because I installed it long
time ago, but obviously it stayed around as installed.

$ apt-cache show netcat6
Package: netcat6
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 148
Maintainer: Guillaume Delacour 
Architecture: amd64
Source: nc6
Version: 1.0-8
Depends: libc6 (>= 2.2.5)
Description: TCP/IP swiss army knife with IPv6 support
 A simple Unix utility which reads and writes data across network
 connections using TCP or UDP protocol.  It is designed to be a reliable
 "back-end" tool that can be used directly or easily driven by other
 programs and scripts. At the same time it is a feature-rich network
 debugging and exploration tool.
 .
 Netcat6 is a rewrite of the original netcat with support for IPv6 and
 an enhanced support for UDP.
Description-md5: 218ff9f8d25e03732fb2d6dbc7b3af6f
Homepage: http://www.deepspace6.net/projects/netcat6.html
$


Sorry for the noise.


-- 
Witold Baryluk
My PGP keys for 2017-02-17 - 2019-02-17:
5B8C 48CB 8B2F CF53 CA55  0995 16D9 6FA2 20A8 F130
https://functor.xyz/pgp/witold.baryluk-gmail.gpg.asc
https://keys.mailvelope.com/pks/lookup?op=get=0x16D96FA220A8F130

Bug#883549: Debian Installer Buster Alpha 1 release - Hardware support of Xunlong Orange Pi zero

[Vagrant Cascadian]

On 2017-12-05, Karsten Merker wrote:
> On Tue, Dec 05, 2017 at 03:37:00AM +, Vasilis wrote:
>> Happy to do any further tests.
>
> If you would be willing to commit to more or less regularly test
> the Debian u-boot package on the board, the Debian u-boot
> maintainer (Vagrant Cascadian, in CC) would probably be happy to
> add u-boot images for the Orange Pi Zero to the Debian u-boot
> package

For more information about enabling boards in the u-boot packages, see:

  https://wiki.debian.org/U-boot

It's already available in mainline u-boot, so it's largely a matter of
getting someone to commit to testing it.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Luca Boccassi]

On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote:
> To help debugging, could you provide me please some link to a newer
> NVidia
> driver release built for stretch please (and some notice to install
> it) ?

Unfortunately I don't think we have anything that can be used in
Stretch - IIRC both 384 and 387 dependencies are structured for the
glvnd transition, so they can't be installed on Stretch.

> Thus :
> - If I disable from a custom xorg.conf file module glx everything
> loads
> fine (as long as I use lightdm as a login manager)
> 
> Thanks a lot.

Could you clarify what this means? You are manually blacklisting glx?

> 2017-12-05 22:14 GMT+01:00 Julien Aubin :
> 
> > GLX crashes here :
> > 
> > #0  0x7588ad01 in __GI_strtol_l_internal
> > (nptr=0x7fffe2b1
> > "001 GLX", endptr=0x7fffe2a8, base=10, group=,
> > loc=0x55ad3620) at ../stdlib/strtol_l.c:293
> > #1  0x555cd0cb in ?? ()
> > #2  0x555bbeb0 in AddExtension ()
> > #3  0x7381d7b2 in ?? () from
> > /usr/lib/xorg/modules/linux/libglx.so
> > 
> > #4  0x555bc040 in ?? ()
> > #5  0x001d in ?? ()
> > #6  0x0200 in ?? ()
> > #7  0x in ?? ()
> > 
> > 
> > 2017-12-05 21:47 GMT+01:00 Julien Aubin :
> > 
> > > Hi,
> > > 
> > > I reinstalled NVidia driver several times and the problem is
> > > still the
> > > same. Trying your method still results in the same issue.
> > > 
> > > Now if I fully blacklist the nvidia driver I get a "better" black
> > > screen
> > > w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log
> > > does not
> > > hang on the GLX stuff.
> > > 
> > > Looks like this issue targets GeForce 10xx GPUs (as my 970 does
> > > seem
> > > unaffected as well).
> > > 
> > > Rgds
> > > 
> > > 
> > > 
> > > 2017-12-05 21:13 GMT+01:00 Luca Boccassi :
> > > 
> > > > On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote:
> > > > > Looks like the culprit is NVidia modeset. Thus the issue does
> > > > > not
> > > > > happen w/
> > > > > a Maxwell GPU.
> > > > > 
> > > > > [  542.167979] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > 
> > > > > 
> > > > > [  542.490521] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  544.081034] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  544.385426] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  546.079744] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  546.399641] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  548.091421] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  548.395724] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  550.088731] nvidia-modeset: Allocated GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > > [  550.392898] nvidia-modeset: Freed GPU:0
> > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > > > 
> > > > Didn't see any issue with my 780 (Kepler?).
> > > > 
> > > > Are you sure the kernel modules is correctly rebuilt? I've seen
> > > > that
> > > > there was a kernel point release, and not all ABI changes are
> > > > reverted.
> > > > Which means DKMS won't rebuild the modules automatically.
> > > > 
> > > > Try to remove it and rebuild it with:
> > > > 
> > > > sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64
> > > > sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64
> > > > > 2017-12-05 20:51 GMT+01:00 Julien Aubin  > > > > om>:
> > > > > 
> > > > > > Driver hangs just here :
> > > > > > --->
> > > > > > [32.680] (II) Initializing extension GLX
> > > > > > [32.680] (II) Indirect GLX disabled.
> > > > > > >
> > > > > > 
> > > > > > Normally I should get then [34.659] (II) config/udev:
> > > > > > Adding
> > > > > > input
> > > > > > device Power Button (/dev/input/event5)
> > > > > > 
> > > > > > But here it crashes without log.
> > > > > > 
> > > > > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System <
> > > > > > ow...@bugs.debian.org>:
> > > > > > 
> > > > > > > Thank you for filing a new Bug report with Debian.
> > > > > > > 
> > > > > > > You can follow progress on this Bug here: 883615:
> > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615.
> > > > > > > 
> > > > > > > This is an automatically generated reply to let you know
> > > > > > > your
> > > > > > > message
> > > > > > > has been received.
> > > > > > > 
> > > > > > 

Bug#883585: [pkg-firebird-general] Bug#883585: firebird3.0: remove unused build-dependency on libatomic-ops-dev

[Damyan Ivanov]

Control: tag -1 confirmed pending

-=| James Cowgill, 05.12.2017 14:06:18 + |=-
> Source: firebird3.0
> Version: 3.0.2.32703.ds4-11
> Severity: minor
> 
> firebird3.0 build-depends on the libatomic-ops-dev package but 
> doesn't use it anywhere.
> 
> The only place where atomic_ops.h is referenced is in
> "src/common/classes/fb_atomic.h", however it is only included when not
> using GCC as the compiler (ie when __GNUC__ is not defined). Since all
> Debian architectures use GCC, the include will never be hit.

You are right.

I have removed the build dependency in Git and it will not be present 
in the next upload.

Thanks!


Cheers,
dam

Bug#883629: netcat6: Please remove from Debian.

[Witold Baryluk]

Package: netcat6
Version: 1.0-8
Severity: important
Tags: security


According to netcat6 website:

"""
THIS PAGE IS OUTDATED AND ONLY STILL ACCESSABLE FOR HISTORICAL REASONS. URLs 
for downloading outdated sources were removed.

Since longer time, following implementations got native IPv6 support:

(the original) nc: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/

nmap-ncat: http://nmap.org/
"""


normal netcat available in Debian (netcat-openbsd, but not
netcat-traditional) does provide now IPv6, and default to IPv6 according
to system wide preferences, example:

# nc -v google.com 80
nc: zrh04s06-in-x0e.1e100.net (2a00:1450:400a:805::200e) 80 [http] open
GET / HTTP/1.0

HTTP/1.0 302 Found

#


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

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

Versions of packages netcat6 depends on:
ii  libc6  2.25-3

netcat6 recommends no packages.

netcat6 suggests no packages.

-- no debconf information

Bug#883628: ITP: ioport -- direct access to I/O ports from the command line

[Lubomir Rintel]

Package: wnpp
Severity: wishlist
Owner: Lubomir Rintel 

* Package name: ioport
  Version : 1.2
  Upstream Author : Richard Jones 
* URL : http://people.redhat.com/rjones/ioport/
* License : GPLv2+
  Programming Lang: C
  Description : direct access to I/O ports from the command line

These commands enable command line and script access directly to I/O
ports on PC hardware.

The packaging: https://people.freedesktop.org/~lkundrak/ioport/

Bug#883521: texlive-bin: FTBFS with poppler 0.61.1

[Hilmar Preuße]

On 05.12.2017 19:36, Hilmar Preuße wrote:

Hi Norbert,

>   Attached is the archlinux patch, which contains still the
> modifications by Hàn. I can build TL with libpoppler.61. I installed the
> package and did some basic tests (i.e. if pdftex/luatex works at all).
> 
The hook for debian/changelog is non-sense and needs to be removed. Sorry!

H.
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#883606: Pending fixes for bugs in the libdancer2-perl package

[pkg-perl-maintainers]

tag 883606 + pending
thanks

Some bugs in the libdancer2-perl package are closed in revision
cfa2426c2feb48bfb8b433a53449374273612f73 in branch 'master' by Damyan
Ivanov

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdancer2-perl.git/commit/?id=cfa2426

Commit message:

add no-phone-home.patch disabling version check when creating new 
application via 'dancer2 -a'

Closes: #883606

Bug#883626: kubrick FTBFS on armel/armhf: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'

[Adrian Bunk]

Source: kubrick
Version: 4:17.08.3-1
Severity: serious
Forwarded: https://bugs.kde.org/show_bug.cgi?id=386367

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

...
In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:107:0,
 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:45,
 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGLFormat:1,
 from /<>/src/kubrick.cpp:24:
/usr/include/GLES3/gl3.h:75:25: error: conflicting declaration 'typedef 
khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;
 ^~
In file included from /usr/include/GL/gl.h:2055:0,
 from /<>/src/kbkglobal.h:33,
 from /<>/src/kubrick.h:26,
 from /<>/src/kubrick.cpp:20:
/usr/include/GL/glext.h:466:19: note: previous declaration as 'typedef 
ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;
   ^~


The problem is that on armel and armhf Qt in Debian uses
OpenGL ES instead of full OpenGL.

Ideally, kubrick should be fixed to also work with OpenGL ES.

If this is not easily possible, then:
- change the build dependency from libqt5opengl5-dev
  to libqt5opengl5-desktop-dev. and
- submit an RM bug against ftp.debian.org asking for
  the removal of the old armel+armhf binaries

Bug#883627: RFS: network-manager-fortisslvpn/1.2.6-1 [ITP] -- NetworkManager Fortinet SSLVPN plugin

[Lubomir Rintel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "hello":

 * Package name: network-manager-fortisslvpn
   Version : 1.2.6-1
   Upstream Author : Lubomir Rintel 
 * URL : https://wiki.gnome.org/Projects/NetworkManager/
 * License : GPLv2+
   Section : net

It builds those binary packages:

  network-manager-fortisslvpn   - network management framework (Fortinet 
SSLVPN plugin core)
  network-manager-fortisslvpn-gnome - network management framework (Fortinet 
SSLVPN plugin GNOME GUI)

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

  https://people.freedesktop.org/~lkundrak/network-manager-fortisslvpn/

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

  dget -x 
https://people.freedesktop.org/~lkundrak/network-manager-fortisslvpn/network-manager-fortisslvpn_1.2.6-1.dsc

Changes since the last upload:

 network-manager-fortisslvpn (1.2.6-1) UNRELEASED; urgency=medium

* Initial release. (Closes: #835938)

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

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

Bug#883367: RFS: roadfighter/1.0.0-1 [ITP] -- Drive a car in a death race

[Adam Borowski]

On Tue, Dec 05, 2017 at 02:53:04AM -0200, Carlos Donizete Froes wrote:
> > Alas, the game segfaults on start, unless ran from a directory containing
> > the source tree.  This looks like the same problem as in April 2016.
> 
> The binary has to be in the same directory where it finds the data: graphics,
> sound and maps.

I don't see why: a glance at the code shows that all (or most) file-handling
already comes through a single function, which can be made to prepend a
directory.

> For the time being, I did not learn to work using "debian/rules" or creating a
> script in the debian directory.

That'd be necessary only if you can't patch the source (ie, non-free closed
binary) or it's prohibitively hard to do so.  In this case, altering asset
loading functions looks trivial.  It'd probably be best to pass the path as
a define from the Makefile -- preferably if you can persuade the upstream to
do so to make life easier for other distributions.  And I believe you have
quite good contacts with current upstream. :p

> > There's also the unfixed problem of some assets: the .ogg files bear
> > metadata saying they come from Konami.
> 
> Thank you for notifying us of this case. I corrected this bug with some sounds
> and changed the metadata. It's in my GitHub account.[1]
> 
> [1] - https://github.com/coringao/roadfighter/tree/master/sound

Uhhh... were the tags indeed incorrect?  Merely altering the metadata
doesn't make copying the music legal, and Konami is quite a litigious
company.

> > Also, fullscreening doesn't work on multi-monitor setups.  It doesn't obey
> > settings such as which monitor is primary, orientation or positions (most
> > programs that fail here at least go to (0,0)).  This puts the game on the
> > wrong monitor, rotated.  Even worse, it permanently destroys randr settings
> > -- desktop environments (at least XFCE) save modifications, thus setting
> > everything from scratch is required.
> > 
> > Some displays don't allow non-native resolutions at all.
> 
> The resolution of this game is 512x384 in window mode by default.
> 
> You do not have the option to play full screen at the moment.
> 
> I'm still working with the source code of this game to have this option.

The window is really tiny, making the game quite unfun, especially on HiDPI
displays.  Multi-screen setups are moderately popular -- you still don't
have to support them, but it'd be bad to break them to the level the current
version does.  But, if you're indeed moving to SDL2, trying to fix this in
SDL1.2 is moot.

> > As far as I know, fixing this is possible but quite tricky in SDL1.2, a
> > non-issue in SDL2 which doesn't ever try to change resolutions (impossible
> > on non-CRTs anyway) but tells the GPU to scale.
> 
> I am a week ago going to SDL2 version of this game, will soon have version
> 1.1.0

Awesome to hear this!


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 14:13 < icenowy[m]> are they hot enough? ;-)
⣾⠁⢰⠒⠀⣿⡁ 14:17 < icenowy[m]> I think now in Europe it should be winter? Let
⢿⡄⠘⠷⠚⠋⠀ the BPi warm you ;-)
⠈⠳⣄ 14:17 <@KotCzarny> yeah, i have a pc to warm me ;)

Bug#883620: [Pkg-roundcube-maintainers] Bug#883620: More informations

[Guilhem Moulin]

Control: reopen -1

Didn't mean to close this, sorry.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

To help debugging, could you provide me please some link to a newer NVidia
driver release built for stretch please (and some notice to install it) ?

Thus :
- If I disable from a custom xorg.conf file module glx everything loads
fine (as long as I use lightdm as a login manager)

Thanks a lot.

2017-12-05 22:14 GMT+01:00 Julien Aubin :

> GLX crashes here :
>
> #0  0x7588ad01 in __GI_strtol_l_internal (nptr=0x7fffe2b1
> "001 GLX", endptr=0x7fffe2a8, base=10, group=,
> loc=0x55ad3620) at ../stdlib/strtol_l.c:293
> #1  0x555cd0cb in ?? ()
> #2  0x555bbeb0 in AddExtension ()
> #3  0x7381d7b2 in ?? () from /usr/lib/xorg/modules/linux/libglx.so
>
> #4  0x555bc040 in ?? ()
> #5  0x001d in ?? ()
> #6  0x0200 in ?? ()
> #7  0x in ?? ()
>
>
> 2017-12-05 21:47 GMT+01:00 Julien Aubin :
>
>> Hi,
>>
>> I reinstalled NVidia driver several times and the problem is still the
>> same. Trying your method still results in the same issue.
>>
>> Now if I fully blacklist the nvidia driver I get a "better" black screen
>> w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log does not
>> hang on the GLX stuff.
>>
>> Looks like this issue targets GeForce 10xx GPUs (as my 970 does seem
>> unaffected as well).
>>
>> Rgds
>>
>>
>>
>> 2017-12-05 21:13 GMT+01:00 Luca Boccassi :
>>
>>> On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote:
>>> > Looks like the culprit is NVidia modeset. Thus the issue does not
>>> > happen w/
>>> > a Maxwell GPU.
>>> >
>>> > [  542.167979] nvidia-modeset: Allocated GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> >
>>> >
>>> > [  542.490521] nvidia-modeset: Freed GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> > [  544.081034] nvidia-modeset: Allocated GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> > [  544.385426] nvidia-modeset: Freed GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> > [  546.079744] nvidia-modeset: Allocated GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> > [  546.399641] nvidia-modeset: Freed GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> > [  548.091421] nvidia-modeset: Allocated GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> > [  548.395724] nvidia-modeset: Freed GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> > [  550.088731] nvidia-modeset: Allocated GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>> > [  550.392898] nvidia-modeset: Freed GPU:0
>>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>>
>>> Didn't see any issue with my 780 (Kepler?).
>>>
>>> Are you sure the kernel modules is correctly rebuilt? I've seen that
>>> there was a kernel point release, and not all ABI changes are reverted.
>>> Which means DKMS won't rebuild the modules automatically.
>>>
>>> Try to remove it and rebuild it with:
>>>
>>> sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64
>>> sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64
>>> > 2017-12-05 20:51 GMT+01:00 Julien Aubin :
>>> >
>>> > > Driver hangs just here :
>>> > > --->
>>> > > [32.680] (II) Initializing extension GLX
>>> > > [32.680] (II) Indirect GLX disabled.
>>> > > >
>>> > >
>>> > > Normally I should get then [34.659] (II) config/udev: Adding
>>> > > input
>>> > > device Power Button (/dev/input/event5)
>>> > >
>>> > > But here it crashes without log.
>>> > >
>>> > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System <
>>> > > ow...@bugs.debian.org>:
>>> > >
>>> > > > Thank you for filing a new Bug report with Debian.
>>> > > >
>>> > > > You can follow progress on this Bug here: 883615:
>>> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615.
>>> > > >
>>> > > > This is an automatically generated reply to let you know your
>>> > > > message
>>> > > > has been received.
>>> > > >
>>> > > > Your message is being forwarded to the package maintainers and
>>> > > > other
>>> > > > interested parties for their attention; they will reply in due
>>> > > > course.
>>> > > >
>>> > > > Your message has been sent to the package maintainer(s):
>>> > > >  Debian NVIDIA Maintainers >> > > > org>
>>> > > >
>>> > > > If you wish to submit further information on this problem, please
>>> > > > send it to 883...@bugs.debian.org.
>>> > > >
>>> > > > Please do not send mail to ow...@bugs.debian.org unless you wish
>>> > > > to report a problem with the Bug-tracking system.
>>> > > >
>>> > > > --
>>> > > > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615
>>> > > > Debian Bug Tracking System
>>> > > > Contact ow...@bugs.debian.org with problems
>>> > 

Bug#881086: qastools: diff for NMU version 0.21.0-1.1

[Adrian Bunk]

Control: tags 881086 + patch
Control: tags 881086 + pending

Dear maintainer,

I've prepared an NMU for qastools (versioned as 0.21.0-1.1) and uploaded 
it to DELAYED/10 Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru qastools-0.21.0/debian/changelog qastools-0.21.0/debian/changelog
--- qastools-0.21.0/debian/changelog	2016-04-28 20:45:13.0 +0300
+++ qastools-0.21.0/debian/changelog	2017-12-05 22:50:10.0 +0200
@@ -1,3 +1,10 @@
+qastools (0.21.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on qttools5-dev. (Closes: #881086)
+
+ -- Adrian Bunk   Tue, 05 Dec 2017 22:50:10 +0200
+
 qastools (0.21.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru qastools-0.21.0/debian/control qastools-0.21.0/debian/control
--- qastools-0.21.0/debian/control	2016-04-28 20:24:42.0 +0300
+++ qastools-0.21.0/debian/control	2017-12-05 22:50:10.0 +0200
@@ -12,6 +12,7 @@
  qtbase5-dev,
  libqt5svg5-dev,
  qttools5-dev-tools,
+ qttools5-dev,
  libudev-dev,
  python-scour
 Standards-Version: 3.9.8

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

GLX crashes here :

#0  0x7588ad01 in __GI_strtol_l_internal (nptr=0x7fffe2b1
"001 GLX", endptr=0x7fffe2a8, base=10, group=,
loc=0x55ad3620) at ../stdlib/strtol_l.c:293
#1  0x555cd0cb in ?? ()
#2  0x555bbeb0 in AddExtension ()
#3  0x7381d7b2 in ?? () from /usr/lib/xorg/modules/linux/libglx.so
#4  0x555bc040 in ?? ()
#5  0x001d in ?? ()
#6  0x0200 in ?? ()
#7  0x in ?? ()


2017-12-05 21:47 GMT+01:00 Julien Aubin :

> Hi,
>
> I reinstalled NVidia driver several times and the problem is still the
> same. Trying your method still results in the same issue.
>
> Now if I fully blacklist the nvidia driver I get a "better" black screen
> w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log does not
> hang on the GLX stuff.
>
> Looks like this issue targets GeForce 10xx GPUs (as my 970 does seem
> unaffected as well).
>
> Rgds
>
>
>
> 2017-12-05 21:13 GMT+01:00 Luca Boccassi :
>
>> On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote:
>> > Looks like the culprit is NVidia modeset. Thus the issue does not
>> > happen w/
>> > a Maxwell GPU.
>> >
>> > [  542.167979] nvidia-modeset: Allocated GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> >
>> >
>> > [  542.490521] nvidia-modeset: Freed GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> > [  544.081034] nvidia-modeset: Allocated GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> > [  544.385426] nvidia-modeset: Freed GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> > [  546.079744] nvidia-modeset: Allocated GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> > [  546.399641] nvidia-modeset: Freed GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> > [  548.091421] nvidia-modeset: Allocated GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> > [  548.395724] nvidia-modeset: Freed GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> > [  550.088731] nvidia-modeset: Allocated GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>> > [  550.392898] nvidia-modeset: Freed GPU:0
>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>>
>> Didn't see any issue with my 780 (Kepler?).
>>
>> Are you sure the kernel modules is correctly rebuilt? I've seen that
>> there was a kernel point release, and not all ABI changes are reverted.
>> Which means DKMS won't rebuild the modules automatically.
>>
>> Try to remove it and rebuild it with:
>>
>> sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64
>> sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64
>> > 2017-12-05 20:51 GMT+01:00 Julien Aubin :
>> >
>> > > Driver hangs just here :
>> > > --->
>> > > [32.680] (II) Initializing extension GLX
>> > > [32.680] (II) Indirect GLX disabled.
>> > > >
>> > >
>> > > Normally I should get then [34.659] (II) config/udev: Adding
>> > > input
>> > > device Power Button (/dev/input/event5)
>> > >
>> > > But here it crashes without log.
>> > >
>> > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System <
>> > > ow...@bugs.debian.org>:
>> > >
>> > > > Thank you for filing a new Bug report with Debian.
>> > > >
>> > > > You can follow progress on this Bug here: 883615:
>> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615.
>> > > >
>> > > > This is an automatically generated reply to let you know your
>> > > > message
>> > > > has been received.
>> > > >
>> > > > Your message is being forwarded to the package maintainers and
>> > > > other
>> > > > interested parties for their attention; they will reply in due
>> > > > course.
>> > > >
>> > > > Your message has been sent to the package maintainer(s):
>> > > >  Debian NVIDIA Maintainers > > > > org>
>> > > >
>> > > > If you wish to submit further information on this problem, please
>> > > > send it to 883...@bugs.debian.org.
>> > > >
>> > > > Please do not send mail to ow...@bugs.debian.org unless you wish
>> > > > to report a problem with the Bug-tracking system.
>> > > >
>> > > > --
>> > > > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615
>> > > > Debian Bug Tracking System
>> > > > Contact ow...@bugs.debian.org with problems
>> > > >
>> > >
>> > >
>> >
>> > ___
>> > pkg-nvidia-devel mailing list
>> > pkg-nvidia-de...@lists.alioth.debian.org
>> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-de
>> > vel
>
>
>

Bug#883625: qemu: CVE-2017-17381: virtio: divide by zero exception while updating rings

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.10.0+dfsg-1
Severity: normal
Tags: patch security upstream
Forwarded: https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg00166.html

Hi,

the following vulnerability was published for qemu.

CVE-2017-17381[0]:
virtio: divide by zero exception while updating rings

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-17381
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17381
[1] https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg00166.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1520782
[3] https://bugzilla.novell.com/show_bug.cgi?id=1071228

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#882810: RFS: jag/0.3.3-1 [ITP] -- arcade-puzzle 2D game in which you have to break all the target pieces

[Adam Borowski]

On Tue, Dec 05, 2017 at 02:12:50AM -0200, Carlos Donizete Froes wrote:
> > However, it crashes a lot.
> > 
> > For example, try to enable fullscreen -> SIGSEGV.
> > 
> > Exit -> SIGABRT:
> > #0  0x7f4207738a70 in __GI_raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:51
> > #1  0x7f420773a19a in __GI_abort () at abort.c:89
> > #2  0x7f4201b78744 in _dbus_abort () at /lib/x86_64-linux-gnu/libdbus-
> > 1.so.3
> > .
> 
> This did not happen on my machine, other than a bug not related to the game, 
> but
> from the SDL2 library.
> 
> ---
> dbus[18767]: arguments to dbus_connection_unref() were incorrect, assertion
> "connection->generation == _dbus_current_generation" failed in file
> ../../../dbus/dbus-connection.c line 2822.
> This is normally a bug in some application using the D-Bus library.

> This bug reported on bugzilla SDL2, but so far I have not got answers.[1]
> 
> [1] - https://bugzilla.libsdl.org/show_bug.cgi?id=3978

Oh well, a crash that happens on exit is not a show stopper.  It'll pollute
home dirs (if started from .desktop) or wherever you start the game from
(cmdline) for people with a non-zero ulimit -c, but the vast majority does
not set it so.

Papering it over by calling _exit(0) (with an underscore) yourself is also
an option (note: on glibc, _exit is really exit_group these days).
 
> > Autopkgtest that consists of "Test-Command: /bin/true" is not exactly of any
> > use.  Please remove that, or replace with an actual test (although I don't
> > see what could be testable this way in a graphical game).
> 
> Unfortunately, I have not yet learned to use autopkgtest. After the end of
> "debuild", lintian notifies me to add autopkgtest where I chose to do it
> erroneously to pass. :(

Using lintian in the pedantic mode includes a bunch of suggestions that
don't apply to every project.  You don't need to use autopkgtest, it makes
sense only for packages with a meaningful way to run automated tests.

> > Package short descs are not supposed to be in title case, unless it's an
> > actual title -- "Arcade and Puzzle 2D Game" is not.
> 
> It was to be "arcade-puzzle 2D game in which you have to break all the
> target pieces", but it went beyond line 60 of the title.

I mean, "title case" in English is Capitalizing Every Word Except Articles
in a Phrase That Would Otherwise Be Lowercased Other Than Proper Names.

Thus, "arcade and puzzle 2D game" would be better.
 
> > The man page lists documentation sections as if they were arguments that
> > can be passed to the executable.
> 
> The man page in my opinion this is normal showing the details about the
> game.  But if you want me to change something in it or you want to change,
> feel free.

The SYNOPSIS section normally shows command line arguments.  Your game
doesn't use those, but you still put something else (a list of sections),
formatted and highlighted to look exactly the way every other man page lists
arguments.  This would make people think you run the executable this way,
realizing it's not the case only after reading the prose.

There's no need for such a list, man pages typically don't have an index.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 14:13 < icenowy[m]> are they hot enough? ;-)
⣾⠁⢰⠒⠀⣿⡁ 14:17 < icenowy[m]> I think now in Europe it should be winter? Let
⢿⡄⠘⠷⠚⠋⠀ the BPi warm you ;-)
⠈⠳⣄ 14:17 <@KotCzarny> yeah, i have a pc to warm me ;)

Bug#883624: transition: libkf5kipi + marble 17.08

[Pino Toscano]

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

Hi,

I would like to request a slot for the transitions of libkf5kipi 17.08
and marble 17.08.  I'm requesting a single slot for them as the impact
of each is limited, and they boh affect digikam (big source, so one
rebuild can be avoided).

The sources affected by libkf5kipi are:
- digikam
- gwenview
- kde-spectacle
- kphotoalbum
The sources affected by marble are:
- digikam
- kreport
- libkf5kgeomap

I will wait for this weekend for the batch of 17.08 uploads I did last
weekend to migrate to testing: the reason is that the new versions of
libkf5kipi and marble carry their translations files, right now shipped
as part of kde-l10n (and thus a coordinated upload is needed, I will
take care of it).

Thanks,
-- 
Pino

Bug#883623: src:ceph: Please provide ceph 12.2.2+ and ceph-deploy 1.5.39+

[Witold Baryluk]

Package: src:ceph
Severity: minor


According to http://docs.ceph.com/docs/master/releases/ , ceph 10.2.x is
going to be retrired in June 2018.

Also 12.2.x series makes few important features available or finally stable:

 * BlueStore backend storage [higher performance, better data integrity, no 
need to use XFS anymore].
 * ceph-mgr, including web dashboard, and prometheus monitoring
 * The new balancer module enables automatic optimization of CRUSH weights to 
balance data across the cluster.
 * Dynamic resharding is now enabled by default for RGW, RGW will now 
automatically reshard there bucket index once the index grows beyond 
rgw_max_objs_per_shard
 * Improved scalability to thousends of nodes / OSDs.
 * CephFS: Multiple active MDS daemons is now considered stable.
 * CephFS directory fragmentation is now stable and enabled by default on new 
filesystems. 
 * Erasure coded pools now have full support for overwrites, allowing them to 
be used with RBD and CephFS.
 * Each OSD now adjusts its default configuration based on whether the backing 
device is an HDD or SSD. Manual tuning generally not required.
 * RGW introduces server side encryption of uploaded objects [...]
 * RGW has consolidated the several metadata index pools via the use of rados 
namespaces.
 * RBD now has full, stable support for erasure coded pools via the new 
--data-pool option to rbd create.
 * CephFS: Client keys can now be created using the new ceph fs authorize 
command to create keys with access to the given CephFS file system and all of 
its data pools.
 * RGW now supports the S3 multipart object copy-part API.
 * Support for NFS version 3 has been added to the RGW NFS gateway.
 * RGW now supports data compression for objects.
 * New monitors default to using rocksdb keyvaluedb.
 * CephFS: Standby replay MDS daemons now consume less memory on workloads 
doing deletions.
 * The jerasure and shec plugins can now detect SIMD instruction at runtime and 
no longer need to be explicitly configured for different processors.

and thousands of other improvements, performance, stability improvements, 
features
and bugfixes.

http://docs.ceph.com/docs/master/release-notes/#v12-2-0-luminous
http://docs.ceph.com/docs/master/release-notes/#v12-2-1-luminous
http://docs.ceph.com/docs/master/release-notes/#v12-2-2-luminous


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

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

Bug#883622: transition: analitza 17.08

[Pino Toscano]

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

Hi,

I would like to request a slot for the analitza 17.08.x transition.
There are only two affected sources:
- kalgebra (which will get a sourceful upload)
- cantor, which just needs a rebuild

I will wait for this weekend for the batch of 17.08 uploads I did last
weekend to migrate to testing: the reason is that the new versions of
analitza and kalgebra carry their translations files, right now shipped
as part of kde-l10n (and thus a coordinated upload is needed, I will
take care of it).

Thanks,
-- 
Pino

Bug#881456: uninstall, purge, reinstall > segfault

[Tobias Frost]

On Sat, Dec 02, 2017 at 10:33:30AM +, Marcos Raúl Carot wrote:

Thanks for providing the information!

> Just to be sure, I purged gmediarender and re-installed.
> 
> Same as before, but running manually ends with a segfault:

This is probably #883118.

(I'm just wondering why it segfaults after the reinstall...)

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

So, I finally got a chance to look at this.
It sounds like you're taking a significantly different approach than we
had discussed earlier.

What we had talked about is parsing the output of $CC.  For example
asking gcc what tripple it was built for and going from there.

But what you did is assume that the gcc path encodes the tripple with
the special case of supporting -m32 assuming that it is the first option
in $CC (and not say in $CFLAGS).

It looks like this was probably a bit easier to code, but looks like it
has the following weaknesses:

* Assumes that -m64 is always on a x86_64 system rather than using gcc
-m64 to build for x86_64 on an 686 system.

* assumes that -m32 and -m64 are only used on x86 architectures

* Mishandles setups where rather than set all the compiler variables, a
  directory including cross tools is prepended to PATH

Are there advantages beyond implementation simplicity over what we
talked about previously?

Bug#883118: gmediarender crashes when gets an upnp search

[Tobias Frost]

Control: tags -1 confirmed
Control: severity -1 serious

Hi, 

thanks for the notice. I saw the segfault also when I was debugging
#881456 but I could not spend enough time on it...
It seesm that the crash occurs deep inside libupnpr6...

Will try to spend some time debugging this on the weekend.

--
tobi

Bug#883562: ejabberd suddenly take all cpu

[Joerg Dorchain]

On Tue, Dec 05, 2017 at 09:07:07PM +0100, Philipp Huebner wrote:
> 
> I assume you have already tried rebooting ejabberd / the whole server?

Yes, helps temporarily. Also, after a while (~1h) it gets better
by itself, only to become a cpu hog again.

> Have you set the log level to debug (5)?
> https://docs.ejabberd.im/admin/guide/troubleshooting/#log-files

Not yet, I've been running at loglevel 4 by now. Set it to 5 now,
waiting for the next occurence.

> Other than that, please check dmesg and make sure it is not due to the
> recently automatically enabled AppArmor.

No, there isn't any trace of that. I only find a libapparmor1 as
a dependency of a package.
> 
> If one (or all) of the updated erlang-p1-* packages has caused this, the
> solution is to update the ejabberd package, which I cannot do yet due to
> #883017.

When the new loglevel does not reveal anything, I'll check the
dates when my erlang_p1* packages entered testing and try rolling
back one version.

Bye,

Joerg


signature.asc
Description: PGP signature

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

Hi,

I reinstalled NVidia driver several times and the problem is still the
same. Trying your method still results in the same issue.

Now if I fully blacklist the nvidia driver I get a "better" black screen w/
Nouveau, in the sense that keyboard answers. Thus Xorg.0.log does not hang
on the GLX stuff.

Looks like this issue targets GeForce 10xx GPUs (as my 970 does seem
unaffected as well).

Rgds



2017-12-05 21:13 GMT+01:00 Luca Boccassi :

> On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote:
> > Looks like the culprit is NVidia modeset. Thus the issue does not
> > happen w/
> > a Maxwell GPU.
> >
> > [  542.167979] nvidia-modeset: Allocated GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> >
> >
> > [  542.490521] nvidia-modeset: Freed GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > [  544.081034] nvidia-modeset: Allocated GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > [  544.385426] nvidia-modeset: Freed GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > [  546.079744] nvidia-modeset: Allocated GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > [  546.399641] nvidia-modeset: Freed GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > [  548.091421] nvidia-modeset: Allocated GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > [  548.395724] nvidia-modeset: Freed GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > [  550.088731] nvidia-modeset: Allocated GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> > [  550.392898] nvidia-modeset: Freed GPU:0
> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
>
> Didn't see any issue with my 780 (Kepler?).
>
> Are you sure the kernel modules is correctly rebuilt? I've seen that
> there was a kernel point release, and not all ABI changes are reverted.
> Which means DKMS won't rebuild the modules automatically.
>
> Try to remove it and rebuild it with:
>
> sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64
> sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64
> > 2017-12-05 20:51 GMT+01:00 Julien Aubin :
> >
> > > Driver hangs just here :
> > > --->
> > > [32.680] (II) Initializing extension GLX
> > > [32.680] (II) Indirect GLX disabled.
> > > >
> > >
> > > Normally I should get then [34.659] (II) config/udev: Adding
> > > input
> > > device Power Button (/dev/input/event5)
> > >
> > > But here it crashes without log.
> > >
> > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System <
> > > ow...@bugs.debian.org>:
> > >
> > > > Thank you for filing a new Bug report with Debian.
> > > >
> > > > You can follow progress on this Bug here: 883615:
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615.
> > > >
> > > > This is an automatically generated reply to let you know your
> > > > message
> > > > has been received.
> > > >
> > > > Your message is being forwarded to the package maintainers and
> > > > other
> > > > interested parties for their attention; they will reply in due
> > > > course.
> > > >
> > > > Your message has been sent to the package maintainer(s):
> > > >  Debian NVIDIA Maintainers  > > > org>
> > > >
> > > > If you wish to submit further information on this problem, please
> > > > send it to 883...@bugs.debian.org.
> > > >
> > > > Please do not send mail to ow...@bugs.debian.org unless you wish
> > > > to report a problem with the Bug-tracking system.
> > > >
> > > > --
> > > > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615
> > > > Debian Bug Tracking System
> > > > Contact ow...@bugs.debian.org with problems
> > > >
> > >
> > >
> >
> > ___
> > pkg-nvidia-devel mailing list
> > pkg-nvidia-de...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-de
> > vel

Bug#803890: chntpw: New samunlock binary. Unlock windows users automatically from cli - Add patch tag

[adrian15]

Control: tags -1 + patch

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#883620: More informations

[Jean-Philippe Guérard]

After more digging, it appears that the permissions on 
/var/lib/roundcube/temp on my server did not allow writing for the PHP 
user.


So the file was created in /tmp instead.

You can close the bug, or add an exception for this kind of situations 
(that would be nice).


Thanks.

Bug#803888: chntpw: sampasswd not working as it's not writing its hive - Add patch tag

[adrian15]

Control: tags -1 + patch

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#803884: sampasswd.c: Wrong definition - Add patch tag

[adrian15]

Control: tags -1 + patch

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#803883: samusrgrp.c: Interactive TYPO - Add patch tag

[adrian15]

Control: tags -1 + patch

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#883431: eureka: grabs focus when I mouse over the map view subwindow

[Fabian Greffrath]

Control: forwarded -1 https://sourceforge.net/p/eureka-editor/tickets/22/
Control: tags -1 upstream confirmed


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

Bug#882007: openssl: add mips r6 support

[Sebastian Andrzej Siewior]

On 2017-11-28 21:15:29 [+0100], To YunQiang Su wrote:
> control: forwarded -1 https://github.com/openssl/openssl/pull/4813
> On 2017-11-18 05:45:29 [+0800], YunQiang Su wrote:
> > If you can help to forward, it will be great.
> 
> done.

Upstream as of 1.1.1 has R6 support the asm part and that was the main
culprit for the mipsr6 targets in 10-*. I smashed that into 20-* and
intend to keep it there for now. Once we move to 1.1.1 I would drop them
and switch to the R6 asm. That means we keep debian-mipsr6 targets and
drop linux-mips32r6 and so on. This is what I have now:


https://git.breakpoint.cc/cgit/bigeasy/openssl-debian.git/commit/?h=debian/unstable=7c7ee04fd1d4ef2b30a239d3b1002a1cec6541db

This should work for you, does it?
 
Sebastian

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

[Julian Andres Klode]

On Tue, Dec 05, 2017 at 09:32:19PM +0100, Julian Andres Klode wrote:
> Control: reassign 883555 systemd-shim
> Control: retitle 883555 systemd-shim should be Multi-Arch: foreign
> 
> On Tue, Dec 05, 2017 at 06:19:28PM +, Ian Jackson wrote:
> > Julian Andres Klode writes ("Re: Bug#883573: Reevaluate libpam-systemd 
> > systemd-sysv dependency ordering (746578)"):
> > > I think another major problem (with bug 883555) though is that 
> > > systemd-shim
> > > is not Multi-Arch: foreign like systemd-sysv. In that case, systemd-shim 
> > > was
> > > first marked for install, but then for removal as systemd-shim:foreign 
> > > was to
> > > be installed. And then it picked systemd-sysv somehow. In summary, 
> > > libpam-systemd:foreign
> > > is currently not installable if systemd-shim is installed.
> > 
> > I think that perhaps systemd-shim should be marked M-A foreign.  Its
> > function is to provide a dbus service which AIUI is not
> > architecture-dependent.  I can easily upload such a change at this
> > stage of the buster cycle.
> 
> Please do so, I think that's probably the major issue. I'm reassigning 
> helmut's
> bug to systemd-shim, as that should fix that specific issue.
> 
> > 
> > > > FAOD, I regard myself as a caretaker for system-shim.
> > > 
> > > Then please adopt the package?
> > 
> > I definitely don't feel the sense of knowledge or ownership that would
> > be appropriate for that.
> > 
> > > On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote:
> > > > One question I have is about this: "several packages now require just
> > > > systemd-sysv".  Can someone refer to some examples, please ?
> > >
> > ...
> > > $ grep-aptavail -FDepends systemd-sysv --and --not -FDepends systemd-shim 
> > > -nsPackage | grep -v ^jak
> > > friendly-recovery
> > > gpsd
> > > mandos
> > > micro-httpd
> > > munin
> > > numad
> > > pk4
> > > prometheus
> > > prometheus-node-exporter
> > > runit-systemd
> > > systemd-cron
> > > gpsd
> > > micro-httpd
> > > numad
> > > pk4
> > > prometheus
> > > prometheus-node-exporter
> > > systemd-cron
> > > freeipa-server
> > > tinysshd
> > > tinysshd
> > 
> > What ?  Why do these packages depend on system-sysv ?  (I mean, for
> > systemd-cron it's kind of obvious but for most of the others it is
> > not.)  I checked gpsd as that was something I thought I knew something
> > about and that Depends on netbase | systemd-sysv, which is rather
> > different and seems OK.
> > 
> > I reran your search in sid with --not -FDepends netbase and got a
> > shorter list.
> > 
> >   freeipa-server
> >   friendly-recovery
> >   lava-dispatcher
> >   lava-server
> >   mandos
> >   micro-httpd
> >   munin
> >   numad
> >   pk4
> >   prometheus
> >   prometheus-node-exporter
> >   runit-systemd
> >   systemd-cron
> > 
> > That still seems to have quite a few false positives (micro-httpd,
> > mandos), as well as some minority packages that seem to have gained or
> > maybe always had unfortunate specific init system dependencies
> > (freeipa-server, friendly-recovery).  I haven't investigated them in
> > detail.
> > 
> > Do you have an example package that is causing the installation
> > failure ?
> 
> I don't have any example. DonKult says he's seen a lot of issues,
> so he should comment on that. I'm not sure how far they are also
> just caused by systemd-shim not being m-a foreign.
> 
> We generally request that dependencies in an or group have the same
> order (so if one has A | B and the other B, that's a different order),
> as that can cause problems in unexpected places when using our
> crappy solver, especially if they are at a low level.

That said, one approach mbiebl proposed in #debian-systemd which might
be better anyway is to swap the dependency order in libpam-systemd and
mark systemd-sysv and sysvinit-core with XB-Important: yes.

This should have the effect actually intended: Prevent accidental
init switching, while still pulling in systemd-sysv on systems
that don't have an init, but depend on systemd-shim | systemd-sysv.

To switch an init, a user likely would have to pass
--allow-remove-essential to apt. We should have a different
flag for XB-Important, but that depends on it getting a final
official name...

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#883621: nova: CVE-2017-17051: Nova FilterScheduler doubles resource allocations during rebuild with new image

[Salvatore Bonaccorso]

Source: nova
Version: 2:16.0.3-1
Severity: grave
Tags: security upstream

Hi,

the following vulnerability was published for nova.

CVE-2017-17051[0]:
| An issue was discovered in the default FilterScheduler in OpenStack
| Nova 16.0.3. By repeatedly rebuilding an instance with new images, an
| authenticated user may consume untracked resources on a hypervisor host
| leading to a denial of service, aka doubled resource allocations. This
| regression was introduced with the fix for OSSA-2017-005
| (CVE-2017-16239); however, only Nova stable/pike or later deployments
| with that fix applied and relying on the default FilterScheduler are
| affected.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-17051
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17051
[1] http://www.openwall.com/lists/oss-security/2017/12/05/5

Regards,
Salvatore

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

[Julian Andres Klode]

Control: reassign 883555 systemd-shim
Control: retitle 883555 systemd-shim should be Multi-Arch: foreign

On Tue, Dec 05, 2017 at 06:19:28PM +, Ian Jackson wrote:
> Julian Andres Klode writes ("Re: Bug#883573: Reevaluate libpam-systemd 
> systemd-sysv dependency ordering (746578)"):
> > I think another major problem (with bug 883555) though is that systemd-shim
> > is not Multi-Arch: foreign like systemd-sysv. In that case, systemd-shim was
> > first marked for install, but then for removal as systemd-shim:foreign was 
> > to
> > be installed. And then it picked systemd-sysv somehow. In summary, 
> > libpam-systemd:foreign
> > is currently not installable if systemd-shim is installed.
> 
> I think that perhaps systemd-shim should be marked M-A foreign.  Its
> function is to provide a dbus service which AIUI is not
> architecture-dependent.  I can easily upload such a change at this
> stage of the buster cycle.

Please do so, I think that's probably the major issue. I'm reassigning helmut's
bug to systemd-shim, as that should fix that specific issue.

> 
> > > FAOD, I regard myself as a caretaker for system-shim.
> > 
> > Then please adopt the package?
> 
> I definitely don't feel the sense of knowledge or ownership that would
> be appropriate for that.
> 
> > On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote:
> > > One question I have is about this: "several packages now require just
> > > systemd-sysv".  Can someone refer to some examples, please ?
> >
> ...
> > $ grep-aptavail -FDepends systemd-sysv --and --not -FDepends systemd-shim 
> > -nsPackage | grep -v ^jak
> > friendly-recovery
> > gpsd
> > mandos
> > micro-httpd
> > munin
> > numad
> > pk4
> > prometheus
> > prometheus-node-exporter
> > runit-systemd
> > systemd-cron
> > gpsd
> > micro-httpd
> > numad
> > pk4
> > prometheus
> > prometheus-node-exporter
> > systemd-cron
> > freeipa-server
> > tinysshd
> > tinysshd
> 
> What ?  Why do these packages depend on system-sysv ?  (I mean, for
> systemd-cron it's kind of obvious but for most of the others it is
> not.)  I checked gpsd as that was something I thought I knew something
> about and that Depends on netbase | systemd-sysv, which is rather
> different and seems OK.
> 
> I reran your search in sid with --not -FDepends netbase and got a
> shorter list.
> 
>   freeipa-server
>   friendly-recovery
>   lava-dispatcher
>   lava-server
>   mandos
>   micro-httpd
>   munin
>   numad
>   pk4
>   prometheus
>   prometheus-node-exporter
>   runit-systemd
>   systemd-cron
> 
> That still seems to have quite a few false positives (micro-httpd,
> mandos), as well as some minority packages that seem to have gained or
> maybe always had unfortunate specific init system dependencies
> (freeipa-server, friendly-recovery).  I haven't investigated them in
> detail.
> 
> Do you have an example package that is causing the installation
> failure ?

I don't have any example. DonKult says he's seen a lot of issues,
so he should comment on that. I'm not sure how far they are also
just caused by systemd-shim not being m-a foreign.

We generally request that dependencies in an or group have the same
order (so if one has A | B and the other B, that's a different order),
as that can cause problems in unexpected places when using our
crappy solver, especially if they are at a low level.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#883604: ntfs-3g: The changelog.gz doesn't any mention from 2014 onwards

[Jean-Pierre André]

> so it seems better to switch back following the AR releases, right?

This is not really a decision by me, I suppose you have
to follow some Debian guidelines.

I can only add that, if no distribution is interested in
the AR releases, the Tuxera versions will be less tested
before they are released. IMHO through its progressive
release steps (unstable, experimental, etc) Debian has a
better policy than most distributions to detect defects
in new versions before they reach unexperienced users.

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Luca Boccassi]

On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote:
> Looks like the culprit is NVidia modeset. Thus the issue does not
> happen w/
> a Maxwell GPU.
> 
> [  542.167979] nvidia-modeset: Allocated GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> 
> 
> [  542.490521] nvidia-modeset: Freed GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> [  544.081034] nvidia-modeset: Allocated GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> [  544.385426] nvidia-modeset: Freed GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> [  546.079744] nvidia-modeset: Allocated GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> [  546.399641] nvidia-modeset: Freed GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> [  548.091421] nvidia-modeset: Allocated GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> [  548.395724] nvidia-modeset: Freed GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> [  550.088731] nvidia-modeset: Allocated GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
> [  550.392898] nvidia-modeset: Freed GPU:0
> (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0

Didn't see any issue with my 780 (Kepler?).

Are you sure the kernel modules is correctly rebuilt? I've seen that
there was a kernel point release, and not all ABI changes are reverted.
Which means DKMS won't rebuild the modules automatically.

Try to remove it and rebuild it with:

sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64
sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64
> 2017-12-05 20:51 GMT+01:00 Julien Aubin :
> 
> > Driver hangs just here :
> > --->
> > [32.680] (II) Initializing extension GLX
> > [32.680] (II) Indirect GLX disabled.
> > >
> > 
> > Normally I should get then [34.659] (II) config/udev: Adding
> > input
> > device Power Button (/dev/input/event5)
> > 
> > But here it crashes without log.
> > 
> > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System <
> > ow...@bugs.debian.org>:
> > 
> > > Thank you for filing a new Bug report with Debian.
> > > 
> > > You can follow progress on this Bug here: 883615:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615.
> > > 
> > > This is an automatically generated reply to let you know your
> > > message
> > > has been received.
> > > 
> > > Your message is being forwarded to the package maintainers and
> > > other
> > > interested parties for their attention; they will reply in due
> > > course.
> > > 
> > > Your message has been sent to the package maintainer(s):
> > >  Debian NVIDIA Maintainers  > > org>
> > > 
> > > If you wish to submit further information on this problem, please
> > > send it to 883...@bugs.debian.org.
> > > 
> > > Please do not send mail to ow...@bugs.debian.org unless you wish
> > > to report a problem with the Bug-tracking system.
> > > 
> > > --
> > > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615
> > > Debian Bug Tracking System
> > > Contact ow...@bugs.debian.org with problems
> > > 
> > 
> > 
> 
> ___
> pkg-nvidia-devel mailing list
> pkg-nvidia-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-de
> vel

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

Bug#883407: libc6: getpwnam_r() leaks memory

[Tim Ruehsen]

Am Dienstag, den 05.12.2017, 19:17 +0100 schrieb Aurelien Jarno:
> On 2017-12-03 17:34, Tim Rühsen wrote:
> > Package: libc6
> > Version: 2.25-3
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > valgrinding a C code shows the following:
> > 
> > ==27943== 4,096 bytes in 1 blocks are definitely lost in loss
> > record 3 of 3
> > ==27943==by 0x6C27715: getpwnam_r@@GLIBC_2.2.5
> > (getXXbyYY_r.c:314)
> > ==27943==by 0x4E8569F: rpl_glob (glob.c:781)
> > 
> > That rpl_glob() is gnulib's glob replacement. The code there looks
> > good.
> > And valgrind doesn't/didn't show this leak with previous (2.24 and
> > lower)
> > versions of glibc.
> > 
> > I can't currently provide you with a short reproducer (out of time
> > here).
> 
> It's not something I can reproduce here, but getpwnam_r can behave
> very
> differently depending on the nss configuration your system. A small
> reproducer and the content of /etc/nsswitch.conf would definitely
> help.
> 
I'll try to make up a reproducer the next days. Here is more info that
I have to far.

### nsswitch.conf ###
passwd: compat systemd
group:  compat systemd
shadow: compat

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis


> That said libc6 version 2.25-3 included security fixes and memory
> leak
> fixes for the glob function. Can you confirm the version you used,
> and
> if it's really 2.25-3 try with version 2.25-2 which is still in
> testing.
> 

The glob issues have been found by me when fuzzing GNU Wget2. Reported
via gnulib mailing list :-)

Just updated my stretch VM to testing... I can reproduce the issue with
2.25-2 (testing) and with 2.25-3 (unstable).

Regards, Tim

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

Bug#883562: ejabberd suddenly take all cpu

[Philipp Huebner]

Hi

Am 05.12.2017 um 10:46 schrieb Joerg Dorchain:
> with a sudden change ejabberd takes all cpu time on all core,
> leading to very high system loads.
> 
> I am not aware of any specific change except erlang_p1* file
> entered testing recently.
> 
> I do not see an apparant reason, and find nothing in the ejabberd
> log.
> 
> How can I debug this any furhter?

I assume you have already tried rebooting ejabberd / the whole server?

Have you set the log level to debug (5)?
https://docs.ejabberd.im/admin/guide/troubleshooting/#log-files

Other than that, please check dmesg and make sure it is not due to the
recently automatically enabled AppArmor.

If one (or all) of the updated erlang-p1-* packages has caused this, the
solution is to update the ejabberd package, which I cannot do yet due to
#883017.

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#357051: libc.info s9.4 qsort example is wrong

[Aurelien Jarno]

Version: 2.16-0experimental1

On 2006-03-15 13:31, Richard Kettlewell wrote:
> Package: glibc-doc
> Version: 2.3.2.ds1-22
> 
> The example for qsort has, among other things:
> 
>  int
>  critter_cmp (const struct critter *c1, const struct critter *c2)
>  {
>return strcmp (c1->name, c2->name);
>  }
> 
>  /* ... */
> 
>result = bsearch (, muppets, count, sizeof (struct critter),
>  critter_cmp);
> 
>  /* ... */
> 
>qsort (muppets, count, sizeof (struct critter), critter_cmp);
> 
> This is incorrect.  The comparison function must be declared as
> 
>   int critter_cmp (const void *c1, const void *c2)
> 
> and should use casts to convert to the proper type.

This has been fixed in version 2.16, in upstream commit e39745ffa030.
Closing the bug.

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

Bug#883619: libceres-dev: dependency on libeigen3-dev isn't strong enough

[Philipp Huebner]

Hi

Am 05.12.2017 um 20:11 schrieb Dima Kogan:
> Hi. Currently in libceres-dev we have
> 
>   Depends: libeigen3-dev (>= 3.2.1)
> 
> However in /usr/lib/cmake/Ceres/CeresConfig.cmake it does
> 
>   set(CERES_EIGEN_VERSION 3.3.4)
> 
> And then proceeds to barf if this wasn't found. The Depends should be
> tightened accordingly, or the requirement in the .cmake file should be
> loosened, if it CAN work with < 3.3.4.

This dependency is set automatically during the version of eigen present
during the build process, that's why #868355 is still open.

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#883595: [pkg-cryptsetup-devel] Bug#883595: cryptsetup: Cannot mount encrypted root using XTS on kernel 4.10 onwards

[Guilhem Moulin]

Control: retitle  -1 xts module should depend on ecb
Control: reassign -1 src:linux 4.10.1-1
Control: affects  -1 cryptsetup

On Tue, 05 Dec 2017 at 14:16:42 +, Francis Russell wrote:
> Apparently from Linux 4.10 onwards, the ecb module became a dependency
> of xts[1]. I am running a custom kernel in which both XTS and ECB are
> built as modules (kernel config attached for 4.14.3). However, ECB does
> not appear in the initrd, causing the system to be unable to mount the
> encrypted root.

The issue was reported against cryptsetup's upstream BTS earlier this
year: https://gitlab.com/cryptsetup/cryptsetup/issues/319 .

> It's unclear to me how this dependency should be picked up.

The xts module needs to explicitly depend on ecb.  AFAICT Milan's patch
[0] has been applied to 4.14.0-1-amd64, but modinfo(8) still doesn't
list ecb in its dependencies, so the initramfs hook file doesn't pull it
automatically.

In the meantime, a workaround is to manually add ‘ecb’ to
/etc/initramfs-tools/modules.  Doesn't seem needed on systems with
AES-NI support, though; there I don't have ecb in the initrd, and

$ grep '^driver\s*:\s*xts' /proc/crypto 
driver   : xts-aes-aesni

while on a system without AES-NI support:

$ grep '^driver\s*:\s*xts' /proc/crypto 
driver   : xts(ecb(aes-asm))

-- 
Guilhem.

[0] https://marc.info/?l=linux-crypto-vger=148783562211457=4


signature.asc
Description: PGP signature

Bug#883620: roundcube: Since the last upgrade, attachment can't be sent anymore

[Jean-Philippe Guérard]

Package: roundcube
Version: 1.2.3+dfsg.1-4+deb9u1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

 Latest Roundcube upgrade

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 Send a message with an attachment.

   * What was the outcome of this action?

 The attachment is not on the sent message, neither on the
 stored copy in the sent folder.

   * What outcome did you expect instead?

 Attachement sent and stored in the sent folder.

*** End of the template - remove these template lines ***

I get the following error in my log files :

Dec  5 20:17:59  roundcube:  PHP Error: toto can't read 
/tmp/rcmAttmntjoFOF5 (not in temp_dir) in 
/usr/share/roundcube/plugins/filesystem_attachments/filesystem_attachments.php 
on line 216 (POST 
/roundcube/?_task=mail&_unlock=loading1512501479300&_lang=fr&_framed=1&_action=send)

The temp_dir variable is the default:
$config['temp_dir'] = RCUBE_INSTALL_PATH . 'temp/';

So, the problem is that the temp file is created in /tmp, and, since it's not
in the Roundcube configured temp dir (/var/lib/roundcube/temp), roundcube 
removes it...

Configuring the temp_dir variable to /tmp/ solves the issue:
$config['temp_dir'] = '/tmp/';

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages roundcube depends on:
ii  dpkg1.18.24
ii  roundcube-core  1.2.3+dfsg.1-4+deb9u1

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  dbconfig-common 2.0.8
ii  debconf [debconf-2.0]   1.5.61
ii  dpkg1.18.24
ii  libapache2-mod-php  1:7.0+49
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.19-1
ii  libmagic1   1:5.30-1+deb9u1
ii  php-auth-sasl   1.0.6-3
ii  php-cli 1:7.0+49
ii  php-common  1:49
ii  php-intl1:7.0+49
ii  php-mail-mime   1.10.0-2
ii  php-mcrypt  1:7.0+49
ii  php-net-smtp1.7.1-2
ii  php-net-socket  1.0.14-2
ii  php-pear1:1.10.1+submodules+notgz-9
ii  php7.0-cli [php-cli]7.0.19-1
ii  php7.0-intl [php-intl]  7.0.19-1
ii  php7.0-json [php-json]  7.0.19-1
ii  php7.0-mcrypt [php-mcrypt]  7.0.19-1
ii  roundcube-pgsql 1.2.3+dfsg.1-4+deb9u1
ii  ucf 3.0036

Versions of packages roundcube-core recommends:
ii  php-gd  1:7.0+49
ii  php-pspell  1:7.0+49
ii  php7.0-gd [php-gd]  7.0.19-1
ii  php7.0-pspell [php-pspell]  7.0.19-1
ii  spawn-fcgi  1.6.4-1+b1

Versions of packages roundcube-core suggests:
pn  php-crypt-gpg  
pn  php-net-ldap2  
pn  php-net-ldap3  
ii  roundcube-plugins  1.2.3+dfsg.1-4+deb9u1

-- debconf information:
  roundcube/restart-webserver: true
  roundcube/pgsql/manualconf:
  roundcube/dbconfig-remove: true
  roundcube/language: fr_FR
  roundcube/pgsql/no-empty-passwords:
  roundcube/purge: false
  roundcube/remote/port:
  roundcube/mysql/method: Unix socket
  roundcube/install-error: ignore
* roundcube/db/app-user: roundcube@localhost
* roundcube/pgsql/authmethod-admin: ident
  roundcube/internal/skip-preseed: false
* roundcube/dbconfig-install: false
  roundcube/mysql/admin-user:
  roundcube/db/basepath:
* roundcube/dbconfig-upgrade: true
  roundcube/hosts:
  roundcube/dbconfig-reinstall: false
* roundcube/upgrade-backup: true
  roundcube/remote/host: localhost
  roundcube/pgsql/changeconf: false
* roundcube/upgrade-error: ignore
  roundcube/internal/reconfiguring: false
  roundcube/remove-error: abort
  roundcube/remote/newhost:
* roundcube/pgsql/authmethod-user: password
* roundcube/pgsql/admin-user: postgres
* roundcube/pgsql/method: Unix socket
  roundcube/missing-db-package-error: abort
* roundcube/db/dbname: roundcube
  roundcube/reconfigure-webserver: apache2, lighttpd
  roundcube/passwords-do-not-match:
  roundcube/database-type: pgsql

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

Looks like the culprit is NVidia modeset. Thus the issue does not happen w/
a Maxwell GPU.

[  542.167979] nvidia-modeset: Allocated GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0


[  542.490521] nvidia-modeset: Freed GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
[  544.081034] nvidia-modeset: Allocated GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
[  544.385426] nvidia-modeset: Freed GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
[  546.079744] nvidia-modeset: Allocated GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
[  546.399641] nvidia-modeset: Freed GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
[  548.091421] nvidia-modeset: Allocated GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
[  548.395724] nvidia-modeset: Freed GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
[  550.088731] nvidia-modeset: Allocated GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0
[  550.392898] nvidia-modeset: Freed GPU:0
(GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0


2017-12-05 20:51 GMT+01:00 Julien Aubin :

> Driver hangs just here :
> --->
> [32.680] (II) Initializing extension GLX
> [32.680] (II) Indirect GLX disabled.
> >
>
> Normally I should get then [34.659] (II) config/udev: Adding input
> device Power Button (/dev/input/event5)
>
> But here it crashes without log.
>
> 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System <
> ow...@bugs.debian.org>:
>
>> Thank you for filing a new Bug report with Debian.
>>
>> You can follow progress on this Bug here: 883615:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615.
>>
>> This is an automatically generated reply to let you know your message
>> has been received.
>>
>> Your message is being forwarded to the package maintainers and other
>> interested parties for their attention; they will reply in due course.
>>
>> Your message has been sent to the package maintainer(s):
>>  Debian NVIDIA Maintainers 
>>
>> If you wish to submit further information on this problem, please
>> send it to 883...@bugs.debian.org.
>>
>> Please do not send mail to ow...@bugs.debian.org unless you wish
>> to report a problem with the Bug-tracking system.
>>
>> --
>> 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615
>> Debian Bug Tracking System
>> Contact ow...@bugs.debian.org with problems
>>
>
>

Bug#883604: ntfs-3g: The changelog.gz doesn't any mention from 2014 onwards

[GCS]

On Tue, Dec 5, 2017 at 8:03 PM, Jean-Pierre André
 wrote:
>> As I understood, Jean-Pierre abandoned the AR releases
>
> Not at all. The only recent change is that Tuxera is not
> referencing the AR releases any more, but they still exist
> and they are a way to push fixes without being tied to
> Tuxera policy of having one release per year. AR changes
> are pushed to Tuxera, and the changes rejected by Tuxera
> are also rejected from the subsequent AR releases.
>
> From a distribution point of view, Tuxera releases are
> more stable, and AR releases are more up to date why implies
> more risks of being defective.
 Thanks for all the information. OK, so it seems better to switch back
following the AR releases, right?

Cheers,
Laszlo/GCS

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Julien Aubin]

Driver hangs just here :
--->
[32.680] (II) Initializing extension GLX
[32.680] (II) Indirect GLX disabled.
>

Normally I should get then [34.659] (II) config/udev: Adding input
device Power Button (/dev/input/event5)

But here it crashes without log.

2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System :

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 883615:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian NVIDIA Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 883...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#883619: libceres-dev: dependency on libeigen3-dev isn't strong enough

[Dima Kogan]

Package: libceres-dev
Version: 1.13.0+dfsg0-1
Severity: normal

Hi. Currently in libceres-dev we have

  Depends: libeigen3-dev (>= 3.2.1)

However in /usr/lib/cmake/Ceres/CeresConfig.cmake it does

  set(CERES_EIGEN_VERSION 3.3.4)

And then proceeds to barf if this wasn't found. The Depends should be
tightened accordingly, or the requirement in the .cmake file should be
loosened, if it CAN work with < 3.3.4.

Thanks

Bug#883618: virt-manager: Can't scroll in virt-manager

[Witold Baryluk]

Package: virt-manager
Version: 1:1.4.3-1
Severity: normal

Similar to https://bugzilla.redhat.com/show_bug.cgi?id=1386602

I am not able to use mouse scroll wheel in guest VMs. Either Debian
Stretch Live MATE and in Windows 8.1.


Debug output

baryluk@wielkiczarny:~$ virt-manager --debug --no-fork
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (cli:264) Launched with 
command line: /usr/share/virt-manager/virt-manager --debug --no-fork
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (virt-manager:185) 
virt-manager version: 1.4.3
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (virt-manager:186) 
virtManager import: 

(virt-manager:24524): Gtk-WARNING **: Theme parsing error: gtk.css:7:21: The 
'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (virt-manager:216) 
PyGObject version: 3.26.1
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (virt-manager:220) GTK 
version: 3.22.26
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (engine:497) libguestfs 
inspection support: True
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (inspection:87) waiting
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (systray:74) Using 
AppIndicator3 for systray
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (systray:156) Showing 
systray: False
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (engine:1032) processing 
cli command uri= show_window= domain=
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (engine:1034) No cli 
action requested, launching default window
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (manager:203) Showing 
manager
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (engine:402) window 
counter incremented to 1
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (engine:161) Loading 
stored URIs:
qemu:///system
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (engine:140) Initial 
gtkapplication activated
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (connection:602) 
conn=qemu:///system changed to state=Łączenie
[wto, 05 gru 2017 20:12:51 virt-manager 24524] DEBUG (connection:1019) 
Scheduling background open thread for qemu:///system
[wto, 05 gru 2017 20:12:55 virt-manager 24524] DEBUG (connection:1069) libvirt 
version=3009000
[wto, 05 gru 2017 20:12:55 virt-manager 24524] DEBUG (connection:1071) daemon 
version=3009000
[wto, 05 gru 2017 20:12:56 virt-manager 24524] DEBUG (connection:1072) conn 
version=2010001
[wto, 05 gru 2017 20:12:56 virt-manager 24524] DEBUG (connection:1074) 
qemu:///system capabilities:


  
03000200-0400-0500-0006-000700080009

  x86_64
  SandyBridge
  Intel
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  


  
  
tcp
rdma
  


  

  32962740
  8240685
  0
  0
  

  
  












  

  


  


  apparmor
  0


  dac
  0
  +118:+140
  +118:+140

  

  
hvm

  64
  /usr/bin/qemu-system-alpha
  clipper
  
/usr/bin/qemu-system-alpha
  


  
  
  

  

  
hvm

  32
  /usr/bin/qemu-system-arm
  integratorcp
  nuri
  mps2-an511
  verdex
  ast2500-evb
  smdkc210
  collie
  imx25-pdk
  spitz
  realview-pbx-a9
  realview-eb
  versatilepb
  realview-pb-a8
  virt-2.9
  musicpal
  z2
  akita
  virt-2.7
  kzm
  virt-2.8
  realview-eb-mpcore
  sx1
  sx1-v1
  virt-2.6
  cubieboard
  highbank
  raspi2
  netduino2
  terrier
  n810
  mainstone
  palmetto-bmc
  sabrelite
  midway
  romulus-bmc
  cheetah
  tosa
  borzoi
  versatileab
  lm3s6965evb
  n800
  virt-2.10
  virt
  connex
  xilinx-zynq-a9
  mps2-an385
  vexpress-a9
  vexpress-a15
  canon-a1100
  lm3s811evb
  
/usr/bin/qemu-system-arm
  


  
  
  

  

  
hvm

  64
  /usr/bin/qemu-system-aarch64
  integratorcp
  nuri
  mps2-an511
  verdex
  ast2500-evb
  smdkc210
  collie
  imx25-pdk
  spitz
  realview-pbx-a9
  realview-eb
  versatilepb
  realview-pb-a8
  virt-2.9
  musicpal
  z2
  akita
  virt-2.7
  kzm
  virt-2.8
  realview-eb-mpcore
  sx1
  sx1-v1
  virt-2.6
  cubieboard
  highbank
  raspi2
  netduino2
  terrier
  n810
  

Bug#883614: [pkg-wpa-devel] Bug#883614: wpasupplicant fails to connect in v2.6

[Philip J Freeman]

hmm.. turns out, I can't repro anymore after installing new package..
perhaps just a local network issue?

Sorry for the cruft. :-/


On Tue, Dec 05, 2017 at 08:10:24PM +0100, Andrew Shadura wrote:
> Hi Philip,
> 
> From the logs you attached it appears that the connection attempt succeeded. 
> Could you please inspect the exact state wpa-supplicant and the interfaces 
> are left in at that point?
> 
> Thanks!
> -- 
> Cheers,
>   Andrew

-- 
⛵

Bug#883611: RFS: auter/0.11 (ITP: Bug#880600)

[Juhani Numminen]

Paolo Gigante kirjoitti 05.12.2017 klo 19:54:

Dear mentors,

...
Any assistance with sponsorship and packaging guidance would be greatly 
appreciated. In addition, we are very eager and willing to have any 
suggestions, requests and/or bugs raised against the auter github page.


Hi Paolo,

I cannot upload your package into Debian, but I suggest to look into at 
least these following items, which I think most potential mentors will 
be interested in. And, even after these, there will probably be yet more 
things to change, depending on the mentor.


* Why not Section: admin?

* The package should not be "native": please create a file in
debian/source/format with contents "3.0 (quilt)". More info at [1].

* Please fix the several lintian warnings (to see them all:
lintian -EviI --pedantic).

* When building the package I get:


dpkg-gencontrol: warning: Depends field of package auter: unknown substitution 
variable ${shlibs:Depends}


${shlibs:Depends} brings in dependencies on shared libraries. It should 
be removed since the binary package in question is "Architecture: all" 
i.e. architecture-independent.


* You could update to debhelper compat 10 as well.

[1] https://wiki.debian.org/DebianMentorsFaq

Regards,
Juhani