Bug#988255: Acknowledgement (buster-pu: package mariadb-10.3 10.3.29-0+deb10u1)

[Salvatore Bonaccorso]

Hi,

On Sat, May 15, 2021 at 12:26:43PM -0700, Otto Kekäläinen wrote:
> There hasn't been any responses from release team to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988255 in the past
> week nor is there a release date for Debian 10.10 at
> https://release.debian.org/
> 
> If the security team wants I can also target this as a security update
> for Debian Buster?

A point release update is fine. AFAIK there is not timeline set yet
though for the next point release for buster, but as soon the stable
release time would acknowledge your upload you can then already do the
upload.

Regards,
Salvatore

Bug#984956: Pmix issues with openmpi-4.1.0

[Lucas Nussbaum]

Hi Alaitair,

Thanks a lot for fixing this.

Unfortunately, I noticed that the upload to unstable was built against
ucx 1.10.1~rc1-1, so both need to migrate to testing.

Did you already engage discussions with the release team? I did not find
an unblock request.

Lucas

Bug#988575: xfce4-panel: Panel dark mode does not work

[luucongthehien]

Package: xfce4-panel
Version: 4.16.2-1
Severity: normal
X-Debbugs-Cc: luucongtheh...@gmail.com

Dear Maintainer,

After switching to the unstable channel and upgrading the Xfce version to
4.16.2, the panel options contains a dark mode feature that when
switched on, does not do anything. I looked up the panel configuration
files on the .config folder and even attempted to log in as root, but
nothing worked.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 xfce4-panel depends on:
ii  exo-utils4.16.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libdbusmenu-gtk3-4   18.10.20180917~bzr492+repack1-2
ii  libexo-2-0   4.16.0-1
ii  libgarcon-1-04.16.1-1
ii  libgarcon-gtk3-1-0   4.16.1-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libwnck-3-0  3.36.0-1
ii  libx11-6 2:1.7.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxfce4panel-2.0-4  4.16.2-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#988569: mirror listing update for debian.qontinuum.space

[Qontinuum]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debian.qontinuum.space
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 powerpc ppc64el
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Qontinuum 
Country: MC Monaco




Trace Url: http://debian.qontinuum.space/debian/project/trace/
Trace Url: 
http://debian.qontinuum.space/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.qontinuum.space/debian/project/trace/debian.qontinuum.space

Bug#988568: mirror submission for debian.qontinuum.space

[Qontinuum]

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

Submission-Type: new
Site: debian.qontinuum.space
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 powerpc ppc64el
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Qontinuum 
Country: MC Monaco
Comment: It can also be considered in france




Trace Url: http://debian.qontinuum.space/debian/project/trace/
Trace Url: 
http://debian.qontinuum.space/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.qontinuum.space/debian/project/trace/debian.qontinuum.space

Bug#988574: linux-image-armmp-lpae: ethernet on orange pi plus does not work

[Vagrant Cascadian]

Source: linux
Version: 5.10.28-1
Severity: normal
Tags: patch
X-Debbugs-Cc: vagr...@reproducible-builds.org

When upgrading the reproducible builds infrastructure to bullseye, on
the orange pi plus ethernet stopped working with 5.10.x.

Applying a fix from upstream for a similar board appears to fix the
issue:

a900cac3750b9f0b8f5ed0503d9c6359532f644d
ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode


dtdiff sun8i-h3-orangepi-plus-orig.dtb sun8i-h3-orangepi-plus.dtb
--- /dev/fd/63  2021-05-16 02:52:30.519751297 +
+++ /dev/fd/62  2021-05-16 02:52:30.523751128 +
@@ -364,7 +364,7 @@
interrupt-names = "macirq";
interrupts = <0x00 0x52 0x04>;
phy-handle = <0x14>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-supply = <0x16>;
pinctrl-0 = <0x15>;
pinctrl-names = "default";


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot

[Rich]

Package: src:linux
Version: 5.10.28-1
Severity: normal
X-Debbugs-Cc: rincebr...@gmail.com

Dear Maintainer,

(This might also affect upstream, I haven't built a vanilla kernel to
experiment.)

On my (qemu-provided) alpha system, attempting to boot with the SMP kernel
yields the following message during boot:


[   17.538076] Unable to handle kernel paging request at virtual address 

[   17.539053] CPU 3
[   17.539053] kworker/3:1(39): Oops -1
[   17.539053] pc = [<>]  ra = [<>]  ps =   
  Tainted: GE
[   17.539053] pc is at 0x0
[   17.541983] ra is at 0x0
[   17.542959] v0 = 0007  t0 = fc00026b8fc0  t1 = 

[   17.542959] t2 = 0002  t3 =   t4 = 
644e
[   17.543936] t5 = 4000  t6 = 0001  t7 = 
fc0004aac000
[   17.544912] s0 = fc00026b8fc0  s1 = fc00026b8fc0  s2 = 
fc0002731290
[   17.544912] s3 = fc0002731290  s4 = fc0002741290  s5 = 
fc00026b9178
[   17.545889] s6 = fc00010c9b80
[   17.545889] a0 =   a1 =   a2 = 
0040
[   17.546866] a3 = 0040  a4 =   a5 = 

[   17.548819] t8 = 0001  t9 = 014bbcf4  t10= 
0a546000
[   17.548819] t11= b938  pv = fc000193c640  at = 
0001
[   17.550772] gp = fc0002721290  sp = 9468c7b6
[   17.550772] Disabling lock debugging due to kernel taint
[   17.550772] Trace:
[   17.551748] [] wait_rcu_exp_gp+0x20/0x50
[   17.551748] [] process_one_work+0x20c/0x520
[   17.552725] [] worker_thread+0x90/0x770
[   17.552725] [] kthread+0x1c4/0x1e0
[   17.553701] [] worker_thread+0x0/0x770
[   17.553701] [] ret_from_kernel_thread+0x18/0x20
[   17.554678] [] kthread+0x0/0x1e0
[   17.555655]
[   17.555655] Code:
[   17.555655]  
[   17.555655]  
[   17.556631]  00063301
[   17.556631]  13d5
[   17.556631]  
[   17.556631]  52a3
[   17.556631]

which is not especially informative. I _suspect_ this may be somewhere in
the network stack, because the boot process shortly thereafter blocks
indefinitely on systemd-timesyncd starting...

Since it could conceivably be relevant, my qemu command line for spawning
this VM is:

qemu-system-alpha -m 4096 -vnc :12 -net nic,model=virtio-net-pci -net 
user,hostfwd=tcp::2-:22 -drive file=alpha,format=raw -smp 4 -kernel 
vmlinux-5.10.0-6-alpha-generic -initrd initrd.img-5.10.0-6-alpha-generic 
-append console=ttyS0 root=UUID=f5487547-65eb-4330-8644-39e494b5d972 -nographic

(with s/-generic/-smp/g for when it breaks)

(I also have tried nic,model=e1000 and nic,model=ne2k_pci, it does not
change the printout.)

The qemu version is qemu-system misc 5.2+dfsg-9~bpo10+1 from
buster-backports, on an x86_64 buster host.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
system type : Tsunami
system variation: Clipper
system revision : 0
platform string : N/A

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

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug enp0s1
iface enp0s1 inet dhcp

** PCI devices:
00:00.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] 
(prog-if 00 [VGA controller])
Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:02.0 IDE interface [0101]: Silicon Image, Inc. PCI0646 [1095:0646] (rev 07) 
(prog-if 8f [PCI native mode controller, supports both channels switched to ISA 
compatibility mode, supports bus mastering])
Subsystem: Red Hat, Inc. PCI0646 [1af4:1100]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
pn  fdutils 
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-6-alpha-smp is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  

Bug#988572: ognibuild: building cmake projects fails

[Paul Wise]

Package: ognibuild
Version: 0.0.4-1
Severity: normal

The ognibuild blog post mentions cmake support but `ogni build` seems
to detect that as make rather than cmake, which means that the build
fails because there is no Makefile before cmake is run and creates it.

   $ git clone -q https://github.com/jameskbride/cmake-hello-world.git
   
   $ cd cmake-hello-world/
   
   cmake-hello-world (master=) $ git ls-tree --name-only -r @
   .gitignore
   CMakeLists.txt
   Hello/CMakeLists.txt
   Hello/Speaker.cpp
   Hello/Speaker.h
   HelloWorld.cpp
   LICENSE
   README.md
   
   cmake-hello-world (master=) $ ogni build
   Preparing directory .
   Using requirement resolver: [cpan, ctan, pypi, npm, go, hackage, cran, cran, 
octave-forge]
   Detected buildsystems: make
   Checking that declared requirements are present
   Unable to determine declared dependencies from Make('.')
   make: *** No rule to make target 'all'.  Stop.
   Build failed and unable to find cause. Giving up.
   
   cmake-hello-world (master=) $ (mkdir build ; cd build ; cmake .. ; make)
   -- The C compiler identification is GNU 10.2.1
   -- The CXX compiler identification is GNU 10.2.1
   -- Detecting C compiler ABI info
   -- Detecting C compiler ABI info - done
   -- Check for working C compiler: /usr/bin/cc - skipped
   -- Detecting C compile features
   -- Detecting C compile features - done
   -- Detecting CXX compiler ABI info
   -- Detecting CXX compiler ABI info - done
   -- Check for working CXX compiler: /usr/bin/c++ - skipped
   -- Detecting CXX compile features
   -- Detecting CXX compile features - done
   -- Configuring done
   -- Generating done
   -- Build files have been written to: cmake-hello-world/build
   Scanning dependencies of target Hello
   [ 25%] Building CXX object Hello/CMakeFiles/Hello.dir/Speaker.cpp.o
   [ 50%] Linking CXX static library libHello.a
   [ 50%] Built target Hello
   Scanning dependencies of target CMakeHelloWorld
   [ 75%] Building CXX object CMakeFiles/CMakeHelloWorld.dir/HelloWorld.cpp.o
   [100%] Linking CXX executable CMakeHelloWorld
   [100%] Built target CMakeHelloWorld
   

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages ognibuild depends on:
ii  python3  3.9.2-3
ii  python3-apt  2.2.0
ii  python3-breezy   3.1.0-8
ii  python3-buildlog-consultant  0.0.9-1
ii  python3-lz4  3.1.3+dfsg-1
ii  python3-requirement-parser   0.2.0-1.1
ii  python3-toml 0.10.1-1

Versions of packages ognibuild recommends:
pn  brz-debian 
ii  python3-debmutate  0.20

ognibuild suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#882804: cdebconf-gtk-udeb: Missing rescue mode label at start-up

[Cyril Brulebois]

Cyril Brulebois  (2017-11-26):
> The banner in the graphical installer doesn't get the “Rescue mode”
> label at start-up. It seems the information message hasn't been received
> yet when the first call to handle_exposed_banner (cdebconf gtk frontend)
> happens, so one has to select a language or switch to another vt back
> and forth to get the message displayed. That doesn't happen with the
> text rescue mode, so it's likely a cdebconf gtk frontend bug, filing
> accordingly.
> 
> This is seen in sid but also with 9.2 installation images.

With a regular mini.iso (cdebconf-gtk-udeb built against GTK+2), on the
start-up screen, the label is missing; switching to a VT and back gets
us the needed refresh and label; without the VT switch, proceeding to
the next screen is sufficient to get it as well.

With a patched mini.iso (cdebconf-gtk-udeb built against GTK+3), the
label is missing as well; the VT switch dance gets it back; but NOT
going to the next screen.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#988571: ognibuild: building iotop from upstream git fails

[Paul Wise]

Package: ognibuild
Version: 0.0.4-1
Severity: normal

Something that ognibuild does means that the build of iotop works with
manually running setup.py but fails with ogni build.

   $ git clone -q https://repo.or.cz/iotop.git
   
   $ cd iotop/
   
   iotop (master=) $ ./setup.py -v build
   running build
   running build_py
   creating build
   creating build/lib.linux-x86_64-3.9
   creating build/lib.linux-x86_64-3.9/iotop
   copying iotop/genetlink.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/ioprio.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/version.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/data.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/vmstat.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/ui.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/netlink.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/__init__.py -> build/lib.linux-x86_64-3.9/iotop
   warning: build_py: byte-compiling is disabled, skipping.
   
   running build_ext
   building 'iotop._ioprio' extension
   creating build/temp.linux-x86_64-3.9
   creating build/temp.linux-x86_64-3.9/iotop
   x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.9 -c iotop/_ioprio.c -o 
build/temp.linux-x86_64-3.9/iotop/_ioprio.o
   x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -fwrapv -O2 -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/iotop/_ioprio.o -o 
build/lib.linux-x86_64-3.9/iotop/_ioprio.cpython-39-x86_64-linux-gnu.so
   running build_scripts
   creating build/scripts-3.9
   copying and adjusting sbin/iotop -> build/scripts-3.9
   changing mode of build/scripts-3.9/iotop from 640 to 755
   
   ~/iotop (master=) $ git clean -dxf
   Removing build/
   
   ~/iotop (master=) $ ogni info
   
   Preparing directory .
   Using requirement resolver: [apt, cpan, ctan, pypi, npm, go, hackage, cran, 
cran, octave-forge]
   Detected buildsystems: setup.py
   SetupPy('.'):
Declared outputs:
binary: iotop
python package: iotop
   
   iotop (master=) $ ogni build
   Preparing directory .
   Using requirement resolver: [cpan, ctan, pypi, npm, go, hackage, cran, cran, 
octave-forge]
   Detected buildsystems: setup.py
   Checking that declared requirements are present
   running build
   running build_py
   creating build
   creating build/lib.linux-x86_64-3.9
   creating build/lib.linux-x86_64-3.9/iotop
   copying iotop/genetlink.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/ioprio.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/version.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/data.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/vmstat.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/ui.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/netlink.py -> build/lib.linux-x86_64-3.9/iotop
   copying iotop/__init__.py -> build/lib.linux-x86_64-3.9/iotop
   running build_ext
   building 'iotop._ioprio' extension
   creating build/temp.linux-x86_64-3.9
   creating build/temp.linux-x86_64-3.9/iotop
   x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.9 -c iotop/_ioprio.c -o 
build/temp.linux-x86_64-3.9/iotop/_ioprio.o
   x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -fwrapv -O2 -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/iotop/_ioprio.o -o 
build/lib.linux-x86_64-3.9/iotop/_ioprio.cpython-39-x86_64-linux-gnu.so
   collect2: fatal error: cannot find ‘ld’
   compilation terminated.
   error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
   Build failed and unable to find cause. Giving up.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 

Bug#988570: lesspipe: improve manpage

[Christoph Anton Mitterer]

Package: less
Version: 551-2
Severity: wishlist


Hi.

1) lesspipe mangpage says:
>USAGE
>   Just  put  one of the following two commands in your login script (e.g.
>   ~/.bash_profile):
> eval "$(lessfile)"
>   or
> eval "$(lesspipe)"

This is however not enough in some cases, which lead to #385168 long ago.

It would be nice if there was a note, that the script uses SHELL to determine
the output, but SHELL isn't re-set by e.g. bash, if already set.

So one should ideally invoke the above like:
eval "$(SHELL=/name/of/the/actual/shell lessfile)"


2) if [ -z "$PS1" ]; then
   exit
   fi

Is IMO a bad check for interactiveness (and it shouldn't be exit, but return?):

a) This will break if PS1 is unset and "set -u" is active, ${PS1-} would solve 
this.
b) But IMO it's anyway better to check for "i" in $-.
   A user could have set an empty prompt (unlikely, but possible) and then the 
shell
   would be considiered non-interactive - while it's not.
   Also, PS1 could always be there in non-interactive shell (by accident).

   OTOH, AFAIU, "i" in $- is really only set by the shell if it considers itself
   interactive.

   The following should be a proper check for that:
   if [ -n "${-##*i*}"  -o  -z "${-}" ]; then
return
   fi

   It's better than the various constructs with case or [[ since it's posix 
compatible,
   and not prone to shopt nocasematch being on.


Cheers,
Chris.

Bug#988565: slapd-contrib: smbk5pwd crashes when enabling krb5 (again)

[Ryan Tandy]

Looks like this is a legitimate bug in how we build smbk5pwd. It's not 
linking -lkrb5, so it doesn't see its versioned symbols. This would have 
been introduced when we switched to heimdal-multidev and started using 
krb5-config, so quite a while ago.

Bug#988549: lxqt: dmesg tail given before a reboot due to graphics subsystem freez

[Amy Kos]

Control: severity -1 minor


Hi

you have mixed lxqt packages, 0.14 from buster (stable) and 0.16 from bullseye 
(testing).
Probably pcmanfm-qt segfaults due to wrong Qt5 version.

Please do an apt full-upgrade

Thanks,
Amy

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Chris Hofstaedtler]

(Replying to the bug only, as its not relevant for d-boot...)

* Ritesh Raj Sarraf  [210515 17:32]:
> Time is pressing and I'm wondering what best to do here. I certainly do
> not care much for the iSCSI support in the installer. I didn't write or
> test that feature either.
[..]

> Maybe best to rope-in Ubuntu folks. I believe they make use of it in
> the installer.

It is my understanding Ubuntu has stopped using d-i, and thus very
likely the udebs.

Chris

Bug#988567: cubicsdr: crashes on first launch after install, lookes like not linked to right so

[Mr. T]

Package: cubicsdr
Version: 0.2.5+dfsg-3+b1
Severity: important
X-Debbugs-Cc: t...@treaki.tk

hi,
i just apt install'ed it and then tried to launch it:

~ $ CubicSDR Loaded 256 rig models via hamlib.

Audio Device #0 PulseAudio
Default Output? Yes
Default Input? Yes
Input channels: 2
Output channels: 2
Duplex channels: 2
Native formats:
16-bit signed integer.
32-bit signed integer.
32-bit float normalized between plus/minus 1.0.
Supported sample rates:
8000hz
16000hz
22050hz
32000hz
44100hz
48000hz
96000hz

SDR enumerator starting.
SoapySDR init..
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr
Loading modules... [ERROR] 
SoapySDR::loadModule(/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librfspaceSupport.so)
dlopen() failed: 
/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librfspaceSupport.so: 
undefined symbol: _ZN5boost6chrono12steady_clock3nowEv
Available factories...airspy, audio, bladerf, hackrf, lime, miri, null, 
osmosdr, redpitaya, remote, rtlsdr, uhd
[INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400; 
UHD_3.15.0.0-4+b1

Hash collision!!! Fatal error!!
Segmentation fault
~ $
but as you see its just crashing...

regards


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 cubicsdr depends on:
ii libc6 2.31-11
ii libgcc-s1 10.2.1-6
ii libglx0 1.3.2-1
ii libhamlib4 4.0-4
ii libliquid2d 1.3.2-2
ii libopengl0 1.3.2-1
ii librtaudio6 5.1.0~ds1-1
ii libsoapysdr0.7 0.7.2-2
ii libstdc++6 10.2.1-6
ii libtinyxml2.6.2v5 2.6.2-4
ii libwxbase3.0-0v5 3.0.5.1+dfsg-2
ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-2

Versions of packages cubicsdr recommends:
ii soapysdr-module-all 0.7.2-2

cubicsdr suggests no packages.

-- no debconf information

Bug#988566: /usr/bin/uscan: [uscan] Incorrect parsing of regular expressions in watch-files

[Patrick Franz]

Package: devscripts
Version: 2.21.2
Severity: normal
File: /usr/bin/uscan
X-Debbugs-Cc: patfr...@gmail.com

Dear Maintainer,

the watch-file for plasma-desktop (and all other Plasma packages accordingly) 
looks like this:

version=4 
opts=pgpsigurlmangle=s/$/.sig/ 
https://download.kde.org/stable/plasma/([\d.]+)/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

The stable releases can be found at https://download.kde.org/stable/plasma/ and 
are caught as intended.
The beta-releases, however, can be found at 
https://download.kde.org/unstable/plasma/ and are not 
caught by the regular expression as intended.

Changing the watch file to

version=4 
opts=pgpsigurlmangle=s/$/.sig/ 
https://download.kde.org/(un)?stable/plasma/([\d.]+)/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

should now catch both stable and unstable releases. Unfortunately, it only 
catches the unstable releases,
but not the stable releases any more.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#793675: hplip-gui: No system tray detected

[Richard B. Kreckel]

Hi,

On 15.05.21 10:32, Fabrice Bauzac-Stehly wrote:
> "Richard B. Kreckel"  writes:
> 
>> Running version 3.21.2+dfsg1-2 of package hplip-gui, the annoying
>> message still pops up after each login.
> 
> Version 3.21.2+dfsg1-2 does not contain the change to
> /etc/xdg/autostart/hplip-systray.desktop, so I expect that you get the
> annoying message.
> 
> The fixed version is 3.21.2+dfsg1-2+exp0.
> 
>> I have checked that /etc/xdg/autostart/hplip-systray.desktop indeed
>> contains the line saying NoShowIn=GNOME;
> 
> Have you modified it manually?

Indeed.

I had tried that fix from Ubuntu long ago and it didn't work...

...but now that you confirmed that it works, I tried again. And d'oh, I
had a typo in it! (NoShowIn=...)

Let's close this bug now...

   -richard.

Bug#988565: slapd-contrib: smbk5pwd crashes when enabling krb5 (again)

[Ryan Tandy]

Package: slapd-contrib
Version: 2.4.57+dfsg-2
Severity: serious

# ldapmodify -H ldapi:// -Y EXTERNAL << eof

dn: olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcSmbK5PwdConfig
olcSmbK5PwdEnable: krb5
eof

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config"
ldap_result: Can't contact LDAP server (-1)

Thread 3 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb5e98700 (LWP 2843)]
initialize_kadm5_error_table_r (list=0x7fffa8105048,
   list@entry=) at 
kadm5_err.c:101
101 kadm5_err.c: No such file or directory.


Same symptoms and root cause as #917129. Different package causing it.

This time the dependency chain is:
slapd -> libwrap.so.0 -> libnsl.so.2 -> libtirpc.so.3 -> libgssapi_krb5.so.2 -> libkrb5.so.3 

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Sanford Rockowitz]

Kernel 5.10 addressed a long standing problem with the I2C 
implementation for DisplayPort Multi-Stream Transport.  Only I2C reads 
were implemented, not writes. (See the nearly 4 year long thread 
at 
freedesktop.org.) As a result it was possible to read the EDID, but DDC 
communication failed. ddcutil reported such displays as "Invalid".


Unfortunately, there are problems with the implementation in 5.10 that 
ddcutil at least partially works around.  In particular, the same 
display can appear to be connected at 2 different /dev/i2c addresses, 
only one of which supports DDC.


All the connectors on a docking station, whether DP, DVI, or HDMI, are 
on a DisplayPort MST chain.  As Joris notes, the Thunderbolt connection 
on recent systems uses MST, so recent Type-C connected displays also 
didn't work.


Joris's report is the first indication I've had that there are displays 
(HDMI, not on a docking station) which ddcutil 0.9.9 successfully 
communicated with prior to kernel 5.10, but on on kernel 5.10 or 
later.   Modulo that, use of 0.9.9 with kernel 5.10 does not constitute 
a regression.   ddcutil 0.9.9 continues to work with the vast majority 
of displays on kernel 5.10.  It simply doesn't add functionality. Joris, 
if there really is a loss of functionality, can you submit, either here 
or on the ddcutil issue tracker 
 at Github) the output of 
"ddcutil environment --verbose" for ddcutil 0.9.9  and "ddcutil 
environment --very-verbose" for ddcutil 1.1.0 for both kernel 5.10 and 
one earlier than 5.10.


There is no simple patch that would bring 0.9.9 up to the functionality 
of 1.1.0 for MST displays.  The changes were extensive.



On 5/15/21 11:34 AM, Andrey Rahmatullin wrote:

On Sat, May 15, 2021 at 10:36:23AM -0400, Sanford Rockowitz wrote:

ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor (Andrey
Rahmatulin) it was not moved to sid because of the freeze for Bullseye.

If the package doesn't work with the bullseye kernel it's a grave bug, not
important, and the package should be fixed (or removed).
Ti be eligible for bullseye the update should be a minimal patch added to
the bullseye version.
What do you think?



On 5/14/21 1:10 AM, Joris wrote:

Package: ddcutil
Version: 0.9.9-2
Severity: important
Tags: upstream
X-Debbugs-Cc: jo...@v5.be




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

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

Versions of packages ddcutil depends on:
ii  i2c-tools 4.2-1+b1
ii  libc6 2.31-11
ii  libdrm2   2.4.104-1
ii  libglib2.0-0  2.66.8-1
ii  libudev1  247.3-5
ii  libx11-6  2:1.7.0-2
ii  libxrandr22:1.5.1-1
ii  pci.ids   0.0~2021.02.08-1
ii  usb.ids   2021.03.31-1
ii  usbutils  1:013-3

ddcutil recommends no packages.

ddcutil suggests no packages.

-- no debconf information


>From the release information on ddcutil (http://www.ddcutil.com/release_notes/) it seems 
Linux kernel 5.10 made changes. They are listed as "docking stations" but in my 
experience also apply to directly connected HDMI and Thunderbolt displays.
Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel. On my system 
bringing back the same capabilities I had under kernel 5.8, whereas with 
ddcutil 0.9.9 on kernel 5.10 there was simply no device detected.

As 5.10 seems to be the default in the upcoming Debian release, it would be 
very nice to get ddcutil updated as well.
I had no issue building ddcutil from source.

Bug#987359: RFS: sfxr-qt/1.3.0+git20210422-1 [ITP] -- sound effect generator, QtQuick port of sfxr

[Adam Borowski]

On Thu, Apr 22, 2021 at 11:58:08AM +0200, Gürkan Myczko wrote:
>  * Package name: sfxr-qt

>  sfxr-qt (1.3.0+git20210422-1) experimental; urgency=medium
>  .
>* Initial release. (Closes: #931030)

It builds, but on trying to start:

QQmlApplicationEngine failed to load component
qrc:/main.qml:288:9: Type FileActions unavailable
qrc:/FileActions.qml:27:9: Type FileDialog unavailable
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:42:1:
 module "QtQuick.Controls" version 1.2 is not installed


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant:
⣾⠁⢠⠒⠀⣿⡁   Reverently made for universal free distribution by Wang Jie
⢿⡄⠘⠷⠚⠋⠀   on behalf of his two parents on the 15th of the 4th moon of
⠈⠳⣄   the 9th year of Xiantong [11 May 868].

Bug#976147: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Otto Kekäläinen]

> I am in favour of removing galera-4 from Depends and as suggested by
> Olaf make it only a suggestion (Suggests), I am not sure if it's even
> necessary (after all, MariaDB standalone server and Galera cluster are
> two very different setup).

Yes we consider doing that. Note however that it does not fix this bug
in question, we still want the dist-upgrade for Galera users to
succeed. It also needs to be debugged and a MR submitted on how to
change Galera-4 debian/control file for the upgrade to pass
flawlessly.

> The salsa CI is still green when doing so:
> https://salsa.debian.org/faust/mariadb-10.5/-/pipelines/254990

Good. Did you also test upstream buildbot?

> Finally, galera-4 is not a dependency on RPM:
> | docker run fedora:latest bash -c "yum update -y && yum install 
> mariadb-server -y && rpm -qa | egrep 'mariadb|galera'"

Good point.

I digged into git blame and found out that I actually tried to make
galera-3 a recommends in 2015 but reverted because upstream tests
started failing:

Starting point: Depends: galera
https://github.com/MariaDB/server/commit/df4dd593f29aec8e2116aec1775ad4b8833d8c93#diff-70229a6b99c9cf63c053270b10c80d7fe50c33c7c167f7c1a4d84a093334d65bR195

Change:
https://github.com/MariaDB/server/commit/6bd94cf54274d54521ece1e50d534777122ff29e

Revert:
https://github.com/MariaDB/server/commit/6bd94cf54274d54521ece1e50d534777122ff29e


But as said, the bug #988089 can only be fixed by a change in galera-4
debian/control. Changing the mariadb-10.5 debian/control to
recommends:galera-4 is a separate change.

Bug#988089: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Otto Kekäläinen]

Faustin,

What you do in 
https://salsa.debian.org/faust/galera-4/-/commit/d0119633bd42ebcedb300fb7423035de4f91f1bc
with aptly and tmux and printf 'X\n' seems overly complex. To make a
local repo for testing you can simply run:

apt install apt-utils
cd /path/to/deb/files
apt-ftparchive release . > Release
echo 'deb [trusted=yes] file:/path/to/deb/files ./' >> /etc/apt/sources.list
apt update
apt dist-upgrade

See
https://manpages.debian.org/unstable/apt-utils/apt-ftparchive.1.en.html

Bug#988365: htmldoc 1.9.3-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: htmldoc
Version: 1.9.3-1+deb10u1

Explanation: fix buffer overflow issues [CVE-2019-19630 CVE-2021-20308]

Bug#988255: Acknowledgement (buster-pu: package mariadb-10.3 10.3.29-0+deb10u1)

[Otto Kekäläinen]

There hasn't been any responses from release team to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988255 in the past
week nor is there a release date for Debian 10.10 at
https://release.debian.org/

If the security team wants I can also target this as a security update
for Debian Buster?

- Otto

Bug#988564: Fails to build for Linux 5.6+

[Ben Hutchings]

Package: vpb-driver-source
Version: 4.2.61-1.1
Severity: grave
Tags: bullseye sid

vpb-driver-source fails to build for Linux kernel version 5.6 and
later.  This is due to a change in the proc_create_data() API.

Ben

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 vpb-driver-source depends on:
ii  bzip2 1.0.8-4
ii  debhelper 13.3.4
ii  make  4.3-4
ii  module-assistant  0.11.10

vpb-driver-source recommends no packages.

vpb-driver-source suggests no packages.

Bug#988204: apparmor: AppArmor container behavior inappropriate under WSL

[intrigeri]

Control: tag -1 + moreinfo

Hi,

Alistair Young (2021-05-07):
> Specifically, systemd-detect-virt detects WSL as a container,
> technically accurately, but this then causes the apparmor.systemd
> script to decline to start apparmor.

I'm trying to understand what's, at the end of the day, the desirable
behavior here, and why.

I understand you would like apparmor.service to start in a WSL
environment, i.e. you would like the AppArmor policy to be loaded.
Correct so far?

May I infer that a container run under WSL can actually load and
enforce AppArmor policy? In that case, IMO it would make much more
sense to have is_container_with_internal_policy return true (0) for
WSL containers, rather than tweaking apparmor.systemd to treat them as
non-containers.

Or is there any other reason why you want apparmor.service to start
under WSL?

Cheers!

Bug#988563: debian-installer: fresh bullseye install report (pxe boot ; lenovo thinkpad e15)

[Michel Briand]

Package: debian-installer
Version: 20190702+deb10u9
Severity: normal
Tags: l10n

Dear Maintainer,

I installed my new Lenovo Thinkpad E15 with Debian Bullseye.

I've setup my PXE + TFTP server with latest netboot.tar.gz.

I've installed Debian with the following options:
- France language, french keyboard
- assisted partman full disk with encryption
- bullseye distribution
- unchecked "debian desktop"
- checked plasma, xfce and lxqt desktops

Booting my new Debian system, initramfs can not load the (crypt) volume group.
Same problem as in #935973.

I solved this issue:
- booting on PXE
- choosing rescue
- chroot into system
- apt install cryptsetup-initramfs
  (this last operation recreates the initrd file)

My new system lacks the french localization for sddm and kde (even if I've 
choosen
France and Plasma in Debian installer).

I installed manually:
- task-french-desktop
- task-french-kde-desktop

When connecting to my bluetooth speaker, the pairing did work but the 
connection failed.
Pulseaudio was lacking the module for bluetooth.

apt install pulseaudio-module-bluetooth.

I think all those packages should be sensible defaults.

THANK YOU AND CONGRATULATIONS FOR THIS NEW DEBIAN RELEASE :))

Best regards

PS: I use only Debian on all my computers since 2005.

-- System Information:
Debian Release: 10.9
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#988562: Fails to build due to unspecified debhelper compatibility level

[Ben Hutchings]

Package: broadcom-sta-source
Version: 6.30.223.271-16
Severity: grave

The source package embedded in broadcom-sta-source cannot be built.
It does not define a debhelper compatibility level, which is mandatory
since debhelper 9.20160618, so all debhelper commands fail.

Ben.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 broadcom-sta-source depends on:
ii  debhelper [debhelper-compat]  13.3.4
ii  make  4.3-4
ii  xz-utils  5.2.5-2

Versions of packages broadcom-sta-source recommends:
ii  module-assistant  0.11.10

broadcom-sta-source suggests no packages.

Bug#877779: linux: modpost uses wrong sizes for mips-octeon kernel

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi James,

On Thu, Oct 05, 2017 at 03:24:12PM +0100, James Cowgill wrote:
> Source: linux
> Version: 4.12.13-1
> Severity: normal
> 
> Hi,
> 
> I recently attempted to install an out-of-tree module (an old version of
> the octeon mmc driver) on an octeon machine running big endian 32-bit
> mips. In this configuration, the kernel is 64-bit, but userspace is 32-bit.
> 
> The module build failed with this error:
> > LD [M]  /var/lib/dkms/octeon-mmc/9/build/octeon-mmc.o
> >   Building modules, stage 2.
> >   MODPOST 1 modules
> > FATAL: /var/lib/dkms/octeon-mmc/9/build/octeon-mmc: sizeof(struct 
> > of_device_id)=196 is not a modulo of the size of section 
> > __mod_of___device_table=600.
> > Fix definition of struct of_device_id in mod_devicetable.h
> 
> of_device_id is defined like this in mod_devicetable.h:
> > struct of_device_id {
> > charname[32];
> > chartype[32];
> > charcompatible[128];
> > const void *data;
> > };
> 
> The size of this structure is 200 bytes and not 196 byte as modpost
> claims because the kernel is compiled as 64-bit (so the pointer at the
> end is 8 bytes instead of 4).
> 
> I think there is a bug in the way Debian compiles modpost, because using
> upstream's modpost works correctly. I see that the
> real-XXX/devicetable-offsets.s file gets compiled with the target
> compiler, but not with the target flags so flags such as "-mabi=64
> -mnoabicalls" which are used in 64-bit MIPS kernels are not used. This
> will cause the compiler to default to the userspace ABI which is 32-bit
> in this case.
> 
> I'm not sure what the correct solution is here. Using the target flags
> directly might make modpost specific to a kernel flavour. Hacking in
> some special flags for mips* doesn't sound great either.
> 
> I have not tested any other platforms, but I am guessing this issue will
> affect other platforms when the size of pointers in userspace and the
> kernel differ.

Going through some older bugreports for src:linux found the above; Is
this still an issue? I have not digged deeper at all.

Regards,
Salvatore

Bug#877763: linux: Still occuring in linux-4.19.0-2-amd64: fs/btrfs/ctree.h:1588 btrfs_update_device

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Sun, Mar 03, 2019 at 07:31:34AM -0600, Matthew Goff wrote:
> Source: linux
> Followup-For: Bug #877763
> 
> Dear Maintainer,
> 
> I'm still seeing these btrfs trace messages on 4.19.0-2-amd64

Are you still experiencing the issues with a kernel from unstable or
buster-backports?

If yes, can you please report this upstream, keeping this bug in the
loop?

Regards,
Salvatore

Bug#988559: [Pkg-javascript-devel] Bug#988559: Support reading from lerna.json to find components automatically

[Pirate Praveen]

On Sat, May 15, 2021 at 8:30 pm, Yadd  wrote:

Le 15/05/2021 à 20:18, Pirate Praveen a écrit :

 Package: pkg-js-tools
 Version: 0.9.65
 Severity: wishlist

 Example module @toast-ui/editor

 Read lerna.json and install these similar to entries in
 debian/nodejs/components

 {
 "packages": ["apps/*", "plugins/*", "libs/*"],
 "version": "2.1.0"
 }


Hi,

pkg-js-tools doesn't modify debian/* files for now. Maybe this is the
job of npm2deb ?


That will work too, or pkg-js-tools could read this directly, may be 
npm2deb is better option.

Bug#988559: [Pkg-javascript-devel] Bug#988559: Support reading from lerna.json to find components automatically

[Yadd]

Le 15/05/2021 à 20:18, Pirate Praveen a écrit :
> Package: pkg-js-tools
> Version: 0.9.65
> Severity: wishlist
> 
> Example module @toast-ui/editor
> 
> Read lerna.json and install these similar to entries in
> debian/nodejs/components
> 
> {
> "packages": ["apps/*", "plugins/*", "libs/*"],
> "version": "2.1.0"
> }

Hi,

pkg-js-tools doesn't modify debian/* files for now. Maybe this is the
job of npm2deb ?

Bug#988560: Package should be in contrib, as it depends on non-free software

[George Shuklin]

Package: pygithub
Version: 1.43.7-1
Severity: normal

Pygithub is completely dependent on Github API, which is a proprietary 
software. I believe this package must be in contrib section (instead of main).
Debian Policy chapter2.2.2 says that 'wrapper packages or other sorts of free 
accessories for non-free programs' should be in contrib section of the Archive.
pygithub is clearly 'free accessory' for 'non free' Github server.

Bug#988559: Support reading from lerna.json to find components automatically

[Pirate Praveen]

Package: pkg-js-tools
Version: 0.9.65
Severity: wishlist

Example module @toast-ui/editor

Read lerna.json and install these similar to entries in 
debian/nodejs/components


{
 "packages": ["apps/*", "plugins/*", "libs/*"],
 "version": "2.1.0"
}

Bug#988558: Fails to build against Linux version 5.3+

[Ben Hutchings]

Source: leds-alix
Version: 0.0.1-1.2
Severity: grave
Tags: bullseye sid patch

The Makefile in leds-alix invokes the kernel build system with the
SUBDIRS variable set.  This was deprecated long ago and is no longer
supported since Linux 5.3.  The patch below allows it to build again,
though I don't know whether it *works*.

Ben.

--- a/Makefile
+++ b/Makefile
@@ -19,10 +19,10 @@
 all: $(MODULE)
 
 $(MODULE): $(SOURCE)
-   $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
+   $(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules
 
 install: $(MODULE)
-   $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) 
INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) modules_install
+   $(MAKE) -C $(KERNEL_DIR) M=$(PWD) INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) 
modules_install
depmod -ae
 
 uninstall:
--- END ---

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

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

Bug#988557: Diff

[Anton Gladky]

Diff is now attached.

Anton
diff -Nru sundials-4.1.0+dfsg/debian/changelog sundials-4.1.0+dfsg/debian/changelog
--- sundials-4.1.0+dfsg/debian/changelog	2020-12-20 14:20:47.0 +0100
+++ sundials-4.1.0+dfsg/debian/changelog	2021-05-15 16:51:20.0 +0200
@@ -1,3 +1,9 @@
+sundials (4.1.0+dfsg-4) unstable; urgency=medium
+
+  * [5c80d16] Install libsundials_*sunnonlinsol*.so.*. (Closes: #988551)
+
+ -- Anton Gladky   Sat, 15 May 2021 16:51:20 +0200
+
 sundials (4.1.0+dfsg-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru sundials-4.1.0+dfsg/debian/libsundials-sunlinsol2.install sundials-4.1.0+dfsg/debian/libsundials-sunlinsol2.install
--- sundials-4.1.0+dfsg/debian/libsundials-sunlinsol2.install	2020-12-07 20:30:37.0 +0100
+++ sundials-4.1.0+dfsg/debian/libsundials-sunlinsol2.install	2021-05-15 16:50:44.0 +0200
@@ -1 +1,2 @@
 usr/lib/*/libsundials_*sunlinsol*.so.*
+usr/lib/*/libsundials_*sunnonlinsol*.so.*

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Ritesh Raj Sarraf  (2021-05-15):
> That'd be nice of you. So, yes, please.
> 
> And you'd be the next best team (debian-boot) to test that feature as
> it is specific to d-i.

Here we go, udeb-support branch in:
  https://salsa.debian.org/kibi/open-iscsi

Tested successfully on amd64:
 - produces the udeb;
 - has the udeb entry in the library's shlibs file.

and on armel:
 - doesn't build the udeb;
 - doesn't have the udeb entry in the library's shlibs file.


For reference, what the second commit does is distinguish between:

kibi@tokyo:~/hack/open-iscsi.git$ dpkg --print-architecture
amd64
kibi@tokyo:~/hack/open-iscsi.git$ dh_listpackages 
open-iscsi
libopeniscsiusr
libopeniscsiusr-dev
iscsiuio
open-iscsi-udeb

and:

(sid_armel-dchroot)kibi@amdahl:~/open-iscsi-2.1.3$ dpkg 
--print-architecture   
armel
(sid_armel-dchroot)kibi@amdahl:~/open-iscsi-2.1.3$ dh_listpackages 
open-iscsi
libopeniscsiusr
libopeniscsiusr-dev
iscsiuio

Please let me know if you have any questions or objections, I'm happy to
help refine this further.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#988557: unblock: sundials/4.1.0+dfsg-4

[Anton Gladky]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,
please unblock package sundials.

Version 4.1.0+dfsg-4 fixes RC-Bug #988551. Diff is attached.

unblock sundials/4.1.0+dfsg-4

Thanks

Anton

Bug#988540: im-config: breaks the keyboard configuration

[Gunnar Hjalmarsson]

On 2021-05-15 18:55, Vincent Lefevre wrote:

It doesn't output everything that is set. For instance, I use
LC_TIME=en_DK.utf8, and reportbug doesn't output it. However,
this setting is still available.


That is just a consequence of the fact that LC_ALL is set.

Bug#886420: Still doesn't autostart

[Borden]

15 May 2021, 03:06 by jo...@jones.dk:
> That's intentional: Reason is documented in 
> /usr/share/doc/radicale/README.Debian:
>
>> Recommended setup for production use is to serve system-wide
>> by Apache via uWSGI with Apache-based authenticating.
>>
>
> and
>
>> It should be possible to serve directly with sysV management,
>> although this is discouraged and not well tested.
>>
>
>
> Kind regards,
>
>  - Jonas
Since I have your attention, I'm happy to open a separate report or take the 
discussion elsewhere.

I found the README.Debian very challenging to understand. My efforts to find 
supplemental support, including on wiki.debian.org, radicale.org and even 
looking up uWSGI were equally frustrated.

For starters, my understanding is that sysV != systemd, so it wasn't clear to 
me that disabling radicale.service was explained in this paragraph.

I have other comments about the documentation and, with your support, I'm happy 
to draft changes to the wiki and Readme that may help reduce your service calls.

Let me know :-)

Bug#976147: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Faustin Lammler]

Hi!
I am in favour of removing galera-4 from Depends and as suggested by
Olaf make it only a suggestion (Suggests), I am not sure if it's even
necessary (after all, MariaDB standalone server and Galera cluster are
two very different setup).

The salsa CI is still green when doing so:
https://salsa.debian.org/faust/mariadb-10.5/-/pipelines/254990

Plus, even if I can't reproduce this dist-upgrade problem on the Salsa
CI, on my personal drone CI, doing so also resolve the problem from an
upstream build with
https://github.com/fauust/mariadb-server/tree/fix-dist-upgrade whereas
the problem exists on the 10.5 branch.

Finally, galera-4 is not a dependency on RPM:
| docker run fedora:latest bash -c "yum update -y && yum install mariadb-server 
-y && rpm -qa | egrep 'mariadb|galera'"

I have asked on Zulip if there is any reason of this dependency that I
could have missed.

Cheers!

-- 
Faustin


signature.asc
Description: PGP signature

Bug#988546: iwyu.1, include-what-you-use.1: Missing sections in the manual page

[Alejandro Colomar]

Hi,

On 5/15/21 1:14 PM, Alejandro Colomar wrote:
> Package: iwyu
> Version: 8.15-2
> Severity: minor
> X-Debbugs-Cc: Alejandro Colomar (man-pages) 
> 
> Dear Maintainer,
> 
> The manual page for this package has some formatting errors,
> and has everything in the DESCRIPTION section.
> 
> I found that the upstream manual page is correct, so it's a bug specific to
> Debian.  Where is the Debian manual page coming from??
> 
> See 
> .

I digged in Salsa, and it looks like the manual page there

is the same as the upstream one, but the ones I got installed with
`apt-get install iwyu` are very different
(,
).  Is there anything you
do when you build the package that changes them so much?

Thanks,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Sat, 2021-05-15 at 17:37 +0200, Cyril Brulebois wrote:
> Ritesh Raj Sarraf  (2021-05-15):
> > Yes. That scsi-modules support bites back now. I just forgot about
> > it
> > completely. My intent was to not duplicate another architecture
> > list
> in
> > d/rules, and in trying to simplify things, it has just fallen apart
> > with this old oddity of support on armel.
> 
> I'm happy to provide (and test) a patch that would only hardcode the
> list in debian/control, and make sure the extra steps aren't run from
> debian/rules. If you like the idea, you might get a patch in the next
> few hours.

That'd be nice of you. So, yes, please.

And you'd be the next best team (debian-boot) to test that feature as
it is specific to d-i.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#988540: im-config: breaks the keyboard configuration

[Vincent Lefevre]

On 2021-05-15 17:54:39 +0200, Gunnar Hjalmarsson wrote:
> But due to that, the "locale output" section in /usr/share/bug/im-config
> isn't so useful. Previously I mentioned the idea to add "unset LC_ALL" in
> the script. Or should we better drop the "locale output" section?
> 
> Quoting from /usr/share/doc/reportbug/README.developers.gz:
> 
> "Part of reportbug "System Information" section of a bug template, already
> contains the locale information, no need for your bugscript to re-discover
> that information again."

Indeed, since reportbug modifies the locales, it should provide the
relevant information. However, this may currently be incomplete:
nothing about LC_ALL, which is precisely what is modified by reportbug.

It doesn't output everything that is set. For instance, I use
LC_TIME=en_DK.utf8, and reportbug doesn't output it. However,
this setting is still available.

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

Bug#964803: dbus-daemon: unaligned trap on alpha

[Rich]

I can't find a setting to do that in Linux sysctl or
kernel-parameters; or searching around, do you have a pointer?

I tried just telling /etc/systemd/system.conf
DefaultLimitCORE=infinity, setting a non-default path in
kernel.core_pattern in sysctl.conf, restarting, restarting dbus after
boot, and running find after systemctl status dbus reported dying with
SEGV, but I don't see any cores, in the path I set with core_pattern
or otherwise. :(

- Rich

On Sat, May 15, 2021 at 11:31 AM Simon McVittie  wrote:
>
> On Sat, 15 May 2021 at 10:42:55 -0400, Rich wrote:
> > I came here to report this very problem, but "reportbug" suggested I
> > try the dbus from experimental(!), so I did, and the problem (in my
> > very limited experimenting) seems to have gone away...
>
> Are you able to configure the system to dump core on misalignment, and
> get a backtrace from the situation(s) where it crashes?
>
> If 1.12.x crashes and 1.13.x does not, this might mean that commit 26d5d97d
> "Don't cast user-supplied pointers to DBusBasicValue *" is what solved it
> for you.
>
> smcv

Bug#988547: apt: Apt seems to keep back galera-3 without reason

[David Kalnischkies]

Hi,

On Sat, May 15, 2021 at 03:57:28PM +0200, Olaf van der Spek wrote:
> Op za 15 mei 2021 om 15:35 schreef David Kalnischkies :
> > galera-3 does not seem to have recommends, but it wasn't updated for
> > 6 months either and you haven't told us the versions involved, so
> > perhaps that's from a different repository…
> 
> It is, I was testing a Debian 10 -> 11 upgrade.
> See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089

(Ahhh. The bugreport said it was testing/sid system, so I thought you
 were on it for a while already, not just upgraded from stable…)

>   MarkInstall mariadb-server:amd64 < 1:10.3.27-0+deb10u1 -> 1:10.5.9-1 @ii 
> umU Ib > FU=0
>   Installing mariadb-server-10.5:amd64 as Depends of mariadb-server:amd64
> MarkInstall mariadb-server-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > 
> FU=0
> Installing galera-4:amd64 as Depends of mariadb-server-10.5:amd64
>   MarkKeep galera-3:amd64 < 25.3.25-2 -> 25.3.31-2+b1 @ii umU > FU=0
>Delayed Removing: galera-3:amd64 as upgrade is not an option for 
> galera-4:amd64 (26.4.7-3)
>   MarkInstall galera-4:amd64 < none -> 26.4.7-3 @un uN Ib > FU=0
>   MarkDelete galera-3:amd64 < 25.3.25-2 | 25.3.31-2+b1 @ii umH Ib > FU=0

So upgrading mariadb will bring you galera-4 which conflicts with
galera-3. Package removals are not allowed in 'upgrade' so this mariadb
upgrade will be reverted and you will get it in the next step with
a full-upgrade – which will remove galera-3.

So, yeah, apt could potentially figure out that it could upgrade
galera-3 in this setup as it can't do the mariadb upgrade, but in
practice this will just waste a bit of time and download bandwidth as
(upgraded or not) it will be removed in the next step.


I will leave this bug open as I have some ideas how to improve this code
area a bit in general, which might or might not work and might or might
not "solve" this (future me: pkgDepCache::Is{Install,Delete}Ok overload)
but that will be bookworm material.

In regards to the mariadb versioned packages and the potential for
upgrade problems they produce I had recently talked to its maintainer,
so I doubt that will change any time soon…
https://lists.debian.org/debian-devel/2021/03/msg00239.html


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Andrey Rahmatullin]

On Sat, May 15, 2021 at 10:36:23AM -0400, Sanford Rockowitz wrote:
> ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor (Andrey
> Rahmatulin) it was not moved to sid because of the freeze for Bullseye.
If the package doesn't work with the bullseye kernel it's a grave bug, not
important, and the package should be fixed (or removed).
Ti be eligible for bullseye the update should be a minimal patch added to
the bullseye version.
What do you think?


> On 5/14/21 1:10 AM, Joris wrote:
> > Package: ddcutil
> > Version: 0.9.9-2
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: jo...@v5.be
> > 
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >APT prefers testing-security
> >APT policy: (500, 'testing-security'), (500, 'testing')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=en_GB:en
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages ddcutil depends on:
> > ii  i2c-tools 4.2-1+b1
> > ii  libc6 2.31-11
> > ii  libdrm2   2.4.104-1
> > ii  libglib2.0-0  2.66.8-1
> > ii  libudev1  247.3-5
> > ii  libx11-6  2:1.7.0-2
> > ii  libxrandr22:1.5.1-1
> > ii  pci.ids   0.0~2021.02.08-1
> > ii  usb.ids   2021.03.31-1
> > ii  usbutils  1:013-3
> > 
> > ddcutil recommends no packages.
> > 
> > ddcutil suggests no packages.
> > 
> > -- no debconf information
> > 
> > 
> > >From the release information on ddcutil 
> > >(http://www.ddcutil.com/release_notes/) it seems Linux kernel 5.10 made 
> > >changes. They are listed as "docking stations" but in my experience also 
> > >apply to directly connected HDMI and Thunderbolt displays.
> > Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel. On my system 
> > bringing back the same capabilities I had under kernel 5.8, whereas with 
> > ddcutil 0.9.9 on kernel 5.10 there was simply no device detected.
> > 
> > As 5.10 seems to be the default in the upcoming Debian release, it would be 
> > very nice to get ddcutil updated as well.
> > I had no issue building ddcutil from source.
> > 
> 
> 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#988486: bouncycastle: upstream version is 1.68, but poms install as 1.65

[tony mancill]

On Thu, May 13, 2021 at 05:44:35PM -0700, tony mancill wrote:
> Source: bouncycastle
> Version: 1.68-1
> Severity: minor
> 
> I noticed while updating bouncycastle to include the bctls that the
> poms weren't refreshed for the 1.68-1 upload and the package installs
> the jars as version 1.65.
> 
> I will address this with an upload of 1.68-2 *before* adding the new
> binary package for bctls (which will result in the packaging going
> through NEW).  Maybe there's still time to fix this for bullseye.

Now that this is fixed in unstable, any thoughts from the Java Team
about whether I should request an unblock from the Release Team for this
bug for Bullseye?  It may prevent some potential confusion but is
otherwise, as far as I can tell, purely cosmetic.  Thus, although there
is no risk, I'm not certain about how to justify the request.

I could wait and request an update via s-p-u.

Thanks,
tony

Bug#988540: im-config: breaks the keyboard configuration

[Gunnar Hjalmarsson]

On 2021-05-15 17:20, Vincent Lefevre wrote:

On 2021-05-15 16:07:46 +0200, Gunnar Hjalmarsson wrote:

What's the contents of your /etc/default/locale file?


#  File generated by update-locale
#LANG="en_US.UTF-8"
LANGUAGE="en_US:en"


Can you please replace

#LANG="en_US.UTF-8"

with

LANG="C.UTF-8"

and then re-enable im-config:

im-config -n REMOVE

and reboot.


Now I can see

dbus-update-activation-environment: setting LANG=C.UTF-8

in the .xsession-errors file.


Does ibus/im-config still mess up your keyboard configuration?


Yes, still the same issue.

But if I add "sleep 3" in my .xsession file before executing xkbcomp,
then the issue disappears. There seems to be a race condition.


Yeah.. Wondering if the explanation can be that ~/.xsession is sourced 
before the launch of ibus-daemon has been completed.


@Changwoo, do you have any theory on this?

Bug#988540: im-config: breaks the keyboard configuration

[Gunnar Hjalmarsson]

Hi Changwoo,

On 2021-05-15 16:35, Changwoo Ryu wrote:

2021년 5월 15일 (토) 오후 8:21, Gunnar Hjalmarsson 님이 작성:


I see one thing which looks suspicious: You have set the LC_ALL
environment variable to C. LC_ALL is not supposed to be set permanently.
Ever. Especially not to C, which disables UTF-8 encoding.


Actually LC_ALL=C is set by reportbug and it's an intended
behavior; see /usr/share/doc/reportbug/README.developers.gz


Yeah, that's what I came to suspect. Thanks for pointing at the relevant 
documentation.


But due to that, the "locale output" section in /usr/share/bug/im-config 
isn't so useful. Previously I mentioned the idea to add "unset LC_ALL" 
in the script. Or should we better drop the "locale output" section?


Quoting from /usr/share/doc/reportbug/README.developers.gz:

"Part of reportbug "System Information" section of a bug template, 
already contains the locale information, no need for your bugscript to 
re-discover that information again."


/ Gunnar

Bug#912717: msg.sock issue still upstream

[Daniel Reichelt]

confirmed on

buster 2:4.9.5+dfsg-5+deb10u1

and

bullseye/sid 2:4.13.5+dfsg-2


cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#988556: freebayes FTCBFS -- B-D on python3

[Nilesh Patra]

Package: freebayes
Version: 1.3.5-1
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

freebayes has cross-satisfiablity issues due to B-D on python3.
While in principle it can simply be annotated with :any, but it seems
that this B-D is unused, and it works perfectly fine w/o Build depending
on the same.

The B-D on python3 has been dropped and commited to salsa[1]. It can and
should be uploaded post bullseye release.
Filing this bug so this change isn't lost.

[1]: 
https://salsa.debian.org/med-team/freebayes/-/commit/4747e62a71f09d014f4fc411842de048c60b8650

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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: unable to detect

Versions of packages freebayes depends on:
ii  libc62.31-3
ii  libgcc-s111-20210220-1
pn  libseqlib2   
ii  libstdc++6   11-20210220-1
pn  libtabixpp0  
pn  libvcflib1   
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages freebayes recommends:
ii  parallel  20161222-1.1

freebayes suggests no packages.

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Ritesh Raj Sarraf  (2021-05-15):
> Yes. That scsi-modules support bites back now. I just forgot about it
> completely. My intent was to not duplicate another architecture list in
> d/rules, and in trying to simplify things, it has just fallen apart
> with this old oddity of support on armel.

I'm happy to provide (and test) a patch that would only hardcode the
list in debian/control, and make sure the extra steps aren't run from
debian/rules. If you like the idea, you might get a patch in the next
few hours.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Sat, 2021-05-15 at 16:30 +0200, Cyril Brulebois wrote:
> It's just scsi-modules that's not available on armel apparently.
> 
> As far as I know, armel is in “maintenance mode” anyway, trying not
> to
> lose support for old devices. I wouldn't worry if an optional
> component
> like open-iscsi(-udeb) would not be installable on this single
> architecture. I'll let folks from debian-arm@ comment further on
> this.
> 
> But of course, this is a problem that prevents migration now, 

> let's
> check why; the old Architecture list looked like this (before
> switching
> it to linux-any):
> 
>     Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc
> ppc64
> ppc64el s390x
> 
> without armel so you had no installability issue there… Note that
> this
> was actually explained in the comment just before that line:
> 
>     # Note: the (virtual) udeb package scsi-modules (provided by
> different
>     #   linux kernel udebs) must exist for these architectures -
> so
>     #   check that before adding them to this list; the other
>     #   scsi-(core|common|...)-modules are NOT sufficient!
> 
> An obvious fix would be to revert to an hardcoded list of supported
> architectures (and requesting a removal of the obsolete armel binary
> that should start appearing in the cruft report[1] once that has
> happened); that's not too nice but I don't see any obvious better fix
> right now.

Yes. That scsi-modules support bites back now. I just forgot about it
completely. My intent was to not duplicate another architecture list in
d/rules, and in trying to simplify things, it has just fallen apart
with this old oddity of support on armel.

Time is pressing and I'm wondering what best to do here. I certainly do
not care much for the iSCSI support in the installer. I didn't write or
test that feature either. And I'm not even sure if that module even
works well in the installer. There's 'Root on (iSCSI + DM Multipath)'
that I use and care for but that doesn't even get set through the d-i
installer. Instead, the setup is to bootstrap the root LUN.

Maybe best to rope-in Ubuntu folks. I believe they make use of it in
the installer. I personally would like to drop the iSCSI support in the
installer, simply because I don't use it and don't have the commitment
to support/test it, nor the necessary hands-on knowledge if a bug is
reported. But derivatives may have a dependency on it.

The current easy fix, as Cyril mentioned above, it to revert it back to
the previous architecture list and adapt the same in d/rules in target
override_dh_makeshlibs.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#964803: dbus-daemon: unaligned trap on alpha

[Simon McVittie]

On Sat, 15 May 2021 at 10:42:55 -0400, Rich wrote:
> I came here to report this very problem, but "reportbug" suggested I
> try the dbus from experimental(!), so I did, and the problem (in my
> very limited experimenting) seems to have gone away...

Are you able to configure the system to dump core on misalignment, and
get a backtrace from the situation(s) where it crashes?

If 1.12.x crashes and 1.13.x does not, this might mean that commit 26d5d97d
"Don't cast user-supplied pointers to DBusBasicValue *" is what solved it
for you.

smcv

Bug#988540: im-config: breaks the keyboard configuration

[Vincent Lefevre]

On 2021-05-15 16:07:46 +0200, Gunnar Hjalmarsson wrote:
> > > What's the contents of your /etc/default/locale file?
> > 
> > #  File generated by update-locale
> > #LANG="en_US.UTF-8"
> > LANGUAGE="en_US:en"
> 
> Can you please replace
> 
> #LANG="en_US.UTF-8"
> 
> with
> 
> LANG="C.UTF-8"
> 
> and then re-enable im-config:
> 
> im-config -n REMOVE
> 
> and reboot.

Now I can see

dbus-update-activation-environment: setting LANG=C.UTF-8

in the .xsession-errors file.

> Does ibus/im-config still mess up your keyboard configuration?

Yes, still the same issue.

But if I add "sleep 3" in my .xsession file before executing xkbcomp,
then the issue disappears. There seems to be a race condition.

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

Bug#988555: RFS: hpcc/1.5.0-2.1 [NMU] [RC] -- HPC Challenge benchmark

[François Mazen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: hpcc
   Version : 1.5.0-2.1
   Upstream Author : [fill in name and email of upstream]
 * URL : http://icl.cs.utk.edu/hpcc/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/hpc-team/hpcc
   Section : science

It builds those binary packages:

  hpcc - HPC Challenge benchmark

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hpcc/hpcc_1.5.0-2.1.dsc

Changes since the last upload:

 hpcc (1.5.0-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix FTBFS with recent openMPI (Closes: #952067)

Regards,

Bug#886420: Still doesn't autostart

[Jonas Smedegaard]

Quoting Borden (2021-05-15 15:12:23)
> Since I have your attention, I'm happy to open a separate report or 
> take the discussion elsewhere.

Please file as a separate bugreport.

Thanks,

 - Jonas

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

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

signature.asc
Description: signature

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Sanford Rockowitz]

ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor (Andrey 
Rahmatulin) it was not moved to sid because of the freeze for Bullseye.



On 5/14/21 1:10 AM, Joris wrote:

Package: ddcutil
Version: 0.9.9-2
Severity: important
Tags: upstream
X-Debbugs-Cc: jo...@v5.be




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

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

Versions of packages ddcutil depends on:
ii  i2c-tools 4.2-1+b1
ii  libc6 2.31-11
ii  libdrm2   2.4.104-1
ii  libglib2.0-0  2.66.8-1
ii  libudev1  247.3-5
ii  libx11-6  2:1.7.0-2
ii  libxrandr22:1.5.1-1
ii  pci.ids   0.0~2021.02.08-1
ii  usb.ids   2021.03.31-1
ii  usbutils  1:013-3

ddcutil recommends no packages.

ddcutil suggests no packages.

-- no debconf information


>From the release information on ddcutil (http://www.ddcutil.com/release_notes/) it seems 
Linux kernel 5.10 made changes. They are listed as "docking stations" but in my 
experience also apply to directly connected HDMI and Thunderbolt displays.
Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel. On my system 
bringing back the same capabilities I had under kernel 5.8, whereas with 
ddcutil 0.9.9 on kernel 5.10 there was simply no device detected.

As 5.10 seems to be the default in the upcoming Debian release, it would be 
very nice to get ddcutil updated as well.
I had no issue building ddcutil from source.

Bug#964803: FWIW...

[Rich]

I came here to report this very problem, but "reportbug" suggested I
try the dbus from experimental(!), so I did, and the problem (in my
very limited experimenting) seems to have gone away...

$ sudo systemctl status dbus
● dbus.service - D-Bus System Message Bus
 Loaded: loaded (/lib/systemd/system/dbus.service; static)
 Active: active (running) since Sat 2021-05-15 10:41:05 EDT; 5s ago
TriggeredBy: ● dbus.socket
   Docs: man:dbus-daemon(1)
   Main PID: 1599 (dbus-daemon)
  Tasks: 1 (limit: 4810)
 Memory: 768.0K
CPU: 83ms
 CGroup: /system.slice/dbus.service
 └─1599 /usr/bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation --syslog-only

May 15 10:41:05 alphatest systemd[1]: Starting D-Bus System Message Bus...
May 15 10:41:05 alphatest systemd[1]: Started D-Bus System Message Bus.
$ uname -a
Linux alphatest 5.10.0-6-alpha-generic #1 Debian 5.10.28-1
(2021-04-09) alpha GNU/Linux
$  dpkg -l | grep dbus
ii  dbus 1.13.18-2
 alphasimple interprocess messaging system (system message
bus)
[...]

- Rich

Bug#988540: im-config: breaks the keyboard configuration

[Changwoo Ryu]

Hello,

2021년 5월 15일 (토) 오후 8:21, Gunnar Hjalmarsson 님이 작성:
>
> I see one thing which looks suspicious: You have set the LC_ALL
> environment variable to C. LC_ALL is not supposed to be set permanently.
> Ever. Especially not to C, which disables UTF-8 encoding.

Actually LC_ALL=C is set by reportbug and it's an intended
behavior; see /usr/share/doc/reportbug/README.developers.gz

Bug#871779: /sbin/mount.cifs: Some remote folders missing when mounting the share using -o vers=2.x option

[Salvatore Bonaccorso]

Source: linux
Source-Version: 4.19~rc7-1~exp1

On Fri, Aug 11, 2017 at 03:02:56PM +0200, Thibault Roulet wrote:
> Package: cifs-utils
> Version: 2:6.7-1
> Severity: normal
> File: /sbin/mount.cifs
> Tags: upstream
> 
> Dear Maintainer,
> 
> I have a shared folder on a windows 7 ENT Machine
> Mounting this folder using the following options
> mount -t cifs //host-address/share -o
> username=user,password=mypassword,ro /path/to/folder/
> I can list the whole content of the shared zone
> 
> # ls -1
> byuno
> cyxmry
> dubikovpkxyx
> dypon
> ruyo
> Fxypxnrh
> foyyo
> fyxurnyxth
> gyxrtprl
> hu
> johnppon
> mxppxnti
> nxprry
> Qurrn
> $RECYCLE.BIN
> prvryin
> ptrllxcci
> ptylixnou
> System Volume Information
> wxpry
> phu
> pobi
> 
> Then when mounting the same folder with
> mount -t cifs //host-address/share -o
> username=user,password=mypassword,ro,vers=2.1 /path/to/folder/
> 
> # ls -1
> cyxmry
> dubikovpkxyx
> dypon
> ruyo
> Fxypxnrh
> foyyo
> fyxurnyxth
> gyxrtprl
> hu
> johnppon
> mxppxnti
> nxprry
> Qurrn
> prvryin
> ptrllxcci
> ptylixnou
> System Volume Information
> wxpry
> phu
> pobi
> 
> The $RECYCLE.BIN folder is missing but also the byuno folder
> I would say I don't care about the RECYCLE.BIN one as it's the trash but the
> other one should be there.
> I checked the permissions/owner of this folder, it's the same as the others.

The upstream commit 0595751f2679 ("smb2: fix missing files in root
share directory listing") landed in 4.19-rc7 and got backported to
various stable series.

Regards,
Salvatore

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Hi,

(cc += debian-arm@)

Ritesh Raj Sarraf  (2021-05-15):
> While this bug is now in fixed status with the recent upload of open-
> iscsi version 2.1.3-4, there's still some other issue about the udeb
> being reported on the tracker package.
> 
> In particular, it metions:
> open-iscsi-udeb/armel has unsatisfiable dependency
> 
> I see no difference in the generated deb's dependency list. Is it
> something you are aware of, in general, about d-i's status on armel ?
> Or are there still bugs from the installer's point of view, where I
> need to step in ?

It's just scsi-modules that's not available on armel apparently.

As far as I know, armel is in “maintenance mode” anyway, trying not to
lose support for old devices. I wouldn't worry if an optional component
like open-iscsi(-udeb) would not be installable on this single
architecture. I'll let folks from debian-arm@ comment further on this.

But of course, this is a problem that prevents migration now, let's
check why; the old Architecture list looked like this (before switching
it to linux-any):

Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64 ppc64el 
s390x

without armel so you had no installability issue there… Note that this
was actually explained in the comment just before that line:

# Note: the (virtual) udeb package scsi-modules (provided by different
#   linux kernel udebs) must exist for these architectures - so
#   check that before adding them to this list; the other
#   scsi-(core|common|...)-modules are NOT sufficient!

An obvious fix would be to revert to an hardcoded list of supported
architectures (and requesting a removal of the obsolete armel binary
that should start appearing in the cruft report[1] once that has
happened); that's not too nice but I don't see any obvious better fix
right now.

 1. https://ftp-master.debian.org/cruft-report-daily.txt


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#988508: buster-pu: package gnutls28/3.6.7-4+deb10u7

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-05-14 at 14:08 +0200, Andreas Metzler wrote:
> I would like to fix three minor security issues (non-DSA) in stable.
> * 46_handshake-reject-no_renegotiation-alert-if-handshake.patch
> pulled from
>   3.6.15: It was found by oss-fuzz that the server sending a
>   "no_renegotiation" alert in an unexpected timing, followed by an
> invalid
>   second handshake can cause a TLS 1.3 client to crash via a null-
> pointer
>   dereference. The crash happens in the application's error handling
> path,
>   where the gnutls_deinit function is called after detecting a
> handshake
>   failure.
>   GNUTLS-SA-2020-09-04 CVE-2020-24659 Closes: #969547
> * Pull multiple fixes designated for 3.6.15 bugfix release:
>   + 47_rel3.6.16_01-gnutls_buffer_append_data-remove-duplicated-
> code.patch
>   + 47_rel3.6.16_02-_gnutls_buffer_resize-add-option-to-use-
> allocation-s.patch
>   + 47_rel3.6.16_03-key_share-avoid-use-after-free-around-
> realloc.patch
> (CVE-2021-20231) and
> 47_rel3.6.16_04-pre_shared_key-avoid-use-after-free-around-
> realloc.patch
> (CVE-2021-20232), both together GNUTLS-SA-2021-03-10.
>   + 47_rel3.6.16_05-_gnutls_buffer_resize-account-for-unused-area-if-
> AGG.patch
>   + 47_rel3.6.16_06-str-suppress-Wunused-function-if-
> AGGRESSIVE_REALLOC-.patch
> 

Please go ahead.

Regards,

Adam

Bug#988455: buster-pu: package velocity/1.7-5+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-05-13 at 11:16 +0100, Chris Lamb wrote:
> Please consider velocity (1.7-5+deb10u1) for buster:
>   
>   velocity (1.7-5+deb10u1) buster; urgency=medium
>   .
> * CVE-2020-13936: Prevent a potential arbitrary code execution
> vulnerability
>   that can be exploited by applications that allow untrusted
> users to
>   upload/modify Velocity templates. (Closes: #985220)
> 

Please go ahead.

Regards,

Adam

Bug#988454: buster-pu: package ruby-websocket-extensions/0.1.2-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-05-13 at 11:25 +0100, Chris Lamb wrote:
> Please consider ruby-websocket-extensions (0.1.2-1+deb10u1) for
> buster:
>   
>   ruby-websocket-extensions (0.1.2-1+deb10u1) buster; urgency=medium
>   .
> * CVE-2020-7663: Prevent a denial of service attack that is
> exploitable
>   by an exponential-time regular expression backtracking
> vulnerability.
>   (Closes: #964274)
> 

Please go ahead.

Regards,

Adam

Bug#987548: buster-pu: package node-redis/2.8.0-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-04-30 at 08:09 +0200, Salvatore Bonaccorso wrote:
> Hi
> 
> [Disclaimer, not part of the release team]
> 
> On Sun, Apr 25, 2021 at 02:13:47PM +0200, Yadd wrote:
> > [ Reason ]
> > rode-redis is vulnerable ro ReDoS (CVE-2021-29469
[...]
> > @@ -1,3 +1,9 @@
> > +node-redis (2.8.0-1+deb10u1) unstable; urgency=medium
> 
> Target distribution should be buster here.

Indeed.

With that change, please go ahead.

Regards,

Adam

Bug#988466: RFS: aspell-sl/0.60-5 -- Slovenian dictionary for GNU Aspell

[Tomaž Šolc]

Hi Paul,

On 15. 05. 21 03:53, Paul Wise wrote:
> The Homepage is 404, but the site it was on still works. Have you
> tried contacting the person (Tomaž Erjavec) listed at the bottom of
> the page (there is an email)?

thank you for your suggestions. I will reach out again to the Slovenian
community and try to figure out what to do with this package.

I took over this package from the previous maintainer in 2016. Back then
we had a discussion about the upstream and as far as I remember the
conclusion was that there was none at that time. Already in 2016 the
aspell-sl home page only existed in archive.org.
> If all of the above suggestions don't help, I would encourage you to
> create a new upstream project for aspell-sl, release a new version and
> then contact all the distro maintainers to update to your new release.

I am happy to continue to maintain the Debian package. I think it has
value and I'm an occassional user. However I don't want to be the
upstream for it.

Best regards
Tomaž

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,


While this bug is now in fixed status with the recent upload of open-
iscsi version 2.1.3-4, there's still some other issue about the udeb
being reported on the tracker package.

In particular, it metions:
open-iscsi-udeb/armel has unsatisfiable dependency

I see now difference in the generated deb's dependency list. Is it
something you are aware of, in general, about d-i's status on armel ?
Or are there still bugs from the installer's point of view, where I
need to step in ?



rrs@priyasi:.../Chrome-Downloads$ dpkg -I open-iscsi-udeb_2.1.3-
4_armel.udeb 
 new Debian package, version 2.0.
 size 212060 bytes: control archive=572 bytes.
 592 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-4
 Architecture: armel
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 1185
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.
19:33 ♒ ॐ ♅ ♄ ⛢ ☺ 
rrs@priyasi:.../Chrome-Downloads$ dpkg -I open-iscsi-udeb_2.1.3-
4_armhf.udeb 
 new Debian package, version 2.0.
 size 218124 bytes: control archive=572 bytes.
 591 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-4
 Architecture: armhf
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 933
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.
19:33 ♒ ॐ ♅ ♄ ⛢ ☺ 


On Sat, 2021-05-01 at 04:32 +0200, Cyril Brulebois wrote:
> Hi,
> 
> Ritesh Raj Sarraf  (2021-04-30):
> > The upload I prepped failed on some of the architectures.
> > https://buildd.debian.org/status/logs.php?pkg=open-iscsi=2.1.3-3
> 
> It's lacking a push to the Git repository (git fetch didn't get
> anything
> new from a few days ago).
> 
> > In d/control, there is:
> > 
> > ```
> > Package: open-iscsi-udeb
> > # Note: the (virtual) udeb package scsi-modules (provided by
> > different
> > #   linux kernel udebs) must exist for these architectures - so
> > #   check that before adding them to this list; the other
> > #   scsi-(core|common|...)-modules are NOT sufficient!
> > Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
> > ppc64el s390x
> > Section: debian-installer
> > Package-Type: udeb
> > ```
> > 
> > 
> > The udeb package was introduced by Colin Watson from Ubuntu. I
> > extended
> > the architecture list, based on the supported architectures by d-i.
> > But
> > I really don't use or test this functionality of the package.
> > 
> > 
> > How would you like to see this fixed Cyril ?
> > 
> > The easiest option, if d-i supports, would be to extend architecture
> > list to: `linux-any`, keeping it in line with what the actual open-
> > iscsi package supports.
> 
> Yes, I think that would be a good idea, so that you don't have to keep
> the list in sync between debian/control and debian/rules. We don't have
> many examples of packages maintained by the d-i team that use it, but
> at least src:haveged and src:systemd have similar udebs (after all,
> that
> only matters at build-time, d-i only sees the results of the build).
> 
> Regarding your conditional, you could check whether you're building for
> linux (once you switch to linux-any) or you could check whether the
> udeb
> is being built: dh_listpackages (-a) can be use to determine that.
> 
> 
> Cheers,

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#988554: xterm does not render U+A7BA ... U+A7F6

[Uwe Waldmann]

Package: xterm
Version: 344-1+deb10u1
Severity: important

Dear Maintainer,

xterm renders all characters between U+A7BA and U+A7F6 with width zero,
that is, not at all, even if they are present in the chosen font.
For instance,

  printf '<\uA7B9>\n'

displays "" with a slash through "u" (correct), whereas

  printf '<\uA7BA>\n'

displays "<>" (incorrect) instead of "" with an apostrophe before
"A". The problem shows up with arbitrary fonts (both pcf and otb are
affected). Using -mk_width does not change the situation.

(In Debian 9.1, it still worked correctly.)

Expected behavior:

Characters between U+A7BA and U+A7F6 should be rendered properly
if present in the given font(s), or replaced by a default character
otherwise.

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

Kernel: Linux 5.4.104.1.pm64-smp (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=en_US 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xterm depends on:
ii  libc6   2.28-10
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20181013-2+deb10u2
ii  libutempter01.1.6-3
ii  libx11-62:1.6.7-1+deb10u1
ii  libxaw7 2:1.0.13-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#988540: im-config: breaks the keyboard configuration

[Gunnar Hjalmarsson]

On 2021-05-15 14:27, Vincent Lefevre wrote:

im-config can be disabled if you don't need it. To do that
you can use the "Input Method Configuration" GUI and select "none".
The command line equivalent is:

im-config -n none


Thanks, that works. But the default should not modify the user's
settings.


Well, the purpose of im-config is to launch and configure an input 
method framework if present, and having it do so by default is 
considered important.



But reportbug still gives LC_ALL=C


I see. Possibly we should add a "unset LC_ALL" to /usr/share/bug/im-config.

But as regards your actual locale configuration, I'm still not convinced 
that it's sensible, since LANG is unset.



What's the contents of your /etc/default/locale file?


#  File generated by update-locale
#LANG="en_US.UTF-8"
LANGUAGE="en_US:en"


Can you please replace

#LANG="en_US.UTF-8"

with

LANG="C.UTF-8"

and then re-enable im-config:

im-config -n REMOVE

and reboot.

Does ibus/im-config still mess up your keyboard configuration?


BTW, reportbug still gives an empty "setxkbmap -print", but the output
is actually sent to the terminal instead of being redirected to the
file... Obviously, there is a missing ">&3" for this line in
"/usr/share/bug/im-config":

[...]
 if [ -x /usr/bin/setxkbmap ]; then
 echo "=== setxkbmap -print ===" >&3
 /usr/bin/setxkbmap -print
 echo >&3
 fi
[...]


Yes, that's indeed a typo. Thanks for mentioning it.

Bug#987731: buster-pu: package openvpn/2.4.7-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-04-28 at 20:15 +0200, Bernhard Schmidt wrote:
> I would like to update openvpn in Buster fixing two no-dsa CVEs and
> one
> performance issue.
> 
> CVE-2020-11810: No Debian Bug#, fixed upstream in 2.4.9
> CVE-2020-15078: Bug#987380, cherry-picked for sid/bullseye in 2.5.1-2
> 
> TCP performance issue: Bug#968942, fixed upsteam in 2.4.8
> 

Please go ahead.

Regards,

Adam

Bug#864807: b53_mdio module doesn't get loaded automatically on Lamobo R1

[Heinrich Schuchardt]

On 5/15/21 3:15 PM, Salvatore Bonaccorso wrote:

Hi,

Is this bug still an issue with recent kernels or can the issue be
closed?

Regards,
Salvatore


I am not using this board anymore.

Best regards

Heinrich

Bug#948674: Processed: RFP: otter-browser -- Fast and configurable web browser inspired by Opera 12

[Ritesh Raj Sarraf]

Hello Chris,

On Fri, 2021-05-14 at 19:34 +0200, Chris Hofstaedtler wrote:
> * Ritesh Raj Sarraf  [210514 17:33]:
> > Is there some explanation on this change ? Or is it some broken
> > script
> > that is run ?
> 
> > > > noowner 948674
> > > Bug #948674 [wnpp] RFP: otter-browser -- Fast and configurable
> > > web
> > > browser inspired by Opera 12
> 
> The bug is still titled "RFP:". I *guess* RFPs usually should not
> have owners. Maybe you want to actually retitle to ITP: and again
> set the owner.
> 
Yes. Possibly that may be the reason. I did retitle the bug report, but
to an "ITA: " than an "ITP: "


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#867776: linux-image-4.9.0-3-amd64: spurious ACPI lid open event on wakeup

[Salvatore Bonaccorso]

Hi Ian,

On Sun, Jul 09, 2017 at 07:58:40PM +0100, Ian Jackson wrote:
> Ben Hutchings writes ("Re: Bug#867776: linux-image-4.9.0-3-amd64: spurious 
> ACPI lid open event on wakeup"):
> > Control: tag -1 upstream
> ...
> > The change can be reverted with a module parameter:
> > 
> > options button lid_init_state=method
> 
> You are a fount of knowledge!  I will try this and report back.

Did you got a chance to test this? Did it work back then?

If so can we close this bugreport?

Regards,
Salvatore

Bug#988547: apt: Apt seems to keep back galera-3 without reason

[David Kalnischkies]

On Sat, May 15, 2021 at 01:27:43PM +0200, Olaf van der Spek wrote:
> Upgrading galera-3 appears to be possible without troubles according to  the 
> second invocation, so shouldn't the first invocation just do that upgrade?

Not necessarily. "upgrade" will e.g. not upgrade a package if that
breaks a previously satisfied recommends or a new recommends can not
be installed – but it does install the new version if you force it
as you do in the second command.

Might also be a case of "A and B can not be done together, so I am not
doing either due to implementation reasons".

galera-3 does not seem to have recommends, but it wasn't updated for
6 months either and you haven't told us the versions involved, so
perhaps that's from a different repository…


Adding:
-o Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgDepCache::Marker=1 -o 
Debug::pkgProblemResolver=1
Would probably shine some light on what happens why.

You could also attach your /var/lib/dpkg/status file to the bugreport.
The README has details on both which you might want to consult.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#988499: systemd: New sgx group looks overly generic and prone to collision

[Michael Biebl]

Am 15.05.21 um 00:26 schrieb Michael Biebl:

Am 14.05.2021 um 12:45 schrieb Guillem Jover:

Ok, that was fast, upstream already closed this as wontfix… :(


So, the only reasonable option I see is to revert this change. That 
said, it will be a patch we'd have to keep (and maintain) for all 
eternity. Not sure if it's worth the effort, tbh.


Chris suggested this on IRC:


zeha
mbiebl: re sgx: revert the patch for a while until someone shows up with a real 
usecase, or upstream reconsiders?
mbiebl
zeha: good idea!
zeha
i know its a bit "kicking the can down the road", but if the fear is "removing 
system groups is hard" (i agree), avoid it until the maintenance cost of not doing it has 
become too annoying?
(also: not having it in debian might yield alternate, possibly better, 
solutions)



So this is probably what I'm going to do:
- Revert the upstream change for the time being (in Debian/Ubuntu)
- If no one shows up within the bookworm release cycle asking for this 
group, re-evaluate. Maybe try to poke upstream again.
- If someone shows up asking for this, I'd just add it (with the 
upstream chosen name).


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988553: coils FTCBFS -- multiple reasons

[Nilesh Patra]

Source: coils
Version: 2002-8
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

Coils FTBFS due to two reasons:

* It has a B-D on perl due to which it has cross-satisfiablity
  issues. Whilst this B-D can simply be dropped due to being a
  transitive dep of debhelper, it can instead be simply
  annotated with :any as a failsafe

* It uses build arch compilar as make default, simplest way of fixing 
which
  is using dpkg's buildtools.mk

The respective fixes for the above have been committed to salsa here[1]
and here[2]
It should be ready to upload, and *should* be uploaded after bullseye
release. I'm filing this bug report so these changes do not get lost
somehow.


[1]:https://salsa.debian.org/med-team/coils/-/commit/0c21e9759609ef257bae884cd65db8fed3ba6c66
[2]:https://salsa.debian.org/med-team/coils/-/commit/a3746328fb758f979d306ddc48ad12d6b93c0a3d

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Bug#988537: ansible: ships broken sylink in /usr/bin/ansible-connection

[Lee Garrett]

Hi Florian,

please update to the current version of ansible, where this bug is
fixed. This is a duplicate of #970422.

Regards,
Lee

On 15/05/2021 11:06, Florian Lohoff wrote:
> Package: ansible
> Version: 2.9.16+dfsg-1.1
> Severity: important
> 
> 
> Hi,
> this ansible version ships with a broken symlink in
> /usr/bin/ansible-connection pointing to:
> 
> flo@p5:/usr/bin$ ls -la ansible-connection
> lrwxrwxrwx 1 root root 57 Jan  6 11:56 ansible-connection -> 
> ../lib/ansible/cli/scripts/ansible_connection_cli_stub.py
> 
> which does not exist. This connection for example
> routeros targets fails with:
> 
> task path: /home/flo/projects/customer/routeros/playbook.yml:2
> fatal: [ros1]: FAILED! => {
> "msg": "Unable to find location of 'ansible-connection'. Please set or 
> check the value of ANSIBLE_CONNECTION_PATH"
> }
> 
> 
> I fixed it with:
> 
> flo@p5:/usr/bin$ sudo rm ansible-connection 
> flo@p5:/usr/bin$ sudo ln -s 
> ../lib/python3/dist-packages/ansible/cli/scripts/ansible_connection_cli_stub.py
>  ansible-connection
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-6-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 ansible depends on:
> ii  openssh-client1:8.4p1-5
> ii  python3   3.9.2-3
> ii  python3-cryptography  3.3.2-1
> ii  python3-distutils 3.9.2-1
> ii  python3-dnspython 2.0.0-1
> ii  python3-httplib2  0.18.1-3
> ii  python3-jinja22.11.3-1
> ii  python3-netaddr   0.7.19-5
> ii  python3-paramiko  2.7.2-1
> ii  python3-yaml  5.3.1-3+b1
> 
> Versions of packages ansible recommends:
> ii  python3-argcomplete  1.8.1-1.5
> ii  python3-jmespath 0.10.0-1
> ii  python3-kerberos 1.1.14-3.1+b3
> ii  python3-libcloud 3.2.0-2
> ii  python3-selinux  3.1-3
> ii  python3-winrm0.3.0-2
> ii  python3-xmltodict0.12.0-2
> 
> Versions of packages ansible suggests:
> pn  cowsay   
> pn  sshpass  
> 
> -- no debconf information
> 

Bug#864807: b53_mdio module doesn't get loaded automatically on Lamobo R1

[Salvatore Bonaccorso]

Hi,

Is this bug still an issue with recent kernels or can the issue be
closed?

Regards,
Salvatore

Bug#988301: exim :include: not working after jessie

[Andreas Metzler]

Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=2751

On 2021-05-10 Josip Rodin  wrote:
> Package: exim4
> Version: 4.89-2+deb9u8

> Hi,

> After an upgrade to stretch, and likewise buster, the :include:
> functionality of the redirect router seems to be broken.

> I have include_directory set to /etc/exim4, and a subdirectory with
> files containing alias content, an an aliases file containing e.g.:

> priprema: :include:/etc/exim4/dynaliases/priprema

> This worked perfectly up to jessie, but after the upgrade, deliveries
> started choking with messages like:
[...]

Hello Josip,

I have reproduced the issue on sid and have forwarded it upstream. The
breakage seems to be with the include_directory setting, dropping lets
the :include: work.

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

Bug#987658: unblock: openjdk-11-jre-dcevm/11.0.11+9-1

[Emmanuel Bourg]

On 15/05/2021 07:51, Paul Gevers wrote:

> Are commits f8bc235 and 10263b1 the head of the OpenJDK archive?

Yes, but these commits refer to the AdoptOpenJDK Git mirror [1] of the
upstream Mercurial repository [2]. src:openjdk-11 pulls directly from
Mercurial but the source tree is identical.


> Does OpenJDK in Debian carry any patches you want to have too?

Yes, DCEVM picks a patch from openjdk-11 to support multi arch libraries
[3]. The other patches are not relevant to DCEVM.


> I start to realize that src:openjdk-11 is probably more than the source
> of src:openjdk-11-jre-dcevm, as I *assume* that the source of the latter
> is only a *subset* of the source of the former. What would we need to do
> to compare those sources? Can you indeed confirm that the delta between
> both sources is exactly the patch set?

The source is the same, but DCEVM builds only the HotSpot VM, not the
Java standard library nor the developer tools. DCEVM just swaps the JVM
at runtime, everything else is provided by openjdk-11, that's why the
two packages are tightly coupled.

I can confirm that the delta between both sources is exactly the patch set.


> Those ranges are all off-by-one. The first commit should be the one you
> want to compare against, not the first one you want to have in the diff.

You are right sorry, I meant the commit ranges as inclusive but that's
not how "git diff" works. The 10 new commits actually change +222/-17
lines [4].

Emmanuel Bourg


[1] https://github.com/AdoptOpenJDK/openjdk-jdk11u/commits/10263b1
[2]
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/shortlog/jdk-11.0.11-ga
[3]
https://salsa.debian.org/java-team/openjdk-11-jre-dcevm/-/blob/master/debian/patches/hotspot-libpath.diff
[4]
https://github.com/HotswapProjects/openjdk-jdk11u-dcevm/compare/7e0e338^..28b9ff6

Bug#988540: im-config: breaks the keyboard configuration

[Vincent Lefevre]

Hi Gunnar,

On 2021-05-15 13:11:04 +0200, Gunnar Hjalmarsson wrote:
> I see one thing which looks suspicious: You have set the LC_ALL environment
> variable to C. LC_ALL is not supposed to be set permanently. Ever.
> Especially not to C, which disables UTF-8 encoding.

Well, I don't have that in my settings, though there may still be
some old scripts around that does this, but only inside the script,
of course.

> What's the contents of your /etc/default/locale file?

#  File generated by update-locale
#LANG="en_US.UTF-8"
LANGUAGE="en_US:en"

And in my shell:

zira:~> locale
LANG=POSIX
LANGUAGE=
LC_CTYPE=C.UTF-8
LC_NUMERIC="POSIX"
LC_TIME=en_DK.utf8
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

And if I run "/usr/share/bug/im-config 3> /dev/stdout" manually,
I get:

[...]
=== locale output ===
LANG=POSIX
LANGUAGE=
LC_CTYPE=C.UTF-8
LC_NUMERIC="POSIX"
LC_TIME=en_DK.utf8
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
[...]

But reportbug still gives LC_ALL=C.

> With that said, im-config can be disabled if you don't need it. To do that
> you can use the "Input Method Configuration" GUI and select "none". The
> command line equivalent is:
> 
> im-config -n none

Thanks, that works. But the default should not modify the user's
settings.

BTW, reportbug still gives an empty "setxkbmap -print", but the output
is actually sent to the terminal instead of being redirected to the
file... Obviously, there is a missing ">&3" for this line in
"/usr/share/bug/im-config":

[...]
if [ -x /usr/bin/setxkbmap ]; then
echo "=== setxkbmap -print ===" >&3
/usr/bin/setxkbmap -print
echo >&3
fi
[...]

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

Bug#988398: unblock: aprx/2.9.0+dfsg-3

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-05-12 00:28:26, Dave Hibberd wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package aprx
> 
> [ Reason ]
> This is a fix for bug #987332, which impacts a web service the daemon
> connects to. Our package installs, enables and starts by default with a 
> useless config, connecting to their server and doing nothing else.
> 
> [ Impact ]
> The grave bug outstanding #987332 for the package will remain standing,
> the remote service shall continue to see dead connections.
> 
> [ Tests ]
> This package has been manually tested to ensure new behaviour is as
> expected (package exits cleanly on start), and importantly doesn't
> cause an update to fail. No autopkgtests have been included as I've not
> yet read enough to feel competent at implementing them.
> 
> [ Risks ]
> This is quite a niche package with 73 Debian users on popcon. Currently, the
> default config is causing issue for the service provider it connects to,
> and it will continue to if left. The only change to the package is made
> to the default configs, commenting out one of the connection details.
> 
> [ Checklist ]
>   [X] all changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in testing
> 
> [ Other info ] 
> Complicating the issue is my relative inexperience with freeze - bundled
> into this upload is a Debian janitor bump from dh11->12 that's been on
> salsa for a while - I included this in the upload, and it is detailed in
> d/changelog, however I didn't want to bring standards or dh any further
> up to date than janitor did a year back.

debhelper compat changes are not approprtiate for this phase of the
freeze. Please revert that change but make sure that the fix for RC bug
still works as intended.

Cheers

> 
> unblock aprx/2.9.0+dfsg-3
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing'), (10, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> thx
> -- 
>   Hibby
>   MM0RFN

> diff -Nru aprx-2.9.0+dfsg/debian/changelog aprx-2.9.0+dfsg/debian/changelog
> --- aprx-2.9.0+dfsg/debian/changelog  2018-09-27 04:20:51.0 +0100
> +++ aprx-2.9.0+dfsg/debian/changelog  2021-05-09 23:15:56.0 +0100
> @@ -1,3 +1,19 @@
> +aprx (2.9.0+dfsg-3) unstable; urgency=medium
> +  [ Dave Hibberd ]
> +  * Add debian/gitlab-ci.yml
> +  * Change installinit behaviour in debian/rules
> +- aprx is now disabled by default upon install
> +- Belt & Braces interrupting installsystemd too
> +  * Added patch to modify default config commenting out default callsign
> +- Closes: #987332
> +  [ Debian Janitor]
> +  * Use secure URI in debian/watch.
> +  * Use secure URI in Homepage field.
> +  * Bump debhelper from old 11 to 12.
> +  * Update renamed lintian tag names in lintian overrides.
> +
> + -- Dave Hibberd   Sun, 09 May 2021 23:15:56 +0100
> +
>  aprx (2.9.0+dfsg-2) unstable; urgency=medium
>  
>* debian/aprx.init
> diff -Nru aprx-2.9.0+dfsg/debian/compat aprx-2.9.0+dfsg/debian/compat
> --- aprx-2.9.0+dfsg/debian/compat 2018-09-27 04:20:51.0 +0100
> +++ aprx-2.9.0+dfsg/debian/compat 1970-01-01 01:00:00.0 +0100
> @@ -1 +0,0 @@
> -11
> diff -Nru aprx-2.9.0+dfsg/debian/control aprx-2.9.0+dfsg/debian/control
> --- aprx-2.9.0+dfsg/debian/control2018-09-27 04:20:51.0 +0100
> +++ aprx-2.9.0+dfsg/debian/control2020-04-20 18:22:23.0 +0100
> @@ -3,9 +3,9 @@
>  Priority: optional
>  Maintainer: Debian Hamradio Maintainers 
>  Uploaders: Chris Knadle , Colin Tuckley  
> , Dave Hibberd 
> -Build-Depends: debhelper (>= 11)
> +Build-Depends: debhelper-compat (= 12)
>  Standards-Version: 4.2.1
> -Homepage: http://thelifeofkenneth.com/aprx/
> +Homepage: https://thelifeofkenneth.com/aprx/
>  Vcs-Browser: https://salsa.debian.org/debian-hamradio-team/aprx
>  Vcs-Git: https://salsa.debian.org/debian-hamradio-team/aprx.git
>  
> diff -Nru aprx-2.9.0+dfsg/debian/gitlab-ci.yml 
> aprx-2.9.0+dfsg/debian/gitlab-ci.yml
> --- aprx-2.9.0+dfsg/debian/gitlab-ci.yml  1970-01-01 01:00:00.0 
> +0100
> +++ aprx-2.9.0+dfsg/debian/gitlab-ci.yml  2021-05-09 22:09:08.0 
> +0100
> @@ -0,0 +1,6 @@
> +include:
> +  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
> +  - 
> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
> +
> +reprotest:
> +  extends: .test-reprotest-diffoscope
> diff -Nru 

Bug#988552: unblock: freefem++/3.61.1+dfsg1-6

[François Mazen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package freefem++

[ Reason ]
Fix the FTBFS RC bug #957233 (fail to build with GCC-10)

[ Impact ]
The package is usable again.

[ Tests ]
Manual tests.

[ Risks ]
No other package depends on freefem++, so impact and risk are low.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
The package is very active upstream.

I've attached the debdiff against the package in stable because the one
in testing has been removed due to the RC bug #957233.

unblock freefem++/3.61.1+dfsg1-6

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/16 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
diff -Nru freefem++-3.61.1+dfsg1/debian/changelog freefem++-3.61.1+dfsg1/debian/changelog
--- freefem++-3.61.1+dfsg1/debian/changelog	2019-01-06 22:28:01.0 +0100
+++ freefem++-3.61.1+dfsg1/debian/changelog	2021-05-13 14:06:33.0 +0200
@@ -1,3 +1,27 @@
+freefem++ (3.61.1+dfsg1-6) unstable; urgency=high
+
+  * Team upload.
+  * Fix FTBFS with GCC-10 (Closes: #957233)
+
+ -- Francois Mazen   Thu, 13 May 2021 14:06:33 +0200
+
+freefem++ (3.61.1+dfsg1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with gsl 2.6 (Closes: #960010)
+
+ -- Stefano Rivera   Sun, 17 May 2020 13:41:04 -0700
+
+freefem++ (3.61.1+dfsg1-5) unstable; urgency=medium
+
+  * Team upload.
+  * Build-Depends non-versioned libpetsc-real-dev and libpetsc-complex-dev
+Closes: #939663
+  * debhelper-compat 12
+  * Rework manual changes in source tree to quilt patches
+
+ -- Andreas Tille   Sat, 05 Oct 2019 09:21:24 +0200
+
 freefem++ (3.61.1+dfsg1-4) unstable; urgency=medium
 
   * Enforce BD to libpetsc-(real,complex)3.10-dev (Closes: #917977)
diff -Nru freefem++-3.61.1+dfsg1/debian/compat freefem++-3.61.1+dfsg1/debian/compat
--- freefem++-3.61.1+dfsg1/debian/compat	2018-08-05 12:33:22.0 +0200
+++ freefem++-3.61.1+dfsg1/debian/compat	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-11
diff -Nru freefem++-3.61.1+dfsg1/debian/control freefem++-3.61.1+dfsg1/debian/control
--- freefem++-3.61.1+dfsg1/debian/control	2019-01-06 22:23:45.0 +0100
+++ freefem++-3.61.1+dfsg1/debian/control	2021-05-13 14:06:33.0 +0200
@@ -4,7 +4,7 @@
Dimitrios Eftaxiopoulos 
 Section: science
 Priority: optional
-Build-Depends: debhelper (>= 11~),
+Build-Depends: debhelper-compat (= 12),
libsuperlu-dev,
gawk,
gfortran,
@@ -42,15 +42,15 @@
coinor-libipopt-dev,
libgmm++-dev,
libtet1.5-dev,
-   libpetsc-real3.10-dev,
-   libpetsc-complex3.10-dev
+   libpetsc-real-dev,
+   libpetsc-complex-dev
 # libmmg3dlib4.0-4.0-dev, freeyams, mshmet, mshint,
 # libparms2-dev, libitsol-dev,
 # libhips-dev, libpastix-dev,
 # libsuperlu-dist-dev
-Standards-Version: 4.3.0.1
-Vcs-Git: https://salsa.debian.org/science-team/freefempp.git
+Standards-Version: 4.4.1
 Vcs-Browser: https://salsa.debian.org/science-team/freefempp
+Vcs-Git: https://salsa.debian.org/science-team/freefempp.git
 Homepage: http://www.freefem.org/ff++/
 
 Package: freefem++
diff -Nru freefem++-3.61.1+dfsg1/debian/.gitlab-ci.yml freefem++-3.61.1+dfsg1/debian/.gitlab-ci.yml
--- freefem++-3.61.1+dfsg1/debian/.gitlab-ci.yml	1970-01-01 01:00:00.0 +0100
+++ freefem++-3.61.1+dfsg1/debian/.gitlab-ci.yml	2021-05-13 14:06:33.0 +0200
@@ -0,0 +1,2 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
diff -Nru freefem++-3.61.1+dfsg1/debian/patches/double-cblas-import.patch freefem++-3.61.1+dfsg1/debian/patches/double-cblas-import.patch
--- freefem++-3.61.1+dfsg1/debian/patches/double-cblas-import.patch	1970-01-01 01:00:00.0 +0100
+++ freefem++-3.61.1+dfsg1/debian/patches/double-cblas-import.patch	2021-05-13 14:06:33.0 +0200
@@ -0,0 +1,25 @@
+Description: Avoid FTBFS with gsl 2.6 by including 2 incompatible cblas headers
+Bug-Debian: https://bugs.debian.org/960010
+Author: Frederic Hecht 
+Origin: upstream, https://github.com/FreeFem/FreeFem-sources/commit/3bfe3eb669c580583e9290474614b45cee52a96c
+
+--- a/src/femlib/MatriceCreuse_tpl.hpp
 b/src/femlib/MatriceCreuse_tpl.hpp
+@@ -12,7 +12,7 @@
+ // test blas 
+ //  on MacOS9 under MWERKS
+ //  cblas_ddot macos-9 is not 
+-#ifdef HAVE_CBLAS_H
++#ifdef HAVE_CBLAS_H_BUG
+ extern "C" {
+ #define FF_VERSION VERSION
+ #undef VERSION
+@@ -21,7 +21,7 @@
+ #define VERSION VERSION

Bug#988551: libsundials-dev: broken symlinks: /usr/lib//libsundials_{,f}sunnonlinsol{newton,fixedpoint}.so

[Andreas Beckmann]

Package: libsundials-dev
Version: 4.1.0+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m41.3s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/libsundials_sunnonlinsolnewton.so -> 
libsundials_sunnonlinsolnewton.so.1 (libsundials-dev)
  /usr/lib/x86_64-linux-gnu/libsundials_sunnonlinsolfixedpoint.so -> 
libsundials_sunnonlinsolfixedpoint.so.1 (libsundials-dev)
  /usr/lib/x86_64-linux-gnu/libsundials_fsunnonlinsolnewton.so -> 
libsundials_fsunnonlinsolnewton.so.1 (libsundials-dev)
  /usr/lib/x86_64-linux-gnu/libsundials_fsunnonlinsolfixedpoint.so -> 
libsundials_fsunnonlinsolfixedpoint.so.1 (libsundials-dev)


cheers,

Andreas


libsundials-dev_4.1.0+dfsg-3.log.gz
Description: application/gzip

Bug#988550: r-cran-ggvis: broken symlink: /usr/lib/R/site-library/ggvis/www/lib/lodash/lodash.min.js -> ../../../../../../../share/javascript/lodash.min.js

[Andreas Beckmann]

Package: r-cran-ggvis
Version: 0.4.7+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

3m18.0s ERROR: FAIL: Broken symlinks:
  /usr/lib/R/site-library/ggvis/www/lib/lodash/lodash.min.js -> 
../../../../../../../share/javascript/lodash.min.js (r-cran-ggvis)

The target file is now at

/usr/share/javascript/lodash/lodash.min.js
 

cheers,

Andreas


r-cran-ggvis_0.4.7+dfsg-1.log.gz
Description: application/gzip

Bug#988549: lxqt: dmesg tail given before a reboot due to graphics subsystem freez

[o1bigtenor]

Subject: lxqt: dmesg tail given before a reboot due to graphics subsystem freeze
Package: lxqt
X-Debbugs-Cc: o1bigte...@gmail.com
Version: 30
Severity: critical
Justification: breaks unrelated software
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?

   Nothing specific was done, found graphics subsystem locked and
before running reboot from a second system on my network ran dmesg

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

   Didn't do anything and a reboot cleared the issue, likely
temporarily but the issue was cleared
   filed a bug report at lxqt

   * What was the outcome of this action?

upstream dev indicated that it wasn't their problem - - - rather
it was debian's problem

Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxqt depends on:
ii  featherpad0.12.1-1
ii  i3-wm [x-window-manager]  4.19.1-1
ii  lightdm [x-display-manager]   1.26.0-7
ii  lxdm [x-display-manager]  0.5.3-4
ii  lximage-qt0.14.1-1+b1
ii  lxqt-about0.14.1-1+b1
ii  lxqt-admin0.14.1-1+b1
ii  lxqt-branding-debian [lxqt-branding]  0.14.0.3
ii  lxqt-core 30
ii  lxqt-openssh-askpass  0.14.1-1
ii  lxqt-powermanagement  0.14.1-1+b1
ii  lxqt-sudo 0.14.1-2+b1
ii  openbox [x-window-manager]3.6.1-9+deb11u1
ii  pavucontrol   4.0-2
ii  qlipper   1:5.1.2-1+b1
ii  qps   2.0.0-1+b1
ii  qterminal 0.14.1-1+b1
ii  qttranslations5-l10n  5.15.2-2
ii  sddm [x-display-manager]  0.18.1-1
ii  sddm-theme-debian-maui [sddm-theme]   0.18.1-1
pn  screengrab 
ii  smplayer   20.6.0~ds0-1
ii  smtube 18.3.0-1+b1
ii  vivaldi-stable [www-browser]   3.8.2259.40-1

Versions of packages lxqt suggests:
ii  calibre5.3.0+dfsg-1
pn  compton-conf   
pn  juffed 
pn  nomacs 
pn  obconf-qt  
pn  qt5-style-kvantum  
pn  qtpass 
pn  shutter
pn  vokoscreen 

-- no debconf information


dpkg -l | less | grep lxqt*

ii  liblxqt-globalkeys-ui0:amd640.14.3-1+b1
 amd64daemon used to register global keyboard
shortcut
ii  liblxqt-globalkeys0:amd64   0.14.3-1+b1
 amd64daemon used to register global keyboard
shortcut
ii  liblxqt-l10n0.16.0-1
 all  Language package for liblxqt
ii  lxqt-policykit  0.14.1-1+b1
 amd64LXQt authentication agent for PolicyKit
ii  lxqt-policykit-l10n 0.16.0-1
 all  Language package for lxqt-policykit
ii  lxqt-powermanagement0.14.1-1+b1
 amd64power management module for LXQt
ii  lxqt-powermanagement-l10n   0.16.0-1
 all  Language package for lxqt-powermanagement
ii  lxqt-qtplugin:amd64 0.14.0-3+b2
 amd64LXQt system integration plugin for Qt
ii  lxqt-runner 0.14.1-1+b1
 amd64LXQt program launcher
ii  lxqt-runner-l10n0.16.0-1
 all  Language package for lxqt-runner
ii  lxqt-session0.14.1-2+b1
 amd64session manager component for LXQt
ii  lxqt-session-l10n   0.16.0-1
 all  Language package for lxqt-session
ii  lxqt-sudo   0.14.1-2+b1
 amd64Graphical QT frontend for plain sudo
ii  lxqt-sudo-l10n  0.16.0-1
 all  Language package for lxqt-sudo
ii  lxqt-system-theme   0.16.0-1
 all  System theme for LXQt
ii  lxqt-theme-debian   0.14.0.3
 all  Debian theme for LXQt
ii  lxqt-themes 0.16.0-1
 all  Themes for LXQt

dmesg  tail showing issue

[Tue May 11 07:41:22 2021] traps: lxqt-globalkeys[1872] general
protection fault ip:7efd223044a6 sp:7ffc014175e0 error:0 in
libc-2.31.so[7efd222e
[Tue May 11 07:41:24 2021] pcmanfm-qt[1871]: segfault at 30 ip
7f038e86e925 sp 7fff7ee3c700 error 4 in
libQt5Core.so.5.14.2[7f038e65c000+
[Tue May 11 

Bug#845658: linux: Bad(?) USB device crashes USB system

[Paul Menzel]

Dear Ritesh,


Am 11.12.16 um 19:23 schrieb Ritesh Raj Sarraf:


Were you able to find a solution to your problem ?
And curiously, were you able to verify the buggy behavior on a more recent
kernel ?


Sorry, for not replying and leaving the bug open. I wasn’t told about 
any occurrences afterward. I guess the behavior was fixed afterward.



Kind regards,

Paul

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

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Sun, Jan 05, 2020 at 04:12:37AM +0100, Marco d'Itri wrote:
> On Mar 15, Marco d'Itri  wrote:
> 
> > Package: src:linux
> > Version: 4.9.13-1
> > Severity: normal
> > 
> > Upgrading from 4.4.0-1 to 4.9.0-2 broke Kerberos security for NFS, at 
> > least as a server.
> FYI, 4.19.0-5-armmp is still broken.

Can you test by chance kernels from unstable or mainline? 

Back in 2017, were you able to test Ben's patch revert, and did that
solve the problem?

Regards,
Salvatore

Bug#988548: ITP: gap-singular -- A GAP interface to Singular

[Joachim Zobel]

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

* Package name: gap-singular
  Version : 2020.12.18
  Upstream Author : Marco Costantini, Willem Adriaan de Graaf

* URL : https://www.gap-system.org/Packages/singular.html
* License : GPL-2+
  Programming Lang: GAP 4
  Description : A GAP interface to Singular

The singular package provides an interface from GAP to the computer algebra
system Singular.

I am packaging this because it is suggested by gap-hap (see Bug#968545)
and needed for several examples.

Bug#976147: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Hi,

Another interesting observation. After upgrading galera-3 from buster
to bullseye first, apt will install 10.5..

# apt full-upgrade
The following packages will be REMOVED:
  libpython-stdlib mariadb-client-10.3 mariadb-client-core-10.3
mariadb-server mariadb-server-10.3 mariadb-server-core-10.3 python
python-minimal
The following packages will be upgraded:
  galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
python2 python2-minimal python2.7 python2.7-minimal
8 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

# apt install galera-3
The following packages will be upgraded:
  galera-3
1 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.

# apt full-upgrade
The following packages will be REMOVED:
  galera-3 libpython-stdlib mariadb-client-10.3
mariadb-client-core-10.3 mariadb-server-10.3 mariadb-server-core-10.3
python python-minimal
The following NEW packages will be installed:
  galera-4 mariadb-client-10.5 mariadb-client-core-10.5
mariadb-server-10.5 mariadb-server-core-10.5
The following packages will be upgraded:
  libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
mariadb-server python2 python2-minimal python2.7 python2.7-minimal
8 upgraded, 5 newly installed, 8 to remove and 0 not upgraded.

Bug#847779: omap2-nand not auto-loaded on gta04

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Sun, Dec 11, 2016 at 05:34:06PM +0100, Josua Mayer wrote:
> Package: linux-image-4.9.0-rc8-armmp-unsigned: src:linux Version: 
> 4.9~rc8-1~exp1
> Message-ID: <148146021121.356.16709761149479929183.reportbug@localhost>
> X-Mailer: reportbug 6.6.6
> Date: Sun, 11 Dec 2016 12:43:31 +
> X-Debbugs-Cc: josua.maye...@gmail.com
> 
> Severity: normal
> 
> Dear Maintainer,
> 
> While doing some more tests on the GTA04 board I found that the nand flash
> works just fine *after* manually loading omap2-nand. The kernel should know
> to load that module on its own, why it doesn't is still to be found.

If you have still the device available, could you please check that
this is still the case? Otherwise we should close the bugreport
accordingly.

Regards,
Salvatore

Bug#988547: apt: Apt seems to keep back galera-3 without reason

[Olaf van der Spek]

Package: apt
Version: 2.2.3
Severity: minor
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

Upgrading galera-3 appears to be possible without troubles according to  the 
second invocation, so shouldn't the first invocation just do that upgrade?

# apt upgrade
The following packages have been kept back:
  galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib 
mariadb-server python2 python2-minimal python2.7 python2.7-minimal
0 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.

# apt upgrade galera-3
The following packages have been kept back:
  libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib mariadb-server 
python2 python2-minimal python2.7 python2.7-minimal
The following packages will be upgraded:
  galera-3
1 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
Need to get 882 kB of archives.
After this operation, 308 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

Greetings,

Olaf

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::LastInstalledKernel "5.10.0-6-amd64";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc 

Bug#988540: im-config: breaks the keyboard configuration

[Gunnar Hjalmarsson]

Severity: normal
Tags: moreinfo

Hi Vincent,

I see one thing which looks suspicious: You have set the LC_ALL 
environment variable to C. LC_ALL is not supposed to be set permanently. 
Ever. Especially not to C, which disables UTF-8 encoding.


What's the contents of your /etc/default/locale file?

With that said, im-config can be disabled if you don't need it. To do 
that you can use the "Input Method Configuration" GUI and select "none". 
The command line equivalent is:


im-config -n none

Rgds,
Gunnar Hjalmarsson

Bug#988546: iwyu.1, include-what-you-use.1: Missing sections in the manual page

[Alejandro Colomar]

Package: iwyu
Version: 8.15-2
Severity: minor
X-Debbugs-Cc: Alejandro Colomar (man-pages) 

Dear Maintainer,

The manual page for this package has some formatting errors,
and has everything in the DESCRIPTION section.

I found that the upstream manual page is correct, so it's a bug specific to
Debian.  Where is the Debian manual page coming from??

See 
.

Thanks,

Alex

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

Kernel: Linux 5.10.0-3-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 iwyu depends on:
ii  clang   1:11.0-51+nmu4
ii  clang-111:11.0.1-2
ii  libc6   2.31-12
ii  libclang-cpp11  1:11.0.1-2
ii  libllvm11   1:11.0.1-2
ii  libstdc++6  10.2.1-6
ii  python3 3.9.2-3

iwyu recommends no packages.

iwyu suggests no packages.

-- no debconf information

Bug#988545: unblock: nextcloud-desktop/3.1.1-2

[Sandro Knauß]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-owncloud-maintain...@lists.alioth.debian.org

Please unblock package nextcloud-desktop

[ Reason ]
#987274: Fix CVE-2021-22879

[ Tests ]
Installed it locally for several days, without issues.
Did not got any reponse that things are broken.

[ Risks ]
nextcloud-desktop is a leaf package, so no other package can break.
The diff is straight forward and small.

[ Checklist ]
  [ x ] all changes are documented in the d/changelog
  [ x ] I reviewed all changes and I approve them
  [ x ] attach debdiff against the package in testing

unblock nextcloud-desktop/3.1.1-2
diff -Nru nextcloud-desktop-3.1.1/debian/changelog 
nextcloud-desktop-3.1.1/debian/changelog
--- nextcloud-desktop-3.1.1/debian/changelog2021-01-19 14:56:40.0 
+0100
+++ nextcloud-desktop-3.1.1/debian/changelog2021-05-08 19:39:35.0 
+0200
@@ -1,3 +1,13 @@
+nextcloud-desktop (3.1.1-2) unstable; urgency=medium
+
+  * Add two upstream patches to fix CVE-2021-22879 (Closes: #987274):
+013f3cea70acfe7b701cb73c93744d5ff5c0c213
+e97b7d8a25d3ef0d8c52b6399f304a42a5d4f212
+into Validate-sensitive-URLs-to-onle-allow-http-s-schemes.patch
+with small modifications to apply to the version in Debian
+
+ -- Sandro Knauß   Sat, 08 May 2021 19:39:35 +0200
+
 nextcloud-desktop (3.1.1-1) unstable; urgency=medium
 
   [ Christian Göttsche ]
diff -Nru 
nextcloud-desktop-3.1.1/debian/patches/0006-Validate-sensitive-URLs-to-onle-allow-http-s-schemes.patch
 
nextcloud-desktop-3.1.1/debian/patches/0006-Validate-sensitive-URLs-to-onle-allow-http-s-schemes.patch
--- 
nextcloud-desktop-3.1.1/debian/patches/0006-Validate-sensitive-URLs-to-onle-allow-http-s-schemes.patch
  1970-01-01 01:00:00.0 +0100
+++ 
nextcloud-desktop-3.1.1/debian/patches/0006-Validate-sensitive-URLs-to-onle-allow-http-s-schemes.patch
  2021-05-08 19:39:35.0 +0200
@@ -0,0 +1,268 @@
+From 013f3cea70acfe7b701cb73c93744d5ff5c0c213 Fri Feb 5 10:06:25 2021
+From: allexzander 
+Date: Fri, 5 Feb 2021 10:06:25 +0200
+Subject: [PATCH] Validate sensitive URLs to onle allow http(s) schemes.
+
+Signed-off-by: allexzander 
+---
+ src/gui/accountsettings.cpp |  5 +++--
+ src/gui/creds/flow2auth.cpp |  3 ++-
+ src/gui/creds/oauth.cpp |  3 ++-
+ src/gui/guiutility.cpp  | 11 +++
+ src/gui/owncloudgui.cpp |  3 ++-
+ src/gui/socketapi.cpp   |  4 ++--
+ src/gui/tray/ActivityListModel.cpp  |  5 +++--
+ src/gui/tray/UserModel.cpp  | 10 ++
+ src/gui/wizard/owncloudwizardresultpage.cpp |  3 ++-
+ src/gui/wizard/webview.cpp  |  3 ++-
+ 10 files changed, 35 insertions(+), 15 deletions(-)
+
+--- a/src/gui/accountsettings.cpp
 b/src/gui/accountsettings.cpp
+@@ -36,6 +36,7 @@
+ #include "encryptfolderjob.h"
+ #include "syncresult.h"
+ #include "ignorelisttablewidget.h"
++#include "guiutility.h"
+ 
+ #include 
+ 
+@@ -705,8 +706,9 @@ void AccountSettings::slotForceSyncCurre
+ 
+ void AccountSettings::slotOpenOC()
+ {
+-if (_OCUrl.isValid())
+-QDesktopServices::openUrl(_OCUrl);
++if (_OCUrl.isValid()) {
++Utility::openBrowser(_OCUrl);
++}
+ }
+ 
+ void AccountSettings::slotUpdateQuota(qint64 total, qint64 used)
+--- a/src/gui/creds/flow2auth.cpp
 b/src/gui/creds/flow2auth.cpp
+@@ -25,6 +25,7 @@
+ #include "theme.h"
+ #include "networkjobs.h"
+ #include "configfile.h"
++#include "guiutility.h"
+ 
+ namespace OCC {
+ 
+@@ -146,7 +147,7 @@ void Flow2Auth::fetchNewToken(const Toke
+ {
+ case actionOpenBrowser:
+ // Try to open Browser
+-if (!QDesktopServices::openUrl(authorisationLink())) {
++if (!Utility::openBrowser(authorisationLink())) {
+ // We cannot open the browser, then we claim we don't support 
Flow2Auth.
+ // Our UI callee will ask the user to copy and open the link.
+ emit result(NotSupported);
+--- a/src/gui/creds/oauth.cpp
 b/src/gui/creds/oauth.cpp
+@@ -22,6 +22,7 @@
+ #include 
+ #include "theme.h"
+ #include "networkjobs.h"
++#include "guiutility.h"
+ 
+ namespace OCC {
+ 
+@@ -165,7 +166,7 @@ QUrl OAuth::authorisationLink() const
+ 
+ bool OAuth::openBrowser()
+ {
+-if (!QDesktopServices::openUrl(authorisationLink())) {
++if (!Utility::openBrowser(authorisationLink())) {
+ // We cannot open the browser, then we claim we don't support OAuth.
+ emit result(NotSupported, QString());
+ return false;
+--- a/src/gui/guiutility.cpp
 b/src/gui/guiutility.cpp
+@@ -27,6 +27,17 @@ Q_LOGGING_CATEGORY(lcUtility, "nextcloud
+ 
+ bool Utility::openBrowser(const QUrl , QWidget *errorWidgetParent)
+ {
++const QStringList allowedUrlSchemes = {
++"http",
++"https",
++"oauthtest"
++};
++

Bug#988544: RM: bbmail -- RoQA; dead upstream; unmaintained; very low popcon

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

bbmail has not seen a new upstream release since 2007, and upstream
seems to have stopped working on bbtools long long time ago.
Furthermore, bbmail was orphaned 5 years ago (see #832561), and at the
time of this writing has a popcon count of 14.

Hence, it looks to me it would be a better idea to simply remove bbmail
from Debian, as I'm sure alternatives to this exist and are more
maintained.

Please also close #832561 when RM'ing bbmail.

Thanks,
-- 
Pino

Bug#988543: autopostgresqlbackup: "Recommends: cron-daemon | anacron"

[Elrond]

Package: autopostgresqlbackup
Version: 1.1-1
Severity: wishlist


Hi,

The script in /etc/cron.daily expects a cron daemon.
Could you please "Recommends: cron-daemon | anacron"?

I would only use "Recommends" instead of "Depends", because
people might have other ways of integrating the script.



Thanks in advance

Elrond

Bug#988542: autopostgresqlbackup: Please use /var/backups

[Elrond]

Package: autopostgresqlbackup
Version: 1.1-1
Severity: wishlist


Hi,

Most backups on Debian go to /var/backups it seems.
Could you modify autopostgresqlbackup to also put its
backups there? Maybe /var/backups/autopostgresqlbackup?


Thanks in advance

Elrond