Bug#962191:

[Jérémy Lal]

Le jeu. 4 juin 2020 à 15:48, Paolo Cavallini  a
écrit :

> > What mirror did you test ?
> deb http://deb.debian.org/debian/ sid main non-free contrib
> deb http://ftp.it.debian.org/debian/ sid main non-free contrib
>
> > Can you see nodejs 10.20.1~dfsg-1+b1 ?
> apt show nodejs
> Package: nodejs
> State: not a real package (virtual)
> N: Can't select candidate version from package nodejs as it has no
> candidate
> N: There are 2 additional records. Please use the '-a' switch to see them.
> N: No packages found
>
> > Did you run apt update ?
> Yes, I can install and update all other packages since many years
>

Just to be sure: you reported the bug from the same machine (amd64 arch) ?

Bug#962190: primer3: please disable Big Endian tests on autopkgtests too

[Gianfranco Costamagna]

control: tags -1 patch

This might work better:

--- primer3-2.4.0/debian/tests/run-unit-test2018-05-28 15:44:30.0 
+0200
+++ primer3-2.4.0/debian/tests/run-unit-test2020-06-04 11:47:04.0 
+0200
@@ -8,6 +8,12 @@
   AUTOPKGTEST_TMP=`mktemp -d /tmp/${pkg}-test.XX`
 fi
 
+BUILDARCH=$(dpkg-architecture -q DEB_BUILD_ARCH_ENDIAN)
+
+P3CORE_FAILED_TESTS="primer_masker primer_masker_formatted"
+
+FAILED_TESTS="testmasker"
+
 cp -a /usr/share/doc/${pkg}/examples/* $AUTOPKGTEST_TMP
 
 cd $AUTOPKGTEST_TMP
@@ -19,6 +25,16 @@
 ln -s /usr/bin/ntthal ./src/ntthal
 ln -s /usr/bin/oligotm ./src/oligotm
 
+if [ $BUILDARCH = big ]; then
+  cp -a test/p3test.pl test/p3test.pl~
+  cp -a test/Makefile test/Makefile~
+  # exclude tests known to fail on big endian
+  # See README.source for further explanation.
+  for tst in $P3CORE_FAILED_TESTS ; do sed -i "/$tst/d" test/p3test.pl ; done
+  sed -i "0,/$FAILED_TESTS/s///" test/Makefile
+  sed -i "/$FAILED_TESTS/,/endif/d" test/Makefile
+fi
+
 cd test/;
 
 echo "testcmdline:"
@@ -36,4 +52,12 @@
 echo "testtm:"
 perl oligotm_test.pl ${TESTOPTS}
 
+cd ..
+
+if [ $BUILDARCH = big ]; then
+  # restore original test file
+  mv test/p3test.pl~ test/p3test.pl
+  mv test/Makefile~ test/Makefile
+fi
+
 echo "PASS"

Bug#962191: [Pkg-javascript-devel] Bug#962191: Bug#962191: Package 'nodejs' has no installation candidate

[Jérémy Lal]

Le jeu. 4 juin 2020 à 16:36, Paolo Cavallini  a
écrit :

> > Thanks - none of those revealed anything exciting.
>
> exactly
>
> > Another idea: Which apt sources do your subscribe to?
> I tried two, see above
>
> > Also, do you have any apt pinning configured?
> no
>

Also, check which packages Provide: nodejs on your system.

Jérémy

Bug#962208: fix ftbfs with glibc 2.31

[Matthias Klose]

Package: src:libtrace3
Version: 3.0.21-1
Severity: important
Tags: sid bullseye

fix ftbfs with glibc 2.31. patch at
http://launchpadlibrarian.net/482821079/libtrace3_3.0.21-1ubuntu4_3.0.21-1ubuntu5.diff.gz

Bug#962199: gnutls28 FTBFS when using the nocheck build profile

[Andreas Metzler]

On 2020-06-04 Helmut Grohne  wrote:
> Source: gnutls28
> Version: 3.6.13-4
> Tags: patch ftbfs
> User: helm...@debian.org
> Usertags: rebootstrap

> gnutls28 fails to build from source when activating the nocheck build
> profile, because it uses netstat, but the corresponding depdendency is
> conditional to the profile. Please consider applying the attached patch
> to fix the buile.
[...]

Sorry for that.

I will drop the whole block once I have managed for gnutls to not
heisen-FTBFS on regular builds on Debian buildds.

cu Andreas

Bug#962212: buildstream: Missing recommends for git and ostree support

[Ben Hutchings]

Package: buildstream
Version: 1.4.1-1
Severity: important

Dear Maintainer,

I think buildstream should recommend:

* git (for the git plugin)
* python3-gi, gir1.2-ostree-1.0 (for the ostree plugin)

Please also check the run-time dependencies of other commonly used
plugins, which I think should be recommended.

Ben.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages buildstream depends on:
ii  python3  3.8.2-3
ii  python3-buildstream  1.4.1-1

Versions of packages buildstream recommends:
ii  python3-bst-external  0.18.0-1

buildstream suggests no packages.

-- no debconf information

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#962191: [Pkg-javascript-devel] Bug#962191: Package 'nodejs' has no installation candidate

[Paolo Cavallini]

> Please provide the output of this command:
> 
>   cat /etc/apt/sources.list sources.list.d/*

only
deb http://deb.debian.org/debian/ sid main non-free contrib
thanks



signature.asc
Description: OpenPGP digital signature

Bug#962198: scilab-test: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Package: scilab-test
Version: 6.1.0+dfsg1-3
Severity: normal

Dear Maintainer,

scilab-test depends on dummy transitional package ttf-dejavu-core, which was 
removed in fonts-dejavu 2.37-2 (#872809).
The dependency name should be updated to fonts-dejavu-core.

Bug#962211: blobandconquer-data: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Attaching patch.


blobandconquer-dejavu-deps.debdiff
Description: Binary data

Bug#948626: kicad: Closing pcbnew hangs main kicad process

[Paul "LeoNerd" Evans]

On Sun, 26 Jan 2020 17:51:55 +0100
Carsten Schoenert  wrote:

> > Seems to be stored there:
> >$ grep canvas_type .config/kicad/pcbnew 
> >canvas_type=1
> > 
> > (When switched on seems to be "=1", switched off to be "=2",
> >  but not completely sure about it.)
> > And maybe which graphics driver do you use?  

Mine is also

  canvas_type=1

I have tried setting it to 2 but that doesn't appear to make any
difference.

> As a shot into the blue, what libwx* libraries are used by the kicad
> main application? Should look like this (Debian testing / unstable) no
> matter if you called only kicad or eeschema or pcbnew.
> 
> > $ grep libwx /proc/$(pidof kicad)/maps
...
> You can also look at all libs that are used, maybe some version
> clashing due some library that's installed accidentally?

Mine are:

7f84a8ac6000-7f84a8b28000 r--p  fe:00 355482 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.5.0
7f84a8b28000-7f84a8ce4000 r-xp 00062000 fe:00 355482 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.5.0
7f84a8ce4000-7f84a8d6f000 r--p 0021e000 fe:00 355482 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.5.0
7f84a8d6f000-7f84a8d7 ---p 002a9000 fe:00 355482 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.5.0
7f84a8d7-7f84a8d7b000 r--p 002a9000 fe:00 355482 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.5.0
7f84a8d7b000-7f84a8d7f000 rw-p 002b4000 fe:00 355482 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.5.0
7f84a8d8a000-7f84a8d9b000 r--p  fe:00 355487 
/usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.5.0
7f84a8d9b000-7f84a8dc3000 r-xp 00011000 fe:00 355487 
/usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.5.0
7f84a8dc3000-7f84a8dd r--p 00039000 fe:00 355487 
/usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.5.0
7f84a8dd-7f84a8dd1000 ---p 00046000 fe:00 355487 
/usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.5.0
7f84a8dd1000-7f84a8dd3000 r--p 00046000 fe:00 355487 
/usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.5.0
7f84a8dd3000-7f84a8dd4000 rw-p 00048000 fe:00 355487 
/usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.5.0
7f84a8dd5000-7f84a8fe6000 r--p  fe:00 353901 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0.5.0
7f84a8fe6000-7f84a92da000 r-xp 00211000 fe:00 353901 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0.5.0
7f84a92da000-7f84a93d8000 r--p 00505000 fe:00 353901 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0.5.0
7f84a93d8000-7f84a93d9000 ---p 00603000 fe:00 353901 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0.5.0
7f84a93d9000-7f84a944b000 r--p 00603000 fe:00 353901 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0.5.0
7f84a944b000-7f84a9453000 rw-p 00675000 fe:00 353901 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0.5.0
7f84a945f000-7f84a949f000 r--p  fe:00 353946 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_html-3.0.so.0.5.0
7f84a949f000-7f84a950e000 r-xp 0004 fe:00 353946 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_html-3.0.so.0.5.0
7f84a950e000-7f84a953 r--p 000af000 fe:00 353946 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_html-3.0.so.0.5.0
7f84a953-7f84a953c000 r--p 000d fe:00 353946 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_html-3.0.so.0.5.0
7f84a953c000-7f84a953f000 rw-p 000dc000 fe:00 353946 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_html-3.0.so.0.5.0
7f84a954-7f84a95e9000 r--p  fe:00 353412 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0.5.0
7f84a95e9000-7f84a96bb000 r-xp 000a9000 fe:00 353412 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0.5.0
7f84a96bb000-7f84a9702000 r--p 0017b000 fe:00 353412 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0.5.0
7f84a9702000-7f84a9703000 ---p 001c2000 fe:00 353412 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0.5.0
7f84a9703000-7f84a9723000 r--p 001c2000 fe:00 353412 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0.5.0
7f84a9723000-7f84a9726000 rw-p 001e2000 fe:00 353412 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0.5.0
7f84a972a000-7f84a9759000 r--p  fe:00 353889 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_aui-3.0.so.0.5.0
7f84a9759000-7f84a97a6000 r-xp 0002f000 fe:00 353889 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_aui-3.0.so.0.5.0
7f84a97a6000-7f84a97be000 r--p 0007c000 fe:00 353889 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_aui-3.0.so.0.5.0
7f84a97be000-7f84a97c6000 r--p 00093000 fe:00 353889 

Bug#962191: [Pkg-javascript-devel] Bug#962191: Package 'nodejs' has no installation candidate

[Jonas Smedegaard]

Quoting Paolo Cavallini (2020-06-04 14:06:30)
> Package: nodejs
> Version: 10.20.1~dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> apt install nodejs
> returns
> Package 'nodejs' has no installation candidate

Please share the full output of these two commands:

  apt update

  apt install nodejs


> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE

Which out-of-tree kernel modules do you have installed?


> Versions of packages nodejs depends on:
> ii  libc6  2.30-8
> ii  libnode64  10.20.1~dfsg-1

The nodejs library is installed and up-to-date.


> Versions of packages nodejs suggests:
> ii  npm  6.14.5+ds-1

You have npm installed.  Please triple-check that it hasn't
messed up your system - check e.g. files below /usr/local and
environment variables...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#962201: natbraille: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Source: natbraille
Version: 2.0rc3-8
Severity: normal

Dear Maintainer,

natbraille depends on dummy transitional package ttf-dejavu-core, which was 
removed in fonts-dejavu 2.37-2 (#872809).
The dependency name should be updated to fonts-dejavu-core.

Bug#962203: DeprecationWarning: isAlive() is deprecated, use is_alive() instead

[Nelson A. de Oliveira]

Package: debdelta
Version: 0.65
Severity: normal

Hi!

It seems that something needs to be update in debdelta:

=
# debdelta-upgrade
Created,time  0.15sec, speed 151kB/sec, libmtdev1_1.1.6-1_amd64.deb
Downloaded, time  0.47sec, speed 83kB/sec, 
libcryptsetup12_2%3a2.3.2-1_2%3a2.3.3-1_amd64.debdelta
Created,time  0.33sec, speed 709kB/sec, 
libcryptsetup12_2%3a2.3.3-1_amd64.deb
Downloaded, time  0.41sec, speed 104kB/sec, 
calibre-bin_4.99.4+dfsg+really4.17.0-1_4.99.4+dfsg+really4.17.0-1+b1_amd64.debdelta
Created,time  2.09sec, speed 375kB/sec, 
calibre-bin_4.99.4+dfsg+really4.17.0-1+b1_amd64.deb
Downloaded, time  2.38sec, speed 206kB/sec, 
libqt5gui5_5.12.5+dfsg-10_5.12.5+dfsg-10+b1_amd64.debdelta
/usr/bin/debdelta-upgrade:5384: DeprecationWarning: isAlive() is deprecated, 
use is_alive() instead
  if patching_thread.isAlive() and no_delta and VERBOSE > 1 :
/usr/bin/debdelta-upgrade:5386: DeprecationWarning: isAlive() is deprecated, 
use is_alive() instead
  while patching_thread.isAlive() or ('a' in DEB_POLICY and no_delta):
/usr/bin/debdelta-upgrade:5386: DeprecationWarning: isAlive() is deprecated, 
use is_alive() instead
  while patching_thread.isAlive() or ('a' in DEB_POLICY and no_delta):
Created,time  6.01sec, speed 484kB/sec, 
libqt5gui5_5.12.5+dfsg-10+b1_amd64.deb
/usr/bin/debdelta-upgrade:5405: DeprecationWarning: isAlive() is deprecated, 
use is_alive() instead
  while patching_thread.isAlive():
/usr/bin/debdelta-upgrade:5410: DeprecationWarning: isAlive() is deprecated, 
use is_alive() instead
  while progress_thread != None and progress_thread.isAlive():
Delta-upgrade statistics:
 total resulting debs, size 3956kB time 11sec virtual speed 340kB/sec
=

Thank you!

Best regards,
Nelson

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

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

Versions of packages debdelta depends on:
ii  binutils  2.34-8
ii  bzip2 1.0.8-3
ii  libbz2-1.01.0.8-3
ii  libc6 2.30-8
ii  python3   3.8.2-3
ii  python3-requests  2.23.0+dfsg-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages debdelta recommends:
ii  bsdiff   4.3-21+b1
ii  gnupg-agent  2.2.20-1
ii  gnupg2   2.2.20-1
ii  gpg-agent [gnupg-agent]  2.2.20-1
ii  python3-apt  2.1.3
ii  python3-debian   0.1.37
pn  xdelta   
ii  xdelta3  3.0.11-dfsg-1+b1
ii  xz-utils [lzma]  5.2.4-1+b1

Versions of packages debdelta suggests:
pn  debdelta-doc  

-- no debconf information

Bug#962205: buildstream: Missing dependency on bubblewrap

[Ben Hutchings]

Package: buildstream
Version: 1.4.1-1
Severity: serious

Dear Maintainer,

bubblewrap is a run-time dependency for BuildStream on Linux, but is
not included in the package dependencies.

Ben.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages buildstream depends on:
ii  python3  3.8.2-3
ii  python3-buildstream  1.4.1-1

Versions of packages buildstream recommends:
ii  python3-bst-external  0.18.0-1

buildstream suggests no packages.

-- no debconf information

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#962206: linux-image-4.19.0-8-amd64: Debian Buster Machine Kernel Panics (consistently) after resume from suspend

[Markus Bawidamann]

Package: src:linux
Version: 4.19.98-1
Severity: normal

This is on a Dell Latitude E6540 Laptop. I have noticed intermittent crashes
after resuming from suspend for Buster for a long time. Now, with this kernel
Version, they are reproducible, so it panics every time I resume from suspend.
(Machine freezes with a black screen and is non responsive)



-- Package-specific info:
** Version:
Linux version 4.19.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-8-amd64 root=/dev/mapper/california--vg-root ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   15.009223] [drm] ring test on 3 succeeded in 4 usecs
[   15.009228] [drm] ring test on 4 succeeded in 3 usecs
[   15.185269] [drm] ring test on 5 succeeded in 2 usecs
[   15.185274] [drm] UVD initialized successfully.
[   15.185427] [drm] ib test on ring 0 succeeded in 0 usecs
[   15.185460] [drm] ib test on ring 1 succeeded in 0 usecs
[   15.185510] [drm] ib test on ring 2 succeeded in 0 usecs
[   15.185543] [drm] ib test on ring 3 succeeded in 0 usecs
[   15.185591] [drm] ib test on ring 4 succeeded in 0 usecs
[   15.446951] media: Linux media interface: v0.10
[   15.462089] videodev: Linux video capture interface: v2.00
[   15.485052] audit: type=1400 audit(1591277410.601:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/snapd/snap-confine" pid=968 comm="apparmor_parser"
[   15.485055] audit: type=1400 audit(1591277410.601:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=968 
comm="apparmor_parser"
[   15.485857] audit: type=1400 audit(1591277410.601:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=969 comm="apparmor_parser"
[   15.489778] audit: type=1400 audit(1591277410.605:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/libvirtd" pid=967 
comm="apparmor_parser"
[   15.489781] audit: type=1400 audit(1591277410.605:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/libvirtd//qemu_bridge_helper" pid=967 comm="apparmor_parser"
[   15.491119] audit: type=1400 audit(1591277410.605:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=974 
comm="apparmor_parser"
[   15.491122] audit: type=1400 audit(1591277410.605:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=974 
comm="apparmor_parser"
[   15.491124] audit: type=1400 audit(1591277410.605:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=974 
comm="apparmor_parser"
[   15.492489] audit: type=1400 audit(1591277410.605:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=975 comm="apparmor_parser"
[   15.495550] audit: type=1400 audit(1591277410.609:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=970 
comm="apparmor_parser"
[   15.636579] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_HD 
(1bcf:2c34)
[   15.653520] uvcvideo 1-1.5:1.0: Entity type for entity Extension 4 was not 
initialized!
[   15.653523] uvcvideo 1-1.5:1.0: Entity type for entity Extension 3 was not 
initialized!
[   15.653525] uvcvideo 1-1.5:1.0: Entity type for entity Processing 2 was not 
initialized!
[   15.653526] uvcvideo 1-1.5:1.0: Entity type for entity Camera 1 was not 
initialized!
[   15.653613] input: Laptop_Integrated_Webcam_HD: In as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0/input/input19
[   15.653697] usbcore: registered new interface driver uvcvideo
[   15.653698] USB Video Class driver (1.1.1)
[   15.841076] [drm] ib test on ring 5 succeeded
[   15.841353] [drm] Radeon Display Connectors
[   15.841354] [drm] Connector 0:
[   15.841354] [drm]   VGA-2
[   15.841355] [drm]   DDC: 0x65c0 0x65c0 0x65c4 0x65c4 0x65c8 0x65c8 0x65cc 
0x65cc
[   15.841356] [drm]   Encoders:
[   15.841356] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   15.899551] Console: switching to colour frame buffer device 240x67
[   15.920051] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   15.933353] [drm] Cannot find any crtc or sizes
[   15.936260] [drm] Initialized radeon 2.50.0 20080528 for :01:00.0 on 
minor 1
[   15.967453] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input20
[   15.967524] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input21
[   15.967583] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input22
[   15.967638] input: HDA Intel HDMI HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.0/sound/card0/input23
[   15.967697] input: HDA Intel HDMI 

Bug#962197: buildstream: Event loop broken on Python 3.8

[Ben Hutchings]

Control: tag -1 upstream fixed-upstream patch

Although there are still some issues with 3.8 upstream, this one is
actually fixed.  Here's the patch.

Ben.

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom
From: Chandan Singh 
Date: Mon, 21 Oct 2019 14:38:07 +0100
Subject: _scheduler/scheduler.py: Enforce SafeChildWatcher
Origin: https://gitlab.com/BuildStream/buildstream/-/commit/0eca9e6a4a01d1094987773bce58d9d3e501f1e8
Bug-Debian: https://bugs.debian.org/962197

In Python 3.8, `ThreadedChildWatcher` is the default watcher that causes
issues with our scheduler. Enforce use of `SafeChildWatcher`.

[benh: Backported to 1.4.1: adjust filename]
---
 buildstream/_scheduler/scheduler.py | 6 ++
 1 file changed, 6 insertions(+)

--- a/buildstream/_scheduler/scheduler.py
+++ b/buildstream/_scheduler/scheduler.py
@@ -137,6 +137,12 @@ class Scheduler():
 # Hold on to the queues to process
 self.queues = queues
 
+# NOTE: Enforce use of `SafeChildWatcher` as we generally don't want
+# background threads.
+# In Python 3.8+, `ThreadedChildWatcher` is the default watcher, and
+# not `SafeChildWatcher`.
+asyncio.set_child_watcher(asyncio.SafeChildWatcher())
+
 # Ensure that we have a fresh new event loop, in case we want
 # to run another test in this thread.
 self.loop = asyncio.new_event_loop()

Bug#890993: fixed in primer3 2.4.0-2

[Gianfranco Costamagna]

control: close -1

Lets close, I opened a new one in the meanwhile

G.

Bug#962204: dhcp-helper and the PID file error

[Aladdin]

Package: dhcp-helper
Version: 1.2-1+b1
Severity: normal

Dear Maintainer,

Installed this package on fresh Buster installation and everytime, when I start 
the server, systemd complains about lac of PID file. Is it possible to fix this?

Jun 04 14:18:13 zeta systemd[1]: Starting DHCP/BOOTP relay agent...
Jun 04 14:18:14 zeta systemd[1]: dhcp-helper.service: Can't open PID file 
/run/dhcp-helper.pid (yet?) after start: No such file or directory
Jun 04 14:18:14 zeta systemd[1]: Started DHCP/BOOTP relay agent.

Another thing is that the service file must be updated from /var/run to only 
/run as I get constant complains about this path.

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

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

Versions of packages dhcp-helper depends on:
ii  libc62.28-10
ii  netbase  5.6

dhcp-helper recommends no packages.

dhcp-helper suggests no packages.

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

-- no debconf information

Bug#961602: castle-game-engine-doc: Depends on removed ttf-dejavu packages

[Olivier Tilloy]

Submitted patch in the VCS:
https://salsa.debian.org/pascal-team/castle-game-engine/-/merge_requests/1

Bug#961439: buster-pu: package clamav/0.102.3+dfsg-0+deb10u1

[Sebastian Andrzej Siewior]

On 2020-06-01 18:52:49 [+0100], Adam D. Barratt wrote:
> 
> Were you assuming that libclamunrar would also be in that set, or just
> clamav itself?

Please go ahead with Clamav. I will ping the libclamunrar bug once it
got through NEW.

> Regards,
> 
> Adam

Sebastian

Bug#962210: blobwars-data: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Attaching patch.


blobwars-dejavu-deps.debdiff
Description: Binary data

Bug#962191: [Pkg-javascript-devel] Bug#962191: Package 'nodejs' has no installation candidate

[Jonas Smedegaard]

Quoting Paolo Cavallini (2020-06-04 16:35:39)
> > Another idea: Which apt sources do your subscribe to?
> I tried two, see above

I think you misunderstood.

Please provide the output of this command:

  cat /etc/apt/sources.list sources.list.d/*


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#962214: Needles dependencies to policykit

[Klaus Ethgen]

Source: gparted
Version: 1.0.0-0.1
Severity: normal

Mark Hindley encuraged me to send this bug report even though I had
certain reserves.

gparted up to version 0.32.0-2 could have been installed without
policykit and the full dependencies up to systemd. With package
1.0.0-0.1, that changed with an hard dependency to policykit-1. This
drives that package somewhat unusable for me as I never want to have any
dbus based privileges escalation in my systems.

And I believe that dependency should be lowered to recommend as it is
not mandatory if the disk device is writable by the user (or the tool is
used as root but that would have other security concerns, running a GUI
tool as root).

It is not often that I use the GUI tool gparted but from time to time it
is very useful. So I would ask to lower that dependency to a recommend
only.

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera/ceres)
Release:unstable
Codename:   sid
Architecture: x86_64

Kernel: Linux 5.6.7 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#850520: lintian: PT_GNU_STACK change triggers ~500 new errors

[Felix Lechner]

Hi Matthias,

> so you still need to update that list manually ...

I can revert commit 4c722ae9, which applied the tag to all
architectures instead of a select list (diff below). Is there a source
for the list, or a plan to implement additional architectures?

Kind regards
Felix Lechner

* * *

commit 4c722ae90d4c09542ee33aa549745879ea11465c
Author: Jakub Wilk 
Date:   Fri Oct 21 20:48:54 2016 +0200

checks/shared-libs: Check for PT_GNU_STACK on all architectures

The list of architectures that supported PT_GNU_STACK was woefully out
of date. Hopefully this feature is supported everywhere these days.

diff --git a/checks/shared-libs.pm b/checks/shared-libs.pm
index 93dfbed28..8122aa50c 100644
--- a/checks/shared-libs.pm
+++ b/checks/shared-libs.pm
@@ -36,19 +36,6 @@ use Lintian::Util qw(fail strip);
 # one of the following names.
 my $HWCAP_DIRS = Lintian::Data->new('shared-libs/hwcap-dirs');

-# The following architectures should always have a STACK setting in shared
-# libraries to disable executable stack.  Other architectures don't always add
-# this section and therefore can't be checked.
-my %stack_arches = map { $_ => 1 }qw(
-  alpha
-  amd64
-  i386
-  m68k
-  powerpc
-  s390
-  sparc
-);
-
 # List of symbols file meta-fields.
 my %symbols_meta_fields = map { $_ => 1 }qw(
   Build-Depends-Package
@@ -162,15 +149,11 @@ sub run {
 tag 'shlib-with-bad-permissions', $cur_file, $perms;
 }

-# executable stack.  We can only warn about a missing
-# section on some architectures.  Only warn if there's an
-# Architecture field; if that's missing, we'll already be
-# complaining elsewhere.
+# executable stack.
 if (not defined $objdump->{$cur_file}{'PH'}{STACK}) {
 if (defined $info->field('architecture')) {
 my $arch = $info->field('architecture');
-tag 'shlib-without-PT_GNU_STACK-section', $cur_file
-  if $stack_arches{$arch};
+tag 'shlib-without-PT_GNU_STACK-section', $cur_file;
 }
 } elsif ($objdump->{$cur_file}{'PH'}{STACK}{flags} ne 'rw-'){
 tag 'shlib-with-executable-stack', $cur_file;
diff --git a/debian/changelog b/debian/changelog
index 7b8e8411e..541ad1e73 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,6 +19,7 @@ lintian (2.5.49) UNRELEASED; urgency=medium
 + [JW] Don't complain about missing SONAME for position-independent
   executables.  Thanks to Reuben Thomas for the bug report.
   (Closes: #731987)
++ [JW] Check for PT_GNU_STACK existence on all architectures.
   * checks/source-copyright.pm:
 + [RA, JW] Fix handling punctuation characters in license expressions
   in machine-readable copyright files.  (Closes: #841356)

Bug#962200: sarg: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Package: sarg
Version: 2.4.0-1
Severity: normal

Dear Maintainer,

sarg depends on dummy transitional package ttf-dejavu-core, which was removed 
in fonts-dejavu 2.37-2 (#872809).
The dependency name should be updated to fonts-dejavu-core.

Bug#962214: Needles dependencies to policykit

[Mark Hindley]

On Thu, 4 Jun 2020 16:00:17 +0100 Klaus Ethgen  wrote:
> Source: gparted
> Version: 1.0.0-0.1
> Severity: normal

I tried this version of gparted this morning. I have a practical suggestion of a
way to resolve this.

gprted works fine running in a terminal as a normal user using sudo for
priviledge escalation. So the policykit-1 dependency does seem overly
restrictive.

Obviously this cannot work when clicking on a menu item.

Maybe the dependency could be 'policykit-1 | sudo' and if pkexec is not found
the /usr/sbin/gparted script could show a notification that it has to be run
with sudo in a terminal?

The majority of users would see no change to the behaviour and those who want to
avoid policykit-1 for whatever reason would be able to do so.

Thanks.

Mark

Bug#896012: lintian: Remove tag library-not-linked-against-libc

[Felix Lechner]

P.S: A recent archive-wide run showed 334 overrides and 
occurrences. The override ratio does not support a removal, but the
total number of occurrences may. Could it be true that we are shipping
 defective shared libraries? I don't think so.

Also, the tag carries the Severity 'error'.

Kind regards
Felix Lechner

* * *

detagtive=> SELECT count(taxiv.hint.id) AS hints,
count(taxiv.override.id) AS overrides

FROM taxiv.hint

INNER JOIN taxiv.run ON taxiv.run.id = taxiv.hint.run_id
INNER JOIN ftp.source ON ftp.source.id = taxiv.run.ftp_source_id
INNER JOIN ftp.source_name ON ftp.source_name.id = ftp.source.source_name_id
INNER JOIN lintian.tag ON lintian.tag.id = taxiv.hint.lintian_tag_id
INNER JOIN lintian.tag_name ON lintian.tag_name.id = lintian.tag.tag_name_id
LEFT JOIN taxiv.override ON taxiv.override.hint_id = taxiv.hint.id

WHERE
taxiv.run.lintian_version_id = 3
AND
lintian.tag_name.literal = 'library-not-linked-against-libc'

 hints | overrides
---+---
   |   334
(1 row)

Bug#962196: singularity: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

I am attaching a patch.


singularity-dejavu-deps.debdiff
Description: Binary data

Bug#962207: manaplus-data: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Package: manaplus-data
Version: 1.9.3.23-4
Severity: normal

Dear Maintainer,

manaplus-data depends on dummy transitional package ttf-dejavu-core, which was 
removed in fonts-dejavu 2.37-2 (#872809).
The dependency name should be updated to fonts-dejavu-core.

Bug#962207: manaplus-data: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Attaching a patch.


manaplus-dejavu-deps.debdiff
Description: Binary data

Bug#962210: blobwars-data: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Package: blobwars-data
Version: 2.00-1
Severity: normal

Dear Maintainer,

blobwars-data depends on dummy transitional package ttf-dejavu-core, which was 
removed in fonts-dejavu 2.37-2 (#872809).
The dependency name should be updated to fonts-dejavu-core.

Bug#962216: journalctl -f --boot header perhaps not appropriate

[積丹尼 Dan Jacobson]

Package: systemd
Version: 245.5-3
Severity: wishlist
File: /bin/journalctl

Are you sure the
-- Logs begin at Sun 2020-02-02 08:24:03 CST. --
message is helpful for
# journalctl --boot
and
# journalctl --follow ?

It may be referring to months of old logs that aren't being shown.

Bug#962222: makedumpfile does not translate addresses properly on arm64

[Ioanna Alifieraki]

Package: makedumpfile
Version: 1:1.6.7-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
This may result in makedumpfile looping forever exhausting all memory,
or translating a virtual address to an invalid physical address and then 
failing and falling back to cp.
The reason it cannot resolve some addresses is because the PMD mask is wrong.
When physical address mask allows up to 48bits pmd mask should allow the
same, currently pmd mask is set to 40bits (see commit [1]).

For more information please refer to :
https://launchpad.net/bugs/1869465

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

The patch aligns the PMD_SECTION_MASK with PHYS_MASK and fixed the bug.

  * d/p/align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) 


Thanks for considering the patch.

[1] 
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-33-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
makedumpfile-1.6.7/debian/patches/align_PMD_SECTION_MASK_with_PHYS_MASK.patch 
makedumpfile-1.6.7/debian/patches/align_PMD_SECTION_MASK_with_PHYS_MASK.patch
--- 
makedumpfile-1.6.7/debian/patches/align_PMD_SECTION_MASK_with_PHYS_MASK.patch   
1970-01-01 00:00:00.0 +
+++ 
makedumpfile-1.6.7/debian/patches/align_PMD_SECTION_MASK_with_PHYS_MASK.patch   
2020-06-04 13:36:01.0 +
@@ -0,0 +1,34 @@
+From: Michal Suchanek 
+Origin: Upstream, 
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1869465
+Date: Mon, 16 Mar 2020 19:39:58 +0100
+Subject: [PATCH] Align PMD_SECTION_MASK with PHYS_MASK
+
+Reportedly on some arm64 systems makedumpfile loops forever exhausting
+all memory when filtering kernel core. It turns out the reason is it
+cannot resolve some addresses because the PMD mask is wrong. When
+physical address mask allows up to 48bits pmd mask should allow the
+same.
+I suppose you would need a system that needs physical addresses over 1TB
+to be able to reproduce this. This may be either because you have a lot
+of memory or because the firmware mapped some memory above 1TB for some
+reason.
+
+Signed-off-by: Michal Suchanek 
+---
+ arch/arm64.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: makedumpfile-1.6.7/arch/arm64.c
+===
+--- makedumpfile-1.6.7.orig/arch/arm64.c
 makedumpfile-1.6.7/arch/arm64.c
+@@ -81,7 +81,7 @@ static unsigned long kimage_voffset;
+  * Remove the highest order bits that are not a part of the
+  * physical address in a section
+  */
+-#define PMD_SECTION_MASK  ((1UL << 40) - 1)
++#define PMD_SECTION_MASK  ((1UL << PHYS_MASK_SHIFT) - 1)
+ 
+ #define PMD_TYPE_MASK 3
+ #define PMD_TYPE_SECT 1
diff -Nru makedumpfile-1.6.7/debian/patches/series 
makedumpfile-1.6.7/debian/patches/series
--- makedumpfile-1.6.7/debian/patches/series2020-03-17 19:40:38.0 
+
+++ makedumpfile-1.6.7/debian/patches/series2020-06-04 13:36:01.0 
+
@@ -1 +1,2 @@
 0002-adapt-makefile-to-debian.patch
+align_PMD_SECTION_MASK_with_PHYS_MASK.patch

Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye

[Alexandre Rossi]

The problem seems to be that the PHP plugin is compiled against PHP7.4
and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in sid.

$ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php
libphp7.so => /usr/lib/libphp7.so (0x7f4b8ca48000)
$ ls -l /usr/lib/libphp7.so
lrwxrwxrwx 1 root root 25 mai   11 19:41 /usr/lib/libphp7.so -> 
/etc/alternatives/libphp7
$ ls -l /etc/alternatives/libphp7
lrwxrwxrwx 1 root root 21 mai   11 19:41 /etc/alternatives/libphp7 -> 
/usr/lib/libphp7.4.so

The php plugin should explicitly be linked against /usr/lib/libphp7.4.so

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Roland Plüss]

On 6/2/20 1:05 PM, Tobias Frost wrote:
> On Mon, Jun 01, 2020 at 04:13:33PM +0200, Roland Plüss wrote:
>> On 5/31/20 9:19 AM, Tobias Frost wrote:
> (...) 
>
>>> It seems at first glance possible that both versions can be in Debian,
>>> however, the release/security team will not be happy to have both of
>>> them in a stable release, IOW, having two versions can only be a
>>> intermediate solution until all reverse dependencies of 1.6* have been
>>> updated (by patching the respective Debian packages.) More about such
>>> library transision:
>>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>>>
>> FOX-1.7 and FOX-1.6 are not compatible (well, mostly yes but in
>> important things not). That said they are different libraries with
>> separate include and library names (/usr/include/fox-1.6 vs
>> /usr/include/fox-1.7 and the same for libraries). So technically
>> applications linking against FOX-1.6 do not have to be change if FOX-1.7
>> is added on the same system (the two can coexist). But it depends if two
>> library versions of the same library are accepted even if they are disjoint.
> Those versions are not disjoint, the new version is just an evolution of the
> old one.
>
>
> Incompatible ABI changes is nothing special and happens all the time in Debian
> (called library transistios). As I tried to explain earlier, the maintainer
> duty is to resolve this by a transistion when updating the library.
>
> For you, hat means you need either 1.6 for code base or you need to help that
> all of Debian is using 1.7. You can't have both versions in Debian…
>
I don't see any way for me to get other projects to update to 1.7 . FOX
separates 1.7 from 1.6 so projects are not forced to upgrade if they
don't want to.

I can try ask the maintainer but I consider this a 0% success rate.

-- 
Mit freundlichen Grüssen
Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch



signature.asc
Description: OpenPGP digital signature

Bug#962201: natbraille: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Submitted patch to the VCS:
https://salsa.debian.org/a11y-team/natbraille/-/merge_requests/1

Bug#962152: buster-pu: package ca-certificates/20200601~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-06-03 at 16:14 -0500, Michael Shuler wrote:
> ca-certificates (20200601~deb10u1) buster; urgency=medium
> 
>* Rebuild for buster.
>* Merge changes from 20200601
>  - d/control; set d/gbp.conf branch to debian-buster
>* This release updates the Mozilla CA bundle to 2.40, blacklists
>  distrusted Symantec roots, and blacklists expired "AddTrust
> External
>  Root". Closes: #956411, #955038, #911289, #961907

Please go ahead.

Regards,

Adam

Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-06-03 at 16:41 -0500, Michael Shuler wrote:
> ca-certificates (20200601~deb9u1) stretch; urgency=medium
> 
>* Rebuild for stretch.
>* Merge changes from 20200601
>  - d/control
>* This release updates the Mozilla CA bundle to 2.40, blacklists
>  distrusted Symantec roots, and blacklists expired "AddTrust
> External
>  Root". Closes: #956411, #955038, #911289, #961907
>* Fix permissions on /usr/local/share/ca-certificates when using 
> symlinks.
>  Closes: #916833
> 

Please go ahead.

Regards,

Adam

Bug#962211: blobandconquer-data: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Package: blobandconquer-data
Version: 1.11-dfsg+20-1.1
Severity: normal

Dear Maintainer,

blobandconquer-data depends on dummy transitional package ttf-dejavu-core, 
which was removed in fonts-dejavu 2.37-2 (#872809).
The dependency name should be updated to fonts-dejavu-core.

Bug#896012: lintian: Remove tag library-not-linked-against-libc

[Felix Lechner]

Control: retitle -1 lintian: Remove tag library-not-linked-against-libc

Hi,

> So probably we need an update for our QA tools to do a better detection of
> dynamically linked binaries.

Lintian cannot detect this tag reliably. It should probably be removed.

Like many other dependency-type problems in Debian, the analysis of
library prerequisites requires a tool with an archive-wide
perspective. The Lintian team may eventually be able to provide
something on lintian.d.o, but the stand-alone program 'lintian' cannot
do it.

In the case of fwupd, Lintian sees the following, immediate library
requirements:

% readelf -WltdVs
dir/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi_recovery.so
...
 0x0001 (NEEDED) Shared library: [libfwupd.so.2]
 0x0001 (NEEDED) Shared library: [libfwupdplugin.so.1]
 0x0001 (NEEDED) Shared library: [libgobject-2.0.so.0]
 0x0001 (NEEDED) Shared library: [libglib-2.0.so.0]
...

while ldd resolves the whole tree:

% ldd dir/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi_recovery.so
linux-vdso.so.1 (0x7ffd7ebca000)
libfwupd.so.2 => /lib/x86_64-linux-gnu/libfwupd.so.2 (0x7fea01bce000)
libfwupdplugin.so.1 => not found
libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0
(0x7fea01b79000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7fea01a5a000)
libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0
(0x7fea0189c000)
libsoup-2.4.so.1 => /lib/x86_64-linux-gnu/libsoup-2.4.so.1
(0x7fea0180c000)
libjson-glib-1.0.so.0 =>
/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 (0x7fea017e)
*   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fea0161f000)
libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 (0x7fea01615000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fea015f4000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fea0158)
libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0
(0x7fea0157a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fea0135a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fea01355000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x7fea012f6000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x7fea010ce000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fea010b4000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2
(0x7fea01067000)
libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x7fea00ebc000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7fea00d9a000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x7fea00d87000)
/lib64/ld-linux-x86-64.so.2 (0x7fea01c1d000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7fea00d32000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fea00d28000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x7fea00c46000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3
(0x7fea00c12000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
(0x7fea00c0c000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0
(0x7fea00bfd000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
(0x7fea00bf6000)
libicui18n.so.63 => /lib/x86_64-linux-gnu/libicui18n.so.63
(0x7fea0091b000)
libicuuc.so.63 => /lib/x86_64-linux-gnu/libicuuc.so.63 (0x7fea0074a000)
libicudata.so.63 => /lib/x86_64-linux-gnu/libicudata.so.63
(0x7fe9fed5a000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fe9fed32000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe9febaf000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x7fe9feb9)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2
(0x7fe9fea0c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fe9fea01000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fe9fe87d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fe9fe863000)

As one can see, the dynamic linker makes libc.so.6 available
indirectly, but that analysis is possible only on a running system.
Another approach would be to scan all shared libraries in the archive
and construct the dependency tree. Both are outside Lintian's purview.

The bootstrapping folks occasionally approach the Lintian team with
requests for similar analysis. Their solution will also require a
portfolio-type approach, and a new tool. Let's call it
'detaxification' for now. It resolves dependencies.

> lintian generates false positives for library-not-linked-against-libc after 
> gcc-7 7.3.0-16

Perhaps the previous title of the bug report is valuable for posterity.

Kind regards
Felix Lechner

Bug#962090: Same Issue with a Python3 Project for Buster

[Jürgen Kuri]

--
 cd /build/ehbackup-api-3.3.2+3+g6939d93~ui10/ && env 
PATH="/usr/lib/ccache:/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" 
dpkg-buildpackage -us -uc  -d   
dpkg-buildpackage: info: source package ehbackup-api


dpkg-buildpackage: info: source version 3.3.2+3+g6939d93~ui10   


dpkg-buildpackage: info: source distribution UNRELEASED 


dpkg-buildpackage: info: source changed by EhBackup Team 


   
dpkg-buildpackage: info: host architecture amd64


 dpkg-source --before-build .   


dpkg-source: info: using options from 
ehbackup-api-3.3.2+3+g6939d93~ui10/debian/source/options: 
--tar-ignore=build-bundle --tar-ignore=.git --tar-ignore=.gitignore 

 debian/rules clean 


dh clean


   dh_auto_clean


dh_auto_clean: warning: Please use the third-party "pybuild" build system 
instead of python-distutils 

  
dh_auto_clean: warning: This feature will be removed in compat 12.  


Can't exec "pyversions": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 124. 

  
dh_auto_clean: error: failed to run pyversions  


make: *** [debian/rules:9: clean] Error 255 


dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2 
--

"pyversions" is part of package "python2-minimal". Why python2-minimal if I 
build a Python3 project?

My "Build-Depends" in "debian/control" file is:

-
Build-Depends: debhelper (>= 8.0.0), build-essential, python3-dev, 
libmysqlclient-dev | default-libmysqlclient-dev,
   python3-pip, python3-venv, libxml2-dev, libxslt1-dev, 
python3-sphinx, python3-setuptools

X-Python3-Version: >= 3.7
--


Jürgen



0xA811F9F222306A1E.asc
Description: application/pgp-keys

Bug#962198: scilab-test: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Submitted patch in the VCS:
https://salsa.debian.org/science-team/scilab/-/merge_requests/4

Bug#962200: sarg: depends on dummy transitional package ttf-dejavu-core

[Olivier Tilloy]

Submitted patch in the VCS:
https://salsa.debian.org/debian/sarg/-/merge_requests/1

Bug#962191: [Pkg-javascript-devel] Bug#962191: Package 'nodejs' has no installation candidate

[Paolo Cavallini]

> Please share the full output of these two commands:
> 
>   apt update

 apt update
Hit:1 http://deb.debian.org/debian sid InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
3 packages can be upgraded. Run 'apt list --upgradable' to see them.

>   apt install nodejs

apt install nodejs
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package nodejs is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  nodejs-doc

E: Package 'nodejs' has no installation candidate

>> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> 
> Which out-of-tree kernel modules do you have installed?

it should be rtlwifi

>> Versions of packages nodejs depends on:
>> ii  libc6  2.30-8
>> ii  libnode64  10.20.1~dfsg-1
> 
> The nodejs library is installed and up-to-date.

as mentioned, I dowloaded the deb and dpkg -i

>> Versions of packages nodejs suggests:
>> ii  npm  6.14.5+ds-1
> 
> You have npm installed.  Please triple-check that it hasn't
> messed up your system - check e.g. files below /usr/local and
> environment variables...

I don't think so: I had the same problem before installing npm.
removing it does not change



signature.asc
Description: OpenPGP digital signature

Bug#961013: diamond-aligner: Diamond faill with the error: Assertion `index >= 0 && index < size()' failed.

[Andreas Tille]

On Wed, Jun 03, 2020 at 10:36:39PM +0530, Pranav Ballaney wrote:
> I've narrowed the issue down to one (or a few) sequences. Basically this
> error occurs whenever a query sequence is less than five nucleotides (and
> is independent of the length of sequences in the database file). Besides,
> it's not specific to the Debian package. I encountered the same error when
> I compiled from the upstream source, but it went away when I downloaded the
> compiled binary, so it's probably something to do with the way it is
> compiled.
> 
> I've reported this on the Github issue page here
>  along with the smallest
> dataset that can be used to reproduce this issue. Maybe now we wait for
> upstream to take a look?

Thanks a lot.  That sounds extremely helpful and promising.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#962191: [Pkg-javascript-devel] Bug#962191: Package 'nodejs' has no installation candidate

[Jonas Smedegaard]

Quoting Paolo Cavallini (2020-06-04 16:23:14)
> > Please share the full output of these two commands:
> > 
> >   apt update
> 
>  apt update
> Hit:1 http://deb.debian.org/debian sid InRelease
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> 3 packages can be upgraded. Run 'apt list --upgradable' to see them.

[details snipped]

Thanks - none of those revealed anything exciting.

Another idea: Which apt sources do your subscribe to?

Also, do you have any apt pinning configured?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#962191: [Pkg-javascript-devel] Bug#962191: Package 'nodejs' has no installation candidate

[Paolo Cavallini]

> Thanks - none of those revealed anything exciting.

exactly

> Another idea: Which apt sources do your subscribe to?
I tried two, see above

> Also, do you have any apt pinning configured?
no



signature.asc
Description: OpenPGP digital signature

Bug#962186: [pkg-uWSGI-devel] Bug#962186: Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye

[Jonas Smedegaard]

Quoting Alexandre Rossi (2020-06-04 16:08:26)
> The problem seems to be that the PHP plugin is compiled against PHP7.4
> and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in sid.
> 
> $ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php
> libphp7.so => /usr/lib/libphp7.so (0x7f4b8ca48000)
> $ ls -l /usr/lib/libphp7.so
> lrwxrwxrwx 1 root root 25 mai   11 19:41 /usr/lib/libphp7.so -> 
> /etc/alternatives/libphp7
> $ ls -l /etc/alternatives/libphp7
> lrwxrwxrwx 1 root root 21 mai   11 19:41 /etc/alternatives/libphp7 -> 
> /usr/lib/libphp7.4.so
> 
> The php plugin should explicitly be linked against /usr/lib/libphp7.4.so

It seems uwsgi gets its information for which library to link against
from /usr/bin/php-config (see /usr/src/uwsgi/plugins/php/uwsgiplugin.py).

And it seems php-dev and php4.7-dev ships php-config* tools that (I guess)
both provides that name using the dpkg alternatives systems.

Try check if those varying build tools offer different build hints,
and if they do then try comeup with a patch for plugins/php/uwsgiplugin.py
to use php-config only by default, overridable by an environment variable.

If those picking the right build tool doesn't solve this,
then try come up with some other patch taking some other more direct
environment variable into account (look at other plugins and try mimic
upstream style, so that hopefully your patch can be adopted upstream).

Then we can have uwsgi-plugin-php pass a suitable environment variable
resolved at build time from the package pulled in by its build-dependency
on virtual package "php-dev".

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#962213: package ftbfs on arm64 and armhf

[Matthias Klose]

Package: opencpn
Version: 5.0.0+dfsg-1
Severity: serious
Tags: sid bullseye patch

The package ftbfs on arm64 and armhf, trying to link with -ldrm. Apparently
libdrm-dev is an implicit b-d for x86 targets, but used explicitly.  Fixed by
b-d on libdrm-dev everywhere.

Bug#962191: [Pkg-javascript-devel] Bug#962191: Bug#962191: Package 'nodejs' has no installation candidate

[Paolo Cavallini]

> Also, check which packages Provide: nodejs on your system.

apt-cache showpkg nodejs

Provides:
10.20.1~dfsg-1+b1 -
10.20.1~dfsg-1 -
Reverse Provides:

Bug#962217: libgdf: autopkgtest needs update for new version of boost-defaults: deprecation warning on stderr

[Paul Gevers]

Source: libgdf
Version: 0.1.3-3
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:boost-defaults

[X-Debbugs-CC: debian...@lists.debian.org,
boost-defau...@packages.debian.org]

Dear maintainer(s),

With a recent upload of boost-defaults the autopkgtest of libgdf fails
in testing when that autopkgtest is run with the binary packages of
boost-defaults from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
boost-defaults from testing1.71.0.3
libgdf from testing0.1.3-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. If possible,
disable deprecation warnings as autopkgtest is not the place to test for
those or, if that's not possible, add the allow-stderr restriction such
that these warnings will be ignored.

Currently this regression is blocking the migration of boost-defaults to
testing [1]. Of course, boost-defaults shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in boost-defaults was intended and your package needs to update
to the new situation.

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=boost-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/libg/libgdf/5757118/log.gz

Copying data  OK
Copying events 
  reading non-equidistant samples (NEQS) ...   OK
  writing non-equidistant samples .
OK
Comparing files  OK
Removing test.gdf.tmp

autopkgtest [23:08:06]: test compile-and-run-tests: ---]
autopkgtest [23:08:07]: test compile-and-run-tests:  - - - - - - - - - -
results - - - - - - - - - -
compile-and-run-tests FAIL stderr: In file included from
/usr/include/boost/detail/endian.hpp:9,
autopkgtest [23:08:07]: test compile-and-run-tests:  - - - - - - - - - -
stderr - - - - - - - - - -
In file included from /usr/include/boost/detail/endian.hpp:9,
 from /usr/include/GDF/Types.h:24,
 from /usr/include/GDF/HeaderItem.h:22,
 from /usr/include/GDF/SignalHeader.h:22,
 from /usr/include/GDF/Channel.h:22,
 from /usr/include/GDF/RecordBuffer.h:22,
 from /usr/include/GDF/Writer.h:22,
 from testCreateGDF.cpp:19:
/usr/include/boost/predef/detail/endian_compat.h:11:161: note: #pragma
message: The use of BOOST_*_ENDIAN and BOOST_BYTE_ORDER is deprecated.
Please include  and use BOOST_ENDIAN_*_BYTE
instead
   11 | #pragma message("The use of BOOST_*_ENDIAN and BOOST_BYTE_ORDER
is deprecated. Please include  and use
BOOST_ENDIAN_*_BYTE instead")
  |

  ^
In file included from /usr/include/boost/detail/endian.hpp:9,
 from /usr/include/GDF/Types.h:24,
 from /usr/include/GDF/HeaderItem.h:22,
 from /usr/include/GDF/SignalHeader.h:22,
 from /usr/include/GDF/Channel.h:22,
 from /usr/include/GDF/Record.h:22,
 from /usr/include/GDF/Reader.h:22,
 from testDataTypes.cpp:21:
/usr/include/boost/predef/detail/endian_compat.h:11:161: note: #pragma
message: The use of BOOST_*_ENDIAN and BOOST_BYTE_ORDER is deprecated.
Please include  and use BOOST_ENDIAN_*_BYTE
instead
   11 | #pragma message("The use of BOOST_*_ENDIAN and BOOST_BYTE_ORDER
is deprecated. Please include  and use
BOOST_ENDIAN_*_BYTE instead")
  |

  ^
In file included from /usr/include/boost/detail/endian.hpp:9,
 from /usr/include/GDF/Types.h:24,
 from /usr/include/GDF/HeaderItem.h:22,
 from /usr/include/GDF/SignalHeader.h:22,
 from /usr/include/GDF/Channel.h:22,
 from /usr/include/GDF/RecordBuffer.h:22,
 from /usr/include/GDF/Writer.h:22,
 from testHeader3.cpp:22:
/usr/include/boost/predef/detail/endian_compat.h:11:161: note: #pragma
message: The use of BOOST_*_ENDIAN and BOOST_BYTE_ORDER is deprecated.
Please include  and use BOOST_ENDIAN_*_BYTE
instead
   11 | #pragma message("The use of BOOST_*_ENDIAN and BOOST_BYTE_ORDER
is deprecated. Please include  and use
BOOST_ENDIAN_*_BYTE instead")
  |

  ^
In file included from /usr/include/boost/detail/endian.hpp:9,
 from /usr/include/GDF/Types.h:24,
 from /usr/include/GDF/HeaderItem.h:22,
 from /usr/include/GDF/SignalHeader.h:22,
 from /usr/include/GDF/Channel.h:22,
 from /usr/include/GDF/RecordBuffer.h:22,
 from /usr/include/GDF/Writer.h:22,
 from testRWConsistency.cpp:22:

Bug#962185: inkscape: Document properties dialog is too small and not resizable

[Michel Le Bihan]

Package: inkscape
Version: 1.0-1
Severity: normal
Tags: upstream

The issue is already being tracked upstream:
https://gitlab.com/inkscape/inkscape/-/issues/1343



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

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

Versions of packages inkscape depends on:
ii  libatkmm-1.6-1v5   2.28.0-2
ii  libc6  2.30-8
ii  libcairo2  1.16.0-4
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.6-1
ii  libdbus-glib-1-2   0.110-5
ii  libdouble-conversion3  3.1.5-5
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.1-2
ii  libgc1c2   1:7.6.4-0.4
ii  libgcc-s1  10.1.0-3
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-4
ii  libgdl-3-5 3.34.0-1
ii  libglib2.0-0   2.64.3-1
ii  libglibmm-2.4-1v5  2.64.2-1
ii  libgomp1   10.1.0-3
ii  libgsl25   2.6+dfsg-2
ii  libgtk-3-0 3.24.20-1
ii  libgtkmm-3.0-1v5   3.24.2-1
ii  libgtkspell3-3-0   3.0.10-1
ii  libharfbuzz0b  2.6.4-1
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblcms2-2 2.9-4+b1
ii  libmagick++-6.q16-88:6.9.10.23+dfsg-2.1+b2
ii  libpango-1.0-0 1.44.7-4
ii  libpangocairo-1.0-01.44.7-4
ii  libpangoft2-1.0-0  1.44.7-4
ii  libpangomm-1.4-1v5 2.42.1-1
ii  libpng16-161.6.37-2
ii  libpoppler-glib8   0.71.0-6
ii  libpoppler82   0.71.0-6
ii  libpotrace01.16-2
ii  librevenge-0.0-0   0.0.4-6+b1
ii  libsigc++-2.0-0v5  2.10.2-1
ii  libsoup2.4-1   2.70.0-1
ii  libstdc++6 10.1.0-3
ii  libvisio-0.1-1 0.1.7-1
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.6.9-2+b1
ii  libxml22.9.10+dfsg-5
ii  libxslt1.1 1.1.34-4
ii  python33.8.2-3
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages inkscape recommends:
ii  aspell   0.60.8-1
ii  fig2dev  1:3.2.7b-4
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  libimage-magick-perl 8:6.9.10.23+dfsg-2.1
ii  libwmf-bin   0.2.8.4-17
ii  python3-lxml 4.5.0-1.1
ii  python3-numpy1:1.17.4-5
ii  python3-scour0.37-4

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials
pn  libsvg-perl   
pn  libxml-xql-perl   
ii  pstoedit  3.75-1
pn  python3-uniconvertor  
ii  ruby  1:2.7+1

-- no debconf information

Bug#960984: ITP: google-http-client-java -- Google HTTP Client Library for Java

[Olek Wojnar]

Hi Sudip,

On Thu, Jun 4, 2020 at 8:30 AM Sudip Mukherjee 
wrote:

> Sorry, I think I am missing something. To build http-java-client you
> should only need "api" and "contrib/http_util" from opencensus-java
> which (iiuc) does not need google-auth.
>

Hmm, I think you're right. Good catch and thanks!

Andreas, since you were working on opencensus, do you want to check if this
will work? I'm going to push an alternate packaging paradigm to Salsa
shortly for your reference.

-Olek

Bug#962202: socket-activate: name is too generic

[Dimitri John Ledkov]

Package: socket-activate
Version: 0.1-2
Severity: important

Dear Maintainer,

socket-activate is too generic name of the package and the binary it
ships. In Debian, we have or had other alternative implementations of
the same functionality. Shipped either stand alone, or as part of
other packages.

For exmaple systemd-socket-activate upstart-socket-bridge and others.

Using generic name socket-activate, which is a different
implementation to the other utilities and without argument
compatibility with them is ill-advised. Please consider renaming the
package and the binary to something that is more unique. For example,
python-socket-activate or some such.


Or maybe even call it heavy-standalone-socket-activate?! Socket
activate wrappers are typically used to reduce resources, such that at
idle it is desired for socket activation wrapper to use as little
resources as possible. That is the case with
systemd/upstart/launchd/xinitd/etc. Loading a full blown python3
interpreter does not seem appropriate per each socket and daemon. Have
you considered implementing this in something more optimized? for
example pypy, cpy, rust, C? Or at least allow socket-activate to
listen on many sockets and launch correspending daemon for each?


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

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

Bug#962209: fix ftbfs with glibc-2.31

[Matthias Klose]

Package: src:lwipv6
Version: 1.5a-5
Severity: important
Tags: sid bullseye

fix ftbfs with glibc-2.31

patch at
http://launchpadlibrarian.net/482821761/lwipv6_1.5a-5_1.5a-5ubuntu1.diff.gz

Bug#962160: buster-pu: package pagekite/0.5.9.3-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-06-03 at 20:50 -0700, Sunil Mohan Adapa wrote:
> This update proposes to fix bug #961984. Pagekite shipped
> certificates internally which are now expired (as of 2020-05-31). All
> users of Pagekite are unable to use the package securely as it can no
> longer make TLS connections to frontend servers. This update makes
> Pagekite use Debian certificate database
> instead of internal certificates (by shipping an additional
> configuration file).

+pagekite (0.5.9.3-2+deb10u1) UNRELEASED; urgency=medium
+
+  * Fix issue with expired internal certificates. Use
+Debian certificates instead of internal certificate. (Closes:
#961984)

The distribution there needs to be "buster".

With that changed, please go ahead.

Regards,

Adam

Bug#962170: gimp-plugin-registry: LQR (liquid rescale) does not work

[jEsuSdA 8)]

I tried to compile the sources from


https://github.com/carlobaldassi/gimp-lqr-plugin


And it works.

Please, consider to update.

Thanks a lot!!!

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Andreas Metzler]

On 2020-06-04 Adrian Bunk  wrote:
> Source: gnutls28
> Version: 3.6.13-2
> Severity: serious
> Tags: ftbfs

> https://buildd.debian.org/status/logs.php?pkg=gnutls28=3.6.13-3
> https://buildd.debian.org/status/logs.php?pkg=gnutls28=3.6.13-4

> ...
[...]

> The conova buildds are IPv6-only, see #962019 for a similar
> problem in perl.

Helo Adrian,

is there a way to declare a dependency on IPv4 for building?

Also the setup is strange, both netstat and ifconfig show IPv4:

DEBUG info about network setup starts ...
if test -x /sbin/ifconfig ; then /sbin/ifconfig ; else true ; fi
eth0: flags=4163  mtu 1500
inet6 2a02:16a8:dc41:100::240  prefixlen 64  scopeid 0x0
inet6 fe80::216:37ff:fed2:16f0  prefixlen 64  scopeid 0x20
ether 00:16:37:d2:16:f0  txqueuelen 1000  (Ethernet)
RX packets 108814178  bytes 157204088386 (146.4 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 13855486  bytes 11641875516 (10.8 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 4506091  bytes 20691973484 (19.2 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 4506091  bytes 20691973484 (19.2 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

netstat -tln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
tcp0  0 0.0.0.0:25  0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:56660.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:  0.0.0.0:*   LISTEN
tcp6   0  0 :::25   :::*LISTEN
tcp6   0  0 :::5666 :::*LISTEN
tcp6   0  0 :::4949 :::*LISTEN
tcp6   0  0 ::1:53  :::*LISTEN
tcp6   0  0 :::22   :::*LISTEN
... DEBUG info about network setup ends.
dh_auto_test -O--builddirectory=b4deb --verbose -- VERBOSE=1
cd b4deb && make -j4 check VERBOSE=1 VERBOSE=1

cu Andreas

PS: I wish the introduction of IPv6-only buildds a) had not happened
when I was trying to get a fix for a serious bug into testing (and
buster) and b) was not happening without announcement.

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#962221: xawtv: CVE-2020-13696

[Salvatore Bonaccorso]

Source: xawtv
Version: 3.106-1
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for xawtv.

CVE-2020-13696[0]:
| v4l-conf setuid-root program allows file existence tests and open(...,
| O_RDRW) on arbitrary files

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13696
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13696
[1] https://www.openwall.com/lists/oss-security/2020/06/04/6

Regards,
Salvatore

Bug#962223: selinux-policy-default: SELinux is preventing chronyd from access on the chronyc's unix_dgram_socket

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Severity: important

Description of problem:
SELinux is preventing chronyd from sendto access on the chronyc's 
unix_dgram_socket.
Chronyc cli is working slower in the Enforcing Selinux mode.
When you start chronyc cli it creates the socket there 
/var/run/chrony/chronyc.(chronyc_pid).sock.

-- Socket is here
root@vps:~# ls -la /var/run/chrony
total 0
drwxr-x---.  2 _chrony _chrony  80 Jun  4 18:17 .
drwxr-xr-x. 26 rootroot800 Jun  4 00:18 ..
srw-rw-rw-.  1 rootroot  0 Jun  4 18:17 chronyc.8825.sock
srwxr-xr-x.  1 _chrony _chrony   0 Jun  3 23:20 chronyd.sock
root@vps:~# ps aux | grep 8825
root  8825  0.0  0.1  29972  1704 pts/1S+   18:17   0:00 chronyc
root  8838  0.0  0.0  12780   944 pts/0S+   18:18   0:00 grep 
--color=auto 8825
root@vps:~#

-- Time of chronyc execution is slower by ~36 times in Enforcing mode
root@vps:~# setenforce 0
root@vps:~# time (chronyc sources &> /dev/null )

real0m0.012s
user0m0.004s
sys 0m0.000s
root@vps:~# setenforce 1
root@vps:~# time (chronyc sources &> /dev/null )

real0m7.022s
user0m0.000s
sys 0m0.008s
root@vps:~#

-- There are AVC deny messages in the audit.log
type=AVC msg=audit(1591284101.289:7635): avc:  denied  { sendto } for  pid=1836 
comm="chronyd" path="/run/chrony/chronyc.8865.sock" 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1591284102.293:7636): avc:  denied  { sendto } for  pid=1836 
comm="chronyd" path="/run/chrony/chronyc.8865.sock" 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1591284104.293:7637): avc:  denied  { sendto } for  pid=1836 
comm="chronyd" path="/run/chrony/chronyc.8865.sock" 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1591286013.714:7751): avc:  denied  { write } for  pid=1836 
comm="chronyd" name="chronyc.9034.sock" dev="tmpfs" ino=372397 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file permissive=0
type=AVC msg=audit(1591286014.718:7752): avc:  denied  { write } for  pid=1836 
comm="chronyd" name="chronyc.9034.sock" dev="tmpfs" ino=372397 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file permissive=0
type=AVC msg=audit(1591286016.718:7753): avc:  denied  { write } for  pid=1836 
comm="chronyd" name="chronyc.9034.sock" dev="tmpfs" ino=372397 
scontext=system_u:system_r:chronyd_t:s0 
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file permissive=0


-- Workaround is to add new fcontext and module
root@vps:/tmp# semanage fcontext -a -t chronyd_exec_t -f f "/usr/bin/chronyc"
root@vps:/tmp# cat chronyd2.te

module chronyd2 1.0;

require {
type chronyd_t;
type var_run_t;
type unconfined_t;
class unix_dgram_socket sendto;
class sock_file write;
}

#= chronyd_t ==
allow chronyd_t unconfined_t:unix_dgram_socket sendto;
allow chronyd_t var_run_t:sock_file write;




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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.6-3+b3
ii  libsemanage1 2.6-2
ii  libsepol12.6-2
ii  policycoreutils  2.6-3
ii  selinux-utils2.6-3+b3

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.6-2
ii  setools  4.0.1-6

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#948626: kicad: Closing pcbnew hangs main kicad process

[Paul "LeoNerd" Evans]

On Thu, 4 Jun 2020 16:45:45 +0100
"Paul \"LeoNerd\" Evans"  wrote:

> At this point now I'm a little stuck, because being unable to
> associate footprints with components, I can't actually make any new
> boards. With pcbnew crashing only on exit, at least I could edit and
> save just fine within one editing session, as it would only crash
> when I tried to exit anyway. At the moment I can't work on new
> boards, so this has become a bit more critical a failure. :(

Some further investigation and help from `nickoe` on the #kicad
channel on Freenode have lead me to find out that kicad was getting
confused with something still remaining from an older built-from-source
install still remaining in /usr/local. While I had removed most of the
binaries and libraries in there, there was apparently something still
left behind. A more thorough removal of various pieces there has now
fixed all my hanging issues.

I think this bug can be closed now.

Thanks all :)

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/


pgpFb_S9NMkSq.pgp
Description: OpenPGP digital signature

Bug#962227: buster-pu: package libapache-mod-jk/1:1.2.46-1

[Markus Koschany]

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

Dear release team,

I would like to fix Debian bug #928813 in Buster. Stretch is not
affected. Due to wrong file naming the configuration file for
libapache-mod-jk was not installed into the mods-enabled directory of
Apache 2 when a2enmod was used. Please find attached the debdiff.

Regards,

Markus
diff -Nru libapache-mod-jk-1.2.46/debian/changelog 
libapache-mod-jk-1.2.46/debian/changelog
--- libapache-mod-jk-1.2.46/debian/changelog2018-10-14 12:26:05.0 
+0200
+++ libapache-mod-jk-1.2.46/debian/changelog2020-06-04 21:18:07.0 
+0200
@@ -1,3 +1,10 @@
+libapache-mod-jk (1:1.2.46-1+deb10u1) buster; urgency=medium
+
+  * Rename httpd-jk.conf to jk.conf to restore compatibility with Debian's 
Apache
+helpers a2enmod and a2dismod. (Closes: #928813)
+
+ -- Markus Koschany   Thu, 04 Jun 2020 21:18:07 +0200
+
 libapache-mod-jk (1:1.2.46-1) unstable; urgency=medium
 
   * New upstream version 1.2.46.
diff -Nru libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.install 
libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.install
--- libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.install2018-10-14 
12:26:05.0 +0200
+++ libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.install2020-06-04 
21:18:07.0 +0200
@@ -1,4 +1,4 @@
-conf/httpd-jk.conf   /etc/apache2/mods-available/
+conf/jk.conf/etc/apache2/mods-available/
 debian/jk.load  /etc/apache2/mods-available/
 debian/workers.properties   /etc/libapache2-mod-jk/
 native/apache-2.0/mod_jk.so /usr/lib/apache2/modules/
diff -Nru libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.links 
libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.links
--- libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.links  2018-10-14 
12:26:05.0 +0200
+++ libapache-mod-jk-1.2.46/debian/libapache2-mod-jk.links  2020-06-04 
21:18:07.0 +0200
@@ -1 +1 @@
-/etc/apache2/mods-available/httpd-jk.conf /etc/libapache2-mod-jk/httpd-jk.conf
+/etc/apache2/mods-available/jk.conf /etc/libapache2-mod-jk/httpd-jk.conf
diff -Nru libapache-mod-jk-1.2.46/debian/rules 
libapache-mod-jk-1.2.46/debian/rules
--- libapache-mod-jk-1.2.46/debian/rules2018-10-14 12:26:05.0 
+0200
+++ libapache-mod-jk-1.2.46/debian/rules2020-06-04 21:18:07.0 
+0200
@@ -24,5 +24,9 @@
 # No check target
 override_dh_auto_test:
 
+override_dh_install:
+   mv $(CURDIR)/conf/httpd-jk.conf $(CURDIR)/conf/jk.conf
+   dh_install
+
 get-orig-source:
uscan --verbose --download-current-version --force-download

Bug#962229: orthanc-postgresql FTBFS with boost1.71

[Adrian Bunk]

Source: orthanc-postgresql
Version: 3.2-1
Severity: serious
Tags: ftbfs bullseye sid
Control: block 961995 by -1

https://buildd.debian.org/status/package.php?p=orthanc-postgresql=sid

...
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake 
(found version "1.71.0")
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:182 
(boost_find_component):
  boost_find_component Macro invoked with incorrect arguments for macro
  named: boost_find_component
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindBoost.cmake:443 (find_package)
  
/<>/Build/Orthanc-1.5.4/Resources/CMake/BoostConfiguration.cmake:15
 (find_package)
  
/<>/Build/Orthanc-1.5.4/Resources/CMake/OrthancFrameworkConfiguration.cmake:417
 (include)
  /<>/Resources/CMake/DatabasesFrameworkConfiguration.cmake:62 
(include)
  /<>/Resources/CMake/DatabasesPluginConfiguration.cmake:21 
(include)
  CMakeLists.txt:22 (include)
...



orthanc-postgresql builds an own copy of src:orthanc,
and this copy does not have #953884 fixed.

Bug#962228: grub-pc: Backport LUKS2 support

[Petr Vorel]

Package: grub-pc
Version: 2.04-7
Severity: wishlist

Dear Maintainer,

could you please backport LUKS2 support from upstream?  #55093 [1], Add LUKS2
support was implemented in 365e0cc3e ("disk: Implement support for LUKS2") [2].

It'd be great to have the support backported at least in experimental (but
preferably in unstable, so it could eventually get into d-i and workaround [3]
wouldn't have to be used).

Kind regards,
Petr

[1] https://savannah.gnu.org/bugs/?55093
[2] 
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755
[3] https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

Bug#937769: python-funcsigs build-dependencies now unsatisfiable in testing, removal of pypy-pytest

[peter green]

A few days ago Sandro Tosi uploaded the python-unittest2 and python-funcsigs source 
packages. It seems that both of these were effectively "team uploads" though 
they were not marked as such. The python-unittest2 upload dropped python 2 support while 
the python-funcsigs package dropped python 2 and pypy support.

python-unittest2, python-traceback2 and python-linecache2 have now migrated to 
testing, the result of this is that the build-dependencies of python-traceback2 
and python-linecache2 are now satisfiable in testing, but those of 
python-funcsigs are now broken in testing.

python-funcsigs is unable to migrate to testing because pypy-pytest depends on 
pypy-funcsigs .

I have just filed a rc bug on vanguards ( 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962232 ), once that is dealt 
with it should then be possible to drop pypy-pytest and related module packages 
( pypy-atomicwrites, pypy-pluggy, pypy-py pypy-setuptools-scm pypy-wcwidth 
pypy-importlib-metadata and pypy-zipp )

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Roland Plüss]

On 5/31/20 9:19 AM, Tobias Frost wrote:
> If you want to follow this route, your next step would be now to contact
> the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking
> to package the version you need, explaining the situation and maybe (==
> if you want) tell them that you would commit helping to offset the extra
> work caused by maintaining the development snapshot.
>
> * dak spits out those r-deps:
> ace: libfox-1.6-dev
> gogglesmm: libfox-1.6-dev
> libgwenhywfar: libfox-1.6-dev
> pcsc-cyberjack: libfox-1.6-dev
> sumo: libfox-1.6-dev
> xfe: libfox-1.6-dev (>= 1.6.45)
>
I tried doing this with reportbug but I failed. It asks me first for the
package where the bug is found. I entered as you suggested "src:fox1.6".
Reportbug complains "src:fox1.6 is not a valid package name.". What am I
doing wrong?

-- 
Mit freundlichen Grüssen
Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch



signature.asc
Description: OpenPGP digital signature

Bug#961042: Wrong package?

[Anton Gladky]

Hi Helmut,

I do not quite understand how #961042 can be fixed in yade.
Could you please check, whether the bug is properly assigned?

Thanks

Anton

Bug#962237: buster-pu: package perl/5.28.1-6+deb10u1

[Dominic Hargreaves]

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

As per #962234 for stretch and my remarks on #961443 I'd like to
uploaded a targeted fix for these no-dsa security issues:

https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod

We can come back to #961443 when we're happy that the upgrade issues
have been solved.

Cheers
Dominic
diff --git a/cpan/IO-Socket-IP/t/01local-client-v4.t 
b/cpan/IO-Socket-IP/t/01local-client-v4.t
index 7ab7156993..f6aeac4c3b 100644
--- a/cpan/IO-Socket-IP/t/01local-client-v4.t
+++ b/cpan/IO-Socket-IP/t/01local-client-v4.t
@@ -8,7 +8,7 @@ use Test::More;
 use IO::Socket::IP;
 
 use IO::Socket::INET;
-use Socket qw( inet_aton inet_ntoa pack_sockaddr_in unpack_sockaddr_in );
+use Socket qw( inet_aton inet_ntoa pack_sockaddr_in unpack_sockaddr_in 
AI_NUMERICHOST );
 
 # Some odd locations like BSD jails might not like INADDR_LOOPBACK. We'll
 # establish a baseline first to test against
@@ -29,12 +29,14 @@ foreach my $socktype (qw( SOCK_STREAM SOCK_DGRAM )) {
   LocalHost => "127.0.0.1",
   Type  => Socket->$socktype,
   Proto => ( $socktype eq "SOCK_STREAM" ? "tcp" : "udp" ), # Because 
IO::Socket::INET is stupid and always presumes tcp
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot listen on PF_INET - $@";
 
my $socket = IO::Socket::IP->new(
   PeerHost=> "127.0.0.1",
   PeerService => $testserver->sockport,
   Type=> Socket->$socktype,
+  GetAddrInfoFlags => AI_NUMERICHOST,
);
 
ok( defined $socket, "IO::Socket::IP->new constructs a $socktype socket" ) 
or
diff --git a/cpan/IO-Socket-IP/t/02local-server-v4.t 
b/cpan/IO-Socket-IP/t/02local-server-v4.t
index c0d349f573..fb711f08bd 100644
--- a/cpan/IO-Socket-IP/t/02local-server-v4.t
+++ b/cpan/IO-Socket-IP/t/02local-server-v4.t
@@ -8,7 +8,7 @@ use Test::More;
 use IO::Socket::IP;
 
 use IO::Socket::INET;
-use Socket qw( inet_aton inet_ntoa pack_sockaddr_in unpack_sockaddr_in );
+use Socket qw( inet_aton inet_ntoa pack_sockaddr_in unpack_sockaddr_in 
AI_NUMERICHOST );
 
 # Some odd locations like BSD jails might not like INADDR_LOOPBACK. We'll
 # establish a baseline first to test against
@@ -29,6 +29,7 @@ foreach my $socktype (qw( SOCK_STREAM SOCK_DGRAM )) {
   LocalHost => "127.0.0.1",
   LocalPort => "0",
   Type  => Socket->$socktype,
+  GetAddrInfoFlags => AI_NUMERICHOST,
);
 
ok( defined $testserver, "IO::Socket::IP->new constructs a $socktype 
socket" ) or
diff --git a/cpan/IO-Socket-IP/t/03local-cross-v4.t 
b/cpan/IO-Socket-IP/t/03local-cross-v4.t
index 8cac72a95b..3e8174ee08 100644
--- a/cpan/IO-Socket-IP/t/03local-cross-v4.t
+++ b/cpan/IO-Socket-IP/t/03local-cross-v4.t
@@ -6,6 +6,7 @@ use warnings;
 use Test::More;
 
 use IO::Socket::IP;
+use Socket qw(AI_NUMERICHOST);
 
 foreach my $socktype (qw( SOCK_STREAM SOCK_DGRAM )) {
my $testserver = IO::Socket::IP->new(
@@ -13,12 +14,14 @@ foreach my $socktype (qw( SOCK_STREAM SOCK_DGRAM )) {
   LocalHost => "127.0.0.1",
   LocalPort => "0",
   Type  => Socket->$socktype,
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot listen on PF_INET - $@";
 
my $socket = IO::Socket::IP->new(
   PeerHost=> "127.0.0.1",
   PeerService => $testserver->sockport,
   Type=> Socket->$socktype,
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot connect on PF_INET - $@";
 
my $testclient = ( $socktype eq "SOCK_STREAM" ) ? 
diff --git a/cpan/IO-Socket-IP/t/11sockopts.t b/cpan/IO-Socket-IP/t/11sockopts.t
index 5b850924dd..28daada89f 100644
--- a/cpan/IO-Socket-IP/t/11sockopts.t
+++ b/cpan/IO-Socket-IP/t/11sockopts.t
@@ -8,7 +8,7 @@ use Test::More;
 use IO::Socket::IP;
 
 use Errno qw( EACCES );
-use Socket qw( SOL_SOCKET SO_REUSEADDR SO_REUSEPORT SO_BROADCAST );
+use Socket qw( SOL_SOCKET SO_REUSEADDR SO_REUSEPORT SO_BROADCAST 
AI_NUMERICHOST);
 
 TODO: {
local $TODO = "SO_REUSEADDR doesn't appear to work on cygwin smokers" if 
$^O eq "cygwin";
@@ -21,6 +21,7 @@ TODO: {
   Type  => SOCK_STREAM,
   Listen=> 1,
   ReuseAddr => 1,
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot socket() - $@";
 
ok( $sock->getsockopt( SOL_SOCKET, SO_REUSEADDR ), 'SO_REUSEADDR set' );
@@ -32,6 +33,7 @@ TODO: {
   Sockopts  => [
  [ SOL_SOCKET, SO_REUSEADDR ],
   ],
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot socket() - $@";
 
ok( $sock->getsockopt( SOL_SOCKET, SO_REUSEADDR ), 'SO_REUSEADDR set via 
Sockopts' );
@@ -50,6 +52,7 @@ SKIP: {
   Type  => SOCK_STREAM,
   Listen=> 1,
   ReusePort => 1,
+  GetAddrInfoFlags => AI_NUMERICHOST,
) or die "Cannot socket() - $@";
 
ok( $sock->getsockopt( SOL_SOCKET, SO_REUSEPORT ), 'SO_REUSEPORT set' );
@@ -62,6 +65,7 @@ SKIP: {
   LocalHost => "127.0.0.1",
   Type  => SOCK_DGRAM,
   Broadcast 

Bug#962194: lintian-brush: autopkgtest failure on s390x

[Jelmer Vernooij]

On Thu, Jun 04, 2020 at 02:41:04PM +0200, Gianfranco Costamagna wrote:
> Hello, since version 0.68 we are hitting autopkgtest failures on Ubuntu s390x
> (but I presume this might be an endianess issue unrelated to Ubuntu, but an 
> issue on Debian too)
> 
> look e.g.:
> 
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lintian-brush/20200526_071151_45b70@/log.gz
> 
> or
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lintian-brush/20200602_160733_92e77@/log.gz
> 
> 
> autopkgtest [16:06:43]: test tool-testsuite: [---
> failed to open trace file: [Errno 13] Permission denied: 
> '/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
> .../usr/lib/python3/dist-packages/debian/changelog.py:483: UserWarning: 
> Unexpected line while looking for first heading: THIS IS NOT A PARSEABLE LINE
>   warnings.warn(message)
> /usr/lib/python3/dist-packages/debian/changelog.py:483: 
> UserWarning: Unexpected line while looking for first heading: lalalalala
>   warnings.warn(message)
> /usr/lib/python3/dist-packages/debian/changelog.py:483: UserWarning: Found 
> eof where expected first heading
>   warnings.warn(message)
> ./tmp/autopkgtest.aoDwvO/build.6pK/src/lintian_brush/_deb822.py:115: 
> UserWarning: cannot parse package relationship "${misc:Depends}", returning 
> it raw
>   warnings.warn(
> ...ss...EE.x..sed:
>  can't read debian/rules: No such file or directory
> sed: can't read debian/rules: No such file or directory
> .sed: can't read debian/rules: No such file or directory
> sed: can't read debian/rules: No such file or directory
> ./tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:176:
>  UserWarning: A common license shortname (Apache-2.0) is used, but license 
> text not recognized.
>   warn(
> ../tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:160: 
> UserWarning: Unable to get canonical name for 'BSD-3-clause'
>   warn('Unable to get canonical name for %r' % license_id)
> /tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:190: 
> UserWarning: Found full license text for BSD-3-clause, but unknown synopsis 
> BSD-3-clause (BSD-3-clause)
>   warn('Found full license text for %s, but unknown synopsis %s (%s)'
> .../usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: 
> UserWarning: cannot parse package relationship "libf2fs5 (= 
> ${binary:Version})", returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning: 
> cannot parse package relationship "libf2fs-format4 (= ${binary:Version})", 
> returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning: 
> cannot parse package relationship "${shlibs:Depends}", returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning: 
> cannot parse package relationship "${misc:Depends}", returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning: 
> cannot parse package relationship "f2fs-tools (= ${binary:Version})", 
> returning it raw
>   warnings.warn(
> /usr/lib/python3/dist-packages/debian/changelog.py:483: 
> UserWarning: Unexpected line while looking for start of change data:  * 
> Initial Release.
>   warnings.warn(message)
> .../usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115:
>  UserWarning: cannot parse package relationship "${misc:Depends}", returning 
> it raw
>   warnings.warn(
> ..Tree has non-standard patches directory debian/patches-applied.
> ..dpkg-architecture: warning: cannot determine CC system 
> type, falling back to default (native compilation)
> Use of uninitialized value $step in string ne at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/perl_build.pm line 24.
> Use of uninitialized value $step in string ne at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem.pm line 424.
> ..dpkg-architecture: warning: cannot determine CC system type, falling back 
> to default (native compilation)
> Use of uninitialized value $step in string ne at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/perl_build.pm line 24.
> Use of uninitialized value $step in string ne at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem.pm line 424.
> ../tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/package-uses-deprecated-debhelper-compat-version.py:80:
>  UserWarning: Not upgrading beyond debhelper 10, since the package disables 
> autoreconf but its configure does not 

Bug#941568: [Python-modules-team] Question about related package to python3-dill

[Sandro Tosi]

yeah if you could transfer the repo to DPMT that'd be great: i'm
already using multiprocess in one of my project and i'll take for the
package as well. any technical reason behind the halt of the packaging
other than lack of time? thanks!

On Thu, Jun 4, 2020 at 4:35 PM Andreas Tille  wrote:
>
> Control: retitle -1 RFP: multiprocess -- better multiprocessing and 
> multithreading in Python
>
> Sorry, this package has lowered in my list of needs.  Feel free to take
> over.  If you want me to transfer the existing repository to DPMT I'd
> happily do so.
>
> Kind regards
>
>Andreas.
>
> On Thu, Jun 04, 2020 at 04:02:23PM -0400, Sandro Tosi wrote:
> > there's been some effort at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941568 , Andreas
> > what's the status of multiprocess? i dont see it in NEW nor the archive
> >
> >
> > On Thu, Jun 4, 2020 at 2:48 PM Marco Costa  wrote:
> > >
> > > Hi,
> > >
> > > As "dill" is a part of the pathos project, I would like to ask why the 
> > > package "multiprocess" is not available also?
> > >
> > > Thank you in advance.
> > >
> > > Marco
> > > ___
> > > Python-modules-team mailing list
> > > python-modules-t...@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
> >
> >
> >
> > --
> > Sandro "morph" Tosi
> > My website: http://sandrotosi.me/
> > Me at Debian: http://wiki.debian.org/SandroTosi
> > Twitter: https://twitter.com/sandrotosi
> >
> > --
> > Sandro "morph" Tosi
> > My website: http://sandrotosi.me/
> > Me at Debian: http://wiki.debian.org/SandroTosi
> > Twitter: https://twitter.com/sandrotosi
> >
>
> --
> http://fam-tille.de



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

Bug#962235: linux-image-4.19.0-9-amd64: USB3 disk aren't detected when connected to a USB3 hub

[Amaury ABRIAL]

Package: src:linux
Version: 4.19.118-2
Severity: normal

Dear Maintainer,

I encounter an issue with USB3 hub and USB3 key and disk

* What led up to the situation?
The problem occur since i udgraded my computer from debian 9 to debian 10
(from librazik2 to librazik3 in fact, but i don't think it's relevant
irrelevant).

* What exactly did you do (or not do) that was effective (or ineffective)?
   - I tried to start my computer with diffferent kernel :
 - 4.19.0-9 => problem is present.
 - 5.4.0-0 => problem is present.
 - 4.9.0-9 => no problem.

   - I tried to identify what configuration produce the bug:
 - Connecting a USB3 device in the USB3 hub => the USB3 device is not
detected, it doesn't appear when doing "lsusb"
 - Connecting a USB3 device in the USB3 hub and then connecting the hub to
the computer => work normally
 - Connecting a USB3 device directly in USB3 port => the device is detected
and preivously USB3 device connected to the hub are detected a same time
 - Connecting a USB2 device directly in USB3 port => the device is
detected, but it doesn't trigger detection of USB3 device connected to the hub
 - I also did some other test with usb2 device and usb2 computer port, it
works until some point i didn't yet identified.



-- Package-specific info:
** Version:
Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2 (2020-04-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/HP--Amaury--vg0-root 
ro threadirqs quiet

** Not tainted

** Kernel log:
[6.472246] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[6.480158] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input14
[6.480754] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[6.480936] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input16
[6.511144] intel_rapl: Found RAPL domain package
[6.511147] intel_rapl: Found RAPL domain core
[6.511148] intel_rapl: Found RAPL domain uncore
[6.511156] intel_rapl: RAPL package 0 domain package locked by BIOS
[6.649762] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: 
(null)
[6.720060] audit: type=1400 audit(1591291208.238:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=525 comm="apparmor_parser"
[6.726098] audit: type=1400 audit(1591291208.242:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=527 
comm="apparmor_parser"
[6.726105] audit: type=1400 audit(1591291208.242:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=527 
comm="apparmor_parser"
[6.726109] audit: type=1400 audit(1591291208.242:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=527 
comm="apparmor_parser"
[6.728496] audit: type=1400 audit(1591291208.246:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=524 
comm="apparmor_parser"
[6.728502] audit: type=1400 audit(1591291208.246:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" 
pid=524 comm="apparmor_parser"
[6.732029] audit: type=1400 audit(1591291208.250:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=531 comm="apparmor_parser"
[6.734048] audit: type=1400 audit(1591291208.250:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=529 
comm="apparmor_parser"
[6.734054] audit: type=1400 audit(1591291208.250:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=529 comm="apparmor_parser"
[6.741411] audit: type=1400 audit(1591291208.258:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=533 comm="apparmor_parser"
[7.294963] random: crng init done
[7.294966] random: 3 urandom warning(s) missed due to ratelimiting
[7.738051] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[7.742363] r8169 :08:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8105e-1.fw
[7.742916] Generic PHY r8169-800:00: attached PHY driver [Generic PHY] 
(mii_bus:phy_addr=r8169-800:00, irq=IGNORE)
[8.021213] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[8.027980] IPv6: ADDRCONF(NETDEV_UP): wlo1: link is not ready
[8.028068] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading 
firmware file 'rt3290.bin'
[8.031784] rt2800pci :07:00.0: firmware: direct-loading firmware 
rt3290.bin
[8.031793] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware 

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Julien Cristau]

On Thu, Jun 04, 2020 at 07:32:13PM +0200, Andreas Metzler wrote:
> On 2020-06-04 Adrian Bunk  wrote:
> > Source: gnutls28
> > Version: 3.6.13-2
> > Severity: serious
> > Tags: ftbfs
> 
> > https://buildd.debian.org/status/logs.php?pkg=gnutls28=3.6.13-3
> > https://buildd.debian.org/status/logs.php?pkg=gnutls28=3.6.13-4
> 
> > ...
> [...]
> 
> > The conova buildds are IPv6-only, see #962019 for a similar
> > problem in perl.
> 
> Helo Adrian,
> 
> is there a way to declare a dependency on IPv4 for building?
> 
> Also the setup is strange, both netstat and ifconfig show IPv4:
> 
eth0 has no ipv4, that's all.  Why is that strange?

Cheers,
Julien

Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin

[Ricardo Ribalda Delgado]

Hi Jonas

Thanks for the heads up.

I have just updated my salsa to 2.2.0
https://salsa.debian.org/ribalda-guest/ugrep/-/tree/debian In case
that you want to give it a try.

When zumbi has some time it will be updated.

Best regards

On Thu, Jun 4, 2020 at 12:04 PM Jonas Smedegaard  wrote:
>
> Quoting Ricardo Ribalda Delgado (2020-05-19 18:13:16)
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ricardo Ribalda Delgado 
> >
> > * Package name: ugrep
> >   Version : 2.1.1
> >   Upstream Author : Robert van Engelen 
> > * URL : https://github.com/Genivia/ugrep/wiki
> > * License : BSD-3-Clause
> >   Programming Lang: C++
> >   Description : Universal grep: ultra fast searcher of file systems, 
> > text and binary files, source code, archives, compressed files, documents, 
> > and more.
> >
> >
> > NEW ultra fast grep with interactive query UI: search file systems,
> > text, source code, binary files, archives (cpio/tar/pax/zip), compressed
> > files (zip/gz/Z/bz2/lzma/xz), documents, and more.
> >
> > It is also very useful when  grepping on codebase with unicode files.
> >
> > I plan to send with a sponsor (zumbi). Hopefuly I will be able to
> > upload packages on my own ;).
>
> Thanks a lot for your work on this package, Ricardo!
>
> Zumbi just now told me that the package is in NEW queue - great! That's
> not the newest upstream release, however: Please consider upgrading to
> release 2.1.4 or newer, for its improved handling of large collections
> of patterns with named capture, as discussed at
> https://github.com/Genivia/ugrep/issues/35
>
> Kind regards,
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



-- 
Ricardo Ribalda

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Julien Cristau]

Control: tag -1 moreinfo

On Thu, Jun 04, 2020 at 07:59:22PM +0300, Adrian Bunk wrote:
> FAIL: dtls_hello_random_value
> =
> 
> testing: default
> client:156: client: Handshake failed: Resource temporarily unavailable, try 
> again.
> server:271: server: Handshake has failed: The TLS connection was non-properly 
> terminated.
> 
> FAIL dtls_hello_random_value (exit status: 1)
> 
This particular test seems to use a AF_UNIX socketpair, I'm not sure
how it would fail due to network setup?

Cheers,
Julien

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Adrian Bunk]

On Thu, Jun 04, 2020 at 07:32:13PM +0200, Andreas Metzler wrote:
> On 2020-06-04 Adrian Bunk  wrote:
> > Source: gnutls28
> > Version: 3.6.13-2
> > Severity: serious
> > Tags: ftbfs
> 
> > https://buildd.debian.org/status/logs.php?pkg=gnutls28=3.6.13-3
> > https://buildd.debian.org/status/logs.php?pkg=gnutls28=3.6.13-4
> 
> > ...
> [...]
> 
> > The conova buildds are IPv6-only, see #962019 for a similar
> > problem in perl.
> 
> Helo Adrian,
> 
> is there a way to declare a dependency on IPv4 for building?

No.

> Also the setup is strange, both netstat and ifconfig show IPv4:
> 
> DEBUG info about network setup starts ...
> if test -x /sbin/ifconfig ; then /sbin/ifconfig ; else true ; fi
> eth0: flags=4163  mtu 1500
> inet6 2a02:16a8:dc41:100::240  prefixlen 64  scopeid 0x0
> inet6 fe80::216:37ff:fed2:16f0  prefixlen 64  scopeid 0x20
> ether 00:16:37:d2:16:f0  txqueuelen 1000  (Ethernet)
> RX packets 108814178  bytes 157204088386 (146.4 GiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 13855486  bytes 11641875516 (10.8 GiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1000  (Local Loopback)
> RX packets 4506091  bytes 20691973484 (19.2 GiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 4506091  bytes 20691973484 (19.2 GiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>...

The usage of AI_ADDRCONFIG in src/serv.c:listen_socket() looks similar
to the problem described in the perl bug.

> cu Andreas
>...

cu
Adrian

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Tobias Frost]

On Thu, Jun 04, 2020 at 06:33:10PM +0200, Roland Plüss wrote:
> 
> On 5/31/20 9:19 AM, Tobias Frost wrote:
> > If you want to follow this route, your next step would be now to contact
> > the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking
> > to package the version you need, explaining the situation and maybe (==
> > if you want) tell them that you would commit helping to offset the extra
> > work caused by maintaining the development snapshot.
> >
> > * dak spits out those r-deps:
> > ace: libfox-1.6-dev
> > gogglesmm: libfox-1.6-dev
> > libgwenhywfar: libfox-1.6-dev
> > pcsc-cyberjack: libfox-1.6-dev
> > sumo: libfox-1.6-dev
> > xfe: libfox-1.6-dev (>= 1.6.45)
> >
> I tried doing this with reportbug but I failed. It asks me first for the
> package where the bug is found. I entered as you suggested "src:fox1.6".
> Reportbug complains "src:fox1.6 is not a valid package name.". What am I
> doing wrong?

Ah, sorry, didn't meant to confuse you. src:$package just means "against the 
source package", so you would do a "reportbug --src fox1.6" or a plain
"reportbug fox1.6" works too.
 
> -- 
> Mit freundlichen Grüssen
> Plüss Roland
> 
> Game Development and Game Engine Technologies https://dragondreams.ch
> 

Bug#962223: selinux-policy-default: SELinux is preventing chronyd from access on the chronyc's unix_dgram_socket

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Followup-For: Bug #962223

I've found release, where policy has fixed: 2.20180701
here it is the commit 
https://github.com/SELinuxProject/refpolicy/commit/3ab07a0e1ee01ee62a6102acdd3957e6894bf795


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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.6-3+b3
ii  libsemanage1 2.6-2
ii  libsepol12.6-2
ii  policycoreutils  2.6-3
ii  selinux-utils2.6-3+b3

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.6-2
ii  setools  4.0.1-6

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#962215: libfox-1.6-0: Is it possible to package fox-1.7.67 or higher?

[Fabian Wolff]

Hi Roland,

I totally understand your need for a more recent version of the FOX
toolkit. There has been very little upstream activity on the 1.6
("stable") branch in the last few years, and honestly, I don't know
why the 1.7 branch isn't yet considered stable or if/when this will
ever happen.

However, there are a few packages in Debian that depend on the 1.6
branch of FOX, and, without having checked this myself, I would assume
that they won't just work with 1.7 (i.e., someone would have to patch
them). Additionally, some Debian users are probably using the FOX 1.6
development package for their own projects, so I can't just drop 1.6
and move to 1.7.

Instead, one would have to create a new package for the 1.7 branch and
maintain that in parallel to the existing 1.6 package (as far as I can
see, this won't lead to any package name clashes).

The fact that 1.7 is still considered the "development" branch is not
such a big deal in my view, because there are regular releases and the
1.7 branch has existed for quite a long time now. The much larger
practical problem is that I currently don't have the time to package
and maintain the 1.7 branch myself.


I have reassigned your bug report as a RFP (Request For Package) to
the "wnpp" package, because it really doesn't have much to do with the
fox1.6 source package, which I maintain. This way, other people can
see that FOX 1.7 has been requested as a Debian package, and if you're
lucky, someone will come along and package/maintain it.

Even if that happens, it can take a while, though, so your best bet
right now would probably be to package and maintain FOX 1.7 yourself.
I haven't personally attempted this, but I would suspect that the
package would look rather similar to the fox1.6 package, so you could
use this as a basis.


I hope this helps, sorry for not being able to solve your problem
right away!

Best regards,
Fabian

Bug#961841: fontforge FTBFS on 64bit big endian: test failures

[Olivier Tilloy]

This upstream commit fixes the test failures on s390x:
https://github.com/oSoMoN/fontforge/commit/fde85b13382595cb3ab889e38570b4944edad808
.

I cherry-picked it and applied it to 1:20190801~dfsg-5 (only the last hunk
doesn't apply cleanly, it can be removed), and the build succeeded
on amd64, arm64, armhf, ppc64el and s390x (against Ubuntu groovy-proposed).

Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin

[Jonas Smedegaard]

Quoting Ricardo Ribalda Delgado (2020-06-04 19:53:10)
> I have just updated my salsa to 2.2.0
> https://salsa.debian.org/ribalda-guest/ugrep/-/tree/debian In case
> that you want to give it a try.

Great!

A few remarks about the packaging:

The autopkgtest failed:

upstream-test-suite  FAIL stderr: configure.ac:31: installing './ar-lib'

Seems you need to add the allow-stderr restriction - more info here: 
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

Related to autopkgtest I (just earlier today in fact) noticed the 
"build-needed" restriction which seems perfectly suitable for the kind 
of test you've setup.

The package short description is wrongly used as a first line of the 
long description - check Debian Policy § 5.6.13 for the details on that.

I also would have expected libreflex to be built as a shared library for 
reuse by other future packages besides ugrep - but perhaps you've 
discussed that with Zumbi already and there is some sensible reason for 
embedding the library with ugrep.

Are you aware that you can use wildcards with lintian overrides? Seems 
your 18 almost identical overrides can be shrunk to just one line.  And 
while at it, please consider adding a comment describing why those 
warnings are overridden (it is easier to agree or disagree with your 
reasoning without first reading your mind :-) ).

You've listed only copyright and licensing for main upstream author and 
yourself - but there are also (at least) some autotools-originated files 
licensed as Expat, FSFAP, FSFUL, FSFULLR, GPL-2+, and GPL-3+.  Possibly 
you are already aware and consider those irrelevant to track in 
debian/copyright, but mentioning in case the omission wasn't deliberate, 
as I suspect ftpmaster might disagree with doing that.  If interested, 
then I can guide you in using licensecheck to check that (and keep track 
of changes for later updates).

Thanks a lot for packaging ugrep.  I hadn't heard about it before I saw 
your ITP, and it looks like an amazing tool, that I will sure spend some 
time getting familiar with now.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#961512: reportbug-gtk: Keyboard navigation broken in some situations

[Nis Martensen]

On 25 May 2020 Patrick ZAJDA wrote:
> When launching the Reportbug GTK, it is not possible to use keyboard
> navigation.
> Nothing happens when I press Tab or Shift+Tab.

Thank you for the report. After receiving your report I have tried to
navigate the GTK UI using only the keyboard, and can confirm that the
experience could be better. However, the reportbug maintenance team are
no GTK experts, so fixing this might not happen soon. Help is welcome.

If you are unable to access any button, try holding down the Alt key.
This should highlight a letter in each button that you can press.

> Another annoying keyboard navigation related issue is when I press "Back", 
> only
> Back/Next/Cancel button can have the focus using keyboard, even when I try to
> use mouse click I cannot modify fields values.

The Back button is not there by design, but by mistake. It is a
well-known bug that has been reported many times and should be fixed in
the next version.

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[David Kalnischkies]

On Thu, Jun 04, 2020 at 09:24:22PM +0300, Aleksey Tulinov wrote:
> On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies
>  wrote:
> > As Julian already said, it is "just" used for its dbus communication
> > implementation. We don't require systemd to be your init or to be even
> > functional. So I guess proposing an alternative which a) works equally
> > well and b) doesn't add additional bootstrapping complications has
> > better chances of acceptance – assuming that exists as the obvious
> > choice libdbus links against libsystemd as well even before checking a)
> > and b) …
> >
> 
> I'm not a big expert in systemd and never will be, but perhaps
> `systemd-inhibit --what="shutdown" --mode="block" apt ...` should do
> about the same thing. If every invocation of apt should be like that
> then maybe `alias apt='systemd-inhibit --what="shutdown"
> --mode="block" apt'` in .bashrc can do the trick. This does not
> require any patching whatsoever.

I mentioned already that this is implemented in libapt to apply to ALL
apt-based clients equally. A cron-job is not effected by aliases nor is
a python script (using python-apt). It isn't even realistic that you
alias all "normal" libapt clients like apt, apt-get, aptitude, synaptics,
various desktop-environment-specific software centers …

Especially as its usually not the interactive sessions as everyone who
has started an apt action by hand usually has the decency to wait for it
to finish before asking the system to shutdown. Just like nobody starts
two or more apt actions in parallel by hand. But cronjobs and background
processes do, so we got frontend lock, waiting for lock release or the
shutdown inhibition in question here (and of course, it turns out given
enough users some actually do all of this anyway because why not).


> This linking to libsystemd is redundant. If issue is with dpkg leaving

It might be redundant – in the best case. Balint already mentioned that
being the case for unattended-upgrades and that is probably a good idea
for a client (for the same reason I will mention below in the apt ↔ dpkg
relationship), but not every client will realistically implement it as
not every client is that involved.


> system in inconsistent state when interrupted, then perhaps this issue
> has to be fixed in dpkg, if issue is with systemd incorrectly
> interrupting dpkg, then in systemd. I think that dependency on

Shutdown is inhibit. That means your system (← no "d") is prevented from
shutting down before the last action inhibiting shutdown is done. dpkg
can inhibit shutdown and perhaps it should¹, but it can only do so while
it is running. libapt potentially runs dpkg multiple times, so if we
don't inhibit your system might shutdown between two dpkg calls. The
system state isn't inconsistent in a package manager sense in such cases,
it might "just" not be able to boot in that state (even if relatively
unusual). For much the same reason libapt inhibits the termination signal
(^C) to stop at a consistent state, but a system being shut down
eventually kills processes which take to long and that can of course not
be inhibited.

(¹ dpkg is essential though, so it can't just use and depend on
something and its not usually run directly in the background so its less
of an issue to begin with)

> So it doesn't do much anyway, it attempts to solve some very specific
> issue in very specific environment, but it doesn't do that very well
> and can be replaced with one shell alias.

So, as explained, yes, the issue is specific and "solved" only in
specific environments (= those which allow shutdown to be inhibited
programmatically), but so far nobody told us how to solve it for
more environments or with library with less downsides and I
hopefully explained above why "one shell alias" does not solve anything.


> It would be really nice if this dependency is removed and ideally

And I have to repeat: This dependency removes itself if your
distribution and/or architecture does not have libsystemd while apt is
being built as evident by the non-linux architectures Debian has.

So it would be really nice if we would get some more reason than just
some OCD-level "but but but, the word 'systemd' is in there somewhere"
arguments for making maintenance of apt harder (via e.g. dlopen) or it
just wont happen as building apt is trivially easy and can be fully
automated, but maintaining and supporting it can't be.


Best regards

David Kalnischkies, who wonders if its Baader-Meinhof that since he
started with resolver changes triggered by runit seemingly things
involving the names of init systems pop up everywhere around him.


signature.asc
Description: PGP signature

Bug#962236: normalize-audio: "normalize-ogg -b -n -v" shows less info than "normalize-audio -b -n -v"

[Francesco Poli (wintermute)]

Package: normalize-audio
Version: 0.7.7-15
Severity: normal

Hello and thanks for maintaining this nice program in Debian!


I wanted to run normalize (in batch mode) on a group of audio files
with the --no-adjust option, in order to analyze the files, without
altering them in any way.

I can do this on a group of .wav files with

  $ normalize-audio --amplitude=-7.5dBFS -b -n -v *.wav

and it seems to work as intended.

However, if I want to do it on a group of .ogg files, I get
per-track info, but not the standard deviation, average, or
per-album adjustment data.

  $ normalize-ogg -a -7.5dBFS --tmpdir /dev/shm -b -n -v *.ogg
  Decoding track01.ogg...
  Decoding track02.ogg...
  Decoding track03.ogg...
  Decoding track04.ogg...
  Decoding track05.ogg...
  Decoding track06.ogg...
  Decoding track07.ogg...
  Decoding track08.ogg...
  Decoding track09.ogg...
  Decoding track10.ogg...
  Decoding track11.ogg...
  Decoding track12.ogg...
  Running normalize...
  Computing levels...
levelpeak
  -6.8533dBFS  0.dBFS   /dev/shm/track01.ogg.16607.wav   
  -8.0583dBFS  0.dBFS   /dev/shm/track02.ogg.16607.wav
  -7.1047dBFS  0.dBFS   /dev/shm/track03.ogg.16607.wav
  -7.2339dBFS  0.dBFS   /dev/shm/track04.ogg.16607.wav
  -7.7699dBFS  0.dBFS   /dev/shm/track05.ogg.16607.wav
  -7.1890dBFS  0.dBFS   /dev/shm/track06.ogg.16607.wav
  -8.0084dBFS  0.dBFS   /dev/shm/track07.ogg.16607.wav
  -7.6048dBFS  0.dBFS   /dev/shm/track08.ogg.16607.wav
  -7.4123dBFS  0.dBFS   /dev/shm/track09.ogg.16607.wav
  -7.5195dBFS  0.dBFS   /dev/shm/track10.ogg.16607.wav
  -8.1773dBFS  0.dBFS   /dev/shm/track11.ogg.16607.wav
  -7.5512dBFS  0.dBFS   /dev/shm/track12.ogg.16607.wav

This is weird, since normalize-ogg decodes the .ogg files into
.wav files and then runs normalize-audio on them.
Hence, I would expect the same output...

Yet, if I manually run normalize-audio on the decoded files,
I also get the final data I am interested in:

  $ normalize-audio --amplitude=-7.5dBFS -b -n -v /dev/shm/*.wav
  Computing levels...
levelpeak
  -6.8533dBFS  0.dBFS   /dev/shm/track01.ogg.16607.wav
  -8.0583dBFS  0.dBFS   /dev/shm/track02.ogg.16607.wav
  -7.1047dBFS  0.dBFS   /dev/shm/track03.ogg.16607.wav
  -7.2339dBFS  0.dBFS   /dev/shm/track04.ogg.16607.wav
  -7.7699dBFS  0.dBFS   /dev/shm/track05.ogg.16607.wav
  -7.1890dBFS  0.dBFS   /dev/shm/track06.ogg.16607.wav
  -8.0084dBFS  0.dBFS   /dev/shm/track07.ogg.16607.wav
  -7.6048dBFS  0.dBFS   /dev/shm/track08.ogg.16607.wav
  -7.4123dBFS  0.dBFS   /dev/shm/track09.ogg.16607.wav
  -7.5195dBFS  0.dBFS   /dev/shm/track10.ogg.16607.wav
  -8.1773dBFS  0.dBFS   /dev/shm/track11.ogg.16607.wav
  -7.5512dBFS  0.dBFS   /dev/shm/track12.ogg.16607.wav
  Standard deviation is 0.39 dB
  -7.5314dBFS  average level
  0.031363dB   volume adjustment

I cannot understand why normalize-ogg seems to suppress the
final output lines (which include interesting data about
standard deviation, average, and per-album adjustment!).

I took a look at the normalize-ogg code, but my knowledge
about Perl is just a smattering, and, in addition, it is rusty.
Hence, I failed to understand the tricky part (with exec()
and pipe handling, I think...).

How can normalize-ogg be fixed to show all the output
of normalize-audio?
Please fix this bug and/or forward my bug report upstream,
as appropriate.

Thanks for your time!
Bye.


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

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

Versions of packages normalize-audio depends on:
ii  libaudiofile1  0.3.6-5
ii  libc6  2.30-8
ii  libmad00.15.1b-10
ii  perl   5.30.2-1

Versions of packages normalize-audio recommends:
ii  flac  1.3.3-1
ii  vorbis-tools  1.4.0-11

Versions of packages normalize-audio suggests:
pn  mpg321  

-- no debconf information

Bug#962238: selinux-policy-default: selinux prevents automounting sshfs

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Severity: important

Dear Maintainer,

Problem describtion:
I set up automounting with sshfs. My selinux is in Enforcing mode.
When triggering the automount, it fails and a SELinux Security alert shows up:

***audit.log***
type=AVC msg=audit(1591302044.718:8608): avc:  denied  { execute } for  
pid=14500 comm="mount.fuse" name="dash" dev="vda1" ino=261652 
scontext=system_u:system_r:mount_t:s0 
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0
***

***syslog***
Jun  4 23:20:44 vps systemd[1]: mnt-maks.automount: Got automount request for 
/mnt/maks, triggered by 14498 (ls)
Jun  4 23:20:44 vps systemd[1]: Mounting /mnt/maks...
Jun  4 23:20:44 vps systemd[1]: mnt-maks.mount: Mount process exited, 
code=exited status=1
Jun  4 23:20:44 vps systemd[1]: Failed to mount /mnt/maks.
Jun  4 23:20:44 vps systemd[1]: mnt-maks.mount: Unit entered failed state.


When setting SELinux to permissive, the automounting with sshfs works as 
expected.


Environment description:
-- fstab
root@vps:~# grep ssh /etc/fstab
media:/vps/maks /mnt/maks   fuse.sshfs  
noauto,x-systemd.automount,_netdev,users,allow_other,reconnect,ServerAliveInterval=15,ServerAliveCountMax=2
 0 0

-- packages
ii  sshfs   2.8-1
ii  mount   2.29.2-1+deb9u1


How to reproduce with Enforcing mode:
root@vps:~# setenforce 1
root@vps:~# getenforce
Enforcing
root@vps:~# grep sshfs /etc/fstab
media:/vps/maks /mnt/maks   fuse.sshfs  
noauto,x-systemd.automount,_netdev,users,allow_other,reconnect,ServerAliveInterval=15,ServerAliveCountMax=2
 0 0
root@vps:~# systemctl daemon-reload
root@vps:~# systemctl list-unit-files --type=mount
UNIT FILE STATE
-.mount   generated
boot-efi.mountgenerated
dev-hugepages.mount   static
dev-mqueue.mount  static
mnt-maks.mountgenerated
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount   static
sys-kernel-debug.mountstatic

9 unit files listed.
root@vps:~# systemctl list-unit-files --type=automount
UNIT FILE STATE
mnt-maks.automountgenerated
proc-sys-fs-binfmt_misc.automount static

2 unit files listed.
root@vps:~# systemctl restart mnt-maks.automount
root@vps:~# systemctl status mnt-maks.automount
● mnt-maks.automount
   Loaded: loaded (/etc/fstab; generated; vendor preset: enabled)
   Active: active (waiting) since Fri 2020-06-05 00:13:58 MSK; 6s ago
Where: /mnt/maks
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)

Jun 05 00:13:58 vps.k-max.name systemd[1]: Set up automount mnt-maks.automount.
root@vps:~#
root@vps:~# findmnt -u
TARGET   SOURCE  FSTYPE OPTIONS
//dev/vda1   ext4   
rw,relatime,seclabel,data=ordered
├─/sys   sysfs   sysfs  
rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/kernel/security securityfs  securityfs 
rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/selinux  selinuxfs   selinuxfs  rw,relatime
│ ├─/sys/fs/cgroup   tmpfs   tmpfs  rw,seclabel,mode=755
│ │ ├─/sys/fs/cgroup/systemd cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
│ │ ├─/sys/fs/cgroup/freezer cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,freezer
│ │ ├─/sys/fs/cgroup/devices cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,devices
│ │ ├─/sys/fs/cgroup/blkio   cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,blkio
│ │ ├─/sys/fs/cgroup/memory  cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,memory
│ │ ├─/sys/fs/cgroup/pidscgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,pids,release_agent=/run/cgmanager/agents/cgm-release-agent.pids
│ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct
│ │ ├─/sys/fs/cgroup/cpuset  cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,cpuset,clone_children
│ │ ├─/sys/fs/cgroup/net_cls,net_prio
│ │ │cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,net_cls,net_prio
│ │ └─/sys/fs/cgroup/perf_event  cgroup  cgroup 
rw,nosuid,nodev,noexec,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event
│ ├─/sys/fs/pstore   pstore  pstore 
rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/firmware/efi/efivarsefivarfsefivarfs   
rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/debugdebugfs debugfsrw,relatime,seclabel
│ │ └─/sys/kernel/debug/tracing  tracefs tracefsrw,relatime
│ └─/sys/fs/fuse/connections fusectl fusectlrw,relatime
├─/proc  procproc   

Bug#962139: [btrfs-progs] initramfs hooks failed with on libgcc_s.so.1

[Daniel Schröter]

On 04.06.20 12:41, Adam Borowski wrote:
> As your setup is different from mine: could you please confirm that
> installing libcc-s1 fixes the problem?

Do you mean libgcc-s1? It's already installed because of dependency to apt.

I have the file under /usr:
# ll /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
-rw-r--r-- 1 root root 99K Feb  4 15:52 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1

Bye

Bug#962157: marked as pending in lintian

[Guillem Jover]

On Thu, 2020-06-04 at 02:39:12 +, Felix Lechner wrote:
> Control: tag -1 pending

> 
> Remove command line option --fail-on from the settings in configuration 
> files. (Closes: #962157)
> 
> The configuration file supports a limited number of settings for end
> users. They all relate to the display (and one allows selecting the
> number of jobs).
> 
> The --fail-on command option, on the other hand, is used only in
> automated settings.  No one on the team that implemented it plans to
> use it in a configuration file. It was a mistake to include that
> option among those available in configuration files.
> 
> For automated settings, the --fail-on command-line option can be
> conveniently enabled in a transparent and straightforward manner. It
> should be added by the invocant as '--fail-on error'.
> 
> Users who rely on the exit status are furthermore advised to examine
> their scripts. The exit codes for program errors and the conditions
> selected via --fail-on are now reversed.
> 
> The new option was introduced at the same time to miminize the overall
> inconvenience. Thank you for using Lintian!
> 

Hmm, well that's unfortunate, :/ as the support for this option in the
config file makes it very convenient to set a global value different
than the default, instead of having to modify all local instances to
use the same value. Please could you restore this support and add a
value to denote «none» or perhaps a --no-fail-on or similar?

(I'd personally have in general more stuff configurable via the config
file rather than less.)

Thanks,
Guillem

Bug#962226: libdr-tarantool-perl build-depends on obsolete package

[peter green]

Source: libdr-tarantool-perl
Version: 0.45-2
Severity: serious
Tags: bullseye, sid

libdr-tarantool-perl build-depends on

tarantool-lts | tarantool (<< 1.6)

tarantool-lts has been removed from Debian and tarantool is now at version 
1.9.1.26.g63eb81e3c-1.1

Bug#888967: selinux-policy-default: Default policy breaks semanage tool

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Followup-For: Bug #888967

I would like to add more information.
After apply workaround:
$ echo '(allow semanage_t semanage_tmp_t (file (getattr open read execute 
ioctl)))' > semanage_mmap_tmp.cil 
$ sudo semodule -i semanage_mmap_tmp.cil

semanage is working, but I've still got AVC errors:
--
type=AVC msg=audit(1591299268.883:8358): avc:  denied  { execute } for  
pid=12319 comm="semanage" name="ldconfig" dev="vda1" ino=1177350 
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=0
type=AVC msg=audit(1591299268.895:8359): avc:  denied  { execute_no_trans } for 
 pid=12321 comm="gcc" path="/usr/lib/gcc/x86_64-linux-gnu/6/collect2" 
dev="vda1" ino=141628 
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1591299268.903:8360): avc:  denied  { execute } for  
pid=12322 comm="semanage" name="ldconfig" dev="vda1" ino=1177350 
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=0
type=AVC msg=audit(1591299268.911:8361): avc:  denied  { execute_no_trans } for 
 pid=12324 comm="gcc" path="/usr/lib/gcc/x86_64-linux-gnu/6/collect2" 
dev="vda1" ino=141628 
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:lib_t:s0 tclass=file permissive=0
--



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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.6-3+b3
ii  libsemanage1 2.6-2
ii  libsepol12.6-2
ii  policycoreutils  2.6-3
ii  selinux-utils2.6-3+b3

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.6-2
ii  setools  4.0.1-6

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#962230: xiphos: FTBFS on mips64el

[Sebastian Ramacher]

Source: xiphos
Version: 4.1.0.1+dfsg1-1+b1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

xiphos fails to build on ftbfs:
| [ 45/131] cxx: src/main/configs.cc -> build/default/src/main/configs_1.o
| 22:41:52 runner system command -> ['/usr/bin/g++', '-O2', 
'-fno-delete-null-pointer-checks', '-DHAVE_CONFIG_H', '-g', '-O2', 
'-fdebug-prefix-map=/<>=.', '-fstack-protector-strong', 
'-Wformat', '-Werror=format-security', '-pthread', '-Wdate-time', 
'-D_FORTIFY_SOURCE=2', '-Wdate-time', '-D_FORTIFY_SOURCE=2', 
'-Idefault/src/main', '-I../src/main', '-Idefault', '-I..', '-Idefault/src', 
'-I../src', '-I/usr/include/dbus-1.0', 
'-I/usr/lib/mips64el-linux-gnuabi64/dbus-1.0/include', 
'-I/usr/include/glib-2.0', 
'-I/usr/lib/mips64el-linux-gnuabi64/glib-2.0/include', 
'-I/usr/include/libgsf-1', '-I/usr/include/webkitgtk-4.0', 
'-I/usr/include/gtk-3.0', '-I/usr/include/at-spi2-atk/2.0', 
'-I/usr/include/at-spi-2.0', '-I/usr/include/gio-unix-2.0', 
'-I/usr/include/cairo', '-I/usr/include/pango-1.0', '-I/usr/include/fribidi', 
'-I/usr/include/harfbuzz', '-I/usr/include/atk-1.0', '-I/usr/include/pixman-1', 
'-I/usr/include/uuid', '-I/usr/include/freetype2', '-I/usr/include/libpng16', 
'-I/usr/include/gdk-pixbuf-2.0', '-I/usr/include/libsoup-2.4', 
'-I/usr/include/libxml2', '-I/usr/include/libmount', '-I/usr/include/blkid', 
'-I/usr/include/sword', '-I/usr/include/biblesync/bibleysnc', 
'../src/main/configs.cc', '-c', '-o', 'default/src/main/configs_1.o']
| In file included from /usr/include/mips64el-linux-gnuabi64/asm/types.h:23,0G
|  from /usr/include/linux/types.h:5,
|  from /usr/include/linux/stat.h:5,
|  from /usr/include/mips64el-linux-gnuabi64/bits/statx.h:31,
|  from /usr/include/mips64el-linux-gnuabi64/sys/stat.h:446,
|  from /usr/include/sword/filemgr.h:26,
|  from ../src/backend/sword_main.cc:31:
| /usr/include/asm-generic/int-l64.h:29:25: error: conflicting declaration 
‘typedef long int __s64’
|29 | typedef __signed__ long __s64;
|   | ^
| In file included from /usr/include/sword/swkey.h:31,
|  from /usr/include/sword/listkey.h:28,
|  from /usr/include/sword/swmodule.h:29,
|  from ../src/backend/sword_main.cc:28:
| /usr/include/sword/sysdata.h:49:44: note: previous declaration as ‘typedef 
long long int __s64’
|49 | __extension__ typedef __signed__ long long __s64;
|   |^
| In file included from /usr/include/mips64el-linux-gnuabi64/asm/types.h:23,
|  from /usr/include/linux/types.h:5,
|  from /usr/include/linux/stat.h:5,
|  from /usr/include/mips64el-linux-gnuabi64/bits/statx.h:31,
|  from /usr/include/mips64el-linux-gnuabi64/sys/stat.h:446,
|  from /usr/include/sword/filemgr.h:26,
|  from ../src/backend/sword_main.cc:31:
| /usr/include/asm-generic/int-l64.h:30:23: error: conflicting declaration 
‘typedef long unsigned int __u64’
|30 | typedef unsigned long __u64;
|   |   ^
| In file included from /usr/include/sword/swkey.h:31,
|  from /usr/include/sword/listkey.h:28,
|  from /usr/include/sword/swmodule.h:29,
|  from ../src/backend/sword_main.cc:28:
| /usr/include/sword/sysdata.h:50:42: note: previous declaration as ‘typedef 
long long unsigned int __u64’
|50 | __extension__ typedef unsigned long long __u64;
|   |  ^
| In file included from /usr/include/sword/swkey.h:31,
|  from /usr/include/sword/listkey.h:28,
|  from /usr/include/sword/swmodule.h:29,
|  from ../src/backend/module_manager.hh:28,
|  from ../src/backend/module_manager.cc:40:
| /usr/include/sword/sysdata.h:49:44: error: conflicting declaration ‘typedef 
long long int __s64’
|49 | __extension__ typedef __signed__ long long __s64;
|   |^
| In file included from /usr/include/mips64el-linux-gnuabi64/asm/types.h:23,
|  from /usr/include/linux/types.h:5,
|  from /usr/include/linux/stat.h:5,
|  from /usr/include/mips64el-linux-gnuabi64/bits/statx.h:31,
|  from /usr/include/mips64el-linux-gnuabi64/sys/stat.h:446,
|  from /usr/include/sword/filemgr.h:26,
|  from ../src/backend/module_manager.cc:36:
| /usr/include/asm-generic/int-l64.h:29:25: note: previous declaration as 
‘typedef long int __s64’
|29 | typedef __signed__ long __s64;
|   | ^
| In file included from /usr/include/sword/swkey.h:31,
|  from /usr/include/sword/listkey.h:28,
|  from 

Bug#953262: lintian.d.o: Provide archive-wide statistics on home page

[Felix Lechner]

Control: retitle -1 lintian.d.o: Provide archive-wide statistics on home page

Hi s3v,

> I would like to see stats of Lintian's tags get restored on the main web
> page of the project.

First of all, sorry our web service has been spotty. We hope it will
become one of people's favorite interfaces to research issues in
Debian packages.

Your request predates my involvement but I would like to understand
how to make our data more meaningful on an archive level. (The
'archive' is actually a fluid set of packages that is constantly
synchronized via dakweb.) I can find meaning only by slicing the data
in other dimensions, such as by architecture, or by providing
normalized averages, such as tags per package or overrides per
package, and so on.

Below you will find an old snapshot from the Internet Archive's
Wayback Machine. Which data was most useful to you, please, and why?

Kind regards,
Felix Lechner

* * *

Archives

The following archives are processed by Lintian:

Archive nameAttributeAttribute value
debianArchitecturesi386 amd64
Distributions/Suitesunstable experimental
Componentsmain contrib non-free
Mirror timestampSun, 21 Apr 2019 20:30:22 +
debian-debugArchitecturesi386 amd64
Distributions/Suitesunstable-debug experimental-debug
Componentsmain contrib non-free
Mirror timestampSun, 21 Apr 2019 20:30:22 +

Statistics

Last updated: Mon, 22 Apr 2019 00:33:21 +
Maintainers: 2423 (+0)
Package groups: 31284 (+5)
Rescheduled groups: 3 (+0)
Groups with processing errors: 3 (+0)
Source packages: 29929 (+1)
Binary packages: 39928 (-3)
μdeb packages: 225 (+0)
E Errors: 32305 (+4)
W Warnings: 186976 (-6)
I Info tags: 575740 (-196)
P Pedantic tags: 175454 (-42)
O Overridden tags: 181682 (-138)
X Experimental tags: 124653 (+25)
Lintian version: 2.12.0

(The numbers in parentheses describe the changes since the last
Lintian report, published on Sun, 21 Apr 2019 00:28:21 +.)

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Aleksey Tulinov]

On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies
 wrote:

> As Julian already said, it is "just" used for its dbus communication
> implementation. We don't require systemd to be your init or to be even
> functional. So I guess proposing an alternative which a) works equally
> well and b) doesn't add additional bootstrapping complications has
> better chances of acceptance – assuming that exists as the obvious
> choice libdbus links against libsystemd as well even before checking a)
> and b) …
>

I'm not a big expert in systemd and never will be, but perhaps
`systemd-inhibit --what="shutdown" --mode="block" apt ...` should do
about the same thing. If every invocation of apt should be like that
then maybe `alias apt='systemd-inhibit --what="shutdown"
--mode="block" apt'` in .bashrc can do the trick. This does not
require any patching whatsoever.

This linking to libsystemd is redundant. If issue is with dpkg leaving
system in inconsistent state when interrupted, then perhaps this issue
has to be fixed in dpkg, if issue is with systemd incorrectly
interrupting dpkg, then in systemd. I think that dependency on
systemd:

1) Doesn't solve any underlying issues;
2) Doesn't solve any issues on systems without systemd;
3) Doesn't solve the issue on systems with systemd installed but not
running because in that case there won't be anyone to react on dbus
message and inhibit shutdown, so this is not going to work.

So it doesn't do much anyway, it attempts to solve some very specific
issue in very specific environment, but it doesn't do that very well
and can be replaced with one shell alias.

It would be really nice if this dependency is removed and ideally
underlying issue(s) properly fixed instead of applying band aid here
and there.

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Adrian Bunk]

On Thu, Jun 04, 2020 at 07:55:32PM +0200, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Thu, Jun 04, 2020 at 07:59:22PM +0300, Adrian Bunk wrote:
> > FAIL: dtls_hello_random_value
> > =
> > 
> > testing: default
> > client:156: client: Handshake failed: Resource temporarily unavailable, try 
> > again.
> > server:271: server: Handshake has failed: The TLS connection was 
> > non-properly terminated.
> > 
> > FAIL dtls_hello_random_value (exit status: 1)
> > 
> This particular test seems to use a AF_UNIX socketpair, I'm not sure
> how it would fail due to network setup?

I copied the log from the 3.6.13-4 arm64 failure.
This specific test passes in the other logs.

The binary-all log (non-conova) of 3.6.13-4 has no test failures,
but the build fails due to timeout after 150 minutes without output.

My gut feeling is that there might be an (unrelated) problem with 
the #961889 fix, but this is just a guess.

> Cheers,
> Julien

cu
Adrian

Bug#962216: journalctl -f --boot header perhaps not appropriate

[Michael Biebl]

Control: tags -1 + moreinfo

Am 04.06.20 um 18:48 schrieb 積丹尼 Dan Jacobson:
> Package: systemd
> Version: 245.5-3
> Severity: wishlist
> File: /bin/journalctl
> 
> Are you sure the
> -- Logs begin at Sun 2020-02-02 08:24:03 CST. --
> message is helpful for
> # journalctl --boot
> and
> # journalctl --follow ?
> 
> It may be referring to months of old logs that aren't being shown.
> 

Huh, I have no idea what you mean here.
What exactly is the problem?



signature.asc
Description: OpenPGP digital signature

Bug#962224: lightdm does not source ~/.profile

[Graeme Vetterlein]

Package: lightdm
Version: 1.26.0-4
Severity: normal
Tags: newcomer

Dear Maintainer,

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

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

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

Having switched to lightdm from GDM3 (due to another bug in gdm3) I now find
~/.profile does
not run.

In order to debug this I created a clean user (new) called guest (pid=1001)
I modified ~/.profile and ~/.bash_profile to log their use (see attached log)

In summary the behaviour was:

gdm3 + cinnamon = Runs ~/.profile only
gdm3 + xfce = Runs ~/.profile only
gdm3 + gnome3 = Runs ~/.profile only

Switch to lioghtdm & reboot system

lightdm + cinnamon = Runs neither
lightdm + xfce = Runs neither
lightdm + gnome = Runs neither
lightdm + gnome(2nd version) = Runs neither

The doc @ https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/794315 points
to where this has been fixed in the past.




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

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

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.16-1
ii  debconf [debconf-2.0]  1.5.71
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libpam-systemd [logind]241-7~deb10u4
ii  libpam0g   1.3.1-5
ii  libxcb11.13.1-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
ii  lsb-base   10.2019051400

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
ii  accountsservice  0.6.45-2
ii  upower   0.99.10-1
ii  xserver-xephyr   2:1.20.4-1

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm
$ head -20 ~/.profile 
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022



ENV="/tmp/${USER}.env"
rm -f ${ENV}
echo ".profile run at $(date)" >  ${ENV}
pstree -glus $$>> ${ENV}
env>> ${ENV} 2>&1

LOGON_TIME=$(date) export LOGON_TIME

$ head -20 ~/.bash_profile 
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022



ENV="/tmp/${USER}-bash.env"
rm -f ${ENV}
echo ".profile run at $(date)" >  ${ENV}
pstree -glus $$>> ${ENV}
env>> ${ENV} 2>&1

LOGON_TIME=$(date) export LOGON_TIME

$ 


*** GDM3 + cinnamon 

$ ls -l /tmp/*.env
-rw-rw-rw- 1 graeme users  462 Jun  4 18:37 /tmp/graeme-bash.env
-rw-r--r-- 1 graeme users 1226 Jun  4 18:37 /tmp/graeme.env
-rw-r--r-- 1 guest  guest  839 Jun  4 18:42 /tmp/guest.env
$ id
uid=1001(guest) gid=1001(guest) groups=1001(guest)
$ cat /tmp/guest.env 
.profile run at Thu  4 Jun 18:42:46 BST 2020
systemd(1)---gdm3(826)---gdm-session-wor(826)---gdm-x-session(8109,guest)---Xsession(8109)---pstree(8109)
USER=guest
LANGUAGE=en_GB:en
XDG_SEAT=seat0
XDG_SESSION_TYPE=x11
HOME=/home/guest
DESKTOP_SESSION=cinnamon
GTK_MODULES=gail:atk-bridge
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus
LOGNAME=guest
XDG_SESSION_CLASS=user
USERNAME=guest
XDG_SESSION_ID=25
WINDOWPATH=4
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
GDM_LANG=en_GB.UTF-8
XDG_RUNTIME_DIR=/run/user/1001
DISPLAY=:0
LANG=en_GB.UTF-8
XDG_SESSION_DESKTOP=cinnamon
XAUTHORITY=/run/user/1001/gdm/Xauthority
SHELL=/bin/sh
GDMSESSION=cinnamon
QT_ACCESSIBILITY=1
XDG_VTNR=4
PWD=/home/guest

Bug#962232: vanguards indirectly build-depends on cruft package.

[peter green]

Package: vanguards
Version: 0.3.1-2
Severity: serious

vanguards build-depends on pypy-pytest which depends on pypy-funcsigs which is 
no longer built by the python-funcsigs source package. The pytest maintainer 
has also said they would like to get rid of pypy support from pytest. Afaict 
vanguards is the only application that build-depends on pypy-pytest (there are 
also some module packages but they all look like they could drop pypy support 
at the same time pytest does).

The ideal fix would be to move to pypy3, but I understand that is currently 
blocked on tooling (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932820 ). Over in bug 937769 
Chris Lamb proposed a patch to run the testsuite with python 3. Obviously 
running the testsuite with a different python version from that used to 
actually run the program is suboptimal but I think it's the lesser evil here.

I manually applied the patch, cleaning up some formatting and making the 
dependency versioning for the python3-stem build-dependency match that for the 
pypy-stem build-dependency. While testing I also noticed some clean target 
issues so I fixed them.

A debdiff is attatched, if I get no objections (and the maintainer doesn't 
upload this first) I will likely NMU this in a week or so.

diff -Nru vanguards-0.3.1/debian/changelog vanguards-0.3.1/debian/changelog
--- vanguards-0.3.1/debian/changelog2019-07-26 16:30:09.0 +
+++ vanguards-0.3.1/debian/changelog2020-06-04 19:21:14.0 +
@@ -1,3 +1,12 @@
+vanguards (0.3.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Clean up pytest cache and egg info in clean target.
+  * Run testsuite with python 3 to get rid of build-depends on pypy-pytest
+(thanks to Chris Lamb for the initial patch)
+
+ -- Peter Michael Green   Thu, 04 Jun 2020 19:21:14 +
+
 vanguards (0.3.1-2) unstable; urgency=medium
 
   [ Nicolas Braud-Santoni ]
diff -Nru vanguards-0.3.1/debian/control vanguards-0.3.1/debian/control
--- vanguards-0.3.1/debian/control  2019-07-26 16:30:09.0 +
+++ vanguards-0.3.1/debian/control  2020-06-04 19:21:14.0 +
@@ -8,8 +8,9 @@
dh-python,
pypy,
pypy-setuptools,
+   python3-pytest ,
+   python3-stem (>= 1.6.0-3.1) ,
pypy-stem (>= 1.6.0-3.1),
-   pypy-pytest,
pypy-ipaddress
 Standards-Version: 4.1.5
 Vcs-Browser: https://salsa.debian.org/pkg-privacy-team/vanguards
diff -Nru vanguards-0.3.1/debian/rules vanguards-0.3.1/debian/rules
--- vanguards-0.3.1/debian/rules2019-07-26 16:30:09.0 +
+++ vanguards-0.3.1/debian/rules2020-06-04 19:21:14.0 +
@@ -5,3 +5,10 @@
 
 override_dh_installsystemd:
dh_installsystemd --no-enable --no-start
+
+override_dh_auto_test:
+   dh_auto_test -- --system=custom --test-args='cd {build_dir}; python3 -m 
pytest $(CURDIR)/tests'
+
+override_dh_auto_clean:
+   dh_auto_clean
+   rm -rf .pytest_cache src/vanguards.egg-info

Bug#941568: [Python-modules-team] Question about related package to python3-dill

[Andreas Tille]

Control: retitle -1 RFP: multiprocess -- better multiprocessing and 
multithreading in Python

Sorry, this package has lowered in my list of needs.  Feel free to take
over.  If you want me to transfer the existing repository to DPMT I'd
happily do so.

Kind regards

   Andreas.

On Thu, Jun 04, 2020 at 04:02:23PM -0400, Sandro Tosi wrote:
> there's been some effort at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941568 , Andreas
> what's the status of multiprocess? i dont see it in NEW nor the archive
> 
> 
> On Thu, Jun 4, 2020 at 2:48 PM Marco Costa  wrote:
> >
> > Hi,
> >
> > As "dill" is a part of the pathos project, I would like to ask why the 
> > package "multiprocess" is not available also?
> >
> > Thank you in advance.
> >
> > Marco
> > ___
> > Python-modules-team mailing list
> > python-modules-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
> 
> 
> 
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
> 
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
> 

-- 
http://fam-tille.de

Bug#962218: gnutls28: build fails on IPv6-only buildds

[Julien Cristau]

On Thu, Jun  4, 2020 at 22:18:10 +0300, Adrian Bunk wrote:

> On Thu, Jun 04, 2020 at 07:55:32PM +0200, Julien Cristau wrote:
> > Control: tag -1 moreinfo
> > 
> > On Thu, Jun 04, 2020 at 07:59:22PM +0300, Adrian Bunk wrote:
> > > FAIL: dtls_hello_random_value
> > > =
> > > 
> > > testing: default
> > > client:156: client: Handshake failed: Resource temporarily unavailable, 
> > > try again.
> > > server:271: server: Handshake has failed: The TLS connection was 
> > > non-properly terminated.
> > > 
> > > FAIL dtls_hello_random_value (exit status: 1)
> > > 
> > This particular test seems to use a AF_UNIX socketpair, I'm not sure
> > how it would fail due to network setup?
> 
> I copied the log from the 3.6.13-4 arm64 failure.
> This specific test passes in the other logs.
> 
> The binary-all log (non-conova) of 3.6.13-4 has no test failures,
> but the build fails due to timeout after 150 minutes without output.
> 
> My gut feeling is that there might be an (unrelated) problem with 
> the #961889 fix, but this is just a guess.
> 
The arch:all failure is at grnet and that buildd has both v4 and v6
addresses, so presumably unrelated.

Which leaves us with the armel failure (on arm-conova-03) which does
look related to the lack of public v4 address, e.g.:

> FAIL: sni-hostname.sh
> =
> 
> Checking SNI hostname in gnutls-cli
> Echo Server listening on IPv6 :: port 26448...done
> Could not connect to 127.0.0.1:26448: Connection refused
> Failure: 1. handshake should have succeeded!
> Exiting via signal 15
> FAIL sni-hostname.sh (exit status: 1)

If we listen on :: and then try to connect to 127.0.0.1, that won't work.

And indeed gnutls-serv seems to call getaddrinfo with node == NULL and
hints.ai_flags == AI_PASSIVE|AI_ADDRCONFIG, to figure out what address
to listen on.  If the host has no non-local ipv4 address, that
getaddrinfo call returns :: but not 0.0.0.0; and then the test hardcodes
127.0.0.1 as the address for gnutls-cli to connect to, and sadness
ensues.

Cheers,
Julien

Bug#962225: smokeping: SmokePing 2.7.3 needs a patch to mitigate '"Unknown key type "rsa1"' (SSH probe)

[Milosz Galazka]

Package: smokeping
Version: 2.7.3-2
Severity: normal

Dear Maintainer,

It is not possible to use SSH probe on Debian Buster:

```
$ sudo smokeping --debug

ERROR: output of '/usr/bin/ssh-keyscan -t dsa,rsa,rsa1 127.0.0.1' does not 
match (?^i:^# \S+ SSH-)
 at (eval 59) line 1.
```

because ssh-keyscan does not support rsa1:

```
$ /usr/bin/ssh-keyscan -t dsa,rsa,rsa1 127.0.0.1
Unknown key type "rsa1"
```

The solution is to apply patch: 
https://github.com/oetiker/SmokePing/commit/62ac9fda04b994bbf4f97d3dd1cf8b92cf279e71.patch?diff=unified

```
>From 62ac9fda04b994bbf4f97d3dd1cf8b92cf279e71 Mon Sep 17 00:00:00 2001
From: "Avinash H. Duduskar" 
Date: Mon, 11 Mar 2019 13:16:13 +0530
Subject: [PATCH] Update SSH.pm to drop SSHv1 rsa1

- Removes rsa1
- Adds ecdsa instead
https://github.com/oetiker/SmokePing/issues/120
---
 lib/Smokeping/probes/SSH.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Smokeping/probes/SSH.pm b/lib/Smokeping/probes/SSH.pm
index ffbb5cc2..f21f53e8 100644
--- a/lib/Smokeping/probes/SSH.pm
+++ b/lib/Smokeping/probes/SSH.pm
@@ -55,7 +55,7 @@ sub new($$$)
 # no need for this if we run as a cgi
 unless ( $ENV{SERVER_SOFTWARE} ) {

-my $call = "$self->{properties}{binary} -t dsa,rsa,rsa1 127.0.0.1";
+my $call = "$self->{properties}{binary} -t dsa,rsa,ecdsa 127.0.0.1";
 my $return = `$call 2>&1`;
 if ($return =~ m/$ssh_re/s){
 print "### parsing ssh-keyscan output...OK\n";
@@ -132,7 +132,7 @@ sub targetvars {
 return $class->_makevars($class->SUPER::targetvars, {
keytype => {
_doc => "Type of key, used in ssh-keyscan -t I",
-  _re => "[dr]sa1*",
+  _re => "[ecdr]sa*",
_example => 'dsa',
_default => 'rsa',
},
``` 

Kind regards,
Milosz


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

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

Versions of packages smokeping depends on:
ii  adduser3.118
ii  debianutils4.8.6.1
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u4
ii  fping  4.2-1
ii  libcgi-fast-perl   1:2.13-1
ii  libconfig-grammar-perl 1.12-2
ii  libdigest-hmac-perl1.03+dfsg-2
ii  libjs-cropper  1.2.2-1
ii  libjs-prototype1.7.1-3
ii  libjs-scriptaculous1.9.0-2
ii  librrds-perl   1.7.1-2
ii  libsnmp-session-perl   1.14~git20130523.186a005-4
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  lsb-base   10.2019051400
ii  perl   5.28.1-6
ii  ucf3.0038+nmu1

Versions of packages smokeping recommends:
pn  apache2 | apache2 | httpd  
ii  dnsutils   1:9.11.5.P4+dfsg-5.1+deb10u1
ii  echoping   6.0.2-10
ii  libsocket6-perl0.29-1+b1
ii  nginx-full [httpd-cgi] 1.14.2-2+deb10u1

Versions of packages smokeping suggests:
ii  curl   7.64.0-4+deb10u1
pn  libauthen-radius-perl  
ii  libio-socket-ssl-perl  2.060-3
pn  libnet-dns-perl
pn  libnet-ldap-perl   
pn  libnet-telnet-perl 
ii  openssh-client 1:7.9p1-10+deb10u2

-- Configuration Files:
/etc/smokeping/smokeping_secrets [Errno 13] Permission denied: 
'/etc/smokeping/smokeping_secrets'

-- no debconf information

Bug#962233: ITP: libatomicbitvector -- atomic bitset/bitvector with size determined at runtime

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: libatomicbitvector -- atomic bitset/bitvector with size 
determined at runtime
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: libatomicbitvector
  Version : 0.0+git20200519.e295358
  Upstream Author : Erik Garrison 
* URL : https://github.com/ekg/atomicbitvector
* License : Apache-2.0
  Programming Lang: C
  Description : atomic bitset/bitvector with size determined at runtime
 This header-only library encodes a bitvector class with size fixed at
 runtime. Atomic operations allow for concurrent access and modification
 of the bitset. Such a structure can help with coordinating parallel
 processing of a given fixed set of entities, and has the advantage of
 only requiring O(1) bit per entry.
 .
 The atomic_bv_t class is a straightforward extension of ConcurrentBitSet
 from Facebook's folly C++ library. It wraps the atomic type with a class
 that allows them to be copied, and these wrapped atomic types are then
 used to build a vector whose size is determined at runtime.

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

Bug#962215: libfox-1.6-0: Is it possible to package fox-1.7.67 or higher?

[Roland Plüss]

Package: libfox-1.6-0
Version: 1.6.57-1
Severity: wishlist

Dear Maintainer,

I try to package my game engine project for debian which requires fox-1.7.67 or 
higher.
Existing version is 1.6.57 which is not compatible to 1.7.67 .
I've been told to create a wishlist bug to see if such an upgrade is possible,
especially seeing how fox-1.7 is not yet marked stable upstream.

Kind Regards

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

Kernel: Linux 4.19.97-gentoo (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libfox-1.6-0 depends on:
ii  libc6   2.30-8
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.1-2
ii  libgcc-s1 [libgcc1] 10.1.0-3
ii  libgl1  1.3.1-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libpng16-16 1.6.37-2
ii  libstdc++6  10.1.0-3
ii  libtiff54.1.0+git191117-2
ii  libx11-62:1.6.9-2+b1
ii  libxcursor1 1:1.2.0-2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  zlib1g  1:1.2.11.dfsg-2

libfox-1.6-0 recommends no packages.

libfox-1.6-0 suggests no packages.

-- no debconf information