Bug#948195:

[KeyofBlueS]

Hi jim_p,

Same problem I reported in bug #948032
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948032

To downgrade I've written a dirty script for my personal use, if you need
it You'll find it in attachment.


nvidia-recovery.sh
Description: application/shellscript

Bug#948195: nvidia-legacy-340xx-driver: Xorg fails to start with a kernel panic after the upgrade to 340.108-1

[jim_p]

Package: nvidia-legacy-340xx-driver
Followup-For: Bug #948195

I finally managed to install 340.107-8 from the snapshot repo and, as you can
also see in the logs below, there is no issue with it.
I am pinning it for now...



-- Package-specific info:
uname -a:
Linux mitsos 5.4.0-1-amd64 #1 SMP Debian 5.4.6-1 (2019-12-27) x86_64 GNU/Linux

/proc/version:
Linux version 5.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191130 (Debian 9.2.1-21)) #1 SMP Debian 5.4.6-1 (2019-12-27)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.107  Thu May 24 21:54:01 
PDT 2018
GCC version:  gcc version 9.2.1 20191130 (Debian 9.2.1-21) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490]
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: nvidia
Kernel modules: nvidia

dmesg:
[0.315706] Console: colour VGA+ 80x25
[0.747348] pci :01:00.0: vgaarb: setting as boot VGA device
[0.747348] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.747348] pci :01:00.0: vgaarb: bridge control possible
[0.747348] vgaarb: loaded
[0.932809] Linux agpgart interface v0.103
[3.333197] nvidia: loading out-of-tree module taints kernel.
[3.333209] nvidia: module license 'NVIDIA' taints kernel.
[3.347973] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.362057] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.363352] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.363365] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.107  Thu May 
24 21:54:01 PDT 2018
[3.849423] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[5.109339] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input17
[5.112939] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input22
[5.113029] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input24
[5.113105] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25
[   20.202050] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Jan  5 09:31 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Jan  5 09:32 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Jan  5 09:32 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Jan  5 09:31 pci-:01:00.0-card -> ../card0
video:*:44:jim

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan  5 09:29 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Jan  5 09:29 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Jan  5 09:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan  5 09:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   54 Jan  5 09:29 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Jan  5 09:29 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   25 Jan  5 09:29 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan  5 09:29 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan  5 09:29 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Jan  5 09:29 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Jan  5 09:29 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Jan  5 09:29 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Jan  5 09:29 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   28 Jan  5 09:27 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/legacy-340xx
lrwxrwxrwx 1 root root   57 Jan  5 09:27 
/etc/alternatives/nvidia--libEGL.so.1-x86_64-linux-gnu 

Bug#936609: cblas / gsl hint needed (Was: Bug#936609: Ported ghmm to Python3 but issues with clapack)

[Andreas Tille]

Control: tags -1 help

Hi,

I was asking upstream about this issue[1] and an issue about gsl usage
is suspected.  Any hint how this can be fixed?

> Finally I have a question about building with lapack.  I get:
> 
> ...
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wdate-time 
> -D_FORTIFY_SOURCE=2 -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -g -O2 
> "-fdebug-prefix-map=/build/ghmm-0.9~rc3=." -fstack-protector-strong -  
> Wformat -Werror=format-security -I/usr/include 
> -I/usr/include/x86_64-linux-gnu -I/usr/include/libxml2 -c rng.c  -fPIC -DPIC 
> -o .libs/rng.o
> In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
>  from matrixop.c:48:
> /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: nested redefinition of 
> 'enum CBLAS_ORDER'
> 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
>   | ^~~
> /usr/include/x86_64-linux-gnu/cblas.h:5:9: error: redeclaration of 'enum 
> CBLAS_ORDER'
> In file included from /usr/include/gsl/gsl_blas_types.h:28,
>  from /usr/include/gsl/gsl_blas.h:29,
>  from /usr/include/gsl/gsl_linalg.h:30,
>  from matrixop.c:44:
> /usr/include/gsl/gsl_cblas.h:46:6: note: originally defined here
>46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
>   |  ^~~
> In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
>  from matrixop.c:48:
> /usr/include/x86_64-linux-gnu/cblas.h:5:22: error: redeclaration of 
> enumerator 'CblasRowMajor'
> 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
>   |  ^
> In file included from /usr/include/gsl/gsl_blas_types.h:28,
>  from /usr/include/gsl/gsl_blas.h:29,
>  from /usr/include/gsl/gsl_linalg.h:30,
>  from matrixop.c:44:
> /usr/include/gsl/gsl_cblas.h:46:19: note: previous definition of 
> 'CblasRowMajor' was here
>46 | enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102};
>   |   ^
> In file included from /usr/include/x86_64-linux-gnu/clapack.h:4,
>  from matrixop.c:48:
> /usr/include/x86_64-linux-gnu/cblas.h:5:41: error: redeclaration of 
> enumerator 'CblasColMajor'
> 5 |enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
>   | ^
> 
> 

Kind regards

 Andreas.


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

-- 
http://fam-tille.de

Bug#947874: libdmapsharing-3.0-2: apt-get source -b libdmapsharing failed with dh_missing errors

[crvi c]

Hi,

The issue is only with Debian stable. Debian unstable works fine.

sid@unstable:~/deb-src/libdmapsharing$ apt-get source -b libdmapsharing

succeeds.


On Sun, 5 Jan 2020 at 04:51, Andreas Beckmann  wrote:

> Control: reassign -1 src:libdmapsharing 2.9.39-4
> Control: severity -1 important
> Control: tag -1 moreinfo unreproducible
>
> Hi,
>
> On Wed, 01 Jan 2020 16:02:26 +0530 crvi  wrote:
> > Package: libdmapsharing-3.0-2
> > Version: 2.9.39-4
>
> >debian/rules override_dh_missing
> > make[1]: Entering directory '/home/user/deb-
> > src/libdmapsharing/libdmapsharing-2.9.39'
> > dh_missing --fail-missing
> > dh_missing: usr/lib/x86_64-linux-gnu/girepository-1.0/DMAP-3.0.typelib
> exists
> > in debian/tmp but is not installed to anywhere
> > dh_missing: usr/share/gir-1.0/DMAP-3.0.gir exists in debian/tmp but is
> not
> > installed to anywhere
>
> I cannot reproduce this behavior in minimal up-to-date buster and sid
> pbuilder chroots. You either have an older version of some build
> dependency installed or by building in a non-minimal chroot you pick up
> some optional tools that "generate more files".
>
>
> Andreas
>

Bug#948195: nvidia-legacy-340xx-driver: Xorg fails to start with a kernel panic after the upgrade to 340.108-1

[jim_p]

Package: nvidia-legacy-340xx-driver
Version: 340.108-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After todays upgrade to 340.108, the system fails to boot in the desktop
enviroment and dmesg reports a kernel panic, as seen on the paste here
https://paste.debian.net/1124712

The lockup is so bad that even ssh-ing to the machine and issuing a reboot does
not work, so I had to reisub out of it every time.
Disabling the display manager (lightdm) and booting to command line works, but
the same happens as soon as I use startx.

Downgrading to kernel 5.3 does not solve the problem and I had to complete
remove nvidia and use nouveau to get back to the desktop and write this bug
report. Now I am trying to install 340.107 from the snapshot repo, but it will
take a lot of time as it seems because of the many dependencies.

Thank you in advance.



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

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

Versions of packages nvidia-legacy-340xx-driver depends on:
pn  nvidia-installer-cleanup 
pn  nvidia-legacy-340xx-alternative  
pn  nvidia-legacy-340xx-driver-bin   
pn  nvidia-legacy-340xx-driver-libs  
pn  nvidia-legacy-340xx-kernel-dkms | nvidia-legacy-340xx-kernel-340.10  
pn  nvidia-legacy-340xx-kernel-dkms | nvidia-legacy-340xx-kernel-340.10  
pn  nvidia-legacy-340xx-vdpau-driver 
pn  nvidia-support   
pn  xserver-xorg-video-nvidia-legacy-340xx   

Versions of packages nvidia-legacy-340xx-driver recommends:
pn  nvidia-persistenced   
pn  nvidia-settings-legacy-340xx  

Versions of packages nvidia-legacy-340xx-driver suggests:
pn  nvidia-legacy-340xx-kernel-dkms | nvidia-legacy-340xx-kernel-source  

Bug#937625: python-bz2file: Python2 removal in sid/bullseye

[Sandro Tosi]

patches, as i dont have access to that repo
From 905138c2115b8055b19f8e1f7374cfb0f741d441 Mon Sep 17 00:00:00 2001
From: Sandro Tosi 
Date: Sun, 5 Jan 2020 01:16:04 -0500
Subject: [PATCH 2/2] releasing package python-bz2file version 0.98-3

---
 debian/changelog | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 2a26a60..093d831 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,9 @@
-python-bz2file (0.98-3) UNRELEASED; urgency=medium
+python-bz2file (0.98-3) unstable; urgency=medium
 
   * Team upload.
   * Drop python2 support; Closes: #937625
 
- -- Sandro Tosi   Sun, 05 Jan 2020 01:15:10 -0500
+ -- Sandro Tosi   Sun, 05 Jan 2020 01:16:02 -0500
 
 python-bz2file (0.98-2) unstable; urgency=medium
 
-- 
2.24.1

From 07bd423a58e539eff9322a4948589fe998c9c4de Mon Sep 17 00:00:00 2001
From: Sandro Tosi 
Date: Sun, 5 Jan 2020 01:16:01 -0500
Subject: [PATCH 1/2] Drop python2 support; Closes: #937625

---
 debian/changelog |  7 +++
 debian/control   | 16 
 debian/rules |  2 +-
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 4381d10..2a26a60 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-bz2file (0.98-3) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Drop python2 support; Closes: #937625
+
+ -- Sandro Tosi   Sun, 05 Jan 2020 01:15:10 -0500
+
 python-bz2file (0.98-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index fd3ed8b..361ef20 100644
--- a/debian/control
+++ b/debian/control
@@ -6,8 +6,6 @@ Testsuite: autopkgtest-pkg-python
 Priority: optional
 Build-Depends: debhelper (>= 11~),
dh-python,
-   python,
-   python-setuptools,
python3,
python3-setuptools
 Standards-Version: 4.2.1
@@ -15,20 +13,6 @@ Vcs-Browser: https://salsa.debian.org/med-team/python-bz2file
 Vcs-Git: https://salsa.debian.org/med-team/python-bz2file.git
 Homepage: https://github.com/nvawda/bz2file
 
-Package: python-bz2file
-Architecture: all
-Depends: ${python:Depends},
- ${misc:Depends}
-Provides: ${python:Provides}
-Description: Python library for reading and writing bzip2-compressed files
- Bz2file is a Python library for reading and writing bzip2-compressed files.
- .
- It contains a drop-in replacement for the file interface in the standard
- library's bz2 module, including features from the latest development version
- of CPython that are not available in older releases.
- .
- Bz2file for Python2.
-
 Package: python3-bz2file
 Architecture: all
 Depends: ${python3:Depends},
diff --git a/debian/rules b/debian/rules
index b945423..32cd64c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,4 +4,4 @@ DH_VERBOSE := 1
 export PYBUILD_NAME=bz2file
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
-- 
2.24.1

Bug#930440: RFP: podman -- Library and tool for running OCI-based containers in Pods

[anarcat]

Control: tags -1 +pending

On Wed, Jun 12, 2019 at 08:26:22PM +0200, Varac wrote:
> * Package name: podman

I just want to mention that it seems podman has entered NEW:

https://ftp-master.debian.org/new/libpod_1.6.4+dfsg-1.html

The last dependency that was missing (#948113) is also waiting there:

https://ftp-master.debian.org/new/golang-github-checkpoint-restore-go-criu_3.11-1.html

This is great news! Can't wait to see this awesome project available in
Debian...

Congratulations to everyone on all their hard work. Let's hope this can
converge on a good, standard set of packages that will satisfy everyone
involved! I, for one, will look at replacing Docker with podman in the
near future on my infrastructure. :)

A.


signature.asc
Description: PGP signature

Bug#948119: [schroot] does not work for non-root user

[Steve Langasek]

On Sat, Jan 04, 2020 at 12:06:41PM -0800, tony mancill wrote:
> On Sat, Jan 04, 2020 at 09:35:27AM +0100, Giovanni Mascellani wrote:
> > I suspect the problem might be related to the fact that /usr/bin/schroot
> > is not set-uid anymore, while it was before. Executing
> > ...

> I ran into this as well and verified on another system running sid that
> the binary update to 1.6.10-7 is when the setuid bit is removed - it's
> simply not set in the binary package, while it is in .

> I'm curious as to how this happened.  I not seeing anything obvious in
> the source package changes [1], and when I rebuild 1.6.10-6 or 1.6.10-7
> from source locally in a sid chroot, neither one of them results in a
> setuid binary.  In the build logs for those builds, the install-arch
> target is no longer being called.

> However, building 1.6.10-7 in a buster chroot does result in a setuid
> binary, so it seems that a recent change in the packaging toolchain
> could be the root cause (although I haven't found anything definitive
> yet).

It is a latent bug in debian/rules, which failed to run the install-arch:
target when run under dpkg-buildpackage -b (instead of -B), which is how I
did my test build for upload to the archive.

I was surprised to find that the archive did not discard my binaries and
rebuild them, which I understood was now the standard upload workflow in
Debian, but instead published them as-is, which is how this bug made it out
to the world.

I have pushed a fix for this bug to the git repository; however, the other
thing that was failing to happen due to this bug, aside from not setting the
binary setuid root, was that the testsuite was not being run.  So I'm in the
process now of fixing various testsuite regressions.

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


signature.asc
Description: PGP signature

Bug#948194: RFS: jcc/3.6-1 [ITA] -- generator for a Python extension from Java classes (transitional)

[Emmanuel Arias]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: jcc
   Version : 3.6-1
   Upstream Author : Andi Vadja 
 * URL : http://lucene.apache.org/pylucene/jcc/
 * License : Apache
 * Vcs : https://salsa.debian.org/debian/jcc
   Section : oldlibs

It builds those binary packages:

  python-jcc - generator for a Python extension from Java classes (Python 2)
  python3-jcc - generator for a Python extension from Java classes (Python 3)
  jcc - generator for a Python extension from Java classes (transitional)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/j/jcc/jcc_3.6-1.dsc

Changes since the last upload:

   [ Emmanuel Arias ]
   * New upstream version 3.6
   * New maintainer (Closes: #922568):
 - Add myself to Maintainer field on d/control.
   * Bump debhelper to 12 (from 9.2):
 - Update debhelper to debhelper-compat on d/control Build-Depends.
   * Update Vcs-* repository to salsa repository.
   * Add myself on debian/* files copyright on d/copyright.
   * Bump Standard-Version to 4.4.1
   * d/control: add autopkgtest-pkg-python

Regards,
Emmanuel

Bug#933934: unmount bash completion complains about "awk: line 18: function gensub never defined"

[Josh Triplett]

Package: mount
Version: 2.34-0.1
Followup-For: Bug #933934

This bug still exists; please consider applying the patch (and ideally
getting it merged upstream).

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

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

Versions of packages mount depends on:
ii  libblkid1  2.34-0.1
ii  libc6  2.29-7
ii  libmount1  2.34-0.1
ii  libselinux13.0-1
ii  libsmartcols1  2.34-0.1
ii  util-linux 2.34-0.1

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- no debconf information

Bug#948193: e2scrub services delay boot by 2 seconds

[Josh Triplett]

Package: e2fsprogs
Version: 1.45.4-1
Severity: important

The e2fsprogs package installs a service and timer to run e2scrub. That
service sleeps for 2 seconds before exiting, delaying the boot by 2
seconds.

First of all, sleeping for 2 seconds is not OK.

Second, please use ConditionPathExists or similar to check for the tools
e2scrub needs (lsblk and lvcreate), rather than running a script that
checks for them and then exits.

And third, please consider *not* enabling this by default.

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

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

Versions of packages e2fsprogs depends on:
ii  libblkid12.34-0.1
ii  libc62.29-7
ii  libcom-err2  1.45.4-1
ii  libext2fs2   1.45.4-1
ii  libss2   1.45.4-1
ii  libuuid1 2.34-0.1
ii  logsave  1.45.4-1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.3-1

-- no debconf information

Bug#948192: flashrom -R does not show version number

[Antoine Beaupre]

Package: flashrom
Version: 1.1-1
Severity: minor

flashrom 1.0 and 1.1, as packaged in Debian, do not correctly show the
expected version number in the -R output:

anarcat@angela:~(master)$ flashrom  --version
flashrom  on Linux 4.19.0-6-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

The first line shows where the version number should come up, because
there's two spaces (instead of one surrounding the version number)
between "flashrom" and "on".

This breaks, probably among other things, the Purism coreboot upgrade
script, which tries to detect the version number:

https://source.puri.sm/coreboot/utility

This patch on the said utility works around the problem:

diff --git i/coreboot_util.sh w/coreboot_util.sh
index 2b4b2e2..e323bdc 100644
--- i/coreboot_util.sh
+++ w/coreboot_util.sh
@@ -333,6 +333,7 @@ get_flashrom () {
 echo "Checking for usable version of flashrom"
 FLASHROM_CMD=$(which flashrom)
 if [ ! -z "$FLASHROM_CMD" ]; then
+return
 #check version
 version=$($FLASHROM_CMD -R | awk -F" " '{print $2;exit}' | grep "1.")
 if [ ! -z "$version" ]; then

but that's not really relevant to this bug report.

-- System Information:
Debian Release: 10.2
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages flashrom depends on:
ii  libc6 2.28-10
ii  libftdi1-21.4-1+b2
ii  libpci3   1:3.5.2-1
ii  libusb-0.1-4  2:0.1.12-32
ii  libusb-1.0-0  2:1.0.22-2

flashrom recommends no packages.

flashrom suggests no packages.

-- no debconf information

Bug#948027: elpa-org: Does not ship org-notmuch anymore

[Nicholas D Steeves]

Control: tag -1 + pending

Done.  Sebastien, if you upload, please note that the changelog needs to
be finalised.  Finally, I noticed that org-drill was removed, and found
the RFP bug for it at #947017.  I didn't finalise the changelog because
I think that ideally it would be nice for this -2 revision to depend or
recommend it.  If you don't think that's required for this revision then
it's good to go :-)


Cheers,
Nicholas

P.S. I will not be packaging org-drill


signature.asc
Description: PGP signature

Bug#857790: sun4i_ss broken on Cubieboard (Allwinner A10)

[Marco d'Itri]

On Mar 15, Marco d'Itri  wrote:

> Package: src:linux
> Version: 4.9.13-1
> Severity: normal
> 
> Upgrading from 4.4.0-1 to 4.9.0-2 broke Kerberos security for NFS, at 
> least as a server.
FYI, 4.19.0-5-armmp is still broken.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#948191: nmu: vlc_3.0.8-0+deb10u1

[Andreas Beckmann]

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

nmu vlc_3.0.8-0+deb10u1 . ANY . buster . -m "Rebuild to tighten libmatroska6v5 
dependency." --extra-depends "libmatroska6v5 (>= 1.4.9-1+deb10u1)"
nmu mkvtoolnix_31.0.0-1 . ANY . buster . -m "Rebuild to tighten libmatroska6v5 
dependency." --extra-depends "libmatroska6v5 (>= 1.4.9-1+deb10u1)"

As a followup to #946864 (buster-pu: package
libmatroska/1.4.9-1+deb10u1), vlc and mkvtoolnix should be rebuilt to 
tighten their libmatroska6v5 dependency.

Is that syntax with --extra-depends correct? I vaguely remember seeing
it in other requests, but it's missing in wanna-build.txt.


Andreas

Bug#947919: schroot: Support for ZFS snapshotting

[Steve Langasek]

Hi Roger,

On Sat, Jan 04, 2020 at 12:54:56PM +, Roger Leigh wrote:

> If you hadn't already seen it, there's an existing implementation here:

> https://gitlab.com/rleigh/schroot/commit/08751fdff2db4d11731983faf8e9868dffbd5dbf

Ah no, I had not seen this!  There don't appear to be any references to this
gitlab repository anywhere in the existing source package.

> I don't know if your work was using this as a basis for your work on top of
> the 1.6 branch (the work here is against master, which is a bit different). 
> If you haven't already, it might be worth looking though.  I think, overall,
> your implementation is better in terms of the options it provides and the
> environment it sets, but it might be useful to compare just in case it has
> any interesting bits you want to pick up.  Note that I didn't complete this
> work; the C++ side was mostly done but the scripting side for setting up the
> ZFS snapshots was not.  At the time, I wasn't entirely sure on how best to
> use ZFS to implement source chroots reliably, which I think you've done
> better but I think not completely (as detailed below).

I'm largely happy with what I have here now, but if you think there are
specific learnings I should take from your branch, I'm happy to look.

> When you clone a snapshot, you're getting an ephemeral dataset and snapshot
> which the 05zfs script is correctly creating and destroying.  No problems
> here that I can see.

> When you clone a source snapshot, we want to make that snapshot the default
> state for the original dataset when you end the session.  The "file" chroot
> type is the most comparable here; the LVM and Btrfs snapshots operate
> directly on the original copy. Right now the ZFS source chroot clone looks
> as ephemeral as a regular cloned session, so I'm not sure the current
> behaviour is corect.  We want the saving of the updated source chroot to be
> done such that it appears atomic for any concurrent usage to clone the old
> state or the new state, and never an intermediate state as the original is
> updated.  It's this part that I wasn't sure about.  I don't see an
> equivalent to "zfs promote" which would allow copying back a clone (or
> snapshot of a clone) to the source dataset, and I don't see any
> source-chroot-specific logic in 05zfs which would preserve any source chroot
> changes.

Ok, you're right that I haven't done anything wrt 'zfs promote'.  Prior to
switching to zfs, all of my schroot work used the lvm-snapshot type, which
has the same limitation you describe here: session clones taken while the
source chroot is in the process of being updated end up cloning some
intermediate state.  I have never had a problem with this limitation in
practice, since my usage of schroot is entirely human-driven, so it's very
easy for me to avoid launching new schroots while in the middle of a
"maintenance window".

Being able to update the source atomically certainly seems like a nice
enhancement, but given that the implementation is currently at parity with
the lvm-snapshot type, I am not likely to invest effort in this myself at
this time.

> I'm sure some strategy could be worked out; these considerations were the
> primary reason I never merged in that branch and made a new major release of
> schroot.  If you or anyone else has better expertise on how to safely
> implement this, I'd be happy to work on merging your work into the master
> branch and releasing this.  Note however, that the master schroot branch did
> made some incompatible configuration changes.  The biggest change was
> dropping support for the lvm-snapshot and btrfs-snapshot chroot types, which
> in practice have proven quite unreliable due to kernel and other
> implementation bugs, including races in udev when using LVM and filesytem
> unbalancing and dataloss with Btrfs.  zfs-snapshot should be free of all
> these irritations.

> Lastly, I saw the buildds were failing due to an issue with the unit test;
> looks like it needs updating to match the configuration serialisation?

This it turns out was caused by a bug in debian/rules, which failed to run
the test suite at all when called via dpkg-buildpackage -b (instead of -B).
I recall being surprised that my changes didn't introduce any new test
failures, but failed to notice the tests were not being run.  I'll follow
through on this, thanks for bringing it to my attention.

On Sat, Jan 04, 2020 at 02:35:47PM +, Roger Leigh wrote:
> On 04/01/2020 12:54, Roger Leigh wrote:
> 
> > When you clone a source snapshot, we want to make that snapshot the
> > default state for the original dataset when you end the session. The
> > "file" chroot type is the most comparable here; the LVM and Btrfs
> > snapshots operate directly on the original copy. Right now the ZFS
> > source chroot clone looks as ephemeral as a regular cloned session, so
> > I'm not sure the current behaviour is corect.  We want the saving of the
> > updated source chroot to be done such that it appears 

Bug#948190: ITP: golang-github-russellhaering-gosaml2 -- Pure Go implementation of SAML 2.0

[Christian Barcenas]

Package: wnpp
Severity: wishlist
Owner: Christian Barcenas 

* Package name: golang-github-russellhaering-gosaml2
  Version : 0.3.1-1
  Upstream Author : Russell Haering
* URL : https://github.com/russellhaering/gosaml2
* License : Apache-2.0
  Programming Lang: Go
  Description : Pure Go implementation of SAML 2.0

 A generic SAML 2.0 implemementation for Service Providers
 based on etree and goxmldsig.

This is a build dependency of several popular open-source projects such as
Kolide Fleet and Gravitational Teleport.

Bug#948189: Please use /etc/kernel/postinst.d hooks for linux-update-symlinks so upstream packages work

[Josh Triplett]

Package: linux-base
Version: 4.6
Severity: normal

Currently, Debian packages of the Linux kernel call
linux-update-symlinks manually, and then separately call the
/etc/kernel/postinst.d hooks. Upstream kernel packages (built with "make
bindeb-pkg") call the /etc/kernel/postinst.d hooks but do not call
linux-update-symlinks, which means /vmlinuz and similar don't get
updated.

Please consider running linux-update-symlinks via a
/etc/kernel/postinst.d hook, which would make it work automatically for
upstream kernels.

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

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

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.73

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information excluded

Bug#947225: CVE-2019-19232 & CVE-2019-19234

[Giorgio Oppo]

these two vulnerabilities do not require elevated privileges, in fact the 
vulnerabilities also work on black-list policies  
Es (ALL,!root)

Bug#947927: Got it working

[Noah Meyerhans]

On Thu, Jan 02, 2020 at 10:42:57AM +0200, Harald Hannelius wrote:
> It seems like a restart of mimedefang was needed after an upgrade of
> spamassassin (and spamd). It might be the spamassassin package's
> responsibility to do that?

Cross-package coordination of this nature involves the dpkg triggers
facility documented in /usr/share/doc/dpkg-dev/triggers.txt.gz and
deb-triggers(5).

As an initial proposal, spamassassin could emit a "spamassassin-upgrade"
trigger, and mimedefang could register an interest in that.  So,
spamassassin would add the following to postinst:

  dpkg-trigger --no-await spamassassin-upgrade

Mimedefang would register an interest in the trigger via
debian/mimedefang.triggers:

  interest-noawait spamassassin-upgrade

And would restart itself via the following in postinst:

  if [ "$1" = "triggered" ] && [ "$2" = "spamassassin-upgrade" ]; then
  echo "restarting mimedefang because of spamassassin-upgrade trigger"
  invoke-rc.d mimedefang restart
  fi

I think that'd basically do it.

Does mimedefang only need to restart when spamassassin is upgraded, or
any time it restarts?  I.e if you simply invoke "systemctl restart
spamassassin.service", does mimedefang get stuck?  If so, we may need
some other kind of coordination.  We have a bit of a template for that
in the form of /etc/spamassassin/sa-update-hooks.d/, but nothing that
specifically addresses this issue.

noah

Bug#946959: RFS: coreboot/4.10-1 -- Coreboot firmware utilities

[John Scott]

The package is in great shape. The only challenge to getting the package in 
the archive seems to be the copyright file. Coreboot's README says
> Some files are licensed under the "GPL (version 2, or any later version)",
> and some files are licensed under the "GPL, version 2". For some parts,
> which were derived from other projects, other (GPL-compatible) licenses may 
apply. Please check the individual source files for details.

debian/copyright says most files are GPL 2+, but it my digging indicates the 
majority are GPL 2 only, and I think I saw additional licenses too.

I believe upstream has recently expressed desire to make listings files with 
respective licenses and/or using SPDX identifiers, rather than their lengthy 
headers in the source. If that's true, checking out the Git version might help 
you parse the licenses.

Speaking of which, you repacked Coreboot with the contents of 3rdparty/ 
removed. As a Libreboot user I thought I understood why, but as best as I can 
tell those files are free. On Coreboot's downloads page they appear to 
distribute the blobs separately which is news to me.

If there really is a problem with those files I would appreciate your letting 
me know what I missed. Otherwise I hope you can avoid the repacking trouble in 
the future.

Lastly, a small enhancement is to add a debian/watch file so that tools can 
check for and utilize new upstream versions automagically. I plan to send a 
Salsa merge request with details shortly.

I hope my feedback is useful for you to help your package.

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

Bug#851109: Emscripten violates font license

[John Scott]

Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/10146
Control: block 939477 by -1

I've reported this upstream since they're still using it.

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

Bug#936481: Emscripten supports Python 3

[John Scott]

Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/5950
Control: tags -1 fixed-upstream

It appears it still supports Python 2 also for the time being
https://github.com/emscripten-core/emscripten/issues/7198

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

Bug#809997: emscripten not installable on Debian/testing...

[John Scott]

Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/5488
Control
> The problem is that emscripten uses a fork of LLVM and I am reluctant to add
> yet-a-new-version of llvm in the archive...
> I have been waiting for the changes to be merged upstream and, with the
> recent progress on webassembly, we are getting there...

I haven't tried it, but it appears they enabled using Web Assembly with 
upstream LLVM in October.

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

Bug#948188: Please package a newer PAM snapshot

[Marco d'Itri]

Source: pam
Severity: wishlist

Now that Debian has libxcrypt in place of the old crypt(3) 
implementation from glibc, we need a newer version of the PAM package to 
actually use the modern password hashing methods.

Fedora has backported from the PAM upstream repository a few patches 
like this one:

https://src.fedoraproject.org/rpms/pam/c/2842b2a1ee2f79cc532cf5409a016308e40004bf
 

But since a new release of PAM does not appear to be forthcoming then 
maybe you could just package an upstream snapshot.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#948186: openvdb: FTBFS against python3.8

[Andreas Beckmann]

Source: openvdb
Version: 6.2.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

openvdb/experimental FTBFS against python3.8:

-- 
--  Configuring OpenVDBPython -
-- 
CMake Error at 
/usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find Python (missing: Development) (found suitable version
  "3.8.1", minimum required is "3.7")
Call Stack (most recent call first):
  /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.15/Modules/FindPython/Support.cmake:1653 
(find_package_handle_standard_args)
  /usr/share/cmake-3.15/Modules/FindPython.cmake:215 (include)
  openvdb/python/CMakeLists.txt:106 (find_package)


-- Configuring incomplete, errors occurred!


Andreas


openvdb_6.2.1-3.log.gz
Description: application/gzip

Bug#948185: kytos-utils: conffiles not removed: /etc/skel/kytos/napp-structure/username/*

[Paul Wise]

Package: kytos-utils
Version: 2019.2-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

Due to the missing conffile removal, the upgrade process prints this:

Unpacking python3-pathspec (0.6.0-1) ...
Preparing to unpack .../kytos-utils_2019.2-1_all.deb ...
Unpacking kytos-utils (2019.2-1) over (2017.2b1-2.1) ...
dpkg: warning: unable to delete old directory 
'/etc/skel/kytos/napp-structure/username/napp': Directory not empty
dpkg: warning: unable to delete old directory 
'/etc/skel/kytos/napp-structure/username': Directory not empty
dpkg: warning: unable to delete old directory '/etc/skel/kytos/napp-structure': 
Directory not empty
dpkg: warning: unable to delete old directory '/etc/skel/kytos': Directory not 
empty

Here you can see that adequate and dpkg report obsolete conffiles:

$ p=kytos-utils ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
obsolete
kytos-utils: obsolete-conffile 
/etc/skel/kytos/napp-structure/username/napp/settings.py.template
kytos-utils: obsolete-conffile 
/etc/skel/kytos/napp-structure/username/napp/openapi.yml.template
kytos-utils: obsolete-conffile 
/etc/skel/kytos/napp-structure/username/napp/main.py.template
kytos-utils: obsolete-conffile 
/etc/skel/kytos/napp-structure/username/napp/kytos.json.template
kytos-utils: obsolete-conffile 
/etc/skel/kytos/napp-structure/username/napp/__init__.py
kytos-utils: obsolete-conffile 
/etc/skel/kytos/napp-structure/username/napp/README.rst.template
kytos-utils: obsolete-conffile 
/etc/skel/kytos/napp-structure/username/__init__.py
 /etc/skel/kytos/napp-structure/username/napp/settings.py.template 
d41d8cd98f00b204e9800998ecf8427e obsolete
 /etc/skel/kytos/napp-structure/username/napp/openapi.yml.template 
fd963a952534e37628f084acbd0cecd2 obsolete
 /etc/skel/kytos/napp-structure/username/napp/main.py.template 
b3b05e3edc97aaa7f02e718c8a7f5574 obsolete
 /etc/skel/kytos/napp-structure/username/napp/kytos.json.template 
67a03d4f8c45e0eb2d3e72af21825761 obsolete
 /etc/skel/kytos/napp-structure/username/napp/__init__.py 
d41d8cd98f00b204e9800998ecf8427e obsolete
 /etc/skel/kytos/napp-structure/username/napp/README.rst.template 
9f30c1c0eb303cb06de1f7a122979a55 obsolete
 /etc/skel/kytos/napp-structure/username/__init__.py 
d41d8cd98f00b204e9800998ecf8427e obsolete

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=en_AU:en (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages kytos-utils depends on:
ii  python3  3.7.5-3
ii  python3-certifi  2018.8.24-1
ii  python3-chardet  3.0.4-4
ii  python3-docopt   0.6.2-2.2
ii  python3-idna 2.6-2
ii  python3-jinja2   2.10.1-1
ii  python3-markupsafe   1.1.0-1+b2
ii  python3-pathspec 0.6.0-1
ii  python3-requests 2.22.0-2
ii  python3-ruamel.yaml  0.15.89-3+b1
ii  python3-urllib3  1.25.6-4

kytos-utils recommends no packages.

kytos-utils suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#948184: ITP: python-numpy-groupies -- performs operations on/with subsets of n-dim arrays

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: python-numpy-groupies -- performs operations on/with subsets of 
n-dim arrays
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-numpy-groupies
  Version : 0.9.10
  Upstream Author : numpy-groupies developers
* URL : https://github.com/ml31415/numpy-groupies
* License : BSD
  Programming Lang: Python
  Description : performs operations on/with subsets of n-dim arrays
 This package consists of a couple of optimised tools for doing things
 that can roughly be considered "group-indexing operations". The most
 prominent tool is `aggregate`.
 .
 `aggregate` takes an array of values, and an array giving the group
 number for each of those values. It then returns the sum (or mean, or
 std, or any, ...etc.) of the values in each group.  You have probably
 come across this idea before, using `matlab` accumarray, `pandas`
 groupby, or generally MapReduce algorithms and histograms.
 .
 There are different implementations of `aggregate` provided, based on
 plain `numpy`, `numba` and `weave`. Performance is a main concern, and
 so far we comfortably beat similar implementations in other packages
 (check the benchmarks).

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/debian/python-modules/numpy-groupies

Bug#948182: wrapsrv: built-in help is missing important information

[Lorenzo L. Ancora]

Package: wrapsrv
Version: 1.0.0-1+b2
Severity: minor
Tags: patch

Dear Maintainer,
this patch improves the integrated help, so novice users will able
to use this tool. The patch also slightly improves performance by removing an
unnecessary call and corrects the use of system streams.

Regards,
Lorenzo

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages wrapsrv depends on:
ii  libc6  2.28-10

wrapsrv recommends no packages.

wrapsrv suggests no packages.

-- no debconf information
Description: add missing fundamental information in the help.
 This patch completes the guide by adding essential information for new users.
 It also slightly improves performance and corrects the use of standard
 system streams (stderr, stdout).
Author: Lorenzo L. Ancora 
Last-Update: 2020-01-04

--- wrapsrv-1.0.0.orig/wrapsrv.c
+++ wrapsrv-1.0.0/wrapsrv.c
@@ -39,6 +39,14 @@
 #define NS_MAXMSG 65535
 #endif
 
+#define USAGE_TXT "Usage: wrapsrv   [COMMAND OPTIONS]\n\n\
+Use all matching DNS SRV (RFC 2782) records to build/execute command lines.\n\
+SRVNAME is the symbolic name of the service (case insensitive).\n\
+%%h and %%p sequences in COMMAND will be converted to hostname and port.\n\n\
+Example (URL building and printing):\n\t\
+wrapsrv _ftps._tcp.domain.example echo ftps://%%h:%%p/\n\n\
+Copyright (c) Farsight Security, Inc.; licensed under 'Apache License 2.0'.\n"
+
 /* Data types. */
 
 struct srv {
@@ -70,7 +78,7 @@ static struct srv *next_tuple(void);
 static void free_tuples(void);
 static void insert_tuple(char *, uint16_t, uint16_t, uint16_t);
 static void parse_answer_section(ns_msg *);
-static void usage(void);
+static void usage(FILE*);
 
 #ifdef DEBUG
 static void print_tuples(void);
@@ -349,10 +357,8 @@ do_cmd(struct srv *se, int argc, char **
 }
 
 static void
-usage(void) {
-   fprintf(stderr, "Usage: wrapsrv   [OPTION]...\n");
-   fprintf(stderr, "%%h and %%p sequences will be converted to "
-   "hostname and port.\n");
+usage(FILE* stream) {
+   fprintf(stream, USAGE_TXT);
exit(EXIT_FAILURE);
 }
 
@@ -367,8 +373,10 @@ main(int argc, char **argv) {
struct timeval tv;
unsigned int seed = 0;
 
-   if (argc < 3)
-   usage();
+   if (argc <= 1)
+   usage(stdout);
+   else if (argc < 3)
+   usage(stderr);
 
ISC_LIST_INIT(prio_list);
 

Bug#948165: marked as pending in ceph

[Andreas Beckmann]

On 04/01/2020 23.35, Bernd Zeimetz wrote:
> https://salsa.debian.org/ceph-team/ceph/commit/c98ea073fc6ec1bfa2a15112616c8c04fb7b1a4b
> 
> 
> Install bash-completion in /usr again.
> 
> This change went missing somewhere during the import of the
> changes done in Ubuntu between 12.2.11 and 14.2.4.
> 
> Closes: #948165
> Thanks: Andreas Beckmann
> 

Don't you need .maintscript files to rm_conffile the now (again)
obsolete conffiles? Or if you already have them, bump the version?

That crafted piuparts test should actually investigate missing B+R for
the potential move of some files from ceph-mds 14.2.4-8 to ceph-common
14.2.5-1:
  usr/bin/cephfs-data-scan
  usr/bin/cephfs-journal-tool
  usr/bin/cephfs-table-tool
but got stopped early when it stomped over the bash completions.


Andreas

Bug#931211: s2s connections are broken after upgrading to buster

[Antonio Ospite]

Package: ejabberd
Followup-For: Bug #931211

Hi,

while taking a look at this I run into an interesting discussion here:
https://github.com/processone/ejabberd/issues/528

The scenario is different but the log message matches the one in this
report.

In that case the problem seemed to be related to name resolution in
erlang, and not strictly an ejabberd issue.

The fact that the issue here started with a buster upgrade might be due
to a change in behavior in erlang internals, which might have broken
ejabberd assumptions is some corner case.

The log message posted by Marco points out to this line in erlang:
https://sources.debian.org/src/erlang/1:21.2.6+dfsg-1/lib/kernel/src/inet_dns.erl/#L694

And the "empty" label mentioned in the comment could be the last entry
in the log message:

... [<<"_xmpps-server">>,<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>]
   

In the discussion above, one possible cause is said to be extra trailing
dots in FQDNs.

Is it possible that the issue Marco is experiencing is caused by
something like that?

I didn't notice anything strange in posted config, but what about DNS
records or entries in /etc/hosts?

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#948181: x2gothinclient-minidesktop: fails to install with lightdm installed

[Andreas Beckmann]

Package: x2gothinclient-minidesktop
Version: 1.5.0.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up x2gothinclient-minidesktop (1.5.0.1-2) ...
  
  Configuration file '/etc/lightdm/lightdm.conf'
   ==> Deleted (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** lightdm.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
x2gothinclient-minidesktop (--configure):
   end of file on stdin at conffile prompt
  Processing triggers for dictionaries-common (1.28.1) ...
  Processing triggers for libc-bin (2.29-7) ...
  Processing triggers for dbus (1.12.16-2) ...
  Errors were encountered while processing:
   x2gothinclient-minidesktop

Are you trying to use dpkg-divert on conffiles? That does not work ...


cheers,

Andreas

PS: If you tell me what exactly you want to achieve, I might think about it ... 
;-)


lightdm=1.26.0-6+b1_x2gothinclient-minidesktop=1.5.0.1-2.log.gz
Description: application/gzip

Bug#851195: [debian-mysql] Bug#851195: Bug#851195: Bug#851195: Bug#851195: mariadb-server-10.1: Time Zone system tables are empty

[Otto Kekäläinen]

Hello!

There has not been any progress on this one for a long time.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851195

Would you like to champion it upstream?

Currently this Debian bug report does not even have a link to MariaDB
Jira in case this is already reported there.

- Otto

Bug#948038: ITP: gfsecret -- Tools to make secret sharing easier.

[Philipp Kern]

On 1/4/2020 10:32 PM, Thomas Perret wrote:
> Le 03/01/2020 à 18:18, Philipp Kern a écrit :
>>
>> What's the advantage of this tool vs. the tools in libgfshare-bin and ?
>>
>> Kind regards and thanks
>> Philipp Kern
>>
> 
> From what I understand (correct me if I'm wrong) the tools included in
> libgfshare-bin are more a raw proof of concept of the underlying library
> than a user friendly interface.
> I wasn't aware of  but from what I tested, it seems you can only
> share a secret passphrase.
> 
> Gfsecret allows you to split and combine files using what is called
> share URIs defined in a configuration file at split time. You can then
> use this configuration file to combine the minimum number of shares
> detected by the software to rebuild the file.
> 
> My main use (and the main purpose of this software) is to split your
> master GPG key. Since a few release versions, there is even a facilating
> tool to do exactly that.
> 
> The share URIs can be put on different local or external volumes.
> Gfsecret supports local filesystem, external volumes identified by
> uuid/label/mtp.
> 
> More information is available on Gfsecret website:
> https://incenp.org/dvlpt/gfsecret.html
> 
> My opinion is that Gfsecret can be a good addition to Debian. Do you
> think I should keep on packaging it or is it too redundant with other
> tools already available?

It looks like it actually uses libgfshare in the background and provides
some value over a naive binary (URIs[1]). So I guess that's ok. Make
sure to elaborate on the unique features in the long description. :)

Kind regards
Philipp Kern

[1] Somehow it'd have been nice if it wouldn't be the responsibility of
every single binary to implement a scheme. Plan 9 and Hurd come to mind
here, but alas.

Bug#943974: [debian-mysql] Bug#943974: Bug#943974: mariadb-server-10.3: as "service mysql stop" fails, system refuse to shut down

[Otto Kekäläinen]

Control: severity -1 normal
Control: tags -1 moreinfo

More info is needed if you want anybody to help out with this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943974

Bug#946671: [debian-mysql] Bug#946671: Bug#946671: mariadb-server-10.3: mysqlhotcopy and transaction_registry table

[Otto Kekäläinen]

Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21317

Bug#948180: opencv: CVE-2019-5063 and CVE-2019-5064

[Markus Koschany]

Package: opencv
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for opencv.

CVE-2019-5064[0]:
| An exploitable heap buffer overflow vulnerability exists in the data
| structure persistence functionality of OpenCV, version 4.1.0. A
| specially crafted JSON file can cause a buffer overflow, resulting in
| multiple heap corruptions and potentially code execution. An attacker
| can provide a specially crafted file to trigger this vulnerability.


CVE-2019-5063[1]:
| An exploitable heap buffer overflow vulnerability exists in the data
| structure persistence functionality of OpenCV 4.1.0. A specially
| crafted XML file can cause a buffer overflow, resulting in multiple
| heap corruptions and potential code execution. An attacker can provide
| a specially crafted file to trigger this vulnerability.


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#948179: gcc-8-doc: Build-Depends on no longer available texlive-generic-recommended

[Andreas Beckmann]

Source: gcc-8-doc
Version: 8.3.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

gcc-8-doc cannot be built in bullseye any longer since the obsolete
package texlive-generic-recommended is no longer available in bullseye.


Andreas

Bug#947874: libdmapsharing-3.0-2: apt-get source -b libdmapsharing failed with dh_missing errors

[Andreas Beckmann]

Control: reassign -1 src:libdmapsharing 2.9.39-4
Control: severity -1 important
Control: tag -1 moreinfo unreproducible

Hi,

On Wed, 01 Jan 2020 16:02:26 +0530 crvi  wrote:
> Package: libdmapsharing-3.0-2
> Version: 2.9.39-4

>debian/rules override_dh_missing
> make[1]: Entering directory '/home/user/deb-
> src/libdmapsharing/libdmapsharing-2.9.39'
> dh_missing --fail-missing
> dh_missing: usr/lib/x86_64-linux-gnu/girepository-1.0/DMAP-3.0.typelib exists
> in debian/tmp but is not installed to anywhere
> dh_missing: usr/share/gir-1.0/DMAP-3.0.gir exists in debian/tmp but is not
> installed to anywhere

I cannot reproduce this behavior in minimal up-to-date buster and sid
pbuilder chroots. You either have an older version of some build
dependency installed or by building in a non-minimal chroot you pick up
some optional tools that "generate more files".


Andreas

Bug#930846: New development of how to build the installation-guide for the website [ Re: Bug#930846: partman-auto-lvm: debconf show guided_size during auto install ]

[Holger Wansing]

Hi,

"Adam D. Barratt"  wrote:
> On Sat, 2020-01-04 at 15:44 +0100, Holger Wansing wrote:
> > Hi,
> > 
> > Huh?
> > I'm totally confused. See below...
> > 
> > "Adam D. Barratt"  wrote:
> > > On Wed, 2020-01-01 at 19:52 +0100, Holger Wansing wrote:
> > > > Hi,
> > > > 
> > > > Laura Arjona Reina  wrote:
> > > > > Hi
> > > > > 
> > > > > The cron job will do the 'git pull' on wolkenstein the next
> > > > > time it
> > > > > runs.
> > > > 
> > > > yes, that worked, thanks.
> > > > So, the build was performed via the new script, and thanks to
> > > > that we
> > > > now have the manual for buster on the webpage for buster :-)
> > > > (the last two days there was the manual for bullseye there.)
> > > > 
> > > > Thus, that part works fine so far.
> > > 
> > > Only for languages up to and including Japanese (see below). A
> > > number
> > > of languages currently have no installation manual there.
> > 
> > Hmm. I wonder where you found this...
> > I did not saw such build errors on
> > https://www-master.debian.org/build-logs/webwml/
> 
> It's in /srv/www.debian.org/installmanual/buster.log on www-master, as
> produced by the lessoften cron. I have no idea if that's exported.
> 
> > and looking here at
> > https://www.debian.org/releases/stable/installmanual
> > I see manuals for all languages and all formats available and
> > correctly 
> > displayed, including Korean pdf!
> 
> Yes, but:
> 
> -rw-rw-r-- 1 debwww debwww 565570 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.pdf.ko
> -rw-rw-r-- 1 debwww debwww 467581 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.txt.ko
> -rw-rw-r-- 1 debwww debwww 793159 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.pdf.nl
> -rw-rw-r-- 1 debwww debwww 495077 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.txt.nl
> -rw-rw-r-- 1 debwww debwww 734356 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.pdf.pt
> -rw-rw-r-- 1 debwww debwww 453409 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.txt.pt
> -rw-rw-r-- 1 debwww debwww 718640 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.pdf.ru
> -rw-rw-r-- 1 debwww debwww 403421 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.txt.ru
> -rw-rw-r-- 1 debwww debwww 719953 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.pdf.sv
> -rw-rw-r-- 1 debwww debwww 433775 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.txt.sv
> -rw-rw-r-- 1 debwww debwww 767819 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.pdf.vi
> -rw-rw-r-- 1 debwww debwww 500863 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.txt.vi
> -rw-rw-r-- 1 debwww debwww 612601 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.pdf.zh-cn
> -rw-rw-r-- 1 debwww debwww 353216 Mar 24  2019 
> /srv/www.debian.org/www/releases/buster/i386/install.txt.zh-cn
> -rw-rw-r-- 1 debwww debwww 693231 Jan  1 14:49 
> /srv/www.debian.org/www/releases/buster/i386/install.pdf.en
> [etc]
> 
> [...]
> > > > Makefile:8: recipe for target 'ko.i386' failed
> > > make: *** [ko.i386] Error 2
> > > 

Ok, now I see.

However, the build went completely fine, when I tested my changes to the
lessoften cron script locally on my laptop.
And the "invalid fontname" error on Korean PDF rings a bell here now.
I think the point is a missing build depends on wolkenstein.

With the version 20190622, a change got applied to change the used font
for Korean PDF. And in the light of this build errors, I assume the needed font 
is not installed on wolkenstein.
Which means, that package version never built successful on that machine!
And that in turn would be the reason why the example-preseed.txt file on the 
webpage was an old version for months!
(This version was uploaded 2019-06-22, and at 2019-07-15 I have reported under
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930846#47
that the example-preseed.txt file is still the old one, so I think the build
failed the same way that time as I does today. Just noone noticed that ...)

We could ask DSA to install 'fonts-nanum' and 'fonts-nanum-coding' at 
wolkenstein,
to get that build successful again.
Would that be an option?

> > > buildweb.sh uses "set -e", so the failing Korean build causes the
> > > script to abort, and the example-preseed.txt is never generated.
> > > 
> > > The build script on www-master, conversely, simply continues and
> > > deploys whatever has been built up to that point.
> > 
> > As above, I am confused: 
> > isn't the buildweb.sh script being used on www-master, triggered by
> > the lessoften cron script I changed on 2020-01-01 ?
> 
> Yes, but I'm not sure how that disagrees with what I said.
> 
> The section I was referring to starts at 
> https://sources.debian.org/src/installation-guide/20191229/build/buildweb.sh/#L51
> 
> If the "make" invocation there fails, the following preseed 

Bug#948178: python3-config forces no-pie

[VA]

Package: python3-dev
Version: 3.7.5-3

I'm trying to compile a C++ app which uses SWIG and embeds a Python 
interpreter. So it uses `python3-config --cflags` to compile and 
`python3-config --ldflags` to link. A few other libs like SDL are 
included with `pkg-config` too, but no weird gcc option is added.
Compiling cpp files runs fine, but when linking the final executable 
file, it fails badly:


```
g++ -I ../SWIG -I-I/usr/include/python3.7m 
-I/usr/include/python3.7m  -Wno-unused-result -Wsign-compare -g 
-fdebug-prefix-map=/build/python3.7-neQ7kp/python3.7-3.7.6=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector -Wformat 
-Werror=format-security  -DNDEBUG -g -fwrapv -O3 -Wall 
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT  -I/usr/include/libdrm 
 -lglut -lGLU -lGL -L/usr/lib/x86_64-linux-gnu -lSDL 
-lSDL_image -lSDL_mixer -lSDL 
-L/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu -L/usr/lib 
-lpython3.7m -lcrypt -lpthread -ldl  -lutil -lm  -o kiki
/usr/bin/ld: ../src/base/KikiAction.o: relocation R_X86_64_32S against 
symbol `_ZTV10KikiAction' can not be used when making a PIE object; 
recompile with -fPIE
/usr/bin/ld: ../src/base/KikiActionObject.o: relocation R_X86_64_32S 
against symbol `_ZTV16KikiActionObject' can not be used when making a 
PIE object; recompile with -fPIE


/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
```

And `python3-config --cflags` generates the following params:

```
-I/usr/include/python3.7m -I/usr/include/python3.7m  -Wno-unused-result 
-Wsign-compare -g 
-fdebug-prefix-map=/build/python3.7-neQ7kp/python3.7-3.7.6=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector -Wformat 
-Werror=format-security  -DNDEBUG -g -fwrapv -O3 -Wall

```

Given the linking error, I believe the incorrect option is in 
`python3-config`'s output, and is 
`-specs=/usr/share/dpkg/no-pie-compile.specs`. If I strip it, linking 
works fine and so does the app.


By contrast, in Python 2, `python-config --cflags` does not have the 
offending param:


```
-I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 
-fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fdebug-prefix-map=/build/python2.7-07FOaN/python2.7-2.7.17=. 
-fstack-protector-strong -Wformat -Werror=format-security  -DNDEBUG -g 
-fwrapv -O2 -Wall -Wstrict-prototypes

```

Testing with a vanilla Python 3 installation from python.org, not from 
Debian packages, `python3-config --cflags` does NOT have the offending 
param either, so it is purely Debian-related.


Please remove the `-specs=/usr/share/dpkg/no-pie-compile.specs` option 
for Debian's `python3-config`.

Bug#937557: pyte: diff for NMU version 0.4.8-1.1

[Sandro Tosi]

Control: tags 937557 + patch


Dear maintainer,

I've prepared an NMU for pyte (versioned as 0.4.8-1.1). The diff
is attached to this message.

Regards.

diff -Nru pyte-0.4.8/debian/changelog pyte-0.4.8/debian/changelog
--- pyte-0.4.8/debian/changelog	2014-09-07 16:26:52.0 -0400
+++ pyte-0.4.8/debian/changelog	2020-01-04 17:51:23.0 -0500
@@ -1,3 +1,10 @@
+pyte (0.4.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937557
+
+ -- Sandro Tosi   Sat, 04 Jan 2020 17:51:23 -0500
+
 pyte (0.4.8-1) unstable; urgency=low
 
   * Initial release.
diff -Nru pyte-0.4.8/debian/control pyte-0.4.8/debian/control
--- pyte-0.4.8/debian/control	2014-09-07 16:32:41.0 -0400
+++ pyte-0.4.8/debian/control	2020-01-04 17:49:58.0 -0500
@@ -4,27 +4,14 @@
 Maintainer: Andrew Shadura 
 Build-Depends:
 dh-python,
-python-setuptools (>= 0.6.24),
 python3-setuptools (>= 0.6.24),
-python-all (>= 2.6.6-3), python3-all,
-python-pytest, python3-pytest,
-python-sphinx (>= 1.0.7+dfsg) | python3-sphinx,
+python3-all,
+python3-pytest,
+python3-sphinx,
 debhelper (>= 9)
 Standards-Version: 3.9.5
 Homepage: http://github.com/selectel/pyte
 
-Package: python-pyte
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Suggests: python-pyte-doc
-Provides: ${python:Provides}
-Description: simple VTXXX-compatible terminal emulator
- pyte is an in-memory VTXXX-compatible terminal emulator, where XXX stands
- for a series of video terminals, developed by DEC between 1970 and 1995.
- .
- pyte is as a fork of vt102, which was an incomplete pure Python
- implementation of VT100 terminal.
-
 Package: python3-pyte
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru pyte-0.4.8/debian/rules pyte-0.4.8/debian/rules
--- pyte-0.4.8/debian/rules	2014-09-07 16:16:15.0 -0400
+++ pyte-0.4.8/debian/rules	2020-01-04 17:51:18.0 -0500
@@ -1,14 +1,13 @@
 #!/usr/bin/make -f
 
-export PYBUILD_DESTDIR_python2=debian/python-pyte/
 export PYBUILD_DESTDIR_python3=debian/python3-pyte/
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build:
 	dh_auto_build
-	sphinx-build -b html -d docs/build/doctrees docs docs/build/html
+	python3 -m sphinx -b html -d docs/build/doctrees docs docs/build/html
 
 override_dh_auto_clean:
 	rm -rf docs/build/*

Bug#948115: Revise init script Policy based on GR result

[Sam Hartman]

Russ said off-list he was ready for seconds.
I second his patch with the status being encouraged rather than
recommended change.
In seconding, my primary review criteria was whether I thought the
change accurately reflected what the GR conclusion was.

--Sam


signature.asc
Description: PGP signature

Bug#711135: Last Submission Days: CLOUD COMPUTING 2020 || April 26 - 30, 2020 - Nice, France

[CLOUD COMPUTING 2020]

INVITATION:

=

Please consider to contribute to and/or forward to the appropriate groups the 
following opportunity to submit and publish original scientific results to:

- CLOUD COMPUTING 2020, The Eleventh International Conference on Cloud 
Computing, GRIDs, and Virtualization

Note that wea are approaching the last few days before the submission deadline 
of January 12, 2020

Authors of selected papers will be invited to submit extended article versions 
to one of the IARIA Journals: http://www.iariajournals.org

=


== CLOUD COMPUTING 2020 | Call for Papers ===

CALL FOR PAPERS, TUTORIALS, PANELS


CLOUD COMPUTING 2020, The Eleventh International Conference on Cloud Computing, 
GRIDs, and Virtualization

General page: http://www.iaria.org/conferences2020/CLOUDCOMPUTING20.html

Submission page: 
http://www.iaria.org/conferences2020/SubmitCLOUDCOMPUTING20.html


Event schedule: April 26 - 30, 2020 - Nice, France


Contributions:

- regular papers [in the proceedings, digital library]

- short papers (work in progress) [in the proceedings, digital library]

- ideas: two pages [in the proceedings, digital library]

- extended abstracts: two pages [in the proceedings, digital library]

- posters: two pages [in the proceedings, digital library]

- posters:  slide only [slide-deck posted at www.iaria.org]

- presentations: slide only [slide-deck posted at www.iaria.org]

- demos: two pages [posted at www.iaria.org]

- doctoral forum submissions: [in the proceedings, digital library]


Proposals for:

- mini symposia: see http://www.iaria.org/symposium.html

- workshops: see http://www.iaria.org/workshop.html

- tutorials:  [slide-deck posed on www.iaria.org]

- panels: [slide-deck posed on www.iaria.org]


Submission deadline: January 12, 2020


Sponsored by IARIA, www.iaria.org

Extended versions of selected papers will be published in IARIA Journals:  
http://www.iariajournals.org

Print proceedings will be available via Curran Associates, Inc.: 
http://www.proceedings.com/9769.html

Articles will be archived in the free access ThinkMind Digital Library: 
http://www.thinkmind.org


The topics suggested by the conference can be discussed in term of concepts, 
state of the art, research, standards, implementations, running experiments, 
applications, and industrial case studies. Authors are invited to submit 
complete unpublished papers, which are not under review in any other conference 
or journal in the following, but not limited to, topic areas.

All tracks are open to both research and industry contributions, in terms of 
Regular papers, Posters, Work in progress, Technical/marketing/business 
presentations, Demos, Tutorials, and Panels.

Before submission, please check and comply with the editorial rules: 
http://www.iaria.org/editorialrules.html


CLOUD COMPUTING 2020 Topics (for topics and submission details: see CfP on the 
site)

Call for Papers: http://www.iaria.org/conferences2020/CfPCLOUDCOMPUTING20.html



TRENDS: New trends

Fog-computing; Mobile Edge Computing; Cloudlets; Hosted Cloud services (WebRTC, 
Containers, Cloud micro-services); Cloud computing and SDN/NFV; Cloud computing 
and 5G; Cloud computing and LTE Pro 4.5; Cloud computing ad Big Data; High 
performance computing (HPC) in the Cloud; Superfluid Clouds; Mobile Apps to the 
public Clouds; Vehicular Cloud networks; Cloud orchestration features; 
Converged edge systems; Cloud federation; Micro-cloud provider federation; 
Open-implementation Cloud infrastructures; Untrusted Cloud environments; 
Multiple Clouds and data centers; Power Constrained VMs; Cloud Green 
abstraction layer

CLOUD: Cloud computing

Cloud economics; Core cloud services; Cloud technologies; Cloud computing; 
On-demand computing models; Hardware-as-a-service; Software-as-a-service [SaaS 
applications]; Platform-as-service; Storage as a service in cloud; 
Data-as-a-Service; Service-oriented architecture (SOA); Cloud computing 
programming and application development; Scalability, discovery of services and 
data in Cloud computing infrastructures; Trust and clouds; Client-cloud 
computing challenges; Geographical constraints for deploying clouds

CLOUD: Challenging features

Privacy, security, ownership and reliability issues; Performance and QoS; 
Dynamic resource provisioning; Power-efficiency and Cloud computing; Load 
balancing; Application streaming; Cloud SLAs; Business models and pricing 
policies; Cloud service subscription models; Cloud standardized SLA; 
Cloud-related privacy; Cloud-related control; Managing applications in the 
clouds; Mobile clouds; Roaming services in Clouds; Agent-based cloud computing; 
Cloud brokering; Cloud contracts (machine readable); Cloud security; Security 
and assurance properties in cloud environments; Big Data Analytics in clouds; 
Cloud computing back-end solutions; Cloud applications portability; 

Bug#948027: elpa-org: Does not ship org-notmuch anymore

[Nicholas D Steeves]

Control: owner -1 !

Hi Intrigeri,

intrig...@debian.org writes:

> Package: elpa-org
> Version: 9.3+dfsg-1
> Severity: normal
>
> Hi!
>
> org-notmuch is not included in the package anymore.
>
> Apparently, with the 9.3 release, upstream renamed a bunch of
> contrib/lisp/org-*.el to contrib/lisp/ol-*.el. Could it be that the
> debian/elpa file needs to be updated accordingly?
>

Thank you for noticing this, and for the notice!  It's a shame upstream
org-notmuch doesn't seem to have documented this in a changelog or
release notes—at least, I wasn't able to find one with a quick glance.

> Thanks a lot for maintaining org-mode in Debian! :)

Yes, thank you Sebastien :-) I hope you don't mind that I'm taking care
of this bug.  P.S. I will leave finalising and doing the upload up to
you.  If I don't hear back from you today I'll also go ahead and write
up the NEWS entry, since the upstream rename of these files/Emacs
packages/library names requires users to change their config like this:

  - (require 'org-notmuch)
  + (require 'ol-notmuch)

I think I've completed all the work and just need to test it, write that
NEWS entry, and push.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#948176: xa FTCBFS: uses the build architecture compiler as linker

[Helmut Grohne]

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

xa fails to cross build from source, because it uses the build
architecture compiler as linker via the LD variable. dh_auto_build does
not substitute this variable, because it is used inconsistently in
different projects. After substituting it to the C compiler, xa cross
builds successfully. Please consider applying the attached patch.

Helmut
diff -u xa-2.3.8/debian/changelog xa-2.3.8/debian/changelog
--- xa-2.3.8/debian/changelog
+++ xa-2.3.8/debian/changelog
@@ -1,3 +1,10 @@
+xa (2.3.8-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass the right C compiler as LD. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 04 Jan 2020 19:09:49 +0100
+
 xa (2.3.8-2) unstable; urgency=low
 
   * debian/control:
diff -u xa-2.3.8/debian/rules xa-2.3.8/debian/rules
--- xa-2.3.8/debian/rules
+++ xa-2.3.8/debian/rules
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+override_dh_auto_build:
+   dh_auto_build -- LD='$$(CC)'
+
 override_dh_auto_install:
make install DESTDIR=$(CURDIR)/debian/xa65/usr
 

Bug#948173: golang-thrift-dev: Go sources are installed into the wrong path

[Christian Barcenas]

Package: golang-thrift-dev
Version: 0.13.0-2
Severity: important

Right now Go source files are installed into /usr/share/gocode/src/thrift.
This means that Debian packages trying to build via dh-golang must refer to
the golang-thrift-dev sources using the import path "thrift".

However, the Go import path that is used by Thrift itself and by dependent
projects is really "github.com/apache/thrift/lib/go/thrift".

Go sources should be installed into
/usr/share/gocode/github.com/apache/thrift/lib/go/thrift.
The thrift source package's control file should also contain an
XS-Go-Import-Path header reflecting the correct Go import path.
 
Aside: is it worth renaming golang-thrift-dev to golang-github-apache-thrift-dev
or golang-github-apache-thrift-lib-go-thrift-dev, in order to comform with the
package naming convention used by the Debian Go Packaging Team?

Bug#948174: pd-beatpipe FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: pd-beatpipe
Version: 0.1-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pd-beatpipe fails to cross build from source, because it strips with the
build architecture strip during make install. Beyond breaking cross
compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. It is best to defer all stripping to
dh_strip. Please consider applying the attached patch.

Helmut
diff --minimal -Nru pd-beatpipe-0.1/debian/changelog 
pd-beatpipe-0.1/debian/changelog
--- pd-beatpipe-0.1/debian/changelog2018-01-29 21:11:57.0 +0100
+++ pd-beatpipe-0.1/debian/changelog2020-01-04 17:34:22.0 +0100
@@ -1,3 +1,10 @@
+pd-beatpipe (0.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 04 Jan 2020 17:34:22 +0100
+
 pd-beatpipe (0.1-5) unstable; urgency=medium
 
   * Updated Vcs-* stanzas to salsa.d.o
diff --minimal -Nru pd-beatpipe-0.1/debian/rules pd-beatpipe-0.1/debian/rules
--- pd-beatpipe-0.1/debian/rules2018-01-29 21:11:57.0 +0100
+++ pd-beatpipe-0.1/debian/rules2020-01-04 17:34:20.0 +0100
@@ -12,6 +12,6 @@
$(empty)
 
 override_dh_auto_install:
-   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
+   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=true
 # replace license file with link to the Debian license file
rm -f -- $(CURDIR)/debian/*/$(pkglibdir)/*/LICENSE.txt

Bug#948175: pd-bassemu FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: pd-bassemu
Version: 0.3-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pd-bassemu fails to cross build from source, because it strips with the
build architecture strip during make install. Beyond breaking cross
compilation, doing so breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. It is best to defer all stripping to
dh_strip. Please consider applying the attached patch.

Helmut
diff --minimal -Nru pd-bassemu-0.3/debian/changelog 
pd-bassemu-0.3/debian/changelog
--- pd-bassemu-0.3/debian/changelog 2018-01-29 21:01:42.0 +0100
+++ pd-bassemu-0.3/debian/changelog 2020-01-04 20:36:40.0 +0100
@@ -1,3 +1,10 @@
+pd-bassemu (0.3-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 04 Jan 2020 20:36:40 +0100
+
 pd-bassemu (0.3-5) unstable; urgency=medium
 
   * Added C/CPP/LDFLAGS to build
diff --minimal -Nru pd-bassemu-0.3/debian/rules pd-bassemu-0.3/debian/rules
--- pd-bassemu-0.3/debian/rules 2018-01-29 21:01:42.0 +0100
+++ pd-bassemu-0.3/debian/rules 2020-01-04 20:36:37.0 +0100
@@ -12,6 +12,6 @@
$(empty)
 
 override_dh_auto_install:
-   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
+   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=true
 # replace license file with link to the Debian license file
rm -f -- $(CURDIR)/debian/*/$(pkglibdir)/*/LICENSE.txt

Bug#804766: inetutils-inetd: please support ipv6

[Jean-Michel Vourgère]

On Wed, 11 Nov 2015 03:48:10 -0800, you wrote:
> inetd does not listen on IPv6 ports, only IPv4.

Actually, you can use "tcp6" rather than "tcp" to have a service work on both 
ipv4 & ipv6.

Too bad this is undocumented, and that the default inetd.conf uses ipv4-only 
in its comments (examples).

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

Bug#948172: RM: minia [armel armhf mipsel] -- RoQA; remove unsupported arch binaries to allow testing migration

[Juhani Numminen]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org, osal...@debian.org, 
ti...@debian.org

Hi,

I think minia binaries for armel, armhf and mipsel should be removed from 
unstable.
minia has build-dependency on libgatbcore-dev which is not built on those 
platforms.
Otherwise the remaining 1.6906-2 binaries in sid will block the testing 
migration.


Thanks,

Juhani

Bug#948171: ITP: python-exchangelib -- Client for Microsoft Exchange Web Services

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-exchangelib
  Version : 2.1.1
  Upstream Author : Erik Cederstrand 
* URL : https://github.com/ecederstrand/exchangelib/
* License : BSD-2-clause
  Programming Lang: Python
  Description : Client for Microsoft Exchange Web Services

 This module provides an well-performing, well-behaving, platform-independent
 and simple interface for communicating with a Microsoft Exchange 2007-2016
 Server or Office365 using Exchange Web Services (EWS). It currently implements
 autodiscover, and functions for searching, creating, updating, deleting,
 exporting and uploading calendar, mailbox, task, contact and distribution list
 items.

I intend to maintain this package as part of the DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl4RC+QRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoQxgf9GvICxQCJcy7eQYKVwSdh2RGA0qivF5rj
w1E02qB9vAoH6NyCNpbIbhZs4bsXHrtlHS8jeP0XY/VVObDEiVRC7YSFlo+G+0uc
MWYQgX8h8PAAUeWvw9WoD9Mzi3CKJPiDJfE8PTocOeOrgZdCCaYJbLIkQe9+YOEo
AoCaUDxp2l047KOk1TAGP2pImHrASqgqDRJuUvJBweEdJUgwnHMkH8bdjKQgDidD
//9lfAwvieC0uR6hUsUW6SDY7kUdhhx1q1PEBAp3FIoX6lMlU7LyliLKi7zKwjHE
p8WbuEXvwgNkjcJfxn0oZyXp5w1LIEwYbF4ZkkVetsmgdKLiRbMFjQ==
=TLYb
-END PGP SIGNATURE-

Bug#922568: ITA: jcc -- code generator producing a Python extension from Java classes

[Emmanuel Arias]

Hello everybody,

I've just push to salsa the the update of the package on
https://salsa.debian.org/debian/jcc

I will need sponsorship for upload.

I will also send the RFS for jcc, if anyone could review the package :)

thanks!

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El dom., 22 de dic. de 2019 a la(s) 14:40, Ludovico Cavedon
(cave...@debian.org) escribió:
>
> Hi Emmanuel,
>
> On Fri, Nov 22, 2019 at 7:24 PM Emmanuel Arias  
> wrote:
>>
>> I've just push to my own repository the new upstream release [1]
>>
>> I have not access to [2].
>>
>>
>> Ludovico, could you give me access to [2], please? This way I can
>> update the package.
>
>
> Done.
> I may not be able to review and sponsor the upload, though, sorry.
>
> Thank you,
> Ludovico

Bug#948038: ITP: gfsecret -- Tools to make secret sharing easier.

[Thomas Perret]

Le 03/01/2020 à 18:18, Philipp Kern a écrit :
> 
> What's the advantage of this tool vs. the tools in libgfshare-bin and ?
> 
> Kind regards and thanks
> Philipp Kern
> 

>From what I understand (correct me if I'm wrong) the tools included in
libgfshare-bin are more a raw proof of concept of the underlying library
than a user friendly interface.
I wasn't aware of  but from what I tested, it seems you can only
share a secret passphrase.

Gfsecret allows you to split and combine files using what is called
share URIs defined in a configuration file at split time. You can then
use this configuration file to combine the minimum number of shares
detected by the software to rebuild the file.

My main use (and the main purpose of this software) is to split your
master GPG key. Since a few release versions, there is even a facilating
tool to do exactly that.

The share URIs can be put on different local or external volumes.
Gfsecret supports local filesystem, external volumes identified by
uuid/label/mtp.

More information is available on Gfsecret website:
https://incenp.org/dvlpt/gfsecret.html

My opinion is that Gfsecret can be a good addition to Debian. Do you
think I should keep on packaging it or is it too redundant with other
tools already available?

Best,
Thomas

Bug#933301: mpd: systemd service doesn't use user configured UNIX socket since last update

[Simon Désaulniers]

Dear contributors,

To this day, I can't reproduce what I was talking about in my initial post.
Therefore, I assume that the issue resolved somehow. I can't say what changed
between those now and then and I think that we can close this issue.

Regards,

On Thu, Nov 07, 2019 at 11:34:03AM +0100, Florian Schlichting wrote:
> Hi Simon,
> 
> On Tue, Oct 01, 2019 at 04:14:40PM +0200, kaliko wrote:
> > On Sun, 28 Jul 2019 17:14:08 -0400 Simon Désaulniers 
> >  wrote:
> > > […] 
> > > After upgrading from 0.21.5-3 to 0.21.11-1, systemd's mpd service doesn't 
> > > seem
> > > to use the UNIX socket configured from my mpd configuration located at
> > > /home/simon/.config/mpd/mpd.conf.
> > > […]
> > 
> > I did not manage to reproduce the issue.
> > I'll try again later on a freshly installed VM upgraded to testing, but so 
> > far I have
> > not been able to reproduce the issue (tested also with mpd 0.21.15).
> > 
> > Maybe someone from MPD team is willing to give it a shot.
> 
> with version 0.21.8, mpd gained a _user_ mpd.socket unit, which defines
> 
> ListenStream=%t/mpd/socket
> ListenStream=6600
> 
> and is enabled by default. My feeling is that this is responsible for
> your observed differences between using systemctl and manually launching
> mpd. Did mpd.socket get stopped/restarted in your testing?
> 
> HTH,
> Florian
> 

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#948159: mmdebstrap: autopkgtest issue: +libcrypt1:amd64 in chroot

[Johannes Schauer]

Hi Paul,

Quoting Paul Gevers (2020-01-04 20:24:50)
> With a recent upload of mmdebstrap the autopkgtest of mmdebstrap fails
> in testing when that autopkgtest is run with the binary packages of
> mmdebstrap from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> mmdebstrap from testing0.5.1-3
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. It seems that
> this apparent regression is actually a sensitivity of the test to what
> is in the base system. Recently libcrypt got split of from gcc (but
> hasn't migrated to testing yet). So, without changes to your test, it
> can either pass in unstable, or in testing, but not both. Please
> consider how you want to fix this, as currently your package can't
> migrate to testing [1].

yes, I was aware of the introduction of libcrypt, that's why I uploaded 0.5.1-3
which addresses precisely this change. My naive assumption was, that once
libcrypt migrates to testing, mmdebstrap would migrate just fine.

Thanks a lot for opening this bug report because apparently I have a
misunderstanding about how our CI and migration work together with automatic
migration and maybe you can help me clear up my understanding of it? :)

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#948168: inetutils-inetd: Typo in inetd.8 : s/--remote/--resolve

[Jean-Michel Vourgère]

Package: inetutils-inetd
Version: 2:1.9.4-7
Severity: minor

Dear Maintainer,

man inetd says:

> --resolve
> Resolve local and remote IP addresses and pass them to the server
> program via TCPLOCALHOST and TCPREMOTEHOST environment variables.
> See ENVIRONMENT below. This option implies --environment.

but latter:

> In addition, if given the --remote option, inetd will set the following
> environment variables:
>
> TCPLOCALHOST: the DNS name of TCPLOCALIP.
>
> TCPREMOTEHOST: the DNS name of TCPREMOTEIP.

Moreover:
> # inetutils-inetd --environment --remote
> inetutils-inetd: unrecognized option '--remote'

So I guess the --remote is a typo for --resolve.

Please consider fixing debian/local/man/inetd.8

Thank you


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

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

Versions of packages inetutils-inetd depends on:
ii  libc62.28-10
ii  lsb-base 10.2019051400
ii  rsyslog [system-log-daemon]  8.1901.0-1
ii  tcpd 7.6.q-28
ii  update-inetd 4.49

inetutils-inetd recommends no packages.

inetutils-inetd suggests no packages.

-- no debconf information

Bug#948167: plplot: autopkgtest regression on arm64: /usr/lib/x86_64-linux-gnu/libm.so: No such file or directory

[Paul Gevers]

Source: plplot
Version: 5.15.0+dfsg-10
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of plplot the autopkgtest of plplot fails in
testing on arm64 when that autopkgtest is run with the binary packages
of plplot from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
plplot from testing5.15.0+dfsg-10
all others from testingfrom testing

I copied some of the output at the bottom of this report. The same error
message is present in older versions, but this time the test actually
fails on it.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=plplot

https://ci.debian.net/data/autopkgtest/testing/arm64/p/plplot/3862955/log.gz
autopkgtest [01:14:56]: test plplot-test: [---
cd c; make
make[1]: Entering directory
'/tmp/autopkgtest-lxc.jq53ogp7/downtmp/autopkgtest_tmp/c'
/usr/bin/cc  -g -O2
-fdebug-prefix-map=/build/plplot-KD6Nbq/plplot-5.15.0+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security
-fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/octave-5.1.0/octave/.. -I/usr/include/octave-5.1.0/octave
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/octave-5.1.0/octave/..
-I/usr/include/octave-5.1.0/octave x00c.c -o x00c  -I/usr/include/plplot
-lplplot /usr/lib/x86_64-linux-gnu/libm.so
cc: error: /usr/lib/x86_64-linux-gnu/libm.so: No such file or directory
make[1]: *** [Makefile:97: x00c] Error 1
make[1]: Leaving directory
'/tmp/autopkgtest-lxc.jq53ogp7/downtmp/autopkgtest_tmp/c'
make: *** [Makefile:31: c/x01c] Error 2
autopkgtest [01:14:56]: test plplot-test: ---]




signature.asc
Description: OpenPGP digital signature

Bug#948166: blkid -t treats UUIDs as case-sensitive

[Josh Triplett]

Package: util-linux
Version: 2.34-0.1
Severity: normal
File: /sbin/blkid

Just spent a while debugging a boot issue caused by blkid treating UUIDs
as case-sensitive:

Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  PARTUUID=5D75BD2D-6C59-4F73-9762-F4025CA97033 does not exist.  Dropping 
to a shell!
(initramfs) blkid -l -t PARTUUID=5D75BD2D-6C59-4F73-9762-F4025CA97033 -o device
(initramfs) blkid
/dev/vda1: UUID="83d14a86-02e0-4d48-abda-53b4ed66c8e0" TYPE="ext4" 
PARTUUID="5d75bd2d-6c59-4f73-9762-f4025ca97033"
(initramfs) blkid -l -t PARTUUID=5d75bd2d-6c59-4f73-9762-f4025ca97033 -o device
/dev/vda1

I would normally expect a string of hexadecimal to not care about the
case of the a-f digits. Either this needs documenting somewhere, or it
needs fixing in blkid.

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

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

Versions of packages util-linux depends on:
ii  fdisk  2.34-0.1
ii  libaudit1  1:2.8.5-2+b1
ii  libblkid1  2.34-0.1
ii  libc6  2.29-7
ii  libcap-ng0 0.7.9-2.1+b1
ii  libmount1  2.34-0.1
ii  libpam0g   1.3.1-5
ii  libselinux13.0-1
ii  libsmartcols1  2.34-0.1
ii  libsystemd0244-3
ii  libtinfo6  6.1+20191019-1
ii  libudev1   244-3
ii  libuuid1   2.34-0.1
ii  login  1:4.8-1
ii  zlib1g 1:1.2.11.dfsg-1+b1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools   4.1-2
pn  kbd | console-tools  
pn  util-linux-locales   

-- no debconf information

Bug#948165: ceph-common: missing Breaks+Replaces: ceph-base (<< 14.2.5)

[Andreas Beckmann]

Package: ceph-common
Version: 14.2.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../10-ceph-common_14.2.5-1_amd64.deb ...
  Unpacking ceph-common (14.2.5-1) over (14.2.4-8) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-zSzHB9/10-ceph-common_14.2.5-1_amd64.deb (--unpack):
   trying to overwrite '/etc/bash_completion.d/ceph', which is also in package 
ceph-base 14.2.4-8
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-zSzHB9/10-ceph-common_14.2.5-1_amd64.deb

Why are you still shipping bash completions in /etc?
These belong to /usr ...


cheers,

Andreas


ceph-mds=14.2.4-8_ceph-common=14.2.5-1.log.gz
Description: application/gzip

Bug#943007: Python2 removal in sid/bullseye

[Stefan Potyra]

Hi,

attached is a debdiff which fixes the problem.

Since I'm not a DD/DM I would appreciate sponsors.

Cheers,
  Stefan.
diff -Nru fauhdlc-20180504/debian/changelog fauhdlc-20180504/debian/changelog
--- fauhdlc-20180504/debian/changelog   2019-03-09 23:58:44.0 +0100
+++ fauhdlc-20180504/debian/changelog   2019-12-04 20:21:21.0 +0100
@@ -1,3 +1,12 @@
+fauhdlc (20180504-3) unstable; urgency=medium
+
+  * debian/control: Update B-D from python to python3,
+(Closes: #943007).
+  * debian/patches/0002-update-python.patch: Update interpreter
+of testsuite to python3 for #934007.
+
+ -- Stefan Potyra   Wed, 04 Dec 2019 20:21:21 +0100
+
 fauhdlc (20180504-2) unstable; urgency=medium
 
   [ Stefan Potyra ]
diff -Nru fauhdlc-20180504/debian/control fauhdlc-20180504/debian/control
--- fauhdlc-20180504/debian/control 2019-03-09 23:58:44.0 +0100
+++ fauhdlc-20180504/debian/control 2019-12-04 20:21:18.0 +0100
@@ -11,7 +11,7 @@
  bison (>= 1:2.1),
  flex,
  libfl-dev,
- python
+ python3
 Standards-Version: 4.1.4
 Homepage: http://faumachine.potyra.de/
 
diff -Nru fauhdlc-20180504/debian/patches/0002-update-python.patch 
fauhdlc-20180504/debian/patches/0002-update-python.patch
--- fauhdlc-20180504/debian/patches/0002-update-python.patch1970-01-01 
01:00:00.0 +0100
+++ fauhdlc-20180504/debian/patches/0002-update-python.patch2019-12-04 
20:21:21.0 +0100
@@ -0,0 +1,137 @@
+Description: Update interpreter of testsuite to python3
+ Update calls to print to python3.
+ Change calls to file() to open().
+Author: Stefan Potyra 
+Forwarded: no
+
+Index: fauhdlc-20180504/tests/run-tests.py
+===
+--- fauhdlc-20180504.orig/tests/run-tests.py
 fauhdlc-20180504/tests/run-tests.py
+@@ -1,9 +1,4 @@
+-#!/bin/sh
+-# vim: set filetype=python :
+-which python2   >/dev/null 2>&1 && exec python2   "$0" "$@" # '''
+-which python2.7 >/dev/null 2>&1 && exec python2.7 "$0" "$@" # '''
+-which python>/dev/null 2>&1 && exec python"$0" "$@" # '''
+-exec echo "Error: I can't find python anywhere" # '''
++#!/usr/bin/python3
+ 
+ # Run the test suite.
+ #
+@@ -39,7 +34,7 @@ class file_handling:
+   def get_output_name(cls, filename, prefix="."):
+   dir = "%s/%s" % (cls._builddir, prefix)
+   if not os.path.isdir(dir):
+-  print "Creating directory %s" % dir
++  print("Creating directory %s" % dir)
+   os.mkdir(dir)
+   return "%s/%s" % (dir, filename)
+ 
+@@ -101,8 +96,8 @@ class InterpreteTC:
+   return cls.useValgrind
+ 
+   def execute(self):
+-  fout = file(self._get_file_name("std.out"), "w")
+-  ferr = file(self._get_file_name("err.out"), "w")
++  fout = open(self._get_file_name("std.out"), "w")
++  ferr = open(self._get_file_name("err.out"), "w")
+ 
+   if InterpreteTC.canUseValgrind():
+   # Use the next lines for deep memory debugging.
+@@ -131,13 +126,13 @@ class InterpreteTC:
+   ferr.close()
+ 
+   def _handle_err_out(self):
+-  ferr = file(self._get_file_name("err.out"), "r")
+-  fout = file(self._get_file_name("std.out"), "r")
++  ferr = open(self._get_file_name("err.out"), "r")
++  fout = open(self._get_file_name("std.out"), "r")
+   lines = ferr.readlines()
+   ferr.close()
+   if InterpreteTC.canUseValgrind():
+   # write valgrind info to separate file
+-  vout = file(self._get_file_name("valgrind.err.out"), 
"w")
++  vout = open(self._get_file_name("valgrind.err.out"), 
"w")
+   vout.writelines(lines)
+   vout.close()
+   sim_fin_seen = False
+@@ -240,7 +235,7 @@ class TestCase:
+   d = eval_helper.eval_opt_list(arr[0])
+ 
+   opts = []
+-  if d.has_key("OPTS"):
++  if "OPTS" in d:
+   opts += d["OPTS"].split(" ")
+ 
+   for o in opts:
+@@ -262,8 +257,8 @@ class TestCase:
+ 
+   def execute(self, compiler, common_opts, output_ic=False):
+   """ execute the test """
+-  fout = file(self._get_out_file_name("std.out"), "w")
+-  ferr = file(self._get_out_file_name("err.out"), "w")
++  fout = open(self._get_out_file_name("std.out"), "w")
++  ferr = open(self._get_out_file_name("err.out"), "w")
+ 
+   cmd = [compiler]
+   if len(common_opts) > 0:
+@@ -285,7 +280,7 @@ class TestCase:
+   ferr.close()
+ 
+   def _store_err_out(self):
+-  f = file(self._get_out_file_name("err.out"), "r")
++  f = open(self._get_out_file_name("err.out"), "r")
+   

Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

[Sunil Mohan Adapa]

On 04/01/20 6:03 am, Martin Pitt wrote:
> Hello,
> 
> Sunil Mohan Adapa [2020-01-01 19:29 -0800]:
>> Debian build servers are unable to build the latest Debian package of pcp
>> uploaded to repositories: 5.0.2-1 [1]. As a consequence, pcp and it's
>> dependencies cockpit and freedombox are at threat of being removed from 
>> Debian
>> testing on January 10, 2020 [2].
>>
>> This is due to incorrect invocation of dh_python2 which is no longer 
>> available
>> on these build machines.
> 
> Right, as the previous upload (rightfully) dropped the py2 build deps. I 
> attach
> a first debdiff, but it doesn't work yet. The package build fails later on 
> with

The attached patch works for me. I have done (on a buster machine):

dpkg-source -x pcp_5.0.2-1.dsc
cd pcp-5.0.2
patch -p1 < ../pcp_5.0.2-1.1.debdiff
sudo apt install python3-all-dev
dpkg-buildpackage -us -uc

After that I did (for building clean on unstable):
cd ..
cowbuilder build pcp_5.0.2-1.1.dsc

Both these builds on stable and unstable worked without any hiccups.

> 
> | === src ===
> | rm -f Makefile.new Makefile.fix; CFLAGS='-fPIC -fno-strict-aliasing 
> -D_GNU_SOURCE  -Wall -O2 -g -DPCP_VERSION=\"5.0.2\" -I../../../src/include 
> -I../../../src/include/pcp' CXXFLAGS='' LDFLAGS=' -Wall 
> -L../../../src/libpcp/src -L../../../src/libpcp_web/src 
> -L../../../src/libpcp_pmda/src ' QT_SELECT=5 /usr/bin/qmake -o Makefile.new 
> CONFIG+=release && sed -e 's/Makefile.new/Makefile/g'  /usr/bin/gawk --posix '$1 == "LIBS" { printf $1; for (i=2;i<=NF;i++) { if 
> ($i~/^-L\//) { save=save " " $i; continue } else if (save!="" && $i~/^-l/) { 
> printf " %s",save; save="" } printf " %s",$i } if (save!="") printf " 
> %s",save; print ""; next } { print }' >Makefile.fix && ( if [ -f Makefile ]; 
> then if diff Makefile Makefile.fix >/dev/null; then :; else rm -f Makefile; 
> mv Makefile.fix Makefile; fi; else mv Makefile.fix Makefile; fi ); rm -f 
> Makefile.new Makefile.fix; /usr/bin/make --no-print-directory -f Makefile
> | rm -f Makefile.new Makefile.fix; CFLAGS='-fPIC -fno-strict-aliasing 
> -D_GNU_SOURCE  -Wall -O2 -g -DPCP_VERSION=\"5.0.2\" -I../../../src/include 
> -I../../../src/include/pcp' CXXFLAGS='' LDFLAGS=' -Wall 
> -L../../../src/libpcp/src -L../../../src/libpcp_web/src 
> -L../../../src/libpcp_pmda/src ' QT_SELECT=5 /usr/bin/qmake -o Makefile.new 
> CONFIG+=release && sed -e 's/Makefile.new/Makefile/g'  /usr/bin/gawk --posix '$1 == "LIBS" { printf $1; for (i=2;i<=NF;i++) { if 
> ($i~/^-L\//) { save=save " " $i; continue } else if (save!="" && $i~/^-l/) { 
> printf " %s",save; save="" } printf " %s",$i } if (save!="") printf " 
> %s",save; print ""; next } { print }' >Makefile.fix && ( if [ -f Makefile ]; 
> then if diff Makefile Makefile.fix >/dev/null; then :; else rm -f Makefile; 
> mv Makefile.fix Makefile; fi; else mv Makefile.fix Makefile; fi ); rm -f 
> Makefile.new Makefile.fix; /usr/bin/make --no-print-directory -f Makefile
> | diff: Makefile: No such file or directory
> | make[5]: Makefile: No such file or directory
> | mv: cannot stat 'Makefile.fix': No such file or directory
> 
> This file doesn't exist anywhere -- apparently src/include/builddefs.install
> builds it, but at this point this is pretty deeply woven into the build 
> system.
> Curiously, resuming the build with "make"  and "dpkg-buildpackage -us -uc -b 
> -nc"
> gets over that, but then in the end it still fails with

I believe the rm commands run during cleanup. I suspect the source is
not conducive to running multiple build/cleanup cycles. The problem
could be pre-existing and does not effect build machines or clean builds
from freshly extracted source. We can treat it as non-critical and leave
it to be dealt later.

> 
> | dpkg-deb: building package 'pcp-import-sar2pcp' in 
> '../pcp-import-sar2pcp_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-import-mrtg2pcp' in 
> '../pcp-import-mrtg2pcp_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-import-iostat2pcp' in 
> '../pcp-import-iostat2pcp_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-doc' in '../pcp-doc_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-import-sheet2pcp' in 
> '../pcp-import-sheet2pcp_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-import-ganglia2pcp' in 
> '../pcp-import-ganglia2pcp_5.0.2-1.1_all.deb'.
> | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
> exit status 2
> 
> without any apparent error message (the dh_builddeb -i itself succeeds).

I ran into similar issue when attempting to build with multiple parallel
tasks with DEB_BUILD_OPTIONS=parallel=8 or with -j8. If you have this
turned on, please try disabling it.

> 
> As pcp and its reverse dependencies are very close to being kicked out of
> testing (in 6 days), I'm interested in doing an NMU. However, with the above
> build system trouble, it may be necessary to fix this upstream first?

Thank you for looking into this :) Hope it will get resolved in time.

-- 
Sunil

Bug#853255: aircrack-ng FTCBFS: uses the build architecture pkg-config

[Samuel Henrique]

Hello Helmut,

Since it' s been some time since you initially submitted the bugreport,
could you please
check if this is still an issue with the latest version and if the patch
still fixes the problem?

I tried cross-building on my machine but it failed and I don' t know it'
something related to
my setup* or if the fix doesn't work anymore.

I would be happy to apply it, thanks.

* I just tried calling sbuild with --march=arm64

-- 
Samuel Henrique 

Bug#925606: gitlab: Fail to upgrade (error with activesupport gem)

[Pirate Praveen]

On ശ, Jan 4, 2020 at 17:31, Libor Klepáč  
wrote:

rake aborted!
NoMethodError: undefined method `rails5?' for Gitlab:Module
/usr/share/gitlab/config/initializers/mysql_set_length_for_binary_index
es.rb:27:in `'


Usually when you see this error with an initializer, it means that 
initializer was removed upstream but since we consider these as 
configuration we need to manually remove those in debian package. So 
you can just check the source package and see if the initializer is 
still present and if not just remove it.


rm 
/usr/share/gitlab/config/initializers/mysql_set_length_for_binary_indexes.rb


Sometimes our test environment does not have these initializers from 
very old versions so we miss removing them in the maintscripts.

Bug#948119: [schroot] does not work for non-root user

[tony mancill]

On Sat, Jan 04, 2020 at 09:35:27AM +0100, Giovanni Mascellani wrote:
> I suspect the problem might be related to the fact that /usr/bin/schroot
> is not set-uid anymore, while it was before. Executing
> ...

I ran into this as well and verified on another system running sid that
the binary update to 1.6.10-7 is when the setuid bit is removed - it's
simply not set in the binary package, while it is in .

I'm curious as to how this happened.  I not seeing anything obvious in
the source package changes [1], and when I rebuild 1.6.10-6 or 1.6.10-7
from source locally in a sid chroot, neither one of them results in a
setuid binary.  In the build logs for those builds, the install-arch
target is no longer being called.

However, building 1.6.10-7 in a buster chroot does result in a setuid
binary, so it seems that a recent change in the packaging toolchain
could be the root cause (although I haven't found anything definitive
yet).

Cheers,
tony

[1] https://salsa.debian.org/debian/schroot/compare/2ba1e043...e3358529

Bug#948163: dh-golang: Should not pass -trimpath to gccgo-go

[Samuel Thibault]

Package: dh-golang
Version: 1.43
Severity: important
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

dh-golang seems to be now passing -trimpath to "go install" invocations,
but that does not seem to be supported by gccgo-go, as can be seen on
e.g.

https://buildd.debian.org/status/fetch.php?pkg=golang-github-pelletier-go-toml=hurd-i386=1.4.0%2Breally1.4.0-2=1578167590=0

Samuel

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

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

Versions of packages dh-golang depends on:
ii  debhelper 12.7.3
ii  libdpkg-perl  1.19.7
ii  perl  5.30.0-9

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information

-- 
Samuel
> Allez, soyez sympa ... traduisez-lui "linux"
Linux, c'est comme le miel : c'est vachement bon mais ça attire les
mouches. En plus, ça colle aux doigts et on a du mal à s'en défaire.
-+- TP in: Guide du linuxien pervers - "Barrez vous les mouches !"

Bug#948111: apt: document “requested hashsum is not available” and others

[Thorsten Glaser]

clone 948111 -1
reassign -1 dpkg-dev
found -1 1.19.7
retitle -1 dpkg-dev: dpkg-scan{packages,sources} should calculate missing hashes
thanks

Dixi quod…

>The .dsc file was generated under a Debian release predating the
>Policy in question. This situation can even happen in Debian itself.
>
>Looking at the Sources file in the repository (generated by
>dpkg-scanpackages on sid) it’s indeed puzzling that it does
>not contain SHA-1 and SHA-256 for the .tar.gz file…

It would be great if dpkg-scan{packages,sources} could automatically
insert the missing hashes if run under sid. (Presence of Checksums-Sha1
and Checksums-Sha256 doesn’t trip up apt of sarge or newer, they
presumably just ignore it.)

Thanks in advance,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)

Bug#948111: apt: document “requested hashsum is not available” and others

[Thorsten Glaser]

David Kalnischkies dixit:

>Note that debian-policy says for the Checksums fields (§5.6.24.):
>| The list of files in these fields must match the list of files in the
>| Files field.
>
>This applies as the https://wiki.debian.org/DebianRepository/Format is
>referring to it in the relevant section. As such your repository is
>properly documented to be invalid.

The .dsc file was generated under a Debian release predating the
Policy in question. This situation can even happen in Debian itself.

Looking at the Sources file in the repository (generated by
dpkg-scanpackages on sid) it’s indeed puzzling that it does
not contain SHA-1 and SHA-256 for the .tar.gz file…

>As usual for these authentication lacking downloads:
>--allow-unauthenticated

It does not lack authentication: the MD5 is present, and I fully
expect it to be checked.


>It would also behoove to have a lot more people contribute to Debian
>native tools like apt. As long as that isn't happening you will have

I don’t speak C++ really. (Although I do plan to do something
with apt-archived-debian now that you mention it.)

>Note also that the first thing you complained about in referred to
>bugreport was that apt-secure(8) is too long (8 pages!). I am not sure

That was intended as a complaint about searchability, not pure length.
I had a hard time finding information about the release name change thing.

Listing all options, on the other hand, is extremely searchable and
discoverable. (Please do so ASCIIbetically, possibly grouped possibly not).

Thanks,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#948162: python-peak.util: should this package be removed?

[Sandro Tosi]

Source: python-peak.util
Severity: serious

Hello,
this package recently became a leaf pkg and it's currently python2-only; looking
at how it's made of, it appears it's a combination of modules:


Module Current  Latest py3k
   Version  Available  available?

addons 0.7  0.7some py3k support
bytecodeassembler  0.6  0.6.1  no
extremes   1.1.11.1.1  yes
proxies0.9  0.10.0 yes
symboltype 1.0  1.0yes

What are the plans for this package? they mostly leave at the new upstream
location on github https://github.com/PEAK-Legacy which says "Projects from the
Python Enterprise Application Kit that are not actively in development, or have
been discontinued. Most are Python 2-only."

Should we just go ahead and remove this package, since there are no more Debian
packages depending on it?

If i dont hear back within a week with a good reason to keep this package
around, i'll file for its removal.

Regards,
Sandro


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

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

Versions of packages python-peak.util depends on:
ii  python   2.7.16-1
pn  python-peak.util.decorators  

python-peak.util recommends no packages.

python-peak.util suggests no packages.

Bug#948161: phpmd: autopkgtest regression: Failed opening required ../../../vendor/autoload.php

[Paul Gevers]

Source: phpmd
Version: 2.8.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of phpmd the autopkgtest of phpmd fails in testing
when that autopkgtest is run with the binary packages of phpmd from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
phpmd  from testing2.8.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=phpmd

https://ci.debian.net/data/autopkgtest/testing/amd64/p/phpmd/3861717/log.gz

autopkgtest [23:13:45]: test command1: [---
PHP Warning:
require_once(/tmp/autopkgtest-lxc.z4bzxsnu/downtmp/build.8Ii/src/src/test/php/../../../vendor/autoload.php):
failed to open stream: No such file or directory in
/tmp/autopkgtest-lxc.z4bzxsnu/downtmp/build.8Ii/src/src/test/php/bootstrap.php
on line 18
PHP Fatal error:  require_once(): Failed opening required
'/tmp/autopkgtest-lxc.z4bzxsnu/downtmp/build.8Ii/src/src/test/php/../../../vendor/autoload.php'
(include_path='.:/usr/share/php') in
/tmp/autopkgtest-lxc.z4bzxsnu/downtmp/build.8Ii/src/src/test/php/bootstrap.php
on line 18
autopkgtest [23:13:45]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#948160: python-id3: should this package be removed?

[Sandro Tosi]

Package: python-id3
Severity: serious

Hello,
recently python-id3 became a leaf package; ID3 is python2-only, and upstream
hasnt updated this project in years; it looks like mutagen has the same
functionality of python-id3, so i believe we can safely remove python-id3 from
Debian without losing funtionalities.

If i dont hear back within a week with a good reason to keep this package in
Debian, i'll file for its removal.

Regards,
Sandro

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

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

Versions of packages python-id3 depends on:
ii  python  2.7.16-1

python-id3 recommends no packages.

python-id3 suggests no packages.

Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1

[Paul Gevers]

Hi,

I maybe interpreting this wrong, but maybe the regression in the
autopkgtest of python-dbusmock is pointing in the same direction. That
would make it very reproducible.

Otherwise that regression deserves its own bug report.

Paul

https://tracker.debian.org/pkg/network-manager

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/3859077/log.gz


==
FAIL: test_eth_and_wifi (__main__.TestNetworkManager)
--
Traceback (most recent call last):
  File "test_networkmanager.py", line 138, in test_eth_and_wifi
self.assertRegex(out, r'eth0.*\sdisconnected')
AssertionError: Regex didn't match: 'eth0.*\\sdisconnected' not found in
'DEVICE  TYPE  STATECONNECTION \neth0ethernet  unknown  --
   \nwlan0   wifi  unknown  -- \n'

==
FAIL: test_one_eth_connected (__main__.TestNetworkManager)
--
Traceback (most recent call last):
  File "test_networkmanager.py", line 115, in test_one_eth_connected
self.assertRegex(out, r'eth0.*\sconnected')
AssertionError: Regex didn't match: 'eth0.*\\sconnected' not found in
'DEVICE  TYPE  STATECONNECTION \neth0ethernet  unknown  --
   \n'

==
FAIL: test_one_eth_disconnected (__main__.TestNetworkManager)
--
Traceback (most recent call last):
  File "test_networkmanager.py", line 109, in test_one_eth_disconnected
self.assertRegex(out, r'eth0.*\sdisconnected')
AssertionError: Regex didn't match: 'eth0.*\\sdisconnected' not found in
'DEVICE  TYPE  STATECONNECTION \neth0ethernet  unknown  --
   \n'

==
FAIL: test_one_wifi_with_accesspoints (__main__.TestNetworkManager)
--
Traceback (most recent call last):
  File "test_networkmanager.py", line 155, in
test_one_wifi_with_accesspoints
self.assertRegex(out, r'wlan0.*\sconnected')
AssertionError: Regex didn't match: 'wlan0.*\\sconnected' not found in
'DEVICE  TYPE  STATECONNECTION \nwlan0   wifi  unknown  -- \n'

==
FAIL: test_remove_connection (__main__.TestNetworkManager)
--
Traceback (most recent call last):
  File "test_networkmanager.py", line 349, in test_remove_connection
self.assertRegex(self.read_device(), r'wlan0.*\sdisconnected')
AssertionError: Regex didn't match: 'wlan0.*\\sdisconnected' not found
in 'DEVICE  TYPE  STATECONNECTION \nwlan0   wifi  unknown  --
  \n'

==
FAIL: test_two_eth (__main__.TestNetworkManager)
--
Traceback (most recent call last):
  File "test_networkmanager.py", line 123, in test_two_eth
self.assertRegex(out, r'eth0.*\sdisconnected')
AssertionError: Regex didn't match: 'eth0.*\\sdisconnected' not found in
'DEVICE  TYPE  STATECONNECTION \neth0ethernet  unknown  --
   \neth1ethernet  unknown  -- \n'

==
FAIL: test_two_wifi_with_accesspoints (__main__.TestNetworkManager)
--
Traceback (most recent call last):
  File "test_networkmanager.py", line 179, in
test_two_wifi_with_accesspoints
self.assertRegex(out, r'wlan0.*\sconnected')
AssertionError: Regex didn't match: 'wlan0.*\\sconnected' not found in
'DEVICE  TYPE  STATECONNECTION \nwlan0   wifi  unknown  --
\nwlan1   wifi  unknown  -- \n'

==
FAIL: test_wifi_without_access_points (__main__.TestNetworkManager)
--
Traceback (most recent call last):
  File "test_networkmanager.py", line 130, in
test_wifi_without_access_points
self.assertRegex(out, r'wlan0.*\sconnected')
AssertionError: Regex didn't match: 'wlan0.*\\sconnected' not found in
'DEVICE  TYPE  STATECONNECTION \nwlan0   wifi  unknown  -- \n'



signature.asc
Description: OpenPGP digital signature

Bug#942062: liblept5: Please add Multi-Arch support

[Jeff Breidenbach]

leptonica-progs also?

Bug#948159: mmdebstrap: autopkgtest issue: +libcrypt1:amd64 in chroot

[Paul Gevers]

Source: mmdebstrap
Version: 0.5.1-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of mmdebstrap the autopkgtest of mmdebstrap fails
in testing when that autopkgtest is run with the binary packages of
mmdebstrap from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
mmdebstrap from testing0.5.1-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
this apparent regression is actually a sensitivity of the test to what
is in the base system. Recently libcrypt got split of from gcc (but
hasn't migrated to testing yet). So, without changes to your test, it
can either pass in unstable, or in testing, but not both. Please
consider how you want to fix this, as currently your package can't
migrate to testing [1].

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=mmdebstrap

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mmdebstrap/3859757/log.gz

diff -u - expected
--- -   2020-01-03 21:51:48.548366290 +
+++ expected2020-01-03 21:51:48.540172927 +
@@ -8,6 +8,7 @@
 libbz2-1.0:amd64
 libc-bin
 libc6:amd64
+libcrypt1:amd64
 libdebconfclient0:amd64
 libgcc1:amd64
 liblzma5:amd64
test.sh failed
+ kill 1780



signature.asc
Description: OpenPGP digital signature

Bug#937495: pyode: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:34:44 + Matthias Klose  wrote:
> Package: src:pyode
> Version: 1.2.0-4+cvs20090320.3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

upstream at http://pyode.sourceforge.net/ has been dormant for several
years now, but it looks like someone ported pyODE to py3k at
https://github.com/filipeabperes/Py3ODE ; i cant judge on the quality
of that port, but are you planning on keeping pyODE in debian? if so
probably the port is your only option, or else we'd likely have to
remove this package (in particular now that it became a leaf pkg).

cheers,
Sandro

Bug#948158: radare2-cutter ftbfs with radare2 3.9

[Paul Gevers]

Source: radare2-cutter
Version: 1.7.4-2
Severity: serious
Justification: ftbfs
Tags: ftbfs sid bullseye

Dear maintainer,

radare2 started a transition and I scheduled binNMUs for radare2-cutter.
However, they failed. Please investigate.

Paul

https://buildd.debian.org/status/package.php?p=radare2-cutter

Tail of log for radare2-cutter on amd64:

/<>/src/Cutter.h:21:31: error: ‘RBNode’ {aka ‘struct
r_rb_node_t’} has no member named ‘head’
   21 | if (list) for (it = list->head; it &&
((x=static_cast(it->data))); it = it->n)
  |   ^~~~
/<>/src/Cutter.cpp:1627:9: note: in expansion of macro
‘CutterRListForeach’
 1627 | CutterRListForeach(core_->bin->cur->o->relocs, it,
RBinReloc, br) {
  | ^~
make[3]: *** [CMakeFiles/Cutter.dir/build.make:228:
CMakeFiles/Cutter.dir/Cutter.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:80: CMakeFiles/Cutter.dir/all] Error 2
make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:87: all] Error 2
make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
dh_auto_build: cd obj-x86_64-linux-gnu && make -j4 "INSTALL=install
--strip-program=true" returned exit code 2
make: *** [debian/rules:10: build-arch] Error 255



signature.asc
Description: OpenPGP digital signature

Bug#948157: /usr/bin/notify-send: notify-send message does not show anything

[Ric And]

Package: libnotify-bin
Version: 0.7.8-1
Severity: important
File: /usr/bin/notify-send

Dear Maintainer,

   * What led up to the situation?

installing libnotify and issuing command
"notify-send message"

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

issuing command
"notify-send message"

   * What was the outcome of this action?

nothing, no usual bubble

   * What outcome did you expect instead?

the usual bubble with the message "message" in it.



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

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

Versions of packages libnotify-bin depends on:
ii  libc6 2.29-3
ii  libglib2.0-0  2.62.4-1
ii  libnotify40.7.8-1

libnotify-bin recommends no packages.

libnotify-bin suggests no packages.

-- debconf-show failed

Bug#948009: blhc: Don't scan dwz invocations seen with DH_VERBOSE=true

[Eriberto]

Em sáb., 4 de jan. de 2020 às 08:18, Simon Ruderich
 escreveu:
>
> thanks for the build log, fixed in f0a9d41 ("Fix false positive
> in `dwz` lines", 2020-01-04) [1].

Hi Simon,

Can you provide a new release?

Cheers,

Eriberto

Bug#948156: closing terminal leaves iftop running using 100% cpu

[Joey Hess]

Package: iftop
Version: 1.0~pre4-6
Severity: normal

This seems reproducible, I had two iftops spinning after closing
terminal windows, and tried again and got a third one spinning.

read(0, "", 1)  = 0
poll([{fd=0, events=POLLIN}], 1, 200)   = 1 ([{fd=0, 
revents=POLLIN|POLLERR|POLLHUP}])
read(0, "", 1)  = 0
poll([{fd=0, events=POLLIN}], 1, 200)   = 1 ([{fd=0, 
revents=POLLIN|POLLERR|POLLHUP}])
read(0, "", 1)  = 0
poll([{fd=0, events=POLLIN}], 1, 200)   = 1 ([{fd=0, 
revents=POLLIN|POLLERR|POLLHUP}])

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

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

Versions of packages iftop depends on:
ii  libc62.29-5
ii  libncurses6  6.1+20191019-1
ii  libpcap0.8   1.9.1-2
ii  libtinfo66.1+20191019-1

iftop recommends no packages.

iftop suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Sam Hartman  writes:

> One question:

> +The Release Team may, at their discretion, downgrade a Policy requirement
> +to a Policy recommendation for a given release of the Debian distribution.
> +This may be done for only a specific package or for the archive as a
> +whole. This provision is intended to provide flexibility to balance the
> +quality standards of the distribution against the release schedule and the
> +importance of making a stable release.

> I wonder if that should be can (or is permitted) rather than may.

Good point.  I agree with your analysis and will change this in my draft
version to "The Release Team can".

-- 
Russ Allbery (r...@debian.org)  

Bug#948115: Revise init script Policy based on GR result

[Russ Allbery]

Sam Hartman  writes:

> I've reviewed your patch.
> It looks good.

> One minor suggestion:

> +The ``start``, ``stop``, ``restart``, and ``force-reload`` options should
> +be supported by all init scripts. Supporting ``status`` is recommended but
> +not required. The ``reload`` and ``try-restart`` options are optional.

> How about supporting status is encouraged.
> At this point in the game, do we really want people opening bugs because
> an init script doesn't support status?

> Besides that, LGTM.

I agree with that change and will make that in my version.  Other folks
reviewing this patch, please consider that change as made when deciding
whether to second (and let me know if you object to that change).

Thank you for the review!

-- 
Russ Allbery (r...@debian.org)  

Bug#948155: upstream-metadata: insert new fields alphabetically

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.53
Severity: minor

When inserting new fields in debian/upstream/metadata, lintian-brush
should insert them where they fit lexicographically, rather than just
adding them to the end.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-3
ii  python3-breezy   3.0.2-1
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.14-4
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.3
ii  lintian2.43.0
ii  python3-asyncpg0.20.0-1
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  210

-- no debconf information

Bug#945588: RFS: lutris/0.5.4-1 -- open source gaming platform for GNU/Linux

[John Scott]

I'm not a DD and can't sponsor packages, but I hope my feedback can be helpful 
for you.

I see Lutris bundles python-distro. This is available in Debian, so the 
package should use it rather than installing a bundled copy. Debian's 
Winetricks should be used also.
Since Winetricks is in contrib, depending or recommending it means that Lutris 
needs to go to contrib or non-free also.

Lutris's description mentions Linux. Does it use any Linux-specific 
functionality, or should it build and work on other kenels like the Hurd and 
kFreeBSD also? If so the Architecture: any is fine.

I see from the TODO and your GitHub issue that you're aware of the copyright 
problems, but as the package currently stands it's not suitable even for non-
free.
Files: share/lutris/icons/hicolor/symbolic/apps/nintendods-symbolic.svg
Copyright: Nintendo
License: none-wikipedia
Comment: from 

Files: share/lutris/icons/hicolor/symbolic/apps/sonyplaystation-symbolic.svg
Copyright: Sony Interactive Entertainment
License: none-wikipedia
Comment: from 

License: none-wikipedia
 This image consists only of simple geometric shapes or text. It does not meet
 the threshold of originality needed for copyright protection, and is 
therefore
 in the public domain.

Does upstream get the images from Wikimedia Commons? These logos are almost 
surely encumbered by copyright and/or trademark issues and can't go in main. 
Wikimedia Commons holds neither the copyright nor trademark and Lutris 
shouldn't go on the editors' words. See the disclaimer
> Other restrictions may apply. These may include trademarks,
> patents, personality rights, moral rights, privacy rights, or any of the
> many other legal causes which are independent of copyright and vary greatly
> by jurisdiction.
It's inconceivable that permission from Nintendo and Sony was obtained.
But actually the Flaticon icons are worst of all and keep this from going even 
in non-free:

License: Flaticon
 From :
 What you CANNOT DO:
  -Distribute Flaticon's Contents unless it has been expressly authorized 
by Flaticon.
  -Include Flaticon's Contents in an online or offline database or file.
  -Offering Flaticon's Contents designs (or modified Flaticon Contents versions)
   for download.

...but I just downloaded them. And as though it couldn't be any worse:
  "The complete content of licenses can be consulted in the Terms of Use, that
  will prevail over the content of this document."
so that isn't the license anyway.

That's problematic and I don't see any 'explicit authorization,' so I've 
reported this issue upstream at https://github.com/lutris/lutris/issues/2573
and hope it will be taken care of.

With respect to the Debian-specific parts, the packaging looks good and I hope 
my feedback helps you tackle your last few challenges.

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

Bug#948154: tor: torify doesn't work with ipv6 network

[Hartmut Limmer]

Package: tor
Version: 0.4.2.5-1
Severity: important

Dear Maintainer,

torify doesn't work with ipv6.

It would be great if there would be a possibility to hide the interface 
identifier, too.

Thank you!

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

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

Versions of packages tor depends on:
ii  adduser 3.118
ii  libc6   2.29-3
ii  libcap2 1:2.25-2
ii  libevent-2.1-7  2.1.11-stable-1
ii  liblzma55.2.4-1
ii  libseccomp2 2.3.3-4
ii  libssl1.1   1.1.1d-0+deb10u2
ii  libsystemd0 241-7~deb10u2
ii  libzstd11.3.8+dfsg-3
ii  lsb-base10.2019051400
ii  runit-helper2.8.14
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages tor recommends:
ii  logrotate3.14.0-4
ii  tor-geoipdb  0.3.5.8-1
ii  torsocks 2.3.0-2

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  socat
pn  tor-arm  
pn  torbrowser-launcher  

-- no debconf information

Bug#948153: tor: doesn't work with ipv6 emails

[Hartmut Limmer]

Package: tor
Version: 0.4.2.5-1
Severity: important

Dear Maintainer,

is there a possibility to make torify with ipv6 work?

Actually it doesn't work.

It would be great if you would make it work.

Thank you!


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

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

Versions of packages tor depends on:
ii  adduser 3.118
ii  libc6   2.29-3
ii  libcap2 1:2.25-2
ii  libevent-2.1-7  2.1.11-stable-1
ii  liblzma55.2.4-1
ii  libseccomp2 2.3.3-4
ii  libssl1.1   1.1.1d-0+deb10u2
ii  libsystemd0 241-7~deb10u2
ii  libzstd11.3.8+dfsg-3
ii  lsb-base10.2019051400
ii  runit-helper2.8.14
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages tor recommends:
ii  logrotate3.14.0-4
ii  tor-geoipdb  0.3.5.8-1
ii  torsocks 2.3.0-2

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  socat
pn  tor-arm  
pn  torbrowser-launcher  

-- no debconf information

Bug#925606: gitlab: Fail to upgrade (error with activesupport gem)

[Libor Klepáč]

Sorry,
it was because i was running it by hand for this email and did not set
RAILS_ENV

It fails with different error when I set RAILS_ENV to production

Libor

$ bundle exec rake db:migrate --trace
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Attention: used pure ruby version of MurmurHash3
** Invoke db:migrate (first_time)
** Invoke db:load_config (first_time)
** Invoke environment (first_time)
** Execute environment
/usr/share/gitlab/lib/gitlab.rb:38: warning: already initialized
constant Gitlab::COM_URL
/usr/share/gitlab/lib/gitlab.rb:38: warning: previous definition of
COM_URL was here
/usr/share/gitlab/lib/gitlab.rb:39: warning: already initialized
constant Gitlab::APP_DIRS_PATTERN
/usr/share/gitlab/lib/gitlab.rb:39: warning: previous definition of
APP_DIRS_PATTERN was here
/usr/share/gitlab/lib/gitlab.rb:40: warning: already initialized
constant Gitlab::SUBDOMAIN_REGEX
/usr/share/gitlab/lib/gitlab.rb:40: warning: previous definition of
SUBDOMAIN_REGEX was here
/usr/share/gitlab/lib/gitlab.rb:41: warning: already initialized
constant Gitlab::VERSION
/usr/share/gitlab/lib/gitlab.rb:41: warning: previous definition of
VERSION was here
/usr/share/gitlab/lib/gitlab.rb:42: warning: already initialized
constant Gitlab::INSTALLATION_TYPE
/usr/share/gitlab/lib/gitlab.rb:42: warning: previous definition of
INSTALLATION_TYPE was here
/usr/share/gitlab/lib/gitlab.rb:43: warning: already initialized
constant Gitlab::HTTP_PROXY_ENV_VARS
/usr/share/gitlab/lib/gitlab.rb:43: warning: previous definition of
HTTP_PROXY_ENV_VARS was here
/usr/share/gitlab/config/initializers/2_app.rb:6: warning: already
initialized constant Gitlab::VERSION
/usr/share/gitlab/lib/gitlab.rb:41: warning: previous definition of
VERSION was here
rake aborted!
NoMethodError: undefined method `rails5?' for Gitlab:Module
/usr/share/gitlab/config/initializers/mysql_set_length_for_binary_index
es.rb:27:in `'
/usr/share/rubygems-integration/all/gems/activesupport-
5.2.3/lib/active_support/dependencies.rb:285:in `load'
/usr/share/rubygems-integration/all/gems/activesupport-
5.2.3/lib/active_support/dependencies.rb:285:in `block in load'
/usr/share/rubygems-integration/all/gems/activesupport-
5.2.3/lib/active_support/dependencies.rb:257:in `load_dependency'
/usr/share/rubygems-integration/all/gems/activesupport-
5.2.3/lib/active_support/dependencies.rb:285:in `load'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:657:in `block in load_config_initializer'
/usr/share/rubygems-integration/all/gems/activesupport-
5.2.3/lib/active_support/notifications.rb:170:in `instrument'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:656:in `load_config_initializer'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:614:in `block (2 levels) in '
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:613:in `each'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:613:in `block in '
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/initializable.rb:32:in `instance_exec'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/initializable.rb:32:in `run'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/initializable.rb:61:in `block in run_initializers'
/usr/lib/ruby/2.5.0/tsort.rb:228:in `block in tsort_each'
/usr/lib/ruby/2.5.0/tsort.rb:350:in `block (2 levels) in
each_strongly_connected_component'
/usr/lib/ruby/2.5.0/tsort.rb:422:in `block (2 levels) in
each_strongly_connected_component_from'
/usr/lib/ruby/2.5.0/tsort.rb:431:in
`each_strongly_connected_component_from'
/usr/lib/ruby/2.5.0/tsort.rb:421:in `block in
each_strongly_connected_component_from'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/initializable.rb:50:in `each'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/initializable.rb:50:in `tsort_each_child'
/usr/lib/ruby/2.5.0/tsort.rb:415:in `call'
/usr/lib/ruby/2.5.0/tsort.rb:415:in
`each_strongly_connected_component_from'
/usr/lib/ruby/2.5.0/tsort.rb:349:in `block in
each_strongly_connected_component'
/usr/lib/ruby/2.5.0/tsort.rb:347:in `each'
/usr/lib/ruby/2.5.0/tsort.rb:347:in `call'
/usr/lib/ruby/2.5.0/tsort.rb:347:in `each_strongly_connected_component'
/usr/lib/ruby/2.5.0/tsort.rb:226:in `tsort_each'
/usr/lib/ruby/2.5.0/tsort.rb:205:in `tsort_each'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/initializable.rb:60:in `run_initializers'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/application.rb:361:in `initialize!'
/usr/share/gitlab/config/environment.rb:6:in `'

Bug#948152: RM: piperka-client [armel mips64el ppc64el s390x] -- RoQA; remove unsupported arch binaries to allow testing migration

[Juhani Numminen]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Kari Pahula 

It seems that the second upload changed the build-dependencies
so the package now can't be built on [armel mips64el ppc64el s390x].
I believe the old binaries should be removed to make piperka-client
migrate from unstable to testing.


--
Juhani

Bug#934119: [Pkg-privacy-maintainers] Bug#934119: torbrowser-launcher: Erroneously manages /etc/apparmor.d/local/torbrowser.* as conffiles

[Roger Shimizu]

On Wed, Dec 11, 2019 at 1:00 AM Andreas Beckmann  wrote:
>
> I can reproduce this with piuparts on the upgrade path
>  jessie -> (stretch) -> (buster) -> bullseye
> There was no torbrowser-launcher in stretch or buster, therefore the
> jessie version was kept installed and finally upgraded to bullseye.
> There are no local modfications to these files.
>
>   Setting up torbrowser-launcher (0.3.2-4) ...
>
>   Configuration file '/etc/apparmor.d/local/torbrowser.Browser.firefox'
>==> File on system created by you or by a script.
>==> File also in package provided by package maintainer.
>  What would you like to do about it ?  Your options are:
>   Y or I  : install the package maintainer's version
>   N or O  : keep your currently-installed version
> D : show the differences between the versions
> Z : start a shell to examine the situation
>The default action is to keep your current version.
>   *** torbrowser.Browser.firefox (Y/I/N/O/D/Z) [default=N] ? dpkg: error 
> processing package torbrowser-launcher (--configure):
>end of file on stdin at conffile prompt

I find this is due to below files were shipped by previous version of
torbrowser-launcher, but not as conffile.
  /etc/apparmor.d/local/torbrowser.Tor.tor
  /etc/apparmor.d/local/torbrowser.Browser.firefox
But now they're shipped with conffile, though in size zero.
So new conffiles complain they don't match with existing ones.

It can be fixed by removing the old files when they match the checksum
of old shipped ones.
The fix will be uploaded soon.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#948106: Please switch to enchant-2 instead of enchant

[Alberto Garcia]

Control: tags -1 pending

On Sat, Jan 04, 2020 at 12:56:10AM +0100, Laurent Bigonville wrote:
> enchant-2 is now in debian unstable, please switch from enchant to
> enchant-2 (libenchant-dev -> libenchant-2-dev)

Thanks, this will happen in the next upload.

https://salsa.debian.org/webkit-team/webkit/commit/9dbf3090719c98a4d545e20091097460f37940f9

Berto

Bug#948151: git: Please consider demoting git-man to Recommends

[John Paul Adrian Glaubitz]

Source: git
Severity: important
User: debian-powe...@lists.debian.org
Usertags: ppc64

Hello!

git is failing to build from source on multiple architectures.

While this is not release-critical for ports architectures, it
makes git uninstallable on any Debian Ports architecture due
to the hard dependency of the git package on the git-man package.

I explained the problem in detail in [1].

Since git-man contains the manpage only and therefore would not
necessarily be needed on any machine like a buildd where git
is used by scripts only, it would be great if git-man could
be moved from Depends to Recommends.

Since Recommends are enabled by default in apt, this would still
cause git-man to be installed on standard desktop installations
when a user invokves "apt install git" but at the same time it
would avoid installability problems as described in [1], especially
for Debian Ports buildds which, for example, cannot build rustc
at the moment because git is no installable [2].

Thanks,
Adrian

> [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html
> [2] https://buildd.debian.org/status/package.php?p=rustc=sid

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

Bug#947936: chrony: Does (still) not start properly on boot on buster

[Santiago Vila]

On Fri, Jan 03, 2020 at 11:21:42PM +0100, Vincent Blut wrote:

> > Unfortunately, AFAIK, conflicts are bi-directional, so apparently the
> > problem will persist in buster as far as chrony still has conflicts
> > in the systemd unit file.
> 
> What do you mean by “conflicts are bi-directional”?

I meant that it is enough that service "A" declares a conflict with service "B"
so that both of them conflict with the other, i.e. they have
the "symmetric property" even if the conflicts is only declared once.

At least that's how I interpret the words "vice versa" here:

Conflicts=

A space-separated list of unit names. Configures negative
requirement dependencies. If a unit has a Conflicts= setting on
another unit, starting the former will stop the latter and vice versa.

So: If we tried to solve this in buster by dropping the use of
conflicts, and chrony still uses conflicts, maybe that would explain
that the problem is still there.

> Also, conflicting with systemd-timesyncd doesn’t seem to cause any issue on
> most systems (well, I hope ;-), so we should be cautious about incriminating
> “Conflicts= systemd-timesyncd.service” use as the root cause.

You are right. We should be cautious.

I really don't know which is the root cause, but I can reproduce this
failure in as many GCE machines as desired via cloning.

So I have just created two different machines for you and Michael to
see this by yourself (please check your private email for access details).

My suspicious is that this is some sort of race condition, but
I am not expert enough on systemd stuff to debug it.

Thanks.

Bug#948150: ruby-docker-api: Unused leaf package?

[Markus Frosch]

Package: ruby-docker-api
Version: 1.22.2-1
Severity: important

Hello maintainer,
Is this package still in use somehow? I noticed it has no active
rdepends in unstable.

As the gem is a pure library, it might make sense to deprecate it and
remove it from unstable.

Has anyone still has interest to maintain or use it?

Regards
Markus Frosch

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

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

Versions of packages ruby-docker-api depends on:
ii  ruby 1:2.5.1
pn  ruby-excon   
ii  ruby-minitar [ruby-archive-tar-minitar]  0.9-1

ruby-docker-api recommends no packages.

Versions of packages ruby-docker-api suggests:
pn  docker.io  

Bug#925606: gitlab: Fail to upgrade (error with activesupport gem)

[Libor Klepáč]

Hi,
i'm trying to upgrade to gitlab 12.6.2-1 from 11.3.11+dsfg-1.

I get this error on db:migrate
I fails on:
$ bundle exec rake db:migrate --trace
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Attention: used pure ruby version of MurmurHash3
rake aborted!
NameError: uninitialized constant RSpec
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/active_supp
ort.rb:53:in `block in load_missing_constant'
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/active_supp
ort.rb:8:in `without_bootsnap_cache'
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/active_supp
ort.rb:53:in `rescue in load_missing_constant'
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/active_supp
ort.rb:42:in `load_missing_constant'
/usr/share/gitlab/lib/tasks/frontend.rake:4:in `block in '
/usr/lib/ruby/vendor_ruby/rake/task_manager.rb:225:in `in_namespace'
/usr/lib/ruby/vendor_ruby/rake/dsl_definition.rb:141:in `namespace'
/usr/share/gitlab/lib/tasks/frontend.rake:2:in `'
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/kernel_requ
ire.rb:50:in `load'
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/kernel_requ
ire.rb:50:in `load'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:650:in `block in run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:650:in `each'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:650:in `run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/application.rb:515:in `run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:459:in `load_tasks'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/railtie.rb:190:in `public_send'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/railtie.rb:190:in `method_missing'
/usr/share/gitlab/Rakefile:10:in `'
/usr/lib/ruby/vendor_ruby/rake/rake_module.rb:29:in `load'
/usr/lib/ruby/vendor_ruby/rake/rake_module.rb:29:in `load_rakefile'
/usr/lib/ruby/vendor_ruby/rake/application.rb:703:in
`raw_load_rakefile'
/usr/lib/ruby/vendor_ruby/rake/application.rb:104:in `block in
load_rakefile'
/usr/lib/ruby/vendor_ruby/rake/application.rb:186:in
`standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:103:in `load_rakefile'
/usr/lib/ruby/vendor_ruby/rake/application.rb:82:in `block in run'
/usr/lib/ruby/vendor_ruby/rake/application.rb:186:in
`standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:80:in `run'
/usr/bin/rake:27:in `'

Caused by:
NameError: uninitialized constant RSpec
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/active_supp
ort.rb:43:in `load_missing_constant'
/usr/share/gitlab/lib/tasks/frontend.rake:4:in `block in '
/usr/lib/ruby/vendor_ruby/rake/task_manager.rb:225:in `in_namespace'
/usr/lib/ruby/vendor_ruby/rake/dsl_definition.rb:141:in `namespace'
/usr/share/gitlab/lib/tasks/frontend.rake:2:in `'
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/kernel_requ
ire.rb:50:in `load'
/usr/lib/ruby/vendor_ruby/bootsnap/load_path_cache/core_ext/kernel_requ
ire.rb:50:in `load'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:650:in `block in run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:650:in `each'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:650:in `run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/application.rb:515:in `run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/engine.rb:459:in `load_tasks'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/railtie.rb:190:in `public_send'
/usr/share/rubygems-integration/all/gems/railties-
5.2.3/lib/rails/railtie.rb:190:in `method_missing'
/usr/share/gitlab/Rakefile:10:in `'
/usr/lib/ruby/vendor_ruby/rake/rake_module.rb:29:in `load'
/usr/lib/ruby/vendor_ruby/rake/rake_module.rb:29:in `load_rakefile'
/usr/lib/ruby/vendor_ruby/rake/application.rb:703:in
`raw_load_rakefile'
/usr/lib/ruby/vendor_ruby/rake/application.rb:104:in `block in
load_rakefile'
/usr/lib/ruby/vendor_ruby/rake/application.rb:186:in
`standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:103:in `load_rakefile'
/usr/lib/ruby/vendor_ruby/rake/application.rb:82:in `block in run'
/usr/lib/ruby/vendor_ruby/rake/application.rb:186:in
`standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:80:in `run'
/usr/bin/rake:27:in `'



In this bugreport, you suggest gitlab should conflict with ruby-
bootsnap, but it depends on it.
Is there 

Bug#948149: RM: structure-synth [armel armhf] -- RoQA; remove unsupported arch binaries to allow testing migration

[Juhani Numminen]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Miriam Ruiz 

AIUI, the maintainer of structure-synth intentionally dropped armel and armhf
so the old binaries should be removed to allow it to migrate to testing.

Filing of an removal request like this was suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911993#5.

--
Juhani

Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library

[Dimitri John Ledkov]

I would be ok to reintroduce boost-python2.7 in experimental only.

On Sat, 4 Jan 2020, 16:16 Dimitri John Ledkov, 
wrote:

>
>
> On Sat, 4 Jan 2020, 06:45 Giovanni Mascellani,  wrote:
>
>> Hi,
>>
>> Il 03/01/20 22:07, Adrian Bunk ha scritto:
>> > Dimitri already agreed in a private discussion that this change was
>> bogus.
>> >
>>
>
> Hm?! I acknowledge it is an Abi Break, but it was intentional. We want to
> both drop python2 and drop boost1.67 from Sid and testing.
>
> Everything that uses or provides boost-python2.7 is RC in both testing and
> unstable.
>
> Thus yeah, I do object to reintroducing python2 support in any boost
> packages.
>
> Doing that will simply block 1.71 transition, and 1.67 removal.
>
> Python2 is dead :-)
>
> > Are there any objections against an NMU reverting the bogus Python 2
>> > removal in boost1.67?
>>
>> Totally agree that there is no reason to remote Python 2 support from
>> boost1.67. Please do the NMU.
>>
>>
>> Giovanni.
>> --
>> Giovanni Mascellani 
>> Postdoc researcher - Université Libre de Bruxelles
>>
>>

Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library

[Dimitri John Ledkov]

On Sat, 4 Jan 2020, 06:45 Giovanni Mascellani,  wrote:

> Hi,
>
> Il 03/01/20 22:07, Adrian Bunk ha scritto:
> > Dimitri already agreed in a private discussion that this change was
> bogus.
> >
>

Hm?! I acknowledge it is an Abi Break, but it was intentional. We want to
both drop python2 and drop boost1.67 from Sid and testing.

Everything that uses or provides boost-python2.7 is RC in both testing and
unstable.

Thus yeah, I do object to reintroducing python2 support in any boost
packages.

Doing that will simply block 1.71 transition, and 1.67 removal.

Python2 is dead :-)

> Are there any objections against an NMU reverting the bogus Python 2
> > removal in boost1.67?
>
> Totally agree that there is no reason to remote Python 2 support from
> boost1.67. Please do the NMU.
>
>
> Giovanni.
> --
> Giovanni Mascellani 
> Postdoc researcher - Université Libre de Bruxelles
>
>

Bug#948148: copyq: "does not start as a application"

[wim]

Package: copyq
Version: 3.7.3-1
Severity: normal

Hello,

starting this from the application menu or super+copy search to start it by 
clicking in the icon does not work.

workaround:
in a terminal type
$copyq show

hth,
Wim

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

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

Versions of packages copyq depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u1
ii  libqt5gui55.11.3+dfsg1-1+deb10u1
ii  libqt5network55.11.3+dfsg1-1+deb10u1
ii  libqt5script5 5.11.3+dfsg-3
ii  libqt5svg55.11.3-2
ii  libqt5widgets55.11.3+dfsg1-1+deb10u1
ii  libqt5x11extras5  5.11.3-2
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxtst6  2:1.2.3-1

Versions of packages copyq recommends:
ii  copyq-plugins  3.7.3-1

Versions of packages copyq suggests:
pn  copyq-doc  

-- no debconf information

Bug#948146: mathic FTCBFS: abuses AC_CHECK_FILE

[Helmut Grohne]

Source: mathic
Version: 1.0~git20180311-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mathic fails to cross build from source, because it abuses AC_CHECK_FILE
for searching files on the build system while it is meant for checking
files on the host system. When inspecting the build system, please use
plain test -e. Please consider applying the attached patch.

Helmut
--- mathic-1.0~git20180311.orig/configure.ac
+++ mathic-1.0~git20180311/configure.ac
@@ -35,7 +35,7 @@
 AS_IF([test "$with_gtest" = ""], [with_gtest="download"])
 
 AS_IF([test "$with_gtest" = "download"],
-  [with_gtest="yes"; AC_CHECK_FILE([$GTEST_PATH/src/gtest-all.cc], [], [
+  [with_gtest="yes"; AS_IF([test -e "$GTEST_PATH/src/gtest-all.cc"], [], [
 mkdir -p "$GTEST_PATH";
 (
   cd $GTEST_PATH;
@@ -54,7 +54,7 @@
 fi
   ])],
   [test "$with_gtest" = "yes"], [
-AC_CHECK_FILE([$GTEST_PATH/src/gtest-all.cc], [], [
+AS_IF([test -e "$GTEST_PATH/src/gtest-all.cc"], [], [
   AC_MSG_ERROR([could not find gtest source at path $GTEST_PATH.])
 ])
   ],

Bug#948147: ax25-apps FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: ax25-apps
Version: 0.0.8-rc4-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ax25-apps fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes ax25-apps cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru ax25-apps-0.0.8-rc4/debian/changelog 
ax25-apps-0.0.8-rc4/debian/changelog
--- ax25-apps-0.0.8-rc4/debian/changelog2015-09-14 01:29:06.0 
+0200
+++ ax25-apps-0.0.8-rc4/debian/changelog2020-01-04 17:10:49.0 
+0100
@@ -1,3 +1,10 @@
+ax25-apps (0.0.8-rc4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 04 Jan 2020 17:10:49 +0100
+
 ax25-apps (0.0.8-rc4-2) unstable; urgency=medium
 
   * debian/control:
diff --minimal -Nru ax25-apps-0.0.8-rc4/debian/rules 
ax25-apps-0.0.8-rc4/debian/rules
--- ax25-apps-0.0.8-rc4/debian/rules2015-09-09 16:01:55.0 +0200
+++ ax25-apps-0.0.8-rc4/debian/rules2020-01-04 17:10:34.0 +0100
@@ -22,8 +22,7 @@
dh_autoreconf
#autoreconf --install --force
chmod +x configure
-   # Add here commands to compile the package.
-   ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var 
--mandir=/usr/share/man 
--program-transform-name='s@^call@axcall@;s@^listen@axlisten@'
+   dh_auto_configure -- 
--program-transform-name='s@^call@axcall@;s@^listen@axlisten@'
dh_auto_build
 #  $(MAKE)
 

Bug#948145: spacearyarya FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: spacearyarya
Version: 1.0.2-7.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

spacearyarya fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes spacearyarya cross buildable. Please consider
applying the attached patch.

Helmut
diff -u spacearyarya-1.0.2/debian/changelog spacearyarya-1.0.2/debian/changelog
--- spacearyarya-1.0.2/debian/changelog
+++ spacearyarya-1.0.2/debian/changelog
@@ -1,3 +1,10 @@
+spacearyarya (1.0.2-7.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 04 Jan 2020 16:49:36 +0100
+
 spacearyarya (1.0.2-7.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -u spacearyarya-1.0.2/debian/rules spacearyarya-1.0.2/debian/rules
--- spacearyarya-1.0.2/debian/rules
+++ spacearyarya-1.0.2/debian/rules
@@ -16,8 +16,7 @@
&& touch configure \
&& touch config.h.in \
&& touch `find . -name Makefile.in`
-   ./configure --prefix=/usr --mandir=$${prefix}/share/man \
-   --infodir=$${prefix}/share/info
+   dh_auto_configure
$(MAKE)
touch build-stamp