Bug#971360: Re : Bug#971360: fonts-noto-color-emoji: error in glyphs display

[nicolas . patrois]

Le 02/10/2020 02:12:58, Jeremy Bicha a écrit :

> Have either of you tried logging out and logging back in or restarting
> your computer?

No, I did not restart anything but it’s the first time I notice such a 
behaviour.

> Fonts can display very badly when updated on a running system. This is
> perhaps even more likely when the font has major changes like the
> recent update of this emoji font. This kind of issue is one reason why
> Fedora has strongly encouraged "offline" updates for a few years now.

An emoji font has been updated but the glyphs I submitted are not emojis. Maybe 
the font has these glyphs too.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#966291: nexet report

[Alexey Kuznetsov]

I did rebuild debian kernel (linux-source-5.4 == 5.4.19-1~bpo10+1) with
ubuntu 5.4.0-26-generic and it works again. And tested kernel for a few
days - no corruption!

Looks like something wrong with original debian config which causes random
data loss on my SSD. Attaching diffconfig's.

config-5.4.19 - debian source code compiled with ubuntu config
config-5.4.0-0.bpo.4-amd64 - debian default kernel
config-5.4.0-26-generic - ubuntu kernel

/usr/src/linux-headers-5.4.19/scripts/diffconfig config-5.4.19
config-5.4.0-26-generic  > ~/debian-5.4.19-ubuntu-5.4.0-26-generic.txt

/usr/src/linux-headers-5.4.19/scripts/diffconfig config-5.4.0-0.bpo.4-amd64
config-5.4.19  > ~/debian-5.4.0-0.bpo.4-debian-5.4.19.txt

Maybe anyone can suggest which configs / values should I try to enable /
disable.

-- AK


debian-5.4.19-ubuntu-5.4.0-26-generic.txt.gz
Description: application/gzip


debian-5.4.0-0.bpo.4-debian-5.4.19.txt.gz
Description: application/gzip

Bug#971580: Please update to the latest upstream version (2.10.2)

[Louis-Philippe Véronneau]

Package: python3-semver
Version: 2.0.1-4
Severity: wishlist

Dear maintainer,

The current version of python3-semver is quite old and hasn't been
updated since jessie. Would it be possible to update it to the latest
upstream release (2.10.2)?

The current version crashes the testsuite in sublime-music, as it
requires some new features.

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#971550: gnome-shell-extension-easyscreencast: Opening "Options" and change "Show alerts and notifications" crashes under Xorg.

[Philip Wyett]

On Thu, 2020-10-01 at 18:04 +0100, Philip Wyett wrote:
> Package: gnome-shell-extension-easyscreencast
> Version: 1.0.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Opening "Options" and change "Show alerts and notifications" or other
> similar option crashes the extension (dialog) under Xorg. This does
> not
> occur under wayland.
> 
> Regards
> 
> Phil
> 
> -- System Information:
> Debian Release: 10.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-11-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_USER
> 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 gnome-shell-extension-easyscreencast depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
> ii  gnome-shell  3.30.2-11~deb10u2
> ii  libgtk-3-common  3.24.5-1
> 
> gnome-shell-extension-easyscreencast recommends no packages.
> 
> gnome-shell-extension-easyscreencast suggests no packages.
> 
> -- no debconf information

After additional testing, this issue can be reproduced on wayland.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#971579: mariadb-10.5 FTCBFS: multiple reasons

[Helmut Grohne]

Source: mariadb-10.5
Version: 1:10.5.5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: tags 920365 + wontfix
Control: close 920365

Hi Otto,

great news. I managed to make mariadb cross buildable. It wasn't that
hard in the end, I just got a number of things wrong on the road, which
made it take a little longer. Instead of detailing on the problems
encountered, I'm attaching a patch with a descriptive changelog. If you
have any questions on why a particular change is needed, don't hesitate
to ask. Integrating this may not be entirely trivial as you already
cherry picked the dh_auto_configure part into git, but this patch is
against the unstable version.

One aspect I'd like to highlight is that mariadb wants to know the stack
direction and you cannot determine this during cross compilation. For
that reason, mariadb includes the stack direction for each architecture.
Updating it will be required for new architectures from time to time.
Hope this works for you.

Do note however that making mariadb cross buildable implies not turning
mariadb_config into a shell script. Doing so would require running
mariadb_config during build, which we cannot do during cross builds. It
was only ever meant as s stop-gap solution and the real solution is
using pkg-config. So I'll have to send a lot of patches to mariadb users
to make them stop using mariadb_config, which is fundamentally
incompatible with cross compilation. Thus closing that bug. There is
nothing we can do about that on the mariadb side anymore.

Thanks for your cooperation with this matter

Helmut
diff --minimal -Nru mariadb-10.5-10.5.5/debian/changelog 
mariadb-10.5-10.5.5/debian/changelog
--- mariadb-10.5-10.5.5/debian/changelog2020-09-25 18:56:59.0 
+0200
+++ mariadb-10.5-10.5.5/debian/changelog2020-09-26 08:00:12.0 
+0200
@@ -1,3 +1,15 @@
+mariadb-10.5 (1:10.5.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Add native dependencies on gnutls, libedit and ncurses.
++ Use a native perl interpreter during build.
++ Let dh_auto_configure pass -DCMAKE_SYSTEM_NAME to cmake.
++ Keep default CMAKE_BUILD_TYPE=RelWithDebInfo instead of debhelper's None.
++ Cache the per-architecture stack direction.
+
+ -- Helmut Grohne   Sat, 26 Sep 2020 08:00:12 +0200
+
 mariadb-10.5 (1:10.5.5-1) unstable; urgency=medium
 
   * New upstream version 10.5.5 (Closes: #968895)
diff --minimal -Nru mariadb-10.5-10.5.5/debian/control 
mariadb-10.5-10.5.5/debian/control
--- mariadb-10.5-10.5.5/debian/control  2020-09-24 00:19:37.0 +0200
+++ mariadb-10.5-10.5.5/debian/control  2020-09-26 08:00:12.0 +0200
@@ -17,12 +17,15 @@
libcrack2-dev (>= 2.9.0),
libcurl4-openssl-dev | libcurl4-dev,
libedit-dev,
+   libedit-dev:native,
libgnutls28-dev (>= 3.3.24),
+   libgnutls28-dev:native (>= 3.3.24),
libjemalloc-dev [linux-any],
libjudy-dev,
libkrb5-dev,
liblz4-dev,
libncurses5-dev (>= 5.0-6~),
+   libncurses5-dev:native (>= 5.0-6~),
libnuma-dev [!armhf],
libpam0g-dev,
libpcre2-dev,
@@ -31,7 +34,7 @@
libxml2-dev,
libzstd-dev (>= 1.3.3),
lsb-release,
-   perl,
+   perl:any,
po-debconf,
psmisc,
unixodbc-dev,
diff --minimal -Nru mariadb-10.5-10.5.5/debian/rules 
mariadb-10.5-10.5.5/debian/rules
--- mariadb-10.5-10.5.5/debian/rules2020-09-17 22:17:28.0 +0200
+++ mariadb-10.5-10.5.5/debian/rules2020-09-26 08:00:12.0 +0200
@@ -22,8 +22,7 @@
 RELEASE := $(shell lsb_release -r -s) # Use changelog based DEB_DISTRIBUTION 
instead?
 TMP:=$(CURDIR)/debian/tmp
 
-CC := $(DEB_HOST_GNU_TYPE)-gcc
-CXX := $(DEB_HOST_GNU_TYPE)-g++
+-include /usr/share/dpkg/buildtools.mk
 
 # According to Debian Policy version 4.2.0 builds should be as verbose as
 # possible unless 'terse' is specifically passed.
@@ -53,6 +52,15 @@
 CMAKEFLAGS += -DPLUGIN_ROCKSDB=NO
 endif
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU),alpha amd64 arm arm64 i386 ia64 m68k 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64))
+CMAKEFLAGS += -DSTACK_DIRECTION=-1
+endif
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU),hppa))
+CMAKEFLAGS += -DSTACK_DIRECTION=1
+endif
+endif
+
 ifeq ($(DEB_HOST_ARCH),riscv64)
 # riscv64 is currently very slow.
 TESTCASE_TIMEOUT=120
@@ -75,7 +83,7 @@
@echo "RULES.$@"
dh_testdir
dh_testroot
-   rm -rf $(BUILDDIR) builddir-native
+   rm -rf $(BUILDDIR) builddir-native extra/readline
 
[ ! -f debian/mysql-test-unstable-tests.orig ] || \
mv debian/mysql-test-unstable-tests.orig mysql-test/unstable-tests
@@ -94,12 

Bug#971578: firejail: overlay-named not working with newer kernels, causes ELOOP

[GSR]

Package: firejail
Version: 0.9.62.4-2
Severity: normal

Dear Maintainer,

"firejail --overlay-named=foobar bash" fails with "Error mounting
overlayfs for mounted home directory: fs.c:1064 fs_overlayfs: Too many
levels of symbolic links".

Similar to upstream https://github.com/netblue30/firejail/issues/2799

This points to overlayfs improvements in recent kernels. It works with
linux-image-4.17.0-1-amd64 4.17.8-1, but with newer ones I tested,
linux-image-5.2.0-2-amd64 5.2.9-2 & linux-image-5.8.0-2-amd64
5.8.10-1, a possible loop is detected and mount aborts.

I hope I found the concept for a solution, but it would need to be
adapted for firejail. Lets prepare the dir tree for the demo, /tmp is
a tmpfs, /home is physical ext4:
---8<---
# mkdir -p /tmp/merged{1,2} /tmp/step1/{upper1,work1}
# export DEMO=username
# mkdir -p /home/$DEMO/.firejail/step2/{upper2,work2}
--->8---

Currently firejail seems to go direct to what I call step 2, creating
a loop which the kernel does not allow, similar to this:
---8<---
# mount -t overlay overlay 
-olowerdir=/home/,upperdir=/home/$DEMO/.firejail/step2/upper2/,workdir=/home/$DEMO/.firejail/step2/work2/
 /tmp/merged2
mount: /tmp/merged2: mount(2) system call failed: Too many levels of symbolic 
links.
--->8---

The workaround I found is to first create an overlay to delete where
the looping point would appear:
---8<---
# mount -t overlay overlay 
-olowerdir=/home/,upperdir=/tmp/step1/upper1/,workdir=/tmp/step1/work1/ 
/tmp/merged1
# rm -fr /tmp/merged1/$DEMO/.firejail/
--->8---

And now proceed with the desired overlay, that stores data in the user
directory for future mounts:
---8<---
# mount -t overlay overlay 
-olowerdir=/tmp/merged1,upperdir=/home/$DEMO/.firejail/step2/upper2/,workdir=/home/$DEMO/.firejail/step2/work2/
 /tmp/merged2
# touch /tmp/merged2/$DEMO/overlay-test
# umount /tmp/merged2
# mount -t overlay overlay 
-olowerdir=/tmp/merged1,upperdir=/home/$DEMO/.firejail/step2/upper2/,workdir=/home/$DEMO/.firejail/step2/work2/
 /tmp/merged2
# ls /tmp/merged2/$DEMO/overlay-test
--->8---

So instead of "overlay over home storing data in home", first "overlay
over home storing data in memory" (reusable for concurrent firejails
until next reboot?), then delete the problematic directory in it, and
another "overlay over the memory one", so this time we can use home
for storage without problems, and hiding it from current (and
concurrent) firejail(s).

Seeing the complexity of doing it by hand, maybe there could be cmds
"firejail --[u]mount-overlay=overlay_name /some/dir/" to make
inspection of (non live?) overlays easier. root could run a script,
but if user alone can check own overlays, it would be a lot better.

(Existing --join-filesystem makes me think the following could be
tricky or unsafe or require some kind of network based fs... still
learning about namespaces:)
Related to above maybe there could be a param "--export-fs=/some/dir"
to launch a jail with the filesystem viewable from outside (as
alternative to multiple --get, --ls and --put); and cmds "firejail
--bind-[u]mount={name|pid} /some/dir" to mount the fs view of a
running jail and keep it after it ends down. They would help debugging
configs and allowing extraction of data even if you forget to launch
with overlays instead of any of the "all discarded on exit" options.

Well, I hope the double overlay is the solution, or leads to something
that makes the feature work again.

Cheers,
GSR
 

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.4-3
ii  libc6 2.31-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.62.4-2
ii  iproute2   5.8.0-1
ii  iptables   1.8.5-3
ii  xauth  1:1.0.10-1
ii  xpra   3.0.9+dfsg1-1+b2
ii  xserver-xephyr 2:1.20.9-2
ii  xvfb   2:1.20.9-2

firejail suggests no packages.

-- no debconf information

Bug#971569: mutter: Laptop display stays dimmed after blanking screen under wayland

[Jaycee Santos]

Package: mutter
Version: 3.38.0-2
Severity: normal
X-Debbugs-Cc: jlsan...@protonmail.com

On a Thinkpad X220, I have GNOME set to dim the screen when inactive, with
blank screen enabled.

When the screen is blanked after inactivity (display turns off), interacting
with the laptop turns on the screen but does not reset the brightness level.
(It stays dimmed and the brightness slider does not match the brightness
level of the display.)

The user would have to adjust the brightness (each time the laptop screen
is blanked) or connect the laptop to power, to free the display from the
dimmed state.

This is reproducible when using GNOME/mutter under Wayland _and_ on battery
power with "Dim Screen When Inactive" enabled. This does not happen when
plugged in.
I have not been able to reproduce this bug when running GNOME/mutter under
Xorg.



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

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

Versions of packages mutter depends on:
ii  adwaita-icon-theme3.38.0-1
ii  gnome-settings-daemon-common  3.38.0-2
ii  gsettings-desktop-schemas 3.38.0-2
ii  libc6 2.31-3
ii  libgles2  1.3.2-1
ii  libglib2.0-0  2.66.0-2
ii  libmutter-7-0 3.38.0-2
ii  libwayland-server01.18.0-2~exp1.1
ii  libx11-6  2:1.6.12-1
ii  libxcomposite11:0.4.5-1
ii  mutter-common 3.38.0-2
ii  zenity3.32.0-5

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:3.38.0-2
ii  xdg-user-dirs 0.17-2

-- no debconf information

Bug#971561: cloud.debian.org: ARM-based Buster AMIs don't support new T4g instance types

[Ryan Thoryk]

Yes, it was just the Marketplace that I was trying to get the AMI from.
 Thanks for your help.

On 10/1/20 6:39 PM, Noah Meyerhans wrote:
> I've confirmed that the Marketplace UI still doesn't let us enable t4g.*
> and opened a support request with AWS to see if they can enable this for
> us.
> 
> For now, use the AMIs listed at
> https://wiki.debian.org/Cloud/AmazonEC2Image/Buster
> 

-- 
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#971347: transition: mumps

[Drew Parsons]

Hi Alastair, I'm getting a PMIX undefined symbol in new builds of MUMPS 
5.3.3 amd armel and mipsel,

see https://buildd.debian.org/status/package.php?p=mumps

The armel log at 
https://buildd.debian.org/status/fetch.php?pkg=mumps=armel=5.3.3-2=1601578910=0

reports:

...
mpifort -o c_example -Wl,-z,relro  c_example.o 
/<>/lib/libdmumps.so 
/<>/lib/libmumps_common.so -L/<>/lib -lpord 
-lscalapack-openmpi -llapack  -lmpi -lblas -lpthread
mpifort -g -O2 -fdebug-prefix-map=/<>/examples=. 
-fstack-protector-strong   -Dintel_  -I. -I../include -I../src  -c 
multiple_arithmetics_example.F -o multiple_arithmetics_example.o
mpifort -o multiple_arithmetics_example -Wl,-z,relro  
multiple_arithmetics_example.o /<>/lib/libsmumps.so 
/<>/lib/libmumps_common.so 
/<>/lib/libdmumps.so 
/<>/lib/libmumps_common.so 
/<>/lib/libcmumps.so 
/<>/lib/libmumps_common.so 
/<>/lib/libzmumps.so 
/<>/lib/libmumps_common.so -L/<>/lib -lpord 
-lscalapack-openmpi -llapack   -lblas -lpthread

make[2]: Leaving directory '/<>/examples'

=== running c_example (serial) ===
OpenCL: Failed to get number of platforms with clGetPlatformIDs(): -1001
[arm-ubc-04:29759] mca_base_component_repository_open: unable to open 
mca_pmix_pmix3x: 
/usr/lib/arm-linux-gnueabi/openmpi/lib/openmpi3/mca_pmix_pmix3x.so: 
undefined symbol: OPAL_MCA_PMIX3X_PMIx_Get_version (ignored)
[arm-ubc-04:29759] [[26335,0],0] ORTE_ERROR_LOG: Not found in file 
../../../../../../orte/mca/ess/hnp/ess_hnp_module.c at line 320




The mipsel log reports the same problem with 
OPAL_MCA_PMIX3X_PMIx_Get_version.



Are you able to diagnose what the problem is?
Does openmpi need to be rebuilt for armel and mipsel?


Drew

Bug#971577: bluez: bluetooth.service fails to start bluetoothd

[Moshe Piekarski]

Package: bluez
Version: 5.55-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Having updated bluez from 5.50.1-2, systemd is no longer able to start 
bluetoothd. I believe this to be connected
to the movement of the binary to /usr/libexec/.

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

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

Versions of packages bluez depends on:
ii  dbus 1.12.20-1
ii  init-system-helpers  1.58
ii  kmod 27+20200310-2
ii  libasound2   1.2.3.2-1
ii  libc62.31-3
ii  libdbus-1-3  1.12.20-1
ii  libdw1   0.181-1
ii  libglib2.0-0 2.66.0-2
ii  libreadline8 8.0-4
ii  libudev1 246.6-1
ii  lsb-base 11.1.0
ii  udev 246.6-1

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  13.0-5

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQJNBAEBCAA3FiEEXbk7X2RxJi0NGP5lMn/Nf3K/IoEFAl9z/2QZHGRlYmlhbi5i
dWdzQG1lbGFjaGltLm5ldAAKCRAyf81/cr8igYnVD/0Yq58mtItHZd0uKIkLd4af
D3Z/NsLuXcHj8KVkZZWyJuDnDe944095n1O5QpKXogGzi42iqptfABtzrmsC1iCi
zgE5zI/wkR4hv0s53l4pkSFy8FOeT75TW8ZAIOUjK9h+pvgnTA2lvufAZBdfoUq6
7JjCubMlvn9ozotr+Y4sIaqWhQ+Ja16wN3uLreJfMZQ6bUSpmbbMxsaEvaht7FRh
TZ79cF+StQfTtk34ROY3NdCe5L2vSYs03jvavnDxUUqDJwsGyRJ9TOVl2S125DHC
M2XXUJcyv+dYqrZBf3Re7JPApMV9tgkvAqEZU/jsvixrbEN1kjuyU/4I86AODxp0
cRoBuFPMdPlTU8SuYGp55I5ryCq/Pv6hJNQjJu6dOTMpONy2e0ca+0lXHcAhO039
s/KLBMlkCSbDWousdSFILpOIQTR9LjDJPzOGHYcSrrXlrScGR+tfuLDAbYnaNRSG
mwABpTWiLvPrl+wPhNcO4FyYf8Cd9m9whkRwlAvQvHOHOOwMfkd8KvVjm8vd7jVh
o3liQVmXXvNDIQBGrawq+IZOuxUzD4xCM9i8+61BuWwYj2j/WmQXioZmxKhD1yyB
47v1xltiZoNUkdNBjWwjPmG/RBvsQ8+MiE5zqnPdRUheyr4pBE2TisdB3TZrkASv
zbsbyLbTktLbjyHCq4bTxQ==
=ORRe
-END PGP SIGNATURE-

Bug#971576: ischroot: sends usage and version to stdout

[Thorsten Glaser]

Package: debianutils
Version: 4.11.2
Severity: wishlist
X-Debbugs-Cc: t...@mirbsd.de

The recent change changes the application to send this
information to stdout. This however is not what normal
Unix users expect *and* probably will break users’ scripts.

The correct fix for #961872 is to do this instead:

diff --git a/debian/tests/smoke b/debian/tests/smoke
index 5dc69ba..214985d 100644
--- a/debian/tests/smoke
+++ b/debian/tests/smoke
@@ -3,5 +3,5 @@
 run-parts --version
 tempfile 2>&1
 which sh
-ischroot --version
+ischroot --version 2>&1
 savelog

Or perhaps this even:

diff --git a/debian/tests/smoke b/debian/tests/smoke
index 5dc69ba..f63041b 100644
--- a/debian/tests/smoke
+++ b/debian/tests/smoke
@@ -1,7 +1,9 @@
 #!/bin/sh -e
 
+exec 2>&1
+
 run-parts --version
-tempfile 2>&1
+tempfile
 which sh
 ischroot --version
 savelog


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages debianutils depends on:
ii  libc6  2.31-3

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

Bug#971575: ITP: mkautodoc -- Auto documentation for MkDocs

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mkautodoc
  Version : 0.1.0
  Upstream Author : Tom Christie
* URL : https://github.com/tomchristie/mkautodoc
* License : BSD
  Programming Lang: Python
  Description : Auto documentation for MkDocs

This markdown extension adds autodoc style support, for use with MkDocs.

This package is needed to build httpcore documentation

Bug#971574: ITP: mkdocs-material -- Material Design theme for MkDocs

[Sandro Tosi]

Package: wnpp
Severity: wishlist

* Package name: mkdocs-material
  Version : 6.0.1
  Upstream Author : Martin Donath 
* URL : https://github.com/squidfunk/mkdocs-material
* License : MIT
  Programming Lang: Python
  Description : Material Design theme for MkDocs

Create a branded static site from a set of Markdown files to host the
documentation of your Open Source or commercial project – customizable,
searchable, mobile-friendly, 40+ languages. Set up in 5 minutes.

Features:

It's just Markdown — write your technical documentation in plain Markdown – no
need to know HTML, JavaScript, or CSS. Material for MkDocs will do the heavy
lifting and convert your writing to a beautiful and functional website.

Responsive by design — built from the ground up to work on all sorts of devices
– from mobile phones to widescreens. The underlying fluid layout will always
adapt perfectly to the available screen space.

Static, yet searchable — almost magically, your technical documentation website
will be searchable without any further ado. Material for MkDocs comes with
built-in search – no server needed – that will instantly answer your users'
queries.

Many configuration options — change the color palette, font families, language,
icons, favicon and logo. Add a source repository link, links to your social
profiles, Google Analytics and Disqus - all with a few lines of code.

Truly international — thanks to many contributors, Material for MkDocs includes
translations for more than 40 languages and offers full native RTL
(right-to-left) support for languages such as Arabic, Persian (Farsi) and
Hebrew.

Accessible — Material for MkDocs provides extensible keyboard navigation and
semantic markup including role attributes and landmarks. Furthermore, the layout
is entirely based on rem values, respecting the user's default font size.

Beyond GitHub Markdown — integrates natively with Python Markdown Extensions,
offering additional elements like callouts, tabbed content containers,
mathematical formulas, critic markup, task lists, and emojis/

Modern architecture — Material for MkDocs's underlying codebase is built with
TypeScript, RxJS, and SCSS, and is compiled with Webpack, bringing excellent
possibilities for theme extension and customization.

This is needed to build httpcore documentation

Bug#971406: gnome-shell: freezes when laptop is configured for external display only

[TomK]

On Wed, 30 Sep 2020 10:55:34 +0100 Simon McVittie 
wrote:
> Control: reassign -1 gnome-shell 3.30.2-11~deb10u2
> Control: retitle -1 gnome-shell: freezes when laptop is configured
for external display only
> Control: tags -1 + moreinfo buster
> 
> On Tue, 29 Sep 2020 at 18:58:55 -0400, tom wrote:
> > Gnome-conrol-center > devices > displays > external monitor set
> > to primary in 'join displays'> 'single display'
> > turns off both LVDS and external monitor, freezes keyboard and 
> > mouse control
> 
> gnome-control-center only changes configuration and doesn't actually
> implement the display change, so I'm reassigning this to gnome-shell,
> which is the component that -control-center is configuring. Please
> send the output of "reportbug --template gnome-shell" so that we can
> see the versions of all the related packages. For now I'm assuming
>that
> it's the latest version from Debian 10.6.
> 
> If you repeat the configuration that caused the freeze, does it
>happen
> reliably?

I think it's fixed. 
Seems to work now.  

> What messages appear in the system log (/var/log/syslog or the
systemd
> journal) when this happens?

I could not determine that.
> 
> Are you using the Wayland or Xorg version of the GNOME session?
>
wayland 
> What hardware are you using?

Lenovo W541 laptop on dock station, ext monitor is Samsung connected by
DP port on dock. 

>You mentioned LVDS, so presumably it's a
> laptop. What graphics device does it have? lspci, from the pciutils
> package, should list a "VGA compatible controller", perhaps more than
> one.

Using Intel video

00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core
Processor Integrated Graphics Controller (rev 06)

01:00.0 VGA compatible controller: NVIDIA Corporation GK106GLM [Quadro
K2100M] (rev a1)

> 
> Are you using any GNOME Shell extensions? If you are, please try
>disabling
> them all and see whether the bug persists.

Not using extensions.

> hard reboot only solution
> 
> Here are some things that might make a hard reboot unnecessary:
> 
> * press Ctrl+Alt+Delete repeatedly (more than 7 times in 2 seconds)
>   to reboot semi-gracefully
> 
> * press Ctrl+Alt+F6, then Ctrl+Alt+Delete repeatedly
> 
> * use "magic sysrq key" sequences
>   (https://en.wikipedia.org/wiki/Magic_SysRq_key#Uses)
>   to reboot less gracefully
> 
Thanks for the reboot advice. Didn't have a chance to try it 'this'
time, but it'll be handy to have in the future.

> Do any of those work? If they do, that gives us useful information
> about
> which layers of the system have stopped working and which layers
> still work.
> 
> > If 'mirror' is used, the external monitor is available, but only at
> > the resolution of the LVDS or lower. 
> 
> Mirroring can only happen at resolutions that are supported by both
> displays, so that part isn't a bug.
> 

> smcv
> 
>
Lenovo machines can be finicky with Linux, because the hardware depends
a lot on custom MS Windows code, written by Lenovo, to function. So,
this report may have  a very narrow scope. I cannot determine what
changed to make 'ext display only' suddenly work.
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: tom 
To: Debian Bug Tracking System 
Subject: gnome-shell: none
X-Debbugs-Cc: foren...@milwpc.com

Package: gnome-shell
Version: 3.30.2-11~deb10u2
Severity: wishlist

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 ***


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1+deb10u1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-4~deb10u1
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0

Bug#919893: rng-tools-debian: package shouldn't exist

[Thorsten Glaser]

Hi,

>Yes, I have made it clear in the past that I am happy with any
>transition plan at all, so I was not under the impression that I had to
>write anything...

ah okay, and I missed *that*. Great that we talked about it,
thanks Michael for pointing us out.

>So, feel free to even become the new upstream for the forked codebase!
>Or just keep it on deep maintenance as a downstream maintainer, if
>you'd rather do it like that.

I basically did that already some time ago, so all that’s left is to
take over rng-tools for one release and migrate users’ settings.

That, and document in the package description and whereever people
wish me to do it absolutely clear that this is the “traditional”
codebase and they should install rng-tools5 whenever it fits their
needs. I’m accepting place and wording suggestions.

Thanks,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#971573: RFP: python-cppimport -- import C or C++ files directly from Python

[Drew Parsons]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: python-cppimport
  Version : 17.09.18
  Upstream Author : Ben Thompson 
* URL : https://github.com/tbenthompson/cppimport
* License : MIT
  Programming Lang: Python
  Description : import C or C++ files directly from Python

Sometimes Python just isn't fast enough. Or you have existing code in
a C++ library.  cppimport combines the process of compiling and
importing an extension in Python so that you can type modulename =
cppimport.imp("modulename") and not have to worry about multiple
steps.

cppimport looks for a C or C++ source file that matches the requested
module. If such a file exists, the file is first run through the Mako
templating system. The compilation options produced by the Mako pass
are then use to compile the file as a Python extension. The extension
(shared library) that is produced is placed in the same folder as the
C++ source file. Then, the extension is loaded.

Most cppimport users combine it with pybind11, but you can use a range
of methods to create your Python extensions. Raw C extensions,
Boost.Python, SWIG all work.




cppimport is used in some dolfinx tests.



Probably best maintained under the Debian Python Team.

Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs

[Henrique de Moraes Holschuh]

On Sun, Sep 27, 2020, at 18:27, Ben Hutchings wrote:
> On Sun, 2020-09-27 at 13:43 -0300, Henrique de Moraes Holschuh wrote:
> > Answering from my phone, please excuse brevity and other netiquete
> > issues such as poor quoting cleanup.

This is still true :(

> However, we normally take all changes from linux-firmware.git up to a
> specific tag, and that might not be appropriate for the AMD microcode
> given the potential for system-breaking regressions.

So, until a more workable solution is found, if you need amd64-microcode to 
carry any other data files, please file a bug.  If I am behind an update for 
any reason, please file a bug.  I will see it and act on it. You don't need to 
wait to see if I noticed the upstream update or not, file the bug as soon as 
you're prepared to.

There was a mention about a pending security update of SES firmware in this 
thread.  If this needs an amd64-microcode release and if the ses firmware 
should go into that release, please explicitly say so, preferably in a new bug 
report, so that we can keep this one open until a final decision is done 
whether we should drop amd64-microcode as a separate package or keep it just 
for scripts, or keep the status-quo.

-- 
  Henrique de Moraes Holschuh 

Bug#919893: rng-tools-debian: package shouldn't exist

[Henrique de Moraes Holschuh]

Hello...

On Thu, Oct 1, 2020, at 21:05, Michael Stone wrote:
> On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote:
> >Michael Stone dixit:
> >
> >> you can fix it right now!
> >
> >So, what do you mean? Take over the rng-tools package?
> >
> >If so, it has a maintainer, you know. hmh has been quiet so far.

Yes, I have made it clear in the past that I am happy with any transition plan 
at all, so I was not under the impression that I had to write anything...

So, as long as you come up with a proper transition, you are very welcome to 
take over the rng-tools name, transition the old, forked codebase for 
low-bandwidth rng to another name such as rng-tools-legacy or -debian, etc...

> he's been clear that he's happy for someone to take it over, or did you 
> talk to him before uploading your package and he told you that you'd 
> have to create your own because rng-tools was off limits?

I am pretty sure I never hard-rejected any offers to take over the old 
rng-tools, but if anything I said years ago sounded like it, I can only say it 
is a major pity it took this long to get it straightened out.

So, feel free to even become the new upstream for the forked codebase!  Or just 
keep it on deep maintenance as a downstream maintainer, if you'd rather do it 
like that.

-- 
  Henrique de Moraes Holschuh 

Bug#971572: oclgrind appears to depend on libclang-common-9-dev

[ryan]

Source: oclgrind
Version: 19.10-2
Severity: normal

Dear Maintainer,

Thanks for packaging oclgrind!

   * What led up to the situation?

I was attempting to use oclgrind, but I found that using oclgrind and trying to
compile an OpenCL program resulted in unexpected output from
clGetProgramBuildInfo():

```
fatal error: malformed or corrupted AST file: 'could not find file
'/usr/lib/llvm-9/lib/clang/9.0.1/include/opencl-c-base.h' referenced by AST file
'/usr/lib/x86_64-linux-gnu/oclgrind/19.10//opencl-c-1.2-64.pch''
```

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

I discovered that this file is provided by libclang-common-9-dev, which I then
installed.  At this point, my program worked successfully.

So it seems like oclgrind should also depend on libclang-common-9-dev.

   * What was the outcome of this action?

I successfully worked around the issue.

   * What outcome did you expect instead?

Hopefully that I might not need to work around the issue. :)

My system information below is inaccurate---I am behind a Comcast host so I
can't use reportbug to actually send an email, so I am here using reportbug on a
different system that is not behind Comcast's awful SMTP block rules.

Please let me know if there's any more information you need.  And thanks again!

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

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

Bug#971567: libgit-raw-perl: libgit2 1.0 transition

[gregor herrmann]

Control: tag -1 + pending

On Fri, 02 Oct 2020 00:42:36 +0100, Ximin Luo wrote:

> libgit2 1.0 is now available in experimental. Please make sure your
> package is ready for this version by the time we upload this package to
> unstable in one to two weeks. The severity of this report will be raised
> to serious once libgit2 1.0 is uploaded to unstable.

libgit-raw-perl 0.87+ds-1 is sitting in our git repo, waiting for libgit2-dev
>= 1.0 to move from experimental to unstable since some time, so
yeah, bring it on :)


Cheers,
gregor


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


signature.asc
Description: Digital Signature

Bug#971571: transition: libgit2

[Ximin Luo]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 971562 971563 971564 971565 971566 971567 971568 971569 
971570

Hello release team!

I'd like to request a transition slot for libgit2.

libgit2 1.0.0 is in experimental and ready to start the transition from
0.28 in unstable.

I've rebuilt the relevant reverse-build-dependencies from unstable

The following succeed and can be binNMU'd directly:
- calligra fritzing gnuastro horizon-eda

The following succeed after patches, bugs have been filed:
- kup-backup

The following could not be tested because they currently FTBFS:
- ktexteditor julia

The following fail, but probably just need to be bumped to the latest upstream 
version:
- libgit-raw-perl libgit2-glib-1.0-0 python-pygit2 ruby-rugged: bindings to 
libgit2
- gnome-builder: depends on libgit2-glib-1.0-0

The following fail, and probably need more invasive changes such as upgrading 
to the new API; bugs have been filed:
- gall (low popcon 30), geany-plugins

The following will be handled later by the rust team (including me):
- cargo (fixed in git), rust-*

Thanks,
Ximin


Ben file:

title = "libgit2";
is_affected = .depends ~ "libgit2-2[0-9]" | .depends ~ "libgit2-1.0";
is_good = .depends ~ "libgit2-1.0";
is_bad = .depends ~ "libgit2-2[0-9]";


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

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

Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files

[Ivan Baldo]

Hello.

So I did check too this way:

docker pull debian:stretch
docker run --rm -it debian:stretch

Inside that container:

sed 's/deb http/deb-src http/' /etc/apt/sources.list
>/etc/apt/sources.list.d/sources.list
cd /tmp
apt-get update && apt-get install devscripts
apt-get build-dep sane-backends && apt-get source sane-backends
cd sane-backends-1.0.25 && dpkg-buildpackage && cd ..
apt-get download libsane-common=1.0.25-4.1 libsane=1.0.25-4.1
debdiff libsane-common_1.0.25-4.1_all.deb
libsane-common_1.0.25-4.1+deb9u1_all.deb
debdiff libsane_1.0.25-4.1_amd64.deb libsane_1.0.25-4.1+deb9u1_amd64.deb

And yes!, as you said: they are identical, they have all the files needed.

Took a look at the log you mentioned, but couldn't find the cause of
the problem :-(.

I am not an expert in building packages or diagnosing building problems though.

Thanks for your help.

El jue., 1 de oct. de 2020 a la(s) 19:32, Sylvain Beucler
(b...@beuc.net) escribió:
>
> Hi,
>
> Thanks for report this issue.
>
> Something must have gone wrong when rebuilding the packages at Debian,
> because the packages I had built didn't have these differences. I just
> ran a local rebuild and I still have valid packages, with all the files.
>
> It's night-time here so I won't look in depth right now, but
> https://buildd.debian.org/status/package.php?p=sane-backends=stretch-security
> should contain possible errors.
>
> This could be due to a bug when building the 'all' and 'amd64' packages
> separately.
>
> Cheers!
> Sylvain



-- 
Ivan Baldo - iba...@gmail.com - http://ibaldo.codigolibre.net/
Freelance C++/PHP programmer and GNU/Linux systems administrator.
The sky isn't the limit!

Bug#971570: julia: libgit2 1.0 transition

[Ximin Luo]

Package: julia
Version: 1.4.1+dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,

libgit2 1.0 is now available in experimental. Please make sure your
package is ready for this version by the time we upload this package to
unstable in one to two weeks. The severity of this report will be raised
to serious once libgit2 1.0 is uploaded to unstable.

Ximin

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

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

Versions of packages julia depends on:
pn  julia-common  
ii  libc6 2.31-3
ii  libcurl3-gnutls   7.72.0-1
pn  libdsfmt-19937-1  
ii  libgcc-s1 10.2.0-9
ii  libgfortran5  10.2.0-9
ii  libgit2-280.28.5+dfsg.1-1
ii  libgmp10  2:6.2.0+dfsg-6
pn  libjulia1 
pn  libllvm8  
ii  libmbedcrypto32.16.5-1
ii  libmbedtls12  2.16.5-1
ii  libmbedx509-0 2.16.5-1
ii  libmpfr6  4.1.0-3
pn  libopenlibm3  
ii  libpcre2-8-0  10.34-7
ii  libquadmath0  10.2.0-9
ii  libssh2-1 1.8.0-2.1
ii  libunwind81.3.2-2
ii  libutf8proc2  2.5.0-1

Versions of packages julia recommends:
ii  git  1:2.28.0-1
ii  openssl  1.1.1g-1

Versions of packages julia suggests:
pn  ess
pn  julia-doc  
pn  vim-julia  

Bug#919893: rng-tools-debian: package shouldn't exist

[Thorsten Glaser]

retitle 919893 rng-tools-debian: please take over rng-tools with a proper 
transition
thanks

Michael Stone dixit:

> On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote:
>> Michael Stone dixit:
>>
>>> you can fix it right now!
>>
>> So, what do you mean? Take over the rng-tools package?
>>
>> If so, it has a maintainer, you know. hmh has been quiet so far.
>
> he's been clear that he's happy for someone to take it over, or did you talk 
> to
> him before uploading your package and he told you that you'd have to create
> your own because rng-tools was off limits?

I’ve not seen that. Please shout loud if this is not okay, otherwise
I will proceed doing this. I asked around doing bugreports, which got
no reaction, but I don’t remember if I (also) asked hmh directly.

Now gimme some time, I’m deep in multiple other things right now.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#969609: [Pkg-rust-maintainers] Bug#969609: Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe

[Ximin Luo]

Steve Langasek:
> Ximin,
> 
> On Tue, Sep 08, 2020 at 09:23:49PM +0100, Ximin Luo wrote:
>> You keep filing these same bugs.  I have told you this many times before
>> already: this is just how rust packaging works, Britney's migration policy
>> already prevents these packages from reaching Debian Testing, so there is
>> no problem, no users are affected.
> 
>> You filing these bug reports accomplishes nothing, except delay & annoy
>> other Rust packagers who forget to close these pointless bugs, thereby
>> unnecessarily blocking any fixed packages from actually reaching Debian
>> Testing.  Oftentimes the fix is also not to update the package itself, but
>> to upload another package.  Due to the idiosyncracies of the BTS, not
>> everyone knows how to close these bugs correctly (notfound -1 $version)
>> and it will result in further delays.
> 
>> Please stop filing these bug reports, they only create extra unnecessary
>> work for other people, and make Debian worse for users, by slowing down
>> the stream of fixes.  Britney already prevents Testing migration.
> 
> It is not credible to me that this is "just how rust packaging works".  The
> bugs I am filing are against packages that have been uninstallable in
> unstable for more than 4 months.  The missing dependencies are not in the
> NEW queue, and there are no ITP bugs filed for them.  There is no reason to
> believe, without filing these bugs, that anyone on the rust packaging team
> is doing anything about these missing dependencies.
> 

Why is it not credible? I am one of the main members of the team, and created 
about 80% of the current process. I am telling you it is simply how it works. 
If you want an in-depth description, see 
https://github.com/kpcyrd/cargo-debstatus/issues/2. In summary, it is because 
the Rust dependency system encodes complex dependency relationships in a more 
efficient way than the Debian dependency system, meaning the typical Rust 
package expresses more complex dependencies than most other Debian packages. 
But you can get this type of situation with other languages too, especially 
those with bootstrap loops. The only difference is in Rust it's much more 
common.

(The NEW queue is another unresolved issue that is blocking Rust packaging - we 
have a policy disagreement with the FTP team and nobody has had time to resolve 
it. That is why things might not be on the NEW queue.)

At the end of the day, it doesn't matter if people don't do anything about 
these missing dependencies, because *the britney migration script prevents 
migration to testing*. For the packages that matter, i.e. that need to be 
migrated to testing (& eventually stable), members of this team are forced to 
fix these issues anyway, and we have a documented process for doing this:

https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/RELEASE.rst

> And filing bug reports in the Debian BTS is the standard way in Debian to
> document bugs in packages.
> 
> And it is unacceptable that Debian maintainers don't know how to operate the
> Debian BTS.
> 

Most Debian Rust Team members are not regular Debian maintainers. And the 
Debian BTS user interface is really unintuitive. So I can't reasonably consider 
it "unacceptable", we have to be realistic regarding volunteer on-boarding.

> So no, I will not stop filing bugs against RC-buggy packages that the Rust
> maintainers are clearly not taking care of.  If you don't want bug reports,
> you have the option to stop uploading packages that are RC buggy from the
> moment they're accepted into the archive.
> 

I am explaining to you why the normal Debian process is inadequate and causes 
more work for everyone in this case. Please trust your fellow maintainers more 
on matters on which they have more expertise. After all of my explanations, 
what benefit do you suppose these bugs are giving?? You filing bug reports is 
not going to magically give people more free time to fix them; when they have 
the free time these problems are automatically and forcibly solved as part of 
our regular process. The bugs do not help this one bit.

Best
Ximin

-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#971360: fonts-noto-color-emoji: error in glyphs display

[Jeremy Bicha]

On Thu, Oct 1, 2020 at 7:51 PM Josh Triplett  wrote:
> I noticed this as well. Specifically, the thumbs-up emoji (U+1F44D)
> renders as a thumbs-down emoji.

Have either of you tried logging out and logging back in or restarting
your computer?

Fonts can display very badly when updated on a running system. This is
perhaps even more likely when the font has major changes like the
recent update of this emoji font. This kind of issue is one reason why
Fedora has strongly encouraged "offline" updates for a few years now.

Thanks,
Jeremy Bicha

Bug#919893: rng-tools-debian: package shouldn't exist

[Michael Stone]

On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote:

Michael Stone dixit:


you can fix it right now!


So, what do you mean? Take over the rng-tools package?

If so, it has a maintainer, you know. hmh has been quiet so far.


he's been clear that he's happy for someone to take it over, or did you 
talk to him before uploading your package and he told you that you'd 
have to create your own because rng-tools was off limits?

Bug#971568: geany-plugins: libgit2 1.0 transition

[Ximin Luo]

Package: geany-plugins
Version: 1.36+dfsg-1.1
Severity: important
Tags: upstream

Dear Maintainer,

libgit2 1.0 is now available in experimental, however geany-plugins FTBFS 
against it.

Sample error:

In file included from /usr/include/git2.h:69,
 from gcb-plugin.c:29:
gcb-plugin.c:35:38: error: token ""1.0"" is not valid in preprocessor 
expressions
   35 | #if ! defined (LIBGIT2_SOVERSION) || LIBGIT2_SOVERSION < 22
  |  ^
gcb-plugin.c:39:38: error: token ""1.0"" is not valid in preprocessor 
expressions
   39 | #if ! defined (LIBGIT2_SOVERSION) || LIBGIT2_SOVERSION < 23
  |  ^
gcb-plugin.c:48:38: error: token ""1.0"" is not valid in preprocessor 
expressions
   48 | #if ! defined (LIBGIT2_SOVERSION) || LIBGIT2_SOVERSION < 28
  |  ^

It looks like these tests need to be updated; in particular the macros
LIBGIT2_VER_MAJOR and LIBGIT2_VER_MINOR are available for use.
There may be other errors after fixing this.

Please make sure your package is ready for this version by the time we upload
this package to unstable in one to two weeks. The severity of this report will
be raised to serious once libgit2 1.0 is uploaded to unstable.

Ximin

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

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

Versions of packages geany-plugins depends on:
pn  geany-plugin-addons  
pn  geany-plugin-autoclose   
pn  geany-plugin-automark
pn  geany-plugin-codenav 
pn  geany-plugin-commander   
pn  geany-plugin-ctags   
pn  geany-plugin-defineformat
pn  geany-plugin-doc 
pn  geany-plugin-extrasel
pn  geany-plugin-gendoc  
pn  geany-plugin-geniuspaste 
pn  geany-plugin-git-changebar   
pn  geany-plugin-insertnum   
pn  geany-plugin-keyrecord   
pn  geany-plugin-latex   
pn  geany-plugin-lineoperations  
pn  geany-plugin-lipsum  
pn  geany-plugin-lua 
pn  geany-plugin-macro   
pn  geany-plugin-miniscript  
pn  geany-plugin-numberedbookmarks   
pn  geany-plugin-overview
pn  geany-plugin-pairtaghighlighter  
pn  geany-plugin-pg  
pn  geany-plugin-pohelper
pn  geany-plugin-prettyprinter   
pn  geany-plugin-prj 
pn  geany-plugin-projectorganizer
pn  geany-plugin-sendmail
pn  geany-plugin-shiftcolumn 
pn  geany-plugin-spellcheck  
pn  geany-plugin-tableconvert
pn  geany-plugin-treebrowser 
pn  geany-plugin-updatechecker   
pn  geany-plugin-vc  
pn  geany-plugin-vimode  
pn  geany-plugin-workbench   
pn  geany-plugin-xmlsnippets 

geany-plugins recommends no packages.

geany-plugins suggests no packages.

Bug#712451: [pkg-apparmor] Bug#712451: Please support AppArmor network rules

[Andrew Savchenko]

Greetings,

As AppArmor v3.0 is now released[1], is there a chance that network, dbus and
sockets will be supported in Bullseye?

[1] https://lists.ubuntu.com/archives/apparmor/2020-October/012183.html


-- 
Regards,
A

Bug#971360: fonts-noto-color-emoji: error in glyphs display

[Josh Triplett]

Package: fonts-noto-color-emoji
Version: 0~20200916-1
Followup-For: Bug #971360
X-Debbugs-Cc: j...@joshtriplett.org

I noticed this as well. Specifically, the thumbs-up emoji (U+1F44D)
renders as a thumbs-down emoji.

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

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

-- no debconf information

Bug#971567: libgit-raw-perl: libgit2 1.0 transition

[Ximin Luo]

Package: libgit-raw-perl
Version: 0.79-7
Severity: important
Tags: upstream

Dear Maintainer,

libgit2 1.0 is now available in experimental. Please make sure your
package is ready for this version by the time we upload this package to
unstable in one to two weeks. The severity of this report will be raised
to serious once libgit2 1.0 is uploaded to unstable.

Ximin

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

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

Versions of packages libgit-raw-perl depends on:
ii  libc6   2.31-3
ii  libgit2-28  0.28.5+dfsg.1-1
ii  perl5.30.3-4
ii  perl-base [perlapi-5.30.0]  5.30.3-4

libgit-raw-perl recommends no packages.

libgit-raw-perl suggests no packages.

Bug#971561: cloud.debian.org: ARM-based Buster AMIs don't support new T4g instance types

[Noah Meyerhans]

I've confirmed that the Marketplace UI still doesn't let us enable t4g.*
and opened a support request with AWS to see if they can enable this for
us.

For now, use the AMIs listed at
https://wiki.debian.org/Cloud/AmazonEC2Image/Buster

Bug#919893: rng-tools-debian: package shouldn't exist

[Thorsten Glaser]

Michael Stone dixit:

> you can fix it right now!

So, what do you mean? Take over the rng-tools package?

If so, it has a maintainer, you know. hmh has been quiet so far.

> you keep talking about launchpad, but this is a conversation in debian 
> channels
> about a debian package. what ubuntu did is irrelevant, what matters is the

It’s not “what Ubuntu did”. One of the developers suggested this
solution to me there, so it was just using Launchpad as communication
channel. Please read what was actually written, not just the label.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#971566: kup-backup: libgit2 1.0 transition

[Ximin Luo]

Package: kup-backup
Version: 0.7.3+dfsg-1
Severity: important
Tags: patch upstream

Dear Maintainer,

libgit2 1.0 is now available in experimental. I have built kup-backup against
it, it needs the attached patch to work. Please forward it upstream and also
apply it in this Debian package.

The severity of this report will be raised to serious once libgit2 1.0 is
uploaded to unstable.

Thanks
Ximin

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

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

Versions of packages kup-backup depends on:
ii  kio5.70.1-1
ii  libc6  2.31-3
ii  libgcc-s1  10.2.0-9
ii  libgit2-28 0.28.5+dfsg.1-1
ii  libkf5completion5  5.70.0-1
ii  libkf5configcore5  5.70.0-1
ii  libkf5configwidgets5   5.70.0-2
ii  libkf5coreaddons5  5.70.0-2
ii  libkf5dbusaddons5  5.70.0-1
ii  libkf5i18n55.70.0-1
ii  libkf5iconthemes5  5.70.0-1
ii  libkf5idletime55.70.0-1
ii  libkf5jobwidgets5  5.70.0-1
ii  libkf5kiocore5 5.70.1-1
ii  libkf5kiofilewidgets5  5.70.1-1
ii  libkf5kiowidgets5  5.70.1-1
ii  libkf5notifications5   5.70.0-1
pn  libkf5plasma5  
ii  libkf5solid5   5.70.0-1
ii  libkf5widgetsaddons5   5.70.0-1
ii  libkf5xmlgui5  5.70.0-1+b1
ii  libqt5core5a   5.14.2+dfsg-6
ii  libqt5dbus55.14.2+dfsg-6
ii  libqt5gui5 5.14.2+dfsg-6
ii  libqt5network5 5.14.2+dfsg-6
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libstdc++6 10.2.0-9

Versions of packages kup-backup recommends:
pn  bup
ii  rsync  3.2.3-2

kup-backup suggests no packages.
--- a/filedigger/main.cpp
+++ b/filedigger/main.cpp
@@ -21,10 +21,10 @@
 #include "filedigger.h"
 #include "mergedvfs.h"
 
-#if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR >= 24
-#include 
-#else
+#if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR < 24
 #include 
+#else
+#include 
 #endif
 
 #include 
@@ -69,19 +69,19 @@
}
 
// This needs to be called first thing, before any other calls to 
libgit2.
-   #if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR >= 24
-   git_libgit2_init();
-   #else
+   #if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR < 24
git_threads_init();
+   #else
+   git_libgit2_init();
#endif
 
FileDigger *lFileDigger = new FileDigger(lRepoPath, 
lParser.value(QStringLiteral("branch")));
lFileDigger->show();
int lRetVal = lApp.exec();
-   #if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR >= 24
-   git_libgit2_shutdown();
-   #else
+   #if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR < 24
git_threads_shutdown();
+   #else
+   git_libgit2_shutdown();
#endif
return lRetVal;
 }
--- a/kioslave/bupslave.cpp
+++ b/kioslave/bupslave.cpp
@@ -63,10 +63,10 @@
 {
mRepository = nullptr;
mOpenFile = nullptr;
-   #if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR >= 24
-   git_libgit2_init();
-   #else
+   #if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR < 24
git_threads_init();
+   #else
+   git_libgit2_init();
#endif
 }
 
@@ -74,10 +74,10 @@
if(mRepository != nullptr) {
delete mRepository;
}
-   #if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR >= 24
-   git_libgit2_shutdown();
-   #else
+   #if LIBGIT2_VER_MAJOR == 0 && LIBGIT2_VER_MINOR < 24
git_threads_shutdown();
+   #else
+   git_libgit2_shutdown();
#endif
 }
 

Bug#919893: rng-tools-debian: package shouldn't exist

[Michael Stone]

On Thu, Oct 01, 2020 at 09:32:47PM +, Thorsten Glaser wrote:

Michael Stone dixit:


So your position is that rng-tools 2-unofficial-mt.14-1+b2 and rng-tools-debian
2-unofficial-mt.14-3 both in buster are completely different codebases?


No, no, no, of course not. I’m talking about sid (and therefore testing).

Even before the release of buster, rng-tools in sid was 5 already and
therefore unusable. It simply did not migrate in time for buster,
thankfully, but the presence of rng-tools-debian would have helped,
even so, to alleviate that.


It was a botched NMU which happened without discussion. The fix is to 
overwrite it with a new package.



Yes, after both getting a suggestion to do so (via Launchpad) from
one of the developers involved *and* running into the problem that
rng-tools (in sid) was version 5 and that not getting fixed.


you can fix it right now!


come up with a better name. rng-tools-legacy makes more sense, or you could


It would have made more sense, but we’re past release now, so…


you can transition right now! I really don't understand why your 
attitude has been "I did this thing, I'm not going to change it, and I'm 
not going to take the remaining steps needed to resolve the mess".



rng-tools-debian because you really want to please at least take care of
cleaning up the rng-tools transition.


I could take over rng-tools and transition them to rng-tools-debian,
but this isn’t desired in most cases, so this is really between the
maintainers of rng-tools and rng-tools5 in my eyes.


there is *no* migration path between rng-tools legacy and rng-tools5. 
The only transition that makes sense *for debian users* is to 
consolidate rng-tools and rng-tools-debian. *Of course* the migration 
that's desired for debian users is to migrate from rng-tools to some 
other rng-tools legacy package, otherwise people would be running 
rng-tools5.


you keep talking about launchpad, but this is a conversation in debian 
channels about a debian package. what ubuntu did is irrelevant, what 
matters is the experience for users of debian (particularly debian 
stable, for which the situation is as I outlined in the previous mail)
The situation in debian unstable is messier *but there is a reason we 
call it unstable* and it's better to fix the situation for released 
versions than to worry about unstable users.

Bug#971561: cloud.debian.org: ARM-based Buster AMIs don't support new T4g instance types

[Noah Meyerhans]

On Thu, Oct 01, 2020 at 05:40:02PM -0500, Ryan Thoryk wrote:
> I've been wanting to run Debian on Amazon's new T4g instances, which utilize
> the ARM-based Graviton2 processor.  The current AMI's don't appear to support
> this, and I assumed it would be fixed as part of the 10.6 update, which it
> wasn't.

They do:

admin@ip-10-0-0-252:~$ ec2metadata --ami-id ; ec2metadata --availability-zone ; 
ec2metadata --instance-type ; cat /etc/debian_version ; uname -a
ami-0d2c5c43cf2ea11a3
us-west-2a
t4g.medium
10.6
Linux ip-10-0-0-252 4.19.0-11-arm64 #1 SMP Debian 4.19.146-1 (2020-09-17) 
aarch64 GNU/Linux

Are you trying to launch from the AWS Marketplace?  They might not be
listed as supporting t4g there, since last time I checked, the
Marketplace UI didn't actually have an option to select t4g support.

The only issue with the current AMIs on t4g is that they don't support
CPU steal-time accounting, which might make it in to 10.7 if the kernel
team is willing to merge
https://salsa.debian.org/kernel-team/linux/-/merge_requests/268

noah

Bug#971565: ruby-rugged: libgit2 1.0 transition

[Ximin Luo]

Package: ruby-rugged
Version: 0.28.4.1+ds-1
Severity: important
Tags: upstream

Dear Maintainer,

libgit2 1.0 is now available in experimental. Please make sure your
package is ready for this version by the time we upload this package to
unstable in one to two weeks. The severity of this report will be raised
to serious once libgit2 1.0 is uploaded to unstable.

Thanks
Ximin

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

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

Versions of packages ruby-rugged depends on:
ii  libc6   2.31-3
ii  libgit2-28  0.28.5+dfsg.1-1
ii  libruby2.7  2.7.1-3
ii  ruby1:2.7+1

ruby-rugged recommends no packages.

ruby-rugged suggests no packages.

Bug#971564: python-pygit2: libgit2 1.0 transition

[Ximin Luo]

Source: python-pygit2
Version: 1.0.3-1
Severity: important
Tags: upstream

Dear Maintainer,

libgit2 1.0 is now available in experimental. Please make sure your
package is ready for this version by the time we upload this package to
unstable in one to two weeks. The severity of this report will be raised
to serious once libgit2 1.0 is uploaded to unstable.

Thanks
Ximin

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

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

Bug#971562: gall: libgit2 1.0 transition

[Ximin Luo]

Source: gall
Version: 1.3-1
Severity: important
Tags: upstream

Dear Maintainer,

libgit2 1.0 is now available in experimental. Please make sure your 
package is ready for this version by the time we upload this package to 
unstable in one to two weeks. The severity of this report will be raised 
to serious once libgit2 1.0 is uploaded to unstable.

Thanks
Ximin


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

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

Bug#971563: libgit2-glib: libgit2 1.0 transition

[Ximin Luo]

Source: libgit2-glib
Version: 0.28.0.1-2
Severity: important

Dear Maintainer,

libgit2 1.0 is now available in experimental. Please make sure your
package is ready for this version by the time we upload this package to
unstable in one to two weeks. The severity of this report will be raised
to serious once libgit2 1.0 is uploaded to unstable.

Thanks
Ximin

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

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

Bug#971561: cloud.debian.org: ARM-based Buster AMIs don't support new T4g instance types

[Ryan Thoryk]

Package: cloud.debian.org
Severity: wishlist

Dear Maintainer,

I've been wanting to run Debian on Amazon's new T4g instances, which utilize
the ARM-based Graviton2 processor.  The current AMI's don't appear to support
this, and I assumed it would be fixed as part of the 10.6 update, which it
wasn't.



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

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

Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files

[Sylvain Beucler]

Hi,

Thanks for report this issue.

Something must have gone wrong when rebuilding the packages at Debian,
because the packages I had built didn't have these differences. I just
ran a local rebuild and I still have valid packages, with all the files.

It's night-time here so I won't look in depth right now, but
https://buildd.debian.org/status/package.php?p=sane-backends=stretch-security
should contain possible errors.

This could be due to a bug when building the 'all' and 'amd64' packages
separately.

Cheers!
Sylvain

Bug#968863: dexdump: Manual page bad

[Philipp Marek]

Package: dexdump
Version: 8.1.0+r23-4
Followup-For: Bug #968863

The manual page of dexdump says 

NAME
   dexdump - Dex Tool

DESCRIPTION
   debian/out/dexdump: error while loading shared libraries: 
libsigchain.so.0: cannot open shared object file: No such file or directory

which isn't that helpful



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

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

Versions of packages dexdump depends on:
ii  android-libart   8.1.0+r23-4
ii  android-libbase  1:8.1.0+r23-7
ii  libc62.31-3
ii  libgcc-s110.2.0-9
ii  libstdc++6   10.2.0-9

dexdump recommends no packages.

dexdump suggests no packages.

-- no debconf information

-- 

Bug#919893: rng-tools-debian: package shouldn't exist

[Thorsten Glaser]

Michael Stone dixit:

> So your position is that rng-tools 2-unofficial-mt.14-1+b2 and 
> rng-tools-debian
> 2-unofficial-mt.14-3 both in buster are completely different codebases?

No, no, no, of course not. I’m talking about sid (and therefore testing).

Even before the release of buster, rng-tools in sid was 5 already and
therefore unusable. It simply did not migrate in time for buster,
thankfully, but the presence of rng-tools-debian would have helped,
even so, to alleviate that.

> Then someone decided to NMU rng-tools with a patch to basically make it a copy
> of rng-tools5. That never made it to release, and buster was released with 
> both
> rng-tools (legacy) and rng-tools5.

It was never reverted. By current migration rules, rng-tools 2.x would
even have been removed from testing prior to the release because the
then-5.x in unstable did not migrate to testing for long.

> And into that you uploaded *another copy* of rng-tools.

Yes, after both getting a suggestion to do so (via Launchpad) from
one of the developers involved *and* running into the problem that
rng-tools (in sid) was version 5 and that not getting fixed.

> Ideally you would come up with a transition mechanism to move rng-tools users
> to some other package name because you are the one who has laid claim to that
> codebase.

Upstream expressed an interest of migrating existing users of rng-tools
to rng-tools5 if at all possible so the rng-tools5 maintainers are
invited to transition like that.

> I still believe that rng-tools-debian is a terrible name because it

Yes. If these concerns were raised in time, we could have easily
renamed it before the buster release. (The package was already in
existence for some time because *buntu had the 5 versions much
earlier, but I’d have ignored that and dealt with it.)

Back then, 5 was the *buntu version and 2 the Debian version,
so the naming was somewhat caused from that.

> is not sponsored by the debian project and because the name does not give any
> hints to users about why they might want to use the package. If anything it

I’ve long added this to the package description:

 This is an unofficial version of rng-tools which has been extensively
 modified to add multithreading and a lot of new functionality. However,
 most users of newer or high-bandwidth HWRNGs might wish to install the
 5.x version of rng-tools, also packaged as rng-tools5, instead; while
 it lacks some of the new functionality from this version, it offers
 more performant support for those.

The package is also “native” now, so it’s kinda “the one that contains
tons of changes developed during Debian packaging historically”. Let’s
take this as naming reason, because changing the name _now_ is going
to be more hassle than it is worth and with the package descriptions in
both packages adjusted suitably, users will be made aware of it.

(Changes to the rng-tools-debian description to express this more
clearly and in a more native English language are, of course, very
welcome. Just drop me an eMail.)

> come up with a better name. rng-tools-legacy makes more sense, or you could

It would have made more sense, but we’re past release now, so…

> rng-tools-debian because you really want to please at least take care of
> cleaning up the rng-tools transition.

I could take over rng-tools and transition them to rng-tools-debian,
but this isn’t desired in most cases, so this is really between the
maintainers of rng-tools and rng-tools5 in my eyes.

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr

Bug#971560: Acknowledgement (libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files)

[Ivan Baldo]

Also debdiff libsane_1.0.25-4.1_amd64.deb
libsane_1.0.25-4.1+deb9u1_amd64.deb shows:

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/sane/libsane-dll.la
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/sane/libsane-dll.so.1.0.25
lrwxrwxrwx  root/root
/usr/lib/x86_64-linux-gnu/sane/libsane-dll.so.1 ->
libsane-dll.so.1.0.25

sane-utils package seems ok, with the same files.

Thanks!

Bug#969141: websocketpp: errors while generating documentation & FTBFS with doxygen 1.8.19

[Gianfranco Costamagna]

control: tags -1 pending

Since it is collaborative maintained, I just uploaded and committed the patch 
on git

thanks!

G.

Bug#971560: libsane-common 1.0.25-4.1+deb9u1 Stretch security update missing lots of files

[Ivan Baldo]

Package: libsane-common
Version: 1.0.25-4.1+deb9u1
Severity: important

Scanners look differently now, some not even appear on the network
(through saned), etc.

debdiff libsane-common_1.0.25-4.1_all.deb
libsane-common_1.0.25-4.1+deb9u1_all.deb shows:

Files in first .deb but not in second
-
-rw-r--r--  root/root   /etc/sane.d/abaton.conf
-rw-r--r--  root/root   /etc/sane.d/agfafocus.conf
-rw-r--r--  root/root   /etc/sane.d/apple.conf
-rw-r--r--  root/root   /etc/sane.d/artec.conf
-rw-r--r--  root/root   /etc/sane.d/artec_eplus48u.conf
-rw-r--r--  root/root   /etc/sane.d/avision.conf
-rw-r--r--  root/root   /etc/sane.d/bh.conf
-rw-r--r--  root/root   /etc/sane.d/canon.conf
-rw-r--r--  root/root   /etc/sane.d/canon630u.conf
-rw-r--r--  root/root   /etc/sane.d/canon_dr.conf
-rw-r--r--  root/root   /etc/sane.d/canon_pp.conf
-rw-r--r--  root/root   /etc/sane.d/cardscan.conf
-rw-r--r--  root/root   /etc/sane.d/coolscan.conf
-rw-r--r--  root/root   /etc/sane.d/coolscan2.conf
-rw-r--r--  root/root   /etc/sane.d/coolscan3.conf
-rw-r--r--  root/root   /etc/sane.d/dc210.conf
-rw-r--r--  root/root   /etc/sane.d/dc240.conf
-rw-r--r--  root/root   /etc/sane.d/dc25.conf
-rw-r--r--  root/root   /etc/sane.d/dell1600n_net.conf
-rw-r--r--  root/root   /etc/sane.d/dll.conf
-rw-r--r--  root/root   /etc/sane.d/dmc.conf
-rw-r--r--  root/root   /etc/sane.d/epjitsu.conf
-rw-r--r--  root/root   /etc/sane.d/epson.conf
-rw-r--r--  root/root   /etc/sane.d/epson2.conf
-rw-r--r--  root/root   /etc/sane.d/epsonds.conf
-rw-r--r--  root/root   /etc/sane.d/fujitsu.conf
-rw-r--r--  root/root   /etc/sane.d/genesys.conf
-rw-r--r--  root/root   /etc/sane.d/gphoto2.conf
-rw-r--r--  root/root   /etc/sane.d/gt68xx.conf
-rw-r--r--  root/root   /etc/sane.d/hp.conf
-rw-r--r--  root/root   /etc/sane.d/hp3900.conf
-rw-r--r--  root/root   /etc/sane.d/hp4200.conf
-rw-r--r--  root/root   /etc/sane.d/hp5400.conf
-rw-r--r--  root/root   /etc/sane.d/hpsj5s.conf
-rw-r--r--  root/root   /etc/sane.d/hs2p.conf
-rw-r--r--  root/root   /etc/sane.d/ibm.conf
-rw-r--r--  root/root   /etc/sane.d/kodak.conf
-rw-r--r--  root/root   /etc/sane.d/kodakaio.conf
-rw-r--r--  root/root   /etc/sane.d/leo.conf
-rw-r--r--  root/root   /etc/sane.d/lexmark.conf
-rw-r--r--  root/root   /etc/sane.d/ma1509.conf
-rw-r--r--  root/root   /etc/sane.d/magicolor.conf
-rw-r--r--  root/root   /etc/sane.d/matsushita.conf
-rw-r--r--  root/root   /etc/sane.d/microtek.conf
-rw-r--r--  root/root   /etc/sane.d/microtek2.conf
-rw-r--r--  root/root   /etc/sane.d/mustek.conf
-rw-r--r--  root/root   /etc/sane.d/mustek_pp.conf
-rw-r--r--  root/root   /etc/sane.d/mustek_usb.conf
-rw-r--r--  root/root   /etc/sane.d/nec.conf
-rw-r--r--  root/root   /etc/sane.d/net.conf
-rw-r--r--  root/root   /etc/sane.d/p5.conf
-rw-r--r--  root/root   /etc/sane.d/pie.conf
-rw-r--r--  root/root   /etc/sane.d/pieusb.conf
-rw-r--r--  root/root   /etc/sane.d/pixma.conf
-rw-r--r--  root/root   /etc/sane.d/plustek.conf
-rw-r--r--  root/root   /etc/sane.d/plustek_pp.conf
-rw-r--r--  root/root   /etc/sane.d/qcam.conf
-rw-r--r--  root/root   /etc/sane.d/ricoh.conf
-rw-r--r--  root/root   /etc/sane.d/rts8891.conf
-rw-r--r--  root/root   /etc/sane.d/s9036.conf
-rw-r--r--  root/root   /etc/sane.d/sceptre.conf
-rw-r--r--  root/root   /etc/sane.d/sharp.conf
-rw-r--r--  root/root   /etc/sane.d/sm3840.conf
-rw-r--r--  root/root   /etc/sane.d/snapscan.conf
-rw-r--r--  root/root   /etc/sane.d/sp15c.conf
-rw-r--r--  root/root   /etc/sane.d/st400.conf
-rw-r--r--  root/root   /etc/sane.d/stv680.conf
-rw-r--r--  root/root   /etc/sane.d/tamarack.conf
-rw-r--r--  root/root   /etc/sane.d/teco1.conf
-rw-r--r--  root/root   /etc/sane.d/teco2.conf
-rw-r--r--  root/root   /etc/sane.d/teco3.conf
-rw-r--r--  root/root   /etc/sane.d/test.conf
-rw-r--r--  root/root   /etc/sane.d/u12.conf
-rw-r--r--  root/root   /etc/sane.d/umax.conf
-rw-r--r--  root/root   /etc/sane.d/umax1220u.conf
-rw-r--r--  root/root   /etc/sane.d/umax_pp.conf
-rw-r--r--  root/root   /etc/sane.d/xerox_mfp.conf
-rw-r--r--  root/root   /usr/share/doc/libsane/AUTHORS.gz
-rw-r--r--  root/root   /usr/share/doc/libsane/NEWS.gz
-rw-r--r--  root/root   /usr/share/doc/libsane/PROBLEMS
-rw-r--r--  root/root   /usr/share/doc/libsane/PROJECTS
-rw-r--r--  root/root   /usr/share/doc/libsane/README.gz
-rw-r--r--  root/root   /usr/share/doc/libsane/backend-writing.txt.gz
-rw-r--r--  root/root   /usr/share/doc/libsane/canon/canon.changes
-rw-r--r--  root/root   /usr/share/doc/libsane/canon/canon.install2700F.txt.gz
-rw-r--r--  root/root   /usr/share/doc/libsane/gt68xx/gt68xx.CHANGES.gz
-rw-r--r--  root/root   /usr/share/doc/libsane/gt68xx/gt68xx.TODO
-rw-r--r--  root/root   /usr/share/doc/libsane/leo/leo.txt
-rw-r--r--  root/root   /usr/share/doc/libsane/matsushita/matsushita.txt.gz
-rw-r--r--  root/root   /usr/share/doc/libsane/mustek/mustek.CHANGES.gz
-rw-r--r--  root/root   /usr/share/doc/libsane/mustek_usb/mustek_usb.CHANGES.gz
-rw-r--r--  root/root   

Bug#971558: clucene-core FTCBFS: uses CHECK_CXX_SOURCE_RUNS

[Helmut Grohne]

Source: clucene-core
Version: 2.3.3.4+dfsg-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

clucene-core fails to cross build from source, because it uses
CHECK_CXX_SOURCE_RUNS in a number of places. In some cases, it is used
for checking whether a particular syntax is supported by the compiler.
There, we can simply use CHECK_CXX_SOURCE_COMPILES at no loss. In some
cases, runtime bugs are checked. The best course of action here is to
assume that there are no runtime bugs (but only for cross compilation).
The attached patch implements that for all relevant checks. Please
consider applying it to make clucene-core cross buildable.

Helmut
--- clucene-core-2.3.3.4+dfsg.orig/src/shared/cmake/CheckNamespace.cmake
+++ clucene-core-2.3.3.4+dfsg/src/shared/cmake/CheckNamespace.cmake
@@ -1,8 +1,8 @@
 #check if we support namespaces
 MACRO ( CHECK_NAMESPACE haveNamespace )
 #Check if namespaces work in the compiler
-CHECK_CXX_SOURCE_RUNS("
+CHECK_CXX_SOURCE_COMPILES("
 	namespace Outer { namespace Inner { int i = 0; }}
 	int main(){ using namespace Outer::Inner; return i; }" 
 	${haveNamespace} )
-ENDMACRO ( CHECK_NAMESPACE haveNamespace )
\ No newline at end of file
+ENDMACRO ( CHECK_NAMESPACE haveNamespace )
--- clucene-core-2.3.3.4+dfsg.orig/src/shared/cmake/CheckSnprintf.cmake
+++ clucene-core-2.3.3.4+dfsg/src/shared/cmake/CheckSnprintf.cmake
@@ -1,42 +1,46 @@
 #checks if snprintf have bugs
 
 MACRO ( CHECK_SNPRINTF )
-#check that our snprintf works correctly...
-IF ( _CL_HAVE_FUNCTION_SNPRINTF )
-CHECK_CXX_SOURCE_RUNS("
-	#include 
-	int main(){
-		char ovbuf[7];
-		int i;
-		for (i=0; i<7; i++) ovbuf[i]='x';
-		snprintf(ovbuf, 4,\"foo%s\", \"bar\");
-		if (ovbuf[5]!='x') return 1;
-		snprintf(ovbuf, 4,\"foo%d\", 666);
-		if (ovbuf[5]!='x') return 1;
-		return 0;
-	}" _CL_HAVE_NO_SNPRINTF_BUG) 
-	IF ( NOT _CL_HAVE_NO_SNPRINTF_BUG )
-		SET ( _CL_HAVE_SNPRINTF_BUG 1 )
-		MESSAGE ( FATAL_ERROR "snprintf has a bug, and we don't have a replacement!" )
-	ENDIF ( NOT _CL_HAVE_NO_SNPRINTF_BUG )
-ENDIF ( _CL_HAVE_FUNCTION_SNPRINTF )
-
-#check that our swnprintf works correctly...
-IF ( _CL_HAVE_FUNCTION_SNWPRINTF )
-CHECK_CXX_SOURCE_RUNS("
-	#include 
-	#include 
-	
-	int main(void)
-	{
-	wchar_t buf[5];
-	snwprintf(buf,5,L\"%s\",L\"foo\");
-	if ( wcslen(buf) != 3 )
-		return 1;
-	return 0;
-	}" _CL_HAVE_NO_SNWPRINTF_BUG) 
-	IF ( NOT _CL_HAVE_NO_SNWPRINTF_BUG )
-		SET ( _CL_HAVE_SNWPRINTF_BUG 1 )
-	ENDIF ( NOT _CL_HAVE_NO_SNWPRINTF_BUG )
-ENDIF ( _CL_HAVE_FUNCTION_SNWPRINTF )
+IF ( CMAKE_CROSSCOMPILING )
+MESSAGE ( WARNING "cannot check for snprintf bugs during cross compilation")
+ELSE ( CMAKE_CROSSCOMPILING )
+#check that our snprintf works correctly...
+IF ( _CL_HAVE_FUNCTION_SNPRINTF )
+CHECK_CXX_SOURCE_RUNS("
+	#include 
+	int main(){
+		char ovbuf[7];
+		int i;
+		for (i=0; i<7; i++) ovbuf[i]='x';
+		snprintf(ovbuf, 4,\"foo%s\", \"bar\");
+		if (ovbuf[5]!='x') return 1;
+		snprintf(ovbuf, 4,\"foo%d\", 666);
+		if (ovbuf[5]!='x') return 1;
+		return 0;
+	}" _CL_HAVE_NO_SNPRINTF_BUG)
+	IF ( NOT _CL_HAVE_NO_SNPRINTF_BUG )
+		SET ( _CL_HAVE_SNPRINTF_BUG 1 )
+		MESSAGE ( FATAL_ERROR "snprintf has a bug, and we don't have a replacement!" )
+	ENDIF ( NOT _CL_HAVE_NO_SNPRINTF_BUG )
+ENDIF ( _CL_HAVE_FUNCTION_SNPRINTF )
+
+#check that our swnprintf works correctly...
+IF ( _CL_HAVE_FUNCTION_SNWPRINTF )
+CHECK_CXX_SOURCE_RUNS("
+	#include 
+	#include 
+
+	int main(void)
+	{
+	wchar_t buf[5];
+	snwprintf(buf,5,L\"%s\",L\"foo\");
+	if ( wcslen(buf) != 3 )
+		return 1;
+	return 0;
+	}" _CL_HAVE_NO_SNWPRINTF_BUG)
+	IF ( NOT _CL_HAVE_NO_SNWPRINTF_BUG )
+		SET ( _CL_HAVE_SNWPRINTF_BUG 1 )
+	ENDIF ( NOT _CL_HAVE_NO_SNWPRINTF_BUG )
+ENDIF ( _CL_HAVE_FUNCTION_SNWPRINTF )
+ENDIF ( CMAKE_CROSSCOMPILING )
 ENDMACRO ( CHECK_SNPRINTF )
--- clucene-core-2.3.3.4+dfsg.orig/src/shared/cmake/CheckAtomicFunctions.cmake
+++ clucene-core-2.3.3.4+dfsg/src/shared/cmake/CheckAtomicFunctions.cmake
@@ -3,7 +3,7 @@
 MACRO ( CHECK_HAVE_GCC_ATOMIC_FUNCTIONS result )
 
 # Do step by step checking,
-CHECK_CXX_SOURCE_RUNS("
+SET( CHECK_HAVE_GCC_ATOMIC_FUNCTIONS_SOURCE "
 #include 
 int main()
 {
@@ -20,6 +20,13 @@
 
return EXIT_SUCCESS;
 }
-" ${result} )
+")
+
+IF ( CMAKE_CROSSCOMPILING )
+CHECK_CXX_SOURCE_COMPILES("${CHECK_HAVE_GCC_ATOMIC_FUNCTIONS_SOURCE}" ${result} )
+MESSAGE ( WARNING "cannot check atomics during cross compilation, assuming that they work" )
+ELSE ( CMAKE_CROSSCOMPILING )
+

Bug#971559: coinor-cgl FTCBFS: doesn't build shared libraries

[Helmut Grohne]

Source: coinor-cgl
Version: 0.60.3+repack1-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

coinor-cgl fails to cross build from source, because it doesn't build
shared libraries and then dh_install fails. Now the reasons for that are
... a little involved. Please sit down and take a cup of coffee or tea
or like that.

Looking into the cross configure output, one can spot this:
http://crossqa.debian.net/build/coinor-cgl_0.60.3+repack1-2_s390x_20200713232329.log
> checking whether the s390x-linux-gnu-gcc linker (/usr/bin/ld -m elf64_s390) 
> supports shared libraries... /usr/bin/ld: unrecognised emulation mode: 
> elf64_s390
> Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om 
> elf_k1om i386pep i386pe
> no

Bummer. It's using the wrong ld. It should be using s390x-linux-gnu-ld.
Why does it do that? It should be driving the ld name from gcc. However,
it only does when working with a GNU compiler and as we can see:

> checking whether we are using the GNU C compiler... no

For some reason, it concludes that gcc is not a GNU C compiler. That's
strange. You can also see this in native builds and it can have a range
of misdetections as a consequence. Just why?

The actual sequence of events is this:

We start following inside AC_COIN_DEBUG_COMPILE.

> checking whether we want to compile in debug mode... no

Now we're moving inside AC_COIN_PROG_CC executing AC_REQUIREd code.

> checking for s390x-linux-gnu-gcc... s390x-linux-gnu-gcc

At this point $ac_objext is not yet computed, so it is empty. What we do
next is use AC_TRY_COMPILE and that checks whether "conftest.$ac_objext"
aka "conftest." is non-empty. It isn't, as the compiler chose to output
to "conftest.o" instead, so we're not using a GNU compiler, right?

> checking whether we are using the GNU C compiler... no
> checking whether s390x-linux-gnu-gcc accepts -g... no
> checking for s390x-linux-gnu-gcc option to accept ISO C89... unsupported
> checking whether s390x-linux-gnu-gcc understands -c and -o together... yes

Now we've completed the AC_REQUIREd stuff and proceed to the AC_PROG_CC
inside AC_COIN_PROG_CC.

> checking for s390x-linux-gnu-gcc... s390x-linux-gnu-gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... yes

This time we compute $ac_cv_objext, which is propagated to $ac_objext.

> checking for suffix of object files... o

But we already checked that we're not using a GNU C compiler, so we
don't check again. If we were checking again, we'd now see that it is a
GNU C compiler as AC_TRY_COMPILE would now check for "conftest.o".

> checking whether we are using the GNU C compiler... (cached) no

The order of invocations is messed up. The basic structure of
AC_COIN_PROG_CC is:

AC_REQUIRE([AC_COIN_ENABLE_MSVC])
...
AC_PROG_CC([$comps])
...
AC_TRY_LINK(...)

Unfortunately, the AC_TRY_LINK AC_REQUIREs AC_PROG_CC, so that gets
executed before AC_COIN_PROG_CC gets a chance to compute $comps for
AC_PROG_CC. The issue is that we're using AC_TRY_LINK in the same defun
as we call AC_PROG_CC. That doesn't work.

Once understood, the solution is quite simple. We must put the
AC_PROG_CC and the AC_TRY_LINK in different defuns and ensure that our
intended AC_PROG_CC is AC_REQUIREd before using AC_TRY_LINK. I'm
attaching a patch to do that. Please consider applying it. I believe
that this is worth fixing even if you don't care about cross builds.

Helmut
--- coinor-cgl-0.60.3+repack1.orig/BuildTools/coin.m4
+++ coinor-cgl-0.60.3+repack1/BuildTools/coin.m4
@@ -665,9 +665,8 @@ AC_LANG_POP(C++)
 # given my the user), and find an appropriate value for CFLAGS.  It is
 # possible to provide additional -D flags in the variable CDEFS.
 
-AC_DEFUN([AC_COIN_PROG_CC],
-[AC_REQUIRE([AC_COIN_ENABLE_MSVC])
-AC_LANG_PUSH(C)
+AC_DEFUN([AC_COIN_PROG_CC_HEAD],
+[
 
 # For consistency, we set the C compiler to the same value of the C++
 # compiler, if the C++ is set, but the C compiler isn't (only for CXX=cl)
@@ -726,6 +725,13 @@ AC_PROG_CC([$comps])
 if test -z "$CC" ; then
   AC_MSG_ERROR([Failed to find a C compiler!])
 fi
+])
+AC_DEFUN([AC_COIN_PROG_CC],
+[AC_REQUIRE([AC_COIN_ENABLE_MSVC])
+dnl Separate the head of this macro to AC_COIN_PROG_CC_HEAD such that it
+dnl controls the invocation of AC_PROG_CC instead of the AC_TRY_LINK below.
+AC_REQUIRE([AC_COIN_PROG_CC_HEAD])
+AC_LANG_PUSH(C)
 # Autoconf incorrectly concludes that cl recognises -g. It doesn't.
 case "$CC" in
   clang* ) ;;

Bug#948125: Please use partx (in essential util-linux) rather than kpartx

[Josh Triplett]

On Sun, Aug 09, 2020 at 10:33:36AM +0300, Lars Wirzenius wrote:
> On Sat, Jan 04, 2020 at 02:55:00AM -0800, Josh Triplett wrote:
> vmdb2 depends on the kpartx package; could it, instead, use partx from
> > the essential util-linux package?
> 
> Speaking as upstream here: I had a look at partx, but I couldn't
> figure out how to replace kpartx with it. If you can show me how to do
> that, I'd be happy to make the changes to vmdb2 to use partx and to
> drop the kpartx dependency.

partx and kpartx have very similar functionality, just different output.

It looks like you're currently using kpartx to tell the kernel to add
and delete partition devices; you're also parsing the output to see what
device was created.

kpartx output looks like this:
add map loop0p1 (254:1): 0 10483679 linear 7:0 2048
And you're using the third word as the device name.

partx (with the -v option) writes output like this:

partition: none, disk: debian.img, lower: 0, upper: 0
Trying to use '/dev/loop0' for the loop device
/dev/loop0: partition table type 'gpt' detected
range recount: max partno=1, lower=0, upper=0
/dev/loop0: partition #1 added

That's not quite as trivial to parse, but you could look for lines that
match `^\(/dev/[^:]*\): partition #\([0-9]*\) added$`, and construct the
device name as match 1 + "p" + match 2.

Bug#783387: dhclient does not wait for ipv6 dad

[Raphael Grewe]

Hi everyone! :-)

It would be really super cool if my predecessor's patch would be
included in the isc-dhcp-client package for Debian Buster. 

We have tested the patch several times and considered it good.

Is that somehow possible?

Best regards,
Raphael Grewe

Bug#971531: firefox-esr: Firefox-esr doesn't apply scale factor of system

[Mike Hommey]

On Thu, Oct 01, 2020 at 12:22:16PM +0200, Teo wrote:
> Package: firefox-esr
> Version: 78.3.0esr-2
> Severity: normal
> Tags: a11y
> X-Debbugs-Cc: teodoro777.coluc...@live.com
> 
> When I enlarge the text through the scale factor, for example setting it on
> 1.25, I can see all app with enlarged text, except firefox.
> Searching on internet I see that this is a known bug, like you can see here
> https://bugzilla.mozilla.org/show_bug.cgi?id=1604761
> I read that it has already been fixed in version 73.0b2, but trying the
> 78.3.0esr version, now available in testing, this doesn't seem to be true.

This sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1554850

Mike

Bug#962596: Any updates?

[mkar...@mpi-inf.mpg.de]

Hey all,

Is there a timeline on this? Still present in 20200601~deb10u1.

Cheers,
Amin

Bug#919893: rng-tools-debian: package shouldn't exist

[Michael Stone]

On Thu, Oct 01, 2020 at 05:28:12PM +, Thorsten Glaser wrote:

Michael Stone dixit:

So you could have added whatever you needed to rng-tools and skipped the
unnecessary package...


No, rng-tools is a completely different software.


So your position is that rng-tools 2-unofficial-mt.14-1+b2 and 
rng-tools-debian 2-unofficial-mt.14-3 both in buster are completely 
different codebases? 


Let's review again.

Prior to buster there was rng-tools. It's a legacy codebase that's 
diverged from basically every other distribution. There was also 
rng-tools5 which was the then-current upstream which provided new 
functionality and is frankly more useful on modern hardware, but which 
did not (and probably never will) support the legacy hardware.


I had discussed with the (past) rng-tools maintainer the possibility of 
renaming that to something like rng-tools-legacy with a transition 
package, with the intent of freeing up the rng-tools package name in the 
short term and possibly renaming rng-tools5 in the long term.


All well and good, stretch was released with rng-tools (legacy) and 
rng-tools5.


Then someone decided to NMU rng-tools with a patch to basically make it 
a copy of rng-tools5. That never made it to release, and buster was 
released with both rng-tools (legacy) and rng-tools5.


And into that you uploaded *another copy* of rng-tools. So now we have 
two versions of rng-tools (legacy), one copy of rng-tools5, and a zombie 
NMU of rng-tools5 called rng-tools in unstable that's been removed from 
testing so that testing currently has no rng-tools.


So anybody using rng-tools in buster will end up with an orphaned 
package in the next release. There's another version of the same code 
*but with no transition mechanism* called rng-tools-debian. And there's 
another package called rng-tools5, originally intended as a bridge to a 
new package structure, and which is now awkwardly named as the upstream 
codebase is now up to version 6. 

Ideally you would come up with a transition mechanism to move rng-tools 
users to some other package name because you are the one who has laid 
claim to that codebase. I still believe that rng-tools-debian is a 
terrible name because it is not sponsored by the debian project and 
because the name does not give any hints to users about why they might 
want to use the package. If anything it misleads them into thinking that 
they should choose the old code if they're running debian when 
realistically that is almost certainly not the case. As long as 
transition packages are being discussed it seems like an ideal time to 
come up with a better name. rng-tools-legacy makes more sense, or you 
could come up with something better, or if you insist on calling it
rng-tools-debian because you really want to please at least take care of 
cleaning up the rng-tools transition. Once rng-tools in debian stable is 
migrated to the new package name (with a transition package that goes 
away) then we'll finally have something sane that supports the users in 
a reasonable fashion and we'll have a way forward in the future.

Bug#971557: ITP: tty-server -- Server side for tty-share

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: tty-server
  Version : 0.0~git20200923.bae58e7+ds-1
  Upstream Author : Vasile Popescu 
* URL : https://github.com/elisescu/tty-server
* License : GPL-2+
  Programming Lang: Go
  Description : Server side for tty-share

tty-server is the server side for tty-share. It provides an instant pairing
solution, allowing you to share a terminal. tty-share is necessary to connect
to the tty-server, when the connection occurs a secret URL is generated,
through which the terminal can be viewed in the browser.

Bug#971543: RFS: sanlock/3.8.2-1 [ITA] [RC] -- Shared storage lock manager

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name : sanlock
Version : 3.8.2-1
* URL : https://www.pagure.io/sanlock/
* License : LGPL-2.1+, GPL-2+
Section : libs

It builds those binary packages:

python3-sanlock - Python3 bindings to shared storage lock manager
libsanlock-dev - Shared storage lock manager (development files)
libsanlock1 - Shared storage lock manager (shared library)
libsanlock-client1 - Shared storage lock manager (client library)
sanlock - Shared storage lock manager

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/s/sanlock/sanlock_3.8.2-1.dsc

Changes since the last upload:

sanlock (3.8.2-1) unstable; urgency=medium
.
* New upstream release.
* New maintainer Closes: #903571
* New package: python3-sanlock
* d/*.symbols:
- Update symbols
- Add Build-Depends-Package: libsanlock-dev
* Switch to debhelper-compat
- d/control: Replace debhelper with debhelper-compat
- Remove d/compat
* d/control:
- Bump debhelper to 12
- Update Standards-Version to 4.4.1
- Drop dh-systemd as build dependency Closes: #958620
- Update homepage
- Add Rules-Requires-Root: no
- Add Pre-Depends: ${misc:Pre-Depends} for sanlock
* d/patches:
- Rebase patches
- Remove patches which is no longer needed.
- Add fix_man-page_macro.patch
- Add fix_typo.patch
* d/changelog: Remove whitespace
* d/copyright:
- Change to secure URI
- Update year
- Move debian/* to a separate file paragraph
* d/watch: Add file
* d/*.service: Add documentation-key
* Set upstream metadata fields: Bug-Database, Repository,
Repository-Browse.
* d/rules: Change to Debian specific init.d script LP: #1745986
This is the same file implemented in bug: #854696

Regards,
Håvard

Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d

[Michael Biebl]

Am 01.10.20 um 21:09 schrieb Michael Biebl:

> https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b#commitcomment-42793750
> 
>>
>>>
>>> Thoughts, Comments?
>>>
>>
>> I wonder if systemd can be fully installed into `/usr` now that we require
>> premounting. Maybe we should start changing lintian and other tools to
>> install into /usr instead of /lib for the tools that currently used
>> rootprefix (I believe systemd searches in /usr anyway).
> 
> I gave this a try. It can.
> See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/104
> Still very rough, but the package is usable and able to boot a system,
> reading udev rules and systemd services from both /lib and /usr/lib.
> We probably need quite a few more compat symlinks though.
> 
> This is only the systemd/udev side, though.
> The i-s-h/debhelper side is still missing and we'd need to hash out a
> plan for this. I'd need help with doing that.
> Anyone interested?


I'm a bit alarmed by "Hopefully we can drop the split soon." in the
github issue above. If upstream really plans to drop split-usr support,
we are up for a rough ride and we should plan for that now.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d

[Michael Biebl]

On Mon, 28 Sep 2020 20:43:30 -0300 Felipe Sateler 
wrote:
> On Mon, Sep 28, 2020 at 4:03 PM Michael Biebl  wrote:
> 
> > Package: systemd
> > Version: 246.6-1
> > Severity: important
> >
> > Upstream changed the paths in systemd.pc from prefix to rootprefix in
> > v246 for sysusers_dir, sysctl_dir, binfmt_dir and modules-load_dir:
> >
> > https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b
> >
> > This breaks packages which use pkg-config to determine those paths and
> > where .install files reference /usr/. An example is mandos.
> >
> > I think we should revert this change. I don't see a compelling reason to
> > move those files from /usr to /lib given that we require /usr to be
> > pre-mounted by initramfs, if it's separate.
> > Moving files from /usr to /lib files kinda backwards nowadays.
> >
> > I intend to apply a patch like the attached one in Debian.
> > That said, I hope I can convince Lennart to revert this change upstream
> > as well.
> >
> 
> Looks good to me.

Ok, thanks for the review. Will apply it to Debian then.
It doesn't look like upstream is interested in changing this back

https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b#commitcomment-42793750

> 
> >
> > Thoughts, Comments?
> >
> 
> I wonder if systemd can be fully installed into `/usr` now that we require
> premounting. Maybe we should start changing lintian and other tools to
> install into /usr instead of /lib for the tools that currently used
> rootprefix (I believe systemd searches in /usr anyway).

I gave this a try. It can.
See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/104
Still very rough, but the package is usable and able to boot a system,
reading udev rules and systemd services from both /lib and /usr/lib.
We probably need quite a few more compat symlinks though.

This is only the systemd/udev side, though.
The i-s-h/debhelper side is still missing and we'd need to hash out a
plan for this. I'd need help with doing that.
Anyone interested?

Michael



signature.asc
Description: OpenPGP digital signature

Bug#971556: golang-github-dgrijalva-jwt-go: CVE-2020-26160

[Salvatore Bonaccorso]

Source: golang-github-dgrijalva-jwt-go
Version: 3.2.0-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-dgrijalva-jwt-go.

CVE-2020-26160[0]:
| jwt-go before 4.0.0-preview1 allows attackers to bypass intended
| access restrictions in situations with []string{} for m["aud"] (which
| is allowed by the specification). Because the type assertion fails, ""
| is the value of aud. This is a security problem if the JWT token is
| presented to a service that lacks its own audience check.


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-26160
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] https://snyk.io/vuln/SNYK-GOLANG-GITHUBCOMDGRIJALVAJWTGO-596515

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#971555: libvirt: CVE-2020-25637

[Salvatore Bonaccorso]

Source: libvirt
Version: 6.6.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 5.0.0-4+deb10u1
Control: found -1 5.0.0-4

Hi,

The following vulnerability was published for libvirt.

CVE-2020-25637[0]:
| double free in qemuAgentGetInterfaces() in qemu_agent.c

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-25637
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25637
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1881037

Regards,
Salvatore

Bug#971554: djangorestframework: CVE-2020-25626

[Salvatore Bonaccorso]

Source: djangorestframework
Version: 3.11.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for djangorestframework.

CVE-2020-25626[0]:
| A flaw was found in Django REST Framework versions before 3.12.0 and
| before 3.11.2. When using the browseable API viewer, Django REST
| Framework fails to properly escape certain strings that can come from
| user input. This allows a user who can control those strings to inject
| malicious script tags, leading to a cross-site-scripting (XSS)
| vulnerability.


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-25626
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25626
[1] 
https://github.com/encode/django-rest-framework/commit/4121b01b912668c049b26194a9a107c27a332429

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#969357: squid-4.6: segfault for unknown reason

[Jiann-Ming Su]

Dang, sorry I missed that.  I will install squid-dbgsym and report back if
it segfaults again.  Thanks for following up.

On Wed, Sep 30, 2020 at 10:29 AM Bernhard Übelacker 
wrote:

> Hello,
> looks like your bug got an answer, but that message
> might not got forwarded to you.
> (For answers please to 969...@bugs.debian.org from now again.)
>
> Kind regards,
> Bernhard
>
>
> On Mon, 7 Sep 2020 16:56:24 +1200 Amos Jeffries 
> wrote:
> > Control: retitle -1 squid-4.6: segfault for unknown reason
> > Control: tags -1 + moreinfo
> >
> > On Mon, 31 Aug 2020 23:45:28 -0400 js1 wrote:
> > > Package: squid
> > > Version: 4.6-1+deb10u4
> > > Severity: normal
> > >
> > > Dear Maintainer,
> > >
> > > Squid segfaults but seems usable.  No segfaults until this current
> version (4.6-1+deb10u4).
> > >
> >
> > Please install the debug symbols package (squid-dbgsym) and provide a
> > backtrace from your segfault if it occurs again.
> >
> > Upstream provide details on how to obtain backtraces without downtime
> > from a running Squid proxy at
> > .
> >
> >
> > Amos
> >
> >
>


-- 
Jiann-Ming Su
"I have to decide between two equally frightening options.
 If I wanted to do that, I'd vote." --Duckman
"The system's broke, Hank.  The election baby has peed in
the bath water.  You got to throw 'em both out."  --Dale Gribble
"Those who vote decide nothing.
Those who count the votes decide everything.”  --Joseph Stalin

Bug#971553: gem2deb: obsolete copyright statement

[Lucas Nussbaum]

Package: gem2deb
Version: 0.43
Severity: minor

Hi,

the gem2deb manpage says:

COPYRIGHT AND AUTHORS
   Copyright (c) 2011, Lucas Nussbaum 

While that guy might have written the initial version almost 10 years
ago, lots of other better programmers turned it into the software it is
today.

Please update this statement to something that matches reality!

Lucas


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

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 gem2deb depends on:
ii  debhelper13.2~bpo10+1
ii  devscripts   2.19.5+deb10u1
ii  gem2deb-test-runner  0.43
ii  perl 5.28.1-6+deb10u1
ii  rake 12.3.1-3+deb10u1
ii  ruby 1:2.5.1
ii  ruby-all-dev 1:2.5.1
ii  ruby-setup   3.4.1-9

Versions of packages gem2deb recommends:
ii  apt-file 3.2.2
ii  build-essential  12.6
ii  python3-debian   0.1.35

gem2deb suggests no packages.

-- no debconf information

Bug#496905: RFH: gnat-gps -- integrated development environment for C and Ada

[Ludovic Brenta]

The packaging scripts have migrated to salsa:
https://salsa.debian.org/debian/gnat-gps

-- 
Ludovic Brenta.

Bug#971545: cloud.debian.org: Provide AMI image ID that is always recent

[Ross Vandegrift]

On Thu, Oct 01, 2020 at 05:16:36PM +0200, tkoeck wrote:
> is there an AMI image ID that is always the recent one?

That's not how AWS works - every image is always a different ID, just
like every instance is always a different ID.

Instead of hardcoding an AMI somewhere, you can search to find the
current release.  With awscli, try something like this:
$ aws ec2 describe-images \
--output text \
--owners 136693071363 \
--filters Name=name,Values="debian-10-amd64-*" \
--query 'Images[].[Name,ImageId]' \
| sort -rn \
| head -n 1 \
| awk '{print $2}'


If you're using terraform, the aws_ami data source works like this:
data "aws_ami" "debian10" {
  most_recent = true
  owners  = ["136693071363"]

  filter {
name = "name"
values = ["debian-10-amd64-*"]
  }
}

Ross

Bug#970818: mrpt: FTBFS on mipse64el: E: Build killed with signal TERM after 150 minutes of inactivity

[José Luis Blanco-Claraco]

Thanks, Scott, it worked!
https://buildd.debian.org/status/package.php?p=mrpt=sid

JL

Bug#971552: composer: Allow duplicate dashes in package names

[Pierre Rudloff]

Package: composer
Version: 1.8.4-1
Severity: minor
Tags: upstream

composer 1.8.4 wrongfully complains about package names that contain duplicate
dashes:

Deprecation warning: require.npm-asset/fortawesome--fontawesome-free is
invalid, it should have a vendor name, a forward slash, and a package name. The
vendor and package name can be words separated by -, . or _. The complete name
should match "[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9]([_.-]?[a-z0-9]+)*". Make sure
you fix this as Composer 2.0 will error.

This was fixed upstream in 1.10.6:
https://github.com/composer/composer/commit/2e7ace238a51fb66969ecd70d4dd823976b96dfb



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

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

Versions of packages composer depends on:
ii  jsonlint 1.7.1-1
ii  php-cli  2:7.3+69
ii  php-common   2:69
ii  php-composer-ca-bundle   1.1.4-1
ii  php-composer-semver  1.4.2-1
ii  php-composer-spdx-licenses   1.5.0-1
ii  php-composer-xdebug-handler  1.3.2-1
ii  php-json-schema  5.2.8-1
ii  php-psr-log  1.1.0-1
ii  php-symfony-console  3.4.22+dfsg-2+deb10u1
ii  php-symfony-filesystem   3.4.22+dfsg-2+deb10u1
ii  php-symfony-finder   3.4.22+dfsg-2+deb10u1
ii  php-symfony-process  3.4.22+dfsg-2+deb10u1
ii  php7.3-cli [php-cli] 7.3.19-1~deb10u1

Versions of packages composer recommends:
ii  git1:2.20.1-2+deb10u3
ii  unzip  6.0-23+deb10u1

Versions of packages composer suggests:
ii  fossil1:2.8-1
ii  mercurial 4.8.2-1+deb10u1
ii  php-zip   2:7.3+69
ii  php7.3-zip [php-zip]  7.3.19-1~deb10u1
ii  subversion1.10.4-1+deb10u1

-- no debconf information

Bug#971551: gcc-10: Please enable gnat on m68k as it works now

[John Paul Adrian Glaubitz]

Source: gcc-10
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hi!

Since the gnat bootstrap on m68k was actually fixed almost over a year ago [1],
I gave it another try and, indeed, I was successfully able to build gcc natively
on m68k with gnat enabled.

I have uploaded a +gnat version of gcc-10 into Debian Ports with gnat enabled so
that the next official upload of the gcc-10 package in unstable can enable gnat
natively on m68k.

Can you apply the following patch to enable gnat on m68k?

--- debian/rules.defs.orig  2020-08-31 13:38:02.0 +0200
+++ debian/rules.defs   2020-10-01 19:30:59.457430044 +0200
@@ -841,10 +841,6 @@
 # Ada 
 ada_no_cpus:= m32r sh3 sh3eb sh4eb
 # no Debian builds ... some of these should exist
-# ... cross-build-native cross-builds a non-working compiler ...
-ifneq (,$(filter $(build_type), build-native))
-  ada_no_cpus += m68k # see https://bugs.debian.org/868365
-endif
 ada_no_systems := 
 ada_no_cross   := no
 ada_no_snap:= no

Not sure what the comment "# no Debian builds ... some of these should exist" 
refers
to, we might be able to remove that as well.

Adrian

> [1] 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9aa357c75358a51f038e50f7c8d9207b58c157e0

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

Bug#970763: bug report acknowledged

[Georges Khaznadar]

Dear Ryan,

thank you for the bug report: wminput does segfault when it is called.

I tried to modify the source to get rid of the build warnings, which in
fact should be reported as errors. It appears to be a tough task, since
many warnings are about unapropriate pointer casts, due to the mix of
python2 and python3 concepts.

I shall try to get some help from the last upstream developer who
touched this software in source form.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#919893: rng-tools-debian: package shouldn't exist

[Thorsten Glaser]

Michael Stone dixit:

> No, there were also user confusion, duplication of functionality, and
> increased difficulty in future migration.

So, the name, and that we have two packages.
Oh well, it has happened now.

> So you could have added whatever you needed to rng-tools and skipped the
> unnecessary package...

No, rng-tools is a completely different software.
Also, trying to get new features into Debian packages,
especially considering this has a different upstream
as well, is pretty hard.

This step, packaging both, was actually suggested on
Launchpad by one of the developers involved.

Anyway, it is now here to stay.

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#917088: [debian-mysql] Bug#917088: Bug#917088: Bug#917088: mariadb-server-10.3: #1071 - Specified key was too long; max key length is 1000 bytes

[Olaf van der Spek]

Op wo 30 sep. 2020 om 17:05 schreef Faustin Lammler :
> I see that you opened a jira issue about this, remember to forward bug
> reports to upstream issue so we can track them better.
>
> What about Sergei last message, do you have any further comments?

Hi Faustin,

I think this issue can be closed, I'm not sure what could be done
about it downstream.

-- 
Olaf

Bug#971521: varnish-modules: autopkgtest needs update for new version of varnish: Depends on old ABI

[Stig Sandbeck Mathisen]

Paul Gevers  writes:

> So, vanish stopped providing vanishabi-11.0 and vanish-modules needs
> to be fixed, otherwise vanish is not allowed to migrate to testing
> (until vanish-modules is removed from testing). vanish-modules in
> unstable is broken now, we don't want that to happen in testing.

Hello,

The varnish-modules package fails to build due to the build erroring out
on deprecated functions. The varnishabi bump should have happened in
6.5.0 but the 6.5.1 was released soon after to only bump the varnish
version.

Example from the build of varnish-modules against varnish 6.5.1:

,
| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/varnish -I../src/foreign -Wall -Werror -Wall 
-Wno-format-y2k -Wstrict-prototypes -Wmissing-prototypes 
-Werror=missing-field-initializers -Wpointer-arith -Wreturn-type 
-Wwrite-strings -Wcast-qual -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Wnested-externs -Wextra -Wno-sign-compare -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c vcc_saintmode_if.c  -fPIC -DPIC -o 
.libs/vcc_saintmode_if.o
| vmod_bodyaccess.c: In function ‘vmod_hash_req_body’:
| vmod_bodyaccess.c:205:2: error: ‘VSB_delete’ is deprecated 
[-Werror=deprecated-declarations]
|   205 |  VSB_delete(vsb);
|   |  ^~
| In file included from /usr/include/varnish/cache/cache_varnishd.h:36,
|  from vmod_bodyaccess.c:37:
| /usr/include/varnish/vsb.h:79:8: note: declared here
|79 | void   VSB_delete(struct vsb *) v_deprecated_;
|   |^~
`

The upstream changelog for varnish 6.5.0 says:

,[ 
https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst ]
| * VSB support for dynamic vs. static allocations has been changed:
| 
|   For dynamic allocations use:
| 
| VSB_new_auto() + VSB_destroy()
| 
|   For preexisting buffers use:
| 
| VSB_init() + VSB_fini()
| 
| VSB_new() + VSB_delete() are now deprecated.
`

Varnish-modules uses VSB_new_auto() and VSB_delete() in vmod_bodyaccess
and vmod_saintmode. The long term is obviously for varnish-modules to
use one of the new VSB_ functions for allocations.

I'm not sure what is the best short term fix. Any suggestions? My C
skills are abysmal, so while I could probably get it to build, I'd not
be comfortable with pushing the result...

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#919893: rng-tools-debian: package shouldn't exist

[Michael Stone]

On Thu, Oct 01, 2020 at 04:51:54PM +, Thorsten Glaser wrote:

Michael Stone dixit:


So the package that shouldn't have existed made it into buster, there's a
ridiculous situation with 3 packages providing essentially the same
functionality with minor differences and no practical way for a user to figure
out which to install, and no movement on fixing this before the *next* release.


Yeah well, it exists now, and IIRC the strongest argument against
*this* package was the name.


No, there were also user confusion, duplication of functionality, and 
increased difficulty in future migration.



But given it’s been in a stable release now, maybe it’s time to
retire rng-tools (not rng-tools5), maybe with a transitional package
migrating users over to either rng-tools5 or rng-tools-debian, taking
their configuration along, or just dropping it so it keeps working
for users who have it installed, but new users need to choose one of
the others. Incidentally, rng-tools is not in testing but rng-tools5
is, so the maintainer might wish to check whether there’s anything
left from the rng-tools package to take over.


So you could have added whatever you needed to rng-tools and skipped the 
unnecessary package...


At this point, please just clean up the mess.

Bug#971550: gnome-shell-extension-easyscreencast: Opening "Options" and change "Show alerts and notifications" crashes under Xorg.

[Philip Wyett]

Package: gnome-shell-extension-easyscreencast
Version: 1.0.2-2
Severity: normal

Dear Maintainer,

Opening "Options" and change "Show alerts and notifications" or other
similar option crashes the extension (dialog) under Xorg. This does not
occur under wayland.

Regards

Phil

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

Kernel: Linux 4.19.0-11-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_USER
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 gnome-shell-extension-easyscreencast depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gnome-shell  3.30.2-11~deb10u2
ii  libgtk-3-common  3.24.5-1

gnome-shell-extension-easyscreencast recommends no packages.

gnome-shell-extension-easyscreencast suggests no packages.

-- no debconf information
-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#919893: rng-tools-debian: package shouldn't exist

[Thorsten Glaser]

Michael Stone dixit:

> So the package that shouldn't have existed made it into buster, there's a
> ridiculous situation with 3 packages providing essentially the same
> functionality with minor differences and no practical way for a user to figure
> out which to install, and no movement on fixing this before the *next* 
> release.

Yeah well, it exists now, and IIRC the strongest argument against
*this* package was the name.

In the meanwhile, the other packages both don’t provide needed
functionality, and *this* one has users beyond just me *and* works.
It’s also got fixes beyond what was in the others, and, while being
low-maintenance, I intend to take care about it. It’s here to stay
now.

But given it’s been in a stable release now, maybe it’s time to
retire rng-tools (not rng-tools5), maybe with a transitional package
migrating users over to either rng-tools5 or rng-tools-debian, taking
their configuration along, or just dropping it so it keeps working
for users who have it installed, but new users need to choose one of
the others. Incidentally, rng-tools is not in testing but rng-tools5
is, so the maintainer might wish to check whether there’s anything
left from the rng-tools package to take over.

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#971545: cloud.debian.org: Provide AMI image ID that is always recent

[Noah Meyerhans]

On Thu, Oct 01, 2020 at 05:16:36PM +0200, tkoeck wrote:
> is there an AMI image ID that is always the recent one?
> 
> As far as I have seen the AMI image ID always changes for every
> subversion (e.g. Debian 10.0 to 10.1)?
> 
> It would be interesting to have an AMI image ID which would always
> represent the newest Debian 10 AMI image with all security updates
> installed.

We publish updated AMIs (and images for other cloud services) when
necessary, not just on stable point releases.  You can see the history
for buster and stretch AMIs at the following locations.  Note especially
the updates addressing DSAs for core packages such as the kernel, libc,
or openssl.

https://wiki.debian.org/Cloud/AmazonEC2Image/Buster and
https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch

We don't necessarily publish updates for every package in the base image
that gets an update.  Many package updates are for relatively minor
issues with a limited exposure.  Cloud-init provides a simple mechanism
allowing packages to be updated upon instance launch, and we run
unattended-upgrades by default.  Primarily, the packages that trigger an
AMI update are packages that require a reboot in order to be effectively
applied.

I think our current approach provides a good balance between up-to-date
contents and excessive churn.  However, if you really want something
more likely to be up-to-date, we generate images daily, and you can use
them.  You should understand that these daily builds are mostly intended
for testing purposes, and they could disappear with little to no
warning.  See
https://noah.meyerhans.us/2020/03/04/daily-vm-image-builds-are-available-from-the-cloud-team/
for details about where to find them.

noah

Bug#971549: ITP: golang-github-dgryski-go-metro -- metrohash library in golang

[Roger Shimizu]

Package: wnpp
Severity: wishlist
Owner: Roger Shimizu 

* Package name: golang-github-dgryski-go-metro
  Version : 0.0~git20200812.85c65e2-1
  Upstream Author : Damian Gryski
* URL : https://github.com/dgryski/go-metro
* License : Expat
  Programming Lang: Go
  Description : metrohash library in golang

 This package is a mechanical translation of the reference C++ code for
 MetroHash, available at https://github.com/jandrewrogers/MetroHash
 .
 MetroHash is a set of state-of-the-art hash functions for
 non-cryptographic use cases. They are notable for being algorithmically
 generated in addition to their exceptional performance. The set of
 published hash functions may be expanded in the future, having been
 selected from a very large set of hash functions that have been
 constructed this way.

Bug#892058: "Your Debian key is expiring" reminder emails

[Anthony Towns]

On Tue, Sep 22, 2020 at 09:42:57PM -0700, Felix Lechner wrote:
> This is a courtesy reminder that your Debian key is expiring on 2020-10-05.
> Please also keep in mind that the Debian folks in charge of the
> keyring update it only once a month. That usually happens on the 24th
> of each month. It is only two days away.

I was going to say it would be nice if there was a month or two advance
notice, but looking at the bug log, it seems this is only due to the first
run of this being just before my key was due to expire, and the idea is
there would normally be two or three months notice? If so, perfect!

> If you like this service, please leave a favorable comment here [2]. Thank 
> you!

It's very good, thank you very much!

FWIW, I would have expected MIA to be contacted for anyone who's key is
expired for more than a few months.

(Also, couldn't anyone write a script to synchronise the keyservers for
expiring keys? Step 1: get a list of Debian keys that will expire in
the next 6 months; Step 2: download them from any key servers; Step 3:
if any of them have an updated expiry date, export and send to Debian's
keyserver. No need to be keyring-maint or have the secret key for any
of those steps. Could sync for new sigs as well, but that might get
tedious)

Cheers,
aj

Bug#971335: broadcom-sta: [patch] Driver improvements, cleanups, fixes

[Roger Shimizu]

Dear Diego,

Thanks for your patches!
Please see my comments below.

On Tue, Sep 29, 2020 at 7:24 AM Diego Escalante Urrelo  wrote:
>
> I've been working on a few improvements to this driver, trying
> (hopelessly) to fix the disconnect issues on my particular card + router
> combination. Although my original goal has failed miserably, I was able
> to figure out a couple of other fixes for common issues with this card.
>
> I have pushed a branch to salsa, which includes the following fixes:
>  * Make power management commands actually work (the driver ignores
>  turning PM off)
>  * Correctly read the value of TX power (the notorious "200dBm" bug)
>  * Correctly refuse MAC address changing (fixes network-manager
>  disconnects because of "random / custom mac address"
>  * Cleanup a few compiler warnings, and cfg80211 API usage
>
> The branch is here:
>  https://salsa.debian.org/diegoe-guest/broadcom-sta/-/commits/diegoe_debian

Thanks again for your great work!
I haven't reviewed the patches yet, but I built a deb package and
tried to install, and found it works well on my macbook.
Maybe I can upload a version to experimental later.

> While working on the above I also figured that I might as well try to
> create a proof of concept "new upstream" without all the cruft from the
> 10 years of kernel versions conditionals:
>  https://salsa.debian.org/diegoe-guest/broadcom-sta/-/commits/frankenwl
>
> My "frankenwl" branch is functionally the same as the above
> "diegoe_debian" branch, but it certainly makes it less convoluted to try
> and find problems in the code going forward. That said, I wasn't sure
> what would be the best way to proceed, or if it was a smart thing to do
> anyway. I guess this package is on "life support" on most distros, so I
> doubt there would be a objections on creating a shared new upstream (but
> I'm not familiar with the packaging of this driver in Debian, or other
> distros).

Since the upstream seems not active for quite a few years, so I think
it's totally fine if you want to fork.
And if you do so, I'm happy to update debian package to follow your
forked git repo.

> I also tried, naively, to contact cypress/broadcom to inquiry about a
> newer firmware blob dump, or just a new code dump. Of course, no
> response. I think it's worth highlighting that the kernel bcmf80211
> driver is very similar to the broadcom-sta code, which lead me to
> believe that it can work with the cards supported only by broadcom-sta,
> we just need the firmware blob and plug the loose ends. Anyway, this is
> probably never going to happen, unless someone figures out how to
> extract the (say, in my case) BCM4360 software-side firmware blob from
> the linux or mac or windows driver.

Yes, I understand and agree with you.

> Anyway, I wanted to share this work here so it's considered for
> inclusion for the upcoming Debian stable. At the very least this solves
> a few nitpicks (power settings, tx set/get) that degrade the user
> experience and a serious issue (mac address failures) that usually gets
> new users stuck and confused (random NM disconnections).
>
> I'm also aware that cards supported by this driver are "old" but most
> computers trapped in the broadcom-sta driver are perfectly functional
> today and will be for a few more years. In my particular case I'm
> running a macbookpro11,1 (2013) which works flawlessly except for the
> wifi! (Hah!) -- And I understand most other macbookpro models from
> around 2013 share this or similar Broadcom cards that use this driver.
> All those machines should be perfectly functional with Debian right now,
> and for a few more years.

Yes, I also have two mac devices that use this driver.
Thanks for your effort to make the driver better.

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

Bug#919893: package shouldn't exist

[Michael Stone]

So the package that shouldn't have existed made it into buster, there's 
a ridiculous situation with 3 packages providing essentially the same 
functionality with minor differences and no practical way for a user to 
figure out which to install, and no movement on fixing this before the 
*next* release.


On Thu, Feb 07, 2019 at 03:34:31PM +, Thorsten Glaser wrote:

Henrique de Moraes Holschuh dixit:


On Sun, Jan 20, 2019, at 14:05, Thorsten Glaser wrote:

How about starting a sort of transition to the split packages instead?=


Looks like a sensible approach to me.


It’s a bit too “short” before the release, always has been.
My other ideas, both the p-u and the “castling”, rely too
much on that all things involved go smooth.

I’d like to propose a new plan:

* we still intend to do a rng-tools → rng-tools5 transition
 for bullseye but leave buster alone

* we’ll just keep rng-tools (5.x) out of testing, and will
 later request package removal of src:rng-tools and the
 binary package (but (new) only AFTER the buster release)

* I’ll request removal of rng-tools-debian from testing
 (and, therefore, buster), but keep it around in sid
 until we have a new solution (to not break existing
 users)

* said new solution could be to either add all features
 needed to rng-tools5 or, well, keeping rng-tools-debian
 (the name’s correct as it’s the former Debian maintainer’s
 fork of rng-tools, but we can bikeshed that later) around

* whatever we do, we’ll do it way after the buster release
 (so we will have had time to discuss it before implementing)
 but way before the bullseye release (so it will have had
 enough time to cook in testing/sid beforehand)

* in bullseye, we will need to handle migration from
 - rng-tools (2.x) [from buster]
 - rng-tools (5.x) [from sid]
 - rng-tools5 [from buster/sid]
 - rng-tools-debian [from sid]
 but we don’t need to handle all of them the same way;
 details mostly depend on whether we manage to patch
 rng-tools5 enough so that we can migrate *all* of them
 to *one* destination package, handling all use cases;
 the configuration change needs to be in the release
 notes of course, but this way, we’ll have actually
 enough time to do that

This most likely means that rng-tools5 people (upstream and
packagers) need to consider adding enough rng-tools-debian
functionality (more command line switches, and making them
actually do what they used to do, and an /etc/default/ file).

Is this agreeable? If so, I’ll go ahead requesting removal
of rng-tools-debian from testing, and we’ll have to continue
blocking rng-tools 5 from entering testing.

The downside is that the fixes in rng-tools-debian won’t
make it into rng-tools in buster, and that rng-tools-debian
will be around for a while longer. But I’ve looked at popcon
and *buntu and saw it’s already used by way more people than
the two or three systems I installed it on myself, so we’ll
do best doing a transition plan including it *anyway*, which
won’t get worse if it sticks round for a while.

Sorry for taking ~2 weeks for this answer, I’ve had the cold
(and now caught conference flu at FOSDEM, no rest for me…),
but I believe that even acting 2 weeks ago we would not have
managed in time it *anything* went wrong, and the current
status quo in testing is “good enough” (that is, not a regres‐
sion from stretch) for us to keep for a release longer. If
one step in the transition had failed, we would have been
left without rng-tools in buster at all, which had derailed
any later transition plans and made users even angrier.

bye,
//mirabilos
--
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

Bug#971548: libgc: Please backport patch to fix alignment issue on m68k

[John Paul Adrian Glaubitz]

Source: libgc
Version: 1:8.0.4-2
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hi!

The current version of src:libgc has an alignment problem on m68k which causes
a couple of other packages to FTBFS on m68k such as asymptote [1].

libgc upstream has fixed the issue in the meantime [2], so it would be great if
the patch in question could be backported.

As a temporary workaround, I have upload a patched src:libgc package to Debian
Ports which will be replaced automatically once a new version of src:libgc has
been uploaded into unstable.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968265
> [2] 
> https://github.com/ivmai/bdwgc/commit/b55459ad47d9aaa75c9a4b0f99a3b867592ab8e0

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

Bug#971547: gcc-10: gm2 should be disabled for cross-builds in debian/rules.defs

[John Paul Adrian Glaubitz]

Source: gcc-10
Severity: normal

Hello!

I tried cross-building gcc-10 yesterday and it failed with a linker error when 
building
gm2. Looking at debian/rules.defs [1], m2 is first disabled, then enabled for 
cross
builds:

> # Modula-2 ---
> m2_no_cross := yes
> m2_no_cross := no

Since cross-builing failed for me with gm2 enabled, I assume it's best to 
remove the line
"m2_no_cross := no" from debian/rules.defs to unbreak cross-builds of 
src:gcc-10.

Thanks,
Adrian

> [1] https://sources.debian.org/src/gcc-10/10.2.0-13/debian/rules.defs/#L1247

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

Bug#971546: pango1.0: Thai word-break detection differs from upstream: U+002D HYPHEN-MINUS not a word end

[Simon McVittie]

Source: pango1.0
Version: 1.46.2-1
Severity: normal
Tags: upstream help
Forwarded: https://gitlab.gnome.org/GNOME/pango/-/issues/507
X-Debbugs-Cc: libt...@packages.debian.org, frib...@packages.debian.org

One of Pango's tests is currently skipped on buildds, but is run if you
build locally and you happen to have a Thai font installed (I used
fonts-noto-core). I'm going to set it up to be run in future uploads,
probably to experimental first, because missing test coverage means we
can never know whether things have regressed.

tests/test-break.c reads tests/breaks/four.break (attached), does some
analysis on it, produces output, and asserts that the output matches
tests/breaks/four.expected (also attached). On Fedora (which is used
for upstream's CI), this succeeds. On Debian, it fails, producing
four.actual (also attached) instead (the output is actually to a temp
file and presented in the log as a diff).

The failure mode seems to be: wherever the Thai input contains "-"
(U+002D HYPHEN-MINUS), on Fedora and in the expected output it's
considered to be a word boundary, a word start, and a word end ("bse"
in the line starting "Words:").  On Debian, it's considered to be
a word boundary and a word start, but *not* a word end ("bs" in the
"Words:" line).

The other information (mandatory breaks, line breaks, char breaks,
expandable spaces, other whitespace, sentence boundary/start/end points)
all seems to be as expected.

Does anyone know what is going on here? libthai and fribidi maintainers
Cc'd in the hope that they know something relevant.

For now I'm going to patch the test so that it will accept either the
expected output, or the output we get on Debian right now, but no
other possibilities (to make sure we don't regress further).

As described on the upstream bug, I tried installing a temporary VM
and upgrading/downgrading various components like libthai and GLib so
their versions were as close as possible to the Fedora image that
upstream use for CI, but I still got the same results. I also checked
whether we and/or Fedora patch libthai, but it seems we don't.

smcv
# For Thai language.
ภาษาไทย หรือ ภาษาไทยกลาง เป็นภาษาราชการและภาษาประจำชาติของประเทศไทย 
ภาษาไทยเป็นภาษาในกลุ่มภาษาไทซึ่งเป็นกลุ่มย่อยของตระกูลภาษาขร้า-ไท สันนิษฐานว่า 
ภาษาในตระกูลนี้มีถิ่นกำเนิดจากทางตอนใต้ของประเทศจีน 
และนักภาษาศาสตร์บางส่วนเสนอว่า 
ภาษาไทยน่าจะมีความเชื่อมโยงกับตระกูลภาษาออสโตร-เอเชียติก 
ตระกูลภาษาออสโตรนีเซียน และตระกูลภาษาจีน-ทิเบต
Text: ภ า ษ า   ไ ท ย  [ ]   ห รื อ  [ ]   ภ า ษ า   ไ ท ย   ก ล า ง  [ 
]   เ ป็ น   ภ า ษ า   ร า ช ก า ร   แ ล ะ   ภ า ษ า   ป ร ะ จ ำ   ช า ติ   ข อ 
ง   ป ร ะ เ ท ศ   ไ ท ย  [ ]   ภ า ษ า   ไ ท ย   เ ป็ น   ภ า ษ า   ใ น   ก ลุ่ 
ม   ภ า ษ า   ไ ท   ซึ่ ง   เ ป็ น   ก ลุ่ ม   ย่ อ ย   ข อ ง   ต ร ะ กู ล   ภ 
า ษ า   ข ร้ า  -   ไ ท  [ ]   สั น นิ ษ ฐ า น   ว่ า  [ ]   ภ า ษ า   ใ น   ต 
ร ะ กู ล   นี้   มี   ถิ่ น   ก ำ เ นิ ด   จ า ก   ท า ง   ต อ น   ใ ต้   ข อ ง 
  ป ร ะ เ ท ศ   จี น  [ ]   แ ล ะ   นั ก   ภ า ษ า ศ า ส ต ร์   บ า ง   ส่ ว น  
 เ ส น อ   ว่ า  [ ]   ภ า ษ า   ไ ท ย   น่ า   จ ะ   มี   ค ว า ม   เ ชื่ อ ม  
 โ ย ง   กั บ   ต ร ะ กู ล   ภ า ษ า   อ อ   ส โ ต ร  -   เ อ เ ชี ย   ติ ก  [ 
]   ต ร ะ กู ล   ภ า ษ า   อ อ   ส โ ต ร นี เ ซี ย น  [ ]   แ ล ะ   ต ร ะ กู ล  
 ภ า ษ า   จี น  -   ทิ เ บ ต  [0x0a] 
Breaks: c  c c c lc  c c clc  c  c clc  c c c lc  c c lc  c c c c   
 lc  c  c lc  c c c lc  c c c c c lc  c c lc  c c c lc  c c c c lc  c c  lc  c 
c lc  c c c c c lc  c c clc  c c c lc  c c lc  c  c lc  c c c lc  c lc  c   
c lc  c c c lc  c lcc lc  c  c lc  c   c lc   c c lc  c c lc  c c c  c lc  
c c c lc  c  c c  lc  c clc   c c  c c c c lc   c clc  c c c lc  c lc  
c c c  c lclc   lcc lc  c c c  c lc  c c lc  c c lc  c c lc  c  lc  c c 
lc  c c c c c lc   c clc  c c lc   c lc  c c c c c c c c  lc  c c lc   c c 
lc  c c c lc   c clc  c c c lc  c c lc   c lc  c lc   lc  c c c lc  c   c c 
lc  c c lc   c lc  c c c  c lc  c c c lc  c lc  c c c c  lc  c c c  c lc   c c  
  lc  c c c  c lc  c c c lc  c lc  c c c c  c c  c c clc  c c lc  c c c  c 
lc  c c c lc   c c  lc   c c c c   c
Whitespace:  x xx   

   x

  x x   

  x 
 x  
 x  
 x  

Bug#965839: Is tk5 still useful? (Re: Bug#965839: tk5: Removal of obsolete debhelper compat 5 and 6 in bookworm)

[tony mancill]

On Wed, Sep 30, 2020 at 06:52:39PM +0200, Christoph Berg wrote:
> Re: tony mancill
> > Since it looks fairly simple to update, I volunteer to update it to keep
> > it around for at least one more cycle.  It seems like a small investment
> > to make, and maybe it helps a few users.
> 
> Sure, if it doesn't eat up an unproportional amount of time, that
> makes sense.

Agreed.  I admit that I am motivated by a slightly nostalgic / romantic
view of Debian being the distro that "has that utility you want already
packaged."

If the package adds any undue load to the team, we shouldn't hesitate to
RM it.

Bug#971544: golang-github-lucas-clemente-quic-go: FTBFS: "drops packets if the receive queue is full" test fails sometimes

[Dmitry Shachnev]

Source: golang-github-lucas-clemente-quic-go
Version: 0.18.0-2
Severity: important
Tags: ftbfs

Dear Maintainer,

This package sometimes fails to build from source. The relevant part of the
log is:

• Failure [0.435 seconds]
Server
/build/golang-github-lucas-clemente-quic-go-0.18.0/obj-x86_64-linux-gnu/src/github.com/lucas-clemente/quic-go/server_test.go:40
  server accepting sessions that completed the handshake
  
/build/golang-github-lucas-clemente-quic-go-0.18.0/obj-x86_64-linux-gnu/src/github.com/lucas-clemente/quic-go/server_test.go:185
handling packets

/build/golang-github-lucas-clemente-quic-go-0.18.0/obj-x86_64-linux-gnu/src/github.com/lucas-clemente/quic-go/server_test.go:206
  drops packets if the receive queue is full [It]
  
/build/golang-github-lucas-clemente-quic-go-0.18.0/obj-x86_64-linux-gnu/src/github.com/lucas-clemente/quic-go/server_test.go:625

  Timed out after 0.118s.
  Expected
  : 727
  to be equivalent to
  : 1025

The full build log is attached. I cannot reproduce this reliably, thus it's
Severity: important and not serious.

It also fails on Reproducible Builds infrastructure:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-lucas-clemente-quic-go.html

And in Ubuntu:

https://launchpad.net/ubuntu/+source/golang-github-lucas-clemente-quic-go/0.18.0-2/+build/20091909

--
Dmitry Shachnev
I: pbuilder: network access will be disabled during build
I: Current time: Thu Oct  1 18:11:46 MSK 2020
I: pbuilder-time-stamp: 1601565106
I: Building the build Environment
I: extracting base tarball [/home/dmitry/pbuilder/sid-base.tgz]
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [golang-github-lucas-clemente-quic-go_0.18.0-2.dsc]
I: copying [./golang-github-lucas-clemente-quic-go_0.18.0.orig.tar.gz]
I: copying 
[./golang-github-lucas-clemente-quic-go_0.18.0-2.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.qw3YLKDx/trustedkeys.kbx': 
General error
gpgv: Signature made Thu Sep 24 14:11:16 2020 UTC
gpgv:using EDDSA key E25DCF798D442B8EDF47814DC4854A3818E0B016
gpgv:issuer "z...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on 
./golang-github-lucas-clemente-quic-go_0.18.0-2.dsc
dpkg-source: info: extracting golang-github-lucas-clemente-quic-go in 
golang-github-lucas-clemente-quic-go-0.18.0
dpkg-source: info: unpacking 
golang-github-lucas-clemente-quic-go_0.18.0.orig.tar.gz
dpkg-source: info: unpacking 
golang-github-lucas-clemente-quic-go_0.18.0-2.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Skip-test-takes-bit-long-time.patch
dpkg-source: info: applying 0002-use-old-go-protobuf.patch
dpkg-source: info: applying 0003-vendor-qtls-go1-15.patch
I: Not using root during the build.
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper-compat (= 13), dh-golang, golang-any, 
golang-github-cheekybits-genny-dev, golang-github-francoispqt-gojay-dev, 
golang-github-golang-mock-dev, golang-github-marten-seemann-qpack-dev, 
golang-github-marten-seemann-qtls-dev (>= 0.10.0~), 
golang-github-onsi-ginkgo-dev, golang-go.opencensus-dev, 
golang-golang-x-crypto-dev, golang-golang-x-net-dev, golang-golang-x-sync-dev, 
golang-gomega-dev, golang-goprotobuf-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 13304 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper-compat (= 13); however:
  Package debhelper-compat is not installed.
 pbuilder-satisfydepends-dummy 

Bug#971545: cloud.debian.org: Provide AMI image ID that is always recent

[tkoeck]

Package: cloud.debian.org
Severity: wishlist

Dear Maintainer,

is there an AMI image ID that is always the recent one?

As far as I have seen the AMI image ID always changes for every
subversion (e.g. Debian 10.0 to 10.1)?

It would be interesting to have an AMI image ID which would always
represent the newest Debian 10 AMI image with all security updates
installed.

Greetings
Tobias

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

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

Bug#971348: frescobaldi: Frescobaldi does not start

[Frédéric Moinard]

Package: frescobaldi
Followup-For: Bug #971348
X-Debbugs-Cc: f2c...@gmail.com

Dear Maintainer,

The last update of :
ii  python3-poppler-qt5 0.75.0-2
seems to have fixed this issue.
Frescobladi seems to works normally again.

Sorry for the inconvenience,
Frédéric



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

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

Versions of packages frescobaldi depends on:
ii  python33.8.2-3
ii  python3-ly 0.9.6-1
ii  python3-poppler-qt50.75.0-2
ii  python3-pygame 1.9.6+dfsg-3
ii  python3-pyqt5  5.15.1+dfsg-2
ii  python3-pyqt5.qtsvg5.15.1+dfsg-2
ii  python3-pyqt5.qtwebengine  5.15.1-1
ii  python3-pyqt5.qtwebkit 5.15.1+dfsg-2
ii  tango-icon-theme   0.8.90-8

Versions of packages frescobaldi recommends:
ii  lilypond  2.20.0-2

Versions of packages frescobaldi suggests:
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  hyphen-fr [hyphen-hyphenation-patterns] 1:7.0.1-1
ii  lilypond-doc2.20.0-2

-- no debconf information

Bug#971542: Please enable HTSlib plugins

[John Marshall]

If you do enable plugins, in 1.11 please also apply this patch: 
https://github.com/samtools/htslib/pull/1150

Bug#970623: RFA: offlineimap -- IMAP/Maildir synchronization and reader support

[Sudip Mukherjee]

Hi Ilias,

On Sun, Sep 20, 2020 at 09:13:57AM +0300, Ilias Tsitsimpis wrote:
> Package: wnpp
> Severity: normal
> 
> OfflineIMAP is an IMAP/Maildir synchronization tool. Currently,
> OfflineIMAP is Python 2 only, but there is a Python 3 port underway.
> Unfortunately, I do not have the time to help with this port, so I
> request an adopter.

I use offlineimap and will hate to see it go away with Bullseye. I think
the Python3 port is at https://github.com/OfflineIMAP/offlineimap3.
I can adopt it, but just wanted to know what will you suggest - update
the existing offlineimap with the new one or package the new one as
new 'offlineimap3' ?

--
Regards
Sudip

Bug#971542: Please enable HTSlib plugins

[John Marshall]

Source: htslib
Version: 1.11-1

I would recommend building HTSlib with plugins enabled. Doing this will 
activate HTSlib's plugin mechanism so that the Debian-supplied libhts.so will 
be able to use any other file access plugins that the user may have installed, 
and will move e.g. the libcurl and associated library dependencies to 
hfile_libcurl.so (which libhts.so will dynamically load) which simplifies 
linking against libhts.a for other programs. This can be done by adding the 
following configure options:

./configure --enable-plugins 
--with-plugin-path='/usr/local/libexec/htslib:$(plugindir)'

See HTSlib's INSTALL file for details. Packagers such as yourselves should set 
with-plugin-path thus so that plugins in both /usr/local and /usr will be used; 
If Debian still folds /usr/libexec into /usr/lib or nearby, you may wish to 
adjust both --with-plugin-dir and --with-plugin-path.

Thanks,

John

Bug#971541: astroquery: autopkgtest failure on armhf

[Graham Inggs]

Source: astroquery
Version: 0.4.1+dfsg-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Autopkgtests have recently started running on armhf, and there
astroquery fails [1].
I've copied what I hope is the relevant part of the log below.

I've marked this as a regression as 0.3.9+dfsg-1 passes in Debian
stable, and 0.4+dfsg-3 passes in Ubuntu.

Regards
Graham


[1] https://ci.debian.net/packages/a/astroquery/testing/armhf/


=== FAILURES ===
_ test_all_tables[toi-query34] _

self = 
cols = [,
,
, , , ...]

def _convert_vals(self, cols):
for col in cols:
# If a specific dtype was specified for a column, then use that
# to set the defaults, otherwise use the generic defaults.
default_converters = ([convert_numpy(col.dtype)] if col.dtype
  else self.default_converters)

# If the user supplied a specific convert then that takes
precedence over defaults
converters = self.converters.get(col.name, default_converters)

col.converters = self._validate_and_copy(col, converters)

# Catch the last error in order to provide additional information
# in case all attempts at column conversion fail.  The initial
# value of of last_error will apply if no converters are defined
# and the first col.converters[0] access raises IndexError.
last_err = 'no converters defined'

while not hasattr(col, 'data'):
try:
converter_func, converter_type = col.converters[0]
if not issubclass(converter_type, col.type):
raise TypeError('converter type does not match
column type')
>   col.data = converter_func(col.str_vals)

/usr/lib/python3/dist-packages/astropy/io/ascii/core.py:960:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

vals = ['9048843364125']

def generic_converter(vals):
>   return numpy.array(vals, numpy_type)
E   OverflowError: Python int too large to convert to C long

/usr/lib/python3/dist-packages/astropy/io/ascii/core.py:904: OverflowError

During handling of the above exception, another exception occurred:

patch_get = <_pytest.monkeypatch.MonkeyPatch object at 0xf299fb08>
table = 'toi', query = {'where': 'toi=256.01'}

@pytest.mark.filterwarnings("error")
@pytest.mark.parametrize("table,query", ALL_TABLES)
def test_all_tables(patch_get, table, query):
>   data = NasaExoplanetArchive.query_criteria(table, select="*", **query)

/usr/lib/python3/dist-packages/astroquery/nasa_exoplanet_archive/tests/test_nasa_exoplanet_archive.py:188:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3/dist-packages/astroquery/utils/class_or_instance.py:25: in f
return self.fn(obj, *args, **kwds)
/usr/lib/python3/dist-packages/astroquery/utils/process_asyncs.py:29:
in newmethod
result = self._parse_result(response, verbose=verbose)
/usr/lib/python3/dist-packages/astroquery/nasa_exoplanet_archive/core.py:471:
in _parse_result
data = ascii.read(text, format="ipac", fast_reader=False,
converters=CONVERTERS)
/usr/lib/python3/dist-packages/astropy/io/ascii/ui.py:323: in read
dat = reader.read(table)
/usr/lib/python3/dist-packages/astropy/io/ascii/core.py:1209: in read
table = self.outputter(cols, self.meta)
/usr/lib/python3/dist-packages/astropy/io/ascii/core.py:990: in __call__
self._convert_vals(cols)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 
cols = [,
,
, , , ...]

def _convert_vals(self, cols):
for col in cols:
# If a specific dtype was specified for a column, then use that
# to set the defaults, otherwise use the generic defaults.
default_converters = ([convert_numpy(col.dtype)] if col.dtype
  else self.default_converters)

# If the user supplied a specific convert then that takes
precedence over defaults
converters = self.converters.get(col.name, default_converters)

col.converters = self._validate_and_copy(col, converters)

# Catch the last error in order to provide additional information
# in case all attempts at column conversion fail.  The initial
# value of of last_error will apply if no converters are defined
# and the first col.converters[0] access raises IndexError.
last_err = 'no converters defined'

while not hasattr(col, 'data'):
try:
converter_func, converter_type = col.converters[0]
if not issubclass(converter_type, col.type):
  

Bug#971540: imbalanced-learn: autopkgtest failure on armhf

[Graham Inggs]

Source: imbalanced-learn
Version: 0.7.0-4
Severity: important
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: fails-always

Hi Maintainer

Autopkgtests have recently started running on armhf, and there
imbalanced-learn fails [1].
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/i/imbalanced-learn/testing/armhf/


imblearn/tests/test_common.py .. [ 17%]
x...s... [ 22%]
s..s.bash: line 1:  3769 Bus error
  $py -m pytest
autopkgtest [04:52:04]: test command1: ---]
autopkgtest [04:52:04]: test command1:  - - - - - - - - - - results -
- - - - - - - - -
command1 FAIL non-zero exit status 135

Bug#971539: RM: zshdb -- ROM; low popcon; no interest in adopting

[Iain R. Learmonth]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 970281-d...@bugs.debian.org, pkg-zsh-de...@lists.alioth.debian.org

Hi,

There has been no interest from the ZSH team in adopting this package,
and it has low popcon, so it's probably best to just remove it rather
than let it rot in the archives.

Thanks,
Iain.

Bug#971280: quodlibet segfauts trying to play some files in archive

[Ian Campbell]

On Thu, 2020-10-01 at 14:34 +0200, Klaumi Klingsporn wrote:
> But the weird thing is that here on a second system with
> the same depending library-versions installed as Ian
> (gir1.2- and gstreamer-Packages 1.16.2-4 and
> gir1.2-webkit2-4.0  2.28.2-2+b1) all works fine even with
> the cover-source-plugins enabled. So the bug must be
> triggered by some other upgrade in the system.

I'm afraid I've misled you, I actually ran reportbug to follow up from
a different system to the one which has the problem (I can't run
reportbug there for various reasons and the system I did run it on I
don't use QL on) but failed to update or redact the various bits
describing the system.

The versions from the affected system (a more or less up to date
testing system at the time I initially wrote  to the bug) are actually:

Versions of packages quodlibet depends on:
ii  exfalso   4.3.0-1
ii  gir1.2-gst-plugins-base-1.0:amd64 1.18.0-2
ii  gir1.2-gstreamer-1.0:amd641.18.0-3
ii  gir1.2-keybinder-3.0  0.3.2-1+b1
ii  gstreamer1.0-alsa:amd64   1.18.0-2
ii  gstreamer1.0-plugins-base:amd64   1.18.0-2
ii  gstreamer1.0-plugins-good:amd64   1.18.0-1
ii  gstreamer1.0-plugins-ugly:amd64   1.18.0-1
ii  gstreamer1.0-pulseaudio:amd64 1.18.0-1 
ii  python3   3.8.2-3

Versions of packages quodlibet recommends:
ii  dunst  1.4.1-1
ii  gir1.2-gtksource-3.0:amd64 3.24.11-2
ii  gir1.2-webkit2-4.0:amd64   2.30.1-1
ii  gnome-shell3.36.6-1
ii  notification-daemon3.20.0-4
ii  python3-dbus   1.2.16-3
ii  python3-pyinotify  0.9.6-1.3

Versions of packages quodlibet suggests:
ii  gstreamer1.0-plugins-bad:amd64 1.18.0-2+b1

Since libproxy appears in the stack trace:

$ dpkg -l *libproxy*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---=
ii  libproxy-tools0.4.15-13amd64automatic 
proxy configuration management library (tools)
un  libproxy1   (no 
description available)
ii  libproxy1-plugin-gsettings:amd64  0.4.15-13amd64automatic 
proxy configuration management library (GSettings plugin)
ii  libproxy1-plugin-networkmanager:amd64 0.4.15-13amd64automatic 
proxy configuration management library (Network Manager plugin)
ii  libproxy1-plugin-webkit:amd64 0.4.15-13amd64automatic 
proxy configuration management library (Webkit plugin)
ii  libproxy1v5:amd64 0.4.15-13amd64automatic 
proxy configuration management library (shared)

Ian.

Bug#971280: quodlibet segfauts trying to play some files in archive

[Klaumi Klingsporn]

Am / On Thu, 01 Oct 2020 14:14:20 +0100
schrieb / wrote Ian Campbell :

> The versions from the affected system (a more or less up
> to date testing system at the time I initially wrote  to
> the bug) are actually:
>
> Versions of packages quodlibet depends on:
> ii  exfalso   4.3.0-1
> ii  gir1.2-gst-plugins-base-1.0:amd64 1.18.0-2
> ii  gir1.2-gstreamer-1.0:amd641.18.0-3
> ii  gir1.2-keybinder-3.0  0.3.2-1+b1
> ii  gstreamer1.0-alsa:amd64   1.18.0-2
> ii  gstreamer1.0-plugins-base:amd64   1.18.0-2
> ii  gstreamer1.0-plugins-good:amd64   1.18.0-1
> ii  gstreamer1.0-plugins-ugly:amd64   1.18.0-1
> ii  gstreamer1.0-pulseaudio:amd64 1.18.0-1
> ii  python3   3.8.2-3

Than it may have somethinge to do with the girl1.2- and
gstreamer1.0-upgrade as the bug does not appear on a sytem
with gir1.2- and gstreamer-Packages 1.16.2-4

> Since libproxy appears in the stack trace:
>
> $ dpkg -l *libproxy*
> ii  libproxy-tools0.4.15-13
> amd64automatic proxy configuration management
> library (tools) un  libproxy1
>   (no description available) ii
> libproxy1-plugin-gsettings:amd64  0.4.15-13amd64
>   automatic proxy configuration management library
> (GSettings plugin) ii
> libproxy1-plugin-networkmanager:amd64 0.4.15-13amd64
>   automatic proxy configuration management library
> (Network Manager plugin) ii
> libproxy1-plugin-webkit:amd64 0.4.15-13amd64
>   automatic proxy configuration management library
> (Webkit plugin) ii  libproxy1v5:amd64
> 0.4.15-13amd64automatic proxy configuration
> management library (shared)

My libproxy-versions on both(!) systems are the same to
yours:

ii  libproxy-tools0.4.15-13amd64automatic
proxy configuration management library (t>
un  libproxy1  (keine Beschreibung
vorhanden)
ii  libproxy1v5:amd64 0.4.15-13amd64
automatic proxy configuration management library (s>
ii libproxy1v5:i386  0.4.15-13i386 automatic proxy
configuration management library (s>

klaumi


---
Klaus-Michael Klingsporn
mail: klaumi...@gmx.de
web: www.klaumikli.de

Bug#971538: qgis: "Couldn't load SIP module." error message when started

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/qgis/QGIS/issues/39117

Thanks for reporting this issue, I've forwarded it upstream as doesn't
seem to be specific to the Debian package.

As noted in the upstream issue, it may be caused by the recent update of
pyqt5 to 5.15.1.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Hugh McMaster]

Hi Andreas,

On Thu, 1 Oct 2020 at 02:49, Andreas Metzler wrote:
> Runtime library are generally installed as a dependency, when the
> depending package is rebuilt against the newer library apt will pull it
> in and the old library can be autoremoved.

Very nice.

> > I’m also targeting experimental to be safe, as I expected some breakage
> > from this change.
> [...]
>
> Also library transition will need to be coordinated with Debian release,
> pre-upload to sid.

Thanks for reminding me. :)

I've uploaded a new version of libexif-gtk to Debian Mentors, fixing
the issues discussed in this thread.

Thanks for your help with this.

Hugh

Bug#957737: FTBFS Fixes

[Christian Ehrhardt]

Hi,
I wanted to let you know that I have today looked into the very same
FTBFS and submitted
the fixes upstream.

https://lists.quagga.net/pipermail/quagga-dev/2020-October/033390.html
https://lists.quagga.net/pipermail/quagga-dev/2020-October/033391.html

With those two gcc-10 builds work.

[1] contains an (Ubuntu) Test build with these applied.
You might wait for upstream to integrate or apply them as-is to fix the FTFBS.

Kind Regards,
Christian

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4291/+packages

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#971538: qgis: "Couldn't load SIP module." error message when started

[Félix Sipma]

Package: qgis
Version: 3.10.10+dfsg-1
Severity: normal

Hello,

When I start qgis, I get a window with the following error message:

Couldn't load SIP module.
Python support will be disabled.


Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/qgis/__init__.py", line 78, in 
import qgis.gui
  File "/usr/lib/python3/dist-packages/qgis/gui/__init__.py", line 25, in 
from qgis._gui import *
ValueError: PyCapsule_GetPointer called with incorrect name


Python version:
3.8.6 (default, Sep 25 2020, 09:36:53) 
[GCC 10.2.0]

QGIS version:
3.10.10-A Coruña 'A Coruña', exported

Python path:
['/usr/share/qgis/python', 
'/home/gueux/.local/share/QGIS/QGIS3/profiles/default/python', 
'/home/gueux/.local/share/QGIS/QGIS3/profiles/default/python/plugins', 
'/usr/share/qgis/python/plugins', '/usr/lib/python38.zip', 
'/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', 
'/home/gueux/.local/lib/python3.8/site-packages', 
'/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages', 
'/usr/lib/python3.8/dist-packages']

This does not prevent qgis from being started.

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

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

Versions of packages qgis depends on:
ii  libc62.31-3
ii  libgcc-s110.2.0-13
ii  libgdal273.1.3+dfsg-1
ii  libgeos-c1v5 3.8.1-1
ii  libgsl25 2.6+dfsg-2
ii  libqgis-analysis3.10.10  3.10.10+dfsg-1
ii  libqgis-app3.10.10   3.10.10+dfsg-1
ii  libqgis-core3.10.10  3.10.10+dfsg-1
ii  libqgis-gui3.10.10   3.10.10+dfsg-1
ii  libqt5core5a 5.14.2+dfsg-6
ii  libqt5gui5   5.14.2+dfsg-6
ii  libqt5keychain1  0.10.0-1
ii  libqt5network5   5.14.2+dfsg-6
ii  libqt5sql5   5.14.2+dfsg-6
ii  libqt5webkit55.212.0~alpha4-5
ii  libqt5widgets5   5.14.2+dfsg-6
ii  libqt5xml5   5.14.2+dfsg-6
ii  libstdc++6   10.2.0-13
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-4
ii  python3-qgis 3.10.10+dfsg-1
ii  qgis-common  3.10.10+dfsg-1
ii  qgis-providers   3.10.10+dfsg-1
ii  qt5-image-formats-plugins5.14.2-2

Versions of packages qgis recommends:
ii  qgis-plugin-grass  3.10.10+dfsg-1

Versions of packages qgis suggests:
ii  gpsbabel  1.7.0+ds-5

-- no debconf information

-- 
Félix


signature.asc
Description: PGP signature

Bug#971537: Impossible to run /sbin/ldconfig on buster using qemu-i386-static

[Rudra Saraswat]

Package: libc-bin
Version: 2.28-10

It impossible to run /sbin/ldconfig using qemu-i386-static (debootstrap
--foreign chroot) on a Raspberry Pi 4B with libc-bin at 2.28-10 (on Debian
Buster in the debootstrap chroot). However, it does work on a stretch
debootstrap chroot, without any errors.

Here is the error encountered with Buster:

qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Multiple people have faced this issue, which is why I'm reporting it as a
bug.

On all setups, Debian Buster/Raspbian Buster is used as the operating
system.