Bug#962791: pristine-tar: pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz

[Vasudev Kamath]

Package: pristine-tar
Version: 1.47
Severity: normal

Dear Maintainer,

Unable to import the new version of libvirt [1]. Seeing following message

bp:info: Importing '../libvirt_6.4.0.orig.tar.xz' to branch 'upstream/latest'...
gbp:info: Source package is libvirt
gbp:info: Upstream version is 6.4.0
gbp:error: Import of ../libvirt_6.4.0.orig.tar.xz failed: Couldn't commit to 
'pristine-tar' with upstream '5d1f17e4035e01548d006d598922650408f56703': 
pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz
(Please file a bug report.)
pristine-tar: failed to generate delta
gbp:error: Error detected, Will roll back changes.
gbp:info: Rolling back branch upstream/latest by resetting it to 
1b6982f1b5d95a81eef1a112d0b1b228d7f910b2
gbp:info: Rolling back branch pristine-tar by resetting it to 
9964e57257fc955481effec950da206799e0cbe1
gbp:error: Rolled back changes after import error.


[1] https://libvirt.org/sources/libvirt-6.4.0.tar.xz

-- 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: armhf, arm64

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

Versions of packages pristine-tar depends on:
ii  bzip21.0.8-3
ii  libbz2-1.0   1.0.8-3
ii  libc62.30-8
ii  libsys-cpuaffinity-perl  1.12-1+b4
ii  pbzip2   1.1.13-1
ii  perl 5.30.3-4
ii  pixz 1.0.6-3
ii  tar  1.30+dfsg-7
ii  xdelta   1.1.3-9.3
ii  xdelta3  3.0.11-dfsg-1+b1
ii  xz-utils 5.2.4-1+b1
ii  zlib1g   1:1.2.11.dfsg-2

pristine-tar recommends no packages.

pristine-tar suggests no packages.

-- no debconf information

Bug#962790: ITP: python-pairix -- 1D/2D indexing and querying with a pair of genomic coordinates

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-pairix -- 1D/2D indexing and querying with a pair of 
genomic coordinates
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-pairix
  Version : 0.3.7
  Upstream Author : Soo Lee
* URL : https://github.com/4dn-dcic/pairix
* License : MIT
  Programming Lang: C
  Description : 1D/2D indexing and querying with a pair of genomic 
coordinates
 Pairix is a tool for indexing and querying on a block-compressed text
 file containing pairs of genomic coordinates.
 .
 Pairix is a stand-alone C program that was written on top of tabix as a
 tool for the 4DN-standard pairs file format describing Hi-C data:
 pairs_format_specification.md
 .
 However, Pairix can be used as a generic tool for indexing and querying
 any bgzipped text file containing genomic coordinates, for either 2D- or
 1D- indexing and querying.
 .
 For example: given the custom text file below, you want to extract
 specific lines from the Pairs file further below. An awk command would
 read the Pairs file from beginning to end. Pairix creates an index and
 uses it to access the file from a relevant position by taking advantage
 of bgzf compression, allowing for a fast query on large files.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-pairix

Bug#962278: Incron crash with an "*** unhandled exception occurred ***"

[debian]

Do you actually inform whether the maintainer has even taken note of the 
reported problem / bug ?

Bug#962789: node-mime: some files are outside below /usr/share/node-mime, nodejs dir

[Jonas Smedegaard]

Package: node-mime
Version: 2.4.4+dfsg-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It seems some files are inappropriately shipped outside of the regular
nodejs dir: /usr/share/node-mime

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl7lwA0ACgkQLHwxRsGg
ASHqjA//aVN8hM/bCygMCnhYdgU2Cq0nUup1U3tePAPjMGu4zgjxKzTLbijEFCin
dbIl/RBcnuP4XGebu7RR9DRZTDW0QT+9OmAAxrJWGVrA/jN8AwXPKDL4RNpkamMm
OxLb5iA8QLpwavWXnlFGF0Kvmk8jSTsqNJp9ST/TH/6jx82ZRXrTRbhX/sO4X+Di
HO7V7pfzI+D3tXOqfjPEpeFkhUAXj94dYGAnCiUbTb37pcpUkxm/0OdBgMbrrMeS
eD0MZ+9FEIh/EK2yI864CX5FriDQmdrrNhplefod5PRVBW2nlofjJqqAe0NgSyjI
6aF03flLSbqQE7H79P2W5SLuptCdahq4dUfaDTb7gUXBCCzGVZAFL5nDFxyrsJFS
/Ma7eqqtz+rkgoiSYtYQ/pC2j+DkSEDw4zqWHmoNSxRBjiQ5B+kY9uUZupZfjOI6
kD2MgOx2dnssp9XE5XeaGaxcddHmiO+ioiF7mFuSFrD6cUQBCP/OPHhAj/QrcUGb
cthmTe6P0hEpl28VjsI1SwuxUy8XTHcDPF6JeDTSUCAgapaFPN7Y7PMuXg+x/6jb
qXFlOzLpmNDY0LYsN7n7zsXAfByt2YjBPc7BErnth8l6YcIcqExXkRj1goCx9I9S
AXcPTE9fc4BBQT3F5zI4Yrf8Q/srXqRkPGV2ccrOGjJYs1M8lHI=
=SSph
-END PGP SIGNATURE-

Bug#962788: rpc.idmapd[9725]: main: open(/run/rpc_pipefs/nfs): No such file or directory

[Harald Dunkel]

Package: nfs-common
Version: 1:1.3.4-2.1

Running "/etc/init.d/nfs-common start" rpc.idmapd failed with

rpc.idmapd[9725]: main: open(/run/rpc_pipefs/nfs): No such file or directory

Ain't the startup script supposed to create this directory?

init is sysv


Regards
Harri

Bug#962763: renderdoc FTBFS: undefined references to spvtools symbols

[Yuya Nishihara]

On Sat, 13 Jun 2020 18:48:23 +0300, Adrian Bunk wrote:
> -lSPIRV-Tools -lSPIRV-Tools-link -lSPIRV-Tools-opt -lrenderdoc_libentry 
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libSPIRV-Tools-opt.a(optimizer.cpp.o):
>  in function `spvtools::Optimizer::Run(unsigned int const*, unsigned long, 
> std::vector >*, 
> spv_optimizer_options_t*) const':
> (.text+0x73f3): undefined reference to 
> `spvtools::SpirvTools::SpirvTools(spv_target_env)'

Hi,

This link error can be addressed by reordering the libs according to
/usr/lib/x86_64-linux-gnu/pkgconfig/SPIRV-Tools.pc

Bug#959432: gdm3: server crashes after 90 seconds frozen on Wayland

[Xerz]

I have not been able to find what the cause of the bug was - however, I 
made a new installation of Debian Sid, which shows no signs of the 
issue.

Bug#962787: gocr: dangling gocr-dev

[Yangfl]

Source: gocr

Hi,

The purpose of gocr-dev is uncleared. gocr is not a library, there is
no readme to state how to use this package, and the mentioned libgocr
package has long been removed from archive.

As k2pdfopt requires libgocr, it would be great if you could consider
providing libgocr.

Bug#962767: java 11 bug with certs

[Andrei POPESCU]

Control: reassign ca-certificates-java 20190405

On Sb, 13 iun 20, 12:48:05, MG wrote:
> Package: ca-certificates-java (apt install ca-certificates-java)
> 
> version : apt 1.8.2.1 (armhf)   (on beagleboard - using 10.3 IoT image)
> 
> 
> Note: Attempting to install jitsi
> 
> 
> root@{hostname}:/home/debian# apt install ca-certificates-java
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> ca-certificates-java is already the newest version (20190405).
> ca-certificates-java set to manually installed.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 2 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Setting up uuid-runtime (2.33.1-0.1) ...
> Adding group `uuidd' (GID 117) ...
> Done.
> Warning: The home dir /run/uuidd you specified can't be accessed: No such
> file or directory
> Adding system user `uuidd' (UID 109) ...
> Adding new user `uuidd' (UID 109) with group `uuidd' ...
> Not creating home directory `/run/uuidd'.
> Created symlink /etc/systemd/system/sockets.target.wants/uuidd.socket →
> /lib/systemd/system/uuidd.socket.
> Setting up ca-certificates-java (20190405) ...
> Adding debian:ISRG_Root_X1.pem
> Adding debian:EC-ACC.pem
> Adding debian:GTS_Root_R4.pem
> Adding debian:Entrust_Root_Certification_Authority_-_G4.pem
> Adding debian:Staat_der_Nederlanden_EV_Root_CA.pem
> Adding debian:GeoTrust_Universal_CA_2.pem
> Adding debian:Sonera_Class_2_Root_CA.pem
> Adding debian:emSign_ECC_Root_CA_-_G3.pem
> Adding debian:IdenTrust_Commercial_Root_CA_1.pem
> Adding debian:SSL.com_Root_Certification_Authority_RSA.pem
> Adding debian:ePKI_Root_Certification_Authority.pem
> Adding debian:XRamp_Global_CA_Root.pem
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGILL (0x4) at pc=0xb40dbb60, pid=3000, tid=3006
> #
> # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build
> 11.0.7+10-post-Debian-3deb10u1)
> # Java VM: OpenJDK Server VM (11.0.7+10-post-Debian-3deb10u1, mixed mode,
> serial gc, linux-)
> # Problematic frame:
> # J 45 c2
> sun.security.provider.X509Factory.readOneBlock(Ljava/io/InputStream;)[B
> java.base@11.0.7 (447 bytes) @ 0xb40dbb60 [0xb40dbae0+0x0080]
> #
> # No core dump will be written. Core dumps have been disabled. To enable
> core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # //hs_err_pid3000.log
> Could not load hsdis-arm.so; library not loadable; PrintAssembly is disabled
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugs.debian.org/openjdk-11
> #
> /var/lib/dpkg/info/ca-certificates-java.postinst: line 88:  2998
> Done    find /etc/ssl/certs -name \*.pem
>   2999   | while read filename; do
>     alias=$(basename $filename .pem | tr A-Z a-z | tr -cs a-z0-9 _);
> alias=${alias%*_}; if [ -n "$FIXOLD" ]; then
>     echo "-${alias}"; echo "-${alias}_pem";
>     fi; echo "+${filename}";
> done
>   3000 Aborted | java -Xmx64m -jar $JAR -storepass
> "$storepass"
> dpkg: error processing package ca-certificates-java (--configure):
>  installed ca-certificates-java package post-installation script subprocess
> returned error exit status 134
> Processing triggers for systemd (241-7~deb10u4) ...
> Processing triggers for man-db (2.8.5-2) ...
> Processing triggers for ca-certificates (20200601~deb10u1) ...
> Updating certificates in /etc/ssl/certs...
> 0 added, 0 removed; done.
> Running hooks in /etc/ca-certificates/update.d...
> 
> done.
> done.
> Processing triggers for libc-bin (2.28-10) ...
> Errors were encountered while processing:
>  ca-certificates-java
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> 
> from uname:
> 
> Linux {hostname} 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC
> 2020 armv7l GNU/Linux
> 
> 
> please let me know if you need more information...

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature

Bug#961976: mumps: provide 64-bit build

[Drew Parsons]

To clarify this Bug, the current 64-bit build now provided for MUMPS 
(Bug#961185) means 64-bit PORD (64-bit ordering of indices), using the 
OPTC=-DPORD_INTSIZE64 flag. MUMPS_INT remains 32 bit.


This Bug (#961976) refers to a full all-integer 64-bit build, which 
would be triggered with OPTC=-DINTSIZE64 OPTF=-fdefault-integer-8 and 
would make MUMPS_INT 64 bit.


Drew

Bug#962786: ITP: pcpp -- C99 preprocessor written in pure Python

[Paul Wise]

‪On Sun, Jun 14, 2020 at 1:45 AM ‫أحمد المحمودي‬‎ wrote:‬

> A pure universal Python C (pre-)preprocessor implementation very useful for 
> pre-preprocessing header only
> C++ libraries into single file includes and other such build or packaging 
> stage malarky.
> The implementation can be used as a Python module or as a command line tool 
> ``pcpp`` which
> can stand in for a conventional C preprocessor (i.e. it'll accept similar 
> arguments).

This binary will conflict with the pcc package:

$ apt-file search bin/pcpp
pcc: /usr/bin/pcpp

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#949472: python-pex: diff for NMU version 1.1.14-3.1

[Gleisson Jesuino Joaquim Cardoso]

Control: tags 949472 + patch



Dear maintainer,

I've prepared an NMU for python-pex (versioned as 1.1.14-3.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer or cancel NMU.

Regards.

Gleisson

diff -Nru python-pex-1.1.14/debian/changelog python-pex-1.1.14/debian/changelog
--- python-pex-1.1.14/debian/changelog  2019-10-27 14:35:10.0 -0300
+++ python-pex-1.1.14/debian/changelog  2020-06-13 02:55:26.0 -0300
@@ -1,3 +1,12 @@
+python-pex (1.1.14-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/source/options: created to ignore changes in 'requires.txt' file.
+  * debian/tests/execute.sh: fixed errors in autopkgtest, thanks to Matthias 
Klose,
+Emmanuel Arias and Gianfranco Costamagna. (Closes: #949472)
+
+ -- Gleisson Jesuino Joaquim Cardoso   Sat, 13 Jun 2020 
02:55:26 -0300
+
 
diff -Nru python-pex-1.1.14/debian/source/options 
python-pex-1.1.14/debian/source/options
--- python-pex-1.1.14/debian/source/options 1969-12-31 21:00:00.0 
-0300
+++ python-pex-1.1.14/debian/source/options 2020-06-13 02:55:26.0 
-0300
@@ -0,0 +1 @@
+extend-diff-ignore = "requires.txt"
diff -Nru python-pex-1.1.14/debian/tests/execute.sh 
python-pex-1.1.14/debian/tests/execute.sh
--- python-pex-1.1.14/debian/tests/execute.sh   2019-10-27 14:35:10.0 
-0300
+++ python-pex-1.1.14/debian/tests/execute.sh   2020-06-13 02:55:26.0 
-0300
@@ -6,4 +6,10 @@
 export http_proxy=127.0.0.1:9
 export https_proxy=127.0.0.1:9
 
-pex -m textwrap -vv -o script && ./script
+pex --python=python3 -m textwrap -vv -o script && ./script
+
+if [ $? -eq 0 ]; then
+echo 9
+fi
+
+echo -1

Bug#962681: battery drain during system shutdown

[Paul Wise]

On Sat, 2020-06-13 at 20:39 +0800, Paul Wise wrote:

> After that you can use the Debian wayback machine to find out which
> Debian builds of the Linux kernel have this issue and which do not.

It seems you had trouble with this. I think the problem might be that
you are downloading all of the Linux binary packages instead of just
the one containing the normal Linux kernel image?

The files you want look like this:

linux-image-4.13.0-rc5-amd64_4.13~rc5-1~exp1_amd64.deb

So the pattern is this:

linux-image--amd64__amd64.deb

Ignore everything else, including -di or non _amd64 packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962755: exif: FTBFS on s390x: test failure

[Hugh McMaster]

On Sun, 14 Jun 2020 at 08:32, Nelson H. F. Beebe  wrote:

> [...]
> That is not the same version of exiftool that Boyuan reported, but there
> was no URL for his version.  I someone cares to send me a suitable source
> URL off list, I'll do another build with it on my new S/390 VM.


Thank you. The software is exif, not exiftool.

I’ll send you an upstream source link separately.

Hugh

>

Bug#962786: ITP: pcpp -- C99 preprocessor written in pure Python

[أحمد المحمودي]

Package: wnpp
Severity: wishlist
Owner: أحمد المحمودي 

* Package name: pcpp
  Version : 1.21
  Upstream Author : Niall Douglas (http://www.nedproductions.biz/) and David 
Beazley (http://www.dabeaz.com/)
* URL : http://www.example.org/
* License : BSD-3
  Programming Lang: Python
  Description : C99 preprocessor written in pure Python

A pure universal Python C (pre-)preprocessor implementation very useful for 
pre-preprocessing header only
C++ libraries into single file includes and other such build or packaging stage 
malarky.
The implementation can be used as a Python module or as a command line tool 
``pcpp`` which
can stand in for a conventional C preprocessor (i.e. it'll accept similar 
arguments).


signature.asc
Description: PGP signature

Bug#887842: salsa.debian.org created

[Antonio Terceiro]

Hello Osamu,

On Mon, Oct 14, 2019 at 09:11:37PM +0900, Osamu Aoki wrote:
> Hi,
> 
> Upstream has already created 2.1.8pre on github.  For my backport needs,
> I have created salsa.debian.org repository with completely updated
> packaging ;-)
> 
>   https://salsa.debian.org/debian/shunit2
> 
> If no major objection exists, I am going to make NMU upload this to
> unstable as my salvage activity.  (I see over 2 years of non-activity
> even with a good patch.)
> 
>   * Packaged new upstream 2.1.8pre pre-release with completely
> refreshed packaging structure to cope with the recent upstream
> file organization and consideration to the backward
> compatibility and RPM compatibility.  Closes: #887842
>   * Updated license to match upstream: LGPL2.1+ -> Apache 2.0
>   * debian/control: Bump Standards-Version to 4.4.1 and
> wrap-and-sort
>   * debian/rules: Clean-up and test against dash, bash, ksh, mksh,
> and zsh.  shunit2_misc_test.sh is only tested for bash.
>   * Manpage updated based on Branden's groff version with
> additional content by me.  Since the main contents are
> apparently copied from upstream documentation, this is also
> changed to Apache 2.0 License.  Closes: #861618
>   * Set up salsa.debian.org repository (dgit-maint-merge approach)
> 
> 
> Osamu

I think you should go ahead with this. It would be nice to have shunit2
properly maintained.


signature.asc
Description: PGP signature

Bug#962686: RFP: s2geometry -- Computational geometry and spatial indexing on the sphere http://s2geometry.io/

[Christoph Anton Mitterer]

btw:

All the dependencies seem to be in Debian already,... building is done
with CMake.


The python bindings work with python3, but it seems that per default
CMake picks up Python2 instead.

I had to set -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3 for
CMake,... then it worked.



https://github.com/google/s2geometry/issues/46 seems to show some other
CMake ways to do this.



Cheers,
Chris.

Bug#962785: RFS: procinfo/1:2.0.304-4 -- tools to display information from /proc and /sys

[Jpaulo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: procinfo
   Version : 1:2.0.304-4
   Upstream Author : [fill in name and email of upstream]
 * URL : http://procinfo-ng.sourceforge.net
 * License : GPL-2
 * Vcs :
https://anonscm.debian.org/git/collab-maint/procinfo.git
   Section : utils

It builds those binary packages:

  procinfo - tools to display information from /proc and /sys

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/procinfo/procinfo_2.0.304-4.dsc

Changes since the last upload:

   * QA upload.
   * Using new DH level format. Consequently:
   - debian/compat: removed.
   - debian/control: changed from 'debhelper' to 'debhelper-compat' in
 Build-Depends field and bumped level to 13.
   * debian/control:
   - Bumped Standards-Version to 4.5.0.
   - Set Rules-Requires-Root:no.
   * debian/copyright:
   - Set secure uri.
   - Added rights for Mattia Rizzolo.
   - Added myself to copyright statement for debian/*.
   * debian/tests/control:Added to provide a trivial test.
   * debian/upstream/metadata: Created.

Regards,

Bug#962784: facter aborts with free(): invalid pointer

[Russ Allbery]

Package: facter
Version: 3.11.0-4.1
Severity: grave

facter no longer works at all on amd64.  When invoked, it dies with
an invalid pointer error:

% facter
free(): invalid pointer
Aborted (core dumped)

gdb backtrace:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x779cb55b in __GI_abort () at abort.c:79
#2  0x77a24038 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x77b30f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x77a2b3da in malloc_printerr (
str=str@entry=0x77b2f0e0 "free(): invalid pointer") at malloc.c:5339
#4  0x77a2cdcc in _int_free (av=, p=, 
have_lock=0) at malloc.c:4173
#5  0x77e835d4 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libfacter.so.3.11.0
#6  0x77e83bd8 in 
facter::facts::collection::add_external_facts(std::vector, std::allocator >, 
std::allocator, 
std::allocator > > > const&) ()
   from /usr/lib/x86_64-linux-gnu/libfacter.so.3.11.0
#7  0x5557154c in main ()

This also renders Puppet unusable.

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

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

Versions of packages facter depends on:
ii  libboost-program-options1.67.0  1.67.0-18
ii  libc6   2.30-8
ii  libfacter3.11.0 3.11.0-4.1
ii  libgcc-s1   10.1.0-3
ii  libleatherman1.4.2  1.4.2+dfsg-2+b1
ii  libstdc++6  10.1.0-3
ii  ruby1:2.7+1

facter recommends no packages.

facter suggests no packages.

-- no debconf information

Bug#961314: ITP: python3-s2sphere -- Python implementation of a part of the C++ S2 geometry library

[Christoph Anton Mitterer]

Hey.

An update on this... it seems to me, that s2sphere is in fact rathe
runmaintained... and it also seems that s2geometry (with it's Python
bindings) is that canonical library (and the bindings seem far more
complete).

I've even ported my own program in the meantime from s2sphere to the
Python SWIG bindings from s2geometry.

Building of these is pretty simple... uses CMake, all dependencies seem
to be in Debian already.

So I'd guess it would rather make sense to package s2geometry, and not
s2sphere.


Cheers,
Chris.

Bug#948074: din FTBFS: cannot find X11/X.h

[Mattia Rizzolo]

I know that at the start of the year some reorganization within the X11
packages caused down FTBFS while files where being moving around.

I recommend you just close this bug.  FTR, it also builds in
reproducible-builds testing.

On Sun, 14 Jun 2020, 12:33 am Sudip Mukherjee, 
wrote:

> Hi Helmut,
>
> On Fri, Jan 03, 2020 at 06:48:06PM +0100, Helmut Grohne wrote:
> > Source: din
> > Version: 5.2.1-6
> > Severity: serious
> > Tags: ftbfs
> >
> > din fails to build from source in unstable on amd64. A build log ends
> > with:
>
> I tried building it today and there was no build failure.
>
>
> +--+
> | Summary
> |
>
> +--+
>
> Build Architecture: amd64
> Build Type: full
> Build-Space: 79072
> Build-Time: 30
> Distribution: unstable
> Host Architecture: amd64
> Install-Time: 65
> Job: din
> Machine Architecture: amd64
> Package: din
> Package-Time: 97
> Source-Version: 5.2.1-6
> Space: 79072
> Status: successful
> Version: 5.2.1-6
>
> 
>
> Can you please retry the build and confirm.
>
> --
> Regards
> Sudip
>
>

Bug#890215: valgrind causes miscalculation

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=421262
Control: retitle -1 valgrind causes miscalculation on long double

On 2018-02-12 03:04:30 +0100, Vincent Lefevre wrote:
> valgrind causes miscalculation on the following program:
> 
> 
> #include 
> 
> int main (void)
> {
>   volatile union {
> long double d;
> unsigned long i[2];
>   } u;
> 
>   u.i[0] = 1;
>   u.i[1] = 0;
>   printf ("%La\n", u.d);
> 
>   return 0;
> }
> 

Note that the above value is a subnormal.

This appears to be the same kind of problem as mentioned in a bug
reported upstream last month:

  https://bugs.kde.org/show_bug.cgi?id=421262

As said, the cause is that valgrind converts the value to
double precision.

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

Bug#962782: valgrind: the URLs in the valgrind(1) man page should be changed to https

[Vincent Lefevre]

Package: valgrind
Version: 1:3.15.0-1
Severity: minor

The valgrind(1) man page uses URLs that start with

  http://www.valgrind.org/

The https version should be used.

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

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

Versions of packages valgrind depends on:
ii  libc6  2.30-8
ii  libc6-dbg  2.30-8

Versions of packages valgrind recommends:
ii  gdb   9.2-1
ii  valgrind-dbg  1:3.15.0-1

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

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

Bug#962781: containernetworking-plugins: may need Breaks+Replaces: rkt (<< ???)

[Andreas Beckmann]

Package: containernetworking-plugins
Version: 0.8.6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

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

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

  Preparing to unpack .../containernetworking-plugins_0.8.6-1_amd64.deb ...
  Unpacking containernetworking-plugins (0.8.6-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/containernetworking-plugins_0.8.6-1_amd64.deb 
(--unpack):
   trying to overwrite '/lib/systemd/system/cni-dhcp.service', which is also in 
package rkt 1.30.0+dfsg1-9
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/containernetworking-plugins_0.8.6-1_amd64.deb


cheers,

Andreas


rkt=1.30.0+dfsg1-9_containernetworking-plugins=0.8.6-1.log.gz
Description: application/gzip

Bug#962780: kaccounts-integration: [ABI break] 20.04 and 20.04.1 have renamed symbols and needs an upstream ABI bump

[Nicholas D Steeves]

Package: kaccounts-integration
Severity: normal
Tags: upstream
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=422191

Hi,

I'm filing this bug so there's a record on the Debian-side.  The
existence of this bug emerged while discussing a yet-unmerged MR with
hefee.

  
https://salsa.debian.org/qt-kde-team/kde/kaccounts-integration/-/merge_requests/3

Pino, I've CCed you because we've collaborated upstream before,
because you've uploaded kio-gdrive, because kio-gdrive depends on
kaccounts, and thus it seems like you might be interested in resolving
this upstream issue.

Regards,
Nicholas

Bug#962755: exif: FTBFS on s390x: test failure

[Nelson H. F. Beebe]

Boyuan Yang  reports on Sat, Jun 13, 2020 at
09:40:19AM -0400:

>> The new upload of exif/0.6.22-1 FTBFS on s390x architecture due to test
>> failure:
>> https://buildd.debian.org/status/fetch.php?pkg=exif&arch=s390x&ver=0.6.22-1&stamp=1591715266&raw=0

As an independent check of a new S/390 VM running Ubuntu 18.04.4 LTS
using QEMU 4.2.0 on a physical machine running Ubuntu 20.04, I pulled
down from

https://sourceforge.net/projects/exiftool/

the Image-ExifTool-12.00.tar.gz file, and followed its README
file to build, test, and install it on my S/390 VM: it reported

All tests successful.
Files=99, Tests=542, 511 wallclock secs ( 5.29 usr 3.08 sys + \
  461.82 cusr 42.11 csys = 512.30 CPU)
Result: PASS

That is not the same version of exiftool that Boyuan reported, but
there was no URL for his version.  I someone cares to send me a
suitable source URL off list, I'll do another build with it on my new
S/390 VM.


---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

Bug#961676: 5.6 kernel crashes host when using VFIO on KVM guests

[Simon John]

I tried to get some sort of useful logging today, best I could do was 
running strace.


So I noticed that virsh exited 0 but didn't instantly crash, it took 2-3 
seconds more.


Photo of screen with strace output here:

https://i.imgur.com/kOSEXXA.jpg

Managed to install 5.5.0-2 from snapshot.debian.org which works fine.

Regards.

--
Simon John

Bug#962779: djview4 color PDF export results in a blank page

[Adam Richter]

Package: djview4
Version: 4.1.0+git191117-2

Attempting to do a PDF export of a color image from djview4 results in
a blank page, as displayed by the evince PDF viewer, and as reported
to me by someone whom I sent one of these bad PDF's.  I propose two
potential temporary fixes at the end (revert tiff2pdf.c or omit JPEG
SOI tokens).

I have observed the problem with Ubuntu for the past couple of years,
through the latest release (20.04).  Today I also observed the problem
on Debian Sid and Bullseye (all x86-64), and from the Debian git
sources at https://salsa.debian.org/debian/djview4.git.

The problem appears to be due to a longstanding libtiff bug discussed
at https://gitlab.com/libtiff/libtiff/-/issues/1 .  I am not that
knowledgeable about jpeg, tiff and pdf formats, but my impression is
that the problem is tiff2pdf.c incorrectly emits a separate "start of
image" (SOI) token (code 0xFF 0xD8) for each strip in a multi-strip
JPEG image, when it should emitting only one.  The plan of record
appears to be fix that bug after JPEG tile mode support is
implemented.

Because the problem is in tiff2pdf.c, it is also possible to produce
the problem by exporting a file to TIFF format instead of PDF, which
will produce a TIFF file that displays properly but which will result
in the same type of bad PDF when converted to PDF using the separate
tiff2pdf program.

I tried changing the strip size from 64 to the full image height in
djview4/src/qdjviewexporters.cpp in the function
QDjViewTiffExporter::doPage, at the line beginning with
"TIFFSetField(tiff, TIFFTAG_ROWSPERSTRIP, ", but that still gave me a
blank page.

I am reporting the problem at the Debian level first rather than to
central djview4 development because the upstream djview4 uses an older
version of tiff2pdf.c that does not have this problem.  The Debian
packaging upgrades the tiff2pdf.c file to a version that has this bug
(libtiff 2.93 through the latest, 4.1.0).

I am aware of two possible temporary solutions that have worked so
far, but which I have only tested slightly.  Perhaps I should refer to
these options as workarounds, because I am not sure that either
generates files that fully conform to JPEG, but, if that is so, then
it is also probably the case that the current code makes similar
violations.  Anyhow, here are the possibilities I would like to
suggest::

1. Revert tiff2pdf.c.  The issue is that if someone went to the
trouble of upgrading it, I wonder what bug or bugs motivated that and
whether those bugs would return.

2. Commenting out the lines that emit the start-of-image tokens,
basically reverting the change in tiff2pdf.c that happened when
libtiff went from 2.9.2 to 2.9.3.  I include patch inline and as an
attachment, because I am not sure what the preferred way is for
submissions to bugs.debian.org.  The problem is that although I have
not gotten djview4 to have a problem with that change, doing the same
change to libtiff to generates a new tiff2pdf executable that still
has problems with tiff files that I generate with ImageMagick or
GraphicsMagick ("gm convert -compress JPEG foo.pnm foo.tiff") without
involving anything related to djvu, where the PDF is sometimes just
rendered as a top strip with the rest of the image blank or, as
before, a blank page.

Anyhow, here is the change to omit the SOI tokens.  Thanks in advance
for any attention to this bug report.

Adam

diff --git a/src/tiff2pdf.c b/src/tiff2pdf.c
index 9838c91..ab06145 100644
--- a/src/tiff2pdf.c
+++ b/src/tiff2pdf.c
@@ -3638,8 +3638,10 @@ int t2p_process_jpeg_strip(
case 0xd8:  /* SOI - start of image */
 if( *bufferoffset + 2 > buffersize )
 return(0);
+#if 0
_TIFFmemcpy(&(buffer[*bufferoffset]),
&(strip[i-1]), 2);
*bufferoffset+=2;
+#endif
break;
case 0xc0:  /* SOF0 */
case 0xc1:  /* SOF1 */
diff --git a/src/tiff2pdf.c b/src/tiff2pdf.c
index 9838c91..ab06145 100644
--- a/src/tiff2pdf.c
+++ b/src/tiff2pdf.c
@@ -3638,8 +3638,10 @@ int t2p_process_jpeg_strip(
 			case 0xd8:	/* SOI - start of image */
 if( *bufferoffset + 2 > buffersize )
 return(0);
+#if 0
 _TIFFmemcpy(&(buffer[*bufferoffset]), &(strip[i-1]), 2);
 *bufferoffset+=2;
+#endif
 break;
 			case 0xc0:	/* SOF0 */
 			case 0xc1:	/* SOF1 */

Bug#948074: din FTBFS: cannot find X11/X.h

[Sudip Mukherjee]

Hi Helmut,

On Fri, Jan 03, 2020 at 06:48:06PM +0100, Helmut Grohne wrote:
> Source: din
> Version: 5.2.1-6
> Severity: serious
> Tags: ftbfs
> 
> din fails to build from source in unstable on amd64. A build log ends
> with:

I tried building it today and there was no build failure.

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 79072
Build-Time: 30
Distribution: unstable
Host Architecture: amd64
Install-Time: 65
Job: din
Machine Architecture: amd64
Package: din
Package-Time: 97
Source-Version: 5.2.1-6
Space: 79072
Status: successful
Version: 5.2.1-6


Can you please retry the build and confirm.

--
Regards
Sudip

Bug#817954: Does this bug prevent firefox from entering backports also?

[Mike Hommey]

On Thu, Jun 11, 2020 at 03:22:40PM +0530, Pirate Praveen wrote:
> On Thu, 25 Jul 2019 12:10:45 +0200 Johannes Rohr  wrote:
> > It would be great to have firefox (or the next firefox-esr) in
> > buster-backports, as it has important new functionality relevant for
> > privacy and data protection, such as the multi account containers
> > function. However, this bug prevents firefox from entering testing,
> > which in my understanding implies, that it cannot make it into backports
> > as well. Is there some way of getting an up-to-date firefox version into
> > stable? For now I work with the binary directly downloaded from
> > mozilla.org, but this is a kludge.
> > 
> 
> We have created https://fasttrack.debian.net for packages like this
> which cannot go with stable releases and hence blocked from entering
> testing and backports as well.
> 
> Mike,
> 
> Would you like to maintain firefox in buster-fasttrack?
> 
> I'm part of the team that maintain this unofficial service and maintains
> gitlab there. If you are okay with the idea, but does not want to do the
> extra work, I'd be happy to maintain it in fasttrack.

The package in unstable can be built for stable as long as its version
contains a ~bpo thing. That could be changed to also support fto. But
the bigger problem is that it requires new versions of rustc, cargo and
cbindgen, which in turn requires a new version of llvm. And it requires
new versions of these quite regularly.

So, no, I'm not really interested in maintaining that.

Mike

Bug#866220: ITA: posterazor -- splits an image across multiple pages for assembly into a poster

[Marcelo Mota]

Hi,

I like posterazor and I am willing to take care of the package.


Regards,

Marcelo S Mota

Bug#676574: ITA: htp -- html simple command line pre-processor

[Marcelo Mota]

retitle 676574 ITA: htp -- html simple command line pre-processor
owner 676574 !
thanks

Hi,

I am willing to take care of the package.

Regards,

Marcelo S Mota

Bug#807648: your mail

[Moritz Mühlenhoff]

On Mon, Sep 03, 2018 at 11:25:07PM -0400, Tiago Bortoletto Vaz wrote:
> Hi, sorry for the long delay.
> 
> I'm doing a (late) cleanup in my packages and will update Zyne to the new
> upstream version, which now runs with python3 and python-wxgtk4.0. I'll have
> to package a new dependency as well: https://github.com/belangeo/pyo-tools.
> It will take some time, anyway just for the record that I didn't give up
> about this nice synth in Debian.

There hasn't been any further update, let's remove zyne?

Cheers,
Moritz

Bug#962778: O: libdispatch -- user space implementation of the Grand Central Dispatch API

[Mark Heily]

Package: wnpp
Severity: normal

I intend to orphan the libdispatch package, and recommend that it be
removed from the archive. There appears to be little interest in the
open source community towards adopting Grand Central Dispatch as a
concurrency mechanism. The upstream library has been rebranded as
"swift-corelibs-libdispatch" to reflect that libdispatch is mostly
used as a private library within the overall Swift language runtime. I
personally have no interest in the Swift language, and do not see very
much demand for it outside of MacOS and iOS development.

Bug#962382: kcollectd: no information printing

[Antonio Russo]

Control: tags -1 +moreinfo

Hello Eduard,

You say that the tree of sensors appears for you.  Just to confirm: what 
happens when you drag an item from
that list into the right-hand region, where it says "Drop sensors from list 
here"?

Antonio

Bug#962777: RFS: jsonlab/2.0 [RFS] -- a native JSON/UBJSON/MassagePack encoder/decoder for MATLAB/Octave

[Qianqian Fang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "jsonlab":

  * Package name : jsonlab
    Version : 2.0
    Upstream Author : Qianqian Fang (fangqq at gmail.com)
  * URL : https://openjdata.org/jsonlab
  * License : GPLv3+ or BSD-3-clause
  * Vcs : https://github.com/fangq/jsonlab
    Section : science

It builds those binary packages:

  octave-jsonlab - a native JSON/UBJSON/MassagePack encoder/decoder for 
Octave
  matlab-jsonlab - a native JSON/UBJSON/MassagePack encoder/decoder for 
MATLAB


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


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

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

dget -x https://mentors.debian.net/debian/pool/main/z/zmat/zmat_0.9.8-1.dsc

(Please note that to install the generated package, one needs to install 
a dependency:
octave-zmat, which is also currently being reviewed - 
https://mentors.debian.net/package/zmat )


Changes since the last upload:


  * Initial import of JSONLab v2.0. (Closes: #962607)
 -- Qianqian Fang   Sat, 13 Jun 2020 15:18:58 -0400


Regards,

Bug#962776: jigdo-lite: silently ignores HTTPS mirrors

[Jakub Wilk]

Package: jigdo-file
Version: 0.7.3-5
Severity: important
Control: fixed -1 0.8.0-1
Tags: patch

jigdo-lite(1) silently ignores HTTPS mirrors, falling back to 
us.cdimage.d.o and snapshot.d.o.


AFAICS this is already fixed in unstable, but please fix it in buster 
too.


--
Jakub Wilk
diff --git a/scripts/jigdo-lite b/scripts/jigdo-lite
index d92fb51..fc57610 100755
--- a/scripts/jigdo-lite
+++ b/scripts/jigdo-lite
@@ -596,7 +596,7 @@ imageDownload() {
 for pass in x xx xxx  x xx xxx ; do
   $jigdoFile print-missing-all --image="$image" --jigdo="$jigdoF" \
 --template="$template" $jigdoOpts $uriOpts \
-  | egrep -i '^(http:|ftp:|$)' >"$list"
+  | egrep -i '^(http:|https:|ftp:|$)' >"$list"
   missingCount=`egrep '^$' <"$list" | wc -l | sed -e 's/ *//g'`
   # Accumulate URLs in $@, pass them to fetchAndMerge in batches
   shift "$#" # Solaris /bin/sh doesn't understand "set --"

Bug#962775: ITP: python-django-cache-machine -- Cache machines for Django

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: python-django-cache-machine
  Version : 1.1.0
  Upstream Author : Jeff Balogh
* URL : 
https://github.com/django-cache-machine/django-cache-machine
* License : BSD-3-clause
  Programming Lang: Python
  Description : Cache machines for Django

 This module provides automatic caching and invalidation for Django
 models through the Object Relational Mapping (ORM).


I want to package it because it is a dep of https://flopedt.org .

I'll maintain it within the Debian Python Modules Team.

Cheers,

JP

Bug#962774: www.debian.org: bug number within webwml/english/security/2020/dsa-4698.wml not included in the final HTML page

[Rafa]

Package: www.debian.org
Severity: wishlist

Dear Maintainers,

Page webwml/english/security/2020/dsa-4698.wml contains, in line 230, the text 
"#952660)." in such a way that the whole text is treated as a wml comment 
and, as a consequence, it is not included in the final HTML page.

I guess that the attached PATCH could solve the issue by simply changing the 
position of the text.

Regards,

Rafa.

From 1534879b5722890f527baf618318d1b00a93b5c6 Mon Sep 17 00:00:00 2001
From: Rafa 
Date: Sat, 13 Jun 2020 20:59:16 +0200
Subject: [PATCH] Fix display of bug number

---
 english/security/2020/dsa-4698.wml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/english/security/2020/dsa-4698.wml b/english/security/2020/dsa-4698.wml
index f381cd0001c..923c0fe7d3f 100644
--- a/english/security/2020/dsa-4698.wml
+++ b/english/security/2020/dsa-4698.wml
@@ -226,8 +226,7 @@ leaks.
 For the oldstable distribution (stretch), these problems have been
 fixed in version 4.9.210-1+deb9u1.  This version also fixes some
 related bugs that do not have their own CVE IDs, and a regression in
-the macvlan driver introduced in the previous point release (bug
-#952660).
+the macvlan driver introduced in the previous point release (bug #952660).
 
 We recommend that you upgrade your linux packages.
 
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#962766: autotools-dev: New versions upstream

[Thorsten Glaser]

Henrique de Moraes Holschuh dixit:

>I emailed whomever I could track down at the time, as well as people
>that were suggested as "might be interested" by the ones I managed to
>reach.  This is like, the third time I try to get a x32 enthusiast to
>help ?

Hrm okay. We apparently are somewhat disconnected, although I still
hang in #debian-x32 on Freenode.

>If https://wiki.debian.org/X32Port was up-to-date, the issue might have
>been resolved a long time ago.

I added the IRC there. We seem to not have a porter list.
Aurélien might know who has porter upload rights; I’d guess
me, cbmuser, perhaps kilobyte and maybe Daniel Schepler(?),
whom I haven’t seen in ages.

>An email to d-devel might be acceptable (unlike sending it to d-d-a, the
>fact that you even suggest d-d-a to reach a x32 porter thruly worries

Sorry, d-devel is much too high-traffic for me currently, and
very polarising and hurting during some… discussions some years
ago so I had to unsubscribe.

>But IMO, arches *must* have up-to-date, active points of contact, and
>that they must be easy to locate when you need them.  That biased me

Agreed. I know cbmuser does the buildds, but I don’t know who
is currently involved. I did tend to consider my status more
like “user who occasionally helps fixing stuff” than porter,
but if this is what it takes to keep x32, I’d be willing to do
more. But we need more coordination for that…

>Note that on previous tries, I did email GNU config upstream, and as far
>as I recall, the people behind the original patches for x32, and asked
>around for people in #d-devel in IRC, etc.
>
>Also, please keep in mind that I went out of my way to help x32 deploy
>in gnu config and Debian at the time it was introduced, it is not like I
>have anything against x32 or its continued existence.

Okay. Thanks, and appreciated. I was pointed to this bug by
an eMail that… somewhat interrupted me during work, so I was
scrambling to respond quickly. No slight or something intended.

>> >I am seriously considering uploading it and effectively removing x32
>> >support from Debian.

This was what alarmed me.

>Sure, please send me a patch that applies against latest upstream and I
>will carry it for as long as it works *and* if it breaks, delay new
>upstreams for a while to get it fixed (that means a few weeks/months,
>not an year, though).

Okay. That’s an impressive offer, thank you. I’ll work on this…
tomorrow, if I can make it.

>However, I *recommend* that this page get a proper update including a
>list of active points of contact: https://wiki.debian.org/X32Port

Indeed. I don’t currently know who to ask, but I’ll point cbmuser
to this bug and ask aurel32. I’ve also added an appropriate section
near the very top of the page.

>And that effort be made to restore x32 in GNU config upstream, even if
>it means convincing upstream to accept the dependency on pre-processors.

Preprocessor could be even better, if we have CPP_FOR_BUILD we can
go with the ifdef used in normal program code as well. But I fear
there is a reluctance (I was informed that they wish to deprecate
CC_FOR_BUILD entirely, in the above-mentioned thread).

Thanks for the informative response,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#962637: node-left-pad -- String left-pad

[fancycade]

Hi there,

> Please don't package already deprecated things in Debian - if you reallz
> need it for compat reasons, make it a wrapper around
> String.prototype.padStart().
>

Trust me, I would not be packaging this if I didn't feel like I had to.

I have taken your advice and created a simple Node package to act as a wrapper.

You can find it here: https://salsa.debian.org/js-team/left-pad

My plan is to create Debian package off of that repository.

Do you think this is acceptable now?

Thanks for the feedback!

Harley

Bug#962773: libpcre2-dev: Linuxinfo fails to link: ./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'

[Helge Kreutzmann]

Package: libpcre2-dev
Version: 10.34-7
Severity: normal

The version of linuxinfo in stable builds and links fine, using
version 10.32-5 of libpcre2-dev.:

Script started on 2020-06-13 21:25:44+02:00 [TERM="linux" TTY="/dev/tty6" 
COLUMNS="240" LINES="75"]
helge@samd:/tmp/testfoo1/linuxinfo-3.1.2$ debuild
…
gcc -DPACKAGE_NAME=\"Linuxinfo\" -DPACKAGE_TARNAME=\"linuxinfo\" 
-DPACKAGE_VERSION=\"3.1.2\" -DPACKAGE_STRING=\"Linuxinfo\ 3.1.2\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"linuxinfo\" 
-DVERSION=\"3.1.2\" -Duse_regexp=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_UNISTD_H=1 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_STRSTR=1 
-DHAVE_UNAME=1 -DENABLE_NLS=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1 -I.  
-DLOCALEDIR=\"/usr/share/locale\" -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/tmp/testfoo1/linuxinfo-3.1.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -c -o linuxinfo_unknown.o linuxinfo_unknown.c
gcc  -g -O2 -fdebug-prefix-map=/tmp/testfoo1/linuxinfo-3.1.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -lpcre2-8 
-Wl,-z,relro -o linuxinfo linuxinfo.o linuxinfo_common.o linuxinfo_arm.o 
linuxinfo_alpha.o linuxinfo_ia64.o linuxinfo_intel.o linuxinfo_m68k.o 
linuxinfo_ppc.o linuxinfo_sh.o linuxinfo_hppa.o linuxinfo_s390.o 
linuxinfo_avr.o linuxinfo_sparc.o linuxinfo_mips.o linuxinfo_unknown.o
make[2]: Verzeichnis „/tmp/testfoo1/linuxinfo-3.1.2“ wird verlassen
…
Successfully signed dsc, buildinfo, changes files


When building the very same source in a sid changeroot, it fails:
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package linuxinfo
dpkg-buildpackage: info: source version 3.1.2-1
…
gcc -DPACKAGE_NAME=\"Linuxinfo\" -DPACKAGE_TARNAME=\"linuxinfo\" 
-DPACKAGE_VERSION=\"3.1.2\" -DPACKAGE_STRING=\"Linuxinfo\ 3.1.2\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"linuxinfo\" 
-DVERSION=\"3.1.2\" -Duse_regexp=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_UNISTD_H=1 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_STRSTR=1 
-DHAVE_UNAME=1 -DENABLE_NLS=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1 -I.  
-DLOCALEDIR=\"/usr/share/locale\" -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/tmp/testfoo2/linuxinfo-3.1.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -c -o linuxinfo_unknown.o linuxinfo_unknown.c
gcc  -g -O2 -fdebug-prefix-map=/tmp/testfoo2/linuxinfo-3.1.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -lpcre2-8 
-Wl,-z,relro -o linuxinfo linuxinfo.o linuxinfo_common.o linuxinfo_arm.o 
linuxinfo_alpha.o linuxinfo_ia64.o linuxinfo_intel.o linuxinfo_m68k.o 
linuxinfo_ppc.o linuxinfo_sh.o linuxinfo_hppa.o linuxinfo_s390.o 
linuxinfo_avr.o linuxinfo_sparc.o linuxinfo_mips.o linuxinfo_unknown.o
/usr/bin/ld: linuxinfo_common.o: in function `regstrcmp':
./linuxinfo_common.c:224: undefined reference to `pcre2_compile_8'
/usr/bin/ld: ./linuxinfo_common.c:252: undefined reference to 
`pcre2_match_data_create_from_pattern_8'
/usr/bin/ld: ./linuxinfo_common.c:254: undefined reference to `pcre2_match_8'
/usr/bin/ld: ./linuxinfo_common.c:281: undefined reference to 
`pcre2_match_data_free_8'
/usr/bin/ld: ./linuxinfo_common.c:282: undefined reference to 
`pcre2_code_free_8'
/usr/bin/ld: ./linuxinfo_common.c:276: undefined reference to 
`pcre2_match_data_free_8'
/usr/bin/ld: ./linuxinfo_common.c:277: undefined reference to 
`pcre2_code_free_8'
/usr/bin/ld: ./linuxinfo_common.c:237: undefined reference to 
`pcre2_get_error_message_8'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:499: linuxinfo] Fehler 1
make[2]: Verzeichnis „/tmp/testfoo2/linuxinfo-3.1.2“ wird verlassen
make[1]: *** [Makefile:593: all-recursive] Fehler 1
make[1]: Verzeichnis „/tmp/testfoo2/linuxinfo-3.1.2“ wird verlassen
dh_auto_build: error: make -j1 returned exit code 2
make: *** [debian/rules:14: build] Fehler 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

I tried to figure out in NEWs etc. if there was a subtle change in
version 10.34-7 compared to 10.32-5 to no avail. 

When searching the net I found a few similar reports which suggested
downgrading, but no proper solution. I could not find a bug report in
the Debian BTS nor in upstream regarding this issue.

I compared the build outputs, they are the same (until the failure).
The only thing I could discern was that in unstable configure got a
new option added:
--disable-option-checking

I haven't fully figured out where this comes from, but since pcre2 is
checked and found as usual (in both cases) I don't think this relates.

I'm rather lost at the moment, so forgive me if I missed the warning
in big red letters…

Thanks

-- 
  

Bug#962766: autotools-dev: New versions upstream

[Henrique de Moraes Holschuh]

On Sat, 13 Jun 2020, Thorsten Glaser wrote:
> I haven’t ever seen this. I’ve prominently worked on x32 support and
> am known to be a user relying on this and willing to help. You could
> at least have asked on d-d-announce or something.

I emailed whomever I could track down at the time, as well as people
that were suggested as "might be interested" by the ones I managed to
reach.  This is like, the third time I try to get a x32 enthusiast to
help ?

If https://wiki.debian.org/X32Port was up-to-date, the issue might have
been resolved a long time ago.

An email to d-devel might be acceptable (unlike sending it to d-d-a, the
fact that you even suggest d-d-a to reach a x32 porter thruly worries
me).  I should have considered sending it more strongly...  and likely
would, before going through with the removal.

But IMO, arches *must* have up-to-date, active points of contact, and
that they must be easy to locate when you need them.  That biased me
against sending emails around to lots of people.  Oh well, my mistake I
suppose.

Note that on previous tries, I did email GNU config upstream, and as far
as I recall, the people behind the original patches for x32, and asked
around for people in #d-devel in IRC, etc.

Also, please keep in mind that I went out of my way to help x32 deploy
in gnu config and Debian at the time it was introduced, it is not like I
have anything against x32 or its continued existence.

> >I am seriously considering uploading it and effectively removing x32
> >support from Debian.
> 
> Please don’t. This can trivially be carried locally (which we did for
> other architectures, even new ones, before so has precedent) and we
> can lobby upstream to retain it.

Sure, please send me a patch that applies against latest upstream and I
will carry it for as long as it works *and* if it breaks, delay new
upstreams for a while to get it fixed (that means a few weeks/months,
not an year, though).

However, I *recommend* that this page get a proper update including a
list of active points of contact: https://wiki.debian.org/X32Port

And that effort be made to restore x32 in GNU config upstream, even if
it means convincing upstream to accept the dependency on pre-processors.

-- 
  Henrique Holschuh

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported ZFS (with acltype=off) (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Elliott Mitchell]

On Sat, Jun 13, 2020 at 02:54:31PM +0200, Salvatore Bonaccorso wrote:
> indicated this was specifically observed on ZFS on Linux only. Seth
> Arnold's answer seem to be inline with that that the issue is more on
> the ZFS on Linux side and the issue keeps biting people a bit
> unexpectedly. Why does this break with ACL off settings?

I disagree with this assessment.  All of the reporters have been using
ZFS, but this could indicate an absence of testers using other
filesystems.  We need someone with a NFS server which has a 4.15+ kernel
and uses a different filesystem which supports ACLs.

I'm though doubtful ACLs are related to the actual problem.  My
impression of what I've read is they're a useful tool to work around the
problem, but not related to the actual cause.


> But there was at least one other (but again without further
> detail/followups) that it was observed on an export from OpenWRT, but
> no specific details here:
> 
> https://bugs.openwrt.org/index.php?do=details&task_id=2581

This appears to be the same reporter as the RedHat bug report (comment 3
on the RedHat report).  This is a report for the server portion of the
reporter's setup.

Analyzing the setup, I disagree with one of the prior assessment of this
report.  This is OpenWRT on x86_64 hardware which would suggest a
high-end router or embedded device.  Such might well have ECC memory and
a processor fast enough to handle ZFS.



Let me add one more data point.  I had been thinking I might need the
additional features in Linux-ZFS 0.7.12.  As such my NFS server had been
running a 4.9 kernel with Debian's ZFS 0.7.12-2+debg10u1~bpo9+1 packages.
Now with the problem manifesting my NFS server is running a 4.19 kernel
with Debian's ZFS 0.7.12-2+deb10u2 packages.

I could well believe the actual root cause is a problem with the
Linux-ZFS implementation.  What manifested the problem though seems to be
in Linux's NFS implementation between 4.9 and 4.15.  ie Linux-ZFS
implemented /something/ which worked when implemented, but may not have
properly implemented the intended API and was broken by Linux-NFS.


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

Bug#962766: autotools-dev: New versions upstream

[Thorsten Glaser]

Vincent Lefevre dixit:

> x86_64:Linux:*:*)
>-   if objdump -f /bin/sh | grep -q elf32-x86-64; then
>-   echo "$UNAME_MACHINE"-pc-linux-"$LIBC"x32
>-   else
>-   echo "$UNAME_MACHINE"-pc-linux-"$LIBC"
>-   fi
>+   echo "$UNAME_MACHINE"-pc-linux-"$LIBC"
>exit ;;

Note that this code is actually wrong anyway (and known to
mis-detect on my system due to klibc being LP64 on x32).

https://lists.gnu.org/archive/html/config-patches/2018-02/msg00019.html

We *MUST* do something like this instead:

x86_64:Linux:*:*)
   case $(${CC_FOR_BUILD:-${CC:-gcc}} -dumpmachine) in
   *x32) echo "$UNAME_MACHINE"-pc-linux-"$LIBC"x32 ;;
   *)echo "$UNAME_MACHINE"-pc-linux-"$LIBC";;
   esac
   exit ;;

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#962750: Update nheko in buster-backports to to latest upstream release (0.7.1)

[Nilesh]

Hi,

On Sat, 13 Jun 2020 16:22:21 +0530 Pirate Praveen
 wrote:

> Package: nheko
> Version: 0.6.4-2~bpo10+1
> Severity: wishlist
> X-debbugs-cc: debian-backpo...@lists.debian.org
> Control: tags -1 help
>
> I'm trying to update nheko to 0.7.1 in buster-backports (packages still
> in backports-new are avilable from
> https://people.debian.org/~praveen/fasttrack-staging/ and use
> buster-backports branch of nheko). From a first look, it seems we need
> a new c++ standard library. Can someone help here?
>
> [ 90%] Linking CXX executable media_downloader
> cd /<>/.deps/examples && /usr/bin/cmake -E
> cmake_link_script CMakeFiles/media_downloader.dir/link.txt --verbose=1
> /usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -DSPDLOG_FMT_EXTERNAL -DFMT_HEADER_ONLY
> -DSPDLOG_FMT_EXTERNAL -DFMT_HEADER_ONLY -Wall -Wextra -pipe -pedantic
> -fsized-deallocation -fdiagnostics-color=always -Wunreachable-code
> -Wl,-z,relro CMakeFiles/media_downloader.dir/media_downloader.cpp.o -o
> media_downloader ../libmatrix_client.a
> /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.71.0
> /usr/lib/x86_64-linux-gnu/libboost_system.so.1.71.0
> /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.71.0
> /usr/lib/x86_64-linux-gnu/libboost_atomic.so.1.71.0
> /usr/lib/x86_64-linux-gnu/libssl.so
> /usr/lib/x86_64-linux-gnu/libcrypto.so
> /usr/lib/x86_64-linux-gnu/libolm.so.3.1.4
> /usr/lib/x86_64-linux-gnu/libz.so
> /usr/lib/x86_64-linux-gnu/libsodium.so -pthread
> /usr/bin/ld: CMakeFiles/media_downloader.dir/media_downloader.cpp.o: in
> function
>
`print_message(std::variant,

> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::StateEvent,
> mtx::events::EncryptedEvent,
> mtx::events::RedactionEvent,
> mtx::events::Sticker,
> mtx::events::RoomEvent,
> mtx::events::RoomEvent,
> mtx::events::RoomEvent,
> mtx::events::RoomEvent,
> mtx::events::RoomEvent,
> mtx::events::RoomEvent,
> mtx::events::RoomEvent,
> mtx::events::RoomEvent >
> const&)::{lambda(std::__cxx11::basic_string std::char_traits, std::allocator > const&,

I tried to fix it, and reporting what was done.


- Tried appending `-lstdc++fs` to CXXFLAGS in debian/rules
- Appending the same to CMAKE_CXX_FLAGS in CMakeLists.txt
- Add "std::filesystem" and/or stdc++fs to link_taget_libraries in
CMakeLists.txt

The result is still exactly same as the error reported.
I also noticed that there's a usage of the namespace in line 119,
std::filesystem::path at
nheko-0.7.1/mtxclient/examples/media_downloader.cpp - this doesn't throw
any error.
Hence, _maybe_ this is not a linker error but something else, not sure
what is exactly wrong here.

NB: Stable has g++version 8.3.0

Kind Regards,
Nilesh

Bug#962766: autotools-dev: New versions upstream

[Thorsten Glaser]

XTaran dixit:

>IIRC hast Du ab und an mal Zeugs mit x32 gemacht.

Erm… yes… I’m using x32 productively on my desktop at work…

>Via https://wiki.debian.org/TopicDebianDevel bin ich grade |ber das
>hier gestolpert:
>
>* last call for the existence of x32 in autotools-dev. Reply on
>  #962766
>
>Inbesondere https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962766#10:

Henrique de Moraes Holschuh dixit:

>On Sat, 13 Jun 2020, Vincent Lefevre wrote:
>> There are new versions upstream.
>
>Yes, and they revert the existence of arch "x32".  Last time I asked for
>help, nobody remotely interested in x32 answered.

I haven’t ever seen this. I’ve prominently worked on x32 support and
am known to be a user relying on this and willing to help. You could
at least have asked on d-d-announce or something.

>I am seriously considering uploading it and effectively removing x32
>support from Debian.

Please don’t. This can trivially be carried locally (which we did for
other architectures, even new ones, before so has precedent) and we
can lobby upstream to retain it.

Thanks,
//mirabilos
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#962772: valgrind thinks that size_t is signed

[Vincent Lefevre]

Package: valgrind
Version: 1:3.15.0-1
Severity: normal

When testing GNU MPFR with valgrind:

FAIL: tabort_defalloc1
==

[tabort_defalloc1] Check for good handling of abort in memory function.
==3948670== Argument 'size' of function malloc has a fishy (possibly negative) 
value: -1
==3948670==at 0x483677F: malloc (vg_replace_malloc.c:309)
==3948670==by 0x10C453: mpfr_default_allocate (memory.c:69)
==3948670==by 0x10C453: tests_allocate (memory.c:162)
==3948670==by 0x488A18F: mpfr_allocate_func (mpfr-gmp.c:315)
==3948670==by 0x10A485: main (tabort_defalloc1.c:43)
==3948670== 
[MPFR] mpfr_default_allocate(): can't allocate memory 
(size=18446744073709551615)
FAIL tabort_defalloc1 (exit status: 1)

FAIL: tabort_defalloc2
==

[tabort_defalloc2] Check for good handling of abort in memory function.
==3948672== Argument 'size' of function realloc has a fishy (possibly negative) 
value: -1
==3948672==at 0x4838D7B: realloc (vg_replace_malloc.c:836)
==3948672==by 0x10C552: mpfr_default_reallocate (memory.c:84)
==3948672==by 0x10C552: tests_reallocate (memory.c:213)
==3948672==by 0x10C552: tests_reallocate (memory.c:174)
==3948672==by 0x488A1F0: mpfr_reallocate_func (mpfr-gmp.c:326)
==3948672==by 0x10A4A7: main (tabort_defalloc2.c:46)
==3948672== 
[MPFR] mpfr_default_reallocate(): can't reallocate memory (old_size=128 
new_size=18446744073709551615)
FAIL tabort_defalloc2 (exit status: 1)

The malloc / realloc argument is of type size_t, which is unsigned
according to the C standard, thus cannot be negative!

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

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

Versions of packages valgrind depends on:
ii  libc6  2.30-8
ii  libc6-dbg  2.30-8

Versions of packages valgrind recommends:
ii  gdb   9.2-1
ii  valgrind-dbg  1:3.15.0-1

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

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

Bug#962766: autotools-dev: New versions upstream

[Vincent Lefevre]

On 2020-06-13 14:40:55 -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 13 Jun 2020, Vincent Lefevre wrote:
> > There are new versions upstream.
> 
> Yes, and they revert the existence of arch "x32".  Last time I asked for
> help, nobody remotely interested in x32 answered.

Thanks for the information. I didn't know that.

After looking at the diff, it seems that the change is minimal:

 x86_64:Linux:*:*)
-   if objdump -f /bin/sh | grep -q elf32-x86-64; then
-   echo "$UNAME_MACHINE"-pc-linux-"$LIBC"x32
-   else
-   echo "$UNAME_MACHINE"-pc-linux-"$LIBC"
-   fi
+   echo "$UNAME_MACHINE"-pc-linux-"$LIBC"
exit ;;

But I might miss something (and I don't use x32 myself).

> I am seriously considering uploading it and effectively removing x32
> support from Debian.

This probably needs to be discussed and see what other distributions
do.

I got a suggestion to use the more recent upstream versions for the
next MPFR release. So in the mean time, I will stick with Debian's.

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

Bug#962766: autotools-dev: New versions upstream

[Henrique de Moraes Holschuh]

On Sat, 13 Jun 2020, Vincent Lefevre wrote:
> There are new versions upstream.

Yes, and they revert the existence of arch "x32".  Last time I asked for
help, nobody remotely interested in x32 answered.

I am seriously considering uploading it and effectively removing x32
support from Debian.

-- 
  Henrique Holschuh

Bug#690849: downgrade fontconfig-config dependencies on fonts to Recommends:

[Ivan Shmakov]

> On 2012-11-11 03:30:58 +0700, Ivan Shmakov wrote:

[…]

 > It took longer than I expected, but I can confirm that neither
 > extract(1), nor pdftotext(1) (both depending on libpoppler19 and thus
 > fontconfig-config) require fonts to operate.  (I presume that GNUnet
 > “non-GUI” processes don't use fonts, either.)

FTR, I believe that GNUnet documentation at one point explicitly
recommended that separate binary packages are provided by
distributions, so that, for instance, the core server(s) would
/not/ depend on libextract (and thus libpoppler and libfontconfig.)

So far this recommendation isn’t implemented in Debian.

[…]

 > To stress it out: due to the libpoppler19 ← libfontconfig1
 > dependency, the latter may become a requirement on systems deployed
 > to deal with PDF files (as in: search engine indexing.)  Given that
 > such a system may itself reside on a “virtual”, resource-limited
 > (as in: a couple of GiB's of filesystem space) server, it may be
 > entirely reasonable to try to save every MiB of the available FS space.

 > That being said, ttf-bitstream-vera takes less than a MiB (as per
 > Installed-Size:), so this issue could certainly be deferred until
 > Wheezy is released.  (And then perhaps the considerations above would
 > no longer be of much importance.)

These days, my primary concern is the amount of code installed
on my systems, as that contributes heavily to their respective
‘attack surfaces’.  With ttf-bitstream-vera being a pure data
package, which apparently knew no security issues (and none I’d
personally expect), I have no qualms about having it installed
on those of my systems where more comprehensive font packages
aren’t needed.

As such, and unless some further work is planned on this issue,
I suggest it be tagged wontfix.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#962771: RM: virt-goodies -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove virt-goodies. It depends on Python 2, is dead upstream and the
last maintainer upload was in 2013.

Cheers,
Moritz

Bug#962770: RM: denyhosts -- RoQA; Unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove denyhosts. It was originally removed back in 2014
for security issues and then eventually re-uploaded in 2015.
However, since then there have been no further uploads, it
depends on Py2 and the question of security support is still
unresolved (802917), so please remove it.

Cheers,
Moritz

Bug#937485: pymvpa2: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

As the upstream and Debian maintainer for it, I am ok with it. It could be 
easily made to build for python 3 but tests would show that it is not entirely 
kosher. I better reupload it when it i an sure it is functioning correctly again

On June 13, 2020 1:16:58 PM EDT, "Moritz Mühlenhoff"  wrote:
>On Mon, Feb 03, 2020 at 08:36:43AM +1100, Stuart Prescott wrote:
>> Dear maintainers,
>> 
>> In the last update on pymvpa2, it sounded like upstream would soon
>have sorted 
>> Python 3 compatibility and the FTBFS bugs for the package would soon
>be fixed. 
>> However, there has been no upstream activity in the referenced PR 
>> https://github.com/PyMVPA/PyMVPA/pull/525 for many months.
>> 
>> What are the prospects for a fixed package in the buster release
>cycle? Given 
>> that it will have to go through NEW to gain the Python 3 module
>package in any 
>> case, are we at the stage where it should just be removed from
>Debian, perhaps 
>> to be reintroduced later when upstream work is completed?
>> 
>> (There's a cost to keeping buggy packages in Debian in that they
>occupy 
>> people's time when dealing with transitions or bug squashing. Even
>finding the 
>> packaging Vcs to see if there has been yet-to-be uploaded progress on
>these 
>> bugs is excessively difficult right now)
>
>Indeed, let's remove it from unstable for now?
>
>Cheers,
>Moritz

Bug#962757: intel-microcode: System hangs on boot - Dell Latitude 7400/i5-8265U (CPU sig 0x806ec)

[Henrique de Moraes Holschuh]

On Sat, 13 Jun 2020, Henrique de Moraes Holschuh wrote:
> Issue reported upstream at:
> https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/33

This is incorrect, the above upstream issue is for 0x806eb.

The one for 0x806ec is this:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/24

Although the report upstream mentions hangs already with revision 0xca,
which contradicts this Debian bug report.  Might be separate issues.

-- 
  Henrique Holschuh

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot

Bug#937485: pymvpa2: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Mon, Feb 03, 2020 at 08:36:43AM +1100, Stuart Prescott wrote:
> Dear maintainers,
> 
> In the last update on pymvpa2, it sounded like upstream would soon have 
> sorted 
> Python 3 compatibility and the FTBFS bugs for the package would soon be 
> fixed. 
> However, there has been no upstream activity in the referenced PR 
> https://github.com/PyMVPA/PyMVPA/pull/525 for many months.
> 
> What are the prospects for a fixed package in the buster release cycle? Given 
> that it will have to go through NEW to gain the Python 3 module package in 
> any 
> case, are we at the stage where it should just be removed from Debian, 
> perhaps 
> to be reintroduced later when upstream work is completed?
> 
> (There's a cost to keeping buggy packages in Debian in that they occupy 
> people's time when dealing with transitions or bug squashing. Even finding 
> the 
> packaging Vcs to see if there has been yet-to-be uploaded progress on these 
> bugs is excessively difficult right now)

Indeed, let's remove it from unstable for now?

Cheers,
Moritz

Bug#937437: pyfeed: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:33:42AM +, Matthias Klose wrote:
> Package: src:pyfeed
> Version: 0.7.4-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> 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.

Thomas, back in 2018 you uploaded a py3-compatible version of pyfeed
to experimental, but at this point there are no reverse dependencies
left for pyfeed in the archive. Are you still planning to upload that
version to sid or should pyfeed by removed?

Cheers,
Moritz

Bug#936239: fixed in brian 2.2.2.1-1

[Moritz Mühlenhoff]

On Sat, Oct 12, 2019 at 10:00:17PM +, Andreas Tille wrote:
> Source: brian
> Source-Version: 2.2.2.1-1
> 
> We believe that the bug you reported is fixed in the latest version of
> brian, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 936...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Andreas Tille  (supplier of updated brian package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Thu, 03 Oct 2019 08:28:05 +0200
> Source: brian
> Binary: python3-brian python3-brian-lib python-brian-doc
> Architecture: source all amd64
> Version: 2.2.2.1-1
> Distribution: experimental
> Urgency: medium
> Maintainer: NeuroDebian Team 
> Changed-By: Andreas Tille 
> Description:
>  python-brian-doc - simulator for spiking neural networks - documentation
>  python3-brian - simulator for spiking neural networks
>  python3-brian-lib - simulator for spiking neural networks -- extensions
> Closes: 876920 896426 936239
> Changes:
>  brian (2.2.2.1-1) experimental; urgency=medium
>  .
>* Team upload.
>* New upstream version providing Python3 support
>  Closes: #936239, #876920
>* Verified that import works
>  Closes: #896426
>* Point watch file to Github
>* debhelper-compat 9
>* Point Vcs fields to salsa.debian.org
>* Standards-Version: 4.4.1
>* Testsuite: autopkgtest-pkg-python
>* buildsystem=pybuild
>* Lintian-overrides for issues created by sphinx
>* hardening=+all
>* More verbose long descriptions

I noticed that this wasn't uploaded to unstable for quite some time, is there
any other remaining issue?

Cheers,
Moritz

Bug#962769: mirror submission for mirrors.nju.edu.cn

[Yao Ge]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.nju.edu.cn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Yao Ge 
Country: CN China
Location: Nanjing
Sponsor: eScience Center, Nanjing University https://sci.nju.edu.cn/
Comment: CDImage-* debian-cd
 https://mirrors.nju.edu.cn/debian-cd/
 
 debian-archive
 https://mirrors.nju.edu.cn/debian-archive/




Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/mirrors.nju.edu.cn

Bug#962768: mirror submission for mirrors.nju.edu.cn

[Yao Ge]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.nju.edu.cn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Yao Ge 
Country: CN China
Location: Nanjing
Sponsor: eScience Center, Nanjing University  https://sci.nju.edu.cn/
Comment: CDImage: https://mirrors.nju.edu.cn/debian-cd/
 
 




Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/mirrors.nju.edu.cn

Bug#962757: intel-microcode: System hangs on boot - Dell Latitude 7400/i5-8265U (CPU sig 0x806ec)

[Henrique de Moraes Holschuh]

On Sat, 13 Jun 2020, Eugenio Paolantonio wrote:
> Latest intel-microcode update (3.20200609.2~deb10u1) renders my laptop (Dell
> Latitude 7400) hang during the load of the initramfs.
> 
> Downgrading the package to 3.20191115.2~deb10u1 fixes the issue.
> 
> Excerpt from dmesg (with the old microcode):
> [0.986742] microcode: sig=0x806ec, pf=0x80, revision=0xca

Good to know it works with 0xca, there are too many confusing reports,
including several (on Ubuntu) about failures with 0xca...

Issue reported upstream at:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/33

We will most likely have to revert this specific microcode update
(0x806ec), and very probably also its companion 0x906ec.

-- 
  Henrique Holschuh

Bug#962750: Update nheko in buster-backports to to latest upstream release (0.7.1)

[Gunter Königsmann]

Wait: it compiles and then the linker tells is that a command that was declared 
somewhere was never compiled? That looks like a -l switch is missing in the 
linker command line. Or like a library declares to provide things it then 
doesn't which would be a big in that library.

On June 13, 2020 12:52:21 PM GMT+02:00, Pirate Praveen 
 wrote:
>Package: nheko
>Version: 0.6.4-2~bpo10+1
>Severity: wishlist
>X-debbugs-cc: debian-backpo...@lists.debian.org
>Control: tags -1 help
>
>I'm trying to update nheko to 0.7.1 in buster-backports (packages still 
>in backports-new are avilable from 
>https://people.debian.org/~praveen/fasttrack-staging/ and use 
>buster-backports branch of nheko). From a first look, it seems we need 
>a new c++ standard library. Can someone help here?
>
>[ 90%] Linking CXX executable media_downloader
>cd /<>/.deps/examples && /usr/bin/cmake -E 
>cmake_link_script CMakeFiles/media_downloader.dir/link.txt --verbose=1
>/usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=. 
>-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>-D_FORTIFY_SOURCE=2 -DSPDLOG_FMT_EXTERNAL -DFMT_HEADER_ONLY 
>-DSPDLOG_FMT_EXTERNAL -DFMT_HEADER_ONLY -Wall -Wextra -pipe -pedantic 
>-fsized-deallocation -fdiagnostics-color=always -Wunreachable-code 
>-Wl,-z,relro CMakeFiles/media_downloader.dir/media_downloader.cpp.o -o 
>media_downloader ../libmatrix_client.a 
>/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.71.0 
>/usr/lib/x86_64-linux-gnu/libboost_system.so.1.71.0 
>/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.71.0 
>/usr/lib/x86_64-linux-gnu/libboost_atomic.so.1.71.0 
>/usr/lib/x86_64-linux-gnu/libssl.so 
>/usr/lib/x86_64-linux-gnu/libcrypto.so 
>/usr/lib/x86_64-linux-gnu/libolm.so.3.1.4 
>/usr/lib/x86_64-linux-gnu/libz.so 
>/usr/lib/x86_64-linux-gnu/libsodium.so -pthread
>/usr/bin/ld: CMakeFiles/media_downloader.dir/media_downloader.cpp.o: in 
>function 
>`print_message(std::variant,
> 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::EncryptedEvent, 
>mtx::events::RedactionEvent, 
>mtx::events::Sticker, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent > 
>const&)::{lambda(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::__cxx11::basic_string, 
>std::allocator > const&, std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::optional 
>const&)#1}::operator()(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::__cxx11::basic_string, 
>std::allocator > const&, std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::optional const&) const':
>/usr/include/c++/8/bits/fs_path.h:184: undefined reference to 
>`std::filesystem::__cxx11::path::_M_split_cmpts()'
>/usr/bin/ld: CMakeFiles/media_downloader.dir/media_downloader.cpp.o: in 
>function 
>`print_message(std::variant,
> 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::StateEvent, 
>mtx::events::EncryptedEvent, 
>mtx::events::RedactionEvent, 
>mtx::events::Sticker, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent, 
>mtx::events::RoomEvent > 
>const&)::{lambda(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::__cxx11::basic_string, 
>std::allocator > const&, std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::optional 
>const&)#1}::operator()(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::__cxx11::basic_string, 
>std::allocator > const&, std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::optional const&) const':
>./.deps/examples/./mtxclient/examples/media_downloader.cpp:120: 
>undefined reference to `std::filesystem::__cxx11::path::parent_path() 
>const'
>/usr/bin/ld: 
>./.deps/examples/./mtxclient/examples/media_downloader.cpp:120: 
>undefined reference to 
>`std::filesystem::create_directories(std::filesystem::__cxx11::path 
>const&)'
>collect2: error: ld returned 1 exit status
>make[4]: *** [examples/CMakeFiles/media_downloader.dir/build.make:97: 
>examples/media_downloader] Error 1
>make[4]: Leaving directory '/<>/.deps'
>make[3]: *** [CMakeFiles/Makefile2:132: 
>examples/CMakeFi

Bug#962645: qbittorrent-nox: Qbittorrent-nox is barely usable after the upgrade to 4.2.4-1+b1

[jim_p]

Package: qbittorrent-nox
Version: 4.2.4-1+b1
Followup-For: Bug #962645

Yes and no. It now works as it should on my i386 system, but it still fails on
the amd64 one.
The output I get at the terminal is identical to the one I mention above. Also,
the gui version of qbittorrent crashes on the amd64 system as I said on
#962716.



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

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

Versions of packages qbittorrent-nox depends on:
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libqt5core5a5.12.5+dfsg-10+b1
ii  libqt5network5  5.12.5+dfsg-10+b1
ii  libqt5xml5  5.12.5+dfsg-10+b1
ii  libssl1.1   1.1.1g-1
ii  libstdc++6  10.1.0-3
ii  libtorrent-rasterbar10  1.2.5-1.1
ii  zlib1g  1:1.2.11.dfsg-2

qbittorrent-nox recommends no packages.

Versions of packages qbittorrent-nox suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#962767: java 11 bug with certs

[MG]

Package: ca-certificates-java (apt install ca-certificates-java)

version : apt 1.8.2.1 (armhf)   (on beagleboard - using 10.3 IoT image)


Note: Attempting to install jitsi


root@{hostname}:/home/debian# apt install ca-certificates-java
Reading package lists... Done
Building dependency tree
Reading state information... Done
ca-certificates-java is already the newest version (20190405).
ca-certificates-java set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up uuid-runtime (2.33.1-0.1) ...
Adding group `uuidd' (GID 117) ...
Done.
Warning: The home dir /run/uuidd you specified can't be accessed: No 
such file or directory

Adding system user `uuidd' (UID 109) ...
Adding new user `uuidd' (UID 109) with group `uuidd' ...
Not creating home directory `/run/uuidd'.
Created symlink /etc/systemd/system/sockets.target.wants/uuidd.socket → 
/lib/systemd/system/uuidd.socket.

Setting up ca-certificates-java (20190405) ...
Adding debian:ISRG_Root_X1.pem
Adding debian:EC-ACC.pem
Adding debian:GTS_Root_R4.pem
Adding debian:Entrust_Root_Certification_Authority_-_G4.pem
Adding debian:Staat_der_Nederlanden_EV_Root_CA.pem
Adding debian:GeoTrust_Universal_CA_2.pem
Adding debian:Sonera_Class_2_Root_CA.pem
Adding debian:emSign_ECC_Root_CA_-_G3.pem
Adding debian:IdenTrust_Commercial_Root_CA_1.pem
Adding debian:SSL.com_Root_Certification_Authority_RSA.pem
Adding debian:ePKI_Root_Certification_Authority.pem
Adding debian:XRamp_Global_CA_Root.pem
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0xb40dbb60, pid=3000, tid=3006
#
# JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 
11.0.7+10-post-Debian-3deb10u1)
# Java VM: OpenJDK Server VM (11.0.7+10-post-Debian-3deb10u1, mixed 
mode, serial gc, linux-)

# Problematic frame:
# J 45 c2 
sun.security.provider.X509Factory.readOneBlock(Ljava/io/InputStream;)[B 
java.base@11.0.7 (447 bytes) @ 0xb40dbb60 [0xb40dbae0+0x0080]

#
# No core dump will be written. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again

#
# An error report file with more information is saved as:
# //hs_err_pid3000.log
Could not load hsdis-arm.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
#   https://bugs.debian.org/openjdk-11
#
/var/lib/dpkg/info/ca-certificates-java.postinst: line 88:  2998 
Done    find /etc/ssl/certs -name \*.pem

  2999   | while read filename; do
    alias=$(basename $filename .pem | tr A-Z a-z | tr -cs a-z0-9 _); 
alias=${alias%*_}; if [ -n "$FIXOLD" ]; then

    echo "-${alias}"; echo "-${alias}_pem";
    fi; echo "+${filename}";
done
  3000 Aborted | java -Xmx64m -jar $JAR -storepass 
"$storepass"

dpkg: error processing package ca-certificates-java (--configure):
 installed ca-certificates-java package post-installation script 
subprocess returned error exit status 134

Processing triggers for systemd (241-7~deb10u4) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for ca-certificates (20200601~deb10u1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

done.
done.
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
 ca-certificates-java
E: Sub-process /usr/bin/dpkg returned an error code (1)


from uname:

Linux {hostname} 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 
UTC 2020 armv7l GNU/Linux



please let me know if you need more information...

Bug#962766: autotools-dev: New versions upstream

[Vincent Lefevre]

Package: autotools-dev
Version: 20180224.1
Severity: normal

Hi,

There are new versions upstream.

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

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

-- no debconf information

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

Bug#962757: intel-microcode: System hangs on boot - Dell Latitude 7400/i5-8265U (CPU sig 0x806ec)

[Pierre Erraud]

Hi,

I confirm I have the same problem with the same laptop (Dell Latitude
7400).

Neither 3.20200609.1 nor 3.20200609.2 works here, I downgraded
to 3.20200520.1.

I don't have exactly the same cpu:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 142
model name  : Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz
stepping: 12
microcode   : 0xca
cpu MHz : 1199.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx
f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single
ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept
vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx
rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves
dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear
flush_l1d arch_capabilities
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad
ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid
unrestricted_guest ple shadow_vmcs pml ept_mode_based_exec
bugs: spectre_v1 spectre_v2 spec_store_bypass swapgs taa
itlb_multihit srbds
bogomips: 4199.88
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

This laptop has got the latest firmwares from Dell (system firmware:
1.7.4).

I would raise the severity because the laptop can't boot with these
updates.

Regards,

Pierre

Bug#962764: mirror submission for mirrors.nju.edu.cn

[Yao Ge]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.nju.edu.cn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Yao Ge 
Country: CN China
Location: Nanjing




Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/mirrors.nju.edu.cn

Bug#962765: mirror submission for mirrors.nju.edu.cn

[Yao Ge]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.nju.edu.cn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Yao Ge 
Country: CN China
Location: Nanjing
Sponsor: eScience Center, Nanjing University https://sci.nju.edu.cn/




Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/mirrors.nju.edu.cn

Bug#550308: [xedit] missing deps on xbitmaps

[Ivan Shmakov]

Control: fixed -1 7.7~1

> On 2011-10-06 12:42:01 +0200, Ralf Jung wrote:

 > Actually, x11-apps currently recommends xbitmap, which does not exist
 > and is probably a typo of xbitmaps.

Per Debian changelog, this was fixed in 7.7~1.  I don’t seem
to see what else could be done for this issue, and thus suggest
to close this bug.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#961945: php-horde 5.2.20+debian0-1+deb10u2 flagged for acceptance

[Adam D. Barratt]

On Sat, 2020-06-13 at 15:41 +, Adam D Barratt wrote:
> package release.debian.org
> tags 961945 = buster pending
> thanks
> 
> Hi,
> 
> The upload referenced by this bug report has been flagged for
> acceptance into the proposed-updates queue for Debian buster.
> 
> Thanks for your contribution!
> 
> Upload details
> ==
> 
> Package: php-horde
> Version: 5.2.20+debian0-1+deb10u2

Oops, got the bug numbers for buster and stretch back to front

Bug#962402: haskell-text-icu built

[Adrian Bunk]

On Fri, Jun 12, 2020 at 09:49:21PM +0200, Frédéric Bonnard wrote:
> Hi,
> I wanted to check that FTBFS but it actually built, on different setup.
> After a give back on ppc64el and s390x, everything went fine. Very few
> changes between the failing and succeeding build. Same ghc, kernel.
> For the record, linux-libc-dev, libgmpxx4ldbl, libgmp-dev, libkrb5support0,
> libk5crypto3, libkrb5-3, libgssapi-krb5-2, libnghttp2-14, hscolour were
> not the same.

Both the buildd failures and the build failures in the reproducible CI 
look as if the failure is random, perhaps with a different probability
depending on some unknown factor.

> F.

cu
Adrian

Bug#901723: Fixing bug close number

[Boyuan Yang]

reopen 901723
fixed 901273 0.64-8
thanks

Sorry for closing the wrong bug number. Reopening it and closing the
correct one instead.

-- 
Regards,
Boyuan Yang


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

Bug#962755: exif: FTBFS on s390x: test failure

[Adrian Bunk]

On Sat, Jun 13, 2020 at 09:40:19AM -0400, Boyuan Yang wrote:
> Source: exif
> Vresion: 0.6.22-1
> Severity: serious
> X-Debbugs-CC: hugh.mcmas...@outlook.com
> 
> Dear Debian exif package maintainers,
> 
> The new upload of exif/0.6.22-1 FTBFS on s390x architecture due to test
> failure:
> 
> https://buildd.debian.org/status/fetch.php?pkg=exif&arch=s390x&ver=0.6.22-1&stamp=1591715266&raw=0
> 
> PASS: check-create-tags.sh
> PASS: check-help.sh
> PASS: check-init-mandatory-tags.sh
> FAIL: check-add-tags.sh
> PASS: check-param-validity.sh
> PASS: check-required-file.sh
> PASS: check-show-description.sh
> PASS: check-show-tag.sh
> PASS: check-tag-description.sh
> PASS: check-thumbnail.sh
> PASS: check-version.sh
> PASS: check-no-seek.sh
> 
>libexif command line interface 0.6.22: test/test-suite.log
> 
> 
> # TOTAL: 12
> # PASS:  11
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> Can you examine it and eventually fix it, perhaps using a porterbox?

This is a big endian problem, and s390x is the only big endian
release architecture.

Could an s390x porter (Cc added) please take a look?

> Regards,
> Boyuan Yang

cu
Adrian

Bug#746732: x11-apps: unable to edit with bitmap

[Ivan Shmakov]

Control: notfound -1 7.7+7

> On 2014-05-03 01:56:09 +0200, Frédéric Baldit wrote:

 > Package: x11-apps
 > Version: 7.5+5
 > Severity: normal

 > bitmap seems to work, but clicking the bitamp to edit/create an image
 > doesn’t work.

 > Found bug #429345 with same symptoms, but I was unable to fix the
 > problem (tried to reinstall x11-apps package).  I have another PC
 > with debian testing running and the problem is the same.

I don’t seem to be able to reproduce this problem with either
7.7+7 (Buster, with *customization: -color) or 7.7+8 (Bullseye,
without).  My guess is that it got fixed somewhere along the way
(say, with the introduction of bitmap 1.0.8 in 7.7+5.)

I suppose this bug can now be closed.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#962763: renderdoc FTBFS: undefined references to spvtools symbols

[Adrian Bunk]

Source: renderdoc
Version: 1.7+dfsg-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/renderdoc.html
https://buildd.debian.org/status/package.php?p=renderdoc&suite=sid

...
/usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++11 -fstrict-aliasing -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-variable 
-Wno-unused-parameter -Wno-unused-result -Wno-type-limits 
-Wno-missing-field-initializers -Wno-unknown-pragmas -Wno-reorder 
-Wno-unused-but-set-variable -Wno-maybe-uninitialized -Wno-class-memaccess 
-Wimplicit-fallthrough=2 -O3 -DNDEBUG -Wl,--undefined,force_include_libentry 
-Wl,--version-script,/<>/renderdoc/renderdoc.version 
-Wl,--no-undefined -Wl,-z,relro -shared -Wl,-soname,librenderdoc.so -o 
../lib/librenderdoc.so 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/blit.vert.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/checkerboard.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/glsl_ubos.h.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/glsl_globals.h.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/fixedcol.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/histogram.comp.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/mesh.comp.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/mesh.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/mesh.geom.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/mesh.vert.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/minmaxresult.comp.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/minmaxtile.comp.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/quadresolve.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/quadwrite.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/texdisplay.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/texremap.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/gl_texsample.h.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/gles_texsample.h.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/vk_texsample.h.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/gltext.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/gltext.vert.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/vktext.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/vktext.vert.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/array2ms.comp.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/ms2array.comp.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/trisize.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/trisize.geom.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/deptharr2ms.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/glsl/depthms2arr.frag.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/data/sourcecodepro.ttf.c.o 
CMakeFiles/renderdoc.dir/CMakeFiles/data.src/driver/vulkan/renderdoc.json.c.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_common.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_counters.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_debug.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_postvs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_overlay.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_outputwindow.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_rendermesh.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_rendertexture.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_rendertext.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_msaa_array_conv.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_driver.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_initstate.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_manager.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_renderstate.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_replay.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_resources.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_program_iterate.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_shader_refl.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/gl_stringise.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_buffer_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_debug_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_draw_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_emulated.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_framebuffer_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_get_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_interop_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_query_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_sampler_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_shader_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_state_funcs.cpp.o 
driver/gl/CMakeFiles/rdoc_gl.dir/wrappers/gl_texture_funcs.cpp.o 
driver/

Bug#962762: Should monotone-viz be removed from unstable?

[Adrian Bunk]

Package: monotone-viz
Severity: serious
Tags: bullseye sid

Neither monotone-viz nor monotone are in the current stable,
and monotone was already removed from unstable.

Should monotone-viz also be removed from unstable?

Bug#961936: ssvnc 1.0.29-4+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ssvnc
Version: 1.0.29-4+deb10u1

Explanation: fix out-of-bounds write [CVE-2018-20020], infinite loop 
[CVE-2018-20021], improper initialisation [CVE-2018-20022], potential 
denial-of-service [CVE-2018-20024]

Bug#962160: pagekite 0.5.9.3-2+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: pagekite
Version: 0.5.9.3-2+deb10u1

Explanation: avoid issues with expiry of shipped SSL certificates by using 
those from the ca-certificates package

Bug#961921: php-horde-gollem 3.0.12-3+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: php-horde-gollem
Version: 3.0.12-3+deb10u1

Explanation: fix cross-site scripting vulnerability in breadcrumb output 
[CVE-2020-8034]

Bug#962255: ruby-json 2.1.0+dfsg-2+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ruby-json
Version: 2.1.0+dfsg-2+deb10u1

Explanation: fix unsafe object creation vulnerability [CVE-2020-10663]

Bug#961978: freerdp2 2.0.0~git20190204.1.2693389a+dfsg1-1+deb10u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: freerdp2
Version: 2.0.0~git20190204.1.2693389a+dfsg1-1+deb10u2

Explanation: fix smartcard logins; security fixes [CVE-2020-11521 
CVE-2020-11522 CVE-2020-11523 CVE-2020-11524 CVE-2020-11525 CVE-2020-11526]

Bug#962227: libapache-mod-jk 1.2.46-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libapache-mod-jk
Version: 1.2.46-1+deb10u1

Explanation: rename Apache configuration file so it can be automatically 
enabled and disabled

Bug#962306: b43-fwcutter 019-4+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: b43-fwcutter
Version: 019-4+deb10u1

Explanation: ensure removal succeeds under non-English locales; do not fail 
removal if some files no longer exist; add missing dependencies on pciutils and 
ca-certificates

Bug#962758: dbus 1.12.18-1 only allows libsane-hpaio to find scanner when root

[Simon McVittie]

Control: tags -1 + moreinfo

On Sat, 13 Jun 2020 at 16:44:41 +0200, Jeffrey Ratcliffe wrote:
> Upgrade from dbus 1.12.16-2 to 1.12.18-1
> 
> scanimage -L
> 
> failed to find my HP OfficeJet 6500

This is unexpected: 1.12.18-1 shouldn't have changed anything related
to authorization or message filtering.

How is your HP OfficeJet 6500 connected/discovered?

After upgrading to 1.12.18-1, did you reboot the system before attempting
to find the scanner? Similarly, when you downgraded back to 1.12.16-2,
did you reboot?

After upgrading to 1.12.18-1 and rebooting, what messages are logged
in the systemd journal when you run "scanimage -L --verbose" as your
ordinary user, and what output does it produce? Also, what messages are
logged and what output does it produce when you run it as root?

Also, if you run "sudo dbus-monitor --system" in another terminal first,
what is logged there in each case? (Press Ctrl+C to exit.)

If you run scanimage -L multiple times as the same user, do you get the
same results each time?

(You can censor log messages and dbus-monitor output as long as you
make it obvious what you've changed, for example replacing MAC addresses
with xx:xx:xx:xx.)

To check that dbus-daemon is operating correctly in general, if you run
"busctl --system" as your ordinary, unprivileged user, do you get a list
of system bus connections?

One important thing that did change in 1.12.18-1 is that the system bus
server now listens on /var/run/dbus/system_bus_socket instead of on
/run/dbus/system_bus_socket. Is /var/run correctly a symbolic link to /run
on your system, and are all the permissions appropriate? It should look
something like this:

$ ls -dl /run /run/dbus /run/dbus/system_bus_socket /var /var/run /var/run/dbus 
/var/run/dbus/system_bus_socket
drwxr-xr-x 48 root root 1180 Jun 13 16:23 /run
drwxr-xr-x  3 root root   80 Jun 13 14:28 /run/dbus
srw-rw-rw-  1 root root0 Jun 13 14:28 /run/dbus/system_bus_socket
drwxr-xr-x  1 root root  126 Nov 11  2016 /var
lrwxrwxrwx  1 root root4 Jun  1  2012 /var/run -> /run
drwxr-xr-x  3 root root   80 Jun 13 14:28 /var/run/dbus
srw-rw-rw-  1 root root0 Jun 13 14:28 /var/run/dbus/system_bus_socket

smcv

Bug#961945: php-horde 5.2.20+debian0-1+deb10u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: php-horde
Version: 5.2.20+debian0-1+deb10u2

Explanation: fix cross-site scripting vulnerability [CVE-2020-8035]

Bug#865285: sntp: Cannot open KoD db file /var/db/ntp-kod: No such file or directory

[Robert Kennedy]

​Can't open KOD db file /var/lib/sntp/kod for writing: Permission denied

This bug is easy to fix.  The permissions are not set properly for the file 
/var/lib/sntp/kod in Debian Buster.

The permissions should be
-rw-rw-rw- 1 root root 0 Jun 13 11:00 /var/lib/sntp/kod

Until the bug is fixed, you can fix the permissions yourself using chmod.

P.S. Mac OS X also includes sntp.  Apple has set the permissions of the kod 
file (called ntp-kod in Mac OS X) to rw for all users.

This solution is preferable than setting the suid bit in the sntp command from 
a security point of view.

Bug#962760: ITP: biocore-ntnu-ncls -- datastructure for interval overlap queries

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: biocore-ntnu-ncls -- datastructure for interval overlap queries
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: biocore-ntnu-ncls
  Version : 0.0+git20200225.f9894b0
  Upstream Author : Endre Bakken Stovner
* URL : https://github.com/biocore-ntnu/ncls
* License : BSD-3-Clause
  Programming Lang: C
  Description : datastructure for interval overlap queries
 The Nested Containment List is a datastructure for interval overlap
 queries, like the interval tree. It is usually an order of magnitude
 faster than the interval tree both for building and query lookups.
 .
 The implementation here is a revived version of the one used in the
 now defunct PyGr library, which died of bitrot. It was now made less
 memory-consuming and wrapper functions allow batch-querying
 the NCLS for further speed gains.
 .
 This package was implemented to be the cornerstone of the PyRanges project,
 but was made available to the Python community as a stand-alone library.

Remark: This package is maintained by Debian Med Packaging Team at
   https://github.com/biocore-ntnu/ncls

Bug#962759: python3-grib: ValueError at import

[Antonio Valentino]

Package: python3-grib
Version: 2.0.4-3
Severity: important

Dear Maintainer,
trying to import pygrib causes a error:

  $ python3 -c "import pygrib"
  Traceback (most recent call last):
File "", line 1, in 
File "pygrib.pyx", line 306, in init pygrib
File "pygrib.pyx", line 305, in pygrib._get_grib_api_version
  ValueError: Unknown format code 'd' for object of type 'float'

the package, as well as all packages using it, are no longer usable.


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

Kernel: Linux 5.4.0-38-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-grib depends on:
ii  libc6   2.30-8
ii  libeccodes-data 2.17.0-2
ii  libeccodes-dev  2.17.0-2
ii  libeccodes0 2.17.0-2
ii  libgrib2c-dev   1.6.0-9+b1
ii  python3 3.8.2-3
ii  python3-numpy [python3-numpy-abi9]  1:1.18.4-1
ii  python3-pyproj  2.6.1+ds-1

Versions of packages python3-grib recommends:
ii  python-grib-doc  2.0.4-3

python3-grib suggests no packages.

-- no debconf information

Bug#962681:

[Gopal Sharma]

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Gopal Sharma 
To: Debian Bug Tracking System 
Subject: linux-image-5.6.0-2-amd64: battery drain during system shutdown
Message-ID: <159205777889.2976.15520989291996417969.reportbug@goapl-hp-notebook>
X-Mailer: reportbug 7.6.0
Date: Sat, 13 Jun 2020 19:46:18 +0530

Package: src:linux
Version: 5.6.14-1
Severity: important

Dear Maintainer,




-- Package-specific info:
** Version:
Linux version 5.6.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-13)) #1 SMP Debian 5.6.14-1 (2020-05-23)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.6.0-2-amd64 
root=UUID=a7b632c2-0e00-4c76-9345-d7f6f16ad4c3 ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: HP
product_name: HP Notebook
product_version: Type1ProductConfigId
chassis_vendor: HP
chassis_version: Chassis Version
bios_vendor: Insyde
bios_version: F.46
board_vendor: HP
board_name: 81EC
board_version: 61.59

** Loaded modules:
rfcomm
fuse
cmac
bnep
btusb
btrtl
btbcm
btintel
bluetooth
x86_pkg_temp_thermal
intel_powerclamp
coretemp
drbg
snd_hda_codec_hdmi
aes_generic
ghash_clmulni_intel
snd_soc_skl
snd_soc_hdac_hda
snd_hda_codec_realtek
snd_hda_ext_core
snd_soc_sst_ipc
snd_soc_sst_dsp
snd_soc_acpi_intel_match
snd_soc_acpi
snd_hda_codec_generic
ledtrig_audio
snd_soc_core
snd_compress
nls_ascii
nls_cp437
snd_hda_intel
joydev
vfat
snd_intel_dspcfg
aesni_intel
fat
intel_rapl_msr
snd_hda_codec
crypto_simd
efi_pstore
cryptd
intel_cstate
glue_helper
snd_hda_core
uvcvideo
ansi_cprng
videobuf2_vmalloc
videobuf2_memops
intel_uncore
snd_hwdep
videobuf2_v4l2
hp_wmi
videobuf2_common
sparse_keymap
intel_rapl_perf
ecdh_generic
pcspkr
ecc
snd_pcm
serio_raw
videodev
efivars
intel_wmi_thunderbolt
wmi_bmof
rmi_smbus
snd_timer
iTCO_wdt
mei_me
rfkill
rmi_core
libaes
iTCO_vendor_support
snd
processor_thermal_device
watchdog
mc
bcma
intel_rapl_common
int340x_thermal_zone
sg
mei
intel_pch_thermal
intel_soc_dts_iosf
soundcore
evdev
ac
hp_wireless
int3400_thermal
acpi_thermal_rel
acpi_pad
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
sr_mod
t10_pi
crc_t10dif
cdrom
crct10dif_generic
amdgpu
gpu_sched
mfd_core
i915
radeon
crct10dif_pclmul
crct10dif_common
ttm
ahci
libahci
crc32_pclmul
i2c_algo_bit
libata
xhci_pci
drm_kms_helper
xhci_hcd
crc32c_intel
r8169
psmouse
realtek
cec
libphy
i2c_i801
drm
scsi_mod
usbcore
usb_common
wmi
fan
battery
video
button

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp2s0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether ec:8e:b5:0d:46:a6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic noprefixroute 
enp2s0
   valid_lft 85561sec preferred_lft 85561sec
inet6 fe80::ee8e:b5ff:fe0d:46a6/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:4604  60000 0  0 0 4604  
60000 0   0  0
enp2s0: 24818104   215080  3360 0  0   156  1321160   
14077000 0   0  0


** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th 
Gen Core Processor Host Bridge/DRAM Registers [8086:1904] (rev 08)
Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Host Bridge/DRAM Registers [103c:81ec]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD 
Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Skylake GT2 [HD Graphics 520] 
[103c:81ec]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Proce

Bug#962006: apparmor="DENIED" operation="capable" profile="/usr/bin/man"

[xiscu]

Package: man-db
Version: 2.9.2-1
Followup-For: Bug #962006

Dear Maintainer,

I'm able to repoduce with:
> man -k man-recode

> then on the logs appear:

audit[42467]: AVC apparmor="DENIED" operation="capable" profile="/usr/bin/man" 
pid=42467 comm="apropos" capability=2  capname="dac_read_search"
Jun 13 16:46:37 r5 kernel: kauditd_printk_skb: 32 callbacks suppressed
Jun 13 16:46:37 r5 kernel: audit: type=1400 audit(1592059597.777:44): 
apparmor="DENIED" operation="capable" profile="/usr/bin/man" pid=42467 
comm="apropos" capability=2  capname="dac_read_search"
Jun 13 16:46:37 r5 kernel: audit: type=1400 audit(1592059597.777:45): 
apparmor="DENIED" operation="capable" profile="/usr/bin/man" pid=42467 
comm="apropos" capability=1  capname="dac_override"
Jun 13 16:46:37 r5 audit[42467]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/bin/man" pid=42467 comm="apropos" capability=1  
capname="dac_override"
Jun 13 16:46:42 r5 wpa_supplicant[772]: wlan0: WPA: Group rekeying completed 
with e0:28:6d:69:7a:f7 [GTK=CCMP]
Jun 13 16:46:48 r5 audit[42498]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/bin/man" pid=42498 comm="man" capability=2  
capname="dac_read_search"
Jun 13 16:46:48 r5 audit[42498]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/bin/man" pid=42498 comm="man" capability=1  capname="dac_override"

Hope it helps!
xiscu

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=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 man-db depends on:
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.74
ii  dpkg   1.19.7
ii  groff-base 1.22.4-5
ii  libc6  2.30-8
ii  libgdbm6   1.18.1-5
ii  libpipeline1   1.5.2-2
ii  libseccomp22.4.3-1+b1
ii  zlib1g 1:1.2.11.dfsg-2

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor2.13.4-2
ii  chromium [www-browser]  81.0.4044.92-1
ii  firefox [www-browser]   70.0.1-1+b1
pn  groff   
ii  less551-1
ii  lynx [www-browser]  2.9.0dev.5-1
ii  surf [www-browser]  2.0+git20190208-2

-- debconf information excluded

Bug#962758: dbus 1.12.18-1 only allows libsane-hpaio to find scanner when root

[Jeffrey Ratcliffe]

Package: dbus
Version: 1.12.16-2
Severity: important

Dear Maintainer,

   * What led up to the situation?

Upgrade from dbus 1.12.16-2 to 1.12.18-1

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

scanimage -L

failed to find my HP OfficeJet 6500

   * What was the outcome of this action?

No scanners found

   * What outcome did you expect instead?

That it listed my scanner

sudo scanimage -L

still worked.

I downgraded to 1.12.16-2 and scanimage was able to find the scanner again.



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

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

Versions of packages dbus depends on:
ii  adduser   3.118
ii  libapparmor1  2.13.4-1+b1
ii  libaudit1 1:2.8.5-3+b1
ii  libc6 2.30-8
ii  libcap-ng00.7.9-2.1+b2
hi  libdbus-1-3   1.12.16-2
ii  libexpat1 2.2.9-1
ii  libselinux1   3.0-1+b3
ii  libsystemd0   245.5-3

dbus recommends no packages.

Versions of packages dbus suggests:
hi  dbus-user-session [default-dbus-session-bus]  1.12.16-2

Versions of packages dbus is related to:
pn  dbus-x11  
ii  systemd   245.5-3
ii  systemd-sysv  245.5-3

-- no debconf information

Bug#962645: qbittorrent-nox: Qbittorrent-nox is barely usable after the upgrade to 4.2.4-1+b1

[Adrian Bunk]

On Fri, Jun 12, 2020 at 07:00:12PM +0300, jim_p wrote:
> Package: qbittorrent-nox
> Followup-For: Bug #962645
> 
> Downgrading to 4.2.4-1, the one from last week before the binary update, makes
> qbittorrent work as it should, so I assume something went really wrong with
> that boost 1.71 build.
>...
> ii  libtorrent-rasterbar10  1.2.5-1+b1
>...

Does upgrading libtorrent-rasterbar10 to 1.2.5-1.1 (built with Boost 1.71)
fix the problems with qbittorrent-nox 4.2.4-1+b1?

cu
Adrian

Bug#962574: ITP: dephell -- project management for Python

[Nicholas D Steeves]

Control: block -1 by 962574

Tomlkit seems to be required for self-tests.

On Wed, 10 Jun 2020 at 01:03, Scott Kitterman  wrote:
> On Wednesday, June 10, 2020 12:49:01 AM EDT Nicholas D Steeves wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Nicholas D Steeves 
> >
> > Package name: dephell
> > Version : 0.8.3
> > Upstream Author : Gram 
> > URL : http://www.example.org/
> Should be https://github.com/dephell/dephell

Thanks for the correction.  Fortunately it was just a mistake in my
ITP and the source package had the correct info :-)

[snip]
> > It's highly likely this software will be useful to the general Python
> > developer community, and I plan to maintain it in either the DPMT or
> > PAPT, as appropriate.  Please comment on this!
>
> It looks to me like PAPT is probably more appropriate.

Thank you!  I'll push my WIP there after I've completed a copyright
review, when it's in reasonable shape, and after converting to a
gbp-with-pristine-tar repo.

Best,
Nicholas

Bug#962757: intel-microcode: System hangs on boot - Dell Latitude 7400/i5-8265U (CPU sig 0x806ec)

[Eugenio Paolantonio]

Package: intel-microcode
Version: 3.20200609.2~deb10u1
Severity: normal
Tags: upstream

Hello,

Latest intel-microcode update (3.20200609.2~deb10u1) renders my laptop (Dell
Latitude 7400) hang during the load of the initramfs.

Downgrading the package to 3.20191115.2~deb10u1 fixes the issue.

Excerpt from dmesg (with the old microcode):

[0.986742] microcode: sig=0x806ec, pf=0x80, revision=0xca

Excerpt from /proc/cpuinfo:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 142
model name  : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping: 12
microcode   : 0xca
cpu MHz : 800.022
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch
cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow
vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms
invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves
dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear
flush_l1d arch_capabilities
bugs: spectre_v1 spectre_v2 spec_store_bypass swapgs itlb_multihit
srbds
bogomips: 3600.00
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:


Thanks.

Eugenio



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

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

Versions of packages intel-microcode depends on:
ii  iucode-tool  2.3.1-1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.133+deb10u1

intel-microcode suggests no packages.

-- no debconf information

Bug#962756: kcalcore FTCBFS: qttools5-dev missing from Build-Depends

[Helmut Grohne]

Source: kcalcore
Version: 5:5.70.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kcalcore fails to cross build from source, because it fails finding
QHelpGenerator. For using it, a dependency on qttools5-dev is required.
Refer to #915122 for details. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru kcalcore-5.70.0/debian/changelog 
kcalcore-5.70.0/debian/changelog
--- kcalcore-5.70.0/debian/changelog2020-05-26 23:56:26.0 +0200
+++ kcalcore-5.70.0/debian/changelog2020-06-13 15:39:49.0 +0200
@@ -1,3 +1,10 @@
+kcalcore (5:5.70.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build-Depends: qttools5-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 13 Jun 2020 15:39:49 +0200
+
 kcalcore (5:5.70.0-1) unstable; urgency=medium
 
   [ Sandro Knauß ]
diff --minimal -Nru kcalcore-5.70.0/debian/control 
kcalcore-5.70.0/debian/control
--- kcalcore-5.70.0/debian/control  2020-05-26 23:56:26.0 +0200
+++ kcalcore-5.70.0/debian/control  2020-06-13 15:39:49.0 +0200
@@ -11,7 +11,8 @@
libical-dev (>= 2.0~),
pkg-kde-tools (>> 0.15.15),
qhelpgenerator-qt5,
-   qtbase5-dev (>= 5.12.0~)
+   qtbase5-dev (>= 5.12.0~),
+   qttools5-dev,
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Homepage: https://projects.kde.org/projects/kde/pim/kcalcore

Bug#962755: exif: FTBFS on s390x: test failure

[Boyuan Yang]

Source: exif
Vresion: 0.6.22-1
Severity: serious
X-Debbugs-CC: hugh.mcmas...@outlook.com

Dear Debian exif package maintainers,

The new upload of exif/0.6.22-1 FTBFS on s390x architecture due to test
failure:

https://buildd.debian.org/status/fetch.php?pkg=exif&arch=s390x&ver=0.6.22-1&stamp=1591715266&raw=0

PASS: check-create-tags.sh
PASS: check-help.sh
PASS: check-init-mandatory-tags.sh
FAIL: check-add-tags.sh
PASS: check-param-validity.sh
PASS: check-required-file.sh
PASS: check-show-description.sh
PASS: check-show-tag.sh
PASS: check-tag-description.sh
PASS: check-thumbnail.sh
PASS: check-version.sh
PASS: check-no-seek.sh

   libexif command line interface 0.6.22: test/test-suite.log


# TOTAL: 12
# PASS:  11
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

Can you examine it and eventually fix it, perhaps using a porterbox?

-- 
Regards,
Boyuan Yang



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

Bug#962754: eukleides FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: eukleides
Version: 1.5.4-4.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

eukleides 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 - fixes the build part, but it still uses install with the
-s flag and thus fails at using the build architecture strip on a host
architecture object. It is best to defer all stripping to dh_strip.
Doing otherwise also breaks generation of -dbgsym packages as well as
DEB_BUILD_OPTIONS=nostrip. The attached patch fixes all of that. Please
consider applying it.

Helmut
diff --minimal -Nru eukleides-1.5.4/debian/changelog 
eukleides-1.5.4/debian/changelog
--- eukleides-1.5.4/debian/changelog2020-05-29 17:05:05.0 +0200
+++ eukleides-1.5.4/debian/changelog2020-06-13 15:06:16.0 +0200
@@ -1,3 +1,13 @@
+eukleides (1.5.4-4.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Make install substitutable.
++ Pass a non-stripping install to make install.
+
+ -- Helmut Grohne   Sat, 13 Jun 2020 15:06:16 +0200
+
 eukleides (1.5.4-4.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru eukleides-1.5.4/debian/patches/cross.patch 
eukleides-1.5.4/debian/patches/cross.patch
--- eukleides-1.5.4/debian/patches/cross.patch  1970-01-01 01:00:00.0 
+0100
+++ eukleides-1.5.4/debian/patches/cross.patch  2020-06-13 15:06:16.0 
+0200
@@ -0,0 +1,19 @@
+--- eukleides-1.5.4.orig/build/Makefile
 eukleides-1.5.4/build/Makefile
+@@ -12,6 +12,7 @@
+ YACC = bison
+ YFLAGS = -d
+ CC = gcc
++INSTALL ?= install
+ IFLAGS = -I$(COMMON_DIR) -I$(MAIN_DIR) -I$(BUILD_DIR) 
+ ifneq ($(strip $(LOCALES)),)
+ MOFLAGS = -DMO_DIR=\"$(MO_DIR)\" 
+@@ -55,7 +56,7 @@
+ 
+ install: $(BINARY)
+   @echo "Installing $<"
+-  @install -s $< $(BIN_DIR)
++  @$(INSTALL) -s $< $(BIN_DIR)
+ 
+ uninstall:
+   @$(RM) $(addprefix $(BIN_DIR)/,$(BINARIES))
diff --minimal -Nru eukleides-1.5.4/debian/patches/series 
eukleides-1.5.4/debian/patches/series
--- eukleides-1.5.4/debian/patches/series   2017-11-06 13:42:43.0 
+0100
+++ eukleides-1.5.4/debian/patches/series   2020-06-13 15:06:16.0 
+0200
@@ -1,3 +1,4 @@
 old-patches.diff
 spelling-mistakes.diff
 ld-as-needed.diff
+cross.patch
diff --minimal -Nru eukleides-1.5.4/debian/rules eukleides-1.5.4/debian/rules
--- eukleides-1.5.4/debian/rules2020-05-29 17:05:05.0 +0200
+++ eukleides-1.5.4/debian/rules2020-06-13 15:06:16.0 +0200
@@ -14,7 +14,7 @@
 
 build-stamp: 
dh_testdir
-   CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" $(MAKE)
+   CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" dh_auto_build
touch $@
 
 clean: 
@@ -29,7 +29,7 @@
dh_testroot
dh_prep
dh_installdirs
-   $(MAKE) DESTDIR=$(CURDIR)/debian/eukleides install
+   $(MAKE) DESTDIR=$(CURDIR)/debian/eukleides install INSTALL='install 
--strip-program=true'
 
 binary-indep: build install
 

Bug#962753: gztool FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: gztool
Version: 0.11.2-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gztool fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
gztool cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru gztool-0.11.2/debian/changelog 
gztool-0.11.2/debian/changelog
--- gztool-0.11.2/debian/changelog  2020-06-12 18:50:34.0 +0200
+++ gztool-0.11.2/debian/changelog  2020-06-13 15:07:04.0 +0200
@@ -1,3 +1,10 @@
+gztool (0.11.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 13 Jun 2020 15:07:04 +0200
+
 gztool (0.11.2-2) unstable; urgency=medium
 
   * Source-only upload.
diff --minimal -Nru gztool-0.11.2/debian/rules gztool-0.11.2/debian/rules
--- gztool-0.11.2/debian/rules  2020-05-29 14:57:28.0 +0200
+++ gztool-0.11.2/debian/rules  2020-06-13 15:07:04.0 +0200
@@ -9,4 +9,4 @@
dh $@
 
 override_dh_auto_build:
-   make gztool LDLIBS="-lz -lm"
+   dh_auto_build --buildsystem=makefile -- gztool LDLIBS="-lz -lm"

Bug#962752: wiipdf FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: wiipdf
Version: 1.4-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wiipdf 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 -
makes wiipdf cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru wiipdf-1.4/debian/changelog wiipdf-1.4/debian/changelog
--- wiipdf-1.4/debian/changelog 2020-06-08 21:06:00.0 +0200
+++ wiipdf-1.4/debian/changelog 2020-06-13 15:15:39.0 +0200
@@ -1,3 +1,9 @@
+wiipdf (1.4-4) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 13 Jun 2020 15:15:39 +0200
+
 wiipdf (1.4-3) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru wiipdf-1.4/debian/rules wiipdf-1.4/debian/rules
--- wiipdf-1.4/debian/rules 2020-06-08 21:06:00.0 +0200
+++ wiipdf-1.4/debian/rules 2020-06-13 15:15:38.0 +0200
@@ -19,10 +19,7 @@
 build-indep: build-stamp
 build-stamp:
dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE)
-
+   dh_auto_build
touch $@
 
 clean:

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported ZFS (with acltype=off) (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Salvatore Bonaccorso]

Hi Elliott,

[I'm adding linux-nfs upstream hopefully J. Bruce Fields or others can
help clarifying]

On Thu, Jun 11, 2020 at 03:37:11PM -0700, Elliott Mitchell wrote:
> Bit more experimentation on this issue.
> 
> I tried a very small C program meant to create files with fewer
> permissions bits set.  This succeeded which strengthens the theory of
> the umask getting ignored.
> 
> I haven't seen anything hinting whether this is more a client or server
> issue.
> 
> I can speculate perhaps somewhere between 4.9 and 4.15 the NFS client
> code stepped closer to proper the "proper" 4.2 protocol.  If a
> corresponding NFS server was slow at getting merged, what we're seeing
> could happen.
> 
> Alternatively someone was trying to get a Linux NFS v4.2 client to work
> better with a different NFS v4.2 server, so they fixed Linux's NFS v4.2
> client.  Yet they failed to test with Linux's v4.2 server.
> 
> 
> This though is speculation.  All I can say is sometime between kernels
> 4.9 and 4.15, NFS v4.2 got broken.  There are hints this is related to
> handling of umask.
 
I was initially confused because of the mentioning of only appearing
with the update to 4.19.118-2 but this is now cleared up, so it shows
up when changing from 4.9.x from stretch to 4.19.x.

Now I'm quite unsure if this should and is to be considered a Linux
kernel issue. What follows is just what I found with respect of the
mentioned behaviour. There is a specific aspect of the NFSv4.2
implementation:

In upstream, with [nfsv4.2-umask-support], [47057abde515] NFSv4.2
support was added. The repsective RFC describing it is [RFC8275].

[nfsv4.2-umask-support]: 

[47057abde515]: 

[RFC8275]: 

Since, they allow the umask to be ignored in the presence of
inheritable NFSv4 ACLs.

Now what is or will be confusing is that the behaviour is reproducible
with ZFS default of acltype=off (aclinherit=restricted, sharenfs=off).

Reproducing the issue is easy as follows (all done on Debian unstable
to verify the behaviours can be triggered there as well with more
current 5.6.14-2, zfs-linux on 0.8.4-1):

# zpool create zfs_test /dev/vdb

and exporting /zfs_test in /etc/exports as

/zfs_test 192.168.122.1/24(rw,sync,no_subtree_check,no_root_squash)

The properties of zfs_test would be:

# zfs get acltype,aclinherit,sharenfs zfs_test
NAME  PROPERTYVALUE  SOURCE
zfs_test  acltype offlocal
zfs_test  aclinherit  restricted local
zfs_test  sharenfsoffdefault

And reproducing then with

# mount -t nfs 192.168.122.150:/zfs_test /mnt
# mkdir /mnt/foo && ls -ld /mnt/foo && rmdir /mnt/foo
drwxrwxrwx 2 root root 2 Jun 13 14:25 /mnt/fo
# umount /mnt

The comment from J. Bruce Fields, in
https://bugzilla.redhat.com/show_bug.cgi?id=1667761#c1 can help debug
it further:

> To start debugging this, I'd recommend looking running wireshark to
> sniff traffic while running your reproducer (mount, mkdir) and
> compare to what's expected from the umask RFC.  Somewhere there
> should be a getattr from the client for the supported_attrs
> attribute, and the reply from the server will probably indicate
> support for the new mode_umask attribute.  If you find the CREATE
> operation that creates the new directory, you should see the client
> set the mode_umask attribute, with the mode part set to the open
> mode and the umask to the process umask.  If those values look
> right, then the problem is likely on the server side.

In fact in sniffing the traffic, there, the gettattr from the client and the
server does indicate support for the new mode_umask. Then later in the CREATE
operation, the client sets the mode_umask attribute, with mode part set to
'0777' and umask to '022'. The mode replied is then as well '0777'.

If further needed to debug we should try to distill a sniff with
wireshark providing the repsective pcap.

https://bugzilla.redhat.com/show_bug.cgi?id=1667761

did not further contain specific information on followups.

https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736

indicated this was specifically observed on ZFS on Linux only. Seth
Arnold's answer seem to be inline with that that the issue is more on
the ZFS on Linux side and the issue keeps biting people a bit
unexpectedly. Why does this break with ACL off settings?

But there was at least one other (but again without further
detail/followups) that it was observed on an export from OpenWRT, but
no specific details here:

https://bugs.openwrt.org/index.php?do=details&task_id=2581

Both Debian bugs itself were as well with underlying ZFS filesystem exported:
https://bugs.debian.org/934160
https://bugs.debian.org/962254

Any hint on were to pin-point the issue? Both on Linux anf ZFS on
Linux side or only on one of the components?

Regards,
Salvatore