date:20190825

Bug#935682: RFP: minetest-mod-wielded-light -- Minetest module to add shining for wielded and dropped items

2019-08-25 Thread Phil Morrell

Package: wnpp
Severity: wishlist

* Package name: minetest-mod-wielded-light
  Version : 2019-01-10
  Upstream Author : bell07
* URL : https://github.com/minetest-mods/wielded_light
* License : GPL-3.0
  Programming Lang: lua
  Description : Minetest module to add shining for wielded and dropped
items

Wielding, dropping or throwing an item shines with light, though a little
dimmer than placing it.

Supports all shining items without any redefinition by re-using the node's
"light_source". Only works with air nodes in or around the item's position,
that means shining does not work on enclosed ladders, underwater or other
nearly empty or airlike nodes.

https://content.minetest.net/packages/bell07/wielded_light/

No dependencies and seems like the right way of implementing the feature
compared to: torches, walking_light, illumination, various specific item mods
etc.


signature.asc
Description: PGP signature

Bug#935684: diffoscope: squashfs-tools output change

2019-08-25 Thread GCS

Package: diffoscope
Version: 121
Severity: important
Tags: patch

Hi!

Recently squashfs-tools changed its output lines. This making
diffoscope self-test fail without real reason. Please apply the
attached patch to fix this and let squashfs-tools migrate to testing.

Thanks,
Laszlo/GCS
--- a/tests/data/squashfs_superblock_expected_diff	2019-08-20 13:13:37.199020598 +
+++ b/tests/data/squashfs_superblock_expected_diff	2019-08-20 13:31:12.385869167 +
@@ -1,13 +1,13 @@
 @@ -1,10 +1,10 @@
  Found a valid SQUASHFS 4:0 superblock
 -Creation or last append time Wed Jun 24 14:49:50 2015
--Filesystem size 0.55 Kbytes (0.00 Mbytes)
+-Filesystem size 561 bytes (0.55 Kbytes / 0.00 Mbytes)
 +Creation or last append time Wed Jun 24 14:50:09 2015
-+Filesystem size 0.70 Kbytes (0.00 Mbytes)
++Filesystem size 712 bytes (0.70 Kbytes / 0.00 Mbytes)
  Compression gzip
  Block size 131072
  Filesystem is exportable via NFS
  Inodes are compressed
  Data is compressed
+ Uids/Gids (Id table) are compressed
  Fragments are compressed
- Always-use-fragments option is not specified

Bug#935683: minetest-mod-torches: obsolete and unmaintained

2019-08-25 Thread Phil Morrell

Package: minetest-mod-torches
Severity: normal
Tags: upstream

The 3D torch mesh has been included since Minetest 0.4.16 and the wielded torch
feature is buggy. See wielded_light (RFP #935682) for a replacement.
--
Phil Morrell (emorrp1)



Versions of packages minetest-mod-torches depends on:
ii  minetest  5.0.1+repack-2~bpo10+1

minetest-mod-torches recommends no packages.

minetest-mod-torches suggests no packages.


signature.asc
Description: PGP signature

Bug#935688: RM: unittest-xml-reporting -- RoM; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertag: py2removal

Latest upstream code supports Python 3. There is a Python 3 request bug,
#737790, 5.5 years old.

Popcon is 34.

Reverse deps checked with dak rm -Rnb python-xmlrunner

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#935687: RM: python-txosc -- RoM; ancient; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertag: py2removal

There is no upstream development at https://bitbucket.org/arjan/txosc since 
2011.

Popcon is 6.

Reverse deps checked with dak rm -Rnb python-txosc

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#935686: RM: python-translitcodec -- RoM; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertag: py2removal

The current upstream code claims to support Python 3.

Popcon is 14.

Reverse deps checked with dak rm -Rnb python-translitcodec

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#935685: RM: python-opster -- RoM; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertag: py2removal

https://github.com/piranha/opster/ supports Python 3.

Popcon is 14.

Reverse deps checked with dak rm -Rnb python-opster

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#935689: RM: python-unipath -- RoM; ancient; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertag: py2removal

No upstream releases since 2008.

Popcon is 17.

Reverse deps checked with dak rm -Rnb python-unipath

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#935690: nm.debian.org: one-click-emeritus doesn't work for people who already have a dd_e/dd_r closed process

2019-08-25 Thread Mattia Rizzolo

Package: nm.debian.org
Severity: important

We now have a case of a person who wants to retire upon receiving a WAT
ping, but who already received and turned down a previos WAT ping.

This causes a 500 error trying to follow the tokenized url:

Internal Server Error: /process/emeritus

MultipleObjectsReturned at /process/emeritus
get() returned more than one Process -- it returned 2!

File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in 
inner
  42. response = get_response(request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_legacy_get_response
  249. response = self._get_response(request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  187. response = self.process_exception_by_middleware(e, 
request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  185. response = wrapped_callback(request, *callback_args, 
**callback_kwargs)
File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in view
  68. return self.dispatch(request, *args, **kwargs)
File "/srv/nm.debian.org/nm2/backend/mixins.py" in dispatch
  66. self.load_objects()
File "/srv/nm.debian.org/nm2/process/views.py" in load_objects
  753. const.STATUS_EMERITUS_DD, const.STATUS_REMOVED_DD))
File "/usr/lib/python3/dist-packages/django/db/models/manager.py" in 
manager_method
  85. return getattr(self.get_queryset(), name)(*args, 
**kwargs)
File "/usr/lib/python3/dist-packages/django/db/models/query.py" in get
  389. (self.model._meta.object_name, num)

Now, the issue is due to this query in process/views.py:

try:
self.process = pmodels.Process.objects.get(person=self.person, 
applying_for__in=(
const.STATUS_EMERITUS_DD, const.STATUS_REMOVED_DD))
except pmodels.Process.DoesNotExist:
self.process = None

I tried to change that to filter out closed processes, but now I
understand that's not correct: the presence of a closed process is
considered as a sign that the process has already been processed and
therefore the applicant can't retire that way anymore.

It's unclear to me how it should behave in this situation:
 * the presence of an open process for dd_e/dd_r definitely means the
   applicant should be able to follow the one-click-emeritus url
 * the presence of one closed process doesn't necassarily mean the
   person is "too late": the closed process might be from an old
   process that is already long over and doens't matter anymore
 * but how to distiguish the previous case from a current dd_r process
   that has already been approved (besides, approved but not closed
   processes are not filtered currently, they probably should) and so
   the applicant can't do anything anymore?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#935684: diffoscope: squashfs-tools output change

2019-08-25 Thread Mattia Rizzolo

On Sun, Aug 25, 2019 at 09:27:33AM +0200, László Böszörményi wrote:
> Recently squashfs-tools changed its output lines. This making
> diffoscope self-test fail without real reason. Please apply the
> attached patch to fix this and let squashfs-tools migrate to testing.

We can't apply that patch, because then the test would fail with an
older squashfs tools.

We usually use the program version or other indicators to decide if our
data is usable with the programs versions, but here I notice that the
change comes from an updated git tarball that doesn't seem to change the
porgram version.

How can we distinguish the previous squashfs-tools with the new one?

-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#933377: gdb: dynamically-linked programs segfault on launch

2019-08-25 Thread Vincent Duvert

After some more testing, it looks like the crash only occurs when Debian is 
running in a VirtualBox VM, whose host is itself running on an older Core 2 Duo 
processor.
I’m guessing this is more of a VirtualBox bug, which fails to properly emulate 
some CPU debug feature on older processors.

Bug#935691: O: viewvc -- web interface for CVS and/or Subversion repositories

2019-08-25 Thread Lev Lamberov

Package: wnpp
Severity: normal

I don't time and interest to work on the viewvc package, so I intend
to orphan it.  Upstream is somewhat active, there's even a new version.
Unfortunately, it is Python 2 only and it is still under transition to
Python 3.  It's userbase is somewhat small, not so many people use CVS
nowadays, and for Subversion there are other options.

The package description is:
 ViewVC is a browser (web) interface for CVS and Subversion version
 control repositories.  It generates templatized HTML to present
 navigable directory, revision, and change log listings.  It can display
 specific versions of files as well as diffs between those versions.
 .
 Basically, ViewVC provides the bulk of the report-like functionality you
 expect out of your version control tool, but much more prettily than the
 average textual command-line program output.
 .
 ViewVC can be used in two modes, both of which are supported by this
 package: (1) by running the simple stand-alone server
 "viewvc-standalone", with or without a GUI, and/or (2) by integrating
 ViewVC with any CGI-enabled HTTP server like Apache or nginx.
 .
 Three different binaries are provided: FastCGI, WSGI (for Apache mod_python),
 and plain CGI.

Bug#935691: (no subject)

2019-08-25 Thread Lev Lamberov

It's repository was migrated to Salsa.

Vcs-Browser: https://salsa.debian.org/debian/viewvc
Vcs-Git: https://salsa.debian.org/debian/viewvc.git

Cheers!
Lev

Bug#694077: Package review

2019-08-25 Thread Jérôme Lebleu

Le 24/08/2019 à 22:26, Lisandro Damián Nicanor Pérez Meyer a écrit :
> please release it (dch -r), push it and I'll upload.

It is now done and pushed, thanks in advance!

I tried again to build the package and didn't have any failure this
time. The one that didn't pass was at this line:


https://github.com/mcallegari/qlcplus/blob/QLC+_4.12.1/engine/test/mastertimer/mastertimer_test.cpp#L197

We will see if this test fails on the Debian build system too. In that
case, we will maybe have to add DEFINES+=SKIP_TEST as it is done when
travis is used:


https://github.com/mcallegari/qlcplus/blob/QLC%2B_4.12.1/engine/test/mastertimer/mastertimer.pro#L18

I should ask Massimo in that case since this variable name can be ambiguous.

Bug#935684: diffoscope: squashfs-tools output change

2019-08-25 Thread Chris Lamb

forwarded 935684 
https://salsa.debian.org/reproducible-builds/diffoscope/issues/62
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/diffoscope/issues/62


Regards,

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

Bug#935692: cpufreqd: FTBFS on ppc64el

2019-08-25 Thread Ivo De Decker

package: src:cpufreqd
version: 2.4.2-2.1
severity: serious
tags: ftbfs

Hi,

A binnmu of cpufreqd in unstable fails on ppc64el:

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

This might be related to changes in libcpupower in the latest linux upload.

Cheers,

Ivo

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

2019-08-25 Thread Otto Kekäläinen

Thanks Andreas for looking into this!

So far https://qa.debian.org/excuses.php?package=mariadb-10.3 hasn't
updated to show the state as fixed, but lets see.

Bug#935693: RM: ioprocess -- RoQA; orphaned; not needed; depends on Python 2

2019-08-25 Thread Andrey Rahmatullin

Package: ftp.debian.org
Severity: normal

Quoting its O bug #903567:

"The only purpose of packaging ioprocess was to provided it as a required
dependency for Vdsm packaging.  Since Vdsm packaging has been abandoned,
there is no sense to provide ioprocess in Debian any longer.  So I'm
orphaning the package and it can safely disappear."

Reverse deps checked with dak rm -Rn ioprocess

Bug#935694: RM: cpopen -- RoQA; orphaned; not needed; depends on Python 2

2019-08-25 Thread Andrey Rahmatullin

Package: ftp.debian.org
Severity: normal

Quoting its O bug #903572:

"The only purpose of packaging cpopen was to provided it as a required
dependency for Vdsm packaging.  Since Vdsm packaging has been abandoned,
there is no sense to provide cpopen in Debian any longer.  So I'm
orphaning the package and it can safely disappear."

There is one reverse dep, ioprocess, for which an RM bug was just filed too.

Reverse deps checked with dak rm -Rn ioprocess cpopen

Bug#931245: unblock: encoding-rs/0.8.15-2

2019-08-25 Thread Santiago Vila

Hi.

I'm still tracking FTBFS bugs in buster. Am I right to think that this
upload for stable (when accepted) will fix Bugs #931002 and #931003 in
rust-coresimd and rust-simd, making them buildable again?

(Those bugs have been closed automatically by FTPmaster, but the automatic
script does not know that the bugs still have to be fixed in buster).

Thanks.

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

2019-08-25 Thread Andreas Beckmann

On 25/08/2019 11.35, Otto Kekäläinen wrote:
> Thanks Andreas for looking into this!
> 
> So far https://qa.debian.org/excuses.php?package=mariadb-10.3 hasn't
> updated to show the state as fixed, but lets see.

It migrated to testing last night:

$ rmadison mariadb-10.3
mariadb-10.3 | 1:10.3.13-1   | unstable   | source
mariadb-10.3 | 1:10.3.15-1   | stable | source
mariadb-10.3 | 1:10.3.17-1   | testing| source
mariadb-10.3 | 1:10.3.17-1   | unstable   | source
mariadb-10.3 | 1:10.3.17-1   | unstable-debug | source

Andreas

Bug#935620: thrift: FTBFS on amd64

2019-08-25 Thread Ivo De Decker


Hi,

On 8/24/19 6:00 PM, László Böszörményi (GCS) wrote:

Control: tags -1 +confirmed

On Sat, Aug 24, 2019 at 4:06 PM Ivo De Decker  wrote:

A binnmu of thrift in unstable fails on amd64:

  Indeed and I've a fix for this. However I would like to add a Python
3 package and don't know if it's accepted automatically or have to go
through the NEW queue. That is, can I do a source only upload or do it
via experimental with a binary upload (otherwise it will not migrate
to testing due to not built on buildd). Please advise.


If you add a new binary package, your upload will go to the NEW queue 
(and will have to include binaries).


Cheers,

Ivo

Bug#935696: dbconfig-common

2019-08-25 Thread Miguel Figueiredo


package: dbconfig-common
version: 2.0.12
tags: l10n, patch

Updated Portuguese translation.
Feel free to use it.

--
Best regards / Melhores cumprimentos,

Miguel Figueiredo
# Portuguese translation for dbconfig-common
# Miguel Figueiredo , 2005-2019
#
msgid ""
msgstr ""
"Project-Id-Version: dbconfig-common 1.6\n"
"Report-Msgid-Bugs-To: dbconfig-com...@packages.debian.org\n"
"POT-Creation-Date: 2019-08-18 20:35+0200\n"
"PO-Revision-Date: 2019-08-21 22:26+0100\n"
"Last-Translator: Miguel Figueiredo \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:2001
msgid "Will this server be used to access remote databases?"
msgstr "Este servidor irÃ¡ ser utilizado para aceder a bases de dados remotas?"

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:2001
msgid ""
"For the database types that support it, dbconfig-common includes support for "
"configuring databases on remote systems. When installing a package's "
"database via dbconfig-common, the questions related to remote configuration "
"are asked with a priority such that they are skipped for most systems."
msgstr ""
"Para os tipos de bases de dados que o suportem, o dbconfig-common inclui "
"suporte para configurar bases de dados em sistemas remotos. Ao instalar a "
"base de dados de um pacote atravÃ©s do dbconfig-common, as questÃµes "
"relacionadas com a configuraÃ§Ã£o remota serÃ£o colocadas com uma prioridade "
"tal que serÃ£o ignoradas para a maioria dos sistemas."

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:2001
msgid ""
"If you select this option, the default behavior will be to prompt you with "
"questions related to remote database configuration when you install new "
"packages."
msgstr ""
"Se escolher esta opÃ§Ã£o, o comportamento predefinido serÃ¡ colocar-lhe "
"questÃµes relacionadas com a configuraÃ§Ã£o da base de dados remota quando "
"instalar novos pacotes."

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:2001
msgid "If you are unsure, you should not select this option."
msgstr "Se nÃ£o tiver a certeza, nÃ£o deve escolher esta opÃ§Ã£o."

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:3001
msgid "Remember database passwords permanently in debconf?"
msgstr "Lembrar as palavras-passe da base de dados permanentemente no debconf?"

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:3001
msgid ""
"When you configure, upgrade, or remove applications with dbconfig-common, "
"administrator-level database passwords are needed. By default, these "
"passwords are not stored, so you will be prompted for them each time."
msgstr ""
"Quando configurar, actualizar ou remover aplicaÃ§Ãµes com dbconfig-common, sÃ£o "
"necessÃ¡rias palavras-passe de administrador da base de dados. Por "
"predefiniÃ§Ã£o estas palavras-passe nÃ£o sÃ£o guardadas, por isso ser-lhe-Ã£o "
"perguntadas em cada vez."

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:3001
msgid ""
"Alternatively the passwords can be permanently remembered in the debconf "
"database (which is protected by Unix file permissions), though this is less "
"secure and thus not the default setting."
msgstr ""
"Em alternativa as palavras-passe pode ser permanentemente lembradas na base "
"de dados debconf (que Ã© protegida por permissÃµes de ficheiro Unix), apesar "
"de ser menos seguro e por isso nÃ£o Ã© a definiÃ§Ã£o predefinida."

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:3001
msgid ""
"If you would rather not be bothered for an administrative password every "
"time you upgrade a database application with dbconfig-common, you should "
"choose this option. Otherwise, you should refuse this option."
msgstr ""
"Se preferir nÃ£o ser incomodado com um pedido de palavra-passe administrativa "
"cada vez que actualizar a base de dados de uma aplicaÃ§Ã£o com o dbconfig-"
"common, deve escolher esta opÃ§Ã£o. Caso contrÃ¡rio, deve recusar esta opÃ§Ã£o."

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:4001
msgid "Configure database for ${pkg} with dbconfig-common?"
msgstr "Configurar a base de dados para ${pkg} com dbconfig-common?"

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:4001
msgid ""
"The ${pkg} package must have a database installed and configured before it "
"can be used. This can be optionally handled with dbconfig-common."
msgstr ""
"O pacote ${pkg} tem de ter uma base de dados instalada e configurada antes "
"de poder ser utilizado. Opcionalmente pode ser lidado com dbconfig-common."

#. Type: boolean
#. Description
#: ../dbconfig-common.templates:4001
msgid ""
"If you are an advanced database administrator and know that you want to "
"perform this configuration manually, or if your database has already been "
"installed and configured, you should refuse this option. Details on what "
"needs t

Bug#935697: xtrlock: FTBFS when binNMUed

2019-08-25 Thread Ivo De Decker

package: src:xtrlock
version: 2.10
severity: serious
tags: ftbfs

Hi,

A binnmu of xtrlock in unstable fails on i386:

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

It seems the version check doesn't work with binNMUs.

Cheers,

Ivo

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

2019-08-25 Thread Francesco Poli

Hello everyone,
I am sorry to ask, but... I cannot understand what's the status of
[this bug report].

[this bug report]: 

A serious bug for libc6-dev without any apparent activity since last
March?
Sure there must have been some hidden progress that I cannot see.


I probably do not fully understand the issue: there seems to be a
transition going on, from some deprecated crypt() implementation to
libxcrypt. And this transition requires some small changes (basically
different #include and #define directives) in C code using crypt(),
if this code has to be recompiled on buster or later.
But these different requirements are not yet documented in the
appropriate [man page].

[man page]: 

Is this a decent summary of the situation?

If this is the case, should this bug report be reassigned to package
manpages-dev and fixed there?


Please clarify, thanks for your time and patience!   :-)

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


pgpp85RySLBpr.pgp
Description: PGP signature

Bug#934928: win32-loader FTBFS on stable - any idea ?

2019-08-25 Thread Simon McVittie

On Sat, 24 Aug 2019 at 18:49:20 +0200, Didier 'OdyX' Raboud wrote:
> The difference I finally found was that the buildds use LANG=C.UTF-8 and 
> LC_ALL=C.UTF-8 whereas mine was not enforcing these (and so I was building 
> with LC_ALL=POSIX).

This was a change in sbuild 0.78.0, so in practice a difference between
buildds hosted on <= stretch (which used LC_ALL=POSIX) and buildds hosted
on >= buster (which use LC_ALL=C.UTF-8).

Forcing the POSIX (or equivalently C) locale effectively means you are
reverting a small part of the behaviour of newer sbuild, to be more like
the old sbuild where the win32-loader currently in buster was built,
so it seems a good minimal change to address this.

> +# A non-UTF-8 locale is needed for the NSIS build to convert some language 
> strings
> +LC_ALL := POSIX
> +export LC_ALL

This is the first time I've encountered a package where changing the locale
to C.UTF-8 *causes* FTBFS - normally the failure mode is that unit tests
assume a UTF-8 (or at least legacy 8-bit) locale, and fail in LC_ALL=POSIX
(or equivalently LC_ALL=C).

It would be interesting to know whether the Farsi locale *works* in the
resulting build; but if it doesn't, then that probably isn't a regression,
because version 0.9.4 in buster would probably be broken in the same way.

smcv

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

2019-08-25 Thread Otto Kekäläinen

Ack.

I didn't get the maintainer email though, nor is it visible at
https://tracker.debian.org/pkg/mariadb-10.3/news/
Anyway, thanks for solving this!

Bug#935650: netcat-openbsd: valid arguments disallowed

2019-08-25 Thread astian

Guilhem Moulin:
> On Sat, 24 Aug 2019 at 20:25:00 +, astian wrote:
>> Looking at the patch I don't trust this is the only behaviour change.  I
>> don't understand why this divergence from upstream was introduced and I
>> wish it was reverted altogether.
>
> The patch was added to support the following calls for consistency with
> netcat-traditional:
>
> nc -l -s 127.0.0.1 -p 12345 ## listen on AF_INET socket 
> INADDR_LOOPBACK:12345
> nc -l -p 12345  ## listen on AF_INET socket ADDR_ANY:12345
>
> It'd be a regression to stop supporting these forms, or any of the
> others from https://bugs.debian.org/897020#17 .

Ah, blessed compatibility.

>> But if that's not possible below is a patch that you can fold into the
>> existing one.
>> […]
>> -} else if (argc == 1 && !pflag && !sflag) {
>> +} else if (argc == 1 && !pflag && (!sflag || family == AF_UNIX)) {
>
> In combination with ‘-U’ the ‘-s’ option only makes sense for datagrams,
> no?

Yes, sorry.  (Now I remember that I was looking into making stream
UNIX-domain clients also bind() and accept an optional '-s' so that the
peer address is reported correctly in verbose mode.  This is an upstream
quirk/bug.)

> AFAICT it's a no-op for stream sockets; might make sense to error
> out unless ‘-u’ is set.

Right, so it could be something like:

-   } else if (argc == 1 && !pflag && !sflag) {
+   } else if (argc == 1 && !pflag && (!sflag || (family == AF_UNIX && 
uflag))) {

Or using the previously suggested diff and adding a dedicated check in
the if group below:

if (family == AF_UNIX) {
 ...
+   if (sflag && !uflag)
+   errx(1, "for unix sockets -s is only valid together "
+   "with -u");

> As for your other patches, I'm personally not keen to further diverge
> with upstream (especially when it comes to adding new flags/options) —

We concur.

Cheers.

Bug#935698: amule-utils-gui: amulegui crashing with current libwxgtk3.0-0v5 3.0.4+dfsg-9 and friends

2019-08-25 Thread martintxo

Package: amule-utils-gui
Version: 1:2.3.2-5+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

This box is a amd64 one, and I'm in testing. The current packages amule and
amule-daemon, and some of the little apps in package amule-utils-gui, works
well here, with the following versions:

amule  1:2.3.2-5+b1
amule-common   1:2.3.2-5
amule-daemon   1:2.3.2-5+b1
amule-gnome-support1:2.3.2-5
amule-utils1:2.3.2-5+b1
amule-utils-gui1:2.3.2-5+b1

libwxbase3.0-0v5:amd64  3.0.4+dfsg-9
libwxgtk-media3.0-gtk3-0v5  3.0.4+dfsg-9
libwxgtk3.0-0v5 3.0.4+dfsg-9
libwxgtk3.0-gtk3-0v53.0.4+dfsg-9

But this is not the case of amulegui. This app shows the initial dialogue for
input a password, and then it crashes with "Segmentation fault"...

I check any solution for this, and view that all amule apps, included amulegui
works well with the former version 3.0.4+dfsg-8 off libwx (I dowloaded from
snapshot repo and now I have them saved). I don't have here now, but I think
that the same fatal result was with an intermediate version 3.0.4+dfsg-8+b1...
So from 3.0.4+dfsg-8 to here, all the libwx versions crashes amulegui...

I make a debug trace of amulegui whit the instructions that reportbug shows,
viewing http://wiki.amule.org/wiki/Backtraces#Create_a_backtrace, and googling
a bit. I get a huge file of 14,8 Mb. I don know if it is useful. A big number
of lines are the same!!

I attached here the first lines, some at the middle part of the file, and the
last ones:

Currently logging to "gdb.txt".
Logs will be appended to the log file.
Output will be logged and displayed.
Starting program: /usr/bin/amulegui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 5529]
[New Thread 0x73805700 (LWP 5531)]
[New Thread 0x73004700 (LWP 5532)]
[New Thread 0x72803700 (LWP 5533)]
[New Thread 0x72002700 (LWP 5534)]
[Detaching after fork from child process 5535]

Thread 1 "amulegui" received signal SIGSEGV, Segmentation fault.
[34m0x775fa19b[m in [33mwxWindow::DoClientToScreen(int*, int*)
const[m () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#0  [34m0x775fa19b[m in [33mwxWindow::DoClientToScreen(int*, int*)
const[m () at [32m/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0[m
#1  [34m0x775fa1c5[m in [33mwxWindow::DoClientToScreen(int*, int*)
const[m () at [32m/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0[m
#2  [34m0x775fa1c5[m in [33mwxWindow::DoClientToScreen(int*, int*)
const[m () at [32m/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0[m
#3  [34m0x775fa1c5[m in [33mwxWindow::DoClientToScreen(int*, int*)
const[m () at [32m/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0[m


#34924 [34m0x775fa1c5[m in [33mwxWindow::DoClientToScreen(int*,
int*) const[m () at [32m/usr/lib/x86_64-linux-
gnu/libwx_gtk2u_core-3.0.so.0[m
#34925 [34m0x775f69f6[m in  () at [32m/usr/lib/x86_64-linux-
gnu/libwx_gtk2u_core-3.0.so.0[m
#34926 [34m0x775f9960[m in  () at [32m/usr/lib/x86_64-linux-
gnu/libwx_gtk2u_core-3.0.so.0[m
#34927 [34m0x767aa1eb[m in  () at [32m/usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0[m
#34928 [34m0x76504e8d[m in [33mg_closure_invoke[m () at
[32m/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
#34929 [34m0x76518555[m in  () at [32m/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0[m
#34930 [34m0x76520b9b[m in [33mg_signal_emit_valist[m () at
[32m/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
#34931 [34m0x76521b6f[m in [33mg_signal_emit[m () at
[32m/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
#34932 [34m0x768c0cac[m in  () at [32m/usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0[m
#34933 [34m0x767a8a04[m in [33mgtk_main_do_event[m () at
[32m/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0[m
#34934 [34m0x7661bbac[m in  () at [32m/usr/lib/x86_64-linux-
gnu/libgdk-x11-2.0.so.0[m
#34935 [34m0x7641e9ee[m in [33mg_main_context_dispatch[m () at
[32m/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0[m
#34936 [34m0x7641ec88[m in  () at [32m/usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0[m
#34937 [34m0x7641ef82[m in [33mg_main_loop_run[m () at
[32m/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0[m
#34938 [34m0x767a78e7[m in [33mgtk_main[m () at
[32m/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0[m
#34939 [34m0x775d9755[m in [33mwxGUIEventLoop::DoRun()[m () at
[32m/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0[m
#34940 [34m0x7710967d[m in [33mwxEventLoopBase::Run()[m () at
[32m/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0[m
#34941 [34m0x770d2e16[m in [33mwxAppConsoleBase::MainLoop()[m () at
[32m/usr/lib/x86_64-linux-gnu/libwx_ba

Bug#935699: gdm3: uninstallable on s390x

2019-08-25 Thread Ivo De Decker

package: gdm3
version: 3.30.2-3
severity: serious

Hi,

On s390x, gdm3 isn't installable, because it needs gnome-shell, which FTBFS
there. So either the dependency should be dropped or the binaries for gdm3 on
s390x should be removed.

Please note that this blocks the s390x binaries from some other packages (like
gnome-panel and gnome-applets) to migrate to testing. This also blocks new
source uploads for the packages depending on libgdm1.

Ivo

Bug#935700: RM: sphinx-issuetracker -- ROM; Python 2 only; dead upstream; no reverse dependencies

2019-08-25 Thread Dmitry Shachnev

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertag: py2removal

Last upstream commit was in 2014, and upstream does not respond to pull
requests like [1].

Reverse dependencies checked with with dak rm -Rn sphinx-issuetracker.

[1]: https://github.com/ignatenkobrain/sphinxcontrib-issuetracker/pull/13

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935568: sphinx-issuetracker: should this package be removed?

2019-08-25 Thread Dmitry Shachnev

On Sat, Aug 24, 2019 at 10:35:27PM -0400, Sandro Tosi wrote:
> it's possible `migrate` used to depend on
> python-sphinxcontrib.issuetracker but that's no longer the case, i
> think?

You are right, I was looking at old version.

Filed RM bug: https://bugs.debian.org/935700.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

2019-08-25 Thread Florian Weimer

* Francesco Poli:

> Hello everyone,
> I am sorry to ask, but... I cannot understand what's the status of
> [this bug report].
>
> [this bug report]: 
>
> A serious bug for libc6-dev without any apparent activity since last
> March?  Sure there must have been some hidden progress that I cannot
> see.

We provided a solution acceptable to the reporter.  I do not think
further action is needed on the glibc side.  The manual page needs to
be updated to reflect the change, but that's not part of glibc.

Bug#934905: libaqbanking35: libaqbanking not ready for PSD2, will not work after 14 September 2019

2019-08-25 Thread Felix Geyer


Hi Micha,

On Mon, 19 Aug 2019 20:19:28 +0200 Micha Lenk  wrote:

Hi Christian,

I understand your bug report and confirm it to be an issue.

Unfortunately I don't have much capacity at the moment to work on an 
updated package in a timely manner. But I do appreciate and support any 
volunteer's help.


I've tested libaqbaking 5.8.1 in combination with gnucash 3.6 + patch for the 
registration key.
It seems to work fine, at least the unregistered software warning from the log 
is gone.

The only packaging changes are some new entries in the symbols file (diff 
attached).
Do you mind if I NMU 5.8.1 to unstable?

Cheers,
Felix
diff --color -Nur libaqbanking-5.7.8/debian/libaqbanking35.symbols aqbanking-5.8.1/debian/libaqbanking35.symbols
--- libaqbanking-5.7.8/debian/libaqbanking35.symbols	2019-01-01 16:17:58.0 +0100
+++ aqbanking-5.8.1/debian/libaqbanking35.symbols	2019-08-25 11:35:28.119248252 +0200
@@ -80,6 +80,8 @@
  AB_AccountStatus_fromDb@Base 4.0.0
  AB_AccountStatus_new@Base 4.0.0
  AB_AccountStatus_toDb@Base 4.0.0
+ AB_AccountType_fromChar@Base 5.8.1
+ AB_AccountType_toChar@Base 5.8.1
  AB_Account_GetAccountName@Base 4.0.0
  AB_Account_GetAccountNumber@Base 4.0.0
  AB_Account_GetAccountType@Base 4.0.0
@@ -480,6 +482,10 @@
  AB_Banking_MakeGermanIban@Base 5.2.0beta
  AB_Banking_OnlineFini@Base 4.0.0
  AB_Banking_OnlineInit@Base 4.0.0
+ AB_Banking_RuntimeConfig_GetCharValue@Base 5.8.1
+ AB_Banking_RuntimeConfig_GetIntValue@Base 5.8.1
+ AB_Banking_RuntimeConfig_SetCharValue@Base 5.8.1
+ AB_Banking_RuntimeConfig_SetIntValue@Base 5.8.1
  AB_Banking_SaveAccountConfig@Base 4.2.0
  AB_Banking_SaveAppConfig@Base 4.0.0
  AB_Banking_SaveLocalImExporterProfile@Base 4.2.6

Bug#935004: cups-filters: print test page problem solved by upgrading to github version (1.25.1)

2019-08-25 Thread Brian Potkin

On Sat 24 Aug 2019 at 18:59:26 -0700, frede...@ofb.net wrote:

> Sorry for the delay, I just ran 'sudo apt-get update' and 'sudo
> apt-get remove cups-filters' and 'sudo apt-get install cups
> cups-filters hplip printer-driver-gutenprint printer-driver-hpcups'
> and I saw that it is trying to install the same version of
> cups-filters as I had reported the bug in. Can you explain how I
> should install the version you uploaded to Debian Unstable? I don't
> often use Debian so I am not familiar with this process.

You need to change the "deb" line in /etc/apt/sources.list to use the
unstable archive:

  deb http://deb.debian.org/debian/ unstable main contrib non-free

Then 'apt update' followed by 'apt install cups-filters'.

I do not see any benefit in updating the other other packages, but it
should not do any harm.

> Also, is there a reason why you think the new version would fix the
> problem? Perhaps since my time is limited and no one else has reported
> this bug, we should regard it as a potential misconfiguration, or an
> issue that may have arisen from my trying to install and then
> uninstall the Github cups-filters package as I explained in my
> original report.

Testing is best done with the latest version. You have described your
issue well, but we have little to go on. My inability to reproduce it
on unstable would incline me to close the report.

(The avahi-browse output would still be useful my records).

Cheers,

Brian.

Bug#921392: mtd-utils version in Debian

2019-08-25 Thread David Oberhollenzer

Hi,

I'm currently maintaining upstream mtd-utils. I saw that Debian Sid is
currently at mtd-utils 2.0.1, which (as of yesterday) is now 2 years old.

Version 2.0.2 suggested by bug #921392 includes a number of bug fixes
over 2.0.1 and was also released quite a bit over a year ago.

I wondered if there is some kind compatibility, regression or other issue
preventing an update to 2.0.2 that I should be aware of?

In particular, I would also be interested in whether there are still issues
upgrading to 2.1.x. Adding a number of new features and dependencies such
as OpenSSL caused some regression (as anticipated). Most of which where
addressed in 2.1.1 so far (released about a month ago).

Thanks,

David

Bug#935702: Wrong DM device size due to integer truncation

2019-08-25 Thread nbf


Package: cryptsetup-bin
Version: 2:2.1.0-5
Severity: serious

Dear Maintainer,

cryptsetup in Stable contains multiple severe integer handling issues.
Created DM device's size is set incorrectly due to integer truncation.

Not only the access to protected data is lost, the integritysetup's 
"open" operation actually succeeds. All reads on the incorrectly created 
DM device will of course fail with I/O errors due to bad integrity tags, 
but all writes will happily write wrong tags at wrong places! This makes 
it very easy for the administrator to destroy the data while trying to 
recover with --integrity-recovery-mode.


The issue is caused by a new set of functions "dm_*_target_set", 
introduced with cryptsetup 2:2.1.0, whose arguments use haphazardly 
chosen integer types, even though the actual types are easy to find.


For example, "uint64_t size" is temporarily stored in a size_t variable.
1) stored in lib/utils_dm.h: struct crypt_dm_active_device { uint64_t 
size, ... }
2) passed to lib/libdevmapper.c dm_*_target_set(..., (size_t)dmd.size, 
...

3) stored in lib/utils_dm.h: struct dm_target { uint64_t size, ... }

Seeing such carelessness in a core crypto software makes me very uneasy.


Best,
n.b.f.

-- Notes:
64-bit systems, whose size_t is 64bit, are safe from this bug.
Partitions smaller than 2TiB (2^32 * 512) are safe from this bug.
Severity: grave may be appropriate due to the potential for data loss.

Bug#935239: ftp.debian.org: Only the kde part depends on qt4

2019-08-25 Thread candeb

Sorry - my bad, syncevolution-libs-kde indeed depends on qt4.
However, I believe this is the only package of this source which does,
and it is not essential.  Could the source package be reinstated with
that particular backend package removed ?  Again, I am willing to do
the actual work.

Cheers,
Itaï.

Bug#935701: RM: zivot -- ROM; the package is not useful

2019-08-25 Thread Radovan Garabik

Package: ftp.debian.org
Severity: normal

Please remove zivot - the package is very simple and not useful. It is not even 
suitable for
teaching purposes.

Thanks



signature.asc
Description: PGP signature

Bug#935703: typo in the long description of Buzztrax

2019-08-25 Thread Olivier Humbert


Package: buzztrax
Version: 0.10.2-6

Dear debian maintainers,

d/control: there looks to be a typo here with "arrangment" which should 
be "arrangement" if I'm not wrong.


HTH
Olivier

--
Site web : https://librazik.tuxfamily.org/
Donation : https://liberapay.com/LibraZiK/
Diaspora : 
https://framasphere.org/people/8c184af0c9450134f6682a053625

Mastodon : https://mastodon.xyz/@LibraZiK

Bug#935239: ftp.debian.org: Package does not depend on qt4

2019-08-25 Thread Itaï BEN YAACOV

Package: ftp.debian.org
Followup-For: Bug #935239

Hello,

I do not understand why this is being removed. In any case the subject
line is wrong -- the package does not use qt4 (the ui package, which I
do not use, depends on gtk3).

The only similar issue I could see was bug #890170 -- dependence on
python-gobject, which Debian wants out.  If this is the case,
removing a useful package (for me at least) is a bit extreme?  If the
maintainer has gone silent, I am perfectly willing to do the trivial
modifications and forward them to someone who has upload rights.

Cheers,
Itaï

Bug#935239: ftp.debian.org: Only the kde part depends on qt4

2019-08-25 Thread Scott Kitterman

On Sunday, August 25, 2019 8:49:28 AM EDT can...@free.fr wrote:
> Sorry - my bad, syncevolution-libs-kde indeed depends on qt4.
> However, I believe this is the only package of this source which does,
> and it is not essential.  Could the source package be reinstated with
> that particular backend package removed ?  Again, I am willing to do
> the actual work.

Sure.  It'll need to go through the normal process for new packages again.

Scott K

Bug#917972: transition: openexr

2019-08-25 Thread Jonathan Wiltshire

Hi,

On Tue, Jan 01, 2019 at 09:47:43PM +0100, Matteo F. Vescovi wrote:
> I'm filing this bug for a new transition of openexr package.
> 
> On January 1st, 2019 a fixed testing-purpose package (2.3.0-4) has been
> uploaded to experimental.
> 
> So, following a checklist obtained via 'reverse-depends', here is the
> list of source packages depending on openexr and the results of the test
> builds (honoring the dependency levels as reported in the checklist, as
> relevant for the correct order):

Is this transition ready to go?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#935704: buster-pu: package sendmail/8.15.2-14~deb10u1

2019-08-25 Thread Andreas Beckmann

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

sendmail/buster is not compatible with the more strict checking in
start-stop-daemon/buster - matching on unpivileged pidfile alone is
insecure.
So match on the binary as well ... and while I debugged this, I also
noticed that sendmail was not stopped upon removal - the alternatives
were removed first, and thereafter the initscript turned into a noop
since the daemon was missing.

The package (a rebuild from sid) is already uploaded.


Andreas
diff -Nru sendmail-8.15.2/debian/changelog sendmail-8.15.2/debian/changelog
--- sendmail-8.15.2/debian/changelog2018-09-16 00:11:47.0 +0200
+++ sendmail-8.15.2/debian/changelog2019-08-25 15:04:16.0 +0200
@@ -1,3 +1,27 @@
+sendmail (8.15.2-14~deb10u1) buster; urgency=medium
+
+  * QA upload.
+  * Rebuild for buster.
+
+ -- Andreas Beckmann   Sun, 25 Aug 2019 15:04:16 +0200
+
+sendmail (8.15.2-14) unstable; urgency=medium
+
+  * QA upload.
+  * sendmail-bin.prerm: Stop sendmail before removing the alternatives.
+  * sendmail-bin.postinst: Let start-stop-daemon match on pidfile and
+executable.  (Closes: #932598)
+
+ -- Andreas Beckmann   Sun, 25 Aug 2019 14:56:41 +0200
+
+sendmail (8.15.2-13) unstable; urgency=medium
+
+  * QA upload.
+  * initscript: Let start-stop-daemon match on pidfile and executable.
+(Closes: #932598, LP: #1822866)
+
+ -- Andreas Beckmann   Tue, 30 Jul 2019 19:22:43 +0200
+
 sendmail (8.15.2-12) unstable; urgency=medium
 
   * QA upload.
diff -Nru sendmail-8.15.2/debian/local/sendmail.in 
sendmail-8.15.2/debian/local/sendmail.in
--- sendmail-8.15.2/debian/local/sendmail.in2018-09-16 00:11:47.0 
+0200
+++ sendmail-8.15.2/debian/local/sendmail.in2019-08-25 15:04:16.0 
+0200
@@ -103,43 +103,46 @@
STAMP_DIR="${SENDMAIL_ROOT}/stampdir";
START_MTAL_CMD="start-stop-daemon \
--pidfile $MTAL_PIDFILE \
-   --exec $MTA_DAEMON \
--startas $MTA_COMMAND \
--start";
STOP_MTAL_CMD="start-stop-daemon \
--pidfile $MTAL_PIDFILE \
+   --exec $MTA_COMMAND \
--name sendmail-mta \
--stop";
SIGNAL_MTAL_CMD="start-stop-daemon \
--pidfile $MTAL_PIDFILE \
+   --exec $MTA_COMMAND \
--name sendmail-mta \
--stop";
START_MTAQ_CMD="start-stop-daemon \
--pidfile $MTAQ_PIDFILE \
--make-pidfile \
-   --exec $MTA_DAEMON \
--startas $MTA_COMMAND \
--start";
STOP_MTAQ_CMD="start-stop-daemon \
--pidfile $MTAQ_PIDFILE \
+   --exec $MTA_COMMAND \
--name sendmail-mta \
--stop";
SIGNAL_MTAQ_CMD="start-stop-daemon \
--pidfile $MTAQ_PIDFILE \
+   --exec $MTA_COMMAND \
--name sendmail-mta \
--stop";
START_MSP_CMD="start-stop-daemon \
--pidfile $MSP_PIDFILE \
-   --exec $MSP_DAEMON \
--startas $MSP_COMMAND \
--chuid smmsp \
--start";
STOP_MSP_CMD="start-stop-daemon \
--pidfile $MSP_PIDFILE \
+   --exec $MSP_COMMAND \
--name sendmail-msp \
--stop";
SIGNAL_MSP_CMD="start-stop-daemon \
--pidfile $MSP_PIDFILE \
+   --exec $MSP_COMMAND \
--name sendmail-msp \
--stop";
NAME='sendmail';
diff -Nru sendmail-8.15.2/debian/sendmail-bin.postinst.in 
sendmail-8.15.2/debian/sendmail-bin.postinst.in
--- sendmail-8.15.2/debian/sendmail-bin.postinst.in 2018-09-16 
00:11:47.0 +0200
+++ sendmail-8.15.2/debian/sendmail-bin.postinst.in 2019-08-25 
15:04:16.0 +0200
@@ -6,29 +6,34 @@
 #---
 #stop(): stop sendmail
 stop_mta () {
+   if [ -x @sysconfdir@/init.d/sendmail ]; then
+   invoke-rc.d --quiet --force sendmail stop
+   fi
# Account for varying PIDfile locations of older sendmail packages
if [ -f /var/run/sendmail/mta/sendmail.pid ]; then
start-stop-daemon --stop --oknodo --quiet \
+   --exec /usr/lib/sm.bin/sendmail \
--pidfile /var/run/sendmail/msp/sendmail.pid > 
/dev/null;
start-stop-daemon --stop --oknodo --quiet \
-   -pidfile /var/run/sendmail/mta/sendmail.pid > /dev/null;
+   --exec /usr/lib/sm.bin/sendmail \
+   --pidfile /var/run/sendmail/mta/sendmail.pid > 
/dev/null;
elif [ -f /var/run/sendmail/sendmail.pid ]; then
start-stop-daemon --stop --oknodo --quiet \
+   --exec /usr/lib/sm.bin/sendma

Bug#935705: RM: qjson -- ROM; Dead upstream, uses Qt 4, superseded by Qt 5 itself

2019-08-25 Thread Lisandro Damián Nicanor Pérez Meyer

Package: ftp.debian.org
Severity: normal
Control: block -1 by #935663

Hi! Qjson can go just after kdepimlib (#935663). Upstream has stopped it's
development shortly after Qt 5 as it's functionality is alredy superseded in Qt
5 itself.

Kinds regards, Lisandro.

Bug#935706: lintian: Make tag certainty a programmatic assessment

2019-08-25 Thread Felix Lechner

Package: lintian

Hi,

A tag's certainty is currently fixed but actually depends on the
programmatic circumstances of its issuance. Some heuristics are better
than others. The 'tag' command should offer alternatives, which then
result in different alert levels (error, warning, info, and so on).

An example are tags that depend on native or non-native sources. For a
source package, the determination is easy. For an installation package
(*.deb) there is no way to know for sure, but the version number may
offer a guess:

For source packages, the tag would be certain (from a pending version
of checks/source-changelog.pm):

my $maintainer_revision = $latest_version->maintainer_revision;
(full version for native)
tag->certain 'hyphen-in-native-debian-changelog-version',
$maintainer_revision
if $info->native && $maintainer_revision =~ qr/-/;

while for installation packages (*.deb) it would not:

my $version = $latest_entry->{Version}; (literal version string)
tag->possible 'hyphen-in-native-debian-changelog-version', $version
if [not sure this can be determined];

The first use would produce an error; the second, a warning.

For the new mechanism to work, overrides should exclude the alert
level. They would function more like the universal tag format used in
the test suite.

Kind regards,
Felix Lechner

Bug#931949: transition: proj

2019-08-25 Thread Jonathan Wiltshire

Hi,

On Fri, Jul 12, 2019 at 09:39:26PM +0200, Bas Couwenberg wrote:
> For the Debian GIS team I'd like to transition to PROJ 6.
> 
> This is a major change that affects the wider GIS ecosystem, with proj
> being at the bottom of the dependency chain.

Please go ahead.

Thanks,
-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#932956: ITP: node-node-sass -- Wrapper around libsass

2019-08-25 Thread Xavier

Hi Ftpmasters,

this package embeds some little components and one big (sass-spec).
sass-spec isn't use elsewhere (see
https://www.npmjs.com/package/sass-spec?activeTab=dependents) and
provides only C++ files needed to compile node-node-sass. That's why
none of its files are installed (installed modules are listed in
debian/nodejs/submodules).

Other little components embedded and installed:
 - async-foreach
 - gaze
 - get-stdin
 - js-base64
 - sass-graph
 - scss-tokenizer
 - stdout-stream
 - true-case-path

Cheers,
Xavier

Bug#935650: netcat-openbsd: valid arguments disallowed

2019-08-25 Thread astian

astian:
>> AFAICT it's a no-op for stream sockets; might make sense to error
>> out unless ‘-u’ is set.
> 
> Right, so it could be something like:
> 
> - } else if (argc == 1 && !pflag && !sflag) {
> + } else if (argc == 1 && !pflag && (!sflag || (family == AF_UNIX && 
> uflag))) {
> 
> Or using the previously suggested diff and adding a dedicated check in
> the if group below:
> 
>   if (family == AF_UNIX) {
>  ...
> + if (sflag && !uflag)
> + errx(1, "for unix sockets -s is only valid together "
> + "with -u");

Actually there are still issues here.  I'll write tomorrow.

Cheers.

Bug#916650: liquidsoap 1.1.1-7.2+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 916650 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: liquidsoap
Version: 1.1.1-7.2+deb9u1

Explanation: fix compilation with Ocaml 4.02

Bug#928276: biomaj-watcher 1.2.2-4+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 928276 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: biomaj-watcher
Version: 1.2.2-4+deb9u1

Explanation: fix upgrades from jessie to stretch

Bug#935709: libupnp13: Port autoconfiguration does not work when running multiple instances of the library

2019-08-25 Thread Jean-Francois Dockes

Package: libupnp13
Version: 1:1.8.4-2
Severity: important

Dear Maintainer,

When libupnp is configured with --enable-reuseaddr (the case on Debian), it
does not retry with a higher port if the default one (49152) is busy.

This makes it difficult to run multiple apps (e.g. renderer + control point
or multiple control points) on the same host. The second libupnp-based
application fails if it tries to use the default port. The only workaround
is to manually configure different ports, but this is a major
regression compared to the previous situation (libupnp 1.6) where the next
available port was just used.

See github issue 91, which includes a patch (also available in 1.8.5).
https://github.com/mrjimenez/pupnp/issues/91

Cheers,

J.F. Dockes

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/3 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libupnp13 depends on:
ii  libc6  2.28-10
ii  libixml10  1:1.8.4-2

libupnp13 recommends no packages.

libupnp13 suggests no packages.

-- no debconf information

Bug#935710: FTBFS: tests fail

2019-08-25 Thread David Bremner

Source: emacs-python-environment
Version: 0.0.2-4
Severity: serious
Justification: ftbfs

During a no-change rebuild, I noticed this package fails to build from source

Apparently the tests are failing

https://buildd.debian.org/status/fetch.php?pkg=emacs-python-environment&arch=all&ver=0.0.2-4&stamp=1566739692&file=log

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

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

Bug#891581: chaosreader 0.96-2+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 891581 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: chaosreader
Version: 0.96-2+deb9u1

Explanation: add missing dependency on libnet-dns-perl

Bug#935599: libxslt 1.1.29-2.1+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 935599 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libxslt
Version: 1.1.29-2.1+deb9u1

Explanation: fix security framework bypass [CVE-2019-11068]; fix uninitialized 
read of xsl:number token [CVE-2019-13117]; fix uninitialized read with UTF-8 
grouping chars [CVE-2019-13118]

Bug#934356: mitmproxy 0.18.2-6+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 934356 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: mitmproxy
Version: 0.18.2-6+deb9u1

Explanation: blacklist tests that require Internet access

Bug#935708: stretch-pu: package clamav/0.101.4+dfsg-0+deb9u1

2019-08-25 Thread Sebastian Andrzej Siewior

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

Clamav upstream released 0.101.4 which is a "security patch release"
only. It is described [0] as:

|- The zip bomb vulnerability mitigated in 0.101.3 has been assigned the CVE
|  identifier CVE-2019-12625. Unfortunately, a workaround for the zip-bomb
|  mitigation was immediately identified. To remediate the zip-bomb scan time
|  issue, a scan time limit has been introduced in 0.101.4. This limit now
|  resolves ClamAV's vulnerability to CVE-2019-12625.
|
|- An out of bounds write was possible within ClamAV's NSIS bzip2 library when
|  attempting decompression in cases where the number of selectors exceeded the
|  max limit set by the library (CVE-2019-12900). The issue has been resolved by
|  respecting that limit.

[0] https://blog.clamav.net/2019/08/clamav-01014-security-patch-release-has.html

Sebastian
diff -Nru clamav-0.101.2+dfsg/clamd/server-th.c clamav-0.101.4+dfsg/clamd/server-th.c
--- clamav-0.101.2+dfsg/clamd/server-th.c	2019-03-13 22:13:01.0 +0100
+++ clamav-0.101.4+dfsg/clamd/server-th.c	2019-08-20 18:08:49.0 +0200
@@ -88,7 +88,7 @@
 #ifndef	_WIN32
 /* ignore all signals */
 sigfillset(&sigset);
-/* The behavior of a process is undefined after it ignores a 
+/* The behavior of a process is undefined after it ignores a
  * SIGFPE, SIGILL, SIGSEGV, or SIGBUS signal */
 sigdelset(&sigset, SIGFPE);
 sigdelset(&sigset, SIGILL);
@@ -552,7 +552,7 @@
 		/* no more commands are accepted */
 		conn->mode = MODE_WAITREPLY;
 		/* Stop monitoring this FD, it will be closed either
-		 * by us, or by the scanner thread. 
+		 * by us, or by the scanner thread.
 		 * Never close a file descriptor that is being
 		 * monitored by poll()/select() from another thread,
 		 * because this can lead to subtle bugs such as:
@@ -631,7 +631,7 @@
 int rc;
 size_t pos = *ppos;
 size_t cmdlen;
-
+
 logg("$mode == MODE_STREAM\n");
 /* we received some data, set readtimeout */
 time(&buf->timeout_at);
@@ -754,12 +754,25 @@
 	memset(&options, 0, sizeof(struct cl_scan_options));
 
 /* set up limits */
-if((opt = optget(opts, "MaxScanSize"))->active) {
-	if((ret = cl_engine_set_num(engine, CL_ENGINE_MAX_SCANSIZE, opt->numarg))) {
-	logg("!cl_engine_set_num(CL_ENGINE_MAX_SCANSIZE) failed: %s\n", cl_strerror(ret));
-	cl_engine_free(engine);
-	return 1;
-	}
+if ((opt = optget(opts, "MaxScanTime"))->active) {
+if ((ret = cl_engine_set_num(engine, CL_ENGINE_MAX_SCANTIME, opt->numarg))) {
+logg("!cl_engine_set_num(CL_ENGINE_MAX_SCANTIME) failed: %s\n", cl_strerror(ret));
+cl_engine_free(engine);
+return 1;
+}
+}
+val = cl_engine_get_num(engine, CL_ENGINE_MAX_SCANTIME, NULL);
+if (val)
+logg("Limits: Global time limit set to %llu milliseconds.\n", val);
+else
+logg("^Limits: Global time limit protection disabled.\n");
+
+if ((opt = optget(opts, "MaxScanSize"))->active) {
+if ((ret = cl_engine_set_num(engine, CL_ENGINE_MAX_SCANSIZE, opt->numarg))) {
+logg("!cl_engine_set_num(CL_ENGINE_MAX_SCANSIZE) failed: %s\n", cl_strerror(ret));
+cl_engine_free(engine);
+return 1;
+}
 }
 val = cl_engine_get_num(engine, CL_ENGINE_MAX_SCANSIZE, NULL);
 if(val)
@@ -1016,7 +1029,7 @@
 
 	/* TODO: Remove deprecated option in a future feature release */
 if (optget(opts, "ScanPE")->enabled || optget(opts, "ScanELF")->enabled) {
-if ((optget(opts, "DetectBrokenExecutables")->enabled) || 
+if ((optget(opts, "DetectBrokenExecutables")->enabled) ||
 			(optget(opts, "AlertBrokenExecutables")->enabled)) {
 logg("Alerting on broken executables enabled.\n");
 options.heuristic |= CL_SCAN_HEURISTIC_BROKEN;
@@ -1039,7 +1052,7 @@
 if (optget(opts, "ScanOLE2")->enabled) {
 logg("OLE2 support enabled.\n");
 options.parse |= CL_SCAN_PARSE_OLE2;
-		
+
 		/* TODO: Remove deprecated option in a future feature release */
 if ((optget(opts, "OLE2BlockMacros")->enabled) ||
 	(optget(opts, "AlertOLE2Macros")->enabled)) {
@@ -1187,7 +1200,7 @@
 	int solaris_has_extended_stdio = 0;
 #endif
 	/* Condition to not run out of file descriptors:
-	 * MaxThreads * MaxRecursion + (MaxQueue - MaxThreads) + CLAMDFILES < RLIMIT_NOFILE 
+	 * MaxThreads * MaxRecursion + (MaxQueue - MaxThreads) + CLAMDFILES < RLIMIT_NOFILE
 	 * CLAMDFILES is 6: 3 standard FD + logfile + 2 FD for reloading the DB
 	 * */
 #ifdef C_SOLARIS
@@ -1314,12 +1327,12 @@
 sigdelset(&sigset, SIGHUP);
 sigdelset(&sigset, SIGPIPE);
 sigdelset(&sigset, SIGUSR2);
-/* The behavior of a process is undefined after it ignores a 
+/* The behavior of a process is undefined after it ignores a
  * SIGFPE, SIGILL, SIGSEGV, or SIGBUS signal */
 sigdelset(&sigset, S

Bug#935711: FTBFS: looks for docker?

2019-08-25 Thread David Bremner

Source: emacs-pdf-tools
Version: 0.90-2
Severity: serious
Justification: ftbfs

During a no-change rebuild I noticed this packge does not build from source.
Apologies if this is caused by the way I created the source package:

%  dgit --quilt=auto push-source --overwrite

A sample build log is at

https://buildd.debian.org/status/fetch.php?pkg=emacs-pdf-tools&arch=amd64&ver=0.90-2&stamp=1566739129&file=log

I'm not sure what it wants docker for, but here is the relevant portion of logs:

Creating Dockerfile for target gentoo
Creating Dockerfile for target centos-7
cat docker/templates/gentoo.Dockerfile.in docker/templates/Dockerfile.in > 
docker/gentoo.Dockerfile
Creating Dockerfile for target fedora-25
cat docker/templates/centos-7.Dockerfile.in docker/templates/Dockerfile.in > 
docker/centos-7.Dockerfile
Creating Dockerfile for target arch
cat docker/templates/fedora-25.Dockerfile.in docker/templates/Dockerfile.in > 
docker/fedora-25.Dockerfile
cat docker/templates/arch.Dockerfile.in docker/templates/Dockerfile.in > 
docker/arch.Dockerfile
Creating Dockerfile for target ubuntu-16
cat docker/templates/ubuntu-16.Dockerfile.in docker/templates/Dockerfile.in > 
docker/ubuntu-16.Dockerfile
Creating Dockerfile for target fedora-24
Creating Dockerfile for target debian-9
cat docker/templates/fedora-24.Dockerfile.in docker/templates/Dockerfile.in > 
docker/fedora-24.Dockerfile
cat docker/templates/debian-9.Dockerfile.in docker/templates/Dockerfile.in > 
docker/debian-9.Dockerfile
Creating Dockerfile for target fedora-26
cat docker/templates/fedora-26.Dockerfile.in docker/templates/Dockerfile.in > 
docker/fedora-26.Dockerfile
Creating Dockerfile for target ubuntu-14
cat docker/templates/ubuntu-14.Dockerfile.in docker/templates/Dockerfile.in > 
docker/ubuntu-14.Dockerfile
Creating Dockerfile for target ubuntu-17
cat docker/templates/ubuntu-17.Dockerfile.in docker/templates/Dockerfile.in > 
docker/ubuntu-17.Dockerfile
Creating Dockerfile for target debian-8
cat docker/templates/debian-8.Dockerfile.in docker/templates/Dockerfile.in > 
docker/debian-8.Dockerfile
Building target gentoo
docker build -q -t epdfinfo/gentoo -f docker/gentoo.Dockerfile ../
Building target centos-7
make[3]: docker: Command not found
Building target fedora-25
docker build -q -t epdfinfo/centos-7 -f docker/centos-7.Dockerfile ../
make[3]: docker: Command not found
Building target arch
make[3]: *** [Makefile:30: docker/.gentoo.build] Error 127
make[3]: *** Waiting for unfinished jobs
make[3]: *** [Makefile:30: docker/.centos-7.build] Error 127
docker build -q -t epdfinfo/fedora-25 -f docker/fedora-25.Dockerfile ../
make[3]: docker: Command not found
make[3]: *** [Makefile:30: docker/.fedora-25.build] Error 127
docker build -q -t epdfinfo/arch -f docker/arch.Dockerfile ../
make[3]: docker: Command not found
make[3]: *** [Makefile:30: docker/.arch.build] Error 127
make[3]: Leaving directory '/<>/server/test'
make[2]: *** [Makefile:940: check-local] Error 2
make[2]: Leaving directory '/<>/server'
make[1]: *** [Makefile:801: check-am] Error 2
make[1]: Leaving directory '/<>/server'
dh_auto_test: cd server && make -j4 check VERBOSE=1 returned exit code 2
make: *** [debian/rules:15: build-arch] Error 255
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Build finished at 2019-08-25T13:18:44Z

Finished




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

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

Bug#935712: FTBFS: dh-elpa error

2019-08-25 Thread David Bremner

Source: emacs-git-modes
Version: 1.2.8-2
Severity: serious
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

during a no-change rebuild of this package I noticed that it fails to build 
from source

It looks like there is an incompatibility with the latest
dh-elpa.

,
| Generating git-modes-autoloads.el
| Installing...
| make[1]: Leaving directory '/<>'
|dh_elpa -i
| dh_elpa: emacs -batch -Q -l package --eval (add-to-list 
'package-directory-list "/usr/share/emacs/site-lisp/elpa") --eval (add-to-list 
'package-directory-list "/usr/share/emacs/site-lisp/elpa-src") -f 
package-initialize -l dh-elpa.el -f dhelpa-batch-install-file 
debian/elpa-git-modes//usr/share/emacs/site-lisp/elpa-src ./git-modes.el 
/<>/debian/.debhelper/elpa 1566734946 returned exit code 255
| E: The Debian version  cannot be used as an ELPA version.
| See dh_elpa(1) HINTS for how to deal with this.
| make: *** [debian/rules:4: binary-indep] Error 255
| dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2
`

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl1ikmgACgkQA0U5G1Wq
FSEbQw/+OXMkwDg7Pw5Cid5/x8GM8JRnWFKypsEBGeRDE0qdNHaGY0ep2uv67lLE
+1OwHCkuMMIkPNgb0qxX66iXejatKKtFefQ/YE6GwtIHaPlr1Fjdi+CeJpRF/PIP
06II9XCzcb8fIPHhQWgOnkO+8ZqQtI26l5piLYqrehfd3ztsoCmP0mlRPtkdYKUJ
0/Ia3t61yq0KYdn8KKNEZD3GPLAbz4c/9zr8FFp30u4qvX6KanYZ7G5Dix1H8sti
Y3fDOzLmjhyLOzVi2Vg7nb1ZzuPqEH0zAcQT+G0ONibuR+Ttfa/Z7StSLaF9Kf1p
W1SoM/TupjYxuDdwGEfnoDVHiBdrWRRkAHngp6vmX/N7odCB3pPGxuM05kOKJhch
duv4hWzMdu6iPoS9Qfm/3FSQe5mUN0bTqfAogRJjTLnXPNkufV1pTmCfE8sT2TJj
O12EUmhB0ELdPVEak6QS2kSXfV6y04iImOkS27lTiE+xtxrrt8RCxRGwZ06Z6lv6
ubdUG9yREAhDsLVFcCISF2YiwhCZ2Pv0wQuTQE+XJLhNyIa1D1v1sOeP02+z8A0o
hCRDB4Hv9H2PzDIY9eDEUOc3VJxk5y21Kj9BLaSAA6aVpbmHCQTjXlS2AdDIE/0j
tB4r5TrT+3mEsM2tt5rv/isPoIg5ZZt+Hbk+8rftdxOw/z9lhU4=
=N3Up
-END PGP SIGNATURE-

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

2019-08-25 Thread Francesco Poli

On Sun, 25 Aug 2019 13:46:36 +0200 Florian Weimer wrote:

> * Francesco Poli:
> 
> > Hello everyone,
> > I am sorry to ask, but... I cannot understand what's the status of
> > [this bug report].
> >
> > [this bug report]: 
> >
> > A serious bug for libc6-dev without any apparent activity since last
> > March?  Sure there must have been some hidden progress that I cannot
> > see.
> 
> We provided a solution acceptable to the reporter.  I do not think
> further action is needed on the glibc side.  The manual page needs to
> be updated to reflect the change, but that's not part of glibc.

OK, good.
Thanks for your prompt reply!

Why is the bug report being kept open, though?
Should it be reassigned to package manpages-dev and fixed there?


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


pgpt0AJHiXGWO.pgp
Description: PGP signature

Bug#935583: babeltrace 1.5.6-2+deb10u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 935583 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: babeltrace
Version: 1.5.6-2+deb10u1

Explanation: bump ctf symbols depends to post merge version

Bug#935474: xymon 4.3.28-5+deb10u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 935474 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: xymon
Version: 4.3.28-5+deb10u1

Explanation: fix several (server only) security issues [CVE-2019-13273 
CVE-2019-13274 CVE-2019-13451 CVE-2019-13452 CVE-2019-13455 CVE-2019-13484 
CVE-2019-13485 CVE-2019-13486]

Bug#931610: pound 2.7-1.3+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 931610 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: pound
Version: 2.7-1.3+deb9u1

Explanation: fix request smuggling via crafted headers [CVE-2016-10711]

Bug#935581: z3 4.4.1-1~deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 935581 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: z3
Version: 4.4.1-1~deb9u1

Explanation: do not set the SONAME of libz3java.so to libz3.so.4

Bug#930112: node-growl 1.7.0-1+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 930112 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: node-growl
Version: 1.7.0-1+deb9u1

Explanation: sanitize input before passing it to exec

Bug#915935: zfs-auto-snapshot 1.2.1-1+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 915935 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: zfs-auto-snapshot
Version: 1.2.1-1+deb9u1

Explanation: make cronjobs exit silently after package removal

Bug#935473: xymon 4.3.28-2+deb9u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 935473 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: xymon
Version: 4.3.28-2+deb9u1

Explanation: fix several (server only) security issues [CVE-2019-13273 
CVE-2019-13274 CVE-2019-13451 CVE-2019-13452 CVE-2019-13455 CVE-2019-13484 
CVE-2019-13485 CVE-2019-13486]

Bug#935708: stretch-pu: package clamav/0.101.4+dfsg-0+deb9u1

2019-08-25 Thread Adam D. Barratt

Control: tags -1 + confirmed

On Sun, 2019-08-25 at 15:27 +0200, Sebastian Andrzej Siewior wrote:
> Clamav upstream released 0.101.4 which is a "security patch release"
> only. It is described [0] as:
> 
> > - The zip bomb vulnerability mitigated in 0.101.3 has been assigned
> > the CVE
> >  identifier CVE-2019-12625. Unfortunately, a workaround for the
> > zip-bomb
> >  mitigation was immediately identified. To remediate the zip-bomb
> > scan time
> >  issue, a scan time limit has been introduced in 0.101.4. This
> > limit now
> >  resolves ClamAV's vulnerability to CVE-2019-12625.
> > 
> > - An out of bounds write was possible within ClamAV's NSIS bzip2
> > library when
> >  attempting decompression in cases where the number of selectors
> > exceeded the
> >  max limit set by the library (CVE-2019-12900). The issue has been
> > resolved by
> >  respecting that limit.

Please go ahead.

Regards,

Adam

Bug#935707: buster-pu: package clamav/0.101.4+dfsg-0+deb10u1

2019-08-25 Thread Adam D. Barratt

Control: tags -1 + confirmed

On Sun, 2019-08-25 at 15:27 +0200, Sebastian Andrzej Siewior wrote:
> Clamav upstream released 0.101.4 which is a "security patch release"
> only. It is described [0] as:
> 
> > - The zip bomb vulnerability mitigated in 0.101.3 has been assigned
> > the CVE
> >  identifier CVE-2019-12625. Unfortunately, a workaround for the
> > zip-bomb
> >  mitigation was immediately identified. To remediate the zip-bomb
> > scan time
> >  issue, a scan time limit has been introduced in 0.101.4. This
> > limit now
> >  resolves ClamAV's vulnerability to CVE-2019-12625.
> > 
> > - An out of bounds write was possible within ClamAV's NSIS bzip2
> > library when
> >  attempting decompression in cases where the number of selectors
> > exceeded the
> >  max limit set by the library (CVE-2019-12900). The issue has been
> > resolved by
> >  respecting that limit.

Please go ahead.

Regards,

Adam

Bug#930795: ruby-airbrussh 1.3.1-2+deb10u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 930795 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: ruby-airbrussh
Version: 1.3.1-2+deb10u1

Explanation: don't throw exception on invalid UTF-8 SSH output

Bug#934650: open-infrastructure-compute-tools 20190301-lts2-1~deb10u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 934650 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: open-infrastructure-compute-tools
Version: 20190301-lts2-1~deb10u1

Explanation: fix container start

Bug#932522: pam-u2f 1.0.7-1+deb10u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 932522 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: pam-u2f
Version: 1.0.7-1+deb10u1

Explanation: fix insecure debug file handling [CVE-2019-12209]; fix debug file 
descriptor leak [CVE-2019-12210]; fix out-of-bounds access; fix segfault 
following a failure to allocate a buffer

Bug#935714: python-os-net-config (build-) depends on cruft package.

2019-08-25 Thread Peter Michael Green


Package: python-os-net-config
Version: 0.1.0-1
Severity: serious
Tags: bullseye, sid

python-os-net-config (build-)depends on the python-oslo.config binary 
package which is no longer built by the corresponding source package.


I see no reverse-depends, should this package simply be removed?

Bug#932009: gcab 1.2-3~deb10u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 932009 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gcab
Version: 1.2-3~deb10u1

Explanation: fix corruption when extracting

Bug#935576: z3 4.4.1-1~deb10u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 935576 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: z3
Version: 4.4.1-1~deb10u1

Explanation: do not set the SONAME of libz3java.so to libz3.so.4

Bug#934704: node-lodash 4.17.11+dfsg-2+deb10u1 flagged for acceptance

2019-08-25 Thread Adam D Barratt

package release.debian.org
tags 934704 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-lodash
Version: 4.17.11+dfsg-2+deb10u1

Explanation: fix prototype pollution [CVE-2019-10744]

Bug#935713: src:thrift: Incomplete debian/copyright

2019-08-25 Thread Scott Kitterman

Package: src:thrift
Version: 0.11.0-4
Severity: serious
Justification: Policy 2.3

While reviewing your package in New, I noticed omissions from debian/
copyright.  Since this problem also exists in the current package, I am
filing this bug rather than rejecting the package.

At a minimum, the following copyright/licenses are missing:

compile: GPL 2+

compiler/cpp/src/thrift/thrifty.hh: GPL 3+ + Bison exception
compiler/cpp/src/thrift/thrifty.cc

lib/php/src/ext/thrift_protocol/run-tests.php: PHP 3.01
Note: it references a LICENSE file that appears to be missing.

Please keep https://ftp-master.debian.org/php-license.html in mind when
you update your debian/copyright.

ylwrap: GPL 2+

build/cmake/FindGLIB.cmake: BSD 2 clause

Scott K

Bug#935715: src:thrift: Python packaging errors

2019-08-25 Thread Scott Kitterman

Package: src:thrift
Version: 0.11.0-5
Severity: normal

While reviewing your package in New, I noted a few errors related to the
python packaging.  Please fix in a future upload.

--- control 2019-08-24 15:47:34.0 +
+++ control.new 2019-08-25 14:09:10.305843854 +
@@ -102,8 +102,6 @@
 Section: python
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
-Provides: ${python:Provides}
-XB-Python-Version: ${python:Versions}
 Conflicts: python-thrift (<= 0.9.1-2)
 Replaces: python-thrift (<= 0.9.1-2)
 Description: Python library for Thrift
@@ -130,8 +128,6 @@
 Section: python
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
-Provides: ${python3:Provides}
-XB-Python-Version: ${python3:Versions}
 Description: Python 3 library for Thrift
  Thrift is a software framework for the development of reliable and
  performant communication and data serialization. It combines a software

Python:Provides and XB-Python-Version are no longer used for Python and
have never been supported for Python 3.

Also, it seems odd to have python-thrift conflict/replace itself, but I
didn't investigate that.

Scott K

Bug#931914: FTBFS with PROJ 6

2019-08-25 Thread Sebastiaan Couwenberg

Control: severity -1 serious

The proj transition has started, raising severity accordingly.

Kind Regards,

bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#935540: debian-installer: Errors on sources.list security repositories

2019-08-25 Thread Cyril Brulebois

[ Please don't drop submitters; quoting in full accordingly. ]

Philip Hands  (2019-08-24):
> Cyril Brulebois  writes:
> 
> > Control: tag -1 - d-i
> >
> > Hi Gustavo,
> >
> > Gustavo Romero Vazquez  (2019-08-23):
> >> See the Wiki Debian (https://wiki.debian.org/Status/Testing), the
> >> security repositories for bullseye are the next (and they working):
> >>
> >> deb http://security.debian.org testing-security main contrib non-free
> >> deb-src http://security.debian.org testing-security main contrib non-free
> >>
> >> Regards and good luck!!
> >
> > You're absolutely right. I had stashed a branch a while ago, but it was
> > suggested to handle things slightly differently:
> >
> >“do it other way around and hardcode the old releases rather than
> > hardcode the new one?”
> >
> > I've just rebased it on top of master, and it'd be great if someone
> > could rework it to take the above comment in consideration:
> >
> >   
> > https://salsa.debian.org/installer-team/apt-setup/tree/pu/security-naming-scheme
> 
> Hopefully something like this what you were wanting done:
> 
>   
> https://salsa.debian.org/installer-team/apt-setup/commit/78078caff231de7bb5a161fa19210b4ac6eb2cb5

Yes, that looks sane enough.

I meant to check how this could affect Ubuntu. But from what I can see
in apt-setup/0.141ubuntu2, there are a bunch of changes already anyway,
so except for a possible merge conflict, that shouldn't be much of an
issue.

Feel free to release that to master/the archive if you like.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#935615: [Aptitude-devel] Bug#935615: aptitude: FTBFS on amd64

2019-08-25 Thread Axel Beckert

Hi Manuel,

Ivo De Decker wrote:
> A binnmu of aptitude in unstable fails on amd64:
> 
> https://buildd.debian.org/status/package.php?p=aptitude

Do you happen to know if any of your recent commits to the master
branch already fixes this issue? I haven't found any which looks
fitting on a first glance...

If you can pinpoint one or more commits, I can cherry pick them and do
a quick upload to fix this issue.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#931949: transition: proj

2019-08-25 Thread Sebastiaan Couwenberg

On 8/25/19 3:22 PM, Jonathan Wiltshire wrote:
> On Fri, Jul 12, 2019 at 09:39:26PM +0200, Bas Couwenberg wrote:
>> For the Debian GIS team I'd like to transition to PROJ 6.
>>
>> This is a major change that affects the wider GIS ecosystem, with proj
>> being at the bottom of the dependency chain.
> 
> Please go ahead.

Thanks!

proj (6.1.1-1), libgeotiff (1.5.1-1) & python-pyproj (2.3.0+ds-1) have
been uploaded to unstable. And the severity of the remaining bugreports
has been raised.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#834414: apt-daily.service fails permanently and quietly as it runs before network is up

2019-08-25 Thread Amy Kos

Hi,

quick and dirty fix could be to add 'sleep 15' to /usr/lib/apt/apt.systemd.daily

Cheers,
Amy

Bug#935716: RM: golang-1.11 -- ROM; obsolete, superseded by golang-1.12

2019-08-25 Thread Dr. Tobias Quathamer

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

please remove golang-1.11 from unstable. The successor golang-1.12 is
now the default version in unstable and testing.

The output of  "dak rm -nR golang-1.11" does not show dependency problems.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#935717: FTBFS: tests fail

2019-08-25 Thread David Bremner

Package: haskell-mode
Version: 16.1-6
Severity: serious
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

during a no-change rebuild of haskell-mode I noticed the tests are failing.

failing tests:

,
| 4 unexpected results:
|FAILED  haskell-cabal-compute-checksum-1
|FAILED  haskell-cabal-compute-next-prev-section-1
|FAILED  haskell-cabal-enum-targets-1
|FAILED  haskell-cabal-get-field-1
`

full log:

https://buildd.debian.org/status/fetch.php?pkg=haskell-mode&arch=all&ver=16.1-7&stamp=1566743946&file=log

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

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

Versions of packages haskell-mode depends on:
ii  elpa-haskell-mode  16.1-6

haskell-mode recommends no packages.

haskell-mode suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl1io0EACgkQA0U5G1Wq
FSHJAw/9FhtGmX6sgT/fR/muGtTG+zUDoslYpjsBEnrReRRJhlIwxCIYK49Hl2ew
oZbSRxo4h5Ut9alewSB5pstt6h+4xZ3+hZ/B8OaPk116BMxsed3LMUWRDZXnjUnn
JaffmLeykgMtLFi2eLyeE/L+x8VyLnUby3jFAfUM0NsHLvMy+aMlyYa1hMi3Fe1t
/xGixtXMhLA7X7/4lEYd8yOFh+6Krqh4g/UoAPogS9V6fgQeIXIgnCLWHPv074Gv
uH36OIQgjTiQChwe4GBlgEvdwrNiU9XZ4QNd9fpR2azFlz/KgDDQf1JvD7Dncecy
q1fZy1iZkbUO5BwVez84Y2lfwF+rse9GU+8O5ykFg0x4KllJJe2deNW2nRXNex8B
0g7xFCwvIlDH84Pxicl3NMyCZ30d4Mp0qZ2c15CuYhLZ5QRKzj4Q1oVQSQdFzHZv
+CNWAnGokkRnCIPCadzuJpF8U+63P2l/k/qSIkPv57obCuRhiqmGhrIq/MkSDvtw
a6ZAQIEMiMARDUkAmieG6nKGfhBVeCR0jxqUzi1F1rr5XPYFabdb5V7PzUNNRynu
3N+EOkW+3QUFbnpatN/SuZ4pXtXa8Lqg0rtbKaJ3q4/WLL+xstr5pUL7wJHyW8Fr
th2DoEN9qT5AmTPHscZxfsG23InsnDizvhKswjHqRMMPoBV7+kw=
=nxBG
-END PGP SIGNATURE-

Bug#935498: burp: missing default file

2019-08-25 Thread kalos

Tags: pending


Thank you Gian Piero for the report.

I reintroduce /etc/default/burp file (or modify sys init script) in the next 
days.

Bye! 

Il 23 agosto 2019 10:11:39 CEST, Gian Piero Carrubba  ha 
scritto:
>Package: burp
>Version: 2.2.18-2
>Severity: normal
>
>Dear Maintainer,
>
>the current burp package *does* contain a sysvinit script (as reported
>in
>the changelog for v2.2.18-2), but misses the default file that's
>referenced by the sysvinit script:
>
>$ sudo invoke-rc.d burp status 
>burp disabled; edit /etc/default/burp
>$ dpkg -l burp | grep ^ii
>ii  burp   2.2.18-2 amd64Simple cross-platform
>network BackUp and Restore Program
>$ dpkg -L burp | grep default || echo "NOT PRESENT"
>NOT PRESENT
>
>I would suggest to reintroduce the default file as it was in previous
>versions of the package:
>
>--8<--
># Defaults for burp initscript
># sourced by /etc/init.d/burp
># installed at /etc/default/burp by the maintainer scripts
>
>#
># This is a POSIX shell fragment
>#
>
>RUN=no
>
># Additional options that are passed to the Daemon.
>DAEMON_ARGS="-c /etc/burp/burp-server.conf"
>--8<--
>
>I also suggest adding a comment before the RUN= assignement along the
>line of:
># Change to RUN=yes in order to run the burp server
>
>
>Thanks,
>Gian Piero.
>
>-- System Information:
>Debian Release: bullseye/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (1, 'experimental')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.2.0-2-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 /usr/bin/dash
>Init: sysvinit (via /sbin/init)
>LSM: AppArmor: enabled
>
>Versions of packages burp depends on:
>ii  init-system-helpers  1.57
>ii  libacl1  2.2.53-4
>ii  libc62.28-10
>ii  libncurses6  6.1+20190803-1
>ii  librsync22.0.2-1
>hi  libssl1.11.1.1a-1
>ii  libtinfo66.1+20190803-1
>ii  lsb-base 11.1.0
>ii  zlib1g   1:1.2.11.dfsg-1+b1
>
>Versions of packages burp recommends:
>ii  openssl  1.1.1c-1
>
>burp suggests no packages.
>
>-- Configuration Files:
>/etc/burp/burp-server.conf [Errno 13] Permission denied:
>'/etc/burp/burp-server.conf'
>/etc/burp/burp.conf [Errno 13] Permission denied: '/etc/burp/burp.conf'
>/etc/burp/clientconfdir/incexc/example [Errno 13] Permission denied:
>'/etc/burp/clientconfdir/incexc/example'
>/etc/burp/clientconfdir/testclient [Errno 13] Permission denied:
>'/etc/burp/clientconfdir/testclient'
>
>-- no debconf information

Bug#935699: gdm3: uninstallable on s390x

2019-08-25 Thread Simon McVittie

On Sun, 25 Aug 2019 at 12:52:08 +0200, Ivo De Decker wrote:
> On s390x, gdm3 isn't installable, because it needs gnome-shell, which FTBFS
> there. So either the dependency should be dropped or the binaries for gdm3 on
> s390x should be removed.

gdm3 genuinely does require gnome-shell at runtime: its GUI is gnome-shell
running in a special mode.

We thought we had addressed this by making gdm3 build-depend on gjs, but
unfortunately mozjs60 and gjs have now been partially fixed on s390x and
work sufficiently well for their own tests to pass, but not well enough
for gnome-shell to pass *its* tests and build successfully.

Is there anything better we can do to resolve this, short of either making
gdm3 build-depend on gnome-shell (which I'm a little reluctant to do
because it isn't actually necessary at build-time and the dependency chain
is extensive), or hard-coding a list of every (release?) architecture
except s390x in gnome-shell's d/control?

I'm going to assume that making gnome-shell tests pass on s390x is not
feasible, given that there has not been any s390x porter involvement
at any point in this saga. I suspect gnome-shell has no practical use
on s390x in any case, since $15K mainframes don't tend to have a GPU
or display.

smcv

Bug#694077: Package review

2019-08-25 Thread Lisandro Damián Nicanor Pérez Meyer

Hi!

On Sun, 25 Aug 2019 at 06:22, Jérôme Lebleu  wrote:
>
> Le 24/08/2019 à 22:26, Lisandro Damián Nicanor Pérez Meyer a écrit :
> > please release it (dch -r), push it and I'll upload.
>
> It is now done and pushed, thanks in advance!
>
> I tried again to build the package and didn't have any failure this
> time. The one that didn't pass was at this line:
>
>
> https://github.com/mcallegari/qlcplus/blob/QLC+_4.12.1/engine/test/mastertimer/mastertimer_test.cpp#L197
>
> We will see if this test fails on the Debian build system too. In that
> case, we will maybe have to add DEFINES+=SKIP_TEST as it is done when
> travis is used:
>
>
> https://github.com/mcallegari/qlcplus/blob/QLC%2B_4.12.1/engine/test/mastertimer/mastertimer.pro#L18
>
> I should ask Massimo in that case since this variable name can be ambiguous.

Mmm, I'm not entirely sure if the code in plugins/hid is
DFSG-compliant. It's license it's too lax. I think I'll upload it non
the less in the meantime, and see what FTP masters think.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#694077: Package review

2019-08-25 Thread Lisandro Damián Nicanor Pérez Meyer

If you go for the patch approach add a Comment field in the copyright
file, so reviewers know what to expect-.

On Sun, 25 Aug 2019 at 12:33, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> On Sun, 25 Aug 2019 at 12:26, Lisandro Damián Nicanor Pérez Meyer
>  wrote:
> [snip]
> >
> > Mmm, I'm not entirely sure if the code in plugins/hid is
> > DFSG-compliant. It's license it's too lax. I think I'll upload it non
> > the less in the meantime, and see what FTP masters think.
>
> Better yet, I looked for previous art within Debian and found:
>
> 
>
> And more specifiically:
>
> 
>
> As you can see the license is much clearer there. This is something
> that must be solved before uploading. Ideally by fixing it upstream,
> but a patch might do the work in the meantime.
>
> Cheers, Lisandro.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#935718: RM: akonadi4 -- RoQA; Obsolete library, no longer needed now that kdepimlibs has been removed

2019-08-25 Thread Scott Kitterman

Package: ftp.debian.org
Severity: normal

Part of the Qt4 cleanup.

Scott K

Bug#694077: Package review

2019-08-25 Thread Lisandro Damián Nicanor Pérez Meyer

On Sun, 25 Aug 2019 at 12:26, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
>
> Mmm, I'm not entirely sure if the code in plugins/hid is
> DFSG-compliant. It's license it's too lax. I think I'll upload it non
> the less in the meantime, and see what FTP masters think.

Better yet, I looked for previous art within Debian and found:

And more specifiically:

As you can see the license is much clearer there. This is something
that must be solved before uploading. Ideally by fixing it upstream,
but a patch might do the work in the meantime.

Cheers, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#935253: buster-pu: package cups/2.2.10-6+deb10u1

2019-08-25 Thread Adam D. Barratt

Control: tags -1 -moreinfo +confirmed

On Wed, 2019-08-21 at 10:01 +0200, Didier 'OdyX' Raboud wrote:
> This bug is about fixing the CVE-2019-8696, CVE-2019-8675 and other
> security bugs fixed by CUPS upstream in [0] in buster.
> 
> The Security Team has declined fixing these in a security upload; so
> here I come for a Stable update. The Stretch counterpart bug is
> #935254.
> 
> The debdiff for Buster is attached. Can I (source-only) upload?
> 

Yes, please go ahead.

Regards,

Adam

Bug#935254: stretch-pu: package cups/2.2.1-8+deb9u4

2019-08-25 Thread Adam D. Barratt

Control: tags -1 +confirmed -moreinfo

On Wed, 2019-08-21 at 10:08 +0200, Didier 'OdyX' Raboud wrote:
> This bug is about fixing the CVE-2019-8696, CVE-2019-8675 and other
> security bugs fixed by CUPS upstream in [0] in stretch.
> 
> The Security Team has declined fixing these in a security upload; so
> here I come for an Oldstable update. The Buster counterpart bug is
> #935253.
> 
> The debdiff for Stretch is attached. Can I (source-only) upload?
> 

Yes, please go ahead.

Regards,

Adam

Bug#935719: buster-pu: package slirp4netns/0.2.3-1

2019-08-25 Thread Salvatore Bonaccorso

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

Hi Reinhard,

On Sun, Aug 25, 2019 at 09:33:58AM -0400, Reinhard Tartler wrote:
> Copying the debian-release mailing list, hope that's OK with everyone.

Ack, no issue with quoting the below to the release mailinglist. The
SRM though prefer for actuall proposed updates to have filled a
corresponding bug. Doing so now and full quoting below the rationale
for the no-dsa:

> On 8/24/19 6:05 AM, Moritz Mühlenhoff wrote:
> > On Sun, Aug 11, 2019 at 09:10:52PM +0200, Salvatore Bonaccorso wrote:
> >> Hi Reinhard,
> >>
> >> Apologies it took that long to come back to you in the first place.
> >>
> >> On Wed, Aug 07, 2019 at 06:13:08PM -0400, Reinhard Tartler wrote:
> >>> Hi Security Team,
> >>>
> >>> I have not received an answer to my question below. Any chance you
> >>> could get back to me on that?
> >>
> >> Unless I severely missunderstand something, slirp4netns is useful for
> >> instance for networking with unprivileged containers and it needs user
> >> namespaces to be enabled.
> >>
> >> By default those are for good reasons disabled in Debian, as well in
> >> buster.
> >>
> >> As such I would have said it would be enough to fix this issue for the
> >> upcoming point release on 7th september (so there is stil enough time
> >> to preare updates).
> >>
> >> Can we route you towards the point release for it? It would though be
> >> good to as well include as well the fix for the new CVE-2019-14378
> >> (#933742) as well. Prerequisites though that it gets accepted for
> >> stable is that the fix is as well first in unstable.
> > 
> > Agreed, enabling unprivileged user namespaces is not fully supported
> > by security support and Debian explicitly disables them by default
> > as it causes a ton of security issues in the Linux kernel (which
> > are often still fixed, but e.g. no DSAs are being released for such
> > issues).
> > 
> > As such, can you fix slirp4netns by the 10.1 buster point release?
> > 
> 
> Done, I've just uploaded 0.2.3 to buster, fixing two CVEs:
> 
> Changes:
>  slirp4netns (0.2.3-1) buster; urgency=medium
>  .
>* New upstream releases:
>  - 0.2.2: check sscanf result when emulating ident, CVE-2019-9824
>  - 0.2.3: Fixes heap overflow in included libslirp, Closes: #933742,
>CVE-2019-14378
> Checksums-Sha1:
>  459c12f439d0f2ba629d1ad5791ca49041931709 2087 slirp4netns_0.2.3-1.dsc
>  befcd9e2f1b1fbf8b51ccac4b83536e22af12003 136459 slirp4netns_0.2.3.orig.tar.gz
>  370b1cf92bf21491038fc08f9d4fa3fcba432878 3968 
> slirp4netns_0.2.3-1.debian.tar.xz

Regards,
Salvatore

Bug#935128: aspell: potentially unbounded buffer over-read in GNU Aspell 0.60.*

2019-08-25 Thread Agustin Martin

El lun., 19 ago. 2019 a las 22:36, Kevin Atkinson () escribió:
>
> On Mon, 19 Aug 2019, Salvatore Bonaccorso wrote:
>
> > See https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg0.html
>
> Also see http://aspell.net/buffer-overread-ucs.txt for a slightly improved
> version of the announcement that I edited for clarity.

Thanks for the info,

Seems we should warn  maintainers of all possibly affected packages
before uploading 0.60.7+fix. I still had no time to even try preparing
0.60.7 upload, but seems the best is to have this fix included when it
is done.

Hope to find some time next week to dig into all this and have
something ready. In case of doubt I may ask for advice.

Regards,

Bug#935721: RM: device3dfx -- ROM; unneeded, RC buggy

2019-08-25 Thread Guillem Jover

Package: ftp.debian.org
Severity: normal

Hi!

The Linux modules built from this package were needed by the glide2
libraries, which are not built anymore by the glide source package.
The glide3 libraries use DRI exclusively, so there is no point in
the old module.

In addition the module does not build anymore with recent Linux kernels,
and even though I have code upstream to make it build, it still makes no
sense to keep this in Debian.

(Both with my Debian and upstream hats.)

Thanks,
Guillem

Bug#935625: preseed: lvm commands during preseed/late_command don't finish

2019-08-25 Thread Tiger!P

On Sun, Aug 25, 2019 at 08:26:26AM +0200, Cyril Brulebois wrote:
> Hi,

Hello Cyril,

> Tiger!P  (2019-08-24):
> > When using a preseed file to install a system, it is not possible to
> > keep a part of the VG free for future use.
> 
> I'm not sure this is true:
>   
> https://salsa.debian.org/installer-team/installation-guide/commit/07d72d9a8afc201949ee116506564645e91d618f

I was not aware of this option, because it is not yet available in the
preseed file which is mentioned in appendix B.4 of the stable release
notes. Thank you for pointing it out.
I tested the option and it works as expected :-)

Even though the lvm commands still hang, you can close this bug if you
want to.

Tiger!P

Bug#935720: gle-graphics: needs manual search for libgs.so

2019-08-25 Thread Francesco Poli (wintermute)

Package: gle-graphics
Version: 4.2.5-7+b1
Severity: normal

Hello,
I am giving gle-graphics a try.

As soon as I start the GUI

  $ qgle

the program says it cannot find libgs.so: I have to manually tell it
to look at /usr/lib/x86_64-linux-gnu/libgs.so.9

I think this should fixed, so that the Debian package knows
where to find libgs.so out of the box...

Please fix this packaging bug.

Thanks for your time!
Bye.


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

Kernel: Linux 4.19.0-5-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 gle-graphics depends on:
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libgcc1 1:9.2.1-1
ii  libgl1  1.1.0-1+b1
ii  libglib2.0-02.60.6-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libncurses6 6.1+20190803-1
ii  libpng16-16 1.6.37-1
ii  libpoppler-glib80.71.0-5+b1
ii  libqt4-network  4:4.8.7+dfsg-19
ii  libqt4-opengl   4:4.8.7+dfsg-19
ii  libqtcore4  4:4.8.7+dfsg-19
ii  libqtgui4   4:4.8.7+dfsg-19
ii  libstdc++6  9.2.1-1
ii  libtiff54.0.10+git190818-1
ii  libtinfo6   6.1+20190803-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages gle-graphics recommends:
pn  gle-graphics-doc  
ii  libgs99.27~dfsg-3.1

gle-graphics suggests no packages.

-- no debconf information

Bug#872507: Config option causes segfault

2019-08-25 Thread Göran Weinholt

Marco d'Itri  writes:

> On Aug 30, Ingo Jürgensmann  wrote:
>
>> When commenting this out, ifcico is working as expected. As this is not an 
>> easy to find error, I’d like to recommend to change the default config 
>> accordingly. 
> It segfaults in the parser, but I know nothing about flex so I cannot 
> fix it.
> I suppose that something changed in flex long ago and broke this ancient 
> code.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xde4f in yylex () at lex.yy.c:813
> 813   *yy_cp = (yy_hold_char);

yy_cp is NULL because of these lines in ifcico/flagexp.y:

| #ifdef FLEX_SCANNER  /* flex requires reinitialization */
|   yy_init=1;
| #endif

In the generated flaglex.c, setting yy_init to 1 inhibits
initialization:

| static int yy_init = 0;   /* whether we need to initialize */
...
|   if ( !(yy_init) )
|   {
|   (yy_init) = 1;
...

Regards,

-- 
Göran Weinholt
https://weinholt.se/

Bug#935722: RM: libdbusmenu-qt -- RoQA; Obsolete, obsolete libs (Qt4)

2019-08-25 Thread Scott Kitterman

Package: ftp.debian.org
Severity: normal

No longer needed now that KDE4 has been removed.

Scott K

1 2 3 >

1 - 100 of 227 matches

Mail list logo