Bug#964429: please add mod_watch_spam_reports

2020-07-07 Thread Martin
Package: prosody-modules
Version: 0.0~hg20200423.0233da912ab6+dfsg-1
Severity: wishlist

mod_watch_spam_reports sends a message to the server admins for
incoming XEP-0377 spam reports. It doesn’t require any
configuration.

https://modules.prosody.im/mod_watch_spam_reports.html
https://xmpp.org/extensions/xep-0377.html



Bug#964236: php-redis: After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash

2020-07-07 Thread Ondřej Surý
Version: 5.3.0+4.3.0-2

I have pulled 5.3.1 prerelease branch into the latest package, so the -2
should no longer crash on you.

Ondrej

On Sat, 4 Jul 2020 at 03:45, John Wong  wrote:

> Package: php-redis
> Version: After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash
> Severity: normal
>
> Dear Maintainer,
>  After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash.
>
>  traps: php-fpm7.4[198823] general protection fault ip:55da0ea4c634
> sp:7ffc14657008 error:0 in php-fpm7.4[55da0e8a8000+268000]
>  php-fpm7.4[198824]: segfault at 10001 ip 55da0ea4b3b6 sp
> 7ffc14656fb8 error 4 in php-fpm7.4[55da0e8a8000+268000]
>  Code: 85 8b 7a e7 ff 48 8b 47 10 48 83 c0 38 48 39 47 18 48 89 c2
>  48 89 47 10 48 0f 43 57 18 48 8b 47 50 48 89 57 18 48 85 c0 74 0a
>  <48> 8b 10 48 89 57 50 c3 66 90 be 06 00 00 00 e9 96 e5 ff f
>  f 66 0f
>
>  Please help, thank you.
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>


Bug#964430: prosody-modules: please add mod_easy_invite

2020-07-07 Thread Martin
Package: prosody-modules
Version: 0.0~hg20200423.0233da912ab6+dfsg-1
Severity: wishlist

mod_easy_invite allows admins and users to create invitations
suitable for sharing to potential new users/contacts.

User invitations can be created through the “New Invite” ad-hoc
command. An overview of the semantics and protocol can be found
at modernxmpp.org/client/invites.

This module depends on mod_invites to actually create and store
the invitation tokens.

https://modules.prosody.im/mod_easy_invite.html
https://docs.modernxmpp.org/client/invites/



Bug#964431: Stop installing rename.ul

2020-07-07 Thread Chris Hofstaedtler
Package: util-linux
Severity: wishlist

Dear Maintainer,

this is a reminder from the current maintainer that I want to stop
installing `rename.ul`.

Chris



Bug#964432: ruby-rails update destroy redmine issue number linking

2020-07-07 Thread s.jaekel
Package: ruby-rails
Version: 2:4.1.8-1+deb8u7
Severity: important
Tags: upstream

Dear Maintainer,

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

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

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


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

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

Versions of packages ruby-rails depends on:
ii  bundler   1.7.4-1
ii  ruby-actionmailer 2:4.1.8-1+deb8u7
ii  ruby-actionpack   2:4.1.8-1+deb8u7
ii  ruby-actionview   2:4.1.8-1+deb8u7
ii  ruby-activemodel  2:4.1.8-1+deb8u7
ii  ruby-activerecord 2:4.1.8-1+deb8u7
ii  ruby-activesupport2:4.1.8-1+deb8u7
ii  ruby-railties 2:4.1.8-1+deb8u7
ii  ruby-sprockets-rails  2.1.3-1
ii  ruby-treetop  1.4.15-1

Versions of packages ruby-rails recommends:
ii  ruby-coffee-rails  4.0.1-1
ii  ruby-jbuilder  2.1.3-1
ii  ruby-jquery-rails  3.1.2-2
ii  ruby-sass-rails4.0.3-2
ii  ruby-sdoc  0.4.1-1
ii  ruby-spring1.1.3-1
ii  ruby-sqlite3   1.3.9-2+b2
ii  ruby-turbolinks2.2.2-1
ii  ruby-uglifier  2.5.3-1

ruby-rails suggests no packages.

-- no debconf information


I updated the ruby-rails packages last week.
Since then i can use the also installed redmine (3.0~20140825-8~deb8u4)
no longer link tickets together.
Redmine always tells me the issues number is empty,
when I will link issue with an other issue.

I have check the installed version with this command

apt-cache policy ruby-activesupport ruby-rails ruby-activemodel ruby-actionview 
ruby-railties ruby-actionmailer ruby-actionpack ruby-activerecord

ruby-activesupport:
  Installiert:   2:4.1.8-1+deb8u7
  Installationskandidat: 2:4.1.8-1+deb8u7
  Versionstabelle:
 *** 2:4.1.8-1+deb8u7 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.1.8-1+deb8u4 0
500 http://ftp.tu-chemnitz.de/pub/linux/debian/debian/ jessie/main 
amd64 Packages
ruby-rails:
  Installiert:   2:4.1.8-1+deb8u7
  Installationskandidat: 2:4.1.8-1+deb8u7
  Versionstabelle:
 *** 2:4.1.8-1+deb8u7 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.1.8-1+deb8u4 0
500 http://ftp.tu-chemnitz.de/pub/linux/debian/debian/ jessie/main 
amd64 Packages
ruby-activemodel:
  Installiert:   2:4.1.8-1+deb8u7
  Installationskandidat: 2:4.1.8-1+deb8u7
  Versionstabelle:
 *** 2:4.1.8-1+deb8u7 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.1.8-1+deb8u4 0
500 http://ftp.tu-chemnitz.de/pub/linux/debian/debian/ jessie/main 
amd64 Packages
ruby-actionview:
  Installiert:   2:4.1.8-1+deb8u7
  Installationskandidat: 2:4.1.8-1+deb8u7
  Versionstabelle:
 *** 2:4.1.8-1+deb8u7 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.1.8-1+deb8u4 0
500 http://ftp.tu-chemnitz.de/pub/linux/debian/debian/ jessie/main 
amd64 Packages
ruby-railties:
  Installiert:   2:4.1.8-1+deb8u7
  Installationskandidat: 2:4.1.8-1+deb8u7
  Versionstabelle:
 *** 2:4.1.8-1+deb8u7 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.1.8-1+deb8u4 0
500 http://ftp.tu-chemnitz.de/pub/linux/debian/debian/ jessie/main 
amd64 Packages
ruby-actionmailer:
  Installiert:   2:4.1.8-1+deb8u7
  Installationskandidat: 2:4.1.8-1+deb8u7
  Versionstabelle:
 *** 2:4.1.8-1+deb8u7 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.1.8-1+deb8u4 0
500 http://ftp.tu-chemnitz.de/pub/linux/debian/debian/ jessie/main 
amd64 Packages
ruby-actionpack:
  Installiert:   2:4.1.8-1+deb8u7
  Installationskandidat: 2:4.1.8-1+deb8u7
  Versionstabelle:
 *** 2:4.1.8-1+deb8u7 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.1.8-1+deb8u4 0
500 http://ftp.tu-chemnitz.de/pub/linux/debian/debian/ jessie/main 
amd64 Packages
ruby-activerecord:
  Installiert:   2:4.1.8-1+deb8u7
  Installationskandidat: 2:4.1.8-1+deb8u7
  Versionstabelle:
 *** 2:4.1.8-1+deb8u7 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2:4.1.8-1+deb8u4 0
500 http://ftp.tu-chemnitz.de/pub/linux/debian/debian/ jessie/main 
amd64 Packages

And 

Bug#964389: bsdmainutils: leftover config files

2020-07-07 Thread Chris Hofstaedtler
* Michael Meskes  [200706 20:38]:
> On Mon, Jul 06, 2020 at 05:40:24PM +0200, Chris Hofstaedtler wrote:
> > It appears there is some gap in the necessary cleanups in
> > bsdmainutils. My "unstable" system has these files listed as owned
> > by bsdmainutils:
> > ... 
> 
> Gheez, I should have done a hard dependency from the get go. I guess this 
> comes
> from one update that didn't bring in calendar. Anyway, could you please verify
> for me that there are no config files in your calendar package? 

Here's some info, I hope its useful:

% dpkg -L bsdmainutils | grep etc
/etc/default/bsdmainutils
/etc/cron.daily/bsdmainutils
% cat /etc/default/bsdmainutils
cat: /etc/default/bsdmainutils: No such file or directory
% cat /etc/cron.daily/bsdmainutils
cat: /etc/cron.daily/bsdmainutils: No such file or directory

% dpkg -L calendar | grep etc
/etc
/etc/calendar
/etc/calendar/default
/etc/cron.daily
/etc/cron.daily/calendar
/etc/default
/etc/default/calendar
% cat /etc/calendar/default
/* This is the system-wide default calendar file, used if calendar(1)
 * is invoked by a user without a ~/calendar or ~/.calendar/calendar file.
 * It may be edited or even deleted to reflect local policy.
 *
 * In the standard setup, we simply include the default calendar
 * definitions from /usr/share/calendar/calendar.all.  If you want
 * only some of those definitions, copy calendar.all to /etc/calendar
 * and edit it there.  That way, your changes will be kept next time
 * you upgrade.
 *
 * The search path for include files is:
 *   /etc/calendar
 *   /usr/share/calendar
 */
#include "calendar.all"
% cat /etc/cron.daily/calendar
#!/bin/sh
# /etc/cron.daily/calendar: BSD mainutils calendar daily maintenance script
# Written by Austin Donnelly 

. /etc/default/calendar

[ x$RUN_DAILY = xtrue ] || exit 0

[ -x /usr/sbin/sendmail ] || exit 0

if [ ! -x /usr/bin/cpp ]; then
  echo "The cpp package is needed to run calendar."
  exit 1
fi

/usr/bin/calendar -a
% cat /etc/default/calendar
# Uncomment the following line if you'd like all of your users'
# ~/calendar files to be checked daily.  Calendar will send them mail
# to remind them of upcoming events.  See calendar(1) for more details.
#RUN_DAILY=true

% dpkg -l bsdmainutils calendar ncal
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---
ii  bsdmainutils   12.1.3   all  collection of more utilities from 
FreeBSD
ii  calendar   12.1.3   amd64display upcoming dates and provide 
reminders
ii  ncal   12.1.3   amd64display a calendar and the date of 
Easter

Chris



Bug#964433: libtomcat9-java: tomcatjss fails to build with the latest libtomcat9-java

2020-07-07 Thread Timo Aaltonen
Package: libtomcat9-java
Version: 9.0.37-1
Severity: important

Hi,

A recent update has broke tomcatjss build:

[javac] 
/<>/tomcat-8.5/src/org/dogtagpki/tomcat/JSSImplementation.java:25: 
error: package org.apache.tomcat.util.net.jsse does not exist
[javac] import org.apache.tomcat.util.net.jsse.JSSEImplementation;

It built fine with 9.0.35-1 when 7.5.0~a1-1 was uploaded to experimental, now a 
new beta2
and the version in sid both fail.



Bug#964434: nextcloud-desktop: Please move the menu entry of nextcloud-dektop to internet

2020-07-07 Thread Mathias Palm
Package: nextcloud-desktop
Version: 2.6.4-1
Severity: minor
Tags: a11y

Dear Maintainer,

in order to make the program more accessible for the common user I would 
suggest to move it to the menupoine Internet. This is the place where most 
other desktop clients for internet services reside.

Kind regards
Mathias Palm 


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

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

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


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US:en (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nextcloud-desktop depends on:
ii  libc6 2.30-8
ii  libcloudproviders00.3.0-3
ii  libgcc-s1 10.1.0-3
ii  libglib2.0-0  2.64.3-1
ii  libnextcloudsync0 2.6.4-1
ii  libqt5core5a  5.12.5+dfsg-10+b1
ii  libqt5dbus5   5.12.5+dfsg-10+b1
ii  libqt5gui55.12.5+dfsg-10+b1
ii  libqt5keychain1   0.10.0-1
ii  libqt5network55.12.5+dfsg-10+b1
ii  libqt5sql5-sqlite 5.12.5+dfsg-10+b1
ii  libqt5webenginecore5  5.12.5+dfsg-7+b3
ii  libqt5webenginewidgets5   5.12.5+dfsg-7+b3
ii  libqt5webkit5 5.212.0~alpha4-1+b1
ii  libqt5widgets55.12.5+dfsg-10+b1
ii  libqt5xml55.12.5+dfsg-10+b1
ii  libstdc++610.1.0-3
ii  nextcloud-desktop-common  2.6.4-1
ii  nextcloud-desktop-l10n2.6.4-1

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  2.6.4-1

nextcloud-desktop suggests no packages.

-- no debconf information



Bug#964370: Thanks for fixing

2020-07-07 Thread Bernhard Reiter
Thanks for the fast fix.
(Now I just have to wait for the build to get to servers. ;))



Bug#964014: Update iptables in buster backports to 1.8.5+ ?

2020-07-07 Thread Arturo Borrero Gonzalez
On Tue, 30 Jun 2020 08:10:49 -0400 Etienne Champetier
 wrote:
> Package: iptables
> Version: 1.8.3-2~bpo10+1
> 
> Hello Debian Netfilter Packaging Team,
> 
> Is it planned to have iptables updated in buster backports to 1.8.5+ ?
> I need it to fix https://bugzilla.netfilter.org/show_bug.cgi?id=1422
> At least the following commit:
> https://git.netfilter.org/iptables/commit/?id=18f01acbdefb211ebfefb728d2b6843c59ae06db
> 

I'm afraid this wont happen soon on my side.

Among other things, we would need to also backport libnftnl first.

Would you be able to contribute or help with this in any way?



Bug#964334: segfault repeatedly

2020-07-07 Thread Stefano Zacchiroli
I've seen this bug has been marked as "more info" (with no comment), but
I'm not clear on which additional info are needed and how I can provide
them.  Advice on how I can help is welcome :-)



Bug#964236: php-redis: After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash

2020-07-07 Thread johnw
Still crash.

ii  php-redis   5.3.0+4.3.0-2  amd64
   PHP extension for interfacing with Redis

php-fpm7.4[128121]: segfault at 10001 ip 563936cd83b6 sp
7fffac26b658 error 4 in php-fpm7.4[563936b35000+268000]
[72499.538048] Code: 85 8b 7a e7 ff 48 8b 47 10 48 83 c0 38 48 39 47 18
48 89 c2 48 89 47 10 48 0f 43 57 18 48 8b 47 50 48 89 57 18 48 85 c0 74
0a <48> 8b 10 48 89 57 50 c3 66 90 be 06 00 00 00 e9 96 e5 ff ff 66 0f
[72506.900324] traps: php-fpm7.4[128120] general protection fault
ip:563936cd9634 sp:7fffac26b6a8 error:0 in php-fpm7.4[563936b35000+268000]
[72506.970571] traps: php-fpm7.4[128118] general protection fault
ip:563936cd9634 sp:7fffac26b6a8 error:0 in php-fpm7.4[563936b35000+268000]
[72508.372771] traps: php-fpm7.4[128122] general protection fault
ip:563936cd9634 sp:7fffac26b6a8 error:0 in php-fpm7.4[563936b35000+268000]
[72508.404409] traps: php-fpm7.4[128125] general protection fault
ip:563936cd9634 sp:7fffac26b6a8 error:0 in php-fpm7.4[563936b35000+268000]

Thanks.

On 7/7/20 3:04 PM, Ondřej Surý wrote:
> Version: 5.3.0+4.3.0-2
> 
> I have pulled 5.3.1 prerelease branch into the latest package, so the -2
> should no longer crash on you.
> 
> Ondrej
> 
> On Sat, 4 Jul 2020 at 03:45, John Wong  > wrote:
> 
> Package: php-redis
> Version: After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash
> Severity: normal
> 
> Dear Maintainer,
>      After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash.
> 
>      traps: php-fpm7.4[198823] general protection fault
> ip:55da0ea4c634 sp:7ffc14657008 error:0 in
> php-fpm7.4[55da0e8a8000+268000]
>      php-fpm7.4[198824]: segfault at 10001 ip 55da0ea4b3b6
> sp 7ffc14656fb8 error 4 in php-fpm7.4[55da0e8a8000+268000]
>      Code: 85 8b 7a e7 ff 48 8b 47 10 48 83 c0 38 48 39 47 18 48 89 c2
>      48 89 47 10 48 0f 43 57 18 48 8b 47 50 48 89 57 18 48 85 c0 74 0a
>      <48> 8b 10 48 89 57 50 c3 66 90 be 06 00 00 00 e9 96 e5 ff f
>      f 66 0f
> 
>      Please help, thank you.
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>    * What led up to the situation?
>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?
>    * What was the outcome of this action?
>    * What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 


-- 
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC



Bug#879014: gpgme1.0: FTBFS on some arches: Qt needs a compile with -fPIC (PIE is not enough), hardening downgrades to PIE

2020-07-07 Thread Dmitry Shachnev
Hi Daniel!

On Wed, Jul 01, 2020 at 05:20:40PM -0400, Daniel Kahn Gillmor wrote:
> gniibe also identified a problem in how Qt reports compilation warnings
> related to the PIE/PIC mismatch.  I've tried to address that in the
> following patch to qtbase-opensource-src:
>
> From 107f387ea625a67ef03b916ef965761f36de2bf4 Mon Sep 17 00:00:00 2001
> From: Daniel Kahn Gillmor 
> Date: Wed, 1 Jul 2020 17:15:12 -0400
> Subject: [PATCH] Clarify warning message about PIC/PIE
>
> As noted in discussion at https://dev.gnupg.org/T4982#135524, the
> warning message produced when there is a mismatch between
> position-independence of the Qt library and other compilations, the
> warning produced by Qt is confusing.
>
> This is an attempt to express a warning that is more closely aligned
> with the actual test used.

Thanks for the patch! I have forwarded it upstream, with minor commit
message corrections:

https://codereview.qt-project.org/c/qt/qtbase/+/307046

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#964435: buster-pu: package glib-networking/2.58.0-2+deb10u1

2020-07-07 Thread Simon McVittie
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Older versions of glib-networking's TLS implementation have a security
issue (CVE-2020-13645): according to the documentation, if the caller
does not specify a server identity, glib-networking should fail closed
(reject all server identities), but in fact it failed open (accept all
server identities).

The only application that was believed to be vulnerable to this
in practice is balsa, which only became vulnerable in post-buster
versions; older versions such as the one in buster implemented their
own TLS. However, if there are other applications in buster that are
vulnerable to this, then they will regress (become unable to connect to
TLS servers) with this update.

The security team have indicated that they would prefer to handle this
via proposed-updates.

Thanks,
smcv
diffstat for glib-networking-2.58.0 glib-networking-2.58.0

 changelog|8 
 gbp.conf |4 
 patches/Return-bad-identity-error-if-identity-is-unset.patch |  158 +++
 patches/debian/01_connection_test.patch  |4 
 patches/series   |1 
 5 files changed, 171 insertions(+), 4 deletions(-)

diff -Nru glib-networking-2.58.0/debian/changelog glib-networking-2.58.0/debian/changelog
--- glib-networking-2.58.0/debian/changelog	2018-12-24 14:40:07.0 +
+++ glib-networking-2.58.0/debian/changelog	2020-07-07 09:30:02.0 +0100
@@ -1,3 +1,11 @@
+glib-networking (2.58.0-2+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * d/p/Return-bad-identity-error-if-identity-is-unset.patch:
+Backport fix for CVE-2020-13645 from upstream (Closes: #961756)
+
+ -- Simon McVittie   Tue, 07 Jul 2020 09:30:02 +0100
+
 glib-networking (2.58.0-2) unstable; urgency=medium
 
   * Add -Wl,-O1 to our LDFLAGS
diff -Nru glib-networking-2.58.0/debian/gbp.conf glib-networking-2.58.0/debian/gbp.conf
--- glib-networking-2.58.0/debian/gbp.conf	2018-12-24 14:40:07.0 +
+++ glib-networking-2.58.0/debian/gbp.conf	2020-07-07 09:30:02.0 +0100
@@ -1,7 +1,7 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
-upstream-branch = upstream/latest
+debian-branch = debian/buster
+upstream-branch = upstream/2.58.x
 upstream-vcs-tag = %(version)s
 
 [buildpackage]
diff -Nru glib-networking-2.58.0/debian/patches/debian/01_connection_test.patch glib-networking-2.58.0/debian/patches/debian/01_connection_test.patch
--- glib-networking-2.58.0/debian/patches/debian/01_connection_test.patch	2018-12-24 14:40:07.0 +
+++ glib-networking-2.58.0/debian/patches/debian/01_connection_test.patch	2020-07-07 09:30:02.0 +0100
@@ -11,10 +11,10 @@
  1 file changed, 2 deletions(-)
 
 diff --git a/tls/tests/meson.build b/tls/tests/meson.build
-index 261fa1e..fb94f22 100644
+index f7489f0..88a 100644
 --- a/tls/tests/meson.build
 +++ b/tls/tests/meson.build
-@@ -23,8 +23,6 @@ envs = [
+@@ -25,8 +25,6 @@ envs = [
  test_programs = [
['certificate', [], deps],
['file-database', [], deps],
diff -Nru glib-networking-2.58.0/debian/patches/Return-bad-identity-error-if-identity-is-unset.patch glib-networking-2.58.0/debian/patches/Return-bad-identity-error-if-identity-is-unset.patch
--- glib-networking-2.58.0/debian/patches/Return-bad-identity-error-if-identity-is-unset.patch	1970-01-01 01:00:00.0 +0100
+++ glib-networking-2.58.0/debian/patches/Return-bad-identity-error-if-identity-is-unset.patch	2020-07-07 09:30:02.0 +0100
@@ -0,0 +1,158 @@
+From: Michael Catanzaro 
+Date: Mon, 4 May 2020 17:47:28 -0500
+Subject: Return bad identity error if identity is unset
+
+When the server-identity property of GTlsClientConnection is unset, the
+documentation sasy we need to fail the certificate verification with
+G_TLS_CERTIFICATE_BAD_IDENTITY. This is important because otherwise,
+it's easy for applications to fail to specify server identity.
+
+Unfortunately, we did not correctly implement the intended, documented
+behavior. When server identity is missing, we check the validity of the
+TLS certificate, but do not check if it corresponds to the expected
+server (since we have no expected server). Then we assume the identity
+is good, instead of returning bad identity, as documented. This means,
+for example, that evil.com can present a valid certificate issued to
+evil.com, and we would happily accept it for paypal.com.
+
+[smcv: Backport to glib-networking 2.58.x, which didn't have OpenSSL
+support or the GTlsConnectionBase base-class]
+
+Bug: https://gitlab.gnome.org/GNOME/glib-networking/-/issues/135
+Origin: backport, 2.62.4, commit:29513946809590c4912550f6f8620468f9836d94
+---
+ tls/gnutls/gtlsconnection-gnutls.c | 20 ++-
+ tls/tests/connection.c | 69 ++
+ 2 files change

Bug#964436: automake: install-info: warning: no info dir entry in `/usr/share/info/automake-history.info.gz'

2020-07-07 Thread Paul Wise
Package: automake
Version: 1:1.16.2-3
Severity: normal
File: /usr/share/info/automake-history.info.gz
Usertags: warnings

install-info warns about automake-history not having a dir entry:

Preparing to unpack .../automake_1%3a1.16.2-3_all.deb ...
Unpacking automake (1:1.16.2-3) over (1:1.16.2-1) ...
Setting up automake (1:1.16.2-3) ...
Processing triggers for install-info (6.7.0.dfsg.2-5) ...
install-info: warning: no info dir entry in 
`/usr/share/info/automake-history.info.gz'
Processing triggers for man-db (2.9.3-1) ...

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-nouveau-extra-crash-debug-info-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages automake depends on:
ii  autoconf   2.69-11.1
ii  autotools-dev  20180224.1

automake recommends no packages.

Versions of packages automake suggests:
ii  autoconf-doc   2.69-11.1
ii  gnu-standards  2010.03.11-1.1

-- no debconf information


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#961756: glib-networking: CVE-2020-13645: GTlsClientConnection silently ignores unset server identity

2020-07-07 Thread smcv
On Thu, 28 May 2020 at 22:41:19 +0200, Salvatore Bonaccorso wrote:
> CVE-2020-13645[0]:
> | In GNOME glib-networking through 2.64.2, the implementation of
> | GTlsClientConnection skips hostname verification of the server's TLS
> | certificate if the application fails to specify the expected server
> | identity. This is in contrast to its intended documented behavior, to
> | fail the certificate verification. Applications that fail to provide
> | the server identity, including Balsa before 2.5.11 and 2.6.x before
> | 2.6.1, accept a TLS certificate if the certificate is valid for any
> | host.

A reproducer is available from
https://gitlab.gnome.org/GNOME/balsa/-/issues/34 (look for
test-tls.tar.xz).

Preconditions:
* Compile the test program from test-tls.tar.xz (attached)
* Have a test server with two names, and no valid cert for one of them.
  people.debian.org works: it has a valid cert for people.debian.org,
  but not for paradis.debian.org. (Check this with a browser first,
  in case SNI gets added later.)

Bad result: connecting without specifying a server identity succeeds.

$ sudo apt-get install glib-networking=2.58.0-2
$ ./test_server_valid people.debian.org:443 0
** Message: 09:16:43.133: set remote server_identity: no
** Message: 09:16:43.534: g_tls_connection_handshake(): OK (no error)
$ ./test_server_valid people.debian.org:443 1
** Message: 09:16:02.406: set remote server_identity: yes
** Message: 09:16:02.779: g_tls_connection_handshake(): OK (no error)
$ ./test_server_valid paradis.debian.org:443 0
** Message: 09:18:36.097: set remote server_identity: no
** Message: 09:18:36.495: g_tls_connection_handshake(): OK (no error)
$ ./test_server_valid paradis.debian.org:443 1
** Message: 09:18:37.722: set remote server_identity: yes
** Message: 09:18:38.132: cert_accept_cb: conn=0x561d080d8150, 
cert=0x7fdbcc005eb0 for 'people.debian.org', error=0x2
** Message: 09:18:38.132: g_tls_connection_handshake(): ERROR (Unacceptable TLS 
certificate)

Good result: the only way to avoid G_TLS_CERTIFICATE_BAD_IDENTITY is to
specify the server's name in the form that appears in its certificate.

$ sudo dpkg -i glib-networking_2.58.0-2+deb10u1_amd64.deb
$ ./test_server_valid people.debian.org:443 0
** Message: 09:20:01.640: set remote server_identity: no
** Message: 09:20:02.045: cert_accept_cb: conn=0x55afead25150, 
cert=0x7f1f3c005eb0 for 'people.debian.org', error=0x2
** Message: 09:20:02.045: g_tls_connection_handshake(): ERROR (Unacceptable TLS 
certificate)
$ ./test_server_valid people.debian.org:443 1
** Message: 09:20:03.338: set remote server_identity: yes
** Message: 09:20:03.737: g_tls_connection_handshake(): OK (no error)
$ ./test_server_valid paradis.debian.org:443 0 
** Message: 09:20:08.924: set remote server_identity: no
** Message: 09:20:09.332: cert_accept_cb: conn=0x5620d607a150, 
cert=0x7f38500066b0 for 'people.debian.org', error=0x2
** Message: 09:20:09.332: g_tls_connection_handshake(): ERROR (Unacceptable TLS 
certificate)
$ ./test_server_valid paradis.debian.org:443 1
** Message: 09:20:10.552: set remote server_identity: yes
** Message: 09:20:10.954: cert_accept_cb: conn=0x560a74e26150, 
cert=0x7f88e8005eb0 for 'people.debian.org', error=0x2
** Message: 09:20:10.955: g_tls_connection_handshake(): ERROR (Unacceptable TLS 
certificate)

(0x2 is G_TLS_CERTIFICATE_BAD_IDENTITY.)

smcv
/*
gcc -Wall -O -g $(pkg-config --cflags glib-2.0 gio-2.0 gcr-3) test_server_valid.c -o test_server_valid \
	$(pkg-config --libs glib-2.0 gio-2.0 gcr-3)
*/

#include 
#include 
#include 
#define GCR_API_SUBJECT_TO_CHANGE
#include 

static gboolean
cert_accept_cb(GTlsConnection *conn, GTlsCertificate *peer_cert, GTlsCertificateFlags errors, gpointer user_data)
{
	GByteArray *der_data;
GcrCertificate *gcr_cert;
gchar *subject;

	g_object_get(peer_cert, "certificate", &der_data, NULL);
	gcr_cert = gcr_simple_certificate_new(der_data->data, der_data->len);
	g_byte_array_unref(der_data);
	subject = gcr_certificate_get_subject_name(gcr_cert);
	g_object_unref(gcr_cert);
	g_message("%s: conn=%p, cert=%p for '%s', error=0x%x", __func__, conn, peer_cert, subject, errors);
	g_free(subject);
	return FALSE;
}

int main(int argc, char **argv)
{
	GSocketClient *sock;
	GSocketConnectable *remote_address;
	GSocketConnection *plain_conn;
	GIOStream *tls_conn;
	gboolean set_ident;
	gboolean tls_ok;
	GError *error = NULL;

	if (argc < 3) {
		g_error("usage: %s connect 0|1 [cafile]", argv[0]);
	}
	set_ident = (atoi(argv[2]) != 0);

	sock = g_socket_client_new();
	remote_address = g_network_address_parse(argv[1], 65000, &error);
	if (remote_address == NULL) {
		g_error("g_network_address_parse(%s): %s", argv[1], error->message);
	}
	plain_conn = g_socket_client_connect(sock, remote_address, NULL, &error);
	if (plain_conn == NULL) {
		g_error("g_socket_client_connect(): %s", error->message);
	}
	g_message("set remote server_identity: %s", set_ident ? "yes" : "no");
	tls_conn = g_tls_client_connection_new(G_IO_STREAM(pl

Bug#964111: dpkg-source: False positive 'points outside source root'

2020-07-07 Thread Holger Levsen
On Mon, Jul 06, 2020 at 09:08:43PM -0700, Felix Lechner wrote:
> > not sure if this is the same bug or just a similar one:
> > lrwxrwxrwx 1 user user 9 Jul  3 16:07 debian/munin.service -> /dev/null
> As for Holger's package, Lintian also flags that condition. Source
> packages can be unpacked anywhere. We likewise consider absolute
> symlink targets unacceptable there.
> W: munin source: absolute-symbolic-link-target-in-source
> debian/munin.service -> /dev/null

sigh. so IMNSHO now lintian *and* dpkg are buggy. Or point me to policy
which prohibits files pointing to /dev/null. This worked for years.

(I haven't cloned the dpkg bug yet, as I believed Guillem would upload a
fix quickly and thus I wanted to prevent busy paperwork. IMO the bug
should be cloned and the severity raised to serious for the clone.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Bug#652747: listadmin: Patched listadmin removing members from current Mailman

2020-07-07 Thread Benedikt Wildenhain (BO)
Package: listadmin
Version: 2.42-1.3
Followup-For: Bug #652747

Hello,

I had no luck with the patch provided here (and having GNU Mailman
2.1.29-1+deb10u1 from Debian buster running on the server).

However,
https://wiki.list.org/DOC/Additional%20web%20administration%20tools
provides a way to unsubscribe members using curl. I translated the
suggested command into perl code and integrated it into listadmin as a
fallback. Not an elegant solution, but works for me.

https://salsa.debian.org/benedikt-guest/listadmin/-/commit/9b796a60eccb253c1655ca5419ad8aface72e1aa

Regards,
Benedikt Wildenhain



Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1

2020-07-07 Thread R hertoric
Samuel Henrique do you know where backdoor is I believe you don't

On Fri, Jul 3, 2020, 4:24 PM Samuel Henrique  wrote:

> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
>
> A backported upstream patch [0] is required to fix #940284 [1] on nmap;
> Bug title: autogeneration of ssl key in ssl server mode of ncat is broken
>
> The issue itself is well described in both BTS [1] and the upstream
> bug report [2], but the summary of it is that the openssl shipped with
> Buster requires a key with minimum size of 2048b, while nmap 7.70
> generates one sized 1024b. This has been fixed in 7.80 (which is the
> version on Testing right now).
>
> The debdiff is attached to this email,
>
> Thanks,
>
> [0]
> https://github.com/nmap/nmap/commit/25db5fbb0d8fb88b6e7f4f298c862cd05ed0f8b1
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940284
> [2] https://github.com/nmap/nmap/pull/1310
>
> --
> Samuel Henrique 
>


Bug#964437: Fails to install

2020-07-07 Thread Yuri D'Elia
Package: elpa-magit
Version: 2.99.0.git0957.ge8c7bd03-1
Severity: important

The newer git version removes the dependency on elpa-magit-popup which
seems to be required:

...
In toplevel form:
magit-tag.el:30:1:Error: Cannot open load file: No such file or directory, 
magit-popup

In toplevel form:
magit-worktree.el:30:1:Error: Cannot open load file: No such file or directory, 
magit-popup
ERROR: install script from elpa-magit package failed
dpkg: error processing package elpa-magit (--configure):
 installed elpa-magit package post-installation script subprocess returned 
error exit status
Errors were encountered while processing:
 elpa-magit



Bug#964438: apt-listbugs: dns error when running from cron job

2020-07-07 Thread Oswald Buddenhagen
Package: apt-listbugs
Version: 0.1.32
Severity: normal

for some days/weeks now, i get this mail every day:

--
From: apt-listbugs timer 
To: root
Subject: prefclean output on ugly

/usr/libexec/apt-listbugs/prefclean:
E: getaddrinfo: Temporary failure in name resolution (bugs.debian.org:80)
E: Exiting with error
---

the program works just fine when invoked from the command line, and 
these errors are a little bit too consistent to be actual network 
outages, so i suspect a permission problem in the configuration of the 
systemd timer (note that apparmor is enabled).

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

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

Versions of packages apt-listbugs depends on:
ii  apt 2.1.6
ii  ruby1:2.7+1
ii  ruby-debian 0.3.10+b3
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b11
ii  ruby-xmlparser  0.7.3-3+b4

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-2

-- no debconf information



Bug#949367: stretch-pu: package wpa/2:2.4-1+deb9u5

2020-07-07 Thread Andrej Shadura
Control: retitle -1  stretch-pu: package wpa/2:2.4-1+deb9u6

Hi,

On Sun, 5 Jul 2020, at 18:08, Cyril Brulebois wrote:
> Andrej Shadura  (2020-05-03):
> > Oh, I somehow forgot about it. Please see attached debdiff; I have
> > also added the same minor fix I wanted to push into buster, I think
> > it’s worth it.
> 
> First thing first: it builds! :D
> 
> Additionally, a d-i netboot-gtk image built with the resulting udeb,
> with the contents of the firmware-iwlwifi package dumped into it, works
> fine on my X230. So there are at least no obvious regressions hidden in
> there (for this specific piece of hardware).
> 
> No objections, thanks.

Thanks!

Apparently, dgit is difficult to convince to allow a repeated upload with the 
same version, so I’m going to add a new entry to the changelog before the 
upload with no other changes.

-- 
Cheers,
 Andrej



Bug#964440: flit: please make the build reproducible

2020-07-07 Thread Chris Lamb
Source: flit
Version: 2.3.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
flit could not be built reproducibly.

This is because it:

  a) It embeds a RECORD file that contains non-deterministic filename
  contents. 99% sure this is being generated by build.py.

  b) The manpage is being generated incorrectly, and actually is a
  manual page depicting an error message:

.TH TRACEBACK "1" "July 2020" "Traceback (most recent call last):" "User 
Commands"
.SH NAME
Traceback \- manual page for Traceback (most recent call last):
.SH DESCRIPTION
.SS "Traceback (most recent call last):"
.IP
File "debian/flit/usr/bin/flit", line 2, in 
.IP
from flit import main
.PP
ModuleNotFoundError: No module named 'flit'
.IP
File "debian/flit/usr/bin/flit", line 2, in 

Patch attached. For a), we simply delete this file and for b) we fix
the generation by setting the right/full PYTHONPATH.

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


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2020-07-07 10:56:23.073323225 +0100
--- b/debian/rules  2020-07-07 11:11:43.945880028 +0100
@@ -17,6 +17,7 @@
 override_dh_auto_install:
cp debian/build.py .
python3 build.py
+   find -type f -name RECORD -delete
rm -f build.py
dh_install
 
@@ -24,7 +25,7 @@
dh_python3 -p flit
 
 override_dh_installman:
-   PYTHONPATH=$(CURDIR) help2man -n flit -s 1 \
+   PYTHONPATH=$(CURDIR):$(CURDIR)/flit_core help2man -n flit -s 1 \
-o debian/flit.1 \
--version-string=$(pkgversion) \
--no-discard-stderr --no-info \


Bug#964441: geeqie: No image is rendered, only white rectangle visible

2020-07-07 Thread Florian
Package: geeqie
Version: 1:1.5.1-11
Severity: important

No image is shown, instead only a white rectangle is visible.

Tested for png and jpg images.

I think this occurs only since the last update (GTK3).

I am on gnome/wayland.

Might be this one: https://github.com/BestImageViewer/geeqie/issues/539

GPU acceleration is off.


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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.5.1-11
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-1
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-1
ii  libexiv2-27  0.27.2-8
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc-s110.1.0-4
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.3-2
ii  libgtk-3-0   3.24.20-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-4+b1
ii  liblirc-client0  0.10.1-6.2
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpoppler-glib8 0.71.0-6
ii  libstdc++6   10.1.0-4
ii  libtiff5 4.1.0+git191117-2
ii  sensible-utils   0.0.12+nmu1

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.3-1
ii  exiftran 2.10-4
ii  exiv20.27.2-8
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  librsvg2-common  2.48.7-1
ii  ufraw-batch  0.22-4
ii  zenity   3.32.0-5

Versions of packages geeqie suggests:
pn  geeqie-dbg 
ii  gimp   2.10.18-1
pn  libjpeg-progs  
pn  ufraw  
pn  xpaint 

-- no debconf information



Bug#964442: cyrus-common: chk_cyrus should'nt be used if CHKCYRUS=0

2020-07-07 Thread Jean Charles Delépine
Package: cyrus-common
Version: 3.2.2-1
Severity: wishlist
Tags: patch

On murdur configs this cronjob sent full maibox list in error on frontend and 
mupdate servers :

020-07-07T06:25:06.401681+02:00 cyrus-mupdate cyrus/chk_cyrus[443016]: 
requested partition directory for unknown partition 'default'
2020-07-07T06:25:06.406333+02:00 cyrus-mupdate2 cyrus/chk_cyrus[443016]: 
IOERROR: opening index user.: Invalid mailbox name
2020-07-07T06:25:06.406576+02:00 cyrus-mupdate cyrus/chk_cyrus[443016]: 
requested partition directory for unknown partition 'default'
2020-07-07T06:25:06.407663+02:00 cyrus-mupdate cyrus/chk_cyrus[443016]: 
IOERROR: opening index user..Drafts: Invalid mailbox name


--- debian/cyrus-common.cyrus-imapd.cron.daily.old  2020-07-07 
11:51:41.023622830 +0200
+++ debian/cyrus-common.cyrus-imapd.cron.daily  2020-07-07 11:51:58.507483957 
+0200
@@ -61,7 +61,7 @@
 }
 
 # 3. runs chk_cyrus
-[ -x /usr/lib/cyrus/bin/chk_cyrus ] && {
+[ $CHKCYRUS -ne 0 ] && [ -x /usr/lib/cyrus/bin/chk_cyrus ] && {
tmpfile=$(mktemp -t cyrus-daily-cronjob.XX)
trap 'rm -f "${tmpfile}"' 0
 #  su "--command=/usr/sbin/chk_cyrus" - cyrus | ...

-- System Information:
Not relevant
--- debian/cyrus-common.cyrus-imapd.cron.daily.old  2020-07-07 
11:51:41.023622830 +0200
+++ debian/cyrus-common.cyrus-imapd.cron.daily  2020-07-07 11:51:58.507483957 
+0200
@@ -61,7 +61,7 @@
 }
 
 # 3. runs chk_cyrus
-[ -x /usr/lib/cyrus/bin/chk_cyrus ] && {
+[ $CHKCYRUS -ne 0 ] && [ -x /usr/lib/cyrus/bin/chk_cyrus ] && {
tmpfile=$(mktemp -t cyrus-daily-cronjob.XX)
trap 'rm -f "${tmpfile}"' 0
 #  su "--command=/usr/sbin/chk_cyrus" - cyrus | ...


Bug#964445: libbluray: binary-all FTBFS

2020-07-07 Thread Adrian Bunk
Source: libbluray
Version: 1:1.2.0-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libbluray&arch=all&ver=1%3A1.2.0-2&stamp=1594068597&raw=0

...
 fakeroot debian/rules binary-indep
dh binary-indep --with javahelper
   dh_testroot -i
   dh_prep -i
   dh_install -i
dh_install: warning: Cannot find (any matches for) "usr/share/java" (tried in 
., debian/tmp)

dh_install: warning: libbluray-bdj missing files: usr/share/java
dh_install: error: missing files, aborting
make: *** [debian/rules:23: binary-indep] Error 25



Bug#964443: javahelper: Please change the dependency to bsdextrautils | bsdmainutils

2020-07-07 Thread Adrian Bunk
Package: javahelper
Version: 0.73
Severity: normal

Now that the bsdmainutils dust has settled, please change
  bsdmainutils, bsdextrautils
in the dependencies to
  bsdextrautils | bsdmainutils

hexdump is now in the new bsdextrautils package,
and this is the preferred dependency.

bsdmainutils either contains hexdump (in buster),
or depends on bsdextrautils (in unstable).



Bug#964444: systemd-timesyncd: time synchronization suddenly stopped working

2020-07-07 Thread Vincent Lefevre
Package: systemd-timesyncd
Version: 245.6-1
Severity: important

systemd-timesyncd no longer seems to work. I couldn't find any reason in the 
logs.
Now there's a 5-second delta!

zira:~> timedatectl timesync-status
   Server: (null) (3.debian.pool.ntp.org)   
Poll interval: 34min 8s (min: 32s; max 34min 8s)
 Leap: normal   
  Version: 4
  Stratum: 2
Reference: 596DFB17 
Precision: 1us (-24)
Root distance: 40.580ms (max: 5s)   
   Offset: -1.087495s   
Delay: 2.156880s
   Jitter: 2.300948s
 Packet count: 620  

zira:~> timedatectl show-timesync
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 
2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=3.debian.pool.ntp.org
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=34min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-24, 
RootDelay=30.776ms, RootDispersion=25.192ms, Reference=596DFB17, 
OriginateTimestamp=Mon 2020-07-06 20:06:14 CEST, ReceiveTimestamp=Mon 
2020-07-06 20:06:14 CEST, TransmitTimestamp=Mon 2020-07-06 20:06:14 CEST, 
DestinationTimestamp=Mon 2020-07-06 20:06:16 CEST, Ignored=yes PacketCount=620, 
Jitter=2.300948s }
Frequency=32768000

zira:~> systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
 Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
vendor preset: enabled)
 Active: active (running) since Sat 2020-07-04 00:39:52 CEST; 3 days ago
   Docs: man:systemd-timesyncd.service(8)
   Main PID: 684 (systemd-timesyn)
 Status: "Idle."
  Tasks: 2 (limit: 19071)
 Memory: 2.8M
 CGroup: /system.slice/systemd-timesyncd.service
 └─684 /lib/systemd/systemd-timesyncd

Jul 05 23:40:38 zira systemd-timesyncd[684]: Timed out waiting for reply from 
37.187.174.185:123 (1.debian.pool.ntp.org).
Jul 05 23:40:51 zira systemd-timesyncd[684]: Initial synchronization to time 
server 185.51.192.34:123 (2.debian.pool.ntp.org).
Jul 06 10:50:50 zira systemd-timesyncd[684]: Initial synchronization to time 
server 51.15.191.239:123 (0.debian.pool.ntp.org).
Jul 06 12:30:47 zira systemd-timesyncd[684]: Initial synchronization to time 
server 4.53.160.75:123 (0.debian.pool.ntp.org).
Jul 06 13:50:59 zira systemd-timesyncd[684]: Initial synchronization to time 
server 91.206.16.3:123 (0.debian.pool.ntp.org).
Jul 06 14:08:11 zira systemd-timesyncd[684]: Initial synchronization to time 
server 162.159.200.1:123 (0.debian.pool.ntp.org).
Jul 06 17:32:15 zira systemd-timesyncd[684]: Initial synchronization to time 
server 193.70.90.148:123 (0.debian.pool.ntp.org).
Jul 06 19:53:13 zira systemd-timesyncd[684]: Initial synchronization to time 
server 94.130.184.193:123 (0.debian.pool.ntp.org).
Jul 06 19:57:43 zira systemd-timesyncd[684]: Timed out waiting for reply from 
94.130.184.193:123 (0.debian.pool.ntp.org).
Jul 06 19:57:44 zira systemd-timesyncd[684]: Initial synchronization to time 
server 91.207.136.55:123 (0.debian.pool.ntp.org).

If I understand the "timedatectl show-timesync" output, it stopped
working on 2020-07-06 20:06:16 CEST. I suspended my laptop shortly
after this time. But I do that several times a day. The only awkward
thing I could notice in the logs is thousands of messages

Jul 07 01:36:34 zira systemd-logind[837]: Got message type=signal sender=:1.0 
destination=n/a path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=Reloading cookie=9958 
reply_cookie=0 signature=b error-name=n/a error-message=n/a
Jul 07 01:36:34 zira systemd-logind[837]: Got message type=signal sender=:1.0 
destination=n/a path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=9959 
reply_cookie=0 signature=so error-name=n/a error-message=n/a
Jul 07 01:36:34 zira systemd-logind[837]: Got message type=signal sender=:1.0 
destination=n/a path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=9960 
reply_cookie=0 signature=so error-name=n/a error-message=n/a
Jul 07 01:36:34 zira systemd-logind[837]: Got message type=signal sender=:1.0 
destination=n/a path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=9961 
reply_cookie=0 signature=so error-name=n/a error-message=n/a
Jul 07 01:36:34 zira systemd-logind[837]: Got message type=signal sender=:1.0 
destination=n/a path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=9962 
reply_cookie=0 signature=so error-name=n/a error-message=n/a
Jul 07 01:36:34 zira systemd-logind[837]: Got message type=signal sender=:1.0 
destination=n/a path=/org/freedesktop/systemd1 
interf

Bug#953875: runit - default installation can force init switch

2020-07-07 Thread Lorenzo Puliti
Package: runit
Version: 2.1.2-36
Followup-For: Bug #953875
Control: tag -1 patch

There is an open RFS bug (#960940) on mentors that fixes this bug.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960940

Lorenzo


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.30-8
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-36

runit suggests no packages.

-- Configuration Files:
/etc/default/runit changed [not included]

-- no debconf information



Bug#964437: Fails to install

2020-07-07 Thread Yuri D'Elia
On Tue, Jul 07 2020, Rémi Vanicat wrote:
> Could you show me the line 30 of the file
>
> /usr/share/emacs/site-lisp/elpa-src/magit-2.99.0/magit-tag.el

(require 'magit)

> Also please check if there is another version of magit installed in
> /root/.emacs.d or in /usr/local/share/emacs/site-lisp/ or even in
> /usr/share/emacs/site-lisp/ ?

No, but I found the issue after looking deeper :/

It's actually due to the elpa-magit-annex package which does

  (require 'magit-popup)

but still only depends on elpa-magit.



Bug#952897: opentmpfiles: Please make opentmpfiles to be drop-in replacement to systemd-tmpfiles

2020-07-07 Thread Lorenzo Puliti
Package: opentmpfiles
Followup-For: Bug #952897
Control: tag -1 patch

Hi,

the following MR on Salsa might fix this bug
https://salsa.debian.org/debian/opentmpfiles/-/merge_requests/2

Best Regards,
Lorenzo



Bug#964437: Fails to install

2020-07-07 Thread Rémi Vanicat
Hello,

The content of your magit seem to not be the one I upload (and just
download again to check).

Testing in a fakeroot confirm that the package in the archive don’t seem
to have your problem.

Could you show me the line 30 of the file

/usr/share/emacs/site-lisp/elpa-src/magit-2.99.0/magit-tag.el

Also please check if there is another version of magit installed in
/root/.emacs.d or in /usr/local/share/emacs/site-lisp/ or even in
/usr/share/emacs/site-lisp/ ?

Thanks



Le 07 juillet 2020, Yuri D'Elia a écrit:

> Package: elpa-magit
> Version: 2.99.0.git0957.ge8c7bd03-1
> Severity: important
>
> The newer git version removes the dependency on elpa-magit-popup which
> seems to be required:
>
> ...
> In toplevel form:
> magit-tag.el:30:1:Error: Cannot open load file: No such file or directory, 
> magit-popup
>
> In toplevel form:
> magit-worktree.el:30:1:Error: Cannot open load file: No such file or 
> directory, magit-popup
> ERROR: install script from elpa-magit package failed
> dpkg: error processing package elpa-magit (--configure):
>  installed elpa-magit package post-installation script subprocess returned 
> error exit status
> Errors were encountered while processing:
>  elpa-magit
>

-- 
Rémi Vanicat



Bug#964446: RFP: sane-airscan - SANE backend for AirScan (eSCL) and WSD document scanners

2020-07-07 Thread Till Kamppeter

Package: wnpp
Severity: wishlist

* Package name: sane-airscan
  Version : 0.99.8
  Upstream Author : Alexander Pevzner 
* URL : https://github.com/alexpevzner/sane-airscan
* License : GPL-2+ with sane exception (same as sane-backends)
  Programming Lang: C
  Description : SANE backend for AirScan (eSCL) and WSD document
scanners

sane-airscan is a SANE backend (scanner driver) for two 
manufacturer-neutral, standardized communication protocols (AirScan/eSCL 
and WSD) which are used by the scanners in most modern printer/scanner 
multi-function devices and so used by thousands of scanners.

.
Similar to modern printers (especially the printing parts of the 
mentioned multi-function devices) using standard protocols and so 
printing driverless (driver = hardware-model-specific software or data) 
we are also scanning driverless with this backend using the standard 
scanning protocols of the multi-function devices.

.
In the near future even a third standard protocol, IPP Scan of the 
Printer Working Group (www.pwg.org) will be added.

.
This all work not only with network-connected devices which advertise 
themselves via DNS-SD but also with USB devices using IPP-over-USB (with 
the ipp-usb software, RFP: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961218, only needed 
for USB access, not required for network access)




From the original README.md:

--
Similar to how most modern network printers support "driverless" 
printing, using the universal vendor-neutral printing protocol, many 
modern network scanners and MFPs support "driverless" scanning.


Driverless scanning comes in two flavors:

Apple AirScan or AirPrint scanning (official protocol name is eSCL)
Microsoft WSD, or WS-Scan (term WSD means "Web Services for Devices)
This backend implements both protocols, choosing automatically between 
them. It was successfully tested with many devices from Brother, Canon, 
Kyocera, Lexmark, Epson, HP, Ricoh, Samsung and Xerox both in WSD and 
eSCL modes.


For eSCL devices, Apple maintains a comprehensive list of compatible 
devices, but please note, this list contains not only scanners and MFP, 
but pure printers as well.


This backend doesn't require to install and doesn't conflict with 
vendor-provided proprietary software like ScanGear from Canon, HPLIP 
from HP and so on.

--

sane-airscan is a standard SANE backend and makes all eSCL- and 
WSD-based scanners immediately available to all SANE-based frontends, 
like simple-scan, X-SANE, ... It also supports the full functionality of 
the scanners, especially the ADF (Automatic Document Feeder) which is 
not supported by the "escl" backend in SANE 1.0.29 and newer. There are 
also some devices which support only WSD and not eSCL which are 
therefiore supported only by this backend and not by "escl".


As eSCL and WSD is supported by the same backend devices with both eSCL 
and WSD support get only listed once in SANE frontends (most modern MF 
devices support both protocols).


It is tested already by many users on many devices (see the list in the 
README.md file).


Alexander Pevzner, author of the backend (and of ipp-usb) answers to bug 
reports (GutHub issues) quickly and works closely together with the user 
to fix the bug. In addition, the backend is under active development, 
IPP Scan is planned to be added by end of September.


Alexander is also generating and publishing binary packages for all 
major Linux distributions via the OpenSUSE Build Service. The files for 
the Debian package, to be found here


https://build.opensuse.org/package/show/home:pzz/sane-airscan

could be a start for creating a .deb package of sane-airscan.

It would be great to have sane-airscan as standard part of Debian, to 
make thousands of scanners just work.


As it will get also synced into Ubuntu I will stay in collaboration with 
the potential packager/Debian maintainer of it as will be the Debian 
Printing group.


   Till



Bug#962880: python3-django-hyperkitty: should depend on fonts-font-awesome and/or fonts-glyphicons-halflings (not fonts-glewlwyd)

2020-07-07 Thread peter green

severity 962880 serious
thanks

fonts-glewlwyd has now been dropped by the glewlwyd source package.



Bug#962876: kytos-sphinx-theme-common: should depend on fonts-glyphicons-halflings (not fonts-glewlwyd)

2020-07-07 Thread peter green

severity 962876 serious
thanks

fonts-glewlwyd has now been dropped by the glewlwyd source package.



Bug#962878: omnidb-common: should depend on fonts-font-awesome and/or fonts-glyphicons-halflings (not fonts-glewlwyd)

2020-07-07 Thread peter green

severity 962878 serious
thanks

fonts-glewlwyd has now been dropped by the glewlwyd source package.



Bug#961345: cups: daemon crashes with invalid free()

2020-07-07 Thread Ronny Adsetts
Package: cups
Version: 2.3.3-1~bpo10+1
Followup-For: Bug #961345

Dear Maintainer,

I'm running the Testing version of cups recompiled for Buster. I'm seeing the
same "invalid pointer" issue as the reporter.

Backtrace for a coredump is below. Please let me know if there's any other
information I can provide in order to help get a solution for this issue. It's
disrupting our printing significantly:

root@samba-prn-01:~# coredumpctl gdb 27338
   PID: 27338 (cupsd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Mon 2020-07-06 17:01:15 BST (17h ago)
  Command Line: /usr/sbin/cupsd -l
Executable: /usr/sbin/cupsd
 Control Group: /system.slice/cups.service
  Unit: cups.service
 Slice: system.slice
   Boot ID: 0fcad17ac3cd455b9f660e247188c9f5
Machine ID: d5fab4a49a044739a79685e71c58019c
  Hostname: samba-prn-01.graysofwestminster.co.uk
   Storage: 
/var/lib/systemd/coredump/core.cupsd.0.0fcad17ac3cd455b9f660e247188c9f5.27338.159405127500.lz4
   Message: Process 27338 (cupsd) of user 0 dumped core.

Stack trace of thread 27338:
#0  0x7f5c88cfb7bb __GI_raise (libc.so.6)
#1  0x7f5c88ce6535 __GI_abort (libc.so.6)
#2  0x7f5c88d3d508 __libc_message (libc.so.6)
#3  0x7f5c88d43c1a malloc_printerr (libc.so.6)
#4  0x7f5c88d4542c _int_free (libc.so.6)
#5  0x7f5c88ec143e n/a (libcups.so.2)
#6  0x7f5c88ec13a8 ippDelete (libcups.so.2)
#7  0x55c691e34ce4 cupsdWriteClient (cupsd)
#8  0x55c691e6ed37 cupsdDoSelect (cupsd)
#9  0x55c691e2c2f5 main (cupsd)
#10 0x7f5c88ce809b __libc_start_main (libc.so.6)
#11 0x55c691e2d5da _start (cupsd)

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/cupsd...Reading symbols from 
/usr/lib/debug/.build-id/6d/c083ea4548b510e5e2e225f09345d3ef998629.debug...done.
done.
[New LWP 27338]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/cupsd -l'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f5c88ce6535 in __GI_abort () at abort.c:79
#2  0x7f5c88d3d508 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f5c88e4828d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f5c88d43c1a in malloc_printerr (
str=str@entry=0x7f5c88e4643b "free(): invalid pointer") at malloc.c:5341
#4  0x7f5c88d4542c in _int_free (av=, p=,
have_lock=) at malloc.c:4165
#5  0x7f5c88ec143e in ?? () from /lib/x86_64-linux-gnu/libcups.so.2
#6  0x7f5c88ec13a8 in ippDelete () from /lib/x86_64-linux-gnu/libcups.so.2
#7  0x55c691e34ce4 in cupsdWriteClient (con=0x55c692502310)
at client.c:2563
#8  0x55c691e6ed37 in cupsdDoSelect (timeout=)
at select.c:485
#9  0x55c691e2c2f5 in main (argc=, argv=)
at main.c:847
(gdb) quit


Thanks for your time.

Ronny


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 cups depends on:
ii  cups-client2.3.3-1~bpo10+1
ii  cups-common2.3.3-1~bpo10+1
ii  cups-core-drivers  2.3.3-1~bpo10+1
ii  cups-daemon2.3.3-1~bpo10+1
ii  cups-filters   1.27.4-1
ii  cups-ppdc  2.3.3-1~bpo10+1
ii  cups-server-common 2.3.3-1~bpo10+1
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2+deb10u3
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libcups2 

Bug#962879: python3-cylc: should depend on fonts-font-awesome and/or fonts-glyphicons-halflings (not fonts-glewlwyd)

2020-07-07 Thread peter green

severity 962879 serious
thanks

fonts-glewlwyd has now been dropped by the glewlwyd source package.



Bug#962886: zoneminder: should depend on fonts-font-awesome and/or fonts-glyphicons-halflings (not fonts-glewlwyd)

2020-07-07 Thread peter green

severity 962886 serious
thanks

fonts-glewlwyd has now been dropped by the glewlwyd source package.



Bug#962877: oca-core: should depend on fonts-font-awesome and/or fonts-glyphicons-halflings (not fonts-glewlwyd)

2020-07-07 Thread peter green

severity 962877 serious
close 962877 11.0.20191007-3
thanks

fonts-glewlwyd has now been dropped by the glewlwyd source package.

The dependency is gone in unstable, but the fix is currently blocked from 
migrating to testing.
A seperate bug report about that will follow.



Bug#964448: oca-core: needs a source-only upload

2020-07-07 Thread peter green

Package: oca-core
Version: 11.0.20191007-3
Severity: serious

The release team have decreed that non-buildd binaries can no longer migrate to 
testing.
Please make a source-only upload so your package can migrate.



Bug#964449: autopkg test failures with binutils 2.35

2020-07-07 Thread Matthias Klose
Package: src:backward-cpp
Version: 1.5-1
Severity: serious
Tags: sid bullseye

see
https://ci.debian.net/data/autopkgtest/testing/amd64/b/backward-cpp/6173600/log.gz

a work around would be to allow stderr in the test.

autopkgtest [09:43:20]: test build: [---
Build: OK
i=0
i=1
BFD: DWARF error: could not find variable specification at offset 1c07
BFD: DWARF error: could not find variable specification at offset 1c82
BFD: DWARF error: could not find variable specification at offset 1d09
BFD: DWARF error: could not find variable specification at offset b1cd
BFD: DWARF error: could not find variable specification at offset b1d9
BFD: DWARF error: could not find variable specification at offset b3ab
BFD: DWARF error: could not find variable specification at offset b3b7
BFD: DWARF error: could not find variable specification at offset b9c6
BFD: DWARF error: could not find variable specification at offset ba0d
BFD: DWARF error: could not find variable specification at offset ba54
BFD: DWARF error: could not find variable specification at offset ba9b
BFD: DWARF error: could not find variable specification at offset baca
BFD: DWARF error: could not find variable specification at offset bb05
BFD: DWARF error: could not find variable specification at offset bb11
#0 at unsigned long
backward::details::unwind::callback>(backward::StackTraceImpl::callback,
unsigned long)
#1 at
backward::StackTraceImpl::load_here(unsigned 
long)
#2 at TracedException::_get_trace[abi:cxx11]()
#3 at TracedException::TracedException()
#4 at f(int)
#5 at f(int)
#6 at f(int)
#7 at main
#8 at __libc_start_main
#9 at _start
#10 at
Run: OK
Test: OK



Bug#964450: wicd-daemon: "Forced disconnect on" though I did not disconnect

2020-07-07 Thread Vincent Lefevre
Package: wicd-daemon
Version: 1.7.4+tb2-6
Severity: important

wicd often suddenly disconnects. In the logs, I can see:

[...]
2020/07/07 13:43:06 :: ifconfig wlp61s0
2020/07/07 13:43:06 :: iwconfig wlp61s0
2020/07/07 13:43:10 :: ifconfig wlp61s0
2020/07/07 13:43:10 :: iwconfig wlp61s0
2020/07/07 13:43:10 :: Forced disconnect on
[...]

This corresponds to

@dbus.service.method('org.wicd.daemon')
def SetForcedDisconnect(self, value):
""" Sets the forced_disconnect status.

Set to True when a user manually disconnects or cancels a connection.
It gets set to False as soon as the connection process is manually
started.

"""
if self.debug_mode and value:
print "Forced disconnect on"
self.forced_disconnect = bool(value)

in wicd-daemon.py, but I did not manually disconnect or cancel a
connection (the GUI was even closed).

-- System Information:
Debian Release: bullseye/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 5.7.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 wicd-daemon depends on:
ii  adduser   3.118
ii  dbus  1.12.18-1
ii  debconf   1.5.74
ii  iputils-ping  3:20190709-3
ii  isc-dhcp-client   4.4.1-2.1+b2
ii  lsb-base  11.1.0
ii  psmisc23.3-1
ii  python2.7.17-2
ii  python-dbus   1.2.16-2
ii  python-gobject-2  2.28.6-14+b1
ii  python-wicd   1.7.4+tb2-6
ii  wireless-tools30~pre9-13.1
ii  wpasupplicant 2:2.9.0-13

Versions of packages wicd-daemon recommends:
ii  rfkill 2.35.2-7
ii  wicd-curses [wicd-client]  1.7.4+tb2-6
ii  wicd-gtk [wicd-client] 1.7.4+tb2-6

Versions of packages wicd-daemon suggests:
pn  pm-utils  

Versions of packages wicd depends on:
ii  wicd-curses [wicd-client]  1.7.4+tb2-6
ii  wicd-gtk [wicd-client] 1.7.4+tb2-6

Versions of packages wicd-gtk depends on:
ii  python 2.7.17-2
ii  python-glade2  2.24.0-6
ii  python-gtk22.24.0-6

Versions of packages wicd-gtk recommends:
ii  menu   2.1.47+b1
ii  policykit-10.105-26
ii  python-notify  0.1.1-4+b2

Versions of packages wicd-curses depends on:
ii  python2.7.17-2
ii  python-urwid  2.0.1-2+b2

Versions of packages wicd-curses recommends:
ii  sudo  1.9.1-1

Versions of packages python-wicd depends on:
ii  net-tools  1.60+git20180626.aebd88e-1
ii  python 2.7.17-2

Versions of packages python-wicd suggests:
ii  ethtool   1:5.4-1
ii  iproute2  5.7.0-1

-- Configuration Files:
/etc/wicd/encryption/templates/active changed:
wpa
wpa-peap
wpa-peap-wo-domain
wpa-psk
wpa-psk-hex
wpa2-leap
wpa2-peap
wpa2-peap-wo-domain
wep-hex
wep-passphrase
wep-shared
leap
ttls
eap
peap
peap-eduroam
peap-tkip
eap-tls
psu


-- debconf information:
* wicd/users:

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



Bug#964451: chromium (83.0.4103.116-1~deb10u2) constantly crashes and slow

2020-07-07 Thread Oleg Devua
Package: chromium

Version: 83.0.4103.116-1~deb10u2

Followup-For: Bug #964161


update to chromium 83.0.4103.116-1~deb10u2, I experienced constant
crashes and slow execution


Bug#960677: Please bump to 1.52.x

2020-07-07 Thread Robert Freeman-Day
Updating to reflect newer version.
-- 


Robert Freeman-Day

https://launchpad.net/~presgas
https://keybase.io/robertfreemanday
GPG Public Key:
https://keybase.io/robertfreemanday/pgp_keys.asc
Pronoun: He or E/Em - https://pronoun.is/he?or=e



Bug#964452: ITP: bgrep -- Tool to search substrings in binary files

2020-07-07 Thread Giovanni Mascellani
Package: wnpp
Severity: wishlist
Owner: Giovanni Mascellani 

* Package name: bgrep
  Version : git5ca1302
  Upstream Author : Felix Domke
* URL : https://github.com/tmbinc/bgrep
* License : BSD
  Programming Lang: C
  Description : Tool to search substrings in binary files

Bgrep is a small utility similar to grep, but searching for binary
substrings into binary files.



Bug#964453: please reenable libkms

2020-07-07 Thread Dmitry Baryshkov
Source: libdrm
Version: 2.4.102-1
Severity: normal

libkms is usefull for other packages outside Debian (e.g. for VK-GL-CTS
test suite). Could you please reenable it (disabled in 2.4.46-3).

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)



Bug#964111: dpkg-source: False positive 'points outside source root'

2020-07-07 Thread Felix Lechner
Hi Holger,

On Tue, Jul 7, 2020 at 2:29 AM Holger Levsen  wrote:
>
> sigh. so IMNSHO now lintian *and* dpkg are buggy. Or point me to policy
> which prohibits files pointing to /dev/null. This worked for years.

The restriction applies only to source packages and not to
installation packages. Is it such a burden to create the file in
d/rules, or elsewhere? It should be one line, at most.

The logic is a little bit similar to device nodes, or other special files.

Kind regards
Felix Lechner



Bug#964453: please reenable libkms

2020-07-07 Thread Julien Cristau
Control: severity -1 wishlist
Control: tag -1 wontfix

On Tue, Jul 07, 2020 at 03:45:52PM +0300, Dmitry Baryshkov wrote:
> Source: libdrm
> Version: 2.4.102-1
> Severity: normal
> 
> libkms is usefull for other packages outside Debian (e.g. for VK-GL-CTS
> test suite). Could you please reenable it (disabled in 2.4.46-3).
> 
I'd rather not re-add it if it's not needed by something we ship, sorry.
My understanding back then was its use is discouraged, anyway.

Cheers,
Julien



Bug#891008: grml-debootstrap: cannot setup stretch images

2020-07-07 Thread Michael Prokop
control: retitle -1 'grml-debootstrap: support predictable network device names 
in VM images'

* Holger Levsen [Mon Jul 06, 2020 at 10:27:32AM +]:
> On Wed, Feb 21, 2018 at 02:58:18PM +0100, Holger Levsen wrote:

> > i'm trying to setup stretch images, and while the same commandline works
> > for jessie, it fails with stretch like this:
[...]

> long story short, this ^ is the cause for what I have seen, using stretch
> and buster the network interface is 'ens3' and not 'eth0', thus the network
> didnt come up as it should...

> Now that I know this, I'm using 'ens3' for these systems but I'd rather like
> grml-debootstrap to (optionally) append 'net.ifnames=0' to the kernel
> commandline, thus forcing the interface name to be 'eth0'. I've changed the
> bug meta-data accordingly.

Thanks for providing an update to the bug report and clarifying this!

JFTR: we already have support for predictable network interfaces
(see e.g. --defaultinterfaces), though it indeed is broken as-is for
the VM image use case, especially as the network device name(s)
depend(s) on the runtime environment of the VM image (and e.g.
ifupdown sadly isn't as dynamic as someone might wish).

So it might indeed make sense to enable net.ifnames=0 by default in
the VM image use case. If anyone should have a better idea, please
let me/us know!

regards
-mika-


signature.asc
Description: Digital signature


Bug#964454: node-color-string: Package description probably missing one line

2020-07-07 Thread Beatrice Torracca
Package: node-color-string
Severity: minor

Hi,

the package description now reads:
«For example, to.hex([255, 255, 255]) will return "
will return {model: 'rgb', value: [255, 255, 255, 1]}.".»

Looking at the previous version of the package I think there is a line
missing in the middle.

Thanks,

beatrice


Bug#964455: node-css-color-names: Package description truncated

2020-07-07 Thread Beatrice Torracca
Package: node-css-color-names
Severity: minor

Hi,

the package description now reads
«For example, aqua is mapped to»

and that is it. No ending to the sentence. I just filed a similar bug
report (964454) on package node-color-string. I think there might be some
issue with some script parsing the color codes.

Thanks,

beatrice


Bug#964453: please reenable libkms

2020-07-07 Thread Michel Dänzer
On 2020-07-07 2:45 p.m., Dmitry Baryshkov wrote:
> Source: libdrm
> Version: 2.4.102-1
> Severity: normal
> 
> libkms is usefull for other packages outside Debian (e.g. for VK-GL-CTS
> test suite). Could you please reenable it (disabled in 2.4.46-3).

AFAIK VK-GL-CTS never actually used libkms, it erroneously claims to
require it.

Upstream Mesa's GitLab CI pipeline uses this to modify the VK-GL-CTS
source tree so it can be built without libkms:

# surfaceless links against libkms and such despite not using it.
sed -i '/gbm/d' targets/surfaceless/surfaceless.cmake
sed -i '/libkms/d' targets/surfaceless/surfaceless.cmake
sed -i '/libgbm/d' targets/surfaceless/surfaceless.cmake


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer



Bug#964111: dpkg-source: False positive 'points outside source root'

2020-07-07 Thread Guillem Jover
On Tue, 2020-07-07 at 09:29:44 +, Holger Levsen wrote:
> On Mon, Jul 06, 2020 at 09:08:43PM -0700, Felix Lechner wrote:
> > > not sure if this is the same bug or just a similar one:
> > > lrwxrwxrwx 1 user user 9 Jul  3 16:07 debian/munin.service -> /dev/null
> > As for Holger's package, Lintian also flags that condition. Source
> > packages can be unpacked anywhere. We likewise consider absolute
> > symlink targets unacceptable there.
> > W: munin source: absolute-symbolic-link-target-in-source
> > debian/munin.service -> /dev/null
> 
> sigh. so IMNSHO now lintian *and* dpkg are buggy. Or point me to policy
> which prohibits files pointing to /dev/null. This worked for years.
> 
> (I haven't cloned the dpkg bug yet, as I believed Guillem would upload a
> fix quickly and thus I wanted to prevent busy paperwork. IMO the bug
> should be cloned and the severity raised to serious for the clone.)

Holger, as I mentioned some days ago, I consider this case a
regression which I was planning on fixing. This fix was already
included earlier today in the dpkg 1.20.4 upload. :)

Thanks,
Guillem



Bug#964456: stretch-pu: package roundcube/1.2.3+dfsg.1-4+deb9u6

2020-07-07 Thread Guilhem Moulin
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi there,

In a recent post roundcube webmail upstream has announced the following
security fix:

CVE-2020-15562: Prevent cross-site scripting (XSS) via HTML messages
with malicious svg/namespace.

This is tracker as #964355.  The security team gave the green light for
an upload of 1.3.14+dfsg.1-1~deb10u1 to buster-security, but suggested
to target old-p-u for stretch.   stretch currently has 1.2.3+dfsg.1-4+deb9u3
wwhile stretch-security and stretch-pu have 1.2.3+dfsg.1-4+deb9u5.  Both
debdiffs attached.

unblock roundcube/1.2.3+dfsg.1-4+deb9u6
cheers
-- 
Guilhem.
diffstat for roundcube-1.2.3+dfsg.1 roundcube-1.2.3+dfsg.1

 changelog|8 
 patches/CVE-2020-15562.patch |   33 +
 patches/series   |1 +
 3 files changed, 42 insertions(+)

diff -Nru roundcube-1.2.3+dfsg.1/debian/changelog 
roundcube-1.2.3+dfsg.1/debian/changelog
--- roundcube-1.2.3+dfsg.1/debian/changelog 2020-06-09 13:46:01.0 
+0200
+++ roundcube-1.2.3+dfsg.1/debian/changelog 2020-07-06 16:14:59.0 
+0200
@@ -1,3 +1,11 @@
+roundcube (1.2.3+dfsg.1-4+deb9u6) stretch; urgency=high
+
+  * Backport security fix for CVE-2020-15562: Cross-Site Scripting (XSS)
+vulnerability via HTML messages with malicious svg/namespace
+(Closes: #964355)
+
+ -- Guilhem Moulin   Mon, 06 Jul 2020 16:14:59 +0200
+
 roundcube (1.2.3+dfsg.1-4+deb9u5) stretch-security; urgency=high
 
   * Backport security fixes from 1.3.12:
diff -Nru roundcube-1.2.3+dfsg.1/debian/patches/CVE-2020-15562.patch 
roundcube-1.2.3+dfsg.1/debian/patches/CVE-2020-15562.patch
--- roundcube-1.2.3+dfsg.1/debian/patches/CVE-2020-15562.patch  1970-01-01 
01:00:00.0 +0100
+++ roundcube-1.2.3+dfsg.1/debian/patches/CVE-2020-15562.patch  2020-07-06 
16:14:59.0 +0200
@@ -0,0 +1,33 @@
+From f3d1566cf223eb04f47b6dfffcd88753f66c36ee Mon Sep 17 00:00:00 2001
+From: Aleksander Machniak 
+Date: Fri, 3 Jul 2020 11:29:50 +0200
+Subject: Fix cross-site scripting (XSS) via HTML messages with malicious 
svg/namespace
+
+Credits to SSD Secure Disclosure (https://ssd-disclosure.com/)
+---
+ program/lib/Roundcube/rcube_washtml.php |7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/program/lib/Roundcube/rcube_washtml.php
 b/program/lib/Roundcube/rcube_washtml.php
+@@ -445,7 +445,10 @@ class rcube_washtml
+ $xpath = new DOMXPath($node->ownerDocument);
+ foreach ($xpath->query('namespace::*') as $ns) {
+ if ($ns->nodeName != 'xmlns:xml') {
+-$dump .= ' ' . $ns->nodeName . '="' . 
$ns->nodeValue . '"';
++$dump .= sprintf(' %s="%s"',
++$ns->nodeName,
++htmlspecialchars($ns->nodeValue, 
ENT_QUOTES, $this->config['charset'])
++);
+ }
+ }
+ }
+@@ -507,7 +510,7 @@ class rcube_washtml
+ $this->max_nesting_level = (int) @ini_get('xdebug.max_nesting_level');
+ 
+ // SVG need to be parsed as XML
+-$this->is_xml = stripos($html, 'is_xml = !preg_match('/<(html|head|body)/i', $html) && 
stripos($html, 'is_xml ? 'loadXML' : 'loadHTML';
+ $options  = 0;
+ 
diff -Nru roundcube-1.2.3+dfsg.1/debian/patches/series 
roundcube-1.2.3+dfsg.1/debian/patches/series
--- roundcube-1.2.3+dfsg.1/debian/patches/series2020-06-09 
13:46:01.0 +0200
+++ roundcube-1.2.3+dfsg.1/debian/patches/series2020-07-06 
16:14:59.0 +0200
@@ -20,3 +20,4 @@
 CVE-2020-12626.patch
 CVE-2020-13964.patch
 CVE-2020-13965.patch
+CVE-2020-15562.patch
diffstat for roundcube-1.2.3+dfsg.1 roundcube-1.2.3+dfsg.1

 changelog|8 
 patches/CVE-2020-15562.patch |   33 +
 patches/series   |1 +
 3 files changed, 42 insertions(+)

diff -Nru roundcube-1.2.3+dfsg.1/debian/changelog 
roundcube-1.2.3+dfsg.1/debian/changelog
--- roundcube-1.2.3+dfsg.1/debian/changelog 2020-06-09 13:46:01.0 
+0200
+++ roundcube-1.2.3+dfsg.1/debian/changelog 2020-07-06 16:14:59.0 
+0200
@@ -1,3 +1,11 @@
+roundcube (1.2.3+dfsg.1-4+deb9u6) stretch; urgency=high
+
+  * Backport security fix for CVE-2020-15562: Cross-Site Scripting (XSS)
+vulnerability via HTML messages with malicious svg/namespace
+(Closes: #964355)
+
+ -- Guilhem Moulin   Mon, 06 Jul 2020 16:14:59 +0200
+
 roundcube (1.2.3+dfsg.1-4+deb9u5) stretch-security; urgency=high
 
   * Backport security fixes from 1.3.12:
diff -Nru roundcube-1.2.3+dfsg.1/debian/patches/CVE-2020-15562.patch 
roundcube-1.2.3+dfsg.1/debian/patches/CVE-2020-15562.patch
--- roundcube-1.2.3+dfsg.1/debian/patches/CVE-202

Bug#964370: dino-im-common: dino-im_0.1.0-5~bpo10+1 removes dino-im on upgrade

2020-07-07 Thread Nico Alt
Thanks a lot for your quick reaction, Martin!

I can confirm this bug to be fixed by now, as I just updated apt and
were able to install dino-im from buster-backports. Thankfully, no chat
history got lost.



Bug#870383: Bug#879014: gpgme1.0: FTBFS on some arches: Qt needs a compile with -fPIC (PIE is not enough), hardening downgrades to PIE

2020-07-07 Thread Guillem Jover
Control: reopen -1
Control: tag -1 - patch

On Tue, 2020-07-07 at 07:06:34 +0200, Guillem Jover wrote:
> On Wed, 2020-07-01 at 17:20:40 -0400, Daniel Kahn Gillmor wrote:
> > Further conversation about problems compiling and linking against Qt and
> > GPGME in debian suggest that the problem might be related to dpkg's
> > default spec files, and confused by Qt's compiler warnings.
> > 
> > I'm attaching a patch to dpkg which (i think) reflects the fix proposed
> > by Guillem Jover (in cc):
> 
> Yes this is what I had locally, thanks for testing! I'm including a
> fix in the next upload.

> > --- a/data/no-pie-compile.specs
> > +++ b/data/no-pie-compile.specs
> > @@ -1,2 +1,2 @@
> > -*self_spec:
> > ++self_spec:
> >  + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fno-PIE}}

Ok, so Thorsten Glaser very helpfully pointed out that this is actually
bogus, as the + is supposed to go with the text not the spec name (which
was already there!). In this case I assume it gets interpreted as a
«[SUFFIX]:» entry, and then this get completely ignored (w/o an error
diagnostic), disabling all the specs files (confirmed by Thorsten on
x32), that's why the specific problem with gpgme+Qt stopped failing in
Daniel's tests.

I'll revert this in a quick .5 upload later today, and then try to
track down what's going on, and add some unit tests for the specs files,
so that this gets tested on architectures where it truly affects them.

Thanks,
Guillem



Bug#964437: Fails to install

2020-07-07 Thread Rémi Vanicat
reassign 964437 elpa-magit-annex 1.7.1-3 
affects 964437 elpa-magit
retitle 964437 elpa-magit-annex should depend on elpa-magit-popup
thanks

Thank you for checking, I confirm the problem, and reassign this bug to
elpa-magit-annex.

Le 07 juillet 2020, Yuri D'Elia a écrit:

> On Tue, Jul 07 2020, Rémi Vanicat wrote:
>> Could you show me the line 30 of the file
>>
>> /usr/share/emacs/site-lisp/elpa-src/magit-2.99.0/magit-tag.el
>
> (require 'magit)
>
>> Also please check if there is another version of magit installed in
>> /root/.emacs.d or in /usr/local/share/emacs/site-lisp/ or even in
>> /usr/share/emacs/site-lisp/ ?
>
> No, but I found the issue after looking deeper :/
>
> It's actually due to the elpa-magit-annex package which does
>
>   (require 'magit-popup)
>
> but still only depends on elpa-magit.

-- 
Rémi Vanicat



Bug#962221: Fixes for CVE-2020-13696 (#962221)

2020-07-07 Thread Mattia Rizzolo
On Mon, Jul 06, 2020 at 09:07:31PM +, Vasyl Gello wrote:
> I pushed the modernized package however

..however it fails to build :)

   dh_auto_install
install -d /build/xawtv-3.107/debian/tmp
make -j4 install DESTDIR=/build/xawtv-3.107/debian/tmp 
AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/build/xawtv-3.107'
/usr/bin/install -c -d -m 755 /build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install -c  console/dump-mixers console/record console/showriff 
console/showqt console/streamer console/webcam console/scantv console/ttv 
console/radio console/fbtv console/v4l-info 
/build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install -c  -m4755 -o root console/v4l-conf 
/build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install: cannot change ownership of 
'/build/xawtv-3.107/debian/tmp/usr/bin/v4l-conf': Operation not permitted
make[1]: *** [console/Subdir.mk:100: install] Error 1
make[1]: Leaving directory '/build/xawtv-3.107'
dh_auto_install: error: make -j4 install DESTDIR=/build/xawtv-3.107/debian/tmp 
AM_UPDATE_INFO_DIR=no returned exit code 2
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


this is related to the addition of Rules-Requires-Root.  When run
without fakeroot it's not possible to run such `chmod` commands.  In
fact, they are most likely always wrong to run them anyway…

> there are two errors claiming two libs are not compiled against libc and 
> several
> others missing requured prerequisites. I have not figured yet how to fix 
> these,
> maybe you know?

I'll see them when I can fully build the package ;)


In d/copyright, that boilerplate-y thing you copied into the Comment
field, IMHO you should just get rid of it.  Also, it's missing many of
the years in the copyright claims: a copyright claim without a year is
at most an legal headache and at worst invalid.

-- 
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#962326: ruby-activeldap: autopkgtest is failing

2020-07-07 Thread duck

Quack,

Just to say I'm starting to have a look.

I had planned a new upstream release which should fix problems with 
Rails 6. Not sure about the current failures but I spent quite some time 
in March to make things work and Ruby 2.7 broke the world it seems :-/.


Regards.
\_o<

--
Marc Dequènes



Bug#964111: dpkg-source: False positive 'points outside source root'

2020-07-07 Thread Holger Levsen
On Tue, Jul 07, 2020 at 03:52:08PM +0200, Guillem Jover wrote:
> Holger, as I mentioned some days ago, I consider this case a
> regression which I was planning on fixing. This fix was already
> included earlier today in the dpkg 1.20.4 upload. :)

yup, I've seen this today. Thank you!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Bug#962221: Fixes for CVE-2020-13696 (#962221)

2020-07-07 Thread Vasyl Gello
Hi Mattia!

July 7, 2020 2:25:37 PM UTC, Mattia Rizzolo  написав(-ла):
>..however it fails to build :)
>
>   dh_auto_install
>   install -d /build/xawtv-3.107/debian/tmp
>   make -j4 install DESTDIR=/build/xawtv-3.107/debian/tmp 
> AM_UPDATE_INFO_DIR=no
>make[1]: Entering directory '/build/xawtv-3.107'
>/usr/bin/install -c -d -m 755 /build/xawtv-3.107/debian/tmp/usr/bin
>/usr/bin/install -c  console/dump-mixers console/record console/showriff 
>console/showqt console/streamer console/webcam console/scantv console/ttv 
>console/radio console/fbtv console/v4l-info 
>/build/xawtv-3.107/debian/tmp/usr/bin
>/usr/bin/install -c  -m4755 -o root console/v4l-conf 
>/build/xawtv-3.107/debian/tmp/usr/bin
>/usr/bin/install: cannot change ownership of 
>'/build/xawtv-3.107/debian/tmp/usr/bin/v4l-conf': Operation not permitted
>make[1]: *** [console/Subdir.mk:100: install] Error 1
>make[1]: Leaving directory '/build/xawtv-3.107'
>dh_auto_install: error: make -j4 install DESTDIR=/build/xawtv-3.107/debian/tmp 
>AM_UPDATE_INFO_DIR=no returned exit code 2
>make: *** [debian/rules:6: binary] Error 25
>dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
>
>
>this is related to the addition of Rules-Requires-Root.  When run
>without fakeroot it's not possible to run such `chmod` commands.  In
>fact, they are most likely always wrong to run them anyway…

I of course built the package but my buildsetup always uses fakeroot exactly to 
get rid
of chown() calls. I will update Rules-Requires-Root to yes then.

>In d/copyright, that boilerplate-y thing you copied into the Comment
>field, IMHO you should just get rid of it.  Also, it's missing many of
>the years in the copyright claims: a copyright claim without a year is
>at most an legal headache and at worst invalid.

Got it! OK, let me do a quick fix for both issues and push additional commit.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature


Bug#964458: checkinstall: causes segfault of cmake

2020-07-07 Thread Jiri Palecek
Package: checkinstall
Version: 1.6.2+git20170426.d24a630-2
Severity: important
File: /usr/bin/installwatch

Dear Maintainer,

while trying to use checkinstall to create a debianized package from a
cmake based source, the build failed with a segfault. These are linked
to installwatch and don't happen without it:

$ installwatch make cmake_check_build_system

INFO : Using a default root directory : /tmp/tmp.JBpq66zd4H

make: *** [Makefile:10806: cmake_check_build_system] Neoprávněný přístup do 
paměti (SIGSEGV) (obraz paměti uložen)

There is a backtrace of the crash, which indicates it happens early in
the initialization of cmake around a stat call:

(gdb) bt
#0  0x in ?? ()
#1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
"/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
#2  _gnutls_update_system_priorities () at ../../lib/priority.c:1309
#3  0xb6a534f5 in _gnutls_global_init (constructor=constructor@entry=1) at 
../../lib/global.c:387
#4  0xb6a25950 in lib_init () at ../../lib/global.c:511
#5  0xb7f35f5c in call_init (l=, argc=argc@entry=6, 
argv=argv@entry=0xbfe33e64, env=0xbfe33e80) at dl-init.c:72
#6  0xb7f36062 in call_init (env=0xbfe33e80, argv=0xbfe33e64, argc=6, 
l=) at dl-init.c:30
#7  _dl_init (main_map=, argc=6, argv=0xbfe33e64, 
env=0xbfe33e80) at dl-init.c:119
#8  0xb7f270fa in _dl_start_user () from /lib/ld-linux.so.2
(gdb) frame 1
#1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
"/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
455   return __xstat (_STAT_VER, __path, __statbuf);

Why did it end up with EIP=0 I don't know.

It seems there's some incompatibility between installwatch's LD_PRELOAD
and glibc.

Could you have a look at it?

Regards
Jiri Palecek

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

Kernel: Linux 5.7.0-1-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages checkinstall depends on:
ii  dpkg-dev1.20.1~2.gbp7298ec
ii  file1:5.38-5
ii  libc6   2.30-7
ii  sensible-utils  0.0.12+nmu1

Versions of packages checkinstall recommends:
ii  make  4.3-4

Versions of packages checkinstall suggests:
ii  gettext  0.19.8.1-9

-- no debconf information



Bug#964435: buster-pu: package glib-networking/2.58.0-2+deb10u1

2020-07-07 Thread Emilio Pozuelo Monfort
On 07/07/2020 11:04, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Older versions of glib-networking's TLS implementation have a security
> issue (CVE-2020-13645): according to the documentation, if the caller
> does not specify a server identity, glib-networking should fail closed
> (reject all server identities), but in fact it failed open (accept all
> server identities).
> 
> The only application that was believed to be vulnerable to this
> in practice is balsa, which only became vulnerable in post-buster
> versions; older versions such as the one in buster implemented their
> own TLS.

Are you sure about this? Ubuntu had to patch balsa in eoan, which had the
same version that buster has, see [1].

Cheers,
Emilio

[1] 
https://launchpadlibrarian.net/485808024/balsa_2.5.6-2_2.5.6-2ubuntu0.1.diff.gz



Bug#956491: git-buildpackage: [PATCH] Add info about --git-ignore-branch when not on branch

2020-07-07 Thread Jonathan Rubenstein
Hey, I noticed you have been active in this project lately, and that you 
have a lot of open bugs. Would you mind taking a quick look at this 5 
line patch?



Thanks,

Jonathan



Bug#964460: Mention debhelper:compat and copyright:Upstream-Contact

2020-07-07 Thread Osamu Aoki
Package: debmake-doc
Version: 1.14-1
Severity: normal

Mention debhelper:compat via debian/control

   In current debhelper, you can specify the compatibility level in
   debian/control by adding a Build-Depends on the debhelper-compat
   package.  For example, to use v12 mode, ensure debian/control
has:

 Build-Depends: debhelper-compat (= 12)

(Oh, set 9->12 too)

debian/copyright:Upstream-Contact



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

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

debmake-doc depends on no packages.

Versions of packages debmake-doc recommends:
ii  debmake  4.3.1-1

Versions of packages debmake-doc suggests:
pn  debian-policy 
pn  developers-reference  



Bug#962221: Fixes for CVE-2020-13696 (#962221)

2020-07-07 Thread Vasyl Gello
Mattia,

July 7, 2020 2:42:20 PM UTC, Vasyl Gello  написав(-ла):
>Got it! OK, let me do a quick fix for both issues and push additional commit.

Commit is pushed, please try rebuilding the package!
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature


Bug#963713: net-snmp: CVE-2019-20892

2020-07-07 Thread Sylvain Beucler
Hi,

On 06/07/2020 19:11, Sylvain Beucler wrote:
> Do we have definite info on what versions are affected?
> 
> I cannot reproduce the issue in jessie/stretch/buster (5.7.x).
> 
> Incidentally Salvatore's test now yields an error in bullseye
> (5.8dfsg-3), though I suspect the issue is at the client's level:
> # snmpbulkget -v3 -Cn1 -Cr1472 -l authPriv -u testuser -a SHA -A
> testpass -x AES -X testpass 127.0.0.1 1.3.6.1.2.1.1.5 1.3.6.1.2.1.1.7
> Error in packet.
> Reason: (genError) A general failure occured

Bisecting gives a range of ~20 commits where the server is buggy (either
goes 100% CPU, or rejects the request with "send response: Too long").

1a0dbe19bf2787bb5bea913f210a9a5eb4c0c80c
"new snmp token sendMessageMaxSize"
works fine.

3eb4b473fed816108d1843dadee1ce877415b96b
"add debug_enable_token_logs debug_disable_token_logs to output_api.h"
triggers the double-free.

Anything in-between is random, and includes 2 "getbulk enhancements".
The date varies greatly so this may be a series of cherry-picks.

In any case, all of this happens between 5.7.3 and 5.8.pre1.

Cheers!
Sylvain



Bug#964462: parlatype-libreoffice-extension: please rename to libreoffice-parlatype

2020-07-07 Thread Rene Engelhard
Package: parlatype-libreoffice-extension
Version: 2.0-1
Severity: important

Dear Maintainer,

I just saw it on debian-devel-changes...

LibreOffice extensions are packaged as libreoffice-* in Debian. Yes,
even ones not shipped by LibreOffice itself.

libreoffice-numbertext
libreoffice-writer2latex
libreoffice-writer2xhtml
libreoffice-zemberek
libreoffice-texmaths
libreoffice-dmaths
libreoffice-voikko
libreoffice-lightproof-en
libreoffice-lightproof-ru-ru

Please rename. (Yes, I know you just got out of NEW, but that could have
been avoided if you looked up how other extensions were packaged.)

Regards,

Rene



Bug#964238: Thank you!

2020-07-07 Thread Alexandre Viau
Thank you for uploading a new version of this package :)

Cheers,

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



Bug#964458: checkinstall: causes segfault of cmake

2020-07-07 Thread Stephen Gelman
On Jul 7, 2020, at 9:42 AM, Jiri Palecek  wrote:
> 
> Package: checkinstall
> Version: 1.6.2+git20170426.d24a630-2
> Severity: important
> File: /usr/bin/installwatch
> 
> Dear Maintainer,
> 
> while trying to use checkinstall to create a debianized package from a
> cmake based source, the build failed with a segfault. These are linked
> to installwatch and don't happen without it:
> 
> $ installwatch make cmake_check_build_system
> 
> INFO : Using a default root directory : /tmp/tmp.JBpq66zd4H
> 
> make: *** [Makefile:10806: cmake_check_build_system] Neoprávněný přístup do 
> paměti (SIGSEGV) (obraz paměti uložen)
> 
> There is a backtrace of the crash, which indicates it happens early in
> the initialization of cmake around a stat call:
> 
> (gdb) bt
> #0  0x in ?? ()
> #1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
> "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
> #2  _gnutls_update_system_priorities () at ../../lib/priority.c:1309
> #3  0xb6a534f5 in _gnutls_global_init (constructor=constructor@entry=1) at 
> ../../lib/global.c:387
> #4  0xb6a25950 in lib_init () at ../../lib/global.c:511
> #5  0xb7f35f5c in call_init (l=, argc=argc@entry=6, 
> argv=argv@entry=0xbfe33e64, env=0xbfe33e80) at dl-init.c:72
> #6  0xb7f36062 in call_init (env=0xbfe33e80, argv=0xbfe33e64, argc=6, 
> l=) at dl-init.c:30
> #7  _dl_init (main_map=, argc=6, argv=0xbfe33e64, 
> env=0xbfe33e80) at dl-init.c:119
> #8  0xb7f270fa in _dl_start_user () from /lib/ld-linux.so.2
> (gdb) frame 1
> #1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
> "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
> 455   return __xstat (_STAT_VER, __path, __statbuf);
> 
> Why did it end up with EIP=0 I don't know.
> 
> It seems there's some incompatibility between installwatch's LD_PRELOAD
> and glibc.
> 
> Could you have a look at it?
> 
> Regards
>Jiri Palecek

Jiri,

Thanks for the report. In order to help me narrow this down are you able to 
provide a simple test case to reproduce the problem?

Thanks!

Stephen


Bug#956637: trash-cli: fail to find trashed file outside home directory

2020-07-07 Thread Jonathan Dowland

On Sun, May 24, 2020 at 10:03:56AM +0200, Samuele Battarra wrote:

Package: trash-cli
Version: 0.17.1.14-3
Followup-For: Bug #956637

Dear Maintainer,

attatched a patch


Thanks for that: one nit, the filesystem path(s) might not always be
utf-8, but the general approach looks right. The patch in #960566 does
much the same thing but determines the filesystem encoding too. It looks
like this also fixes using trash-cli on big endian machines.



Bug#964435: buster-pu: package glib-networking/2.58.0-2+deb10u1

2020-07-07 Thread Simon McVittie
Control: tags -1 + moreinfo

On Tue, 07 Jul 2020 at 16:50:36 +0200, Emilio Pozuelo Monfort wrote:
> On 07/07/2020 11:04, Simon McVittie wrote:
> > The only application that was believed to be vulnerable to this
> > in practice is balsa, which only became vulnerable in post-buster
> > versions; older versions such as the one in buster implemented their
> > own TLS.
> 
> Are you sure about this? Ubuntu had to patch balsa in eoan, which had the
> same version that buster has, see [1].
> 
> [1] 
> https://launchpadlibrarian.net/485808024/balsa_2.5.6-2_2.5.6-2ubuntu0.1.diff.gz

Well spotted. I haven't verified this myself, I
was just relaying what the balsa maintainer said on
.

Daniel: perhaps there is more than one module using TLS? In #961792 you're
talking about libbalsa/{server,libbalsa}.c, but the Ubuntu patch is against
libnetclient/net-client.c. Sorry, I don't know this codebase.

If balsa in buster is affected by this, then we'll need to hold off on
doing this stable-update until a matching version of balsa is ready, like
I originally suspected was going to be necessary.

I've uploaded the proposed glib-networking to proposed-updates, and it's
available from
https://salsa.debian.org/gnome-team/glib-networking/-/tree/debian/buster-proposed
if that helps with testing against it.

smcv



Bug#964463: krita doesn't start with multiple monitors

2020-07-07 Thread Johannes Visintini
Package: krita
Version: 1:4.3.0+dfsg-1
Severity: normal

Dear Maintainer,

I installed krita for the first time on this machine. When I start krita
with just one monitor (eDP-1, regular notebook monitor) it works just
fine, but not with my normal workplace setup with multiple monitors.

These are my monitors (eDP-1 is disabled in this setup):
> % xrandr -q | grep "\bconnected\b"
> eDP-1 connected (normal left inverted right x axis y axis)
> DP-2-2 connected primary 3840x2160+0+648 (normal left inverted right x axis y 
> axis) 596mm x 335mm
> DP-2-3 connected 1800x2880+3840+0 left (normal left inverted right x axis y 
> axis) 518mm x 324mm

I get this lines when starting krita:
> % krita
> Invalid profile :  "/usr/share/color/icc/colord/Crayons.icc" "Crayon Colors"
> Invalid profile :  "/usr/share/color/icc/colord/x11-colors.icc" "X11 Colors"
> qt.gui.icc: Unsupported ICC input color space 47524159
> qt.gui.icc: fromIccProfile: failed general sanity check
> QPngHandler: Failed to parse ICC profile
> qt.gui.icc: Unsupported ICC input color space 47524159
> qt.gui.icc: fromIccProfile: failed general sanity check
> QPngHandler: Failed to parse ICC profile
> qt.gui.icc: Unsupported ICC input color space 47524159
> qt.gui.icc: fromIccProfile: failed general sanity check
> QPngHandler: Failed to parse ICC profile
> qt.gui.icc: Unsupported ICC input color space 47524159
> qt.gui.icc: fromIccProfile: failed general sanity check
> QPngHandler: Failed to parse ICC profile
> qt.gui.icc: Unsupported ICC input color space 47524159
> qt.gui.icc: fromIccProfile: failed general sanity check
> QPngHandler: Failed to parse ICC profile
> QObject::startTimer: Timers cannot have negative intervals
> /usr/lib/x86_64-linux-gnu/krita-python-libs/krita added to PYTHONPATH
> ASSERT (krita): "screen < QGuiApplication::screens().size() && screen >= 0" 
> in file /build/krita-VZXkgT/krita-4.3.0+dfsg/libs/widgets/KoToolBox.cpp, line 
> 51
> [1]51107 abort  krita

I think only the assert is relevant to this bug.

If you need any further information, give me a heads up :)


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'oldoldstable'), (600, 'stable'), (600, 
'oldstable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (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 krita depends on:
ii  krita-data1:4.3.0+dfsg-1
ii  libc6 2.30-8
ii  libexiv2-27   0.27.2-8
ii  libfftw3-double3  3.3.8-2
ii  libgcc-s1 10.1.0-4
ii  libgif7   5.1.9-1
ii  libgsl25  2.6+dfsg-2
ii  libheif1  1.6.1-1
ii  libilmbase24  2.3.0-6
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libkf5completion5 5.70.0-1
ii  libkf5configcore5 5.70.0-1
ii  libkf5configgui5  5.70.0-1
ii  libkf5coreaddons5 5.70.0-1
ii  libkf5crash5  5.70.0-1
ii  libkf5guiaddons5  5.70.0-2
ii  libkf5i18n5   5.70.0-1
ii  libkf5itemviews5  5.70.0-1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libkf5windowsystem5   5.70.0-1
ii  liblcms2-22.9-4+b1
ii  libopencolorio1v5 1.1.1~dfsg0-6+b1
ii  libopenexr24  2.3.0-6
ii  libopenjp2-7  2.3.1-1
ii  libpng16-16   1.6.37-2
ii  libpoppler-qt5-1  0.71.0-6
ii  libpython3.8  3.8.4~rc1-1
ii  libqt5concurrent5 5.14.2+dfsg-4
ii  libqt5core5a  5.14.2+dfsg-4
ii  libqt5dbus5   5.14.2+dfsg-4
ii  libqt5gui55.14.2+dfsg-4
ii  libqt5multimedia5 5.14.2-2
ii  libqt5network55.14.2+dfsg-4
ii  libqt5printsupport5   5.14.2+dfsg-4
ii  libqt5qml55.14.2+dfsg-2
ii  libqt5quick5  5.14.2+dfsg-2
ii  libqt5quickwidgets5   5.14.2+dfsg-2
ii  libqt5svg55.14.2-2
ii  libqt5widgets55.14.2+dfsg-4
ii  libqt5x11extras5  5.14.2-2
ii  libqt5xml55.14.2+dfsg-4
ii  libquazip5-1  0.9-2
ii  libraw19  0.19.5-1
ii  libstdc++610.1.0-4
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.9-2+b1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages krita recommends:
ii  krita-gmic   2.4.5-1.1
ii  python3-pyqt55.15.0+dfsg-1+b1
ii  python3-sip  4.19.23+dfsg-1
ii  qml-module-qtmultimedia  5.14.2-2

Versions of packages krita suggests:
ii  colord  1.4.4-2
ii  ffmpeg  7:4.3-2
pn  krita-l10n  

-- no debconf information



Bug#964238: Thank you!

2020-07-07 Thread Roger Shimizu
no problem.
it's bit tricky for that package... current fix is just a workaround.
anyway, now you can work on your syncthing package.

Cheers

On Wed, Jul 8, 2020 at 12:11 AM Alexandre Viau  wrote:
>
> Thank you for uploading a new version of this package :)
>
> Cheers,
>
> --
> Alexandre Viau
> av...@debian.org



Bug#963713: net-snmp: CVE-2019-20892

2020-07-07 Thread Sylvain Beucler
Hi,

On 07/07/2020 17:07, Sylvain Beucler wrote:
> On 06/07/2020 19:11, Sylvain Beucler wrote:
>> Do we have definite info on what versions are affected?
>>
>> I cannot reproduce the issue in jessie/stretch/buster (5.7.x).
>>
>> Incidentally Salvatore's test now yields an error in bullseye
>> (5.8dfsg-3), though I suspect the issue is at the client's level:
>> # snmpbulkget -v3 -Cn1 -Cr1472 -l authPriv -u testuser -a SHA -A
>> testpass -x AES -X testpass 127.0.0.1 1.3.6.1.2.1.1.5 1.3.6.1.2.1.1.7
>> Error in packet.
>> Reason: (genError) A general failure occured
> 
> Bisecting gives a range of ~20 commits where the server is buggy (either
> goes 100% CPU, or rejects the request with "send response: Too long").
> 
> 1a0dbe19bf2787bb5bea913f210a9a5eb4c0c80c
> "new snmp token sendMessageMaxSize"
> works fine.
> 
> 3eb4b473fed816108d1843dadee1ce877415b96b
> "add debug_enable_token_logs debug_disable_token_logs to output_api.h"
> triggers the double-free.
> 
> Anything in-between is random, and includes 2 "getbulk enhancements".
> The date varies greatly so this may be a series of cherry-picks.
> 
> In any case, all of this happens between 5.7.3 and 5.8.pre1.

Restricting further (good..bad):

$ git shortlog
1a0dbe19bf2787bb5bea913f210a9a5eb4c0c80c..e207b8113260fd7d84df0ebdb66925ab70da29b2
Robert Story (2):
  Add VMware copyright
  tweak sndMsgMaxSize handling

VMwareDev Randy (4):
  getbulk enhancements: limit responses gathered
  reduce session msg max sizes to transport max
  getbulk enhancements: response size + fallback to forward encoding
  move v3 engineID probe into initial packet build

Cheers!
Sylvain Beucler
Debian LTS Team



Bug#964381: lintian: Detecting bogus email address

2020-07-07 Thread Felix Lechner
Hi Hugh,

On Mon, Jul 6, 2020 at 6:24 AM Hugh McMaster  wrote:
>
> Should I ignore lintian, override the tag or change the problem email 
> addresses
> to the upstream author's actual email address (also found all over the
> changelog)?

Adam confirmed via private email that changing the address is okay. An
internal address appeared by mistake.

Alternatively, you could wait until a new version of
Data::Validate::Domain is uploaded. At that point, the TLD validation
will probably be turned off (although it worked well in your case).
The use of that feature is worth a discussion somewhere.

Please feel free to close this bug report.

Kind regards
Felix Lechner



Bug#964447: plasma-workspace: please split out xembed-sni-proxy into separate bin:pkg

2020-07-07 Thread Mike Gabriel

Package: src:plasma-workspace
Severity: whishlist
X-Debbugs-Cc: debian-m...@lists.debian.org

Hi all,

I just stumbled over the xembed-sni-proxy executable from  
src:plasma-workspace. I plan to support it in  
ayatana-indicator-application [1] (and thus in the  
mate-indicator-applet of the MATE desktop environment).


For a cross-desktop use case, it would be nice to have  
xembed-sni-proxy available as a standalone package (that does not pull  
in the complete KDE package stack).


Would that be a feasible thing to do for plasma-workspace in Debian?

Thanks+Greets,
Mike

[1]  
https://github.com/AyatanaIndicators/ayatana-indicator-application/issues/1

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

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



pgpRA1i3XPoDL.pgp
Description: Digitale PGP-Signatur


Bug#964464: libkimageannotator-common: missing Breaks+Replaces: libkimageannotator0 (<< 0.3.1-4)

2020-07-07 Thread Andreas Beckmann
Package: libkimageannotator-common
Version: 0.3.1-4
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 .../libkimageannotator-common_0.3.1-4_all.deb ...
  Unpacking libkimageannotator-common (0.3.1-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libkimageannotator-common_0.3.1-4_all.deb (--unpack):
   trying to overwrite 
'/usr/share/kImageAnnotator/translations/kImageAnnotator_cs.qm', which is also 
in package libkimageannotator0:amd64 0.3.1-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libkimageannotator-common_0.3.1-4_all.deb


cheers,

Andreas


libkimageannotator0=0.3.1-1_libkimageannotator-common=0.3.1-4.log.gz
Description: application/gzip


Bug#964462: parlatype-libreoffice-extension: please rename to libreoffice-parlatype

2020-07-07 Thread Gabor Karsay

Rene Engelhard schrieb am 07.07.20 um 17:05:
> [...]
> LibreOffice extensions are packaged as libreoffice-* in Debian. Yes,
> even ones not shipped by LibreOffice itself.
> [...]

Well, the idea is that it's closer to Parlatype than to LibreOffice. I
guess there is more code in Parlatype to make this possible than in
LibreOffice. But yes, it is a LibreOffice extension.

I saw a few packaged extensions but I was not aware of a naming
convention. I'm curious why the severity is "important" ("major effect
on the usability of a package")?

If you really think it's important, I can change it. It's only in
experimental, so that shouldn't be a big problem.

Regards,
Gabor



Bug#824774: pkg-config: please support DPKG_ROOT in dpkghook script

2020-07-07 Thread David Kalnischkies
Hi,

as the unlucky stars aligned today again for who knows what reason
(I guess it comes with the support dpkg added around d-m-h recently)
I got some strange apt test failures again as a result of:

| pkg-config-dpkghook: error: failed to remove symlink 
/usr/bin/arm-linux-gnueabi-pkg-config: Permission denied
| dpkg: error: error executing hook 'if { test "$DPKG_HOOK_ACTION" = 
add-architecture || test "$DPKG_HOOK_ACTION" = remove-architecture; } && test 
-x /usr/share/pkg-config-dpkghook; then /usr/share/pkg-config-dpkghook update; 
fi', exit code 65280

(which is "expected" in so far as my host has 'armel' as foreign
 architecture enabled in dpkg, while the dpkgroot has not. Good
 thing I am not running the tests as root [that often]).

Attached a refreshed patch, no real code changes.


Best regards

David Kalnischkies
--- /usr/share/pkg-config-dpkghook	2020-04-21 20:30:00.0 +0200
+++ /tmp/pkg-config-dpkghook	2020-07-07 17:14:05.269928572 +0200
@@ -14,17 +14,26 @@
 use Dpkg::Arch qw(debarch_to_gnutriplet);
 use Dpkg::ErrorHandling qw(error warning);
 
-my $crosswrapper = "/usr/share/pkg-config-crosswrapper";
+my $dpkgroot = $ENV{'DPKG_ROOT'} // '';
+my $crosswrapper = "$dpkgroot/usr/share/pkg-config-crosswrapper";
 
 my $action = $ARGV[0];
 error("parameter must be 'remove' or 'update'")
   unless defined $action && ($action eq "remove" || $action eq "update");
 
-my $arch = `dpkg --print-architecture`;
-error('dpkg --print-architecture failed') if $? >> 8;
-my @architectures = `dpkg --print-foreign-architectures`;
-error('dpkg --print-foreign-architectures failed') if $? >> 8;
-push @architectures, $arch;
+if ($dpkgroot) {
+  open(NATIVE_FH, "-|", "dpkg", "--root", $dpkgroot, "--print-architecture")
+or error("dpkg --root $dpkgroot --print-architecture failed");
+  open(FOREIGN_FH, "-|", "dpkg", "--root", $dpkgroot, "--print-foreign-architectures")
+or error("dpkg --root $dpkgroot --print-foreign-architecture failed");
+} else {
+  open(NATIVE_FH, "-|", "dpkg", "--print-architecture")
+or error('dpkg --print-architecture failed');
+  open(FOREIGN_FH, "-|", "dpkg", "--print-foreign-architectures")
+or error("dpkg --print-foreign-architecture failed");
+}
+my @architectures = ;
+push @architectures, ;
 chomp @architectures;
 
 my %gnutriplets;
@@ -37,10 +46,17 @@
  $gnutriplets{$triplet} = 1;
 }
 
-my %symlinks = map { $_ => 1 } ;
+my %symlinks;
+if (opendir(USRBIN, "$dpkgroot/usr/bin")) {
+  while (my $file = readdir(USRBIN)) {
+next unless $file =~ /[^-]+-[^-]+-[^-]+-pkg-config$/;
+my $name = "$dpkgroot/usr/bin/$file";
+$symlinks{$name} = 1;
+  }
+}
 
 foreach my $symlink (keys %symlinks) {
-  $symlink =~ m,^/usr/bin/([^-]+-[^-]+-[^-]+)-pkg-config, or next;
+  $symlink =~ m,^$dpkgroot/usr/bin/([^-]+-[^-]+-[^-]+)-pkg-config, or next;
   next if exists $gnutriplets{$1} && $action eq "update";
   next unless -l $symlink;
   next unless readlink $symlink eq $crosswrapper;
@@ -48,9 +64,9 @@
 error("failed to remove symlink $symlink: $!");
 }
 
-if ($action eq 'update') {
+if ($action eq 'update' && -e $crosswrapper) {
   foreach (keys %gnutriplets) {
-my $linktarget = "/usr/bin/${_}-pkg-config";
+my $linktarget = "$dpkgroot/usr/bin/${_}-pkg-config";
 next if exists $symlinks{$linktarget};
 next if -e $linktarget;
 symlink $crosswrapper, $linktarget or


signature.asc
Description: PGP signature


Bug#964462: parlatype-libreoffice-extension: please rename to libreoffice-parlatype

2020-07-07 Thread Rene Engelhard
Hi,


Am 07.07.20 um 18:00 schrieb Gabor Karsay:
> Rene Engelhard schrieb am 07.07.20 um 17:05:
> > [...]
> > LibreOffice extensions are packaged as libreoffice-* in Debian. Yes,
> > even ones not shipped by LibreOffice itself.
> > [...]
>
> Well, the idea is that it's closer to Parlatype than to LibreOffice. I
> guess there is more code in Parlatype to make this possible than in
> LibreOffice. But yes, it is a LibreOffice extension.
>
writer2latex also uses libwriter2latex-java (though admittedly that is

a artificial split just at Debian and not upstream...) and
libreoffice-voikko libvoikko

for their actual work :-)

> I saw a few packaged extensions but I was not aware of a naming
> convention. 
The convention is libreoffice-*. [1] :)
> I'm curious why the severity is "important" ("major effect
> on the usability of a package")?
>
I didn't want to go to RC level and minor was too minor for me :-)

> If you really think it's important, I can change it. It's only in
> experimental, so that shouldn't be a big problem.

I do. IMHO we should go for consistency.

(One also could rename all extensions to something else, but that would

be more intrusive than changing this one which as you say only is in
experimental ;))


Regards,


Rene


[1] I think I wrote that down somewhen and it got lost. Or I didn't and
I misremember...



Bug#964453: please reenable libkms

2020-07-07 Thread Eric Anholt
On Tue, Jul 7, 2020 at 6:15 AM Michel Dänzer  wrote:
>
> On 2020-07-07 2:45 p.m., Dmitry Baryshkov wrote:
> > Source: libdrm
> > Version: 2.4.102-1
> > Severity: normal
> >
> > libkms is usefull for other packages outside Debian (e.g. for VK-GL-CTS
> > test suite). Could you please reenable it (disabled in 2.4.46-3).
>
> AFAIK VK-GL-CTS never actually used libkms, it erroneously claims to
> require it.
>
> Upstream Mesa's GitLab CI pipeline uses this to modify the VK-GL-CTS
> source tree so it can be built without libkms:
>
> # surfaceless links against libkms and such despite not using it.
> sed -i '/gbm/d' targets/surfaceless/surfaceless.cmake
> sed -i '/libkms/d' targets/surfaceless/surfaceless.cmake
> sed -i '/libgbm/d' targets/surfaceless/surfaceless.cmake

And I've fixed it in upstream VK-GL-CTS, too.



Bug#964422: buster-pu: package raspi3-firmware/1.20190215-1+deb10u3

2020-07-07 Thread Adam D. Barratt
Hi,

On Mon, 2020-07-06 at 19:02 -0500, Gunnar Wolf wrote:
> Back in March, I uploaded to Buster version 1.20190215-1+deb10u3 of
> raspi3-firmware, stating it fixed "unbootableness" on several
> systems. I assumed it was all done, and went on with my life.
> 
> Some time later (kernel / firmware updates are not *that* common), I
> started getting reports of b0rkenness again.
> 
> Thorsten Glaser found and fixed (#961377) a very small and silly typo
> in my last upload, and fixed it: I used a wrong variable name when
> installing the new set of DTBs.
> 
> Please allow this package, version 1.20190215-1+deb10u4, to enter
> Stable. The fix is found at:
> 
> 
> https://salsa.debian.org/debian/raspi-firmware/-/commit/2bf38f62de0514c2759f2c33d147c935e4d044bf
> 

For future reference, please attach the full source debdiff to the
release.d.o bug report, rather than pointing to external resources.
It's much easier to track and confirm things when the report is self-
contained.

Regards,

Adam



Bug#964456: stretch-pu: package roundcube/1.2.3+dfsg.1-4+deb9u6

2020-07-07 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Tue, 2020-07-07 at 16:00 +0200, Guilhem Moulin wrote:
> In a recent post roundcube webmail upstream has announced the
> following security fix:
> 
> CVE-2020-15562: Prevent cross-site scripting (XSS) via HTML
> messages with malicious svg/namespace.
> 
> This is tracker as #964355.  The security team gave the green light
> for an upload of 1.3.14+dfsg.1-1~deb10u1 to buster-security, but
> suggested to target old-p-u for stretch.   stretch currently has
> 1.2.3+dfsg.1-4+deb9u3
> wwhile stretch-security and stretch-pu have 1.2.3+dfsg.1-
> 4+deb9u5.  Both debdiffs attached.

It looks like you actually attached the latter debdiff twice. But
that's the one we want, so that's fine. :-)

Please go ahead.

> unblock roundcube/1.2.3+dfsg.1-4+deb9u6

Did reportbug add that for a p-u request?

Regards,

Adam



Bug#964465: python3-ironic-lib: missing Breaks+Replaces: ironic-common (<< 1:15)

2020-07-07 Thread Andreas Beckmann
Package: python3-ironic-lib
Version: 4.2.1-1
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 .../python3-ironic-lib_4.2.1-1_all.deb ...
  Unpacking python3-ironic-lib (4.2.1-1) over (2.14.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-ironic-lib_4.2.1-1_all.deb (--unpack):
   trying to overwrite '/etc/ironic/rootwrap.d/ironic-lib.filters', which is 
also in package ironic-common 1:11.1.0-6
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-ironic-lib_4.2.1-1_all.deb

(Not sure which ironic-common version dropped the file, the sid version no
longer has it.)


cheers,

Andreas


ironic-common=1:11.1.0-6_python3-ironic-lib=4.2.1-1.log.gz
Description: application/gzip


Bug#955743: AH01882: mod_ssl was compiled against a newer library

2020-07-07 Thread Francois Mescam
Now the message I've observed does not appear in the logs so I think you 
can close the bug.


Thank's

--
Francois Mescam



Bug#964456: stretch-pu: package roundcube/1.2.3+dfsg.1-4+deb9u6

2020-07-07 Thread Guilhem Moulin
On Tue, 07 Jul 2020 at 17:31:01 +0100, Adam D. Barratt wrote:
>> The security team gave the green light for an upload of
>> 1.3.14+dfsg.1-1~deb10u1 to buster-security, but suggested to target
>> old-p-u for stretch.   stretch currently has 1.2.3+dfsg.1-4+deb9u3
>> wwhile stretch-security and stretch-pu have 1.2.3+dfsg.1- 4+deb9u5.
>> Both debdiffs attached.
>
> It looks like you actually attached the latter debdiff twice. But
> that's the one we want, so that's fine. :-)

Oops :-P

> Please go ahead.

Thanks, done!
 
>> unblock roundcube/1.2.3+dfsg.1-4+deb9u6
> 
> Did reportbug add that for a p-u request?

Ooops nope my bad, I mixed things up in my template.  Thanks for
pointing it out!

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#964334: segfault repeatedly

2020-07-07 Thread Martin Hradil
Package: chromium
Version: 83.0.4103.116-2
Followup-For: Bug #964334

Dear Maintainer,

seeing the same issue in chromium 83.0.4103.116-2, keeps crashing after a few 
minutes of use.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964362 is a dup of this one,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963548 *may* be, but that one 
also mentions tab crashes (as opposed to browser crashes)
In 83.0.4103.116-1~deb10u2 I get both tab crashes (consistently when opening 
google chat) and browser crashes.

In 83.0.4103.116-2 I only get browser crashes...

[30759:30759:0707/165049.768521:ERROR:sandbox_linux.cc(374)] 
InitializeSandbox() called with multiple threads in process gpu-process.
[30720:30840:0707/165050.050567:ERROR:object_proxy.cc(632)] Failed to call 
method: org.freedesktop.DBus.Properties.Get: object_path= 
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.UPower was not provided by any .service files
[30720:30840:0707/165050.054057:ERROR:object_proxy.cc(632)] Failed to call 
method: org.freedesktop.UPower.GetDisplayDevice: object_path= 
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.UPower was not provided by any .service files
[30720:30840:0707/165050.054430:ERROR:object_proxy.cc(632)] Failed to call 
method: org.freedesktop.UPower.EnumerateDevices: object_path= 
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.UPower was not provided by any .service files
libpng warning: iCCP: known incorrect sRGB profile
Received signal 11 SEGV_MAPERR 7f01bc2be677
#0 0x563a76110c69 (/usr/lib/chromium/chromium+0x52b3c68)
#1 0x563a7606fef3 (/usr/lib/chromium/chromium+0x5212ef2)
#2 0x563a761107f1 (/usr/lib/chromium/chromium+0x52b37f0)
#3 0x7f62e4052110 (/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f)
#4 0x7f62df13dd3c (/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b)
#5 0x7f62df13ff33 (/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32)
#6 0x7f62df141bf9 __libc_malloc
#7 0x563a761289be operator new()
#8 0x7f62df3c8a2c std::__cxx11::basic_string<>::reserve()
#9 0x7f62df3be498 std::__cxx11::basic_stringbuf<>::overflow()
#10 0x7f62df3c704a std::basic_streambuf<>::xsputn()
#11 0x7f62df3b9714 std::__ostream_insert<>()
#12 0x563a76110d39 (/usr/lib/chromium/chromium+0x52b3d38)
#13 0x563a76111054 (/usr/lib/chromium/chromium+0x52b4053)
#14 0x563a76082412 (/usr/lib/chromium/chromium+0x5225411)
#15 0x563a76084548 (/usr/lib/chromium/chromium+0x5227547)
#16 0x563a747ca12a (/usr/lib/chromium/chromium+0x396d129)
#17 0x563a747ca17e (/usr/lib/chromium/chromium+0x396d17d)
#18 0x563a73e1f387 (/usr/lib/chromium/chromium+0x2fc2386)
#19 0x563a747833d9 (/usr/lib/chromium/chromium+0x39263d8)
#20 0x563a7478361e (/usr/lib/chromium/chromium+0x392661d)
#21 0x563a747cd967 (/usr/lib/chromium/chromium+0x3970966)
#22 0x563a747f94c7 (/usr/lib/chromium/chromium+0x399c4c6)
#23 0x563a747f977e (/usr/lib/chromium/chromium+0x399c77d)
#24 0x563a747ca13f (/usr/lib/chromium/chromium+0x396d13e)
#25 0x563a747ca17e (/usr/lib/chromium/chromium+0x396d17d)
#26 0x563a73e1f387 (/usr/lib/chromium/chromium+0x2fc2386)
#27 0x563a740e27a3 (/usr/lib/chromium/chromium+0x32857a2)
#28 0x563a744510bc (/usr/lib/chromium/chromium+0x35f40bb)
#29 0x563a7624245f (/usr/lib/chromium/chromium+0x53e545e)
#30 0x563a76248a24 (/usr/lib/chromium/chromium+0x53eba23)
#31 0x563a76246b62 (/usr/lib/chromium/chromium+0x53e9b61)
#32 0x563a7624582d (/usr/lib/chromium/chromium+0x53e882c)
#33 0x563a7623e213 (/usr/lib/chromium/chromium+0x53e1212)
#34 0x563a76259abb (/usr/lib/chromium/chromium+0x53fcaba)
#35 0x563a76259de0 (/usr/lib/chromium/chromium+0x53fcddf)
#36 0x563a76259370 (/usr/lib/chromium/chromium+0x53fc36f)
#37 0x563a740cbc46 (/usr/lib/chromium/chromium+0x326ec45)
#38 0x563a740cb76c (/usr/lib/chromium/chromium+0x326e76b)
#39 0x563a740c7eed (/usr/lib/chromium/chromium+0x326aeec)
#40 0x563a740be74b (/usr/lib/chromium/chromium+0x326174a)
#41 0x563a740b1044 (/usr/lib/chromium/chromium+0x3254043)
#42 0x563a740b0d75 (/usr/lib/chromium/chromium+0x3253d74)
#43 0x563a740cf426 (/usr/lib/chromium/chromium+0x3272425)
#44 0x563a7612e0e0 (/usr/lib/chromium/chromium+0x52d10df)
#45 0x7f62e2e07b0f (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7.0.0+0x23b0e)
#46 0x7f62e2e0824f event_base_loop
#47 0x563a7612e38e (/usr/lib/chromium/chromium+0x52d138d)
#48 0x563a760ce5d5 (/usr/lib/chromium/chromium+0x52715d4)
#49 0x563a760a6670 (/usr/lib/chromium/chromium+0x524966f)
#50 0x563a743ec3b3 (/usr/lib/chromium/chromium+0x358f3b2)
#51 0x563a760e42a9 (/usr/lib/chromium/chromium+0x52872a8)
#52 0x563a76120c9e (/usr/lib/chromium/chromium+0x52c3c9d)
#53 0x7f62e4046f27 start_thread
#54 0x7f62df1b531f clone
  r8: 0077  r9: 0050 r10: 0004 r11: 
007c
 r12: 7f62bc20 r13: 7f62bc30 r14: 7f62bc206850 r15: 
0040
  di: 0261  si: 0004  bp: 0260  bx: 
7f01bc2be66f
  dx: 7f62bc8

Bug#964466: missing packet on installing wine32-preloader:i386 4.0-2 on ftp.de.debian.org

2020-07-07 Thread Giancarlo Giesa
Package: wine32-preloader:i386

Version: 4.0-2

When installing by ufficial german repository are missing some dependence:

(i386)
libsystemd0,libopenjp2,libcups2,libglapi-mesa,libudev1,libosmesa6,mesa-va-drivers,mesa-vdpau-drivers

i just performed apt-get update before



Bug#940613: ITP: GNU poke -- An interactive, extensible editor for binary data

2020-07-07 Thread Sudip Mukherjee
Hi Sergio,

On Tue, Sep 17, 2019 at 05:30:01PM -0400, Sergio Durigan Junior wrote:
> [ Forwarding.  ]
> 
> <#secure method=pgpmime mode=sign>
> On Tuesday, September 17 2019, I wrote:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sergio Durigan Junior 
> >
> > * Package name: poke
> >   Version : 0.1-beta
> >   Upstream Author : Jose E. Marchesi
> > * URL : http://www.jemarch.net/poke.html
> > * License : GPL-3+
> >   Programming Lang: C
> >   Description : GNU poke -- An interactive, extensible editor for 
> > binary data
> >
> >  GNU poke is an interactive, extensible editor for binary data. Not
> >  limited to editing basic entities such as bits and bytes, it provides a
> >  full-fledged procedural, interactive programming language designed to
> >  describe data structures and to operate on them.

Any idea when this can land? I attended a conference last year where
Jose demonstrated this and it seemed pretty cool.

--
Regards
Sudip



Bug#819490: debmirror: SHA256 validating of debian-installer files (patch)

2020-07-07 Thread Bastian Germann
The merge request was open for 1.5 years. The change is enclosed as
patch which applied on 0b94d0df.
From 4b510c506ced96636b973066de270fce707caa35 Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Fri, 22 Feb 2019 23:48:50 +0100
Subject: [PATCH] Download and validate SHA256SUMS (closes: #819490)

---
 debmirror | 67 ++-
 1 file changed, 37 insertions(+), 30 deletions(-)

diff --git a/debmirror b/debmirror
index 2d12e9e..8018ca2 100755
--- a/debmirror
+++ b/debmirror
@@ -1107,8 +1107,7 @@ foreach my $dist (keys %distset) {
   }
 }

-# Get and parse MD5SUMS files for D-I images.
-# (There are not currently other checksums for these.)
+# Get and parse MD5SUMS/SHA256SUMS files for D-I images.
 di_add_files() if @di_dists;

 # Get Packages and Sources files and other miscellany.
@@ -2942,35 +2941,39 @@ sub di_add_files {

   my $image_dir = "dists/$dist/main/installer-$arch/current/images";
   make_dir ("$tdir/$image_dir");
-  if (!remote_get("$image_dir/MD5SUMS", $tdir)) {
-say("Failed to download $image_dir/MD5SUMS; skipping.");
-return;
-  }
-  if (-f "$tdir/$image_dir/MD5SUMS") {
-$bytes_to_get += -s _; # As we did not have the size earlier
-  }

-  local $/;
-  undef $/; # Read whole file
-  open(FILE, "<", "$tdir/$image_dir/MD5SUMS") or die "$tdir/$image_dir/MD5SUMS: $!";
-  $_ = ;
-  while (m/^([A-Za-z0-9]{32}  .*)/mg) {
-my ($md5sum, $filename) = split(' ', $1, 3);
-$filename =~ s:^\./::;
-if(!(defined($include) && ($image_dir."/".$filename)=~/$include/o)) {
-  next if (defined($exclude) && ($image_dir."/".$filename)=~/$exclude/o);
+  foreach my $sums_fname ("SHA256SUMS", "MD5SUMS") {
+my $sum_name = substr($sums_fname, 0, 6);
+if (!remote_get("$image_dir/$sums_fname", $tdir)) {
+  say("Failed to download $image_dir/$sums_fname; skipping.");
+  return;
 }
+if (-f "$tdir/$image_dir/$sums_fname") {
+  $bytes_to_get += -s _; # As we did not have the size earlier
+}
+
+local $/;
+undef $/; # Read whole file
+open(FILE, "<", "$tdir/$image_dir/$sums_fname") or die "$tdir/$image_dir/$sums_fname: $!";
+$_ = ;
+while (m/^([A-Za-z0-9]+  .+)/mg) {
+  my ($checksum, $filename) = split(' ', $1, 3);
+  $filename =~ s:^\./::;
+  if(!(defined($include) && ($image_dir."/".$filename)=~/$include/o)) {
+next if (defined($exclude) && ($image_dir."/".$filename)=~/$exclude/o);
+  }

-$di_files{$image_dir}{$filename}{md5sum} = $md5sum;
+  $di_files{$image_dir}{$filename}{$sum_name} = $checksum;

-# Check against the version currently on the mirror
-if (check_file(filename => "$image_dir/$filename", size => -1, MD5Sum => $md5sum)) {
-  $di_files{$image_dir}{$filename}{status} = 1;
-} else {
-  $di_files{$image_dir}{$filename}{status} = 0;
+  # Check against the version currently on the mirror
+  if (check_file(filename => "$image_dir/$filename", size => -1, $sum_name => $checksum)) {
+$di_files{$image_dir}{$filename}{status} = 1;
+  } else {
+$di_files{$image_dir}{$filename}{status} = 0;
+  }
 }
+close(FILE);
   }
-  close(FILE);
 }
   }
 }
@@ -2989,7 +2992,9 @@ sub di_get_files {
   $file =~ m:(^.*)/:;
   make_dir ("$tdir/$image_dir/$1") if $1;
   if (!remote_get("$image_dir/$file", $tdir) ||
-  !check_file(filename => "$tdir/$image_dir/$file", size => -1, MD5Sum => $di_files{$image_dir}{$file}{md5sum})) {
+  !check_file(filename => "$tdir/$image_dir/$file", size => -1,
+  SHA256 => $di_files{$image_dir}{$file}{SHA256},
+  MD5SUM => $di_files{$image_dir}{$file}{MD5SUM})) {
 $lres = 0;
 last if (! $do_dry_run);
   }
@@ -3007,9 +3012,11 @@ sub di_get_files {
 unlink "$image_dir/$file" if (-f "$image_dir/$file");
 link("$tdir/$image_dir/$file", "$image_dir/$file");
   }
-  # Move the MD5SUMS file in place on mirror
-  unlink "$image_dir/MD5SUMS" if (-f "$image_dir/MD5SUMS");
-  link("$tdir/$image_dir/MD5SUMS", "$image_dir/MD5SUMS");
+  # Move the checksums file in place on mirror
+  foreach my $sums_fname ("SHA256SUMS", "MD5SUMS") {
+unlink "$image_dir/$sums_fname" if (-f "$image_dir/$sums_fname");
+link("$tdir/$image_dir/$sums_fname", "$image_dir/$sums_fname");
+  }
 } elsif (! $do_dry_run) {
   say("Failed to download some files in $image_dir; not updating images.");
 }
@@ -3026,7 +3033,7 @@ sub di_cleanup {
   chomp $file;
   $file=~s:^\./::;
   if (! exists $di_files{$image_dir} || ! exists $di_files{$image_dir}{$file}) {
-next if (exists $di_files{$image_dir} && $file eq "MD5SUMS");
+next if (exists $

Bug#964467: elpa-markdown-mode: shoudl depend on markdown package

2020-07-07 Thread James Youngman
Package: elpa-markdown-mode
Version: 2.3+154-2
Severity: minor

Result is:

M-x markdown-other-window generates:




http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>

http://www.w3.org/1999/xhtml";>


*markdown-output*





/bin/bash: markdown: command not found







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

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

Versions of packages elpa-markdown-mode depends on:
ii  emacs1:26.1+1-3.2+deb10u1
ii  emacs-gtk [emacsen]  1:26.1+1-3.2+deb10u1
ii  emacsen-common   3.0.4

elpa-markdown-mode recommends no packages.

Versions of packages elpa-markdown-mode suggests:
pn  elpa-imenu-list  

-- no debconf information



Bug#964438: apt-listbugs: dns error when running from cron job

2020-07-07 Thread Francesco Poli
Control: tags -1 + moreinfo


On Tue, 07 Jul 2020 11:36:43 +0200 Oswald Buddenhagen wrote:

> Package: apt-listbugs
> Version: 0.1.32
> Severity: normal
> 
> for some days/weeks now, i get this mail every day:
> 
> --
> From: apt-listbugs timer 
> To: root
> Subject: prefclean output on ugly
> 
> /usr/libexec/apt-listbugs/prefclean:
> E: getaddrinfo: Temporary failure in name resolution (bugs.debian.org:80)
> E: Exiting with error
> ---

Hello Oswald,
thanks for your bug report.

What you are experiencing is awkward, I have never seen anything like
this.

Please let me understand:

 • when did it begin? just after upgrading to apt-listbugs/0.1.32 ?
   or in some other point in time?

 • what happens if you try the following (as root)?

 # rm /var/spool/apt-listbugs/lastprefclean
 # /usr/libexec/apt-listbugs/prefclean

> 
> the program works just fine when invoked from the command line,

When you say "the program", do you mean "apt-listbugs" or
"/usr/libexec/apt-listbugs/prefclean" ?

> and 
> these errors are a little bit too consistent to be actual network 
> outages, so i suspect a permission problem in the configuration of the 
> systemd timer (note that apparmor is enabled).

I see that AppArmor is enabled, but it is enabled on my system as well,
and I do not experience any DNS issues in running the systemd timer...

Do you happen to have any special AppArmor configuration?
Mine is just the default that comes with current Debian testing.

Do you happen to know whether anything relevant has recently changed in
unstable (but not yet in testing)?

Is there anything else you are aware of, that could help in the
investigation?


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


pgpLiE3v25cSd.pgp
Description: PGP signature


Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1

2020-07-07 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Fri, 2020-07-03 at 22:19 +0100, Samuel Henrique wrote:
> A backported upstream patch [0] is required to fix #940284 [1] on
> nmap;
> Bug title: autogeneration of ssl key in ssl server mode of ncat is
> broken
> 
> The issue itself is well described in both BTS [1] and the upstream
> bug report [2], but the summary of it is that the openssl shipped
> with Buster requires a key with minimum size of 2048b, while nmap
> 7.70 generates one sized 1024b. This has been fixed in 7.80 (which is
> the version on Testing right now).

Please go ahead.

Regards,

Adam



Bug#964244: stretch-pu: package xml-security-c/1.7.3-4+deb9u2

2020-07-07 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sat, 2020-07-04 at 13:00 +0200, Ferenc Wágner wrote:
> There's an old bug reported against xml-security-c (#922984), which
> was fixed in the 2.0 branch in buster but still lingers around in 1.7
> in stretch.  I'm ready to upload with the following debdiff:
> 
> $ debdiff xml-security-c_1.7.3-4+deb9u[23].dsc 
> diff -Nru xml-security-c-1.7.3/debian/changelog xml-security-c-
> 1.7.3/debian/changelog
> --- xml-security-c-1.7.3/debian/changelog 2018-12-10
> 11:45:41.0 +0100
> +++ xml-security-c-1.7.3/debian/changelog 2020-07-04
> 12:47:24.0 +0200
> @@ -1,3 +1,10 @@
> +xml-security-c (1.7.3-4+deb9u3) stretch; urgency=medium
> +
> +  * [02c3993] New patch: Fix a length bug in concat method.
> +Thanks to Scott Cantor (Closes: #922984 )
> 

Please go ahead, bearing in mind that the window for getting fixes into
the final stretch point release closes this weekend.

Regards,

Adam



Bug#960600: buster-pu: package asunder/2.9.3-3+deb10u1

2020-07-07 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Thu, 2020-05-14 at 14:25 +0200, Andreas Ronnquist wrote:
> The cddb service freedb,org has been closed down, and I would like to
> update asunder so that it uses gnudb.org by default instead. I
> mention it in a NEWS item too, so that others get a warning and
> chance to change their setting too.

diff -Nru asunder-2.9.3/debian/NEWS.Debian asunder-2.9.3/debian/NEWS.Debian
--- asunder-2.9.3/debian/NEWS.Debian2019-01-23 21:58:01.0 +0100
+++ asunder-2.9.3/debian/NEWS.Debian2020-05-14 14:12:58.0 +0200
@@ -1,3 +1,12 @@
+asunder (2.9.3-3+deb10u1) unstable; urgency=medium

That should be buster, in line with the changelog.

With that fixed, please go ahead.

Regards,

Adam



Bug#964417: buster-pu: package mod-gnutls/0.9.0-1.1~deb10u1

2020-07-07 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Tue, 2020-07-07 at 01:07 +0300, Adrian Bunk wrote:
> On Tue, Jul 07, 2020 at 12:58:41AM +0300, Adrian Bunk wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: buster
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> >   * Backported patches to fix test failures with the
> > apache CVE-2019-10092 fix. (Closes: #950300)
> >   * Disable a test that fails with GnuTLS >= 3.6.11. (Closes:
> > #950301)
> >   * Backported a fix for a possible segfault on failed TLS
> > handshake.
> > 
> > Technically the #950301 fix is not necessary in buster,
> > but the tests of this package are so fragile with changes
> > in build dependencies that disabling a test that might
> > pass is better-safe-than-sorry.
> 
> The missing debdiff is attached.

Please go ahead.

Regards,

Adam



Bug#948653: stretch-pu: package mod-gnutls/0.8.2-3+deb9u1

2020-07-07 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Tue, 2020-07-07 at 01:01 +0300, Adrian Bunk wrote:
> Control: retitle -1 stretch-pu: package mod-gnutls/0.8.2-3+deb9u2
> Control: tags -1 - pending
> 
> On Fri, Jul 03, 2020 at 06:57:55AM +0100, Adam D. Barratt wrote:
> > Hi,
> 
> Hi Adam,
> 
> > On Fri, 2020-01-31 at 08:43 +0200, Adrian Bunk wrote:
> > > Control: block -1 by 950300
> > > 
> > > On Tue, Jan 28, 2020 at 08:41:29AM +, Adam D. Barratt wrote:
> > > > Control: tags -1 + confirmed
> > > > 
> > > > On 2020-01-11 10:34, Adrian Bunk wrote:
> > > > >   * Avoid deprecated ciphersuites in test suite (Closes:
> > > > > #907008)
> > > > > 
> > > > > FTBFS, tests were broken by gnutls28 3.5.8-5+deb9u4.
> > > > 
> > > > Please go ahead.
> > > 
> > > The apache2 2.4.25-3+deb9u9 upgrade causes an unrelated FTBFS in 
> > > mod-gnutls, which made 0.8.2-3+deb9u1 fail on the buildds.
> > > 
> > > Reported as #950300, this bug is present even in unstable.
> > > 
> > > Seems fixed in upstream 0.9.1.
> > > 
> > > I'll take care of this, but there is not enough time left to get
> > > this fixed for the upcoming stretch point release - I won't do a
> > > 0-
> > > day NMU  for a just reported FTBFS in unstable.
> > 
> > What's the status of this?
> 
> sorry for the delay, debdiff is attached.

Thanks; please go ahead.

Regards,

Adam



Bug#947758: buster-pu: package node-handlebars/3:4.1.0-1+deb10u1

2020-07-07 Thread Adam D. Barratt
Control: tags -1 -pending +confirmed

On Mon, 2020-05-04 at 22:02 +0200, Xavier wrote:
> Le 04/05/2020 à 18:53, Mattia Rizzolo a écrit :
> > Hi,
> > 
> > let me reply before adsb has a chance ;)
> > 
> > On Mon, May 04, 2020 at 02:24:20PM +0200, Xavier wrote:
> > > Finally I found a way to fix CVE and keep autopkgtest OK
> > > (node-markdown-it-html5-embed). Here is a debdiff for a future
> > > point release
> > 
> > This is good, however,
> > 
> > > diff --git a/debian/changelog b/debian/changelog
> > > index b985661..64df8db 100644
> > > --- a/debian/changelog
> > > +++ b/debian/changelog
> > > @@ -1,3 +1,11 @@
> > > +node-handlebars (3:4.1.0-1+deb10u1) buster; urgency=medium
> > > +
> > > +  * Team upload
> > > +  * Disallow calling "helperMissing" and "blockHelperMissing"
> > > directly
> > > +(Closes: CVE-2019-19919)
> > > +
> > > + -- Xavier Guimard   Mon, 04 May 2020 14:21:11
> > > +0200
> > 
> > By now 3:4.1.0-1+deb10u1 is already accepted in p-u, built and all,
> > and
> > it can't really be removed from there and replaced by a same-
> > versined
> > pacakge.
> > 
> > Please prepare a +deb10u2 version, and post here a debdiff against
> > the
> > already uploaded +deb10u1 one.
> 
> Is it good so ?

Sorry for the delay. Please feel free to go ahead.

Regards,

Adam



  1   2   3   >