Bug#1011193: rust-clap: fails to build with feauture derive

[Jonas Smedegaard]

Source: rust-clap
Version: 3.1.6-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The packaging of Rust crate clap is patched to remove feature "derive".

Please uncripple and enable, now that crate clap-derive is in Debian -
this feature is needed by rsass currently in NEW queue.


Thanks,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIyBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmKEh38ACgkQLHwxRsGg
ASEf+w/4lypgN5MBxJGn4rVj8WOL7uU3MZV+ZNDZ/XIO6CHL7K0GMpVuF/VGY3ix
kxCrmweIJDVAvLi/OjUIK8/3Sh/WoxqpsLKJdq4O1YSG81/DfHzUCPw1Z7nP97fA
/9ujeuqWTMT4f39JzyqX/RGSRNk7qx0qVFEJ0+aENHuwk8P341hdgrnQF/CCBbBW
TslgqSMGzoe8jXA2CYAcShLrDCL4Z7UUZR36FU4hmGhTKo7mt5idfriNbvewH8Zo
9O6bAPS0Oyi/JfMGuSZ5OmWn9dNgQEaugZTryv/cvbFNdFFK7vKBsOiq6eq6pLO4
hnig7PMf5E5miw1eZojx114dPAAha5r+aO5rth5Jd42fO5aJbMASRydoXbcePHbx
wChErTmlj1+J5hPPJapcNe6qPkfP0soH+teoe5pg/7zvXDSKbLCW7iRnKEPruKlM
Bsc4SoBKzNY1n7j9cqEikQR3SIdIHgOIGZKXPN3KemgHlKzxzkPZQ0tJP8rF6Ekw
/+SJX2I2MoTDOFfdTGrH+aT1Jfl/bR7gaBnfaDN5z2rQ5f6u6Nku2IZP7QzY6i5J
nPq4yFB24C3EP0tg08YMQIy1rb4lixCyFdHMrZkF3KWGgxHt6r3O3+GMVgCvr6+d
qMmjIqe9wBWuVUZAutmnyVyweIarki14lCn17R7O+6LA7WHuHg==
=NMjE
-END PGP SIGNATURE-

Bug#1011192: ITP: python-griffe -- Signatures for entire Python programs

[Carsten Schoenert]

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

* Package name: python-griffe
  Version : 0.18.0
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/griffe
* License : ISC
  Programming Lang: Python
  Description : Signatures for entire Python programs

 Extract the structure, the frame, the skeleton of your project,
 to generate API documentation or find breaking changes in your API.

This package is a new indirect dependency for mkdocstrings >= 0.18.0
because mkdocstrings got refactored into more dedicated libraries and
tools since version 0.18.0.
In detail python-griffe is a dependency of mkdocstings-python-handlers
which itself is a dependency of mkdocstrings-python-legacy.

It will be maintained within the Debian Python Team.

Bug#1011191: dpkg: let buildinfo record whether host architecture binaries can be executed when cross-compiling

[Johannes Schauer Marin Rodrigues]

Package: dpkg
Version: 1.21.7
Severity: wishlist
Tags: patch
X-Debbugs-Cc: jo...@debian.org

Hi,

when cross compiling, one property of the build system that can
influence the contents of the generate binary packages is whether or not
the host architecture can be executed. While some platforms can natively
execute others (like amd64 can execute i386), other combinations are
more surprising. When installing the qemu-user-static package on a
system with binfmt-support, then foreign architecture binaries for all
architectures qemu supports will suddenly become executable. This is
especially tricky because this will also transparently affect chroot
builds with sbuild and neither schroot nor unshare isolation can prevent
the emulation from happening. The only ways to stop automatic emulation
are uninstalling qemu-user-static on the outside of the build chroot,
writing 0 to /proc/sys/fs/binfmt_misc/qemu-$arch or running the build
with QEMU_VERSION=1 (unreliable). Since transparent foreign architecture
emulation is easily present on a developer's machine and thus
influencing the build (even when done inside a chroot) it would be
useful to record whether or not foreign architecture binaries can be
executed in the buildinfo file.

I attached a proof-of-concept patch that does exactly that. Since we
cannot rely on arch-test being installed in the build environment, this
approach cross compiles a small true.c executable for the host
architecture. This should always work because gcc is build-essential.
The binary outputs a small string instead of just relying on the exit
code to guard against QEMU_VERSION=1 "disabling" of emulation. The field
'Can-Execute-Host-Architecture is only added when cross-compiling, i.e
when host and build architectures mismatch.

Thanks!

cheers, josch
>From 62179358b57d09fc8c6bb7a59deb128c67cbe522 Mon Sep 17 00:00:00 2001
From: Johannes Schauer Marin Rodrigues 
Date: Wed, 18 May 2022 07:11:39 +0200
Subject: [PATCH] dpkg-genbuildinfo: when cross-compiling add
 Can-Execute-Host-Architecture field

---
 scripts/dpkg-genbuildinfo.pl | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/scripts/dpkg-genbuildinfo.pl b/scripts/dpkg-genbuildinfo.pl
index e05fce048..a296a7314 100755
--- a/scripts/dpkg-genbuildinfo.pl
+++ b/scripts/dpkg-genbuildinfo.pl
@@ -28,13 +28,14 @@ use warnings;
 use List::Util qw(any);
 use Cwd;
 use File::Basename;
+use File::Temp qw(tmpnam);
 use POSIX qw(:fcntl_h :locale_h strftime);
 
 use Dpkg ();
 use Dpkg::Gettext;
 use Dpkg::Checksums;
 use Dpkg::ErrorHandling;
-use Dpkg::Arch qw(get_build_arch get_host_arch debarch_eq);
+use Dpkg::Arch qw(get_build_arch get_host_arch debarch_eq 
debarch_to_gnutriplet);
 use Dpkg::Build::Types;
 use Dpkg::Build::Info qw(get_build_env_allowed);
 use Dpkg::BuildOptions;
@@ -46,6 +47,8 @@ use Dpkg::Control;
 use Dpkg::Changelog::Parse;
 use Dpkg::Deps;
 use Dpkg::Dist::Files;
+use Dpkg::Exit qw(push_exit_handler);
+use Dpkg::IPC;
 use Dpkg::Lock;
 use Dpkg::Version;
 use Dpkg::Vendor qw(get_current_vendor run_vendor_hook);
@@ -455,6 +458,33 @@ $fields->{'Installed-Build-Depends'} = 
collect_installed_builddeps($control);
 
 $fields->{'Environment'} = "\n" . cleansed_environment();
 
+if (get_host_arch() ne $fields->{'Build-Architecture'}) {
+# if we are cross-compiling, record whether it was possible to execute the
+# host architecture by cross-compiling and executing a small host-arch
+# binary
+
+my $tmpname = tmpnam();
+push_exit_handler(sub { unlink($tmpname) });
+my ($stdout, $stderr) = ('', '');
+my $testprog = 'int main(){write(1,"ok",2);return 0;}';
+spawn(exec => [ debarch_to_gnutriplet(get_host_arch()) . '-gcc', '-x', 
'c', '-o', $tmpname, '-' ],
+   wait_child => 1, nocheck => 1,
+   to_string => \$stdout,
+   error_to_string => \$stderr,
+   from_string => \$testprog);
+if ($?) {
+   print { *STDOUT } $stdout;
+   print { *STDERR } $stderr;
+   subprocerr("gcc -x c -");
+}
+spawn(exec => [ $tmpname ], error_to_file => '/dev/null', 'to_string' => 
\$stdout, wait_child => 1, nocheck => 1);
+if ($? == 0 && $stdout eq "ok") {
+   $fields->{'Can-Execute-Host-Architecture'} = "true";
+} else {
+   $fields->{'Can-Execute-Host-Architecture'} = "false";
+}
+}
+
 # Generate the buildinfo filename.
 if ($stdout) {
 # Nothing to do.
-- 
2.35.1

Bug#1010913: nala: Please provide a means to run "nala upgrade" without updating the package list

[Blake Lee]

I think this sounds like a great idea. I'll be sure to get a configuration 
option for this in the next release.

In the mean time `nala upgrade --no-update` should be able to get the 
functionality that you want.

Thanks,
Blake

On Thu, May 12, 2022, at 9:03 PM, Axel Beckert wrote:
> Package: nala
> Version: 0.8.2
> Severity: wishlist
> 
> Hi,
> 
> nala seems to mimic that annoying misfeature of yum/dnf to always update
> the package list even if you just did that and just want to upgrade
> packages.
> 
> So please provide a means (e.g. a configuration option in
> /etc/nala/nala.conf) to not run a package list update on "nala upgrade".
> 
> Thanks in advance!
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
> (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), 
> (1, 'buildd-experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
> 
> Versions of packages nala depends on:
> ii  apt  2.4.5
> ii  python3  3.10.4-1+b1
> ii  python3-anyio3.5.0-4
> ii  python3-apt  2.3.0+b1
> ii  python3-httpx0.22.0-2
> ii  python3-pexpect  4.8.0-2
> ii  python3-rich 12.1.0-1
> ii  python3-typer0.4.1-1
> 
> Versions of packages nala recommends:
> ii  python3-socksio  1.0.0-2
> 
> nala suggests no packages.
> 
> -- no debconf information
> 

Bug#1011190: systray-mdstat: Not appearing in system tray on plasma wayland

[Geoff]

Package: systray-mdstat
Version: 1.2.0-2
Severity: important
X-Debbugs-Cc: unit...@bigpond.com

Dear Maintainer,

systray-mdstat notifications appear as per normal but the icon is not in the 
tray.

When run from the command line I see these errors:

(systray-mdstat:60879): Gtk-CRITICAL **: 12:27:36.773: 
gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

This happened after I changed to using wayland.

If I run it like this I don't get those errors and it does appear in the 
systray and works normally:

GDK_BACKEND=x11 systray-mdstat

I also tried this but it didn't help:

GDK_BACKEND=wayland systray-mdstat

Normally that variable is not set.

Thanks,
Geoff



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

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

Versions of packages systray-mdstat depends on:
ii  libdesktop-notify-perl  0.05-2
ii  libfile-sharedir-perl   1.118-1
ii  libgtk3-perl0.038-1
ii  libtry-tiny-perl0.31-1
ii  notification-daemon 3.20.0-4+b1
ii  perl5.34.0-4
ii  plasma-workspace [notification-daemon]  4:5.24.5-1

systray-mdstat recommends no packages.

Versions of packages systray-mdstat suggests:
pn  perlpanel | stalonetray | trayer | cairo-dock-systray-plug-in | wmd  
pn  smart-notifier   

-- no debconf information

Bug#1010764: upstream fix

[Jeremy Stanley]

The fix for this appears to have merged upstream in January, so
could probably be backported in Salsa:

https://gerrit.openafs.org/14882

Bug#1011189: partman-auto-lvm/guided_size defaults to invalid value

[Stephen Gelman]

Source: partman-auto-lvm
Version: 85
Severity: normal
Tags: d-i
X-Debbugs-Cc: ssg...@debian.org

While updating some d-i preseed configs from stretch to bullseye, I
found that previously working partman configs no longer produce the
expected output. For example, on a 3.5T disk, I have the following
partman config:

  boot-root :: \
538 538 538 ext4 \
  $primary{ } \
  $bootable{ } \
  method{ format } \
  format{ } \
  use_filesystem{ } \
  filesystem{ ext4 } \
  mountpoint{ /boot } \
. \
21475 21475 21475 ext4 \
  lv_name{ root } \
  method{ lvm } \
  format{ } \
  use_filesystem{ } \
  filesystem{ ext4 } \
  mountpoint{ / } \
  $lvmok{ } \
. \
1024 1024 -1 ext4 \
  lv_name{ var } \
  method{ lvm } \
  format{ } \
  use_filesystem{ } \
  filesystem{ ext4 } \
  mountpoint{ /var } \
  $lvmok{ } \
.

I would expect this to produce the following:
- 512M /boot
- LVM VG filling the rest of the disk with:
  - 20G /
  - 3.4T /var (rest of the disk)

That is what happens in stretch and earlier (and maybe buster, I haven't
tested). In the bullseye installer I end up with the following:

  $ lsblk
  NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  sda8:00  3.5T  0 disk
  ├─sda1 8:10  512M  0 part /boot
  └─sda2 8:20  3.5T  0 part
├─vg0-root 254:00   20G  0 lvm  /
└─vg0-var  254:10  976M  0 lvm  /var

In trying to track down this bug, I found that
partman-auto-lvm/guided_size was added and according to
https://salsa.debian.org/installer-team/partman-auto-lvm/-/blob/master/debian/partman-auto-lvm.templates#L77-L79,
defaults to a value of "some number". Unsurprisingly, this is not a
valid number configuration option, so the maximum size doesn't get set
properly. Setting "d-i partman-auto-lvm/guided_size string max" in my
preseed restores the previous behavior. I believe there are two issues
here:

1. "partman-auto-lvm/guided_size" should default to "max" in order to
   maintain compatibility with previous releases.
2. When "partman-auto-lvm/guided_size" is set to an invalid value it
   seems that the code does not behave properly. I'm not sure what behavior
   I'd expect, but I don't think the behavior I am seeing of picking the
   minimum size for each partition is correct.

Thanks!

Stephen

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

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

Bug#1010863: streamlink: Broken audio timestamps on arte.tv

[Alexis Murzeau]

Le 18/05/2022 à 01:42, Alexis Murzeau a écrit :
> Le 17/05/2022 à 20:06, Alexis Murzeau a écrit :
>> [...]
> 
> => So really the only option to use ffmpeg v5.x
> 
> 
In Debian ffmpeg v5.0 is only in experimental, but you can try upstream
linux binaries.

If you want to use it only for streamlink without replacing the system one,
you can use this streamlink option:
https://streamlink.github.io/cli.html#cmdoption-ffmpeg-ffmpeg

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



signature.asc
Description: OpenPGP digital signature

Bug#1010863: streamlink: Broken audio timestamps on arte.tv

[Alexis Murzeau]

Le 17/05/2022 à 20:06, Alexis Murzeau a écrit :
> [...]


I've investigated a bit more on how the arte.tv stream is made.
I've found that ffmpeg v4 is using wrong timestamp information from the
input stream and that only ffmpeg v5 read the correct timestamps.
So the same conclusion as upstream.


Details of why (brain dump :-) ):

In fact, arte.tv is not using MPEGTS at all but fragmented MP4.
I've checked the original files 108210-039-B_v216.mp4 and 
108210-039-B_aud_VA.mp4
that are on arte.tv servers, and it is using the fragmented MP4 format
correctly, with this structure:

 - A "header" with metadata: ftyp + moov + sidx
 - Several fragments: moof + mdat
 - A closing header: mfra

In the aud_VA.m3u8 file:
 - The part referenced by #EXT-X-MAP matches exactly the first 1680 bytes
   of the .mp4 files which is the "header"(ftyp + moov + sidx)
 - One fragment in the m3u8 (#EXT-X-BYTERANGE) references 3 MP4 fragments
   (so 3x moof + mdat)

So when streamlink process this file, it will add the "header" every 3
MP4 fragments like this:
 - One "header" (EXT-X-MAP)
   - ftyp + moov + sidx
 - One HLS fragment (EXT-X-BYTERANGE) == 3 MP4 fragments
   - moof + mdat
   - moof + mdat
   - moof + mdat

 - One "header" (EXT-X-MAP)
   - ftyp + moov + sidx
 - One HLS fragment (EXT-X-BYTERANGE) == 3 MP4 fragments
   - moof + mdat
   - moof + mdat
   - moof + mdat
etc... until the last fragment (the "closing header" doesn't appear
anymore).

When checking with the HLS RFC, everything seems fine here.


The MP4 stream contains timestamp in both sidx and tfdt (which is inside
moof blocks).

The issue is that ffmpeg v4 sees the sidx block and decide to reset sample
timestamps (PTS and DTS, presentation and decoding timestamps) according
to that data in sidx.

The correct timestamps are in moof/tfdt which are not part
of the header, so their values are different for each fragments (and
correct). Timestamp in sidx are the same for all fragment as sidx is part
of the "header" which is copied before each HLS fragment.

As sidx appear for each HLS fragment, the behavior of ffmpeg v4 is to
ignore tfdt and resets timestamps instead (which is wrong here).
Then ffmpeg try to recover from that when writing the mpegts output file.

Unfortunately, this means the resulting output file has bad frame
timestamps and players try to follow them, which cause the glitches.


With ffmpeg v5.x, it uses the tfdt (a block in moof block) instead of sidx
and that tfdt contains correct data, that's why everything work fine with
that version.
There is a new option in ffmpeg called "use_tfdt" in that version, which
is enabled by default now.
This was implemented in parts, where the first is here:
https://github.com/FFmpeg/FFmpeg/commit/071930de724166bfb90fc6d368c748771188fd94
According to github, this commit is only in version v5.0 (tag n5.0) but
not earlier.

=> So really the only option to use ffmpeg v5.x



Relevant files:
https://arte-cmafhls.akamaized.net/am/cmaf/108000/108200/108210-039-B/220509185705/medias/108210-039-B_v216.m3u8
https://arte-cmafhls.akamaized.net/am/cmaf/108000/108200/108210-039-B/220509185705/medias/108210-039-B_v216.mp4
https://arte-cmafhls.akamaized.net/am/cmaf/108000/108200/108210-039-B/220509185705/medias/108210-039-B_aud_VA.m3u8
https://arte-cmafhls.akamaized.net/am/cmaf/108000/108200/108210-039-B/220509185705/medias/108210-039-B_aud_VA.mp4
https://arte-cmafhls.akamaized.net/am/cmaf/108000/108200/108210-039-B/220509185705/108210-039-B_VA_XQ.m3u8

Additional sources that helped me:
For MP4: https://bitmovin.com/fun-with-container-formats-2/
For MPEGTS: https://bitmovin.com/fun-with-container-formats-3/
HLS RFC: https://datatracker.ietf.org/doc/html/rfc8216#section-3.3
ffmpeg MP4 options: https://ffmpeg.org/ffmpeg-formats.html#Options-2
Raw MP4 file browser: https://github.com/sannies/isoviewer

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



signature.asc
Description: OpenPGP digital signature

Bug#948108: closed by yokota (Re: unrar corrupts filenames given as arguments)

[Marc Lehmann]

> Tags: wontfix

Shocking.

> This file name bug comes from conversion between wide char strings and
> multi byte strings.

Why would unrar even try to do such a thing for an archive filename on
the command line? It would make sense if this had anything to do with the
filenames stored in the archive, but that's not the case.

> These encoding conversion has so many wired pitfalls, and there is no
> trivial fix.

This is simply false: since there is no need for any conversion, the fix
is trivial, namely don't do any conversion.

Your decision to close this bugreport is wrong, please reconsider.

If you really don't know why the fix is trivial, here is how to do it:
unrar gets a filename to open as archive on the command line. This
filename is a C string in argv.

All it has to do is to use this string in e.g. the open(2) syscall. No
conversion is necessary, and any attempted conversion is simply a bug with
a trivial fix.

The proof for this is that basically every other command has no trouble
with this. If unsure, try to look at how programs such as "cat", "zip" or
"unzip" work, none of which have trouble with this.

Seriously, I have no clue how you can make such extremely wrong claims as
this being a conversion problem.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#1005718: mosh: FTBFS with OpenSSL 3.0

[Vincent Lefevre]

On 2022-05-17 16:57:55 +0200, Axel Beckert wrote:
> > Concerning this bug, it was reported upstream 3 months ago, and
> > there is still no reaction there.
> 
> You are aware, that at least for mosh the Debian package maintainer
> and main upstream developer of Mosh is the same person? So actually
> the forwarding of this bug report into the upstream bug tracker was an
> upstream reaction itself.

I didn't know that. So I'm wondering why he hasn't done anything
for 3 months.

Also note that /usr/share/doc/mosh/README.md.gz says

A note on compiler flags: Mosh is security-sensitive code. When making
automated builds for a binary package, we recommend passing the option
`--enable-compile-warnings=error` to `./configure`. On GNU/Linux with
`g++` or `clang++`, the package should compile cleanly with
`-Werror`. Please report a bug if it doesn't.

I assume that this is the real reason for the current failure. But
the -Wdeprecated-declarations warning (which is thus changed into
an error) isn't related to security.

BTW, warnings may also come from macros provided by libraries, if any.

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

Bug#1011188: linux-image-5.10.0-14-amd64: System freeze

[JPP]

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

Dear Maintainer,

I get a system freeze, mouse and keyboard were blocked.
I had to use the "reset" button on the computer, the system restarts and is
working.
I get a trace in the kern.log that I join to this report.

Regards

JP P


-- Package-specific info:
** Version:
Linux version 5.10.0-14-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.113-1 (2022-04-29)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-14-amd64 
root=UUID=7c11042c-9927-4ec4-94a2-d83c0af03832 ro quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: MSI
product_name: MS-7A70
product_version: 2.0
chassis_vendor: MSI
chassis_version: 2.0
bios_vendor: American Megatrends Inc.
bios_version: A.40
board_vendor: MSI
board_name: B250M PRO-VDH (MS-7A70)
board_version: 2.0

** Loaded modules:
nfnetlink_queue
nft_counter
nf_tables
nfnetlink
rfkill
bridge
stp
llc
intel_rapl_msr
intel_rapl_common
x86_pkg_temp_thermal
snd_hda_codec_realtek
intel_powerclamp
coretemp
snd_hda_codec_generic
ledtrig_audio
snd_hda_codec_hdmi
kvm_intel
snd_hda_intel
nvidia_drm(POE)
snd_intel_dspcfg
kvm
soundwire_intel
soundwire_generic_allocation
irqbypass
snd_soc_core
ghash_clmulni_intel
snd_compress
drm_kms_helper
soundwire_cadence
snd_hda_codec
aesni_intel
cec
libaes
snd_hda_core
crypto_simd
cryptd
mei_hdcp
nvidia_modeset(POE)
snd_hwdep
glue_helper
soundwire_bus
rapl
iTCO_wdt
intel_pmc_bxt
snd_pcm
intel_cstate
iTCO_vendor_support
intel_uncore
snd_timer
nvidia(POE)
mei_me
snd
watchdog
soundcore
ee1004
mei
sg
serio_raw
pcspkr
intel_wmi_thunderbolt
acpi_pad
evdev
intel_pmc_core
parport_pc
ppdev
lp
parport
drm
sunrpc
fuse
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid0
multipath
linear
hid_generic
usbhid
hid
dm_mod
raid1
md_mod
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
mxm_wmi
crct10dif_pclmul
crct10dif_common
crc32_pclmul
psmouse
crc32c_intel
ahci
r8169
libahci
i2c_i801
xhci_pci
realtek
i2c_smbus
libata
mdio_devres
xhci_hcd
libphy
e1000e
scsi_mod
usbcore
ptp
pps_core
usb_common
fan
wmi
video
button

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

auto lo
iface lo inet loopback

allow-hotplug eth0
allow-hotplug eth1
auto br0
iface br0 inet static
address 192.168.1.4
netmask 255.255.255.0
network 192.168.1.0
broadcast   192.168.1.255
gateway 192.168.1.254
bridge_portsenp3s0
bridge_maxwait 1
txqueuelen  8192

auto br1
iface br1 inet static
address 192.168.2.4
netmask 255.255.255.0
network 192.168.2.0
broadcast   192.168.2.255
bridge_portsenp2s0
bridge_maxwait  1
bridge_stp  off
bridge_fd   0
txqueuelen  8192

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp3s0:  mtu 1500 qdisc pfifo_fast master 
br0 state UP group default qlen 1000
link/ether 30:9c:23:64:3c:37 brd ff:ff:ff:ff:ff:ff
3: enp2s0:  mtu 1500 qdisc pfifo_fast master 
br1 state UP group default qlen 1000
link/ether 68:05:ca:71:8b:e2 brd ff:ff:ff:ff:ff:ff
4: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
link/ether 06:b0:90:c3:4a:03 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.4/24 brd 192.168.1.255 scope global br0
   valid_lft forever preferred_lft forever
inet6 fe80::4b0:90ff:fec3:4a03/64 scope link 
   valid_lft forever preferred_lft forever
5: br1:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
link/ether 22:c0:33:94:9e:c7 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.4/24 brd 192.168.2.255 scope global br1
   valid_lft forever preferred_lft forever
inet6 fe80::20c0:33ff:fe94:9ec7/64 scope link 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:  1965521886000 0  0 0   196552
1886000 0   0  0
enp3s0: 407475850  275623000 0  0  2398  5015929   
70422000 0   0  0
enp2s0:  36891535740  1360   

Bug#1011187: redis: FTBFS: killed due to inactivity

[Sebastian Ramacher]

Source: redis
Version: 5:6.0.16-2
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=redis=amd64=5%3A6.0.16-2%2Bb1=1652566704=0

--- Iteration 16 ---
19:48:12> Cluster is writable before failover: OK
19:48:12> Killing node #7: OK
19:48:12> Cluster should eventually be up again: OK
19:48:12> Cluster is writable again: OK
19:48:12> Restarting node #7: OK
19:48:12> Instance #7 is now a slave: OK
19:48:12> We can read back the value we set before: OK
--- Iteration 15 ---
19:48:13> Wait for slave of #1 to sync: OK
19:48:13> Cluster is writable before failover: OK
19:48:13> Killing node #1: OK
19:48:13> Wait failover by #6 with old epoch 2: OK
19:48:18> Cluster should eventually be up again: OK
19:48:18> Cluster is writable again: Expected error reading "sock562250dc96c0": 
software caused connection abort eq {OK} (context: type eval line 4 cmd {assert 
{$err eq {OK}}} proc ::test)
(Jumping to next unit after error)
--- Iteration 14 ---
19:48:18> Cluster is writable before failover: 
E: Build killed with signal TERM after 150 minutes of inactivity

Cheers
-- 
Sebastian Ramacher

Bug#1011186: ovn: FTBFS on armhf

[Sebastian Ramacher]

Source: ovn
Version: 21.06.0+ds1-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=ovn=armhf=21.06.0%2Bds1-5=1652705748=0

/usr/bin/make  check-local
make[4]: Entering directory '/<>'
set /bin/bash './tests/testsuite' -C tests 
AUTOTEST_PATH=/<>/ovs/utilities:/<>/ovs/vswitchd:/<>/ovs/ovsdb:/<>/ovs/vtep:tests:::controller-vtep:northd:utilities:controller:ic;
 \
"$@" --recheck || \
(test -z "$(find /<>/tests/testsuite.dir -name 'asan.*')" && \
 test X'' = Xyes && "$@" --recheck)
## --- ##
## ovn 21.06.0 test suite. ##
## --- ##

OVN end-to-end tests

156: ovn -- policy-based routing IPv6: 1 HVs, 3 LSs, 1 lport/LS, 1 LR -- 
ovn-northd -- dp-groups=no FAILED (ovn.at:7180)
332: ovn -- ACL conjunction -- ovn-northd -- dp-groups=no FAILED 
(ovs-macros.at:255)
379: ovn -- neighbor update on same HV -- ovn-northd -- dp-groups=yes ok
557: ovn -- nb_cfg timestamp -- ovn-northd -- dp-groups=yes ok

OVN Interconnection Controller

946: ovn-ic -- gateway sync -- ovn-northd -- dp-groups=no FAILED (ovn-ic.at:67)

## - ##
## Test results. ##
## - ##

ERROR: All 5 tests were run,
3 failed unexpectedly.
## -- ##
## testsuite.log was created. ##
## -- ##

Please send `tests/testsuite.log' and all information you think might help:

   To: 
   Subject: [ovn 21.06.0] testsuite: 156 332 946 failed

You may investigate any problem if you feel able to do so, in which
case the test suite provides a good starting point.  Its output may
be found below `tests/testsuite.dir'.

make[4]: *** [Makefile:3437: check-local] Error 1
make[4]: Leaving directory '/<>'


Cheers
-- 
Sebastian Ramacher

Bug#994672: open-isns: diff for NMU version 0.101-0.1

[Sebastian Ramacher]

Control: tags 994672 + patch
Control: tags 994672 + pending

Dear maintainer,

I've prepared an NMU for open-isns (versioned as 0.101-0.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru open-isns-0.100/ChangeLog open-isns-0.101/ChangeLog
--- open-isns-0.100/ChangeLog	2020-01-23 22:02:36.0 +0100
+++ open-isns-0.101/ChangeLog	2021-02-01 18:27:33.0 +0100
@@ -1,3 +1,28 @@
+* Changes v0.100 to v0.101:
+
+Dmitry Bogdanov (1):
+  Fix parsing of GetNextRsp
+
+Lee Duncan (10):
+  Ignore common build files
+  Fix compiler issue when not in security mode
+  Do not ignore write() return value.
+  Fix 586 compile issue and remove -Werror
+  Added a TODO: 'make depend' not worrking
+  Update version string to "0.100".
+  Fix broken server authentication initialization.
+  Add man page for isnssetup.
+  Added TODO to test "isnsd --init"
+  Preparing for version 0.101
+
+Leo (1):
+  socket.c: include poll.h instead of sys/poll.h for POSIX compatibility
+
+Rosen Penev (2):
+  fix compilation without deprecated OpenSSL APIs
+  libisns: remove sighold and sigrelse
+
+
 * Changes v0.99 to v0.100:
 
 Chris Leech (1):
diff -Nru open-isns-0.100/client.c open-isns-0.101/client.c
--- open-isns-0.100/client.c	2020-01-23 22:02:36.0 +0100
+++ open-isns-0.101/client.c	2021-02-01 18:27:33.0 +0100
@@ -122,22 +122,17 @@
 /*
  * Create a security context
  */
+#ifdef WITH_SECURITY
 static isns_security_t *
 __create_security_context(const char *name, const char *auth_key,
 		const char *server_key)
 {
-#ifdef WITH_SECURITY
 	isns_security_t 	*ctx;
 	isns_principal_t	*princ;
-#endif /* WITH_SECURITY */
 
 	if (!isns_config.ic_security)
 		return NULL;
 
-#ifndef WITH_SECURITY
-	isns_error("Cannot create security context: security disabled at build time\n");
-	return NULL;
-#else /* WITH_SECURITY */
 	ctx = isns_create_dsa_context();
 	if (ctx == NULL)
 		isns_fatal("Unable to create security context\n");
@@ -174,8 +169,19 @@
 	}
 
 	return ctx;
-#endif /* WITH_SECURITY */
 }
+#else	/* WITH_SECURITY */
+static isns_security_t *
+__create_security_context(__attribute__((unused))const char *name,
+			  __attribute__((unused))const char *auth_key,
+			  __attribute__((unused))const char *server_key)
+{
+	if (!isns_config.ic_security)
+		return NULL;
+	isns_error("Cannot create security context: security disabled at build time\n");
+	return NULL;
+}
+#endif	/* WITH_SECURITY */
 
 /*
  * Create the default security context
diff -Nru open-isns-0.100/configure open-isns-0.101/configure
--- open-isns-0.100/configure	2020-01-23 22:02:36.0 +0100
+++ open-isns-0.101/configure	2021-02-01 18:27:33.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for open-isns 0.100.
+# Generated by GNU Autoconf 2.69 for open-isns 0.101.
 #
 #
 # Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc.
@@ -577,8 +577,8 @@
 # Identity of this package.
 PACKAGE_NAME='open-isns'
 PACKAGE_TARNAME='open-isns'
-PACKAGE_VERSION='0.100'
-PACKAGE_STRING='open-isns 0.100'
+PACKAGE_VERSION='0.101'
+PACKAGE_STRING='open-isns 0.101'
 PACKAGE_BUGREPORT=''
 PACKAGE_URL=''
 
@@ -1250,7 +1250,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures open-isns 0.100 to adapt to many kinds of systems.
+\`configure' configures open-isns 0.101 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1315,7 +1315,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of open-isns 0.100:";;
+ short | recursive ) echo "Configuration of open-isns 0.101:";;
esac
   cat <<\_ACEOF
 
@@ -1410,7 +1410,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-open-isns configure 0.100
+open-isns configure 0.101
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1775,7 +1775,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by open-isns $as_me 0.100, which was
+It was created by open-isns $as_me 0.101, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -3996,7 +3996,7 @@
 esac
 
 if test "$GCC" = "yes"; then
-CFLAGS="-Wall -Werror -Wextra $CFLAGS"
+CFLAGS="-Wall -Wextra $CFLAGS"
 	CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"
 fi
 
@@ -4985,7 +4985,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by open-isns $as_me 0.100, which was
+This file was extended by open-isns $as_me 0.101, which was
 generated by 

Bug#1011185: multiverse-core: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6

[Emmanuel Bourg]

Source: multiverse-core
Version: 0.7.0-5
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

multiverse-core fails to build with OpenJDK 17 because it invokes javac with
the source/target options set to 6. Since OpenJDK 12 the minimum version
supported is 7.

Bug#1011184: jalview: FTBFS with OpenJDK 17 due to JSObject.getWindow() removal

[Emmanuel Bourg]

Source: jalview
Version: 2.11.1.4+dfsg-3
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17


jalview fails to build with OpenJDK 17 due to the removal of the 
JSObject.getWindow() method:

  Compiling with JDK Java compiler API.
  
/<>/src/jalview/viewmodel/seqfeatures/FeatureRendererModel.java:296:
 warning: [synchronization] attempt to synchronize on an instance of a 
value-based class
  synchronized (firing)
  ^
  /<>/src/jalview/appletgui/Tooltip.java:188: warning: [removal] 
Applet in java.applet has been deprecated and marked for removal
if ((parent instanceof Applet) || (parent instanceof Frame))
   ^
  /<>/src/jalview/bin/JalviewLite.java:87: warning: [removal] 
Applet in java.applet has been deprecated and marked for removal
  public class JalviewLite extends Applet
   ^
  /<>/src/jalview/bin/JalviewLite.java:87: warning: [removal] 
Applet in java.applet has been deprecated and marked for removal
  public class JalviewLite extends Applet
   ^
  /<>/src/jalview/bin/JalviewLite.java:87: warning: [removal] 
Applet in java.applet has been deprecated and marked for removal
  public class JalviewLite extends Applet
   ^
  /<>/src/jalview/bin/JalviewLite.java:1418: error: cannot find 
symbol
JSObject scriptObject = JSObject.getWindow(this);
^
symbol:   method getWindow(JalviewLite)
location: class JSObject
  /<>/src/jalview/bin/JalviewLite.java:1587: error: cannot find 
symbol
  JSObject scriptObject = JSObject.getWindow(this);
  ^
symbol:   method getWindow(JalviewLite)
location: class JSObject
  /<>/src/jalview/bin/JalviewLite.java:1613: error: cannot find 
symbol
  scriptObject = JSObject.getWindow(this);
 ^
symbol:   method getWindow(JalviewLite)
location: class JSObject
  /<>/src/jalview/javascript/JSFunctionExec.java:165: error: 
cannot find symbol
  scriptObject = JSObject.getWindow(jvlite);
 ^
symbol:   method getWindow(JalviewLite)
location: class JSObject


Applets are dead, the JalviewLite class should be scrapped.

Bug#1011183: nvidia-driver: Please package 470.129.06 that just appeared today

[Eric Valette]

Package: nvidia-driver
Version: 470.103.01-4
Severity: wishlist

See : https://www.nvidia.com/download/driverResults.aspx/188877/en-us


-- no debconf information

Bug#1011182: xygrib build-depends on obsolete package

[Peter Green]

Package: xygrib
Version: 1.2.6.1-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: patch

xygrib build-depends on libgrib2c-dev which is no longer built by the g2clib
source package. It is still present in unstable as a cruft package, but is
completely gone from testing.

Changing the build-dependency to libg2c-dev resulted in a succesful build in
my test environment.I have not tested if the resulting packages actually work.

Bug#1011181: libspring-java: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6

[Emmanuel Bourg]

Source: libspring-java
Version: 4.3.30-1
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

libspring-java fails to build with OpenJDK 17 because it invokes javac with
the source/target options set to 6. Since OpenJDK 12 the minimum
version supported is 7.

Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0

[Agathe Porte]

Hi,

17/05/2022 19:02, John Paul Adrian Glaubitz :

Hello Agathe!

On 5/17/22 18:48, Agathe Porte wrote:

I do not know when that was done, but the two latest Fedora releases have been 
using >=35
versions which properly support OpenSSL 3.0 [1]. I have opened #1011155 in 
order to discuss
why we cannot just update to latest upstream versions, if that is the case, and 
to not pollute
this thread.

At least for Debian Ports, updating to python-cryptography 35 or newer would 
mean that the package
becomes BD-Uninstallable, i.e. not buildable as the Rust compiler is not 
available on all architectures
yet.

Rust support is slowly coming to more architectures with the rustc_codegen_gcc 
backend and gccrs,
so this problem will be eventually resolved. However, this work is not 
completed yet.
Thanks for this explanation. I totally forgot about architectures other 
than x86_64 and arm64. Makes sense. You may want to repost this to bug 
#1006008 [1] so that we can keep track (or I’ll do it if you want).


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

Bests,

Agata.

Bug#1011180: jline2: FTBFS with OpenJDK 17: release version 6 not supported

[Emmanuel Bourg]

Source: jline2
Version: 2.14.6-4
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17


jline2 fails to build with OpenJDK 17:

  [INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ jline ---
  [INFO] Changes detected - recompiling the module!
  [INFO] Compiling 53 source files to /<>/target/classes
  [WARNING] Unable to autodetect 'javac' path, using 'javac' from the 
environment.
  [INFO] -
  [ERROR] COMPILATION ERROR :
  [INFO] -
  [ERROR] error: release version 6 not supported
  [INFO] 1 error
  [INFO] -

Bug#1011179: picocli: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6

[Emmanuel Bourg]

Source: picocli
Version: 3.9.6-3
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

picocli fails to build with OpenJDK 17 because it invokes javac with
the source/target options set to 6. Since OpenJDK 12 the minimum
version supported is 7.

Bug#1005305: RFS: php-codeigniter-framework/3.1.11-1 [ITP] -- The CodeIgniter framework

[Bastian Germann]

Control: tags -1 moreinfo

On Thu, 10 Feb 2022 23:15:11 +0100 Fab Stz  wrote:

Changes for the initial release:

 php-codeigniter-framework (3.1.11-1) unstable; urgency=low
 .
   * Initial release. Closes: #471583


You added another version and created a new changelog entry for it. Instead of 
this,
please replace the version number for 3.1.13-1 and keep the rest of changelog 
untouched.

Please untag moreinfo when you have uploaded a new revision.

Bug#1001661: notcurses: flaky autopkgtests on armhf

[peter green]

Version 3.0.7 seems to be be passing most of the time on armhf, though there 
were
a few failures duing attempts to migrate gcc-12. The failures appear to be 
timeouts.

Unfortunately 3.0.7 seems to be pretty consistently failing on s390x :(

Bug#1011178: python-fitsio: testsuite fails with cfitsio 4.1.0

[Aurelien Jarno]

Source: python-fitsio
Version: 1.1.7+dfsg-1
Severity: normal
Tags: upstream patch
Forwarded: https://github.com/esheldon/fitsio/pull/349

The python-fitsio testsuite fails when ran against cfitsio 4.1.0:

| testCompressPreserveZeros (fitsio.test.TestReadWrite)
| Test writing and reading gzip compressed image ... Warning: CFITSIO does not 
allow subtractive_dither_2 when using Hcompress algorithm.
| Will use subtractive_dither_1 instead.
| FAIL

...

| ==
| FAIL: testCompressPreserveZeros (fitsio.test.TestReadWrite)
| Test writing and reading gzip compressed image
| --
| Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/fitsio/test.py", line 1375, in 
testCompressPreserveZeros
| assert rdata[zind[0], zind[1]] == 0.0
| AssertionError
| 
| --
| Ran 60 tests in 1.072s

A full test log is available:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-fitsio/21835539/log.gz

The problem is that cfitsio 4.1.0 removed support for
SUBTRACTIVE_DITHER_2 when using the HCOMPRESS algorithm, which is
exactly (one of) the configuration tested in testCompressPreserveZeros.

The fix is to stop testing the HCOMPRESS algorithm, a fix is available
there:
https://github.com/esheldon/fitsio/pull/349

Bug#984789: needrestart: Microcode warnings without using Systemd

[Patrik Schindler]

Hello,

thanks a lot!!

:wq! PoC

Bug#1011177: opennds: binary-any FTBFS

[Adrian Bunk]

Source: opennds
Version: 9.7.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=opennds=9.7.0-1

...
dh_fixperms
chmod a-x debian/opennds/etc/opennds/fas-hid.php
chmod: cannot access 'debian/opennds/etc/opennds/fas-hid.php': No such file or 
directory
make[1]: *** [debian/rules:29: override_dh_fixperms] Error 1

Bug#1011069: decode-dimms does not detect SPD for kingston memory strips

[Aurelien Jarno]

control: reassign -1 src:linux
control: forcemerge 1001286 -1

On 2022-05-16 17:47, Сергей Фёдоров wrote:
> Package: i2c-tools
> Version: 4.3-2
> Severity: normal
> X-Debbugs-Cc: serfyo...@yandex.ru
> 
> Dear Maintainer,
> 
> 
> Problems:
> 
> 1. I want to see the contents of the SPD for each memory strip, but 
> decode-dimms
> (the i2c-tools 4.3-2 package) does not give this for this motherboard. But I 
> see
> it in the BIOS on computers boot and can change it.

decode-dimms uses the kernel spd or ee1004 drivers to access the content
of the EEPROM, and only parses the content. If your SPD EEPROM are not
recognized by the kernel, nothing can be done on the i2c-tools side. I
am therefore reassigning the bug to the kernel and merging it with the
one you already opened there.

> 2. Systems with more than 4 memory slots not supported yet, not instantiating 
> SPD.
> I solved this problem, which I described below.

Just increasing the limit from 4 to 8 won't make things work. The reason
for the limit is that above 4 DIMMs, the EEPROM are usually placed
behind a I2C mux (probably the chip at address 0x44 on your system).
Support for that needs to be added to the kernel.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#976439: wminput: Aborts with "undefined symbol: PyVarObject_CallFunction"

[Bernd Zeimetz]

Hi,

with this MR applied, it does not crash at least.
https://salsa.debian.org/georgesk/cwiid/-/merge_requests/1

Not tested yet.

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1011176: apertium-recursive: fails to detect EOF condition on unsigned char archs

[Steve Langasek]

Package: apertium-recursive
Version: 1.1.0-1
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear maintainers,

The new version of apertium-recursive FTBFS in Ubuntu on most archs because
of incorrect handling of EOF condition from fgetc():

[...]
g++ -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-I/usr/include/lttoolbox-3.6 -I/usr/include/apertium-3.8 
-I/usr/lib/aarch64-linux-gnu/apertium-3.8/include -I/usr/include/libxml2   
-Wall -Wextra -g -O2 -ffile-prefix-map=/<>=. -flto=auto 
-ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong 
-Wformat -Werror=format-security -std=c++20 -c -o pattern.o pattern.cc
rtx_comp.cc: In function ‘int main(int, char**)’:
rtx_comp.cc:104:10: warning: comparison is always false due to limited range of 
data type [-Wtype-limits]
  104 | if(c == EOF)
  |  ^
[...]
==
FAIL: test_compiles (__main__.NoRules)
--
Traceback (most recent call last):
  File "/<>/tests/./run_tests.py", line 8, in test_compiles
with self.assertRaises(subprocess.CalledProcessError):
AssertionError: CalledProcessError not raised

--
Ran 66 tests in 2.751s
[...]

  
(https://launchpad.net/ubuntu/+source/apertium-recursive/1.1.0-1/+build/23586338)

I have no idea why the tests passed at build time in Debian!  But the logic
error in the C code is clear: fgetc() returns an int, not a char, and on
many archs (but not x86), a bare 'char' is unsigned, so can never == EOF.

The attached patch has been uploaded to Ubuntu to fix the build failure
there, and complete the libapertium3-3.8-1 transition.

Please consider applying it in Debian as well (and forwarding upstream).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru apertium-recursive-1.1.0/debian/patches/series 
apertium-recursive-1.1.0/debian/patches/series
--- apertium-recursive-1.1.0/debian/patches/series  1969-12-31 
16:00:00.0 -0800
+++ apertium-recursive-1.1.0/debian/patches/series  2022-05-17 
13:49:42.0 -0700
@@ -0,0 +1 @@
+unsigned-char.patch
diff -Nru apertium-recursive-1.1.0/debian/patches/unsigned-char.patch 
apertium-recursive-1.1.0/debian/patches/unsigned-char.patch
--- apertium-recursive-1.1.0/debian/patches/unsigned-char.patch 1969-12-31 
16:00:00.0 -0800
+++ apertium-recursive-1.1.0/debian/patches/unsigned-char.patch 2022-05-17 
13:52:04.0 -0700
@@ -0,0 +1,29 @@
+Description: fgetc() returns an int, not a (unsigned) char
+ The code is wrongly assigning fgetc()'s return value to a char instead of an
+ int.  On some architectures, this is doubly wrong because 'char' is
+ unsigned, meaning it can never hold the EOF value:
+ .
+ rtx_comp.cc: In function ‘int main(int, char**)’:
+ rtx_comp.cc:104:10: warning: comparison is always false due to limited range 
of data type [-Wtype-limits]
+   104 | if(c == EOF)
+   |  ^
+ .
+ Fix the type, which removes the warning and also fixes build failures on
+ these unsigned char archs in Ubuntu.
+Author: Steve Langasek 
+Last-Update: 2022-05-17
+Forwarded: no
+
+Index: apertium-recursive-1.1.0/src/rtx_comp.cc
+===
+--- apertium-recursive-1.1.0.orig/src/rtx_comp.cc
 apertium-recursive-1.1.0/src/rtx_comp.cc
+@@ -98,7 +98,7 @@
+ cout << "Unable to open " << argv[optind] << " for reading." << endl;
+ exit(EXIT_FAILURE);
+   }
+-  char c;
++  int c;
+   while((c = fgetc(check)) != '<')
+   {
+ if(c == EOF)

Bug#1011018: RFS: pyment/1.0-1 [ITP] -- generate/convert the docstrings from code signature

[Bastian Germann]

Control: tags -1 moreinfo

Please change d/copyright's Files-Excluded to the whole doc/sphinx/html 
directory.
Please force push the upstream branch, rebase debian/master on it and then 
force push debian/master.

Why don't you build the documentation? It should be included as separate binary 
package.
Please see the dh_make python template on how to build it without using the 
Makefile.

I have slightly changed d/copyright and d/watch in git. Please pull the changes.

When you have updated the package please untag moreinfo.

Bug#1011175: visualvm: FTBFS with OpenJDK 17 due to type inference changes

[Emmanuel Bourg]

Source: visualvm
Version: 2.0.6+dfsg-1
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17


visualvm fails to build with OpenJDK 17:


  [nb-javac] 
/<>/visualvm/libs.profiler/lib.profiler.ui/src/org/graalvm/visualvm/lib/ui/swing/ProfilerTreeTable.java:663:
 error: incompatible types: List cannot be converted to List
  [nb-javac] sortKeys = newKeys == null ? Collections.emptyList() :
  [nb-javac]^

Bug#1011174: controlsfx: FTBFS with OpenJDK 17: reference to newFileSystem is ambiguous

[Emmanuel Bourg]

Source: controlsfx
Version: 9.0.0+hg20181001-1
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

controlsfx fails to build with OpenJDK 17:


  
/<>/controlsfx/src/main/java/impl/org/controlsfx/i18n/Translations.java:53:
 error: reference to newFileSystem is ambiguous
  try (FileSystem fs = FileSystems.newFileSystem(jarFile, null)) {
  ^
both method newFileSystem(Path,ClassLoader) in FileSystems and method 
newFileSystem(Path,Map) in FileSystems match

Bug#1011173: RM: gajim-urlimagepreview -- RoM; obsoleted by gajim 1.4.0

[Martin]

Package: ftp.debian.org

Please remove gajim-urlimagepreview from unstable and testing.
Gajim 1.4.0 (now in unstable) includes its functionality. The plugin is
therefore obsolete. Thank you!

Bug#1011172: segment: FTBFS with OpenJDK 17: Attempting to assign weaker access privileges to CharSequence.isEmpty()

[Emmanuel Bourg]

Source: segment
Version: 1.4.2-1
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17


segment fails to build with OpenJDK 17:

  [INFO] -
  [ERROR] COMPILATION ERROR :
  [INFO] -
  [ERROR] 
/<>/src/main/java/net/sourceforge/segment/srx/legacy/Buffer.java:[99,25]
 isEmpty() in net.sourceforge.segment.srx.legacy.Buffer cannot implement 
isEmpty() in java.lang.CharSequence
attempting to assign weaker access privileges; was public
  [INFO] 1 error
  [INFO] -

Bug#1011171: RFS: streamlink/4.0.1-1~bpo11+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bullseye-backports repository.

 * Package name: streamlink
   Version : 4.0.1-1~bpo11+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from various 
websites
  python3-streamlink-doc - CLI for extracting video streams from various 
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to a 
video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_4.0.1-1~bpo11+1.dsc

Changes since the last upload to bullseye-backports:
streamlink (4.0.1-1~bpo11+1) bullseye-backports; urgency=medium

  * Rebuild for bullseye-backports.
  * d/salsa-ci.yml: run CI for bullseye-backports

 -- Alexis Murzeau   Tue, 17 May 2022 22:03:03 +0200

streamlink (4.0.1-1) unstable; urgency=medium

  * New upstream version 4.0.1
  * d/patches: update patches
  * switch to pyproject build
  * d/patches: remove dependency on versioningit
  * d/patches: remove intersphinx which requires internet
  * d/patches: add patch to fix build with root
  * d/control: remove ancient version requirements
  * d/control: avoid lxml crashes with some LC_ALL values

 -- Alexis Murzeau   Thu, 05 May 2022 23:02:52 +0200


Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|





signature.asc
Description: OpenPGP digital signature

Bug#1011170: RM: gajim-syntaxhighlight -- RoM; obsoleted by gajim 1.4.0

[Martin]

Package: ftp.debian.org

Please remove gajim-syntaxhighlight from unstable and testing.
Gajim 1.4.0 (now in unstable) includes its functionality. The plugin is
therefore obsolete. Thank you!

Bug#1011168: linux-image-5.17.0-2-amd64: rebooting KVM guest crashes kernel

[Jon]

Package: src:linux
Version: 5.17.6-1+b1
Severity: normal

Dear Maintainer,

I have a Debian Sid box running some KVM/QEMU guests and ever since the
upgrade to 5.17 it is kernel panicing fairly reliably whenever I reboot
the guest VMs on it. This is happening under both 5.17.3 and 5.17.6.


[420450.562966] BUG: kernel NULL pointer dereference, address: 000b
[420450.586155] #PF: supervisor write access in kernel mode
[420450.603615] #PF: error_code(0x0002) - not-present page
[420450.620787] PGD 0 P4D 0
[420450.629381] Oops: 0002 [#1] PREEMPT SMP PTI
[420450.643410] CPU: 23 PID: 93711 Comm: qemu-system-x86 Kdump: loaded Not 
tainted 5.17.0-2-amd64 #1  Debian 5.17.6-1
[420450.677460] Hardware name: Intel Corporation T5520UR/T5520UR, BIOS 
S5500.86B.01.00.0061.030920121535 03/09/2012
[420450.710936] RIP: 0010:kvm_replace_memslot+0xcf/0x390 [kvm]
[420450.729338] Code: 44 24 08 48 85 db 0f 84 3b 02 00 00 48 89 ea 48 c1 e2 04 
48 01 da 48 8b 4a 08 48 85 c9 74 1e 48 8b 32 48 89 31 48 85 f6 74 04 <48> 89 4e 
08 48 c7 02 00 00 00 00 48 c7 42 08 00 00 00 00 48 8d 54
[420450.791413] RSP: 0018:ad89c683fd70 EFLAGS: 00010206
[420450.808873] RAX: ad89c6a19058 RBX: 8b77f553b400 RCX: 
ad89c6a19110
[420450.832622] RDX: 8b77f553b400 RSI: 0003 RDI: 
ad89c6a19000
[420450.856371] RBP:  R08:  R09: 

[420450.880122] R10: 0001 R11:  R12: 
8b77f553b200
[420450.903874] R13:  R14:  R15: 
ad89c6a19000
[420450.927626] FS:  7f46eff3c640() GS:8b7dd7cc() 
knlGS:
[420450.954525] CS:  0010 DS:  ES:  CR0: 80050033
[420450.973699] CR2: 000b CR3: 0001085ea005 CR4: 
000226e0
[420450.997452] Call Trace:
[420451.005762]  
[420451.012925]  ? kmem_cache_alloc_trace+0x175/0x3e0
[420451.028676]  kvm_set_memslot+0x2fe/0x490 [kvm]
[420451.043622]  kvm_vm_ioctl+0x2cb/0xd80 [kvm]
[420451.057714]  ? handle_mm_fault+0xb2/0x280
[420451.071175]  __x64_sys_ioctl+0x82/0xb0
[420451.083775]  do_syscall_64+0x3b/0xc0
[420451.095805]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[420451.112696] RIP: 0033:0x7f46f6b13397
[420451.124723] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 
5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48
[420451.186798] RSP: 002b:7f46eff3af68 EFLAGS: 0246 ORIG_RAX: 
0010
[420451.211981] RAX: ffda RBX: 4020ae46 RCX: 
7f46f6b13397
[420451.235732] RDX: 7f46eff3b030 RSI: 4020ae46 RDI: 
000c
[420451.259482] RBP: 55b038bce1f0 R08:  R09: 
000c
[420451.283234] R10: 000c R11: 0246 R12: 
7f46eff3b030
[420451.306984] R13: 7ff4 R14: 55b038b69460 R15: 
000c
[420451.330738]  
[420451.338184] Modules linked in: cpuid rpcsec_gss_krb5 nfsv4 dns_resolver 
nf_conntrack_netlink xfrm_user xfrm_algo br_netfilter bridge stp llc overlay 
autofs4 ip6_tables ip6t_rpfilter nft_chain_nat xt_MASQUERADE nf_nat xt_addrtype 
ip_tables xt_state xt_conntrack ipt_REJECT nf_reject_ipv4 nf_conntrack_tftp 
nf_conntrack_ftp xt_tcpudp ipt_rpfilter xt_CT nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 nft_compat nf_tables x_tables nfnetlink nfsd auth_rpcgss nfs_acl 
nfs lockd grace fscache netfs sunrpc jc42 vhost_vsock 
vmw_vsock_virtio_transport_common vsock vhost_net tun vhost vhost_iotlb tap 
ipmi_watchdog nbd squashfs loop dm_crypt dm_mod intel_powerclamp coretemp 
ipmi_ssif kvm_intel kvm irqbypass ghash_clmulni_intel mgag200 drm_shmem_helper 
drm_kms_helper aesni_intel cec crypto_simd rc_core cryptd acpi_ipmi iTCO_wdt 
intel_pmc_bxt intel_cstate ipmi_si drm iTCO_vendor_support evdev sg 
intel_uncore ipmi_devintf watchdog ioatdma i7core_edac i5500_temp 
ipmi_msghandler button acpi_cpufreq xfs
[420451.338279]  libcrc32c crc32c_generic hid_generic usbhid hid uas 
ata_generic usb_storage ses sd_mod enclosure t10_pi scsi_transport_sas 
crc_t10dif ata_piix crct10dif_generic uhci_hcd ehci_pci libata igb megaraid_sas 
ehci_hcd i2c_algo_bit crct10dif_pclmul dca crct10dif_common i2c_i801 usbcore 
scsi_mod ptp crc32_pclmul crc32c_intel i2c_smbus lpc_ich scsi_common usb_common 
pps_core
[420451.734448] CR2: 000b


-- Package-specific info:
** Version:
Linux version 5.17.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-1) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 
5.17.6-1 (2022-05-14)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.17.0-2-amd64 root=/dev/sda1 ro console=ttyS0,38400n8 
UUID=43a6b5ff-7af0-440e-9a9c-3c3a5a6d96fc lockdown=integrity crashkernel=384M

** Not tainted

** Kernel log:
[   16.398935] sd 5:0:0:0: [sdb] Attached SCSI disk
[   20.784872] SGI XFS with ACLs, security attributes, realtime, quota, no 
debug enabled
[   20.815021] XFS 

Bug#1011169: RM: gajim-appindicatorintegration -- RoM; obsoleted by gajim 1.4.0

[Martin]

Package: ftp.debian.org

Please remove gajim-appindicatorintegration from unstable and testing.
Gajim 1.4.0 (now in unstable) includes its functionality. The plugin is
therefore obsolete. Thank you!

Bug#1010911: RM: gajim-plugininstaller -- ROM; obsoleted by gajim 1.4.0

[Martin]

Control: retitle -1 RM: gajim-plugininstaller -- ROM; obsoleted by gajim 1.4.0

gajim-plugininstaller should be removed from experimental, unstable, and
testing now.

Bug#1011167: lwjgl: FTBFS with OpenJDK 17 due to pack200 removal

[Emmanuel Bourg]

Source: lwjgl
Version: 2.9.3+dfsg-5
Severity: important
Tags: sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17


lwjgl fails to build with OpenJDK 17 due to the removal of the pack200 API:


 [core] 
/<>/src/java/org/lwjgl/util/applet/AppletLoader.java:88: error: 
cannot find symbol
 [core] import java.util.jar.Pack200;
 [core] ^
 [core]   symbol:   class Pack200
 [core]   location: package java.util.jar
 [core] 
/<>/src/java/org/lwjgl/util/mapped/MappedObjectUnsafe.java:39: 
warning: Unsafe is internal proprietary API and may be removed in a future 
release
 [core] import sun.misc.Unsafe;
 [core]^
 [core] 
/<>/src/java/org/lwjgl/util/applet/AppletLoader.java:380: error: 
cannot find symbol
 [core] java.util.jar.Pack200.class.getSimpleName();
 [core]  ^
 [core]   symbol:   class Pack200
 [core]   location: package java.util.jar
 [core] 
/<>/src/java/org/lwjgl/util/applet/AppletLoader.java:1688: error: 
package Pack200 does not exist
 [core] Pack200.Unpacker unpacker = Pack200.newUnpacker();
 [core]^
 [core] 
/<>/src/java/org/lwjgl/util/applet/AppletLoader.java:1688: error: 
cannot find symbol
 [core] Pack200.Unpacker unpacker = Pack200.newUnpacker();
 [core] ^
 [core]   symbol:   variable Pack200
 [core]   location: class AppletLoader


The AppletLoader class should be scrapped.

Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0

[Paul Gevers]

Source: pidgin, chatty
Control: found -1 pidgin/2.14.9-2
Control: found -1 chatty/0.6.3-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
pidgin from testing2.14.9-2
chatty from testing0.6.3-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. I note that 
the library moved location from /usr/lib/purple-2/libjabber.so.0.0.0 to 
/usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0. Naively I would 
have expected it to be picked up, but maybe the /purple-2 in the middle 
of the path is preventing that.


Currently this regression is blocking the migration of pidgin to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


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

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
pidgin/2.14.9-2. I.e. due to versioned dependencies or breaks/conflicts.

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

https://ci.debian.net/data/autopkgtest/testing/amd64/c/chatty/21821951/log.gz

/usr/bin/chatty: error while loading shared libraries: libjabber.so.0: 
cannot open shared object file: No such file or directory

autopkgtest [19:11:11]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976439: wminput: Aborts with "undefined symbol: PyVarObject_CallFunction"

[Bernd Zeimetz]

Hi,

I've raised to seveirity to grave as this basically renders the package
useless - and breaks connecting wiimotes.


Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#349388: Fwd: Cfh52

[Martial D Douti]

An email was sent to you to stand as heir to an estate by my secretary, did
you receive it,  are you interested?

Bug#1010202: libmatio: FTBFS against hdf5 1.12.0 currently in experimental - 3 failed tests

[Gilles Filippini]

Hi Sébastien,

Gilles Filippini a écrit le 02/05/2022 à 11:04 :

Hi,

Gilles Filippini a écrit le 29/04/2022 à 14:10 :

Hi Sébastien,

Sébastien Villemot a écrit le 29/04/2022 à 11:45 :

Hi Gilles,

Le mardi 26 avril 2022 à 10:38 +0200, Gilles Filippini a écrit :

Source: libmatio
Version: 1.5.23-1
Severity: important
Tags: ftbfs

While rebuilding libmatio 1.5.23 against hdf5 1.12.0, 3 testcases 
failed with:

[…]

I had an exchange with upstream, who says that libmatio 1.5.23 should
pass all tests against hdf5 1.12.2.

Is there any reason why you’re sticking to hdf5 1.12.0 instead of the
latest stable release 1.12.2?


No, no reason. I wanted to transition 1.12.0 before switching to 
1.12.2, but the other way should be fine as well. I'll give it a try.


I've just tested a rebuild against HDF5 1.12.2, and the same 3 tests 
fail mosly the same way:


2272. mat73_compressed_read_le.at:475: testing Read directory ...
./mat73_compressed_read_le.at:478: cp $srcdir/results/dir_le.out expout
  $builddir/test_mat directory 
$srcdir/datasets/matio_test_cases_compressed_hdf_le.mat

--- /dev/null   2022-04-25 15:38:39.0 +
+++ /<>/test/testsuite.dir/at-groups/2272/stderr 2022-05-02 
08:55:13.515220334 +

@@ -0,0 +1,40 @@
+-E- test_mat: HDF5 error #000 in H5Fopen()
+  file : ../../../src/H5F.c:620
+  major: File accessibility
+  minor: Unable to open file
+-E- test_mat: HDF5 error #001 in H5VL_file_open()
+  file : ../../../src/H5VLcallback.c:3501
+  major: Virtual Object Layer
+  minor: Iteration failed
+-E- test_mat: HDF5 error #002 in H5PL__path_table_iterate()
+  file : ../../../src/H5PLpath.c:578
+  major: Plugin for dynamically loaded library
+  minor: Iteration failed
+-E- test_mat: HDF5 error #003 in H5PL__path_table_iterate_process_path()
+  file : ../../../src/H5PLpath.c:620
+  major: Plugin for dynamically loaded library
+  minor: Can't open directory or file
+-E- test_mat: HDF5 error #004 in H5VL__file_open()
+  file : ../../../src/H5VLcallback.c:3351
+  major: Virtual Object Layer
+  minor: Can't open object
+-E- test_mat: HDF5 error #005 in H5VL__native_file_open()
+  file : ../../../src/H5VLnative_file.c:97
+  major: File accessibility
+  minor: Unable to open file
+-E- test_mat: HDF5 error #006 in H5F_open()
+  file : ../../../src/H5Fint.c:1898
+  major: File accessibility
+  minor: Unable to lock file
+-E- test_mat: HDF5 error #007 in H5FD_lock()
+  file : ../../../src/H5FD.c:1625
+  major: Virtual File Layer
+  minor: Unable to lock file
+-E- test_mat: HDF5 error #008 in H5FD__sec2_lock()
+  file : ../../../src/H5FDsec2.c:1002
+  major: Virtual File Layer
+  minor: Unable to lock file
+-E- test_mat: HDF5 error #000 in H5Fclose()
+  file : ../../../src/H5F.c:707
+  major: Invalid arguments to routine
+  minor: Inappropriate type


Running each failed test alone doesn't fail. Hence I've just tried adding:

override_dh_auto_test:
dh_auto_test --no-parallel

and tada! no more failure.

Best,

_g.

Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found

[Markus Koschany]

Control: severity -1 serious

Am Dienstag, dem 17.05.2022 um 21:59 +0200 schrieb mt...@nurfuerspam.de:
> Package: mediathekview
> Version: 13.2.1-4
> Severity: important
> 
> Dear Maintainer,
> 
> after libh2-java was updated from version 2.1.210+really1.4.197-1 to 2.1.212-
> 1
> there is an enormous occurrence of the following error exceptions when
> starting mediathekview:

Hello and thanks for the report. Currently this cannot be avoided because we
had to move forward with the h2 database in Debian. The latest version of
mediathekview should not require h2 anymore. I don't have the time to package a
new upstream release right now but if someone wants to beat me to it, please go
ahead and mark yourself as the owner of this bug report.

Regards,

Markus


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

Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found

[mtths]

Package: mediathekview
Version: 13.2.1-4
Severity: important

Dear Maintainer,

after libh2-java was updated from version 2.1.210+really1.4.197-1 to 2.1.212-1
there is an enormous occurrence of the following error exceptions when
starting mediathekview:

[ERROR] 2022-05-17 21:11:24.398 [FilmeImportierenAutoThread] 
mSearch.daten.DatenFilm - SQLException:
org.h2.jdbc.JdbcSQLSyntaxErrorException: Schema "MEDIATHEKVIEW" nicht gefunden
Schema "MEDIATHEKVIEW" not found; SQL statement:
INSERT INTO mediathekview.film VALUES (?) [90079-212]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:632) 
~[h2.jar:2.1.212]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:477) 
~[h2.jar:2.1.212]
at org.h2.message.DbException.get(DbException.java:223) 
~[h2.jar:2.1.212]
at org.h2.message.DbException.get(DbException.java:199) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.getSchema(Parser.java:1052) ~[h2.jar:2.1.212]
at org.h2.command.Parser.getSchema(Parser.java:1058) ~[h2.jar:2.1.212]
at org.h2.command.Parser.readTableOrView(Parser.java:8311) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.readTableOrView(Parser.java:8306) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.parseInsert(Parser.java:1641) ~[h2.jar:2.1.212]
at org.h2.command.Parser.parsePrepared(Parser.java:814) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.parse(Parser.java:691) ~[h2.jar:2.1.212]
at org.h2.command.Parser.parse(Parser.java:661) ~[h2.jar:2.1.212]
at org.h2.command.Parser.prepareCommand(Parser.java:568) 
~[h2.jar:2.1.212]
at org.h2.engine.SessionLocal.prepareLocal(SessionLocal.java:631) 
~[h2.jar:2.1.212]
at org.h2.engine.SessionLocal.prepareCommand(SessionLocal.java:554) 
~[h2.jar:2.1.212]
at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1116) 
~[h2.jar:2.1.212]
at 
org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:92) 
~[h2.jar:2.1.212]
at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:288) 
~[h2.jar:2.1.212]
at 
org.apache.commons.dbcp2.DelegatingConnection.prepareStatement(DelegatingConnection.java:696)
 ~[commons-dbcp2.jar:2.9.0]
at 
org.apache.commons.dbcp2.DelegatingConnection.prepareStatement(DelegatingConnection.java:696)
 ~[commons-dbcp2.jar:2.9.0]
at 
mSearch.daten.DatenFilm.writeFilmNumberToDatabase(DatenFilm.java:171) 
~[MediathekView.jar:?]
at mSearch.daten.DatenFilm.(DatenFilm.java:164) 
~[MediathekView.jar:?]
at 
mSearch.filmlisten.reader.FilmListReader.readData(FilmListReader.java:262) 
~[MediathekView.jar:?]
at 
mSearch.filmlisten.reader.FilmListReader.processFromWeb(FilmListReader.java:407)
 ~[MediathekView.jar:?]
at 
mSearch.filmlisten.reader.FilmListReader.readFilmListe(FilmListReader.java:318) 
~[MediathekView.jar:?]
at 
mediathek.filmlisten.ImportFilmliste.urlLaden(ImportFilmliste.java:95) 
~[MediathekView.jar:?]
at 
mediathek.filmlisten.FilmeImportierenAutoThread.searchFullList(FilmeImportierenAutoThread.java:82)
 ~[MediathekView.jar:?]
at 
mediathek.filmlisten.FilmeImportierenAutoThread.run(FilmeImportierenAutoThread.java:40)
 ~[MediathekView.jar:?]
[ERROR] 2022-05-17 21:11:24.435 [pool-5-thread-2] mSearch.daten.DatenFilm - 
org.h2.jdbc.JdbcSQLSyntaxErrorException: Schema "MEDIATHEKVIEW" nicht gefunden
Schema "MEDIATHEKVIEW" not found; SQL statement:
MERGE INTO mediathekview.website_links KEY(ID) VALUES (?,?) [90079-212]
[ERROR] 2022-05-17 21:11:24.430 [pool-5-thread-1] mSearch.daten.DatenFilm - 
SQLException:
org.h2.jdbc.JdbcSQLSyntaxErrorException: Schema "MEDIATHEKVIEW" nicht gefunden
Schema "MEDIATHEKVIEW" not found; SQL statement:
MERGE INTO mediathekview.description KEY(ID) VALUES (?,?) [90079-212]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:632) 
~[h2.jar:2.1.212]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:477) 
~[h2.jar:2.1.212]
at org.h2.message.DbException.get(DbException.java:223) 
~[h2.jar:2.1.212]
at org.h2.message.DbException.get(DbException.java:199) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.getSchema(Parser.java:1052) ~[h2.jar:2.1.212]
at org.h2.command.Parser.getSchema(Parser.java:1058) ~[h2.jar:2.1.212]
at org.h2.command.Parser.readTableOrView(Parser.java:8311) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.readTableOrView(Parser.java:8306) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.readSimpleTableFilter(Parser.java:1168) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.parseMerge(Parser.java:1537) ~[h2.jar:2.1.212]
at org.h2.command.Parser.parsePrepared(Parser.java:819) 
~[h2.jar:2.1.212]
at org.h2.command.Parser.parse(Parser.java:691) ~[h2.jar:2.1.212]
at org.h2.command.Parser.parse(Parser.java:661) ~[h2.jar:2.1.212]
at 

Bug#1011152: spyder: Console not starting. Spyder alerts : iPython 7.31.1 & qtconsole 5.3.0 not installed. But they are !

[Julian Gilbey]

It's a pleasure!

We cannot write instructions to cover every eventually; that is
effectively impossible.  But it seems like you did the right thing to
sort out your problem, which I am pleased to hear.

Best wishes,

   Julian

On Tue, May 17, 2022 at 07:42:37PM +0200, epsommum...@virgilio.it wrote:
> Thank you very much !
> 
> Your command did not work in Spyder's console on the desktop, first because of
> the 3 at the end of pip, then because pressing the Y key at the prompt did not
> do anything. After googling how to force uninstall I found the command that
> worked for the desktop :
> 
> pip uninstall iPython -y
> 
> (I did not have a local qtconsole package installed)
> 
> In qemu, I typed this in a regular console since no console worked in Spyder :
> 
> python3 -m pip uninstall qtconsole iPython
> 
> Here the prompts accepted my Y presses.
> 
> I then had to do (probably because I closed spyder while it was reporting the
> error messages for a github bug report) :
> 
> killall spyder
> 
> Then Spyder started successfully !
> 
> Too bad your instructions are not included in Spyder's error messages to 
> explain
> to people like me who are not pros what to do to solve such a simple problem !
> 
> Anyway, thank you again !
> 
> P.S. : the mail bounced because this mail address I use for bug reports had 
> not
> been used for too long, and I had to renew the password.

Bug#1011127: libssl3 breaks systems vith VIA Nehemiah cpu

[Sebastian Andrzej Siewior]

control: forward -1 https://github.com/openssl/openssl/issues/18334

On 2022-05-17 16:01:35 [+0200], Wolfgang Walter wrote:
> 
> Yes, with libssl3_3.0.3-4.noendbr_i386.deb this is fixed.

perfect, thank you for the confirmation.
I forwarded it upstream and I hope to have something for the next
upload.

> Thanks

Sebastian

Bug#1009282: Should live-wrapper be removed?

[Moritz Mühlenhoff]

severity 1009282 normal
reassign 1009282 ftp.debian.org
retitle 1009282 RM: live-wrapper -- RoQA; Depends on Python 2, depends on 
removed package
thanks

Reassigning for removal.

Cheers,
Moritz

Bug#1009276: Should fsl be removed?

[Moritz Mühlenhoff]

severity 1009276 normal
reassign 1009276 ftp.debian.org
retitle 1009276 RM: fsl -- RoM; Depends on Python 2, FTBFS, unmaintained
thanks

Reassigning for removal.

Bug#1009280: Should python-passfd be removed?

[Moritz Mühlenhoff]

severity 1009280 normal
reassign 1009280 ftp.debian.org
retitle 1009280 RM: python-passfd -- RoQA; Depends on Python 2, no reverse deps
thanks

Reassigning for removal.

Cheers,
Moritz

Bug#972359: ITP: nemo-compare -- Context menu comparison extension for Nemo file manager

[Bastian Germann]

On Sat, 12 Dec 2020 02:39:21 + ItzSwirlz Joshua Peisach 
 wrote:

Latest upstream release 4.8.0 has been uploaded to mentors.


Please package the current version. I will keep an eye on sponsorship-requests.
Uscan on http://packages.linuxmint.com/pool/backport/n/nemo-compare/ is okay,
please ignore my previous comments about it.

Bug#1011164: rtcwake: time without date defaulting to "today" is useless

[Simon Richter]

Package: util-linux
Version: 2.36.1-8+deb11u1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: s...@debian.org

Hi,

the rtcwake command accepts a time without a date as an argument to --date,
interprets it as meaning "today", then complains that the RTC doesn't go
backwards. The string "tomorrow" can only stand alone and means midnight.

This makes it difficult to specify "tomorrow 9:00" without date calculation
code, like rtcwake -t `date +%s -d "tomorrow 9:00"`.

Since it is clear that the desired time cannot be in the past, it would be
nice to interpret a time without a date as either today or tomorrow,
similar to how at(1) handles it.

   Simon

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

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

Versions of packages util-linux depends on:
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-8+deb11u1
ii  libc6  2.31-13+deb11u3
ii  libcap-ng0 0.7.9-2.2+b1
ii  libcrypt1  1:4.4.18-4
ii  libmount1  2.36.1-8+deb11u1
ii  libpam0g   1.4.0-9+deb11u1
ii  libselinux13.1-3
ii  libsmartcols1  2.36.1-8+deb11u1
ii  libsystemd0247.3-7
ii  libtinfo6  6.2+20201114-2
ii  libudev1   247.3-7
ii  libuuid1   2.36.1-8+deb11u1
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.3.0-3
ii  util-linux-locales  2.36.1-8+deb11u1

-- no debconf information

Bug#943903: samba 2:4.11.1+dfsg-1 server breaks mount.cifs from cifs-utils 2:6.9-1

[Marvin Renich]

* Michael Tokarev  [220510 15:54]:
> Control: tag -1 + moreinfo
> 
> On Thu, 31 Oct 2019 11:53:52 -0400 Marvin Renich  wrote:
> > Package: samba
> > Version: 2:4.11.1+dfsg-1
> > Severity: normal
> > 
> > I plan to clone this bug to cifs-utils, as it is unclear which package has 
> > the bug.
> > 
> > After upgrading from samba 2:4.9.13+dfsg-1 to 2:4.11.0+dfsg-10 on a server 
> > machine, mount.cifs from cifs-utils 2:6.9-1
> > on a different machine fails to connect with "mount error(13): Permission 
> > denied".  Subsequently upgrading samba to
> > 2:4.11.1+dfsg-1 did not help.
> > 
> > Downgrading samba to stable 2:4.9.5+dfsg-5+deb10u1 on the server fixes the 
> > problem.  Adding a snapshot version to figure
> > out what needed to be downgraded to get version 2:4.9.13+dfsg-1 was deemed 
> > not worth the effort, as my daily backup on
> > the client machine (which mounts the remote cifs share) was running fine 
> > when the server had 2:4.9.13+dfsg-1.
> 
> Hi!
> 
> Is this still a problem in current bullseye version of samba (4.13) and 
> cifs-utils?
> If yes, can you please try samba version 4.16 (available in 
> bullseye-backports)?
> 
> Thank you!

I no longer have the same setup; both hardware and software configuration are
different.  For example, at the time I reported the bug, I was using 
smbldap-tools
for authentication from an LDAP server.

I tried recreating the original bug in a buster VM with the same versions of 
samba
and cifs-utils (but without all the extra stuff, like LDAP and samba acting as 
WINS
server), but could not replicate the problem.  It also does not occur in my 
current
setup with either bullseye or bookworm.

You can probably close this bug.  If it rears its ugly head again, I'll reopen 
or
file a new bug.

Thanks...Marvin

Bug#1011163: samba: FTBFS on kfreebsd

[Laurent Bigonville]

Source: samba
Version: 2:4.16.1+dfsg-4
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

samba still FTBFS on kfreebsd

PYTHONHASHSEED=1 python3 ./buildtools/bin/waf -j2 -j1 configure -C 
--prefix=/usr --enable-fhs --sysconfdir=/etc --localstatedir=/var 
--libexecdir=/usr/libexec --libdir=/usr/lib/x86_64-kfreebsd-gnu 
--datadir=/usr/share --with-modulesdir=/usr/lib/x86_64-kfreebsd-gnu/samba 
--with-pammodulesdir=/lib/x86_64-kfreebsd-gnu/security 
--with-privatedir=/var/lib/samba/private 
--with-smbpasswd-file=/etc/samba/smbpasswd --with-piddir=/run/samba 
--with-lockdir=/run/samba --with-statedir=/var/lib/samba 
--with-cachedir=/var/cache/samba --with-pam --with-syslog --with-utmp 
--with-winbind --with-quota --with-automount --with-ldap --with-ads 
--with-gpgme --enable-avahi --enable-spotlight --disable-rpath 
--disable-rpath-install 
--with-shared-modules=idmap_rid,idmap_ad,idmap_adex,idmap_hash,idmap_ldap,idmap_tdb2,vfs_dfs_samba4,auth_samba4,vfs_nfs4acl_xattr
 --bundled-libraries=NONE,pytevent,ldb --with-cluster-support 
--enable-etcd-reclock --with-socketpath=/run/ctdb/ctdbd.socket 
--with-logdir=/var/log/ctdb   --disable-cephfs --without-systemd || \
  { echo " contents of config.log:"; cat bin/config.log; false; }
Setting top to   : /<> 
Setting out to   : /<>/bin 
Checking for 'clang' (C compiler): Traceback (most recent call last):
  File "/<>/third_party/waf/waflib/Utils.py", line 831, in wrap
return cache[k]
KeyError: (,)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/<>/third_party/waf/waflib/Utils.py", line 831, in wrap
return cache[k]
KeyError: (,)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/<>/third_party/waf/waflib/Scripting.py", line 159, in 
waf_entry_point
run_commands()
  File "/<>/third_party/waf/waflib/Scripting.py", line 255, in 
run_commands
ctx = run_command(cmd_name)
  File "/<>/third_party/waf/waflib/Scripting.py", line 239, in 
run_command
ctx.execute()
  File "/<>/third_party/waf/waflib/Configure.py", line 159, in 
execute
super(ConfigurationContext, self).execute()
  File "/<>/third_party/waf/waflib/Context.py", line 214, in 
execute
self.recurse([os.path.dirname(g_module.root_path)])
  File "/<>/third_party/waf/waflib/Context.py", line 296, in 
recurse
user_function(self)
  File "/<>/wscript", line 163, in configure
conf.RECURSE('lib/replace')
  File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun
return f(*k, **kw)
  File "/<>/./buildtools/wafsamba/samba_utils.py", line 469, in 
RECURSE
return ctx.recurse(relpath)
  File "/<>/third_party/waf/waflib/Context.py", line 296, in 
recurse
user_function(self)
  File "/<>/third_party/waf/waflib/Utils.py", line 833, in wrap
ret = fun(*k)
  File "/<>/lib/replace/wscript", line 30, in configure
conf.RECURSE('buildtools/wafsamba')
  File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun
return f(*k, **kw)
  File "/<>/./buildtools/wafsamba/samba_utils.py", line 469, in 
RECURSE
return ctx.recurse(relpath)
  File "/<>/third_party/waf/waflib/Context.py", line 296, in 
recurse
user_function(self)
  File "/<>/third_party/waf/waflib/Utils.py", line 833, in wrap
ret = fun(*k)
  File "/<>/buildtools/wafsamba/wscript", line 296, in configure
conf.load('compiler_c')
  File "/<>/third_party/waf/waflib/Configure.py", line 271, in load
func(self)
  File "/<>/third_party/waf/waflib/Tools/compiler_c.py", line 79, 
in configure
conf.load(compiler)
  File "/<>/third_party/waf/waflib/Configure.py", line 271, in load
func(self)
  File "/<>/third_party/waf/waflib/Tools/clang.py", line 22, in 
configure
conf.find_clang()
  File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun
return f(*k, **kw)
  File "/<>/third_party/waf/waflib/Tools/clang.py", line 18, in 
find_clang
conf.get_cc_version(cc, clang=True)
  File "/<>/third_party/waf/waflib/Configure.py", line 317, in fun
return f(*k, **kw)
  File "/<>/third_party/waf/waflib/Tools/c_config.py", line 1027, 
in get_cc_version
cmd = cc + ['-dM', '-E', '-']
TypeError: unsupported operand type(s) for +: 'NoneType' and 'list'


Kind regards,
Laurent Bigonville


-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf present, but not attached

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set

Bug#1011161: RM: libinovasdk [armhf] -- RoM; NBS no longer builds on armhf

[Thorsten Alteholz]

Package: ftp.debian.org
Severity: normal

The package no longer builds on armhf.

  Thorsten

Bug#1011162: ITP: r-cran-metadat -- GNU R meta-analysis datasets

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-metadat -- GNU R meta-analysis datasets
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-metadat
  Version : 1.2
  Upstream Author : Thomas White,
* URL : https://cran.r-project.org/package=metadat
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R meta-analysis datasets
 A collection of meta-analysis datasets for teaching purposes,
 illustrating/testing meta-analytic methods, and validating
 published analyses.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-metadat

Bug#1011160: Incorrect patch for CVE-2022-1355

[Robert Scott]

Package: libtiff
Version: 4.3.0-7

In 4.3.0-7 it looks like you've included a patch based on https://gitlab.com/
libtiff/libtiff/-/commit/9752dae8febab08879fc0159e7d387cff14eb3c3 as a fix for 
CVE-2022-1355, but I don't think this is the right patch. You can confirm this 
by building the package with `-fsanitize=address` and running the issue's poc 
command listed at https://gitlab.com/libtiff/libtiff/-/issues/400:

> tiffcp  -8 -8 -8 -8 -8 -8 -8 -8 -8 -8 ./i ./i

When putting together the fix for the NixOS package, I noticed that it still 
triggers AddressSanitizer in an identical way with the patch. I think this 
happened because the commit in question is (mistakenly?) commented with

> Closes #400 et #8

Perhaps this was just a typo on their part.

The good news is that the commit https://gitlab.com/libtiff/libtiff/-/commit/
c1ae29f9ebacd29b7c3e0c7db671af7db3584bc2, merged in https://gitlab.com/
libtiff/libtiff/-/merge_requests/323, applies cleanly (no prerequisite patches 
or patch mangling required) and *does* solve the poc.


robert.

Bug#1011116: solved

[wr250]

I had to killall connectd  but leave kde indicator running. then attempt 
to pair the phone; the kdeconnectd service will be restarted automatically.


Oddly a reboot did not solve this issue, but killall did.

Bug#1010863: streamlink: Broken audio timestamps on arte.tv

[Alexis Murzeau]

Hi,

On May 11, 2022 9:11:20 PM GMT+02:00, Markus Demleitner  
wrote:
>Package: streamlink
>Version: 3.2.0-1~bpo11+1
>Severity: normal
>
>Dear Maintainer,
>
>When pulling video from arte, e.g.,
>
>streamlink --output o.mp4 \
>https://www.arte.tv/de/videos/108210-039-A/mit-offenen-karten-im-fokus/
>\
>  worst
>
>the audio timestamps for the resulting video file are broken for me
>(since
>fairly recently), which leads to various failures in different clients
>(mpv has
>seconds of hanging videos, vlc has stutters, webkit goes all haywire).
>
>Upstream says it's not a streamlink problem, 
>https://github.com/streamlink/streamlink/issues/4520;
>I've suspected ffmpeg and so backported ffmpeg 4.4 -- to no avail.
>I've also tried a uupdated streamlink 4 -- same result, broken
>timestamps.
>
>So... while I don't doubt upstream's analysis that it's not a
>streamlink
>bug per se that's causing the bad timestamps, I don't know what else
>is.
>I'm grateful for hints on what that might be -- and reports on whether
>other people see the broken timestamps, too.

I've checked this and found that:
 - arte.tv uses a single mp4 file for the whole video
 - use HLS playlist with video fragment referencing part of the mp4 file
 - define a special header as the beginning of the mp4 file. That header is 
repeated before each fragment according to HLS specification. It is a PAT/PMT 
header, and explained here: 
https://medium.com/@stackhousejs/reducing-mpeg-ts-metadata-for-hls-6cec37484d38

So streamlink does that header repetition as it should, but this seems to 
confuse ffmpeg v4.

As of now, I've no more solutions than installing ffmpeg v5 manually (in 
debian, it is currently still n experimental). Maybe a workaround in streamlink 
could be found, but I don't know enough about mpegts.

>
>-- System Information:
>Debian Release: 11.3
>  APT prefers stable-security
>  APT policy: (500, 'stable-security'), (500, 'stable')
>Architecture: i386 (x86_64)
>
>Kernel: Linux 5.16.19 (SMP w/4 CPU threads)
>Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE
>Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not
>set
>Shell: /bin/sh linked to /bin/bash
>Init: sysvinit (via /sbin/init)
>
>Versions of packages streamlink depends on:
>ii  python3 3.9.2-3
>ii  python3-streamlink  3.2.0-1~bpo11+1
>
>Versions of packages streamlink recommends:
>ii  mpv  0.32.0-3
>ii  vlc  3.0.16-1
>
>streamlink suggests no packages.
>
>-- no debconf information

-- 
Alexis Murzeau

Bug#983250: vlc: Crash when starting to play video under weston / wayland

[Rémi Denis-Courmont]

On Sun, 21 Feb 2021 20:08:05 +0200 Rémi Denis-Courmont  
wrote:
> > Wayland support is spposed to be better with the upcoming vlc 4.0. No
> > idea when that version will be released, though.
> 
> Basic playback should work. The crash looks like a problem within EGL, so
> not clear why you flag this as an upstream bug.

In this case, it seems to be a bug in the VLC Qt Wayland support which is 
notoriously broken. To be fair, the VLC 3.0 configure script does state:
 "Incomplete Wayland support (default disabled)"

It was probably not a good idea to enable it in Debian. VLC 3 should be used 
through XWayland.

-- 
Реми Дёни-Курмон
http://www.remlab.net/

Bug#1011159: qbs: FTBFS on hppa: '/usr/lib/qt5/bin/qdoc': No such file or directory

[John David Anglin]

Source: qbs
Version: 1.22.1-2
Severity: normal

Dear Maintainer,

The build fails because '/usr/lib/qt5/bin/qdoc' is not available on hppa.

See:
https://buildd.debian.org/status/fetch.php?pkg=qbs=hppa=1.22.1-2=1652808385=0

[snip]
AutoGen: Writing the parse cache file 
"SRC:/obj-hppa-linux-gnu/src/lib/pkgconfig/CMakeFiles/qbspkgconfig_autogen.dir/ParseCache.txt"
AutoGen: Writing the settings file 
"SRC:/obj-hppa-linux-gnu/src/lib/pkgconfig/CMakeFiles/qbspkgconfig_autogen.dir/AutogenUsed.txt"
qdoc: could not exec '/usr/lib/qt5/bin/qdoc': No such file or directory
make[3]: Leaving directory '/<>/obj-hppa-linux-gnu'
make[3]: *** [doc/CMakeFiles/qbs_qch_docs_qbs.dir/build.make:242: 
doc/html/index.html] Error 1
make[3]: Leaving directory '/<>/obj-hppa-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:2086: 
doc/CMakeFiles/qbs_qch_docs_qbs.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs

qdoc-qt5 is no longer built on hppa because it requires clang.

If there is no way to work around this issue, maybe add qdoc-qt5 to
package dependencies.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.18.0-rc6+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_SOFTLOCKUP
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)

Bug#1011152: spyder: Console not starting. Spyder alerts : iPython 7.31.1 & qtconsole 5.3.0 not installed. But they are !

[epsommumule]

Thank you very much !

Your command did not work in Spyder's console on the desktop, first because of 
the 3 at the end of pip, then because pressing the Y key at the prompt did not 
do anything. After googling how to force uninstall I found the command that 
worked for the desktop :

pip uninstall iPython -y

(I did not have a local qtconsole package installed)


In qemu, I typed this in a regular console since no console worked in Spyder :

python3 -m pip uninstall qtconsole iPython

Here the prompts accepted my Y presses.

I then had to do (probably because I closed spyder while it was reporting the 
error messages for a github bug report) :

killall spyder

Then Spyder started successfully !


Too bad your instructions are not included in Spyder's error messages to 
explain to people like me who are not pros what to do to solve such a simple 
problem !


Anyway, thank you again !


P.S. : the mail bounced because this mail address I use for bug reports had not 
been used for too long, and I had to renew the password.

Bug#842613: vlc: should warn when choosing a DVB channel that isn't from the same transponder.

[Rémi Denis-Courmont]

Control: tags -1 + wontfix

On Sun, 30 Oct 2016 20:59:32 +0100 Jiff  wrote:
> Vlc to act the same as Kaffeine: popping a warning up that explains the
> new chosen channel being on another transponder the former recording
> will be stopped, AND (obviously?) allow channel change smoothly when the
> new channel is on the same transponder without any warning and without
> stopping the current recording.

VLC does not know that another pipeline or another process is recording from 
the same tuner if the kernel does not return an error. VLC cannot warn you 
about something that it is not aware of.

VLC can listen on the demux without access to the tuner, in which case you can 
"safely" change channel within the transponder from the Playback menu.

Br,

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/

Bug#1010110: ncbi-blast+: terminate called after throwing an instance of 'ncbi::CIO_Exception'

[Patrice Duroux]

Thanks a lot!

Bug#958250: Use system libjsonparser-dev

[Rémi Denis-Courmont]

Le tiistaina 21. huhtikuuta 2020, 12.59.20 EEST Jonas Smedegaard a écrit :
> > > But anyway, is libjsonparser's upstream still active? No release
> > > since 2014 doesn't suggest that they are. If that is not the case
> > > and we end up with libjsonparser being maintained in Debian, this
> > > means that changing vlc to libjsonparser is not upstreamable. Due to
> > > the size and security history of vlc, I'd like to avoid that.
> 
> A security bug in libjsonparser should be fixed for all consumers of
> that library, not only for VLC.
>
> If upstream project is dead, and VLC discovers and fixes a bug in the
> library, then that bugfix should be forwarded to the Debian package so
> that other consumers benefit from it as well.

As an upstream developer, I would counter that it is up to Debian, 
specifically, the maintainers of the affected package (not VLC) to take bug 
fixes 
if their upstream is dead.

> Only if VLC changes the API of libjsonparser, effectively forking it
> (and that fork is not packaged separately in Debian!) does it make sense
> to keep using an embedded code copy.

In general and overall, VLC has a pretty good track record of enabling Linux 
distros to use system library builds rather than embedded ones.

But to put things back into historical context, libjsonparser was added to 
Debian in 2018. VLC has depended on it since 2012 and it is quite a small 
library, so that's that.

With that said, in this particular case, VLC 4.0 is probably getting rid of 
libjsonparser entirely in favour of a different implementation, so the 
motivation for overhauling the build system around it is pretty much 
nonexistent from the VLC project side.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/

Bug#1011158: mockito: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6

[Emmanuel Bourg]

Source: mockito
Version: 2.23.0-1
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

mockito fails to build with OpenJDK 17 because it invokes javac with
the source/target options set to 6. Since OpenJDK 12 the minimum
version supported is 7.

  Compiling with JDK Java compiler API.
  error: Source option 6 is no longer supported. Use 7 or later.
  error: Target option 6 is no longer supported. Use 7 or later.
  :compileJava FAILED
  :compileJava (Thread[Task worker for ':' Thread 5,5,main]) completed. Took 
1.067 secs.

Bug#1011157: libsbml: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6

[Emmanuel Bourg]

Source: libsbml
Version: 5.19.0+dfsg-2
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

libsbml fails to build with OpenJDK 17 because it invokes javac with
the source/target options set to 6. Since OpenJDK 12 the minimum
version supported is 7.

  [ 99%] Building: libsbml.jar
  Creating: libsbml.jar
  CMake Error at 
/<>/src/bindings/java/compile-native-files.cmake:71 (message):
  
Could not compile java wrappers:
  
  
warning: [options] bootstrap class path not set in conjunction with -source 
6
  
error: Source option 6 is no longer supported.  Use 7 or later.
  
error: Target option 6 is no longer supported.  Use 7 or later.
  
  
  make[4]: *** 
[src/bindings/java/CMakeFiles/binding_java_jar.dir/build.make:74: 
src/bindings/java/libsbmlj.jar] Error 1

Bug#961118: vlc: Rendering issues on scaled display

[Rémi Denis-Courmont]

Control: -1 tags + moreinfo

On Wed, 20 May 2020 12:39:58 +0200 Kyle Robbertze  
wrote:
> Package: vlc
> Version: 3.0.10-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Opening video in VLC on a scaled display causes incorrect rendering to
> occur. Under KDE the window gets broken up badly and the video is purely
> a black screen. Moving it to an unscaled monitor fixes the issue. A
> screenshot is attached. The playlist screen is not affected and renders
> correctly.

TBH, this looks like a bug in Xorg or the WM. Does this affect all video output 
methods and both integrated/embedded and non-embedded video playback?

Br,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#1011156: picard-tools: FTBFS with OpenJDK 17 due to com.sun.javadoc removal

[Emmanuel Bourg]

Source: picard-tools
Version: 2.27.1+dfsg-1
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

picard-tools fails to build with Java 17 because it uses classes from
the com.sun.javadoc package which was removed:


  :compileJava
  Putting task artifact state for task ':compileJava' into context took 0.003 
secs.
  Up-to-date check for task ':compileJava' took 1.643 secs. It is not 
up-to-date because:
No history is available.
  All input files are considered out-of-date for incremental task 
':compileJava'.
  Compiling with JDK Java compiler API.
  /<>/src/main/java/picard/util/help/PicardHelpDoclet.java:3: 
error: package com.sun.javadoc does not exist
  import com.sun.javadoc.ClassDoc;
^
  /<>/src/main/java/picard/util/help/PicardHelpDoclet.java:4: 
error: package com.sun.javadoc does not exist
  import com.sun.javadoc.RootDoc;
^
  /<>/src/main/java/picard/util/help/PicardHelpDoclet.java:32: 
error: cannot find symbol
  public static boolean start(final RootDoc rootDoc) throws IOException {
^
symbol:   class RootDoc
location: class PicardHelpDoclet
  /<>/src/main/java/picard/util/help/PicardHelpDoclet.java:58: 
error: cannot find symbol
  final ClassDoc classDoc,
^
symbol:   class ClassDoc
location: class PicardHelpDoclet
  
/<>/src/main/java/picard/util/help/PicardHelpDocWorkUnitHandler.java:3:
 error: package com.sun.javadoc does not exist
  import com.sun.javadoc.FieldDoc;
^
  Note: /<>/src/main/java/picard/analysis/CollectOxoGMetrics.java 
uses or overrides a deprecated API.
  Note: Recompile with -Xlint:deprecation for details.
  5 errors
  :compileJava FAILED

Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0

[John Paul Adrian Glaubitz]

Hello Agathe!

On 5/17/22 18:48, Agathe Porte wrote:
> I do not know when that was done, but the two latest Fedora releases have 
> been using >=35
> versions which properly support OpenSSL 3.0 [1]. I have opened #1011155 in 
> order to discuss
> why we cannot just update to latest upstream versions, if that is the case, 
> and to not pollute
> this thread.

At least for Debian Ports, updating to python-cryptography 35 or newer would 
mean that the package
becomes BD-Uninstallable, i.e. not buildable as the Rust compiler is not 
available on all architectures
yet.

Rust support is slowly coming to more architectures with the rustc_codegen_gcc 
backend and gccrs,
so this problem will be eventually resolved. However, this work is not 
completed yet.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1010505: golang-gopkg-libgit2-git2go.v31 autopkgtest failure with libgit2 1.3

[Steve Langasek]

Package: golang-gopkg-libgit2-git2go.v31
Followup-For: Bug #1010505
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

This package builds (and tests) fine, except for this strict version check
in the test.

Testing for versions instead of features doesn't make for very good tests.
Here's a patch that relaxes the version check (but really, it should just be
dropped upstream, and if there are specific compatibilities they're
concerned about, those should be expressed as tests of the code).

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru 
golang-gopkg-libgit2-git2go.v31-31.4.3/debian/patches/libgit-1.3-compat.patch 
golang-gopkg-libgit2-git2go.v31-31.4.3/debian/patches/libgit-1.3-compat.patch
--- 
golang-gopkg-libgit2-git2go.v31-31.4.3/debian/patches/libgit-1.3-compat.patch   
1969-12-31 16:00:00.0 -0800
+++ 
golang-gopkg-libgit2-git2go.v31-31.4.3/debian/patches/libgit-1.3-compat.patch   
2022-05-17 09:09:59.0 -0700
@@ -0,0 +1,21 @@
+Description: raise the upper bound for libgit compat
+ Generally best not to put upper version constraints in source code, we don't
+ know the future.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1010505
+Last-Update: 2022-05-17
+Forwarded: no
+
+Index: golang-gopkg-libgit2-git2go.v31-31.4.3/git_system_dynamic.go
+===
+--- golang-gopkg-libgit2-git2go.v31-31.4.3.orig/git_system_dynamic.go
 golang-gopkg-libgit2-git2go.v31-31.4.3/git_system_dynamic.go
+@@ -7,7 +7,7 @@
+ #cgo CFLAGS: -DLIBGIT2_DYNAMIC
+ #include 
+ 
+-#if LIBGIT2_VER_MAJOR != 1 || LIBGIT2_VER_MINOR < 1 || LIBGIT2_VER_MINOR > 1
++#if LIBGIT2_VER_MAJOR != 1 || LIBGIT2_VER_MINOR < 1 || LIBGIT2_VER_MINOR > 3
+ # error "Invalid libgit2 version; this git2go supports libgit2 between v1.1.0 
and v1.1.0"
+ #endif
+ */
diff -Nru golang-gopkg-libgit2-git2go.v31-31.4.3/debian/patches/series 
golang-gopkg-libgit2-git2go.v31-31.4.3/debian/patches/series
--- golang-gopkg-libgit2-git2go.v31-31.4.3/debian/patches/series
2021-08-29 09:48:38.0 -0700
+++ golang-gopkg-libgit2-git2go.v31-31.4.3/debian/patches/series
2022-05-17 09:08:10.0 -0700
@@ -1 +1,2 @@
 Skip-remote-tests.patch
+libgit-1.3-compat.patch

Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0

[Agathe Porte]

Hi,

17/05/2022 08:43, John Paul Adrian Glaubitz :

Hi!


Looks like an upgrade to at least v35.0.0 is needed to fix this issue:
https://github.com/pyca/cryptography/issues/7039#issuecomment-1088566628=

Not necessarily. One of the Python core developers, Christian Heimes, actually
backported fixes for Python3.10 and OpenSSL 3.0.0 for Fedora [1].


I do not know when that was done, but the two latest Fedora releases 
have been using >=35 versions which properly support OpenSSL 3.0 [1]. I 
have opened #1011155 in order to discuss why we cannot just update to 
latest upstream versions, if that is the case, and to not pollute this 
thread.


[1] https://src.fedoraproject.org/rpms/python-cryptography

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011155

Best regards,

Agata.

Bug#1011155: python-cryptography: please update to latest >= v35 releases

[Agathe Porte]

Source: python-cryptography
Version: 3.4.8-1
Severity: wishlist
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

- The debian version of cryptography (3.4.8) is from 2021-08-24 [0][1].
- The latest upstream release is May 4th, 2022 [1].

Making it almost 8 months late behind upstream.

This update may have been delayed because the upstream versions starting
from 35.0.0 to require some Rust dependencies [2]. Given that the
current Rust integration in Debian seems reasonable to me [3], I do not
see if this could be an issue preventing the upgrade.

As a side note, Fedora has been using latest >=35 upstream releases
since Fedora 36 [4], so it should be technically feasible.

If there are other reasons for avoiding to keep up with upstream
releases, please let us know in this ticket.

Best regards,

Agata.

[0] https://tracker.debian.org/pkg/python-cryptography
[1] https://pypi.org/project/cryptography/#history
[2] 
https://github.com/pyca/cryptography/blob/main/CHANGELOG.rst#3500---2021-09-29=
[3] https://wiki.debian.org/Teams/RustPackaging
[4] https://src.fedoraproject.org/rpms/python-cryptography

Bug#1011152: spyder: Console not starting. Spyder alerts : iPython 7.31.1 & qtconsole 5.3.0 not installed. But they are !

[Julian Gilbey]

Dear RB68,

On Tue, May 17, 2022 at 04:54:19PM +0200, RB68 wrote:
> Package: spyder
> Version: 5.3.0+dfsg1-7
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: epsommum...@virgilio.it
> 
> Dear Maintainer,
> 
> I upgraded Spyder 4.2.1 to 5.3 both on my main desktop PC and in a qemu 
> client.
> In both cases I encountered a problem.
> 
> The console would not start in the qemu client, Spyder alerting that iPython
> 7.31.1 & qtconsole 5.3.0 are not installed, even though they are ! After a
> reboot I still faced the same problem.

Thanks for this report.  This is strange...

> [...]
> 
> Here are the error messages from Spyder :
> 
> # Mandatory:
> IPython >=7.31.1 : 7.28.0 (NOK)
> qtconsole >=5.3.0;<5.4.0 : 5.1.1 (NOK)

This says that the versions of ipython and qtconsole that spyder has
loaded are versions 7.28.0 and 5.1.1 respectively.

> Traceback (most recent call last):
>   File "/home/horses/.local/lib/python3.9/site-
> packages/qtconsole/base_frontend_mixin.py", line 138, in _dispatch
> handler(msg)

And I think we have the problem: you have locally installed versions
of several of the required Python packages (presumably using "pip3
install --user", and these are loaded in preference to the system
versions.

Have a look at the directory ~/.local/lib/python3.9/site-packages to
see what's locally installed, and uninstall all of the packages that
have newer versions on the system.  For example:

pip3 uninstall qtconsole iPython

I assume that doing this will resolve the problem.  If not, please let
me know.

Best wishes,

   Julian

Bug#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.

[okan bağkesen]

On Sat, 12 Nov 2016 20:22:21 -0500 Kamaraju Kusumanchi 
wrote:
> Confirm that Tim Small solution worked for me as well. I am running
> Debian Stretch and removing libgnutls-deb0-28 fixed the error.
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages curl depends on:
> ii  libc62.24-3
> ii  libcurl3-gnutls  7.50.1-1
> ii  zlib1g   1:1.2.8.dfsg-2+b1
>
> curl recommends no packages.
>
> curl suggests no packages.
>
> -- no debconf information
>
> --
> Kamaraju S. Kusumanchi
> http://raju.shoutwiki.com/wiki/Blog
>
>

Bug#1011131: josm: FTBFS with JavaCC 6

[Sebastiaan Couwenberg]

In the upstream issue it's noted that javacc 6.1.3 was never released:

"
 This tagged release may or may not be released, but is tagged here so
 that we maintain a history prior to merging in Francis' substantial
 changes.
"

https://github.com/javacc/javacc/releases/tag/release_6_1_3

6.1.2 is the most recent 6.x on Maven Central:

 https://search.maven.org/artifact/net.java.dev.javacc/javacc

And that works as expected:


https://github.com/simonpoole/OpeningHoursParser/issues/72#issuecomment-1129016265

Would you consider downgrading to 6.1.2?

Kind Regards,

Bas

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

Bug#998468: libvirt0: qmeu KVM: USB Passthrough partially stopped working in Bullseye

[Alejandro R . Sedeño]

I experienced this exact same issue when I tried to upgrade my home server
in April 2022.

Also trying to pass a Conbee II to a HomeAssistant VM, same issues, same
dmesg spam.

I ended up rolling back to Buster because I had no time to investigate
further.

-Alejandro

Bug#1011153: dh-cargo, sometimes includes generated cargo.lock in lib package.

[Peter Green]

Package: dh-cargo

rust-libc is currently blocked from migrating to testing by an autopkgtest 
regression
in rust-rpassword.


debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', '-j56', 
'--target', 'x86_64-unknown-linux-gnu', '--all-targets', 
'--no-default-features'],) {}
error: failed to select a version for the requirement `libc = "=0.2.103"`
candidate versions found which didn't match: 0.2.125
location searched: directory source `/tmp/tmp.FK7ISfSozf/registry` (which is 
replacing registry `crates-io`)
required by package `rpassword v5.0.1 
(/usr/share/cargo/registry/rpassword-5.0.1)`


It appears the cause is that librust-rpassword-dev contains a Cargo.lock file 
which
was generated from the versions of packages in debian at the time of it's 
upload.

Doing some poking around it appears that the Cargo.lock file is generated by the
"dh_auto_test -- test --all" command in debian/rules. What I haven't figured out
is under what circumstances this happens, there appears to be at least* one 
other
rust library package containing a Cargo.lock file in it's root 
librust-os-pipe-dev
and it's autopkgtest is failing in the same way.

I think the most sensible way to deal with this is to exclude Cargo.lock in 
dh-cargo,
does anyone else have any thoughts before I go ahead and do that?


* The search on packages.debian.org for Cargo.lock gave a "too many results" 
error.

Bug#990247: vlc: reproducible builds: Fix passing sort order to tar when generating default.vlt

[Rémi Denis-Courmont]

Control: tags 990247 = upstream

On Wed, 23 Jun 2021 13:24:23 -0700 Vagrant Cascadian  wrote:
> In share/Makefile.am, when creating default.vlt it attempts to detect
> the availability of the tar --sort= option, but then incorrectly passes
> the variable to tar.
> 
> It does not appear to affect the sort order on
> tests.reproducible-builds.org, but it does appear to cause issues when
> testing with reprotest, and so may occur in other situations in the
> wild.
> 
> 
> The attached patch fixes this by passing it as a make variable rather
> than a quoted shell variable.

Such a patch should be submitted upstream but for a start, it does not look 
right to me. Specifically $$tarsort is correct. AFAICT, the problem is that 
predicate for the assignment relies on locale-dependent behaviour and thus 
fails with non-English languages.

Br,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#842513: vlc: immediate crash on launch on powerpc

[Rémi Denis-Courmont]

Hi,

I have submitted an upstream MR to attempt to fix this. But I don't have a 
setup to actually test it. So I would appreciate if someone could try it out:

https://code.videolan.org/videolan/vlc/-/merge_requests/1934

Br,

-- 
Реми Дёни-Курмон
http://www.remlab.net/

Bug#1007097: iwd forcefully enabled randomize mac address, cannot disable via /etc/iwd/main.conf

[Seth Arnold]

Hello, is "AddressRandomizatio" a typo in only the bug report or also a
typo in the configuration file?

Thanks

Bug#1005718: mosh: FTBFS with OpenSSL 3.0

[Axel Beckert]

Hi Vincent,

Vincent Lefevre wrote:
> > > Shouldn't Debian use -Wno-error=deprecated-declarations to ignore
> > > the use of deprecated functions?
> > 
> > No, in contrary. These kind of problems only appear in Debian Unstable
> > which is our development branch. And there we should see such issues
> > rather early than late.
> 
> Upstream developers could (should) test their software on a machine
> with recent libraries (such as Debian/unstable), so that they would
> see the issue without needing downstream to tell them.

I agree.

> Or Debian should have a specific build system (with options like
> -Werror=deprecated-declarations for any package) just for testing
> and reporting bugs to upstream, but which would not affect the
> build of packages for Debian/unstable.

I disagree.

> Concerning this bug, it was reported upstream 3 months ago, and
> there is still no reaction there.

You are aware, that at least for mosh the Debian package maintainer
and main upstream developer of Mosh is the same person? So actually
the forwarding of this bug report into the upstream bug tracker was an
upstream reaction itself.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#170390: (no subject)

[Oswald Buddenhagen]

isync had the --one2one option since v0.9, and the Patterns option since 
v1.0. i think these satisfy the request.

Bug#1011151: BM_TARBALL_BLACKLIST not taken into account

[Frédéric Mazoyer]

Package: backup-manager
Version: 0.7.14-1.2

Here are options of /etc/backup-manager.conf that are not by default

export BM_REPOSITORY_ROOT="/var/archives"
export BM_ARCHIVE_TTL="7"
export BM_ARCHIVE_METHOD="tarball-incremental"
export BM_TARBALL_FILETYPE="zip"
export BM_TARBALL_DIRECTORIES="/etc /var"
export BM_TARBALL_BLACKLIST="/var/archives"
export BM_TARBALLINC_MASTERDATETYPE="weekly"
export BM_TARBALLINC_MASTERDATEVALUE="0"
export BM_UPLOAD_METHOD="ssh-gpg"
export BM_UPLOAD_HOSTS="..xx"
export BM_UPLOAD_DESTINATION="/home/-backup/$HOSTNAME/"
export BM_UPLOAD_SSH_USER="-backup"
export BM_UPLOAD_SSH_KEY="/xxx//-rsa"
export BM_UPLOAD_SSH_HOSTS="..xx"
export BM_UPLOAD_SSH_PORT="22"
export BM_UPLOAD_SSH_DESTINATION="/home/-backup/$HOSTNAME/"
export BM_UPLOAD_SSH_PURGE="true"
export BM_UPLOAD_SSH_TTL=""
export BM_UPLOAD_SSHGPG_RECIPIENT="xx"
export BM_BURNING_METHOD="none"
export BM_PRE_BACKUP_COMMAND="/root/backup-manager-PRE_BACKUP_COMMAND.sh"

the /etc archive is made and exported without problem
The zip compression of /var is launcher but i get not enough space on my hard 
drive.

the /var/log/user.log show a problem:
backup-manager[29643]: warning * Impossible de créer « 
/var/archives/-var.20220517.master.zip », lisez /tmp/bm-tarball.log.XkoNY3 
pour les détails.

The end of /tmp/bm-tarball.log.XkoNY3 is:
  adding: var/archives/-etc.20220515.master.zip (stored 0%)
  adding: var/archives/-etc.20220513.master.zip (stored 0%)
  adding: var/archives/-etc.20220514.master.zip (stored 0%)
  adding: var/archives/-var.20220514.master.zip
zip I/O error: No space left on device
zip error: Output file write failure (write error on zip file)

The problem that /var/archives who is the content of BM_TARBALL_BLACKLIST 
shouldn't be include to the zip !



I am using Debian GNU/Linux 11, kernel SMP Debian 5.10.113-1 (2022-04-29)

Bug#990117: (no subject)

[Oswald Buddenhagen]

fixed upstream in v1.4.3.

Bug#226100: (no subject)

[Oswald Buddenhagen]

since v1.0, one can use

  mbsync --push-delete

to achieve the desired effect.

Bug#921666: isync: error:141A318A:SSL with one server

[Oswald Buddenhagen]

maybe the openssl/libssl package changed its default config, or maybe 
the affected server simply had its configuration fixed. in either case 
it wasn't an isync bug to start with.


for reference, isync has the CipherString option since v1.4, which could 
be used to work around this issue.

Bug#1010266: RFS: base16384/2.2.0-3 [ITP] -- Encode binary files to printable utf16be

[Bastian Germann]

Control: tags -1 moreinfo

On Wed, 27 Apr 2022 22:28:04 +0800 "=?ISO-8859-1?B?ZnVtaWFtYQ==?=" 
 wrote:

Thanks for your introduction. I have restored the Debian revision to -1 and 
edited the changelog.
Then I sent an email and marked the ITP bug #1010055 as done. Now I would like 
to remove
the moreinfo tag.


Please create a watch file that can download the release that your package 
references.
Currently, you do not provide the correct orig tarball for v2.2.0 but some 
random git version.

Bug#403554: isync: Messes up boxes while syncing

[Oswald Buddenhagen]

there have been some subtle changes in the namespace interpretation over 
the years, which caused some configuration breakage in (more or less) 
corner cases. also, some genuine bugs, which have been fixed long 
since.

i don't think it makes sense to keep this report open, given its age.

Bug#908368: isync: Does not work with GSSAPI authentication

[Oswald Buddenhagen]

fixed upstream in v1.4 for good (dynamic buffer).
for v1.3, see #1004979.

Bug#512182: isync: mbsync crash

[Oswald Buddenhagen]

i recommend closing this report, as it's useless in its current form, 
and the issue has almost certainly been fixed upstream meanwhile.

Bug#1011078: chromium: arm64 package not available in bullseye-security

[Steinberg, Benjamin]

> Okay, so arm64 should be building now (thanks Salvatore!). Assuming no
> build failures, they should show up in the archive in a day or two.
> Chromium is a slow build. :)

Thank you, Andres and Salvatore!

Is the build in fact running? I just want to make sure that the "not" in

> > Which I did and the package is not back in building state for arm64.

is a typo for "now" -- :)

Ben

Bug#1010883: dkms breaks nvidia-graphics-drivers autopkgtest on arm64: unmet dependencies

[Andreas Beckmann]

On 12/05/2022 14.21, Andreas Beckmann wrote:
That dependency problem should resolve automatically once src:linux gets 
decrufted.
But we should probably have a better way to enumerate "all 
linux-header-* packages" in dkms-autopkgtest ... and skip cruft ...


Nope, that is a problem in src:linux-signed-amd64 after src:linux got 
binNMUed, the metapackges are uninstallable


The following packages have unmet dependencies:
 linux-headers-amd64 : Depends: linux-headers-5.17.0-2-amd64 (= 
5.17.6-1) but it is not going to be installed


$ rmadison linux-headers-5.17.0-2-amd64
linux-headers-5.17.0-2-amd64 | 5.17.6-1+b1   | unstable   | amd64


Andreas

Bug#1005718: mosh: FTBFS with OpenSSL 3.0

[Vincent Lefevre]

Hi Axel,

On 2022-05-17 14:26:51 +0200, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > Shouldn't Debian use -Wno-error=deprecated-declarations to ignore
> > the use of deprecated functions?
> 
> No, in contrary. These kind of problems only appear in Debian Unstable
> which is our development branch. And there we should see such issues
> rather early than late.

Upstream developers could (should) test their software on a machine
with recent libraries (such as Debian/unstable), so that they would
see the issue without needing downstream to tell them.

Or Debian should have a specific build system (with options like
-Werror=deprecated-declarations for any package) just for testing
and reporting bugs to upstream, but which would not affect the
build of packages for Debian/unstable.

The problem is that it can take months before upstream provides
updated code, while in general, deprecated functions are not removed
before several years (giving the time to developers to notice them
even on platforms with a stable OS release). Of course, this is
completely different if the maintainer or some other Debian developer
is willing to do the work.

Concerning this bug, it was reported upstream 3 months ago, and
there is still no reaction there.

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

Bug#984789: needrestart: Microcode warnings without using Systemd

[Thomas Liske]

Control: tags -1 + upstream fixed-upstream


Hi Patrik,


On Mo, 2021-03-08 at 13:25 +0100, Patrik Schindler wrote:
> libimvirt-perl would provide a convenient way to not depend on
> systemd at all.

I did not want it as a hard dependency.

> Here, it's installed automatically, because I use apt-dater, and apt-
> dater-host
> relies on libimvirt-perl. I suggest to use the code provided in
> /usr/bin/apt-dater-host if systemd-detect-virt can't be found. This
> is most
> likely the most easy solution. Of course, package-dependencies need
> to be
> updated also.

I've changed needrestart to try to use the ImVirt perl package if
systemd-detect-virt is not available. This will be part of the
upcomming needrestart 3.6.

@Patrick Could you add a recommend for `systemd|libimvirt-perl` ?


> Note: Systemd is *not* mandatory. Even for Debian 10 most "server"
> packages
> behave fine with SysVinit.

Full ACK. But, sadly, needrestart's daemon/user session detection works
best on systemd due to the cgroup naming schema. Sadly I'm not aware of
any other init system doing something similar.



Regards,
Thomas
(Upstream)

Bug#1011127: [Pkg-openssl-devel] Bug#1011127: libssl3 breaks systems vith VIA Nehemiah cpu

[Wolfgang Walter]

Am 2022-05-17 15:34, schrieb Sebastian Andrzej Siewior:

On 2022-05-17 12:53:07 [+0200], Wolfgang Walter wrote:
Systems with VIA Nehemiah cpu break after upgrading unstable. All 
commands

using libssl3 fail with

…

lscpu shows:

Architecture:i686
CPU op-mode(s):  32-bit

…
Flags:   fpu vme de pse tsc msr cx8 sep mtrr 
pge

cmov pat mmx fxsr sse cpuid rng rng_en ace ace_en


My guess is that your CPU lacks sse2, which in turn doesn't support
multi-byte nops, which in turn does not support the endbr opcode / CET.
I built i386 packages without endbr and uploaded everything to
https://people.debian.org/~bigeasy/openssl-3-noendbr/

Could you please give a try report if this is correct?

Sebastian


Yes, with libssl3_3.0.3-4.noendbr_i386.deb this is fixed.

Thanks
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Bug#1011150: git-buildpackage: suggestions improving the packaging

[Nicolas Boulenguez]

Package: git-buildpackage
Version: 0.9.22
Severity: wishlist
Tags: patch

Hello.
The attached commits may slightly help the maintainance of the Debian
packaging.
Please apply the ones you agree with.
Thanks.
>From e3ffa388e72450a6fbb37800a69d1094aafdc55d Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Tue, 17 May 2022 14:54:08 +0200
Subject: [PATCH 1/8] debhelper: make package prefix explicit in configuration
 files

This slightly improves readability.
---
 debian/{doc-base => git-buildpackage.doc-base} | 0
 debian/{docs => git-buildpackage.docs} | 0
 debian/{examples => git-buildpackage.examples} | 0
 debian/{links => git-buildpackage.links}   | 0
 4 files changed, 0 insertions(+), 0 deletions(-)
 rename debian/{doc-base => git-buildpackage.doc-base} (100%)
 rename debian/{docs => git-buildpackage.docs} (100%)
 rename debian/{examples => git-buildpackage.examples} (100%)
 rename debian/{links => git-buildpackage.links} (100%)

diff --git a/debian/doc-base b/debian/git-buildpackage.doc-base
similarity index 100%
rename from debian/doc-base
rename to debian/git-buildpackage.doc-base
diff --git a/debian/docs b/debian/git-buildpackage.docs
similarity index 100%
rename from debian/docs
rename to debian/git-buildpackage.docs
diff --git a/debian/examples b/debian/git-buildpackage.examples
similarity index 100%
rename from debian/examples
rename to debian/git-buildpackage.examples
diff --git a/debian/links b/debian/git-buildpackage.links
similarity index 100%
rename from debian/links
rename to debian/git-buildpackage.links
-- 
2.30.2

>From 31c177f2ad1177ae9872975c7dc15fb5c697314c Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Tue, 17 May 2022 15:02:13 +0200
Subject: [PATCH 2/8] debian/rules: simplify installation of zsh and pk4

There seems to be no reason to change their names and permissions
between the source tree and the eventual installation path.
---
 debian/git-buildpackage.install  | 2 ++
 debian/{pk4 => pk4/gbp}  | 0
 debian/rules | 9 -
 debian/{git-buildpackage.zsh-completion => zsh/_gbp} | 0
 4 files changed, 2 insertions(+), 9 deletions(-)
 rename debian/{pk4 => pk4/gbp} (100%)
 mode change 100644 => 100755
 rename debian/{git-buildpackage.zsh-completion => zsh/_gbp} (100%)

diff --git a/debian/git-buildpackage.install b/debian/git-buildpackage.install
index 8e898c17..956ac8c3 100644
--- a/debian/git-buildpackage.install
+++ b/debian/git-buildpackage.install
@@ -1,3 +1,5 @@
+debian/zsh/_gbp   usr/share/zsh/vendor-completions
+debian/pk4/gbpusr/share/pk4/hooks-available/unpack
 usr/bin/gbp
 usr/bin/git-pbuilder
 usr/lib/python3.*/dist-packages/gbp-* usr/lib/python3/dist-packages/
diff --git a/debian/pk4 b/debian/pk4/gbp
old mode 100644
new mode 100755
similarity index 100%
rename from debian/pk4
rename to debian/pk4/gbp
diff --git a/debian/rules b/debian/rules
index 24dedb6c..c49d2c2e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,9 +9,6 @@ EXAMPLE_SCRIPTS=\
 
 DEB_COMPRESS_EXCLUDE=$(EXAMPLE_SCRIPTS)
 
-ZSH_COMPDIR = /usr/share/zsh/vendor-completions/
-PK4_DIR = /usr/share/pk4/hooks-available/unpack/
-
 PYCHECKER_ARGS=-boptparse --no-override --no-shadowbuiltin
 
 %:
@@ -31,12 +28,6 @@ override_dh_auto_build:
 override_dh_auto_install:
 	dh_auto_install
 	dh_bash-completion
-	mkdir -p debian/git-buildpackage/$(ZSH_COMPDIR)
-	install -m644 debian/git-buildpackage.zsh-completion \
-		debian/git-buildpackage/$(ZSH_COMPDIR)/_gbp
-	mkdir -p debian/git-buildpackage/$(PK4_DIR)
-	install -m755 debian/pk4 \
-		debian/git-buildpackage/$(PK4_DIR)/gbp
 	chmod a+x debian/tmp/usr/lib/python3.*/dist-packages/gbp/scripts/supercommand.py
 
 override_dh_auto_clean:
diff --git a/debian/git-buildpackage.zsh-completion b/debian/zsh/_gbp
similarity index 100%
rename from debian/git-buildpackage.zsh-completion
rename to debian/zsh/_gbp
-- 
2.30.2

>From a37e989709635d46e4ca17a4e2c6bfdea0614463 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Tue, 17 May 2022 15:13:06 +0200
Subject: [PATCH 3/8] rules: simplify thanks to debhelper compat 13

When dh-sequence-foo is listed in build-depends, debhelper
automatically inserts dh_foo in the commands.

override_dh_auto_test is not invoked anymore if DEB_BUILD_OPTIONS
contains nocheck.

execute_after_dh_* is available and more readable than override_dh_*.

Move chmod to execute_after_dh_fixperms for clarity.

Examples are not compressed anymore.
---
 debian/control |  1 +
 debian/rules   | 22 ++
 2 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/debian/control b/debian/control
index ab89dc58..0997139e 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Build-Depends:
  bash-completion (>= 1:2.1-4.2~),
  debhelper-compat (= 13),
  dh-python,
+ dh-sequence-bash-completion,
  dh-sequence-python3,
  docbook2x,
  flake8,
diff --git a/debian/rules b/debian/rules