Bug#906380: libtool: FTBFS in buster/sid

[shirish शिरीष]

Dear Juhani Numminen,

Could you upload the built libtool binary somewhere so I could install
it and see if the issue goes away ?

Thank you.

I'll share my findings on the bug itself.

-- 
  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#907670: O: c-icap -- ICAP server implementation

[Mathieu Parent]

Package: wnpp
Severity: normal

I intend to orphan the c-icap package.

The package description is:
 C-ICAP is an implementation of an ICAP server. It can be used with
 HTTP proxies that support the ICAP protocol to implement content
 adaptation and filtering services.
 .
 Most of the commercial HTTP proxies must support the ICAP protocol.
 The open source Squid 3.x proxy server supports it.
 .
 This Package contains the core ICAP daemon

Package is in good shape. I will probably make some more upload before buster:
- move to salsa
- debian-policy and lintian stuff
- new upstream

New maintainer should take over c-icap-modules too.

Regards

Mathieu Parent

Bug#907669: O: c-icap-modules -- Antivirus Service for c-icap

[Mathieu Parent]

Package: wnpp
Severity: normal

I intend to orphan the c-icap-modules package.

The source package description would be:
 Those are various services for c-icap to do content filtering, url checking or
 virus scanning. They are distributed with c-icap and written by the same
 author.

Package is in good shape. I will probably make some more upload before buster: 
- move to salsa
- debian-policy and lintian stuff
- new upstream

New maintainer should take over c-icap too.

Regards

Mathieu Parent

Bug#887946: RM: gnome-hearts -- RoM; unmaintained, depends on unmaintained libgnome

[Bob Bib]

Hi,

Sorry for bumping an archived bug.

Just for history:
in Debian, the last version was 0.3 (dated 2008 upstream);
the last upstream version was 0.3.1 (2013).

Links (archived):
https://web.archive.org/web/20160308075926/http://www.jejik.com/gnome-hearts/
https://web.archive.org/web/20160305091341/http://www.jejik.com/gnome-hearts/download
http://www.gnome-hearts.org/ -> http://www.jejik.com/gnome-hearts/

--
Best wishes,
Bob

Bug#753464: firewalld: Upon startup, no rules are setup

[Michael Biebl]

On Wed, 02 Jul 2014 09:02:23 +0200 Vincent Bernat  wrote:
> Package: firewalld
> Version: 0.3.10-1
> Severity: important
> 
> Hi!
> 
> Upon startup, firewalld is running but nor rules are setup.
> 
> firewalld.service - firewalld - dynamic firewall daemon
>Loaded: loaded (/lib/systemd/system/firewalld.service; enabled)
>Active: active (running) since mer. 2014-07-02 08:50:42 CEST; 3min 15s ago
>  Main PID: 1049 (firewalld)
>CGroup: /system.slice/firewalld.service
>└─1049 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
> 
> juil. 02 08:50:42 zoro systemd[1]: Starting firewalld - dynamic firewall 
> daemon...
> juil. 02 08:50:42 zoro systemd[1]: Started firewalld - dynamic firewall 
> daemon.
> juil. 02 08:51:28 zoro firewalld[1049]: 2014-07-02 08:51:28 ERROR: 
> INVALID_ZONE
> 

Is this still reproducible?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#869585: (No Subject)

[Fjfj109]

I understand Debian Stable = frozen packages, but is this really not something 
that can just be fixed in stable? It's pretty severe.

Bug#873951: xpdf: new major upstream version 4.x

[Masanori Goto]

It sounds like the big question is whether we want to remove Motif
version or not.  If we want to continue to retain, we may want to have
both (e.g.) xpdf-motif and xpdf-qt (and default is xpdf-qt).

I personally think the only advantage of xpdf-motif (3.0.4) is speed -
because it has a small footprint to start the app. Other than that, is
there any other reason to keep having 3.0.4?

Bug#907493: ghostscript breaks cups autopkgtest: test times out

[Jonas Smedegaard]

Quoting Paul Gevers (2018-08-29 20:24:49)
> Control: tags -1 moreinfo
> 
> Hi,
> 
> On 29-08-18 20:20, Jonas Smedegaard wrote:
> > Thanks - that is indeed helpful, but provides only the _cups_ commands.
> > 
> > Inside those are some Ghostscript command (and some data) which I would 
> > need to check if/what fails with Ghostscript.
> 
> Both of them are "ELF 64-bit LSB shared object" so it would help if the
> cups maintainers could help here.

Do the freshly released experimental Ghostscript release help anything?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#747181: xpdf: too many warning messages

[Masanori Goto]

Hi,

Yes, xpdf shows many warnings, and adding "-q" command line option
should make xpdf silent. Could you try it out?  Thanks!

Bug#907667: lintian: should html escape output if --color=html is used

[James Cowgill]

Package: lintian
Version: 2.5.99
Severity: important
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
X-Debbugs-CC: debian-ad...@lists.debian.org

Hi,

Lintian does not html escape tag information when --color=html is used.
I noticed this after browsing a few packages in the NEW queue which have
broken stylesheets. Current examples:
https://ftp-master.debian.org/new/displaycal_3.6.1.0-1.html
https://ftp-master.debian.org/new/json-editor.js_0.7.28+ds-1.html

When generating those pages, dak passes --color=html to lintian and does
not escape the output (because that would escape the span tags). In this
case some privacy-breach-generic tags contained  $ lintian --color=html libjs-json-editor_0.7.28+ds-1_all.deb
> W: libjs-json-editor: privacy-breach-generic 
> usr/share/doc/libjs-json-editor/examples/wysiwyg.html [ href="//cdn.jsdelivr.net/sceditor/1.4.3/jquery.sceditor.default.min.css">] 
> (//cdn.jsdelivr.net/sceditor/1.4.3/jquery.sceditor.default.min.css)
> W: libjs-json-editor: privacy-breach-generic 
> usr/share/doc/libjs-json-editor/examples/wysiwyg.html [ href="//cdn.jsdelivr.net/sceditor/1.4.3/themes/default.min.css">] 
> (//cdn.jsdelivr.net/sceditor/1.4.3/themes/default.min.css)
> W: libjs-json-editor: privacy-breach-generic 
> usr/share/doc/libjs-json-editor/examples/wysiwyg.html 

Bug#907657: dicoweb does not work after django_1.10 patch (#868832)

[Michael Vlasenko]

Package: dicoweb
Version: 2.3-2
Tags: patch
Followup-For: Bug #907657

Dear Maintainer,

This should fix it.
Change line 20 in base.html to

  GNU Dico

Can you test this and see if it works?
Thanks.

My patch for solving this problem I send as an attachment.


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

Kernel: Linux 2.6.32-042stab129.1 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dicoweb depends on:
ii  libapache2-mod-passenger  5.0.30-1+b1
ii  libapache2-mod-wsgi   4.5.11-1
ii  python2.7.13-2
ii  python-dicoclient 2.3-2
ii  python-django 1:1.10.7-2+deb9u1
ii  python-memcache   1.57-2
ii  python-wit2.3-2

dicoweb recommends no packages.

dicoweb suggests no packages.

-- Configuration Files:
/etc/dicoweb/settings.py changed:
import os
SITE_ROOT = os.path.dirname(os.path.realpath(__file__))
BASE_DIR = SITE_ROOT
DEBUG = True
TEMPLATE_DEBUG = False
ALLOWED_HOSTS = [
'localhost',
'127.0.0.1',
'dict.bible.ru'
]
ADMINS = (
('Dico Admin', 'root@localhost'),
)
MANAGERS = ADMINS
SITE_ID = 1
USE_I18N = True
LOCALE_PATHS = (
os.path.join(SITE_ROOT, 'locale'),
)
TIME_ZONE = 'UTC'
LANGUAGE_CODE = 'en-us'
LANGUAGE_COOKIE_NAME = 'dicoweb_lang'
SESSION_COOKIE_NAME = 'dicoweb_sid'
SESSION_ENGINE = 'django.contrib.sessions.backends.file'
SESSION_EXPIRE_AT_BROWSER_CLOSE = True
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
'KEY_PREFIX': 'dicoweb',
},
}
MEDIA_ROOT = os.path.join(SITE_ROOT, 'static')
MEDIA_URL = '/static/'
SECRET_KEY = 'SET THIS TO A RANDOM STRING'
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
)
MIDDLEWARE_CLASSES = (
'django.middleware.cache.UpdateCacheMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.middleware.gzip.GZipMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
)
ROOT_URLCONF = 'dicoweb.urls'
WSGI_APPLICATION = 'dicoweb.wsgi.application'
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'APP_DIRS': True,
'DIRS': [
os.path.join(SITE_ROOT, 'templates'),
],
},
]
INSTALLED_APPS = (
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'dicoweb',
)
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse'
}
},
'handlers': {
'mail_admins': {
'level': 'ERROR',
'filters': ['require_debug_false'],
'class': 'django.utils.log.AdminEmailHandler'
}
},
'loggers': {
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
}
}
DICT_SERVERS = ('localhost',)
DICT_TIMEOUT = 10

/etc/dicoweb/templates/base.html changed:
{% load media %}
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml;>

{{ page.title|striptags }}GNU Dico Web










  

  GNU Dico
  


  {% block search %}{% endblock %}

  
  
{% block results %}{% endblock %}
  
http://www.gnu.org/software/dico/;>GNU Dico
Web interface. Copyright  2008-{% now "Y" %} GNU Dico Team.
  



/etc/dicoweb/templates/index.html changed:
{% extends 'base.html' %}
{% load i18n %}
{% load dictlookup %}
{% block search %}

  

  

  {% trans "Search term:" %}
  

{% trans "more options" %}
  

  
  
{% if selects.sv %}

  {% trans "DICT server:" %}
  

  {{ selects.sv.html|safe }}

  

{% endif %}

  {% trans "Database:" %}
  

  {{ selects.db.html|safe }}

  


  {% trans "Match strategy:" %}
  

  {{ selects.st.html|safe }}

  

  
  

  
  


  

  

  

{% endblock %}
{% block results %}
{% if result.error %}

  {{ result.msg }}

{% else %}
{% if result.definitions %}
  
{% if mtc.matches %}
{% trans "last match results" 
%}
{% 

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Phil]

Hi, I hope you're all doing well.

Shall we/I maybe reopen a new issue?

I'm still affected by this and I'd could use some advice how to debug
the issue a little bit better, especially since the kexec kernel
crashdumps appear not to be helpful. Can I maybe compile the module with
special debug flags and load it via. dkms or something?

I don't see any actual changes in [cdc_ncm.c][cdc_ncm], besides the one
change in `cdc_ncm_unbind`.

Also I'm confused why this is happening now again, I managed to do an
rsync upload with ~10GB over night back then - and my system didn't
crash - but right now even if I'm just trying to upload a picture to
twitter via. Firefox my laptop freezes.

[cdc_ncm]:
https://github.com/torvalds/linux/commits/master/drivers/net/usb/cdc_ncm.c

Bug#824649: ostree: document how to prepare and update a .deb-based system root

[Simon McVittie]

On Thu, 30 Aug 2018 at 23:09:10 +0200, Felix Krull wrote:
> Ok, I wrote up a guide on how to build and deploy a Debian-based ostree root
> with ostree-boot; I've attached the files for now. I can also add it to the 
> Git
> repository directly and make another merge request, if you prefer.

Thanks! I'm probably not going to be able to review this for a couple
of weeks, but I'll get to it when I can.

The ostree-boot package will need to go through the NEW queue, so don't
expect to see that particularly quickly.

smcv

Bug#907666: developers-reference: (partially) updating the German translations

[Tobias Frost]

Package: developers-reference-de
Severity: minor
Tags: patch

Translating some previously untranslated sentences and checking other
which were marked fuzzy. Note that this is not complete, poedit says
there are still 115 tasks open... (I will time permitting, work a bit on
them the next few days and update the MR accordingly.)

Please see the MR here: 
https://salsa.debian.org/debian/developers-reference/merge_requests/3

-- 
tobi

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

developers-reference-de depends on no packages.

Versions of packages developers-reference-de recommends:
pn  debian-policy  

Versions of packages developers-reference-de suggests:
pn  doc-base  

Bug#907665: developers-reference: Section 6.7.9 about dbg packages outdated

[Tobias Frost]

Source: developers-reference
Severity: normal
Tags: patch

As we now have Automatic Debug Symbol package, I think most of the
section could be deleted and replaced to the references on the Wiki.

The attached patch does that…

-- 
tobi

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 6f05ece..6a85f23 100644
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -1795,58 +1795,32 @@ it in its official location).
 
 
 Best practices for debug packages
+
 
-A debug package is a package with a name ending in -dbg, that contains
-additional information that gdb can use.  Since Debian 
binaries are stripped by
-default, debugging information, including function names and line numbers, is
-otherwise not available when running gdb on Debian 
binaries.  Debug packages
-allow users who need this additional debugging information to install it,
-without bloating a regular system with the information.
-
-
-It is up to a package's maintainer whether to create a debug package or not.
-Maintainers are encouraged to create debug packages for library packages, since
-this can aid in debugging many programs linked to a library.  In general, debug
-packages do not need to be added for all programs; doing so would bloat the
-archive.  But if a maintainer finds that users often need a debugging version
-of a program, it can be worthwhile to make a debug package for it.  Programs
-that are core infrastructure, such as Apache and the X server are also good
-candidates for debug packages.
-
-
-Some debug packages may contain an entire special debugging build of a library
-or other binary, but most of them can save space and build time by instead
-containing separated debugging symbols that gdb can find 
and load on the fly
-when debugging a program or library.  The convention in Debian is to keep these
-symbols in 
/usr/lib/debug/path, where
-path is the path to the executable or library.  For
-example, debugging symbols for /usr/bin/foo go in
-/usr/lib/debug/usr/bin/foo, and debugging symbols for
-/usr/lib/libfoo.so.1 go in
-/usr/lib/debug/usr/lib/libfoo.so.1.
-
-
-The debugging symbols can be extracted from an object file using 
-objcopy --only-keep-debug.  Then the object file can be 
stripped,
-and objcopy --add-gnu-debuglink used to specify the path
-to the debugging symbol file. 
- objcopy 1
- explains in detail how this works.
-
-
-The dh_strip command in debhelper supports creating debug
-packages, and can take care of using objcopy to separate
-out the debugging symbols for you.  If your package uses debhelper, all you
-need to do is call dh_strip --dbg-package=libfoo-dbg, and
-add an entry to debian/control for the debug package.
+A debug package is a package that contains additional information that
+gdb can use.  Since Debian binaries are stripped by
+default, debugging information, including function names and line
+numbers, is otherwise not available when running gdb
+on Debian binaries.  Debug packages allow users who need this additional
+debugging information to install it, without bloating a regular system
+with the information.
 
+
 
-Note that the debug package should depend on the package that it provides
-debugging symbols for, and this dependency should be versioned.  For example:
+Previously is was up to a package's maintainer whether to create a debug
+package or not. You can still find those manually generated debug
+packages, whose package names generally ended with -dbg.
+
+However, since end of 2015 manually generating dbg packages are
+depreciated and has been replaced largely by automatic debug symbol
+generation, which will generate packages with names ending with -dbgsym.
+
+If you want to migrate your legacy -dbg package, please read
+https://wiki.debian.org/AutomaticDebugPackages;> here ,
+if you want to use the dbgsym packages, you can find instructions
+https://wiki.debian.org/HowToGetABacktrace;> here .
+
 
-
-Depends: libfoo (= ${binary:Version})
-
 
 
 Best practices for meta-packages

Bug#907664: RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-1

[David Mohammed]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "budgie-desktop"

 * Package name: budgie-desktop
   Version : 10.4+git20180830.01.f2dbc215fdb-1
   Upstream Author : i...@solus-project.com
 * URL : https://github.com/budgie-desktop/budgie-desktop
 * License : LGPL-2.1/GPL2.0
   Section : x11

  It builds those binary packages:

 budgie-core - Core package for Budgie-Desktop
 budgie-core-dev - Development package for budgie-desktop
 budgie-desktop - Desktop package for budgie-desktop
 budgie-desktop-doc - documentation files for the budgie-desktop
 gir1.2-budgie-1.0 - GNOME introspection library for budgie-desktop
 libbudgie-plugin0 - Plugin library for budgie-desktop
 libbudgie-private0 - Budgie Private library for budgie-desktop
 libbudgietheme0 - Theme library for budgie-desktop
 libraven0  - Raven library for budgie-desktop

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

  https://mentors.debian.net/package/budgie-desktop


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.4+git20180830.01.f2dbc215fdb-1.dsc

Notes:
This upload to experimental has been requested to facilitate the
upcoming GNOME mutter 3.30
transition that is about to be undertaken (Serious: #907616)

Tested by pbuilder-dist on experimental; this has been tested on
Ubuntu 18.10 (cosmic) and is part of the daily ISO builds

check-all-the-things has been run on the source
lintian -i -I --pedantic run on the built changes files.

W: orig-tarball-missing-upstream-signature --> this is due to using
a git release tarball. A v10.5 signed tarball is expected soon by the
upstream project but date is yet to be set publically; I am using a
git release to
increase testing exposure in Ubuntu; since Debian is now about to
transition I'm more than happy for the Debian community to join the
testing effort.

May I request that this package be added to my debian maintainers list
of packages I'm allowed to look after (dak fossfree...@ubuntu.com) ? ;

timeliness of uploads is key especially as I am working with upstream
with development activities and the production of additional patches
as we
move towards budgie-desktop v10.5

  Changes since the last upload:

  * Release to experimental (Closes: #907616)
- base on ubuntu cosmic package; this includes a git release of
  budgie-desktop that will form the forthcoming v10.5 release.
  Includes additional patches to compile for mutter 3.30 plus
  current work-in-progress stability patches
  * Packaging Changes
- budgie-core.lintian-overrides - revise explanation of the lintian
  false positive results with the objdump test to confirm the observations
- bump control Standards-Version; no additional changes required
- libraven0.symbols add two additional symbols for git release


  Regards,
   David Mohammed

Bug#172892: best practices for CVS package handling

[Tobias Frost]

On Mon, 1 Jun 2015 15:59:30 +0900 Hideki Yamane 
wrote:
> control: tags -1 wontfix
> 
> Hi,
> 
>  Probably it was useful when reported in 2002, but we're in 2015 and
>  CVS was gone. so I'll tag wontfix for it.

Should we just close the bug?

Bug#907659: nageru: FTBFS against x264 0.155

[Steinar H. Gunderson]

On Thu, Aug 30, 2018 at 09:47:24PM +0200, Sebastian Ramacher wrote:
> nageru does not build against the current version of x264 available in
> experimental:

Hi,

Do you know if there's documentation anywhere about the new handling of
10-bit? And what #ifdef I should use to check whether x264_bit_depth is
available or not?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#906997: lua-sec: FTBFS with OpenSSL 1.1.1: test failure

[Daniel Kahn Gillmor]

On Thu 2018-08-30 15:38:50 -0400, Daniel Kahn Gillmor wrote:
> On Thu 2018-08-30 15:25:49 -0400, Daniel Kahn Gillmor wrote:
>> the NMU uses the attached patches, which i'll push to salsa as well
>> shortly.
>
> The changes are available on salsa at
> https://salsa.debian.org/lua-team/lua-sec/merge_requests/1.
>
> They also merge in upstream's git history, which should make it easier
> to cherry-pick from upstream in the future.

I've just updated debian/patches/0010-*.patch to cover the transition
from sha1 to sha256 as well.  I made that 0.6-4.2 and uploaded it as an
NMU.

the current version of that patch is attached below, and i've updated
the merge request on salsa.

Regards,

--dkg

From: Daniel Kahn Gillmor 
Date: Thu, 30 Aug 2018 14:53:01 -0400
Subject: use 2048-bit RSA keys and sha256 instead of 1024-bit RSA and sha1

According to Kurt Roeckx in https://bugs.debian.org/906997, the test
suite is failing when built against libssl 1.1.1 because we require at
least 2048-bit keys.

We also move from sha1 to sha256, as we're updating our cryptographic
primitives.
---
 samples/certs/clientA.bat  | 4 ++--
 samples/certs/clientA.cnf  | 4 ++--
 samples/certs/clientA.sh   | 4 ++--
 samples/certs/clientB.bat  | 4 ++--
 samples/certs/clientB.cnf  | 4 ++--
 samples/certs/clientB.sh   | 4 ++--
 samples/certs/rootA.bat| 4 ++--
 samples/certs/rootA.cnf| 4 ++--
 samples/certs/rootA.sh | 4 ++--
 samples/certs/rootB.bat| 4 ++--
 samples/certs/rootB.cnf| 4 ++--
 samples/certs/rootB.sh | 4 ++--
 samples/certs/serverA.bat  | 4 ++--
 samples/certs/serverA.cnf  | 4 ++--
 samples/certs/serverA.sh   | 4 ++--
 samples/certs/serverB.bat  | 4 ++--
 samples/certs/serverB.cnf  | 4 ++--
 samples/certs/serverB.sh   | 4 ++--
 samples/dhparam/params.sh  | 2 +-
 samples/dhparam/server.lua | 4 ++--
 20 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/samples/certs/clientA.bat b/samples/certs/clientA.bat
index 112cdef..f70a832 100644
--- a/samples/certs/clientA.bat
+++ b/samples/certs/clientA.bat
@@ -1,8 +1,8 @@
 rem #!/bin/sh
 
-openssl req -newkey rsa:1024 -sha1 -keyout clientAkey.pem -out clientAreq.pem -nodes -config ./clientA.cnf -days 365 -batch
+openssl req -newkey rsa:2048 -sha256 -keyout clientAkey.pem -out clientAreq.pem -nodes -config ./clientA.cnf -days 365 -batch
 
-openssl x509 -req -in clientAreq.pem -sha1 -extfile ./clientA.cnf -extensions usr_cert -CA rootA.pem -CAkey rootAkey.pem -CAcreateserial -out clientAcert.pem -days 365
+openssl x509 -req -in clientAreq.pem -sha256 -extfile ./clientA.cnf -extensions usr_cert -CA rootA.pem -CAkey rootAkey.pem -CAcreateserial -out clientAcert.pem -days 365
 
 copy clientAcert.pem + rootA.pem clientA.pem
 
diff --git a/samples/certs/clientA.cnf b/samples/certs/clientA.cnf
index f938d90..d88219c 100644
--- a/samples/certs/clientA.cnf
+++ b/samples/certs/clientA.cnf
@@ -67,7 +67,7 @@ cert_opt 	= ca_default		# Certificate field options
 
 default_days	= 365			# how long to certify for
 default_crl_days= 30			# how long before next CRL
-default_md	= sha1			# which md to use.
+default_md	= sha256			# which md to use.
 preserve	= no			# keep passed DN ordering
 
 # A few difference way of specifying how similar the request should look
@@ -98,7 +98,7 @@ emailAddress		= optional
 
 
 [ req ]
-default_bits		= 1024
+default_bits		= 2048
 default_keyfile 	= privkey.pem
 distinguished_name	= req_distinguished_name
 attributes		= req_attributes
diff --git a/samples/certs/clientA.sh b/samples/certs/clientA.sh
index 0350ede..118e186 100755
--- a/samples/certs/clientA.sh
+++ b/samples/certs/clientA.sh
@@ -1,9 +1,9 @@
 #!/bin/sh
 
-openssl req -newkey rsa:1024 -sha1 -keyout clientAkey.pem -out clientAreq.pem \
+openssl req -newkey rsa:2048 -sha256 -keyout clientAkey.pem -out clientAreq.pem \
   -nodes -config ./clientA.cnf -days 365 -batch
 
-openssl x509 -req -in clientAreq.pem -sha1 -extfile ./clientA.cnf \
+openssl x509 -req -in clientAreq.pem -sha256 -extfile ./clientA.cnf \
   -extensions usr_cert -CA rootA.pem -CAkey rootAkey.pem -CAcreateserial \
   -out clientAcert.pem -days 365
 
diff --git a/samples/certs/clientB.bat b/samples/certs/clientB.bat
index 9f341f6..ded7537 100644
--- a/samples/certs/clientB.bat
+++ b/samples/certs/clientB.bat
@@ -1,8 +1,8 @@
 rem #!/bin/sh
 
-openssl req -newkey rsa:1024 -sha1 -keyout clientBkey.pem -out clientBreq.pem -nodes -config ./clientB.cnf -days 365 -batch
+openssl req -newkey rsa:2048 -sha256 -keyout clientBkey.pem -out clientBreq.pem -nodes -config ./clientB.cnf -days 365 -batch
 
-openssl x509 -req -in clientBreq.pem -sha1 -extfile ./clientB.cnf -extensions usr_cert -CA rootB.pem -CAkey rootBkey.pem -CAcreateserial -out clientBcert.pem -days 365
+openssl x509 -req -in clientBreq.pem -sha256 -extfile ./clientB.cnf -extensions usr_cert -CA rootB.pem -CAkey rootBkey.pem -CAcreateserial -out clientBcert.pem -days 365
 
 copy clientBcert.pem + 

Bug#907518: New libssl1.1 1.1.1~~pre9-1 in unstable breaks connecting to some wifi networks

[Ian Maxon]

Similar story here. The update broke eduroam networks for me, but
downgrading to the testing package makes the issue disappear.
---
wpa_supplicant[11832]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wpa_supplicant[11832]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0
method 21 (TTLS) selected
wpa_supplicant[11832]: SSL: SSL3 alert: write (local SSL3 detected an
error):fatal:protocol version
wpa_supplicant[11832]: OpenSSL: openssl_handshake - SSL_connect
error:1425F18C:SSL routines:ssl_choose_client_version:version too low
wpa_supplicant[11832]: wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
---

Bug#907663: subdownloader depends on python-kaa-metadata

[Adrian Bunk]

Package: subdownloader
Version: 2.0.18-2.1
Severity: serious
Tags: fixed-upstream
Control: block -1 by 892751

subdownloader is the last reverse dependency of python-kaa-metadata
which has already been removed from testing.

Upstream version 2.0.19 supports pymediainfo as fallback.

Bug#907662: python-tvrage: useless after TVRage.com shut down?

[Adrian Bunk]

Package: python-tvrage
Version: 0.4.1-1
Severity: grave

http://www.tvrage.com/
TVRage.com website has shut down (2005-2015) 

Bug#824649: ostree: document how to prepare and update a .deb-based system root

[Felix Krull]

On Mon, 27 Aug 2018 at 21:39 Simon McVittie  wrote:

> The bug is tagged "help" because the maintainer does not know how to
> test this. If you can help to document how, please do, but the bug is not
> going to progress without someone's help.
>

Ok, I wrote up a guide on how to build and deploy a Debian-based ostree
root with ostree-boot; I've attached the files for now. I can also add it
to the Git repository directly and make another merge request, if you
prefer.

For reference: I've used this VM for testing:
https://app.vagrantup.com/bento/boxes/debian-9
But any other system should work so long as it satisfies the requirements
in the guide. The operative word being "should", of course...

I've also opened a merge request for the package changes to get
ostree-boot:  https://salsa.debian.org/debian/ostree/merge_requests/1

-Felix


ostree-2.conf
Description: Binary data


ostree-1.conf
Description: Binary data


ostree-boot-instructions
Description: Binary data

Bug#824650:

[Felix Krull]

I opened a merge request for this:
https://salsa.debian.org/debian/ostree/merge_requests/1

-Felix

Bug#907466: Package doesn't ship xml files anymore

[Dr. Tobias Quathamer]

Am 30.08.2018 um 22:43 schrieb Michael Biebl:
> Hi Tobias
> 
> On 8/30/18 22:35, Dr. Tobias Quathamer wrote:
>> thanks for your investigation. I've deprecated those XML files more than
>> two years ago and thought that this time might suffice to switch over to
>> the JSON files.
> 
> From past experience, unless you actively file bug reports, don't expect
> packages to migrate on their own.

Right. :-)

>> I would like to go through this list of packages and try to spot the
>> actual usage of the XML files. If there are only a few packages which
>> need to be fixed, it might still be doable before the freeze. From a
>> quick glance, there are a few false positives included. So maybe it's
>> not that bad after all.
> 
> Filing bug reports against affected packages and user-tagging them might
> be a good idea. This will help with tracking the progress of this
> transition.

Yes, that was my plan. That will take a few days, however, because I'd
like to quickly look into the sources of those packages and try to
determine if they actually rely on the XML files.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#907466: Package doesn't ship xml files anymore

[Michael Biebl]

On 8/30/18 22:35, Dr. Tobias Quathamer wrote:
> I would like to go through this list of packages and try to spot the
> actual usage of the XML files. If there are only a few packages which
> need to be fixed, it might still be doable before the freeze. From a
> quick glance, there are a few false positives included.

This is very well possible/likely, that this list contains false
positives. But I also might have missed affected packages.
My attempt to find affected packages was done knowing virtually nothing
about the iso-codes package.

I guess you have a better idea, how to find affected reverse dependencies.
Aside from trying codesearch.debian.net, checking for package
(build)-depending on iso-codes might also be an idea.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#907661: freecol: Does not start up with OpenJDK 10

[Johannes Kloos]

Package: freecol
Version: 0.11.6+dfsg2-1
Severity: important
Tags: patch

Dear Maintainer,

The freecol package tries to start up the JVM for freecol with the
JVM option -Xincgc. This option has been removed some time before
OpenJDK 10, causing startup to fail.

Removing the option makes the game start on my machine.

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

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

Versions of packages freecol depends on:
ii  default-jre [java8-runtime] 2:1.10-68
ii  java-wrappers   0.3
ii  libcommons-cli-java 1.4-1
ii  libcortado-java 0.6.0-4
ii  libmiglayout-java   5.1-1
ii  openjdk-10-jre [java8-runtime]  10.0.2+13-1

freecol recommends no packages.

freecol suggests no packages.

-- no debconf information

Bug#907660: fig2dev: CVE-2018-16140: buffer underwrite in get_line()

[Salvatore Bonaccorso]

Source: fig2dev
Version: 1:3.2.7a-2
Severity: important
Tags: patch security upstream
Forwarded: https://sourceforge.net/p/mcj/tickets/28/

Hi,

The following vulnerability was published for fig2dev.

CVE-2018-16140[0]:
| A buffer underwrite vulnerability in get_line() (read.c) in fig2dev
| 3.2.7a allows an attacker to write prior to the beginning of the buffer
| via a crafted .fig file.

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-2018-16140
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16140
[1] https://sourceforge.net/p/mcj/tickets/28/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#907466: Package doesn't ship xml files anymore

[Michael Biebl]

Hi Tobias

On 8/30/18 22:35, Dr. Tobias Quathamer wrote:
> thanks for your investigation. I've deprecated those XML files more than
> two years ago and thought that this time might suffice to switch over to
> the JSON files.

From past experience, unless you actively file bug reports, don't expect
packages to migrate on their own.

> I would like to go through this list of packages and try to spot the
> actual usage of the XML files. If there are only a few packages which
> need to be fixed, it might still be doable before the freeze. From a
> quick glance, there are a few false positives included. So maybe it's
> not that bad after all.

Filing bug reports against affected packages and user-tagging them might
be a good idea. This will help with tracking the progress of this
transition.

> If however most of the packages in your list have problems now, I'll
> re-add the XML files with the next upload of iso-codes. Maybe another
> try to remove them after the next Debian release ...

I fear unless you actively file bug reports against those packages, the
situation will not automatically be better in buster+1.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#907466: Package doesn't ship xml files anymore

[Dr. Tobias Quathamer]

Am 30.08.2018 um 14:47 schrieb Michael Biebl:
> On Wed, 29 Aug 2018 15:49:43 +0200 Michael Biebl  wrote:
> 
>> Possibly affected:
>> https://codesearch.debian.net/search?q=iso-codes.*xml
> 
> The list might be even longer:
> https://codesearch.debian.net/search?q=iso_.*%5C.xml
[...]>
> Given that, what do you think about rolling back the changes in
> iso-codes for now e.g. by re-adding the xml files to 4.0 or re-uploading
> 3.79?

Hi,

thanks for your investigation. I've deprecated those XML files more than
two years ago and thought that this time might suffice to switch over to
the JSON files.

Maybe this is not true, after all. :-(

I would like to go through this list of packages and try to spot the
actual usage of the XML files. If there are only a few packages which
need to be fixed, it might still be doable before the freeze. From a
quick glance, there are a few false positives included. So maybe it's
not that bad after all.

If however most of the packages in your list have problems now, I'll
re-add the XML files with the next upload of iso-codes. Maybe another
try to remove them after the next Debian release ...

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#887361: ccnet: Coordinated Packaging for ccnet and ccnet-server

[Nicholas D Steeves]

On Thu, Aug 30, 2018 at 04:16:14PM -0400, Nicholas D Steeves wrote:
> On Sat, Mar 17, 2018 at 06:13:03PM +0100, Georg Faerber wrote:
> > (Sorry for missing References and In-Reply-To.)
> > 
> > Hi all,
> > 
> > First of all: Thanks a lot for your work on seafile -- highly
> > appreciated!
> > 
> > Upstream responded in the linked issue of Alexandre Rossi:
> > 
> > "We're going to deprecate ccnet dependency in the upcoming 6.3 syncing
> > client. Ccnet is currently only used for syncing libraries created
> > before 3.0 servers. Because it uses TCP sockets to communicate with
> > seaf-daemon (the syncing daemon), it prevents users from running
> > multiple instances of syncing clients on Windows. So there would be no
> > ccnet in the client in the future. By the way, the drive client doesn't
> > rely on ccnet already."
> 
> v6.3.2-server has been tagged in the upstream repo.

P.S. my apologies, I failed to notice that seafile-client was still at
6.2.4 :-(  ( https://github.com/haiwen/seafile )

I guess we still need to wait...


signature.asc
Description: PGP signature

Bug#887361: ccnet: Coordinated Packaging for ccnet and ccnet-server

[Nicholas D Steeves]

Hello!

Licensing has been resolved:
https://github.com/haiwen/ccnet/issues/7
https://github.com/haiwen/seafile/issues/631
https://github.com/haiwen/seafile/issues/666

On Sat, Mar 17, 2018 at 06:13:03PM +0100, Georg Faerber wrote:
> (Sorry for missing References and In-Reply-To.)
> 
> Hi all,
> 
> First of all: Thanks a lot for your work on seafile -- highly
> appreciated!
> 
> Upstream responded in the linked issue of Alexandre Rossi:
> 
> "We're going to deprecate ccnet dependency in the upcoming 6.3 syncing
> client. Ccnet is currently only used for syncing libraries created
> before 3.0 servers. Because it uses TCP sockets to communicate with
> seaf-daemon (the syncing daemon), it prevents users from running
> multiple instances of syncing clients on Windows. So there would be no
> ccnet in the client in the future. By the way, the drive client doesn't
> rely on ccnet already."

v6.3.2-server has been tagged in the upstream repo.

> Therefore, once released, this
> 
> > The very best solution of course would be if the two repos were merged
> > again so that we can build ccnet and ccnet-server packages from the
> > same source.
> 
> seems possible then, doesn't it?

Given that Debian has never distributed a Seafile 3.0 server, why not
KISS, reduce the potentially greater attack surface, and just
--disable-ccnet?  If it has been officially depreciated upstream, then
upstream should provide the option to do so.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#897214: Fixed in 6.1.7-1

[Nicholas D Steeves]

On Mon, Apr 30, 2018 at 02:56:00PM +0200, Christoph Martin wrote:
> seafile-6.1.7-1 is still stuck in NEW queue.
> 
> Am 30.04.2018 um 10:24 schrieb Moritz Schlarb:
> > Control: fixed -1 seafile-cli/6.1.7-1
> > Control: tags -1 + fixed pending
> > 
> > This will be resolved as soon as src:seafile/6.1.7-1 finally migrates...
> > 

Given 6.1.8-1 is in buster, and there is additionally a bpo9 of this
version, I think this bug can be closed, no?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#905586: lxc: diff for NMU version 1:2.0.9-6.1

[Salvatore Bonaccorso]

Control: tags 905586 + pending


Dear maintainer,

I've prepared an NMU for lxc (versioned as 1:2.0.9-6.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer. Note that the two patches while adressing the
issue, still would allow test for existence of files, but this was
afaics not adressed explicitly.

Regards,
Salvatore
diff -Nru lxc-2.0.9/debian/changelog lxc-2.0.9/debian/changelog
--- lxc-2.0.9/debian/changelog	2018-01-27 15:44:36.0 +0100
+++ lxc-2.0.9/debian/changelog	2018-08-29 15:22:46.0 +0200
@@ -1,3 +1,11 @@
+lxc (1:2.0.9-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * utils: add LXC_PROC_PID_FD_LEN
+  * CVE 2018-6556: verify netns fd in lxc-user-nic (Closes: #905586)
+
+ -- Salvatore Bonaccorso   Wed, 29 Aug 2018 15:22:46 +0200
+
 lxc (1:2.0.9-6) unstable; urgency=medium
 
   * 0004-debian-Use-iproute2-instead-of-iproute.patch: fix creation of
diff -Nru lxc-2.0.9/debian/patches/0005-utils-add-LXC_PROC_PID_FD_LEN_stable-2.0.patch lxc-2.0.9/debian/patches/0005-utils-add-LXC_PROC_PID_FD_LEN_stable-2.0.patch
--- lxc-2.0.9/debian/patches/0005-utils-add-LXC_PROC_PID_FD_LEN_stable-2.0.patch	1970-01-01 01:00:00.0 +0100
+++ lxc-2.0.9/debian/patches/0005-utils-add-LXC_PROC_PID_FD_LEN_stable-2.0.patch	2018-08-29 15:22:46.0 +0200
@@ -0,0 +1,35 @@
+From f96f5f3c1341e73ee51c8b49bef4ba571c562d8c Mon Sep 17 00:00:00 2001
+From: Christian Brauner 
+Date: Fri, 4 May 2018 11:59:11 +0200
+Subject: [PATCH] utils: add LXC_PROC_PID_FD_LEN
+
+Signed-off-by: Christian Brauner 
+---
+ src/lxc/utils.h | 11 +++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/src/lxc/utils.h b/src/lxc/utils.h
+index a2bad89db..e4d8519db 100644
+--- a/src/lxc/utils.h
 b/src/lxc/utils.h
+@@ -99,6 +99,17 @@
+ #define LXC_NUMSTRLEN64 21
+ #define LXC_LINELEN 4096
+ #define LXC_IDMAPLEN 4096
++/* /proc/   =6
++ *+
++ *  =   LXC_NUMSTRLEN64
++ *+
++ * /fd/ =4
++ *+
++ *   =   LXC_NUMSTRLEN64
++ *+
++ * \0   =1
++ */
++#define LXC_PROC_PID_FD_LEN (6 + LXC_NUMSTRLEN64 + 4 + LXC_NUMSTRLEN64 + 1)
+ 
+ /* returns 1 on success, 0 if there were any failures */
+ extern int lxc_rmdir_onedev(char *path, const char *exclude);
+-- 
+2.17.1
+
diff -Nru lxc-2.0.9/debian/patches/0006-stable-2.0-lxc-user-nic-verify-file-descriptor.patch lxc-2.0.9/debian/patches/0006-stable-2.0-lxc-user-nic-verify-file-descriptor.patch
--- lxc-2.0.9/debian/patches/0006-stable-2.0-lxc-user-nic-verify-file-descriptor.patch	1970-01-01 01:00:00.0 +0100
+++ lxc-2.0.9/debian/patches/0006-stable-2.0-lxc-user-nic-verify-file-descriptor.patch	2018-08-29 15:22:46.0 +0200
@@ -0,0 +1,101 @@
+From d183654ec1a2cd1149bdb92601ccb7246bddb14e Mon Sep 17 00:00:00 2001
+From: Christian Brauner 
+Date: Wed, 25 Jul 2018 19:56:54 +0200
+Subject: [PATCH] CVE 2018-6556: verify netns fd in lxc-user-nic
+
+Signed-off-by: Christian Brauner 
+---
+ src/lxc/lxc_user_nic.c | 35 ---
+ src/lxc/utils.c| 12 
+ src/lxc/utils.h|  5 +
+ 3 files changed, 49 insertions(+), 3 deletions(-)
+
+--- a/src/lxc/lxc_user_nic.c
 b/src/lxc/lxc_user_nic.c
+@@ -1124,12 +1124,41 @@ int main(int argc, char *argv[])
+ 			exit(EXIT_FAILURE);
+ 		}
+ 	} else if (request == LXC_USERNIC_DELETE) {
+-		netns_fd = open(args.pid, O_RDONLY);
++		char opath[LXC_PROC_PID_FD_LEN];
++
++		/* Open the path with O_PATH which will not trigger an actual
++		 * open(). Don't report an errno to the caller to not leak
++		 * information whether the path exists or not.
++		 * When stracing setuid is stripped so this is not a concern
++		 * either.
++		 */
++		netns_fd = open(args.pid, O_PATH | O_CLOEXEC);
+ 		if (netns_fd < 0) {
+-			usernic_error("Could not open \"%s\": %s\n", args.pid,
+-  strerror(errno));
++			usernic_error("Failed to open \"%s\"\n", args.pid);
++			exit(EXIT_FAILURE);
++		}
++
++		if (!fhas_fs_type(netns_fd, NSFS_MAGIC)) {
++			usernic_error("Path \"%s\" does not refer to a network namespace path\n", args.pid);
++			close(netns_fd);
++			exit(EXIT_FAILURE);
++		}
++
++		ret = snprintf(opath, sizeof(opath), "/proc/self/fd/%d", netns_fd);
++		if (ret < 0 || (size_t)ret >= sizeof(opath)) {
++			close(netns_fd);
++			exit(EXIT_FAILURE);
++		}
++
++		/* Now get an fd that we can use in setns() calls. */
++		ret = open(opath, O_RDONLY | O_CLOEXEC);
++		if (ret < 0) {
++			usernic_error("Failed to open \"%s\": %s\n", args.pid, strerror(errno));
++			close(netns_fd);
+ 			exit(EXIT_FAILURE);
+ 		}
++		close(netns_fd);
++		netns_fd = ret;
+ 	}
+ 
+ 	if (!create_db_dir(LXC_USERNIC_DB)) {
+--- a/src/lxc/utils.c
 b/src/lxc/utils.c
+@@ -2377,6 +2377,18 @@ bool has_fs_type(const char *path, fs_ty
+ 	return has_type;
+ }
+ 
++bool fhas_fs_type(int fd, fs_type_magic magic_val)
++{
++	int ret;
++	struct statfs sb;
++
++	ret = fstatfs(fd, );
++	if (ret < 0)
++		

Bug#907659: nageru: FTBFS against x264 0.155

[Sebastian Ramacher]

Source: nageru
Version: 1.7.3-1
Severity: important
Tags: sid buster

nageru does not build against the current version of x264 available in
experimental:
| g++ -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -std=gnu++11 -fPIC -DQT_OPENGLEXTENSIONS_LIB 
-DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB 
-DQT_CORE_LIB -pthread -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGLExtensions 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/movit 
-I/usr/include/luajit-2.1 -I/usr/include/p11-kit-1 -I/usr/include/libusb-1.0 
-I/usr/include/eigen3 -pthread -DMOVIT_SHADER_DIR=\"/usr/share/movit\" 
-Idecklink/ -o x264_dynamic.o -c x264_dynamic.cpp
| x264_dynamic.cpp: In function 'X264Dynamic load_x264_for_bit_depth(unsigned 
int)':
| x264_dynamic.cpp:17:15: error: 'x264_bit_depth' was not declared in this scope
|   if (unsigned(x264_bit_depth) >= depth) {
|^~
| x264_dynamic.cpp:17:15: note: suggested alternative: 'x264_picture_t'
|   if (unsigned(x264_bit_depth) >= depth) {
|^~
|x264_picture_t
| make[1]: *** [Makefile:87: x264_dynamic.o] Error 1

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#906997: lua-sec: FTBFS with OpenSSL 1.1.1: test failure

[Daniel Kahn Gillmor]

On Thu 2018-08-30 15:25:49 -0400, Daniel Kahn Gillmor wrote:
> the NMU uses the attached patches, which i'll push to salsa as well
> shortly.

The changes are available on salsa at
https://salsa.debian.org/lua-team/lua-sec/merge_requests/1.

They also merge in upstream's git history, which should make it easier
to cherry-pick from upstream in the future.

Enrico, if you'd like, i can also provide patches to do other
modernization and minor cleanup of the package, i can convert the git
repo to DEP-14, and to potentially to merge upstream version 0.7.  let
me know if you want that.

  --dkg


signature.asc
Description: PGP signature

Bug#907658: ITP: Fork Awesome - fork of the iconic font Font Awesome

[Joseph Nuthalapati]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: wnpp
Severity: wishlist
Owner: Joseph Nuthalapati 


* Package name: fonts-fork-awesome
  Version : 1.1.0
* URL : https://github.com/ForkAwesome/Fork-Awesome
* License : Expat (MIT)
  Programming Lang: CSS
  Description : A fork of the iconic font and CSS toolkit (Font-Awesome 4.7)

Fork Awesome is a fork from the iconic font Font Awesome 4.7
which was the last free version of Font Awesome. The Debian
package fonts-font-awesome also points to Font Awesome 4.7. Font
Awesome 5 follows a freemium model.

Fork Awesome has been in parallel development since March 2018
and now includes several icons of free software projects.

- -- 
Regards,
Joseph Nuthalapati

-BEGIN PGP SIGNATURE-

iQIyBAEBCgAdFiEE4rQIdbX3Xc6j+BCYU5jwCi+kPDUFAluIR54ACgkQU5jwCi+k
PDUCkw/4u9OMwRLwQfROV7ITnEGhRmROsRkwLkFQddE3Bjo2aKhCwR7RD5o/UuO1
pLxJ8+q3fxDsHZCAhZo02FXYcmhtUiPH9v4qxScEfSFX++9iyEidY1Ulj/lejbp5
dUvcA4bsHLcKf8b0Sre9MJDZD6MDVnvWaYpi8qNzMIsemVfCJYlyI7fs10AYozKr
0dXxvTbYqzf3rbhVHgdlo6UAa6qDICjCMM6dYzNiWAOBth3bSVFSdMklFMlHsyMj
amruf1/ywEcYAbXjUR147f1FjV3B1qEBWgycjWsnYQUjrXkDO959uz4MAjo4799y
Be8Pmbr+Jg99tyB3HVA3Sy3NNWTQN+4hrlVLrIb2ykqFlG4yG+u8Wx/2RCgYz8HU
glnhV7PAMfmGlAeJPv4T448pcV43ZOtdDh9lAJeCGoJtx8gBYQ1opixAPyBrDarn
44GNCdKUlOlI91iDNayoisZWmdgt564NCltYVDWr90uHuMKcCEyCZrOCPjqSoKRR
EqEyXIZMgSTdOFmw6RunVyRZYdgCygGsG06nmVVrA3s+BjI6wn6unkorI/Mi5qZO
NjRmV2B6GmXaxm1qbR2Z+E9gHOl2/QSVVhiQMx+1k2YFLFenafvgHpnDmGXTQtik
Xrw5YDTy3IBU6jY8cvpQLNHcu4evdbwb4LHxGAC3TvU1SRipxw==
=wRas
-END PGP SIGNATURE-

Bug#906997: lua-sec: FTBFS with OpenSSL 1.1.1: test failure

[Daniel Kahn Gillmor]

On Sat 2018-08-25 20:10:36 +0200, Kurt Roeckx wrote:
> The problem is:
>> Generating a 1024 bit RSA private key
>
> Which then later results in:
>> lua: server.lua:19: error loading certificate (ee key too small)
>
> We've changed the default in Debian to require 2048 bit keys.

thanks for the pointer!

I've just uploaded an NMU for this, and i've taken the opportunity to to
a bit of simple packaging cleanup to reduce the number of pedantic
lintian warnings a bit at least, and to point to the latest upstream
repository as well.

the NMU uses the attached patches, which i'll push to salsa as well
shortly.

--dkg

From c442b9a28ba78241d4da5f051529e1d87141b00b Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Thu, 30 Aug 2018 14:46:25 -0400
Subject: [PATCH 1/7] point Vcs-* to salsa

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 4bc9c45..bffd2b1 100644
--- a/debian/control
+++ b/debian/control
@@ -10,8 +10,8 @@ Build-Depends: debhelper (>= 8.1.3),
openssl
 Standards-Version: 3.9.6
 Homepage: https://github.com/brunoos/luasec
-Vcs-Git: git://git.debian.org/git/pkg-lua/lua-sec.git
-Vcs-Browser: http://git.debian.org/?p=pkg-lua/lua-sec.git
+Vcs-Git: https://salsa.debian.org/lua-team/lua-sec.git
+Vcs-Browser: https://salsa.debian.org/lua-team/lua-sec
 
 Package: lua-sec
 Architecture: any
-- 
2.18.0

From 16d8759e90ac04afddd7dd5c7ee86fdb530cf0d1 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Thu, 30 Aug 2018 14:54:49 -0400
Subject: [PATCH 2/7] use 2048-bit keys in test suite (Closes: #906997)

---
 debian/patches/0010-use-2048-bit-keys.patch | 279 
 debian/patches/series   |   1 +
 2 files changed, 280 insertions(+)
 create mode 100644 debian/patches/0010-use-2048-bit-keys.patch

diff --git a/debian/patches/0010-use-2048-bit-keys.patch b/debian/patches/0010-use-2048-bit-keys.patch
new file mode 100644
index 000..7e99e7c
--- /dev/null
+++ b/debian/patches/0010-use-2048-bit-keys.patch
@@ -0,0 +1,279 @@
+From: Daniel Kahn Gillmor 
+Date: Thu, 30 Aug 2018 14:53:01 -0400
+Subject: use 2048-bit keys
+
+According to Kurt Roeckx in https://bugs.debian.org/906997, the test
+suite is failing when built against libssl 1.1.1 because we require at
+least 2048-bit keys.
+
+this should address that issue.
+---
+ samples/certs/clientA.bat  | 2 +-
+ samples/certs/clientA.cnf  | 2 +-
+ samples/certs/clientA.sh   | 2 +-
+ samples/certs/clientB.bat  | 2 +-
+ samples/certs/clientB.cnf  | 2 +-
+ samples/certs/clientB.sh   | 2 +-
+ samples/certs/rootA.bat| 2 +-
+ samples/certs/rootA.cnf| 2 +-
+ samples/certs/rootA.sh | 2 +-
+ samples/certs/rootB.bat| 2 +-
+ samples/certs/rootB.cnf| 2 +-
+ samples/certs/rootB.sh | 2 +-
+ samples/certs/serverA.bat  | 2 +-
+ samples/certs/serverA.cnf  | 2 +-
+ samples/certs/serverA.sh   | 2 +-
+ samples/certs/serverB.bat  | 2 +-
+ samples/certs/serverB.cnf  | 2 +-
+ samples/certs/serverB.sh   | 2 +-
+ samples/dhparam/params.sh  | 2 +-
+ samples/dhparam/server.lua | 4 ++--
+ 20 files changed, 21 insertions(+), 21 deletions(-)
+
+diff --git a/samples/certs/clientA.bat b/samples/certs/clientA.bat
+index 112cdef..ddde0e4 100644
+--- a/samples/certs/clientA.bat
 b/samples/certs/clientA.bat
+@@ -1,6 +1,6 @@
+ rem #!/bin/sh
+ 
+-openssl req -newkey rsa:1024 -sha1 -keyout clientAkey.pem -out clientAreq.pem -nodes -config ./clientA.cnf -days 365 -batch
++openssl req -newkey rsa:2048 -sha1 -keyout clientAkey.pem -out clientAreq.pem -nodes -config ./clientA.cnf -days 365 -batch
+ 
+ openssl x509 -req -in clientAreq.pem -sha1 -extfile ./clientA.cnf -extensions usr_cert -CA rootA.pem -CAkey rootAkey.pem -CAcreateserial -out clientAcert.pem -days 365
+ 
+diff --git a/samples/certs/clientA.cnf b/samples/certs/clientA.cnf
+index f938d90..3c6a6fe 100644
+--- a/samples/certs/clientA.cnf
 b/samples/certs/clientA.cnf
+@@ -98,7 +98,7 @@ emailAddress		= optional
+ 
+ 
+ [ req ]
+-default_bits		= 1024
++default_bits		= 2048
+ default_keyfile 	= privkey.pem
+ distinguished_name	= req_distinguished_name
+ attributes		= req_attributes
+diff --git a/samples/certs/clientA.sh b/samples/certs/clientA.sh
+index 0350ede..363230b 100755
+--- a/samples/certs/clientA.sh
 b/samples/certs/clientA.sh
+@@ -1,6 +1,6 @@
+ #!/bin/sh
+ 
+-openssl req -newkey rsa:1024 -sha1 -keyout clientAkey.pem -out clientAreq.pem \
++openssl req -newkey rsa:2048 -sha1 -keyout clientAkey.pem -out clientAreq.pem \
+   -nodes -config ./clientA.cnf -days 365 -batch
+ 
+ openssl x509 -req -in clientAreq.pem -sha1 -extfile ./clientA.cnf \
+diff --git a/samples/certs/clientB.bat b/samples/certs/clientB.bat
+index 9f341f6..1da9677 100644
+--- a/samples/certs/clientB.bat
 b/samples/certs/clientB.bat
+@@ -1,6 +1,6 @@
+ rem #!/bin/sh
+ 
+-openssl req -newkey rsa:1024 -sha1 -keyout clientBkey.pem 

Bug#907656: src:lua-sec: please package upstream version 0.7

[Daniel Kahn Gillmor]

Package: src:lua-sec
Severity: wishlist

on github, lua-sec has released version 0.7.  it would be good to put
that into debian.

thanks for maintaining lua in debian!

 --dkg

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

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

Bug#907655: xserver-xorg-video-mga: X don't start with the latest package version

[Davide Prina]

Package: xserver-xorg-video-mga
Version: 1:1.6.5-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

upgrading the system to the latest version don't let X to start: screen 
black with a cursor not blinking at the upper left corner. Ctrl-Alt-Fx 
don't works. Magic keys work.


Restarting the system in recovery mode and accessing as root I was able 
to install previous version of xserver-xorg-video-mga and server-xorg-core:


# dpkg -i xserver-xorg-video-mga_1%3a1.6.5-1_i386.deb xserver-xorg-
core_2%3a1.19.6-1_i386.deb

this fix the problem.

using the command
$ grep --binary-files=text wdm /var/log/syslog

in a successful start I see the following:

Aug 30 20:12:52 debian-eeepc wdm: X.Org X Server 1.19.6
Aug 30 20:12:52 debian-eeepc wdm: Release Date: 2017-12-20
Aug 30 20:12:53 debian-eeepc wdm: X Protocol Version 11, Revision 0
Aug 30 20:12:53 debian-eeepc wdm: Build Operating System: Linux 
4.9.0-5-amd64

i686 Debian
Aug 30 20:12:53 debian-eeepc wdm: Current Operating System: Linux 
debian-eeepc

4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18) i686
Aug 30 20:12:53 debian-eeepc wdm: Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-4.17.0-3-686-pae
root=UUID=0a5125b0-7623-41ad-9924-f86564311fe3 ro quiet
Aug 30 20:12:53 debian-eeepc wdm: Build Date: 26 January 2018  05:11:03PM
Aug 30 20:12:53 debian-eeepc wdm: xorg-server 2:1.19.6-1
(https://www.debian.org/support)
Aug 30 20:12:53 debian-eeepc wdm: Current version of pixman: 0.34.0
Aug 30 20:12:53 debian-eeepc wdm: #011Before reporting problems, check
http://wiki.x.org
Aug 30 20:12:53 debian-eeepc wdm: #011to make sure that you have the latest
version.
Aug 30 20:12:53 debian-eeepc wdm: Markers: (--) probed, (**) from config 
file,

(==) default setting,
Aug 30 20:12:53 debian-eeepc wdm: #011(++) from command line, (!!) 
notice, (II)

informational,
Aug 30 20:12:53 debian-eeepc wdm: #011(WW) warning, (EE) error, (NI) not
implemented, (??) unknown.
Aug 30 20:12:53 debian-eeepc wdm: (==) Log file: "/var/log/Xorg.0.log", 
Time:

Thu Aug 30 20:12:52 2018
Aug 30 20:12:53 debian-eeepc wdm: (==) Using system config directory
"/usr/share/X11/xorg.conf.d"
Aug 30 20:12:54 debian-eeepc wdm: (EE) fbdev: module ABI major version (24)
doesn't match the server's version (23)
Aug 30 20:12:54 debian-eeepc wdm: (EE) vesa: module ABI major version (24)
doesn't match the server's version (23)
Aug 30 20:12:54 debian-eeepc wdm: pci id for fd 14: 8086:8108, driver (null)
Aug 30 20:12:58 debian-eeepc wdm: EGL_MESA_drm_image required.
Aug 30 20:13:02 debian-eeepc wdm: Cannot open config file. Using builtin
defaults
Aug 30 20:16:55 debian-eeepc wdm[705]: geometry:
530x240+-2147483648+-2147483648

Note: the EE is because I have installed all 24 except mga and core

in an unsuccessful start I see the following:
Aug 30 18:41:52 debian-eeepc wdm: X.Org X Server 1.20.1
Aug 30 18:41:52 debian-eeepc wdm: X Protocol Version 11, Revision 0
Aug 30 18:41:52 debian-eeepc wdm: Build Operating System: Linux 
4.9.0-7-amd64

i686 Debian
Aug 30 18:41:52 debian-eeepc wdm: Current Operating System: Linux 
debian-eeepc

4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18) i686
Aug 30 18:41:52 debian-eeepc wdm: Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-4.17.0-3-686-pae
root=UUID=0a5125b0-7623-41ad-9924-f86564311fe3 ro quiet
Aug 30 18:41:52 debian-eeepc wdm: Build Date: 17 August 2018  08:05:00PM
Aug 30 18:41:52 debian-eeepc wdm: xorg-server 2:1.20.1-1
(https://www.debian.org/support)
Aug 30 18:41:52 debian-eeepc wdm: Current version of pixman: 0.34.0
Aug 30 18:41:52 debian-eeepc wdm: #011Before reporting problems, check
http://wiki.x.org
Aug 30 18:41:52 debian-eeepc wdm: #011to make sure that you have the latest
version.
Aug 30 18:41:52 debian-eeepc wdm: Markers: (--) probed, (**) from config 
file,

(==) default setting,
Aug 30 18:41:52 debian-eeepc wdm: #011(++) from command line, (!!) 
notice, (II)

informational,
Aug 30 18:41:52 debian-eeepc wdm: #011(WW) warning, (EE) error, (NI) not
implemented, (??) unknown.
Aug 30 18:41:52 debian-eeepc wdm: (==) Log file: "/var/log/Xorg.0.log", 
Time:

Thu Aug 30 18:41:52 2018
Aug 30 18:41:52 debian-eeepc wdm: (==) Using system config directory
"/usr/share/X11/xorg.conf.d"
Aug 30 18:41:52 debian-eeepc wdm: pci id for fd 14: 8086:8108, driver (null)
Aug 30 18:41:53 debian-eeepc wdm: (EE)
Aug 30 18:41:53 debian-eeepc wdm: (EE) Backtrace:
Aug 30 18:41:53 debian-eeepc wdm: server unexpectedly died
Aug 30 18:42:08 debian-eeepc wdm: Server for display :0 can't be started,
session disabled

Let me know if you need more info.

Ciao
Davide


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Dec  5  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Jan 18  2018 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation System 
Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108] (rev 

Bug#907654: Please package 2.7.x

[Thomas Goirand]

Package: python-dateutil
Severity: important

Hi Guido,

OpenStack vitrage needs >= 2.7.0. Can you please package it? Eventually, would
you accept an NMU?

Cheers,

Thomas Goirand (zigo)

Bug#907317: Forgot attachment?

[Chris Leick]

Hi Thomas,

sorry. Here the attachment.

Cheers,
Chris



Thomas Goirand:

Thanks, but it looks like you forgot the attachment.




de.po.gz
Description: application/gzip

Bug#907653: libapache2-mod-fcgid: autopkgtest regression: wget failed

[Paul Gevers]

Source: libapache2-mod-fcgid
Version: 1:2.3.9-3
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With the upload of 1:2.3.9-3 the autopkgtest of your package started to
fail in unstable and testing. I copied the output below.

Currently this regression is contributing to the delay of the migration
to testing [1]. Could you please investigate the situation and fix it?

It seems that you changed the code that now fails in your last upload. I
think (but haven't tested) that you should check if apache2 is running
and if so, restart it instead of start. If one has just installed
apache2, as our infrastructure is doing, apache2 is automatically started.

By the way, you should add the "isolation-container" restriction to your
test definition, see:
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libapache2-mod-fcgid

https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libapache2-mod-fcgid/905094/log.gz

autopkgtest [03:09:54]: test perl: [---
Module fcgid already enabled
AH00558: apache2: Could not reliably determine the server's fully
qualified domain name, using 192.168.122.3. Set the 'ServerName'
directive globally to suppress this message
httpd (pid 1771) already running
wget failed, output was:

autopkgtest [03:09:54]: test perl: ---]



signature.asc
Description: OpenPGP digital signature

Bug#890265: systemd: journalctl compiled without pattern matching support

[Simon McVittie]

On Tue, 05 Jun 2018 at 09:53:02 +0200, Tiziano Zito wrote:
> Installing pcre2 by default would maybe motivate the grep maintainers
> to migrate away from the deprecated libpcre3 and move to libpcre2-posix0
> instead...

Opening a bug on the grep package seems a more reliable way to
communicate with the grep maintainers than making changes to a different
package. I've opened  and
.

smcv

Bug#901461: Packaging mu for Debian

[Nick Morrott]

On 25 August 2018 at 07:44, Petter Reinholdtsen  wrote:
> [Nick Morrott]
>> This update tags the packages for non-free/{python,docs} - the
>> embedded pre-compiled Micropython firmware for the micro:bit doesn't
>> leave an alternative AFAICT at the moment).
>
> Is the Micropython implementation free software, and possible to build
> using free software?  Is it possible to place it into its own package
> and build the firmware in Debian?  Should it be split into a separate
> package to be shared between mu and uflash?

Discussion about the upstream MicroPython runtime is taking place at
https://github.com/ntoll/uflash/issues/54.

Upstream have confirmed that there are no non-free sources included in
the firmware, However, whether it is possible to build the firmware
locally with yotta without requiring an ARM mbed account *and* network
connection remains to be clarified.

The yotta build tool is not packaged in Debian.

>> The packaging would benefit from review and is currently without a
>> sponsor - I'll post an RFS to debian-python separately,
>
> Several lintian issues to address.  Are you looking into those?

Aside from ever-changing Standards versions, there are 2 non-overridden issues:

testsuite-autopkgtest-missing
debian-watch-does-not-check-gpg-signature

I am looking into addressing the first issue, as I add build testing using xvfb.

> Feel free to contact me on IRC if you want me to sponsor the package.

Thanks. I am also pinging #debian-python for suggestions - the outcome
of the MicroPython runtime build steps seems like it will dictate how
to binary packages are organised.

Bug#907652: grep: please use libpcre2 instead of pcre3

[Simon McVittie]

Package: grep
Version: 3.1-2
Severity: wishlist
Tags: upstream

grep currently uses libpcre.so.3 (pcre3) for its -P option. That library
is deprecated in favour of libpcre2-8.so.0 (and its 16-bit equivalent, but
I think the 8-bit flavour is the one you'd want); please consider switching
to that one.

Note that the API and ABI are not necessarily the same: pcre2 is a
separate parallel-installable library, like the difference between GTK+ 2
and GTK+ 3, or Qt 4 and Qt 5.

smcv

Bug#907267: openmpi: liggghts build on i386 times out

[Graham Inggs]

Latest build of liggghts on i386 against openmpi 3.1.2-1 timed out.
https://buildd.debian.org/status/fetch.php?pkg=liggghts=i386=3.7.0%2Brepack1-1.1=1535641058=0

Bug#907645: [Python-modules-team] Bug#907645: src:python-networkmanager: please package new version 2.1

[eamanu15]

Great!

El jue., 30 de ago. de 2018 a la(s) 13:21, W. Martin Borgert (
deba...@debian.org) escribió:

> Package: src:python-networkmanager
> Version: 2.0.1-4
> Severity: wishlist
>
> There is a new version that supports the Statistics interface,
> which I need.
>
> (I'm a DPMT member and would just upload the new version,
> and also apply the patch from #896281, if nobody objects.)
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team



-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#907651: grep: dlopens libpcre, but is directly linked to it anyway

[Simon McVittie]

Package: grep
Version: 3.1-2
Severity: normal

The version of grep in Debian carries a patch to dlopen libpcre.so.3.
However, it is also directly linked to libpcre.so.3 (objdump -Tx /bin/grep
shows "NEEDED libpcre.so.3"), and will not execute without it. This also
generates a hard dependency (in fact a Pre-Depends, because grep is
Essential: yes).

If the intention was to make grep -P opportunistically use libpcre.so.3
if present, but not use it if absent (like the way libopenal1 has a weak
dependency on libasound2, libpulse0 and libportaudio2), then it should
not be linked with -lpcre, only with -ldl. This will need some sort of
patch to its build system.

Alternatively, if grep -P is considered to be part of the Essential
functionality of grep, then the dlopen patch can be dropped and it can
just use libpcre like a normal library (the same as pcregrep).

Please choose one or the other: the current situation is the worst of
both worlds (you have the maintenance headache of the patch, but you
still have the dependency).

The changelog entry for 2.25-6 suggests that a weak dependency
is what was intended. If so, then it should be possible for the
upstream-test-suite-no-pcre3 autopkgtest to be reinstated and pass
without libpcre3 installed. It would probably be also good to have an
autopkgtest that runs "objdump -Tx /bin/grep | grep NEEDED" and
asserts that libpcre is not in the output.

smcv

Bug#891801: stretch-pu: package unbound/1.6.0-3+deb9u2

[Robert Edmonds]

Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2018-07-14 07:46, Salvatore Bonaccorso wrote:
> > Control: tags -1 - moreinfo
> > 
> > On Fri, Mar 02, 2018 at 05:49:52PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + moreinfo
> > > 
> > > On Wed, 2018-02-28 at 17:47 -0500, Robert Edmonds wrote:
> > > > I would like to fix a DNSSEC validation bug (CVE-2017-15105) in the
> > > > unbound package shipped in stretch. After discussion with the
> > > > security
> > > > team, this bug was deemed minor enough that the fix could be shipped
> > > > in
> > > > a point release:
> > > >
> > > > https://security-tracker.debian.org/tracker/CVE-2017-15105
> > > >
> > > 
> > > According to the above Security Tracker entry, this issue has not yet
> > > been fixed in unstable. Assuming that's correct, I'm afraid that's a
> > > blocker for looking at an update in stable.
> > 
> > This happened later on with the 1.7.1-1 upload.
> 
> Thanks, Salvatore. Robert, please feel free to upload.
> 
> Regards,
> 
> Adam

Uploaded. Thanks!

-- 
Robert Edmonds
edmo...@debian.org

Bug#907650: /usr/lib/libreoffice/program/libmergedlo.so: undefined symbol: _ZN8MsLangId13getScriptTypeEN4o3tl10strong_intIt15LanguageTypeTagEE"

[Davide Prina]

Package: libreoffice
Version: 1:6.1.1~rc1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

partially upgrade libreoffice or upgrade the libreoffice package without 
an upgrade of the whole system


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

# apt install libreoffice

   * What was the outcome of this action?

the error message in the subject

This bug has been archived has 864690, but this bug is present in 
testing if you upgrade libreoffice or part of it and not the whole system.


Upgrading only libreoffice or part of it you don't upgrade ure and 
uno-libs3, on your system, to the last version that solve the problem.


Please consider to upgrade the dependencies of all libreoffice packages 
to ure and uno-libs3 with the last version present in testing (6.1.1~rc1-1).


Ciao
Davide

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

Kernel: Linux 4.17.17-dp-20180823 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), 
LANGUAGE=it_IT.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:6.1.1~rc1-1
ii  libreoffice-base   1:6.1.1~rc1-1
ii  libreoffice-calc   1:6.1.1~rc1-1
ii  libreoffice-core   1:6.1.1~rc1-1
ii  libreoffice-draw   1:6.1.1~rc1-1
ii  libreoffice-impress1:6.1.1~rc1-1
ii  libreoffice-math   1:6.1.1~rc1-1
ii  libreoffice-report-builder-bin 1:6.1.1~rc1-1
ii  libreoffice-writer 1:6.1.1~rc1-1
ii  python3-uno1:6.1.1~rc1-1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-7
ii  fonts-liberation2   2.00.1-7
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-hinted   20171026-2
ii  fonts-noto-mono 20171026-2
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.1.1~rc1-1
ii  libreoffice-librelogo   1:6.1.1~rc1-1
ii  libreoffice-nlpsolver   0.9+LibO6.1.1~rc1-1
ii  libreoffice-ogltrans1:6.1.1~rc1-1
pn  libreoffice-report-builder  
ii  libreoffice-script-provider-bsh 1:6.1.1~rc1-1
ii  libreoffice-script-provider-js  1:6.1.1~rc1-1
ii  libreoffice-script-provider-python  1:6.1.1~rc1-1
ii  libreoffice-sdbc-postgresql 1:6.1.1~rc1-1
ii  libreoffice-wiki-publisher  1.2.0+LibO6.1.1~rc1-1

Versions of packages libreoffice suggests:
ii  cups-bsd2.2.8-5
ii  default-jre [java6-runtime] 2:1.10-68
ii  firefox-esr 52.9.0esr-1
ii  ghostscript 9.22~dfsg-2.1
ii  gnupg   2.2.9-1
pn  gpa 
ii  gstreamer1.0-libav 
1.15.0.1+git20180723+db823502-1

ii  gstreamer1.0-plugins-bad1.14.2-1
ii  gstreamer1.0-plugins-base   1.14.2-1
ii  gstreamer1.0-plugins-good   1.14.2-1
ii  gstreamer1.0-plugins-ugly   1.14.2-1
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hunspell-it [hunspell-dictionary]   1:6.1.0~rc2-2
pn  hyphen-hyphenation-patterns 
ii  imagemagick 8:6.9.10.8+dfsg-1
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.8+dfsg-1
ii  libgl1  1.1.0-1
ii  libreoffice-gnome   1:6.1.1~rc1-1
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
ii  libreoffice-officebean  1:6.1.1~rc1-1
pn  libsane1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
ii  mythes-en-us [mythes-thesaurus] 1:6.1.0~rc2-2
pn  openclipart2-libreoffice | openclipart-lib  
ii  openjdk-10-jre [java6-runtime]  10.0.2+13-1
ii  pstoedit3.73-1+b1
ii  thunderbird 1:52.9.1-1
ii  unixodbc2.3.6-0.1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.0-5
ii  fonts-opensymbol  2:102.10+LibO6.1.1~rc1-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-8
ii  libboost-locale1.62.0 1.62.0+dfsg-8
ii  libc6 2.27-5

Bug#907614: vmdb2: please provide documentation

[Lars Wirzenius]

On Thu, 2018-08-30 at 09:57 +0200, Johannes 'josch' Schauer wrote:
> Could you please provide documentation of vmdb2 in its binary package?

You're right that documentation is missing. I wrote up some:

http://code.liw.fi/vmdb2.html

This will eventaully be included in the package. Any feedback you may have
is welcome.




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

Bug#907647: ITP: svg-labels -- simple tool for generation of printable labels documents from SVG templates

[Miroslav Kravec]

I intend to package svg-labels on my own. Therefore, I've set the
owner to myself. After I'm done, I'll upload it to mentors, and submit
a RFS.

Bug#905431: Not quite sorted

[John Talbut]

I was getting LibreOffice printing graphics but not printing any text.
Having upgraded to 1:6.1.1~rc1-1 I can now print text, but the character
spacing is garbled for proportional fonts unless I set the output to pdf
(my printer is postscript so I don't know where the conversion takes place).

See attached screenshot for the postscript output.

Bug#907638: [Pkg-libvirt-maintainers] Bug#907638: Please upgrade to version 7.0

[Guido Günther]

Hi,
On Thu, Aug 30, 2018 at 03:39:49PM +0200, Laurent Bigonville wrote:
> Package: virt-viewer
> Version: 6.0-2
> Severity: important
> 
> Hi,
> 
> I'm planning to upload spice-gtk to version 0.35 in the following days
> and it seems that upstream has removed libspice-controller which is used
> by virt-viewer 6.0.

7.0 already requires 0.35 of libspice-gtk so I'd say you go first and
I'll then upload virt-viewer right away.
Cheers,
 -- Guido

> 
> It seems that you need to upgrade to 7.0 to make it work.
> 
> Could you have a look at this?
> 
> Kind regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
> 
> Versions of packages virt-viewer depends on:
> ii  libatk1.0-0 2.28.1-1
> ii  libc6   2.27-5
> ii  libcairo-gobject2   1.15.12-1
> ii  libcairo2   1.15.12-1
> ii  libgdk-pixbuf2.0-0  2.36.12-2
> ii  libglib2.0-02.56.1-2
> ii  libgovirt2  0.3.4-2
> ii  libgtk-3-0  3.22.30-2
> ii  libgtk-vnc-2.0-00.7.2-1
> ii  libgvnc-1.0-0   0.7.2-1
> ii  libpango-1.0-0  1.42.4-2
> ii  libpangocairo-1.0-0 1.42.4-2
> ii  librest-0.7-0   0.8.0-2
> ii  libsoup2.4-12.62.2-2
> ii  libspice-client-glib-2.0-8  0.34-1.1
> ii  libspice-client-gtk-3.0-5   0.34-1.1
> ii  libvirt-glib-1.0-0  1.0.0-1
> ii  libvirt04.6.0-2
> ii  libxml2 2.9.4+dfsg1-7+b1
> 
> virt-viewer recommends no packages.
> 
> Versions of packages virt-viewer suggests:
> ii  netcat-openbsd [netcat]  1.190-2
> ii  netcat-traditional [netcat]  1.10-41.1
> 
> -- no debconf information
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Bug#907649: clang-6.0: Erroneous loop optimisation with -O2, accessing to wrong std::vector element

[Juan Carlos Garcia Hernandez]

Package: clang-6.0
Version: 1:6.0.1-5
Severity: normal

Dear Maintainer,

When compiling with -O2 the code below, resulting loop is wrongly optimized 
leading
to plainly wrong results (not an approximation), it seems that elements in 
std::vector are not accessed in the right order.


#include 
#include 

class Foo {
private:
std::vector _a;
std::vector _d;

public:
Foo(const std::vector , const std::vector )
: _a(x.size()), _d(x.size()) {

for (unsigned int i = 0; i < x.size() - 1; i++) {
_a[i] = x[i + 1] - x[i];
_d[i] = (y[i + 1] - y[i]) / _a[i];
}
}

const std::vector () const noexcept { return _a; }
};

int main() {

// Read input file
std::vector x, y;
while (std::cin) {
double xi, yi;
if (std::cin >> xi >> yi) {
x.push_back(xi);
y.push_back(yi);
}
}

// Create Foo instance
Foo foo(x, y);

// Print computed data
for (auto a : foo.a()) std::cout << a << '\n';

return 0;
}


When executing the following commands (assuming that file bug.cpp contains code 
above)

$> clang++-6.0 -std=c++11 -O2 -o bug  bug.cpp
$> paste <(seq 1 5) <(seq 1 5) | ./bug

the expected result is:
1
1
1
1
0

But one gets:
1
2
2
0
0

Nevertheless, the expected result is obtained with -O1.

Best regards,

Juan


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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clang-6.0 depends on:
ii  binutils 2.31.1-4
ii  libc62.27-5
ii  libc6-dev2.27-5
ii  libclang-common-6.0-dev  1:6.0.1-5
ii  libclang1-6.01:6.0.1-5
ii  libgcc-8-dev 8.2.0-4
ii  libgcc1  1:8.2.0-4
ii  libjsoncpp1  1.7.4-3
ii  libllvm6.0   1:6.0.1-5
ii  libobjc-8-dev8.2.0-4
ii  libstdc++-8-dev  8.2.0-4
ii  libstdc++6   8.2.0-4

Versions of packages clang-6.0 recommends:
ii  libomp-dev6.0.1-1
ii  llvm-6.0-dev  1:6.0.1-5
ii  python2.7.15-3

Versions of packages clang-6.0 suggests:
pn  clang-6.0-doc  
pn  gnustep
pn  gnustep-devel  

-- no debconf information

Bug#907648: hexedit: autopkgtest doesn't work

[Jeremy Bicha]

Source: hexedit
Version: 1.4.2-2
Severity: important

Your new autopkgtest does not work:

https://ci.debian.net/packages/h/hexedit/testing/amd64/

Thanks,
Jeremy Bicha

Bug#902468: Info

[Martín Ferrari]

It took me a while to reproduce, as it seems to only happen with high
CPU contention. I will see if I can fix the bug, or disable it otherwise.

-- 
Martín Ferrari (Tincho)

Bug#907643: freerdp2-wayland: wlfreerdp mouse issue

[Mike Gabriel]

Control: tags -1 moreinfo

Hi,

On  Do 30 Aug 2018 18:09:39 CEST, Eduardo Barros wrote:


Package: freerdp2-wayland
Version: 2.0.0~git20180411.1.7a7b1802+dfsg1-2+b1
Severity: normal

Dear Maintainer,

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


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



I don't see any description of your observed issue. Please specify  
your mouse problems in detail. If not, this bug report will be closed.


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp1PswE7SEu0.pgp
Description: Digitale PGP-Signatur

Bug#885751: teg: Port to GooCanvas / GTK+ 3 / GSettings

[Markus Koschany]

Am 30.08.2018 um 01:53 schrieb Yavor Doganov:
> tags 885751 + patch
> thanks
> 
> Attached are patches that should fix this bug completely (removing all
> dependencies on old libraries that are scheduled for removal), plus
> the following issues of non-RC severity:

[...]

Yavor, thank you very much again for your work on porting games to newer
libraries. I will take a look at the patch tomorrow and if I don't find
anything serious, I'm going to upload it.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#907647: ITP: svg-labels -- simple tool for generation of printable labels documents from SVG templates

[Miroslav Kravec]

Package: wnpp
Severity: wishlist

* Package name: svg-labels
  Version : 0.3.0
  Upstream Author : Miroslav Kravec 
* URL : https://github.com/kravemir/svg-labels
* License : Apache-2.0
  Programming Lang: Java
  Description :  CLI tool for generation of printable labels documents

SVG labels is designed to be simply usable tool for generation of printable
documents with labels to print. Documents can be generated from SVG image,
or SVG template with instance(s) data.

Bug#907646: amd64-microcode: platform microcode: firmware: failed to load amd-ucode/microcode_amd_fam17h.bin (-2)

[Berni Elbourn]

Package: amd64-microcode
Version: 2.20160316.1~deb8u1
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?

I move this system to new hardware with Rixen7 2700X a few weeks ago. All is 
well and I have just noticed the log entry

[7.473799] platform microcode: firmware: failed to load 
amd-ucode/microcode_amd_fam17h.bin (-2)

Presumably there is no need for this firmware. Can the error be masked?

If it needed - can I help testing?


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


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

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

-- no debconf information

Bug#907642: Suggested solution

[Viktor VM Mihajlovski]

The attached patch would change s390 installation behavior to be in line
with other architectures w.r.t IP configuration.

As a side effect it would remove the requirement to build a
netcfg-static binary in d-i/netcfg.

-- 
Regards,
  Viktor Mihajlovski
diff --git a/build/pkg-lists/generic/s390.cfg b/build/pkg-lists/generic/s390.cfg
index 38caf90..9277834 100644
--- a/build/pkg-lists/generic/s390.cfg
+++ b/build/pkg-lists/generic/s390.cfg
@@ -1,6 +1,6 @@
 cdebconf-text-udeb
 
-netcfg-static
+netcfg
 nic-modules-${kernel:Version}
 s390-netdevice
 virtio-modules-${kernel:Version}
diff --git a/build/pkg-lists/generic/s390x.cfg b/build/pkg-lists/generic/s390x.cfg
index 38caf90..9277834 100644
--- a/build/pkg-lists/generic/s390x.cfg
+++ b/build/pkg-lists/generic/s390x.cfg
@@ -1,6 +1,6 @@
 cdebconf-text-udeb
 
-netcfg-static
+netcfg
 nic-modules-${kernel:Version}
 s390-netdevice
 virtio-modules-${kernel:Version}
diff --git a/build/pkg-lists/netboot/s390.cfg b/build/pkg-lists/netboot/s390.cfg
index 1aa1065..0fa732e 100644
--- a/build/pkg-lists/netboot/s390.cfg
+++ b/build/pkg-lists/netboot/s390.cfg
@@ -1,4 +1,4 @@
-netcfg-static
+netcfg
 nic-modules-${kernel:Version}
 s390-netdevice
 virtio-modules-${kernel:Version}
diff --git a/build/pkg-lists/netboot/s390x.cfg b/build/pkg-lists/netboot/s390x.cfg
index 1aa1065..0fa732e 100644
--- a/build/pkg-lists/netboot/s390x.cfg
+++ b/build/pkg-lists/netboot/s390x.cfg
@@ -1,4 +1,4 @@
-netcfg-static
+netcfg
 nic-modules-${kernel:Version}
 s390-netdevice
 virtio-modules-${kernel:Version}

Bug#907645: src:python-networkmanager: please package new version 2.1

[W. Martin Borgert]

Package: src:python-networkmanager
Version: 2.0.1-4
Severity: wishlist

There is a new version that supports the Statistics interface,
which I need.

(I'm a DPMT member and would just upload the new version,
and also apply the patch from #896281, if nobody objects.)

Bug#907644: libreoffice-calc: coloured text saved with Openoffice is displayed as black

[Francesco Potortì]

Package: libreoffice-calc
Version: 1:6.1.1~rc1-1
Severity: normal

Dear Maintainer,

the attached Calc file was created and saved with Windows Openoffice
4.1.3.  It displays normally when read under Linux with Gnumeric
1.12.41.

When read with Libreoffice, cells in C3:C30, whose text colour is Red4,
are displayed with black text, and cells in C31:C41, whose text colour
in #0084D1, are likewise displayed in black.

The correct text colour is reported when looking at the cell properties.


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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=C:en_GB:en:en_US:it:fr:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc3   2.9.9+repack1-1
ii  coinor-libcoinmp1v5  1.8.3-2
ii  coinor-libcoinutils3v5   2.10.14+repack1-1
ii  libatlas3-base [liblapack.so.3]  3.10.3-7+b1
ii  libblas3 [libblas.so.3]  3.8.0-1+b1
ii  libboost-filesystem1.62.01.62.0+dfsg-8
ii  libboost-iostreams1.62.0 1.62.0+dfsg-8
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-5
ii  libetonyek-0.1-1 0.1.8-1
ii  libgcc1  1:8.2.0-4
ii  libicu60 60.2-6
ii  liblapack3 [liblapack.so.3]  3.8.0-1+b1
ii  liblcms2-2   2.9-2
ii  libmwaw-0.3-30.3.14-1
ii  libodfgen-0.1-1  0.1.7-1
ii  liborcus-0.13-0  0.13.4-6
ii  libreoffice-base-core1:6.1.1~rc1-1
ii  libreoffice-core 1:6.1.1~rc1-1
ii  librevenge-0.0-0 0.0.4-6
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   8.2.0-4
ii  libwps-0.4-4 0.4.10-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  lp-solve 5.5.0.15-4+b1
ii  uno-libs36.1.1~rc1-1
ii  ure  6.1.1~rc1-1
ii  zlib1g   1:1.2.11.dfsg-1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.2.12-1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.0-5
ii  fonts-opensymbol  2:102.10+LibO6.1.1~rc1-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-8
ii  libboost-locale1.62.0 1.62.0+dfsg-8
ii  libc6 2.27-5
ii  libcairo2 1.15.12-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.8-5
ii  libcurl3-gnutls   7.61.0-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libdconf1 0.28.0-2
ii  libeot0   0.01-5
ii  libepoxy0 1.4.3-1
ii  libexpat1 2.2.6-1
ii  libexttextcat-2.0-0   3.4.5-1
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-4
ii  libglib2.0-0  2.56.1-2
ii  libgpgmepp6   1.11.1-1
ii  libgraphite2-31.3.11-2
ii  libharfbuzz-icu0  1.8.8-2
ii  libharfbuzz0b 1.8.8-2
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libhyphen02.8.8-5
ii  libice6   2:1.0.9-2
ii  libicu60  60.2-6
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-2
ii  libldap-2.4-2 2.4.46+dfsg-5
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-2
ii  libnspr4  2:4.19-3
ii  libnss3   2:3.38-1
ii  libnumbertext-1.0-0   1.0-2
ii  libodfgen-0.1-1   0.1.7-1
ii  liborcus-0.13-0   0.13.4-6
ii  libpng16-16   1.6.34-2
ii  libpoppler74  0.63.0-2
ii  librdf0   1.0.17-1.1
ii  libreoffice-common1:6.1.1~rc1-1
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.2-1+b3
ii  libstdc++68.2.0-4
ii  libx11-6  2:1.6.6-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxml2   2.9.4+dfsg1-7+b1
ii  libxmlsec11.2.26-3
ii  libxmlsec1-nss1.2.26-3
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.32-2
ii  uno-libs3 6.1.1~rc1-1
ii  ure   6.1.1~rc1-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.24+nmu5

-- no debconf 

Bug#907643: freerdp2-wayland: wlfreerdp mouse issue

[Eduardo Barros]

Package: freerdp2-wayland
Version: 2.0.0~git20180411.1.7a7b1802+dfsg1-2+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt:pt_BR:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freerdp2-wayland depends on:
ii  libc6 2.27-5
ii  libfreerdp-client2-2  2.0.0~git20180411.1.7a7b1802+dfsg1-2+b1
ii  libfreerdp2-2 2.0.0~git20180411.1.7a7b1802+dfsg1-2+b1
ii  libuwac0-02.0.0~git20180411.1.7a7b1802+dfsg1-2+b1
ii  libwinpr2-2   2.0.0~git20180411.1.7a7b1802+dfsg1-2+b1

freerdp2-wayland recommends no packages.

freerdp2-wayland suggests no packages.

-- no debconf information

Bug#776314: /var/log/faillog is never updated

[Avinash Sonawane]

Package: login
Version: 1:4.4-4.1
Followup-For: Bug #776314

Dear Maintainer,

I can reproduce this exact same issue on Debian Stretch.

> # grep -i faillog /etc/login.defs :
> FAILLOG_ENAByes

An interesting thing to note is that the comment just above these lines says
"Enable logging and display of /var/log/faillog login failure info. This option
conflicts with the pam_tally PAM module."

But, `grep pam_tally /etc/pam.d/login` yields nothing so I don't think
pam_tally is active and causing this issue.

This is something else.



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

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

Versions of packages login depends on:
ii  libaudit1   1:2.6.7-2
ii  libc6   2.24-11+deb9u3
ii  libpam-modules  1.1.8-3.6
ii  libpam-runtime  1.1.8-3.6
ii  libpam0g1.1.8-3.6

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#776314: /var/log/faillog is never updated

[Avinash Sonawane]

Package: login
Version: 1:4.4-4.1
Followup-For: Bug #776314

Dear Maintainer,

I can reproduce this exact same issue on Debian Stretch.

> # grep -i faillog /etc/login.defs :
> FAILLOG_ENAByes

An interesting thing to note is that the comment just above these lines says
"Enable logging and display of /var/log/faillog login failure info. This option
conflicts with the pam_tally PAM module."

But, `grep pam_tally /etc/pam.d/login` yields nothing so I don't think
pam_tally is active and causing this issue.

This is something else.



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

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

Versions of packages login depends on:
ii  libaudit1   1:2.6.7-2
ii  libc6   2.24-11+deb9u3
ii  libpam-modules  1.1.8-3.6
ii  libpam-runtime  1.1.8-3.6
ii  libpam0g1.1.8-3.6

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#907642: s390[x]: Installer forces static IP configuration

[Viktor VM Mihajlovski]

Package: debian-installer
Version: stable
Tags: d-i
User: debian-b...@lists.debian.org
Usertags: s390 s390x
X-Debbugs-CC: debian-s...@lists.debian.org

Installation on s390 or s390x always requires a static IP configuration.
This was a reasonable thing to do in the past, when only LPAR and z/VM
installations were common.
Installing in KVM however often requires the use of autoconfiguration
via DHCP which is not possible today.

-- 
Regards,
  Viktor Mihajlovski

Bug#907600: diffoscope: add option to ignore timestamp differences in containers

[Felipe Sateler]

On Thu, Aug 30, 2018, 12:31 Chris Lamb  wrote:

> Dear Felipe,
>
> > > Does the --exclude-directory-metadata option match your requirements?
> >
> > No, and according to the manpage it is intentional
>
> Whoops, apologies for the premature suggestion.


No worries, it was still useful :)


Indeed, it seems like I
> was confused in the past:
>
>   http://bugs.debian.org/893324
>
> … leading me to add that exact line:
>
>
> https://salsa.debian.org/reproducible-builds/diffoscope/commit/0da118a131f95811c158c5d47e4d620d01a233ea
>
> One option here would be to extend the --exclude-directory-metadata
> option to ignore metadata inside archive formats too rather than create
> a new, separate, option. Thoughts?
>

I would assume the current behavior is intentional, so it probably should
be an (optional) argument for this new behavior. But it would work for me.

Saludos

Bug#907600: diffoscope: add option to ignore timestamp differences in containers

[Chris Lamb]

Dear Felipe,

> > Does the --exclude-directory-metadata option match your requirements?
> 
> No, and according to the manpage it is intentional

Whoops, apologies for the premature suggestion. Indeed, it seems like I
was confused in the past:

  http://bugs.debian.org/893324

… leading me to add that exact line:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/0da118a131f95811c158c5d47e4d620d01a233ea

One option here would be to extend the --exclude-directory-metadata
option to ignore metadata inside archive formats too rather than create
a new, separate, option. Thoughts?


Regards,

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

Bug#907641: RFP: phosh -- Pure Wayland shell for mobile devices

[Guido Günther]

Package: wnpp
Severity: wishlist

* Package name: phosh
  Upstream Author : Guido Günther 
* URL : http://www.example.org/
* License : GPLv3
  Programming Lang: C
  Description : Pure Wayland shell for mobile devices

 Phosh is a simple shell for Wayland compositors speaking the layer-surface
 protocol. It currently supports
 .
 * a lockscreen
 * brightness control and nighlight
 * the gcr system-prompter interface
 * enough of org.gnome.Mutter.DisplayConfig to make gnome-settings-daemon happy
 * a homebutton that toggles a simple favorites menu
 * status icons for battary and wwan
 .
 If you're not working on a Wayland compositor then this package is likely not
 very useful for you.

Bug#907640: compiz: Migrating to compiz-reloaded?

[Samuel Thibault]

Package: compiz
Severity: important

Hello,

The launchpad upstream for compiz has switched to light maintenance mode
and will not make further development since Ubuntu has stopped using it.

How do people feel about switching to compiz-reloaded?

https://gitlab.com/compiz

Basically they restarted from the 0.8.8 version to avoid all recent
changes which have apparently introduced issues (see
http://compiz-debian.tuxfamily.org/ ). We can probably just take the
packaging from tuxfamily and work in hand with them to maintain it
officially in Debian.

Of course, since this is an older (but maintained) version, some
recent features are not there. Perhaps people can check, by installing
packages from tuxfamily, that everything they need is there?

Samuel

Bug#907389: ITP: pscircle -- visualizing Linux processes in a form of radial tree

[Mo Zhou]

control: retitle -1 RFP: pscircle -- visualizing Linux processes in a form of 
radial tree
control: owner -1 wnpp.debian.org

This software looks not quite mature at the time of ITP submission.

Bug#905913: sane-backends: Don't install into testing

[Yuri D'Elia]

Package: libsane
Version: 1.0.25-4.1
Followup-For: Bug #905913

The upload of 1.0.27-1~experimental6 makes libsane currently
uninstallable on sid.

-- System Information:
Debian Release: buster/sid
 APT prefers unstable
 APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 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 libsane depends on:
ii  acl2.2.52-3+b1
ii  adduser3.117
ii  libavahi-client3   0.7-4
ii  libavahi-common3   0.7-4
ii  libc6  2.27-5
ii  libgphoto2-6   2.5.19-1
ii  libgphoto2-port12  2.5.19-1
ii  libieee1284-3  0.2.11-13
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libsane-common 1.0.25-4.1
ii  libtiff5   4.0.9-6
ii  libusb-1.0-0   2:1.0.22-2
ii  udev   239-7

Versions of packages libsane recommends:
pn  libsane-extras  
pn  sane-utils  

Versions of packages libsane suggests:
pn  avahi-daemon  
pn  hplip 

Bug#906380: libtool: FTBFS in buster/sid

[shirish शिरीष]

at bottom :-

On 30/08/2018, Juhani Numminen  wrote:
> Control: tags -1 patch
>
> shirish शिरीष kirjoitti 30.08.2018 klo 07:51:> I,  and I guess others would
> welcome a test build if it helps to see
>> if the issue is resolved.  See how to apply patch [1] and see if you
>> can do the same thing -
>>
>> 1.
>> https://unix.stackexchange.com/questions/324680/how-to-apply-a-patch-in-a-debian-package
>>
>> Look forward to seeing a new deb package and trying it out to see if
>> it fixes the issue. Can't compile any packages due to the libtool
>> issues :(
>
> I applied the patch and the build is successful. The tests pass. You can
> find the commands I used in the end of this message.
>
> While I can already apply a patch in a Debian package, I appreciate you
> sharing the instructions :)
>
> Regards,
> Juhani
>
> --
> dget -x
> http://deb.debian.org/debian/pool/main/libt/libtool/libtool_2.4.6-2.1.dsc
> wget
> https://src.fedoraproject.org/rpms/libtool/raw/master/f/libtool-2.4.6-am-1.16-test.patch
> cd libtool-2.4.6
> quilt import ../libtool-2.4.6-am-1.16-test.patch
> dch
> dpkg-buildpackage -S -d -us -uc
> sudo cowbuilder --build ../libtool_2.4.6-2.1+local1.dsc
>

Wish I could help but cannot even install dget i.e. devscripts due to
the libtool and other bugs :(

$ sudo aptitude install devscripts -y
The following NEW packages will be installed:
  debhelper{a} devscripts dh-autoreconf{a} dh-strip-nondeterminism{a}
equivs{a} libltdl-dev{a} libtool{a}
  libyaml-libyaml-perl{a} lintian{a}
0 packages upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,115 kB/3,887 kB of archives. After unpacking 10.5 MB will be used.
Get: 1 http://cdn-fastly.deb.debian.org/debian buster/main amd64
devscripts amd64 2.18.3 [984 kB]
Get: 2 http://cdn-fastly.deb.debian.org/debian buster/main amd64
lintian all 2.5.98 [1,131 kB]
Fetched 2,115 kB in 24s (89.5 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of libltdl-dev (→ 2.4.6-2.1) 
 b1 - #905841 - libltdl-dev: dependency on specific automake version
   Merged with: 906394 906395 906423 906501 906507
grave bugs of libyaml-libyaml-perl (→ 0.72+repack-1) 
 b2 - #862373 - libyaml-libyaml-perl: Unconditionally instantiates
objects from yaml data
grave bugs of devscripts (→ 2.18.3) 
 b3 - #902409 - devscripts: CVE-2018-13043 - grep-excuses uses
YAML::Syck in a unsafe way
Summary:
 devscripts(1 bug), libltdl-dev(1 bug), libyaml-libyaml-perl(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] n
**
** Exiting with an error in order to stop the installation. **
**
E: Sub-process /usr/sbin/apt-listbugs apt returned an error code (10)
E: Failure running script /usr/sbin/apt-listbugs apt


$ apt-file list devscripts | grep dget
devscripts: /usr/bin/dget
devscripts: /usr/share/bash-completion/completions/dget
devscripts: /usr/share/man/de/man1/dget.1.gz
devscripts: /usr/share/man/fr/man1/dget.1.gz
devscripts: /usr/share/man/man1/dget.1.gz

Btw, thank you for sharing the updated instructions, have bookmarked it :)

-- 
  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#907496: libcurlpp0: Always fails with "No URL set!"

[Juhani Numminen]

Hi,

I'd like to report that I'm not seeing this error.

When I compile and run the program from Ted's mail, I just get some
HTML from example.org in stdout as expected.


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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcurlpp0 depends on:
ii  libc6   2.27-5
ii  libcurl47.61.0-1
ii  libgcc1 1:8.2.0-4
ii  libstdc++6  8.2.0-4

libcurlpp0 recommends no packages.

libcurlpp0 suggests no packages.

-- no debconf information

Bug#907639: ITP: golang-github-juju-clock -- Clock definition and a testing clock

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-juju-clock
  Version : 0.0~git20180808.bab88fc-1
  Upstream Author : Juju
* URL : https://github.com/juju/clock
* License : LGPL-3.0
  Programming Lang: Go
  Description : Clock definition and a testing clock.

 clock An interface definition for a fully defined clock.
 .
 An WallClock implementation of that interface using the time package.
 .
 A testing clock.

This is a new dependency for golang-github-juju-testing.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#907603: Update with upgrade path.

[Charlie Hagedorn]

Pulled from /var/log/apt/history.log, chasing down taskwarrior's
dependencies, as found by reportbug. Taskwarrior was functioning normally
for me through at least August 23. I believe that it failed following the
August 27 update.

I haven't changed anything in my taskwarrior configuration in many months
-- it was a real surprise to type 't sync' (aliased) this week and see it
fail.

Versions of packages taskwarrior depends on:

ii  libc62.27-5

ii  libgcc1  1:8.2.0-4

ii  libgnutls30  3.5.19-1

ii  libstdc++6   8.2.0-4

ii  libuuid1 2.32.1-0.1

August 17:
libgcc1:amd64 (1:8.1.0-12, 1:8.2.0-3)
libgcc1:i386 (1:8.1.0-12, 1:8.2.0-3)
libstdc++6:amd64 (8.1.0-12, 8.2.0-3)
libstdc++6:i386 (8.1.0-12, 8.2.0-3)
libuuid1:amd64 (2.32-0.1, 2.32-0.4)
libuuid1:i386 (2.32-0.1, 2.32-0.4)

August 21:
libgcc1:amd64 (1:8.2.0-3, 1:8.2.0-4)
libgcc1:i386 (1:8.2.0-3, 1:8.2.0-4)
libstdc++6:amd64 (8.2.0-3, 8.2.0-4)
libstdc++6:i386 (8.2.0-3, 8.2.0-4)
libuuid1:amd64 (2.32-0.4, 2.32.1-0.1)
libuuid1:i386 (2.32-0.4, 2.32.1-0.1)

August 27:
libc6-i386:amd64 (2.27-5, automatic)  <-- this is the only hit when
grepping 'libc6'

Bug#907608: libtirpc: CVE-2018-14622: Segmentation fault in makefd_xprt return value in svc_vc.c

[Salvatore Bonaccorso]

On Thu, Aug 30, 2018 at 03:35:54PM +0200, Salvatore Bonaccorso wrote:
> Note, there is potentially a CVE duplication here. CVE-2018-14622 and
> CVE-2015-9265 both refer to the same commit.

CVE-2015-9265 has been rejected in favour of CVE-2018-14622.

Regards,
Salvatore

Bug#907600: diffoscope: add option to ignore timestamp differences in containers

[Felipe Sateler]

Hi Chris,
On Thu, Aug 30, 2018 at 4:43 AM Chris Lamb  wrote:

> Dear Felipe,
>
> > diffoscope has been a very useful tool for me, in comparing dumps of
> > various sorts spit out by several systems. It would be great to have an
> > option to ignore timestamps
>
> Does the --exclude-directory-metadata option match your requirements?


No, and according to the manpage it is intentional:

> Metadata of archive members remain un-excluded.

I could get the results I want by unpacking the tarballs on two dirs and
then using this option, though, so thanks for suggesting it!

It would still be nice if diffoscope provided this option natively.

-- 

Saludos,
Felipe Sateler

Bug#907626: release.debian.org: Release status of non-Rust architectures?

[YunQiang Su]

Simon McVittie  于2018年8月30日周四 下午6:09写道：
>
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: libr...@packages.debian.org, ru...@packages.debian.org, 
> debian-m...@lists.debian.org
> Affects: src:librsvg
>
> The librsvg package in testing/unstable is currently lagging behind
> upstream by 1 year (2.40.x vs. 2.44.x) and I'm concerned that if there
> are security vulnerabilities in the lifetime of buster, we will not
> necessarily be able to fix them. Since 2.40.20, the 2.40.x branch is no
> longer supported by its upstream developer "except for emergencies".
>
> After 2.40.x, upstream started converting the internals of librsvg from
> C to Rust, for better memory-safety in the many interlocking parsers
> involved in interpreting SVGs. However, Debian still has release
> architectures that do not have cargo/dh-cargo/rustc (namely the 32-bit
> mips ports, mips and mipsel), so we cannot update to 2.42 or 2.44.
> Many of the ports architectures also don't have Rust available.
>
> Debian's default web browser, firefox-esr, also requires Rust and is
> also unbuildable on the 32-bit mips ports.
>

rust should work on 32bit mips. The only work is bootstrap.
I am working on it.

> What's the plan for non-Rust architectures? Are mips and mipsel intended
> to be supported for the lifetime of buster?
>
> Would it be acceptable to the release team to do architecture-specific
> removals of librsvg and its (many) reverse dependencies from testing on
> mips and mipsel?
>
> Another possible solution would be to upload a separate librsvg-2.40
> source package that only builds binaries for mips and mipsel (and any
> other non-Rust-capable ports that want it). However, the GNOME team
> do not have enough developer time or mips expertise to maintain such
> a package, it would become useless as soon as dependent packages start
> requiring features of newer librsvg versions, and it would have the same
> security, bug and upstream maintenance concerns as the current librsvg
> 2.40.x in unstable.
>
> I've been doing some triaging, and a lot of open librsvg bugs are present
> in unstable but fixed in experimental, so I'm keen to update to the new
> upstream release if we can. Lack of Rust on mips and mipsel is not the
> only blocker, but it is the main blocker. (We also have a FTBFS during
> "make check" on ppc64el, reported upstream, and endianness-related test
> failures on s390x, which will be selectively ignored in the next upload
> because the bug exhibited by those tests does not seem RC.)
>
> Thanks,
> smcv
>


-- 
YunQiang Su

Bug#906380: libtool: FTBFS in buster/sid

[Juhani Numminen]

Control: tags -1 patch

shirish शिरीष kirjoitti 30.08.2018 klo 07:51:> I,  and I guess others would 
welcome a test build if it helps to see
> if the issue is resolved.  See how to apply patch [1] and see if you
> can do the same thing -
> 
> 1. 
> https://unix.stackexchange.com/questions/324680/how-to-apply-a-patch-in-a-debian-package
> 
> Look forward to seeing a new deb package and trying it out to see if
> it fixes the issue. Can't compile any packages due to the libtool
> issues :(

I applied the patch and the build is successful. The tests pass. You can
find the commands I used in the end of this message.

While I can already apply a patch in a Debian package, I appreciate you
sharing the instructions :)

Regards,
Juhani

--
dget -x 
http://deb.debian.org/debian/pool/main/libt/libtool/libtool_2.4.6-2.1.dsc
wget 
https://src.fedoraproject.org/rpms/libtool/raw/master/f/libtool-2.4.6-am-1.16-test.patch
cd libtool-2.4.6
quilt import ../libtool-2.4.6-am-1.16-test.patch
dch
dpkg-buildpackage -S -d -us -uc
sudo cowbuilder --build ../libtool_2.4.6-2.1+local1.dsc

Bug#907049: [Pkg-openssl-devel] Bug#907049: openssl: Update to 1.1.1~~pre9-1 makes certain programs unusable

[Christian Neumann]

Hey,

for OpenVPN 2.3.4 on Jessie, the problem is solved for me by enforcing TLS 1.2 
with
tls-version-min 1.2
in the server config.

Best
Christian

Bug#907638: Please upgrade to version 7.0

[Laurent Bigonville]

Package: virt-viewer
Version: 6.0-2
Severity: important

Hi,

I'm planning to upload spice-gtk to version 0.35 in the following days
and it seems that upstream has removed libspice-controller which is used
by virt-viewer 6.0.

It seems that you need to upgrade to 7.0 to make it work.

Could you have a look at this?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages virt-viewer depends on:
ii  libatk1.0-0 2.28.1-1
ii  libc6   2.27-5
ii  libcairo-gobject2   1.15.12-1
ii  libcairo2   1.15.12-1
ii  libgdk-pixbuf2.0-0  2.36.12-2
ii  libglib2.0-02.56.1-2
ii  libgovirt2  0.3.4-2
ii  libgtk-3-0  3.22.30-2
ii  libgtk-vnc-2.0-00.7.2-1
ii  libgvnc-1.0-0   0.7.2-1
ii  libpango-1.0-0  1.42.4-2
ii  libpangocairo-1.0-0 1.42.4-2
ii  librest-0.7-0   0.8.0-2
ii  libsoup2.4-12.62.2-2
ii  libspice-client-glib-2.0-8  0.34-1.1
ii  libspice-client-gtk-3.0-5   0.34-1.1
ii  libvirt-glib-1.0-0  1.0.0-1
ii  libvirt04.6.0-2
ii  libxml2 2.9.4+dfsg1-7+b1

virt-viewer recommends no packages.

Versions of packages virt-viewer suggests:
ii  netcat-openbsd [netcat]  1.190-2
ii  netcat-traditional [netcat]  1.10-41.1

-- no debconf information

Bug#907608: libtirpc: CVE-2018-14622: Segmentation fault in makefd_xprt return value in svc_vc.c

[Salvatore Bonaccorso]

Note, there is potentially a CVE duplication here. CVE-2018-14622 and
CVE-2015-9265 both refer to the same commit.

Regards,
Salvatore

Bug#907637: bonding with virtio NICs does not work any more

[Robert Sander]

Package: src:linux
Version: 4.9.110-3+deb9u4
Severity: critical

Hi,

For network testing reasons I run several KVM VMs with up to now four virtio 
NICs,
where only one NIC is connected and the others are marked as "link_down" in the
KVM configuration.

In the guest the NICs are configured as bonding device with lacp. Up to 
linux-image-4.9.0-6-amd64
this worked without issues. Starting with linux-image-4.9.0-7-amd64 the kernel 
now reports
after booting:

Aug 27 12:01:39 test-gate-1 kernel: [   22.881163] bond0: link status up for 
interface ens18, enabling it in 0 ms
Aug 27 12:01:39 test-gate-1 kernel: [   22.882881] bond0: failed to get link 
speed/duplex for ens18
Aug 27 12:01:39 test-gate-1 kernel: [   22.985209] bond0: link status up for 
interface ens18, enabling it in 0 ms
Aug 27 12:01:39 test-gate-1 kernel: [   22.986998] bond0: failed to get link 
speed/duplex for ens18
Aug 27 12:01:39 test-gate-1 kernel: [   23.089250] bond0: link status up for 
interface ens18, enabling it in 0 ms
Aug 27 12:01:39 test-gate-1 kernel: [   23.091765] bond0: failed to get link 
speed/duplex for ens18
Aug 27 12:01:40 test-gate-1 kernel: [   23.193170] bond0: link status up for 
interface ens18, enabling it in 0 ms
Aug 27 12:01:40 test-gate-1 kernel: [   23.195772] bond0: failed to get link 
speed/duplex for ens18

ethtool also shows unknown speed and duplex for the virtio interfaces.

This seems to not have been an issue before linux-4.9.0-7.

Switching the virtual NICs from virtio to vmxnet3 solves the issue,
ethtool also reports speed and duplex mode.

I do not know if this is a KVM issue or a kernel issue, but as
the older kernel image works it looks more like a kernel issue to me.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: QEMU
product_name: Standard PC (i440FX + PIIX, 1996)
product_version: pc-i440fx-2.11
chassis_vendor: QEMU
chassis_version: pc-i440fx-2.11
bios_vendor: SeaBIOS
bios_version: rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] 
[8086:1237] (rev 02)
Subsystem: Red Hat, Inc Qemu virtual machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- 
BAR=0 offset= size=
Capabilities: [70] Vendor Specific Information: VirtIO: Notify
BAR=4 offset=3000 size=1000 multiplier=0004
Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg
BAR=4 offset=2000 size=1000
Capabilities: [50] Vendor Specific Information: VirtIO: ISR
BAR=4 offset=1000 size=1000
Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg
BAR=4 offset= size=1000
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:05.0 SCSI storage controller [0100]: Red Hat, Inc Virtio SCSI [1af4:1004]
Subsystem: Red Hat, Inc Virtio SCSI [1af4:0008]
Physical Slot: 5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
BAR=0 offset= size=
Capabilities: [70] Vendor Specific Information: VirtIO: Notify
BAR=4 offset=3000 size=1000 multiplier=0004
Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg
BAR=4 offset=2000 size=1000
Capabilities: [50] Vendor Specific Information: VirtIO: ISR
BAR=4 offset=1000 size=1000
Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg
BAR=4 offset= size=1000
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:08.0 Communication controller [0780]: Red Hat, Inc Virtio console [1af4:1003]
Subsystem: Red Hat, Inc Virtio console [1af4:0003]
Physical Slot: 8
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
BAR=0 offset= size=
Capabilities: [70] Vendor Specific Information: VirtIO: Notify
BAR=4 offset=3000 size=1000 multiplier=0004
Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg
BAR=4 offset=2000 size=1000
Capabilities: [50] Vendor Specific Information: VirtIO: ISR
BAR=4 offset=1000 size=1000
Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg
   

Bug#907636: opam: "opam init" calls gringo that requires 3GB of memory

[Samuel Hym]

Package: opam
Version: 2.0.0-1
Severity: normal

Dear Maintainer,

I ran "opam init" on my little machine that has only 2GB of RAM and
had to kill it after gringo had gobbled all the available memory.
I just tried on a bigger computer to see that it peaks at 3 or 4GB,
making it unusable on small machines.

I wondered why, and how to mitigate this: maybe gringo is not the best
default choice for the chain of dependencies (opam -> aspcud ->
gringo) in opam's case? Is it a bug in opam 2 (I had not noticed a
problem with the previous version), giving a terrible problem to solve
to aspcud?

Best regards,
Samuel

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

Kernel: Linux 4.17.0-3-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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages opam depends on:
ii  aspcud   1:1.9.4-1
ii  build-essential  12.5
ii  curl 7.61.0-1
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-5
ii  opam-docs2.0.0-1
ii  opam-installer   2.0.0-1
ii  packup   0.6-3
ii  unzip6.0-21
ii  wget 1.19.5-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages opam recommends:
ii  darcs  2.14.0-1
ii  git1:2.19.0~rc1-1
ii  m4 1.4.18-1
ii  mercurial  4.7-1
ii  ocaml  4.05.0-10+b1
ii  rsync  3.1.2-2.2

opam suggests no packages.

-- no debconf information

Bug#907635: add .apk as file extension for jar and jarsigner

[Hans-Christoph Steiner]

Package: bash-completion
Version: 1:2.8-1

Android APK files are officially defined as JAR files with JAR
signatures.  An APK _must_ have a JAR signature to be considered a valid
APK.  JAR signatures in Android land are known as "v1 signatures", there
is now v2 and v3 signatures which are still compatible with JAR, but not
verified or created by JAR tools.

I would really love to see `jarsigner` and `jar` do proper completion
for .apk files.

https://source.android.com/security/apksigning/#schemes

Google used to recommend jarsigner, but now has their own apksigner tool
 Microsoft still recommends jarsigner:

https://docs.microsoft.com/en-us/xamarin/android/deploy-test/signing/manually-signing-the-apk#Sign_the_APK_with_jarsigner

Bug#907633: ITP: pass-tomb -- lightweight directory-based password manager (tomb extension)

[David Kunz]

Package: wnpp

* Package name: pass-tomb
  Upstream Author : David Kunz 
* License : GPL-3+
  Description : lightweight directory-based password manager (tomb
extension)

  Stores, retrieves, generates, and synchronizes passwords securely
  using gpg and git.
  .
  This package provides an extension for the password store that
  allows to use a single tomb to keep the password tree encrypted
  when it is not used.


Greetings,
David

Bug#907466: Package doesn't ship xml files anymore

[Michael Biebl]

On Wed, 29 Aug 2018 15:49:43 +0200 Michael Biebl  wrote:

> Possibly affected:
> https://codesearch.debian.net/search?q=iso-codes.*xml

The list might be even longer:
https://codesearch.debian.net/search?q=iso_.*%5C.xml

apper
calibre
choose-mirror
cinnamon-control-center
django-countries
empathy
epiphany-browser
evolution
fcitx
fcitx-configtool
firefox
firefox-esr
gaupol
geary
gimagereader
gimp
gnome-desktop3
gnome-software
gnuradio
gspell
gst-plugins-base1.0
gtkpod
gtkspell3
gtranslator
hexchat
ibus
iso-codes
java-gnome
kaffeine
ldm
libgda5
libgweather
libisocodes
liblingua-translit-perl
lintian
localechooser
lxdm
mkvtoolnix
mozjs24
mozjs52
network-manager-applet
ocrfeeder
onboard
openjfx
oz
performous
plasma-desktop
pluma
python-apt
qtdeclarative-opensource-src
qtspell
quodlibet
ros-catkin
ruby-libxml
software-properties
sound-juicer
subtitleeditor
thunderbird
trilinos
workrave


Given that, what do you think about rolling back the changes in
iso-codes for now e.g. by re-adding the xml files to 4.0 or re-uploading
3.79?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#907171: prometheus FTBFS:

[Ian Campbell]

On Thu, 2018-08-30 at 13:23 +0100, Martín Ferrari wrote:

> > Unless the tests are run in their own network namespace (which provides
> > some guarantees over what else might be bound to a port, I can't seem
> > to find logs which would confirm or deny if a netns was in use here
> > though) probably the test needs to use a random port or otherwise be
> > tollerant of 9090 not being available. 

> Right, but this can't be done without root, and buildds do not give root.

I don't think that applies to the "needs to use a random port or otherwise be
tollerant of 9090 not being available" which was the main thrust of my comment.

> > Maybe there is (or should be) an autopkgtest flag to request a clean
> > netns be used?
> 
> This discussion is about a FTBFS bug, not about the CI system. ALso,
> that would not solve the issue, as it is autopkgtest installing (and
> therefore starting) prometheus.

So the issue is a parallel (but unrelated) autopkgtest run on the same
host interfering with builds which are happening at the same time? (I
had thought the autopkgtest was part of the build hence → FTBFS, seems
I was misunderstanding then, sorry for the noise on that front)

Ian.

Bug#903121: (no subject)

[Philipp Baumgart]

I did not encounter this bug or any other related problem on my system.


System type: Desktop PC
Gfx: Nvidia GTX 10170
CPU: AMD Ryzen 2700

Kernel: 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 GNU/Linux

Nvidia Driver: nvidia-graphics-drivers 390.77-1

Even the problem described in 
https://lists.debian.org/debian-user/2018/07/msg00059.html is solved.


Maybe its only Laptop related. The bug reporter should give an update if 
the issue still exists.

Bug#891087: beautifulsoup has been replaced by bs4

[Stefano Rivera]

Control: severity -1 serious

> This bug is for tracking the transition to bs4.

Time to raise this to RC, and let the testing autoremover do its job.

I think most of the packages that are still actively maintained have
been ported.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#907171: prometheus FTBFS:

[Martín Ferrari]

Ian,

On 30/08/18 09:51, Ian Campbell wrote:

> Does `nc -l -p 9090` repro the test failure perhaps?

yes, of course.

> Unless the tests are run in their own network namespace (which provides
> some guarantees over what else might be bound to a port, I can't seem
> to find logs which would confirm or deny if a netns was in use here
> though) probably the test needs to use a random port or otherwise be
> tollerant of 9090 not being available. 

Right, but this can't be done without root, and buildds do not give root.

> Maybe there is (or should be) an autopkgtest flag to request a clean
> netns be used?

This discussion is about a FTBFS bug, not about the CI system. ALso,
that would not solve the issue, as it is autopkgtest installing (and
therefore starting) prometheus.

-- 
Martín Ferrari (Tincho)

Bug#903541: nvidia-driver: Nvidia-driver 390-67 displays SDDM black screen

[Michael Haag]

This is an update to my previous response (copied below). I purged Kodi and 
pulseaudio, since it was after installing those items that my system went 
completely black screen.

Surprisingly, a reboot brought up a working SDDM login screen, but after 
logging in I'm presented with a black KDE desktop just as before. I can enter 
commands to reboot, so the desktop is active, but all I ever get upon logging 
in is a black screen.


On Wed, Aug 29, 2018, at 21:22, Michael Haag wrote:
> There's some really weird shit going on here.
> 
> I'm going to start from the beginning, as best as memory serves:
> 
> I had problems with surround sound on my HTPC, primarily due to the 
> limitations of S/PDIF. I decided to upgrade to a video card that 
> supported audio over HDMI. I wanted fanless, so my options were very 
> limited. I went with a NVidia GT730 card. This was several months ago.
> 
> As it turned out, Debian stable (Stretch) did not support this card. I 
> think it was both a kernel issue and an nvidia-driver issue. So I 
> upgraded to Debian testing (Buster).
> 
> Initially, I ran into an SDDM black screen problem, which I reported. I 
> was able to type in my password (don't ask why I even tried this) and my 
> KDE desktop would load normally. This is why I thought is was an SDDM 
> problem.
> 
> After some time, Debian testing updated the nvidia-driver, and lo and 
> behold, I got an SDDM login and a subsequent functioning KDE desktop 
> session, no problem. I was happy. I think the update nvidia-driver 
> version was 384.??, but I'm not sure.
> 
> All was good for awhile, but then another nvidia-driver upgrade created 
> the same problem as before. SDDM black screen, but I was still able to 
> login to a functioning KDE session.
> 
> Another nvidia-driver update (390.77) resulted in an SDDM black screen 
> but I was still able to login to a KDE session with a working desktop. 
> However, a subsequent update to KDE resulted in an SDDM black screen 
> that also resulted in a black screen KDE session. What I mean by that is 
> that SDDM allowed me to login, but KDE then also presented a black 
> screen. I could enter commands to reboot the system, so the KDE session 
> was active but there was no display.
> 
> My setup is this:
> 
> HTPC connected to a Marantz AV7005 receiver via HDMI. Marantz receiver 
> connected to a Samsung 4k TV via HDMI.
> 
> The Marantz receiver is limited to 1920x1080 video input. The nvidia-
> driver correctly detects this.
> 
> The first time I experienced this problem I applied a firmware update to 
> my Marantz receiver, but the problem persisted.
> 
> When I connect my HTPC directly to the TV there is no display problem at 
> all, but there is no way to get surround sound working that way (ARC is 
> non-functional and S/PDIF outputs digital stereo, not surround).
> 
> I suspected some type of resolution "handshaking" issue, so I searched 
> the Internet for tips on forcing resolution settings with NVidia 
> drivers. I came across instances where people were using xorg.conf to 
> override system defaults (as you suggested) so I created a file using 
> the NVidia utility and placed it in /etc/X11/.
> 
> To my surprise (according to Debian xorg.conf is deprecated) it worked. 
> Unfortunately, the fix was temporary. I successfully logged in via SDDM 
> and was presented with a functioning KDE desktop session several times. 
> I was very happy.
> 
> I subsequently installed Kodi and a few other applications that I use, 
> but discovered sound was no longer working. I checked all the multimedia 
> settings, pulse audio, Kodi audio settings, etc. etc. etc. and could 
> still not get sound working. It was working briefly, which is why I went 
> and installed Kodi in the first place.
> 
> During the process of trying to resolve the sound issues, I rebooted, 
> only to find I now have both a black SDDM screen AND a black KDE 
> session. I'm right back where I started, several days and multiple 
> installations (Kubuntu, Ubuntu, Stretch, Buster) later, including trying 
> out experimental nvidia-driver.
> 
> Fuck me. Shit works, and then it doesn't, for no apparent reason.
> 
> 
> On Wed, Aug 29, 2018, at 19:27, Vojtech Bocek wrote:
> > Yeah, xorg should be self-configuring now, but I think you can still use
> > xorg.conf file. Doing this should have the desired effect, I think, and
> > it's worth trying out (if it doesn't work, just remove xorg.conf):
> > 
> > cp -i /etc/nvidia/nvidia-drm-outputclass.conf /etc/X11/xorg.conf
> > 
> > On Sat, 25 Aug 2018 at 09:25, Michael Haag  wrote:
> > 
> > > Yes. I should have mentioned I was sending the bug report from another
> > > machine.
> > >
> > > Thanks for the response, but to my knowledge Xorg.conf has been
> > > deprecated. I know there is no such file on either of my PCs.
> > >
> > >
> > > On Fri, Aug 24, 2018, at 16:20, Vojtech Bocek wrote:
> > > > Hello,
> > > > I'm assuming the bug report in your message is from the PC where it is
> > 

Bug#907632: [ppc64-el] Breaks building aspectc++

[Reinhard Tartler]

Package: gcc-8
Version: 8.2.0-4
Affects: aspectc++
X-Debbugs-CC: debian-powe...@lists.debian.org

Relevant part from 
https://buildd.debian.org/status/fetch.php?pkg=aspectc%2B%2B=ppc64el=1%3A2.2%2Bgit20170823-8=1535500793=0

In file included from 
/build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/src/PrePrintVisitor.Icc:19:
In file included from 
/build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24:
In file included from 
/build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24:
In file included from 
/build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTree.h:26:
In file included from 
/build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Token.h:26:
In file included from 
/build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Location.h:25:
In file included from 
/build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Filename.h:26:
In file included from 
/build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Printable.h:25:
In file included from /usr/include/c++/8/iostream:39:
In file included from /usr/include/c++/8/ostream:38:
In file included from /usr/include/c++/8/ios:38:
In file included from /usr/include/c++/8/iosfwd:40:
In file included from /usr/include/c++/8/bits/postypes.h:40:
In file included from /usr/include/c++/8/cwchar:44:
In file included from /usr/include/wchar.h:30:
/usr/include/powerpc64le-linux-gnu/bits/floatn.h:72:52: error: unknown machine 
mode '__KC__'
typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__)));
   ^
/usr/include/powernpc64le-linux-gnu/bits/floatn.h:84:9: error: unknown type 
name '__ieee128'
typedef __float128 _Float128;
^
:431:20: note: expanded from here
#define __float128 __ieee128
   ^

If you look at 
https://buildd.debian.org/status/logs.php?pkg=aspectc%2B%2B=ppc64el,
you'll see that 1:2.2+git20170823-7 did build successfully. There are no 
relevant
upstream code changes, but it was built with gcc-7, which works fine. 
1:2.2+git20170823-8 uses gcc-8,
and that breaks.

Also it seems this bug seems to affect the architecture ppc64-el only.

Any ideas, hints and suggestions are much appreciated.

Best,
-rt

Bug#890024: npapi-vlc: upcoming Firefox ESR dropping support for NPAPI

[Reinhard Tartler]

I agree that it's time to have the package npapi-vlc removed from unstable.

Let's proceed with the RM bug.

Bug#860477: debian-handbook: revision of the references to "KDE"

[Raphael Hertzog]

Control: tag -1 + pending

On Mon, 17 Apr 2017, Luigi Toscano wrote:
> I attached a patch which uses the proper terminology.

Thanks for the patch. I merged it a while ago but for some reason the
salsa hook that should have notified did not do it.

https://salsa.debian.org/hertzog/debian-handbook/commit/6b26a0631e22fcebdd2fc5d894300aed0014b633

And my changes:
https://salsa.debian.org/hertzog/debian-handbook/commit/21ee298c7c80805aff5c13452e2908c78b667946

> There are really two patches because I'm not sure which is the branch
> still active. A quick look at the git history shows that jessie/master
> is still active, so please check the the jessie-master-... patch. The
> other one is still useful as reference when merging that branch into
> master.

I work on stretch/master only, jessie/master is just for translation
updates.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#712503: hmmmm

[Imran K]

root@nuc:/# ps aux | grep dhcpd | grep -v grep
root  3223  0.0  0.0  22764  9780 ?Ss   Aug29   0:01
/usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf eno1
root@nuc:/# lsof -i -nP | grep dhcpd
dhcpd  3223 root7u  IPv4 1903742  0t0  UDP *:67
dhcpd  3223 root   20u  IPv4 1903736  0t0  UDP *:21258
dhcpd  3223 root   21u  IPv6 1903737  0t0  UDP *:9127
root@nuc:/# cat /etc/default/isc-dhcp-server | grep = | grep -v pid
DHCPDv4_CONF=/etc/dhcp/dhcpd.conf
#DHCPDv6_CONF=/etc/dhcp/dhcpd6.conf
OPTIONS="-4"
INTERFACESv4="eno1"
#INTERFACESv6=""



FYI: /etc/dhcp/dhcpd.conf
+local-address 10.32.1.23;
goes 1/3 of the to workaround..