date:20211022

On 10/21/21 11:17 PM, Sebastian Ramacher wrote:
> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
>> Control: forwarded -1 
>> https://release.debian.org/transitions/html/auto-proj.html
>> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345
>>
>> For the Debian GIS team I'd like to transition to PROJ 8.
> 
> Please go ahead. Please also raise  the remaining FTBFS bugs to serious.

proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to
unstable. And the severity of the bugreports has been raised to serious.

Thanks for already scheduling the dependency level 2 NMUs, these are
almost done except for mips64el where they had to wait for proj to be
installed which it is now.

Kind Regards,

Bas

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

Bug#996994: [Pkg-utopia-maintainers] Bug#996994: pipewire-bin: Recent pipewire upgrade lacks WirePlumber

2021-10-22 Thread Gökalp Çelik

On Fri, 22 Oct 2021 09:55:33 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= <
dai...@debian.org> wrote:
> Hi,
>
> Le ven. 22 oct. 2021 à 08:54, Michael Biebl  a écrit :
> >
> > > pipewire 0.3.39 replaces pipewire-media-session with wireplumber and
recent upgrade removes media-session.
> > >
> >
> > Maybe pipewire-media-mession should be an empty transitional package,
> > depending on wireplumber and in bookworm+1 this empty transitional is
> > dropped?
> >
>
> I will upload today the new version of pipewire-media-session as an
> independent package that should fix this issue.
>
> And because the new pipewire-media-session has a build-dep on
> libpipewire-0.3-dev (>= 0.3.39), this transitional was a bit tricky.
> Sorry about that.
>
> Best,
> Dylan
>
>

On the gitlab page it says

PipeWire 0.3.39 (2021-10-21)

This is a bugfix release that is API and ABI compatible with previous 0.3.x
releases.
<#highlights>Highlights

   - media-session is now moved into a separate module to speed up its
   deprecation in favour of WirePlumber.

Maybe wireplumber could be offered as the default pipewire session manager?

Bug#997005: RM: gnome-shell-extension-remove-dropdown-arrows -- ROM; No longer needed/useful with gnome-shell version 41

2021-10-22 Thread Jonathan Carter

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: j...@debian.org

Please remove gnome-shell-extension-remove-dropdown-arrows

It is no longer needed/useful with the latest gnome-shell,
which is now in unstable.

thanks

Bug#997006: systemd-networkd: broken/regression in unprivileged LXD container in v247

2021-10-22 Thread Linus Lüssing

Package: systemd
Version: 247.3-6
Severity: normal
Tags: upstream
X-Debbugs-Cc: linus.luess...@c0d3.blue

Hi,

We found that using systemd-networkd in an unprivileged LXD container is
broken in systemd v247. A network or link file is not attached to an
interface and instead "networkctl -l status eth0" shows "n/a" for the
"Link File" and "Network File". Leading to the network interface not being
configured at all. systemd v246 and v248/v249 work fine, so it is a
regression specific to v247.

Bisect'ing shows that this commit introduced the bug for v247:

https://github.com/systemd/systemd/commit/88da55e28b467999da005591d3252a98f4436522

And the following commit fixed it again for v248:

https://github.com/systemd/systemd/commit/0e789e6d48046d43c50dd949a71ac56f1127bb96

Git cherry-picking 0e789e6d4 onto v247 fixes the issue (cherry-picking does
not apply cleanly but resolving this is straight forward).

Furthermore systemd-networkd does not work if the udev package is
missing (same symptoms, no link or network file gets attached to the
interface).


Suggestions to fix:

* Add a dependency to the systemd package for the udev package.
* Backport 0e789e6d4 to the systemd v247 package.

Alternatively (or additionally) systemd v249 could be added to
bullseye-backports, so people using Debian Bullseye could work around
the issue by installing systemd v249.

For more details see the following links:

https://discuss.linuxcontainers.org/t/systemd-networkd-not-working-in-debian-sid-or-bullseye-images/11503/17
https://github.com/systemd/systemd/pull/18559

Regards, Linus



-- Package-specific info:

-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.9.2-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-10
ii  libapparmor1 2.13.6-10
ii  libaudit11:3.0-2
ii  libblkid12.36.1-8
ii  libc62.31-13+deb11u2
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.18-4
ii  libcryptsetup12  2:2.3.5-1
ii  libgcrypt20  1.8.7-6
ii  libgnutls30  3.7.1-5
ii  libgpg-error01.38-2
ii  libip4tc21.8.7-1
ii  libkmod2 28-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.36.1-8
ii  libpam0g 1.4.0-9+deb11u1
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.3-6
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.36.1-8
ii  systemd-timesyncd [time-daemon]  247.3-6
ii  util-linux   2.36.1-8

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
pn  initramfs-tools  
ii  libnss-systemd   247.3-6
ii  libpam-systemd   247.3-6
pn  udev 

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]

/etc/systemd/logind.conf changed:
[Login]

/etc/systemd/resolved.conf changed:
[Resolve]


-- no debconf information

Bug#996977: kbd-chooser: can't chose keyboard variant keymap

2021-10-22 Thread Xavier Brochard


Hello Samuel

Le 21.10.2021 23:15, Samuel Thibault a écrit :

Hello,

Xavier Brochard, le jeu. 21 oct. 2021 21:09:26 +0200, a ecrit:
I allways use a keyboard variant. While installing Debian 11, the only 
keyboard layout

offered was the most common in my language (French Azerty).


Yes, we do not want to clutter the menu with various variant choices 
for

each and every language.


May be I don't remember, but I think it was possible to chose a variant 
on the ncurse UI in "advanced" mode (at the lower priority options).



but it breaks security during install as user is unable to type a good
password.


Why?


You can install in french with a different keyboard layout for whatever 
reasons : being in another country or using a variant layout like Dvorak 
or Bépo (my case). It is thus very hard to find characters different 
from numbers or french alphabet. Actually, it was difficult for me to 
type identical password 2 times, and then I was unable to type the same 
password at the login prompt. It happened on 2 or 3 installations until 
I decided to type only numbers in the password.


Xavier

Bug#997007: RM: gnome-shell-extension-no-annoyance -- ROM; No longer needed/useful for gnome-shell version 40+

2021-10-22 Thread Jonathan Carter

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: j...@debian.org

Please remove gnome-shell-extension-no-annoyance, it is no longer
needed/useful with gnome 40+ (gnome-shell 41 is now in unstable).

thanks

Bug#997008: llvm-toolchain-12: FTBFS on armel: undefined reference to `__atomic_load_8' in scudo

Source: llvm-toolchain-12
Version: 1:12.0.1-13
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-12&arch=armel&ver=1%3A12.0.1-13&stamp=1634838707&raw=0
> [326/735] : && /<>/build-llvm/./bin/clang++ 
> --target=arm-linux-gnueabi -fPIC -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC 
> -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
> -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type 
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
> -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections 
> -Wall -std=c++14 -Wno-unused-parameter -O3 -DNDEBUG  -Wl,-z,relro -Wl,-z,defs 
> -Wl,-z,nodelete   -nodefaultlibs -Wl,-z,text -nostdlib++ -Wl,--gc-sections 
> -Wl,-rpath-link,/<>/build-llvm/./lib -shared 
> -Wl,-soname,libclang_rt.scudo-arm.so -o 
> /<>/build-llvm/lib/clang/12.0.1/lib/linux/libclang_rt.scudo-arm.so
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_allocator.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_common.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_deadlock_detector1.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_deadlock_detector2.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_errno.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_file.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_flags.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_flag_parser.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_fuchsia.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_libc.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_libignore.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_linux.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_linux_s390.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_mac.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_netbsd.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_persistent_allocator.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_platform_limits_freebsd.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_platform_limits_linux.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_platform_limits_netbsd.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_platform_limits_posix.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_platform_limits_solaris.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_posix.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_printf.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_procmaps_common.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_procmaps_bsd.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_procmaps_fuchsia.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_procmaps_linux.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_procmaps_mac.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_procmaps_solaris.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_rtems.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_solaris.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.arm.dir/sanitizer_stoptheworld_fuchsia.cpp.o
>  
> compiler-rt/lib/sanitizer_common/CMa

Bug#997009: libpciaccess: FTBFS on hurd-i386

2021-10-22 Thread Svante Signell

Source: libpciaccess
Version: 0.16-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

Currently libpciaccess FTBFS on GNU/Hurd due to missing symbols in the
libpciaccess0.symbols file. The attached patch, 
debian_libpciaccess0.symbols.hurd-i386.diff, defines the symbols
specifically for Hurd.

Thanks!


--- /dev/null	2021-10-22 11:54:06.0 +0200
+++ b/debian/libpciaccess0.symbols.hurd-i386	2021-10-22 11:54:40.0 +0200
@@ -0,0 +1,73 @@
+libpciaccess.so.0 libpciaccess0 #MINVER#
+ pci_device_cfg_read@Base 0
+ pci_device_cfg_read_u16@Base 0
+ pci_device_cfg_read_u32@Base 0
+ pci_device_cfg_read_u8@Base 0
+ pci_device_cfg_write@Base 0
+ pci_device_cfg_write_bits@Base 0
+ pci_device_cfg_write_u16@Base 0
+ pci_device_cfg_write_u32@Base 0
+ pci_device_cfg_write_u8@Base 0
+ pci_device_close_io@Base 0.11.0
+ pci_device_enable@Base 0.10.2
+ pci_device_find_by_slot@Base 0
+ pci_device_get_agp_info@Base 0
+ pci_device_get_bridge_buses@Base 0
+ pci_device_get_bridge_info@Base 0
+ pci_device_get_device_name@Base 0
+ pci_device_get_parent_bridge@Base 0.11.0
+ pci_device_get_pcmcia_bridge_info@Base 0
+ pci_device_get_subdevice_name@Base 0
+ pci_device_get_subvendor_name@Base 0
+ pci_device_get_vendor_name@Base 0
+ pci_device_has_kernel_driver@Base 0.10.7
+ pci_device_is_boot_vga@Base 0.10.7
+ pci_device_map_legacy@Base 0.12.902
+ pci_device_map_memory_range@Base 0
+ pci_device_map_range@Base 0.8.0+git20071002
+ pci_device_map_region@Base 0
+ pci_device_next@Base 0
+ pci_device_open_io@Base 0.11.0
+ pci_device_probe@Base 0
+ pci_device_read_rom@Base 0
+ pci_device_unmap_legacy@Base 0.12.902
+ pci_device_unmap_memory_range@Base 0
+ pci_device_unmap_range@Base 0.8.0+git20071002
+ pci_device_unmap_region@Base 0
+ pci_device_vgaarb_decodes@Base 0.10.7
+ pci_device_vgaarb_fini@Base 0.10.7
+ pci_device_vgaarb_get_info@Base 0.10.7
+ pci_device_vgaarb_init@Base 0.10.7
+ pci_device_vgaarb_lock@Base 0.10.7
+ pci_device_vgaarb_set_target@Base 0.10.7
+ pci_device_vgaarb_trylock@Base 0.10.7
+ pci_device_vgaarb_unlock@Base 0.10.7
+ pci_device_x86_close_io@Base 0.16-1
+ pci_device_x86_map_legacy@Base 0.16-1
+ pci_device_x86_map_range@Base 0.16-1
+ pci_device_x86_open_legacy_io@Base 0.16-1
+ pci_device_x86_read16@Base 0.16-1
+ pci_device_x86_read32@Base 0.16-1
+ pci_device_x86_read8@Base 0.16-1
+ pci_device_x86_unmap_legacy@Base 0.16-1
+ pci_device_x86_unmap_range@Base 0.16-1
+ pci_device_x86_write16@Base 0.16-1
+ pci_device_x86_write32@Base 0.16-1
+ pci_device_x86_write8@Base 0.16-1
+ pci_get_strings@Base 0
+ pci_id_match_iterator_create@Base 0
+ pci_io_read16@Base 0.11.0
+ pci_io_read32@Base 0.11.0
+ pci_io_read8@Base 0.11.0
+ pci_io_write16@Base 0.11.0
+ pci_io_write32@Base 0.11.0
+ pci_io_write8@Base 0.11.0
+ pci_iterator_destroy@Base 0
+ pci_legacy_open_io@Base 0.11.0
+ pci_slot_match_iterator_create@Base 0
+ pci_system_cleanup@Base 0
+ pci_system_init@Base 0
+ pci_system_init_dev_mem@Base 0.10.2
+ pci_system_x86_destroy@Base 0.16-1
+ x86_disable_io@Base 0.16-1
+ x86_enable_io@Base 0.16-1

Bug#996802: llvm-toolchain-12: FTBFS on s390x since 1:12.0.1-10: Cannot find builtins library for the target architecture

Control: retitle -1 llvm-toolchain-12: FTBFS on s390x since 1:12.0.1-10: Cannot 
find builtins library for the target architecture
Control: found -1 1:12.0.1-13

On Thu, 21 Oct 2021 at 10:19:01 +0100, Simon McVittie wrote:
> 1:12.0.1-11 has a similar issue on armhf, presumably exposed by fixing
> #996828.

This appears to be fixed in 1:12.0.1-13 on armhf, but s390x still has
the same issue.

After llvm-toolchain-12 in unstable gets back to a state where all release
architectures are built successfully, I think it would be better to use
experimental to try different ways of building, and only upload to unstable
when all release architectures work - otherwise it's disruptive to packages
like Mesa (and, indirectly, many GUI programs).

smcv

Bug#997010: pius: -e option is broken

2021-10-22 Thread Łukasz Stelmach

Package: pius
Version: 3.0.0-2
Severity: important
Control: tags -1 fixed-upstream
X-Debbugs-Cc: none, Łukasz Stelmach 

Dear Maintainer,

Upstream issue report[1] follows:

--8<---cut here---start->8---
I tried

./pius -e -A -r ~/.gnupg/pubring.kbx -s 123456

Got

Traceback (most recent call last):
  File "/home/x/pius/./pius", line 365, in 
main()
  File "/home/x/pius/./pius", line 346, in main
if signer.sign_all_uids(key, retval):
  File "/home/x/pius/libpius/signer.py", line 741, in sign_all_uids
self.encrypt_signed_uid(key, uid["file"])
  File "/home/x/pius/libpius/signer.py", line 405, in encrypt_signed_uid
gpg.stdin.write("\n")
TypeError: a bytes-like object is required, not 'str'

Everything goes well without -e.
--8<---cut here---end--->8---

The issue has been fixed[2]

[1] https://github.com/jaymzh/pius/issues/138
[2] https://github.com/jaymzh/pius/pull/139

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU threads)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 pius depends on:
ii  gnupg2.2.27-2
ii  python3  3.9.2-3

pius recommends no packages.

pius suggests no packages.

-- no debconf information

-- 
Miłego dnia,
Łukasz Stelmach

Bug#989777: Re: Re: Bug#989777: Re: Severity: High / Debian 10 &amp;amp;amp;amp;amp;amp; 11 with Kernel 5.10.x-amd64 =&amp;amp;amp;amp;amp;gt; Intel AX210 Wifi &amp;amp;amp;amp

2021-10-22 Thread pham...@bluewin.ch

Good evening Vincent,

I am attaching 6 files to you with the commands you asked me to perform cold vs 
hot, hoping that this can help you to move things forward in the right 
direction.

On the Ubuntu side, version 21.04 with kernel 5.11 manages my Wifi / Bluetooth 
card perfectly, whether it is in "cold" or "hot" start-up. Wouldn't it be 
possible to integrate their work natively into Debian? It would be by far the 
easiest solution ... and they owe us that :)

Concerning the problem of the keyboard in Bluetooth, it must certainly come 
from a module missing in the dependencies of "Blueman" ... I have to see it 
more closely when I have a moment to devote to it.

Yes I am using a slightly customized version of Cinnamon as my desktop 
environment.

I saw that SID was in version 5.14.12-1: amd64 as soon as it goes into testing, 
I'll install it and get back to you. Hopefully this will solve my problem. What 
is the version of firmware-iwlwifi_xxx which is supplied with this kernel from 
SID ??

https://packages.debian.org/fr/linux-image-amd64

Have a nice weekend.

Philippe

PS : I can't answer you on your private messaging, your "Free.fr" provider must 
have a problem...



Message d'origine
De : vincent.deb...@free.fr
Date : 19/10/2021 - 17:59 (E)
À : pham...@bluewin.ch
Objet : Re: Re: Bug#989777: Re: Severity: High / Debian 10 
&amp;amp;amp;amp; 11 with Kernel 5.10.x-amd64 =&amp;amp;amp;gt; 
Intel AX210 Wifi &amp;amp;amp;amp; Bluetooth not work

Le 2021-10-15 13:24, pham...@bluewin.ch a écrit :
> Hello Vincent,

Hi Philippe,

I'm sending this privately since I don't think the pairing issue is due to a
kernel issue.

> Thank you for your message.
 
You are welcome.
 
> Regarding the Kernel 5.14.0-2amd64 and the operation of Bluetooth with the 
> firmware-iwlwifi_20210818-1_all.deb, I confirm that at each cold start (power 
> OFF => power ON) the Bluetooth still works, but that each warm start (reboot) 
> the Bluetooth refuses to work.
 
Good to know. This confirms what I read here and there. It also shows that some
work is required for this driver to meet the expected stability.
 
> The 'solaar' package is very cool, I did not know him. 
> 
> Unfortunately it does not allow me to pair my keyboard in Bluetooth ;-( See 
> attached screenshots.

My bad, I misunderstood that you absolutely wanted to use bluetooth to
connect your keyboard to your system. Solaar does not handle connecting
or disconnecting via Bluetooth, which is done using the usual Bluetooth
mechanisms.
 
> I have the exact same problem with my workstation running Debian 11 with 
> kernel 5.10.0-9-amd64. 
> 
> It looks like a package is missing which has the role of displaying a numeric 
> code on the screen, which must then be entered on the keyboard to complete 
> safely the pairing of the keyboards ;-(

What desktop environment are you using? From the screenshots sent previously,
it looks like Cinnamon‽

Can you please show the output of the following commands?:

$ bluetoothctl show
# systemctl status bluetooth.service (as root)
 
> Best regards et bon week-end.
> 
> 
> Philippe

Bonne soirée,
Vincent





systemctl status bluetooth.service - Démarrage à froid
Description: Binary data


journalctl -k | grep -Ei 'bluetooth|iwlwifi' - Démarrage à froid
Description: Binary data


bluetoothctl show - Démarrage à froid
Description: Binary data


systemctl status bluetooth.service - Démarrage à chaud
Description: Binary data


journalctl -k | grep -Ei 'bluetooth|iwlwifi' - Démarrage à chaud
Description: Binary data


bluetoothctl show - Démarrage à chaud
Description: Binary data

Bug#996074: extension compatibility with GNOME Shell 41

2021-10-22 Thread Christian Lauinger

On Sun, 17 Oct 2021 12:54:28 +0100 Simon McVittie 
wrote:
> Control: severity -1 serious
> 
> On Sun, 10 Oct 2021 at 21:33:02 +0100, Simon McVittie wrote:
> > The metadata.json for this extension doesn't declare compatibility
with
> > GNOME 41. I don't know whether the actual code will need changes or
not:
> > the conservative assumption is that it probably will (so please
test).
> 
> gnome-shell 41 is now in unstable, so incompatibilities with that
version
> are now RC. Please upload an updated extension if one is available.
> 
> smcv
> 
> 

I fixed it and created a pull request upstream:
https://gitlab.com/bertoldia/gnome-shell-trash-extension/-/merge_requests/23

-- 
Grüße / Regards

Christian


visit http://www.lauinger-clan.de


Realität ist, wenn Du's nicht mit der Maus wegklicken kannst.

Bug#997011: llvm-toolchain-13: FTBFS on mipsel: undefined reference to lldb_private::process_linux::NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux in lldb-server

Source: llvm-toolchain-13
Version: 1:13.0.0-7
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-13&arch=mipsel&ver=1%3A13.0.0-7&stamp=1634849868&raw=0
> [7723/7788] : && /<>/build-llvm/./bin/clang++ -fPIC 
> -Wno-unused-command-line-argument -Wno-unknown-warning-option -fPIC 
> -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
> -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
> -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type 
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override 
> -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color 
> -ffunction-sections -fdata-sections -Wno-deprecated-declarations 
> -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register 
> -Wno-vla-extension -O2 -DNDEBUG -g1 -latomic -fPIC 
> -Wno-unused-command-line-argument -Wno-unknown-warning-option -Wl,--build-id  
>   -Wl,-rpath-link,/<>/build-llvm/tools/clang/stage2-bins/./lib  
> -Wl,-O3 -Wl,--gc-sections 
> tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/Acceptor.cpp.o 
> tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-gdbserver.cpp.o 
> tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-platform.cpp.o 
> tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-server.cpp.o 
> tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/LLDBServerUtilities.cpp.o
>  
> tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/SystemInitializerLLGS.cpp.o
>  -o bin/lldb-server  -Wl,-rpath,"\$ORIGIN/../lib"  -lpthread  
> lib/liblldbBase.a  lib/liblldbHost.a  lib/liblldbInitialization.a  
> lib/liblldbPluginProcessLinux.a  lib/liblldbPluginObjectFileELF.a  
> lib/liblldbPluginInstructionARM.a  lib/liblldbPluginInstructionMIPS.a  
> lib/liblldbPluginInstructionMIPS64.a  lib/liblldbPluginProcessGDBRemote.a  
> lib/liblldbPluginPlatformMacOSX.a  lib/liblldbPluginPlatformPOSIX.a  
> lib/liblldbPluginProcessPOSIX.a  lib/liblldbCore.a  lib/liblldbSymbol.a  
> lib/liblldbTarget.a  lib/liblldbPluginProcessUtility.a  
> lib/liblldbInterpreter.a  lib/liblldbBreakpoint.a  
> lib/liblldbDataFormatters.a  lib/liblldbExpression.a  
> lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  
> lib/liblldbCommands.a  lib/liblldbPluginObjectFileJIT.a  
> lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  
> lib/liblldbPluginTypeSystemClang.a  lib/liblldbPluginAppleObjCRuntime.a  
> lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginSymbolFileDWARF.a  
> lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginObjCRuntime.a  
> lib/liblldbPluginRenderScriptRuntime.a  
> lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjectFilePDB.a  
> lib/liblldbCore.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  
> lib/liblldbPluginProcessUtility.a  lib/liblldbInterpreter.a  
> lib/liblldbBreakpoint.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a 
>  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  
> lib/liblldbCommands.a  lib/liblldbPluginObjectFileJIT.a  
> lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  
> lib/liblldbPluginTypeSystemClang.a  lib/liblldbPluginAppleObjCRuntime.a  
> lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginSymbolFileDWARF.a  
> lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginObjCRuntime.a  
> lib/liblldbPluginRenderScriptRuntime.a  
> lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjectFilePDB.a  
> lib/liblldbCore.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  
> lib/liblldbPluginProcessUtility.a  lib/liblldbInterpreter.a  
> lib/liblldbBreakpoint.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a 
>  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  
> lib/liblldbCommands.a  lib/liblldbPluginObjectFileJIT.a  
> lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  
> lib/liblldbPluginTypeSystemClang.a  lib/liblldbPluginAppleObjCRuntime.a  
> lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginSymbolFileDWARF.a  
> lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginObjCRuntime.a  
> lib/liblldbPluginRenderScriptRuntime.a  
> lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjectFilePDB.a  
> lib/liblldbCore.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  
> lib/liblldbPluginProcessUtility.a  lib/liblldbInterpreter.a  
> lib/liblldbBreakpoint.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a 
>  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  
> lib/liblldbCommands.a  lib/liblldbPluginObjectFileJIT.a  
> lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  
> lib/liblldbPluginTypeSystemClang.a  lib/liblldbPluginAppleObjCRuntime.a  
> lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginSymbolFileDWARF.a  
> lib/liblldbPluginSymbolFilePDB.

Bug#996947: llvm-toolchain-12: FTBFS on armel since 1:12.0.1-11: error: instruction requires: data-barriers

Control: tags -1 + moreinfo

On Thu, 21 Oct 2021 at 10:16:01 +0100, Simon McVittie wrote:
> https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-12&arch=armel&ver=1%3A12.0.1-11&stamp=1634667108&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-12&arch=armel&ver=1%3A12.0.1-12&stamp=1634719287&raw=0
> >/<>/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S:19:193: 
> >error: instruction requires: data-barriers

I think this particular root cause is fixed in 1:12.0.1-13, but it's
hard to tell until the other reasons for FTBFS on armel are all fixed.

smcv

Bug#996479: httpie: Version 2.6.0 available

2021-10-22 Thread Mickaël Schoentgen


Hey Bartosz,

Thanks for having a look.

They are all runtime dependencies.

- charset-normalizer is a new requirement since HTTPie 2.6.0, always 
needed as you saw it.


- defusedxml is needed when treating XML responses. The import error 
would be encountered only at that time.


- requests-toolbelt is always required, but the missing 
charset-normalizer error is simply shadowing its requirement.


Trice are build and runtime dependencies (I guess, I am not sure about 
the difference: without them, HTTPie will not work properly, or not work 
at all).


Regards,

On 10/22/21 9:45 AM, bart...@fenski.pl wrote:


So one more thing which is most probably blocker for now.

Does new httpie depend on python-charset-normalizer? I mean for runtime.

(fenio@debian) ➜ httpiehttp
Traceback (most recent call last):
 File "/usr/bin/http", line 33, in 
   sys.exit(load_entry_point('httpie==2.6.0', 'console_scripts', 
'http')())
 File "/usr/lib/python3/dist-packages/httpie/__main__.py", line 8, in 
main

   from httpie.core import main
 File "/usr/lib/python3/dist-packages/httpie/core.py", line 13, in 


   from .client import collect_messages
 File "/usr/lib/python3/dist-packages/httpie/client.py", line 15, in 


   from .encoding import UTF8
 File "/usr/lib/python3/dist-packages/httpie/encoding.py", line 3, in 


   from charset_normalizer import from_bytes
ModuleNotFoundError: No module named 'charset_normalizer'

If that's the case then this package is not yet available in Debian. 
It sits in NEW queue[1][2].


Also I was able to build package without python3-defusedxml, 
python3-socks and python3-requests-toolbelt.


Are these really build dependencies? Or maybe they are also runtime 
dependencies but I didn't hit issues with them since charset 
normalizer is being called prior to them?


regards
Bartosz Fenski


On 2021-10-14 16:50, Mickaël Schoentgen wrote:


Package: httpie
Severity: normal

Hello dear maintainers,

I've just released HTTPie 2.6.0, it brings interesting changes and bug fixes:

- Added support for formatting & coloring of JSON bodies preceded by non-JSON 
data (e.g., an XXSI prefix).
- Added charset auto-detection when Content-Type doesn't include it.
- Added --response-charset to allow overriding the response encoding for 
terminal display purposes.
- Added --response-mime to allow overriding the response mime type for coloring 
and formatting for the terminal.
- Added the ability to silence warnings through using -q or --quiet twice (e.g. 
-qq).
- Added installed plugin list to --debug output.
- Fixed duplicate keys preservation in JSON data.

I guess the bug report about upgrading HTTPie 2.5.0 should be closed then 
(#993937)?

Thanks in advance.

Note: I changed the severity from wishlist to normal as HTTPie is obsolete on 
every Debian-derived distributions (mostly because it is too on Debian itself).
   I kindly hope to improve the situation, maybe is there another way to 
make the process smoother, and painless, for everyone?
--
Mickaël Schoentgen
https://www.tiger-222.fr  


--
Mickaël SCHOENTGEN
https://www.tiger-222.fr

Bug#997006: systemd-networkd: broken/regression in unprivileged LXD container in v247

2021-10-22 Thread Michael Biebl

Control: tags -1 fixed-upstream patch
Control: fixed -1 248-1

Hello

Am 22.10.21 um 11:43 schrieb Linus Lüssing:

Package: systemd
Version: 247.3-6
Severity: normal
Tags: upstream
X-Debbugs-Cc: linus.luess...@c0d3.blue

Hi,

We found that using systemd-networkd in an unprivileged LXD container is
broken in systemd v247. A network or link file is not attached to an
interface and instead "networkctl -l status eth0" shows "n/a" for the
"Link File" and "Network File". Leading to the network interface not being
configured at all. systemd v246 and v248/v249 work fine, so it is a
regression specific to v247.

Bisect'ing shows that this commit introduced the bug for v247:

https://github.com/systemd/systemd/commit/88da55e28b467999da005591d3252a98f4436522

And the following commit fixed it again for v248:

https://github.com/systemd/systemd/commit/0e789e6d48046d43c50dd949a71ac56f1127bb96

Git cherry-picking 0e789e6d4 onto v247 fixes the issue (cherry-picking does
not apply cleanly but resolving this is straight forward).

Thanks for the detailed bug report and the effort of bisecting the issue.
Marking the bug report accordingly.

Furthermore systemd-networkd does not work if the udev package is
missing (same symptoms, no link or network file gets attached to the
interface).

Suggestions to fix:

* Add a dependency to the systemd package for the udev package.

I don't think we want that. We deliberately do not have a udev
dependency in systemd, as udev is not strictly needed in minimal containers.

* Backport 0e789e6d4 to the systemd v247 package.

The patch seems reasonable and small enough to qualify for a v247
backport and being fixed via a stable upload. I've marked it accordingly [1]

Alternatively (or additionally) systemd v249 could be added to
bullseye-backports, so people using Debian Bullseye could work around
the issue by installing systemd v249.

A backport of v249 (and later) for bullseye is planned in any case.

Regards,
Michael

[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=bullseye-backport;dist=bullseye

OpenPGP_signature
Description: OpenPGP digital signature

Bug#996994: [Pkg-utopia-maintainers] Bug#996994: Bug#996994: pipewire-bin: Recent pipewire upgrade lacks WirePlumber

2021-10-22 Thread Michael Biebl


Am 22.10.21 um 09:55 schrieb Dylan Aïssi:

Hi,

Le ven. 22 oct. 2021 à 08:54, Michael Biebl  a écrit :



pipewire 0.3.39 replaces pipewire-media-session with wireplumber and recent 
upgrade removes media-session.



Maybe pipewire-media-mession should be an empty transitional package,
depending on wireplumber and in bookworm+1 this empty transitional is
dropped?



I will upload today the new version of pipewire-media-session as an
independent package that should fix this issue.

And because the new pipewire-media-session has a build-dep on
libpipewire-0.3-dev (>= 0.3.39), this transitional was a bit tricky.


Now you have me confused.
If pipewire-media-session is going away soon anyway, being replaced by 
wireplumber, why introduce it as a new source package?
Is wireplumber not ready it or are there other reasons to keep 
pipewire-media-session installed?





OpenPGP_signature
Description: OpenPGP digital signature

Bug#996994: [Pkg-utopia-maintainers] Bug#996994: Bug#996994: pipewire-bin: Recent pipewire upgrade lacks WirePlumber

2021-10-22 Thread Dylan Aïssi

Le ven. 22 oct. 2021 à 12:27, Michael Biebl  a écrit :
>
> Now you have me confused.
> If pipewire-media-session is going away soon anyway, being replaced by
> wireplumber, why introduce it as a new source package?
> Is wireplumber not ready it or are there other reasons to keep
> pipewire-media-session installed?
>

To avoid complaints from people :) and because wireplumber is still
not able to build on some architectures.

Bug#996693: google-http-client-java: please upgrade to version 1.40.1

2021-10-22 Thread Markus Koschany

Hi, 

could you both comment on Debian bugs #996693 and #996696 please?

Regards,

Markus


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

Bug#997012: RFS: fonts-lxgw-wenkai/1.110-1 [ITP] -- Chinese font "LXGW WenKai"

2021-10-22 Thread 肖盛文


Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fonts-lxgw-wenkai":

* Package name : fonts-lxgw-wenkai
Version : 1.110-1
Upstream Author : lxgw 
* URL : https://github.com/lxgw/LxgwWenKai
* License : SIL-1.1
* Vcs : https://salsa.debian.org/fonts-team/fonts-lxgw-wenkai
Section : fonts

It builds those binary packages:

fonts-lxgw-wenkai - Chinese font "LXGW WenKai"

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


https://mentors.debian.net/package/fonts-lxgw-wenkai/

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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-lxgw-wenkai/fonts-lxgw-wenkai_1.110-1.dsc


Changes for the initial release:

fonts-lxgw-wenkai (1.110-1) unstable; urgency=medium
.
* Initial release. (Closes: #996989)

Regards,

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#980474: freecad: metapackage should depend on the right package versions

2021-10-22 Thread Tobias Frost

There is now a propsed patch on salsa:
https://salsa.debian.org/science-team/freecad/-/merge_requests/20

Tested as described above, now an apt install freecad will pull all required
packages. The constraints should be binNMU safe and should also allow
something like apt isntall freecad=xyz where e.g xyz is the version of testing
and sid would have e.g xyz+2. 

-- 
tobi

Bug#996977: kbd-chooser: can't chose keyboard variant keymap

2021-10-22 Thread Samuel Thibault

Holger Wansing, le ven. 22 oct. 2021 11:54:07 +0200, a ecrit:
> Am 22. Oktober 2021 10:24:43 MESZ schrieb Xavier Brochard 
> :
> >Le 21.10.2021 23:15, Samuel Thibault a écrit :
> >> Yes, we do not want to clutter the menu with various variant choices for
> >> each and every language.
> >
> >May be I don't remember, but I think it was possible to chose a variant on 
> >the ncurse UI in "advanced" mode (at the lower priority options).
> 
> As I wrote in another mail:
> this was possible until Debian 6 (2012).

Yes, but also Debian 6 didn't have as many languages. This was discussed
at the time, and when switching to console-setup. We cannot deal with
each user's preference, Debian already has a reputation of asking too
many questions that users don't know to answer.

There is an open requestion for the dvorak-like layouts, which could
make its way by letting users find it out in the list, then choose
which dvorak-like layout to use. That would probably be a reasonable
compromise. But I don't see how presenting each and every variant would
be good for our users.

Samuel

Bug#996977: kbd-chooser: can't chose keyboard variant keymap

2021-10-22 Thread Samuel Thibault

Xavier Brochard, le ven. 22 oct. 2021 10:24:43 +0200, a ecrit:
> You can install in french with a different keyboard layout for whatever
> reasons : being in another country

You will find that other country's layout in the list.

> or using a variant layout like Dvorak or Bépo (my case).

Ok, then this is "just" a duplicate of the old request I mentioned in my
other mail. This is "just" waiting for somebody to implement it.

Samuel

Bug#980889: RFP: binutils-sh-elf -- cross binary utilities for SuperH bare-metal systems

2021-10-22 Thread John Scott

On Fri, 2021-10-22 at 11:18 +0200, John Paul Adrian Glaubitz wrote:
> I had a look at the package and it throws a number of lintian errors. Are you
> planning to address these or are they common for all binutils-$ARCH-elf 
> packages
> we currently have in Debian?
I believe you're referring to debian-rules-missing-required-target and
debian-rules-missing-recommended-target. In this case, Lintian seems to
not recognize that I'm using Debhelper via the .DEFAULT target in the
Makefile. I've filed a Lintian bug for this (#983539).

If it's really bothersome, I could switch debian/rules from
.DEFAULT:
dh $@
to
%:
dh $@
but I personally prefer the former as a stylistic choice, and this
would cover up an area where Lintian should be smarter.

As for debian-rules-sets-DH_COMPAT, which is merely a warning, Lintian
has this to say:
> As of debhelper version 4, the DH_COMPAT environment variable is only
> to be used for temporarily overriding debian/compat. Any line in
> debian/rules that sets it globally should be deleted and a separate
> debian/compat file created if needed.
I don't set DH_COMPAT globally; I use it as a temporary override for
dh_auto_configure, and my source comments explain why I do this.

I would consider filing a Lintian bug, and still would if you'd like me
to, but frankly I'd like to keep the warning around as a reminder that
we should drop this hack when we're able.


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

Bug#997013: RM: gnome-mime-data -- RoQA; unmaintained, obsoleted by fd.o specifications (#947878)

Package: ftp.debian.org
Severity: normal

gnome-mime-data is the obsolete system of MIME-type associations that
was used by gnome-vfs, a GNOME 2 component that was deprecated in around
2009 and finally removed from Debian in 2019. Modern versions of GNOME
(and KDE, and anything else relevant this decade) use freedesktop.org
shared-mime-info instead.

I've just NMU'd chemical-mime-data to drop its build-dependency on
gnome-mime-data, which was the last thing preventing gnome-mime-data
from being removed. Please remove gnome-mime-data from unstable.

smcv

Bug#996270: false positive custom-library-search-path

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2021-10-21 at 18:03 -0700, Felix Lechner wrote:
> I believe we only disabled the use of /usr/lib/${installable_name} in
> favor of /usr/lib/${source_name}. (I think I was unable to find
> packages using that exemption.) Is your package affected by that
> change?
> 
> The commit [2] reduced the nesting depth and the complexity of the
> conditionals. It is therefore possible that the relevant portion of
> the check did not previously run for your package.

Actually I've double-checked and I previously had an override for binary-or-
shlib-defines-rpath which has been “replaced” by the new ones.

I've adjusted the overrides for now. I think it'd be nice to have a way to
express that there's a generic/accepted RPATH for a package (which might be
different than the source name), but for now the overrides works for that.

Thanks for the reply anyway.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFymqoACgkQ3rYcyPpX
RFvXJAgA6ru9l5QdgJ2poWiRUGSwvPqAXE4HXVpY4HUWIl2u1NXBkpWvIFjC+KSs
C3Mj8J4v2YHpnPJWIDzGOo5+Xtdxa1fbag8Yal6BlEfAUDsINvezMcR2kgpY72Ch
lgvYma2V0psnnFassvLigGynA2HtZKufFQS3L2HMNpIbZ4PJTpRJXDYXLNA9zja0
H3L7DLRptfIluXQ/q+hNlje3i9ccSteiVJdNsspEZ+98MbFIheWHjdddQEm8SxoD
AuXsCZnM789JRi1RUbAYsAryc//xxA4TTvLqxrA+DMP2/38XkAGSd1yr7wU7s/q2
6ZuuQ0QQahcVtG72ZFrlKmEI5twHZA==
=bVb6
-END PGP SIGNATURE-

Bug#996479: httpie: Version 2.6.0 available

2021-10-22 Thread bartosz

Hey, 

I'm working on this new release. Should be ready soon. 

No need to close bugreport for 2.5.0. Will be closed with my upload. 


regards
Bartosz Fenski

On 2021-10-14 16:50, Mickaël Schoentgen wrote:


Package: httpie
Severity: normal

Hello dear maintainers,

I've just released HTTPie 2.6.0, it brings interesting changes and bug fixes:

- Added support for formatting & coloring of JSON bodies preceded by non-JSON 
data (e.g., an XXSI prefix).
- Added charset auto-detection when Content-Type doesn't include it.
- Added --response-charset to allow overriding the response encoding for 
terminal display purposes.
- Added --response-mime to allow overriding the response mime type for coloring 
and formatting for the terminal.
- Added the ability to silence warnings through using -q or --quiet twice (e.g. 
-qq).
- Added installed plugin list to --debug output.
- Fixed duplicate keys preservation in JSON data.

I guess the bug report about upgrading HTTPie 2.5.0 should be closed then 
(#993937)?

Thanks in advance.

Note: I changed the severity from wishlist to normal as HTTPie is obsolete on 
every Debian-derived distributions (mostly because it is too on Debian itself).
I kindly hope to improve the situation, maybe is there another way to make the 
process smoother, and painless, for everyone?

--
Mickaël Schoentgen
https://www.tiger-222.fr

Bug#997014: desktop-profiles: /etc/csh/login.d/desktop-profiles.csh uses tempfile, which is deprecated

2021-10-22 Thread Alexandre DENIS

Package: desktop-profiles
Version: 1.4.30
Severity: normal

Dear Maintainer,

When connecting remotely to this computer, I get the following message:

tempfile: Command not found.
/usr/share/desktop-profiles/get_desktop-profiles_variables: line 22: : No such 
file or directory
sed: no input files
source: Too few arguments.

The first issue seems to come from
/etc/csh/login.d/desktop-profiles.csh calling `tempfile`, which has
been deprecated, and has now been remove from package debianutils.
I guess the other errors result from the first one.

My login shell is tcsh.

Thanks.


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

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

desktop-profiles depends on no packages.

desktop-profiles recommends no packages.

Versions of packages desktop-profiles suggests:
pn  gconf-editor
ii  hicolor-icon-theme  0.17-2
ii  menu-xdg0.6+nmu1
ii  shared-mime-info2.0-1

-- debconf information:
  desktop-profiles/replace-old-vars:

Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2021-10-22 at 02:13 +0800, Marc Gallet wrote:
> 
> Am I correct to assume this issue is still relevant for buster and that
> for now, I should simply defer the upgrade (marking the packages to be
> held back) and simply wait for this bug to be resolved?

Hi Marc,

as far as I can tell, yes the bug is still present. The fix attempt didn't
work for me, maybe because my database is already corrupted, or maybe because
it's actually not fixed at all.

I have yet to try to dump my database under 10.3.25 and import it under
10.3.31 to check if it fixes the issue.

Another possibility would be to rebuild with
e46f76c9749d7758765ba274a212cfc2dcf3eeb8 (which Ondrej identified as the first
bad commit) reverted.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFynPYACgkQ3rYcyPpX
RFvOoAgAwWYdiSdkN/Wau7jUf68hUVgcy6hIp1Wo5IbKIZcizs0KyEguOA6gjff2
Zv7VnTJ3Fv+y3i98FgV2f2rYbLkNw+PDmrdWjyYIzXIDS7jb05CZ1CwaAb0ni/qm
rkYKm2vQIPl9sajvgWhbXkVgMcFDP9E25tELjHb3SX3YhhoTKQliTD+JUbSEr5Pw
6N16Z9mUFHuNYhDw99OUKbWxhJpAPa/VYu5ZzqR5gfYjYUQrQ3VXWxlJKsfhCBv+
+a3+GFR2pHVGWB6JUPzWj0wdwq5D2zp04uP1ZLtL40PrqwpH2Wd8rWIHbTHMszVY
MjWAgfmlJnaU/eqIjtSqVVjDPIm+Jg==
=91rF
-END PGP SIGNATURE-

Bug#997015: valgrind: Please remove x32 from the architecture list

2021-10-22 Thread Adrian Bunk

Source: valgrind
Severity: normal
Tags: ftbfs

x32 is not supported upstream, and it has never built:
https://buildd.debian.org/status/logs.php?pkg=valgrind&arch=x32

Please remove x32 from the architecture list.

Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2021-10-14 at 19:38 +0200, Ondrej Zary wrote:
>     MDEV-15912: Remove traces of insert_undo
> 
>     Let us simply refuse an upgrade from earlier versions if the
>     upgrade procedure was not followed. This simplifies the purge,
>     commit, and rollback of transactions.
> 
>     Before upgrading to MariaDB 10.3 or later, a clean shutdown
>     of the server (with innodb_fast_shutdown=1 or 0) is necessary,
>     to ensure that any incomplete transactions are rolled back.
>     The undo log format was changed in MDEV-12288. There is only
>     one persistent undo log for each transaction.


Hi Ondrej,
it might be worth trying with that patch reverted, but I'm a bit confused at
the commit message. That seems to imply my server didn't have a clean shutdown
before upgrading to 10.3, which is possible but that upgrade is quite old by
now (afaict it's between Stretch and Buster), so I'm unsure what to do now.

innodb_fast_shutdown=0 doesn't terminate on 10.3.25, and I'm not sure if there
are other ways to ensure a “clean shutdown”.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFynjAACgkQ3rYcyPpX
RFtw9Qf/WcV91Ea5ltjqC4rzuNn877t0sjbdYx/4gESfevP+OY8lBboAckXQfejK
FAMZIrRtQ6vmLiTDpYEZgBEqVuyPICFJ2kuK6ejxzYT3zpUqoXMTi21fUd2pivKF
IVVHdMlFEgHfErGxN66Rv8m/OZUknfDAmkdAgKO0+WS+HuD/wuN7Y2zRCQBZ5PJg
8GJUZK+9O/7UdfHtxJvEja4U7B8G+bwQhKBNtgolOIrfapakB9b63KasJ18PVpQm
TpkL8XdolAG/cvqxp6UYjVdatOTmceH/tME0xzbnad/hNxzR4MZKjUlCrZ8T0zgW
WvXUZt1YsEivScpY15T32FELKPQeDQ==
=92/m
-END PGP SIGNATURE-

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

2021-10-22 Thread Christoph Biedl

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

Folks,

perhaps I should start with an outright confession: When doing
http-parser version 2.8.1-1+deb10u1 for a buster point release,
I messed up things horribly. Nobody noticed in time, it's in stable
now, and all I can do now is bringing things back in order.


# Problem

As described in #996939: The fix for CVE-2019-15605 changed, among
other things, the layout of "struct http_parser", by increasing the
size of the "flag" field and also its position¹ within the struct.

The latter ought not to do harm as the fields affected are marked as
private. But since that is not enforced in C, applications still might
access them.

The size change however is way worse, it caused the following elements,
especially "public" ones like "data" to change their offset.
Subsequently, applications built using the old header file will access
the wrong offset, and possibly segfault. This has been reported for the
tang package in #996460, and I have reason to assume *all* nine²
packages that use http-parser are affected.


# Solutions

After some discussion with Hilko Bengen (Cc:'ed) I can see two ways out
of this:

## Rebuild rdeps

In buster, re-build all packages that were built against http-parser.
So more or less a binNMU, but in a rather unusual area. Tightening the
install dependency to something like "libhttp-parser2.8 (>=
2.8.1-1+deb10u1~)" was nice to have.

Pros:
* If you have a process/automation for that, it should be little work
  and therefore the risk of mistakes rather low.

Cons:
* Several packages are affected.
* If this has to be done manually, co-ordination with package
  maintainers is needed, yada-yada.
* The ruby-http-parser.rb will FTBFS as mentioned in #989494. My old
  patch for unstable should apply. That would be my job.

## Rework the patch

Revert the ABI break by reworking the patch to restore the previous
struct layout - while maintaining the purpose of the change: Storing a
ninth status bit. Hilko Bengen did a great job implementing this, and
also reported success with several tests.

Pros:
* Only http-parser needs an upload.
* External applications (built using Debian but not shipped by Debian)
  continue to work. While this is not within our scope, it provides a
  good service.

Cons:
* Requires testing on all architectures supported in buster. My job.
* Applications that access private fields still might break. Highly
  unlikely to happen, and I have little mercy here.
* Applications and packages built *since* the ABI break will require
  a rebuild since technically this is a second ABI break. For Debian,
  the intersection with
  https://release.debian.org/proposed-updates/oldstable.html
  seems to be empty.

## Or ...

Still I am open for other ideas - my main goal is to find a sensible
fix for this issue.


Please advise how to proceed. I would like to see this handled as soon
as possible - knowing users out there encounter problems and will do so
until the next oldstable point release is not quite a pleasant
situation.

Personally I have a slight preference for the second ("rework the
patch") way, but that's not put in stone.

Kind regards,

Christoph

PS: Related, do you check autopkgtest of reverse dependencies as part
of a stable point release procedure? If not, please consider doing
so - although this time it would not have avoided the situation: Of
the list of packages, only libgit2 has an autopkgtest in buster,
and it still passes.

Related (not so) fun fact: Out of curiosity, I backported the
autopkgtest of the tang package locally, and it failed due to the
ABI breakage. Lesson learned: Do more autopkgtests!


¹ See

  
https://sources.debian.org/src/http-parser/2.8.1-1+deb10u1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch/#L223

  and line 228

² Affected packages should be:

  cargo
  jabberd2
  libgit2
  libgit-raw-perl
  ocserv
  python-httptools
  ruby-http-parser.rb
  sssd
  tang
  tcpflow



signature.asc
Description: PGP signature

Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator

2021-10-22 Thread Seunghun Han

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: swtpm
   Version : 0.7.0-rc2-1
   Upstream Author : Stefan Berger 
 * URL : https://github.com/stefanberger/swtpm
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/kkamagui-guest/swtpm
   Section : misc

It builds those binary packages:

  swtpm - Libtpms-based TPM emulator
  swtpm-dev - Include files for the TPM emulator's CUSE interface
  swtpm-libs - Common libraries for TPM emulators
  swtpm-tools - Tools for the TPM emulator

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/swtpm/swtpm_0.7.0-rc2-1.dsc

Changes for the initial release:

 swtpm (0.7.0-rc2-1) unstable; urgency=medium
 .
   * New maintainer (Closes: #941199)
   * Changed Standard-Version to 4.5.1 in debian/control
   * Updated debhelper version to 13 in debian/control
   * Added Rules-Requires-Root to debian/control
   * Added Vcs-Browser and Vcs-Git to debian/control
   * Converted debian/copyright to dep5-copyright format
   * Added debian/watch file
   * Fixed typos in source code and man pages

Regards,
-- 
  Seunghun Han

Bug#941199: Upstream has valid debian packaging

2021-10-22 Thread Seunghun Han

Hi all,

I'm so sorry for letting you wait. I have packaged and uploaded it to
mentors.debian.net [1]. I also have sent the RFS [2] to the mailing list. I
hope one of Debian developers supports it to get involved in sid.

Best regards,

Seunghun

[1]: https://mentors.debian.net/package/swtpm/
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997016

On Fri, Oct 22, 2021 at 2:57 AM Tom W  wrote:

> Is anyone looking into this? I sense increasing demand for swtpm +
> qemu for Win 11 VM.
>

Bug#996479: httpie: Version 2.6.0 available

2021-10-22 Thread bartosz

So one more thing which is most probably blocker for now. 


Does new httpie depend on python-charset-normalizer? I mean for runtime.


(fenio@debian) ➜  httpie http 
Traceback (most recent call last): 
File "/usr/bin/http", line 33, in  
  sys.exit(load_entry_point('httpie==2.6.0', 'console_scripts',
'http')()) 
File "/usr/lib/python3/dist-packages/httpie/__main__.py", line 8, in
main 
  from httpie.core import main 
File "/usr/lib/python3/dist-packages/httpie/core.py", line 13, in
 
  from .client import collect_messages 
File "/usr/lib/python3/dist-packages/httpie/client.py", line 15, in
 
  from .encoding import UTF8 
File "/usr/lib/python3/dist-packages/httpie/encoding.py", line 3, in
 
  from charset_normalizer import from_bytes 
ModuleNotFoundError: No module named 'charset_normalizer'


If that's the case then this package is not yet available in Debian. It
sits in NEW queue[1][2]. 


Also I was able to build package without python3-defusedxml,
python3-socks and python3-requests-toolbelt. 


Are these really build dependencies? Or maybe they are also runtime
dependencies but I didn't hit issues with them since charset normalizer
is being called prior to them? 


regards
Bartosz Fenski

On 2021-10-14 16:50, Mickaël Schoentgen wrote:


Package: httpie
Severity: normal

Hello dear maintainers,

I've just released HTTPie 2.6.0, it brings interesting changes and bug fixes:

- Added support for formatting & coloring of JSON bodies preceded by non-JSON 
data (e.g., an XXSI prefix).
- Added charset auto-detection when Content-Type doesn't include it.
- Added --response-charset to allow overriding the response encoding for 
terminal display purposes.
- Added --response-mime to allow overriding the response mime type for coloring 
and formatting for the terminal.
- Added the ability to silence warnings through using -q or --quiet twice (e.g. 
-qq).
- Added installed plugin list to --debug output.
- Fixed duplicate keys preservation in JSON data.

I guess the bug report about upgrading HTTPie 2.5.0 should be closed then 
(#993937)?

Thanks in advance.

Note: I changed the severity from wishlist to normal as HTTPie is obsolete on 
every Debian-derived distributions (mostly because it is too on Debian itself).
I kindly hope to improve the situation, maybe is there another way to make the 
process smoother, and painless, for everyone?

--
Mickaël Schoentgen
https://www.tiger-222.fr

Bug#984243: Help: mothur: ftbfs with GCC-11

2021-10-22 Thread Aaron M. Ucko

Andreas Tille  writes:

> OK, I've implemented this in my last commit.

Great, thanks!

> Isn't
>
> # Get the list of all .cpp files, rename to .o files
> #
> OBJECTS=$(patsubst %.cpp,%.o,$(wildcard $(addsuffix *.cpp,$(subdirs
> OBJECTS+=$(patsubst %.c,%.o,$(wildcard $(addsuffix *.c,$(subdirs
> OBJECTS+=$(patsubst %.cpp,%.o,$(wildcard *.cpp))
> OBJECTS+=$(patsubst %.c,%.o,$(wildcard *.c))
>
> the right way to get the path correctly?  Or what do you mean?

Please try changing the last two lines to

OBJECTS+=$(patsubst %.cpp,%.o,$(wildcard source/*.cpp))
OBJECTS+=$(patsubst %.c,%.o,$(wildcard source/*.c))

to match the relevant sources' actual location; sorry if that was unclear.
(The existing setup only covers subdirectories of source, missing that
directory's immediate contents.)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#993680: transition: proj

On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote:
> On 10/21/21 11:17 PM, Sebastian Ramacher wrote:
>> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
>>> Control: forwarded -1 
>>> https://release.debian.org/transitions/html/auto-proj.html
>>> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345
>>>
>>> For the Debian GIS team I'd like to transition to PROJ 8.
>>
>> Please go ahead. Please also raise  the remaining FTBFS bugs to serious.
> 
> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to
> unstable. And the severity of the bugreports has been raised to serious.
> 
> Thanks for already scheduling the dependency level 2 NMUs, these are
> almost done except for mips64el where they had to wait for proj to be
> installed which it is now.

libgeotiff & spatialite are built & installed on all release
architectures, dependency level 3 can be NMUed now.

The rebuild of octave-octproj is blocked by sundials not having been
rebuilt with the new petsc yet.

Kind Regards,

Bas

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

Bug#996981: multiqc: Link to jquery missing

2021-10-22 Thread Nilesh Patra


On Thu, 21 Oct 2021 22:59:23 +0200 Steffen Moeller  wrote:

Package: multiqc
Version: 1.11+dfsg-1
Severity: normal

Reminder to self:

distutils.errors.DistutilsFileError: can't copy 
'/usr/lib/python3/dist-packages/multiqc/templates/default/assets/js/packages/jquery-3.1.1.min.js':
 doesn't exist or not a regular file


Can you give more details?
How to reproduce the error?

Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#997014: Acknowledgement (desktop-profiles: /etc/csh/login.d/desktop-profiles.csh uses tempfile, which is deprecated)

2021-10-22 Thread Alexandre DENIS


I didn't notice the package had been removed from sid. Thus the bug is
non applicable.

We can close.

Tanks.


pgpWOlzpHYkZS.pgp
Description: OpenPGP digital signature

Bug#997017: RM: rust-capstone [armel armhf i386 mips64el mipsel ppc64el s390x] -- ROM; Only {amd,arm}64 for now

2021-10-22 Thread Michael R. Crusoe

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: cru...@debian.org

When we update to newer versions later I'll restore the other archs.

Bug#994443: [R-pkg-team] Bug#994443: marked as done (r-bioc-deseq2: autopkgtest regression)

2021-10-22 Thread Michael R. Crusoe


On Thu, 21 Oct 2021 15:15:52 +0200 Graham Inggs  wrote:
> Control: reopen -1
>
> r-bioc-deseq2's autopkgtests started to again pass in testing on
> 2021-09-29, once r-bioc-tximportdata migrated.
> However, the autopkgtests in stable continue to fail [1].

Correct, because the package r-bioc-tximportdata does not exist in stable.

--
Michael R. Crusoe

Bug#996730: Certain menus don't work right when chrome is in the Normal Layer

2021-10-22 Thread 積丹尼 Dan Jacobson

> "EB" == Eduard Bloch  writes:
EB> I have no idea what you mean and this is definitively not "grave". Tried

I was thinking because it caused other packages to not work properly...

EB> to reproduce with different settings and chromium 93.0.4577.82-1 and it
EB> just works.

EB> Maybe some issue with other software on your system which is
EB> manipulating properties?

Well I turned off picom and it didn't help.

EB> Maybe gijsbers finds something.

I don't know. I think he is saying this bug is not possible:
https://github.com/ice-wm/icewm/issues/62#issuecomment-933694736

Does it work if you downgrade icewm (and
EB> icewm-common) to the Testing version?

They are the same:
# apt-cache policy icewm icewm-common
icewm:
  Installed: 2.8.0-1
  Candidate: 2.8.0-1
  Version table:
 *** 2.8.0-1 990
990 http://opensource.nchc.org.tw/debian unstable/main amd64 Packages
500 http://opensource.nchc.org.tw/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
icewm-common:
  Installed: 2.8.0-1
  Candidate: 2.8.0-1
  Version table:
 *** 2.8.0-1 990
990 http://opensource.nchc.org.tw/debian unstable/main amd64 Packages
500 http://opensource.nchc.org.tw/debian testing/main amd64 Packages
100 /var/lib/dpkg/status

Should I go further back?

Bug#996204: transition: numerical library stack

2021-10-22 Thread Sebastian Ramacher

Hi Anton

On 2021-10-12 13:09:02, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-scie...@lists.debian.org, Anton Gladky 
> 
> I'd like to proceed with a transition of the numerical library stack.
> This involves
> 
> superlu   5.2.2+dfsg1 -> 5.3.0+dfsg1  (both libsuperlu5 so not really a 
> transition)
> superlu-dist  libsuperlu-dist6 -> libsuperlu-dist7
> hypre 2.18.2 -> 2.22.1 (internal within libhypre-dev)
> mumps libmumps-5.3 -> libmumps-5.4
> scotch6.1.0 -> 6.1.1 (both libscotch-6.1 so not a transition)
> petsc libpetsc-.*3.14 -> libpetsc-.*3.15
> slepc libslepc-.*3.14 -> libslepc-.*3.15
> (together with petsc4py, slepc4py)
> 
> Header packages libxtensor-dev, libxtensor-blas-dev will also be
> upgraded (xtl-dev 0.7.2 already got uploaded to unstable).
> 
> fenics-dolfinx will upgrade
>   libdolfinx-.*2019.2 -> libdolfinx-.*0.3
> (along with other fenics components). There is currently some problem
> with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf.
> I'll skip the demo_poisson_mpi tests for them if necessary.
> 
> sundials 5.7.0 is incompatible with hypre 2.22, Anton Gladky (cc:d) will
> upgrade to sundials 5.8.0.

I think we are ready for the sundials upload.

Cheers

> 
> openmpi/mpi4py/h5py have recently migrated to testing so shouldn't give
> any particular trouble (apart from the known 32-bit dolfinx problem)
> 
> auto transitions are already in place:
> 
> https://release.debian.org/transitions/html/auto-superlu-dist.html
> https://release.debian.org/transitions/html/auto-mumps.html
> https://release.debian.org/transitions/html/auto-petsc.html
> https://release.debian.org/transitions/html/auto-slepc.html
> 
> 
> Ben file:
> 
> title = "numerical library stack";
> is_affected = .depends ~ "libpetsc-.*3.14" | .depends ~ "libpetsc-.*3.15";
> is_good = .depends ~ "libpetsc-.*3.15";
> is_bad = .depends ~ "libpetsc-.*3.14";
> 

-- 
Sebastian Ramacher

Bug#996995: dh-python: Unable to parse debian/control

2021-10-22 Thread Christian Marillat

On 22 oct. 2021 09:24, "Chris Lamb"  wrote:

> tags 996995 + patch
> severity 996995 serious
> thanks
>
> Patch attached.

This patch fix this issue.

Christian

Bug#997018: RM: rust-elfx86exts [armhf i386 mips64el mipsel ppc64el s390x] -- ROM; Only {amd,arm}64 for now

2021-10-22 Thread Michael R. Crusoe

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: cru...@debian.org

Thanks!

Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31

2021-10-22 Thread Ondrej Zary

On Friday 22 October 2021, Yves-Alexis Perez wrote:
> On Thu, 2021-10-14 at 19:38 +0200, Ondrej Zary wrote:
> >     MDEV-15912: Remove traces of insert_undo
> >
> >     Let us simply refuse an upgrade from earlier versions if the
> >     upgrade procedure was not followed. This simplifies the purge,
> >     commit, and rollback of transactions.
> >
> >     Before upgrading to MariaDB 10.3 or later, a clean shutdown
> >     of the server (with innodb_fast_shutdown=1 or 0) is necessary,
> >     to ensure that any incomplete transactions are rolled back.
> >     The undo log format was changed in MDEV-12288. There is only
> >     one persistent undo log for each transaction.
> 
> 
> Hi Ondrej,
> it might be worth trying with that patch reverted, but I'm a bit confused at
> the commit message. That seems to imply my server didn't have a clean shutdown
> before upgrading to 10.3, which is possible but that upgrade is quite old by
> now (afaict it's between Stretch and Buster), so I'm unsure what to do now.
> 
> innodb_fast_shutdown=0 doesn't terminate on 10.3.25, and I'm not sure if there
> are other ways to ensure a “clean shutdown”.
> 
> Regards,

With 10.3.29 running, I've dumped all databases (mysqldump --all-databases -p 
>mysql.dump), then dropped all databases, stopped mariadb and deleted 
/var/lib/mysql/ib*.
Then restarted mariadb, restored databases (source mysql.dump) and finally 
upgraded to 10.3.31.

So my problem is solved. I've also found the patch that's causing the problem. 
I'm not going to waste any more time on this.

During many years of running mysql, upgrade just worked all the time. Looks 
like there are some quality problems with the developement process now.

-- 
Ondrej Zary

Bug#997003: php: CVE-2021-21703

2021-10-22 Thread Christian Göttsche

Source: php7.4
Version: 7.4.21-1+deb11u1
Severity: serious
Tags: security fixed-upstream

A privilege escalation vulnerability has been discovered in php
(CVE-2021-21703).
This has been fixed in upstream version 7.4.25.

Bug#923345: evince cannot start default browser due to AppArmor

2021-10-22 Thread Michael Deegan

Package: evince
Version: 3.38.2-1
Followup-For: Bug #923345

This bug still exists in bullseye, despite the partial fix in #954013.

   Oct 22 15:15:03 joyola kernel: [193012.379454] audit: type=1400 
audit(1634886903.112:32): apparmor="DENIED" operation="exec" 
profile="/usr/bin/evince" name="/usr/bin/xfce4-mime-helper" pid=1348354 
comm="exo-open" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

(Why yes, I *am* running XFCE here!)

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), 
(470, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (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 evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  evince-common3.38.2-1
ii  gsettings-desktop-schemas3.38.0-2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libevdocument3-4 3.38.2-1
ii  libevview3-3 3.38.2-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgnome-desktop-3-193.38.5-3
ii  libgtk-3-0   3.24.24-4
ii  libnautilus-extension1a  3.38.2-1+deb11u1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libsecret-1-00.20.4-2
ii  shared-mime-info 2.0-1

Versions of packages evince recommends:
ii  dbus-x11 [dbus-session-bus]  1.12.20-2

Versions of packages evince suggests:
ii  gvfs 1.46.2-1
pn  nautilus-sendto  
ii  poppler-data 0.4.10-1
ii  unrar1:6.0.3-1

-- no debconf information

-MD

-- 
-
Michael Deegan   Hugaholic  https://www.deegan.id.au/
  Jung, zr jbeel?  --

Bug#793549: cmake-data: Can't find fluid with FLTK 1.3.3

2021-10-22 Thread Timo Röhling


Hi Aaron,

On Fri, 24 Jul 2015 19:46:57 -0400 "Aaron M. Ucko"  wrote:

Prior to 1.3.3, this worked fine, because /usr/lib/fltk/FLTKConfig.cmake
defined FLTK_FLUID_EXECUTABLE, and to an absolute path at that.
However, 1.3.3 yields a very different setup: the definition appears
only in UseFLTK.cmake, which FLTKConfig.cmake doesn't include, just
points FLTK_USE_FILE to.  Moreover, the definition is simply "fluid",
with no path specified.

AFAICT upstream has modified their FLTKConfig.cmake to set
FLTK_FLUID_EXECUTABLE without UseFLTK.cmake; albeit still to "fluid"
without absolute path.

Is this sufficient for you to consider this bug done?

Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#997019: mailman3: Mailman itself seems to be refusing LMTP connections from Exim4

2021-10-22 Thread Colin Turner

Package: mailman3
Version: 3.3.3-1
Severity: normal

Dear Maintainer,

Thank you for all your work on the mailman3 package. I have just started to try 
to install this and migrating a mailman2 residual configuration.

I have been unable to get mailman to receive mail from Exim4. While exim4 is 
selecting the correct router and transport I am getting:

2021-10-21 22:29:38 1mdfd3-005vLS-T4 == rolep...@lists.piglets.com 
R=mailman3_router T=mailman3_transport defer (111): Connection refused

on all emails I am trying to send as tests to the lists.

- Exim Config -

My exim4 transport is as follows:

# /etc/exim4/conf.d/transport/55_mm3_transport
mailman3_transport:
  driver = smtp
  protocol = lmtp
  allow_localhost
  hosts = localhost
  port = MM3_LMTP_PORT
  rcpt_include_affixes = true

and the MM3_LMTP_PORT is defined here:

# /etc/exim4/conf.d/main/25_mm3_macros
# The colon-separated list of domains served by Mailman.
domainlist mm_domains=lists.piglets.com

MM3_LMTP_PORT=8024

# MM3_HOME must be set to mailman's var directory, wherever it is
# according to your installation.
MM3_HOME=/var/lib/mailman3
MM3_UID=list
MM3_GID=list


# The configuration below is boilerplate:
# you should not need to change it.

# The path to the list receipt (used as the required file when
# matching list addresses)
MM3_LISTCHK=MM3_HOME/lists/${local_part}.${domain}

- mta in mailman.cfg -

The [mta] stanza of my mailman.cfg files is as below

[mta]
# The class defining the interface to the incoming mail transport agent.
incoming: mailman.mta.exim4.LMTP
#incoming: mailman.mta.postfix.LMTP

# The callable implementing delivery to the outgoing mail transport agent.
# This must accept three arguments, the mailing list, the message, and the
# message metadata dictionary.
outgoing: mailman.mta.deliver.deliver

# How to connect to the outgoing MTA.  If smtp_user and smtp_pass is given,
# then Mailman will attempt to log into the MTA when making a new connection.
smtp_host: 127.0.0.1
smtp_port: 25
smtp_user:
smtp_pass:

# Where the LMTP server listens for connections.  Use 127.0.0.1 instead of
# localhost for Postfix integration, because Postfix only consults DNS
# (e.g. not /etc/hosts).
lmtp_host: localhost
lmtp_port: 8024

# Where can we find the mail server specific configuration file?  The path can
# be either a file system path or a Python import path.  If the value starts
# with python: then it is a Python import path, otherwise it is a file system
# path.  File system paths must be absolute since no guarantees are made about
# the current working directory.  Python paths should not include the trailing
# .cfg, which the file must end with.
configuration: python:mailman.config.exim4
#configuration: python:mailman.config.postfix

-

I have tried restarting all the relevant services. Telnet shows the runner to 
be listening

root@gondolin:~# telnet localhost 8024
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 gondolin.piglets.org GNU Mailman LMTP runner 2.0

But for some reason all email inbound is being rejected as connection refused. 
I have probably made an elementary error, but I'm not sure where if so, so 
apologies in advance.

Kind regards,

CT.

PS. I also ran into the issue #996560 of broken web links and fixed it with the 
same workaround

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

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

Versions of packages mailman3 depends on:
ii  dbconfig-sqlite3 2.0.20
ii  debconf [debconf-2.0]1.5.77
ii  init-system-helpers  1.60
ii  logrotate3.18.1-2
ii  lsb-base 11.1.0
ii  python3  3.9.2-3
ii  python3-aiosmtpd 1.4.2-1
ii  python3-alembic  1.7.1-3
ii  python3-authheaders  0.13.0-1
ii  python3-authres  1.2.0-2
ii  python3-click7.1.2-1
ii  python3-dateutil 2.8.1-6
ii  python3-dnspython2.0.0-1
ii  python3-falcon   3.0.1-2
ii  python3-flufl.bounce 3.0.1-1
ii  python3-flufl.i18n   3.0.1-1
ii  python3-flufl.lock   5.0.1-1
ii  python3-gunicorn 20.1.0-1
ii  python3-importlib-resources  5.1.2-1
ii  python3-lazr.config  2.2.3-1
ii  python3-passlib  1.7.4-1
ii  python3-psycopg2 2.8.6-2
ii  python3-public   0.5-1.1
ii  python3-pymysql  1.0.2-2
ii  python3-requests 2.25.1+dfsg-2
ii  python3-sqlalchemy   1.3.22+ds1-1
ii  python3-zope.component   4.3.0-3
ii  python3-zope.configuration   4.4.0-1

Bug#997020: RFP: fnott -- keyboard driven and lightweight Wayland notification daemon

2021-10-22 Thread Piotr Ożarowski

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+swa...@tracker.debian.org

* Package name: fnott
  Version : 1.1.2
  Upstream Author : Daniel Eklöf 
* URL : https://codeberg.org/dnkl/fnott
* License : MIT
  Programming Lang: C
  Description : keyboard driven and lightweight Wayland notification daemon

Fnott is a keyboard driven and lightweight notification daemon for
wlroots-based Wayland compositors. It implements (parts of) the Desktop
Notification Specification.

Supported features
• Summary
• Body
• Actions (requires a dmenu-like utility to display and let user select action)
• Urgency
• Icons
  - PNGs (using libpng)
  - SVGs (using bundled nanosvg)
• Markup
• Timeout


We already have mako-notifier in Debian but fnott better suits my needs.
F.e. it adjusts notification popup size as needed (instead of hardcoding
width/height of the popup)

Sway and related packages team added to X-Debbugs-Cc.

I can create an initial package and/or sponsor potential maintainer.


signature.asc
Description: PGP signature

Bug#997021: RFS: igtf-policy-bundle/1.113-1~bpo11+1 -- IGTF experimental Certificate Authorities

2021-10-22 Thread Dennis van Dok

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "igtf-policy-bundle".

The package is already in stable and buster-backerports. It is NEW
for bullseye backports and I would like to maintain updating it there.

The package has regular (~monthly) updates of the trust anchors which is why it 
makes
sense to also keep backporting it.


 * Package name: igtf-policy-bundle
   Version : 1.113-1~bpo11+1
   Upstream Author : IGTF 
 * URL : http://www.igtf.net/
 * License : CC-BY-3.0, MPL-1.1
 * Vcs : https://github.com/dvandok/igtf-policy-bundle
   Section : misc

It builds those binary packages:

  igtf-policy-classic - IGTF classic profile for Certificate Authorities
  igtf-policy-mics - IGTF MICS profile for Certificate Authorities
  igtf-policy-slcs - IGTF SLCS profile for Certificate Authorities
  igtf-policy-iota - IGTF IOTA profile for Certificate Authorities
  igtf-policy-unaccredited - IGTF unaccredited Certificate Authorities
  igtf-policy-experimental - IGTF experimental Certificate Authorities

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

  https://mentors.debian.net/package/igtf-policy-bundle/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.113-1~bpo11+1.dsc

Changes since the last upload:

 igtf-policy-bundle (1.113-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.
 .
 igtf-policy-bundle (1.113-1) unstable; urgency=medium
 .
   * New upstream release:
   * [Changes from 1.112 to 1.113 (4 October 2021)]
   * Suspended MD-GRID CA due to network resolution issues (MD)
   * [Changes from 1.111 to 1.112 (16 August 2021)]
   * Updated ANSPGrid CA with extended validity date (BR)
   * [Changes from 1.110 to 1.111 (24 May 2021)]
   * Removed discontinued NERSC-SLCS CA (US)
   * Removed discontinued MYIFAM CA (MY)
   * [Changes from 1.109 to 1.110 (22 March 2021)]
   * Removed INFN-CA-2015 that has disappeared operationally (IT)

Regards,
-- 
  Dennis van Dok

Bug#996977: kbd-chooser: can't chose keyboard variant keymap

2021-10-22 Thread Holger Wansing

Hi,

Am 22. Oktober 2021 10:24:43 MESZ schrieb Xavier Brochard 
:
>Le 21.10.2021 23:15, Samuel Thibault a écrit :
>> Yes, we do not want to clutter the menu with various variant choices for
>> each and every language.
>
>May be I don't remember, but I think it was possible to chose a variant on the 
>ncurse UI in "advanced" mode (at the lower priority options).

As I wrote in another mail:
this was possible until Debian 6 (2012).

Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#997022: kwin-x11: Black screen after attempting to enable compositing

2021-10-22 Thread Ben Morris

Package: kwin-x11
Version: 4:5.23.0-2
Severity: important

When starting compositing in kwin (either by starting kwin with compositing
enabled, or by pressing Ctrl-Alt-F12 while kwin is running), the whole screen
goes black apart from the mouse cursor.

When this happens, kwin prints `kwin_core: Failed to initialize compositing,
compositing disable`. Further attempts to enable compositing via the keyboard
shortcut produce two lines: `kwin_core: Failed to initialize compositing,
compositing disable` and `kwin_core: XCB error: 10 (BadAccess), sequence: 2497,
resource id: 1730, major code: 142 (Composite), minor code: 2
(RedirectSubwindows)`.


Attempting to disable or enable compositing has no visible effect. The screen
simply remains black until kwin is killed.


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

Kernel: Linux 5.14.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, 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_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kwin-x11 depends on:
ii  kwin-common   4:5.23.0-2
ii  libc6 2.32-4
ii  libepoxy0 1.5.9-2
ii  libgcc-s1 11.2.0-10
ii  libkf5configcore5 5.86.0-1
ii  libkf5coreaddons5 5.86.0-1
ii  libkf5crash5  5.86.0-1
ii  libkf5i18n5   5.86.0-1
ii  libkf5quickaddons55.86.0-1
ii  libkf5windowsystem5   5.86.0-1
ii  libkwaylandserver5 [libkwaylandserver5-5.23]  5.23.0-1
ii  libkwineffects13  4:5.23.0-2
ii  libkwinglutils13  4:5.23.0-2
ii  libkwinxrenderutils13 4:5.23.0-2
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5dbus5   5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libqt5widgets55.15.2+dfsg-12
ii  libqt5x11extras5  5.15.2-2
ii  libstdc++611.2.0-10
ii  libx11-6  2:1.7.2-2+b1
ii  libxcb-composite0 1.14-3
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.14-3
ii  libxcb-render01.14-3
ii  libxcb-shape0 1.14-3
ii  libxcb-xfixes01.14-3
ii  libxcb1   1.14-3
ii  libxi62:1.8-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

Bug#992715: freecad: Cannot find icon: Surface_Extend

2021-10-22 Thread Tobias Frost

Control: tags -1 fixed-upstream

upstream has merged the PR.

Bug#997024: [greek]babel + cleveref + pagenumbering + label = ☇

2021-10-22 Thread Peter Mueller

Package: texlive-latex-extra
Version: 2021.20210921-1
Reproduce:
1) Put
\documentclass{article} \usepackage[greek]{babel}%%% greek should not 
necessarily be the main language; e.g., [greek, ngerman] would also expose the 
bug \usepackage{cleveref} \begin{document} \pagenumbering{Roman} 
\label{someLabel} \end{document}
into mwe.tex
2) Run pdflatex mwe
3) Observe the error message
! Incomplete \iffalse; all text was ignored after line 6.  \fi 
<*> mwe? X
Since cleveref has not been updated since 2018, I wildly guess that it is 
cleveref that has to be updated to match the current development of latex and 
babel.  At the same time, I'm unsure who is the real culprit (perhaps, none, 
but the interface is broken) and leave the investigation concerning bugs in 
packaging or upstream development to the Debian maintainers.
Thanks in advance
Peter

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

2021-10-22 Thread YunQiang Su

Claudio Kuenzler  于2021年10月22日周五 下午2:03写道：
>
> The fact that a later Kernel versions work fine _could_ be because of a hpwdt 
> commit after 5.10: 
> https://github.com/torvalds/linux/commit/acc195bd2cc48445ea35d00036d8c0afcc4fcc9c#diff-994ee4b010b5c6222ad7a20e160f733401f46894b36fa3e1fb6ffbb48bedb817
> I have not tested sid or a newer Kernel on our HP machines though.
> If you've compiled your own Kernel and this one works (did your do a multiple 
> reboot test?), maybe there's a difference in the Kernel "config"?
>
> What happens if you disable the hpwdt module as mentioned in the other bug 
> reports? Does Bullseye with 5.10 and experimental with 5.14 work in this case?

I test upstream linux and debian-linux with the same config.
All of the upstream config works fine, while debian-linux has this problem.
I guess it is due to one patch by Debian.

-- 
YunQiang Su

Bug#986027: firefox: WebExtensions process sometimes consumes 100% CPU indefinitely on Firefox 87

2021-10-22 Thread Paul Wise

On Sun, 28 Mar 2021 15:41:29 +0900 Yuya Nishihara wrote:

> After upgrading to Firefox 87, I've sometimes seen one of the firefox
> contentproc consumes 100% CPU usage indefinitely after start. Killing that
> process appears to terminate all of the extensions, and firefox goes back
> to normal by reenabling them in "Add-ons Manager" page.

FYI I found a faster way to disable/enable addons:

First in about:config set devtools.chrome.enabled to true.

Then when you want to apply the workaround pres Ctrl+Shift+j, run this:

Components.utils.import("resource://gre/modules/AddonManager.jsm");
AddonManager.getAllAddons().then(addons => addons.forEach(addon => 
{addon.disable() ; addon.enable()}))

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#641768: New upstream repo (fork)

2021-10-22 Thread Sven Mäder

Dear Maintainer

The https://github.com/Antergos/web-greeter repo was archived due to:
https://fossbytes.com/antergos-linux-dead-alternatives/

A fork exists on https://github.com/JezerM/web-greeter where v3.x.x was
released recently.

Kind regards
Sven

-- 
Sven Mäder 
Support: https://m.ethz.ch/#/#helpdesk:phys.ethz.ch
Chat: https://m.ethz.ch/#/@rda:phys.ethz.ch
Voice: not available
IT Services Group, HPT H 6
Physics Department, ETH Zurich
CH-8093 Zurich, Switzerland

Bug#984036: disulfinder: ftbfs with GCC-11

2021-10-22 Thread Nilesh Patra


On Wed, 03 Mar 2021 16:11:37 + Matthias Klose  wrote:

BRNN/RNNs/Options.h:69:5: error: ISO C++17 does not allow dynamic exception 
specifications
  69 | throw(BadOptionSetting);
 | ^
BRNN/RNNs/Options.h:143:5: error: ISO C++17 does not allow dynamic exception 
specifications
143 | throw(BadOptionSetting);
 | ^
BRNN/RNNs/Options.h:180:5: error: ISO C++17 does not allow dynamic exception 
specifications
 180 | throw(BadOptionSetting);
 | ^


Hi all,

looks like C++17 has removed the provision to specify custom exceptions, and 
there are a lot of errors
like the one above.
In this case, does it makes sense to force C++14 standard (with chnages in 
d/rules or with patches) in such cases and ask upstream to
clean these up? Or do I miss a relatively easy solutions?

Let me know

Nilesh

Bug#996270: false positive custom-library-search-path

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2021-10-22 at 05:36 -0700, Felix Lechner wrote:
> > I think it'd be nice to have a way to
> > express that there's a generic/accepted RPATH for a package
> 
> I am not sure Debian's position is particularly accommodating [1] but
> I am happy to entertain any proposal.

That page doesn't apparently mention the term 'plugin', which I think is one
good reason to set the runpath on a binary, though :)

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFy1sYACgkQ3rYcyPpX
RFtkOQgAtnvLk+iZ0YXfN4LzV4LIL7vzSK3I9sS8nagYwBgmceUJS4ce8SPV3cQP
6fVl+UqTUlgdyY3woZK8SvULtKyUg0+1OnlZMZx4G+raE/ts8U/hm+W5xesN2GiM
4MN14YsrxmcGNPJiMt3GeV9wWkrtnxagiyOLIBRfbt02F9wlaBya/HrM01TJUMqc
6GPp6/LQ0j2FFTSmfBCHrYz8XOh8mhRPt7SPb6M3nJgk6b/HMaquxfIpAgInfhyu
2cIE4dVjSRSwB1CvEw88OTjYawYQrr4CEyh6RfTAAdQBATsimbn9Un5Jhi0+369o
aEE47M9UnByQGV7tjpyHn02wOb6oqQ==
=7jyt
-END PGP SIGNATURE-

Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2021-10-22 at 15:22 +0200, Ondrej Zary wrote:
> With 10.3.29 running, I've dumped all databases (mysqldump --all-databases -
> p >mysql.dump), then dropped all databases, stopped mariadb and deleted
> /var/lib/mysql/ib*.
> Then restarted mariadb, restored databases (source mysql.dump) and finally
> upgraded to 10.3.31.

Thanks, I did the same, and it seemed to work.


Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFy2ToACgkQ3rYcyPpX
RFsnKggA7XFwEwfLwE/paI4ThRlsP6GbXSUT193ivkC//qVQCMdHc6HJPFkuMFEa
7DhLkyE+QfNhzPQad2XRhEoQklpp98392q1QztWt+z5lgopuw8PgHQXeyXLB4in0
dfUcbCCylIWf/HV0qzt5lMOn8aIgZ0pQrEDjC4hYolkl2lyhq8N8zyu5DnXAlSXL
L90/VZUmuM48YOMZ40W5OTs/LYNB7O+dmMAhM6J4gM3xyQ+//Nn33f89v86BFemD
DtqGtsCr+7ZIOHeZmf/OAHLudZ8z0wvVGeO80OCxc95K8Vo503L+CmZI4h/QGA6J
KRm6Pv1tpwHIe4tuE+327DHAo1Z3YQ==
=+ZaT
-END PGP SIGNATURE-

Bug#793549: cmake-data: Can't find fluid with FLTK 1.3.3

2021-10-22 Thread Aaron M. Ucko

Timo Röhling  writes:

> AFAICT upstream has modified their FLTKConfig.cmake to set
> FLTK_FLUID_EXECUTABLE without UseFLTK.cmake; albeit still to "fluid"
> without absolute path.

Ah, yeah, I see in retrospect that *only* 1.3.3 played poorly with
FindFLTK.cmake.

> Is this sufficient for you to consider this bug done?

Sure, thanks.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#996204: transition: numerical library stack

2021-10-22 Thread Anton Gladky

Great, thanks! Will do it very shortly.

Anton

Sebastian Ramacher  schrieb am Fr., 22. Okt. 2021,
14:35:

> Hi Anton
>
> On 2021-10-12 13:09:02, Drew Parsons wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-scie...@lists.debian.org, Anton Gladky <
> gl...@debian.org>
> >
> > I'd like to proceed with a transition of the numerical library stack.
> > This involves
> >
> > superlu   5.2.2+dfsg1 -> 5.3.0+dfsg1  (both libsuperlu5 so not
> really a transition)
> > superlu-dist  libsuperlu-dist6 -> libsuperlu-dist7
> > hypre 2.18.2 -> 2.22.1 (internal within libhypre-dev)
> > mumps libmumps-5.3 -> libmumps-5.4
> > scotch6.1.0 -> 6.1.1 (both libscotch-6.1 so not a transition)
> > petsc libpetsc-.*3.14 -> libpetsc-.*3.15
> > slepc libslepc-.*3.14 -> libslepc-.*3.15
> > (together with petsc4py, slepc4py)
> >
> > Header packages libxtensor-dev, libxtensor-blas-dev will also be
> > upgraded (xtl-dev 0.7.2 already got uploaded to unstable).
> >
> > fenics-dolfinx will upgrade
> >   libdolfinx-.*2019.2 -> libdolfinx-.*0.3
> > (along with other fenics components). There is currently some problem
> > with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf.
> > I'll skip the demo_poisson_mpi tests for them if necessary.
> >
> > sundials 5.7.0 is incompatible with hypre 2.22, Anton Gladky (cc:d) will
> > upgrade to sundials 5.8.0.
>
> I think we are ready for the sundials upload.
>
> Cheers
>
> >
> > openmpi/mpi4py/h5py have recently migrated to testing so shouldn't give
> > any particular trouble (apart from the known 32-bit dolfinx problem)
> >
> > auto transitions are already in place:
> >
> > https://release.debian.org/transitions/html/auto-superlu-dist.html
> > https://release.debian.org/transitions/html/auto-mumps.html
> > https://release.debian.org/transitions/html/auto-petsc.html
> > https://release.debian.org/transitions/html/auto-slepc.html
> >
> >
> > Ben file:
> >
> > title = "numerical library stack";
> > is_affected = .depends ~ "libpetsc-.*3.14" | .depends ~
> "libpetsc-.*3.15";
> > is_good = .depends ~ "libpetsc-.*3.15";
> > is_bad = .depends ~ "libpetsc-.*3.14";
> >
>
> --
> Sebastian Ramacher
>

Bug#997024: (no subject)

2021-10-22 Thread Peter Mueller

… and I've just ping'ed the maintainers of cleveref, babel, and greek.ldf. 
(Just in case the bug is also present upstream.)

Bug#993680: transition: proj

On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote:
> On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote:
>> On 10/21/21 11:17 PM, Sebastian Ramacher wrote:
>>> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition
 X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
 Control: forwarded -1 
 https://release.debian.org/transitions/html/auto-proj.html
 Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 
 983345

 For the Debian GIS team I'd like to transition to PROJ 8.
>>>
>>> Please go ahead. Please also raise  the remaining FTBFS bugs to serious.
>>
>> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to
>> unstable. And the severity of the bugreports has been raised to serious.
>>
>> Thanks for already scheduling the dependency level 2 NMUs, these are
>> almost done except for mips64el where they had to wait for proj to be
>> installed which it is now.
> 
> libgeotiff & spatialite are built & installed on all release
> architectures, dependency level 3 can be NMUed now.

magics++ is built and installed on all release architectures, cdo can be
NMUed now.

> The rebuild of octave-octproj is blocked by sundials not having been
> rebuilt with the new petsc yet.

Kind Regards,

Bas

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

Bug#996270: false positive custom-library-search-path

2021-10-22 Thread Felix Lechner

Hi,

On Fri, Oct 22, 2021 at 8:20 AM Yves-Alexis Perez  wrote:
>
> That page doesn't apparently mention the term 'plugin', which I think is one
> good reason to set the runpath on a binary, though :)

Maybe you could add it to the Wiki page, if you have time. Thanks!

Kind regards,
Felix Lechner

Bug#996104: dkms: Fail to remove modules

2021-10-22 Thread Damir Islamov

Tags 996104 patch fixed-upstream

 https://github.com/dell/dkms/commit/
64a882a32fdf126ef20e6b6403b5cb158dad21f4[1]


Sincerely yours,
*Damir Islamov*



[1] https://github.com/dell/dkms/commit/
64a882a32fdf126ef20e6b6403b5cb158dad21f4


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

Bug#997025: RM: node-request-promise-core -- ROP; Obsolete and now useless

2021-10-22 Thread Yadd

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.net

Hi,

the last reverse dependency of this oldlib has been removed
(node-jsdom). It can now be removed safely.

Cheers,
Yadd

Bug#993680: transition: proj