Bug#916902: Taking over pspp into Debian Science team maintenance (Was: pspp: CVE-2018-20230)

[Andreas Tille]

Hi Friedrich,

I stumbled upon #916902 in my Buster bug squashing effort.  I'm willing
to apply and upload the suggested fix[1], but I feel our both time
better spent if the changes are done in a repository on Salsa.  Since
the package perfectly fits into Debian Science scope I'd volunteer to
move the package to Debian Science.

In case I will not hear from you I in the next five days asume you agree
with this.

Kind regards

  Andreas.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916902#32

-- 
http://fam-tille.de

Bug#927753: gnome-maps: segmentation fault at startup

[Simon McVittie]

Control: reassign -1 libgeocode-glib0 3.26.0-2
Control: severity 925539 serious
Control: forcemerge 925539 -1

On Tue, 23 Apr 2019 at 01:05:55 +0200, gpe wrote:
> I confirm. Installing libgeocode-glib0 3.26.1-1 resolves the issue.

Reassigning to libgeocode-glib0 and merging with the existing bug, then.
Thanks for confirming this.

smcv

Bug#927779: evince: search box ignores Japanese input method

[Kenshi Muto]

Package: evince
Version: 3.30.2-3
Severity: normal

Dear Maintainer,

I noticed evince on Buster version won't accept inputting Japanese via
input method.

- After opening any PDFs on evince, I pushed Ctrl-J to launch
  Japanese input method (I use 'uim'). But it seems be ignored.
- From uim-toolbar-gtk's status view, the search box only accepts
  'direct' input.
- Stretch version (3.22.1) had accepted an input method.
- copying Japanese string & pasting it to search box still works.
- Other applications, for example both gedit (3.30.2-2) and gnome-help
  (yelp 3.31.90-1) work well.

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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evince-common3.30.2-3
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-8
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libevdocument3-4 3.30.2-3
ii  libevview3-3 3.30.2-3
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgnome-desktop-3-173.30.2.1-1
ii  libgtk-3-0   3.24.5-1
ii  libnautilus-extension1a  3.30.5-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libsecret-1-00.18.7-1
ii  shared-mime-info 1.10-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1

Versions of packages evince suggests:
ii  gvfs 1.38.1-3
ii  nautilus-sendto  3.8.6-3
ii  poppler-data 0.4.9-2
pn  unrar

-- no debconf information

Bug#918988: Update libaprutil1-dbd-mysql

[Otto Kekäläinen]

It was reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920619#20:
> Updating libaprutil1-dbd-mysql to 1.6.1-4 (from unstable as of now)
> fixed the problem

Does this fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918988
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916375 as well?

Bug#927778: unblock: bind9/1:9.11.5.P4+dfsg-3

[Cyril Brulebois]

Niels Thykier  (2019-04-23):
> Package: release.debian.org
> Severity: normal
> Tags: d-i confirmed
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi,
> 
> I am filing an unblock for bind9 as it has a fixed RC bug and
> needs a d-i ack.
> 
> bind9 (1:9.11.5.P4+dfsg-3) unstable; urgency=medium
> 
>   * More fixes to the AppArmor policy for Samba AD DLZ
> - allow access to /dev/urandom
> - allow locking for dns.keytab
> - fix path to smb.conf
> 
>  -- Bernhard Schmidt   Mon, 22 Apr 2019 22:31:06 +0200
> 
> bind9 (1:9.11.5.P4+dfsg-2) unstable; urgency=medium
> 
>   [ Ondřej Surý ]
>   * Update d/gbp.conf for Debian Buster
> 
>   [ Bernhard Schmidt ]
>   * Cherry-Pick upstream commit to prevent dnssec-keymgr from immediately
> expiring and deleting old DNSSEC keys when being run for the first
> time (Closes: #923984)
>   * Update AppArmor policy for Samba AD DLZ
> - Add changed default location for named.conf
> - Allow read/mmap on some Samba libraries
> Thanks to Steven Monai (Closes: #920530)
> 
>   [ Andreas Beckmann ]
>   * bind9.preinst: cope with ancient conffile named.conf.options
> (Closes: #905177)
> 
>  -- Bernhard Schmidt   Tue, 02 Apr 2019 21:12:50 +0200
> 
> 
> unblock bind9/1:9.11.5.P4+dfsg-3

Not used on release archs at the moment, so no objections.


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


signature.asc
Description: PGP signature

Bug#927778: unblock: bind9/1:9.11.5.P4+dfsg-3

[Niels Thykier]

Package: release.debian.org
Severity: normal
Tags: d-i confirmed
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

I am filing an unblock for bind9 as it has a fixed RC bug and
needs a d-i ack.

bind9 (1:9.11.5.P4+dfsg-3) unstable; urgency=medium

  * More fixes to the AppArmor policy for Samba AD DLZ
- allow access to /dev/urandom
- allow locking for dns.keytab
- fix path to smb.conf

 -- Bernhard Schmidt   Mon, 22 Apr 2019 22:31:06 +0200

bind9 (1:9.11.5.P4+dfsg-2) unstable; urgency=medium

  [ Ondřej Surý ]
  * Update d/gbp.conf for Debian Buster

  [ Bernhard Schmidt ]
  * Cherry-Pick upstream commit to prevent dnssec-keymgr from immediately
expiring and deleting old DNSSEC keys when being run for the first
time (Closes: #923984)
  * Update AppArmor policy for Samba AD DLZ
- Add changed default location for named.conf
- Allow read/mmap on some Samba libraries
Thanks to Steven Monai (Closes: #920530)

  [ Andreas Beckmann ]
  * bind9.preinst: cope with ancient conffile named.conf.options
(Closes: #905177)

 -- Bernhard Schmidt   Tue, 02 Apr 2019 21:12:50 +0200


unblock bind9/1:9.11.5.P4+dfsg-3

Thanks,
~Niels
Base version: bind9_1:9.11.5.P4+dfsg-1 from testing
Target version: bind9_1:9.11.5.P4+dfsg-3 from unstable

Hints in place:
==> nthykier
  #2019-04-23
  unblock bind9/1:9.11.5.P4+dfsg-3
==> freeze
  # These udebs need to be put in one of the lists:
  block-udeb bind9

Excuses:

bind9 (1:9.11.5.P4+dfsg-1 to 1:9.11.5.P4+dfsg-3)
Migration status: BLOCKED: Needs an approval (either due to a freeze, the 
source suite or a manual hint)
Maintainer: Debian DNS Team
Too young, only 0 of 2 days old
Updating bind9 fixes old bugs: #905177
Piuparts tested OK - https://piuparts.debian.org/sid/source/b/bind9.html
Required age reduced by 3 days because of autopkgtest
Not touching package due to block-udeb request by freeze (please contact 
the d-i release manager if an update is needed)
Not touching package due to block request by freeze (please contact 
debian-release if update is needed)

Filter applied (not reflected in the diffstat):
  filterdiff -x **/*.po -x **/*.pot

 bind9.preinst   |   10 +
 changelog   |   29 +++
 extras/apparmor.d/usr.sbin.named|   11 +
 gbp.conf|3 
 patches/keymgr-dont-immediately-delete.diff |  217 
 patches/series  |1 
 6 files changed, 267 insertions(+), 4 deletions(-)

gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made 2019-02-22T17:47:49 UTC
gpgv:using RSA key D6E01EC516A5DFCEF71956D3775079E5B850BC93
gpgv:issuer "be...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on 
/tmp/tmplzeh50h3/bind9_9.11.5.P4+dfsg-1.dsc
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made 2019-04-22T21:03:24 UTC
gpgv:using RSA key D6E01EC516A5DFCEF71956D3775079E5B850BC93
gpgv:issuer "be...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on 
/tmp/tmplzeh50h3/bind9_9.11.5.P4+dfsg-3.dsc
diff -Nru bind9-9.11.5.P4+dfsg/debian/bind9.preinst 
bind9-9.11.5.P4+dfsg/debian/bind9.preinst
--- bind9-9.11.5.P4+dfsg/debian/bind9.preinst   2019-02-22 16:54:10.0 
+
+++ bind9-9.11.5.P4+dfsg/debian/bind9.preinst   2019-04-22 20:31:06.0 
+
@@ -20,7 +20,15 @@
theirs=$(md5sum /etc/bind/named.conf.options | sed 's/ .*$//')
mine=56919cbc0d819c9a303a8bdeb306b5f1
if [ "$mine" = "$theirs" ]; then
-   mv /etc/bind/named.conf.options 
/etc/bind/named.conf.options.dpkg-old
+   if [ -n "$(dpkg-query -f '${Conffiles}' -W bind9 | grep 
/etc/bind/named.conf.options)" ]; then
+   # dpkg knows /etc/bind/named.conf.options as a conffile 
(from squeeze or older)
+   # cannot move the outdated file aside to avoid dpkg 
noticing deleted-by-local-admin
+   # therefore edit it in place to make it match the 
to-be-installed version
+   cp -p /etc/bind/named.conf.options 
/etc/bind/named.conf.options.dpkg-old
+   sed -i '26{/^$/d}; 23{/auth-nxdomain no;/d}' 
/etc/bind/named.conf.options
+   else
+   mv /etc/bind/named.conf.options 
/etc/bind/named.conf.options.dpkg-old
+   fi
fi
fi
 ;;
diff -Nru bind9-9.11.5.P4+dfsg/debian/changelog 
bind9-9.11.5.P4+dfsg/debian/changelog
--- bind9-9.11.5.P4+dfsg/debian/changelog   2019-02-22 16:54:10.0 
+
+++ bind9-9.11.5.P4+dfsg/debian/changelog   

Bug#927777: unblock: alsa-utils/1.1.8-2

[Cyril Brulebois]

Niels Thykier  (2019-04-23):
> Package: release.debian.org
> Severity: normal
> Tags: d-i confirmed
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi,
> 
> I am filing an unblock for alsa-utils as it has a fixed RC bug and
> needs a d-i ack.
> 
> alsa-utils (1.1.8-2) unstable; urgency=medium
> 
>   * Introduce Fix-alsactl-to-restore-config.patch. Don't rely on undocumented
> /etc/alsa/state-daemon.conf to start alsa-state.service.  
> alsa-restore.service
> now will have an error code 99 the first time it runs. But after an 
> reload of
> the service or just a reboot both services will run smoothly.
> [closes: #925455]
> 
>  -- Elimar Riesebieter   Sat, 30 Mar 2019 10:18:40 +0100
> 
> unblock alsa-utils/1.1.8-2
> 
> Thanks,
> ~Niels

No objections, thanks.


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


signature.asc
Description: PGP signature

Bug#927777: unblock: alsa-utils/1.1.8-2

[Niels Thykier]

Package: release.debian.org
Severity: normal
Tags: d-i confirmed
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

I am filing an unblock for alsa-utils as it has a fixed RC bug and
needs a d-i ack.

alsa-utils (1.1.8-2) unstable; urgency=medium

  * Introduce Fix-alsactl-to-restore-config.patch. Don't rely on undocumented
/etc/alsa/state-daemon.conf to start alsa-state.service.  
alsa-restore.service
now will have an error code 99 the first time it runs. But after an reload 
of
the service or just a reboot both services will run smoothly.
[closes: #925455]

 -- Elimar Riesebieter   Sat, 30 Mar 2019 10:18:40 +0100

unblock alsa-utils/1.1.8-2

Thanks,
~Niels
Base version: alsa-utils_1.1.8-1 from testing
Target version: alsa-utils_1.1.8-2 from unstable

Hints in place:
==> freeze
  # These udebs need to be put in one of the lists:
  block-udeb alsa-utils

Excuses:

alsa-utils (1.1.8-1 to 1.1.8-2)
Migration status: BLOCKED: Needs an approval (either due to a freeze, the 
source suite or a manual hint)
Maintainer: Debian ALSA Maintainers
13 days old (needed 5 days)
Updating alsa-utils fixes old bugs: #925455
Piuparts tested OK - 
https://piuparts.debian.org/sid/source/a/alsa-utils.html
Not touching package due to block-udeb request by freeze (please contact 
the d-i release manager if an update is needed)
Not touching package due to block request by freeze (please contact 
debian-release if update is needed)

Filter applied (not reflected in the diffstat):
  filterdiff -x **/*.po -x **/*.pot

 changelog   |   10 ++
 patches/Fix-alsactl-to-restore-config.patch |   46 
 patches/series  |1 
 3 files changed, 57 insertions(+)

gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made 2019-02-11T12:43:26 UTC
gpgv:using RSA key E8175486C02929837C286A1625502F6FCBE3CB04
gpgv:issuer "jo...@mallach.net"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on 
/tmp/tmpy1szi6bf/alsa-utils_1.1.8-1.dsc
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/nthykier/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made 2019-04-09T16:08:42 UTC
gpgv:using RSA key D1E1316E93A760A8104D85FABB3A68018649AA06
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on 
/tmp/tmpy1szi6bf/alsa-utils_1.1.8-2.dsc
diff -Nru alsa-utils-1.1.8/debian/changelog alsa-utils-1.1.8/debian/changelog
--- alsa-utils-1.1.8/debian/changelog   2019-01-27 18:55:15.0 +
+++ alsa-utils-1.1.8/debian/changelog   2019-03-30 09:18:40.0 +
@@ -1,3 +1,13 @@
+alsa-utils (1.1.8-2) unstable; urgency=medium
+
+  * Introduce Fix-alsactl-to-restore-config.patch. Don't rely on undocumented
+/etc/alsa/state-daemon.conf to start alsa-state.service.  
alsa-restore.service
+now will have an error code 99 the first time it runs. But after an reload 
of
+the service or just a reboot both services will run smoothly.
+[closes: #925455]
+
+ -- Elimar Riesebieter   Sat, 30 Mar 2019 10:18:40 +0100
+
 alsa-utils (1.1.8-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru alsa-utils-1.1.8/debian/patches/Fix-alsactl-to-restore-config.patch 
alsa-utils-1.1.8/debian/patches/Fix-alsactl-to-restore-config.patch
--- alsa-utils-1.1.8/debian/patches/Fix-alsactl-to-restore-config.patch 
1970-01-01 00:00:00.0 +
+++ alsa-utils-1.1.8/debian/patches/Fix-alsactl-to-restore-config.patch 
2019-03-30 09:18:40.0 +
@@ -0,0 +1,46 @@
+From 6198e81500938a1e0f5e9d8f58c4e45dec2ee6b3 Mon Sep 17 00:00:00 2001
+From: Elimar Riesebieter 
+Date: Sat, 30 Mar 2019 10:07:46 +0100
+Subject: [PATCH] Fix-alsactl-to-restore-config.
+
+---
+ alsactl/alsa-restore.service.in | 2 +-
+ alsactl/alsa-state.service.in   | 5 +++--
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/alsactl/alsa-restore.service.in b/alsactl/alsa-restore.service.in
+index 38ffea7..74b9290 100644
+--- a/alsactl/alsa-restore.service.in
 b/alsactl/alsa-restore.service.in
+@@ -8,7 +8,7 @@ Description=Save/Restore Sound Card State
+ Documentation=man:alsactl(1)
+ ConditionPathExists=!@daemonswitch@
+ ConditionPathExistsGlob=/dev/snd/control*
+-ConditionPathExists=@asoundrcfile@
++After=alsa-state.service
+ 
+ [Service]
+ Type=oneshot
+diff --git a/alsactl/alsa-state.service.in b/alsactl/alsa-state.service.in
+index a3c6e49..f631cc3 100644
+--- a/alsactl/alsa-state.service.in
 b/alsactl/alsa-state.service.in
+@@ -1,4 +1,4 @@
+-#
++
+ # Note that two different ALSA card state management schemes exist and they
+ # can be switched using a file exist check - /etc/alsa/state-daemon.conf .
+ #
+@@ -6,7 +6,8 @@
+ [Unit]
+ Description=Manage Sound Card Stat

Bug#927776: archive.debian.org: Please do not remove stable-updates repo from mirror until its LTS ends

[Hideki Yamane]

Package: ftp.debian.org
Severity: important

Hi,

 Archiving EOLed repository is necessary work (thanks), however,
 it should not break current users' environment. jessie-backports
 is added by users with their intention but jessie-updates is enabled
 **by default** at installation, every jessie users are affects with
 this archiving.

 jessie is still under LTS at that time, so users expect they can run it
 without any modification until LTS ends (and it should be so, IMO).

 Unfortunately it broke users' system behavior (especially container
 environment), but our social contract says "4. Our priorities are our
 users and free software" - infrastructure change should not harm our
 users from that point of view. So, please do not remove stable-updates
 repo from mirror until its LTS ends next time (for stretch).


 If there is much benefit to archive it than stay it, then we would
 announce archiving work though several channels (users mailing list,
 our website, blog, SNS, etc...) before it happens (sorry, posting it
 to d-d-a is not enough, IMO).


-- 
Regards,

 Hideki Yamane 

Bug#927378: stretch-pu: package node-superagent/0.20.0+dfsg-1+deb9u1

[Adam D. Barratt]

On Tue, 2019-04-23 at 07:10 +0200, Xavier wrote:
> Le 23/04/2019 à 07:02, Adam D. Barratt a écrit :
> > On Mon, 2019-04-22 at 23:17 +0200, Xavier wrote:
> > > Le 22/04/2019 à 20:15, Paul Gevers a écrit :
> > 
> > [...]
> > > > I think your patch seems to be invalid in stretch. When I ran
> > > > the
> > > > autopkgtests in stretch I see the error below, which is exactly
> > > > the
> > > > new code.
> > 
> > [...]
> > > sorry for this error in my tests. Here is a new debdiff (let
> > > replaced
> > > by var for old nodejs, no consequences here since this variable
> > > isn't
> > > used somewhere else).
> > > 
> > 
> > +deb9u1 is already in p-u, so this needs to be a +deb9u2 with a fix
> > on
> > top of that, not a replacement +deb9u1.
> 
> OK, here is the new one

Thanks. Please go ahead.

Regards,

Adam

Bug#927307: Bug#927688: graphicsmagick breaks mpfit autopkgtest: LockSemaphoreInfo: Assertion `semaphore_info != (SemaphoreInfo *) NULL' failed

[GCS]

Hi Ole,

On Mon, Apr 22, 2019 at 3:45 PM Ole Streicher  wrote:
> On 21.04.19 12:46, László Böszörményi (GCS) wrote:
> > I do _not_ want to NMU it as I consider that unwelcomed as Ole is
> > alive and well. But please, do a fixed upload of gnudatalanguage soon.
>
> Thanks for the patience; I will check this in the next days; latest at
> weekend (I am currently on easter vacation). Pls ping me if it is really
> needed earlier.
 If possible, please do the upload by Wednesday or by Thursday. The
recent GraphicsMagick uploads contain way too many security fixes that
I would like to see in Buster. But I only can ask for a freeze
exception if I don't break anything. The patch for gnudatalanguage is
small and just need to be copied in.

Thanks,
Laszlo/GCS

Bug#663255: Une tentative de connexion à votre compte a été effectuée.

[zim...@helpdesk.com]

-- 
Votre accès par courriel a été restreint. Une tentative de connexion à votre 
compte à partir de cette adresse IP a été effectuée. 168.195.206.93:3389. Si 
vous ne validez pas votre compte dans les 24 heures, vous ne pourrez ni envoyer 
ni recevoir de nouveaux messages tant que vous n'avez pas re-validé votre 
mailbox.prior afin de gérer votre boîte aux lettres. CLIQUEZ ICI pour vérifier.

Bug#927275: Info received (Bug#927275: gnome-shell - Intel GPU - monitors.xml is ignored and settings are not applied after suspend/reboot)

[-]

Interestingly, if the dock with the two monitors (at work) is connected
via Thunderbolt, the naming of the interfaces is different (DP-5 and
DP-4 instead of DP-1-2 and DP1-3 with the L390). This can be seen in
the old monitors.xml from the first post (where it was connected to a
L390 via USB alternate mode DP) and the monitors.xml attached here,
which is created on the T470 with a Thunderbolt USB-C alternate mode.


monitors.xml
Description: XML document

Bug#927378: stretch-pu: package node-superagent/0.20.0+dfsg-1+deb9u1

[Xavier]

Le 23/04/2019 à 07:02, Adam D. Barratt a écrit :
> On Mon, 2019-04-22 at 23:17 +0200, Xavier wrote:
>> Le 22/04/2019 à 20:15, Paul Gevers a écrit :
> [...]
>>> I think your patch seems to be invalid in stretch. When I ran the
>>> autopkgtests in stretch I see the error below, which is exactly the
>>> new code.
> [...]
>> sorry for this error in my tests. Here is a new debdiff (let replaced
>> by var for old nodejs, no consequences here since this variable isn't
>> used somewhere else).
>>
> 
> +deb9u1 is already in p-u, so this needs to be a +deb9u2 with a fix on
> top of that, not a replacement +deb9u1.

OK, here is the new one
diff --git a/debian/changelog b/debian/changelog
index 645a574..5fde1b8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-superagent (0.20.0+dfsg-1+deb9u2) stretch; urgency=medium
+
+  * Fix incompatible instruction in CVE-2017-16129 patch
+
+ -- Xavier Guimard   Tue, 23 Apr 2019 07:07:07 +0200
+
 node-superagent (0.20.0+dfsg-1+deb9u1) stretch; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2017-16129.diff 
b/debian/patches/CVE-2017-16129.diff
index c1f700c..bedfe20 100644
--- a/debian/patches/CVE-2017-16129.diff
+++ b/debian/patches/CVE-2017-16129.diff
@@ -13,7 +13,7 @@ Last-Update: 2019-04-18
  
 +if (buffer) {
 +  // Protection against zip bombs and other nuisance
-+  let responseBytesLeft = self._maxResponseSize || 2;
++  var responseBytesLeft = self._maxResponseSize || 2;
 +  res.on('data', function(buf) {
 +responseBytesLeft -= buf.byteLength || buf.length;
 +if (responseBytesLeft < 0) {

Bug#927378: stretch-pu: package node-superagent/0.20.0+dfsg-1+deb9u1

[Adam D. Barratt]

On Mon, 2019-04-22 at 23:17 +0200, Xavier wrote:
> Le 22/04/2019 à 20:15, Paul Gevers a écrit :
[...]
> > I think your patch seems to be invalid in stretch. When I ran the
> > autopkgtests in stretch I see the error below, which is exactly the
> > new code.
[...]
> sorry for this error in my tests. Here is a new debdiff (let replaced
> by var for old nodejs, no consequences here since this variable isn't
> used somewhere else).
> 

+deb9u1 is already in p-u, so this needs to be a +deb9u2 with a fix on
top of that, not a replacement +deb9u1.

Regards,

Adam

Bug#927775: monit: CVE-2019-11454 CVE-2019-11455

[Salvatore Bonaccorso]

Source: monit
Version: 1:5.25.2-3
Severity: important
Tags: security upstream
Control: found -1 1:5.20.0-6

Hi,

The following vulnerabilities were published for monit.

CVE-2019-11454[0]:
| Persistent cross-site scripting (XSS) in http/cervlet.c in Tildeslash
| Monit before 5.25.3 allows a remote unauthenticated attacker to
| introduce arbitrary JavaScript via manipulation of an unsanitized user
| field of the Authorization header for HTTP Basic Authentication, which
| is mishandled during an _viewlog operation.


CVE-2019-11455[1]:
| A buffer over-read in Util_urlDecode in util.c in Tildeslash Monit
| before 5.25.3 allows a remote authenticated attacker to retrieve the
| contents of adjacent memory via manipulation of GET or POST
| parameters. The attacker can also cause a denial of service
| (application outage).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11454
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11454
[1] https://security-tracker.debian.org/tracker/CVE-2019-11455
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11455

Regards,
Salvatore

Bug#927774: bad build time dependency

[Harald Dunkel]

Package: jaxws
Version: 2.3.0.2-1

Trying to backport jaxws to Stretch I stumbled over this:

{hdunkel@dpcl082:jaxws-2.3.0.2 () 522} fakeroot debian/rules clean
dh clean --buildsystem=maven
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/export/local/debian-backports/stretch/jaxws/jaxws-2.3.0.2'
dh_auto_clean -- -f jaxws-ri/pom.xml
"for dir in \$(find . -name target -type d); do if [ -f \$(echo \$dir | 
sed -e s/target\$/pom.xml/) ]; then rm -Rf \$dir; fi done"
Can't exec "for dir in $(find . -name target -type d); do if [ -f $(echo $dir | 
sed -e s/target$/pom.xml/) ]; then rm -Rf $dir; fi done": No such file or 
directory at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 475.
dh_auto_clean: "for dir in \$(find . -name target -type d); do if [ -f \$(echo 
\$dir | sed -e s/target\$/pom.xml/) ]; then rm -Rf \$dir; fi done" failed to 
execute: No child processes
dh_auto_clean: "for dir in \$(find . -name target -type d); do if [ -f \$(echo 
\$dir | sed -e s/target\$/pom.xml/) ]; then rm -Rf \$dir; fi done" returned 
exit code 10
debian/rules:21: recipe for target 'override_dh_auto_clean' failed
make[1]: *** [override_dh_auto_clean] Error 2
make[1]: Leaving directory 
'/export/local/debian-backports/stretch/jaxws/jaxws-2.3.0.2'
debian/rules:4: recipe for target 'clean' failed
make: *** [clean] Error 2

{hdunkel@dpcl082:jaxws-2.3.0.2 () 523} dpkg -l debhelper
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  debhelper12.1.1~bpo9+1 all  
 helper programs for debian/rules

Obviously some build time dependency is not correct.


Regards
Harri

Bug#927732: unblock: variety/0.7.1-2 (pre-approval)

[James Lu]

Control: tags -1 moreinfo

Hi Niels,

I've uploaded the package and it should be in unstable now.

Best,
James

On 2019-04-21 10:45 p.m., Niels Thykier wrote:
> Control: tags -1 moreinfo confirmed
> 
> James Lu:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Dear Release Team,
>>
>> Please consider unblocking variety 0.7.1-2. I've backported a couple of
>> fixes from the newest upstream version, which fix a couple of subtle but
>> annoying bugs. The changelog is as follows:
>>
>> variety (0.7.1-2) unstable; urgency=medium
>>
>>   * Backport bugfixes from Variety 0.7.2:
>> - fix-crash-on-help-version.patch: Don't forward --help or --version to
>>   running Variety instances, as this causes it to crash.
>> - fix-spurious-error-when-analyzing-gifs.patch: Fix spurious
>>   FileNotFoundError when analyzing GIFs inside a wallpaper folder
>>
>>  -- James Lu   Sun, 21 Apr 2019 19:10:58 -0700
>>
>> The debdiff is attached.
>>
>> Best,
>> James
>>
> 
> Hi James,
> 
> Please go ahead with this upload and remove the moreinfo tag when it is
> in unstable and ready to be unblocked.
> 
> Thanks,
> ~Niels
> 

Bug#927414: Debian package with SB MS keys?

[Steve McIntyre]

On Mon, Apr 22, 2019 at 04:46:51PM +0200, adrian15 wrote:
>Hi,
>
>  Sledge asked me to bring here this discussion from the irc channel.
>
>  What about a Debian package that includes Secure Boot Microsoft keys?
>
>So that anyone having that package installed alongside mokutil can
>re-enroll Microsoft keys?
>
>  Maybe in qemu package to be able to simulate MS Secure Boot easier?
>Maybe in another package?
>
>Why?
>I might add an option to Rescapp to re-enroll default MS keys. Adding
>the keys manually might not be a problem but it's always better to rely
>on another package.
>
>Rescapp is part of rescatux. https://.supergrubdisk.org/rescatux/ .

Hi Adrian,

Dann is looking into this in #927414 - let'c sontinue the discussion
there maybe?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#732791: [l10n] codeblocks: Please include the translations in Debian

[Witold Baryluk]

Package: codeblocks
Version: 16.01+dfsg-2.1
Followup-For: Bug #732791


I do not feel it is acceptable to provide so old version of this software
in Debian probably. There are in fact some external libraries that makes
codeblocks 16.01 not usable in debian anymore, i.e. newer versions of
boost libraries, various newer C++ features not supported in editor well,
etc.

There is a third party repo, for codeblock with deb package for version 17.12

https://apt.jenslody.de/

and source packages are available too, so if there is something broken in 
current
version of package scripts, they can be easily taken from Jens' scripts.

codeblocks is not dead upstream, despite infrequent releases. There are
simply not many new features, but it fully functional and will see
developement in the future. In just last 7 days, I have seen about 20 SVN
commits in this project, and since start of the year 2019, there was
about 110 commits by 4 developers, both new features and bug fixes, which
is healthy amount.

It would be even interesting to have SVN repo be automatically build
every week and pushed to experimental.

I wish to have CodeBlocks working, as it is nice editor, and it is
especially useful for me when developing and debugging apps written in D
programming language, with GDC or LDC compilers (available in Debian).

Especially with Eclipse, and Eclipse CDT and Eclipse DDT, also not
available in Debian (and DDT being not supported upstream anymore), there
is not many good options for D or C++ programming in Debian using IDEs.

Thanks,
Witold

Bug#927767: e2fsck: Needs to clear *all* MMP flags in one pass

[Elliott Mitchell]

On Mon, Apr 22, 2019 at 09:42:01PM -0400, Theodore Ts'o wrote:
> On Mon, Apr 22, 2019 at 03:08:09PM -0700, Elliott Mitchell wrote:
> > Package: e2fsprogs
> > Version: 1.43.4-2
> > Severity: minor
> > 
> > If being run on a system which uses MMP and they weren't unmounted
> > cleanly, e2fsck will clear the MMP flags in order individually heavily
> > slowing the check process.
> > 
> > At a minimum when `e2fsck -a` is run, if it needs to clear one MMP flag
> > it should check for MMP flags on other filesystems and attempt to clear
> > them too.
> > 
> > Needing two MMP waits (one for `fsck /` and one for `fsck -a`) is
> > acceptable, 3+ is not.
> 
> What's the use case where you are using MMP on multiple file systems?
> In most of the configurations that I've seen, each server will have
> its own root file system, and the only thing which gets shared is a
> single data partition.
> 
> In a boot sequence, e2fsck gets called separate for each partition.  For 
> example:
> 
> % fsck -A -V -N
> fsck from util-linux 2.33.1
> Checking all file systems.
> [/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/mapper/lambda-root 
> [/sbin/fsck.vfat (1) -- /boot/efi] fsck.vfat /dev/nvme0n1p1 
> [/sbin/fsck.ext4 (1) -- /boot] fsck.ext4 /dev/nvme0n1p4

Ah, perhaps I'm hearkening to an earlier era where e2fsck was taking care
of parallel-izing operations itself and that is no longer the case.

> So e2fsck has no idea whether multiple file systems are being checked,
> or only one.  E2fsck is also not parsing /etc/fstab --- that's the job
> of the fsck driver program, or if you are using systemd, the systemd
> generator.
> 
> So at the risk of sounding like Steve Jobs --- if you are trying to
> use multiple MMP file systems, you're probably holding it wrong.  :-)
> 
> What is your use case; what are you trying to achieve, and how are
> your systems setup?   How are the disks connected to multiple servers?

Could well be I'm doing a really whacky setup.

This is several VMs on a hypervisor.  Most filesystems aren't shared, I'm
mostly using MMP for protection against my doing something stupid due to
typing a command with the wrong device.  The VMs have separate /, and
/var.  Their storage isn't being presented to them as a single disk, but
instead being divided into block devices for filesystems in the
privileged area.

The privileged area understands ext4 and I'm mostly worried about
mistakenly trying to mount a filesystem in the privileged area while a VM
is active on it.  There is no fallover, mostly protection against
fumble-fingers.  %-)


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#927773: wmnet FTCBFS: uses the build architecture compiler

[Nguyen Van. Hieu]

Source: wmnet
Version: 1.06-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

wmnet fails to cross build from source, because it uses the build
architecture compiler.
Using "dh_auto_build" instead of "make" can solve this problem.
Please consider applying the attached patch.

Hieu.

diff -Nru wmnet-1.06/debian/rules wmnet-1.06/debian/rules
--- wmnet-1.06/debian/rules 2012-03-04 03:13:23.0 +0700
+++ wmnet-1.06/debian/rules 2012-03-04 03:20:19.0 +0700
@@ -10,7 +10,7 @@
dh_testdir
 
xmkmf
-   make
+   dh_auto_build
 
touch build-stamp
 
-- 
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com

Bug#927414: how best to do this

[dann frazier]

This script is currently shipped in the edk2 source package in Ubuntu,
where it is used to pre-gen VARS images w/ Microsoft's keys pre-baked.
I plan to merge this delta into Debian soon after buster releases.
However, that will still not make it available to end users who may
want to generate images with their own keys pre-baked. Adding a new
deb to the distro isn't free, so I'd be interested in knowing if
there's a significant number of people who have that need and would
use this package to fulfill it.

Now, assuming we do have the users, what would be the best way to package it?

To make it apt-installable, I think we'd end up needing a new binary
package. Since presumably it could be useful for users of any of the
existing binary packages, we wouldn't want to just e.g. ship it in
ovmf. We could make edk2 build that new package, but I personally
don't like the idea of bundling out of tree source that is not tightly
coupled. If we take the hit and create a new deb, I'd lean towards
also keeping it in its own source package, and replace edk2's
(soon-to-be) bundled version w/ a build-dep on the new binary.

Bug#927756: Run provided tests at package built time

[eamanu]

Hello Yaroslav,

Thanks for the report.

I think that this issue is related to #927756. So, I will merge the bugs.
Please feel free to unmerge if you consider necessary.

Regards!

On 4/22/19 3:30 PM, Yaroslav Halchenko wrote:
> Package: python-github
> Version: 1.40-1
> Severity: wishlist
>
> It is typical for packages to run their tests batteries at the package build
> time.  This helps to guarantee their correct operation for the to be uploaded
> version on Debian systems.
>
> I have tried
>
>   http_proxy=http://127.0.0.1:9/ HOME=/tmp python -m github.tests -v
>
> on my laptop within virtualenv installing github module from within source
> package (since github.tests is not shipped ATM, separate issue).  And it seems
> to pass so it seems to not  require network access and doesn't rely on any 
> HOME
> configuration.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), 
> (100, 'unstable-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
> LANGUAGE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages python-github depends on:
> ii  python   2.7.16-1
> ii  python-jwt   1.7.0-2
> ii  python-requests  2.21.0-1
>
> python-github recommends no packages.
>
> python-github suggests no packages.
>
> -- no debconf information
>

-- 
@eamanu
@eamanu-guest
https://eamanu.com




signature.asc
Description: OpenPGP digital signature

Bug#927259: release.debian.org: unblock request: nheko

[Hubert Chathi]

Control: tags -1 - moreinfo

On Sat, 20 Apr 2019 18:20:00 +, Niels Thykier  said:

> Please go ahead with the upload including the two extra changes you
> mentioned above and remove the moreinfo tag when it is in unstable and
> ready to be unblocked.

Done.  Thank you for approving the changes.

> For future reference: We generally prefer seeing the debdiff before
> approving the changes.  Had the two extra changes not been obvious
> from your description, then it would have been necessary for me to ask
> you for the full debdiff.  Please make it easier for us by always
> including the changes you want us to consider (modulo filterdiff of
> auto-generated files).

Noted.  I wasn't sure about the process, but will do so in the future.
For reference, here is the complete debdiff.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

diff -Nru nheko-0.6.3/debian/changelog nheko-0.6.3/debian/changelog
--- nheko-0.6.3/debian/changelog	2019-02-08 15:35:59.0 -0500
+++ nheko-0.6.3/debian/changelog	2019-04-22 14:42:00.0 -0400
@@ -1,3 +1,11 @@
+nheko (0.6.3-2) unstable; urgency=medium
+
+  * Support v3 rooms (Closes: #926671)
+  * debian/rules: clean up fakehome (Closes: #926680)
+  * debian/README.source: fix filename (Closes: #926659)
+
+ -- Hubert Chathi   Mon, 22 Apr 2019 14:42:00 -0400
+
 nheko (0.6.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru nheko-0.6.3/debian/patches/series nheko-0.6.3/debian/patches/series
--- nheko-0.6.3/debian/patches/series	2019-02-08 15:35:01.0 -0500
+++ nheko-0.6.3/debian/patches/series	2019-04-08 17:57:30.0 -0400
@@ -1,2 +1,3 @@
 no_rpath
 nlohmann-json
+v3_support
diff -Nru nheko-0.6.3/debian/patches/v3_support nheko-0.6.3/debian/patches/v3_support
--- nheko-0.6.3/debian/patches/v3_support	1969-12-31 19:00:00.0 -0500
+++ nheko-0.6.3/debian/patches/v3_support	2019-04-08 17:56:34.0 -0400
@@ -0,0 +1,27 @@
+Author: redsky17 
+Bug: https://github.com/Nheko-Reborn/mtxclient/issues/3
+Bug-Debian: https://bugs.debian.org/926671
+Description: Fix Room v3 Issue
+ This at least partially addresses #3.  I have a feeling that
+ additional updates will be needed at some point, but this
+ fixes the issue where mtxclient would throw an exception for
+ unrecognized event id formats, which caused nheko to crash.
+Origin: backport, https://github.com/Nheko-Reborn/mtxclient/commit/67d39691666bcdf3cc660db19ccc0d9941df13fd
+Last-Update: 2019-04-08
+
+diff --git a/mtxclient/include/mtx/identifiers.hpp b/mtxclient/include/mtx/identifiers.hpp
+index 87acc43..7885885 100644
+--- a/mtxclient/include/mtx/identifiers.hpp
 b/mtxclient/include/mtx/identifiers.hpp
+@@ -90,7 +90,10 @@ parse(const std::string &id)
+ identifier.hostname_  = id.substr(parts + 1);
+ identifier.id_= id;
+ } else {
+-throw std::invalid_argument(id + ": invalid format\n");
++// V3 event ids don't use ':' at all, don't parse them the same way.
++identifier.localpart_ = id;
++identifier.hostname_ = id;
++identifier.id_ = id;
+ }
+ 
+ return identifier;
diff -Nru nheko-0.6.3/debian/README.source nheko-0.6.3/debian/README.source
--- nheko-0.6.3/debian/README.source	1969-12-31 19:00:00.0 -0500
+++ nheko-0.6.3/debian/README.source	2019-02-08 15:35:01.0 -0500
@@ -0,0 +1,13 @@
+nheko for Debian
+
+
+Since nheko is currently the only package that uses mtxclient, and nheko links
+to it statically, we include the sources for mtxclient with nheko's source.  If
+you have separate tarballs for nheko and mtxclient, the tarball for nheko
+should be named normally for an orig.tar.* file, and the tarball for
+matrix-structs should be named nheko_.orig-mtxclient.tar.*.  If
+you have an unpacked source (with the appropriate version of mtxclient placed
+in the mtxclient directory), then you can run "debian/rules make-orig-source"
+to create the tarballs for nheko and mtxclient.
+
+ -- Hubert Chathi , Wed, 26 Sep 2018 19:38:58 -0400
diff -Nru nheko-0.6.3/debian/README.sources nheko-0.6.3/debian/README.sources
--- nheko-0.6.3/debian/README.sources	2019-02-08 15:35:01.0 -0500
+++ nheko-0.6.3/debian/README.sources	1969-12-31 19:00:00.0 -0500
@@ -1,13 +0,0 @@
-nheko for Debian
-
-
-Since nheko is currently the only package that uses mtxclient, and nheko links
-to it statically, we include the sources for mtxclient with nheko's source.  If
-you have separate tarballs for nheko and mtxclient, the tarball for nheko
-should be named normally for an orig.tar.* file, and the tarball for
-matrix-structs should be named nheko_.orig-mtxclient.tar.*.  If
-you have an unpacked source (with the appropriate version of mtxclient placed
-in the mtxclient directory), then you can 

Bug#927484: CVE-2018-12179 CVE-2018-12182

[dann frazier]

On Sat, Apr 20, 2019 at 07:58:07PM +0200, Moritz Muehlenhoff wrote:
> Source: edk2
> Severity: important
> Tags: security

Thanks Moritz! Upon review, I believe Debian is not impacted by
either...

> CVE-2018-12179:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1133

The OpalPassword code isn't compiled for the Debian images. I
mechanically verified this by enabling atime and doing a build, and
generated lists of files touched by the build and not. Of the files
modified in the proposed patchset, these were not accessed:
  SecurityPkg/Include/Guid/OpalPasswordExtraInfoVariable.h
  SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c
  SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalPasswordDxe.inf
  SecurityPkg/Tcg/Opal/OpalPasswordSmm/OpalPasswordSmm.c
  SecurityPkg/Tcg/Opal/OpalPasswordSmm/OpalPasswordSmm.h
  SecurityPkg/Tcg/Opal/OpalPasswordSmm/OpalPasswordSmm.inf

This one was:
  SecurityPkg/SecurityPkg.dec
but the only proposed change to it is to remove a Guid definition.

> CVE-2018-12182:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1136

Upstream explains why OVMF is not impacted here:
  https://bugzilla.tianocore.org/show_bug.cgi?id=1136#c13

  -dann

Bug#927767: e2fsck: Needs to clear *all* MMP flags in one pass

[Theodore Ts'o]

On Mon, Apr 22, 2019 at 03:08:09PM -0700, Elliott Mitchell wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
> Severity: minor
> 
> If being run on a system which uses MMP and they weren't unmounted
> cleanly, e2fsck will clear the MMP flags in order individually heavily
> slowing the check process.
> 
> At a minimum when `e2fsck -a` is run, if it needs to clear one MMP flag
> it should check for MMP flags on other filesystems and attempt to clear
> them too.
> 
> Needing two MMP waits (one for `fsck /` and one for `fsck -a`) is
> acceptable, 3+ is not.

What's the use case where you are using MMP on multiple file systems?
In most of the configurations that I've seen, each server will have
its own root file system, and the only thing which gets shared is a
single data partition.

In a boot sequence, e2fsck gets called separate for each partition.  For 
example:

% fsck -A -V -N
fsck from util-linux 2.33.1
Checking all file systems.
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/mapper/lambda-root 
[/sbin/fsck.vfat (1) -- /boot/efi] fsck.vfat /dev/nvme0n1p1 
[/sbin/fsck.ext4 (1) -- /boot] fsck.ext4 /dev/nvme0n1p4

So e2fsck has no idea whether multiple file systems are being checked,
or only one.  E2fsck is also not parsing /etc/fstab --- that's the job
of the fsck driver program, or if you are using systemd, the systemd
generator.

So at the risk of sounding like Steve Jobs --- if you are trying to
use multiple MMP file systems, you're probably holding it wrong.  :-)

What is your use case; what are you trying to achieve, and how are
your systems setup?   How are the disks connected to multiple servers?


For that matter, there could easily be configurations where just
because one MMP file system is no longer accessible to its primary
system, another MMP file system might still be accessible to its
primary system.  (For example, one could imagine 3 systems, where each
system back up the other two, and so system #3 might be the backup for
systems #1 and #2.  Just because one MMP file system --- say the one
for #1 --- has failed over, doesn't mean that the other MMP file
system --- which might be hooked up to system #2 --- should have its
MMP flag cleared.)

- Ted

Bug#927772: liferea: random crash (SIGSEGV)

[Paul Wise]

Package: liferea
Version: 1.12.6-1
Severity: normal
Usertags: crash

Today I had a random crash (SIGSEGV) in liferea. If the information
below is not useful, please close this bug.

$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core 
/var/crash/1000/25152-1000-1000-11-1555932477-chianamo--usr-bin-liferea.core 
/usr/bin/liferea
[New LWP 25152]
[New LWP 25165]
[New LWP 25189]
[New LWP 25190]
[New LWP 26708]
[New LWP 25157]
[New LWP 25166]
[New LWP 25155]
[New LWP 25154]
[New LWP 25167]
[New LWP 25168]
[New LWP 25169]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `liferea'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:32
32  ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or 
directory.
[Current thread is 1 (Thread 0x7ff00f78aac0 (LWP 25152))]
#0  0x7ff016668c7e in __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:32
#1  0x5561423a60ca in comments_process_update_result 
(result=0x55614605f3c0, user_data=0x55614419a300, flags=) at 
comments.c:110
#2  0x5561423bd26a in update_process_result_idle_cb 
(user_data=0x556145f643b0) at update.c:591
#3  0x7ff01698add8 in g_main_dispatch (context=0x5561434ae2a0) at 
../../../glib/gmain.c:3182
#4  0x7ff01698add8 in g_main_context_dispatch 
(context=context@entry=0x5561434ae2a0) at ../../../glib/gmain.c:3847
#5  0x7ff01698b1c8 in g_main_context_iterate 
(context=context@entry=0x5561434ae2a0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:3920
#6  0x7ff01698b25c in g_main_context_iteration 
(context=context@entry=0x5561434ae2a0, may_block=may_block@entry=1) at 
../../../glib/gmain.c:3981
#7  0x7ff016bb699d in g_application_run (application=0x5561434ac0e0 
[LifereaApplication], argc=, argv=0x7fffc1853c08) at 
../../../gio/gapplication.c:2470
#8  0x5561423a5367 in main (argc=1, argv=0x7fffc1853c08) at main.c:77

Thread 12 (Thread 0x7feffe5fc700 (LWP 25169)):
#0  0x7ff0166c6b69 in __GI___poll (fds=0x7fefa0003f00, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
resultvar = 18446744073709551100
sc_cancel_oldtype = 0
#1  0x7ff01698b136 in g_main_context_poll (priority=, 
n_fds=1, fds=0x7fefa0003f00, timeout=, context=0x7fefab20) 
at ../../../glib/gmain.c:4221
ret = 
errsv = 
poll_func = 0x7ff01699a800 
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 1
allocated_nfds = 1
fds = 0x7fefa0003f00
#2  0x7ff01698b136 in g_main_context_iterate (context=0x7fefab20, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:3915
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 1
allocated_nfds = 1
fds = 0x7fefa0003f00
#3  0x7ff01698b4c2 in g_main_loop_run (loop=0x7fefa0002d80) at 
../../../glib/gmain.c:4116
__FUNCTION__ = "g_main_loop_run"
#4  0x7ff013ffdce0 in WTF::RunLoop::run() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:96
runLoop = @0x7ff00c3d2000: { = 
{> = { = {m_refCount = 
{> = {static _S_alignment = 4, _M_i = 1}, }}, }, _vptr.FunctionDispatcher = 0x7ff0142ae640 
}, m_functionQueueLock = {static isHeldBit = 1 
'\001', static hasParkedBit = 2 '\002', m_byte = {value = 
{> = {static _S_alignment = 1, _M_i = 0 
'\000'}, }}}, m_functionQueue = {m_start = 0, m_end = 0, 
m_buffer = { >> = {m_buffer = 0x0, 
m_capacity = 0, m_size = 0}, }}, m_mainContext = {m_ptr = 
0x7fefab20}, m_mainLoops = {, 
0>> = { >> = {m_buffer = 
0x7ff00c3d, m_capacity = 16, m_size = 1}, }, }, m_source = {m_ptr = 0x7fefa0002da0}}
mainContext = 0x7fefab20
innermostLoop = 0x7fefa0002d80
nestedMainLoop = 
#5  0x7ff013fb386b in WTF::Function::operator()() const 
(this=) at ../Source/WTF/wtf/Function.h:54
function = {m_callableWrapper = 
std::unique_ptr::CallableWrapperBase> = {get() = 
0x7ff00c3f41f8}}
#6  0x7ff013fb386b in 
WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) 
(newThreadContext=0x7ff00c3f8410) at ../Source/WTF/wtf/Threading.cpp:136
function = {m_callableWrapper = 
std::unique_ptr::CallableWrapperBase> = {get() = 
0x7ff00c3f41f8}}
#7  0x7ff013ffe139 in WTF::wtfThreadEntryPoint(void*) (context=) at ../Source/WTF/wtf/posix/ThreadingPOSIX.cpp:200
#8  0x7ff0167a0fa3 in start_thread (arg=) at 
pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140668741601024, 
-770875793426231364, 140736440117230, 140736440117231, 140668741601024, 
140668974297088, 761865022784786364, 769377183225597884}, mask_was_saved = 0}}, 
priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,

Bug#927764: evince crashes in poppler on unusual pdf document

[Daniel Kahn Gillmor]

Control: forcemerge 924029 927764

On Mon 2019-04-22 23:18:10 +0200, Bernhard Übelacker wrote:
> the backtrace looks similar to that from this bug:
>
> https://bugs.debian.org/924029

Thanks, that does look right.  I've tested it and i can confirm that it
solves the problem for me.

I've submitted a merge request in salsa with the patchset that i used:

https://salsa.debian.org/freedesktop-team/poppler/merge_requests/3

Thanks for your prompt pointer!

   --dkg


signature.asc
Description: PGP signature

Bug#927728: gnome-maps: search functionality (main or directions) causes a crash (SIGSEGV)

[Paul Wise]

Control: reassign -1 libgeocode-glib0 3.26.0-2
Control: severity 925539 serious
Control: forcemerge 925539 -1
Control: affects 925539 + gnome-maps

On Mon, 2019-04-22 at 15:07 +0200, Bernhard Übelacker wrote:

> might this be related to #925539 ?

Looks like it is indeed.

> Can you still reproduce it when you install
> libgeocode-glib0 3.26.1-1 from unstable?

No, that fixes the issue :D

Could you please get the fixed version into Debian buster?

https://release.debian.org/buster/freeze_policy.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

control: severity -1 normal

Hi.  I ran a number of other upgrades today of libvirtd from stretch to
buster and was not able to reproduce the problem in the environments I
thought would cause it.
I don't know what's up, but I don't think characterizing this as RC
given the data we have is correct.

Bug#927771: rsyslog: Update URL in logcheck files for x-info

[Craig Small]

Package: rsyslog
Version: 8.1901.0-1
Severity: minor
Tags: patch

The logcheck files use the http:// url but rsyslog now outputs its
messages using https://

Also for some reason there are two spaces in the HUPed message. I'm not
sure if the others have the same problem either.


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/6 CPU cores)
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 rsyslog depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-8
ii  libestr0 0.1.10-2.1
ii  libfastjson4 0.99.8-2
ii  liblognorm5  2.0.5-1
ii  libsystemd0  241-3
ii  libuuid1 2.33.1-0.1
ii  lsb-base 10.2019031300
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages rsyslog recommends:
ii  logrotate  3.14.0-4

Versions of packages rsyslog suggests:
pn  rsyslog-doc
ii  rsyslog-gnutls 8.1901.0-1
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- Configuration Files:
/etc/logcheck/ignore.d.server/rsyslog [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/rsyslog'
/etc/rsyslog.conf changed [not included]

-- no debconf information
3,5c3,5
< ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd" 
swVersion="[0-9.]+" x-pid="[0-9]+" x-info="http://www.rsyslog.com"\] start$
< ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd" 
swVersion="[0-9.]+" x-pid="[0-9]+" x-info="http://www.rsyslog.com"\] exiting on 
signal [0-9]+.$
< ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd" 
swVersion="[0-9.]+" x-pid="[0-9]+" x-info="http://www.rsyslog.com"\] rsyslogd 
was HUPed$
---
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd" 
> swVersion="[0-9.]+" x-pid="[0-9]+" x-info="https://www.rsyslog.com"\] start$
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd" 
> swVersion="[0-9.]+" x-pid="[0-9]+" x-info="https://www.rsyslog.com"\] exiting 
> on signal [0-9]+.$
> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: +\[origin software="rsyslogd" 
> swVersion="[0-9.]+" x-pid="[0-9]+" x-info="https://www.rsyslog.com"\] 
> rsyslogd was HUPed$

Bug#920118: sponge: preverses permissions but not ownership

[Hamish Moffatt]

On 19/4/19 6:42 am, Nicolas Schier wrote:

Control: severity -1 wishlist
Control: tag -1 wontfix

On Tue, Jan 22, 2019 at 09:40:20AM +1100, Hamish Moffatt wrote:

[...]
sponge preserves file permissions (as mentioned in the man page), but
not the file ownership.

This is different from shell redirections in bash, which do preserve
ownership.

yes, you're right.  As 'sponge' is not a shell redirect, and it is not
designed to emulate one, it behaves more like 'tee' than like a shell
redirection.  I do understand that preserving the owner might be a nice
feature, but I think this could work well only if 'sponge' is called
with superuser capabilities (or if installed with suid-bit set).

Why do you think that sponge ought to preserve the owner?  Did the man
page induce that somehow?



I only expect it to preserve the ownership when you run it as root, on a 
file which doesn't belong to root.


tee preserves the file ownership in this case, just as shell 
redirections do. sponge does not.



With tee:

# id
uid=0(root) gid=0(root) groups=0(root)


# ls -l foo
-rw-r--r-- 1 hamish hamish 257 Apr 23 09:52 foo
# echo hi | tee foo
hi
# ls -l foo
-rw-r--r-- 1 hamish hamish 3 Apr 23 09:53 foo


But with sponge:

# echo hi | sponge foo
# ls -l foo
-rw-r--r-- 1 root root 3 Apr 23 09:53 foo


tee is doing this automatically because it truncates the original file. 
sponge is copying the permissions from the original to the new file 
before replacing the original. It could also copy the owner, if running 
as root.



Hamish

Bug#924591: this requires linking in libsparse, which is from Android sources

[Theodore Ts'o]

On Mon, Apr 22, 2019 at 10:19:46PM +0200, Hans-Christoph Steiner wrote:
> 
> I don't really know how fastboot in stretch provided the mke2fs support,
> but judging by the dependencies, it might have been that fastboot used
> to do the formatting itself, based on being linked to
> android-libext4-utils and android-libsparse.  The buster version of
> fastboot is clearly calling mk2efs, which in AOSP is built from an
> inline e2fsprogs fork.

Yes, that's correct.

>From running strings on the fastboot binary from Stretch, it's using
the statically linked-in make_ext4fs code.  The make_ext4fs was code
written years and years ago, back when Android senior management
(rumor has it was that it was Andy Rubin himself) didn't want to use
any GPL'ed code in userspace.  Fortunately, that's no longer the case.

The old make_ext4fs code was old, creaky, and didn't exactly work the
same way as mke2fs (since it was written as a clean-room
reimplementation from scratch).  As a result I was very happy when we
were finally able to take the make_ext4fs code and KILL IT WITH
FIRE[1].  :-)

[1] https://www.youtube.com/watch?v=Tnod9vtB4xA

Unfortunately, the focus was to make the make_ext4fs replacement work
with AOSP only.  I wasn't aware of Debian's native Android tools; but
even if I did, it's not clear that we could have gotten things working
within the scope of the intern project to drop make_ext4fs support and
port the necessary support code into e2fsprogs.

This change started landing in AOSP in November 2016 (it was a Fall
2016 intern project).  I'd have to check to be sure, but looking at
the Debian changelog, the AOSP release with the actual KILL IT WITH
FIRE commit probably landed in Debian sometime in late 2017.  Alas,
apparently no one had noticed the problem for well over a year.  So
I'm guessing Debian's fastboot, or at least its format command, is
rarely used by Debian users.  :-/

- Ted

Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi

[Jamie Zawinski]

Xscreensaver 5.42 tries really hard to do something sensible with whatever set 
of garbage fonts you happen to have installed, so it would be helpful if you 
send me the output of xlsfonts on your system where it's doing something 
terrible.

If you're feeling adventurous, rebuilding with DEBUG defined in 
utils/font-retry.c and sending me the output of a run with that version would 
also be helpful.

Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi

[Matthew Gabeler-Lee]

Package: xscreensaver
Version: 5.42+dfsg1-1
Followup-For: Bug #699392

It's now actually worse.  The core xscreensaver package does not work
without xfonts-(100|75)dpi installed, because the font it uses to render the
unlock widget is unavailable without one of those packages installed.

The result then, is that you get the unlock widget, and it works ...  if you
know what it is supposed to look like.  The only text on it that renders is
the username and password asterisks.  Everything else is a sea of blankness.

As to Tormod's question of 6+ years ago, this can happen if you have a
headless box using a vnc server to provide X sessions.

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

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

Bug#927562: Updating the elilo-installer Uploaders list

[Steve McIntyre]

On Sat, Apr 20, 2019 at 09:03:05PM +0200, John Paul Adrian Glaubitz wrote:
>
>> On Apr 20, 2019, at 8:44 PM, Tobias Frost  wrote:
>> 
>> Source: elilo-installer
>> Version: 1.34
>> Severity: minor
>> User: m...@qa.debian.org
>> Usertags: mia-teammaint
>> 
>> We are tracking their status in the MIA team and would like to ask you
>> to remove them from the Uploaders list of the package so we can close
>> that part of the file.
>
>elilo-installer can actually be removed as elilo is no longer part of
>the archive (although I actually created an updated 3.16 package
>which I could upload).
>
>GRUB actually works fine on ia64 and I’m going to switch it over by
>patching grub-installer and partman-auto once Buster has been
>released (I avoid pushing any Ports-related changes during freeze).
>
>I’ll file a removal request later. There are also remnants of elilo
>references in debian-installer and debian-cd.

Nod, it's definitely time that elilo went away.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#927770: lios does not work properly on KDE

[gcab_dzan]

Package: lios
Version: 2.7-2
Severity: important

Dear Maintainer,

  I installed Lios on Buster with KDE.

Launching it graphically, it pops an advise that cannot find the hunspell/ etc. 
language pack which is instead installed.

Launching it from terminal I get the warning reported in the attached. 

The lios window opens, I can load an image (as filter ?) and the thumb shows on 
the left column, but no way to get it to appear on the central pane and choose 
the part to recognize.

But I can OCR (in english, at least) the whole image. 

That's much of a pity since lios looks to be the only GUI front-end to 
tesseract working on KDE.

Thus I hope the problem can be solved quickly, and thanks indeed for your 
attention and commitment.

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

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

Versions of packages lios depends on:
ii  aspell-en2018.04.16-0-1
ii  espeak   1.48.04+dfsg-7
ii  gir1.2-gst-plugins-base-1.0  1.14.4-1
ii  gir1.2-gstreamer-1.0 1.14.4-1
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-vte-2.91  0.54.2-2
ii  imagemagick  8:6.9.10.23+dfsg-2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2
ii  poppler-utils0.71.0-3
ii  python3  3.7.2-1
ii  python3-enchant  2.0.0-1
ii  python3-gi   3.30.4-1
ii  python3-sane 2.8.3-1+b2
ii  python3-speechd  0.9.0-5
ii  tesseract-ocr4.0.0-2

lios recommends no packages.

Versions of packages lios suggests:
pn  cuneiform  

-- no debconf information
giuliano@a64-tst:~$ lios
/usr/lib/python3/dist-packages/lios/ui/gtk/text_view.py:21: PyGIWarning: Gtk 
was imported without specifying a version first. Use gi.require_version('Gtk', 
'3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk
/usr/lib/python3/dist-packages/lios/ui/gtk/print_dialog.py:23: PyGIWarning: 
PangoCairo was imported without specifying a version first. Use 
gi.require_version('PangoCairo', '1.0') before import to ensure that the right 
version gets loaded.
  from gi.repository import PangoCairo
/usr/lib/python3/dist-packages/lios/cam.py:19: PyGIWarning: GstVideo was 
imported without specifying a version first. Use gi.require_version('GstVideo', 
'1.0') before import to ensure that the right version gets loaded.
  from gi.repository import GdkX11, GstVideo
/usr/lib/python3/dist-packages/lios/ui/gtk/terminal.py:21: PyGIWarning: Vte was 
imported without specifying a version first. Use gi.require_version('Vte', 
'2.91') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, GObject, Vte

(lios:2874): Gtk-WARNING **: 00:01:59.778: Theme parsing error: gtk.css:127:35: 
The style property GtkButton:child-displacement-x is deprecated and shouldn't 
be used anymore. It will be removed in a future version

(lios:2874): Gtk-WARNING **: 00:01:59.778: Theme parsing error: gtk.css:128:35: 
The style property GtkButton:child-displacement-y is deprecated and shouldn't 
be used anymore. It will be removed in a future version

(lios:2874): Gtk-WARNING **: 00:01:59.778: Theme parsing error: gtk.css:129:34: 
The style property GtkCheckButton:indicator-size is deprecated and shouldn't be 
used anymore. It will be removed in a future version

(lios:2874): Gtk-WARNING **: 00:01:59.778: Theme parsing error: gtk.css:132:46: 
The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lios:2874): Gtk-WARNING **: 00:01:59.798: Cannot connect attribute 'text' for 
cell renderer class 'lios+ui+gtk+tree_view+CellRendererToggle' since attribute 
does not exist
update_scanner_list Started
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct conver

Bug#927753: gnome-maps: segmentation fault at startup

[gpe]

Le mardi 23 avril 2019 à 00:44 +0200, Bernhard Übelacker a écrit :
> Hello gpe,
> this stack trace looks really like that one
> submitted in https://bugs.debian.org/927728 .
> 
> Possibly you can install just libgeocode-glib0 3.26.1-1
> from unstable?
> 
> From my findings in https://bugs.debian.org/927728
> I would expect that this crash should then be gone.
> 
> Kind regards,
> Bernhard
> 


I confirm. Installing libgeocode-glib0 3.26.1-1 resolves the issue.

BR

Bug#927265: dpkg-dev: dpkg-buildpackage -F does not generate a source.changes files

[Guillem Jover]

Control: severity -1 minor

Hi!

On Wed, 2019-04-17 at 12:03:34 +0800, Drew Parsons wrote:
> Package: dpkg-dev
> Version: 1.19.6
> Severity: normal

> dpkg-buildpackage -F is supposed to be equivalent to
> dpkg-buildpackage --build=source,binary
> 
> The dpkg-buildpackage manpage tells us that if --build=source is used,
> then a source.changes file will be generated.
> 
> But dpkg-buildpackage -F does not generate source.changes, it only
> generates the binary changes file.

It also says that:

  Specifies the build type from a comma-separated list of components

> The expected behaviour is that it will generate both, just as pdebuild
> does.
> 
> The same applies to dpkg-buildpackage -g and -G (--build=source,all
> and --build=source,any)

I have to confess I find this notion to be a bit strange. :) More so
given alias mappings given. I guess I should emphasize that the
arguments to --build (or their equivalent aliases) get combined to
form a single build type? Or what do you think would have made this
more clear?

Thanks,
Guillem

Bug#927752: Mention --clear-selections actually also grows selections

[Guillem Jover]

Control: severity -1 minor
Control: retitle -1 dpkg: --clear-selections marks unknown packages for 
deinstall

Hi!

On Tue, 2019-04-23 at 01:55:17 +0800, 積丹尼 Dan Jacobson wrote:
> Package: dpkg
> Version: 1.19.6
> Severity: wishlist
> File: /usr/share/man/man1/dpkg.1.gz

> Man page says
> 
>   --clear-selections
> 
>   Set the requested state of every non-essential package to 
> deinstall
>   (since dpkg 1.13.18). This is intended to be used
>   immediately before --set-selections, to deinstall any
>   packages not in list given to --set-selections.
> 
> OK but isn't there little point in dragging in uninstalled packages into
> the status file?

Right, this looks like a bug, I've fixed it now locally, targetting
1.20.x. It's very much inconsequential though, as all those selections
should disappear on the next operation, as they are requesting to
deinstall not-installed packages.

> (P.S., better be ready to restore via status.old after trying this,
> else e.g.,
> # aptitude full-upgrade
> E: Cannot remove aptitude within aptitude
> E: Problem parsing '/var/lib/aptitude//pkgstates', is it corrupt or 
> malformed? You can try to recover from '/var/lib/aptitude//pkgstates.old'.)

Well, sure, I'd have thought the description is pretty clear about
this, as it says explicitly that it will mark everything for removal,
and to be used before a --set-selections which might also be partial.

Thanks,
Guillem

Bug#927753: gnome-maps: segmentation fault at startup

[Bernhard Übelacker]

Hello gpe,
this stack trace looks really like that one
submitted in https://bugs.debian.org/927728 .

Possibly you can install just libgeocode-glib0 3.26.1-1
from unstable?

>From my findings in https://bugs.debian.org/927728
I would expect that this crash should then be gone.

Kind regards,
Bernhard

Bug#927769: ITP: ruby-jekyll-last-modified-at -- indicate the last time a file was modified

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-jekyll-last-modified-at
  Version : 1.1.0
  Upstream Author : Garen J. Torikian
* URL : https://github.com/gjtorikian/jekyll-last-modified-at
* License : MIT
  Programming Lang: Ruby
  Description : indicate the last time a file was modified

This Jekyll plugin adds a liquid tag to indicate the last time a file was
modified. The tag can be called and processed to pass along your own
time format.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAly+QO0ACgkQS80FZ8KW
0F0XlQ/+NSdYssqOVco4As0/svGc4nHAFhi0gXSrfI3EEH7qmPnG3U1COPYZj9eX
nj0lsIgkSt7bHXiUWA4qVa83pNADLEZO9MkQasYji8XGz4V7r+LFq7VY+dEMpAOI
JItlSy7gxS+vgXEgYu2w78qGhCfrRW5JL8B3Q/5eJ89BdfRBulkrX4zrIEI/xMjW
t4H69T/A5cW8RqkDsPWb8yzwxXK96ryfksXatB5SayweNX3kNgMIADwEtMhJgGqp
xTY2T1ei0eNR7CtzR7VuLxRlgYf98yc4LdFeiicFbhfvdjyYRqEkaqSUK4i86LDU
BUcmrst/i3meKlKpJ8mu6GHlAJhucaNB3oMTFFplk8Nk8qTN8a4c/av31zBs3lcP
NFFm5anrsWCpJh8mS0zuBgfKERWwtVwrunlNOgJ3yupguArj1TMtw5NgNw6JA3nU
2N9MQelPzWngZbRTQoiM0jNmLszF+IyycSoKzwBgG7frAUs9bkOneHM3zkAE2XCR
MWlDWd7dyYKOVyjW8NrmBS48sfLcHfb7UiNZW8bE0cityjBNtSkdOPT15dQv9Y9g
kaMGIo6s2v8neI62Mxkn3ZfRtz4pEZVv/C3ZDurIpfCsAkpimy5OU+5VHdnXAR4r
yWSkek5keWF5lRn/WMdbOsDroVB88Lwqd9vHXsuI0jwdWdd8cDc=
=kG89
-END PGP SIGNATURE-

Bug#927753: gnome-maps: segmentation fault at startup

[gpe]

Le mardi 23 avril 2019 à 00:20 +0200, Bernhard Übelacker a écrit :
> Hello gpe92,
> maybe you could add some more information for the maintainer
> by following steps, if possible:
> - install the package "systemd-coredump"
> - try to start gnome-maps again
> - forward the output of following command to this bug:
> journalctl | sed -n '/dumped core/,/systemd-coredump@/p'
> 
> I guess this issue could be the same as in bugs 925539 or 927728.
> 
> Kind regards,
> Bernhard

Here is the result in the attached file.

BR.

journalctl | sed -n '/dumped core/,/systemd-coredump@/p'
avril 23 00:25:08 reveillon systemd-coredump[5265]: Process 4680 (gnome-maps) 
of user 1000 dumped core.

Stack trace of thread 4680:
#0  0x7fbfc2a1bdc6 
__GI_strtol_l_internal (libc.so.6)
#1  0x7fbfaec9bd7e n/a 
(libgeocode-glib.so.0)
#2  0x7fbfaec9d900 
_geocode_parse_search_json (libgeocode-glib.so.0)
#3  0x7fbfaec9da89 n/a 
(libgeocode-glib.so.0)
#4  0x7fbfc3026719 n/a 
(libgio-2.0.so.0)
#5  0x7fbfc3027196 n/a 
(libgio-2.0.so.0)
#6  0x7fbfaec9c683 n/a 
(libgeocode-glib.so.0)
#7  0x7fbfc3026719 n/a 
(libgio-2.0.so.0)
#8  0x7fbfc3027196 n/a 
(libgio-2.0.so.0)
#9  0x7fbfc2fde582 n/a 
(libgio-2.0.so.0)
#10 0x7fbfc2ffa94d n/a 
(libgio-2.0.so.0)
#11 0x7fbfc3026719 n/a 
(libgio-2.0.so.0)
#12 0x7fbfc3026759 n/a 
(libgio-2.0.so.0)
#13 0x7fbfc2e5edd8 
g_main_context_dispatch (libglib-2.0.so.0)
#14 0x7fbfc2e5f1c8 n/a 
(libglib-2.0.so.0)
#15 0x7fbfc2e5f25c 
g_main_context_iteration (libglib-2.0.so.0)
#16 0x7fbfc305199d 
g_application_run (libgio-2.0.so.0)
#17 0x7fbfc24ed8ee 
ffi_call_unix64 (libffi.so.6)
#18 0x7fbfc24ed2bf 
ffi_call (libffi.so.6)
#19 0x7fbfc2d63819 n/a 
(libgjs.so.0)
#20 0x7fbfc2d64f96 n/a 
(libgjs.so.0)
#21 0x7fbfc1143474 n/a 
(libmozjs-60.so.0)
#22 0x7fbfc11366e1 n/a 
(libmozjs-60.so.0)
#23 0x7fbfc1142cf6 n/a 
(libmozjs-60.so.0)
#24 0x7fbfc1144947 n/a 
(libmozjs-60.so.0)
#25 0x7fbfc1144a6c n/a 
(libmozjs-60.so.0)
#26 0x7fbfc1457d6e n/a 
(libmozjs-60.so.0)
#27 0x7fbfc1457e7b n/a 
(libmozjs-60.so.0)
#28 0x7fbfc2d8c36a 
gjs_eval_with_scope (libgjs.so.0)
#29 0x7fbfc2d825c2 
gjs_context_eval (libgjs.so.0)
#30 0x55df5ed719cb main 
(gjs-console)
#31 0x7fbfc2a0409b 
__libc_start_main (libc.so.6)
#32 0x55df5ed71cca 
_start (gjs-console)

Stack trace of thread 4685:
#0  0x7fbfc24ff00c 
futex_wait_cancelable (libpthread.so.0)
#1  0x7fbfc17a7aff 
_ZN7mozilla6detail21ConditionVariableImpl4waitERNS0_9MutexImplE 
(libmozjs-60.so.0)
#2  0x7fbfc17a7cd5 
_ZN7mozilla6detail21ConditionVariableImpl8wait_forERNS0_9MutexImplERKNS_16BaseTimeDurationINS_27TimeDurationValueCalculatorEEE
 (libmozjs-60.so.0)
#3  0x7fbfc1524644 n/a 
(libmozjs-60.so.0)
#4  0x

Bug#927428: arbtt-recover leaks memory

[Joey Hess]

Memory use is still ~2.4 gb (profile below).


Mon Apr 22 17:57 2019 Time and Allocation Profiling Report  (Final)

   arbtt-recover +RTS -p -RTS -i capture.log -o capture.log.recovered

total time  =  292.96 secs   (292957 ticks @ 1000 us, 1 processor)
total alloc = 99,752,360,032 bytes  (excludes profiling overheads)

COST CENTRE  MODULESRC  
%time %alloc

appendTimeLogTimeLog   src/TimeLog.hs:(59,1)-(60,42)
 51.3   32.4
ls_put   Data.Binary.StringRef 
src/Data/Binary/StringRef.hs:(68,9)-(71,49)6.95.4
get  Data  src/Data.hs:(100,2)-(103,96) 
  6.2   11.3
==   Data.MyText   src/Data/MyText.hs:17:66-67  
  4.20.0
ls_put   Data.Binary.StringRef 
src/Data/Binary/StringRef.hs:51:5-68   2.74.2
ls_put   Data.Binary.StringRef 
src/Data/Binary/StringRef.hs:38:5-81   2.76.3
put  Data  src/Data.hs:(97,2)-(99,26)   
  2.71.8
ls_get   Data.Binary.StringRef 
src/Data/Binary/StringRef.hs:(72,9)-(76,62)2.22.6
diffTimeFromRational Data  src/Data.hs:103:82-95
  1.90.5
get  Data.MyText   src/Data/MyText.hs:31:5-22   
  1.65.1
listOfStringsData  src/Data.hs:106:3-58 
  1.54.9
ls_get   Data.Binary.StringRef 
src/Data/Binary/StringRef.hs:39:5-87   1.42.1
ls_get   Data  src/Data.hs:(90,2)-(94,71)   
  1.10.8
encodeChar   Codec.Binary.UTF8.String  
Codec/Binary/UTF8/String.hs:(50,1)-(67,25) 1.02.7
ls_get   Data  src/Data.hs:(118,2)-(124,70) 
  0.91.5
encode   Codec.Binary.UTF8.String  
Codec/Binary/UTF8/String.hs:72:1-290.92.3
foldrData.ByteString.UTF8  
Data/ByteString/UTF8.hs:(171,1)-(173,40)   0.82.7
unconsB  Codec.Binary.UTF8.Generic 
Codec/Binary/UTF8/Generic.hs:297:1-18  0.73.5
decode   Data.ByteString.UTF8  
Data/ByteString/UTF8.hs:(68,1)-(124,32)0.61.2
decode.chooseData.ByteString.UTF8  
Data/ByteString/UTF8.hs:(72,3)-(78,39) 0.41.7
encodeChar.goCodec.Binary.UTF8.String  
Codec/Binary/UTF8/String.hs:(52,3)-(67,25) 0.11.0



 individual 
 inherited
COST CENTREMODULE   
   SRCno. entries  %time %alloc 
  %time %alloc

MAIN   MAIN 
408  00.00.0  
 100.0  100.0
 CAF   
System.Directory.Internal.Posix 
606  00.00.0 0.00.0
 CAF   System.FilePath.Posix
   580  00.00.0  
   0.00.0
 CAF   Data.Binary.Get  
   578  00.00.0  
   0.00.0
 CAF   Data.Binary.Class
   576  00.00.0  
   0.00.0
 CAF   Data.ByteString.Internal 
   565  00.00.0  
   0.00.0
 CAF   GHC.Conc.Signal  
   522  00.00.0  
   0.00.0
 CAF   GHC.Exception
   518  00.00.0  
   0.00.0
 CAF   GHC.IO.Encoding  
   504  00.00.0  
   0.00.0
 CAF   GHC.IO.Encoding.Iconv
   502  00.00.0  
   0.00.0
 CAF   GHC.IO.Handle.FD 
   494  00.00.0  
   0.00.0
 CAF   GHC.IO.Handle.Text   
   492  00.00.0  
   0.00.0
 CAF  

Bug#918130: Mail::SpamAssassin::Plugin::ASN reports wrong ASN for IPv6

[Bernhard Schmidt]

Control: tags -1 + patch

> There is a bug/patch proposed in upstream bz,
> 
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7211
> 
> I've prodded them to commit it to trunk so it could be cherry-picked for 
> Buster.

The patch has been included upstream. I've created a merge request on
Salsa for this. Getting this into Buster would be _highly_ appreciated.

https://salsa.debian.org/debian/spamassassin/merge_requests/1

Bernhard

Bug#927753: gnome-maps: segmentation fault at startup

[Bernhard Übelacker]

Hello gpe92,
maybe you could add some more information for the maintainer
by following steps, if possible:
- install the package "systemd-coredump"
- try to start gnome-maps again
- forward the output of following command to this bug:
journalctl | sed -n '/dumped core/,/systemd-coredump@/p'

I guess this issue could be the same as in bugs 925539 or 927728.

Kind regards,
Bernhard

Bug#927768: bash: 'read -e -u FD' reads from stdin if FD is a terminal

[Marriott NZ]

Package: bash
Version: 4.4-5
Severity: normal

Dear Maintainer,

If the read builtin
- is called with both -e and -u FD, and
- FD is a terminal
then it doesn't read from the specified file descriptor FD as documented, but 
it reads from the standard input instead.

For example:

## unexpected ('pipe' comes from echo)
$ exec 9

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#927378: stretch-pu: package node-superagent/0.20.0+dfsg-1+deb9u1

[Xavier]

Le 22/04/2019 à 20:15, Paul Gevers a écrit :
> Hi Xavier,
> 
> On Thu, 18 Apr 2019 20:44:01 +0200 Xavier Guimard  wrote:
>> I updated node-superagent for Buster. Now I would like to propose the
>> security fix for stretch. This fixes CVE-2017-16129 (ZIP bomb attacks).
> 
> I think your patch seems to be invalid in stretch. When I ran the
> autopkgtests in stretch I see the error below, which is exactly the new
> code.
> 
> Could you please have a look soon?
> 
> Paul

Hello,

sorry for this error in my tests. Here is a new debdiff (let replaced by
var for old nodejs, no consequences here since this variable isn't used
somewhere else).

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index 0df52d2..645a574 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-superagent (0.20.0+dfsg-1+deb9u1) stretch; urgency=medium
+
+  * Team upload
+  * Add patch to fix ZIP bomb attacks (Closes: CVE-2017-16129)
+
+ -- Xavier Guimard   Thu, 18 Apr 2019 20:37:30 +0200
+
 node-superagent (0.20.0+dfsg-1) unstable; urgency=medium
 
   * Imported Upstream version 0.20.0+dfsg
diff --git a/debian/patches/CVE-2017-16129.diff 
b/debian/patches/CVE-2017-16129.diff
new file mode 100644
index 000..bedfe20
--- /dev/null
+++ b/debian/patches/CVE-2017-16129.diff
@@ -0,0 +1,34 @@
+Description: Fix for CVE-2017-16129
+Author: Xavier Guimard 
+Origin: 
https://github.com/visionmedia/superagent/commit/946e28dab08f2ab334753bf36a2fbc5110d17789
+Bug: https://security-tracker.debian.org/tracker/CVE-2017-16129
+Forwarded: 
https://github.com/visionmedia/superagent/commit/946e28dab08f2ab334753bf36a2fbc5110d17789
+Last-Update: 2019-04-18
+
+--- a/lib/node/index.js
 b/lib/node/index.js
+@@ -898,6 +898,24 @@
+ // explicit parser
+ if (parser) parse = parser;
+ 
++if (buffer) {
++  // Protection against zip bombs and other nuisance
++  var responseBytesLeft = self._maxResponseSize || 2;
++  res.on('data', function(buf) {
++responseBytesLeft -= buf.byteLength || buf.length;
++if (responseBytesLeft < 0) {
++  // This will propagate through error event
++  const err = Error("Maximum response size reached");
++  err.code = "ETOOLARGE";
++  // Parsers aren't required to observe error event,
++  // so would incorrectly report success
++  parserHandlesEnd = false;
++  // Will emit error event
++  res.destroy(err);
++}
++  });
++}
++
+ // parse
+ if (parse) {
+   try {
diff --git a/debian/patches/series b/debian/patches/series
index c366f88..a44323a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 no_require_readable-stream.patch
+CVE-2017-16129.diff

Bug#927760: choose-mirror: deb.debian.org should be advertised as supporting debian-ports

[Samuel Thibault]

John Paul Adrian Glaubitz, le lun. 22 avril 2019 23:45:15 +0200, a ecrit:
> On 4/22/19 11:40 PM, Samuel Thibault wrote:
> > John Paul Adrian Glaubitz, le lun. 22 avril 2019 23:24:53 +0200, a ecrit:
> >> This seems outdated.
> >>
> >> Ports-architecture should be:
> >>
> >> alpha hppa hurd-i386 ia64 kfreebsd-i386 kfreebsd-amd64 m68k powerpc 
> >> powerpcspe ppc64 riscv64 sh4 sparc64 x32
> > 
> > kfreebsd* are not there yet.
> 
> It was just discussed on #debian-ports that it's being moved there.

Sure, but we don't want to point anything to it before it is there :)

Samuel

Bug#927757: Drop 0001-Disable-installation-of-tests.patch

[Emmanuel Arias]

> Thanks! But may be wait a bit ;-) upstream apparently moved tests from the 
> package into top directory on the last
release. See my question
https://github.com/PyGithub/PyGithub/issues/1098

>
Ok. The buster will be release with 1.40 and have this patch.

We can close this issue with a new version of python-github on sid (1.43).



signature.asc
Description: OpenPGP digital signature

Bug#927760: choose-mirror: deb.debian.org should be advertised as supporting debian-ports

[John Paul Adrian Glaubitz]

On 4/22/19 11:40 PM, Samuel Thibault wrote:
> John Paul Adrian Glaubitz, le lun. 22 avril 2019 23:24:53 +0200, a ecrit:
>> This seems outdated.
>>
>> Ports-architecture should be:
>>
>> alpha hppa hurd-i386 ia64 kfreebsd-i386 kfreebsd-amd64 m68k powerpc 
>> powerpcspe ppc64 riscv64 sh4 sparc64 x32
> 
> kfreebsd* are not there yet.

It was just discussed on #debian-ports that it's being moved there.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#927760: choose-mirror: deb.debian.org should be advertised as supporting debian-ports

[Samuel Thibault]

John Paul Adrian Glaubitz, le lun. 22 avril 2019 23:24:53 +0200, a ecrit:
> This seems outdated.
> 
> Ports-architecture should be:
> 
> alpha hppa hurd-i386 ia64 kfreebsd-i386 kfreebsd-amd64 m68k powerpc 
> powerpcspe ppc64 riscv64 sh4 sparc64 x32

kfreebsd* are not there yet.

I have submitted to 

https://salsa.debian.org/mirror-team/masterlist/merge_requests/5
 
an update.

> We also have the problem that Debian Ports mirrors do not show up
> in the mirror list which overwhelms many users when installing one
> of the ports architectures unfortunately.

That's Bug#879130 that I mentioned, yes.

Samuel

Bug#920530: apparmor: Apparmour breaks bind/named DLZ with samba

[Bernhard Schmidt]

Am 02.04.19 um 18:25 schrieb Steven Monai:

Hi Steven,
> 
> So far, my buster Samba AD controller appears to be working correctly
> with the 'usr.sbin.named' profile in 'complain' mode. I will monitor the
> logs for a while to see if any further apparmor-related issues appear
> during my testing.

I have just uploaded 1:9.11.5.P4+dfsg-3 that should incorporate all your
local changes and also allowed /dev/urandom. I have upgraded my local
Samba AD DC to Buster with this configuration and it appears to work
fine, but this is only my personal server.

The package should be built within the next couple of hours, could you
please test it (ideally with all your local AppArmor overrides removed
and in enforce mode). I will then ask the Release Team for a Freeze
Exception.

Best Regards,
Bernhard

Bug#927766: ITP: ruby-html-proofer -- Test your rendered HTML files to make sure they're accurate

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-html-proofer
  Version : 3.10.2
  Upstream Author : Garen Torikian
* URL : https://github.com/gjtorikian/html-proofer
* License : MIT
  Programming Lang: Ruby
  Description : Test your rendered HTML files to make sure they're accurate

HTMLProofer is a set of tests to validate your HTML output. These tests check
if your image references are legitimate, if they have alt tags, if your
internal links are working, and so on. It's intended to be an all-in-one
checker for your output.

In scope is any well-known and widely-used test for HTML document quality.
A major use is continuous integration, so reliable results are a must have.
Correctness is usually balanced over performance. And, if necessary, one
should be able to trace this program's detection of HTML errors back to
documented best practices or standards, such as W3 specifications.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAly+MtkACgkQS80FZ8KW
0F1IYg/+Puol3kff1iB8v2wp5lIK+czYPYiGjqYmLoTyHzadYr3p/bT1pqAHng61
BUNS2YlJAW3iPxD+jML/JChfXRY1Baou8RJRshNFbY2A7tWwSn6mHLzHyX5T+es2
kXKHV8x9cD9JgcjFMQf6Zm2yG6bn9u0v3rpeK9s4a+5iIRpyvDfl0ChBw7ghLYmi
osgkl15k7zkKbfCEuvtcpu00hX2tkad/4LCANfoAZpRf77GTM73xN2hF1P4fb8gQ
MTzoQFPwaWC6tVe05rNrWaK6K7Czlmj8xeh77wLfWw6hBjI3wg5ohu5gLZ6fok7Q
2p6IpOuizC0+W0PNG1Ai4Kqj5tpUyD8T1PDAVNZ2zak+A2o5lQIeCPhbjJ+x9kyd
PKhoku4YNhWcQNsE+gxHYa4F65RwAiARaS1rkcDQ8zxFCim05FGJbvWfJjUYW/NO
tYOTTVo+UP3ysivZHd8tLlWhFmOzZS2mASyJGG1JauKYyyjeysOcNJ2KaDbszLgS
DPDJUkmvuKV3yIfXHtzy6cdtp/v1fhe5Y9MBLAqmFB8PsrY1SnwYzQXMsAfjb6Ae
WKksQ0RD+nrKt176qC84SbeFFWGBbv5XtpvEAxSKLTAZP6ox05+D+6xBDUIbLywe
xoLtzrE0EvgoWM5S8FUnD73xHoFj/nIWmlao6dqBcItaU5XK23g=
=zjER
-END PGP SIGNATURE-

Bug#927765: debian-archive-keyring: Team maintainer but no human uploaders (policy 3.3)

[Jonathan Wiltshire]

Package: debian-archive-keyring
Version: 2011.10.21
Severity: serious
Justification: Policy 3.3

d-a-k has a team maintainer but no human uploaders, violating the "must"
directive in policy 3.3.

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

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

-- debconf-show failed

Bug#927757: Drop 0001-Disable-installation-of-tests.patch

[Yaroslav Halchenko]

Thanks! But may be wait a bit ;-) upstream apparently moved tests from the 
package into top directory on the last release. See my question 
https://github.com/PyGithub/PyGithub/issues/1098

On April 22, 2019 5:11:53 PM EDT, Emmanuel Arias  
wrote:
>Hi Yaroslav,
>
>Thanks for the report. I am working on that.
>
>Regards!
>eamanu
>
>On 4/22/19 3:30 PM, Yaroslav Halchenko wrote:
>> Package: python-github
>> Version: 1.40-1
>> Severity: normal
>>
>> That patch disables installation of github.tests submodule.
>>
>> Having .tests submodules installed is a convention followed by the
>majority of
>> python-* packages since that allows to quickly test the functionality
>of the
>> module as installed on the system.  
>>
>> In my case I am also considering using github.tests.Framework to
>establish
>> testing of our code (in datalad) which uses github package for
>interaction with
>> github.  And I wouldn't be able to do so if this package doesn't even
>provide
>> github.tests .
>>
>> Thank you in advance
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers testing
>>   APT policy: (900, 'testing'), (600, 'unstable'), (300,
>'experimental'), (100, 'unstable-debug')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores)
>> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
>LANGUAGE=en_US.utf8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages python-github depends on:
>> ii  python   2.7.16-1
>> ii  python-jwt   1.7.0-2
>> ii  python-requests  2.21.0-1
>>
>> python-github recommends no packages.
>>
>> python-github suggests no packages.
>>
>> -- no debconf information
>>

Bug#927760: choose-mirror: deb.debian.org should be advertised as supporting debian-ports

[John Paul Adrian Glaubitz]

On 4/22/19 11:05 PM, Cyril Brulebois wrote:
> In the top-level Makefile:
> 
> 
> MIRRORLISTURL=https://salsa.debian.org/mirror-team/masterlist/raw/master/Mirrors.masterlist
> 
> so get the mirror list updated on the mirror side, and it'll get synced
> at some point.

This seems outdated.

Ports-architecture should be:

alpha hppa hurd-i386 ia64 kfreebsd-i386 kfreebsd-amd64 m68k powerpc powerpcspe 
ppc64 riscv64 sh4 sparc64 x32

We also have the problem that Debian Ports mirrors do not show up
in the mirror list which overwhelms many users when installing one
of the ports architectures unfortunately.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#927764: evince crashes in poppler on unusual pdf document

[Bernhard Übelacker]

Hello Daniel Kahn Gillmor,
the backtrace looks similar to that from this bug:

https://bugs.debian.org/924029

Kind regards,
Bernhard

Bug#927757: Drop 0001-Disable-installation-of-tests.patch

[Emmanuel Arias]

Hi Yaroslav,

Thanks for the report. I am working on that.

Regards!
eamanu

On 4/22/19 3:30 PM, Yaroslav Halchenko wrote:
> Package: python-github
> Version: 1.40-1
> Severity: normal
>
> That patch disables installation of github.tests submodule.
>
> Having .tests submodules installed is a convention followed by the majority of
> python-* packages since that allows to quickly test the functionality of the
> module as installed on the system.  
>
> In my case I am also considering using github.tests.Framework to establish
> testing of our code (in datalad) which uses github package for interaction 
> with
> github.  And I wouldn't be able to do so if this package doesn't even provide
> github.tests .
>
> Thank you in advance
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), 
> (100, 'unstable-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
> LANGUAGE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages python-github depends on:
> ii  python   2.7.16-1
> ii  python-jwt   1.7.0-2
> ii  python-requests  2.21.0-1
>
> python-github recommends no packages.
>
> python-github suggests no packages.
>
> -- no debconf information
>

-- 
Emmanuel Arias
@eamanu
https://eamanu.com




signature.asc
Description: OpenPGP digital signature

Bug#927760: choose-mirror: deb.debian.org should be advertised as supporting debian-ports

[Cyril Brulebois]

Samuel Thibault  (2019-04-22):
> Package: choose-mirror
> Version: 2.99
> Severity: normal
> 
> Hello,
> 
> I don't know the file generation details, but Mirrors.masterlist
> currently doesn't include Ports-architecture:, while it does support it,
> and I guess it would be preferred to get load balancing.

In the top-level Makefile:


MIRRORLISTURL=https://salsa.debian.org/mirror-team/masterlist/raw/master/Mirrors.masterlist

so get the mirror list updated on the mirror side, and it'll get synced
at some point.


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


signature.asc
Description: PGP signature

Bug#927764: evince crashes in poppler on unusual pdf document

[Daniel Kahn Gillmor]

Package: libpoppler-glib8
Version: 0.71.0-3
Control: affects -1 + evince

I have a pdf document that i unfortunately cannot share here.

however, trying to open the document with evince 3.30.2-3 crashes in
this way:

0 dkg@alice:~$ evince test.pdf 
! SyncTeX Error : No file?
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid
Aborted
134 dkg@alice:~$  

(i think that the SyncTeX error message is a red herring, because that
shows up on every file that i open with evince; see
https://gitlab.gnome.org/GNOME/evince/commit/678410e81d0c889f4db4e995ca451ed62b8a2eee)

(i get the same crash when testing evince 3.32.0-1 from experimental)

It looks like the underlying failure might be similar to this:

 https://bbs.archlinux.org/viewtopic.php?id=242607

That report suggests that poppler 0.72.0 might fix the issue, but i have
not tested it.  If poppler 0.72.0 was in experimental, i'd be happy to
try it out.

Here is a backtrace of the crash according to gdb:

#0  0x76e528bb in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x76e3d535 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2  0x710db983 in __gnu_cxx::__verbose_terminate_handler() () at 
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x710e18c6 in __cxxabiv1::__terminate(void (*)()) 
(handler=) at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x710e1901 in std::terminate() () at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x710e1b34 in __cxxabiv1::__cxa_throw(void*, std::type_info*, void 
(*)(void*))
(obj=obj@entry=0x7fffe040bc80, tinfo=0x711c5958 , dest=0x710f6530 ) at 
../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:95
#6  0x710dd7d3 in std::__throw_logic_error(char const*) () at 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x7172c82c in std::__cxx11::basic_string, std::allocator >::_M_construct(char 
const*, char const*, std::forward_iterator_tag)
(__end=0x , __beg=0x0, this=0x71fb89f0) at 
/usr/include/c++/8/bits/basic_string.tcc:206
#8  0x7172c82c in std::__cxx11::basic_string, std::allocator >::_M_construct_aux(char const*, char const*, std::__false_type)
(__end=0x , __beg=0x0, this=0x71fb89f0) at 
/usr/include/c++/8/bits/basic_string.h:236
#9  0x7172c82c in std::__cxx11::basic_string, std::allocator >::_M_construct(char 
const*, char const*)
(__end=0x , __beg=0x0, this=0x71fb89f0) at 
/usr/include/c++/8/bits/basic_string.h:255
#10 0x7172c82c in std::__cxx11::basic_string, std::allocator >::basic_string(char const*, 
std::allocator const&) (__a=..., __s=0x0, this=0x71fb89f0)
at /usr/include/c++/8/bits/basic_string.h:516
#11 0x7172c82c in GooString::GooString(char const*) (sA=0x0, 
this=0x71fb89f0) at ./goo/GooString.h:63
#12 0x7172c82c in poppler_date_parse(gchar const*, time_t*) 
(date=date@entry=0x0, timet=timet@entry=0x71fb8aa0) at 
./glib/poppler-date.cc:42
#13 0x717ae307 in ev_annot_from_poppler_annot (page=0x7fffe0405640, 
poppler_annot=0x557c8520) at ev-poppler.cc:3285
#14 0x717ae307 in 
pdf_document_annotations_get_annotations(EvDocumentAnnotations*, EvPage*) 
(document_annotations=, page=0x7fffe0405640) at 
ev-poppler.cc:3395
#15 0x77f2d4fa in  () at /usr/lib/x86_64-linux-gnu/libevview3.so.3
#16 0x77f2f4c2 in  () at /usr/lib/x86_64-linux-gnu/libevview3.so.3
#17 0x771f6425 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x76fe3fa3 in start_thread () at 
/lib/x86_64-linux-gnu/libpthread.so.0
#19 0x76f1482f in clone () at /lib/x86_64-linux-gnu/libc.so.6

Thanks for maintaining poppler in debian!

   --dkg


signature.asc
Description: PGP signature

Bug#927763: qemu-system-arm: switch from secure monitor to hypervisor mode fails

[Heinrich Schuchardt]

Package: qemu-system-arm
Version: 1:3.1+dfsg-7
Severity: normal

Running the U-Boot UEFI subsystem fails with the current U-Boot. It
simply hangs when trying to switch to hypervisor mode.

The appended patch resolves the issue. It has been merged in upstream
QEMU as

Commit 2d2a4549cc29850aab891495685a7b31f5254b12
target/arm: Allow Aarch32 exception return to switch from Mon->Hyp

"In U-boot, we switch from S-SVC -> Mon -> Hyp mode when we want to
enter Hyp mode. The change into Hyp mode is done by doing an
exception return from Mon. This doesn't work with current QEMU."

Please, add the patch to our Debian package.

Best regards

Heinrich Schuchardt
From 2d2a4549cc29850aab891495685a7b31f5254b12 Mon Sep 17 00:00:00 2001
From: Alexander Graf 
Date: Mon, 21 Jan 2019 10:23:11 +
Subject: [PATCH] target/arm: Allow Aarch32 exception return to switch from
 Mon->Hyp

In U-boot, we switch from S-SVC -> Mon -> Hyp mode when we want to
enter Hyp mode. The change into Hyp mode is done by doing an
exception return from Mon. This doesn't work with current QEMU.

The problem is that in bad_mode_switch() we refuse to allow
the change of mode.

Note that bad_mode_switch() is used to do validation for two situations:

 (1) changes to mode by instructions writing to CPSR.M
 (ie not exception take/return) -- this corresponds to the
 Armv8 Arm ARM pseudocode Arch32.WriteModeByInstr
 (2) changes to mode by exception return

Attempting to enter or leave Hyp mode via case (1) is forbidden in
v8 and UNPREDICTABLE in v7, and QEMU is correct to disallow it
there. However, we're already doing that check at the top of the
bad_mode_switch() function, so if that passes then we should allow
the case (2) exception return mode changes to switch into Hyp mode.

We want to test whether we're trying to return to the nonexistent
"secure Hyp" mode, so we need to look at arm_is_secure_below_el3()
rather than arm_is_secure(), since the latter is always true if
we're in Mon (EL3).

Signed-off-by: Alexander Graf 
Reviewed-by: Peter Maydell 
Message-id: 20190109152430.32359-1-ag...@suse.de
[PMM: rewrote commit message]
Signed-off-by: Peter Maydell 
---
 target/arm/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index f00c141ef9..9bf8fbd8f9 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6297,7 +6297,7 @@ static int bad_mode_switch(CPUARMState *env, int mode, CPSRWriteType write_type)
 return 0;
 case ARM_CPU_MODE_HYP:
 return !arm_feature(env, ARM_FEATURE_EL2)
-|| arm_current_el(env) < 2 || arm_is_secure(env);
+|| arm_current_el(env) < 2 || arm_is_secure_below_el3(env);
 case ARM_CPU_MODE_MON:
 return arm_current_el(env) < 3;
 default:
--
2.20.1

Bug#927695: network-manager-applet: "Advanced Network Configuration" appears under the category "X-GNOME...", please carry upstream patch to put under "Utilities"

[Andrew Hayzen]

Note that if one increases the resolution it isn't the network group it
is currently in but "X-GNOME-Sundry", so I don't think the X-GNOME-
NetworkSettings needs to be removed (and it wasn't upstream) ?


Sorry if I wasn't clear before, from the discussions in the gnome-menus 
bug https://gitlab.gnome.org/GNOME/gnome-menus/issues/10  it looks like
all of the following three patches are required for a complete
solution:

1 - 
https://gitlab.gnome.org/GNOME/gnome-menus/commit/b4600621efefd75b58486729e806a81a1014ee4b
2 - 
https://gitlab.gnome.org/GNOME/gnome-software/commit/f82457c079ab887de448dd0f01bfb0a3daaff70e
3 - 
https://gitlab.gnome.org/GNOME/network-manager-applet/commit/f1b006dd092d5e4323f887f9dc1a1c3a40b5ba2d

The gnome-software part fixes the app grid grouping.
The gnome-menu part fixes when the app-menu extension is used.
I believe the desktop file change for nm-applet helps prevent incorrect
categories from being created.

I'm new to the debian bug tracker, can a bug be made to affect multiple
projects ?  As gnome-menus needs the release in unstable to reach
testing and gnome-software needs the patch added to it.


On Mon, 2019-04-22 at 19:27 +0200, Michael Biebl wrote:
> On Sun, 21 Apr 2019 12:47:49 +0100 Andrew Hayzen 
> wrote:
> > 2 - 
> > https://gitlab.gnome.org/GNOME/network-manager-applet/commit/f1b006dd092d5e4323f887f9dc1a1c3a40b5ba2d
> 
> I tested this patch. I still get a X-GNOME.. category with it.
> I guess we not only need to add X-GNOME-Utilies, we also need to drop
> X-GNOME-NetworkSettings?
> 

Bug#924591: this requires linking in libsparse, which is from Android sources

[Hans-Christoph Steiner]

Theodore Ts'o:
> On Mon, Apr 22, 2019 at 06:09:23PM +0200, Jonas Meurer wrote:
>> Hans-Christoph Steiner:
>>> Theodore Ts'o:
 So your choice --- we can either reassign this bug back to fastboot or
 android-sdk-platforms-tools, or I can downgrade the severity of this
 bug for e2fsprogs down to wishlist[1].  Let me know how you want to
 handle this.

 [1] This is because I view this both as a "feature request" and "bugs
 that are very difficult to fix due to major design considerations"
 (per https://www.debian.org/Bugs/Developer#severities), not to mention
 that it's going to affect a miniscule fraction of the e2fsprogs
 package's users.
>>>
>>> Makes sense to me.  I'm fine with this being done post-Buster or as a
>>> custom mke2fs in android-platform-system-core.
>>
>> So the bottom line here is that the ext4 formatting support in fastboot
>> remains broken in Buster, right? That would be very unfortunate and a
>> regression compared to Stretch.
> 
> I'm not sure whether or not Stretch was using the old-style
> make_ext4fs from AOSP, or was including the mke2fs from AOSP, but yes,
> it sounds like it's a regression from stretch.  I'm not sure how many
> Debian users are using the Debian-native fastboot versus using the
> version from the Google SDK or the AOSP binaries, though.
> 
> It does seem that if this is considered high priority, the most
> straightforward way to address this bug is going to be to include
> building mke2fs from AOSP and placing it in
> /usr/lib/android-sdk/platform-tools/mke2fs.  I know some folks on the
> android tools teams aren't excited with that approach, but that
> probably is the best thing to do if you want to address this in
> Buster.

That approach sounds fine for buster.  The only question in my mind is
who will do the work...

I don't really know how fastboot in stretch provided the mke2fs support,
but judging by the dependencies, it might have been that fastboot used
to do the formatting itself, based on being linked to
android-libext4-utils and android-libsparse.  The buster version of
fastboot is clearly calling mk2efs, which in AOSP is built from an
inline e2fsprogs fork.

.hc

Bug#927762: flask-mongoengine: autopkgtest depends on mongodb which is not in buster

[Paul Gevers]

Source: flask-mongoengine
Version: 0.9.3-2
Severity: important
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainers,

I was looking into the failure of your package on the ci.debian.org
infrastructure when run in testing. One of your autopkgtests depends on
mongodb, which isn't supported anymore in testing/buster. Could you
please have a look and fix your autopkgtest?

Looking at the name and purpose of this package, is it still worthwhile
to ship it in buster, and why does it not (indirect) depend on mongodb?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924838: Any idea how to fix remote access when trying to build package?

[Andreas Tille]

Hi,

any idea how to fix the attempt to access remote location when
trying to build?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#927761: fclib: flaky autopkgtest: Segmentation fault

[Paul Gevers]

Source: fclib
Version: 3.0.0+dfsg-2
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainers,

Your package has an autopkgtest, great. However, it fails once in a
while in unstable and testing. Because the unstable-to-testing migration
software now blocks on regressions in testing, flaky tests, i.e. tests
that flip between passing and failing without changes to the list of
installed packages, are wasting peoples time. Please either fix the test
to be more robust, or mark the particular test as "flaky".

I copied some of the output at the bottom of this report. The failures
that I inspected seem to always be the same.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/f/fclib/2264257/log.gz

autopkgtest [16:33:39]: test unittests-pkgconfig: [---
'/tmp/autopkgtest-lxc._jnwn8i6/downtmp/build.o32/src/debian/tests/../../src/tests/data/local_problem_test.hdf5'
-> './local_problem_test.hdf5'
gcc -DFCLIB_NOT_HEADER_ONLY -DFCLIB_WITH_MERIT_FUNCTIONS -o
./fctst.c.bin
/tmp/autopkgtest-lxc._jnwn8i6/downtmp/build.o32/src/debian/tests/../../src/tests/fctst.c
-I/usr/include/hdf5/serial -L/usr/lib/x86_64-linux-gnu/hdf5/serial
-lfclib -lhdf5
./fctst.c.bin
Segmentation fault
autopkgtest [16:33:40]: test unittests-pkgconfig: ---]



signature.asc
Description: OpenPGP digital signature

Bug#927759: unblock: lxc/1:3.1.0+really3.0.3-8

[Pierre-Elliott Bécue]

Le lundi 22 avril 2019 à 21:40:31+0200, Pierre-Elliott Bécue a écrit :
> Subject: unblock: lxc/1:3.1.0+really3.0.3-8
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> Severity: normal
> X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org
> 
> Dear release team,
> 
> Please unblock package lxc 1:3.1.0+really3.0.3-8 from unstable to
> testing.
> 
> This release fixes the important bug 925899[0] and introduces a little
> more documentation regarding unprivileged containers which behave differently
> from the privileged ones.
> 
> As the changes made in -7 release were not actually appropriate (I sed a
> dependency on apparmor, which is quite strong), I had to do another
> release to revert some of these. The whole diff is attached and remains
> quite decent.
> 
> Thanks a lot for considering. :)
> 
> unblock lxc/1:3.1.0+really3.0.3-8
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925899
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to fr_FR.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

*grmbl* forgotten attachment *grmbl*

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
diff -Nru lxc-3.1.0+really3.0.3/debian/changelog lxc-3.1.0+really3.0.3/debian/changelog
--- lxc-3.1.0+really3.0.3/debian/changelog	2019-03-09 15:49:21.0 +0100
+++ lxc-3.1.0+really3.0.3/debian/changelog	2019-04-14 15:46:47.0 +0200
@@ -1,3 +1,24 @@
+lxc (1:3.1.0+really3.0.3-8) unstable; urgency=medium
+
+  * d/control:
+- bin:lxc sets AppArmor as a Recommend instead of a Dependency
+  * d/README.Debian:
+- Update the documentation to explain how to manage containers not
+  starting if AppArmor is missing.
+
+ -- Pierre-Elliott Bécue   Sun, 14 Apr 2019 15:46:47 +0200
+
+lxc (1:3.1.0+really3.0.3-7) unstable; urgency=medium
+
+  * d/ccontrol:
+- Add a dependency to AppArmor for lxc package as the default.conf file
+  includes an AppArmor profile.
+  * d/{NEWS,README.Debian}:
+- Add appropriate documentation for unprivileged containers
+  (Closes: #925899)
+
+ -- Pierre-Elliott Bécue   Tue, 09 Apr 2019 02:03:05 +0200
+
 lxc (1:3.1.0+really3.0.3-6) unstable; urgency=medium
 
   * d/patches/0005: Tweaks the 0004 patch for CVE-2019-5736 (Closes: #923932)
diff -Nru lxc-3.1.0+really3.0.3/debian/control lxc-3.1.0+really3.0.3/debian/control
--- lxc-3.1.0+really3.0.3/debian/control	2019-01-10 23:26:17.0 +0100
+++ lxc-3.1.0+really3.0.3/debian/control	2019-04-14 15:27:01.0 +0200
@@ -33,7 +33,8 @@
  ${misc:Depends},
  ${shlibs:Depends},
  lsb-base (>= 3.0-6)
-Recommends: bridge-utils,
+Recommends: apparmor,
+bridge-utils,
 debootstrap,
 dirmngr,
 dnsmasq-base,
@@ -46,7 +47,7 @@
 openssl,
 rsync,
 uidmap
-Suggests: apparmor, btrfs-progs, lvm2, python3-lxc
+Suggests: btrfs-progs, lvm2, python3-lxc
 Description: Linux Containers userspace tools
  Containers are insulated areas inside a system, which have their own namespace
  for filesystem, network, PID, IPC, CPU and memory allocation and which can be
diff -Nru lxc-3.1.0+really3.0.3/debian/NEWS lxc-3.1.0+really3.0.3/debian/NEWS
--- lxc-3.1.0+really3.0.3/debian/NEWS	2019-03-09 15:49:19.0 +0100
+++ lxc-3.1.0+really3.0.3/debian/NEWS	2019-04-09 02:02:51.0 +0200
@@ -6,7 +6,7 @@
   lxc-update-config is available to update automatically your
   configuration files. An automatic update is possible and offered by
   debconf during the upgrade of lxc version < 3.0.2 to lxc version >=
-  3.0.2. Mind that this update will only work for priviledged containers
+  3.0.2. Mind that this update will only work for privileged containers
   with configurations present in /var/lib/lxc/*/config and any other
   container will not be updated.
2. AppArmor support in Debian has increased, thus preventing some systemd
@@ -20,7 +20,13 @@
 
   These parameters are provided in the `/etc/lxc/default.conf` file
   shipped with LXC 3. Hence, any newly created container will have these
-  parameters set properly, execpt if you alter the forementionned file.
+  parameters set properly, except if you alter the aforementioned file.
+
+  WARNING: Note that with these parameters, unprivileged containers won't
+  be able to start. lxc.apparmor.profile must be set to either
+  'unconfined' or to 'lxc-container-default-cgns'. This can be done either
+   

Bug#927760: choose-mirror: deb.debian.org should be advertised as supporting debian-ports

[Samuel Thibault]

Package: choose-mirror
Version: 2.99
Severity: normal

Hello,

I don't know the file generation details, but Mirrors.masterlist
currently doesn't include Ports-architecture:, while it does support it,
and I guess it would be preferred to get load balancing.

(of course, Bug#879130 needs to be resolved to get it to actually show
up)

Samuel

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

Kernel: Linux 5.0.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
 je sens venir la fonte 14 pour le rapport
 -+- #ens-mim -+-

Bug#927152: teeworlds: CVE-2019-10877 CVE-2019-10878 CVE-2019-10879

[Jordy Ruiz]

On Mon, 15 Apr 2019 18:07:12 +0200 Markus Koschany wrote:
> Package: teeworlds
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
>
> Hi,
>
> The following vulnerabilities were published for teeworlds.
>
> CVE-2019-10877[0]:
> | In Teeworlds 0.7.2, there is an integer overflow in CMap::Load() in
> | engine/shared/map.cpp that can lead to a buffer overflow, because
> | multiplication of width and height is mishandled.
>
>
> CVE-2019-10878[1]:
> | In Teeworlds 0.7.2, there is a failed bounds check in
> | CDataFileReader::GetData() and CDataFileReader::ReplaceData() and
> | related functions in engine/shared/datafile.cpp that can lead to an
> | arbitrary free and out-of-bounds pointer write, possibly resulting in
> | remote code execution.
>
>
> CVE-2019-10879[2]:
> | In Teeworlds 0.7.2, there is an integer overflow in
> | CDataFileReader::Open() in engine/shared/datafile.cpp that can lead to
> | a buffer overflow and possibly remote code execution, because size-
> | related multiplications are mishandled.
>
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2019-10877
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10877
> [1] https://security-tracker.debian.org/tracker/CVE-2019-10878
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10878
> [2] https://security-tracker.debian.org/tracker/CVE-2019-10879
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10879
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
>
> Markus

>


Hi,

Teeworlds 0.7.3 was released and includes the aforementioned patches: 
https://teeworlds.com/?page=journal&id=12806


> fix security vulnerabilities CVE-2019-10879, CVE-2019-10879, 
CVE-2019-10879


Greetings,
Dune

Bug#927758: coreutils: possible autopkgtests

[Michael Stone]

On Mon, Apr 22, 2019 at 12:12:26PM -0700, you wrote:

On Mon, Apr 22, 2019 at 02:59:22PM -0400, Michael Stone wrote:

On Mon, Apr 22, 2019 at 11:41:27AM -0700, Steve Langasek wrote:
> In Ubuntu, we have applied the attached patch to include autopkgtests in the
> coreutils package.  As a core package, it is useful to have autopkgtests in
> order to detect regressions (however unlikely) introduced by the
> dependencies of coreutils.



> Would you consider including this patch in Debian?



Maybe after buster, but probably no. For years I did have coreutils run
tests on build, but test failures were far too common due to false positives
caused by idiosyncratic autobuilder configurations.


Ok, fair.  FWIW the autopkgtest that's been defined here appears to be
fairly reliable in Ubuntu: http://autopkgtest.ubuntu.com/packages/coreutils


You have a lot fewer platforms. :) OTOH, it may become more reasonable as 
some of the more obscure platforms are going away.

Bug#927759: unblock: lxc/1:3.1.0+really3.0.3-8

[Pierre-Elliott Bécue]

Subject: unblock: lxc/1:3.1.0+really3.0.3-8
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org

Dear release team,

Please unblock package lxc 1:3.1.0+really3.0.3-8 from unstable to
testing.

This release fixes the important bug 925899[0] and introduces a little
more documentation regarding unprivileged containers which behave differently
from the privileged ones.

As the changes made in -7 release were not actually appropriate (I sed a
dependency on apparmor, which is quite strong), I had to do another
release to revert some of these. The whole diff is attached and remains
quite decent.

Thanks a lot for considering. :)

unblock lxc/1:3.1.0+really3.0.3-8

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925899

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

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

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#927758: coreutils: possible autopkgtests

[Steve Langasek]

On Mon, Apr 22, 2019 at 02:59:22PM -0400, Michael Stone wrote:
> On Mon, Apr 22, 2019 at 11:41:27AM -0700, Steve Langasek wrote:
> > In Ubuntu, we have applied the attached patch to include autopkgtests in the
> > coreutils package.  As a core package, it is useful to have autopkgtests in
> > order to detect regressions (however unlikely) introduced by the
> > dependencies of coreutils.

> > Would you consider including this patch in Debian?

> Maybe after buster, but probably no. For years I did have coreutils run
> tests on build, but test failures were far too common due to false positives
> caused by idiosyncratic autobuilder configurations.

Ok, fair.  FWIW the autopkgtest that's been defined here appears to be
fairly reliable in Ubuntu: http://autopkgtest.ubuntu.com/packages/coreutils

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


signature.asc
Description: PGP signature

Bug#927395: Do not touch(1) update-exim4.conf.conf for no good reason

[Adam D. Barratt]

On Tue, 2019-04-23 at 02:35 +0800, 積丹尼 Dan Jacobson wrote:
> https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html :
> "Note that a package should not **modify** a dpkg-handled conffile in
> its
> maintainer scripts. Doing this will lead to dpkg giving the user
> confusing and possibly dangerous options for conffile update when the
> package is upgraded."
> 
> > > $ stat /etc/exim4/update-exim4.conf.conf
> > > Modify: 2019-04-18 01:32:53.473019451 +0800  
> Modified!

update-exim4.conf.conf isn't a conffile, so Policy's statements on
conffiles do not apply to it (it can't be, since the file isn't shipped
by a package).

Regards,

Adam

Bug#927758: coreutils: possible autopkgtests

[Michael Stone]

On Mon, Apr 22, 2019 at 11:41:27AM -0700, Steve Langasek wrote:

In Ubuntu, we have applied the attached patch to include autopkgtests in the
coreutils package.  As a core package, it is useful to have autopkgtests in
order to detect regressions (however unlikely) introduced by the
dependencies of coreutils.

Would you consider including this patch in Debian?


Maybe after buster, but probably no. For years I did have coreutils run 
tests on build, but test failures were far too common due to false 
positives caused by idiosyncratic autobuilder configurations.


Mike Stone

Bug#926500: freecad: FreeCad crashes when attemting to edit a existing sketch

[Kurt Kremitzki]

Hello Pere,

This issue has also been reported in the FreeCAD forums, and there are 
two likely culprits.


One user reported that temporarily moving the ~/.FreeCAD directory and 
then launching FreeCAD resulted in the issue no longer occurring, which 
would narrow the cause down to some file in that directory.


The other possible issue is the presence of 3rd party extensions, 
whether installed from the FreeCAD Community Extras PPA or otherwise, 
causing upgrade issues which may or may not have been noticed.


Could you try the "moving ~/.FreeCAD" workaround, and if that doesn't 
work, could you provide the output of `ls -l /usr/lib/freecad`?

Bug#927731: epiphany-browser/i386: private libdazzle not loaded

[積丹尼 Dan Jacobson]

SM> Does this perhaps depend on settings or something? If you create a new
SM> temporary user account, log in as the new user and run epiphany-browser,
SM> do you get the same warnings?

Same on AMD64:

$ su - some_vanilla_acct
$ DISPLAY=:0 epiphany

(epiphany:8477): dbind-WARNING **: 02:40:20.380: Couldn't register with 
accessibility bus: Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy blocked the 
reply, the reply timeout expired, or the network connection was broken.

(WebKitWebProcess:8500): dbind-WARNING **: 02:40:21.817: Couldn't register with 
accessibility bus: Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy blocked the 
reply, the reply timeout expired, or the network connection was broken.
Error loading module 
'/usr/lib/x86_64-linux-gnu/epiphany-browser/web-extensions/libephywebextension.so':
 libdazzle-1.0.so.0: cannot open shared object file: No such file or directory

Package: epiphany-browser
Version: 3.32.1.2-1

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

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

Versions of packages epiphany-browser depends on:
ii  dbus-x11 [dbus-session-bus]  1.13.8-1
ii  epiphany-browser-data3.32.1.2-1
ii  gsettings-desktop-schemas3.32.0-1
ii  iso-codes4.2-1
ii  libc62.28-8
ii  libcairo21.16.0-4
ii  libgcr-base-3-1  3.28.1-2
ii  libgcr-ui-3-13.28.1-2
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.0-1
ii  libgmp10 2:6.1.2+dfsg-4
ii  libgtk-3-0   3.24.8-1
ii  libhogweed4  3.4.1-1
ii  libicu63 63.1-6
ii  libjavascriptcoregtk-4.0-18  2.24.1-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libnettle6   3.4.1-1
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libsecret-1-00.18.8-1
ii  libsoup2.4-1 2.66.1-1
ii  libsqlite3-0 3.27.2-2
ii  libwebkit2gtk-4.0-37 2.24.1-1
ii  libxml2  2.9.8+dfsg-1+b1

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20190110
pn  evince   
pn  yelp 

epiphany-browser suggests no packages.

-- no debconf information

Bug#927758: coreutils: possible autopkgtests

[Steve Langasek]

Package: coreutils
Version: 8.30-3
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Hi Michael,

In Ubuntu, we have applied the attached patch to include autopkgtests in the
coreutils package.  As a core package, it is useful to have autopkgtests in
order to detect regressions (however unlikely) introduced by the
dependencies of coreutils.

Would you consider including this patch in Debian?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru coreutils-8.30/debian/tests/control 
coreutils-8.30/debian/tests/control
--- coreutils-8.30/debian/tests/control 1969-12-31 16:00:00.0 -0800
+++ coreutils-8.30/debian/tests/control 2017-02-28 01:13:10.0 -0800
@@ -0,0 +1,2 @@
+Tests: upstream
+Depends: coreutils, acl, strace
diff -Nru coreutils-8.30/debian/tests/upstream 
coreutils-8.30/debian/tests/upstream
--- coreutils-8.30/debian/tests/upstream1969-12-31 16:00:00.0 
-0800
+++ coreutils-8.30/debian/tests/upstream2017-02-28 01:13:10.0 
-0800
@@ -0,0 +1,348 @@
+#!/bin/sh
+# Run a subset of the upstream tests which work in an unbuilt tree against the
+# system installed package; these have been selected with
+#
+#   for t in tests/*/*; do if env LANG= LANGUAGE= LC_ALL=C 
CONFIG_HEADER=/dev/null $t >/dev/null 2>&1; then echo ${t#tests/}; fi; done
+
+# plus remove all tests depending on test binaries (getlimits, ginstall).
+#set -e
+
+# ensure that we do not stumble over translations
+unset LANG
+unset LANGUAGE
+export LC_ALL=C
+fails=0
+
+for test in \
+chgrp/basic.sh \
+chgrp/default-no-deref.sh \
+chgrp/deref.sh \
+chgrp/no-x.sh \
+chgrp/posix-H.sh \
+chgrp/recurse.sh \
+chmod/c-option.sh \
+chmod/equal-x.sh \
+chmod/equals.sh \
+chmod/inaccessible.sh \
+chmod/no-x.sh \
+chmod/octal.sh \
+chmod/setgid.sh \
+chmod/silent.sh \
+chmod/thru-dangling.sh \
+chmod/umask-x.sh \
+chmod/usage.sh \
+chown/deref.sh \
+chown/preserve-root.sh \
+cp/abuse.sh \
+cp/attr-existing.sh \
+cp/backup-1.sh \
+cp/backup-dir.sh \
+cp/backup-is-src.sh \
+cp/cp-HL.sh \
+cp/cp-deref.sh \
+cp/cp-i.sh \
+cp/cp-mv-backup.sh \
+cp/cp-parents.sh \
+cp/deref-slink.sh \
+cp/dir-rm-dest.sh \
+cp/dir-slash.sh \
+cp/dir-vs-file.sh \
+cp/existing-perm-dir.sh \
+cp/fail-perm.sh \
+cp/into-self.sh \
+cp/link-deref.sh \
+cp/link-no-deref.sh \
+cp/link-preserve.sh \
+cp/link-symlink.sh \
+cp/link.sh \
+cp/no-deref-link1.sh \
+cp/no-deref-link2.sh \
+cp/no-deref-link3.sh \
+cp/preserve-link.sh \
+cp/preserve-mode.sh \
+cp/proc-short-read.sh \
+cp/proc-zero-len.sh \
+cp/r-vs-symlink.sh \
+cp/reflink-perm.sh \
+cp/same-file.sh \
+cp/slink-2-slink.sh \
+cp/sparse-to-pipe.sh \
+cp/sparse.sh \
+cp/special-f.sh \
+cp/src-base-dot.sh \
+cp/symlink-slash.sh \
+cp/thru-dangling.sh \
+dd/ascii.sh \
+dd/bytes.sh \
+dd/direct.sh \
+dd/misc.sh \
+dd/no-allocate.sh \
+dd/nocache.sh \
+dd/not-rewound.sh \
+dd/reblock.sh \
+dd/skip-seek2.sh \
+dd/sparse.sh \
+dd/stderr.sh \
+dd/unblock-sync.sh \
+df/df-P.sh \
+df/df-output.sh \
+df/header.sh \
+df/unreadable.sh \
+du/8gb.sh \
+du/basic.sh \
+du/bigtime.sh \
+du/deref-args.sh \
+du/deref.sh \
+du/exclude.sh \
+du/files0-from-dir.sh \
+du/hard-link.sh \
+du/inacc-dest.sh \
+du/inacc-dir.sh \
+du/inodes.sh \
+du/long-from-unreadable.sh \
+du/long-sloop.sh \
+du/max-depth.sh \
+du/no-deref.sh \
+du/no-x.sh \
+du/restore-wd.sh \
+du/slash.sh \
+du/threshold.sh \
+du/trailing-slash.sh \
+du/two-args.sh \
+fmt/goal-option.sh \
+fmt/long-line.sh \
+id/uid.sh \
+id/zero.sh \
+install/trap.sh \
+ln/backup-1.sh \
+ln/hard-backup.sh \
+ln/hard-to-sym.sh \
+ln/relative.sh \
+ln/sf-1.sh \
+ln/slash-decorated-nonexistent-dest.sh \
+ln/target-1.sh \
+ls/abmon-align.sh \
+ls/block-size.sh \
+ls/color-clear-to-eol.sh \
+ls/color-dtype-dir.sh \
+ls/color-norm.sh \
+ls/color-term.sh \
+ls/dangle.sh \
+ls/dired.sh \
+ls/file-type.sh \
+ls/follow-slink.sh \
+ls/infloop.sh \
+ls/inode.sh \
+ls/m-option.sh \
+ls/multihardlink.sh \
+ls/no-arg.sh \
+ls/proc-selinux-segfault.sh \
+ls/recursive.sh \
+ls/root-rel-symlink-color.sh \
+ls/rt-1.sh \
+ls/slink-acl.sh \
+ls/stat-dtype.sh \
+ls/stat-failed.sh \
+ls/stat-free-symlinks.sh \
+ls/stat-vs-dirent.sh \
+ls/symlink-slash.

Bug#927678: elpa-beginend installs but is not accessible in emacs

[Lev Lamberov]

Damon,

Пн 22 апр 2019 @ 12:40 asmegir :

> I can confirm that '(package-initialize)' (without quotation marks) is
> present yet M-x is not finding beginend-global-mode.

thanks for your confirmation. Could you also confirm that your Emacs
init file contains "(require 'beginend)" (also without double quotes)?

Alternatively, you can open *scratch* buffer, add the following lines:

   (package-initialize)
   (require 'beginend)

and after that run eval-buffer command by

   M-x eval-buffer

With regards,
Lev

Bug#927395: Do not touch(1) update-exim4.conf.conf for no good reason

[積丹尼 Dan Jacobson]

https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html :
"Note that a package should not **modify** a dpkg-handled conffile in its
maintainer scripts. Doing this will lead to dpkg giving the user
confusing and possibly dangerous options for conffile update when the
package is upgraded."

>> $ stat /etc/exim4/update-exim4.conf.conf
>> Modify: 2019-04-18 01:32:53.473019451 +0800 

Bug#927756: Run provided tests at package built time

[Yaroslav Halchenko]

Package: python-github
Version: 1.40-1
Severity: wishlist

It is typical for packages to run their tests batteries at the package build
time.  This helps to guarantee their correct operation for the to be uploaded
version on Debian systems.

I have tried

  http_proxy=http://127.0.0.1:9/ HOME=/tmp python -m github.tests -v

on my laptop within virtualenv installing github module from within source
package (since github.tests is not shipped ATM, separate issue).  And it seems
to pass so it seems to not  require network access and doesn't rely on any HOME
configuration.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-github depends on:
ii  python   2.7.16-1
ii  python-jwt   1.7.0-2
ii  python-requests  2.21.0-1

python-github recommends no packages.

python-github suggests no packages.

-- no debconf information

Bug#927754: unblock: libfm-qt/0.14.1-6

[Alf Gaida]

diff --git a/debian/changelog b/debian/changelog
index 2124e86..e5012f5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libfm-qt (0.14.1-6) unstable; urgency=medium
+
+  * Fixed ignored creation-deletion sequences (Closes: #927707)
+
+ -- Alf Gaida   Sun, 21 Apr 2019 20:50:23 +0200
+
 libfm-qt (0.14.1-5) unstable; urgency=medium
 
   * Fixed license for vfs-search.c and vfs-menu.c - was forgotten upstream.
diff --git a/debian/patches/dont-ignore-crea-del-sequences.patch b/debian/patches/dont-ignore-crea-del-sequences.patch
new file mode 100644
index 000..677695c
--- /dev/null
+++ b/debian/patches/dont-ignore-crea-del-sequences.patch
@@ -0,0 +1,115 @@
+From 7e79e591eb536603da92ee537bf949490b1259fc Mon Sep 17 00:00:00 2001
+From: Tsu Jan 
+Date: Sun, 21 Apr 2019 14:11:14 +0430
+Subject: [PATCH] Don't ignore creation-deletion sequences
+
+Fixes https://github.com/lxqt/pcmanfm-qt/issues/944
+
+Previously, if a file was in addition queue and then it came into the deletion
+queue, its addition and deletion were both ignored. That was wrong and could
+result in showing nonexistent files because addition can also happen in
+directory list job before being processed by file info job.
+
+Also process accumulated changes only after finishing the current info job and
+don't clear all deletion paths after processing them (because, logically, only
+those paths that can be deleted should be removed).
+---
+ src/core/folder.cpp | 60 +++--
+ 1 file changed, 31 insertions(+), 29 deletions(-)
+
+diff --git a/src/core/folder.cpp b/src/core/folder.cpp
+index 6c2b27d..2385a8b 100644
+--- a/src/core/folder.cpp
 b/src/core/folder.cpp
+@@ -228,16 +228,6 @@ void Folder::onFileInfoFinished() {
+ return;
+ }
+ 
+-// process the changes accumulated during this info job
+-if(filesystem_info_pending // means a pending change; see "onFileSystemInfoFinished()"
+-   || !paths_to_update.empty() || !paths_to_add.empty() || !paths_to_del.empty()) {
+-QTimer::singleShot(0, this, &Folder::processPendingChanges);
+-}
+-// there's no pending change at the moment; let the next one be processed
+-else {
+-has_idle_update_handler = false;
+-}
+-
+ FileInfoList files_to_add;
+ FileInfoList files_to_delete;
+ std::vector files_to_update;
+@@ -271,6 +261,16 @@ void Folder::onFileInfoFinished() {
+ Q_EMIT filesChanged(files_to_update);
+ }
+ Q_EMIT contentChanged();
++
++// process the changes accumulated during this info job
++if(filesystem_info_pending // means a pending change; see "onFileSystemInfoFinished()"
++   || !paths_to_update.empty() || !paths_to_add.empty() || !paths_to_del.empty()) {
++QTimer::singleShot(0, this, &Folder::processPendingChanges);
++}
++// there's no pending change at the moment; let the next one be processed
++else {
++has_idle_update_handler = false;
++}
+ }
+ 
+ void Folder::processPendingChanges() {
+@@ -314,21 +314,24 @@ void Folder::processPendingChanges() {
+ }
+ 
+ // process deletion
+-if(!paths_to_del.empty()) {
+-FileInfoList deleted_files;
+-for(const auto &path: paths_to_del) {
+-auto name = path.baseName();
+-auto it = files_.find(name.get());
+-if(it != files_.end()) {
+-deleted_files.push_back(it->second);
+-files_.erase(it);
+-}
++FileInfoList deleted_files;
++auto path_it = paths_to_del.begin();
++while(path_it != paths_to_del.end()) {
++const auto& path = *path_it;
++auto name = path.baseName();
++auto it = files_.find(name.get());
++if(it != files_.end()) {
++deleted_files.push_back(it->second);
++files_.erase(it);
++path_it = paths_to_del.erase(path_it);
+ }
+-if(!deleted_files.empty()) {
+-Q_EMIT filesRemoved(deleted_files);
+-Q_EMIT contentChanged();
++else {
++++path_it;
+ }
+-paths_to_del.clear();
++}
++if(!deleted_files.empty()) {
++Q_EMIT filesRemoved(deleted_files);
++Q_EMIT contentChanged();
+ }
+ 
+ if(pending_change_notify) {
+@@ -404,13 +407,12 @@ void Folder::eventFileDeleted(const FilePath& path) {
+ bool deleted = true;
+ // qDebug() << "delete " << path.baseName().get();
+ // G_LOCK(lists);
+-if(std::find(paths_to_add.cbegin(), paths_to_add.cend(), path) != paths_to_add.cend()) {
+-// if the file was going to be added, just remove it from the addition queue
+-paths_to_add.erase(std::remove(paths_to_add.begin(), paths_to_add.end(), path), paths_to_add.cend());
+-}
+-else if(std::find(paths_to_del.cbegin(), paths_to_del.cend(), path) == paths_to_del.cend()) {
++/* WARNING: If the file is in the addition queue, we shouldn not remove it from that queue
++   an

Bug#927757: Drop 0001-Disable-installation-of-tests.patch

[Yaroslav Halchenko]

Package: python-github
Version: 1.40-1
Severity: normal

That patch disables installation of github.tests submodule.

Having .tests submodules installed is a convention followed by the majority of
python-* packages since that allows to quickly test the functionality of the
module as installed on the system.  

In my case I am also considering using github.tests.Framework to establish
testing of our code (in datalad) which uses github package for interaction with
github.  And I wouldn't be able to do so if this package doesn't even provide
github.tests .

Thank you in advance


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-github depends on:
ii  python   2.7.16-1
ii  python-jwt   1.7.0-2
ii  python-requests  2.21.0-1

python-github recommends no packages.

python-github suggests no packages.

-- no debconf information

Bug#927754: unblock: libfm-qt/0.14.1-6

[Alf Gaida]

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

Please unblock package libfm-qt

In some rare cases libfm-qt ignore creation/deletion squences resulting in
displaying non-existing files. (#927707)

This version fixes this.

(include/attach the debdiff against the package in testing)

unblock libfm-qt/0.14.1-6

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

Kernel: Linux 5.0.7-towo.4-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#927755: installation-reports: Debian 10 Installer RC1

[Philippe Cochy]

Package: installation-reports
Severity: normal
Tags: d-i

Dear Maintainer,

Fail to install using LVM non crypted 1 partition.
-> bypass install DD 1 partition
Driver for Caicos HD 5450 not active
-> need to install firmware-amd-graphics (non-free) *AND* remove xserver-xorg-
video-radeon (should be mutually exclusive packages)
*CRITICAL* Synaptic is not usable because of Wayland and there is no acceptable
alternative : please remove Wayland !!!



-- Package-specific info:

Boot method: network
Image version: debian-buster-DI-rc1-amd64-netinst.iso
Date: 

Machine: Shuttle SH67H3
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190410"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux pecita04 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
Processor Family DRAM Controller [8086:0100] (rev 09)
lspci -knn: Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 
[1297:4004]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd 
Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 6 
Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
lspci -knn: Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 
[1297:4004]
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05)
lspci -knn: Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 
[1297:4004]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series 
Chipset Family High Definition Audio Controller [8086:1c20] (rev 05)
lspci -knn: Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 
[1297:4004]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 3 [8086:1c14] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 05)
lspci -knn: Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 
[1297:4004]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation H67 Express Chipset 
Family LPC Controller [8086:1c4a] (rev 05)
lspci -knn: Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 
[1297:4004]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 
Series Chipset Family SATA AHCI Controller [8086:1c02] (rev 05)
lspci -knn: Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 
[1297:4004]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 6 

Bug#927709: libetpan: GnuTLS timeouts are 1000 times shorter than configured

[Ricardo Mones]

On Sun, Apr 21, 2019 at 09:10:26PM +0100, Chris Boot wrote:
> Control: severity -1 serious
> Control: tags -1 patch
> 
> Dear Maintainer,
> 
> I think this bug should be RC given that it appears to make some
> important (to some people at least) software potentially unusable on
> Buster. Please feel free to downgrade if you particularly disagree, though.

Isn't that basically the definition of 'important' severity level? :-)

Anyway, haven't looked at the bug or the fix, just arriving from a short
trip, so if you feel serious is more appropriate, so be it.

thanks,
-- 
  Ricardo Mones 
  ~
  I'm sorry, my responses are limited. You must ask the right 
  questions.   A hologram



signature.asc
Description: PGP signature

Bug#927378: stretch-pu: package node-superagent/0.20.0+dfsg-1+deb9u1

[Paul Gevers]

Hi Xavier,

On Thu, 18 Apr 2019 20:44:01 +0200 Xavier Guimard  wrote:
> I updated node-superagent for Buster. Now I would like to propose the
> security fix for stretch. This fixes CVE-2017-16129 (ZIP bomb attacks).

I think your patch seems to be invalid in stretch. When I ran the
autopkgtests in stretch I see the error below, which is exactly the new
code.

Could you please have a look soon?

Paul

https://ci.debian.net/data/autopkgtest/stable/amd64/n/node-superagent/2285440/log.gz

autopkgtest [17:53:58]: test require: [---
/usr/lib/nodejs/superagent/lib/node/index.js:903
  let responseBytesLeft = self._maxResponseSize || 2;
  ^^^

SyntaxError: Block-scoped declarations (let, const, function, class) not
yet supported outside strict mode
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at [eval]:1:1
at Object.exports.runInThisContext (vm.js:54:17)
at Object. ([eval]-wrapper:6:22)
autopkgtest [17:53:58]: test require: ---]



https://ci.debian.net/data/autopkgtest/stable/amd64/n/node-supertest/2285441/log.gz

autopkgtest [17:54:01]: test require: [---
/usr/lib/nodejs/superagent/lib/node/index.js:903
  let responseBytesLeft = self._maxResponseSize || 2;
  ^^^

SyntaxError: Block-scoped declarations (let, const, function, class) not
yet supported outside strict mode
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object. (/usr/lib/nodejs/supertest/lib/test.js:5:15)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
autopkgtest [17:54:01]: test require: ---]

Bug#927395: Do not touch(1) update-exim4.conf.conf for no good reason

[Marc Haber]

severity #927395 wishlist
thanks

On Thu, Apr 18, 2019 at 09:44:05PM +0800, 積丹尼 Dan Jacobson wrote:
> $ cat /var/log/apt/history.log
> Start-Date: 2019-04-18  01:32:49
> Upgrade: exim4-base:amd64 (4.92-5, 4.92-6), openssl:amd64 (1.1.1b-1, 
> 1.1.1b-2), unicode-data:amd64 (12.0.0-1, 12.1.0~pre1-1), 
> exim4-daemon-light:amd64 (4.92-5, 4.92-6), rsyslog:amd64 (8.1903.0-4, 
> 8.1904.0-1), exim4-config:amd64 (4.92-5, 4.92-6), exim4:amd64 (4.92-5, 
> 4.92-6), libssl1.1:amd64 (1.1.1b-1, 1.1.1b-2), libfaad2:amd64 (2.8.8-1, 
> 2.8.8-2)
> End-Date: 2019-04-18  01:32:56
> 
> some process did a touch(1) or otherwise changing
> $ stat /etc/exim4/update-exim4.conf.conf
>   File: /etc/exim4/update-exim4.conf.conf
>   Size: 1154Blocks: 8  IO Block: 4096   regular file
> Device: 803h/2051d  Inode: 524387  Links: 1
> Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
> Modify: 2019-04-18 01:32:53.473019451 +0800  Change: 2019-04-18 01:32:53.477019558 +0800

Tihs is probably the debconf-driven generation of ue4cc that happens
during package upgrades. Things have always been that way, and I bet
that a hundred other packages do the same thing. The file belongs to the
package and IMO it is ok to expect that a file that belongs to a
package changes during an update.

To avoid this, one would need to write the output to
update.exim4.conf.conf.temp, compare checksums and only move the temp
file to the real file if they are different. This probably opens the
possibility of five insecure temp file name, cruft left around bugs and
in addition a bunch of nice race conditions. I am unsure whether this is
really worth the trouble.

> causing alarm bells to ring on my homebrew security system.

Local problem ;-)  lowering severity.

> (Plus I bet it is a policy violation.)

citation needed

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#927753: gnome-maps: segmentation fault at startup

[gpe92]

Package: gnome-maps
Version: 3.30.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

   starts gnome-maps

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

   run gnome-maps in CLI

   * What was the outcome of this action?
~$ gnome-maps 

(org.gnome.Maps:29445): Gjs-WARNING **: 19:54:40.265: Some code called 
array.toString() on a Uint8Array instance. Previously this would have 
interpreted the bytes of the array as a string, but that is nonstandard. In the 
future this will return the bytes as comma-separated digits. For the time 
being, the old behavior has been preserved, but please fix your code anyway to 
explicitly call ByteArray.toString(array).
(Note that array.toString() may have been called implicitly.)
0  ["resource:///org/gnome/Maps/js/osmTypes.js":32]
1  ["resource:///org/gnome/Maps/js/osmEditDialog.js":35]
2  ["resource:///org/gnome/Maps/js/osmEdit.js":25]
3  ["resource:///org/gnome/Maps/js/contextMenu.js":33]
4  ["resource:///org/gnome/Maps/js/mainWindow.js":33]
5  ["resource:///org/gnome/Maps/js/application.js":35]
6  ["resource:///org/gnome/Maps/js/main.js":43]
7 start() ["resource:///org/gnome/gjs/modules/package.js":209]
8  ["/usr/bin/gnome-maps":2]


(org.gnome.Maps:29445): Gjs-WARNING **: 19:54:41.312: Some code called 
array.toString() on a Uint8Array instance. Previously this would have 
interpreted the bytes of the array as a string, but that is nonstandard. In the 
future this will return the bytes as comma-separated digits. For the time 
being, the old behavior has been preserved, but please fix your code anyway to 
explicitly call ByteArray.toString(array).
(Note that array.toString() may have been called implicitly.)
0 load() ["resource:///org/gnome/Maps/js/placeStore.js":168]
1 _initPlaceStore() ["resource:///org/gnome/Maps/js/application.js":186]
2 vfunc_startup() ["resource:///org/gnome/Maps/js/application.js":233]
3 main() ["resource:///org/gnome/Maps/js/main.js":57]
4 run() ["resource:///org/gnome/gjs/modules/package.js":225]
5 start() ["resource:///org/gnome/gjs/modules/package.js":209]
6  ["/usr/bin/gnome-maps":2]

Erreur de segmentation
   
   * What outcome did you expect instead?

   gnome-maps starts ...

BR

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

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

Versions of packages gnome-maps depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  geoclue-2.0  2.5.2-1
ii  gir1.2-champlain-0.120.12.16-3
ii  gir1.2-clutter-1.0   1.26.2+dfsg-10
ii  gir1.2-cogl-1.0  1.22.2-6
ii  gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-geocodeglib-1.0   3.26.0-2
ii  gir1.2-gfbgraph-0.2  0.2.3-3
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-goa-1.0   3.30.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gtkchamplain-0.12 0.12.16-3
ii  gir1.2-gtkclutter-1.01.8.4-4
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-rest-0.7  0.8.1-1
ii  gir1.2-secret-1  0.18.7-1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-webkit2-4.0   2.24.1-dmo1
ii  gjs  1.54.3-1
ii  libc62.28-8
ii  libchamplain-0.12-0  0.12.16-3
ii  libfolks25   0.11.4-1+b2
ii  libgee-0.8-2 0.20.1-2
ii  libgeocode-glib0 3.26.0-2
ii  libglib2.0-0 2.58.3-1
ii  libglib2.0-bin   2.58.3-1
ii  librest-0.7-00.8.1-1
ii  libxml2  2.9.4+dfsg1-7+b3

gnome-maps recommends no packages.

gnome-maps suggests no packages.

-- no debconf information

Bug#927752: Mention --clear-selections actually also grows selections

[積丹尼 Dan Jacobson]

Package: dpkg
Version: 1.19.6
Severity: wishlist
File: /usr/share/man/man1/dpkg.1.gz

Man page says

  --clear-selections

  Set the requested state of every non-essential package to 
deinstall
  (since dpkg 1.13.18). This is intended to be used
  immediately before --set-selections, to deinstall any
  packages not in list given to --set-selections.

OK but isn't there little point in dragging in uninstalled packages into
the status file?

# wc -l /var/lib/dpkg/status
39307 /var/lib/dpkg/status
# dpkg --clear-selections
# wc -l /var/lib/dpkg/status
45424 /var/lib/dpkg/status

Also since the name is "--clear-selections" one would think that the
status file would only stay the same or shrink, not in fact grow !
Therefore the man page should mention this side effect of what it also
does.

(P.S., better be ready to restore via status.old after trying this,
else e.g.,
# aptitude full-upgrade
E: Cannot remove aptitude within aptitude
E: Problem parsing '/var/lib/aptitude//pkgstates', is it corrupt or malformed? 
You can try to recover from '/var/lib/aptitude//pkgstates.old'.)

Bug#920619: libmariadbclient18: Upgrading from 10.1 to 10.3 breaks libaprutil1-dbd-mysql

[Markus Treinen]

Hi,

yes I can still reproduce the problem with MariaDB 1:10.3.13-2:
Apr 22 19:28:41 guybrush apachectl[1763]: Can't load driver file 
apr_dbd_mysql.so


BUT updating libaprutil1-dbd-mysql to 1.6.1-4 (from unstable as of now) 
fixed the problem.


Thanks!


Am 31.03.2019 um 16:52 schrieb Otto Kekäläinen:

Hello!

Can you still reproduce this with latest versions of MariaDB 10.3.13
and mod_perl ?

Bug#927751: elpa-lsp-ui: Race condition when using imenu and session restore

[Jerome]

Package: elpa-lsp-ui
Version: 6.0-2
Severity: normal
Tags: patch

This complement Debian bug #927749. When using lsp-ui it needs to be patched
too, or imenu will be enabled at the wrong time. See the other bug and the
upstream bug for details:
 https://github.com/emacs-lsp/lsp-mode/issues/784

Thanks



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

Kernel: Linux 4.19.0-4-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:us (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-lsp-ui depends on:
ii  elpa-dash 2.14.1+dfsg-1
ii  elpa-dash-functional  1.2.0+dfsg-5
ii  elpa-flycheck 31-2
ii  elpa-lsp-mode 6.0-1
ii  elpa-markdown-mode2.3+154-2
ii  emacsen-common3.0.4

Versions of packages elpa-lsp-ui recommends:
ii  emacs  1:26.1+1-3.2
ii  emacs-gtk [emacs]  1:26.1+1-3.2

elpa-lsp-ui suggests no packages.

-- no debconf information
--- lsp-ui-imenu.el.orig2019-01-30 10:49:12.0 +0100
+++ lsp-ui-imenu.el 2019-04-22 19:08:24.025968556 +0200
@@ -325,11 +325,7 @@
   "Mode showing imenu entries.")
 
 (defun lsp-ui-imenu-enable (enable)
-  (if enable
-  (lsp-enable-imenu)
-(when (eq imenu-create-index-function 'lsp--imenu-create-index)
-  (setq imenu-create-index-function
-'imenu-default-create-index-function
+  )
 
 (provide 'lsp-ui-imenu)
 ;;; lsp-ui-imenu.el ends here

Bug#924591: this requires linking in libsparse, which is from Android sources

[Theodore Ts'o]

On Mon, Apr 22, 2019 at 06:09:23PM +0200, Jonas Meurer wrote:
> Hans-Christoph Steiner:
> > Theodore Ts'o:
> >> So your choice --- we can either reassign this bug back to fastboot or
> >> android-sdk-platforms-tools, or I can downgrade the severity of this
> >> bug for e2fsprogs down to wishlist[1].  Let me know how you want to
> >> handle this.
> >>
> >> [1] This is because I view this both as a "feature request" and "bugs
> >> that are very difficult to fix due to major design considerations"
> >> (per https://www.debian.org/Bugs/Developer#severities), not to mention
> >> that it's going to affect a miniscule fraction of the e2fsprogs
> >> package's users.
> > 
> > Makes sense to me.  I'm fine with this being done post-Buster or as a
> > custom mke2fs in android-platform-system-core.
> 
> So the bottom line here is that the ext4 formatting support in fastboot
> remains broken in Buster, right? That would be very unfortunate and a
> regression compared to Stretch.

I'm not sure whether or not Stretch was using the old-style
make_ext4fs from AOSP, or was including the mke2fs from AOSP, but yes,
it sounds like it's a regression from stretch.  I'm not sure how many
Debian users are using the Debian-native fastboot versus using the
version from the Google SDK or the AOSP binaries, though.

It does seem that if this is considered high priority, the most
straightforward way to address this bug is going to be to include
building mke2fs from AOSP and placing it in
/usr/lib/android-sdk/platform-tools/mke2fs.  I know some folks on the
android tools teams aren't excited with that approach, but that
probably is the best thing to do if you want to address this in
Buster.

- Ted

Bug#927750: Doubled slash

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.11-7
Severity: minor

One sees a (harmless) // in:

E: Cannot remove aptitude within aptitude
E: Problem parsing '/var/lib/aptitude//pkgstates', is it corrupt or malformed? 
You can try to recover from '/var/lib/aptitude//pkgstates.old'.

Reproduce by doing
dpkg --forget-old-unavail
dpkg --clear-avail
dpkg --clear-selections
(but you better keep a backup of
/var/lib/dpkg/status
before you start.)
and then aptitude full-upgrade

Bug#927749: elpa-lsp-mode: Race condition in lsp-mode when using imenu and session restore

[Jerome]

Package: elpa-lsp-mode
Version: 6.0-1
Severity: normal
Tags: patch

There is a race condition possibly leading to an error when lsp-mode is used
with imenu and session restore. See the upstream bug report for more details:
  https://github.com/emacs-lsp/lsp-mode/issues/784

The author helped in getting a patch for version 6.0 as included in Debian
Buster. The packet lsp-ui also need a small patch, I'll file another bug for
that.



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

Kernel: Linux 4.19.0-4-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:us (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-lsp-mode depends on:
ii  elpa-dash 2.14.1+dfsg-1
ii  elpa-dash-functional  1.2.0+dfsg-5
ii  elpa-f0.20.0-1
ii  elpa-ht   2.2-2
ii  elpa-spinner  1.7.3-1
ii  emacsen-common3.0.4

Versions of packages elpa-lsp-mode recommends:
ii  emacs  1:26.1+1-3.2
ii  emacs-gtk [emacs]  1:26.1+1-3.2

elpa-lsp-mode suggests no packages.

-- no debconf information
--- lsp-mode.el.orig2019-01-21 21:56:43.0 +0100
+++ lsp-mode.el 2019-04-22 19:17:56.714357377 +0200
@@ -473,6 +473,16 @@
 
 (defvar lsp--tcp-port 1)
 
+(defvar-local lsp--document-symbols nil
+  "The latest document symbols.")
+
+(defvar-local lsp--document-symbols-request-async nil
+  "If non-nil, request document symbols asynchronously.")
+
+(defvar-local lsp--document-symbols-tick -1
+  "The value of `buffer-chars-modified-tick' when document
+  symbols were last retrieved.")
+
 (cl-defgeneric lsp-execute-command (server command arguments)
   "Ask SERVER to execute COMMAND with ARGUMENTS.")
 
@@ -1674,6 +1684,9 @@
  (kind (if (hash-table-p sync) (gethash "change" sync) sync)))
 (setq lsp--server-sync-method (or lsp-document-sync-method
   (alist-get kind lsp--sync-methods
+  (when (and lsp-auto-configure (lsp--capability "documentSymbolProvider"))
+(lsp-enable-imenu))
+
   (run-hooks 'lsp-after-open-hook))
 
 (define-inline lsp--text-document-identifier ()
@@ -2591,8 +2604,38 @@
 'def-params td-params)))
 
 (defun lsp--get-document-symbols ()
-  (lsp-request "textDocument/documentSymbol"
-   `(:textDocument ,(lsp--text-document-identifier
+  "Get document symbols.
+
+If the buffer has not been modified since symbols were last
+retrieved, simply return the latest result.
+
+Else, if the request was initiated by Imenu updating its menu-bar
+entry, perform it asynchronously; i.e., give Imenu the latest
+result and then force a refresh when a new one is available.
+
+Else (e.g., due to intereactive use of `imenu' or `xref'),
+perform the request synchronously."
+  (if (= (buffer-chars-modified-tick) lsp--document-symbols-tick)
+  lsp--document-symbols
+(let ((method "textDocument/documentSymbol")
+ (params `(:textDocument ,(lsp--text-document-identifier)))
+ (tick (buffer-chars-modified-tick)))
+  (if (not lsp--document-symbols-request-async)
+ (prog1
+ (setq lsp--document-symbols (lsp-request method params))
+   (setq lsp--document-symbols-tick tick))
+   (lsp-request-async method params
+  (lambda (document-symbols)
+(setq lsp--document-symbols 
document-symbols
+  lsp--document-symbols-tick 
tick)
+(lsp--imenu-refresh))
+  :mode 'alive)
+   lsp--document-symbols
+
+(advice-add 'imenu-update-menubar :around
+   (lambda (oldfun &rest r)
+ (let ((lsp--document-symbols-request-async t))
+   (apply oldfun r
 
 (defun lsp--xref-backend () 'xref-lsp)
 
@@ -3173,9 +3216,14 @@
  (result (compare-strings name1 0 (length name1) name2 0 (length 
name2
 (if (numberp result) result 0)))
 
+(defun lsp--imenu-refresh ()
+  "Force Imenu to refresh itself."
+  (imenu--menubar-select imenu--rescan-item))
+
 (defun lsp-enable-imenu ()
   "Use lsp-imenu for the current buffer."
-  (setq-local imenu-create-index-function #'lsp--imenu-create-index))
+  (setq-local imenu-create-index-function #'lsp--imenu-create-index)
+  (lsp--imenu-refresh))
 
 (defun lsp-resolve-final-function (command)
   "Resolve final function COMMAND."
@@ -3304,8 +3352,6 @@
 (lsp-ui-flycheck-enable t)
 (flycheck-mode 1)))
 
-  (lsp-enable-imenu)
-
   (when (functionp 'company-lsp)
 (company-mode 1)
 (setq-local company-backends '(company-lsp

Bug#923675: debian-installer: consider using haveged to gather entropy

[Cyril Brulebois]

Holger Levsen  (2019-04-22):
> heh. what was the reason haveged was choosen and not
> jitterentropy-rngd which was also suggested here?

I have enough things to keep me busy; if the first one I look at can be
turned into something useful in d-i, seems to have reasonable integration
and maintenance costs, and has a maintainer who is happy to let me modify
the packaging accordingly, then it's unlikely I'll spend more time looking
at an alternative.

Not that I wouldn't appreciate such a comparison in theory; in practice,
time is limited. If others want to compare both, feel free to.


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


signature.asc
Description: PGP signature

Bug#927695: network-manager-applet: "Advanced Network Configuration" appears under the category "X-GNOME...", please carry upstream patch to put under "Utilities"

[Michael Biebl]

On Sun, 21 Apr 2019 12:47:49 +0100 Andrew Hayzen  wrote:
> 2 - 
> https://gitlab.gnome.org/GNOME/network-manager-applet/commit/f1b006dd092d5e4323f887f9dc1a1c3a40b5ba2d

I tested this patch. I still get a X-GNOME.. category with it.
I guess we not only need to add X-GNOME-Utilies, we also need to drop
X-GNOME-NetworkSettings?

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



signature.asc
Description: OpenPGP digital signature

Bug#926888: unblock: wget/1.20.1-1.1

[Cyril Brulebois]

Hi,

Niels Thykier  (2019-04-21):
> On Fri, 12 Apr 2019 07:54:00 + Niels Thykier  wrote:
> > Control: tags -1 d-i confirmed
> > 
> > Salvatore Bonaccorso:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: unblock
> > > 
> > > Hi,
> > > 
> > > Please unblock package wget
> > > 
> > > It fixes CVE-2019-5953, #926389 a buffer overflow vulnerability in the
> > > handling of Internationalized Resource Identifiers (IRI), it was
> > > adressed as well in DSA-4425-1 for stretch.
> > > 
> > > Attached is the debdiff between 1.20.1-1 and 1.20.1-1.1.
> > > 
> > > unblock wget/1.20.1-1.1
> > > 
> > > Regards,
> > > Salvatore

> > OK from here; Cc'ing KiBi for a d-i ack.
> > 
> > Thanks,
> > ~Niels
> > 
> > 
> 
> Gentle ping on this unblock request for a CVE fix in wget.

No objections, thanks.

Sorry, I had closed my local todo item as I thought it was done already,
but I got confused there (was probably thinking about the openssl bug
fix that made wget work in d-i)…


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


signature.asc
Description: PGP signature

Bug#927726: wlroots: Please upload new upstream version

[Birger Schacht]

hi,

On 4/22/19 8:46 AM, Guido Günther wrote:
> Hi,
> On Mon, Apr 22, 2019 at 01:28:49AM +, Linda Lapinlampi wrote:
>> Source: wlroots
>> Severity: wishlist
>>
>> Dear Maintainer,
>>
>> 0.4 and 0.5.0 have been have been packaged a month ago at VCS (salsa),
>> but never uploaded to Debian's distribution. Could you upload wlroots
>> 0.5.0 to experimental distribution, please?
> 
> They were uploaded and set in new for several weeks but were rejected
> last week due to missing d/copyright entries. If you want to fix those
> I'm happy to take a MR. 

There you go: https://salsa.debian.org/swaywm-team/wlroots/merge_requests/2

cheers,
Birger


> This is the ftp-masters mail:
> 
> ```
> our hard working trainess found the following issues in your package:
> 
>   include/rootston/ini.h, rootston/ini.c, examples/screencopy.c,
>   numerous files in protocol/, tinywl/ not accounted for in d/copyright
> 
>   Minor issues in d/copyright: `Files: *` stanza needs copyright years
>   updating; should be `License: Expat` not `License: MIT`.
> ```
> 
> Cheers,
>  -- Guido
> 

-- 
That's my email. Hope you liked it!