Bug#921499: ITP: ruby-blade-sauce-labs-plugin -- Blade Runner plugin for Sauce Labs (saucelabs.com)

[Pirate Praveen]

package: wnpp
severity: wishlist
owner: Pirate Praveen 

from rubygems.org/gems/blade-sauce_labs_plugin
rails 5 build depends on this package (required for building 
action_cable.js)



















signature.asc
Description: PGP signature

Bug#921450: (no subject)

[GCS]

Hi Lev and Matthias,

On Wed, Feb 6, 2019 at 8:00 AM Lev Lamberov  wrote:
> I have the same problem, I run testing + some bits from unstable on this 
> machine.
> $ env LC_ALL=C fetchmail -v -v -v  --nodetach --nosyslog -b 2
[...]
> fetchmail: POP3> DELE 1
> fetchmail: POP3< +OK Marked to be deleted.
> Segmentation fault
 It seems the POP3 deletion is the problem or related to it somehow.
Others also experienced that the mail is fetched and delivered locally
but not deleted from the POP3 server (on the next fetchmail run the
same mail fetched again) despite the 'DELE' command is received but
was not acted upon.

> I've tried to downgrade to fetchmail 6.4.0~beta4-1 (from
> snapshot.debian.org), tried to upgrade to glibc 2.28-6, tried to reboot
> with another version of Linux kernel, and the problem is still there.
 Do you mean 6.4.0~beta4-1 worked right previously?

Thanks,
Laszlo/GCS

Bug#921430: closed by Andreas Beckmann (Re: libssl1.0.2-dbgsym: Cannot install libssl1.0.2-dbgsym since packet is outdated)

[Alexander Lochmann]

Thank you for the advice!
That works.

- Alex

On 05.02.19 23:45, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the libssl1.0.2-dbgsym package:
> 
> #921430: libssl1.0.2-dbgsym: Cannot install libssl1.0.2-dbgsym since packet 
> is outdated
> 
> It has been closed by Andreas Beckmann .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Andreas Beckmann 
>  by
> replying to this email.
> 
> 

-- 
Technische Universität Dortmund
Alexander LochmannPGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16 phone:  +49.231.7556141
D-44227 Dortmund  fax:+49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al



signature.asc
Description: OpenPGP digital signature

Bug#921432: closed by Andreas Beckmann (Re: libssl1.0.2-dbgsym: Cannot install libssl1.0.2-dbgsym since packet is outdated)

[Alexander Lochmann]

Thank you for the advice!
That works.

- Alex

On 05.02.19 23:45, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the libssl1.1-dbgsym package:
> 
> #921432: libssl1.1-dbgsym: Cannot install libssl1.1-dbgsym since packet is 
> outdated
> 
> It has been closed by Andreas Beckmann .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Andreas Beckmann 
>  by
> replying to this email.
> 
> 

-- 
Technische Universität Dortmund
Alexander LochmannPGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16 phone:  +49.231.7556141
D-44227 Dortmund  fax:+49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al



signature.asc
Description: OpenPGP digital signature

Bug#921498: matrix-synapse: Login fails in version 0.34.1

[Joseph Nuthalapati]

Package: matrix-synapse
Version: 0.34.1.1-4
Severity: important

Dear maintainer,

I installed Matrix Synapse on a new amd64 Debian testing machine. I was
able to register a new account and use the application (automatically
logged in). However, if I log out of this account and try to login
again, an error is thrown.
I am using the Riot web client provided at https://riot.im/app

Error message in Riot UI:
Error: Problem communicating with the given homeserver. (M_UNKNOWN)

Error in server logs (from journald):
see attached file

A user who logs out gets permanently locked out. I didn't find any
workaround for this.

New user registrations still work though.

-- 
Regards,
Joseph Nuthalapati
Feb 06 06:48:00 ip-172-31-40-122 synapse[5913]: synapse.access.http.8008: [OPTIONS-4452] ::1 - 8008 - Received request: OPTIONS /_matrix/client/r0/login
Feb 06 06:48:00 ip-172-31-40-122 synapse[5913]: synapse.access.http.8008: [OPTIONS-4452] ::1 - 8008 - {None} Processed request: 0.002sec/0.000sec (0.002sec, 0.000sec) (0.000sec/0.000sec/0) 22B 200 "OPTIONS /_matrix/client/r0/login HTTP/1.1" "Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0" [0 dbevts]
Feb 06 06:48:00 ip-172-31-40-122 synapse[5913]: synapse.access.http.8008: [POST-4453] ::1 - 8008 - Received request: POST /_matrix/client/r0/login
Feb 06 06:48:00 ip-172-31-40-122 synapse[5913]: synapse.rest.client.v1.login: [POST-4453] Got login request with identifier: {'type': 'm.id.user', 'user': 'tester'}, medium: None, address: None, user: 'tester'
Feb 06 06:48:00 ip-172-31-40-122 synapse[5913]: synapse.metrics: [] Collecting gc 0
Feb 06 06:48:00 ip-172-31-40-122 synapse[5913]: synapse.storage._base: [] Starting db txn 'get_users_by_id_case_insensitive' from sentinel context
Feb 06 06:48:00 ip-172-31-40-122 synapse[5913]: synapse.storage._base: [] Starting db connection from sentinel context: metrics will be lost
Feb 06 06:48:00 ip-172-31-40-122 synapse[5913]: synapse.http.server: [] Failed handle request via : : Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 654, in _runCallbacks
current.result = callback(current.result, *args, **kw)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1475, in gotResult
_inlineCallbacks(r, g, status)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1416, in _inlineCallbacks
result = result.throwExceptionIntoGenerator(g)
  File "/usr/lib/python3/dist-packages/twisted/python/failure.py", line 491, in throwExceptionIntoGenerator
return g.throw(self.type, self.value, self.tb)
---  ---
  File "/usr/lib/python3/dist-packages/synapse/http/server.py", line 81, in wrapped_request_handler
yield h(self, request)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1416, in _inlineCallbacks
result = result.throwExceptionIntoGenerator(g)
  File "/usr/lib/python3/dist-packages/twisted/python/failure.py", line 491, in throwExceptionIntoGenerator
return g.throw(self.type, self.value, self.tb)
  File "/usr/lib/python3/dist-packages/synapse/http/server.py", line 316, in _async_render
callback_return = yield callback(request, **kwargs)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1416, in _inlineCallbacks
result = result.throwExceptionIntoGenerator(g)
  File "/usr/lib/python3/dist-packages/twisted/python/failure.py", line 491, in throwExceptionIntoGenerator
return g.throw(self.type, self.value, self.tb)
  File "/usr/lib/python3/dist-packages/synapse/rest/client/v1/login.py", line 140, in on_POST
result = yield self._do_other_login(login_submission)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1416, in _inlineCallbacks
result = result.th

Bug#921450: (no subject)

[Lev Lamberov]

Hi,

I have the same problem, I run testing + some bits from unstable on this 
machine.

$ env LC_ALL=C fetchmail -v -v -v  --nodetach --nosyslog -b 2
Old UID list from mail.riseup.net:
 

Scratch list of UIDs:
 

fetchmail: removing stale lockfile
fetchmail: 6.4.0.beta4 querying mail.riseup.net (protocol POP3) at Wed Feb  6 
11:42:01 2019: poll started
Trying to connect to 198.252.153.22/110...connected.
fetchmail: POP3< +OK howdy, ready.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< STLS
fetchmail: POP3< SASL
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation now.
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: COMODO CA Limited
fetchmail: Issuer CommonName: COMODO RSA Certification Authority
fetchmail: Subject CommonName: COMODO RSA Certification Authority
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: COMODO CA Limited
fetchmail: Issuer CommonName: COMODO RSA Certification Authority
fetchmail: Subject CommonName: COMODO RSA Domain Validation Secure Server CA
fetchmail: Server certificate:
fetchmail: Issuer Organization: COMODO CA Limited
fetchmail: Issuer CommonName: COMODO RSA Domain Validation Secure Server CA
fetchmail: Subject CommonName: *.riseup.net
fetchmail: Subject Alternative Name: *.riseup.net
fetchmail: Subject Alternative Name: riseup.net
fetchmail: mail.riseup.net key fingerprint: 
A6:13:14:09:4D:61:97:D9:D0:A1:E1:C7:2D:F4:4E:6E
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES128-GCM-SHA256, 
128/128 secret/processed bits
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: mail.riseup.net: upgrade to TLS succeeded.
fetchmail: POP3> USER dogsleg
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Logged in.
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 29 272396
29 messages for dogsleg at mail.riseup.net (272396 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 6319
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 6319 octets
reading message dogs...@mail.riseup.net:1 of 29 (6319 octets) About to rewrite 
Return-Path: ...
...rewritten version is Return-Path: 
.
About to rewrite From: Paul Wise ...
...rewritten version is From: Paul Wise .
About to rewrite To: debian-de...@lists.debian.org...
...rewritten version is To: debian-de...@lists.debian.org.
About to rewrite Resent-From: debian-de...@lists.debian.org...
...rewritten version is Resent-From: debian-de...@lists.debian.org.
About to rewrite Resent-Sender: debian-devel-requ...@lists.debian.org...
...rewritten version is Resent-Sender: debian-devel-requ...@lists.debian.org.

Trying to connect to ::1/25...connection failed.
fetchmail: connection to localhost:smtp [::1/25] failed: Connection refused.
Trying to connect to 127.0.0.1/25...connected.
fetchmail: SMTP< 220 urfu-thinkpad ESMTP Exim 4.92-RC5 Wed, 06 Feb 2019 
11:42:05 +0500
fetchmail: SMTP> EHLO mail.riseup.net
fetchmail: SMTP< 250-urfu-thinkpad Hello mail.riseup.net [127.0.0.1]
fetchmail: SMTP< 250-SIZE 52428800
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-CHUNKING
fetchmail: SMTP< 250-PRDR
fetchmail: SMTP< 250 HELP
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL 
FROM: BODY=8BITMIME 
SIZE=6319
fetchmail: SMTP< 250 OK
fetchmail: SMTP> RCPT TO:
fetchmail: SMTP< 250 Accepted
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself
#**
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 OK id=1grGuL-0002s8-Oa
 flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK Marked to be deleted.
Segmentation fault

I've tried to downgrade to fetchmail 6.4.0~beta4-1 (from
snapshot.debian.org), tried to upgrade to glibc 2.28-6, tried to reboot
with another version of Linux kernel, and the problem is still there.

Since the problem is a recent one, I've tried to investigate, which
packages were upgraded on my machine recently:

$ which-pkg-broke fetchmail
perl-base  Tue Feb  5 11:20:26 2019
libdb5.3:amd64 Wed Feb  6 11:02:03 2019
libc6:amd64Wed Feb  6 11:20:43 2019
fetchmail  Wed Feb  6 11:41:49 2019

Changes in libc6 reflect my attempts to upgrade to glibc 2.28-6 and
changes in fetchmail reflect my attempts to downgrade (which I mentioned
before).

With regards,
Lev Lamberov

Bug#921497: ITP: swaylock -- Screen locker for Wayland

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: swaylock
  Version : 1.3
  Upstream Author : Drew DeVault 
* URL : https://github.com/swaywm/swaylock
* License : MIT
  Programming Lang: C
  Description : Screen locker for Wayland

swaylock is a screen locking utility for Wayland compositors. It is
compatible with any Wayland compositor which implements the following
Wayland protocols:
* wlr-layer-shell
* wlr-input-inhibitor
* xdg-output
* xdg-shell

Bug#921496: ITP: swayidle -- Idle management daemon for Wayland

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: swayidle
  Version : 1.2
  Upstream Author : Drew DeVault 
* URL : https://github.com/swaywm/swayidle
* License : MIT
  Programming Lang: C
  Description : Idle management daemon for Wayland

This is sway's idle management daemon, swayidle. It is compatible with
any Wayland compositor which implements the KDE idle protocol. See the
man page, swayidle(1), for instructions on configuring swayidle.

Bug#921495: libbio-perl-perl: Package not upgradable, file conflicts.

[Nicolas Patrois]

Package: libbio-perl-perl
Version: 1.7.2-3
Severity: normal

Dear Maintainer,

The package can’t be upgraded because one of its files
(/usr/share/man/man3/Bio::Tools::Run::Analysis.3pm.gz) conflicts with libbio-
perl-run-perl.



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

Kernel: Linux 4.17.0-3-686-pae (SMP w/3 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libbio-perl-perl depends on:
ii  libdata-stag-perl  0.14-2
ii  libio-string-perl  1.08-3
ii  perl   5.28.1-4

Versions of packages libbio-perl-perl recommends:
ii  libace-perl 1.92-8+b1
ii  libalgorithm-munkres-perl   0.08-3
pn  libarray-compare-perl   
ii  libbio-asn1-entrezgene-perl 1.720-2
ii  libbio-perl-run-perl1.7.2-4
ii  libclone-perl   0.41-1+b1
ii  libconvert-binary-c-perl0.78-1+b4
pn  libdbd-mysql-perl   
pn  libdbd-pg-perl  
pn  libdbd-sqlite3-perl 
pn  libgd-perl  
ii  libgraph-perl   1:0.9704-1
ii  libgraphviz-perl2.22-1
ii  libhtml-parser-perl 3.72-3+b3
ii  libhtml-tableextract-perl   2.15-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  libpostscript-perl  0.06-3
ii  libset-scalar-perl  1.29-2
ii  libsoap-lite-perl   1.27-1
ii  libsort-naturally-perl  1.03-2
ii  libspreadsheet-parseexcel-perl  0.6500-1
ii  libspreadsheet-writeexcel-perl  2.40-1
pn  libstorable-perl
pn  libsvg-graph-perl   
ii  libsvg-perl 2.84-1
ii  liburi-perl 1.76-1
ii  libwww-perl 6.36-1
ii  libxml-dom-xpath-perl   0.14-3
ii  libxml-libxml-perl  2.0133+dfsg-1
ii  libxml-parser-perl  2.44-2+b4
ii  libxml-sax-perl 1.00+dfsg-1
ii  libxml-sax-writer-perl  0.57-1
ii  libxml-simple-perl  2.25-1
ii  libxml-twig-perl1:3.50-1
ii  libxml-writer-perl  0.625-1

Versions of packages libbio-perl-perl suggests:
pn  bioperl  
pn  libxml-sax-expatxs-perl  

-- no debconf information

Bug#821397: sway 1.0-rc1

[Birger Schacht]

Hi!

On 2/6/19 1:11 AM, Sean Whitton wrote:
> Hello,
> 
> On Tue 05 Feb 2019 at 05:09PM -07, Sean Whitton wrote:
> 
>> There is a new release of sway out, and it moves swayidle and swaylock
>> into separate source packages.
>>
>> Those are all going to have to pass through NEW.  Do you have time to
>> prepare separate source packages for all these?  We might as well do it
>> now rather than later.
> 
> What I mean is: we might as well put the three separate sway source
> packages in NEW now, rather than wait for 1.0~beta.2 to pass through
> NEW, and then moving the binary packages between source packages.  But
> only if you have time!

Yes! I've already started working on this, but sway now needs wlroots
0.3 and that not in the archive yet (i've ask Guido about it, but didn't
get an answer yet).
But both swayidle and swaylock don't depend on wlroots, so i can start
with those.

cheers,
Birger



signature.asc
Description: OpenPGP digital signature

Bug#921488: [debian-mysql] Bug#921488: libmariadb3: OpenSSL license contamination of GPL reverse-dependencies

[Steve Langasek]

On Wed, Feb 06, 2019 at 07:21:46AM +0200, Otto Kekäläinen wrote:
> The OpenSSL licence will change from 3.0.0 onwards
> (https://www.openssl.org/source/license.html) but you are right that
> for version 1.1.1 the SSLeay clause applies. MySQL and MariaDB has the
> OpenSSL exception, and YaSSL has been used due to earlier
> interpretation by non-maintainers that it might be needed, but
> currently I think using OpenSSL is the right thing to use, just like
> upstream MariaDB uses as well.

How does your statement that you think it is "the right thing to use" help
the maintainers of the various packages in the archive that are not
violating the GPL?  What action do you expect them to take for the buster
release?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#921494: pypy3: ImportError: No module named '_lzma_cffi'

[Helmut Grohne]

Package: pypy3
Version: 6.0.0+dfsg-2

Consider the following pypy3 interaction:

| $ pypy3
| Python 3.5.3 (6.0.0+dfsg-2, Jan 31 2019, 18:16:16)
| [PyPy 6.0.0 with GCC 8.2.0] on linux
| Type "help", "copyright", "credits" or "license" for more information.
|  import lzma
| Traceback (most recent call last):
|   File "", line 1, in 
|   File "/usr/lib/pypy3/lib-python/3/lzma.py", line 26, in 
| from _lzma import *
|   File "/usr/lib/pypy3/lib_pypy/_lzma.py", line 15, in 
| from _lzma_cffi import ffi, lib as m
| ImportError: No module named '_lzma_cffi'
| 

pypy upstream does have support for lzma, but the relevant cffi module
is not built by the Debian package as can be seen in a build log:

https://buildd.debian.org/status/fetch.php?pkg=pypy3&arch=amd64&ver=6.0.0%2Bdfsg-2&stamp=1548970515&raw=0

| stderr:
| _lzma_cffi.c:496:10: fatal error: lzma.h: No such file or directory
|  #include 
|   ^~~~
| compilation terminated.
| Traceback (most recent call last):
|   File 
"/<>/pypy3-6.0.0+dfsg/lib-python/3/distutils/unixccompiler.py", line 
133, in _compile
| extra_postargs)
|   File "/<>/pypy3-6.0.0+dfsg/lib-python/3/distutils/ccompiler.py", 
line 909, in spawn
| spawn(cmd, dry_run=self.dry_run)
|   File "/<>/pypy3-6.0.0+dfsg/lib-python/3/distutils/spawn.py", line 
36, in spawn
| _spawn_posix(cmd, search_path, dry_run=dry_run)
|   File "/<>/pypy3-6.0.0+dfsg/lib-python/3/distutils/spawn.py", line 
159, in _spawn_posix
| % (cmd, exit_status))
| distutils.errors.DistutilsExecError: command 'cc' failed with exit status 1

I guess fixing this is a matter of adding liblzma-dev (which ships
lzma.h) to Build-Depends.

Helmut

Bug#921493: RFP: node-ava -- ava helps with testing

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-ava
  Version : 1.2.1
  Upstream Author : Mark Wubben (novemberborn.net)
* URL : https://notabug.org/makenotabuggreatagain/ava
* License : MIT
  Programming Lang: javascript
  Description : ava helps with testing

AVA is a test runner for Node.js with a concise API, detailed error
output, embrace of new language features and process isolation that
let you write tests more effectively.

AVA is a prerequisite for node-gulp-debug ( #915067 )

Bug#921492: ledger: please upgrade to new upstream release 3.1.2

[Sampo Sorsa]

Package: ledger
Version: 3.1.2~pre1+g3a00e1c+dfsg1-2+b1

Dear Maintainer,

Upstream has release 3.1.2 just now:

https://github.com/ledger/ledger/releases/tag/3.1.2

This fixes many issues, and upgrading would close at least Debian bugs #839634, 
#870900 and #913660.

Would be really nice if this release made it into Buster.

--
Sampo Sorsa

Bug#921475: stretch-pu: package postfix/3.1.9-0+deb9u1

[Scott Kitterman]

On Wed, 06 Feb 2019 05:59:37 + "Adam D. Barratt"  wrote:
> Control: tags -1 + confirmed
...
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Uploaded.  Thanks,

Scott K

Bug#921475: stretch-pu: package postfix/3.1.9-0+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-02-05 at 18:09 -0500, Scott Kitterman wrote:
> This update covers two types of changes:
> 
>  - Bug fixes released by upstream in postfix 3.1.9.  As has been the
> case in previous micro-releases the fixes are compact, low risk, and
> backed by postfix's upstream QA.  The release has been out upstream
> with no noted regressions (this is another one I haven't had time to
> package yet, but it deals with other issues, no regressions from
> 3.1.9).  Additionally, I've been running this release in production
> on one of my servers for two months with no problems.
> 
>  - Packaging fixes related to the systemd generator.  This has been a
> long-standing problem which affects certain configurations very
> significnatly.

Please go ahead.

Regards,

Adam

Bug#919766: FTBFS-es

[Balint Reczey]

Hi Barak,

On Thu, Jan 31, 2019 at 2:54 AM Barak A. Pearlmutter
 wrote:
>
> Thanks, that was very kind of you. Much appreciated. I'm in the
> process of preparing to upload.
> But next time feel free to just NMU, 0 day, tell me after, I totally don't 
> mind!
> (This goes for any of my packages.)

Thanks!

I see you have already closed the changelog in git just did not
upload. If you hold back the upload because of the current doxygen
breakage [1], then please just do a source-only upload and let it be
built when the broken build-dependencies are fixed.

[1] https://lists.debian.org/debian-science/2019/02/msg6.html

Cheers,
Balint

>
> Cheers,
>
> --Barak.



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#921488: [debian-mysql] Bug#921488: libmariadb3: OpenSSL license contamination of GPL reverse-dependencies

[Otto Kekäläinen]

Hello!

The OpenSSL licence will change from 3.0.0 onwards
(https://www.openssl.org/source/license.html) but you are right that
for version 1.1.1 the SSLeay clause applies. MySQL and MariaDB has the
OpenSSL exception, and YaSSL has been used due to earlier
interpretation by non-maintainers that it might be needed, but
currently I think using OpenSSL is the right thing to use, just like
upstream MariaDB uses as well.

Bug#921491: debirf: Broken on usr merged systems

[Herve Werner]

Package: debirf
Version: 0.38
Severity: important
Tags: patch

Dear Maintainer,

Since usr merge, Debirf no longer works properly.

The issue lays in the install-kernel script :
debirf_exec dpkg --extract /var/cache/apt/archives/"$KPKG" /

This line installs the kernel by extracting it inside the chroot environment.
For some reason, a classic dpkg install can't be done here.

The package linux-image-4.19.0-1-amd64 embeds directory trees and unfortunately
dpkg --extract overwrite the existing /lib symlink in the chroot with its
directory tree. In that state the system is then completely unusable.

>From reading the source code of dpkg it seems that this way of extracting the
inner tar archive embeded in the package is not configurable.

So as a workaround, we can extract the files ourselves and specify the option
--keep-directory-symlink in the tar command :
-debirf_exec dpkg -i /var/cache/apt/archives/"$KPKG"
+debirf_exec apt-get install -y binutils xz-utils
+debirf_exec ar x /var/cache/apt/archives/"$KPKG" data.tar.xz
+debirf_exec tar -x --keep-directory-symlink -f data.tar.xz
+debirf_exec rm -f data.tar.xz



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

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

Versions of packages debirf depends on:
ii  apt  1.8.0~beta1
ii  cpio 2.12+dfsg-6
ii  debootstrap  1.0.114
ii  fakechroot   2.19-3.2
ii  fakeroot 1.23-1
ii  klibc-utils  2.0.4-15
ii  xz-utils 5.2.2-1.3

Versions of packages debirf recommends:
ii  grub-common  2.02+dfsg1-10
ii  lsb-release  10.2018112800
ii  xorriso  1.5.0-1

Versions of packages debirf suggests:
pn  syslinux-common  

-- no debconf information

Bug#921490: gnome-shell: CVE-2019-3820

[Salvatore Bonaccorso]

Source: gnome-shell
Version: 3.30.2-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/gnome-shell/issues/851

Hi,

The following vulnerability was published for gnome-shell.

CVE-2019-3820[0]:
partial lock screen bypass

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-3820
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3820
[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/851

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#921489: mplayer: OSD and subtitles almost unreadable on at least x11, fbdev and fbdev2 video outputs

[Yui Hirasawa]

Package: mplayer
Version: 2:1.3.0-8+b4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Updated from Debian Jessie to Debian Buster.

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

I played a video file with subtitles. I toggled internal setting such as 
audio and subtitle track.


   * What was the outcome of this action?

Both the subtitles and the OSD that displays track changes were almost 
unreadable.

Screenshot available at: https://gnu.moe/fb.png

   * What outcome did you expect instead?

I expected clear text like before.

As you probably know, mplayer has quite a lot of dependencies. On irc 
people instructed me to use `which-pkg-broke` but that proved quite 
useless since it lists 261 packages as the possible cause.


Before I though this problem was only on experimental since that's what 
some of my other machines are running but I just now made a completely 
clean netinst on this machine without any desktop.

After the install I installed mplayer.
I tested a video file with subtitles and the subtitles worked fine.
Next I updated to Buster (testing).
I tested the same file as before but this time the subtitles looked like 
in the screenshot I linked earlier.


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 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)

Versions of packages mplayer depends on:
ii  liba52-0.7.4  0.7.4-19
ii  libaa1    1.4p5-45
ii  libasound2    1.1.7-2
ii  libass9   1:0.14.0-2
ii  libaudio2 1.9.4-6
ii  libavcodec58  7:4.1-1
ii  libavformat58 7:4.1-1
ii  libavutil56   7:4.1-1
ii  libbluray2    1:1.0.2-3
ii  libbs2b0  3.1.0+dfsg-2.2
ii  libc6 2.28-5
ii  libcaca0  0.99.beta19-2+b3
ii  libcdio-cdda2 10.2+0.94+2-4
ii  libcdio-paranoia2 10.2+0.94+2-4
ii  libcdio18 2.0.0-2
ii  libdca0   0.0.6-1
ii  libdirectfb-1.7-7 1.7.7-8
ii  libdv4    1.0.0-12
ii  libdvdnav4    6.0.0-1
ii  libdvdread4   6.0.0-1
ii  libenca0  1.19-1+b1
ii  libfaad2  2.8.8-1
ii  libfontconfig1    2.13.1-2
ii  libfreetype6  2.9.1-3
ii  libfribidi0   1.0.5-3.1
ii  libgif7   5.1.4-3
ii  libgl1    1.1.0-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblirc-client0   0.10.1-5
ii  libmad0   0.15.1b-9
ii  libmpeg2-4    0.5.1-8
ii  libmpg123-0   1.25.10-2
ii  libogg0   1.3.2-1+b1
ii  libopenal1    1:1.19.1-1
ii  libpng16-16   1.6.36-2
ii  libpostproc55 7:4.1-1
ii  libpulse0 12.2-3
ii  libsdl1.2debian   1.2.15+dfsg2-4
ii  libsmbclient  2:4.9.4+dfsg-2
ii  libspeex1 1.2~rc1.2-1+b2
ii  libswresample3    7:4.1-1
ii  libswscale5   7:4.1-1
ii  libtheora0    1.1.1+dfsg.1-14+b1
ii  libtinfo6 6.1+20181013-1
ii  libvdpau1 1.1.1-10
ii  libvorbisidec1    1.2.1+git20180316-2
ii  libx11-6  2:1.6.7-1
ii  libx264-155   2:0.155.2917+git0a84d98-2
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-1
ii  libxss1   1:1.2.3-1
ii  libxv1    2:1.0.11-1
ii  libxvidcore4  2:1.3.5-1
ii  libxvmc1  2:1.0.10-1
ii  libxxf86dga1  2:1.1.4-1+b3
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g    1:1.2.11.dfsg-1

mplayer recommends no packages.

Versions of packages mplayer suggests:
ii  bzip2   1.0.6-9
ii  fontconfig  2.13.1-2
pn  fonts-freefont-ttf  
pn  mplayer-doc 
pn  netselect | fping   

-- no debconf information

Bug#921423: /var/log/letsencrypt gets wiped on transitional package purge

[Harlan Lieberman-Berg]

On Tue, Feb 5, 2019 at 10:57 PM Mattia Rizzolo  wrote:
> Sure, of course that's the cause, but your suggested fix would instead
> introduce the other bug that "purge does not delete related logs", which
> is what everybody is expecting "purge" to do.

Hi Mattia,

The bug here is that the transitional dummy package purges the
directory that the main package which provides it uses.  Both certbot
and letsencrypt use `/var/log/letsencrypt` for their log storage, but
the letsencrypt package has been hollowed out and made into a dummy.
The directory will still be deleted if you purge certbot, which is the
new and correct owner of that path.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#921488: libmariadb3: OpenSSL license contamination of GPL reverse-dependencies

[Steve Langasek]

Package: libmariadb3
Version: 1:10.3.12-2
Severity: serious
Affects: w1retap
Justification: renders many Debian packages undistributable

Hello,

It's come to my attention that in buster and unstable, packages which
build-depend on default-libmysqlclient-dev wind up linked against
libmariadb3, which in turn links against OpenSSL (libssl1.1).

This includes software which is licensed under the GPL and uses the MySQL
APIs.  (Example: w1retap)

It is well understood that the OpenSSL license is not "compatible" with the
GPL (either version 2 or 3); and furthermore, Debian has long taken the
position that, unless a license exception is granted by the copyright
holders, a package which is distributed under the GPL must only link to
libraries whose licenses are also GPL-compatible in order for it to be
included in Debian.

There is bug #787118 requesting that mariadb-server use OpenSSL instead of
YaSSL; this bug is still open in the BTS despite the fact that mariadb does
now link against OpenSSL.  This bug also acknowledges the need for a license
exception for MariaDB itself to ship linked against OpenSSL, but the license
compatibility problem for reverse-dependencies of the client library seems
to have been overlooked.

I cannot find any discussion of the switch from yassl to openssl in the
mariadb-10.3 changelog, so as near as I can see, there has been no explicit
consideration of the licensing implications.

I am opening this as a serious bug, since I believe this makes a large and
indeterminate number of packages non-distributable in buster.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#921487: fonts-dkg-handwriting: please add GARLIC (U+1F9C4) glyph

[Clint Adams]

Package: fonts-dkg-handwriting
Version: 0.16-2
Severity: wishlist

Unicode 12.0 was released today.

Bug#921229: the df* plugins don't respect [df*] anymore

[Lars Kruse]

Hello Mattia,


thank you for your report!

Could it be, that your plugin configuration files contain a section "df"?
In this case the more specific section ("df") would take precedence over the
wildcard section ("df*").

Or maybe another theory: the wildcards are currently applied a bit loosely:
 https://github.com/munin-monitoring/munin/issues/1158
Maybe this could be related?

Cheers,
Lars

Bug#921486: ruby-adsf: make test suite compatible with $http_proxy

[Steve Langasek]

Package: ruby-adsf
Version: 1.4.1+dfsg1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hi Cédric,

The ruby-asdf autopkgtests have been failing in Ubuntu despite passing in
Debian, with the following error:

[...]
  1) Failure:
Adsf::Test::Server#test_non_local_interfaces [/tmp/autopkgtest.Y5x1aO/build.RK7/
src/adsf/test/test_server.rb:115]:
[Errno::ECONNREFUSED] exception expected, not
Class: 
Message: <"Net::ReadTimeout">
---Backtrace---
[...]

  (http://autopkgtest.ubuntu.com/packages/r/ruby-adsf/disco/amd64)

This error occurs because the Ubuntu autopkgtest runners have an http proxy
configured for Internet access, which cannot be used to access the runner's
own local addresses; so an http_proxy-aware function that tries to connect
to a local port fails as a result.

The attached patch allows the ruby-adsf tests to succeed in Ubuntu.  Would
you consider applying this change in Debian?

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ruby-adsf-1.4.1+dfsg1/debian/patches/proxy-safe-tests.patch 
ruby-adsf-1.4.1+dfsg1/debian/patches/proxy-safe-tests.patch
--- ruby-adsf-1.4.1+dfsg1/debian/patches/proxy-safe-tests.patch 1969-12-31 
16:00:00.0 -0800
+++ ruby-adsf-1.4.1+dfsg1/debian/patches/proxy-safe-tests.patch 2019-02-05 
17:20:15.0 -0800
@@ -0,0 +1,19 @@
+Description: fix test suite to work when a proxy environment is configured
+ If http_proxy is set in the environment, test_non_local_interfaces fails
+ because it tries to connect via the proxy when it should be connecting to
+ a local server instead.  Simply remove this setting from the environment to
+ let the test pass.
+Author: Steve Langasek 
+
+Index: ruby-adsf-1.4.1+dfsg1/adsf/test/test_server.rb
+===
+--- ruby-adsf-1.4.1+dfsg1.orig/adsf/test/test_server.rb
 ruby-adsf-1.4.1+dfsg1/adsf/test/test_server.rb
+@@ -104,6 +104,7 @@
+   end
+ 
+   def test_non_local_interfaces
++ENV.delete('http_proxy')
+ addresses = 
Socket.getifaddrs.map(&:addr).select(&:ipv4?).map(&:ip_address)
+ non_local_addresses = addresses - ['127.0.0.1']
+ 
diff -Nru ruby-adsf-1.4.1+dfsg1/debian/patches/series 
ruby-adsf-1.4.1+dfsg1/debian/patches/series
--- ruby-adsf-1.4.1+dfsg1/debian/patches/series 2019-01-05 15:26:03.0 
-0800
+++ ruby-adsf-1.4.1+dfsg1/debian/patches/series 2019-02-05 17:18:14.0 
-0800
@@ -1,3 +1,4 @@
 clean_test_helper.patch
 no_faye_websocket.patch
 disable_tests.patch
+proxy-safe-tests.patch

Bug#921423: /var/log/letsencrypt gets wiped on transitional package purge

[Mattia Rizzolo]

On Tue, Feb 05, 2019 at 10:42:25AM +, Robie Basak wrote:
> Expected: logs still exist back to the beginning, or at least since step
> 4.
> 
> Actual: logs are gone.
> 
> Real use case: users upgrading through the regular upgrade path will,
> upon purging old transitional packages, lose their logs.

Well, purging by definition would go about deleting such things.
At most, you'd be expecting to see the stuff coming from after step 4,
but everything before should be deleted by the definition of "purge".

> Suspected cause: letsencrypt.postrm removes /var/log/letsencrypt.
> 
> Suggested fix: drop the "rm -rf /var/log/letsencrypt" from
> letsencrypt.postrm (which makes the postrm redundant so the entire file
> can be removed).

Sure, of course that's the cause, but your suggested fix would instead
introduce the other bug that "purge does not delete related logs", which
is what everybody is expecting "purge" to do.

-- 
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#921464: ITP: gnome-books -- ebook reader for GNOME

[Jeremy Bicha]

On Tue, Feb 5, 2019 at 8:14 PM eamanu15  wrote:
> I see that on debian/copyright file there is not a
> license section for debian/* files and you (or GNOME team)
> are not there.

My gnome-books packaging has the same copyright and license as the
rest of gnome-books.

In other words, debian/* is part of the Files: * section in debian/copyright.

Thanks,
Jeremy Bicha

Bug#921485: RFP: python-srht-git -- sr.ht git services

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist

* Package name : python-srht-git
Version : 0.22.2
Upstream Author : Drew DeVault (@s...@cmpwn.com)
* URL : https://git.sr.ht/~sircmpwn/git.sr.ht
* License : Affero GPLv3
Programming Lang: python
Description : sr.ht git services

This is the git component of sr.ht

git is a distributed source version control system, and the
client is available in debian already. What this is, is
a web server that allows for git collaboration in large
groups - ie free software development using the web and
git together

This along with the core sr.ht module ( #920873 ), and the
scm sr.ht module ( #921407 ) form the back end code for the
website sr.ht; called "a github replacement for hackers by
hackers"

Bug#921331: [signing-party] gpglist: a bug politely introduces itself and demands to be reported

[Guilhem Moulin]

Control: retitle -1 gpglist chokes on direct-key signatures
Control: tag -1 pending

Hi Giovanni,

On Mon, 04 Feb 2019 at 11:16:32 +0100, Giovanni Mascellani wrote:
> I am sorry I am not able to provide further information, because I
> have no idea what gpglist is not liking about my key.

It doesn't like the direct-keys signatures you have at the begining of
your key (type 0x1F, cf. RFC 4880 sec. 5.2.1), before the first UID:

$ gpg --list-options no-show-uid-validity --list-sigs 
82D119A840C6EFCA6F5AF9459EDCC991D9AB457E | head -n 7
pub   rsa4096 2010-02-24 [SC] [expires: 2020-04-22]
  82D119A840C6EFCA6F5AF9459EDCC991D9AB457E
sigR 9EDCC991D9AB457E 2010-02-24  Giovanni Mascellani 

sigR 9EDCC991D9AB457E 2010-02-24  Giovanni Mascellani 

sigR 9EDCC991D9AB457E 2010-02-24  Giovanni Mascellani 

sigR 9EDCC991D9AB457E 2010-02-24  Giovanni Mascellani 

uid  Giovanni Mascellani 

> Also, I would really like to use gpglist on my key! :-)

The attached patch should fix this. :-)

Cheers,
-- 
Guilhem.
gpglist: Don't choke on direct-key signatures (type 0x1F).

Closes: #921331.

--- a/gpglist
+++ b/gpglist
@@ -128,9 +128,10 @@ while (<$SIGS>) {
 		push @uids, $uid; # preserve the order
 		$uids{$uid} = $2;
 	}
-	elsif (/^sig:(?:[^:]*:){3}([0-9A-F]{16}):(\d+):(\d*):(?:[^:]*:){2}([^:]+):(1[0-3][lx])(?::.*)?$/) {
+	elsif (/^sig:(?:[^:]*:){3}([0-9A-F]{16}):(\d+):(\d*):(?:[^:]*:){2}([^:]+):(1[0-3fF])[lx](?::.*)?$/) {
 		$id = $1;
 		next if $3 ne '' and $3 < $now; # expired
+		next if lc $5 eq '1f'; # direct-key signature
 		$ids{$id} = $4;
 		# keep only the most recent sig (a more recent sig might appear anywhere in the list)
 		$sigs{$id}->{$uid} = $2 unless defined $sigs{$id}->{$uid} and


signature.asc
Description: PGP signature

Bug#888266: stterm: Space between letters when using GNU Unifont

[Nils Dagsson Moskopp]

Paride Legovini  writes:

> On Wed, 24 Jan 2018 14:22:24 +0100 Nils Dagsson Moskopp
>  wrote:> when starting
> stterm with GNU Unifont, with “stterm -f unifont”, the
>> letter spacing is much too wide. This makes this terminal unpleasant
>> to read. Also the terminal window became unusually wide due to this.
>
> Hello Nils,
>
> I can't reproduce the issue with stterm 0.8.1-1. Could you please give
> it a try and confirm it's fixed?

I did try st downloaded from https://dl.suckless.org/st/st-0.8.1.tar.gz
sha256 c4fb0fe2b8d2d3bd5e72763e80a8ae05b7d44dbac8f8e3bb18ef0161c7266926

As far as I can tell, the bug seems to be fixed in that stterm version.

Greetings,
Nils

Bug#916298: steam: should depend on steam-devices

[Michael Gilbert]

On Mon, Feb 4, 2019 at 3:03 AM Simon McVittie wrote:
> This was reduced from Depends to Recommends in 1.0.0.59-4. Michael:
> why this change?

Recommends are installed by default by apt, so most users will get it
installed automatically, but this also supports users that don't need
or want it.  You could even consider it from a policy perspective,
steam-devices is not required for the steam package to be functional.

Best wishes,
Mike

Bug#921484: Origin of background.js and manifest.json not documented?

[Vincent Bernat]

Package: webext-browserpass
Version: 2.0.22-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

I am curious to know why there is a debian/background.js as well as a
debian/manifest.json? They are not documented in debian/copyright. The
manifest seems to have a bogus version numbre (2.1.19 instead of
2.0.22) and is different from the manifest shipped in
{firefox/chrome}/manifest.json. The background.js is also different
(fillLoginForm doesn't have the right signature for example).

Thanks.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages webext-browserpass depends on:
ii  libc6  2.28-5

Versions of packages webext-browserpass recommends:
ii  chromium  72.0.3626.81-1
ii  firefox   65.0-1

webext-browserpass suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlxaN5kSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5hMsP/0Z/JrWfOJLZzSy5/0QIzJYlzkhtcpsI
iehpCZuAoMn5vkmthZT7drdUUclHGKk6QHhnpWRi0nk2d5CF7wFhKdn7VUx32oKD
h0rIxDA+8O17SqZxNNBcykiKbODVpRqIu3L04BqrlVnNMIJotyQmf+ddAq41Bast
IXL0tENdNNOXtuUXAaU6//wBvKChe0Mnq4L5m084Jj8do+enDELiMO9Eu3/fs/EL
nOdOrltMS+6UAik4K3cA/8l/ZX5wsYJbQTmrFizkyNNqWRnx83imbPHmPsMhPsAA
M4LL5XMsMNEeY0VYyQHgtONkb0J8XMGO2hOODvx5xhoEx71PA+/NgP/IN2XDbUaz
8SXc5UIoR/ATHreN05DyG55eiQGMJo8AdQmAsyJdULn7vMLU00HawutMW62M324+
gyJY00h+9ZB6lP8crNtR2a4rR/tHxQef4zhNC0zuJqMEV0LDltefqOas9PAVPBzB
T0k2jPlbmGqX60aqCQYKL+LYEZd2ZZnAdEDIeqXiQ2kpEabLYaQDoUpepDiVXYpj
Sr3xXYFYDvUVylbEdqAqR5nQ6t8xHVwcriq9JkaXFqJfUj1W80dMLd/bhrd/E5dP
xgx8j0jJuLf2jX/KT5VNUymWyCLPpEvZHm/0NDiJmnQ9TigtIJrZx8tt5e7HvzxU
Wb2keYQ6r02I
=8GJn
-END PGP SIGNATURE-

Bug#921464: ITP: gnome-books -- ebook reader for GNOME

[eamanu15]

Hi!



> My gnome-books packaging has the same copyright and license as the
> rest of gnome-books.
>
> In other words, debian/* is part of the Files: * section in
> debian/copyright.
>

yes! I suppose that but I want to be sure.

Thanks!
Regards


> Thanks,
> Jeremy Bicha
>


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

Bug#921470: A short summary of the changes

[Oliver Kurth]

A short summary of the changes:

- Attempt to notify the host that a backup manifest is available on every 
completed snapshot. Previously vmtoolsd attempted to detect whether the host 
was running an older version of ESX that did not support receiving a backup 
manifest, which occasionally resulted in it erroneously identifying a host as 
an older host.
- Provide more informative logging messages when a backup manifest notification 
is refused by the host.
- Abort quiesced snapshot operations promptly after detecting that the host has 
aborted its side of the operation. Previously vmtools would continue until it 
hit its own internal timeout.
- Don’t try to notify the host that a backup manifest is available when the 
quiesced snapshot is aborted.

We suggest to have these changes integrated into the 10.3.5 package.

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

> Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
>  escreveu:
> >
> > According to https://release.debian.org/buster/freeze_policy.html:
> >
> > 2019-01-12 - Transition freeze
> >
> > Is there still time yet to get a fix in, or is it FUBAR already?
> 
> Transition freeze means ABI changes in libraries are forbidden.  We're
> almost in soft-freeze now, more info at:
> https://lists.debian.org/debian-devel-announce/2019/01/msg8.html

So do we have time until the soft freeze on 2019-02-12 (I hope not)
or the full freeze (2019-03-12) to get a 2.4.0 uploaded?

> I have to review the situation again, I completely swapped it out of
> my memory.

My suggestion of 2018-11-25 still stands. But if you want me to do
my part of it, please do your review quickly and tell me soon
(or, if it's indeed necessary for the soft freeze, immediately) to
avoid running out of time.

> Assuming that the changes in a new release do not change
> other behaviour, or that I can cherry pick a targeted fix for this
> problem, we're still good to go.

Not much to cherry pick AFAICS. This issue is the only discrepancy
between our versions and if we find a (transitory) solution, we'll
be in sync.

Cheers,
Frank

Bug#921483: fail2ban: does not catch all connection failures for postfix

[Vincent Lefevre]

Package: fail2ban
Version: 0.10.2-2.1
Severity: normal

I have the following:

[postfix]
enabled  = true
mode = aggressive
maxretry = 3
bantime  = 3024000  ; 5 weeks

but /var/log/mail.log shows:

Feb  5 10:34:16 zira postfix/smtpd[7268]: connect from unknown[37.49.225.223]
Feb  5 10:34:16 zira postfix/smtpd[7268]: disconnect from 
unknown[37.49.225.223] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Feb  5 11:35:36 zira postfix/smtpd[9120]: connect from unknown[37.49.225.223]
Feb  5 11:35:36 zira postfix/smtpd[9120]: disconnect from 
unknown[37.49.225.223] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Feb  5 12:36:58 zira postfix/smtpd[10976]: connect from unknown[37.49.225.223]
Feb  5 12:36:59 zira postfix/smtpd[10976]: disconnect from 
unknown[37.49.225.223] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Feb  5 13:38:32 zira postfix/smtpd[12811]: connect from unknown[37.49.225.223]
Feb  5 13:38:32 zira postfix/smtpd[12811]: disconnect from 
unknown[37.49.225.223] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Feb  5 14:40:07 zira postfix/smtpd[15135]: connect from unknown[37.49.225.223]
Feb  5 14:40:07 zira postfix/smtpd[15135]: disconnect from 
unknown[37.49.225.223] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Feb  5 15:41:36 zira postfix/smtpd[17275]: connect from unknown[37.49.225.223]
Feb  5 15:41:36 zira postfix/smtpd[17275]: disconnect from 
unknown[37.49.225.223] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Feb  5 16:43:16 zira postfix/smtpd[19100]: connect from unknown[37.49.225.223]
Feb  5 16:43:16 zira postfix/smtpd[19100]: disconnect from 
unknown[37.49.225.223] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4

That's more than 3.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fail2ban depends on:
ii  lsb-base  10.2018112800
ii  python3   3.7.2-1

Versions of packages fail2ban recommends:
ii  iptables   1.8.2-3
ii  nftables   0.9.0-2
ii  python 2.7.15-4
ii  python3-pyinotify  0.9.6-1
ii  python3-systemd234-2+b1
ii  whois  5.4.1

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii  mailutils [mailx]1:3.5-2
ii  monit1:5.25.2-2
ii  rsyslog [system-log-daemon]  8.40.0-1+b1
ii  sqlite3  3.26.0+fossilbc891ac6b-2

-- no debconf information

Bug#906686: still present on php7.3-fpm version 7.3.1

[Ernesto Domato]

Hello everyone,

I'm having this problem on a VM running on kvm and this is what
systemctl status says:

edomato@buster ~> sudo systemctl status php7.3-fpm.service
● php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; enabled;
vendor preset: enabled)
   Active: failed (Result: timeout) since Tue 2019-02-05 22:30:29 -03;
1h 9min ago
 Docs: man:php-fpm7.3(8)
  Process: 360 ExecStart=/usr/sbin/php-fpm7.3 --nodaemonize
--fpm-config /etc/php/7.3/fpm/php-fpm.conf (code=killed, signal=TERM)
 Main PID: 360 (code=killed, signal=TERM)

feb 05 22:28:58 buster systemd[1]: Starting The PHP 7.3 FastCGI
Process Manager...
feb 05 22:30:29 buster systemd[1]: php7.3-fpm.service: Start operation
timed out. Terminating.
feb 05 22:30:29 buster systemd[1]: php7.3-fpm.service: Main process
exited, code=killed, status=15/TERM
feb 05 22:30:29 buster systemd[1]: php7.3-fpm.service: Failed with
result 'timeout'.
feb 05 22:30:29 buster systemd[1]: Failed to start The PHP 7.3 FastCGI
Process Manager.

Let me know what can I do to try debug this problem, for what I see on
the messages, it seems that the process timed out maybe because of
load on the host machine at the time the VM boots.

I'm a little concern about this because I need to use 7.3 version on a
project that I'm working on and when I launch it on production, I need
it to run stable :-)

Thanks for all.
Cheers.
Ermesto

Bug#921326: exim4-daemon-light: old exim4 daemon did not stop; socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned

[Vincent Lefevre]

On 2019-02-05 19:41:22 +0100, Andreas Metzler wrote:
> Do the warning messages quoted above show up on every stop/start? Is the
> issue, (service exim4 stop does not stop the daemon) reproducible?

Well, this is worse:

# service exim4 stop
# service exim4 start

yields a second running daemon, as root:

Debian-+  1227 1  0 Feb04 ?00:00:00 /usr/sbin/exim4 -bd -q5m
root 17597 1  0 02:18 ?00:00:00 /usr/sbin/exim4 -bd -q5m

and I still get the error message in the logs:

Feb 06 02:18:08 cventin systemd[1]: Stopping LSB: exim Mail Transport Agent...
Feb 06 02:18:08 cventin exim4[17314]: Stopping MTA:/sbin/start-stop-daemon: 
matching only on non-root pidfile /run/exim4/exim.pid is insecure
Feb 06 02:18:08 cventin exim4[17314]:  exim4_listener.
Feb 06 02:18:08 cventin exim4[17314]: ALERT: exim paniclog 
/var/log/exim4/paniclog has non-zero size, mail system possibly broken
Feb 06 02:18:08 cventin systemd[1]: exim4.service: Succeeded.
Feb 06 02:18:08 cventin systemd[1]: Stopped LSB: exim Mail Transport Agent.
Feb 06 02:18:11 cventin systemd[1]: exim4.service: Found left-over process 1227 
(exim4) in control group while starting unit. Ignoring.
Feb 06 02:18:11 cventin systemd[1]: This usually indicates unclean termination 
of a previous run, or service implementation deficiencies.
Feb 06 02:18:11 cventin systemd[1]: Starting LSB: exim Mail Transport Agent...
Feb 06 02:18:12 cventin exim4[17350]: Starting MTA: exim4.
Feb 06 02:18:12 cventin exim4[17350]: ALERT: exim paniclog 
/var/log/exim4/paniclog has non-zero size, mail system possibly broken
Feb 06 02:18:12 cventin systemd[1]: Started LSB: exim Mail Transport Agent.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#921482: RFS: note/1.3.26-3

[eamanu15]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: kact...@debian.org

Dear mentors,

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

* Package name: note
 Version : 1.3.26-3
 Upstream Author : Thomas von Dein >
* URL : http://www.daemon.de/NOTE
* License : Gnu Public License(GPL)
 Section : utils

It builds those binary packages:

  note  - small program managing notes from commandline

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/n/note/note_1.3.26-3.dsc

More information about note can be obtained from http://www.daemon.de/NOTE

Changes since the last upload:

* Add me to Maintainer Field on d/control:
  - For some reason that I ignore the Maintainer field
  on d/control was not updated.
* Update fix-spelling.patch because is old.
* Delete NOTEDB folder and NOTEDB.pm because they are
  not on upstream from ad6cb95 commit (Github).
* Delete install.sh.
   - This file was forgotten to be deleted by the
   upstream author.
   - delete-install.patch was created
* Update d/watch file to download the upstream version
  from CPAN repository.
* Adding on d/rules a sentence to delete README from
  /usr/share/perl5/NOTEDB/


Regards,
 Emmanuel Arias

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

Bug#921403: RFS: pyfltk/1.3.4.1-1 [ITP]

[eamanu15]

Hi,

I was reviewing the package that you upload to mentors.d.n

IMO you have several problem that you need fix:

  * The last version is on UNRELEASED. The package must be on
"unstable".
  * You should write a better debian/changelog. "Initial release
using Python 3" does not give me several information about
the change that you made.
  * You should request access to DPTM (because this is a python
package) and salsa user, this way you can create the repo for
pyflitk and add Vcs-* field on d/control.
  * IMO would be great if you can put the range of year of copyright
on d/copyright. For example, for Charlie S. I will write:
2011-2019, and for you just it is.
  * You don't have the standard version field on d/control.
  * I think that you forgot write the d/rules header
#!/usr/bin/make -f

Please, do not be discouraged. I am just a Debian contributor,
not a mentor or a DD, so I know that the first times could be
I little complicate, but keep going :-)

Regards!
Emmanuel

Bug#921464: ITP: gnome-books -- ebook reader for GNOME

[eamanu15]

Hi!

I see that on debian/copyright file there is not a
license section for debian/* files and you (or GNOME team)
are not there.

There a reason for that?

Regards!


El mar., 5 de feb. de 2019 a la(s) 16:48, Jeremy Bicha (jbi...@debian.org)
escribió:

> Package: wnpp
> Severity: wishlist
> Owner: jbi...@debian.org
> X-Debbugs-CC: debian-de...@lists.debian.org,
> debian-gtk-gn...@lists.debian.org
>
> Package Name: gnome-books
> Version: 3.31.90
> Upstream Authors: Cosimo Cecchi
> License : GPL-2+
> Programming Lang: JavaScript
> Homepage: https://wiki.gnome.org/Apps/Books
> Description: ebook reader for GNOME
>  GNOME Books is a simple application to access and organize your ebooks.
>  It is meant to be a simple and elegant replacement for using a
>  file manager to deal with ebooks. The app supports comic books
>  and ePub books.
>
> Other Info
> --
> Before GNOME 3.32, this app was bundled as part of the GNOME Documents app.
> It was split to allow users to easily install one app without the
> other. I am intending to get the new versions of these 2 apps into
> Debian Buster to fix the usability problem when you try to install or
> remove one of the apps in the GNOME Software app.
>
> Packaging is maintained by the Debian GNOME Team at
> https://salsa.debian.org/gnome-team/gnome-books
>
> Thanks,
> Jeremy Bicha
>
>

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

Bug#583843: [2]Re: Best test

[Daniela Salazar Silva]

My name is Cruz Torres Amarilys,

I have a business deal for you



Please Reply: amarilyscr...@hotmail.com








Listo si señor, en tu oficina? Mil gracias

Descarga

De: Jaison Daniel Cucarian Hurtado 

Bug#921481: pass: should not depend on / recommend the dummy package gnupg2

[Vincent Lefevre]

Package: pass
Version: 1.7.3-1
Severity: important

Package pass has:

Depends: gnupg2 | gnupg, tree (>= 1.7.0)
Recommends: gnupg2, git, qrencode, xclip

But gnupg2 is a dummy package, and this is annoying as it will be
installed by default because of this.

Instead, it should have:

Depends: gnupg, tree (>= 1.7.0)
Recommends: git, qrencode, xclip

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pass depends on:
ii  gnupg  2.2.12-1
pn  pwgen  
ii  tree   1.8.0-1

Versions of packages pass recommends:
ii  git   1:2.20.1-2
pn  gnupg2
pn  qrencode  
ii  xclip 0.13-1

Versions of packages pass suggests:
ii  libxml-simple-perl  2.25-1
ii  perl5.28.1-4
ii  python  2.7.15-4
ii  python3 3.7.2-1
ii  ruby1:2.5.1

Bug#921473: calibre: Invalid maintainer address

[Scott Kitterman]

On February 5, 2019 11:50:47 PM UTC, Nicholas D Steeves  
wrote:
>Hi Scott,
>
>Reply follows inline.
>
>On Tue, Feb 05, 2019 at 05:31:23PM -0500, Scott Kitterman wrote:
>> Package: calibre
>> Version: 3.39.1+dfsg-1
>> Severity: serious
>> Justification: Policy 3.3
>> 
>> Debian policy requires a valid maintainer address:
>> 
>> A message that you sent could not be delivered to one or more of its
>> recipients. This is a permanent error. The following address(es)
>failed:
>> 
>>   prein...@debian.org
>> Unrouteable address
>> 
>> From: Debian FTP Masters 
>> Subject: Processing of calibre_3.39.1+dfsg-1_source.changes
>> Date: Tue, 05 Feb 2019 22:27:18 +
>> X-Debian: DAK
>> X-DAK: DAK
>> Precedence: bulk
>> Auto-Submitted: auto-generated
>> X-Debian-Package: calibre
>> Message-Id: 
>> 
>> calibre_3.39.1+dfsg-1_source.changes uploaded successfully to
>localhost
>> along with the files:
>>   calibre_3.39.1+dfsg-1.dsc
>>   calibre_3.39.1+dfsg.orig.tar.xz
>>   calibre_3.39.1+dfsg-1.debian.tar.xz
>>   calibre_3.39.1+dfsg-1_amd64.buildinfo
>> 
>> Greetings,
>> 
>>  Your Debian queue daemon (running on host usper.debian.org)
>> 
>> --1549405639-eximdsn-1087713461--
>> 
>> Scott K
>
>Thank you for bringing this to my attention, as far as I know, Norbert
>I've contacted him using his other email address, to ask to use that
>address as maintainer.
>
>Worst case scenario, what is the deadline to adopt Calibre?  I believe
>Norbert is still the maintainer, but am willing to adopt the package
>if I do not receive consent to publish a package using his private
>address before $deadline.

For deadlines for Buster, you should consult the release team's emails on the 
freeze schedule.

Scott K

Bug#921326: Bug#921205: Bug#921326: exim4-daemon-light: old exim4 daemon did not stop; socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned

[積丹尼 Dan Jacobson]

The problem only occurs during upgrades, not the daily boot. P.S., I
don't use testing. I use:
-- System Information:
Debian Release: buster/sid
  APT prefers experimental
  APT policy: (990, 'experimental'), (500, 'unstable')
Architecture: i386 (i686) (AND AMD64 too).

Bug#921480: nnn: lacking 'suggests' / 'recommends'

[Boruch Baum]

Package: nnn
Version: 2.2-1
Severity: normal

Dear Maintainer,

The package has a list of optional dependencies that are documented in
different parts of the README. None are implemented in the debian
packaging as 'suggests', or 'recommends'.

Here are what I've found: mediainfo or exiftool, atool or patool, vidir
(moreutils), vlock, file, lftp, findutils, xdg-open (xdg-utils).


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 2.0.0 (ascii)
Release:2.0.0
Codename:   ascii
Architecture: x86_64

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

Versions of packages nnn depends on:
ii  libc6 2.28-5
ii  libncursesw6  6.1+20181013-1
ii  libtinfo6 6.1+20181013-1

nnn recommends no packages.

nnn suggests no packages.

-- no debconf information




-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#907573: Please provide u-boot image for qemu

[Vagrant Cascadian]

On 2018-11-26, Ivo De Decker wrote:
> On 11/26/18 8:42 AM, Vagrant Cascadian wrote:
>> On 2018-10-10, Vagrant Cascadian wrote:
>>> On 2018-09-30, Ivo De Decker wrote:
 I pushed a branch 'qemu' to salsa which creates a u-boot-qemu package with 
 the
 images for the architectures that are actually in debian:
>> ...
 Inspired by other qemu bootloaders (like edk2, openbios, ...), I created 
 this
 as an arch all package, which is built using the cross compilers available 
 in
 the archive. This caused some changes in the build of the package. I would 
 be
 interested to get your feedback on this. Do you think this is an acceptable
 way forward?
>> 
>> The branch still merges on top of 2018.11-1 and if building arch:all
>> only, it builds! Cool!

I made a qemu-v3 branch, merging qemu-v2 on top of current master, and
making some additional changes so that building arch:all on other
architectures does not fail to build if they're missing the appropriate
cross-compilers... by allowing it to skip such targets.

I'll need to document in debian/README.source that it should only be
built on amd64 or i386, where all the targets can be built.

It's not pretty, but it at least allows the reproducible builds arm*
builders to continue to test u-boot, while at least building the targets
it can on those architectures. If the additional needed cross-compilers
are enabled, they just need to be added in Build-Depends-Indep and it
will "just work".

It does appear to be a bit late to get this into buster, but I intend to
push it to expperimental with the next u-boot release/release candidate.


live well,
  vagrant

Bug#821397: sway 1.0-rc1

[Sean Whitton]

Hello,

On Tue 05 Feb 2019 at 05:09PM -07, Sean Whitton wrote:

> There is a new release of sway out, and it moves swayidle and swaylock
> into separate source packages.
>
> Those are all going to have to pass through NEW.  Do you have time to
> prepare separate source packages for all these?  We might as well do it
> now rather than later.

What I mean is: we might as well put the three separate sway source
packages in NEW now, rather than wait for 1.0~beta.2 to pass through
NEW, and then moving the binary packages between source packages.  But
only if you have time!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#821397: sway 1.0-rc1

[Sean Whitton]

Hello Birger,

There is a new release of sway out, and it moves swayidle and swaylock
into separate source packages.

Those are all going to have to pass through NEW.  Do you have time to
prepare separate source packages for all these?  We might as well do it
now rather than later.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#921479: lxqt-branding-debian: fails to upgrade from 'stable' to 'sid' - trying to overwrite /etc/xdg/lxqt/panel.conf

[Alf Gaida]

Thank you very much, nice finding. No discussions, my fault.

Bug#900165: calibre: segfault

[Nicholas D Steeves]

Hi Sam,

On Tue, May 29, 2018 at 02:17:25PM +, Sam Spade wrote:
> Sorry here is what I meant:
> 
> If I run Calibre with the launcher or with the command line, now it works 
> fine.
> But if I run the following command:
> $ calibre-debug --test-build
> it still returns the same "error":
> File "/usr/lib/calibre/duktape/__init__.py", line 15, in 
> import dukpy
> ImportError: No module named dukpy
> 
> Regards

It's looking for dukpy, "a simple javascript interpreter for Python
built on top of duktape engine without any external dependency".
  https://pypi.org/project/dukpy/

Dukpy might be unsuitable for Debian if "dukpy is currently not
production ready and might actually crash your program as it is mostly
implemented in C." is true, but it would take time to establish
whether it meets the minimum standards of quality/reliability...


Cheers,
Nicholas



signature.asc
Description: PGP signature

Bug#921479: lxqt-branding-debian: fails to upgrade from 'stable' to 'sid' - trying to overwrite /etc/xdg/lxqt/panel.conf

[Andreas Beckmann]

Package: lxqt-branding-debian
Version: 0.14.0
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

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

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

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

  Preparing to unpack .../lxqt-branding-debian_0.14.0_all.deb ...   

   Unpacking 
lxqt-branding-debian (0.14.0) ...   

   dpkg: error processing archive 
/var/cache/apt/archives/lxqt-branding-debian_0.14.0_all.deb (--unpack): 

   trying to overwrite '/etc/xdg/lxqt/panel.conf', which is 
also in package lxqt-panel 0.11.1-1 
   
Errors were encountered while processing:   

  
/var/cache/apt/archives/lxqt-branding-debian_0.14.0_all.deb 

  


cheers,

Andreas


lxqt-panel=0.11.1-1_lxqt-branding-debian=0.14.0.log.gz
Description: application/gzip

Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)

[Steve Langasek]

On Tue, Feb 05, 2019 at 11:10:15PM +0200, Adrian Bunk wrote:
> On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote:
> > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote:
> > > And then there is the unrelated #908269 that currently prevents testing 
> > > migration of pbbam.

> > > Steve seems to be addressing this with
> > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz

> > Yes, but the net result of this change is that now the autopkgtest fails by
> > running out of memory during the package build at test time, which is why I
> > haven't submitted a better patch to the BTS.

> > I think the ideal here would be to either have a way to generate just the
> > single data file we need for the tests, or to capture that file from the
> > package build and ship it in a binary package, so that we don't have to do a
> > full rebuild during the autopkgtests.

> The file is generated during configure, not build.

> As proof of concept, it works to do

> override_dh_auto_test: $(subst .t.in,.deb.t,$(wildcard 
> tests/src/cram/pb*.t.in))
> ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
>   dh_auto_configure -O--buildsystem=meson
> ...

Indeed, with this pbbam now passes its autopkgtests on all three
architectures in Ubuntu.  Attached is a complete patch against pbbam
0.19.0+dfsg-3 for this.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pbbam-0.19.0+dfsg/debian/rules pbbam-0.19.0+dfsg/debian/rules
--- pbbam-0.19.0+dfsg/debian/rules  2019-02-04 02:47:51.0 -0800
+++ pbbam-0.19.0+dfsg/debian/rules  2019-02-05 13:58:07.0 -0800
@@ -26,6 +26,7 @@
 
 override_dh_auto_test: $(subst .t.in,.deb.t,$(wildcard 
tests/src/cram/pb*.t.in))
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+   dh_auto_configure -O--buildsystem=meson
mkdir -p $(generated_data_dir)
python tests/scripts/generate_data.py $(CURDIR)/tests/data 
$(generated_data_dir)
# Fix broken PATH
diff -Nru pbbam-0.19.0+dfsg/debian/tests/control 
pbbam-0.19.0+dfsg/debian/tests/control
--- pbbam-0.19.0+dfsg/debian/tests/control  2019-02-02 22:57:09.0 
-0800
+++ pbbam-0.19.0+dfsg/debian/tests/control  2019-02-05 13:58:07.0 
-0800
@@ -1,11 +1,5 @@
 Test-Command: debian/rules override_dh_auto_test
 Depends:
-   make,
-   python,
+   @builddeps@,
pbbamtools,
-   python-cram,
-   samtools
-Restrictions:
-   rw-build-tree,
-   allow-stderr,
-   build-needed
+Restrictions: rw-build-tree, allow-stderr


signature.asc
Description: PGP signature

Bug#921478: Package should Suggest other alsa packages

[積丹尼 Dan Jacobson]

Package: alsa-utils
Version: 1.1.7-1

This package should Maybe at least Suggest other alsa packages, else the
user might wonder why some of the utilities don't seem to work
correctly.

Bug#920037: dont include in buster - scala and sbt

[Thomas Finneid]

Hi

I am arriving a little late to this disucussion, so please forgive me if 
this is old news or I have misunderstood.


First, a small comment. Even though there might be only a few debian 
packages that requires java 8, there are still a lot of projects, both 
amateur and professional that still use java 8 and will use it for many 
years to come. So it would probably be missed if removed too early.


To the main point:

Long story short: the current scala package in debian depends on the 
wrong version of java so it does not allways work correctly.


The current scala package contains scala 2.11, which is compatible with 
java 6, but it depends on the java 8 package, so its not really well 
supported.

That is, the scala project built and tested scala 2.11 using java 6.
The current Scala release, 2.12, requires java 8 to work correctly.

I have suggested this, in an email to the pkg-java list and have offered 
to help resolve these issues, as I want to help provide a painless and 
fuller scala development environment for both debian and ubuntu.


But that means jdk 8 must be available in some form in the release.

NB: its not just the java language version, but also the jdk classes 
that are important for correct working of scala. So that means it must 
actually be the jdk-v8 that has to be available, not just jdk11 with 
java8 interpretation.


Regards

Thomas

Bug#921477: please add mod_client_certs (XEP-0257: Client Certificate Management for SASL EXTERNAL)

[W. Martin Borgert]

Package: prosody-modules
Version: 0.0~hg20181209.39ec478a752e+dfsg-1
Severity: wishlist

See https://modules.prosody.im/mod_client_certs.html
and https://xmpp.org/extensions/xep-0257.html

Bug#921473: calibre: Invalid maintainer address

[Nicholas D Steeves]

Hi Scott,

Reply follows inline.

On Tue, Feb 05, 2019 at 05:31:23PM -0500, Scott Kitterman wrote:
> Package: calibre
> Version: 3.39.1+dfsg-1
> Severity: serious
> Justification: Policy 3.3
> 
> Debian policy requires a valid maintainer address:
> 
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
> 
>   prein...@debian.org
> Unrouteable address
> 
> From: Debian FTP Masters 
> Subject: Processing of calibre_3.39.1+dfsg-1_source.changes
> Date: Tue, 05 Feb 2019 22:27:18 +
> X-Debian: DAK
> X-DAK: DAK
> Precedence: bulk
> Auto-Submitted: auto-generated
> X-Debian-Package: calibre
> Message-Id: 
> 
> calibre_3.39.1+dfsg-1_source.changes uploaded successfully to localhost
> along with the files:
>   calibre_3.39.1+dfsg-1.dsc
>   calibre_3.39.1+dfsg.orig.tar.xz
>   calibre_3.39.1+dfsg-1.debian.tar.xz
>   calibre_3.39.1+dfsg-1_amd64.buildinfo
> 
> Greetings,
> 
>   Your Debian queue daemon (running on host usper.debian.org)
> 
> --1549405639-eximdsn-1087713461--
> 
> Scott K

Thank you for bringing this to my attention, as far as I know, Norbert
I've contacted him using his other email address, to ask to use that
address as maintainer.

Worst case scenario, what is the deadline to adopt Calibre?  I believe
Norbert is still the maintainer, but am willing to adopt the package
if I do not receive consent to publish a package using his private
address before $deadline.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#886836: closed by Simon McVittie (Bug#886836: fixed in gtkmm2.4 1:2.24.5-3)

[Andreas Beckmann]

Control: found -1 1:2.24.5-3

On 2019-02-05 01:24, Debian Bug Tracking System wrote:
>* Fix "both ship usr/share/doc/libgtkmm-2.4-dev/examples/*":
>  Install all demos into the -dev package, and only there;
>  and also install Makefile*.

libgtkmm-2.4-dev now needs Breaks+Replaces: libgtkmm-2.4-doc (<< 1:2.24.5-3)


Andreas

Bug#921476: python3-spf-engine: missing Breaks+Replaces: postfix-policyd-spf-python (<< 2.9)

[Andreas Beckmann]

Package: python3-spf-engine
Version: 2.9.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

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

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

  Preparing to unpack .../python3-spf-engine_2.9.0-1_all.deb ...

   Unpacking 
python3-spf-engine (2.9.0-1) ...

   dpkg: error processing archive 
/var/cache/apt/archives/python3-spf-engine_2.9.0-1_all.deb (--unpack):  

   trying to overwrite 
'/usr/lib/python3/dist-packages/spf_engine/__init__.py', which is also in 
package postfix-policyd-spf-python 2.1.0-1  
  Errors were encountered while processing: 


/var/cache/apt/archives/python3-spf-engine_2.9.0-1_all.deb  

  

cheers,

Andreas


postfix-policyd-spf-python=2.1.0-1_python3-spf-engine=2.9.0-1.log.gz
Description: application/gzip

Bug#246621: ifupdown patch to optionally keep lease

[Austen, Jeffrey]

Package: ifupdown
Tags: patch

Attached is a patch providing an option to keep the lease. A new 
optional parameter is created in the /etc/network/interfaces file. The 
default is set so the current behavior is not changed, thus there is no 
impact on existing systems.

Please apply this patch to ifupdown.


--- ifupdown-0.8.35/inet.defn.orig	2019-01-28 14:09:58.0 -0600
+++ ifupdown-0.8.35/inet.defn	2019-02-05 16:25:21.742343309 -0600
@@ -92,6 +92,7 @@
 vendor vendor   -- Vendor class identifier (dhcpcd)
 client client   -- Client identifier (dhcpcd)
 hwaddress address   -- Hardware address.
+dhcprelease int -- Release address when finished (0=off, 1=on) (dhclient) [1]
 
   conversion
 hwaddress cleanup_hwaddress
@@ -113,7 +114,9 @@
 
   down
 /sbin/dhclient -4 -v -i -r -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp/dhclient.%iface%.leases -I -df /var/lib/dhcp/dhclient6.%iface%.leases %iface% \
-if (execable("/sbin/dhclient"))
+if (var_true("dhcprelease",ifd) && execable("/sbin/dhclient"))
+/sbin/dhclient -4 -v -i -x -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp/dhclient.%iface%.leases -I -df /var/lib/dhcp/dhclient6.%iface%.leases %iface% \
+elsif (!var_true("dhcprelease",ifd) && execable("/sbin/dhclient"))
 /sbin/pump -i %iface% -r \
 elsif (execable("/sbin/pump"))
 if test -f /run/udhcpc.%iface%.pid; then kill -USR2 $(/bin/cat /run/udhcpc.%iface%.pid); kill -TERM $(/bin/cat /run/udhcpc.%iface%.pid); fi \
@@ -278,6 +281,7 @@
 vendor vendor   -- Vendor class identifier (dhcpcd)
 client client   -- Client identifier (dhcpcd, udhcpc)
 hwaddress address   -- Hardware Address.
+dhcprelease int -- Release address when finished (0=off, 1=on) (dhclient) [1]
 
   conversion
 hwaddress cleanup_hwaddress
@@ -298,7 +302,9 @@
 
   down
 /sbin/dhclient -4 -v -i -r -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp/dhclient.%iface%.leases -I -df /var/lib/dhcp/dhclient6.%iface%.leases %iface% \
-if (execable("/sbin/dhclient"))
+if (var_true("dhcprelease",ifd) && execable("/sbin/dhclient"))
+/sbin/dhclient -4 -v -i -x -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp/dhclient.%iface%.leases -I -df /var/lib/dhcp/dhclient6.%iface%.leases %iface% \
+elsif (!var_true("dhcprelease",ifd) && execable("/sbin/dhclient"))
 if test -f /run/udhcpc.%iface%.pid; then kill -USR2 $(/bin/cat /run/udhcpc.%iface%.pid); kill -TERM $(/bin/cat /run/udhcpc.%iface%.pid); fi \
 elsif (execable("/sbin/udhcpc"))
 /sbin/dhcpcd -k %iface% \
@@ -430,6 +436,7 @@
 vendor vendor   -- Vendor class identifier (dhcpcd)
 client client   -- Client identifier (dhcpcd, udhcpc)
 hwaddress address   -- Hardware Address (Not yet supported)
+dhcprelease int -- Release address when finished (0=off, 1=on) (dhclient) [1]
 
   conversion
 hwaddress cleanup_hwaddress
@@ -449,7 +456,9 @@
 
   down
 /sbin/dhclient -4 -v -i -r -pf /run/dhclient.%iface///.%.pid -lf /var/lib/dhcp/dhclient.%iface///.%.leases -I -df /var/lib/dhcp/dhclient6.%iface///.%.leases %iface% \
-if (execable("/sbin/dhclient"))
+if (var_true("dhcprelease",ifd) && execable("/sbin/dhclient"))
+/sbin/dhclient -4 -v -i -x -pf /run/dhclient.%iface///.%.pid -lf /var/lib/dhcp/dhclient.%iface///.%.leases -I -df /var/lib/dhcp/dhclient6.%iface///.%.leases %iface% \
+if (!var_true("dhcprelease",ifd) && execable("/sbin/dhclient"))
 if test -f /run/udhcpc.%iface///.%.pid; then kill -USR2 $(/bin/cat /run/udhcpc.%iface///.%.pid); kill -TERM $(/bin/cat /run/udhcpc.%iface///.%.pid); fi \
 elsif (execable("/sbin/udhcpc"))
 /sbin/dhcpcd -k %iface% \
--- ifupdown-0.8.35/inet6.defn.orig	2019-01-28 14:14:20.0 -0600
+++ ifupdown-0.8.35/inet6.defn	2019-02-05 16:27:44.092401408 -0600
@@ -142,6 +142,7 @@
 request_prefix int -- Request a prefix through DHCPv6 Prefix Delegation (0=off, 1=on) [0]
 ll-attempts-- Number of attempts to wait for a link-local address [60]
 ll-interval-- Link-local address polling interval in seconds [0.1]
+dhcprelease int-- Release address when finished (0=off, 1=on) (dhclient) [1]
 
   conversion
 hwaddress cleanup_hwaddress
@@ -163,7 +164,9 @@
 
   down
 /sbin/dhclient -6 -v -r -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases -I -df /var/lib/dhcp/dhclient.%iface%.leases %iface% \
-if (execable("/sbin/dhclient"))
+if (var_true("dhcprelease",ifd) && execable("/sbin/dhclient"))
+/sbin/dhclient -6 -v -x -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases -I -df /var/lib/dhcp/dhclient.%iface%.leases %iface% \
+elsif (!var_true("dhcprelease",ifd) && execable("/sbin/dhclient"))
 echo 'No DHCPv6 client software found!' >&2; false \
 elsif (1)
 
@@ -319,6 +322,7 @@
 
   

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Manuel A. Fernandez Montecelo]

Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
 escreveu:
>
> According to https://release.debian.org/buster/freeze_policy.html:
>
> 2019-01-12 - Transition freeze
>
> Is there still time yet to get a fix in, or is it FUBAR already?

Transition freeze means ABI changes in libraries are forbidden.  We're
almost in soft-freeze now, more info at:
https://lists.debian.org/debian-devel-announce/2019/01/msg8.html

Sorry, I've been very busy since end of November, with unexpected work
and family loads.

I have to review the situation again, I completely swapped it out of
my memory.  Assuming that the changes in a new release do not change
other behaviour, or that I can cherry pick a targeted fix for this
problem, we're still good to go.

Cheers,
-- 
Manuel A. Fernandez Montecelo 

Bug#921466: rust-rusty-tags: Section: FIXME-(source.section)

[Robin Krahl]

Thanks for the report!  I prepared a new version to fix this issue [0]
and will double-check the section field in the future (though I am
surprised that lintian did not catch that).

[0] 
https://salsa.debian.org/rust-team/debcargo-conf/commit/bcda3d8c5b6efbd1b5b3f6ea0ffa3afea45dbc66


signature.asc
Description: PGP signature

Bug#921183: closed by Andreas Tille (Bug#921183: fixed in pysurfer 0.9.0-2)

[Andreas Beckmann]

Control: found -1  0.9.0-2

On 2019-02-04 14:54, Debian Bug Tracking System wrote:
>* Breaks / Replaces: python-surfer (<= 0.7-1)

buster has 0.7-2.1 with the file in the old location.


Andreas

Bug#921463: [Python-modules-team] Bug#921463: python3-dask: recursion problem

[Scott Kitterman]

This seems relevant:

https://github.com/python/typing/issues/523

Scott K


On Tuesday, February 05, 2019 11:02:56 PM Ruano Ruano Javier wrote:
> Hello Diane,
> The exact message is:
> 
> args2 = [_get_recursive(dsk, k, cache) for k in args]
>   File "/usr/lib/python3/dist-packages/dask/core.py", line 136, in
> 
 args2 = [_get_recursive(dsk, k, cache) for k in args]
>   File "/usr/lib/python3/dist-packages/dask/core.py", line 132, in
> _get_recursive
 res = cache[x] = _get_recursive(dsk, dsk[x], cache)
>   File "/usr/lib/python3/dist-packages/dask/core.py", line 128, in
> _get_recursive
 hashable = ishashable(x)
>   File "/usr/lib/python3/dist-packages/dask/core.py", line 20, in
> ishashable
 hash(x)
> RecursionError: maximum recursion depth exceeded while calling a Python
> object
 
> I have used the
> for i in listIndex:
> daskdataframe.loc[i].values.compute()
> 
> The daskdataframe is from a read_csv and the csv has 2.5 Gb Volume.
> 
> 
> 5 feb. 2019 22:53, Diane Trout  escribió:
> 
> Could send me a small test program that triggers the bug?
> 
> I'll try looking at it and sending it upstream.
> 
> Thanks,
> Diane
> 
> On Tue, 2019-02-05 at 20:33 +0100, javierruano wrote:
> 
> > Package: python3-dask
> > Version: 1.0.0+dfsg-2
> > Severity: normal
> > Tags: lfs
> >
> >
> >
> > Dear Maintainer,
> >
> >
> >
> > *** Reporter, please consider answering these questions, where
> > appropriate ***
> > At the operation compute to dask.dataframe.
> > 
> >   args2 = [_get_recursive(dsk, k, cache) for k in args]
> >   File "/usr/lib/python3/dist-packages/dask/core.py", line 136, in
> > 
> > 
> > 
> > args2 = [_get_recursive(dsk, k, cache) for k in args]
> >   
> >   File "/usr/lib/python3/dist-packages/dask/core.py", line 132, in
> > 
> > _get_recursive
> >
> >
> >
> >  Information:
> > 
> > Debian Release: buster/sid
> > 
> >   APT prefers testing
> >   APT policy: (500, 'testing'), (500, 'oldstable')
> > 
> > Architecture: amd64 (x86_64)
> >
> >
> >
> > Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> > LANGUAGE=en_GB:en (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> >
> >
> > Versions of packages python3-dask depends on:
> > ii  python33.7.2-1
> > ii  python3-toolz  0.9.0-1
> >
> >
> >
> > Versions of packages python3-dask recommends:
> > ii  python3-cloudpickle  0.5.6-1
> > ii  python3-numpy1:1.16.1-1
> > ii  python3-pandas   0.23.3-1
> > ii  python3-partd0.3.9-1
> > ii  python3-requests 2.20.0-2
> >
> >
> >
> > Versions of packages python3-dask suggests:
> > pn  ipython  
> > pn  python-dask-doc  
> > pn  python3-bcolz
> > ii  python3-blosc1.7.0+ds1-1
> > pn  python3-boto 
> > pn  python3-distributed  
> > pn  python3-graphviz 
> > pn  python3-h5py 
> > ii  python3-psutil   5.5.0-1
> > ii  python3-scipy1.1.0-2
> > pn  python3-skimage  
> > ii  python3-sklearn  0.20.2+dfsg-6
> > pn  python3-sqlalchemy   
> > ii  python3-tables   3.4.4-2
> >
> >
> >
> > -- no debconf information
> >
> >
> 
> 
> 

Bug#921475: stretch-pu: package postfix/3.1.9-0+deb9u1

[Scott Kitterman]

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

This update covers two types of changes:

 - Bug fixes released by upstream in postfix 3.1.9.  As has been the case
   in previous micro-releases the fixes are compact, low risk, and backed by
   postfix's upstream QA.  The release has been out upstream with no noted
   regressions (this is another one I haven't had time to package yet, but it
   deals with other issues, no regressions from 3.1.9).  Additionally, I've
   been running this release in production on one of my servers for two months
   with no problems.

 - Packaging fixes related to the systemd generator.  This has been a long-
   standing problem which affects certain configurations very significnatly.
   It has been in Unstable/Testing with no issues noted and I am no longer
   able to replicate the problems the bugs this close refer to.  For the users
   it affects, these are important fixes.

Please see the attached debdiff.  I have the package ready to upload.

Scott k
diff -Nru postfix-3.1.8/debian/changelog postfix-3.1.9/debian/changelog
--- postfix-3.1.8/debian/changelog	2018-02-23 17:29:18.0 -0500
+++ postfix-3.1.9/debian/changelog	2019-02-05 17:51:41.0 -0500
@@ -1,3 +1,35 @@
+postfix (3.1.9-0+deb9u1) stretch; urgency=medium
+
+[Scott Kitterman]
+
+  * Unset inet_interfaces in postfix-instance-generator to avoid postconf
+failures when the generator runs during boot (Thanks to Stefan Anders for
+the patch).  Closes: #896155
+  * Also fix use of postmulti in debian/configure-instance.sh since
+postfix-instance-generator uses it before the network is up.
+Closes: #882141
+
+[Wietse Venema]
+
+  * 3.1.9
+- Cleanup: added 21 missing *_maps parameters to the default
+  proxy_read_maps setting. Files: global/mail_params.h.
+
+- Bugfix (introduced: 20120117): postconf should scan only
+  built-in or service-defined parameters for ldap, *sql, etc.
+  database names. Files: postconf/postconf_user.c.
+
+- Bugfix (introduced: 19990302): when luser_relay specifies
+  a non-existent local address, the luser_relay feature becomes
+  a black hole. Reported by Jørgen Thomsen. File: local/unknown.c.
+
+- Bugfix (introduced: Postfix 2.8): missing tls_server_start()
+  error propagation in tlsproxy(8) resulting in segfault after
+  TLS handshake error. Found during code maintenance. File:
+  tlsproxy/tlsproxy.c.
+
+ -- Scott Kitterman   Tue, 05 Feb 2019 17:50:21 -0500
+
 postfix (3.1.8-0+deb9u1) stretch; urgency=medium
 
 [Scott Kitterman]
diff -Nru postfix-3.1.8/debian/configure-instance.sh postfix-3.1.9/debian/configure-instance.sh
--- postfix-3.1.8/debian/configure-instance.sh	2018-02-23 02:31:37.0 -0500
+++ postfix-3.1.9/debian/configure-instance.sh	2019-02-05 17:48:40.0 -0500
@@ -17,9 +17,9 @@
 fi
 
 if [ "X$INSTANCE" = X ] || [ "X$INSTANCE" = "X-" ]; then
-	POSTCONF="postconf"
+	POSTCONF="postconf -o inet_interfaces="
 else
-	POSTCONF="postmulti -i $INSTANCE -x postconf"
+	POSTCONF="postconf -o inet_interfaces= -c /etc/$INSTANCE"
 fi
 
 # if you set myorigin to 'ubuntu.com' or 'debian.org', it's wrong, and annoys the admins of
diff -Nru postfix-3.1.8/debian/postfix-instance-generator postfix-3.1.9/debian/postfix-instance-generator
--- postfix-3.1.8/debian/postfix-instance-generator	2018-02-23 02:31:37.0 -0500
+++ postfix-3.1.9/debian/postfix-instance-generator	2019-02-05 17:46:37.0 -0500
@@ -9,7 +9,7 @@
 
 ln -s "$SERVICEFILE" "$WANTDIR/postfix@-.service"
 for DIR in $(postconf -h multi_instance_directories); do
-ln -s "$SERVICEFILE" "$WANTDIR/postfix@$(postconf -hc $DIR multi_instance_name).service"
+ln -s "$SERVICEFILE" "$WANTDIR/postfix@$(postconf -o inet_interfaces= -hc $DIR multi_instance_name).service"
 done
 
 exit 0
diff -Nru postfix-3.1.8/HISTORY postfix-3.1.9/HISTORY
--- postfix-3.1.8/HISTORY	2018-01-27 21:49:38.0 -0500
+++ postfix-3.1.9/HISTORY	2018-05-19 16:45:43.0 -0400
@@ -22398,3 +22398,25 @@
 
 	Cleanup: incorrect mailbox seek-to-end error message in the
 	virtual(8) delivery agent. File: virtual/mailbox.c.
+
+20180218
+
+	Cleanup: added 21 missing *_maps parameters to the default
+	proxy_read_maps setting. Files: global/mail_params.h.
+
+	Bugfix (introduced: 20120117): postconf should scan only
+	built-in or service-defined parameters for ldap, *sql, etc.
+	database names. Files: postconf/postconf_user.c.
+
+20180306
+
+	Bugfix (introduced: 19990302): when luser_relay specifies
+	a non-existent local address, the luser_relay feature becomes
+	a black hole. Reported by Jørgen Thomsen. File: local/unknown.c.
+
+20180422
+
+	Bugfix (introduced: Postfix 2.8): missing tls_server_start()
+	error propagation in tlsproxy(8) resulting in segfault after
+	TLS handshake error. Found during code maintenance. File:
+	tlsproxy/tlsproxy.c.
diff -Nru postfix-3.1.8/src/global/mail_para

Bug#921474: mtail: /usr/bin/mgen is already provided by the mgen package

[Andreas Beckmann]

Package: mtail
Version: 3.0.0~rc19-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Selecting previously unselected package mtail.

   Preparing to unpack 
.../mtail_3.0.0~rc19-1_amd64.deb ...

 Unpacking mtail (3.0.0~rc19-1) ... 


  dpkg: error processing archive 
/var/cache/apt/archives/mtail_3.0.0~rc19-1_amd64.deb (--unpack):

   trying to overwrite '/usr/bin/mgen', which is also in 
package mgen 5.02.b+dfsg1-2.2   
  
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

 Errors were encountered 
while processing:   

  
/var/cache/apt/archives/mtail_3.0.0~rc19-1_amd64.deb

  

cheers,

Andreas


mgen=5.02.b+dfsg1-2.2_mtail=3.0.0~rc19-1.log.gz
Description: application/gzip

Bug#921463: python3-dask: recursion problem

[Ruano Ruano Javier]

Hello Diane,
The exact message is:

args2 = [_get_recursive(dsk, k, cache) for k in args]
  File "/usr/lib/python3/dist-packages/dask/core.py", line 136, in 
args2 = [_get_recursive(dsk, k, cache) for k in args]
  File "/usr/lib/python3/dist-packages/dask/core.py", line 132, in 
_get_recursive
res = cache[x] = _get_recursive(dsk, dsk[x], cache)
  File "/usr/lib/python3/dist-packages/dask/core.py", line 128, in 
_get_recursive
hashable = ishashable(x)
  File "/usr/lib/python3/dist-packages/dask/core.py", line 20, in ishashable
hash(x)
RecursionError: maximum recursion depth exceeded while calling a Python object

I have used the
for i in listIndex:
daskdataframe.loc[i].values.compute()

The daskdataframe is from a read_csv and the csv has 2.5 Gb Volume.


5 feb. 2019 22:53, Diane Trout  escribió:

Could send me a small test program that triggers the bug?

I'll try looking at it and sending it upstream.

Thanks,
Diane

On Tue, 2019-02-05 at 20:33 +0100, javierruano wrote:
> Package: python3-dask
> Version: 1.0.0+dfsg-2
> Severity: normal
> Tags: lfs
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where
> appropriate ***
> At the operation compute to dask.dataframe.
>   args2 = [_get_recursive(dsk, k, cache) for k in args]
>   File "/usr/lib/python3/dist-packages/dask/core.py", line 136, in
> 
> args2 = [_get_recursive(dsk, k, cache) for k in args]
>   File "/usr/lib/python3/dist-packages/dask/core.py", line 132, in
> _get_recursive
>
>  Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages python3-dask depends on:
> ii  python33.7.2-1
> ii  python3-toolz  0.9.0-1
>
> Versions of packages python3-dask recommends:
> ii  python3-cloudpickle  0.5.6-1
> ii  python3-numpy1:1.16.1-1
> ii  python3-pandas   0.23.3-1
> ii  python3-partd0.3.9-1
> ii  python3-requests 2.20.0-2
>
> Versions of packages python3-dask suggests:
> pn  ipython  
> pn  python-dask-doc  
> pn  python3-bcolz
> ii  python3-blosc1.7.0+ds1-1
> pn  python3-boto 
> pn  python3-distributed  
> pn  python3-graphviz 
> pn  python3-h5py 
> ii  python3-psutil   5.5.0-1
> ii  python3-scipy1.1.0-2
> pn  python3-skimage  
> ii  python3-sklearn  0.20.2+dfsg-6
> pn  python3-sqlalchemy   
> ii  python3-tables   3.4.4-2
>
> -- no debconf information
>

Bug#591781: texlive-base: texdoc barfs on gzipped files under gnome

[Julian Gilbey]

On Fri, Feb 01, 2019 at 01:07:51PM +0100, Hilmar Preuße wrote:
> On 31.01.19 00:05, Julian Gilbey wrote:
> > On Wed, Jan 30, 2019 at 11:27:51PM +0100, Hilmar Preuße wrote:
> 
> Hi Julian,
> 
> >> The code you mentioned initially now looks completely different. The
> >> view.tlu did not change much between stable and unstable. When comparing
> >> the code between unstable & git I don't see essential changes, so I'd
> >> suspect that the issue is also available in git. Further I don't see git
> >> commits for this topic in the last 1/2 year.
> > 
> > Yes, indeed.  I haven't looked at the view.tlu code recently, but it
> > still appears to be texdoc which is doing the unzipping.
> > 
> Upstream suggested attached patch (line numbers may differ and git has
> different line breaks, but I guess you will be able to adapt it). Does
> it solve the problem for you?

Hi Hilmar,

Yes, that works for ifsym!  Many thanks for this.

Best wishes,

   Julian

Bug#921450: fetchmail: Fetchmail segfaults upon execution

[Sébastien Dinot]

- Mail original -
>  Thanks! Do you get the message via procmail and / or does it get
> deleted from your server?

Each time I launch fetchmail, I retrieve a copy of the same first message in my 
local mailbox, but this message is not deleted from my server.

I don't know if this other piece of information can help, but this issue is not 
the only issue I encounters since the last update of fetchmail. Actually, I 
also use fetchmail to retrieve messages from another mail server (my ISP's). 
Since the last update of fetchmail, recovery on this server fails (without 
segmentation fault) for another reason:


$ env LC_ALL=C fetchmail -v -v -v  --nodetach --nosyslog -b 2
Old UID list from pop.free.fr:
 

Scratch list of UIDs:
 

fetchmail: removing stale lockfile
fetchmail: 6.4.0.beta4 querying pop.free.fr (protocol POP3) at Tue Feb  5 
23:33:22 2019: poll started
Trying to connect to 212.27.48.3/110...connected.
fetchmail: POP3< +OK POP3 ready <1391411951.1549406002@popn1>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< UIDL
fetchmail: POP3< SASL LOGIN PLAIN
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< -ERR invalid command
fetchmail: invalid command
fetchmail: pop.free.fr: upgrade to TLS failed.
fetchmail: Unknown login or authentication error on sebastien.di...@pop.free.fr
fetchmail: socket error while fetching from sebastien.di...@pop.free.fr
fetchmail: 6.4.0.beta4 querying pop.free.fr (protocol POP3) at Tue Feb  5 
23:33:22 2019: poll completed
Merged UID list from pop.free.fr:
 
fetchmail: Query status=2 (SOCKET)
fetchmail: normal termination, status 2


Sébastien

Bug#921411: Improving the Debian logo on the login page

[Aurélien COUDERC]

Hi Jeremy,

Le 05/02/2019 à 23:00, Jeremy Bicha a écrit :
> On Tue, Feb 5, 2019 at 2:45 AM Aurélien COUDERC  wrote:
>> Also the new logo is behind an alternative that will make it much more easy
>> for derivatives to provide their own without patching.
> 
> The path in the patch should be
> /etc/alternatives/vendor-logos/logo-text-version-128.png
> right?

well I find it more readable when it’s in /usr/share/images but the path’s 
basename in my patch is a symlink to the one in you’re proposal so whichever 
you like better will work.

$ ls -l /usr/share/images/vendor-logos
lrwxrwxrwx 1 root root 30 févr.  5 00:06 /usr/share/images/vendor-logos -> 
/etc/alternatives/vendor-logos


Cheers,
--
Aurélien

Bug#892288: arrayfire test crash

[Rebecca N. Palmer]

Control: tags -1 fixed-upstream patch

These look like the upstream fixes, though I haven't actually tried them 
yet.


for index:

https://github.com/arrayfire/arrayfire/commit/58ac59497b50257631713e689a6b0ddffb73361a

for assign:

https://github.com/arrayfire/arrayfire/commit/1b18226dfec811e4b7b7254f5cfc85a3116a3dc2

Bug#915103: Apache2 HTTP/2 connection problems with Safari clients

[Philip Iezzi]

Hi Stefan,

Wow, this is great! I have applied your bug915103-try2.diff patch and it seems 
to fix the issue.
Only did some rudimentary testing so far. I have patched Apache for 2hrs now 
and started to switch some crucial sites back to HTTP/2. Could not reproduce 
the problem any more. Very nice!

Thank you S much!
No worries about late response. It is a great response with a great patch and I 
totally appreciate.

For the ones that are not used to patching Apache on Debian, here's my short 
HOWTO (it's enough to install apache2-bin package):

$ cd /usr/src/apache2-bug915103
$ apt-get source apache2
$ cd apache2-2.4.25
$ patch -p1 < ../bug915103-try2.diff
$ apt-get build-dep apache2
$ dpkg-buildpackage -b
$ cd ../
$ dpkg -i apache2-bin_2.4.25-3+deb9u6_amd64.deb
$ systemctl restart apache2
$ echo apache2-bin hold | dpkg --set-selections

Cheers,
Philip

Bug#921473: calibre: Invalid maintainer address

[Scott Kitterman]

Package: calibre
Version: 3.39.1+dfsg-1
Severity: serious
Justification: Policy 3.3

Debian policy requires a valid maintainer address:

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

  prein...@debian.org
Unrouteable address

From: Debian FTP Masters 
Subject: Processing of calibre_3.39.1+dfsg-1_source.changes
Date: Tue, 05 Feb 2019 22:27:18 +
X-Debian: DAK
X-DAK: DAK
Precedence: bulk
Auto-Submitted: auto-generated
X-Debian-Package: calibre
Message-Id: 

calibre_3.39.1+dfsg-1_source.changes uploaded successfully to localhost
along with the files:
  calibre_3.39.1+dfsg-1.dsc
  calibre_3.39.1+dfsg.orig.tar.xz
  calibre_3.39.1+dfsg-1.debian.tar.xz
  calibre_3.39.1+dfsg-1_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

--1549405639-eximdsn-1087713461--

Scott K

Bug#921472: libqt5qml5: recommends dummy transitional package libgl1-mesa-glx

[Gabriele Stilli]

Package: libqt5qml5
Version: 5.11.3-2

Hi, libqt5qml5 recommends dummy transitional package libgl1-mesa-glx.
This should be updated to recommend current packages.

Regards,
Gabriele Stilli

Bug#921471: Should pdf2htmlex be removed?

[Johannes Schauer]

On Tue, 05 Feb 2019 23:12:03 +0100 Moritz Muehlenhoff  wrote:
> Should pdf2htmlex be removed? It's RC-buggy for over a year and upstream
> development seems to have stopped:
> http://pdf2htmlex.blogspot.de/2016/12/looking-for-new-maintainer.html

Yes, possibly.

Funny, that you are reporting this today because just a few hours ago, I
reached out to a fork that claims to continue development. Unfortunately,
things don't look rosy over there either:

https://github.com/pdf2htmlEX/pdf2htmlEX/issues/20


signature.asc
Description: signature

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Bernhard Übelacker]

Hello Thomas,

Am 05.02.19 um 20:50 schrieb Thomas Gaugler:
...
> I thought to use the momentum around secure boot within Debian [2] for
> supporting it within win32-loader as well.
> 
> The basic idea is to replicate the following commands in win32-loader:
> $ # Copy /usr/lib/shim/shimx64.efi.signed from shim-signed package to
> $ # /boot/efi/EFI/debian/shimx64.efi
> $ sudo efibootmgr --create --label 'Debian GNU/Linux - Continue with
> install process' --loader '\EFI\debian\shimx64.efi'
> ...
> Boot0009* Debian GNU/Linux - Continue with install process ...
> $ sudo efibootmgr --bootnext 0009

In message [10] in points 1 and 3 I tried to describe how a manual
crafted grub2 efi image could be configured from a windows cmd.
Hope that it might be of some help.

Kind regards,
Bernhard

[10] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918863#10

Bug#921471: Should pdf2htmlex be removed?

[Moritz Muehlenhoff]

Package: pdf2htmlex
Severity: serious

Should pdf2htmlex be removed? It's RC-buggy for over a year and upstream
development seems to have stopped:
http://pdf2htmlex.blogspot.de/2016/12/looking-for-new-maintainer.html

Cheers,
Moritz

Bug#921470: Correct and/or improve handling of certain quiesced snapshot failures

[Oliver Kurth]

Package: open-vm-tools
Version: 2:10.3.5-5

Customers may hit issues with quiesced snapshots under certain circumstances. 
This is fixed in a branch forked from 10.3.5:

https://github.com/vmware/open-vm-tools/tree/stable-10.3.5-quiesced-snapshot

A more detailed description of the issue can be found in the individual commit 
messages.

Bug#921469: enigma: depends on dummy transitional packages ttf-dejavu-{core,extra}

[Gabriele Stilli]

Package: enigma
Version: 1.20-dfsg.1-2.1

Hi,

enigma depends on dummy transitional packages ttf-dejavu-{core,extra}.
Those should be changed to fonts-dejavu-{core,extra}.

Regards,
Gabriele Stilli

Bug#920691: lintian gets stuck collecting info after failed objdump-info

[Felix Lechner]

On Mon, Feb 4, 2019 at 5:03 AM Raphael Hertzog  wrote:
> Thanks for the notice, I tried with that version of Perl but the problem I
> reported is still present. So it seems unrelated.

This MR fixes the hang here:

https://salsa.debian.org/lintian/lintian/merge_requests/140

Bug#921450: fetchmail: Fetchmail segfaults upon execution

[GCS]

On Tue, Feb 5, 2019 at 10:36 PM Sébastien Dinot  wrote:
> I didn't find the fetchmail-dbgsym package, but here is what the
> suggested command displays:
[...]
> fetchmail: POP3> LIST 1
> fetchmail: POP3< +OK 1 474
> fetchmail: POP3> RETR 1
> fetchmail: POP3< +OK 474 octets
> reading message m...@mail.example.com:1 of 22 (474 octets) About to rewrite 
> Return-Path: ...
> ...rewritten version is Return-Path: .
> About to rewrite From: Fail2Ban ...
> ...rewritten version is From: Fail2Ban .
> About to rewrite To: r...@example.com...
> ...rewritten version is To: r...@example.com.
> fetchmail: about to deliver with: /usr/bin/procmail -Y -d 'me'
> #*** flushed
> fetchmail: POP3> DELE 1
> fetchmail: POP3< +OK Marked to be deleted.
> Segmentation fault
 Thanks! Do you get the message via procmail and / or does it get
deleted from your server?

Cheers,
Laszlo/GCS

Bug#921450: fetchmail: Fetchmail segfaults upon execution

[Eduard Bloch]

On Tue, 5 Feb 2019 19:22:21 +0100 
=?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:
> Control: tags -1 +unreproducible moreinfo
> 
> Hi James,
> 
> On Tue, Feb 5, 2019 at 6:09 PM James Henried  wrote:
> > fetchmail has stopped working in version 6.4.0~beta4-2.
>  Which previous version did you use?
> 
> > Running the daemon gets the first mail in the queue delivered, but then it 
> > segfaults.
>  Please install fetchmail-dbgsym if it may give more information.
> 
> What happens if you stop the daemon and run it from the command line?
> What's the output if it still fails?
> Are you open to provide detailed log like the following produces?
> $ env LC_ALL=C fetchmail -v -v -v  --nodetach --nosyslog -b 2

I can reproduce it well if it's the same problem.
Here is your stack information, with minimal anonymization.

For me it's not crashing ASAP, it skips two messages with "bad header"
status and crashes upon encountering the first good message.

(gdb) bt
#0  pop3_delete (sock=, ctl=0x555b4db0, number=3) at 
pop3.c:1362
#1  0x555669b0 in fetch_messages (msgsizes=0x5559f480 , 
transient_errors=, 
deletions=, dispatches=, 
fetches=, maxfetch=1000, 
count=, ctl=0x555b4db0, mailserver_socket=3) at 
driver.c:812
#2  do_session (ctl=ctl@entry=0x555b4db0, proto=proto@entry=0x5559a200 
, maxfetch=maxfetch@entry=1000)
at driver.c:1435
#3  0x55567df9 in do_protocol (ctl=0x555b4db0, proto=0x5559a200 
) at driver.c:1677
#4  0xfb48 in query_host (ctl=0x555b4db0) at fetchmail.c:1546
#5  0xa37b in main (argc=, argv=0x7fffe5d8) at 
fetchmail.c:793
(gdb) display ctl
1: ctl = (struct query *) 0x555b4db0
(gdb) display *ctl
2: *ctl = {server = {pollname = 0x555b4cf0 "MYSERVER", via = 0x0, akalist = 
0x0, localdomains = 0x0, protocol = 3, 
service = 0x0, interval = 0, authenticate = 1, timeout = 300, envelope = 
0x0, envskip = 0, qvirtual = 0x0, 
skip = 0 '\000', dns = 1 '\001', uidl = 0 '\000', sdps = 0 '\000', 
checkalias = 0 '\000', tracepolls = 0 '\000', 
principal = 0x0, esmtp_name = 0x0, esmtp_password = 0x0, badheader = 
BHREJECT, interface = 0x0, monitor = 0x0, 
monitor_io = 0, interface_pair = 0x0, plugin = 0x0, plugout = 0x0, 
base_protocol = 0x5559a200 , poll_count = 0, 
queryname = 0x555b3f90 "MYSERVER", truename = 0x555b4020 
"MYSERVER", trueaddr = 0x555fcf50, 
trueaddr_len = 16, lead_server = 0x0, esmtp_options = 3, workarounds = 0}, 
localnames = 0x555b4d50, wildcard = 0, 
  remotename = 0x555b4cd0 "ANON", password = 0x555b4d10 "ANON", 
mailboxes = 0x555b4080, 
  smtphunt = 0x555b4060, domainlist = 0x0, smtpaddress = 0x0, smtpname = 
0x0, antispam = 0x555b4d90, mda = 0x0, 
  bsmtp = 0x0, listener = 83 'S', preconnect = 0x0, postconnect = 0x0, keep = 0 
'\000', fetchall = 1 '\001', flush = 0 '\000', 
  limitflush = 0 '\000', rewrite = 1 '\001', stripcr = 0 '\000', forcecr = 0 
'\000', pass8bits = 0 '\000', 
  dropstatus = 0 '\000', dropdelivered = 0 '\000', mimedecode = 0 '\000', idle 
= 0 '\000', limit = 0, warnings = 3600, 
  fetchlimit = 0, fetchsizelimit = 100, fastuidl = 4, fastuidlcount = 0, 
batchlimit = 70, expunge = 1000, use_ssl = 1 '\001', 
  sslkey = 0x0, sslcert = 0x0, sslproto = 0x0, sslcertfile = 0x0, sslcertpath = 
0x0, sslcertck = 1 '\001', 
  sslcommonname = 0x0, sslfingerprint = 0x0, properties = 0x0, active = 1 
'\001', destaddr = 0x5564c7e0 "localhost", 
  errcount = 0, authfailcount = 0, wehaveauthed = 1, wehavesentauthnote = 0, 
wedged = 0, 
  smtphost = 0x555b4040 "localhost", smtphostmode = 83 'S', smtp_socket = 
4, uid = 103, skipped = 0x0, oldsaved = {
pat_root = 0x555b41c0, records = 0x555dbd00, records_max = 2048, 
records_next = 1888, num_ndx = {records = 0x0, 
  pos_0_value = 4294967295, end_value = 4294967295}}, newsaved = {pat_root 
= 0x0, records = 0x555b4130, 
records_max = 16, records_next = 0, num_ndx = {records = 0x0, pos_0_value = 
4294967295, end_value = 4294967295}}, 
  lastdigest = '\000' , folder = 0x0, mimemsg = 1, digest = 
'\000' , next = 0x0}

Valgrind confirms:

==4368== Invalid write of size 4
==4368==at 0x10DDDA: pop3_delete (pop3.c:1374)
==4368==by 0x10DDDA: pop3_delete.cold.13 (pop3.c:1362)
==4368==by 0x11A9AF: fetch_messages (driver.c:812)
==4368==by 0x11A9AF: do_session (driver.c:1435)
==4368==by 0x11BDF8: do_protocol (driver.c:1677)
==4368==by 0x113B47: query_host (fetchmail.c:1546)
==4368==by 0x10E37A: main (fetchmail.c:793)
==4368==  Address 0x14 is not stack'd, malloc'd or (recently) free'd
==4368== 
==4368== 
==4368== Process terminating with default action of signal 11 (SIGSEGV)
==4368==  Access not within mapped region at address 0x14
==4368==at 0x10DDDA: pop3_delete (pop3.c:1374)
==4368==by 0x10DDDA: pop3_delete.cold.13 (pop3.c:1362)
==4368==by 0x11A9AF: fetch_messages (driver.c:812)
==4368==by 0x11A9AF: do_sessi

Bug#921468: ITS: byobu

[Alex Chernyakhovsky]

I am still willing to maintain this package am and in communication
with the Ubuntu maintainer and will be dcut'ing him privileges to do
both uploads simultaneously.

Sincerely,
-Alex

On Tue, Feb 5, 2019 at 4:57 PM Boyuan Yang  wrote:
>
> Package: byobu
> Version: 5.112-1.1
> Severity: important
> X-Debbugs-CC: acher...@mit.edu
>
> Dear byobu maintainers,
>
> I noticed that package byobu in Debian has received no maintainer activity for
> over 2 years and it's diverging from downstream Ubuntu's package [2]. As a
> result, I'm starting the package ITS process [1] as defined by Developers'
> Reference §5.12 in order to improve the maintenance status of byobu in Debian.
>
> Please let me know if you are still willing to maintain this package in
> Debian. Otherwise, I will upload an NMU for byobu 21 days onto DELAYED/7 to
> take over maintainership.
>
> Thank you very much for your understanding and looking forward to your reply.
>
> --
> Regards,
> Boyuan Yang
>
>
> [1] https://wiki.debian.org/PackageSalvaging
> [2] https://tracker.debian.org/pkg/byobu

Bug#921468: ITS: byobu

[Boyuan Yang]

X-Debbugs-CC: acher...@debian.org

Hi Alex,

Thanks for your quick reply. It's good to hear that there's work in progress.

If you need any help, please feel free to let me know.

--
Cheers,
Boyuan Yang

在 2019-02-05二的 16:58 -0500，Alex Chernyakhovsky写道：
> I am still willing to maintain this package am and in communication
> with the Ubuntu maintainer and will be dcut'ing him privileges to do
> both uploads simultaneously.
> 
> Sincerely,
> -Alex
> 
> On Tue, Feb 5, 2019 at 4:57 PM Boyuan Yang  wrote:
> > Package: byobu
> > Version: 5.112-1.1
> > Severity: important
> > X-Debbugs-CC: acher...@mit.edu
> > 
> > Dear byobu maintainers,
> > 
> > I noticed that package byobu in Debian has received no maintainer activity
> > for
> > over 2 years and it's diverging from downstream Ubuntu's package [2]. As a
> > result, I'm starting the package ITS process [1] as defined by Developers'
> > Reference §5.12 in order to improve the maintenance status of byobu in
> > Debian.
> > 
> > Please let me know if you are still willing to maintain this package in
> > Debian. Otherwise, I will upload an NMU for byobu 21 days onto DELAYED/7
> > to
> > take over maintainership.
> > 
> > Thank you very much for your understanding and looking forward to your
> > reply.
> > 
> > --
> > Regards,
> > Boyuan Yang
> > 
> > 
> > [1] https://wiki.debian.org/PackageSalvaging
> > [2] https://tracker.debian.org/pkg/byobu

Bug#921411: Improving the Debian logo on the login page

[Jeremy Bicha]

On Tue, Feb 5, 2019 at 2:45 AM Aurélien COUDERC  wrote:
> Also the new logo is behind an alternative that will make it much more easy
> for derivatives to provide their own without patching.

The path in the patch should be
/etc/alternatives/vendor-logos/logo-text-version-128.png
right?

Thanks,
Jeremy Bicha

Bug#921463: python3-dask: recursion problem

[Diane Trout]

Could send me a small test program that triggers the bug?

I'll try looking at it and sending it upstream.

Thanks,
Diane

On Tue, 2019-02-05 at 20:33 +0100, javierruano wrote:
> Package: python3-dask
> Version: 1.0.0+dfsg-2
> Severity: normal
> Tags: lfs
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> At the operation compute to dask.dataframe.
>   args2 = [_get_recursive(dsk, k, cache) for k in args]
>   File "/usr/lib/python3/dist-packages/dask/core.py", line 136, in
> 
> args2 = [_get_recursive(dsk, k, cache) for k in args]
>   File "/usr/lib/python3/dist-packages/dask/core.py", line 132, in
> _get_recursive
> 
>  Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages python3-dask depends on:
> ii  python33.7.2-1
> ii  python3-toolz  0.9.0-1
> 
> Versions of packages python3-dask recommends:
> ii  python3-cloudpickle  0.5.6-1
> ii  python3-numpy1:1.16.1-1
> ii  python3-pandas   0.23.3-1
> ii  python3-partd0.3.9-1
> ii  python3-requests 2.20.0-2
> 
> Versions of packages python3-dask suggests:
> pn  ipython  
> pn  python-dask-doc  
> pn  python3-bcolz
> ii  python3-blosc1.7.0+ds1-1
> pn  python3-boto 
> pn  python3-distributed  
> pn  python3-graphviz 
> pn  python3-h5py 
> ii  python3-psutil   5.5.0-1
> ii  python3-scipy1.1.0-2
> pn  python3-skimage  
> ii  python3-sklearn  0.20.2+dfsg-6
> pn  python3-sqlalchemy   
> ii  python3-tables   3.4.4-2
> 
> -- no debconf information
> 

Bug#921468: ITS: byobu

[Boyuan Yang]

Package: byobu
Version: 5.112-1.1
Severity: important
X-Debbugs-CC: acher...@mit.edu

Dear byobu maintainers,

I noticed that package byobu in Debian has received no maintainer activity for
over 2 years and it's diverging from downstream Ubuntu's package [2]. As a
result, I'm starting the package ITS process [1] as defined by Developers'
Reference §5.12 in order to improve the maintenance status of byobu in Debian.

Please let me know if you are still willing to maintain this package in
Debian. Otherwise, I will upload an NMU for byobu 21 days onto DELAYED/7 to
take over maintainership.

Thank you very much for your understanding and looking forward to your reply.

--
Regards,
Boyuan Yang


[1] https://wiki.debian.org/PackageSalvaging
[2] https://tracker.debian.org/pkg/byobu


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

Bug#919770: ETA for upload of postgresql-11

[Christoph Berg]

Re: Helge Kreutzmann 2019-02-05 
<20190205181450.GF10512@Debian-50-lenny-64-minimal>
> several debconf translations were submitted for postgresql-11 were
> submitted (including the German one) and marked pending (e.g. the
> German about two weeks ago). 
> 
> As the freeze is rapdily approaching I'd like to ask if an upload in
> time is planned, including all new/updated debconf translations.

There next round of PG minor releases will be due next week, i.e. I'll
upload 11.2 with the debconf changes then.

Christoph

Bug#915738: fixed in GCC

[Matthias Klose]

gcc-8 8.2.0-18 will have the upstream fix for that issue.

Bug#919413: fix and status update

[Paolo Greppi]

Following a suggestion by sthibault, I added texlive-plain-generic as build dep 
for doxygen-latex.
With that change, I did a partial ratt job, focusing on the 9 
build-dependencies of doxygen mentioned above.
Details here:
https://salsa.debian.org/paolog-guest/doxygen/wikis/ratt3

The new version fixed hwloc and starpu.
For the remaining 7, they also fail without doxygen 1.8.15, so the FTBFS is 
"maybe unrelated to new changes".

I have just launched a new full ratt job:
https://salsa.debian.org/paolog-guest/doxygen/wikis/ratt4

P.

Bug#921450: fetchmail: Fetchmail segfaults upon execution

[Sébastien Dinot]

Hi,

I have the same problem with the same version of fetchmail package.

I didn't find the fetchmail-dbgsym package, but here is what the
suggested command displays:


$ env LC_ALL=C fetchmail -v -v -v  --nodetach --nosyslog -b 2
Old UID list from mail.example.com:
 

Scratch list of UIDs:
 

fetchmail: removing stale lockfile
fetchmail: 6.4.0.beta4 querying mail.example.com (protocol POP3) at Tue Feb  5 
22:22:59 2019: poll started
Trying to connect to 12.34.56.78/110...connected.
fetchmail: POP3< +OK Dovecot (Debian) ready.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< STLS
fetchmail: POP3< SASL
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation now.
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: Digital Signature Trust Co.
fetchmail: Issuer CommonName: DST Root CA X3
fetchmail: Subject CommonName: DST Root CA X3
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: Digital Signature Trust Co.
fetchmail: Issuer CommonName: DST Root CA X3
fetchmail: Subject CommonName: Let's Encrypt Authority X3
fetchmail: Server certificate:
fetchmail: Issuer Organization: Let's Encrypt
fetchmail: Issuer CommonName: Let's Encrypt Authority X3
fetchmail: Subject CommonName: mail.example.com
fetchmail: Subject Alternative Name: mail.example.com
fetchmail: Subject Alternative Name: smtp.example.com
fetchmail: mail.example.com key fingerprint: 
A8:63:B2:92:47:25:A2:89:E5:00:09:F6:80:B2:47:D5
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 
256/256 secret/processed bits
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< .
fetchmail: mail.example.com: upgrade to TLS succeeded.
fetchmail: POP3> USER me
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Logged in.
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 22 262046
22 messages for me at mail.example.com (262046 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 474
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 474 octets
reading message m...@mail.example.com:1 of 22 (474 octets) About to rewrite 
Return-Path: ...
...rewritten version is Return-Path: .
About to rewrite From: Fail2Ban ...
...rewritten version is From: Fail2Ban .
About to rewrite To: r...@example.com...
...rewritten version is To: r...@example.com.
fetchmail: about to deliver with: /usr/bin/procmail -Y -d 'me'
#*** flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK Marked to be deleted.
Segmentation fault

Bug#914408: [20181123] mirror.cs.uwm.edu: out of date, syncscript

[Jim Wagner]

FYI:


The server host mirror.cs.uwm.edu will be taken down on February 8th, 
2019and won't be rebuilt.


If this is too short of notice I can let it run until you tell me I can retire 
it.



Regards

-Jim




From: Peter Palfrader 
Sent: Friday, November 23, 2018 1:51:32 AM
To: sub...@bugs.debian.org
Subject: Bug#914408: [20181123] mirror.cs.uwm.edu: out of date, syncscript

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problems

Hi!

It seems http://mirror.cs.uwm.edu/debian/
is out of date
https://mirror-master.debian.org/status/mirror-info/mirror.cs.uwm.edu.html

Please investigate.

o If you sync off kernel.org, you might want to pick a different site
  (do not use ftp.*.debian.org names, only http is guaranteed at
   those names and they do switch around.)
  https://mirror-master.debian.org/status/mirror-hierarchy.html might help
  you pick.

o Also, please switch to using a modern ftpsync to mirroring.
  The trace file at
  http://mirror.cs.uwm.edu/debian/project/trace/mirror.cs.uwm.edu
  does not contain much information.

  Please use our ftpsync script to mirror Debian.

  Using a modern ftpsync ensures updates are done in the correct order
  so apt clients don't get confused.   In particular, it processes
  translations, contents, and more files that have been added to the
  archive in recent years in the correct stage.  It also should produce
  trace files that contain more information that is useful for us and helps
  downstream mirrors sync better.

  http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz
--
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#921467: syncthing: new upstream 1.0.1

[Jonatan Nyberg]

package: syncthing
severity: normal

Please consider to upgrade to the current upstream version
(1.0.1).

Regards,
Jonatan

Bug#921452: curl: zsh completion for curl -E is borken

[Alessandro Ghedini]

forwarded -1 https://github.com/curl/curl/pull/3528
kthxbye

On Tue, Feb 05, 2019 at 01:58:50PM -0400, David Bremner wrote:
> Package: curl
> Version: 7.63.0-1
> Severity: normal
> 
> Seen on #zsh / arch, verified also present in Debian; presumably an upstream 
> bug.
> 
> ╭─ rocinante:~ 
> ╰─% curl -E 
> (eval):1: parse error near `>'
> _arguments:463: command not found: p

Yeah, the script that generates the completion has a bug. Submitted a PR to
fix it.

Cheers


signature.asc
Description: PGP signature

Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)

[Adrian Bunk]

On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote:
> On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote:
> > And then there is the unrelated #908269 that currently prevents testing 
> > migration of pbbam.
> 
> > Steve seems to be addressing this with
> > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz
> 
> Yes, but the net result of this change is that now the autopkgtest fails by
> running out of memory during the package build at test time, which is why I
> haven't submitted a better patch to the BTS.
> 
> I think the ideal here would be to either have a way to generate just the
> single data file we need for the tests, or to capture that file from the
> package build and ship it in a binary package, so that we don't have to do a
> full rebuild during the autopkgtests.

The file is generated during configure, not build.

As proof of concept, it works to do

override_dh_auto_test: $(subst .t.in,.deb.t,$(wildcard tests/src/cram/pb*.t.in))
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
dh_auto_configure -O--buildsystem=meson
...


cu
Adrian

-- 

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

Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)

[Andreas Tille]

On Tue, Feb 05, 2019 at 12:56:53PM -0800, Steve Langasek wrote:
> 
> Regardless, the autopkgtest problem is not amd64-specific, because at least
> for Ubuntu, we do not size our autopkgtest runners any differently on amd64
> than on other architectures.  Fixing the autopkgtest to not require a full
> source build for one data file would allow the autopkgtest to run (and
> likely succeed) on all available archs.

OK, I'll check tomorrow (by all means feel free to NMU since we are
quite close before freeze and if you find a solution that works on
Ubuntu for these packages I'm pretty sure it will work for Debian).
I'm too tired now and I'm not sure when I will manage tomorrow.

Thanks a lot for your patience

   Andreas.

-- 
http://fam-tille.de

Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)

[Steve Langasek]

On Tue, Feb 05, 2019 at 09:45:33PM +0100, Andreas Tille wrote:
> Hi Steve,

> On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote:
> > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote:
> > > And then there is the unrelated #908269 that currently prevents testing 
> > > migration of pbbam.

> > > Steve seems to be addressing this with
> > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz

> > Yes, but the net result of this change is that now the autopkgtest fails by
> > running out of memory during the package build at test time, which is why I
> > haven't submitted a better patch to the BTS.

> > I think the ideal here would be to either have a way to generate just the
> > single data file we need for the tests, or to capture that file from the
> > package build and ship it in a binary package, so that we don't have to do a
> > full rebuild during the autopkgtests.

> Thanks a lot for the time you have spent into this leaf package.  I
> think it is absolutely realistic that this package these days and also
> for the next couple of years will be practically used only on amd64
> architecture.  It might be sensible to draw a line here and simply
> declare this package and its rdepends "Architecture: amd64" and move on
> with problems that might affect more users and realistic applications
> for other architectures.

> What do you think?

I have no opinion.  I recognize that pretty much everyone working in this
domain is using x86, but I also know that Debian and Ubuntu run quite well
on both arm64 and ppc64el servers (the other two architectures pbbam
supports); and Amazon has recently announced ARM64 cloud instances which are
a fraction of the price of x86; so if I were the maintainer I would probably
leave these enabled.

Regardless, the autopkgtest problem is not amd64-specific, because at least
for Ubuntu, we do not size our autopkgtest runners any differently on amd64
than on other architectures.  Fixing the autopkgtest to not require a full
source build for one data file would allow the autopkgtest to run (and
likely succeed) on all available archs.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#920711: Test suite seems to uncover conflict between new version of tibble and repr (Was: Bug#920711: r-cran-repr: autopkgtest regression)

[Graham Inggs]

Hi!

On Tue, 5 Feb 2019 at 22:34, Andreas Tille  wrote:
> I can also add r-cran-tibble via
>
> apt-get install --no-install-recommends r-cran-tibble
>
> and the test suite keeps on succeeding!  However, after intalling
> r-cran-dplyr the described error occures while after deinstalling
> r-cran-dplyr the test suite passes again.  So the incompatibility
> seems to be rather between r-cran-repr and r-cran-dplyr.

The reason the two tests only fail when r-cran-dplyr is installed is because of:
if (has_dplyr) { }
in both cases [1][2].

Regards
Graham


[1] 
https://salsa.debian.org/r-pkg-team/r-cran-repr/blob/master/tests/testthat/test_array_manipulation.r#L226
[2] 
https://salsa.debian.org/r-pkg-team/r-cran-repr/blob/master/tests/testthat/test_array_manipulation.r#L249

Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)

[Adrian Bunk]

On Tue, Feb 05, 2019 at 09:45:33PM +0100, Andreas Tille wrote:
> Hi Steve,
> 
> On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote:
> > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote:
> > > And then there is the unrelated #908269 that currently prevents testing 
> > > migration of pbbam.
> > 
> > > Steve seems to be addressing this with
> > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz
> > 
> > Yes, but the net result of this change is that now the autopkgtest fails by
> > running out of memory during the package build at test time, which is why I
> > haven't submitted a better patch to the BTS.
> > 
> > I think the ideal here would be to either have a way to generate just the
> > single data file we need for the tests, or to capture that file from the
> > package build and ship it in a binary package, so that we don't have to do a
> > full rebuild during the autopkgtests.
> 
> Thanks a lot for the time you have spent into this leaf package.  I
> think it is absolutely realistic that this package these days and also
> for the next couple of years will be practically used only on amd64
> architecture.  It might be sensible to draw a line here and simply
> declare this package and its rdepends "Architecture: amd64" and move on
> with problems that might affect more users and realistic applications
> for other architectures.
> 
> What do you think?

All problems discussed are on amd64.

> Kind regards
> 
>   Andreas.

cu
Adrian

-- 

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