Bug#198112: Ahoj

[L Consultant]

Kontaktujte nás, je to velmi naléhavé.
S pozdravem
L konzultant

Bug#949127: RM: ppx-driver -- ROM; deprecated by upstream

[Stéphane Glondu]

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

Please remove ppx-driver from unstable. It is deprecated upstream [1]
(in favour of ppxlib) and no longer has reverse-dependencies.

[1] https://github.com/janestreet-deprecated/ppx_driver


Cheers,

-- 
Stéphane

Bug#939506: expected primary-expression before ‘{’ token (Was: Bug#939506: unanimity ftbfs in unstable)

[Andreas Tille]

Hi Matthew,

On Thu, Jan 16, 2020 at 07:55:44PM -0800, Matthew Fernandez wrote:
> > I forgot to mention that I bounced your mail to the bug log of #939506
> > and I also CC this one to make sure there is some publicly visible
> > record of the discussion.
> 
> Good idea for a future audience.

:-)
 
> > On Wed, Jan 15, 2020 at 09:27:16AM +0100, Andreas Tille wrote:
> >> Hope that you might find some time to reproduce any may be suggest a
> >> patch.  If not you might have learned at least something about Debian
> >> packaging. ;-)
> 
> Despite using git-buildpackage in my own packaging attempts, I am basically a 
> GBP noob. All of the above was new information to me, so thank you for 
> educating me :)

It was a pleasure. :-)  In case you might loose this mail you can always
to a web search for "Debian Med team policy" which shoud lead you to

  
https://med-team.pages.debian.net/policy/#to-make-gbp-buildpackage-build-the-package-with-pdebuild

telling basically the same.

> Following your steps, I can now reproduce this error. I’ll try to  
> investigate but given the complexity of this build system and dependencies I 
> would not hold my breath. If someone else reading can offer more help, please 
> do.

Surely any help is welcome.  I admit we even have some more C++ problems
pending in the team.  Just in case you might run out of challenges. ;-)

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#949126: RFP: xraylarch -- X-ray absorption, fluorescence spectroscopy and diffraction data analysis

[merkys]

Hi Stuart,

On 2020-01-17 08:30, Stuart Prescott wrote:
> * Package name: xraylarch
>   Version : 0.9.46
>   Upstream Author : Matthew Newville, The University of Chicago
> * URL : http://xraypy.github.io/xraylarch/
> * License : BSD-2-clause
>   Programming Lang: Python
>   Description : X-ray absorption, fluorescence spectroscopy and 
> diffraction data analysis

This sounds interesting. Are you going to give its packaging a try?

Best,
Andrius

Bug#949126: RFP: xraylarch -- X-ray absorption, fluorescence spectroscopy and diffraction data analysis

[Stuart Prescott]

Package: wnpp
Severity: wishlist

* Package name: xraylarch
  Version : 0.9.46
  Upstream Author : Matthew Newville, The University of Chicago
* URL : http://xraypy.github.io/xraylarch/
* License : BSD-2-clause
  Programming Lang: Python
  Description : X-ray absorption, fluorescence spectroscopy and diffraction 
data analysis

Larch is a library and set of applications for processing and analyzing X-ray
absorption and fluorescence spectroscopy data and X-ray fluorescence and
diffraction image data from synchrotron beamlines. It is especially focussed
on X-ray absorption fine-structure spectroscopy (XAFS) including X-ray
absorption near-edge spectroscopy (XANES) and extended X-ray absorption
fine-structure spectroscopy (EXAFS). It also supports visualization and
analysis tools for X-ray fluorescence (XRF) spectra and XRF and X-ray
diffraction (XRD) images as collected at scanning X-ray microprobe beamlines.


This package replaces the iffeffit and horae applications.

Bug#949125: bts: add shortcut command for use when reintroducing packages

[Paul Wise]

Package: devscripts
Severity: wishlist
File: /usr/bin/bts
User: devscri...@packages.debian.org
Usertags: bts

One of the extra steps when reintroducing packages is to unarchive and
reopen any bugs that were closed by the FTP Masters with the +rm
version. Then those bugs should be either kept open until they are
fixed or marked as fixed in the first new upload.

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

Manually going through all the bugs, checking if they are archived,
checking if their closed version ends in +rm and then emitting the
right unarchive and reopen commands in the right order is tedious.

It would be nice to have a command something like this:

bts reintroduced fontmatrix

Send these commands to the BTS control bot:

package fontmatrix
unarchive 744698
reopen 744698
unarchive 787350
reopen 787350
⋮

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#949124: RM: horae -- RoQA; rdeps removed; dead upstream

[Stuart Prescott]

Package: ftp.debian.org
Severity: normal

The horae package relies on the iffeffit package which is Python 2-only and
ready to be removed from Debian. Upstream has replaced it with a
new suite of programs known as Larch. http://xraypy.github.io/xraylarch/

horae (and ifeffit) can be removed from Debian.

Bug#949123: RM: ifeffit -- RoQA; Python 2 only; dead upstream

[Stuart Prescott]

Package: ftp.debian.org
Severity: normal

The ifeffit package is Python 2-only and upstream has replaced it with a
new suite of programs known as Larch. http://xraypy.github.io/xraylarch/

ifeffit (and horae) can be removed from Debian.

Bug#938419: ruby-github-markup: Python2 removal in sid/bullseye

[Pirate Praveen]

On 2020, ജനുവരി 17 1:18:01 AM IST, Matthias Klose  wrote:
>On 16.01.20 20:28, Pirate Praveen wrote:
>> Control: tags -1 help
>> 
>> On Fri, 30 Aug 2019 07:51:22 + Matthias Klose 
>wrote:
>>> Python2 becomes end-of-live upstream, and Debian aims to remove
>>> Python2 from the distribution, as discussed in
>>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>>>
>>> Your package either build-depends, depends on Python2, or uses
>Python2
>>> in the autopkg tests.  Please stop using Python2, and fix this issue
>>> by one of the following actions.
>>>
>>> - Convert your Package to Python3. This is the preferred option.  In
>>>   case you are providing a Python module foo, please consider
>dropping
>>>   the python-foo package, and only build a python3-foo package. 
>Please
>>>   don't drop Python2 modules, which still have reverse dependencies,
>>>   just document them.
>>>     This is the preferred option.
>> 
>> I have tried to port this package to python 3, but one test is
>failing now.
>> Changes are pushed to salsa master branch. I need help in fixing
>this.
>> 
>>   1) Failure:
>> MarkupTest#test_rst [/<>/test/markup_test.rb:71]:
>> README.rst.html's contents are not html equal to output:
>
>at least in Ubuntu I saw that failure with Python2 as well, with a
>no-change
>rebuild.

Can you share the logs? Previous failure was on README.org.html which I was 
able to reproduce and fix with a patch.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#937969: python-omemo-backend-signal: Python2 removal in sid/bullseye

[Scott Kitterman]

The fact that python-omemo-backend-signal hasn't been removed yet is 
preventing python-omemo, python-xeddsa, and python-nacl from migrating to 
Testing.  

It's only needed as a Recommends for sat-xmpp-core, whch is about to be 
removed from Testing.  I think it would be better to go ahead and drop the  -
python-omemo=-backend-signal, but I'm going to bump the severity of this bug 
and wait for maintainer feedback.  If python-omemo-backend-signal is removed 
from Testing as a result, that will solve the problem of the other packages 
not migrating.

If you'd prefer I NMU to remove it, please let me know (please cc me as I'm 
not subscribed to the bug).

Scott K

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

Bug#936337: cp2k: Python2 removal in sid/bullseye

[Stuart Prescott]

Control: tags -1 + patch

An initial take on a patch for this is in a MR on salsa.

https://salsa.debian.org/debichem-team/cp2k/merge_requests/1


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#949122: fai-setup-storage: btrfs on additional device does not apear in fstab

[Stefan]

Package: fai-setup-storage
Version: 5.8.9
Severity: normal

Dear Martin,

I use the followin disk config (after many tries, coz of errors with missing
dirs if I use other subvols (like /media/@sda1 /var/lib/@vz etc.)), which at
least did what I want:
disk_config sdc disklabel:msdos bootable:1 fstabkey:uuid
primary /   100Gbtrfs   rw,subvol=@/
createopts="-L root"
logical swap5G  swapsw
logical /var50G btrfs
rw,relatime,nosuid,nodev,subvol=@var createopts="-L var -m 1" tuneopts="-c 0 -i
0"
logical /opt100Gbtrfs
rw,relatime,nosuid,nodev,subvol=@opt createopts="-L opt -m 1" tuneopts="-c 0 -i
0"
logical /var/lib/vz 0-  btrfs
rw,relatime,nosuid,nodev,subvol=@vz createopts="-L vz -m 0" tuneopts="-c 0 -i
0"
#logical/var/lib/vz 0-  btrfs
rw,relatime,nosuid,nodev,subvol=/var/lib/@vz createopts="-L vz -m 0"
tuneopts="-c 0 -i 0"

disk_config sda fstabkey:uuid
primary /media/sda1 0-  btrfs
rw,relatime,nosuid,nodev,subvol=@sda1 createopts="-L sda1 -m 1" tuneopts="-c 0
-i 0"

disk_config sdb fstabkey:uuid
primary /media/sdb1 0-  btrfs
rw,relatime,nosuid,nodev,subvol=@sdb1 createopts="-L sdb1 -m 1" tuneopts="-c 0
-i 0"

In the format.log I can see that everything is happened as expected:
Starting setup-storage 2.2
Using config file: /var/lib/fai/config/disk_config/srv4
Parted could not read a disk label (new disk?)
Executing: parted -s /dev/sdc mklabel msdos
Adding mkfs command for '/dev/sdb1, /dev/sda1, /dev/sdc8'.
Adding mkfs command for '/dev/sdc6'.
Adding mkfs command for '/dev/sdc1'.
Adding mkfs command for '/dev/sdc7'.
Executing: wipefs -af /dev/sdb1
Executing: parted -s /dev/sdb mklabel msdos
Executing: parted -s /dev/sdb mkpart primary "btrfs" 1048576B 400088457215B
Executing: wipefs -af /dev/sda1
Executing: parted -s /dev/sda mklabel msdos
Executing: parted -s /dev/sda mkpart primary "btrfs" 1048576B 400088457215B
Executing: parted -s /dev/sdc mklabel msdos
Executing: parted -s /dev/sdc mkpart primary "btrfs" 1048576B 107375230975B
Executing: parted -s /dev/sdc set 1 boot on
Executing: parted -s /dev/sdc mkpart extended "" 107375230976B 599550590975B
Executing: parted -s /dev/sdc mkpart logical "linux-swap" 107375232000B
112743941119B
Executing: parted -s /dev/sdc mkpart logical "btrfs" 112743942144B
166431033343B
Executing: parted -s /dev/sdc mkpart logical "btrfs" 166431034368B
273805216767B
Executing: parted -s /dev/sdc mkpart logical "btrfs" 273805217792B
599550590975B
Executing: mkswap  /dev/sdc5
Executing: mkfs.btrfs -d single  -f /dev/sdc6
Executing: mount /dev/sdc6 /mnt
Executing: btrfs subvolume create   /mnt/@var
Executing: umount /dev/sdc6
Executing: mkfs.btrfs -d single  -f /dev/sdc1
Executing: mount /dev/sdc1 /mnt
Executing: btrfs subvolume create   /mnt/@/
Executing: umount /dev/sdc1
Executing: mkfs.btrfs -d single  -f /dev/sdc7
Executing: mount /dev/sdc7 /mnt
Executing: btrfs subvolume create   /mnt/@opt
Executing: umount /dev/sdc7
Executing: mkfs.btrfs -d single  -f /dev/sdb1 /dev/sda1 /dev/sdc8
Executing: mount /dev/sdb1 /mnt
Executing: btrfs subvolume create   /mnt/@vz
Executing: umount /dev/sdb1
/dev/sdb1 UUID=f357b638-29f5-44c3-90d3-8114fffd906d
/dev/sdc6 UUID=2c9efc7c-6937-4a9f-a54a-762b1767a865
/dev/sdc1 UUID=5c8354d8-6a63-4584-8409-5befcb2bd9a8
/dev/sdc7 UUID=b4ba3b35-f2eb-4cbf-96e6-16b215417545
/dev/sdc5 UUID=d03e8c52-be5d-4705-9a61-88f373502ac9

But I cannot see any entry for real sd[a|b]1 in the fstab, but there is an sdb1
entry which looks totally wrong (pointed to /var/lib/vz):
# cat /target/etc/fstab
--
# /etc/fstab: static file system information.
#
#   

# device during installation: /dev/sdc1
UUID=5c8354d8-6a63-4584-8409-5befcb2bd9a8   /   btrfs   rw,subvol=@/
0   1

# device during installation: /dev/sdc7
UUID=b4ba3b35-f2eb-4cbf-96e6-16b215417545   /optbtrfs
rw,relatime,nosuid,nodev,subvol=@opt0   2

# device during installation: /dev/sdc6
UUID=2c9efc7c-6937-4a9f-a54a-762b1767a865   /varbtrfs
rw,relatime,nosuid,nodev,subvol=@var0   2

# device during installation: /dev/sdb1
UUID=f357b638-29f5-44c3-90d3-8114fffd906d   /var/lib/vz btrfs
rw,relatime,nosuid,nodev,subvol=@vz 0   2

# device during installation: /dev/sdc5
UUID=d03e8c52-be5d-4705-9a61-88f373502ac9   noneswapsw  0
0
tmpfs /tmp tmpfs nodev,nosuid,size=50%,mode=1777   00
/dev/sr0/media/cdrom0   udf,iso9660 ro,user,noauto  0   0
---



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

Kernel: Linux 5.3.0-24-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE

Bug#949089: libxmlrpc3-java: CVE-2019-17570: deserialization of server-side exception from faultCause in XMLRPC error response

[Salvatore Bonaccorso]

Hi Markus,

On Fri, Jan 17, 2020 at 01:04:10AM +0100, Markus Koschany wrote:
> Hi,
> 
> Am 16.01.20 um 21:27 schrieb Salvatore Bonaccorso:
> > Source: libxmlrpc3-java
> > Version: 3.1.3-9
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > 
> > Hi,
> > 
> > The following vulnerability was published for libxmlrpc3-java.
> > 
> > CVE-2019-17570[0]:
> > | Deserialization of server-side exception from faultCause in XMLRPC
> > | error response
> > 
> > That said, should libxmlrpc3-java rather be removed from unstable, and
> > not included in bullseye?
> 
> [...]
> 
> It looks like starjava-topcat is the only package that build-depends on
> libxmlrpc3-java at the moment (need to check that again). I think the
> issue itself can be fixed by the proposed Red Hat patch, making the use
> of some parts of the vulnerable method conditional on a set property.
> Since Apache xml-rpc is EOL it makes sense to remove it from Debian
> though. I will file a bug report for starjava-topcat and then let's see
> how it goes.

I did check yesterday for that to see what impact it would have on the
archive, and indeed the "only" package problem are as follows, as you
have already spotted:

| Will remove the following packages from sid:
| 
| libxmlrpc3-client-java |3.1.3-9 | all
| libxmlrpc3-common-java |3.1.3-9 | all
| libxmlrpc3-java |3.1.3-9 | source
| libxmlrpc3-java-doc |3.1.3-9 | all
| libxmlrpc3-server-java |3.1.3-9 | all
| 
| Maintainer: Debian Java Maintainers 

| 
| --- Reason ---
| 
| --
| 
| Checking reverse dependencies...
| # Broken Build-Depends:
| starjava-topcat: libxmlrpc3-client-java
| 
| Dependency problem found.

The patch proposed by Red Hat looks straightforward (with my limited
understanding though), but might have as well potential for regression
reports, as it is disabling deserialization by default, i.e. only uses
it if isEnabledForExceptions is set.

So I'm wary yet on what to do for stable (and older releases and have
not done any marking yet in the security tracker.

Opinions on that?

Regards,
Salvatore

Bug#949121: buster-pu: package node-kind-of/6.0.2+dfsg-1+deb10u1

[Xavier Guimard]

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

Hi,

node-kind-of is vulnerable to CVE-2019-20149: it allows external user
input to overwrite certain internal attributes via a conflicting name.
This little patch fixes this issue.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index f69a6ac..93d28bf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-kind-of (6.0.2+dfsg-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * fix type checking vul in ctorName (Closes: #948095, CVE-2019-20149)
+
+ -- Xavier Guimard   Fri, 17 Jan 2020 06:19:37 +0100
+
 node-kind-of (6.0.2+dfsg-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2019-20149.diff 
b/debian/patches/CVE-2019-20149.diff
new file mode 100644
index 000..0129c8e
--- /dev/null
+++ b/debian/patches/CVE-2019-20149.diff
@@ -0,0 +1,20 @@
+Description: fix type checking vul in ctorName
+ CVE-2019-20149
+Author: Brian Woodward
+Bug: https://github.com/jonschlinkert/kind-of/pull/30
+Bug-Debian: https://bugs.debian.org/948095
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-01-17
+
+--- a/index.js
 b/index.js
+@@ -66,7 +66,7 @@
+ };
+ 
+ function ctorName(val) {
+-  return val.constructor ? val.constructor.name : null;
++  return typeof val.constructor === 'function' ? val.constructor.name : null;
+ }
+ 
+ function isArray(val) {
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..4228152
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2019-20149.diff

Bug#949120: buster-pu: package quassel/1:0.13.1-1

[Scott Kitterman]

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

This update does two things:

1.  Corrects the provided apparmor profile so that user creation and
storage work with quassel-core.  Currently on  a new install or if a new
user is added to an existing install, the storage for the user
information will fail due to inadquate appamor permissions and some time
later, users will discover their information is gone (it works during
the initial session, but is not saved for subsequent use.

The most typical response of users that run into this problem is to give
up on using the package.  The second most typical response is to disable
apparmor.  Obviously neither of those are good.  The change is low risk.
I did test it on buster with a new setup to verify it works.

2.  Corrects default Debian channel.  I don't know when #debian-user got
replaced by #debian, but #debian is the standard support channel that we
want as the default for new users.  Currenlty new users will get an
error about being blocked from joinging #debian-user which recommends
joining #debian.  This is a very pooor first user experience.

The change is trivial and low risk (only affects new installs).

These changes are both already in Testing.

Scott K
diff -Nru quassel-0.13.1/debian/changelog quassel-0.13.1/debian/changelog
--- quassel-0.13.1/debian/changelog 2019-02-15 13:00:08.0 -0500
+++ quassel-0.13.1/debian/changelog 2020-01-16 23:28:02.0 -0500
@@ -1,3 +1,15 @@
+quassel (1:0.13.1-1+deb10u1) buster; urgency=medium
+
+  [ Felix Geyer ]
+  * Fix quasselcore AppArmor denials when the config is saved. (Closes:
+#940482)
+
+  [ Scott Kitterman ]
+  * Correct default channel for Debian
+  * Add NEWS entry about reloading the quaseelcore AppArmor profile
+
+ -- Scott Kitterman   Thu, 16 Jan 2020 23:28:02 -0500
+
 quassel (1:0.13.1-1) unstable; urgency=medium
 
   [ Scott Kitterman ]
diff -Nru quassel-0.13.1/debian/NEWS quassel-0.13.1/debian/NEWS
--- quassel-0.13.1/debian/NEWS  1969-12-31 19:00:00.0 -0500
+++ quassel-0.13.1/debian/NEWS  2020-01-11 19:58:20.0 -0500
@@ -0,0 +1,11 @@
+quassel (1:0.13.1-2) unstable; urgency=medium
+
+  * This revision of quassel contains an updated apparmor profile for quassel-
+core.  To load the new profile, use the following command on the server
+running the core:
+
+apparmor_parser -r /etc/apparmor.d/usr.bin.quasselcore
+
+This only applies to quaseelcore, no action is required for clients.
+
+ -- Scott Kitterman   Sat, 11 Jan 2020 14:55:50 -0500
diff -Nru quassel-0.13.1/debian/patches/01_default_network_channel.patch 
quassel-0.13.1/debian/patches/01_default_network_channel.patch
--- quassel-0.13.1/debian/patches/01_default_network_channel.patch  
2019-01-05 15:18:57.0 -0500
+++ quassel-0.13.1/debian/patches/01_default_network_channel.patch  
2020-01-10 21:03:05.0 -0500
@@ -21,4 +21,4 @@
 +Servers=irc.debian.org:+6697
 +
 +Default=Yes
-+DefaultChannels=#debian-user
++DefaultChannels=#debian
diff -Nru quassel-0.13.1/debian/usr.bin.quasselcore 
quassel-0.13.1/debian/usr.bin.quasselcore
--- quassel-0.13.1/debian/usr.bin.quasselcore   2019-01-05 15:18:52.0 
-0500
+++ quassel-0.13.1/debian/usr.bin.quasselcore   2020-01-10 21:02:22.0 
-0500
@@ -13,7 +13,7 @@
   #include 
 
   /var/lib/quassel/ rw,
-  /var/lib/quassel/** rwk,
+  /var/lib/quassel/** rwkl,
 
   /var/log/quassel/* rw,
 
@@ -22,6 +22,13 @@
   /etc/ssl/openssl.cnf r,
   /usr/lib/ssl/openssl.cnf r,
 
+  # QSysInfo::machineUniqueId()
+  /var/lib/dbus/machine-id r,
+  /etc/machine-id r,
+
+  # QSysInfo::bootUniqueId()
+  @{PROC}/sys/kernel/random/boot_id r,
+
   # Site-specific additions and overrides. See local/README for details.
   #include 
 }

Bug#949119: tesseract: incorrectly removed autoconf-archive from Build-Depends

[Paul Wise]

Source: tesseract
Version: 4.1.1-1
Severity: important

tesseract still uses parts of autoconf-archive, so it should remain in
Build-Depends, please keep it in Build-Depends until it is not used.

tesseract-4.1.1/ $ find -iname 'ax_*'
./m4/ax_split_version.m4
./m4/ax_check_compile_flag.m4

tesseract-4.1.1/ $ grep AX_ configure.ac 
AX_SPLIT_VERSION
GENERIC_MAJOR_VERSION=$(echo "$AX_MAJOR_VERSION" | $SED 's/^[[^0-9]]*//')
GENERIC_MINOR_VERSION=$AX_MINOR_VERSION
GENERIC_MICRO_VERSION=`echo "$AX_POINT_VERSION" | $SED 
's/^\([[0-9]][[0-9]]*\).*/\1/'`
# The test code used by AX_CHECK_COMPILE_FLAG uses an empty statement
AX_CHECK_COMPILE_FLAG([-Werror=unused-command-line-argument], 
[WERROR=-Werror=unused-command-line-argument])
AX_CHECK_COMPILE_FLAG([-mavx], [avx=true], [avx=false], [$WERROR])
AX_CHECK_COMPILE_FLAG([-mavx2], [avx2=true], [avx2=false], [$WERROR])
AX_CHECK_COMPILE_FLAG([-mfma], [fma=true], [fma=false], [$WERROR])
AX_CHECK_COMPILE_FLAG([-msse4.1], [sse41=true], [sse41=false], [$WERROR])
AX_CHECK_COMPILE_FLAG([-march=native], [arch_native=true], [arch_native=false], 
[$WERROR])
AX_CHECK_COMPILE_FLAG([-std=c++11], [CPLUSPLUS=11], [], [$WERROR])
AX_CHECK_COMPILE_FLAG([-std=c++14], [CPLUSPLUS=14], [], [$WERROR])
AX_CHECK_COMPILE_FLAG([-std=c++17], [CPLUSPLUS=17], [], [$WERROR])
#AX_CHECK_COMPILE_FLAG([-std=c++20], [CPLUSPLUS=20], [], [$WERROR])

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#948404: glances crashes on startup

[Vasudev Kamath]

Hi Daniel,

Daniel Echeverry  writes:

> On Wed, Jan 08, 2020 at 11:25:05PM -0500, Daniel Echeverry wrote:
>> tags 948404 + moreinfo unreproducible
>> thanks
>> 
>> Hi!
>> 
>> Thanks for your report! Unfortunately I can't reproduce this bug, I install 
>> glances via ap-get install and works fine, However, I think that bug is 
>> related with this other bug[1], One Question, Do you have network interfaces?
>> 
>> Regards.
>> 
>> [1]: https://github.com/nicolargo/glances/issues/1535
>
> Hi!
>
> Excuse me, In the reply, I forgot to cc you, do you see the message? 

Yes I indeed have network interface

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: docker0:  mtu 1500 qdisc noqueue state 
DOWN mode DEFAULT group default 
link/ether 02:42:11:40:33:45 brd ff:ff:ff:ff:ff:ff
8: wlp3s0:  mtu 1500 qdisc pfifo_fast state UP 
mode DORMANT group default qlen 1000
link/ether 64:5a:ed:e8:cc:87 brd ff:ff:ff:ff:ff:ff


But now I can launch glances fine. I'm not sure what really changed. I
did a couple of update of system initially glances from pip was only
getting launched.

I think for now the bug can safely be closed. Thanks for maintaining
glances in Debian

Cheers,
Vasudev

Bug#939506: expected primary-expression before ‘{’ token (Was: Bug#939506: unanimity ftbfs in unstable)

[Matthew Fernandez]

> On Jan 15, 2020, at 02:13, Andreas Tille  wrote:
> 
> Hi again,
> 
> I forgot to mention that I bounced your mail to the bug log of #939506
> and I also CC this one to make sure there is some publicly visible
> record of the discussion.

Good idea for a future audience.

> On Wed, Jan 15, 2020 at 09:27:16AM +0100, Andreas Tille wrote:
>> Hi Matthew,
>> 
>> On Tue, Jan 14, 2020 at 07:00:02PM -0800, Matthew Fernandez wrote:
>>> 
>>> Offhand I don’t know the fix to the error message you quoted, but I just 
>>> tried to reproduce the build error on Debian 10.2. This repository has 
>>> multiple build systems in the root directory and no build instructions in 
>>> the README, so I guessed CMake. However, this doesn’t work:
>>> 
>>>$ mkdir build
>>>$ cd build
>>>$ cmake ..
>>>-- The CXX compiler identification is GNU 8.3.0
>>>-- The C compiler identification is GNU 8.3.0
>>>-- Performing Test HAS_NO_UNUSED_LOCAL_TYPEDEFS - Success
>>>-- Configuring incomplete, errors occurred!
>>>See also "/home/matthew/unanimity/build/CMakeFiles/CMakeOutput.log".
>>>See also "/home/matthew/unanimity/build/CMakeFiles/CMakeError.log”.
>>> 
>>> Unfortunately without further context I don’t know how to build this 
>>> program.
>> 
>> Ahhh, I assumed you would know how to build a Debian package from Git.
>> Well, here is some short introduction.  The best idea is to use
>> git-buildpackage.  If you have installed it you can do
>> 
>>   gbp clone https://salsa.debian.org/med-team/unanimity
>>   cd unanimity
>>   gbp buildpackage
>> 
>> This will call the build system that is used in Debian.  BTW, gbp needs
>> some configuration like:
>> 
>> ~> cat ~/.gbp.conf
>> [DEFAULT]
>> builder = ~/bin/git-pbuilder
>> 
>> # Might lead to problems because it tries to use non-patched makefiles
>> # cleaner = fakeroot debian/rules clean
>> cleaner = /bin/true
>> pristine-tar = True
>> export=WC
>> 
>> [buildpackage]
>> # use this for more svn-buildpackage like behaviour:
>> export-dir = ../build-area/
>> tarball-dir = ../tarballs/
>> pbuilder = True
>> pbuilder-options=--source-only-changes
>> 
>> 
>> The builder script can be used to control that the build is done using
>> cowbuilder which is a clean chroot system.  My bin/git-pbuilder has
>> basically this line:
>> 
>>  /usr/bin/pdebuild --pbuilder cowbuilder --buildresult `dirname \$PWD` 
>> --debbuildopts "-i\.git -I.git $*"
>> 
>> Before you can use cowbuilder you need to do
>> 
>>  sudo cowbuilder --create
>> 
>> 
>> Sorry for writing instructions bottom up - but I don't know what you
>> know about Debian package building.
>> 
>> Hope that you might find some time to reproduce any may be suggest a
>> patch.  If not you might have learned at least something about Debian
>> packaging. ;-)

Despite using git-buildpackage in my own packaging attempts, I am basically a 
GBP noob. All of the above was new information to me, so thank you for 
educating me :) Following your steps, I can now reproduce this error. I’ll try 
to  investigate but given the complexity of this build system and dependencies 
I would not hold my breath. If someone else reading can offer more help, please 
do.

Bug#948708: Further information

[Ralph Giles]

On Wed, 15 Jan 2020 19:02:47 + Nick Thomas  wrote:

> Attached is the output of bt from gdb with debug symbols loaded, and
> disassemble too. Looks like it's just going into NULL memory?

Illegal instruction in a smart pointer dereference sounds like basic
mis-compilation.

> Should this go upstream instead?

They might be able to assist, but it's probably a debian bug. The
upstream nightly build I tried worked fine. E.g. 
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XFUMm2ySQ4yPTDTxRr55bw/runs/0/artifacts/public/build/target.tar.bz2
linked from https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr68

Note this is the next point release (68.5.0) so it's possible something
was fixed upstream after 68.4.1.

 -r

Bug#949118: RM: goopg -- ROM; RC-Buggy, Python 2 only, Dead upstream

[David Steele]

Package: ftp.debian.org
Severity: normal
Control: affects -1 goopg
thanks

Please remove "goopg" from "unstable".

The goopg package is currently non-functional, as documented in two RC
bugs. It requires Python 2, with no indication that a Python 3 version
will become available.

Goopg is a Chromium Native Messaging Host utility for GMail. It allows
one to verify and sign emails in GMail web page, using GnuPG. The Chrome
'goopg' Extension is also required.

Goopg has no reverse dependencies.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=no=pending-fixed=fixed=done=critical=grave=serious=no=goopg

Upstream
https://github.com/LeoIannacone/goopg/issues/34
https://github.com/LeoIannacone/goopg/issues/33

David Steele



signature.asc
Description: OpenPGP digital signature

Bug#938797: volatility: Python2 removal in sid/bullseye

[Sandro Tosi]

On Sat, 19 Oct 2019 11:56:21 -0300 Eriberto  wrote:
> Em sábado, 19 de outubro de 2019, Raphael Hertzog 
> escreveu:
>
> > Control: tag -1 + fixed-upstream
> >
> > On Fri, 30 Aug 2019, Matthias Klose wrote:
> > > Python2 becomes end-of-live upstream, and Debian aims to remove
> > > Python2 from the distribution, as discussed in
> > > https://lists.debian.org/debian-python/2019/07/msg00080.html
> >
> > There's a volatility 3.0 that works with Python 3:
> > https://github.com/volatilityfoundation/volatility3
> >
> > We should package it! Putting in CC the uploaders of volatility.
> >
> >
> Don't worry. I will update it soon.

any update here?

Bug#944988: Change to intented package name

[Keyikedalube Ndang]

Package: libmng1
Version: 1.0.10+dfsg-3.1+b5

Hello Debian maintainers,

Seems I reported this bug against the wrong package. There is a libmng2 package 
in experimental with the fix applied. Here's the 
[link](https://metadata.ftp-master.debian.org/changelogs//main/libm/libmng/libmng_2.0.3+dfsg-3_changelog)
 and a quoted changelog:

libmng (2.0.3+dfsg-3) experimental; urgency=low

  * debian/libmng-dev.install:
+ Install pkgconfig file.
  * debian/rules:
+ Synced from Ubuntu. Thanks!
+ Fixed clean target.
+ Use dh-autoreconf and fix dpkg-buildflags usage.
+ Fixed installation of pkgconfig.
+ Removed -V from dh_makeshlibs, debian/shlibs overrides it.
  * Update debian/shlibs file.

 -- Kartik Mistry <
kar...@debian.org
>  Fri, 23 Nov 2018 22:12:39 +0530

Can that fix be applied on libmng1? Or is it better to pull libmng2 from 
experimental?

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Bernhard R. Link:
> * Ximin Luo  [191223 12:58]:
>> dpkg and all other debian tools support it right now. It is only reprepro 
>> with this artifical constraint, which makes it not work for packages that 
>> are processable by dpkg and other debian tools.
> 
> If it is artifical, then it is artifically high. It is 128 times more than
> what almost every single package needs and more than five times what the most
> absurd package before needed and twice what other tools are said to have
> had as limit there. I will increase it in reprepro (and maybe might make it
> configurable to some extent), but there will always be an upper limit.
> 

OK, as long as it doesn't stop people from pulling in the normal Debian archive.

The package in question had another RC bug filed against it (uninstallable 
B-D); in the process of updating it, the Provides entry is now again 277988 
bytes big.

Therefore I've source-only uploaded an NMU of reprepro to DELAYED/5 with the 
limit set to 4MB. It builds fine, so anyone who needs it urgently can apply the 
debdiff attached themselves.

>> Are you suggesting that dpkg and other tools have a concrete security 
>> problem?
> 
> dpkg does not check checksums of index files, so it is likely
> uneffected. If apt has no limit then that likely makes some attacks
> needlessly easy (though it might have other mitigations in that regard,
> and there are less things apt has to care about the way it is typically
> used).
> Accepting absurd input without confirmation is never a secure way to handle
> things, though.
> 

I don't see any similar limits on the size of .deb files (or lists files, or 
whatever), so the limit on the Provides: field *inside* a .deb file seems 
out-of-place. Also "dput" into a reprepro repository with this size of a 
Provides file works totally fine, it seems the limit is only hit when pulling 
from another mirror.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
diff -Nru reprepro-5.3.0/debian/changelog reprepro-5.3.0/debian/changelog
--- reprepro-5.3.0/debian/changelog	2019-02-02 22:20:17.0 +
+++ reprepro-5.3.0/debian/changelog	2020-01-17 02:03:27.0 +
@@ -1,3 +1,11 @@
+reprepro (5.3.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump up the maxsize on a fixed-size C buffer to avoid breaking on some
+autogenerated rust packages. (Closes: #942487)
+
+ -- Ximin Luo   Fri, 17 Jan 2020 02:03:27 +
+
 reprepro (5.3.0-1) unstable; urgency=medium
 
   * new release
diff -Nru reprepro-5.3.0/debian/patches/bump-buffer-size reprepro-5.3.0/debian/patches/bump-buffer-size
--- reprepro-5.3.0/debian/patches/bump-buffer-size	1970-01-01 01:00:00.0 +0100
+++ reprepro-5.3.0/debian/patches/bump-buffer-size	2020-01-17 01:58:23.0 +
@@ -0,0 +1,15 @@
+Description: Bump up the maxsize on a fixed-size C buffer to avoid breaking on some autogenerated rust packages. (Closes: #942487)
+Author: Ximin Luo 
+Bug-Debian: https://bugs.debian.org/942487
+
+--- reprepro-5.3.0.orig/indexfile.c
 reprepro-5.3.0/indexfile.c
+@@ -63,7 +63,7 @@ retvalue indexfile_open(struct indexfile
+ 	f->linenumber = 0;
+ 	f->startlinenumber = 0;
+ 	f->status = RET_OK;
+-	f->size = 256*1024;
++	f->size = 4*1024*1024;
+ 	f->ofs = 0;
+ 	f->content = 0;
+ 	/* +1 for *d = '\0' in eof case */
diff -Nru reprepro-5.3.0/debian/patches/series reprepro-5.3.0/debian/patches/series
--- reprepro-5.3.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ reprepro-5.3.0/debian/patches/series	2020-01-17 01:57:30.0 +
@@ -0,0 +1 @@
+bump-buffer-size

Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language

[Matthew Fernandez]

> On Jan 15, 2020, at 10:33, Adam Borowski  wrote:
> 
> On Tue, Jan 14, 2020 at 08:07:05PM -0800, Matthew Fernandez wrote:
>> OK, uploaded a new version with this fix. Please let me know if you have a 
>> chance to take another look.
> 
> Alas, still fails:
> 
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/librumur.a(parser.yy.cc.o):
>  in function `rumur::VarDecl::~VarDecl()':
> (.text._ZN5rumur7VarDeclD0Ev[_ZN5rumur7VarDeclD5Ev]+0x14): undefined 
> reference to `__gmpz_clear'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/librumur.a(parser.yy.cc.o):
>  in function `void 
> rumur::parser::semantic_type::move, 
> std::allocator > > 
> >(rumur::parser::semantic_type&&)':
> (.text._ZN5rumur6parser13semantic_type4moveISt6vectorINS_3PtrINS_7VarDeclEEESaIS6_vOS1_[_ZN5rumur6parser13semantic_type4moveISt6vectorINS_3PtrINS_7VarDeclEEESaIS6_vOS1_]+0x89):
>  undefined reference to `__gmpz_clear'
> [...]
> /usr/bin/ld: (.text+0xf2e): undefined reference to `__gmpz_add'
> /usr/bin/ld: (.text+0xf36): undefined reference to `__gmpz_clear'
> /usr/bin/ld: (.text+0xf3e): undefined reference to `__gmpz_clear'
> 
> 
> Full log at http://ix.io/27tY 
The riddle continues. I think this is a link order problem. I managed to 
reproduce something like this error and then subsequently fixed it by 
reordering the libraries. I’ve uploaded a new version with this fix. Can I beg 
you to take yet another look at the latest upload?

Bug#949117: fribidi 1.0.8 causes regression in pyfribidi

[Laurent Bigonville]

Package: fribidi
Version: 1.0.8-2
Severity: important

Hi,

It seems that fribidi 1.0.8 is causing regression in pyfribidi

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyfribidi/4000410/log.gz

I tried with the version currently in testing (1.0.7-1.1) and the test
succeed

Can you have a look? It's blocking pango migration to testing

Kind regards,

Laurent Bigonville

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

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

Bug#949116: xfce4-screenshooter without delay

[Joachim Wiedorn]

Package: xfce4-screenshooter
Version: 1.9.3-1
Severity: important

Hello Maintainer,

if you set a delay in this xfce4 plugin, it doesn't work. But the
delay comes with "Select a region" which is useless.

I have found this bugreport by upstream:
https://bugzilla.xfce.org/show_bug.cgi?id=14604

and the bugfix:
https://git.xfce.org/apps/xfce4-screenshooter/commit/?id=4476a87b84b2e3ef6896dee273619f56389776fd

Please patch the stable version to make this nice plugin usefull again.
Thanks!

---
Have a nice day.
Joachim (Germany)


pgpG3ExiDXNJ0.pgp
Description: Digitale Signatur von OpenPGP

Bug#949111: Correction

[Teran McKinney]

Correction: When I said -soundhw ac97 worked fine on Debian Stretch,
I meant to write that -soundhw hda worked fine in Debian Stretch.

Bug#949115: alsa-tools: example Makefile contains different paths when built on usrmerge system

[Vagrant Cascadian]

Source: alsa-tools
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge environment
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

./usr/share/doc/ld10k1/examples/emu10k1MIDIEffects/Makefile.gz contains
several variables which get a different value depending on if the system
has a merged /usr, where /bin and /sbin are symlinks to /usr/bin and
/usr/sbin respectively:

  EGREP·​=·​/​bin/​grep·​-​E

vs.

  EGREP·​=·​/​usr/​bin/​grep·​-​E

The attached patch sets several of these values in the ./configure phase
to use the /bin/ directory, as this works both on merged /usr and
unmerged /usr systems.

Alternately, consider removing this mentioned Makefile entirely, as it
make not actually be functional without considerable changes anyways.


live well,
  vagrant

From 961d29c0b88c2ea82d70db526d8bdd33dadc2cb4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 12 Jan 2020 21:54:59 -0800
Subject: [PATCH 1/2] debian/rules: set GREP, MKDIR_P, SED and SHELL from
 ./configure, to prevent variations when built on a system with merged /usr.

---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index e6922fb..5288edf 100755
--- a/debian/rules
+++ b/debian/rules
@@ -50,6 +50,10 @@ config-stamp:
 	--datadir=\$${prefix}/share \
 	--cache-file=$(CURDIR)/config.cache \
 	$(shell dpkg-buildflags --export=configure) \
+	GREP=/bin/grep \
+	MKDIR_P="/bin/mkdir -p" \
+	SED=/bin/sed \
+	SHELL=/bin/bash \
 	  ); \
 	done
 
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#949114: alsa-tools: Embeds build path in example Makefile

[Vagrant Cascadian]

Source: alsa-tools
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

A makefile shipped in the examples directory contains build path
variations for several values:

  usr/share/doc/ld10k1/examples/emu10k1MIDIEffects/Makefile.gz


AUTOCONF·​=·​${SHELL}·​/​build/​1st/​alsa-​tools-​1.​1.​7/​ld10k1/​missing·​-​-​run·​autoconf

This makes the build unreproducible when built from a different path,
but the Makefile itself would require some manual configuration anyways,
since the end-user most likely does not contain the original build path
on their system.

I'd suggest simply removing the Makefile, as it's not functional, or
alternately, sanitizing it with the attached patch to debian/rules.

live well,
  vagrant

From 19189abec0b54705d8205650e2ed918c7a9a3fd2 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 16 Jan 2020 15:38:44 -0800
Subject: [PATCH 2/2] debian/rules: Strip instances of build path out of
 example Makefile.

---
 debian/rules | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/rules b/debian/rules
index 5288edf..9463186 100755
--- a/debian/rules
+++ b/debian/rules
@@ -130,6 +130,13 @@ binary-common:
 	dh_installdocs --exclude=Makefile
 	dh_installexamples --exclude=.cvsignore --exclude=Makefile.am --exclude=Makefile.in
 	chmod 644 $(CURDIR)/debian/ld10k1/usr/share/doc/ld10k1/examples/emu10k1MIDIEffects/pontodo5
+	# Clean up embedded build paths in order to ensure reproducible builds.
+	sed -i -e "s,-fdebug-prefix-map=$(CURDIR)=\.,,g" \
+		-e "s,-ffile-prefix-map=$(CURDIR)=\.,,g" \
+		-e "s,abs_.*$(CURDIR).*,,g" \
+		-e "s,$(CURDIR).*missing --run,,g" \
+		-e "s,$(CURDIR),./,g" \
+		$(CURDIR)/debian/ld10k1/usr/share/doc/ld10k1/examples/emu10k1MIDIEffects/Makefile
 	dh_install --list-missing
 	(cd debian/ld10k1/usr/bin && mv -f lo10k1 lo10k1.bin && mv -f lo10k1.sh lo10k1)
 	dh_installmenu
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#949089: libxmlrpc3-java: CVE-2019-17570: deserialization of server-side exception from faultCause in XMLRPC error response

[Markus Koschany]

Hi,

Am 16.01.20 um 21:27 schrieb Salvatore Bonaccorso:
> Source: libxmlrpc3-java
> Version: 3.1.3-9
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> 
> Hi,
> 
> The following vulnerability was published for libxmlrpc3-java.
> 
> CVE-2019-17570[0]:
> | Deserialization of server-side exception from faultCause in XMLRPC
> | error response
> 
> That said, should libxmlrpc3-java rather be removed from unstable, and
> not included in bullseye?

[...]

It looks like starjava-topcat is the only package that build-depends on
libxmlrpc3-java at the moment (need to check that again). I think the
issue itself can be fixed by the proposed Red Hat patch, making the use
of some parts of the vulnerable method conditional on a set property.
Since Apache xml-rpc is EOL it makes sense to remove it from Debian
though. I will file a bug report for starjava-topcat and then let's see
how it goes.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#949113: buster-pu: package xtrlock/2.8+deb10u1

[Chris Lamb]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: t...@security.debian.org

Dear stable release managers,

Please consider xtrlock (2.8+deb10u1) for buster:
  
  xtrlock (2.8+deb10u1) buster; urgency=high
  
* CVE-2016-10894: Attempt to grab multitouch devices which are not
  intercepted via XGrabPointer.
  
  xtrlock did not block multitouch events so an attacker could still input
  and thus control various programs such as Chromium, etc. via so-called
  "multitouch" events such as pan scrolling, "pinch and zoom", or even being
  able to provide regular mouse clicks by depressing the touchpad once and
  then clicking with a secondary finger.
  
  This fix does not the situation where Eve plugs in a multitouch device
  *after* the screen has been locked. For more information on this angle,
  please see . (Closes: #830726)

The full diff is attached. In addition, this update has been filed at
the behest of the security team after marking this CVE as no-dsa.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/changelog b/debian/changelog
index 91ebaab..ad44f3b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+xtrlock (2.8+deb10u1) buster; urgency=high
+
+  * CVE-2016-10894: Attempt to grab multitouch devices which are not
+intercepted via XGrabPointer.
+
+xtrlock did not block multitouch events so an attacker could still input
+and thus control various programs such as Chromium, etc. via so-called
+"multitouch" events such as pan scrolling, "pinch and zoom", or even being
+able to provide regular mouse clicks by depressing the touchpad once and
+then clicking with a secondary finger.
+
+This fix does not the situation where Eve plugs in a multitouch device
+*after* the screen has been locked. For more information on this angle,
+please see . (Closes: #830726)
+
+ -- Chris Lamb   Thu, 16 Jan 2020 16:00:52 +
+
 xtrlock (2.8) unstable; urgency=low
 
   * patch from Simon Tatham to add a -f option [fork, and return success
diff --git a/Imakefile b/Imakefile
index 68605d8..c792294 100644
--- a/Imakefile
+++ b/Imakefile
@@ -12,6 +12,6 @@
 #! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 #! GNU General Public License for more details.
 
-SingleProgramTarget(xtrlock,xtrlock.o,-lcrypt -lX11,)
+SingleProgramTarget(xtrlock,xtrlock.o,-lcrypt -lX11 -lXi,)
 InstallProgram(xtrlock,$(BINDIR))
 InstallManPage(xtrlock,$(MANDIR))
diff --git a/debian/control b/debian/control
index c01554d..359d7a0 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: xtrlock
 Maintainer: Matthew Vernon 
 Section: x11
 Priority: optional
-Build-Depends: libx11-dev, x11proto-core-dev, xutils-dev, dpkg-dev (>= 1.16.1~)
+Build-Depends: libx11-dev, x11proto-core-dev, xutils-dev, dpkg-dev (>= 
1.16.1~), libxi-dev
 Standards-Version: 3.9.1
 
 Package: xtrlock
diff --git a/debian/rules b/debian/rules
index 91b1572..55e8b4e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,7 +11,7 @@ DPKG_EXPORT_BUILDFLAGS = 1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 include /usr/share/dpkg/buildflags.mk
 
-CFLAGS+=-DSHADOW_PWD
+CFLAGS+=-DSHADOW_PWD -DMULTITOUCH
 
 build:
$(checkdir)
diff --git a/xtrlock.c b/xtrlock.c
index 6117c6f..a08fe4e 100644
--- a/xtrlock.c
+++ b/xtrlock.c
@@ -41,6 +41,11 @@
 #include 
 #endif
 
+#ifdef MULTITOUCH
+#include 
+#include 
+#endif
+
 #include "lock.bitmap"
 #include "mask.bitmap"
 #include "patchlevel.h"
@@ -71,6 +76,34 @@ int passwordok(const char *s) {
 #endif
 }
 
+#if MULTITOUCH
+XIEventMask evmask;
+
+/* (Optimistically) attempt to grab multitouch devices which are not
+ * intercepted via XGrabPointer. */
+void handle_multitouch(Cursor cursor) {
+  XIDeviceInfo *info;
+  int xi_ndevices;
+
+  info = XIQueryDevice(display, XIAllDevices, _ndevices);
+
+  int i;
+  for (i = 0; i < xi_ndevices; i++) {
+XIDeviceInfo *dev = [i];
+
+int j;
+for (j = 0; j < dev->num_classes; j++) {
+  if (dev->classes[j]->type == XITouchClass &&
+  dev->use == XISlavePointer) {
+XIGrabDevice(display, dev->deviceid, window, CurrentTime, cursor,
+ GrabModeAsync, GrabModeAsync, False, );
+  }
+}
+  }
+  XIFreeDeviceInfo(info);
+}
+#endif
+
 int main(int argc, char **argv){
   XEvent ev;
   KeySym ks;
@@ -132,7 +165,32 @@ int main(int argc, char **argv){
program_version);
 exit(1);
   }
+
+#ifdef MULTITOUCH
+  unsigned char mask[XIMaskLen(XI_LASTEVENT)];
+  int xi_major = 2, xi_minor = 2, xi_opcode, xi_error, xi_event;
+
+  if (!XQueryExtension(display, INAME, _opcode, _event, _error)) {
+fprintf(stderr, "xtrlock (version %s): No X Input extension\n",
+program_version);
+

Bug#949095: calibredb broken in python3 version

[Norbert Preining]

tags 949095 + pending
thanks

On Fri, 17 Jan 2020, Norbert Preining wrote:
> -% (nb_entries, nowf().strftime("%A, %d. %B %Y 
> %H:%M").decode(preferred_encoding)))
> +% (nb_entries, nowf().strftime("%A, %d. %B %Y %H:%M")))

Upstream is informed, Debian git repo updated so that the next upload
contains the fix. Tag as pending.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#949112: stretch-pu: package xtrlock/2.8+deb9u1

[Chris Lamb]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: t...@security.debian.org

Dear oldstable release managers,

Please consider xtrlock (2.8+deb9u1) for stretch:
  
  xtrlock (2.8+deb9u1) stretch; urgency=high
  
* CVE-2016-10894: Attempt to grab multitouch devices which are not
  intercepted via XGrabPointer.
  
  xtrlock did not block multitouch events so an attacker could still input
  and thus control various programs such as Chromium, etc. via so-called
  "multitouch" events such as pan scrolling, "pinch and zoom", or even being
  able to provide regular mouse clicks by depressing the touchpad once and
  then clicking with a secondary finger.
  
  This fix does not the situation where Eve plugs in a multitouch device
  *after* the screen has been locked. For more information on this angle,
  please see . (Closes: #830726)

The full diff is attached. In addition, this update has been filed at
the behest of the security team after marking this CVE as no-dsa.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/changelog b/debian/changelog
index 91ebaab..df64472 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+xtrlock (2.8+deb9u1) stretch; urgency=high
+
+  * CVE-2016-10894: Attempt to grab multitouch devices which are not
+intercepted via XGrabPointer.
+
+xtrlock did not block multitouch events so an attacker could still input
+and thus control various programs such as Chromium, etc. via so-called
+"multitouch" events such as pan scrolling, "pinch and zoom", or even being
+able to provide regular mouse clicks by depressing the touchpad once and
+then clicking with a secondary finger.
+
+This fix does not the situation where Eve plugs in a multitouch device
+*after* the screen has been locked. For more information on this angle,
+please see . (Closes: #830726)
+
+ -- Chris Lamb   Thu, 16 Jan 2020 16:00:52 +
+
 xtrlock (2.8) unstable; urgency=low
 
   * patch from Simon Tatham to add a -f option [fork, and return success
diff --git a/Imakefile b/Imakefile
index 68605d8..c792294 100644
--- a/Imakefile
+++ b/Imakefile
@@ -12,6 +12,6 @@
 #! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 #! GNU General Public License for more details.
 
-SingleProgramTarget(xtrlock,xtrlock.o,-lcrypt -lX11,)
+SingleProgramTarget(xtrlock,xtrlock.o,-lcrypt -lX11 -lXi,)
 InstallProgram(xtrlock,$(BINDIR))
 InstallManPage(xtrlock,$(MANDIR))
diff --git a/debian/control b/debian/control
index c01554d..359d7a0 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: xtrlock
 Maintainer: Matthew Vernon 
 Section: x11
 Priority: optional
-Build-Depends: libx11-dev, x11proto-core-dev, xutils-dev, dpkg-dev (>= 1.16.1~)
+Build-Depends: libx11-dev, x11proto-core-dev, xutils-dev, dpkg-dev (>= 
1.16.1~), libxi-dev
 Standards-Version: 3.9.1
 
 Package: xtrlock
diff --git a/debian/rules b/debian/rules
index 91b1572..55e8b4e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,7 +11,7 @@ DPKG_EXPORT_BUILDFLAGS = 1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 include /usr/share/dpkg/buildflags.mk
 
-CFLAGS+=-DSHADOW_PWD
+CFLAGS+=-DSHADOW_PWD -DMULTITOUCH
 
 build:
$(checkdir)
diff --git a/xtrlock.c b/xtrlock.c
index 6117c6f..a08fe4e 100644
--- a/xtrlock.c
+++ b/xtrlock.c
@@ -41,6 +41,11 @@
 #include 
 #endif
 
+#ifdef MULTITOUCH
+#include 
+#include 
+#endif
+
 #include "lock.bitmap"
 #include "mask.bitmap"
 #include "patchlevel.h"
@@ -71,6 +76,34 @@ int passwordok(const char *s) {
 #endif
 }
 
+#if MULTITOUCH
+XIEventMask evmask;
+
+/* (Optimistically) attempt to grab multitouch devices which are not
+ * intercepted via XGrabPointer. */
+void handle_multitouch(Cursor cursor) {
+  XIDeviceInfo *info;
+  int xi_ndevices;
+
+  info = XIQueryDevice(display, XIAllDevices, _ndevices);
+
+  int i;
+  for (i = 0; i < xi_ndevices; i++) {
+XIDeviceInfo *dev = [i];
+
+int j;
+for (j = 0; j < dev->num_classes; j++) {
+  if (dev->classes[j]->type == XITouchClass &&
+  dev->use == XISlavePointer) {
+XIGrabDevice(display, dev->deviceid, window, CurrentTime, cursor,
+ GrabModeAsync, GrabModeAsync, False, );
+  }
+}
+  }
+  XIFreeDeviceInfo(info);
+}
+#endif
+
 int main(int argc, char **argv){
   XEvent ev;
   KeySym ks;
@@ -132,7 +165,32 @@ int main(int argc, char **argv){
program_version);
 exit(1);
   }
+
+#ifdef MULTITOUCH
+  unsigned char mask[XIMaskLen(XI_LASTEVENT)];
+  int xi_major = 2, xi_minor = 2, xi_opcode, xi_error, xi_event;
+
+  if (!XQueryExtension(display, INAME, _opcode, _event, _error)) {
+fprintf(stderr, "xtrlock (version %s): No X Input extension\n",
+program_version);
+

Bug#949111: qemu-system-x86: Qemu soundhw hda is broken

[Teran McKinney]

Package: qemu-system-x86
Version: 1:3.1+dfsg-8+deb10u3
Severity: normal

Dear Maintainer,

In Debian Buster qemu's -soundhw hda feature is broken. From a guest if you
try to play audio it you may hear small bits of it. If you play something
with mpv, you will get Alsa XRUN errors. -soundhw ac97 works fine.

Guests tested: Debian Buster, Ubuntu 18.04.

I previously used this with Debian Stretch and had no issues with -soundhw
ac97.

Thank you,

Teran

Bug#906706: nifti2dicom: diff for NMU version 0.4.11-1.1

[Adrian Bunk]

Control: tags 906706 + patch
Control: tags 906706 + pending

Dear maintainer,

I've prepared an NMU for nifti2dicom (versioned as 0.4.11-1.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru nifti2dicom-0.4.11/debian/changelog nifti2dicom-0.4.11/debian/changelog
--- nifti2dicom-0.4.11/debian/changelog	2016-03-02 18:28:36.0 +0200
+++ nifti2dicom-0.4.11/debian/changelog	2020-01-17 01:27:58.0 +0200
@@ -1,3 +1,11 @@
+nifti2dicom (0.4.11-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Uncontitionally build depend on libinsighttoolkit,
+the package does not build without it. (Closes: #906706)
+
+ -- Adrian Bunk   Fri, 17 Jan 2020 01:27:58 +0200
+
 nifti2dicom (0.4.11-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru nifti2dicom-0.4.11/debian/control nifti2dicom-0.4.11/debian/control
--- nifti2dicom-0.4.11/debian/control	2016-03-02 18:23:40.0 +0200
+++ nifti2dicom-0.4.11/debian/control	2020-01-17 01:27:58.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Daniele E. Domenichelli 
 Build-Depends: debhelper (>= 7.3.16),
  cdbs, cmake (>= 2.6.4), qtbase5-dev | libqt4-dev (>= 4.4),
- libinsighttoolkit4-dev (>= 4.3.0) [i386 amd64] | libinsighttoolkit3-dev,
+ libinsighttoolkit4-dev (>= 4.3.0) | libinsighttoolkit3-dev,
  libfftw3-dev,
  libtclap-dev (>= 1.2.0),
  libvtk6-qt-dev | libvtk6-dev (<< 6.2) | libvtk5-qt4-dev

Bug#949024: g++: internal compiler error on beignet

[Matthias Klose]

Control: tags -1 + moreinfo

On 16.01.20 23:34, Rebecca N. Palmer wrote:
> Control: retitle -1 g++: ICE at cp/pt.c:15779 on beignet in -std=gnu++14 or 
> higher
> 
> This also happens with LLVM 9 (which makes sense given that the error message
> points to code in beignet itself):
> 
>   LLVM 9    LLVM 10
> -std=c++0x   success    std::index_sequence fail
> -std=c++11   success    std::index_sequence fail
> none (gnu++14)  ICE ICE
> -std=c++17  not tested  ICE
> none, gcc-snapshot  ICE   not tested
> 
> ("std::index_sequence fail" above means
> /usr/lib/llvm-10/include/llvm/ADT/STLExtras.h:559:49: error:
> 'std::index_sequence' has not been declared
> I suspect this is "LLVM 10 needs at least c++14" and not a bug, but as it
> happens first, I don't know whether those combinations would have the ICE.)
> 
> It probably *isn't* the upstream GCC bug I mentioned above, as the line number
> doesn't match: in Debian gcc 9, upstream bugs 91467 and 92583 are both
> cp/pt.c:15538, 92625 is cp/pt.c:16142, and 92948 is cp/pt.c:15774.
> 
> gcc-snapshot also has this bug (at cp/pt.c:16332).

please use creduce to produce a test case and forward it upstream.

Bug#948634: Bug#948648: Bug#948634: debian-security-support: please elaborate on binutils' status

[Matthias Klose]

On 11.01.20 21:32, Daniel Shahaf wrote:
> Good morning Salvatore,
> 
> Salvatore Bonaccorso wrote on Sat, Jan 11, 2020 at 09:07:30 +0100:
>> Control: clone 948634 -1
>> Control: reassign -1 src:binutils
>> Control: retitle -1 binutils: Please add a README.Debian.security 
>> documenting security support for binutils
>> Control: blocked 948634 with -1
>>
>> On Sat, Jan 11, 2020 at 02:28:14AM +, Daniel Shahaf wrote:
>>> +++ b/security-support-limited
>>> @@ -7,7 +7,7 @@
>>> -binutilsNot covered by security support
>>> +binutilsOnly suitable for trusted content; see 
>>> https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
>>>  ganglia See README.Debian.security, only supported behind an 
>>> authenticated HTTP zone, #702775
>>>  ganglia-web See README.Debian.security, only supported behind an 
>>> authenticated HTTP zone, #702776
>>>  glpiOnly supported behind an authenticated HTTP zone for 
>>> trusted users
>>>
>>> @Florian That linked message is yours; any objections from you?
>>
>> yes we can add that, but OTOH we asked the binutils maintainer already
>> when we decided to mark it as unsupported, to please add a
>> README.Debian.security file shipped in the package with a explanation,
>> similar to the above, that there is none covering binutils by security
>> updates (including upstream!). That would then be a slightly better
>> reference to add, so I would rather go with that.
> 
> Yes, this make sense: binutils would document its own support status and
> security-support-limited would simply point to README.Debian.security, as
> it does for some other packages.
> 
>> The README.Debian.security file could contain something along the
>> following lines:
>>
>>> binutils (the tools the included libraries like libbfd) are not
>>> covered by security support, i.e. bugfixes are not backported to
>>> stable releases and will only land in the next release.
>>
>> Matthias, could you add this?
> 
> I suggest to state not only the negative promise ("no security support") but
> also the positive one (e.g., "Only suitable for use on trusted content").
> 
> Nitpicking: Suggest to change "next release" either to "next release 
> (bullseye)"
> or to "next point release" to clarify the intended meaning.
> 
> Thanks for the quick answer,

I won't add such a file.

Most issues are about the stack unwinder.  So you should file same requests for
any package using libiberty.

the unwinder changed a lot. Does this still apply to the current unstable 
package?

Matthias

Bug#949109: wmnd: glibc 2.30 drops support for stropts.h, used by solaris_fpppd driver

[Rafael David Tinoco]

Package: wmnd
Version: 0.4.17-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules: remove solaris_fpppd driver since it uses stropts.h which is
gone with glibc 2.30 (LP: #1860018)

Thanks for considering the patch.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE9/EO4QjRa7yS94ISqT4OCtg8DQ8FAl4g8KUACgkQqT4OCtg8
DQ+DIg/+Lli+I2MOfbLLepjXtSMx90omN6rHiybAzahyLSFCOhCod99K/aw5yLyv
+W/oVHQFYVxhCLkMd5q/6poChnMPj4t2Tmbgg/nZ3ErNwnM48XRdTXerK7mL0Z9r
D58MaFDPB9lztMnoxAOVRLKwH7f2J4PFO4VUaMkO60TGbKDX/F7nk6GqS6fRX7Rq
Xr13EKM0AHLy1uQQu40GqXccLiQqr4LewzkDVsuVqaYcCFyRKIXbPFPEhyE3bQke
mIoAdVHdlavgARRENYiL6VqFHm0EnKeDWBAb8ordBocKSxWuTJPrI+o4ZcwbIB2x
ecqsycnFpaWcMxgOS3E4itf1uGE+JOslfON+8qj7g0eqQcb6qxazAPcmosXkRFRG
4Wjoq20rn1cXUx4egM04quEw7EaCP3YBD2y6ced91Lf5jgk8LY7h61hO3/6hdJgF
YHHq/MrqaygmO9RJOlupEUqwxYUAncOqCZA671RAghpZ53cM7cdU2/9dWtE46J5l
0QJxkYdOT1UGIswZjAi5Vgw7vuo9ERU6fHnG9b1Dvs57dl/l/3FJxjdB8bPCBtWS
HsG81rCV2L2kwI5Bi7uihIaL4wwKSdRfaQrRglLHzpC3SAi83EZTmzHwgnTmVJrD
grgqN/9Ym5XWaPj1mFfFR2tlpYLZxcTO3go3bFmhUxyLTE+RsTQ=
=By4d
-END PGP SIGNATURE-
diff -Nru wmnd-0.4.17/debian/rules wmnd-0.4.17/debian/rules
--- wmnd-0.4.17/debian/rules2018-09-09 10:08:13.0 +
+++ wmnd-0.4.17/debian/rules2020-01-16 21:00:48.0 +
@@ -31,12 +31,12 @@
$(call dh_auto_command,$@,$(pwmnd), 
   \
 -- $(CONFFLAGS)
   \
 --docdir="\$${prefix}/share/doc/$(pwmnd)"  
   \
---enable-drivers="linux_proc solaris_fpppd"
   )
-   
+--enable-drivers="linux_proc"  
   )
+
$(call dh_auto_command,$@,$(pwmnd_snmp),
   \
 -- $(CONFFLAGS)
   \
 --docdir="\$${prefix}/share/doc/$(pwmnd_snmp)" 
   \
---enable-drivers="linux_proc solaris_fpppd 
generic_snmp"  \
+--enable-drivers="linux_proc generic_snmp" 
   \
 LIBS="$(LIBS) -lsnmp"  
   )
 
 

Bug#949108: rake: Please depend on ruby:any, not ruby

[Steve Langasek]

Package: rake
Version: 12.3.3-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

rake declares itself to be Architecture: all, Multi-Arch: foreign, to allow
it to satisfy dependencies of packages from foreign architectures.  However,
it then also depends on ruby without an architecture qualifier, which makes
it impossible to ever install a foreign-architecture ruby interpreter
because e.g.  ruby:i386 Depends: ruby2.5:i386 Depends: libruby2.5:i386
Depends: rake:all Depends: ruby:amd64, and while libruby2.5 is
co-installable between architectures, ruby obviously is not.

Cross-installing ruby is currently of interest to us in Ubuntu, because we
in the process of moving the i386 architecture to a compatibility-only layer
on amd64, and therefore we are also moving our autopkgtest infrastructure to
test i386 binaries in a cross-environment.  This change should allow ruby to
be cross-installable, and therefore cross-testable.  Would you consider
applying this change to the Debian package?

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru rake-12.3.3/debian/control rake-12.3.3/debian/control
--- rake-12.3.3/debian/control  2019-09-14 22:59:53.0 -0700
+++ rake-12.3.3/debian/control  2020-01-16 15:10:19.0 -0800
@@ -21,7 +21,7 @@
 Architecture: all
 XB-Ruby-Versions: ${ruby:Versions}
 Multi-Arch: foreign
-Depends: ruby | ruby-interpreter,
+Depends: ruby:any | ruby-interpreter,
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: zip

Bug#948008: Please consider packaging PMIx plugin

[Gennaro Oliva]

Hi Paul,

On Fri, Jan 03, 2020 at 10:39:04AM +0100, Paul Jähne wrote:
> please consider packaging the PMIx library with SLURM similar to #840404.
> See also: https://pmix.org/support/how-to/slurm-support/.

this will be available in version 19.05.5-1.

On Fri, Jan 03, 2020 at 09:49:48AM +, Alastair McKinstry wrote:
> Just to note: pmix is already packaged in Debian, but needs to be enabled.

Thanks for pointing this out Alastair.

Best regards,
-- 
Gennaro Oliva

Bug#948859: coccinelle: Package is uninstallable

[Benjamin Poirier]

On 2020/01/16 15:11 +0100, Stéphane Glondu wrote:
> Le 14/01/2020 à 02:26, Benjamin Poirier a écrit :
> > The coccinelle package has been uninstallable for many weeks in unstable:
> > 
> > root@f3:~# apt install coccinelle
> > [...]
> > The following packages have unmet dependencies:
> >  coccinelle : Depends: libpcre-ocaml-2h5n2 but it is not installable
> >   Depends: ocaml-base-nox-4.05.0 but it is not installable
> > E: Unable to correct problems, you have held broken packages.
> 
> This is known; the package currently FTBFS in unstable. I've fixed it in
> git, but wonder if it is worth an upload because of #885267, which I've
> not fixed. In its current state, the package will never migrate to
> testing because of #885267.

One step at a time? It would be useful to make the package usable in
unstable as a first step.

Have you brought up the pygtk issue with upstream?

Bug#949106: Porcupine: a "web browser" that copies URLs to your clipboard

[iandeb]

Package: wnpp

Severity: wishlist

Set porcupine as your default web browser. When you click a link, 
porcupine will copy the URL to your clipboard and notify you about this.
Or it can run a command of your choice. This way you'll never 
accidentally open a link you don't want to, and you can easily choose 
which browser to load it in.

Source: https://github.com/micahflee/porcupine

Bug#949107: RFP: Porcupine -- a "web browser" that copies URLs to your clipboard

[iandeb]

Package: wnpp

Severity: wishlist

Set porcupine as your default web browser. When you click a link, 
porcupine will copy the URL to your clipboard and notify you about this.
Or it can run a command of your choice. This way you'll never 
accidentally open a link you don't want to, and you can easily choose 
which browser to load it in.

Source: https://github.com/micahflee/porcupine

Bug#949105: ITP: golang-github-emersion-go-imap-idle -- IDLE extension for go-imap

[Ben Fiedler]

Package: wnpp
Severity: wishlist
Owner: Ben Fiedler 

* Package name: golang-github-emersion-go-imap-idle
  Version : 0.0~git20190519.2704abd-1
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/go-imap-idle
* License : Expat
  Programming Lang: Go
  Description : IDLE extension for golang-github-emersion-go-imap

 IDLE (RFC2177) extension for golang-github-emersion-go-imap.

This is a dependency of aerc [1] (ITP tracked here [2]). It further
depends on go-imap [3] (ITP [4]) being packaged first.

[1]: https://aerc-mail.org
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947962
[3]: https://github.com/emersion/go-imap
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949094

Bug#949089: libxmlrpc3-java: CVE-2019-17570: deserialization of server-side exception from faultCause in XMLRPC error response

[Markus Koschany]

Control: owner -1 !


More information and proposed patch at

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-17570



signature.asc
Description: OpenPGP digital signature

Bug#948976: python-argcomplete: diff for NMU version 1.8.1-1.3

[Sandro Tosi]

Dear maintainer,

I've prepared an NMU for python-argcomplete (versioned as 1.8.1-1.3). The diff
is attached to this message.

Regards.

diff -Nru python-argcomplete-1.8.1/debian/changelog python-argcomplete-1.8.1/debian/changelog
--- python-argcomplete-1.8.1/debian/changelog	2020-01-16 16:06:17.0 -0500
+++ python-argcomplete-1.8.1/debian/changelog	2020-01-16 17:49:36.0 -0500
@@ -1,3 +1,11 @@
+python-argcomplete (1.8.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Actually, use an unversioned Breaks+Replace on python-argcomplete;
+Closes: #948976
+
+ -- Sandro Tosi   Thu, 16 Jan 2020 17:49:36 -0500
+
 python-argcomplete (1.8.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-argcomplete-1.8.1/debian/control python-argcomplete-1.8.1/debian/control
--- python-argcomplete-1.8.1/debian/control	2020-01-16 16:05:55.0 -0500
+++ python-argcomplete-1.8.1/debian/control	2020-01-16 17:49:13.0 -0500
@@ -12,8 +12,8 @@
 Package: python3-argcomplete
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
-Breaks: python-argcomplete (<< 1.8.1-1)
-Replaces: python-argcomplete (<< 1.8.1-1)
+Breaks: python-argcomplete
+Replaces: python-argcomplete
 Description: bash tab completion for argparse (for Python 3)
  Argcomplete provides easy, extensible command line tab completion of
  arguments for your Python script.

Bug#895874: git-send-email does require Mail::Address

[Felipe Contreras]

The git-send-email.perl file does have use
Git::LoadCPAN::Mail::Address and since you do NO_PERL_CPAN_FALLBACKS
trying to use it throws the following error explaining that the system
is broken:

> BUG: The 'Mail::Address' module is not here, but NO_PERL_CPAN_FALLBACKS was 
> set!
>
> Git needs this Perl module from the CPAN, and will by default ship
> with a copy of it. This Git was built with NO_PERL_CPAN_FALLBACKS,
> meaning that whoever built it promised to provide this module.
>
> You're seeing this error because they broke that promise, and we can't
> load our fallback version, since we were asked not to install it.
>
> If you're seeing this error and didn't package Git yourself the
> package you're using is broken, or your system is broken. This error
> won't appear if Git is built without NO_PERL_CPAN_FALLBACKS (instead
> we'll use our fallback version of the module). at 
> /usr/share/perl5/Git/LoadCPAN.pm line 76.
> BEGIN failed--compilation aborted at 
> /usr/share/perl5/Git/LoadCPAN/Mail/Address.pm line 8.
> Compilation failed in require at /usr/lib/git-core/git-send-email line 37.
> BEGIN failed--compilation aborted at /usr/lib/git-core/git-send-email line 37.
> diff: actual: No such file or directory

-- 
Felipe Contreras

Bug#949013: Upgrade of Perl stymied by a dependency issue

[gregor herrmann]

Control: forcemerge 942135 -1

On Thu, 16 Jan 2020 11:28:30 +1100, rob stone wrote:

> Package: libgtk2-perl
> Version: 2:1.24993-1
> 
> Whilst running a dist-upgrade, the Perl packages cannot be upgraded due
> to an erroneous dependency.
> 
> libgtk2-perl : Depends: perlapi-5.28.1 which is a virtual package,
> provided by: - perl-base (5.28.1-6), but 5.30.0-9 is to be installed

libgtk2-perl is about to be removed from the Debian archive (#912860)
and currently doesn't even build anymore (#942135).

So if you want to update your perl to 5.30, the only option is to
uninstall libgtk2-perl.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Henry Thomas: Bull doze blues


signature.asc
Description: Digital Signature

Bug#948976: closed by Sandro Tosi (Bug#948976: fixed in python-argcomplete 1.8.1-1.2)

[Sandro Tosi]

> On 16/01/2020 22.24, Debian Bug Tracking System wrote:
> >* Add Breaks+Replace on python-argcomplete (<< 1.8.1-1);
>
> if you really used this constraint in the upload (I can't see the source
> package, yet, and check myself), that's wrong since it does not cover
> the version currently in stretch/buster/bullseye.
> This either needs to be unversioned (my preference) or (<< 1.8.1-1.1).

argh, i'll fix. maybe that recommendation should be part of your bug
reports in the first place, would simply things quite a bit.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#949104: piuparts.debian.org: please deploy latest fixes on pejacevic

[Nis Martensen]

Package: piuparts.debian.org
Severity: normal

The latest logs[1] still show this error:

Traceback (most recent call last):
  File 
"/srv/piuparts.debian.org/share/piuparts/master/detect_well_known_errors", line 
182, in 
args.recheck_failed)
  File 
"/srv/piuparts.debian.org/share/piuparts/master/detect_well_known_errors", line 
122, in detect_well_known_errors
recheck, recheck_failed)
  File 
"/srv/piuparts.debian.org/share/piuparts/master/detect_well_known_errors", line 
103, in process_section
add_cnt = make_kprs(logdict, kprdict, problem_list)
  File 
"/srv/piuparts.debian.org/lib/python3/dist-packages/piupartslib/dwke.py", line 
252, in make_kprs
logbody = lb.read()
  File "/usr/lib/python3.7/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)

[1] https://piuparts.debian.org/logs/2020/01/16/detect_well_known_errors.txt

It would be nice to know if merge request !26 really fixed that. :)

Please also consider merging !10 and possibly !15, which are both
single-line changes.

Bug#949024: g++: internal compiler error on beignet

[Rebecca N. Palmer]

Control: retitle -1 g++: ICE at cp/pt.c:15779 on beignet in -std=gnu++14 
or higher


This also happens with LLVM 9 (which makes sense given that the error 
message points to code in beignet itself):


  LLVM 9LLVM 10
-std=c++0x   successstd::index_sequence fail
-std=c++11   successstd::index_sequence fail
none (gnu++14)  ICE ICE
-std=c++17  not tested  ICE
none, gcc-snapshot  ICE   not tested

("std::index_sequence fail" above means
/usr/lib/llvm-10/include/llvm/ADT/STLExtras.h:559:49: error: 
'std::index_sequence' has not been declared
I suspect this is "LLVM 10 needs at least c++14" and not a bug, but as 
it happens first, I don't know whether those combinations would have the 
ICE.)


It probably *isn't* the upstream GCC bug I mentioned above, as the line 
number doesn't match: in Debian gcc 9, upstream bugs 91467 and 92583 are 
both cp/pt.c:15538, 92625 is cp/pt.c:16142, and 92948 is cp/pt.c:15774.


gcc-snapshot also has this bug (at cp/pt.c:16332).

Bug#949103: default log level is too low

[Richard van der Hoff]

Package: matrix-synapse
Version: 1.8.0-1

I am one of the upstream maintainers of this package.

I note that, since v0.99.2 or so, the Debian package has shipped with a 
log config which disables any logging below WARNING, and some below ERROR.


We have recently had a number of users approach us looking for support 
to resolve one problem or another, but we are unable to help with their 
problem because it turns out that the necessary logs are not present; 
resolving any problem therefore first becomes a matter of talking the 
user through updating their log config. This takes considerable time and 
I feel it gives a poor user experience.


I understand the concern that, with logging set to INFO and when 
participating in large rooms, Synapse logs a significant quantity of 
data; and I understand that some users may wish to increase the log 
threshold to reduce the quantity of data logged. *However* I think this 
is something that more experienced users could do once their system is 
largely working: it is *not* something that new users should have to 
learn to *undo* before we can solve their problem.


In short, I believe the changes made to the log config in 
https://salsa.debian.org/matrix-team/matrix-synapse/commit/9ee4bc38cf88425bd4fe9a70e97439910afb63e6 
are misguided and placing an unnecessary burden on users of the package 
and on those of us who end up supporting them; please consider reverting 
the changes.

Bug#948976: closed by Sandro Tosi (Bug#948976: fixed in python-argcomplete 1.8.1-1.2)

[Andreas Beckmann]

Hi Sandro,

On 16/01/2020 22.24, Debian Bug Tracking System wrote:
>* Add Breaks+Replace on python-argcomplete (<< 1.8.1-1);

if you really used this constraint in the upload (I can't see the source
package, yet, and check myself), that's wrong since it does not cover
the version currently in stretch/buster/bullseye.
This either needs to be unversioned (my preference) or (<< 1.8.1-1.1).


Andreas

Bug#949095: calibredb broken in python3 version

[Norbert Preining]

Hi Gregor,

On Thu, 16 Jan 2020, gregor herrmann wrote:
>   File "/usr/lib/calibre/calibre/library/catalogs/bibtex.py", line 400, in run
> % (nb_entries, nowf().strftime("%A, %d. %B %Y 
> %H:%M").decode(preferred_encoding)))

That does not work. For a quick fix, use this:
--- bibtex.py.orig  2020-01-17 07:19:29.325310092 +0900
+++ bibtex.py   2020-01-17 07:19:31.577334960 +0900
@@ -397,7 +397,7 @@

 outfile.write('%%%Calibre catalog\n%%%{0} entries in 
catalog\n\n'.format(nb_entries))
 outfile.write('@preamble{"This catalog of %d entries was generated 
by calibre on %s"}\n\n'
-% (nb_entries, nowf().strftime("%A, %d. %B %Y 
%H:%M").decode(preferred_encoding)))
+% (nb_entries, nowf().strftime("%A, %d. %B %Y %H:%M")))

 for entry in data:
 outfile.write(create_bibtex_entry(entry, fields, bib_entry, 
template_citation,

on /usr/lib/calibre/calibre/library/catalogs/bibtex.py

I will contact/check upstream and report.

Thanks for the report

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#946413: Done

[gregor herrmann]

On Thu, 16 Jan 2020 01:43:11 +, Jelmer Vernooij wrote:

> I believe all the suggestions from the original bug report have now been
> implemented and are live in the version of lintian-brush in sid and the 
> version
> used by the janitor.

Ack, thank you!


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: U2: New York


signature.asc
Description: Digital Signature

Bug#949101: iptables-restore: segmentation fault

[Alexander E. Patrakov]

Package: iptables
Version: 1.8.2-4
Severity: normal

Dear maintainer,

This is a reproducible way to segfault iptables-restore (the nftables variant):

0. Start with a blank state.

1. Load the initial rules:

iptables-restore < original_rules.iptables

2. Attempt to test new rules, to be applied incrementally:

iptables-restore -n -t < new.iptables

The second command results in a segfault.

I don't care in this bug report if the rules are actually valid, the program 
should point out the error instead of segfaulting.

Here is what gdb says:

Program received signal SIGSEGV, Segmentation fault.
0x77da8787 in nftnl_expr_build_payload (nlh=nlh@entry=0x775b3220, 
expr=expr@entry=0x0) at expr.c:210
210 expr.c: No such file or directory.
(gdb) bt full
#0  0x77da8787 in nftnl_expr_build_payload 
(nlh=nlh@entry=0x775b3220, expr=expr@entry=0x0) at expr.c:210
nest = 
#1  0x77da3783 in nftnl_rule_nlmsg_build_payload (nlh=0x775b3220, 
r=0x555f89d0) at rule.c:320
expr = 0x0
nest = 0x775b324c
nest2 = 0x775b35a4
#2  0x55564c66 in nft_compat_rule_batch_add (h=h@entry=0x7fffe4e0, 
type=type@entry=6, flags=flags@entry=3072, 
seq=, rule=) at nft.c:2579
nlh = 
#3  0x5556593e in nft_action (h=0x7fffe4e0, action=1) at nft.c:2673
n = 0x555f8c30
tmp = 
err = 
ne = 
buflen = 
i = 
len = 
show_errors = true
errmsg = 
"\001\000\000\000\000\000\000\000\242\241i\367\377\177\000\000\340\344\377\377\377\177\000\000\t\000\000\000\000\000\000\000\240\305_UUU\000\000\060\253_UUU\000\000\260\272\377\377\377\177\000\000\373HVUUU\000\000\340\344\377\377\377\177\000\000\240\305_UUU\000\000\000\000\000\000\000\000\000\000\366xVUUU\000\000\340\242_UUU\000\000\000\000\000\000\000\000\000\000T{_UUU\000\000\260\272\377\377\377\177\000\000\064\217_UUU\000\000\000\000\000\000\000\000\000\000\340\242_UUU\000\000\352%VUUU\000\000\060\253_UUU\000\000\064\217_UUU\000\000\000\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000@\217_UUU\000\000"...
seq = 10
ret = 0
#4  0x55561555 in xtables_restore_parse (h=h@entry=0x7fffe4e0, 
p=p@entry=0x7fffe4c0, 
cb=cb@entry=0x55589140 , argc=argc@entry=4, 
argv=argv@entry=0x7fffe668) at xtables-restore.c:143
ret = 0
buffer = "COMMIT\n\000RD -j COMPLAIN\n\000rs -p tcp -m tcp --tcp-flags 
FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT\n", '\000' ...
in_table = 
curtable = 0x55589c20 
ops = 
chain_list = 0x555f54b0
#5  0x55561f90 in xtables_restore_main (family=2, progname=, argc=4, argv=0x7fffe668)
at xtables-restore.c:474
tables = 
h = {family = 2, nl = 0x555f5490, portid = 2389, seq = 0, obj_list 
= {next = 0x555f6df0, prev = 0x555fabf0}, 
  obj_list_num = 16, batch = 0x555fac20, err_list = {next = 
0x7fffe518, prev = 0x7fffe518}, 
  ops = 0x55589ee0 , tables = 0x55589c20 
, chain_cache = 0x555f54b0, 
  rule_cache = 0x555f7c30, restore = true, config_done = -1 '\377', 
error = {lineno = 23}}
c = 
--Type  for more, q to quit, c to continue without paging--
p = {in = 0x555f5260, testing = 1, tablename = 0x0, commit = true}
#6  0x7763909b in __libc_start_main (main=0xcfb0 , 
argc=4, argv=0x7fffe668, init=, 
fini=, rtld_fini=, stack_end=0x7fffe658) 
at ../csu/libc-start.c:308
self = 
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -5955117646945397298, 
93824992268224, 140737488348768, 0, 0, 
-572386658808703538, -572405319023536690}, mask_was_saved = 
0}}, priv = {pad = {0x0, 0x0, 0x7fffe690, 
  0x77ffe190}, data = {prev = 0x0, cleanup = 0x0, canceltype = 
-6512}}}
not_first_call = 
#7  0xcfea in _start ()
No symbol table info available.


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

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

Versions of packages iptables depends on:
ii  libc62.28-10
ii  libip4tc01.8.2-4
ii  libip6tc01.8.2-4
ii  libiptc0 1.8.2-4
ii  libmnl0  1.0.4-2
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.2-2
ii  libxtables12 1.8.2-4

Versions of packages iptables recommends:
pn  nftables  

Versions of packages iptables suggests:
ii  kmod  26-1

-- no debconf information
# Generated by 

Bug#949098: dvdauthor: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Mattia Rizzolo]

Source: dvdauthor
Version: 0.7.2-1
Severity: important
Tags: ftbfs
User: libx...@packages.debian.org
Usertags: ftbfs-2.9.10 xml2-config


Dear maintainer,

your package is using `xml2-config` to detect and use libxml2.  I'm
removing that script, so please update your build system to use
pkg-config instead.

The libxml2 package in experimental already doesn't ship the xml2-config
script.

Attached is the full build log, hopefully relevant excerpt follows:


checking for xml2-config... no
checking for libxml - version >= 2.6.0... no
*** The xml2-config script installed by LIBXML could not be found
*** If libxml was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the XML2_CONFIG environment variable to the
*** full path to xml2-config.
configure: error: You must have libxml2 >= 2.6.0 installed
make: *** [/usr/share/cdbs/1/class/autotools.mk:46: debian/stamp-autotools] 
Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
I: Using pkgname logfile
I: Current time: Thu Jan 16 20:30:44 UTC 2020
I: pbuilder-time-stamp: 1579206644
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [pkgs/dvdauthor_0.7.2-1.dsc]
I: copying [pkgs/dvdauthor_0.7.2.orig.tar.gz]
I: copying [pkgs/dvdauthor_0.7.2-1.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/mattia/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Sat Jan 26 15:33:14 2019 UTC
gpgv:using RSA key A401FF99368FA1F98152DE755C808C2B65558117
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./dvdauthor_0.7.2-1.dsc
dpkg-source: info: extracting dvdauthor in dvdauthor-0.7.2
dpkg-source: info: unpacking dvdauthor_0.7.2.orig.tar.gz
dpkg-source: info: unpacking dvdauthor_0.7.2-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-add-config-rpath.patch
dpkg-source: info: applying 0002-dvdcli-move-message-to-stdout.patch
dpkg-source: info: applying 
0003-autotools-use-pkg-config-to-test-freetype2.patch
I: using fakeroot in build.
I: Installing the build-deps
I: -> Attempting to satisfy build-dependencies
Note, using file '/build/dvdauthor_0.7.2-1.dsc' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  autoconf automake autopoint autotools-dev bison bsdmainutils cdbs debhelper
  dh-autoreconf dh-strip-nondeterminism diffstat docbook docbook-dsssl
  docbook-to-man docbook-utils dwz file flex fontconfig fontconfig-config
  fonts-dejavu-core fonts-lmodern gettext gettext-base gir1.2-freedesktop
  gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0 gir1.2-rsvg-2.0 groff-base
  imagemagick-6-common intltool-debian libarchive-zip-perl libblkid-dev
  libbsd0 libbz2-dev libcairo-gobject2 libcairo-script-interpreter2 libcairo2
  libcairo2-dev libcroco3 libdatrie1 libde265-0 libdebhelper-perl
  libdjvulibre-dev libdjvulibre-text libdjvulibre21 libdvdread-dev libdvdread7
  libelf1 libexif-dev libexif12 libexpat1-dev libffi-dev libfftw3-double3
  libfile-stripnondeterminism-perl libfontconfig1 libfontconfig1-dev
  libfreetype-dev libfreetype6 libfreetype6-dev libfribidi-dev libfribidi0
  libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common
  libgdk-pixbuf2.0-dev libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin
  libglib2.0-data libglib2.0-dev libglib2.0-dev-bin libgraphite2-3
  libharfbuzz-icu0 libharfbuzz0b libheif1 libice-dev libice6 libidn11
  libilmbase-dev libilmbase24 libjbig-dev libjbig0 libjpeg-dev libjpeg62-turbo
  libjpeg62-turbo-dev libkpathsea6 liblcms2-2 liblcms2-dev liblqr-1-0
  liblqr-1-0-dev libltdl-dev libltdl7 liblzma-dev liblzo2-2 libmagic-mgc
  libmagic1 libmagick++-6-headers libmagick++-6.q16-8 libmagick++-6.q16-dev
  libmagick++-dev libmagickcore-6-arch-config libmagickcore-6-headers
  libmagickcore-6.q16-6 libmagickcore-6.q16-6-extra libmagickcore-6.q16-dev
  libmagickwand-6-headers libmagickwand-6.q16-6 libmagickwand-6.q16-dev
  libmount-dev libnuma1 libopenexr-dev libopenexr24 libopenjp2-7
  libopenjp2-7-dev libosp5 libostyle1c2 libpango-1.0-0 libpangocairo-1.0-0
  libpangoft2-1.0-0 libpaper-utils libpaper1 libpcre16-3 libpcre2-16-0
  libpcre2-32-0 libpcre2-dev libpcre2-posix2 libpcre3-dev libpcre32-3
  libpcrecpp0v5 libpipeline1 libpixman-1-0 libpixman-1-dev libpng-dev
  libpng16-16 libptexenc1 libpthread-stubs0-dev libpython-stdlib librsvg2-2
  librsvg2-common 

Bug#949096: ITP: golang-github-emersion-go-sasl -- A SASL library written in Go

[Ben Fiedler]

Package: wnpp
Severity: wishlist
Owner: Ben Fiedler 

* Package name: golang-github-emersion-go-sasl
  Version : 0.0~git20191210.430746e-1
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/go-sasl
* License : Expat
  Programming Lang: Go
  Description : A SASL library written in Go

 A SASL (RFC 4422-complicant) library written in Go.
 .
 Implemented mechanisms: ANONYMOUS, EXTERNAL, LOGIN,
 PLAIN, OAUTHBEARER XOAUTH2

This is a dependency of aerc [1] (ITP tracked here [2]).

[1]: https://aerc-mail.org
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947962

Bug#949095: calibredb broken in python3 version

[gregor herrmann]

Package: calibre
Version: 4.99.3+dfsg-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm exporting my ebook library in a script with calibredb, and this
is broken in the python3 version (in the one which was briefly in
unstable before, and now also in 4.99.3+dfsg-2):

% calibredb catalog foo.bib --entry-type=mixed --add-files-path=False 
--fields=authors,title,pubdate,id,library_name,publisher
Traceback (most recent call last):
  File "/usr/bin/calibredb", line 20, in 
sys.exit(main())
  File "/usr/lib/calibre/calibre/db/cli/main.py", line 255, in main
return run_cmd(cmd, opts, args[1:], DBCtx(opts))
  File "/usr/lib/calibre/calibre/db/cli/main.py", line 52, in run_cmd
ret = m.main(opts, args, dbctx)
  File "/usr/lib/calibre/calibre/db/cli/cmd_catalog.py", line 129, in main
plugin.run(dest, opts, dbctx.db)
  File "/usr/lib/calibre/calibre/library/catalogs/bibtex.py", line 400, in run
% (nb_entries, nowf().strftime("%A, %d. %B %Y 
%H:%M").decode(preferred_encoding)))
AttributeError: 'str' object has no attribute 'decode'


Cheers,
gregor


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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages calibre depends on:
ii  calibre-bin  4.99.3+dfsg-2
ii  dpkg 1.19.7
ii  fonts-liberation 1:1.07.4-10
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-mathjax2.7.4+dfsg-1
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-1+b1
ii  poppler-utils0.71.0-6
ii  python3  3.7.5-3
ii  python3-apsw 3.30.1-r1-1
ii  python3-bs4  4.8.2-1
ii  python3-chardet  3.0.4-4
ii  python3-chm  0.8.6-2
ii  python3-css-parser   1.0.4-1
ii  python3-cssselect1.1.0-1
ii  python3-cssutils 1.0.2-2
ii  python3-dateutil 2.7.3-3
ii  python3-dbus 1.2.16-1
ii  python3-feedparser   5.2.1-1
ii  python3-html2text2019.8.11-1
ii  python3-html5-parser 0.4.9-2
ii  python3-html5lib 1.0.1-1
ii  python3-lxml 4.4.2-1
ii  python3-markdown 3.1.1-2
ii  python3-mechanize1:0.4.5-1
ii  python3-msgpack  0.5.6-2+b1
ii  python3-netifaces0.10.9-0.1
ii  python3-pil  7.0.0-3
ii  python3-pkg-resources44.0.0-1
ii  python3-pygments 2.3.1+dfsg-1
ii  python3-pyparsing2.4.2-1
ii  python3-pyqt55.14.1+dfsg-2
ii  python3-pyqt5.qtsvg  5.14.1+dfsg-2
ii  python3-pyqt5.qtwebengine5.14.0-1
ii  python3-regex0.1.20190819-1
ii  python3-routes   2.4.1-1.1
ii  python3-zeroconf 0.23.0-1
ii  xdg-utils1.1.3-1

Versions of packages calibre recommends:
ii  python3-dnspython  1.16.0-1

Versions of packages calibre suggests:
pn  python3-unrardll  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl4g2IZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaI5xAAuc7EKtlslJsoI7Pe4ldVuKb/C0DSikFXaVrWa9N98WlDlKkuz7Fb2vq/
Szt9brR+8GubPqaY04EI4QNJ+1HXBzmtnc44gLWg2JMXxJvvE0s9RmpAh3DQVYJi
mPIQ1l+B2IfsGmk+AzeojTMZu8Yqy9XZJ4FEM7QA6Or7vGGZKDHMzHQX0NNYzMwH
NKrAFlCwm9sgydxR9730za1OiCOr3J0yn74gLg4/pQVodlKUlA2d0c/dgJ/NWU6T
N4L3NfxmcOdhN1HHNfW+dBik61ZEdMWMZ50FJ2xvBphBzVa9YeLFmfVpqkiYTqB7
c7jgnJnEnuQa+9Du+MGYlrivFhBccT887k15S2oYewKjPeq0uGFKSzw2+cQXin3E
GVA7pIqw8WU7kWFw0dof37ySHsjdwBEcGt+MyvwM9cR2RWeQYFxcdNKHF9COeWJn
0Bd86V+ibTcizDxp7TSC4kCtZ7a84+35iilKSm0ynTM4iAUX7xZhB2ThVAbnS/iZ
wMWiWjJ4ZYO7B1muyxEZkmEyukaIx6uxvVR8tjsVpvMReuOIvJ8cwlADWuIpnQVn
X+WEgkCIcwP0ETZ0M+zRp/3hKyvm41JhIAZBy2//Ova/D13hzsahKddU8bm3VK/F
nXZyEms2DXoZjf0bW//w8LTNbEjwMTylyilK3AHLJq9obsa35AY=
=MWW/
-END PGP SIGNATURE-

Bug#928375: Announce - swig-4.0.0

[Torsten Landschoff]

On 1/1/20 5:13 PM, Alan Woodland wrote:
> On Mon, 2 Sep 2019 23:02:32 +0200 Torsten Landschoff <
> tors...@landschoff.net> wrote:
>> On 5/3/19 10:37 AM, Mathieu Malaterre wrote:
>>> Would be super nice to have swig 4 in Debian.
>> absolutely. And I did not notice for months. I'll have a go - maybe
> this
>> weekend, but no guarantees!
> How did it go? Is there anything you'd like some extra effort from
> another person on? I'm pretty invested in SWIG these days, so it'd be
> great to see this release in Debian.

The late reply is probably answer enough. I took today and tomorrow of
to finally have some time to spare on stuff I want to get done.

I'm astonished that the release announcement of swig 4.0 is dated april
2019 :-(


Working on it now but it's already late for today.

Greetings, Torsten

Bug#949094: ITP: golang-github-emersion-go-imap -- An IMAP library for clients and servers

[Ben Fiedler]

Package: wnpp
Severity: wishlist
Owner: Ben Fiedler 

* Package name: golang-github-emersion-go-imap
  Version : 1.0.2-1
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/go-imap
* License : Expat
  Programming Lang: Go
  Description : An IMAP library for clients and servers

 An IMAP4rev1 (RFC 3501-compliant) library written in
 Go. It can be used to build a client and/or a server.

This is a dependency of aerc [1] (ITP tracked here [2]).

[1]: https://aerc-mail.org
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947962

Bug#949093: ITP: golang-github-creack-pty -- PTY interface for Go

[Ben Fiedler]

Package: wnpp
Severity: wishlist
Owner: Ben Fiedler 

* Package name: golang-github-creack-pty
  Version : 1.1.9-1
  Upstream Author : Guillaume J. Charmes
* URL : https://github.com/creack/pty
* License : Expat
  Programming Lang: Go
  Description : PTY interface for Go

 Pty is a Go package for using unix pseudo-terminals.

This is a dependency of aerc [1] (ITP tracked here [2]).

[1]: https://aerc-mail.org
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947962

Bug#948842: nm.debian.org: please let people upload their OpenPGP certificate directly

[Daniel Kahn Gillmor]

On Wed 2020-01-15 21:40:38 +, Jonathan McDowell wrote:
> Y'all are welcome to (and tell prospective contributors to) send keys to
> the.earth.li, which is not SKS and still accepts third party
> certifications. It does some limited signature verification which I'm
> generally working to improve when time allows, but I think it's a
> half-way house between what we current have (trust a failing keyserver
> network to have the data) and what's being proposed (implement a very
> specific service to suit our needs for retrieving 3rd party certs).

It looks to me like the only thing nm needs the keyserver for is a
placeholder for keys until they land in the debian keyring (or the
debian-maintainer keyring), at which point we can rely on
keyring.debian.org.

right?

if the applicant is expected to submit this key somehow, it seems
simpler to me to have them just submit it to nm directly with the rest
of the application (e.g. "here are 9 questions, one of them needs you to
paste your OpenPGP certificate")  than to say "here are 8 questions; for
the 9th question, send your OpenPGP certificate to service X, and then
paste the fingerprint of the certificate here, and we'll reassemble it
from service X later".

 --dkg


signature.asc
Description: PGP signature

Bug#876131: qtbase-opensource-src FTCBFS: uses the build architecture toolchain

[Lisandro Damián Nicanor Pérez Meyer]

On 20/01/16 08:25, Helmut Grohne wrote:
> Hi Lisandro,
> 
> On Thu, Jan 16, 2020 at 04:07:24PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > > I also updated the patch to the current version.
> > > 
> > > Limitations:
> > >  * Only works for arm64 and armel since no other architectures have
> > >matching mkspecs
> > 
> > I'm wondering why we don't use linux-g++ too, as it has been happening on 
> > all other archs.
> 
> I can explain this. Please compare the relevant mkspecs:
> 
> https://sources.debian.org/src/qtbase-opensource-src/5.12.5+dfsg-5/mkspecs/linux-g++/qmake.conf/
> https://sources.debian.org/src/qtbase-opensource-src/5.12.5+dfsg-5/mkspecs/linux-aarch64-gnu-g++/qmake.conf/
> 
> You'll quickly observe that they look much the same with one key
> difference. The arm64 one has all the tools prefixed with the GNU
> triplet. And that's precisely the property we need here. In principle,
> could mechanically generate a similar mkspec for any other architecture.
> It is much like a CMake toolchain file or a meson toolchain file. We
> need it to tell QT which architecture to build for.

It seems clear I need to improve my communication skills :-) Yes, that's what I
intended to write in my original mail below, but my fault at not re reading
everything.

> Possibly we could patch a new linux-debian-g++ mkspec that sets up the
> variables based on the dpkg-architecture environment variables. If we go
> that route, make sure not to install that into a binary package. Prior
> art: linux-oe-g++
> (https://github.com/meta-qt5/meta-qt5/wiki/Building-with-OE).

Indeed, that's a good point.

> > Should we really close the bug here? I would keep it open until we make it 
> > work.
> 
> I tend to use Debian bugs as patch tracking ids for getting changes into
> packages. We could file FTCBFS bugs for any package that doesn't cross
> build, but I wouldn't find that useful. If you think there is something
> actionable left, I don't mind leaving it open. Otherwise I prefer
> closing it.

Perfect then.

> > Would the following comment be ok?
> > 
> > # Check we are cross building with the exact same Qt version.
> > > +ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
> > > + test "`dpkg-query -f '$${Version}' -W qt5-qmake-bin`" = "$(DEB_VERSION)"
> > > +endif
> 
> Yes, though in my book the comment just explains the code. I'd rather
> write down the intention:
> 
> # Refuse building with a qmake whose version differs from the package.

Again, perfect.

Bug#948976: python-argcomplete: diff for NMU version 1.8.1-1.2

[Sandro Tosi]

Control: tags 948976 + patch


Dear maintainer,

I've prepared an NMU for python-argcomplete (versioned as 1.8.1-1.2). The diff
is attached to this message.

Regards.

diff -Nru python-argcomplete-1.8.1/debian/changelog python-argcomplete-1.8.1/debian/changelog
--- python-argcomplete-1.8.1/debian/changelog	2020-01-14 16:48:14.0 -0500
+++ python-argcomplete-1.8.1/debian/changelog	2020-01-16 16:06:17.0 -0500
@@ -1,3 +1,10 @@
+python-argcomplete (1.8.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Breaks+Replace on python-argcomplete (<< 1.8.1-1); Closes: #948976
+
+ -- Sandro Tosi   Thu, 16 Jan 2020 16:06:17 -0500
+
 python-argcomplete (1.8.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-argcomplete-1.8.1/debian/control python-argcomplete-1.8.1/debian/control
--- python-argcomplete-1.8.1/debian/control	2020-01-14 16:47:49.0 -0500
+++ python-argcomplete-1.8.1/debian/control	2020-01-16 16:05:55.0 -0500
@@ -12,6 +12,8 @@
 Package: python3-argcomplete
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
+Breaks: python-argcomplete (<< 1.8.1-1)
+Replaces: python-argcomplete (<< 1.8.1-1)
 Description: bash tab completion for argparse (for Python 3)
  Argcomplete provides easy, extensible command line tab completion of
  arguments for your Python script.

Bug#949090: ddccontrol: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Mattia Rizzolo]

Source: ddccontrol
Version: 0.4.4-1
Severity: important
Tags: ftbfs
User: libx...@packages.debian.org
Usertags: ftbfs-2.9.10 xml2-config


Dear maintainer,

your package is using `xml2-config` to detect and use libxml2.  I'm
removing that script, so please update your build system to use
pkg-config instead.

The libxml2 package in experimental already doesn't ship the xml2-config
script.

Attached is the full build log, hopefully relevant excerpt follows:


checking for xml2-config... no
configure: error: xml2-config not found, please install libxml2, available at 
http://www.xmlsoft.org/.



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
I: Using pkgname logfile
I: Current time: Thu Jan 16 19:19:13 UTC 2020
I: pbuilder-time-stamp: 1579202353
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [pkgs/ddccontrol_0.4.4-1.dsc]
I: copying [pkgs/ddccontrol_0.4.4.orig.tar.gz]
I: copying [pkgs/ddccontrol_0.4.4-1.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/mattia/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Sun Apr 29 18:50:08 2018 UTC
gpgv:using RSA key 9236557B170C87F8821C0AC3C1E0D92E986F7C7E
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./ddccontrol_0.4.4-1.dsc
dpkg-source: info: extracting ddccontrol in ddccontrol-0.4.4
dpkg-source: info: unpacking ddccontrol_0.4.4.orig.tar.gz
dpkg-source: info: unpacking ddccontrol_0.4.4-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-use-pkexec-for-gddccontrol.patch
dpkg-source: info: applying 0002-load-i2c-dev-module-at-boot.patch
I: using fakeroot in build.
I: Installing the build-deps
I: -> Attempting to satisfy build-dependencies
Note, using file '/build/ddccontrol_0.4.4-1.dsc' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  adwaita-icon-theme autoconf automake autopoint autotools-dev bsdmainutils
  ca-certificates debhelper dh-autoreconf dh-strip-nondeterminism docbook-xsl
  dwz file fontconfig fontconfig-config fonts-dejavu-core gettext gettext-base
  gir1.2-atk-1.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0
  gir1.2-gtk-2.0 gir1.2-harfbuzz-0.0 gir1.2-pango-1.0 groff-base
  gtk-update-icon-cache hicolor-icon-theme intltool intltool-debian
  libarchive-zip-perl libatk1.0-0 libatk1.0-data libatk1.0-dev
  libavahi-client3 libavahi-common-data libavahi-common3 libblkid-dev libbsd0
  libcairo-gobject2 libcairo-script-interpreter2 libcairo2 libcairo2-dev
  libcroco3 libcups2 libdatrie1 libdbus-1-3 libdebhelper-perl libelf1
  libencode-locale-perl libexpat1-dev libffi-dev libfile-listing-perl
  libfile-stripnondeterminism-perl libfontconfig1 libfontconfig1-dev
  libfreetype-dev libfreetype6 libfreetype6-dev libfribidi-dev libfribidi0
  libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common
  libgdk-pixbuf2.0-dev libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin
  libglib2.0-data libglib2.0-dev libglib2.0-dev-bin libgraphite2-3
  libgraphite2-dev libgssapi-krb5-2 libgtk2.0-0 libgtk2.0-common libgtk2.0-dev
  libharfbuzz-dev libharfbuzz-gobject0 libharfbuzz-icu0 libharfbuzz0b
  libhtml-parser-perl libhtml-tagset-perl libhtml-tree-perl
  libhttp-cookies-perl libhttp-date-perl libhttp-message-perl
  libhttp-negotiate-perl libice-dev libice6 libio-html-perl
  libio-socket-ssl-perl libjbig0 libjpeg62-turbo libk5crypto3 libkeyutils1
  libkrb5-3 libkrb5support0 liblwp-mediatypes-perl liblwp-protocol-https-perl
  liblzo2-2 libmagic-mgc libmagic1 libmount-dev libnet-http-perl
  libnet-ssleay-perl libpango-1.0-0 libpango1.0-dev libpangocairo-1.0-0
  libpangoft2-1.0-0 libpangoxft-1.0-0 libpci-dev libpci3 libpcre16-3
  libpcre2-16-0 libpcre2-32-0 libpcre2-dev libpcre2-posix2 libpcre3-dev
  libpcre32-3 libpcrecpp0v5 libpipeline1 libpixman-1-0 libpixman-1-dev
  libpng-dev libpng16-16 libpthread-stubs0-dev librsvg2-2 librsvg2-common
  libselinux1-dev libsepol1-dev libsigsegv2 libsm-dev libsm6
  libsub-override-perl libthai-data libthai0 libtidy5deb1 libtiff5
  libtimedate-perl libtool libtry-tiny-perl libuchardet0 libudev-dev
  liburi-perl libwebp6 libwww-perl libwww-robotrules-perl libx11-6 libx11-data
  libx11-dev libxau-dev libxau6 libxcb-render0 libxcb-render0-dev libxcb-shm0
  libxcb-shm0-dev libxcb1 libxcb1-dev libxcomposite-dev libxcomposite1
  libxcursor-dev libxcursor1 libxdamage-dev libxdamage1 libxdmcp-dev libxdmcp6
  libxext-dev 

Bug#949092: dictconv: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Mattia Rizzolo]

Source: dictconv
Version: 0.2-7
Severity: important
Tags: ftbfs
User: libx...@packages.debian.org
Usertags: ftbfs-2.9.10 xml2-config


Dear maintainer,

your package is using `xml2-config` to detect and use libxml2.  I'm
removing that script, so please update your build system to use
pkg-config instead.

The libxml2 package in experimental already doesn't ship the xml2-config
script.

Attached is the full build log, hopefully relevant excerpt follows:


checking for xml2-config... no
checking for libxml - version >= 2.5.0... no
*** The xml2-config script installed by LIBXML could not be found
*** If libxml was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the XML2_CONFIG environment variable to the
*** full path to xml2-config.
configure: error: You must have libxml2 >= 2.5.0 installed
make: *** [/usr/share/cdbs/1/class/autotools.mk:46: debian/stamp-autotools] 
Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
I: Using pkgname logfile
I: Current time: Thu Jan 16 20:00:21 UTC 2020
I: pbuilder-time-stamp: 1579204821
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [pkgs/dictconv_0.2-7.dsc]
I: copying [pkgs/dictconv_0.2.orig.tar.gz]
I: copying [pkgs/dictconv_0.2-7.diff.gz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/mattia/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Thu Jun 19 19:51:44 2008 UTC
gpgv:using DSA key 010C2EA6D9309644
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./dictconv_0.2-7.dsc
dpkg-source: info: extracting dictconv in dictconv-0.2
dpkg-source: info: unpacking dictconv_0.2.orig.tar.gz
dpkg-source: info: applying dictconv_0.2-7.diff.gz
I: using fakeroot in build.
I: Installing the build-deps
I: -> Attempting to satisfy build-dependencies
Note, using file '/build/dictconv_0.2-7.dsc' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  autoconf automake autopoint autotools-dev bsdmainutils cdbs debhelper
  dh-autoreconf dh-strip-nondeterminism dwz file gettext gettext-base
  groff-base intltool-debian libarchive-zip-perl libbsd0 libcroco3
  libdebhelper-perl libelf1 libfile-stripnondeterminism-perl libglib2.0-0
  libmagic-mgc libmagic1 libpipeline1 libsigsegv2 libsub-override-perl libtool
  libuchardet0 m4 man-db patchutils po-debconf sensible-utils zlib1g-dev
debconf: delaying package configuration, since apt-utils is not installed
0 upgraded, 35 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/10.7 MB of archives.
After this operation, 37.2 MB of additional disk space will be used.
Selecting previously unselected package libbsd0:amd64.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14048 files and directories currently installed.)
Preparing to unpack .../00-libbsd0_0.10.0-1_amd64.deb ...
Unpacking libbsd0:amd64 (0.10.0-1) ...
Selecting previously unselected package bsdmainutils.
Preparing to unpack .../01-bsdmainutils_11.1.2+b1_amd64.deb ...
Unpacking bsdmainutils (11.1.2+b1) ...
Selecting previously unselected package libuchardet0:amd64.
Preparing to unpack .../02-libuchardet0_0.0.6-3_amd64.deb ...
Unpacking libuchardet0:amd64 (0.0.6-3) ...
Selecting previously unselected package groff-base.
Preparing to unpack .../03-groff-base_1.22.4-4_amd64.deb ...
Unpacking groff-base (1.22.4-4) ...
Selecting previously unselected package libpipeline1:amd64.
Preparing to unpack .../04-libpipeline1_1.5.2-2_amd64.deb ...
Unpacking libpipeline1:amd64 (1.5.2-2) ...
Selecting previously unselected package man-db.
Preparing to unpack .../05-man-db_2.9.0-2_amd64.deb ...
Unpacking man-db (2.9.0-2) ...
Selecting previously unselected package sensible-utils.
Preparing to unpack .../06-sensible-utils_0.0.12+nmu1_all.deb ...
Unpacking sensible-utils (0.0.12+nmu1) ...
Selecting previously unselected package libmagic-mgc.
Preparing to 

Bug#949091: dia2code: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Mattia Rizzolo]

Source: dia2code
Version: 0.8.3-4
Severity: important
Tags: ftbfs
User: libx...@packages.debian.org
Usertags: ftbfs-2.9.10 xml2-config


Dear maintainer,

your package is using `xml2-config` to detect and use libxml2.  I'm
removing that script, so please update your build system to use
pkg-config instead.

The libxml2 package in experimental already doesn't ship the xml2-config
script.

Attached is the full build log, hopefully relevant excerpt follows:


checking for xml2-config... no
configure: error: Cannot determine configuration of libxml.
Perhaps you forgot to install the package libxml2-devel ?
make: *** [/usr/share/cdbs/1/class/autotools.mk:46: debian/stamp-autotools] 
Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
I: Using pkgname logfile
I: Current time: Thu Jan 16 19:58:22 UTC 2020
I: pbuilder-time-stamp: 1579204702
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [pkgs/dia2code_0.8.3-4.dsc]
I: copying [pkgs/dia2code_0.8.3.orig.tar.gz]
I: copying [pkgs/dia2code_0.8.3-4.diff.gz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/mattia/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Sat Apr 24 18:58:56 2010 UTC
gpgv:using RSA key 3355F4D63B5821CC
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./dia2code_0.8.3-4.dsc
dpkg-source: info: extracting dia2code in dia2code-0.8.3
dpkg-source: info: unpacking dia2code_0.8.3.orig.tar.gz
dpkg-source: info: applying dia2code_0.8.3-4.diff.gz
I: using fakeroot in build.
I: Installing the build-deps
I: -> Attempting to satisfy build-dependencies
Note, using file '/build/dia2code_0.8.3-4.dsc' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  autoconf automake autopoint autotools-dev bsdmainutils cdbs debhelper
  dh-autoreconf dh-strip-nondeterminism dwz file gettext gettext-base
  groff-base intltool-debian libarchive-zip-perl libbsd0 libcroco3
  libdebhelper-perl libelf1 libfile-stripnondeterminism-perl libglib2.0-0
  libmagic-mgc libmagic1 libpipeline1 libsigsegv2 libsub-override-perl libtool
  libuchardet0 m4 man-db patchutils po-debconf sensible-utils
debconf: delaying package configuration, since apt-utils is not installed
0 upgraded, 34 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/10.5 MB of archives.
After this operation, 36.7 MB of additional disk space will be used.
Selecting previously unselected package libbsd0:amd64.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14048 files and directories currently installed.)
Preparing to unpack .../00-libbsd0_0.10.0-1_amd64.deb ...
Unpacking libbsd0:amd64 (0.10.0-1) ...
Selecting previously unselected package bsdmainutils.
Preparing to unpack .../01-bsdmainutils_11.1.2+b1_amd64.deb ...
Unpacking bsdmainutils (11.1.2+b1) ...
Selecting previously unselected package libuchardet0:amd64.
Preparing to unpack .../02-libuchardet0_0.0.6-3_amd64.deb ...
Unpacking libuchardet0:amd64 (0.0.6-3) ...
Selecting previously unselected package groff-base.
Preparing to unpack .../03-groff-base_1.22.4-4_amd64.deb ...
Unpacking groff-base (1.22.4-4) ...
Selecting previously unselected package libpipeline1:amd64.
Preparing to unpack .../04-libpipeline1_1.5.2-2_amd64.deb ...
Unpacking libpipeline1:amd64 (1.5.2-2) ...
Selecting previously unselected package man-db.
Preparing to unpack .../05-man-db_2.9.0-2_amd64.deb ...
Unpacking man-db (2.9.0-2) ...
Selecting previously unselected package sensible-utils.
Preparing to unpack .../06-sensible-utils_0.0.12+nmu1_all.deb ...
Unpacking sensible-utils (0.0.12+nmu1) ...
Selecting previously unselected package libmagic-mgc.
Preparing to unpack .../07-libmagic-mgc_1%3a5.38-3_amd64.deb ...
Unpacking libmagic-mgc (1:5.38-3) ...
Selecting previously unselected package libmagic1:amd64.
Preparing to unpack .../08-libmagic1_1%3a5.38-3_amd64.deb 

Bug#949089: libxmlrpc3-java: CVE-2019-17570: deserialization of server-side exception from faultCause in XMLRPC error response

[Salvatore Bonaccorso]

Source: libxmlrpc3-java
Version: 3.1.3-9
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerability was published for libxmlrpc3-java.

CVE-2019-17570[0]:
| Deserialization of server-side exception from faultCause in XMLRPC
| error response

That said, should libxmlrpc3-java rather be removed from unstable, and
not included in bullseye?

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-17570
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17570
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1775193

Regards,
Salvatore

Bug#946608: shadow: [INTL:nl] Dutch po file for the shadow package

[Frans Spiesschaert]

Hi Bálint,

Bálint Réczey schreef op vr 20-12-2019 om 13:59 [+0100]:
> Control: tags -1 confirmed upstream moreinfo
> 
> Hi Frans,
> 
> On Wed, Dec 11, 2019, 8:45 PM Frans Spiesschaert <
> frans.spiesscha...@yucom.be> wrote:
> > Package: shadow
> > Severity: wishlist
> > Tags: l10n patch 
> > 
> > 
> Thank you for the translation. I'm about to update shadow to 4.8
> which needs further translation updates. Could you please refresh the
> translation for it or possibly forward it upstream?

Please find attached an updated translation for shadow version 4.8.
I also created a pull request for it on GitHub.


> 
> Thanks,
> Balint
> 

-- 
Kind regards,
Frans Spiesschaert

# dutch po-file for shadow
# Copyright (C) 2004 Free Software Foundation, Inc.
# Bart Cornelis , 2004, 2006.
# Frans Spiesschaert , 2014-2019.
#
msgid ""
msgstr ""
"Project-Id-Version: shadow_1_4.8\n"
"Report-Msgid-Bugs-To: pkg-shadow-de...@lists.alioth.debian.org\n"
"POT-Creation-Date: 2019-12-01 11:37-0600\n"
"PO-Revision-Date: 2019-12-23 23:33+0100\n"
"Last-Translator: Frans Spiesschaert \n"
"Language-Team: Debian Dutch l10n Team \n"
"Language: nl\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Gtranslator 3.30.1\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#, c-format
msgid ""
"Multiple entries named '%s' in %s. Please fix this with pwck or grpck.\n"
msgstr ""
"In %s staan meerdere regels met als naam '%s'. Gelieve dit met pwck of grpck "
"te repareren.\n"

#, c-format
msgid "crypt method not supported by libcrypt? (%s)\n"
msgstr "niet door libcrypt ondersteunde encryptiemethode? (%s)\n"

#, c-format
msgid "configuration error - cannot parse %s value: '%s'"
msgstr "configuratiefout - kan waarde %s niet ontleden: '%s'"

msgid "Could not allocate space for config info.\n"
msgstr "Kon geen ruimte toewijzen voor de configuratie-info.\n"

#, c-format
msgid "configuration error - unknown item '%s' (notify administrator)\n"
msgstr ""
"configuratiefout - onbekend item '%s' (waarschuw een systeembeheerder)\n"

#, c-format
msgid "%s: nscd did not terminate normally (signal %d)\n"
msgstr "%s: nscd werd niet normaal beëindigd (signaal %d)\n"

#, c-format
msgid "%s: nscd exited with status %d\n"
msgstr "%s: nscd sloot af met status %d\n"

msgid "Password: "
msgstr "Wachtwoord: "

#, c-format
msgid "%s's Password: "
msgstr "Wachtwoord van %s: "

msgid "Cannot open audit interface.\n"
msgstr "Kan auditinterface niet openen.\n"

#, c-format
msgid "%s: can not get previous SELinux process context: %s\n"
msgstr ""
"%s: kan context van vorige SELinux-proces niet verkrijgen: %s\n"
"\n"

#, c-format
msgid "[libsemanage]: %s\n"
msgstr "[libsemanage]: %s\n"

#, c-format
msgid "Cannot create SELinux management handle\n"
msgstr "Kan geen instrument voor SELinux-beheer creëren\n"

#, c-format
msgid "SELinux policy not managed\n"
msgstr "SELinux-beleid wordt niet beheerd\n"

#, c-format
msgid "Cannot read SELinux policy store\n"
msgstr "Kan het gebied met het SELinux-beleid niet lezen\n"

#, c-format
msgid "Cannot establish SELinux management connection\n"
msgstr "Kan geen verbinding leggen om SELinux te beheren\n"

#, c-format
msgid "Cannot begin SELinux transaction\n"
msgstr "Kan de SELinux-transactie niet beginnen\n"

#, c-format
msgid "Could not query seuser for %s\n"
msgstr "Kon de seuser van %s niet opvragen\n"

#, c-format
msgid "Could not set serange for %s\n"
msgstr "Kon de serange van %s niet instellen\n"

#, c-format
msgid "Could not set sename for %s\n"
msgstr "Kon de sename van %s niet instellen\n"

#, c-format
msgid "Could not modify login mapping for %s\n"
msgstr "Kon de aanmeldkoppeling van %s niet veranderen\n"

#, c-format
msgid "Cannot create SELinux login mapping for %s\n"
msgstr "Kan voor %s geen SELinux-aanmeldkoppeling maken\n"

#, c-format
msgid "Could not set name for %s\n"
msgstr "Kon voor %s geen naam instellen\n"

#, c-format
msgid "Could not set SELinux user for %s\n"
msgstr "Kon voor %s geen SELinuxgebruiker instellen\n"

#, c-format
msgid "Could not add login mapping for %s\n"
msgstr "Kon voor %s geen aanmeldkoppeling toevoegen\n"

#, c-format
msgid "Cannot init SELinux management\n"
msgstr "Kan SELinuxbeheer niet initialiseren\n"

#, c-format
msgid "Cannot create SELinux user key\n"
msgstr "Kan de gebruikerssleutel voor SELinux niet aanmaken\n"

#, c-format
msgid "Cannot verify the SELinux user\n"
msgstr "Kan de SELinuxgebruiker niet verifiëren\n"

#, c-format
msgid "Cannot modify SELinux user mapping\n"
msgstr "Kon de gebruikerskoppeling in SELinux niet veranderen\n"

#, c-format
msgid "Cannot add SELinux user mapping\n"
msgstr "Kan in SELinux geen gebruikerskoppeling toevoegen\n"

#, c-format
msgid "Cannot commit SELinux transaction\n"
msgstr "Kan de SELinux-transactie niet vastleggen\n"

#, c-format
msgid "Login mapping for %s is not defined, OK if default mapping was used\n"
msgstr ""
"Geen aanmeldkoppeling gedefinieerd voor %s. OK als de 

Bug#949088: cpm: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Mattia Rizzolo]

Source: cpm
Version: 0.32-1.2
Severity: important
Tags: ftbfs
User: libx...@packages.debian.org
Usertags: ftbfs-2.9.10 xml2-config


Dear maintainer,

your package is using `xml2-config` to detect and use libxml2.  I'm
removing that script, so please update your build system to use
pkg-config instead.

The libxml2 package in experimental already doesn't ship the xml2-config
script.

Attached is the full build log, hopefully relevant excerpt follows:


checking for xml2-config... no
: error: Could not find libxml2 anywhere.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
I: Using pkgname logfile
I: Current time: Thu Jan 16 18:29:31 UTC 2020
I: pbuilder-time-stamp: 1579199371
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [pkgs/cpm_0.32-1.2.dsc]
I: copying [pkgs/cpm_0.32.orig.tar.xz]
I: copying [pkgs/cpm_0.32-1.2.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/mattia/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Wed Dec  7 18:56:09 2016 UTC
gpgv:using RSA key F34F09744E9F5DD9
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./cpm_0.32-1.2.dsc
dpkg-source: info: extracting cpm in cpm-0.32
dpkg-source: info: unpacking cpm_0.32.orig.tar.xz
dpkg-source: info: unpacking cpm_0.32-1.2.debian.tar.xz
I: using fakeroot in build.
I: Installing the build-deps
I: -> Attempting to satisfy build-dependencies
Note, using file '/build/cpm_0.32-1.2.dsc' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  autoconf automake autopoint autotools-dev bsdmainutils debhelper
  dh-autoreconf dh-strip-nondeterminism dirmngr dwz file gawk gettext
  gettext-base gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client
  gpg-wks-server gpgconf gpgsm groff-base intltool-debian libarchive-zip-perl
  libassuan-dev libassuan0 libbsd0 libcdk5-dev libcdk5nc6 libcrack2
  libcrack2-dev libcroco3 libdebhelper-perl libdotconf-dev libdotconf0 libelf1
  libfile-stripnondeterminism-perl libglib2.0-0 libgpg-error-dev libgpgme-dev
  libgpgme11 libksba8 libldap-2.4-2 libldap-common libmagic-mgc libmagic1
  libncurses-dev libncurses6 libnpth0 libpipeline1 libsasl2-2
  libsasl2-modules-db libsigsegv2 libsub-override-perl libtool libuchardet0 m4
  man-db pinentry-curses po-debconf sensible-utils txt2man zlib1g-dev
debconf: delaying package configuration, since apt-utils is not installed
0 upgraded, 65 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/21.0 MB of archives.
After this operation, 63.7 MB of additional disk space will be used.
Selecting previously unselected package libbsd0:amd64.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14048 files and directories currently installed.)
Preparing to unpack .../0-libbsd0_0.10.0-1_amd64.deb ...
Unpacking libbsd0:amd64 (0.10.0-1) ...
Selecting previously unselected package bsdmainutils.
Preparing to unpack .../1-bsdmainutils_11.1.2+b1_amd64.deb ...
Unpacking bsdmainutils (11.1.2+b1) ...
Selecting previously unselected package libuchardet0:amd64.
Preparing to unpack .../2-libuchardet0_0.0.6-3_amd64.deb ...
Unpacking libuchardet0:amd64 (0.0.6-3) ...
Selecting previously unselected package groff-base.
Preparing to unpack .../3-groff-base_1.22.4-4_amd64.deb ...
Unpacking groff-base (1.22.4-4) ...
Selecting previously unselected package libpipeline1:amd64.
Preparing to unpack .../4-libpipeline1_1.5.2-2_amd64.deb ...
Unpacking libpipeline1:amd64 (1.5.2-2) ...
Selecting previously unselected package man-db.
Preparing to unpack .../5-man-db_2.9.0-2_amd64.deb ...
Unpacking man-db (2.9.0-2) ...
Selecting previously unselected package libsigsegv2:amd64.
Preparing to unpack .../6-libsigsegv2_2.12-2_amd64.deb ...
Unpacking libsigsegv2:amd64 (2.12-2) ...
Setting up libsigsegv2:amd64 (2.12-2) ...
Selecting previously unselected package gawk.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 

Bug#949087: cluster-glue: FTBFS with libxml2 2.9.10 (uses xml2-config)

[Mattia Rizzolo]

Source: cluster-glue
Version: 1.0.12-14
Severity: important
Tags: ftbfs
User: libx...@packages.debian.org
Usertags: ftbfs-2.9.10 xml2-config


Dear maintainer,

your package is using `xml2-config` to detect and use libxml2.  I'm
removing that script, so please update your build system to use
pkg-config instead.

The libxml2 package in experimental already doesn't ship the xml2-config
script.

Attached is the full build log, hopefully relevant excerpt follows:


checking for special libxml2 includes... configure: error: libxml2 config not 
found
make[1]: *** [debian/rules:20: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/build/cluster-glue-1.0.12'
make: *** [debian/rules:14: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
I: Using pkgname logfile
I: Current time: Thu Jan 16 17:23:30 UTC 2020
I: pbuilder-time-stamp: 1579195410
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [pkgs/cluster-glue_1.0.12-14.dsc]
I: copying [pkgs/cluster-glue_1.0.12.orig.tar.bz2]
I: copying [pkgs/cluster-glue_1.0.12-14.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/mattia/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Tue Oct 15 17:47:31 2019 UTC
gpgv:using RSA key C5A5B9DDC33D93FBB63D67C83287D89A97CDA87B
gpgv:issuer "vvi...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./cluster-glue_1.0.12-14.dsc
dpkg-source: info: extracting cluster-glue in cluster-glue-1.0.12
dpkg-source: info: unpacking cluster-glue_1.0.12.orig.tar.bz2
dpkg-source: info: unpacking cluster-glue_1.0.12-14.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-libtoolize_check.patch
dpkg-source: info: applying 
0002-Fix-spelling-of-output-and-improve-grammar.patch
dpkg-source: info: applying 0003-Remove-.hgtags-from-source.patch
dpkg-source: info: applying 0004-Remove-.hgignore-from-source.patch
dpkg-source: info: applying 0005-Remove-.hgsigs-from-source.patch
dpkg-source: info: applying kfbsd.diff
dpkg-source: info: applying hurd.diff
dpkg-source: info: applying x32-cl_times
dpkg-source: info: applying ipc_param_type
dpkg-source: info: applying python3.patch
dpkg-source: info: applying spelling.patch
dpkg-source: info: applying systemd-doc.patch
dpkg-source: info: applying openipmi-selector.patch
dpkg-source: info: applying perl-interpreter.patch
dpkg-source: info: applying asciidoctor.patch
dpkg-source: info: applying file_paths.patch
dpkg-source: info: applying ha_logger_man.patch
I: Not using root during the build.
I: Installing the build-deps
I: -> Attempting to satisfy build-dependencies
Note, using file '/build/cluster-glue_1.0.12-14.dsc' to get the build 
dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  asciidoctor autoconf automake autopoint autotools-dev bison bsdmainutils
  ca-certificates chrpath debhelper dh-autoreconf dh-python
  dh-strip-nondeterminism dmsetup docbook-xml docbook-xsl dwz file flex
  gettext gettext-base groff-base help2man inetutils-ping intltool-debian
  libaio-dev libaio1 libapparmor1 libarchive-zip-perl libargon2-1 libblkid-dev
  libbrotli1 libbsd0 libbz2-dev libcap2 libcroco3 libcryptsetup12 libcurl4
  libcurl4-openssl-dev libdbus-1-3 libdbus-1-dev libdbus-glib-1-2
  libdbus-glib-1-dev libdbus-glib-1-dev-bin libdebhelper-perl
  libdevmapper1.02.1 libedit2 libelf1 libffi-dev
  libfile-stripnondeterminism-perl libgdbm-dev libglib2.0-0 libglib2.0-bin
  libglib2.0-data libglib2.0-dev libglib2.0-dev-bin libgssapi-krb5-2 libidn11
  libip4tc2 libjson-c4 libk5crypto3 libkeyutils1 libkmod2 libkrb5-3
  libkrb5support0 libldap-2.4-2 libldap-common liblocale-gettext-perl
  libltdl-dev libltdl7 libmagic-mgc libmagic1 libmount-dev libncurses-dev
  libncurses5-dev libncurses6 libnet1 libnet1-dev libnghttp2-14 libopenhpi-dev
  libopenhpi3 libopenipmi-dev libopenipmi0 libpam0g-dev libpci-dev libpci3
  libpcre16-3 libpcre2-16-0 libpcre2-32-0 libpcre2-dev libpcre2-posix2
  libpcre3-dev libpcre32-3 libpcrecpp0v5 libpipeline1 libpopt0 libprocps7
  libpsl5 librabbitmq4 librtmp1 libruby2.5 libsasl2-2 libsasl2-modules-db
  libselinux1-dev libsensors-config libsensors4-dev libsensors5 libsepol1-dev
  libsigsegv2 libsnmp-base libsnmp-dev libsnmp35 libssh2-1 libssl-dev
  libsub-override-perl libtool 

Bug#949038: python-watson-developer-cloud: autopkgtest regression: No module named 'watson_developer_cloud'

[Simon McVittie]

On Thu, 16 Jan 2020 at 12:23:51 +0100, Paul Gevers wrote:
> It seems that
> due to the rename of the binary package, autopkgtest logic doesn't apply
> anymore.  autodep8 recently acquired a new feature that enables you to
> tell autode8 what the real module name is that should be tested [0].

I think this also illustrates that the transitional package is probably
inappropriate in this case: the API of python3-watson-developer-cloud is
"you can import watson_developer_cloud and use it", but that isn't actually
true here. So the autopkgtest has correctly identified a bug?

If there were existing packages that depended on
python3-watson-developer-cloud, they would now be broken (unable to import
watson_developer_cloud despite still having the right dependency), and would
need source changes to update their imports to ibm_watson - at which point
they might as well also update their dependency to python3-ibm-watson,
making the transitional package somewhat pointless.

(However, according to dak, there are currently no such packages.)

smcv

Bug#948722: qemu-block-extra, (build-)dependencies unsatisfiable on mipsel.

[Bernd Zeimetz]

Hi,

I might have a workaround, if ceph-dencoder is the only piece that fails.

Unfortunately I doubt it is, but I'll give it a try in experimental soon.

Bernd

Am 16. Jänner 2020 00:55:11 MEZ schrieb peter green :
>On 14/01/2020 10:24, Michael Tokarev wrote:
>> Control: severity -1 normal
>> Control: tag -1 + moreinfo
>>
>> 12.01.2020 18:37, peter green wrote:
>>> Package: qemu-block-extra
>>> Version: 1:4.2-1
>>> Severity: serious
>>>
>>> The binary packages built from the ceph source package were recently
>removed from mipsel, because the new version of ceph runs out of
>address space
>>> during the build. Your package build-depends on libradios-dev and
>librbd-dev and depends on librados2 and librbd1 which are built from
>the ceph source
>>> package. So qemu-block-extra is now uninstallable and the qemu
>source package is unbuildable on mipsel.
>> Hm. For the start, I see that new ceph packages are being built on
>mips/mips64
>> right now as I write this. So things aren't that simple, at least.
>
>Ceph 14.2.4 was uploaded to unstable in late december, but failed to
>build on many architectures. The maintainer found workarounds for most
>of them, but could not find any soloution to the address space
>exhaustion issue on mipsel (when a build says "out of memory" it nearly
>always really means out of address space).
>
>With version 14.2.4-8 the maintainer decided it was time to give up on
>mipsel, he removed mipsel from the architecture lists and filed a
>removal request with the ftp masters.
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947887
>
>It seems that with version 1.4.2.5-1 mipsel was quietly re-added to the
>achitecture list, I do not know if this was a mistake or if the
>maintainer was deliberately testing if the problem had gone away.
>Either way ceph has continued to fail to build on mipsel.
>
>> Next, even if we're now uninstallable on some architecture, it is
>definitely not
>> our fault,
>
>It's not about "fault".
>
>> so I don't see why this bugreport is of serious severity.
>rc policy "Packages must be buildable within the same release."
>
>I'm not going to play severity ping-pong with you, but I am ccing the
>ceph maintainers and the release team in-case they want to give a
>position on this.
>>   Also, it has
>> nothing to do with this particular version of qemu, either.
>True enough, afaict normal practice is to file bugs against the current
>version in testing/unstable unless there is reason not to.
>>And more, it has
>> nothing to do with qemu-block-extra package, too, even if that's the
>only pkg
>> which actually uses the library in question, -- we _build_-depend on
>librados-dev
>> too, so it is qemu source which FTBFS on mips.
>If you would preffer to reassign to the source package that is fine by
>me, doesn't make much practical difference.
>>
>> So far I don't quite understand what's going on with ceph on mips,
>hence adding
>> a "moreinfo" tag. We shouldn't drop optional features on different
>architectures
>> easily,
>
>If I thought this was just some transient issue I wouldn't have
>bothered filing this bug, but I doubt it is.
>
>>   or else it would quickly become a mess, not understanding which
>features
>> of which packages are enabled on which architecture (I speak here
>about general
>> debian, not about this particular (pair of) package).
>At some point I think Debian needs to have a hard think about how
>32-bit architectures are supported, possiblly introducing official
>support for cross-building heavier packages, but so-far there doesn't
>seem to have been a strong will to do so.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#948735: apt doesn't completely remove "postgresql-11" dependencies

[Алексей Шилин]

В Вс, 12/01/2020 в 22:06 +, Mario E. Weisz пишет:
> $ apt rdepends postgresql-client-11 --installed
> 
> returns nothing (empty result).
> 
> The install/remove/autoremove sequence was executed right after a
> fresh installation.
> 

postgresql-common installs the following configuration snippet to
/etc/apt/apt.conf.d/01autoremove-postgresql:

   // File installed by postgresql-common. Currently not updated
   automatically,
   // but might be in future releases.
   //
   // We mark all PostgreSQL packages as NeverAutoRemove because
   otherwise apt
   // would remove the old postgresql-NN package when the "postgresql"
   meta
   // package changes its dependencies to a new version, rendering the
   old
   // database cluster inaccessible. As access to the cluster might
   depend on
   // other modules (like datatypes), we use a pretty wide pattern
   here. We might
   // tighten this to match only actually used PostgreSQL versions in
   the future.

   APT
   {
 NeverAutoRemove
 {
   "^postgresql-";
 };
   };

I guess, this answers your question.

It's obvious that APT is not in fault here and behaves exactly as it's
supposed to.

Bug#876131: qtbase-opensource-src FTCBFS: uses the build architecture toolchain

[Dmitry Shachnev]

Hi Helmut!

On Thu, Jan 16, 2020 at 08:25:47PM +0100, Helmut Grohne wrote:
> I can explain this. Please compare the relevant mkspecs:
>
> https://sources.debian.org/src/qtbase-opensource-src/5.12.5+dfsg-5/mkspecs/linux-g++/qmake.conf/
> https://sources.debian.org/src/qtbase-opensource-src/5.12.5+dfsg-5/mkspecs/linux-aarch64-gnu-g++/qmake.conf/
>
> You'll quickly observe that they look much the same with one key
> difference. The arm64 one has all the tools prefixed with the GNU
> triplet. And that's precisely the property we need here. In principle,
> could mechanically generate a similar mkspec for any other architecture.
> It is much like a CMake toolchain file or a meson toolchain file. We
> need it to tell QT which architecture to build for.
>
> Possibly we could patch a new linux-debian-g++ mkspec that sets up the
> variables based on the dpkg-architecture environment variables. If we go
> that route, make sure not to install that into a binary package. Prior
> art: linux-oe-g++
> (https://github.com/meta-qt5/meta-qt5/wiki/Building-with-OE).

I wonder if we can use the linux-g++ mkspec and pass QMAKE_CXX and similar
variables to configure, just like we pass them to qmake for cross builds:

https://salsa.debian.org/qt-kde-team/qt/qtbase/blob/master/debian/qmake-cross-wrapper.in

configure just passes its options to qmake anyway:

https://sources.debian.org/src/qtbase-opensource-src/5.12.5+dfsg-5/configure/#L857

Or maybe set external-hostbindir to /usr/lib/${DEB_BUILD_MULTIARCH}/qt5/bin,
in which case qmake will be a symlink to qmake-cross-wrapper? Though thinking
more about it, in this case the real qmake will get two -qtconf options, of
which the latter (added by configure) will be wrong. So that will probably not
work.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#948987: libssl: libssl1.1 segfaults when kopete is using it (libjingle-call)

[Sebastian Andrzej Siewior]

control: reassing -1 kopete 4:17.08.3-2.1
control: retitle -1 kopete: segfaults when is using it (libjingle-call)

On 2020-01-16 13:55:17 [+0100], Jens Schmidt wrote:
> Dear Sebastion,
> 
> yes, it seems that way.
> I dit not look at the kopete package for the bug, since libssl was the thing
> that is crashing.

verry well. It seems that the library is used wrongly.

Let me reassing the bug then to the proper department. I used version
4:17.08.3-2.1 since this is what is in Buster and you used the Buster
version for your bug. If you have another version please let the bug
know.

> Cheers Jens

Sebastian

Bug#949084: libslirp: CVE-2020-7039

[Salvatore Bonaccorso]

Source: libslirp
Version: 4.1.0-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerability was published for libslirp.

CVE-2020-7039[0]:
| OOB buffer access while emulating tcp protocols in tcp_emu()

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-7039
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7039
[1] https://www.openwall.com/lists/oss-security/2020/01/16/2
[2] 
https://gitlab.freedesktop.org/slirp/libslirp/commit/2655fffed7a9e765bcb4701dd876e9dab975f289

https://gitlab.freedesktop.org/slirp/libslirp/commit/ce131029d6d4a405cb7d3ac6716d03e58fb4a5d9

https://gitlab.freedesktop.org/slirp/libslirp/commit/82ebe9c370a0e2970fb5695aa19aa5214a6a1c80

Regards,
Salvatore

Bug#948697: apt-listbugs: Listbugs-spawned QueryBTS can't find Firefox

[Calum McConnell]

Bug#938419: ruby-github-markup: Python2 removal in sid/bullseye

[Matthias Klose]

On 16.01.20 20:28, Pirate Praveen wrote:
> Control: tags -1 help
> 
> On Fri, 30 Aug 2019 07:51:22 + Matthias Klose  wrote:
>> Python2 becomes end-of-live upstream, and Debian aims to remove
>> Python2 from the distribution, as discussed in
>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>>
>> Your package either build-depends, depends on Python2, or uses Python2
>> in the autopkg tests.  Please stop using Python2, and fix this issue
>> by one of the following actions.
>>
>> - Convert your Package to Python3. This is the preferred option.  In
>>   case you are providing a Python module foo, please consider dropping
>>   the python-foo package, and only build a python3-foo package.  Please
>>   don't drop Python2 modules, which still have reverse dependencies,
>>   just document them.
>>     This is the preferred option.
> 
> I have tried to port this package to python 3, but one test is failing now.
> Changes are pushed to salsa master branch. I need help in fixing this.
> 
>   1) Failure:
> MarkupTest#test_rst [/<>/test/markup_test.rb:71]:
> README.rst.html's contents are not html equal to output:

at least in Ubuntu I saw that failure with Python2 as well, with a no-change
rebuild.

Bug#949006: debian-policy: Stop recommending stamp files in debian/rules

[Niels Thykier]

Jonathan Nieder:
> Niels Thykier wrote:
> 
>> debhelper cannot see "inside" the upstream build system.  If you modify
>> a .c file, debhelper won't notice and will currently just skip the
>> entire build.  Alternatively, debhelper will have to invoke the build
>> system and rely on it to not be flawed.
> 
> Yes, I think that would be a good behavior (invoking the build system
> and if it's flawed, let the packager work with upstream on it).
> Especially because the effect is directly on the packagers --- buildds
> wouldn't be hurt by this, as you note.
> 
> Is that the proposed debhelper change?  Where can I sign up? :)
> 

You can get this behaviour today with:

dh $@ --without build-stamp

(You probably want to implement "Rules-Requires-Root: no" first)

My idea would be to use Rules-Requires-Root as conditional to whether
the build-stamp should be enabled by default in a future compat level.
The rationale for that conditional being that we do not want to invoke
the build system as root by default.

>> AFAICT, the current practise recommended by policy have the same issue
>> (assuming you implement the stamp file or touch the "build" file).
> 
> Right, using "touch build" or build-stamp is a last resort, for
> dealing with irreperable upstream build systems.  Having a proper
> upstream build system is much better (and isn't all that rare).
> 
> Thanks,
> Jonathan
> 


Thanks,
~Niels

Bug#938419: ruby-github-markup: Python2 removal in sid/bullseye

[Pirate Praveen]

Control: tags -1 help

On Fri, 30 Aug 2019 07:51:22 + Matthias Klose  wrote:

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.


I have tried to port this package to python 3, but one test is failing 
now. Changes are pushed to salsa master branch. I need help in fixing this.


  1) Failure:
MarkupTest#test_rst [/<>/test/markup_test.rb:71]:
README.rst.html's contents are not html equal to output:

Bug#942540: removing some files should help

[Bjoern Franke]

see 
https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/PAMC4L5LALDRWXTUNJMQCL4AQRJEMEVF/


But afterwards, it crashes with another issue:

Traceback (most recent call last):
  File "/usr/bin/django-admin", line 21, in 
management.execute_from_command_line()
  File 
"/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 364, in execute_from_command_line

utility.execute()
  File 
"/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 308, in execute

settings.INSTALLED_APPS
  File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 
56, in __getattr__

self._setup(name)
  File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 
41, in _setup

self._wrapped = Settings(settings_module)
  File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 
110, in __init__

mod = importlib.import_module(self.SETTINGS_MODULE)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in 
import_module

return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1006, in _gcd_import
  File "", line 983, in _find_and_load
  File "", line 965, in 
_find_and_load_unlocked

ModuleNotFoundError: No module named 'settings'

Bug#938409: Bug#941669: python3-rpi.gpio fails to work on aarch64 (upgrade needed)

[Peter Green]

On 07/01/2020 13:55, andred wrote:

On Tue, Jan 7, 2020 at 9:22 AM Peter Green  wrote:

have either of you tested 0.7.0 on a Pi running Debian arm64

Yes, v0.7.0 (from pypi.org) works fine here on Debian arm64.

Thanks.

I have just prepared a package of 0.7.0, I would appreciate people testing it, 
both on systems where it worked before and on systems where it is currently 
broken.

This package also drops python 2 support in-line with the general effort to 
remove python 2. I'm not sure why sandro's script hasn't bumped the python 2 
removal bug on this package to serious, despite their being no 
reverse-dependencies. Maybe it's been confused by the fact that this package is 
not currently in testing or the limited architecture list.

I also discovered a missing build-dependency on dh-python, so I added that.

I have attached a debdiff to this mail, I have also posted source and binary 
packages (for armhf and arm64) at https://plugwash.raspbian.org/rpi.gpio/

If I get positive feedback from users or get around to setting up a test 
environment to test this myself then I will NMU this.
diff -Nru rpi.gpio-0.6.5/CHANGELOG.txt rpi.gpio-0.7.0/CHANGELOG.txt
--- rpi.gpio-0.6.5/CHANGELOG.txt2018-11-16 10:05:26.0 +
+++ rpi.gpio-0.7.0/CHANGELOG.txt2019-07-21 13:42:56.0 +
@@ -1,6 +1,15 @@
 Change Log
 ==
 
+0.7.0
+---
+- Updated RPI_INFO to include RPi 4B
+- Fixed pull up/down for Pi4 (issue 168)
+- Fix spelling mistake in docstrings
+- Tested and working on Raspbian Buster + Python 3.8.0b2
+- Fix board detection for aarch64 (Issues 161 / 165)
+- Fix checking mmap return value in c_gpio.c (issue 166)
+
 0.6.5
 -
 - Fix exception on re-export of /sys/class/gpio/gpioNN
diff -Nru rpi.gpio-0.6.5/debian/changelog rpi.gpio-0.7.0/debian/changelog
--- rpi.gpio-0.6.5/debian/changelog 2019-01-13 13:50:43.0 +
+++ rpi.gpio-0.7.0/debian/changelog 2020-01-16 16:20:40.0 +
@@ -1,3 +1,14 @@
+rpi.gpio (0.7.0-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release
+- Fixes pi detection on arm64 (Closes: 941669)
+- Adds Raspberry pi 4 support.
+  * Drop python 2 support (Closes: 938409)
+  * Drop spelling.patch (fixed upstream)
+
+ -- Peter Michael Green   Thu, 16 Jan 2020 16:20:40 +
+
 rpi.gpio (0.6.5-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru rpi.gpio-0.6.5/debian/control rpi.gpio-0.7.0/debian/control
--- rpi.gpio-0.6.5/debian/control   2019-01-13 13:50:43.0 +
+++ rpi.gpio-0.7.0/debian/control   2020-01-16 16:20:40.0 +
@@ -6,13 +6,10 @@
 Priority: optional
 Build-Depends:
  debhelper (>= 11~),
- dh-python,
- python-all (>= 2.6.6-3),
- python-all-dev,
- python-setuptools (>= 0.6b3),
  python3-all,
  python3-all-dev,
  python3-setuptools,
+ dh-python,
 Standards-Version: 4.3.1
 Homepage: http://sourceforge.net/projects/raspberry-gpio-python/
 Vcs-Git: https://salsa.debian.org/raspi-team/rpi.gpio.git
@@ -32,21 +29,6 @@
  .
  This package contains common files, for example udev rules.
 
-Package: python-rpi.gpio
-Architecture: arm64 armel armhf
-Depends:
- ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
-Description: Module to control Raspberry Pi GPIO channels (Python 2)
- RPi.GPIO allows controlling Raspberry Pi GPIO channels in Python.
- .
- It provides all the basic functionality, but is unsuitable for
- real-time or timing critical applications. RPi.GPIO also does not
- support SPI, I²C or hardware PWM yet.
- .
- This package contains the Python 2 module.
-
 Package: python3-rpi.gpio
 Architecture: arm64 armel armhf
 Depends:
diff -Nru rpi.gpio-0.6.5/debian/patches/series 
rpi.gpio-0.7.0/debian/patches/series
--- rpi.gpio-0.6.5/debian/patches/series2018-10-26 17:45:22.0 
+
+++ rpi.gpio-0.7.0/debian/patches/series1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-spelling.patch
diff -Nru rpi.gpio-0.6.5/debian/patches/spelling.patch 
rpi.gpio-0.7.0/debian/patches/spelling.patch
--- rpi.gpio-0.6.5/debian/patches/spelling.patch2018-06-12 
12:22:46.0 +
+++ rpi.gpio-0.7.0/debian/patches/spelling.patch1970-01-01 
00:00:00.0 +
@@ -1,13 +0,0 @@
-From: Dominik George 
-Subject: Fix spelling in upstream source
 a/source/py_gpio.c
-+++ b/source/py_gpio.c
-@@ -962,7 +962,7 @@ PyMethodDef rpi_gpio_methods[] = {
-{"getmode", py_getmode, METH_VARARGS, "Get numbering mode used for channel 
numbers.\nReturns BOARD, BCM or None"},
-{"add_event_detect", (PyCFunction)py_add_event_detect, METH_VARARGS | 
METH_KEYWORDS, "Enable edge detection events for a particular GPIO 
channel.\nchannel  - either board pin number or BCM number depending on 
which mode is set.\nedge - RISING, FALLING or BOTH\n[callback]   - A 
callback function for the event (optional)\n[bouncetime] - Switch bounce 
timeout in ms for callback"},
-{"remove_event_detect", py_remove_event_detect, 

Bug#876131: qtbase-opensource-src FTCBFS: uses the build architecture toolchain

[Helmut Grohne]

Hi Lisandro,

On Thu, Jan 16, 2020 at 04:07:24PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > I also updated the patch to the current version.
> > 
> > Limitations:
> >  * Only works for arm64 and armel since no other architectures have
> >matching mkspecs
> 
> I'm wondering why we don't use linux-g++ too, as it has been happening on all 
> other archs.

I can explain this. Please compare the relevant mkspecs:

https://sources.debian.org/src/qtbase-opensource-src/5.12.5+dfsg-5/mkspecs/linux-g++/qmake.conf/
https://sources.debian.org/src/qtbase-opensource-src/5.12.5+dfsg-5/mkspecs/linux-aarch64-gnu-g++/qmake.conf/

You'll quickly observe that they look much the same with one key
difference. The arm64 one has all the tools prefixed with the GNU
triplet. And that's precisely the property we need here. In principle,
could mechanically generate a similar mkspec for any other architecture.
It is much like a CMake toolchain file or a meson toolchain file. We
need it to tell QT which architecture to build for.

Possibly we could patch a new linux-debian-g++ mkspec that sets up the
variables based on the dpkg-architecture environment variables. If we go
that route, make sure not to install that into a binary package. Prior
art: linux-oe-g++
(https://github.com/meta-qt5/meta-qt5/wiki/Building-with-OE).

> Should we really close the bug here? I would keep it open until we make it 
> work.

I tend to use Debian bugs as patch tracking ids for getting changes into
packages. We could file FTCBFS bugs for any package that doesn't cross
build, but I wouldn't find that useful. If you think there is something
actionable left, I don't mind leaving it open. Otherwise I prefer
closing it.

> Would the following comment be ok?
> 
> # Check we are cross building with the exact same Qt version.
> > +ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
> > +   test "`dpkg-query -f '$${Version}' -W qt5-qmake-bin`" = "$(DEB_VERSION)"
> > +endif

Yes, though in my book the comment just explains the code. I'd rather
write down the intention:

# Refuse building with a qmake whose version differs from the package.

Helmut

Bug#876131: qtbase-opensource-src FTCBFS: uses the build architecture toolchain

[Lisandro Damián Nicanor Pérez Meyer]

Hi again!

On Thu, 16 Jan 2020 at 16:07, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi Helmut!
>
> On 20/01/16 07:41, Helmut Grohne wrote:
> > Hi,
> >
> > On Mon, Sep 18, 2017 at 05:04:40PM -0300, Lisandro Damián Nicanor Pérez 
> > Meyer wrote:
> > > The only way I could accept that if we could build-depend on a
> > > specific version (the same version we are trying to compile).
> > >
> > > Helmut told me that's not possible, and I know from experience that
> > > having a window opened to build qt with an oder qmake it's calling for
> > > big troubles.
> >
> > We arrived at a compromise: Turn the check into a build-time check.
> > Rather than having dpkg-checkbuilddeps verify the property, we can have
> > debian/rules check the version.
>
> Totally agreed.
>
> > I also updated the patch to the current version.
> >
> > Limitations:
> >  * Only works for arm64 and armel since no other architectures have
> >matching mkspecs
>
> I'm wondering why we don't use linux-g++ too, as it has been happening on all 
> other archs.

I'm comparing the mkspecs and the only thing that changes are the
qmake.conf files that set up the necessary QMAKE_* variables. The
qplatformdefs.h files are just includes of the linux-g++ one.

So yes, we could easily hack something here. Question is... how?

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

Bug#949083: krfb FTBFS: error: field 'm_clientActions' has incomplete type 'QHash'

[Helmut Grohne]

Source: krfb
Version: 4:17.08.3-1
Severity: serious
Tags: ftbfs

kfrb fails to build from source in unstable:

| In file included from /<>/krfb/trayicon.cpp:19:
| /<>/krfb/trayicon.h:44:39: error: field 'm_clientActions' has 
incomplete type 'QHash'
|44 | QHash m_clientActions;
|   |   ^~~
| In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1204,
|  from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qnamespace.h:43,
|  from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs.h:48,
|  from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:46,
|  from /usr/include/x86_64-linux-gnu/qt5/QtCore/QObject:1,
|  from 
/usr/include/KF5/KNotifications/kstatusnotifieritem.h:24,
|  from /usr/include/KF5/KNotifications/KStatusNotifierItem:1,
|  from /<>/krfb/trayicon.h:21,
|  from /<>/krfb/trayicon.cpp:19:
| /usr/include/x86_64-linux-gnu/qt5/QtCore/qtypeinfo.h:223:1: note: declaration 
of 'class QHash'
|   223 | Q_DECLARE_MOVABLE_CONTAINER(QHash);
|   | ^~~

Also reproducible by reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/krfb_17.08.3-1.rbuild.log.gz

Also seen by crossqa since around September 2019:
http://crossqa.debian.net/build/krfb_4:17.08.3-1_armhf_20190922042109.log

Helmut

Bug#949082: guile-2.2: include debian/watch file and signing key

[Vagrant Cascadian]

Source: guile-2.2
Severity: minor
Tags: patch

The debian/watch file helps checking for updated versions (such as, say,
3.0.0!); The patch below adds a debian/watch file and upstream signing
key.

live well,
  vagrant

 debian/upstream/signing-key.asc | 77 +
 debian/watch|  3 ++
 2 files changed, 80 insertions(+)
 create mode 100644 debian/upstream/signing-key.asc
 create mode 100644 debian/watch

diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
new file mode 100644
index 000..ab74f50
--- /dev/null
+++ b/debian/upstream/signing-key.asc
@@ -0,0 +1,77 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+
+mQINBFmLEIkBEAC7U27v6jysuSadTd8WK0lTnoK4TueYHey17+KWilOXrGx80R1Q
+kjIPDfQaTX76F3CQ22EeIXEYBZ858WImkrkolhEvoeJHOXkgJnib2EA6d7oXINkO
+UIij5cH0GCoEuw+aU415OAHK/cv09WXeDVy7/cwfhPAUc5QmWQzOEwuaV0ERd1Mw
+q3yxhiXN5wOS77TXKYNTMiXp4NdXgYwJFqO0e/POKPrzWSVqeZClh+ecXenapZDd
+R120+qRtC/Kz9YwupJPz7FImAC4XOYqZXY3ILft8Y6nCj/iE8ArIsJGF+zfz0m4L
+7wJfcN1gZ2sjgzjX51USi7Y39ra2MemnbBrPG+6cR/aGvScd4V/CYoAJDB+WumhP
+clksxTS1s4PPVELwLvbF+3trwrkKyWMCEg2kTTUQxExYe9QavSPh9p3tKpi3SNns
+K/hndxGKtTrH8OVe32r93Bt8w7IqYMxwEgr4wCAgF6RCZhks5PlXaLzrrAW80aak
+ZU8wVCfZPQO0rZ1e2m+gLmG4rkw0kB4nkBF3I+oYM2WABGXGA7G6pDgszBQIbkQf
+FXaWWxtLvNKtlm458Mf+Dc6VaIcVY32Wkpeu3ev9WkeDOZIIPu6dKA1mLZexODBT
+9uXKMIqB1Gj2ysUGgPGBwzcf5XYqjGxuCgWmCfxv70dh/PInn7W3Le1x0QARAQAB
+tBxBbmR5IFdpbmdvIDx3aW5nb0Bwb2JveC5jb20+iQJRBBMBCAA7AhsDBQsJCAcD
+BRUKCQgLBRYCAwEAAh4BAheAFiEET9TSiNRFk04KFPmlqIA3MuRDaIUFAlmLEf0C
+GQEACgkQqIA3MuRDaIUo7w//UQTnuOXmE0Z+w9prtcsq0myF6bipdsJulSwnbZzq
+nKI8rlgvKqJBHXhEHq2EC4hsgbnEb2wW61LeZvzyN6wi7HOH5z6/xNWZSUnmCM8Z
+H+eIKL+EQ/BgNDM0hkak8J2xZ/6/ZbbhwYF6FPNMg1PFQ/rHtOw9emjAUUUItrRD
+JYRMyA6HtRXn5kPKYzptkwGN5QVJMBjL9Ya5i6G+mDzxO8b1gLt08CYv/ZovNfJG
+y9I3+r7gC2k7/FKXnfUz3vmYKpNYoBL7OycPFWp36k8KH55hTbLZR68jbpFH+4iy
+TyuSWpNKiBg6pU0lvoFPyDFDPQUU3iA/T+GCj8UCB+zGeGic+NgVAMJgOni/nA4X
+tcrGf4QCMi16QP7QM5mZmZV9AxjdsdzKxhDt9M4FpPVyQqxayDUP5RCYimdItcTz
+Ai8pop2t+B53NjFDddfgMPx4CfVgHBnqYiAXJ1PvYSGwRn6pp+64KSOKxKNuLJox
+PF+2kOrY6Q9JTNpqG7beunRJQ3Nl9FItG26C/F79vQEQVcoU7Qu7efFcAdc+Bss7
+5jUl4KS5TpvxxbplSrk8i/FsS2kGdSmniy1gKN+TAv+7wddDSaeL2/ptOKAmU8uJ
+zwxW77gh5i6N5Sc6RmAlnMvohhbjEoDHNTOjN/MVnheXMS0MYWE4ahlBiTjqETck
+roq0HUFuZHkgV2luZ28gPHdpbmdvQGlnYWxpYS5jb20+iQJOBBMBCAA4FiEET9TS
+iNRFk04KFPmlqIA3MuRDaIUFAlmLEcgCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgEC
+F4AACgkQqIA3MuRDaIWZChAApzEgZZCKZjoOTExbTzx7UvmYoarU52Kuz1H/Ev4A
+Ej3OrypHSXbt+O8NJUkgh8b8XQT9C0CoBhr8hwC3JOmyihKjqodSAS9BVJlpQ+4u
+lbu78HmqvABuuExsPGF8me5kRqjCn++1wSkQ2Ri4Lr3KUcT/lZRA9mI6qkyY4iTn
+XcpEFjfKwhIiGIPchy0GjcfogGz78TndlDJoJKtbLMaouQ33bdo01sJKCVWIQhag
+15hrL8rAQjxr7zz+4IIuHLwZewqUAsX9hqGPgmBZBfVHccPpVh9zfMaP1at9jXzV
+dys9YXJfHDzM680h7QvidLl10JvgEZkJbx4fGWdyG7R56FxOM9isrSdQ8kYPthyb
+SXm9oK7XQOV9nmrWUKAOeokPI9eimgtRjemEdo5MiUH1Dkc0xeoqc5wE64OFrUAc
+ASc0plU2ff6jsSNq7Q+Q4U9z3tdB8zTz+lCSQZOfgIk3baAAEUCE9v9DDXT20B3E
+C+zZuifPVmKRYIQxbA3Epx4Yh/IBc8kqIHHTW0NTMotKdzNZzC1o6putfmRvzHa4
+8VU8JHoR3x6TmG65B2Agw9j7As5ve0UUSq7mpYqAMgg6jW4rzIsYZc//93liR6i2
+5fsupFpDBPK3fip1H08LhljsFgdRnrPVz+b8MZpujAErqusLSNxxiDJBUBQTHNwZ
+lO60GkFuZHkgV2luZ28gPHdpbmdvQGdudS5vcmc+iQJOBBMBCAA4FiEET9TSiNRF
+k04KFPmlqIA3MuRDaIUFAlmLEdQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AA
+CgkQqIA3MuRDaIW5TA/9FmTktjFCuF41rlrXNW7DN4FzFmP1oO5t7QgTnNau/aWt
+64hUZQ04j5DgQ8Rr9gqPQdpZB6yhIf9dQui7ynuE4xhrjUu63qWxSGQwkyjB0BSY
+JVUJPGa3K+5ZD06SG3Ch1smOJVTp0D4pmdMZHrp8Hf9dfSyzfzXDSxLilUZaQ3fP
+r/xMYR6LeVV71XyuNEzQ7H9YeF1GuO2+JHEMDbUUIgWi/SISJfVhBTHnlefiRvGX
+K8Cy3S2LQ92j2g8HB5a5tYuUB+7ZbQBtCxCixOmOczbVpRzE/fVnQS7K5r0MLFP+
+u14s0zWosGS0f01l5g0VbNmYX5G/EiP2g9jx+sThvXBKv3uvHnvjauB1k4pBj+/w
+CsBsZhyomjsMEAVsLa6QhyhGo2sFpoisF6zLk3yM7Hz2VbLy7rtEtu27BkIZ6yi9
+CKLMu5M9VQ0JtQyuKhuXkWL3P6tgh0tvKxv5xM+gXqwiBQHF2KV9oW65bcdZaHfa
+wH3zZwIppSHKiJ+AUmeiOd9/+MKc46symEhsx5jUtuaH2rNb1SYLsnJlVMcWaHul
+Gw1ZBYaLwWWFMJtJsi+vq5VxXex3/VMSByU2S/PS1+tk6RgKbmsuIZZ6knR8VefG
+C33ZKqVQjfgTC0B7iDs3cgr982kvTURt2t0bhz+fMCu7/ohzkw6VhgJcjHFenvS5
+Ag0EWYsQiQEQAMuqr/iDzidezZ6T520DDCUsx1sypvAYtmClrIdXMwpd37uGTbp+
++5Cf2NNgRJsyf3jhNsWuxoAPJhjrqsr6c8FlAapki4PUvBDtW4bQg6m3T08fSk5C
+Lpk+oUXGH0zceDgwnz8mSRcKBBdpC4O69P8cp3L0DdrDikSNye6ZTwdMc+PSvZcs
++c+7O2UZSeuxPvLRr3u5jahJGmXzySzTbwe/xzhGhQSetfYEFx/SbDZSZA7Det2W
+tR+prIDaX+CtGhFXrBqkKiXKqhpjTdN7vqaHx8wATdOJ5YACvkb1XsfHpjtOnna2
+DvuOln7iQNt9CwwiXmX6WvEAc21IpkcY53WQDXz6TFmtGyrQsCB0mawi7gAU1N4Z
+b+a5TGSD/aHLUpoHBe7pOy/c+wDJFRkK1scVS6gPxQwhy7IqzAxYWo3D7bQFurFT
+QVFfcRVQfZYIUIfm6MrHvygsyJ5rJCQ8rCUR4f7iGGM4LkPYQVRi2zUopql5uejZ
+MoqvLRSB8IeP/ItDgsdXq9JHSyIlwatZNRqHDQzHqQ4n+GaNckfDQ1aK/2/zh7rp
+YOprOwqo1DvQIlg1RnbjiXPnv48aae3jpeV9BDRN1Nd2TzQsm6diA7MITnmYji1N
+AJMigOcpHEKVM0EPaNeMahjhoA1uJPn8T+eK0nzuqiD3Z2ICQ6SalKPZABEBAAGJ
+AjYEGAEIACAWIQRP1NKI1EWTTgoU+aWogDcy5ENohQUCWYsQiQIbDAAKCRCogDcy
+5ENohf0tEAChNbqT1siyZmvBt7iRPXPWYHkBx4u0S9AIaCddocaKHLOQMO7D4gQL
+HANO4pmM5P8DZVApE9zpvigUMH5Lz67g+H2DEnHqCqE6lN8+d0fZ6SZk7sS+7ZOH
+NfB4TX021AHhcP9m16luTkr8PLwJJnFJNg8z1BGMygAZZKxAOSopeGuJXaDj6ASp

Bug#876131: qtbase-opensource-src FTCBFS: uses the build architecture toolchain

[Lisandro Damián Nicanor Pérez Meyer]

Hi Helmut!

On 20/01/16 07:41, Helmut Grohne wrote:
> Hi,
> 
> On Mon, Sep 18, 2017 at 05:04:40PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > The only way I could accept that if we could build-depend on a
> > specific version (the same version we are trying to compile).
> > 
> > Helmut told me that's not possible, and I know from experience that
> > having a window opened to build qt with an oder qmake it's calling for
> > big troubles.
> 
> We arrived at a compromise: Turn the check into a build-time check.
> Rather than having dpkg-checkbuilddeps verify the property, we can have
> debian/rules check the version.

Totally agreed.

> I also updated the patch to the current version.
> 
> Limitations:
>  * Only works for arm64 and armel since no other architectures have
>matching mkspecs

I'm wondering why we don't use linux-g++ too, as it has been happening on all 
other archs.

>  * Fails when it encounters mysql_config. I didn't figure out yet how to
>make it use pkg-config mysqlclient instead, but that's what needs to
>happen.
> 
> Helmut

ACK, topic to investigate then.

I've added the following into experimental as part of a not yet released change 
(but I have to do it soon rather than later):

> diff --minimal -Nru qtbase-opensource-src-5.12.5+dfsg/debian/changelog 
> qtbase-opensource-src-5.12.5+dfsg/debian/changelog
> --- qtbase-opensource-src-5.12.5+dfsg/debian/changelog2019-12-31 
> 12:19:15.0 +0100
> +++ qtbase-opensource-src-5.12.5+dfsg/debian/changelog2020-01-16 
> 16:27:50.0 +0100
> @@ -1,3 +1,13 @@
> +qtbase-opensource-src (5.12.5+dfsg-5.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.

Should we really close the bug here? I would keep it open until we make it work.

> +  * Improve cross building: (Closes: #876131)
> ++ Pass --external-hostbindir to use the native qmake.
> ++ Pass a cross platform_arg.
> ++ Verify that the qmake self-dependency exactly matches the version.
> +
> + -- Helmut Grohne   Thu, 16 Jan 2020 16:27:50 +0100
> +
>  qtbase-opensource-src (5.12.5+dfsg-5) unstable; urgency=medium

[snip]

Here:

> -ifeq ($(DEB_HOST_ARCH_OS),linux)
> - platform_arg = linux-g++
> -else ifeq ($(DEB_HOST_ARCH_OS),hurd)
> - platform_arg = hurd-g++
> -else ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
> - platform_arg = gnukfreebsd-g++
> -else
> - $(error Unknown qmake mkspec for $(DEB_HOST_ARCH_OS))
> +mkspec_osmap_kfreebsd = gnukfreebsd
> +platform_os = $(or $(mkspec_osmap_$(DEB_HOST_ARCH_OS)),$(DEB_HOST_ARCH_OS))
> +platform_arg = $(platform_os)-g++
> +
> +ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
> +platform_arg = 
> $(platform_os)-$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_LIBC)$(filter-out 
> base,$(DEB_HOST_ARCH_ABI))-g++
> +endif
> +ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
> +extra_configure_opts += -external-hostbindir /usr/lib/qt5/bin
>  endif

We have always used linux-g++ on linux, so maybe we can keep that?

>  ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
> @@ -72,6 +73,9 @@
>   dh $@ --with pkgkde_symbolshelper
>  
>  override_dh_auto_configure:

Would the following comment be ok?

# Check we are cross building with the exact same Qt version.
> +ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
> + test "`dpkg-query -f '$${Version}' -W qt5-qmake-bin`" = "$(DEB_VERSION)"
> +endif

Cheers, Lisandro.

Bug#947837: python3-debianbts needed in buster-backports (was Re:Bug#947837: piuparts.debian.org: please upgrade python3-debianbts on pejacevic)

[Utkarsh Gupta]

On 17/01/20 12:07 am, Holger Levsen wrote:
> On Fri, Jan 17, 2020 at 12:06:02AM +0530, Utkarsh Gupta wrote:
>> Prepared and uploaded :)
> 
> wow, that was quick! thank you!

:)

>> Please let me know if somebody else wants to maintain, I'd happily step
>> aside.
> 
> :) that's why I didnt upload... ;)

I am happy to help and maintain it by all means!
But if someone wants to take over (especially the package maintainer),
I'd be happy to hand over the maintenance :)

But for now, I am happy that this particular bug is done \o/
Happy to help, always :)


Best,
Utkarsh



signature.asc
Description: OpenPGP digital signature

Bug#949081: wget2 FTBFS: makeinfo: command not found

[Helmut Grohne]

Source: wget2
Version: 1.99.1-2
Severity: serious
Tags: ftbfs

wget2 fails to build from source in unstable. A build ends with:

| /bin/bash /<>/build-aux/missing makeinfo --force -o ./wget2.info 
./wget2.texi
| /<>/build-aux/missing: line 81: makeinfo: command not found
| WARNING: 'makeinfo' is missing on your system.
|  You should only need it if you modified a '.texi' file, or
|  any other file indirectly affecting the aspect of the manual.
|  You might want to install the Texinfo package:
|  
|  The spurious makeinfo call might also be the consequence of
|  using a buggy 'make' (AIX, DU, IRIX), in which case you might
|  want to install GNU make:
|  
| make[3]: *** [Makefile:1719: wget2.stamp] Error 127
| make[3]: Leaving directory '/<>/docs'
| make[2]: *** [Makefile:1579: all-recursive] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:1488: all] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:43: build-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

This is also reproduced by crossqa, but not yet reproduced by
reproducible builds, so it likely is a fairly recent regression.
http://crossqa.debian.net/build/wget2_1.99.1-2_armel_20200115220118.log

I suppose that this is a result of gnulib having dropped its dependency
on texinfo, so now wget2 needs to depend on texinfo itself.

Helmut

Bug#876131: qtbase-opensource-src FTCBFS: uses the build architecture toolchain

[Helmut Grohne]

Hi,

On Mon, Sep 18, 2017 at 05:04:40PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> The only way I could accept that if we could build-depend on a
> specific version (the same version we are trying to compile).
> 
> Helmut told me that's not possible, and I know from experience that
> having a window opened to build qt with an oder qmake it's calling for
> big troubles.

We arrived at a compromise: Turn the check into a build-time check.
Rather than having dpkg-checkbuilddeps verify the property, we can have
debian/rules check the version.

I also updated the patch to the current version.

Limitations:
 * Only works for arm64 and armel since no other architectures have
   matching mkspecs
 * Fails when it encounters mysql_config. I didn't figure out yet how to
   make it use pkg-config mysqlclient instead, but that's what needs to
   happen.

Helmut
diff --minimal -Nru qtbase-opensource-src-5.12.5+dfsg/debian/changelog 
qtbase-opensource-src-5.12.5+dfsg/debian/changelog
--- qtbase-opensource-src-5.12.5+dfsg/debian/changelog  2019-12-31 
12:19:15.0 +0100
+++ qtbase-opensource-src-5.12.5+dfsg/debian/changelog  2020-01-16 
16:27:50.0 +0100
@@ -1,3 +1,13 @@
+qtbase-opensource-src (5.12.5+dfsg-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: (Closes: #876131)
++ Pass --external-hostbindir to use the native qmake.
++ Pass a cross platform_arg.
++ Verify that the qmake self-dependency exactly matches the version.
+
+ -- Helmut Grohne   Thu, 16 Jan 2020 16:27:50 +0100
+
 qtbase-opensource-src (5.12.5+dfsg-5) unstable; urgency=medium
 
   [ Pino Toscano ]
diff --minimal -Nru qtbase-opensource-src-5.12.5+dfsg/debian/control 
qtbase-opensource-src-5.12.5+dfsg/debian/control
--- qtbase-opensource-src-5.12.5+dfsg/debian/control2019-12-31 
12:19:15.0 +0100
+++ qtbase-opensource-src-5.12.5+dfsg/debian/control2020-01-16 
16:27:50.0 +0100
@@ -66,6 +66,7 @@
libxrender-dev,
pkg-kde-tools (>= 0.15.17~),
publicsuffix,
+   qt5-qmake-bin ,
unixodbc-dev,
zlib1g-dev
 Build-Depends-Indep: qdoc-qt5 (>= 5.12) ,
diff --minimal -Nru qtbase-opensource-src-5.12.5+dfsg/debian/rules 
qtbase-opensource-src-5.12.5+dfsg/debian/rules
--- qtbase-opensource-src-5.12.5+dfsg/debian/rules  2019-12-31 
12:19:15.0 +0100
+++ qtbase-opensource-src-5.12.5+dfsg/debian/rules  2020-01-16 
16:27:50.0 +0100
@@ -52,14 +52,15 @@
cpu_opt = -no-sse2 -no-pch
 endif
 
-ifeq ($(DEB_HOST_ARCH_OS),linux)
-   platform_arg = linux-g++
-else ifeq ($(DEB_HOST_ARCH_OS),hurd)
-   platform_arg = hurd-g++
-else ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
-   platform_arg = gnukfreebsd-g++
-else
-   $(error Unknown qmake mkspec for $(DEB_HOST_ARCH_OS))
+mkspec_osmap_kfreebsd = gnukfreebsd
+platform_os = $(or $(mkspec_osmap_$(DEB_HOST_ARCH_OS)),$(DEB_HOST_ARCH_OS))
+platform_arg = $(platform_os)-g++
+
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+platform_arg = 
$(platform_os)-$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_LIBC)$(filter-out 
base,$(DEB_HOST_ARCH_ABI))-g++
+endif
+ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+extra_configure_opts += -external-hostbindir /usr/lib/qt5/bin
 endif
 
 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
@@ -72,6 +73,9 @@
dh $@ --with pkgkde_symbolshelper
 
 override_dh_auto_configure:
+ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+   test "`dpkg-query -f '$${Version}' -W qt5-qmake-bin`" = "$(DEB_VERSION)"
+endif
MAKEFLAGS="-j$(NUMJOBS) ${CXXFLAGS:%=EXTRA_CXXFLAGS+=%} 
${LDFLAGS:%=EXTRA_LFLAGS+=%}" \
./configure \
-confirm-license \

Bug#949079: kannel FTCBFS: abuses AC_CHECK_FILE, uses mysql_config

[Helmut Grohne]

Source: kannel
Version: 1.4.5-7
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kannel fails to cross build from source for two reasons. One is its use
of AC_CHECK_FILE. The macro is meant to check for files on the host
system, but kannel exclusively uses it for checking build system files.
For that task, a simple test -e is the solution. The other issue is that
it misdetects presence of mysql. During cross compilation mysql_config
does not work. Please use pkg-config instead. When applying the patch,
you need to add pkg-config to Build-Depends. Please consider applying
it.

Helmut
--- kannel-1.4.5.orig/configure.in
+++ kannel-1.4.5/configure.in
@@ -494,7 +494,7 @@
 ${loc}/share/sgml/dsssl/docbook-dsssl-nwalsh/html/docbook.dsl \
 ${loc}/share/dsssl/docbook-dsssl/html/docbook.dsl ; do
   if test "x$found" = "x" ; then 
-	AC_CHECK_FILE($file,HTML_DSL=$file; found=1)
+	AS_IF([test -e "$file"],HTML_DSL=$file; found=1)
   fi
 done
   fi
@@ -512,7 +512,7 @@
 ${loc}/share/sgml/dsssl/docbook-dsssl-nwalsh/print/docbook.dsl \
 ${loc}/share/dsssl/docbook-dsssl/print/docbook.dsl ; do
   if test "x$found" = "x" ; then 
-	AC_CHECK_FILE($file,TEX_DSL=$file; found=1)
+	AS_IF([test -e "$file"],TEX_DSL=$file; found=1)
   fi
 done
   fi
@@ -531,7 +531,7 @@
 ${loc}/share/sgml/dsssl/docbook-dsssl-nwalsh/dtds/decls/xml.dcl \
 ${loc}/share/dsssl/docbook-dsssl/dtds/decls/xml.dcl ; do
   if test "x$found" = "x" ; then 
-AC_CHECK_FILE($file,XML_DCL=$file; found=1)
+AS_IF([test -e "$file"],XML_DCL=$file; found=1)
   fi
 done
   fi
@@ -993,6 +993,16 @@
 ])
 
 AC_MSG_RESULT(searching)
+mysql_found=no
+AS_IF([test "x$mysqlloc" = x],,[
+  PKG_CHECK_MODULES([MYSQLCLIENT],[mysqlclient],[
+CFLAGS="$CFLAGS $MYSQLCLIENT_CFLAGS"
+LIBS="$LIBS $MYSQLCLIENT_LIBS"
+	mysql_found=yes
+  ])
+])
+
+if test "$mysql_found" = no; then
 AC_PATH_PROG(MYSQL_CONFIG, mysql_config, no, [$PATH:$mysqlloc/bin:$mysqlloc])
 dnl check for MySQL 4.x style mysql_config information
 if test "$MYSQL_CONFIG" = "no"; then
@@ -1001,9 +1011,9 @@
 if test "x$found" = "x" ; then
 AC_MSG_CHECKING([for MySQL client support in])
 AC_MSG_RESULT($loc)
-AC_CHECK_FILE("$loc/include/mysql/mysql.h",
+AS_IF([test -e "$loc/include/mysql/mysql.h"],
 [CFLAGS="$CFLAGS -I$loc/include/mysql"; LIBS="$LIBS -L$loc/lib/mysql -lmysqlclient"]; found=1,
-[AC_CHECK_FILE("$loc/include/mysql.h",
+[AS_IF([test -e "$loc/include/mysql.h"],
 [CFLAGS="$CFLAGS -I$loc/include"; LIBS="$LIBS -L$loc/lib -lmysqlclient"]; found=1
 )]
 )
@@ -1043,6 +1053,7 @@
 CFLAGS="$CFLAGS $MYSQL_CFLAGS"
 AC_MSG_RESULT([$MYSQL_CFLAGS])
 fi
+fi
 AC_CHECK_HEADERS(mysql/mysql.h mysql/mysql_version.h)
 AC_CHECK_LIB(mysqlclient_r, mysql_stmt_init, [],
 		AC_CHECK_LIB(mysqlclient, mysql_stmt_init, [], [AC_MSG_ERROR([Unable to find MySQL client libraries version >= 4.1])])
@@ -1241,11 +1252,11 @@
 		if test "x$found" = "x" ; then
 			AC_MSG_CHECKING([for PostgresSQL include files in])
 			AC_MSG_RESULT($loc)
-			AC_CHECK_FILE("$loc/include/postgresql/libpq-fe.h",
+			AS_IF([test -e "$loc/include/postgresql/libpq-fe.h"],
 	  [CFLAGS="$CFLAGS -I$loc/include/postgresql"; LIBS="$LIBS -L$loc/lib/postgresql -lpq"]; found=1,
-	  [AC_CHECK_FILE("$loc/include/pgsql/libpq-fe.h",
+	  [AS_IF([test -e "$loc/include/pgsql/libpq-fe.h"],
 	[CFLAGS="$CFLAGS -I$loc/include/pgsql"; LIBS="$LIBS -L$loc/lib/pgsql -lpq"]; found=1,
-	[AC_CHECK_FILE("$loc/pgsql/include/libpq-fe.h",
+	[AS_IF([test -e "$loc/pgsql/include/libpq-fe.h"],
 	[CFLAGS="$CFLAGS -I$loc/pgsql/include"; LIBS="$LIBS -L$loc/pgsql/lib -lpq"]; found=1,
   )]
 )])
@@ -1314,9 +1325,9 @@
 if test "x$found" = "x" ; then
 AC_MSG_CHECKING([for Redis include files in])
 AC_MSG_RESULT($loc)
-AC_CHECK_FILE("$loc/hiredis.h",
+AS_IF([test -e "$loc/hiredis.h"],
   [CFLAGS="$CFLAGS -I$loc"; LIBS="$LIBS -L$loc -lhiredis"]; found=1,
-  [AC_CHECK_FILE("$loc/include/hiredis/hiredis.h",
+  [AS_IF([test -e "$loc/include/hiredis/hiredis.h"],
 [CFLAGS="$CFLAGS -I$loc/include/hiredis"; LIBS="$LIBS -L$loc/lib -lhiredis"]; found=1
   )]
 )
@@ -1412,7 +1423,7 @@
 if test "x$found" = "x" ; then
 AC_MSG_CHECKING([for Cassandra include files in])
 AC_MSG_RESULT($loc)
-AC_CHECK_FILE("$loc/include/cassandra.h",
+AS_IF([test -e "$loc/include/cassandra.h"],
   [CFLAGS="$CFLAGS 

Bug#949080: libpam-chroot FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: libpam-chroot
Version: 0.9-4.3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libpam-chroots fails to cross build from source, because it does not
pass cross tools to make. The easiest way of fixing that - using
dh_auto_build - is not sufficient here as make install strips with the
build architecture strip. Doing so also breaks generation of -dbgsym
packages as well as DEB_BUILD_OPTIONS=nostrip (reported as #437385). It
is best to disable such stripping. Please consider applying the attached
patch. It also fixes #437385.

Helmut
diff -u libpam-chroot-0.9/Makefile libpam-chroot-0.9/Makefile
--- libpam-chroot-0.9/Makefile
+++ libpam-chroot-0.9/Makefile
@@ -5,6 +5,7 @@
 CPPFLAGS=-I.
 LDFLAGS=-shared
 DESTDIR=/
+INSTALL?=install
 
 OUT=pam_chroot.so
 CONF=chroot.conf
@@ -21,2 +22,2 @@
-   install -s -o0 -g0 -m755 $(OUT) $(DESTDIR)/lib/security
-   install -m640 $(CONF) $(DESTDIR)/etc/security
+   $(INSTALL) -s -o0 -g0 -m755 $(OUT) $(DESTDIR)/lib/security
+   $(INSTALL) -m640 $(CONF) $(DESTDIR)/etc/security
diff -u libpam-chroot-0.9/debian/changelog libpam-chroot-0.9/debian/changelog
--- libpam-chroot-0.9/debian/changelog
+++ libpam-chroot-0.9/debian/changelog
@@ -1,3 +1,13 @@
+libpam-chroot (0.9-4.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Make install substitutable.
++ Pass a non-stripping install to make install.
+
+ -- Helmut Grohne   Thu, 16 Jan 2020 16:12:37 +0100
+
 libpam-chroot (0.9-4.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libpam-chroot-0.9/debian/control libpam-chroot-0.9/debian/control
--- libpam-chroot-0.9/debian/control
+++ libpam-chroot-0.9/debian/control
@@ -2,7 +2,7 @@
 Section: devel
 Priority: optional
 Maintainer: Javier Fernandez-Sanguino Pen~a  
-Build-Depends: libpam0g-dev, debhelper (>> 3.0.0)
+Build-Depends: libpam0g-dev, debhelper (>= 7)
 Standards-Version: 3.9.2
 Homepage: http://sourceforge.net/projects/pam-chroot/
 
diff -u libpam-chroot-0.9/debian/rules libpam-chroot-0.9/debian/rules
--- libpam-chroot-0.9/debian/rules
+++ libpam-chroot-0.9/debian/rules
@@ -14,7 +14,7 @@
 
 build-stamp: 
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch build-stamp
 
 clean:
@@ -30,7 +30,7 @@
dh_installdirs
 
# Add here commands to install the package into debian/libpam-chroot
-   $(MAKE) install DESTDIR=$(CURDIR)/debian/libpam-chroot
+   $(MAKE) install DESTDIR=$(CURDIR)/debian/libpam-chroot INSTALL="install 
--strip-program=true"
 
 
 # Build architecture-independent files here.

Bug#947837: python3-debianbts needed in buster-backports (was Re:Bug#947837: piuparts.debian.org: please upgrade python3-debianbts on pejacevic)

[Holger Levsen]

On Fri, Jan 17, 2020 at 12:06:02AM +0530, Utkarsh Gupta wrote:
> Prepared and uploaded :)

wow, that was quick! thank you!

> Please let me know if somebody else wants to maintain, I'd happily step
> aside.

:) that's why I didnt upload... ;)


-- 
cheers,
Holger

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



signature.asc
Description: PGP signature

Bug#947837: python3-debianbts needed in buster-backports (was Re:Bug#947837: piuparts.debian.org: please upgrade python3-debianbts on pejacevic)

[Utkarsh Gupta]

Hi all,

On 16/01/20 11:38 pm, Holger Levsen wrote:
> On Tue, Dec 31, 2019 at 02:51:33PM +0100, Nis Martensen wrote:
>> Package: piuparts.debian.org
>> Severity: normal
>>
>> Since 27 December the piuparts-analyze output is broken. E.g.:
>> https://piuparts.debian.org/logs/2019/12/27/piuparts-analyze.txt
>>
>> The failure start date coincides with the date when the new code from
>> the develop branch was deployed. I think the python3-debianbts package
>> needs to be upgraded on the piuparts master host, since the new code now
>> depends on at least version 2.10.0 of that package.
> 
> now that python-debianbts 3.0.2 is in bullseye, backporting and
> uploading it to buster-backports is possible, which in turn will make
> it installable on pejacevic.debian.org, which runs piuparts.debian.org
> 
> Could someone please prepare and maintain such a backport?

Prepared and uploaded :)
Please let me know if somebody else wants to maintain, I'd happily step
aside.


Best,
Utkarsh



signature.asc
Description: OpenPGP digital signature

Bug#947837: python3-debianbts needed in buster-backports (was Re:Bug#947837: piuparts.debian.org: please upgrade python3-debianbts on pejacevic)

[Holger Levsen]

Hi,

On Tue, Dec 31, 2019 at 02:51:33PM +0100, Nis Martensen wrote:
> Package: piuparts.debian.org
> Severity: normal
> 
> Since 27 December the piuparts-analyze output is broken. E.g.:
> https://piuparts.debian.org/logs/2019/12/27/piuparts-analyze.txt
> 
> The failure start date coincides with the date when the new code from
> the develop branch was deployed. I think the python3-debianbts package
> needs to be upgraded on the piuparts master host, since the new code now
> depends on at least version 2.10.0 of that package.

now that python-debianbts 3.0.2 is in bullseye, backporting and
uploading it to buster-backports is possible, which in turn will make
it installable on pejacevic.debian.org, which runs piuparts.debian.org

Could someone please prepare and maintain such a backport?


-- 
cheers,
Holger

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



signature.asc
Description: PGP signature

Bug#949078: gnome-screenshot: area-mode screenshot on wayland gnome includes selection

[Christoph Schulz]

Package: gnome-screenshot
Version: 3.34.0-1
Severity: normal

Dear Maintainer,


while taking a screenshot in area mode on wayland gnome the blue
selection that is present while tragging the area that should be
screenshot is included in the final screenshot.

The problem does not arise when using x11 gnome.

Attached screenshots show the difference:

PNG 18-18-36 was taken on wayland gnome and includes the blue selection
PNG 18-20-45 was taken on x11 gnome and not includes the selection

Best Regards,
Christoph


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

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

Versions of packages gnome-screenshot depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-2
ii  libc62.29-7
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-2
ii  libglib2.0-0 2.62.4-1
ii  libgtk-3-0   3.24.13-1
ii  libx11-6 2:1.6.8-1
ii  libxext6 2:1.3.3-1+b2

gnome-screenshot recommends no packages.

gnome-screenshot suggests no packages.

-- no debconf information

Bug#949028: qtbase5-gles-dev: Try to remove all libkf5*-dev and qt*-dev packages

[Dmitry Shachnev]

Hi Christian,

On Thu, Jan 16, 2020 at 09:29:35AM +0100, Christian Marillat wrote:
> Dear Maintainer,
>
> I can't build a package with qtbase5-gles-dev, because all libkf5*-dev
> are removed.
>
> See apt output below.
>
> The problem is that all (I didn't checked) qt*-dev packages depends
> on qtbase5-dev instead of 'qtbase5-dev | qtbase5-gles-dev'
>
> I am wrong ?

This is a valid bug, and we will update dependencies of qt*-dev packages.

However please note that in most cases, you don't need to build anything
against qtbase5-gles-dev.

Unless your package is using some OpenGL ES specific functions, you
can build it against qtbase5-dev and then it will be installable with
libqt5*-gles.

If your local system has libqt5gui5-gles installed, you can build packages
in a clean chroot that does not have it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#949077: RM: ask -- RoQA; py2; upstream not active anymore; low popcon

[Juhani Numminen]

Package: ftp.debian.org
X-debbugs-cc: Pablo Oliveira , 936...@bugs.debian.org

Please remove ask from Debian.
Below a quote from Pablo, who is maintainer for this package.

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

On Fri, 30 Aug 2019 11:14:19 +0200 Pablo Oliveira  wrote:
> Hi,
> 
> Upstream project is not active anymore and there is no current plan to
> port ask to Python3.
> Since there are no reverse dependencies and popcon is low, I think the
> package should be marked for removal.
> 
> Cheers,
> 
> Pablo

--
Juhani