Bug#1043321: spectre-meltdown-checker: support for downfall, inception

[Matt Taggart]

Package: spectre-meltdown-checker
Version: 0.45-2
Severity: wishlist

There is an upstream issue requesting support for the new Downfall 
architecture vulnerability:


https://downfall.page/
https://github.com/speed47/spectre-meltdown-checker/issues/465

and also AMD Inception

https://comsec.ethz.ch/research/microarch/inception/
https://github.com/speed47/spectre-meltdown-checker/issues/466

--
Matt Taggart
m...@lackof.org

Bug#1042376: digikam crashes with "Illegal instruction"

[Steven Robbins]

On Sun, 30 Jul 2023 10:22:19 +0200 Detlef Matthiessen 
 wrote:
> On 30.07.23 07:45, Detlef Matthiessen wrote:
> > 642QMatrix4x4 m = m1;
> 
>On a related note: a quick search for "digikam" and "642" yields the 
following bug report:
> https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/2000718
> https://bugs.kde.org/show_bug.cgi?id=465548
> 
>Admittedly, I'm not familiar with the similarities of the instruction 
sets of an AMD Athlon II vs. my own Intel Q6700
> (or more precise, their lack of complex instructions), but the problem 
sounds quite similar to mine.
> 
>FWIW, comment https://bugs.kde.org/show_bug.cgi?id=465548#c16 points to 
AppImages provided by the KDE team. 8.1.0 is no
> longer available, but I was able to successfully start https://files.kde.org/
digikam/digiKam-8.2.0-20230724T132443-x86-64.appimage
> on my machine. So to me it looks as this bug probably already has been fixed 
upstream.


Thanks for this.  Oddly, the KDE bug notes indicate that the fix was put into 
8.1.0 -- which is the version that this bug's originator reported on.  So it's 
unclear whether this is the same issue.

-Steve




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

Bug#1043311: rustc: please enable profiler builtin

[Andres Salomon]

Control: tags -1 + patch



On Tue, Aug 8 2023 at 06:22:28 PM -04:00:00, Andres Salomon 
 wrote:

Package: src:rustc
Version: 1.66.0+dfsg1-1
Severity: wishlist

Chromium's new rust build requirements include the need for 
/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libprofiler_builtins-*.rlib. 
It would be really helpful to have this built into Debian's rust 
packages.


Ubuntu apparently enabled it, and you can see their patch here:


However, that didn't work for me, at least not with the default of 
BUILD_WINDOWS=true in rustc's current debian/rules. The build 
involving --target $(WINDOWS_ARCH)-pc-windows-gnu  requires 
libclang-rt-15-dev-wasm64 and some extra logic. I'm currently working 
on an updated patch now.







Alright, here's a patch that builds in sid.  I don't know exactly 
whether the stuff with wasi targets are okay building against 
libclang-rt-15-dev (amd64 package), or if it's supposed to be using the 
two dev-wasm packages, but I assumed the wasm packages. I'm also not 
sure if the versioned build-deps in the ubuntu patch are necessary, but 
I didn't include them.


This patch adds "cargo:rustc-link-search=/usr/lib/clang/15/lib/linux/" 
and "cargo:rustc-link-lib=static=clang_rt.profile-x86_64" (or whatever 
architecture it happens to be building on) to the profiler_builtins 
build flags when the target matches the host. In the case where the 
target is different from the host, it assumes a wasm build and sets 
"rustc-link-lib=static=clang_rt.builtins-wasm32" or 
"cargo:rustc-link-lib=static=clang_rt.builtins-wasm64" depending upon 
whether the target is 32 or 64 bits, respectively.


Along with sid, I'd also obviously love to see this in bookworm - but 
given that chromium in bullseye gets another 5 months of support, I'm 
still trying to figure out our options.




diff -urN a/debian/changelog b/debian/changelog
--- a/debian/changelog	2023-06-27 15:12:20.0 +
+++ b/debian/changelog	2023-08-09 00:17:21.192106183 +
@@ -1,3 +1,10 @@
+rustc (1.66.0+dfsg1-1.1) unstable; urgency=medium
+
+  * NMU
+  * add profiler.patch and profiler=true.
+
+ -- Andres Salomon   Mon, 07 Aug 2023 22:23:05 +
+
 rustc (1.66.0+dfsg1-1) unstable; urgency=medium
 
   * Upload to unstable
diff -urN a/debian/config.toml.in b/debian/config.toml.in
--- a/debian/config.toml.in	2023-06-20 18:22:34.0 +
+++ b/debian/config.toml.in	2023-08-09 00:17:21.192106183 +
@@ -5,6 +5,7 @@
 vendor = true
 locked-deps = false
 verbose = VERBOSITY
+profiler = true
 
 rustc = "RUST_DESTDIR/usr/bin/rustc"
 cargo = "RUST_DESTDIR/usr/bin/cargo"
diff -urN a/debian/control b/debian/control
--- a/debian/control	2023-06-27 15:11:38.0 +
+++ b/debian/control	2023-08-09 00:17:21.192106183 +
@@ -18,6 +18,9 @@
  rustc:native (<= 1.66.0++),
  llvm-15-dev:native,
  llvm-15-tools:native,
+ libclang-rt-15-dev,
+ libclang-rt-15-dev-wasm32,
+ libclang-rt-15-dev-wasm64,
  gcc-mingw-w64-x86-64-posix:native [amd64] ,
  gcc-mingw-w64-i686-posix:native [i386] ,
  libllvm15 (>= 1:15.0.0),
diff -urN a/debian/patches/profiler.patch b/debian/patches/profiler.patch
--- a/debian/patches/profiler.patch	1970-01-01 00:00:00.0 +
+++ b/debian/patches/profiler.patch	2023-08-09 00:17:21.196106193 +
@@ -0,0 +1,27 @@
+--- a/library/profiler_builtins/build.rs
 b/library/profiler_builtins/build.rs
+@@ -7,6 +7,24 @@ use std::path::Path;
+ 
+ fn main() {
+ let target = env::var("TARGET").expect("TARGET was not set");
++// use system profiler runtime if possible
++println!(
++"cargo:rustc-link-search=/usr/lib/clang/{}/lib/{}/",
++env::var("DEB_LLVM_VERSION").unwrap(),
++env::var("DEB_CLANG_RT_OS").unwrap()
++);
++if target == std::env::var("HOST").unwrap() {
++println!(
++"cargo:rustc-link-lib=static=clang_rt.profile-{}",
++env::var("DEB_CLANG_RT_ARCH").unwrap()
++);
++return;
++} else {
++println!("cargo:rustc-link-lib=static=clang_rt.builtins-wasm{}",
++if env::var("DEB_CLANG_RT_ARCH").unwrap() == "x86_64" { "64" } else { "32" }
++);
++return;
++}
+ let cfg =  cc::Build::new();
+ 
+ // FIXME: `rerun-if-changed` directives are not currently emitted and the build script
diff -urN a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series	2023-06-27 15:11:38.0 +
+++ b/debian/patches/series	2023-08-09 00:17:21.196106193 +
@@ -19,6 +19,7 @@
 
 # Debian-specific patches, not suitable for upstream
 d-fix-rustix-outline.patch
+profiler.patch
 
 ## Patches needed by debian/prune-unused-deps, for building bootstrap
 d--ignore-removed-submodules.patch
diff -urN a/debian/rules b/debian/rules
--- a/debian/rules	2023-06-20 18:22:34.0 +
+++ b/debian/rules	2023-08-09 00:19:00.740358977 +
@@ -30,6 

Bug#1043320: bash: Background loop with sudo and wait cause terminal problems

[Bruce Momjian]

Package: bash
Version: 5.2.15-2+b2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
A script that worked fine on Debian 11 caused terminal corruption on Debian 12.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I was able to create a minimal test case to illustrate the problem.
   * What was the outcome of this action?
The problem is that output loses carriage returns and echo is turned off for 
the terminal on script exit.
   * What outcome did you expect instead?
I expected no terminal device corruption.  stty sane does fix the terminal 
after the failure.

Here is a test case:

#!/bin/bash

for DIR in $(jot 5)
do  { echo 1; sudo -u $USER -- echo test > /dev/null; echo 2; } | 
cat &
done

wait

Running this on my system outputs the '2' with line feeds and no carriage 
returns, and on exit, the terminal has echo turned off.  stty sane fixes it.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/48 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bash depends on:
ii  base-files   12.4+deb12u1
ii  debianutils  5.7-0.4
ii  libc62.36-9+deb12u1
ii  libtinfo66.4-4

Versions of packages bash recommends:
ii  bash-completion  1:2.11-6

Versions of packages bash suggests:
pn  bash-doc  

-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
  PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
if [ -x /usr/lib/command-not-found -o -x 
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
   /usr/lib/command-not-found -- "$1"
   return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
   /usr/share/command-not-found/command-not-found -- "$1"
   return $?
else
   printf "%s: command not found\n" "$1" >&2
   return 127
fi
}
fi
shopt -s histappend


-- no debconf information

Bug#1043301:

[Tianyu Chen]

Control: tags -1 + patch

patch available by Stuart Prescott at salsa[1], thanks!

Tianyu Chen

[1]: https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/45

Bug#1043319: linux-image-6.5.0-0-amd64: kernel boot hang with 6.5-rc4 and secure boot enabled

[ayan]

Package: src:linux
Version: 6.5~rc4-1~exp1
Severity: important
X-Debbugs-Cc: lazy.tin...@outlook.com

Dear Maintainer,

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

   * What led up to the situation?
 Upgrade kernel to experimental 6.5-rc4, and with laptop secure boot
 enabled.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Disable secure boot, then kernel boot normal, no freezing.

 Enable secure boot, kernel will boot hang, if enable kernel debug,
 then kernel will repeatlly report system lockdown.

 Switch boot to 6.4, kernel boot normally what ever if secure boot
 enabled or not.



-- Package-specific info:
** Version:
Linux version 6.5.0-0-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-1) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC 
Debian 6.5~rc4-1~exp1 (2023-08-04)

** Command line:
root=UUID=789380bb-8570-41d2-b7a7-984073fb0321 ro quiet 
initrd=boot\initrd.img-6.5.0-0-amd64

** Not tainted

** Kernel log:
[3.064195] [drm] PCIE GART of 512M enabled (table at 0x00801FD0).
[3.064537] [drm] Loading DMUB firmware via PSP: version=0x08001E00
[3.064924] amdgpu :03:00.0: firmware: direct-loading firmware 
amdgpu/gc_11_0_1_imu.bin
[3.065841] amdgpu :03:00.0: firmware: direct-loading firmware 
amdgpu/sdma_6_0_1.bin
[3.065988] [drm] Found VCN firmware Version ENC: 1.10 DEC: 5 VEP: 0 
Revision: 0
[3.065992] amdgpu :03:00.0: amdgpu: Will use PSP to load VCN firmware
[3.066062] [drm] max_doorbell_slices=255
[3.069275] cfg80211: Loading compiled-in X.509 certificates for regulatory 
database
[3.069368] Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[3.069447] Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[3.069523] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[3.071110] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[3.071158] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[3.074429] usbcore: registered new interface driver btusb
[3.076697] bluetooth hci0: firmware: direct-loading firmware 
mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
[3.090141] [drm] reserve 0x4a0 from 0x801000 for PSP TMR
[3.118600] mt7921e :01:00.0: enabling device ( -> 0002)
[3.119627] mt7921e :01:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[3.123147] mt7921e :01:00.0: ASIC revision: 79610010
[3.203403] mt7921e :01:00.0: firmware: direct-loading firmware 
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
[3.203704] mt7921e :01:00.0: HW/SW Version: 0x8a108a10, Build Time: 
20230526130917a

[3.212260] Bluetooth: hci0: Device setup in 134557 usecs
[3.212265] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection 
command is advertised, but not supported.
[3.213635] mt7921e :01:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[3.215573] mt7921e :01:00.0: WM Firmware Version: 01, Build 
Time: 20230526130958
[3.239625] zram: Added device: zram0
[3.246180] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[3.246185] Bluetooth: BNEP filters: protocol multicast
[3.246192] Bluetooth: BNEP socket layer initialized
[3.247341] Bluetooth: MGMT ver 1.22
[3.252112] zram0: detected capacity change from 0 to 31142720
[3.254497] mt7921e :01:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[3.254674] NET: Registered PF_ALG protocol family
[3.257108] Adding 15571356k swap on /dev/zram0.  Priority:100 extents:1 
across:15571356k SSFS
[3.314263] NET: Registered PF_QIPCRTR protocol family
[3.715409] amdgpu :03:00.0: amdgpu: RAS: optional ras ta ucode is not 
available
[3.723617] amdgpu :03:00.0: amdgpu: RAP: optional rap ta ucode is not 
available
[3.723618] amdgpu :03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta 
ucode is not available
[3.742330] amdgpu :03:00.0: amdgpu: SMU is initialized successfully!
[3.743382] [drm] Display Core v3.2.241 initialized on DCN 3.1.4
[3.743385] [drm] DP-HDMI FRL PCON supported
[3.745278] [drm] DMUB hardware initialized: version=0x08001E00
[3.761297] snd_hda_intel :03:00.1: bound :03:00.0 (ops 
amdgpu_dm_audio_component_bind_ops [amdgpu])
[3.857564] [drm] PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 
0x3a su_y_granularity 4
[3.859286] [drm] kiq ring mec 3 pipe 1 q 0
[3.863294] [drm] VCN decode and encode initialized successfully(under DPG 
Mode).
[3.863321] amdgpu :03:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG 
decode initialized successfully.
[3.866212] kfd kfd: amdgpu: Allocated 3969056 bytes on gart
[3.866216] kfd kfd: amdgpu: Total number of KFD nodes to be created: 1
[3.866681] 

Bug#1043301: dh-python should declare Depends python3 >= 3.11

[Tianyu Chen]

Control: reopen -1

Hi Stefano,

I believe dh-python should either declare dependency on python3 >= 3.11, or 
install python3-tomli on python3 << 3.11 and use tomli as fallback when tomllib 
can't be imported.

Tianyu Chen

Bug#1042517:

[Mad Horse]

The bug has been reported to upstream ( 
https://gitlab.freedesktop.org/drm/intel/-/issues/8991 ), and a fix is 
available there, though it may need backport.

Bug#1036302: free(): double free detected in tcache 2 during history search

[Ben Wong]

Thank you for narrowing it down, Bernhard. I’ve further isolated the
problem to libreadline. I have attached a program based on the sample code
from the libreadline documentation which exhibits the same behaviour.

Example run:

$ make
cc rlgets.c  -lreadline -o rlgets

$ make test
bash -c "echo $'foo\nbar\n\cp\cu\cp\cu\cn\cj' | ./rlgets"
prompt> foo
prompt> bar
prompt>
free(): double free detected in tcache 2
bash: line 1: 556449 Doneecho 'foo
bar

'
 556450 Aborted (core dumped) | ./rlgets
make: *** [Makefile:5: test] Error 134

Ben Wong
rlgets.c

#include /* readline() */#include
/* add_history() */#include 
/* free() */
/* A static variable for holding the line. */static char *line_read =
(char *)NULL;
/* Read a string, and return a pointer to it.
   Returns NULL on EOF. */char *
rl_gets (char *prompt)
{
  /* If the buffer has already been allocated,
 return the memory to the free pool. */
  if (line_read)
{
  free (line_read);
  line_read = (char *)NULL;
}

  /* Get a line from the user. */
  line_read = readline (prompt);

  /* If the line has any text in it,
 save it on the history. */
  if (line_read && *line_read)
add_history (line_read);

  return (line_read);
}
int main(int argc, char *argv[]) {
  char *buf;

  rl_bind_key ('p'-'a'+1, rl_history_search_backward);
  rl_bind_key ('n'-'a'+1, rl_history_search_forward);
  read_history("history_file");

  while (1) {
buf = rl_gets("prompt> ");
if (!buf) { break; }
if ( !strncmp(buf, "exit", 4) || !strncmp(buf, "quit", 4) ) { break; }
  }

  write_history ("history_file");
  return 0;
}

Makefile

LDLIBS+=-lreadline
rlgets:rlgets.c

test:rlgets
bash -c "echo $$'foo\nbar\n\cp\cu\cp\cu\cn\cj' | ./rlgets"

clean:
rm rlgets history_file core *~ 2>/dev/null || true

On Fri, Jun 2, 2023 at 3:01 AM Bernhard Übelacker bernha...@mailbox.org
 wrote:

Hello,
> below is the top of a valgrind run
> with dbgsym package installed.
>
> Kind regards,
> Bernhard
>
>
#include 	/* readline() */
#include 	/* add_history() */
#include 		/* free() */

/* A static variable for holding the line. */
static char *line_read = (char *)NULL;

/* Read a string, and return a pointer to it.
   Returns NULL on EOF. */
char *
rl_gets (char *prompt)
{
  /* If the buffer has already been allocated,
 return the memory to the free pool. */
  if (line_read)
{
  free (line_read);
  line_read = (char *)NULL;
}

  /* Get a line from the user. */
  line_read = readline (prompt);

  /* If the line has any text in it,
 save it on the history. */
  if (line_read && *line_read)
add_history (line_read);

  return (line_read);
}

int main(int argc, char *argv[]) {
  char *buf;

  rl_bind_key ('p'-'a'+1, rl_history_search_backward);
  rl_bind_key ('n'-'a'+1, rl_history_search_forward);
  read_history("history_file");


  while (1) {
buf = rl_gets("prompt> ");
if (!buf) { break; }
if ( !strncmp(buf, "exit", 4) || !strncmp(buf, "quit", 4) ) { break; }
  }

  write_history ("history_file");
  return 0;
}
  


Makefile
Description: Binary data

Bug#1043318: No *.elc files are made and installed

[Takeshi Soejima]

Package: proofgeneral
Version: 4.4.1~pre170114-1.2

Dear Maintainer,

This package does not support current emacs version 28.2 in Bookworm,
and no *.elc files are made and installed to
/usr/share/emacs/site-lisp/proofgeneral/.

Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Bertram Felgenhauer]

Luca Boccassi wrote:
[...]
> I don't think this is something we should facilitate by default or
> spend any energy on.
>
> You can correct me if I'm wrong, but I don't see any good reason why
> anybody would need to run a polkitd:i386 on an otherwise amd64 system.
> It's not what happens by default if you have i386 enabled and you type
> 'apt install polkitd' or so.

I agree that there isn't a good reason, and I'm not sure how I ended
up in that situation in the first place (the log files don't go back
far enough). One thing I do know is that polkitd:i386 was marked as
automatically installed, so I almost certainly did not make that
decision deliberately.

My speculation is that this happened while satisfying dependencies for
a third party i386 application. That meant installing required 32 bit
libraries, and one of them must have come with a polkitd dependency,
and the i386 version was selected because I was installing an i386
package.

Anyway, I reported this because I assumed that pinning packages to the
native architecture was easy, so it would be justified even for this
(hopefully!) rare scenario... apparently that's not the case.

Cheers,

Bertram

Bug#1042990: util-linux: FTBFS on hppa - #error Unknown target architecture

[John David Anglin]

On 2023-08-05 3:47 p.m., Chris Hofstaedtler wrote:

could you please forward your patch toutil-li...@vger.kernel.org
including a proper Signed-Off-By line? Then upstream can apply it
and downstreams do not need to carry the same patches over and over
again.

Patch is here:
https://marc.info/?l=util-linux-ng=169142291102062=2

Regards,
Dave anglin

--
John David Anglin  dave.ang...@bell.net

Bug#1043259: ArgumentCountError: Too few arguments to function (set_error_handler)

[James Valleroy]

This issue only occurs if development debugging is enabled, so most users are 
not affected.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043317: duck: Please drop "parked domain" test

[gregor herrmann]

Package: duck
Version: 0.14.2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I like duck and run it after each package build.
Unfortunately typically I get output from the wild-guess check for
some strings on websites where duck tells me that the upstream
homepage or the Debian BTS or a well-known license is a "parked
domain of for sale", and this test is almost always a false positive.

Current example, package rex:

I: debian/copyright:62: URL: https://www.apache.org/licenses/LICENSE-2.0: 
INFORMATION (Certainty:wild-guess)
   Curl:0 HTTP:200 No error 
   Website seems to be outdated, is probably a parked domain or for sale. 
Please update your links!
   Matching regular expression(s):
m/\breplaced with\b/i

I: debian/control: Homepage: https://www.rexify.org/: INFORMATION 
(Certainty:wild-guess)
   Curl:0 HTTP:200 No error 
   Website seems to be outdated, is probably a parked domain or for sale. 
Please update your links!
   Matching regular expression(s):
m/\breplace .* with\b/i

I: debian/upstream/metadata:URL: https://github.com/RexOps/Rex.git: INFORMATION 
(Certainty:wild-guess)
   Curl:0 HTTP:200 No error 
   Website seems to be outdated, is probably a parked domain or for sale. 
Please update your links!
   Matching regular expression(s):
m/\breplace .* with\b/i

I: debian/upstream/metadata:URL: https://github.com/RexOps/Rex: INFORMATION 
(Certainty:wild-guess)
   Curl:0 HTTP:200 No error 
   Website seems to be outdated, is probably a parked domain or for sale. 
Please update your links!
   Matching regular expression(s):
m/\breplace .* with\b/i


Checking for "deprecated" (on upstream websites which document
functions) or "replaced (by|with)" doesn't make any sense IMO …
Please just remove tese tests …


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmTS6ixfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgahWhAAuUO8pMaL8fa+Ev1Y4VZZHJ8ggKB3zRjmoAouYPHdhC0UGonJCCxwYT/R
nLRxe60k2cRPE+Zog6XuD888vUqvy1XKQDbdTvE+Xk11clmJVabnAnYYF6xsNe1B
trlfBP+P54xBFUMxDxu0JNEvUc9mdQ0gGf+HeNFWdIVzxXsw7ipj3C/igDMG0DeC
d7rPYbt1SuESh3sAsusxyTdp60s7vn8Hpa4mXByQcpop6l19qA32TOG1qWJdIldf
8y6PNrOubYt5rl+aZKbuxzPe5HgfO0C4wfFEtGgOXRj9LplZc2Qw9fEEDOWETCXt
XRlAr9JwZSLZcOQmw3vGCnDPVERCBdFdbOH102QVfq6Hk5xsoTk/fRFWoBMOtnEl
2V4sLGoaOuCgCCj9rgVH9ZO8noGAhPKgi0O5WSAtm2rOYGyr4YHclPr935uuz1iR
m1LIFoHQOFP6lwETFFnyo9SjegrGZ0HqE5mTLTMa43nKI7e5qrLXsBM4kScMy21x
trn+lcp6H7Ngy+41r4Lc93XoVTnhT1hlKPvtgsx2tfQ1SEEZvR6janTFEuZCM2wg
IC0RvAw9UqhRiU7lL6y40Goa8PcmPRRCMudcx486dEI0u0r5bL30vq4NB1QphMsw
PwOemyLoay01URDcI+SR50Lqz4isBD7LOO3BcU2k1YcXCZEdPJ8=
=V19B
-END PGP SIGNATURE-

Bug#1043316: git-delta is a binary in git-extras

[Carl Suster]

Source: git-delta
Version: 0.16.5-2
Severity: wishlist

Dear Maintainer,

The package git-extras provides /usr/bin/git-delta and an associated man page.
This is completely unrelated to /usr/bin/delta provided by git-delta, other
than that they both work with git. I assume that most people would be looking
for this git-delta, not the other one, which is a very minimal script.

There's no technical issue since the binaries are named differently, but the
fact that /usr/bin/git-delta and `man git-delta` are not related to git-delta
makes things slightly confusing as a user.

Perhaps it's worth a note in README.Debian or the package description? Feel
free to close this if you disagree; just thought it was worth pointing out.

Bug#1041836: libc6 2.36-9+deb12u1 double free abort

[Paul Szabo]

Maybe related: seems that the default for "mcheck" or MALLOC_CHECK_ has
changed.

I observe an oddity. I only noticed this recently, with libc6 version
2.36-9+deb12u1; reverting to previous 2.36-9 did not seem to help.

The issue. Sending SIGHUP to the inetd(8) process should cause it to
re-load its configuration, but instead it elicits

  free(): double free detected in tcache 2

and an abort. This is easiest seen (after "systemctl stop inetd") with

  root# inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs
  [1] 2431
  ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 
server=/usr/sbin/identd
  free(): double free detected in tcache 2
  [1]+  Aborted inetd -d -i
  root# 

Sanity(?) is restored by using MALLOC_CHECK_=0 (needs LD_PRELOAD):

  root# LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i & sleep 1; 
kill -HUP $!; sleep 1; jobs; kill $!; sleep 1; jobs
  [1] 2437
  ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 
server=/usr/sbin/identd
  REDO: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 
server=/usr/sbin/identd
  [1]+  Running LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 
inetd -d -i &
  [1]+  DoneLD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 
inetd -d -i
  root# 

To compound the oddity, the value of MALLOC_CHECK_ or even its presence
seems ignored, just the LD_PRELOAD=libc_malloc_debug.so "fixes" the
issue.

Hope this helps to find the cause.

Cheers, Paul


References:
http://btorpey.github.io/blog/2019/07/14/memory-checking/
https://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html


-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia

Join the Union and fight for a better University: www.nteu.au/join

Bug#1043315: linux-image-6.1.0-10-amd64: i915 kernel modesetting fails on GPD MicroPC and GPD Pocket 3

[Jamie Bainbridge]

Package: src:linux
Version: 6.1.38-2
Severity: important
X-Debbugs-Cc: jamie.bainbri...@gmail.com

Dear Maintainer,

GPD MicroPC and GPD Pocket 3 fail kernel modesetting of the Intel GPU on
Debian v6.1-based kernels. The system performs a hardware lockup and
must be forcibly powered off.

Booting with "nomodeset" works around this, however these systems require
display rotation to display normally, so it effectively makes Debian 12
unusable on this hardware. This problem does not happen with Linux v6.1
or v6.2 or v6.3 or v6.4. It's a regression in v6.1.y longterm kernel only.

This was bisected to upstream patch 0fc6fea41c71("drm/i915: Disable DC
states for all commits") which was included in v6.1.23.

This was reported to Intel graphics maintainers and a resolution has
just been found today:

https://gitlab.freedesktop.org/drm/intel/-/issues/8419

I guess that fix needs to go upstream, then into v6.1.y longterm, then
Debian can consume it as part of a regular kernel update.

This was also discussed on Debian User Forums:

https://forums.debian.net/viewtopic.php?p=777900

I was asked to log a bug on that thread, so I am logging this one.

(the system making the bug report is currently booted into my own v6.4.7
build so that I can actually use the system, however this bug affects
Debian 12's default kernel package. i can't boot into that kernel to
report the bug because the system hardlocks on KMS)

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

** Model information
sys_vendor: GPD
product_name: MicroPC
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 4.18
board_vendor: GPD
board_name: MicroPC
board_version: Default string

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Gemini Lake Host Bridge 
[8086:31f0] (rev 06)
DeviceName: Onboard - Other
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy

00:02.0 VGA compatible controller [0300]: Intel Corporation GeminiLake [UHD 
Graphics 600] [8086:3185] (rev 06) (prog-if 00 [VGA controller])
DeviceName: Onboard - Video
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:0e.0 Audio device [0403]: Intel Corporation Celeron/Pentium Silver Processor 
High Definition Audio [8086:3198] (rev 06)
DeviceName: Onboard - Sound
Subsystem: Realtek Semiconductor Co., Ltd. Celeron/Pentium Silver 
Processor High Definition Audio [10ec:]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci_intel_apl

00:0f.0 Communication controller [0780]: Intel Corporation Celeron/Pentium 
Silver Processor Trusted Execution Engine Interface [8086:319a] (rev 06)
DeviceName: Onboard - Other
Subsystem: Intel Corporation Celeron/Pentium Silver Processor Trusted 
Execution Engine Interface [8086:7270]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:12.0 SATA controller [0106]: Intel Corporation Celeron/Pentium Silver 
Processor SATA Controller [8086:31e3] (rev 06) (prog-if 01 [AHCI 1.0])
DeviceName: Onboard - SATA
Subsystem: Intel Corporation Celeron/Pentium Silver Processor SATA 
Controller [8086:7270]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:13.0 PCI bridge [0604]: Intel Corporation Gemini Lake PCI Express Root Port 
[8086:31d8] (rev f6) (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Gemini Lake PCI Express Root Port 
[8086:7270]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:13.2 PCI bridge [0604]: Intel Corporation Gemini Lake PCI Express Root Port 
[8086:31da] (rev 

Bug#1043314: libnftnl: please disable documentation build when not building -doc package

[Simon McVittie]

Source: libnftnl
Version: 1.2.6-1
Severity: wishlist
Tags: patch

Similar to libnetfilter-conntrack, libnftnl only needs graphviz
(and doxygen) for its API documentation, so an easy way to reduce
dependency chains would be for libnetfilter-conntrack to only build its
API documentation when "Architecture: all" packages are being built.

Please consider the attached patch, with the "Closes" line amended to
mention this bug report's bug number. I used diffoscope to confirm that
this change does not alter the contents of either the _amd64 or _all
binary packages.

Thanks,
smcv
>From fbd556ab0eabfab4acd7bd143949fea65481c6ea Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 8 Aug 2023 23:48:14 +0100
Subject: [PATCH] d/control, d/rules: Only build API documentation if we need
 it

When only building the architecture-specific packages, as the buildds do,
we won't produce the -doc package and therefore we don't need to run
doxygen. We can also skip the -doc package under the nodoc build profile.

Closes: #-1
---
 debian/control | 5 +++--
 debian/rules   | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 6c9bfdb..a03b0cd 100644
--- a/debian/control
+++ b/debian/control
@@ -4,11 +4,11 @@ Maintainer: Debian Netfilter Packaging Team ,
Jeremy Sowden 
 Build-Depends: debhelper-compat (= 13),
-   doxygen,
-   graphviz,
libmnl-dev,
libtool,
pkg-config
+Build-Depends-Indep: doxygen ,
+ graphviz 
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
 Section: libs
@@ -45,6 +45,7 @@ Description: Development files for libnftnl
  This package provides development files and static libraries.
 
 Package: libnftnl-dev-doc
+Build-Profiles: 
 Section: doc
 Architecture: all
 Multi-Arch: foreign
diff --git a/debian/rules b/debian/rules
index 090055f..144d90c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,7 @@ include /usr/share/dpkg/buildflags.mk
 override_dh_auto_configure:	
 	dh_auto_configure --  --enable-static
 
-override_dh_auto_build:
-	dh_auto_build
+ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
+execute_after_dh_auto_build-indep:
 	doxygen doxygen.cfg
+endif
-- 
2.40.1

Bug#1043299: xterm: build with ReGIS support

[Thomas Dickey]

On Tue, Aug 08, 2023 at 02:33:10PM -0400, Benjamin Barenblat wrote:
> Package: xterm
> Version: 384-1
> Severity: wishlist
> 
> Xterm supports ReGIS (DEC vector graphics) emulation, but it’s not
> compiled in by default. Would you be willing to add
> `--enable-regis-graphics` to the `configure` invocation in debian/rules?

INSTALL says:

  --enable-regis-graphics enable support for ReGIS graphics

Compile-in code to support experimental ReGIS graphics

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1043313: libsuperlu-dev: Inconsistent declaration of double{C,M}alloc()

[Adrian Bunk]

Package: libsuperlu-dev
Version: 6.0.0+dfsg1-2
Severity: serious
Tags: ftbfs
Forwarded: https://github.com/xiaoyeli/superlu/pull/100
Control: affects -1 src:freefem++

https://buildd.debian.org/status/logs.php?pkg=freefem%2B%2B=4.13%2Bdfsg-1%2Bb2

...
In file included from SuperLu.cpp:32:
/usr/include/superlu/slu_zdefs.h:239:17: error: conflicting declaration of C 
function ‘double* doubleMalloc(int)’
  239 | extern double  *doubleMalloc(int);
  | ^~~~
In file included from SuperLu.cpp:29:
/usr/include/superlu/slu_ddefs.h:236:17: note: previous declaration ‘double* 
doubleMalloc(size_t)’
  236 | extern double  *doubleMalloc(size_t);
  | ^~~~
/usr/include/superlu/slu_zdefs.h:240:17: error: conflicting declaration of C 
function ‘double* doubleCalloc(int)’
  240 | extern double  *doubleCalloc(int);
  | ^~~~
/usr/include/superlu/slu_ddefs.h:237:17: note: previous declaration ‘double* 
doubleCalloc(size_t)’
  237 | extern double  *doubleCalloc(size_t);
  | ^~~~
make[6]: *** [Makefile:901: SuperLu.so] Error 1

Bug#1043298: Package dependenciens mishmash

[Guillem Jover]

Control: tag -1 moreinfo unreproducible

Hi!

On Tue, 2023-08-08 at 18:28:57 +, Mcgiwer wrote:
> Package: dpkg
> Version: 1.21.22 (amd64)

> There seem to be problem with the packages dependencies.

If there is a problem with package dependencies, then that should
probably be assigned to the specific package involved.

> While attempting to upgrade while having other then only default
> repositories included (there is no error about package duplicates),
> I had recivied following dependency issue:
> 
> By some packages, dpkg (thru aptitude) requires that the package
> from with it's dependant has in the same time the version is:
> smaller, equal, bigger and equal, with is mutually exclusive.

I do not recognize this message, so I'm not even sure what this report
is about, what packages are involved, or what the actual error is. Or
even whether this is really a problem in dpkg or a problem at all.

> System: Debian (bookworm)

> Please fix it asap.

Hard to do anything with this with the information given, to be
honest. As is, this report is not actionable.

Thanks,
Guillem

Bug#1043312: vg: Replace transitional bsdmainutils

[Bastian Germann]

Source: vg
Version: 1.30.0+ds-1
Severity: minor

Please replace the Build-Dependency bsdmainutils with bsdextrautils, which 
holds hexdump and column.
bsdmainutils is a transitional package and should be removed.

Bug#1040447: odbc-mariadb cannot set up odcb-mariadb

[John Covici]

Did you have anything in your /etc/odbc.ini  or odbcinst.ini ?

On Tue, 08 Aug 2023 18:03:05 -0400,
Bernhard Schmidt wrote:
> 
> Control: severity -1 important
> Control: tags -1 unreproducible
> 
> Same as Tuukka I cannot reproduce this. 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Bug#1043311: rustc: please enable profiler builtin

[Andres Salomon]

Package: src:rustc
Version: 1.66.0+dfsg1-1
Severity: wishlist

Chromium's new rust build requirements include the need for 
/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libprofiler_builtins-*.rlib. 
It would be really helpful to have this built into Debian's rust 
packages.


Ubuntu apparently enabled it, and you can see their patch here:


However, that didn't work for me, at least not with the default of 
BUILD_WINDOWS=true in rustc's current debian/rules. The build involving 
--target $(WINDOWS_ARCH)-pc-windows-gnu  requires 
libclang-rt-15-dev-wasm64 and some extra logic. I'm currently working 
on an updated patch now.

Bug#1043309: curl: ‐‐connect‐timeout is weirdly broken

[FC Stegerman]

* Daniel Stenberg  [2023-08-08 23:39]:
> On Tue, 8 Aug 2023, FC Stegerman wrote:
> 
> > $ curl ‐‐connect‐timeout
> > curl: (6) Could not resolve host: xn--connecttimeout-462hah
> > 
> > $ curl ‐‐connect‐timeout 2 -I example.com
> > curl: (6) Could not resolve host: xn--connecttimeout-462hah
> 
> Those dashes in there are not ascii minuses, they are unicode e2 80 90 (when
> copied from the web page for this report), also known as Unicode Character
> 'HYPHEN' (U+2010).
> 
> Since they are not ascii minus (ascii byte code 45), they do not specify the
> command line option --connect-timeout but that sequence of characters is
> instead treaded as a "URL", which is converted from its unicode into
> punycode before resolved.
> 
> And on and on. This is not the bug it is made out to be.

You are absolutely correct.  And it makes sense now.

That does leave a bug of sorts in the curl man page, which is where I
copied that from.  Looking at curl.1 I see:

.IP "\-\-connect-timeout "
[...]
Examples:
.nf
 curl --connect-timeout 20 https://example.com
 curl --connect-timeout 3.14 https://example.com
.fi

It seems that the unescaped dashes become U+2010.  I was not expecting
that, hence my not realising what was going on.  Sorry about that.

- FC

Bug#1040447: odbc-mariadb cannot set up odcb-mariadb

[Bernhard Schmidt]

Control: severity -1 important
Control: tags -1 unreproducible

Same as Tuukka I cannot reproduce this. 

Bug#1043310: RM: longrun -- RoQA; low popcon; targets i586 CPU

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:longrun

Please remove longrun. The package has a very low popcon which is to be expected as there should be 
no hardware that current Debian can run this on. Transmeta Crusoe is a i586 platform. The last 
maintainer upload was more than 14 years ago.

Bug#1043138: thunderbird: cannot send OpenPGP signed message: rnp_op_sign_add_signature failed since upgrade to 115.1.0 (sid)

[Alexis Murzeau]

Hi,

On Mon, 7 Aug 2023 16:45:32 -0400 Jamie McClelland  wrote:

On 8/7/23 11:46, Carsten Schoenert wrote:
> Hello Jamie,
> 
> I can't reproduce this issue.


Thank you for the support and sorry to waste your time.

I think the problem is that I didn't have a Primary password set. I set 
a primary password, then re-imported my secret key and now it seems to work.


jamie




I was reproducing the exact issue (same error and same RNP function).

I'm using a primary key without its private key and 2 subkeys with their 
private keys:


| Key Part| Usage |
| --- | - |
| (!) primary key | Sign, Certify |
| subkey  | Encrypt   |
| subkey  | Sign  |
For keys marked with (!) the secret key is not available.


I've tried to use a fresh thunderbird profile and re-import my GPG key 
and sending signed messages is working again.

So I guess something was bad in the thunderbird profile.


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


OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043309: curl: ‐‐connect‐timeout is weirdly broken

[Daniel Stenberg]

On Tue, 8 Aug 2023, FC Stegerman wrote:


$ curl ‐‐connect‐timeout
curl: (6) Could not resolve host: xn--connecttimeout-462hah

$ curl ‐‐connect‐timeout 2 -I example.com
curl: (6) Could not resolve host: xn--connecttimeout-462hah


Those dashes in there are not ascii minuses, they are unicode e2 80 90 (when 
copied from the web page for this report), also known as Unicode Character 
'HYPHEN' (U+2010).


Since they are not ascii minus (ascii byte code 45), they do not specify the 
command line option --connect-timeout but that sequence of characters is 
instead treaded as a "URL", which is converted from its unicode into punycode 
before resolved.


And on and on. This is not the bug it is made out to be.

--

 / daniel.haxx.se

Bug#1042065: ltrace: [p]{read,write}[v]() handling, common *64() functions in modern glibc, [fl]seek[o]()/ftell[o](); requisite [u]llong; 20x speed optimisation in default config; format %b+bin() lens

[наб]

Control: retitle -1 ltrace: [p]{read,write}[v]() handling, common *64() 
functions in modern glibc, [fl]seek[o]()/ftell[o](); requisite [u]llong; 20x 
speed optimisation in default config; format %b+bin() lens and %w[f]32x; 
splice/c_f_r/sendfile[64] formatting; useful __errno_location; %config lines 
not limited to 1kB; pipe[2]() with fds; sysconf(); %m[un]map[64](); operator 
new/delete; ; another ~10%; %*locale(); time.h functions; strto*l(); 
qsort_r()

For demo see https://github.com/neomutt/neomutt/pull/3963
From: =?utf-8?b?0L3QsNCx?= 
Date: Tue, 8 Aug 2023 19:52:01 +0200
Subject: *locale(); time.h functions; strto*l(); qsort_r()

---
 etc/ltrace.conf | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/etc/ltrace.conf b/etc/ltrace.conf
index bd9a111..4ffb725 100644
--- a/etc/ltrace.conf
+++ b/etc/ltrace.conf
@@ -91,6 +91,10 @@ int _IO_putc(char,file);
 
 ; locale.h
 string setlocale(enum(LC_CTYPE=0, LC_NUMERIC=1, LC_TIME=2, LC_COLLATE=3, LC_MONETARY=4, LC_MESSAGES=5, LC_ALL=6, LC_PAPER=7, LC_NAME=8, LC_ADDRESS=9, LC_TELEPHONE=10, LC_MEASUREMENT=11, LC_IDENTIFICATION=12), string);
+addr duplocale(addr);
+addr uselocale(addr);
+addr newlocale(bin(int),string,addr);
+void freelocale(addr);
 
 ; mcheck.h
 void mtrace();
@@ -229,7 +233,13 @@ int rename(string,string);
 
 ; stdlib.h
 long __strtol_internal(string,addr,int);
+llong __strtoll_internal(string,addr,int);
 ulong __strtoul_internal(string,addr,int);
+ullong __strtoull_internal(string,addr,int);
+long strtol(string,+string*,int);
+llong strtoll(string,+string*,int);
+ulong strtoul(string,+string*,int);
+ullong strtoull(string,+string*,int);
 int atexit(addr);
 addr bsearch(string, addr, ulong, ulong, addr);
 addr calloc(ulong, ulong);
@@ -241,7 +251,8 @@ int setenv(string,string,int);
 void unsetenv(string);
 addr malloc(ulong);
 void qsort(addr,ulong,ulong,addr);
-int random();
+void qsort_r(addr,ulong,ulong,addr,addr);
+long random();
 addr realloc(addr,ulong);
 addr reallocarray(addr,ulong,ulong);
 void srandom(uint);
@@ -313,12 +324,17 @@ int tcgetattr(int,addr);
 int tcsetattr(int,int,addr);
 
 ; time.h
+typedef tm = struct(int,int,int,int,int,int,int,int,int,long,string);
 string ctime(addr);
 int gettimeofday(addr, addr);
-addr gmtime(addr);
-addr localtime(addr);
-ulong strftime(+string2,ulong,string,addr);
-long time(addr);
+tm* gmtime(llong*);
+tm* localtime(llong*);
+tm* gmtime_r(llong*,addr);
+tm* localtime_r(llong*,addr);
+ulong strftime(+string2,ulong,string,tm*);
+ulong strftime_l(+string2,ulong,string,tm*,addr);
+llong time(addr);
+llong mktime(tm*);
 
 ; unistd.h
 void _exit(int);


signature.asc
Description: PGP signature

Bug#1043309: curl: ‐‐connect‐timeout is weirdly broken

[FC Stegerman]

Package: curl
Version: 8.2.1-1
Severity: normal
X-Debbugs-Cc: f...@obfusk.net

Hi!

Something seems to be going wrong here:

$ curl ‐‐connect‐timeout
curl: (6) Could not resolve host: xn--connecttimeout-462hah

$ curl ‐‐connect‐timeout 2 -I example.com
curl: (6) Could not resolve host: xn--connecttimeout-462hah
[hangs]

- FC

Bug#1042362: RFS: streamlink/6.0.1-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

On 08/08/2023 20:18, Alexis Murzeau wrote:

[...]
Changes since the last upload to unstable:


Just a note that I've updated the package to remove rtmpdmp which is no more 
needed as upstream (Sebastian Meyer) just told me.

The updated changelog since the last upload to unstable is:
streamlink (6.0.1-1) unstable; urgency=medium

  * New upstream version 6.0.1
  * d/upstream/signing-key.asc: update upstream key
  * d/patches: update patches
  * d/control: add new dependency python3-pytest-trio
  * d/rules: streamlink manpage: use CW font instead of C
  * d/rules: remove unused inclusion of pkg-info.mk
  * d/rules: fix duplicate doc assets
  * d/control: remove unused dependency on rtmpdump
  * Upload to unstable

 -- Alexis Murzeau   Tue, 08 Aug 2023 22:34:59 +0200

streamlink (5.5.1-1~exp1) experimental; urgency=medium

  * New upstream version 5.5.1
  * d/patches: update patches
  * d/patches,control: use furo theme instead of sphinx-rtd-theme
  * d/patches,control: use fork-awesome as a replacement for font-awesome
  * d/s/lintian-overrides: remove obsolete override about a test file

 -- Alexis Murzeau   Sat, 20 May 2023 19:52:43 +0200


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

Bug#1043308: libc6-dev-mips64el-cross: Unmatched libc6 verison in mips64el unstable release

[Haorong Lu]

Package: libc6-dev-mips64el-cross
Version: 2.36-8cross2
Severity: important

Dear Maintainer,

I'm trying to build a cross-compiling environment for mips64el on my x86
VM. The
Dockerfile is in this form:

```
FROM dockcross/base:latest

ENV ARCH=mips
ENV SUBARCH=mips
ENV DEBIAN_ARCH=mips64el
ENV CROSS_TRIPLET=mips64el-linux-gnuabi64

# Add the cross compiler sources
RUN echo "deb http://deb.debian.org/debian/ unstable main" >>
/etc/apt/sources.list && \
  dpkg --add-architecture ${DEBIAN_ARCH}

RUN apt-install \
crossbuild-essential-${DEBIAN_ARCH} \
libc6-dev-${DEBIAN_ARCH}-cross  \
libc6-${DEBIAN_ARCH}-cross  \
libbz2-dev:${DEBIAN_ARCH}   \
libexpat1-dev:${DEBIAN_ARCH}\
ncurses-dev:${DEBIAN_ARCH}  \
libssl-dev:${DEBIAN_ARCH}   \
protobuf-c-compiler \
protobuf-compiler   \
python3-protobuf\
libnl-3-dev:${DEBIAN_ARCH}  \
libprotobuf-dev:${DEBIAN_ARCH}  \
libnet-dev:${DEBIAN_ARCH}   \
libprotobuf-c-dev:${DEBIAN_ARCH}\
libcap-dev:${DEBIAN_ARCH}   \
libaio-dev:${DEBIAN_ARCH}   \
libnl-route-3-dev:${DEBIAN_ARCH}

# Compile my stuff...
```

The error message received is:
libc6-dev:mips64el : Breaks: libc6-dev-mips64el-cross (< 2.37~) but
2.36-8cross2 is to be installed

IMHO, The root of the problem is that while libc6-dev:mips64el has been
updated to
version 2.37-7 in the unstable release, the libc6-dev-mips64el-cross
remains at
version 2.36-8cross2 in both stable and unstable releases, leading to
dependency
issue. Notably, most other architectures have updated their unstable
versions of
lib6-dev-${arch}-cross to 2.37-3cross1, such as arm64, armhf, s390x, and so
on.

Is it possible to upgrade lib6-dev-mips64el-cross to a new version, or
change the
dep requirements of lib6-dev:mips64el in unstable release? Thanks a lot :)

Bug#1043307: mshr: FTBFS in sid

[Andreas Hasenack]

Package: mshr
Version: 2019.2.0~git20200924.c27eb18+dfsg1-8
Severity: important

Dear Maintainer,

mshr is failing to build in sid:

In file included from /usr/include/boost/mpl/aux_/has_begin.hpp:17,
 from /usr/include/boost/mpl/aux_/begin_end_impl.hpp:21,
 from /usr/include/boost/mpl/begin_end.hpp:18,
 from /usr/include/boost/mpl/iter_fold.hpp:18,
 from /usr/include/boost/variant/detail/initializer.hpp:28,
 from /usr/include/boost/variant/variant.hpp:30,
 from /usr/include/boost/variant.hpp:17,
 from /usr/include/dolfin/parameter/Parameters.h:25,
 from /usr/include/dolfin/common/Variable.h:28,
 from /home/ubuntu/deb/mshr/mshr/include/mshr/CSGGeometry.h:29,
 from /home/ubuntu/deb/mshr/mshr/include/mshr/CSGPrimitive.h:23,
 from
/home/ubuntu/deb/mshr/mshr/include/mshr/CSGPrimitives3D.h:23,
 from
/home/ubuntu/deb/mshr/mshr/include/mshr/CSGCGALDomain3D.h:21,
 from
/home/ubuntu/deb/mshr/mshr/include/mshr/CSGCGALMeshGenerator3D.h:21,
 from
/home/ubuntu/deb/mshr/mshr/src/CSGCGALMeshGenerator3D.cpp:19:
/usr/include/CGAL/STL_Extension/internal/Has_features.h:24:3: note:
‘CGAL::internal::has_Has_features’ declared here
   24 |   BOOST_MPL_HAS_XXX_TRAIT_DEF(Has_features)
  |   ^~~
/home/ubuntu/deb/mshr/mshr/src/make_multicomponent_mesh_3.h:44:29:
error: ‘has_Has_features’ is not a member of ‘CGAL::Mesh_3::internal’;
did you mean ‘CGAL::internal::has_Has_features’?
   44 | CGAL::Mesh_3::internal::has_Has_features::value
> () (c3t3,
  | ^~~~
/usr/include/CGAL/STL_Extension/internal/Has_features.h:24:3: note:
‘CGAL::internal::has_Has_features’ declared here
   24 |   BOOST_MPL_HAS_XXX_TRAIT_DEF(Has_features)
  |   ^~~
/home/ubuntu/deb/mshr/mshr/src/make_multicomponent_mesh_3.h:44:56:
error: template argument 4 is invalid
   44 | CGAL::Mesh_3::internal::has_Has_features::value
> () (c3t3,
  |^
/home/ubuntu/deb/mshr/mshr/src/make_multicomponent_mesh_3.h:44:65:
error: qualified-id in declaration before ‘>’ token
   44 | CGAL::Mesh_3::internal::has_Has_features::value
> () (c3t3,
  | ^
/home/ubuntu/deb/mshr/mshr/src/CSGCGALMeshGenerator3D.cpp: In member
function ‘void mshr::CSGCGALMeshGenerator3D::generate(std::shared_ptr, dolfin::Mesh&) const’:
/home/ubuntu/deb/mshr/mshr/src/CSGCGALMeshGenerator3D.cpp:333:44:
error: no matching function for call to
‘make_multicomponent_mesh_3_impl(C3t3&, PolyhedralMeshDomain&,
CGAL::Mesh_criteria_3
>, 
>CGAL::Mesh_triangulation_3
>::Tds> >&, 
>CGAL::Named_function_parameters,
CGAL::Named_function_parameters,
CGAL::Named_function_parameters,
CGAL::Named_function_parameters, bool)’
  333 |   make_multicomponent_mesh_3_impl(c3t3,
  |   ~^~
  334 | domain,
  | ~~~
  335 | *criteria,
  | ~~
  336 |
CGAL::parameters::no_exude(),
  |
~
  337 |
CGAL::parameters::no_perturb(),
  |
~~~
  338 | CGAL::parameters::no_odt(),
  | ~~~
  339 |
CGAL::parameters::no_lloyd(),
  |
~
  340 | true);
  | ~
/home/ubuntu/deb/mshr/mshr/src/make_multicomponent_mesh_3.h:26:6:
note: candidate: ‘template void make_multicomponent_mesh_3_impl(C3T3&, const
MeshDomain&, const MeshCriteria&, const
CGAL::parameters::internal::Exude_options&, const
CGAL::parameters::internal::Perturb_options&, const
CGAL::parameters::internal::Odt_options&, const
CGAL::parameters::internal::Lloyd_options&, bool, const
CGAL::parameters::internal::Mesh_3_options&)’
   26 | void make_multicomponent_mesh_3_impl(C3T3& c3t3,
  |  ^~~
/home/ubuntu/deb/mshr/mshr/src/make_multicomponent_mesh_3.h:26:6:
note:   template argument deduction/substitution failed:
/home/ubuntu/deb/mshr/mshr/src/CSGCGALMeshGenerator3D.cpp:336:71:
note:   cannot convert ‘CGAL::parameters::no_exude()’ (type
‘CGAL::Named_function_parameters’) to type ‘const
CGAL::parameters::internal::Exude_options&’
  336 |
CGAL::parameters::no_exude(),
  | ~~^~
make[4]: *** [CMakeFiles/mshr.dir/build.make:135:
CMakeFiles/mshr.dir/src/CSGCGALMeshGenerator3D.cpp.o] Error 1
make[4]: 

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hi Nicholas,
MR filed:
https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2

>Does that link really work?  Are you sure it's not this one?

I have no idea what automagically happened, somehow the first one
worked for me, but now does not. :) Using yours (thanks!).

>The copyright info you've written in this version is immensely
>improved :)
Thanks, it was your patience and help that got me here too :D

>Oh man, yeah, hello early days of the internet!  All you need now is
>some MIDI files and GIFs.
 Haha, your paragraph makes me want to reinstall DOOM/Starcraft for the
nth time now :)

>3. Please note which version of NCSA httpd matches mini-httpd.
After much diff'ing and vim'ing and staring at #ifdefs and trying to
separate Jef's unversioned changes to htpasswd.c from actual NCSA
updates: 
It's 99.999% 1.4.2. I noted that in debian/copyright.

I hope everything is in order with my MR.

Have a great day and may the Debian swirl girate eternally !
Alexandru Mihail



> 
> 
> > Portions of htpasswd* were edited by Jef Poskanzer, thus these
> > files
> > remain under BSD-2-clause.
> 
> The copyright info you've written in this version is immensely
> improved :)
> 
> 2. Beyond this, you'll need to add a on every blank line that
> 
>  .
> 
> so that the paragraphs in the "Comment" field of the "Files:
> htpasswd.c
> htpasswd.1" aren't split by an empty newline; they need to remain
> part
> of the same field.  Nagivate to /usr/share/doc/*/copyright for many
> examples.
> 
> > NCSA License:
> > This code is in the public domain. Specifically, we give to the
> > public
> > domain all rights for future licensing of the source code, all
> > resale
> > rights, and all publishing rights.
>   .
> > We ask, but do not require, that the following message be included
> > in
> > all derived works:
>   .
> > Portions developed at the National Center for Supercomputing
> > Applications at the University of Illinois at Urbana-Champaign.
>   .
> > THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
> > FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
> > LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR
> > A
> > PARTICULAR PURPOSE.
> 
>  /\ It will look something like that (note the new indented periods)
> 
> >  debian-legal thread:
> > https://lists.debian.org/debian-legal/2023/07/msg1.html
> > 
> > ---
> > 
> > Nicholas, I've finally found an "original" copy 
> > of the httpd 1.5.2 src !! (Mentioned in the text above, it's the
> > very
> > long WaybackMachine link).
> 
> You have exceptional research skills.
> 
> > After diff'ing the github copy and the
> > original .tar.Z (also, haven't seen that format in years), they
> > seem to
> > match! Thus, I can confirm the github copy is accurate (previously,
> > we
> > had no authoritative way to trust the github repo).
> 
> Oh man, yeah, hello early days of the internet!  All you need now is
> some MIDI files and GIFs.
> 
> 3. Please note which version of NCSA httpd matches mini-httpd.
> 
> > > I'm still not certain that this wiki contributor's position is
> > > legally
> > > sound everywhere in the world.  For a counter example see:
> > > 
> > https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe
> > 
> > I've read the link and I share your concerns. I'm a bit lost
> > here..maybe another question to legal is the right choice ?
> 
> While I'm not a lawyer, I believe that the approach we're going with
> is
> more legally defensible around the world than the aspirational public
> domain one.  BSD-2-clause is also better understood than NCSA as far
> as
> I know. I'm relieved that work this didn't end up being a pulp novel
> situation where someone stumbles onto a dirty rotten secret at the
> heart
> of the origins of the internet while untangling the roots of a
> project
> like this one.  
> 
> As an aside, the last release that Robert McCool worked on was v1.3,
> and
> then he left in 1994 [1].
> 
> > Thanks for your time and may you have a great day,
> 
> You're welcome, you too!  Send me that merge request when you have
> time.
> 
> 
> Cheers,
> Nicholas
> 
> [1]
> https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html



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

Bug#967642: mp3info: depends on deprecated GTK 2

[Bastian Germann]

Hi Hugo,

I suggest to remove mp3info-gtk. What do you think?

Cheers,
Bastian

Bug#1041731: groff-base: Tough bug to find

[Jesse Hathaway]

Package: groff-base
Version: 1.23.0-2
Followup-For: Bug #1041731
X-Debbugs-Cc: je...@mbuki-mvuki.org

Thanks for maintaining groff-base,

I spent a half hour debugging why the example command in podman-images
would not work and then another half hour debugging why my man pages
were suddenly displaying U+2010 rather than U+002D. I sympathize with
the desire for accurate typography, but the manner in which this change
was introduced hurts users like myself. Please consider patching
Debian's copy and investigating another why to encourage man page
authors and tooling to use the correct hyphen.

Bug#1042842: network interface names wrong in domU (>10 interfaces)

[zithro]

On 08 Aug 2023 16:59, Hans van Kranenburg wrote:

I didn't read the other mailthread on the xen list fully yet.


You gave me the idea to post the IRC digest, so the report here is more 
complete, and people not tracking the xen-devel ML can read it nicely.
For those who do, the mail is dated "02 Aug 2023 18:19", and titled 
"Network interfaces naming changes in domUs with >10 vifs (Debian bug 
1042842)".

The ML post got no answer yet.

[--- IRC ---]
- AFAIK, there is no sorting in Xenstored. And you should not expect 
that even if libxl sorted properly it will be seen in the same order on 
the other end.
- is the ethN number in domU related to vif number in xenstore, or to 
device detection order?
- there's no order to eth names at all. they're allocated 
first-come-first-serve, so it entirely depends on how parallel the 
probing of nic drivers are. even if netfront is serialised around 
xenstore accesses, it probably allocates in the order that XS_DIRECTORY 
comes back with
- from simple tests, it looks like VIFs are created in Xenstore in the 
order of the config file, but if you "xenstore-ls /[...]/vif", you can 
see vifs are ordered like vif1,vif10,vif11,vif2,etc
- the order is different between Xen 4.14 and 4.17 (ie. the "expected" 
order works on 4.14, not 4.17)
- But really, Debian should have never relied on how the nodes are 
ordered. This is not something we guarantee in the Xenstored API
- the last big batch of XSA content for the xenstoreds did some major 
rearranging of oxenstored. We dropped a NIH second garbage collector, 
and a NIH weakref system IIRC. I could entirely believe that the 
apparent sort order changed as a result
- generally, I think Linux world established quite some time ago that 
ethN names are not stable
- It's definitely a complicated issue.  Perhaps best to post to 
xen-devel so we can have a discussion. I expect the answer is not-a-Xen 
bug, but I don't think we have a clear understanding of the problem yet

[--- /IRC ---]

I'll report back when having tested the 111 vifs domU ... if my system 
agrees o_O
As it requires a script to populate the cfg, one could also enhance it 
to try how dynamically adding/removing vifs is handled.


(BTW, before this report I thought Xen had a hard limit of 8 vifs per 
domU. Or was that only on FreeBSD domUs ? Can't remember).

Bug#1043306: mp3info: Includes Windows binaries

[Bastian Germann]

Source: mp3info
Version: 0.8.5a-5
Severity: serious

Please repack to exclude the win32 binaries which cannot be checked easily to 
be DFSG-free.

Bug#1012864: graphviz: new upstream version 7.0.0 is available

[GCS]

Hi,

On Tue, Aug 8, 2023 at 6:30 PM Benjamin Redelings
 wrote:
> I tried running the following command, and it looks like there's an issue 
> where libtool has just recently removed a "Provides: libltdl7-dev" from 
> libtldl-dev.
[...]
> I was able to get around this problem by downgrading libltdl-dev and libltdl7 
> from 2.4.7-7 to 2.4.7-5, but then I got some errors about usr/bin/smyrna 
> being missing.
 These are addressed in the upcoming 8.1.0 [1] update. Please note
it's not yet finished, still addresses the above, contains upstream
recommendations and a huge package split.

> Perhaps an upload to experimental could be done?  Then people could use that 
> while you are getting advice from upstream on packaging 8.1.
 Indeed, that's the plan. I need some days for further testing.

Regards,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/graphviz_8.1.0-1.dsc

Bug#1043245: libdbus-c++-ecore-1-0/experimental: undeclared file conflict with libdbus-c++-1-0v5/unsable

[Thomas Uhle]

Hello Helmut,

you are right.  This has happened because with my upload to Debian Mentors 
I was assuming the next release would be 0.9.0-12~exp1, but Bastian had 
already uploaded the new release 0.9.0-12 and so had to pick a newer 
release number for my changes.  That means that the version number 
0.9.0-12~ in the Breaks and Replaces statements is simply wrong and needs 
to be adapted.  I am going to upload a new version with another update 
next week and can fix this issue as well.


Cheers,

Thomas

Bug#1043304: Latest Debian 12 AMI will not allocate a public IP at creation time

[Tom Boutell]

Package: cloud.debian.org
Version: ami-06885bf4009501fc0 (aka debian-12-amd64-20230723-1450)

I created an EC2 instance in us-east-1 using the command line below. The
instance does not have a public IP, although I requested one. It is not
possible to add a public IP after creation time, except for elastic IPs,
which carry additional cost.

When I try the same command with a CentOS 7 or Ubuntu 22.04 AMI, a public
IP is allocated as expected.

Command line:

aws ec2 run-instances  --image-id ami-06885bf4009501fc0 --count 1
--instance-type t2.micro --key-name MY-KEY-NAME-HERE
--associate-public-ip-address

Note that with the other AMIs "--associate-public-ip-address" is not
actually required. I have tried both with and without this option.

Here is the output of describe-instances:

{
"Groups": [],
"Instances": [
{
"AmiLaunchIndex": 0,
"ImageId": "ami-06885bf4009501fc0",
"InstanceId": "i-0dfddb45f03aa386e",
"InstanceType": "t2.micro",
"KeyName": "a3-demo-tinytest",
"LaunchTime": "2023-08-08T18:09:26+00:00",
"Monitoring": {
"State": "disabled"
},
"Placement": {
"AvailabilityZone": "us-east-1d",
"GroupName": "",
"Tenancy": "default"
},
"PrivateDnsName": "ip-172-31-92-173.ec2.internal",
"PrivateIpAddress": "172.31.92.173",
"ProductCodes": [],
"PublicDnsName": "",
"State": {
"Code": 0,
"Name": "pending"
},
"StateTransitionReason": "",
"SubnetId": "subnet-498eab67",
"VpcId": "vpc-945a30ee",
"Architecture": "x86_64",
"BlockDeviceMappings": [],
"ClientToken": "e8ef92dc-264b-4730-89bc-19570b8901d1",
"EbsOptimized": false,
"EnaSupport": true,
"Hypervisor": "xen",
"NetworkInterfaces": [
{
"Attachment": {
"AttachTime": "2023-08-08T18:09:26+00:00",
"AttachmentId": "eni-attach-032a657d6e940bf25",
"DeleteOnTermination": true,
"DeviceIndex": 0,
"Status": "attaching",
"NetworkCardIndex": 0
},
"Description": "",
"Groups": [
{
"GroupName": "default",
"GroupId": "sg-66c1293b"
}
],
"Ipv6Addresses": [],
"MacAddress": "12:5c:0d:9d:e9:a9",
"NetworkInterfaceId": "eni-0cdd6f909afc4ceb0",
"OwnerId": "108378846686",
"PrivateDnsName": "ip-172-31-92-173.ec2.internal",
"PrivateIpAddress": "172.31.92.173",
"PrivateIpAddresses": [
{
"Primary": true,
"PrivateDnsName":
"ip-172-31-92-173.ec2.internal",
"PrivateIpAddress": "172.31.92.173"
}
],
"SourceDestCheck": true,
"Status": "in-use",
"SubnetId": "subnet-498eab67",
"VpcId": "vpc-945a30ee",
"InterfaceType": "interface"
}
],
"RootDeviceName": "/dev/xvda",
"RootDeviceType": "ebs",
"SecurityGroups": [
{
"GroupName": "default",
"GroupId": "sg-66c1293b"
}
],
"SourceDestCheck": true,
"StateReason": {
"Code": "pending",
"Message": "pending"
},
"VirtualizationType": "hvm",
"CpuOptions": {
"CoreCount": 1,
"ThreadsPerCore": 1
},
"CapacityReservationSpecification": {
"CapacityReservationPreference": "open"
},
"MetadataOptions": {
"State": "pending",
"HttpTokens": "optional",
"HttpPutResponseHopLimit": 1,
"HttpEndpoint": "enabled",
"HttpProtocolIpv6": "disabled",
"InstanceMetadataTags": "disabled"
},
"EnclaveOptions": {
"Enabled": false
},
"PrivateDnsNameOptions": {
"HostnameType": "ip-name",
"EnableResourceNameDnsARecord": false,
"EnableResourceNameDnsRecord": false
},
"MaintenanceOptions": {
"AutoRecovery": "default"
},

Bug#1043305: intel-microcode: CVE-2022-40982 CVE-2022-41804 CVE-2023-23908

[Salvatore Bonaccorso]

Source: intel-microcode
Version: 3.20230512.1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20220510.1~deb11u1
Control: found -1 3.20230214.1~deb11u1

Hi,

The following vulnerabilities were published for intel-microcode.

CVE-2022-40982[0], CVE-2022-41804[1] and CVE-2023-23908[2].


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-40982
https://www.cve.org/CVERecord?id=CVE-2022-40982

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00828.html
[1] https://security-tracker.debian.org/tracker/CVE-2022-41804
https://www.cve.org/CVERecord?id=CVE-2022-41804

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00837.html
[2] https://security-tracker.debian.org/tracker/CVE-2023-23908
https://www.cve.org/CVERecord?id=CVE-2023-23908

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00836.html
[3] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20230808

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1038155: [Pkg-zfsonlinux-devel] Bug#1038155: Bug#1038155: zfs-linux: Provide a package based on OpenZFS master branch (a.k.a. 2.1.99)

[Colm Buckley]

I *really* don't think we should be pushing RC versions of ZFS (or any
other project) to the mainline Debian distributions. Using a kernel from
"unstable" has always been risky, and in this case one of the risks is that
ZFS will not work.

Maintainer bandwidth is a limited resource, and I would vastly prefer that
time be spent on ensuring the stability and reliability of the "stable"
release, with the second priority being a reasonable set of updates being
available in "backports".

Zhou and the gang do a great job in keeping things up to date; I wouldn't
view it as their responsibility to deal with breakages in unstable, unless
there's some other compelling reason.

My personal preference, assuming maintainer time is available, would be to
continue to offer 2.1.X in stable, and 2.2.X in backports when 2.2.0 is
released (as opposed to being RC).

Colm


On Tue, 8 Aug 2023 at 12:09, Peter Samuelson  wrote:

>
> [M. Zhou]
> > I'd personally not prefer to upload zfs-X.Y.99 anytime in the future.
> > Since debian is volunteer-based, we don't seem to have more bandwidth
> > than Ubuntu for dealing with regressions and serious bugs in a
> > snapshot version.
>
> That's fair - but now that Linux 6.4 is in unstable, zfs-dkms is no
> longer supported and will not build.  For that reason, could you update
> to 2.2.0-rc3?
>
> Peter
>
> ___
> Pkg-zfsonlinux-devel mailing list
> pkg-zfsonlinux-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
>


-- 
Colm Buckley | c...@tuatha.org

Bug#1043303: RFS: runit-services/0.5.5 -- UNIX init scheme with service supervision (services)

[lorenzo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "runit-services":

 * Package name : runit-services
   Version  : 0.5.5
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : CC0-1.0, BSD-3-Clause
 * Vcs  :
   https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section
  : admin

The source builds the following binary packages:

  runit-services - UNIX init scheme with service supervision (services)

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

  https://mentors.debian.net/package/runit-services/

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

  dget -x
  
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.5.dsc

Git repo:
  
https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/bookworm-pu?ref_type=heads

Changes since the last upload:

 runit-services (0.5.5) unstable; urgency=medium
 .
   * dhclient: don't hardcode eth1 interface to
  avoid flood of syslog in systems where eth1
  does not exist (Closes: #1033542)

Regards,
Lorenzo

Bug#1043302: RM: bist -- RoQA; Upstream Dead; RC-Buggy; Unmaintained

[Boyuan Yang]

Package: ftp.debian.org
Control: affects -1 + src:bist
X-Debbugs-Cc: b...@packages.debian.org da...@debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: by...@debian.org
Severity: normal


Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/1038395 previously, package bist (
https://tracker.debian.org/pkg/bist ) is RC-Buggy, missed previous Debian 12
release, has a dead upstream, and received no maintainer upload in the last
decade. The request on package removal also received no maintainer reply in
the last 2 months. As a result, I believe this package should be removed from
Debian archive.

Thanks,
Boyuan Yang


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

Bug#1038155: [Pkg-zfsonlinux-devel] Bug#1038155: zfs-linux: Provide a package based on OpenZFS master branch (a.k.a. 2.1.99)

[Peter Samuelson]

[M. Zhou]
> I'd personally not prefer to upload zfs-X.Y.99 anytime in the future.
> Since debian is volunteer-based, we don't seem to have more bandwidth
> than Ubuntu for dealing with regressions and serious bugs in a
> snapshot version.

That's fair - but now that Linux 6.4 is in unstable, zfs-dkms is no
longer supported and will not build.  For that reason, could you update
to 2.2.0-rc3?

Peter

Bug#1043301: dh-python should declare Depends python3 >= 3.11

[Tianyu Chen]

Package: dh-python
Version: 6.20230802
Severity: important
X-Debbugs-Cc: sweetyf...@deepin.org, Tianyu Chen , 
Tianyu Chen 

Hi,

As bug #1032866, dh-python should Depend on python3 >= 3.11 else
pyproject plugin won't auto detect.

D: pybuild __init__:40: cannot initialize 'pyproject' plugin
Traceback (most recent call last):
  File "/usr/share/dh-python/dhpython/build/__init__.py", line 32, in 

module = __import__("dhpython.build.plugin_%s" % i, fromlist=[i])
  File "/usr/share/dh-python/dhpython/build/plugin_pyproject.py", line 
28, in 
import tomllib
ModuleNotFoundError: No module named 'tomllib'

Sincerely,
Tianyu Chen


-- System Information:
Distributor ID: Deepin
Description:Deepin 23
Release:23
Codename:   beige
Architecture: x86_64

Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-python depends on:
ii  python33.10.4-1
ii  python3-distutils  3.9.12-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev   1.21.20-1deepin2+rb6
pn  flit   
ii  libdpkg-perl   1.21.20-1deepin2+rb6
ii  python3-build  0.10.0-1
ii  python3-installer  0.4.0+dfsg1-1
ii  python3-wheel  0.34.2-1

-- no debconf information

Bug#1025221: abseil: please consider disabling tests on riscv64

[Aurelien Jarno]

Hi Benjamin,

On 2022-12-06 11:15, Benjamin Barenblat wrote:
> Control: owner 1025221 !
> Control: tags 1025221 - patch
> 
> Hi, Manuel,
> 
> Yesterday, I tried a build on a porterbox with your patch. It looks like
> disabling parallelism improves the situation but does not completely
> solve it; absl_mutex_test is still flaky. I’ll continue investigating
> and see if I can get that test fixed.
> 
> In the meantime, it looks like a recent binNMU to Abseil on riscv64 has
> passed the buildds. Does that unblock your work?

Thanks for your upload fixing #1037567. Unfortunately it appears that we
are now bitten by this bug with a failure in the testsuite. Would that
be possible to use the same patch that you applied to the experimental
branch? [1] While it doesn't fully fix the issue, it increases the
chance for the testsuite to path.

BTW, by just looking at the code, the problem with absl_mutex_test could
be the use of rdcycle to measure the time. This counter is per CPU, so
if the process is rescheduled to another CPU (which is likely in a
multithreaded test) the time measurement is totally wrong. In addition
rdcycle will likely going to be forbidden from the userland, for
security reasons [2]. rdtime would be a better replacement here, but at
this stage I haven't looked at how to change that, nor if its the real
issue.

Thanks,
Aurelien

[1] 
https://salsa.debian.org/debian/abseil/-/commit/f4f2c1da90c4e6a0683c4e66c0268baa1b79cdf3
[2] https://lore.kernel.org/lkml/20230802-7c19a712ae071f68030ab5f2@orel/T/

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

Bug#994722: apt-show-versions: Syntax error on or around line 378.

[Richard Lewis]

control: tags -1 + patch
thanks

On Sun, 6 Aug 2023 at 17:15, Richard Lewis
 wrote:
> On Sun, 19 Sep 2021 22:41:24 +0100 Richard Lewis
>  wrote:
>
> > giving two arguments including one that is not a package shows there is a 
> > syntax error somewhere around line 378:
> >
> > $ apt-show-versions apt whatever
> > apt:amd64/bullseye 2.2.4 uptodate
> > Use of uninitialized value $arch in concatenation (.) or string at 
> > /usr/bin/apt-show-versions line 378.
> > Use of uninitialized value $arch in hash element at 
> > /usr/bin/apt-show-versions line 381.
> > Use of uninitialized value $arch in hash element at 
> > /usr/bin/apt-show-versions line 393.
> > whatever: not installed

I believe the following patch fixes this bug, and the main issue in
883766 (but not the bit about the version number)

--- /usr/bin/apt-show-versions  2022-10-15 10:52:39.0 +0100
+++ ./apt-show-versions 2023-08-08 19:29:45.842051600 +0100
@@ -355,8 +355,8 @@
 if ($archname and ! defined $apackages->{$pkgname}{$archname}) {
 printf("%s not available for architecture %s\n", $pkgname, $archname);
 } elsif (! defined $pkgs->{$pkgname}) {
-if ($mode != $MODE_SINGLE || $archname) {
-   print_package_internal($pkgname, $archname)
+if ($archname) {
+
print_package_internal($pkgname, $archname)
 } elsif (keys(%{$apackages->{$pkgname}})) {
 my $archlist = "";
 foreach my $a (sort keys(%{$apackages->{$pkgname}})) {

Bug#1043300: src:ruby-ox: fails to migrate to testing for too long: triggers autopkgtest failure on ppc64el

[Paul Gevers]

Source: ruby-ox
Version: 2.14.9-1
Severity: serious
Control: close -1 2.14.17-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:ruby-ox has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable triggers 
an autopkgtest failure in ruby-moneta on ppc64el when tested in testing.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=ruby-ox



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043299: xterm: build with ReGIS support

[Benjamin Barenblat]

Package: xterm
Version: 384-1
Severity: wishlist

Xterm supports ReGIS (DEC vector graphics) emulation, but it’s not
compiled in by default. Would you be willing to add
`--enable-regis-graphics` to the `configure` invocation in debian/rules?

Bug#936009: shim-unsigned:amd64 cannot be installed alongside shim-unsigned:i386

[Pascal Hambourg]

Control: tags -1 patch

Merge request !12 should fix this issue by adding "Multi-Arch: same".


Is there any reason to not accept it ?

Bug#1043298: Package dependenciens mishmash

[Mcgiwer]

Package: dpkg
Version: 1.21.22 (amd64)

There seem to be problem with the packages dependencies.

While attempting to upgrade while having other then only default repositories 
included (there is no error about package duplicates), I had recivied following 
dependency issue:

By some packages, dpkg (thru aptitude) requires that the package from with it's 
dependant has in the same time the version is: smaller, equal, bigger and 
equal, with is mutually exclusive.

System: Debian (bookworm)

Please fix it asap.

Mcgiwer

publickey - mcgiwer@proton.me - 0xD936838D.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#1043297: src:dynarmic: fails to migrate to testing for too long: unresolved RC issue

[Paul Gevers]

Source: dynarmic
Version: 6.4.5+ds-1
Severity: serious
Control: close -1 6.4.8+ds-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1041270

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:dynarmic has been trying to migrate for 33 
days [2]. Hence, I am filing this bug. The version in unstable has an 
unresolved RC issue as reported in bug 1041270.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=dynarmic



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042362: RFS: streamlink/6.0.1-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Control: retitle 1042362 RFS: streamlink/6.0.1-1 -- CLI for extracting video 
streams from various websites to a video player

Hi,

On 27/07/2023 00:42, Alexis Murzeau wrote:

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.0.1.



A new upstream release 6.0.1 was released in the mean time.
I've updated the package on mentors.

   * Package name: streamlink
 Version : 6.0.1-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_6.0.1-1.dsc

Changes since the last upload to unstable:
streamlink (6.0.1-1) unstable; urgency=medium

  * New upstream version 6.0.1
  * d/upstream/signing-key.asc: update upstream key
  * d/patches: update patches
  * d/control: add new dependency python3-pytest-trio
  * d/rules: streamlink manpage: use CW font instead of C
  * d/rules: remove unused inclusion of pkg-info.mk
  * d/rules: fix duplicate doc assets
  * Upload to unstable

 -- Alexis Murzeau   Tue, 08 Aug 2023 19:10:29 +0200

streamlink (5.5.1-1~exp1) experimental; urgency=medium

   * New upstream version 5.5.1
   * d/patches: update patches
   * d/patches,control: use furo theme instead of sphinx-rtd-theme
   * d/patches,control: use fork-awesome as a replacement for font-awesome
   * d/s/lintian-overrides: remove obsolete override about a test file

  -- Alexis Murzeau   Sat, 20 May 2023 19:52:43 +0200


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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043296: evolution: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed

[Henrik Ahlgren]

Package: evolution
Version: 3.46.4-2
Severity: normal
X-Debbugs-Cc: none, Henrik Ahlgren 

Not sure if this bugs belongs to evolution or libgtk-3-0 package, but I
mostly see this with Evolution (randomly also with LibreOffice?), so I
don't think it's a Gtk bug affecting all software.

Consider a system with:

- AMD/APU desktop PC with Samsung 4K display connected via DisplayPort.

- All suspend/sleep modes disabled in systemd sleep.conf.

- Evolution running.

- GNOME desktop session locked (Super-L).

- Monitor powered off, since something (perhaps slight mouse movement?)
tends to disable the power saving mode and activate the backlight of the
monitor every few minutes.

This causes the following log entry to be flooded nearly constantly to the
system log:

  evolution[34996]: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR 
(monitor)' failed

The errors come in bursts of dozens of errors, and then there might be a
pause of 1 to 15 minutes, but this pattern does not seem to be
consistent. Anyway, sometimes the log (systemd journal) can grow
gigabytes (wearing the SSD) from this single error if the PC sits idle
for few days and the user forgets to exit from Evolution before locking
his screen.


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
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 evolution depends on:
ii  dbus [default-dbus-system-bus]  1.14.8-2~deb12u1
ii  evolution-common3.46.4-2
ii  evolution-data-server   3.46.4-2
ii  libc6   2.36-9+deb12u1
ii  libcamel-1.2-64 3.46.4-2
ii  libecal-2.0-2   3.46.4-2
ii  libedataserver-1.2-27   3.46.4-2
ii  libevolution3.46.4-2
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.37-2
ii  libical33.0.16-1+b1
ii  libnotify4  0.8.1-1
ii  libwebkit2gtk-4.1-0 2.40.5-1~deb12u1
ii  libxml2 2.9.14+dfsg-1.3~deb12u1
ii  psmisc  23.6-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.46.4-2
ii  evolution-plugin-pstimport   3.46.4-2
ii  evolution-plugins3.46.4-2
ii  yelp 42.2-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.40-1.1
ii  network-manager 1.42.4-1

-- no debconf information

Bug#1043268: libnetfilter-conntrack: please disable documentation build when not building libnetfilter-conntrack-doc

[Jeremy Sowden]

Control: tags -1 + pending

On 2023-08-08, at 09:49:15 +0100, Simon McVittie wrote:
> Source: libnetfilter-conntrack
> Version: 1.0.9-3
> Severity: wishlist
> Tags: patch
> X-Debbugs-Cc: debian-ri...@lists.debian.org
> 
> The riscv64 port is currently being bootstrapped, and I noticed that
> packages like gtk4 are currently unbuildable because they are waiting
> for src:systemd. Looking at the dependency chain for src:systemd,
> it indirectly depends on libnetfilter-conntrack, which is currently
> unbuildable because of a long dependency chain starting with graphviz
> (and ending at abseil, which takes a long time to build on riscv64 and
> failed several times with timeouts).
> 
> libnetfilter-conntrack only needs graphviz (and doxygen) for its API
> documentation, so an easy way to break this dependency chain would be
> for libnetfilter-conntrack to only build its API documentation when
> "Architecture: all" packages are being built. A side benefit is that
> this would make official builds by the buildds a bit faster.
> 
> Please consider applying the attached patch, with the "Closes" line
> amended to mention this bug report's bug number. I used diffoscope to
> confirm that this change does not alter the contents of either the _amd64
> or _all binary packages.

Patch applied.  I've added `nodoc` support too.

J.


signature.asc
Description: PGP signature

Bug#1043278: libshumate-dev: file conflict in Multi-Arch package

[Simon McVittie]

On Tue, 08 Aug 2023 at 13:12:04 +0200, Matthias Geiger wrote:
> The
> Multi-Arch hinter states the following: "libshumte-dev conflicts on
> /usr/share/gir-1.0/Shumate-1.0.gir on mips64el <-> amd64, arm64, armel
> and 5 five more." 

What are the differences between the mips64el content and the others?

> This is a similar issue as #905715.
> I'd appreciate help regarding this issue so I can fix this.

The short-term solution is very easy: remove "Multi-Arch: same" from
libshumate-dev.

The long-term solution depends on what the per-architecture differences
actually are.

smcv

Bug#1043295: rust-tendril: Please consider updating to 0.4.3 to fix upcoming FTBFS

[Andreas Hasenack]

Package: rust-tendril
Version: 0.4.0-1
Severity: normal

Dear Maintainer,

please consider updating rust-tendril to 0.4.3. It fixes a build
problem in 0.4.0 when built with rustc 1.70.0:

error[E0793]: reference to packed field is unaligned
   --> src/tendril.rs:241:20
|
241 | if (*header).refcount.decrement() == 1 {
|^^
|
= note: fields of packed structs are not properly aligned, and
creating a misaligned reference is undefined behavior (even if that
reference is never dereferenced)
= help: copy the field contents to a local variable, or replace
the reference with a raw pointer and use
`read_unaligned`/`write_unaligned` (loads and stores via `*p` must be
properly aligned even when using raw pointers)

These were in 0.4.3. Note that 0.4.3 also requires a version update
for rust-futf, and maybe others (I stopped checking at rust-futf).

https://github.com/servo/tendril/issues/58
https://github.com/servo/tendril/issues/67

Bug#1042005: transition: mumps hypre2.28.0 superlu combblas

[Drew Parsons]

On 2023-08-06 20:05, Drew Parsons wrote:


hypre test timeouts are an ongoing problem, now chronic on ppc64el.
Historically a retry would pass, but ppc64el remains uncooperative.  I
raised the issue upstream at
https://github.com/hypre-space/hypre/issues/955
They suggest making life easier for ourselves and just run `make
check`, touching only a subset of all their tests.


ppc64el tests continue to hand with make checkpar.
We identified that the hypre timeouts occur in pmix, and possibly fixed 
in pmix v5.


Bug#1043263 does not literally block this transition in the sense that I 
uploaded hypre 2.28.0-6 to just skip ppc64el build tests altogether (can 
revisit it once pmix v5 is uploaded).


With that done, all packages for the transition are uploaded and built, 
so the transition ready for higher level dependency rebuilds  (I'll 
upload dolfin/dolfinx once petsc is rebuilt).


Drew

Bug#1025221: Work around abseil test failures on riscv64

[Stéphane Glondu]

Hi,

In the attached patch, I propose to make test failures non-fatal on riscv64.


Cheers,

--
StéphaneFrom 0b75b77441aeb3bcca5695e4bd17dc2732e86432 Mon Sep 17 00:00:00 2001
From: Stephane Glondu 
Date: Tue, 8 Aug 2023 15:07:23 +0200
Subject: [PATCH] Backport fix to #1025221

---
 debian/changelog | 8 
 debian/rules | 8 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 0a2de86..22dc86d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+abseil (20220623.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Run tests serially on riscv64 to avoid hitting Debian build hardware
+limits, and do not fail the build on failures. (Closes: #1025221)
+
+ -- Stéphane Glondu   Tue, 08 Aug 2023 15:06:55 +0200
+
 abseil (20220623.1-2) unstable; urgency=medium
 
   * Constrain build to GCC 12, since this version of Abseil doesn’t build
diff --git a/debian/rules b/debian/rules
index d609759..2497135 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,6 +30,12 @@ else
 ABSL_RUN_TESTS=ON
 endif
 
+# Debian's RISC-V builders don't have enough resources to run tests in parallel.
+# See https://bugs.debian.org/1025221.
+ifneq ($(filter $(DEB_HOST_ARCH),riscv64),)
+ABSL_TEST_EXTRA_ARGS=--no-parallel || true
+endif
+
 %:
 	dh $@
 
@@ -51,7 +57,7 @@ override_dh_auto_build:
 
 ifeq ($(ABSL_RUN_TESTS),ON)
 override_dh_auto_test:
-	dh_auto_test -Bshared
+	dh_auto_test -Bshared $(ABSL_TEST_EXTRA_ARGS)
 endif
 
 override_dh_auto_install:
-- 
2.40.1

Bug#1043294: Bluetooth keeps disconnecting mouse

[Steven Friedrich]

Package: Bluetooth
Version: unknown

Synopsis: Bluetooth keeps disconnecting mouse
Expectation: The mouse should only be disconnected when powered off or 
commanded by user in settings.

Bug#1043293: davmail: autopkgtest should invoke specific nc implementation

[Graham Inggs]

Source: davmail
Version: 6.1.0.3423-4
Tags: patch

Hi Alexandre

Thanks for the quick fix for #1043143!

I did not consider that netcat-openbsd and netcat-traditional are
co-installable, and that the 'nc' symlink is handled by the
alternatives system.

Please consider the following change to debian/tests/binary-starts:

-nc -z localhost 1025 || echo "Daemon does not seem to listen" >&2
+nc.traditional -z localhost 1025 || echo "Daemon does not seem to listen" >&2

Regards
Graham

Bug#1043264: sunpinyin: Please add support for arch loongarch64

[Boyuan Yang]

Hi,

在 2023-08-08星期二的 15:55 +0800，zhangdandan写道：
> Package: sunpinyin
> Version: 3.0.0~rc2+ds1-4
> Severity: wishlist
> Tags: patch
> User: debian-de...@lists.debian.org
> Usertags: loongarch64
> 
> Dear maintainers,
> 
>     When I compiled sunpinyin for loongarch architecture, it reported 
> missing architecture support.
> The error message is as follows,
> In file included from src/portability.cpp:39:
> ./config.h:124:3: error: #error can not detect the endianness!
>    124 | # error can not detect the endianness!
>    |   ^
> 
> We have added loongarch architecture support for sunpinyin, the patch 
> can be found in the attachment.
> 
> If you have any questions, you can contact me at any time.

I will take the patch as submitted previously at
https://github.com/sunpinyin/sunpinyin/pull/140 . They look essentially the
same.

Thanks,
Boyuan Yang


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

Bug#1043114: Please remove mipsel port from testing and sid

[Sebastian Ramacher]

On 2023-08-06 21:23:13 +0200, Sebastian Ramacher wrote:
> Mark Hymers wrote:
> > 1. Release team: reconfigure britney2 to remove mipsel from testing
> > 2. ftp-team remove architecture from testing and associated queues and
> > perform any needed cleanup
> > 3. ftp-team remove architecture from unstable and experimental and
> > associated queues + cleanup
> 
> To handle the first step, I'm cloning and reassigning this bug to
> release.debian.org.

Implemented in
https://salsa.debian.org/release-team/britney2/-/commit/0747486ec3a31f981e97bdb0e9ee36c404a488d0
and the first britney run without mipsel happened today at 16 UTC.

Step 2 is for the ftp-team.

Cheers
-- 
Sebastian Ramacher

Bug#1043292: rmlint is out-of-date, latest version is v2.10.2

[Cebtenzzre]

Package: rmlint
Version: 2.9.0-2.5

Version 2.9.0 is from August 20, 2019. Version 2.10.2, which I released
today, contains many important bug fixes. The package should be updated
to the latest release.

Bug#1042734: binutils-mingw-w64 FTBFS: Patch debian/patches/specify-timestamp.patch does not apply

[Nicolas Dandrimont]

Control: tags -1 + patch pending

On Mon, Jul 31, 2023 at 11:37:39AM +0300, Adrian Bunk wrote:
> Source: binutils-mingw-w64
> Version: 11
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/binutils-mingw-w64.html
> https://buildd.debian.org/status/fetch.php?pkg=binutils-mingw-w64=riscv64=11=1690696627=0
> 
> ...
> pplying patch debian/patches/specify-timestamp.patch
> patching file upstream/bfd/peXXigen.c
> Hunk #2 FAILED at 840.
> 1 out of 2 hunks FAILED -- rejects in file upstream/bfd/peXXigen.c
> patching file upstream/ld/pe-dll.c
> Hunk #2 FAILED at 1232.
> 1 out of 2 hunks FAILED -- rejects in file upstream/ld/pe-dll.c
> patching file upstream/ld/emultempl/pe.em
> patching file upstream/ld/emultempl/pep.em
> Patch debian/patches/specify-timestamp.patch does not apply (enforce with -f)
> make[1]: *** [debian/rules:71: unpack] Error 1
> 

A patch implementing SOURCE_DATE_EPOCH support for --insert-timestamp was merged
upstream, so this debian-specific implementation can be dropped.

http://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6badd1020f5bebd3f60a780b8e41a1b581046087

Attached is a git-format-patch for a NMU of binutils-mingw-w64 dropping the
patch. I've uploaded it to DELAYED/2.

Cheers,
Nicolas
From 1c70e29cafe59e1f099a546ae157eef62bbab0e6 Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont 
Date: Tue, 8 Aug 2023 18:13:53 +0200
Subject: [PATCH] Drop specify-timestamp.patch, applied upstream in binutils
 2.41 (Closes: #1042734)

---
 debian/changelog   |   8 ++
 debian/patches/series  |   1 -
 debian/patches/specify-timestamp.patch | 128 -
 3 files changed, 8 insertions(+), 129 deletions(-)
 delete mode 100644 debian/patches/specify-timestamp.patch

diff --git a/debian/changelog b/debian/changelog
index 4ce45da..f254c82 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+binutils-mingw-w64 (11+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop specify-timestamp.patch, applied upstream in binutils 2.41
+(Closes: #1042734)
+
+ -- Nicolas Dandrimont   Tue, 08 Aug 2023 18:18:48 +0200
+
 binutils-mingw-w64 (11) unstable; urgency=medium
 
   * In preparation for binutils 2.41, drop pr30079.patch, merged
diff --git a/debian/patches/series b/debian/patches/series
index df17d1d..1d58fe7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,5 +1,4 @@
 testsuite-timeout.patch
-specify-timestamp.patch
 dont-run-objcopy.patch
 disable-flags.patch
 reproducible-import-libraries.patch
diff --git a/debian/patches/specify-timestamp.patch b/debian/patches/specify-timestamp.patch
deleted file mode 100644
index f268ea4..000
--- a/debian/patches/specify-timestamp.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-Description: Allow the PE timestamp to be specified
-Author: Stephen Kitt 
-
 a/upstream/bfd/peXXigen.c
-+++ b/upstream/bfd/peXXigen.c
-@@ -74,6 +74,9 @@
- #include 
- #include 
- 
-+#include 
-+#include 
-+
- /* NOTE: it's strange to be including an architecture specific header
-in what's supposed to be general (to PE/PEI) code.  However, that's
-where the definitions are, and they don't vary per architecture
-@@ -837,9 +840,36 @@
- 
-   /* Use a real timestamp by default, unless the no-insert-timestamp
-  option was chosen.  */
--  if ((pe_data (abfd)->timestamp) == -1)
--H_PUT_32 (abfd, time (0), filehdr_out->f_timdat);
--  else
-+  if ((pe_data (abfd)->timestamp) == -1) {
-+time_t now;
-+char *source_date_epoch;
-+unsigned long long epoch;
-+char *endptr;
-+
-+now = time (NULL);
-+source_date_epoch = getenv("SOURCE_DATE_EPOCH");
-+if (source_date_epoch) {
-+  errno = 0;
-+  epoch = strtoull(source_date_epoch, , 10);
-+  if ((errno == ERANGE && (epoch == ULLONG_MAX || epoch == 0))
-+  || (errno != 0 && epoch == 0)) {
-+_bfd_error_handler("Environment variable $SOURCE_DATE_EPOCH: strtoull: %s\n",
-+   strerror(errno));
-+  } else if (endptr == source_date_epoch) {
-+_bfd_error_handler("Environment variable $SOURCE_DATE_EPOCH: No digits were found: %s\n",
-+   endptr);
-+  } else if (*endptr != '\0') {
-+_bfd_error_handler("Environment variable $SOURCE_DATE_EPOCH: Trailing garbage: %s\n",
-+   endptr);
-+  } else if (epoch > ULONG_MAX) {
-+_bfd_error_handler("Environment variable $SOURCE_DATE_EPOCH: value must be smaller than or equal to: %lu but was found to be: %llu\n",
-+   ULONG_MAX, epoch);
-+  } else {
-+now = epoch;
-+  }
-+}
-+H_PUT_32 (abfd, now, filehdr_out->f_timdat);
-+  } else
- H_PUT_32 (abfd, pe_data (abfd)->timestamp, filehdr_out->f_timdat);
- 
-   PUT_FILEHDR_SYMPTR (abfd, filehdr_in->f_symptr,
 a/upstream/ld/pe-dll.c
-+++ b/upstream/ld/pe-dll.c
-@@ -27,6 +27,8 @@
- #include 

Bug#1012864: graphviz: new upstream version 7.0.0 is available

[Benjamin Redelings]

Hi László,

Thanks for working on packaging a new version of graphviz!  This will be 
really useful.


I tried running the following command, and it looks like there's an 
issue where libtool has just recently removed a "Provides: libltdl7-dev" 
from libtldl-dev [1].


dget -u -xhttps://people.debian.org/~gcs/graphviz_8.0.5-1.dsc  --build

I was able to get around this problem by downgrading libltdl-dev and 
libltdl7 from 2.4.7-7 to 2.4.7-5, but then I got some errors about 
usr/bin/smyrna being missing [2].


Perhaps an upload to experimental could be done?  Then people could use 
that while you are getting advice from upstream on packaging 8.1.


Thanks for all your work on this!

-BenRI

[1]
make[1]: Leaving directory '/home/bredelings/Work/dtmp/graphviz-8.0.5' 
debian/rules override_dh_install-arch make[1]: Entering directory 
'/home/bredelings/Work/dtmp/graphviz-8.0.5' # Compute the dependencies 
of the -dev package # NOTE: It is important to do that before 
splitting the files into # their respective packages, otherwise the 
symlinks are broken d-devlibdeps \ --override s/libpathplan4-dev// \ 
--override s/libgraph6-dev// \ --override s/libcdt5-dev// \ 
/home/bredelings/Work/dtmp/graphviz-8.0.5/debian/libgraphviz-dev.substvars 
\ 
/home/bredelings/Work/dtmp/graphviz-8.0.5/debian/tmp/usr/lib/x86_64-linux-gnu/*.so 
--> libexpat1-dev package exists. --> libgraphviz-dev package from 
same source package. devlibs error: There is no package matching 
[libltdl7-dev] and noone provides it, please report bug to d-shlibs 
maintainer --> zlib1g-dev package exists. make[1]: *** 
[debian/rules:110: override_dh_install-arch] Error 1 make[1]: Leaving 
directory '/home/bredelings/Work/dtmp/graphviz-8.0.5' make: *** 
[debian/rules:130: binary] Error 2 dpkg-buildpackage: error: fakeroot 
debian/rules binary subprocess returned exit status 2 


[2]
dh_install: warning: Cannot find (any matches for) "usr/bin/smyrna" 
(tried in ., debian/tmp) dh_install: warning: smyrna missing files: 
usr/bin/smyrna dh_install: warning: Cannot find (any matches for) 
"usr/share/graphviz/smyrna/" (tried in ., debian/tmp) dh_install: 
warning: smyrna missing files: usr/share/graphviz/smyrna/ dh_install: 
warning: Cannot find (any matches for) "usr/share/man/man1/smyrna.1" 
(tried in ., debian/tmp) dh_install: warning: smyrna missing files: 
usr/share/man/man1/smyrna.1 dh_install: error: missing files, aborting 
make[1]: *** [debian/rules:111: override_dh_install-arch] Error 255 
make[1]: Leaving directory '/home/bredelings/Work/dtmp/graphviz-8.0.5' 
make: *** [debian/rules:130: binary] Error 2 dpkg-buildpackage: error: 
fakeroot debian/rules binary subprocess returned exit status 2 

Bug#1043291: mate-tweak: can't change MATE panel layout by mate-tweak because of missed mate-volume-control-applet executable

[Norbert]

Package: mate-tweak
Version: 22.10.0-2
Severity: normal
X-Debbugs-Cc: nrb...@gmail.com

Dear Maintainer,

please repeat the following steps to reproduce the issue:
1. Install task-mate-desktop with mate-tweak to get full MATE desktop
2. Launch mate-tweak from terminal
3. Go to Panel tab, then try to switch panel layouts using drop-down menu

Expected results:
* user is able to select any available MATE Panel layouts - one from Fedora,
GNOME, openSUSE

Actual results:
* user is unable to select needed panel layout, gets the following error
messages in the terminal:

```
$ mate-tweak
Window Manager is: marco-no-composite
System installed layouts:
['fedora', 'default', 'opensuse']
Current layout: opensuse
/usr/bin/mate-tweak:684: PyGTKDeprecationWarning: The "buttons" argument must
be a Gtk.ButtonsType enum value. Please use the "add_buttons" method for adding
buttons. See: https://wiki.gnome.org/PyGObject/InitializerDeprecations
  dialog = Gtk.Dialog(title, None, Gtk.DialogFlags.MODAL |
Gtk.DialogFlags.DESTROY_WITH_PARENT,
/usr/bin/mate-tweak:684: PyGTKDeprecationWarning: The "flags" argument for
dialog construction is deprecated. Please use initializer keywords: modal=True
and/or destroy_with_parent=True. See:
https://wiki.gnome.org/PyGObject/InitializerDeprecations
  dialog = Gtk.Dialog(title, None, Gtk.DialogFlags.MODAL |
Gtk.DialogFlags.DESTROY_WITH_PARENT,
/usr/bin/mate-tweak:690: PyGTKDeprecationWarning: Using positional arguments
with the GObject constructor has been deprecated. Please specify keyword(s) for
"label" or use a class specific constructor. See:
https://wiki.gnome.org/PyGObject/InitializerDeprecations
  label = Gtk.Label(text)
Switching to: fedora
Traceback (most recent call last):
  File "/usr/bin/mate-tweak", line 1047, in combo_fallback
self.additional_tweaks(schema, key, value[1])
  File "/usr/bin/mate-tweak", line 1031, in additional_tweaks
self.replace_panel_layout(panel_layout)
  File "/usr/bin/mate-tweak", line 768, in replace_panel_layout
self.enable_applets()
  File "/usr/bin/mate-tweak", line 571, in enable_applets
pid = subprocess.Popen(['mate-volume-control-applet'], stdout=DEVNULL,
stderr=DEVNULL).pid

  File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'mate-volume-control-
applet'
/usr/bin/mate-tweak:684: PyGTKDeprecationWarning: The "buttons" argument must
be a Gtk.ButtonsType enum value. Please use the "add_buttons" method for adding
buttons. See: https://wiki.gnome.org/PyGObject/InitializerDeprecations
  dialog = Gtk.Dialog(title, None, Gtk.DialogFlags.MODAL |
Gtk.DialogFlags.DESTROY_WITH_PARENT,
/usr/bin/mate-tweak:684: PyGTKDeprecationWarning: The "flags" argument for
dialog construction is deprecated. Please use initializer keywords: modal=True
and/or destroy_with_parent=True. See:
https://wiki.gnome.org/PyGObject/InitializerDeprecations
  dialog = Gtk.Dialog(title, None, Gtk.DialogFlags.MODAL |
Gtk.DialogFlags.DESTROY_WITH_PARENT,
/usr/bin/mate-tweak:690: PyGTKDeprecationWarning: Using positional arguments
with the GObject constructor has been deprecated. Please specify keyword(s) for
"label" or use a class specific constructor. See:
https://wiki.gnome.org/PyGObject/InitializerDeprecations
  label = Gtk.Label(text)
Switching to: default
Traceback (most recent call last):
  File "/usr/bin/mate-tweak", line 1047, in combo_fallback
self.additional_tweaks(schema, key, value[1])
  File "/usr/bin/mate-tweak", line 1031, in additional_tweaks
self.replace_panel_layout(panel_layout)
  File "/usr/bin/mate-tweak", line 768, in replace_panel_layout
self.enable_applets()
  File "/usr/bin/mate-tweak", line 571, in enable_applets
pid = subprocess.Popen(['mate-volume-control-applet'], stdout=DEVNULL,
stderr=DEVNULL).pid

  File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'mate-volume-control-
applet'
/usr/bin/mate-tweak:684: PyGTKDeprecationWarning: The "buttons" argument must
be a Gtk.ButtonsType enum value. Please use the "add_buttons" method for adding
buttons. See: https://wiki.gnome.org/PyGObject/InitializerDeprecations
  dialog = Gtk.Dialog(title, None, Gtk.DialogFlags.MODAL |
Gtk.DialogFlags.DESTROY_WITH_PARENT,
/usr/bin/mate-tweak:684: PyGTKDeprecationWarning: The "flags" argument for
dialog construction is deprecated. Please use initializer 

Bug#1043290: ITS policy lost in transition?

[Phillip Susi]

Package: src:policykit-1
Version: 123-1

I'm trying to package a new upstream of the gparted package and respond
to bug #1025568 involving a policykit transition.  It appears that
gparted uses gettext which is failing to build because it requires
/usr/share/gettex/its/policy.its and policy.loc.  These files used to be
provided by policykit-1, but no longer appear to be packaged at all in
Trixie.  Were these files supposed to be migrated to another package and
forgotten?  I would imagine this should be causing ftbs in a number of
packages that use gettext.  Then again, I wonder if gettext needs these
files, why were they part of policykit before?  Why aren't they shipped
with gettext or a package that it depends on?

Bug#1043034: pipewire-pulse: Missing dependencie(s) or incomplete

[Bzzzz]

On Tue, 8 Aug 2023 11:06:23 +0200
Dylan Aïssi  wrote:

Hi Dylan,

> Hi,
> 
> Le sam. 5 août 2023 à 11:42, B  a écrit :
> >
> > After removing almost all pulseaudio packages, except those linked
> > to other programs, I rebooted and pipewire-pulse was gone (pipewire
> > and wireplumber were launched as usual).
> 
> Not sure what happened, maybe a package that should have stayed
> has been deleted.


Yep, I forgot that I also reinstalled xdg-desktop-portal &
xdg-desktop-portal-gtk due to the log you're talking about below.

> > I rebooted just in case, but still no pipewire-pulse, so I scooped
> > the web searching for a solution and find a guy saying that
> > installing pavucontrol & paprefs made him troubleshoot his loss of
> > audio also with pipewire-pulse too, so I tried, which installed
> > some other packages, and rebooted - this time, pipewire-pulse was
> > up and running after login.
> >
> > I'm not a specialist, but I think it was missing an
> > org.freedesktop.xxx.xml file that came with one of these two
> > packages or came from one of their dependencies.
> 
> I don't see any reference about a missing org.freedesktop.xxx.xml
> file in the log you provided. I suppose you've confused it with the
> missing "org.freedesktop.portal.Desktop"  which is a D-Bus interface
> used by pipewire for screen-sharing, so not related to your sound
> issue. This file is provided by the package xdg-desktop-portal
> (neither pavucontrol nor paprefs).
> 
> However, I can see in your log you are facing these bugs #995357 [1]
> and #1037447 [2]. Both of them are not blocking to get sound and
> are already fixed in newer versions that should land in
> *-backports repo soon I hope (waiting for a review in the backports
> queue)


Fine, as backports is a registered source in my system, it'll upgrade
the time being.

> > As I made a research for org.freedesktop.*.xml and checked before
> > and after installing these 2 packages, I saw that the one in the log
> > wasn't on my disk before, but was there after.
> >
> > So, I emitted the hypothesis that it could be an omission in the
> > pipewire-pulse package, whether it is missing in it or a missing
> > dependency toward another package.
> 
> To get rid of pulseaudio and to install pipewire, you can install the
> metapackage pipewire-audio which depends on all required pipewire
> packages and conflicts with pulseaudio and its bluetooth plugins
> package. But really, pipewire does not depend or requires pavucontrol
> or paprefs.


I digged a bit into dependencies, the pipewire package wants :
xdg-desktop-portal-tests & xdg-desktop-portal-wlr
however, these we'rent installed (but synaptic did not show any broken
pacakage(s)).

As said above, I manually (re)installed xdg-desktop-portal &
xdg-desktop-portal-gtk and up to now, pipewire was ferpectly working.

What I do not understand is, even without installing pipewire-audio
(that I did 10' ago), there is something missing in the pipewire
dependencies, may be something like :
xdg-desktop-portal, xdg-desktop-portal-gtk | xdg-desktop-portal

I also see that other packages shown as pkg pipewire dependencies are
not installed, such as sxmo-utils and that there is a collision that did
not triggered a loop: wireplumber _and_ pipewire-media-session !

Well, in this matter, you are the boss, so it's your call.

Best regards,
Jean-Yves

Bug#1043235: crystal: Package `crystal` misses important dependencies

[Beta Ziliani]

<3 we perfectly understand the issue with time, feel free to contact us for
help

On Tue, Aug 8, 2023 at 11:37 AM David Suarez 
wrote:

> Hi,
>
> Yep, you are right, at some point (probably my fault), we lose the
> correct depends. Will release a new version with the fixes as soon as
> possible.
>
> About interpreter support, I can't remember, but at some point I
> disabled it because it was not working. Will try to re-enable it again
> (
> https://salsa.debian.org/deiv/crystal/-/commit/329e1a0b7046b21eeb04efbb20e0a8c4e8a89c1a
> ).
>
> In relation to shards, yep I have it in my TODO to package it, as my
> free time allows me.
>
> Thanks for pointing out the problems ! :)
>
> El lun, 7 ago 2023 a las 21:09, Beta () escribió:
> >
> > Package: crystal
> > Version: 1.9.2+dfsg
> > Severity: important
> > X-Debbugs-Cc: b...@manas.tech
> >
> > Dear Maintainer,
> >
> >   It was [brought to our
> >   attention](
> https://forum.crystal-lang.org/t/whats-up-with-the-debian-packages/5913)
> >   that the official debian package for crystal 1.9.2+dfsg-1 is not
> >   usable as is, as it is not requiring the libevent-dev library.
> >
> >   Let me say upfront that I understand that the issue is likely dragged
> >   from the previous version of the package (1.6.2+dfsg-1 IIRC). Another,
> >   related issue, is that it does not ship `shards`, another important
> >   part of the Crystal ecosystem.
> >
> >   As official maintainer of the [official crystal package](
> https://software.opensuse.org/download.html?project=devel%3Alanguages%3Acrystal=crystal),
> we are very happy to see that Crystal is being updated to its recent
> version, and we would like to help to improve it. One way is to add the
> dependencies. To give you an idea, here is what the official package `apt
> info` says:
> >
> > ```
> > Package: crystal
> > Version: 1.9.2-1+2.15
> > Priority: extra
> > Section: devel
> > Maintainer: Crystal Team 
> > Installed-Size: 133 MB
> > Provides: crystal1.9
> > Depends: gcc, pkg-config, libpcre3-dev, libpcre2-dev, libevent-dev
> > Recommends: libssl-dev, libz-dev, libxml2-dev, libgmp-dev, libyaml-dev
> > Conflicts: crystal
> > Homepage: https://crystal-lang.org
> > Download-Size: 31.8 MB
> > APT-Sources:
> http://download.opensuse.org/repositories/devel:/languages:/crystal/Debian_Unstable
> Packages
> > Description: Crystal is a general-purpose, object-oriented programming
> language.
> >  With syntax inspired by Ruby, it is a compiled language with static
> type-checking,
> >  serving both, humans and computers.
> > ```
> >
> >   (Note: libpcre3-dev is not really required though, it could be in the
> > Recommends section, as it is there for backwards compatibility.)
> >
> >   Another interesting addition is to compile it with interpreter
> > support (passing `interpreter=1` to `make`).
> >
> >   Feel free to contact me for any information regarding this issue. The
> >   Crystal team would love to see the compiler working out-of-the-box in
> >   debian-based distros.
> >
> > Thanks for your work!
> > Beta
> >
> > -- System Information:
> > Debian Release: trixie/sid
> >   APT prefers testing
> >   APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 5.15.49-linuxkit (SMP w/6 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
> > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: unable to detect
> >
> > Versions of packages crystal depends on:
> > ii  libc6   2.37-6
> > pn  libevent-2.1-7  
> > pn  libgc-dev   
> > pn  libgc1  
> > ii  libgcc-s1   13.1.0-6
> > pn  libllvm14   
> > ii  libpcre2-8-010.42-2
> > ii  libstdc++6  13.1.0-6
> > pn  pkg-config  
> >
> > crystal recommends no packages.
> >
> > Versions of packages crystal suggests:
> > pn  crystal-doc  
> > pn  crystal-samples  
>

Bug#1042842: network interface names wrong in domU (>10 interfaces)

[Hans van Kranenburg]

Hi,

On 8/8/23 15:22, Valentin Kleibel wrote:
>> On [0], you can read "In both cases the device naming is subject to the 
>> usual guest or backend domain facilities for renaming network devices".
>> It says "naming/renaming", but you can assume "detecting".
>>
>>> I also checked which net_ids udev knows about and the only things that 
>>> pop up are:
>>> ID_NET_NAMING_SCHEME=v247
>>> ID_NET_NAME_MAC=enx00163efd832b
>>> ID_OUI_FROM_DATABASE=Xensource, Inc.

What I do is stuff like this:

-$ cat /etc/udev/rules.d/70-persistent-vifname.rules

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/0",
NAME="vlan2"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/1",
NAME="vlan3"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/2",
NAME="vlan4"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/3",
NAME="vlan6"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/4",
NAME="vlan9"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/5",
NAME="vlan10"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/6",
NAME="vlan11"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/7",
NAME="vlan12"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/8",
NAME="vlan13"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/9",
NAME="vlan14"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/10",
NAME="vlan15"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/11",
NAME="vlan16"

The vif/X always matches the order in which you define the interfaces
inside the guest config file.

After starting to build router VMs (well before the whole interface
naming madness was a thing), it took only the first time when we wanted
to throw away a vlan, to realize that all the ethX numbers would shift 1
up, and from then on, I've always been using this so set my own style
predictable names (whenever there's more than one, otherwise it's just
eth0).

>> Is it from dom0 or domU ?
>> Are you using "net.ifnames=0" on the domU kernel command line ?
>> "v247" looks like systemd "predictive naming scheme" (eth -> enX).
>>  From bookworm on, domUs vifs get named enXN (enX0, enX1, ...).
>> Read on :
>> https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#xen-network
> 
> This is from the domU, running bullseye with a bookworm dom0.
> 
>> See how ethN interfaces get messed up, like in your setup, but 
>> predictable names would work, as you can see in "altname enXN" :
>> eth1 (:01) -> enX1
>> eth2 (:10) -> enX10
>> eth3 (:02) -> enX2

But yeah, so, even while not depending on whatever order it gets
initialized, and still having it function correctly, this is still just
pretty annoying... If I'm doing stuff around here, and just quickly want
to look up things (e.g. messing around with vlan15 settings), and
quickly type ip a instead of having to spend more time typing ip a show
dev vlan15 jadijadi, I still every time get this short "WTF huh, argh",
raises arms, does table flip, grmbl grbml feeling for a split second.

2: vlan2:  I could not get our bullseye domU to show the "predictable names" even 
> though i tried installing the bullseye-backports kernel 6.1.
> After you wrote this i installed udev 252.5 from backports and it now 
> uses the correct enXn interface names, even with kernel 5.10.
> 
>> So, my answer does not tell you if something changed in Xen itself, only 
>> in Debian.
>> But I guess it relates to what Xen devs told us : vifs detection order 
>> cannot be relied upon, that's why "predictable names" were invented.
>> The vif detection part is related to the domains kernels, not Xen itself 
>> (at least that's what I understood).
>>
>> Using eth0 nowadays is a bit like using /dev/sda for hard drives, it's 
>> considered legacy as it may create problems in some setups, like yours 
>> (ie. for disks, it's recommended to use UUIDs or /dev/disk/by-*).
>>
>> I hope this answers your question.
> 
> Thank you, yes it does.
> 
> In our case the dom0 was updated to bookworm while the domU is still 
> running bullseye.
> -> updated Xen so the vif detection order changed (which we relied on)

I didn't read the other mailthread on the xen list fully yet. But, I
think it's shouldn't be very hard to find the code changes and see if
it's deterministic and can just be fixed. Simply just to decrease the
totally unnecessary amount of silliness.

> -> the predictable network names for Xen don't work with bullseye
> 
> So my new resolution for bullseye domUs on a bookworm dom0 is to install 
> udev from backports and change the domUs network config to use the new 
> enXn naming scheme instead of ethn.

Or the "device/vif/X" way...

So, anyway, did someone already did some test "just because we can" to
see how much network interfaces you can get added for fun, and if the
pattern keeps looking the same, also with enX4 enX40 .. enX49 enX5 etc?
:D enX1 enX10 enX100 .. enX109 enX11 enX110 argh o_O

Have fun,
Hans

Bug#1043147: [Pkg-sssd-devel] Bug#1043147: ding-libs: please consider upgrading to 3.0 source format

[Simon Josefsson]

sön 2023-08-06 klockan 19:53 +0200 skrev Bastian Germann:
> Source: ding-libs
> Version: 0.6.2-1
> Severity: wishlist
> 
> This package is among the few that still use source format 1.0.
> Please upgrade it to source format 3.0:
> https://wiki.debian.org/Projects/DebSrc3.0

Nice catch.  Fixed in git, and CICD is happy:

https://salsa.debian.org/sssd-team/ding-libs/-/commit/527d1f3065b43402ded0b3b8fc113e68c34a734c
https://salsa.debian.org/sssd-team/ding-libs/-/pipelines/561837

Timo: I did some other improvements similar to the *-wrapper packages
and pushed them to ding-libs too, are you happy with these?  I can make
the upload if you want, but didn't want to step onto ding-libs without
syncing first.

/Simon



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

Bug#1037086: dropbear-initramfs: /etc/dropbear/initramfs/dropbear_dss_host_key file not generated

[Michael Meier]

Sorry for the late reply, I've been in vacations.

ok as it seems, everything I've mentioned was just wrong.

The problem was/is, that if the root filesystem is not encrypted, 
dropbear-initramfs does nothing, besides showing cryptic error messages.


To my defense, as it seems I haven't been the only person with that 
problem, I've found it in several forums, without answers ;-).


Possible solutions are:

- Encrypt rootfs (Haven't got permission to do so)

- in /etc/crypttab add "initramfs" as parameter to the corresponding 
partition


Maybe mentioning that in

/usr/share/doc/dropbear-initramfs/initrfamfs.README

would help future users.

Even more helpful would probably be, that

update-initramfs

would spit out a message, that no encrypted fs have been found.

'

hope you didn't loose too much time trying reproducing the error. sorry.


On 30.06.23 16:30, Guilhem Moulin wrote:

On Fri, 30 Jun 2023 at 11:14:35 -0500, Michael Meier wrote:

I had to edit the file /usr/share/initramfs-tools-hooks so it also copies the 
dss key:

src:dropbear doesn't ship that file, do you mean 
/usr/share/initramfs-tools/hooks/dropbear?


The option DROPBEAR_OPTIONS="-E" should be default, so the user gets some
kind of error message if something is not working. Would have saved me an
hour or so...

-E is the default in debug mode…  Need a debug trace anyway to track
this down, because it works just fine here (and in ci).

Bug#1043289: RM: nrefactory -- RoQA; low popcon; dead upstream; depends on gtk2

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:nrefactory
Control: block -1 by 1041639
Control: block 967477 by -1

Please remove nrefactory. It is dead upstream (archived) and build-depends on 
libgtk2.0-cil-dev.
The package has a low popcon and the only listed uploader has just retired.

Bug#1043288: ITP: qad -- A simple, REST-API compliant daemon for automated testing

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com

* Package name: qad
  Version : 0.0~git20230710.75f9d50
  Upstream Contact: James Thomas 
Scott Clarke 
* URL : https://gitlab.com/CodethinkLabs/qad/qad/
* License : GPL and MIT
  Programming Lang: C and Perl
  Description : A simple, REST-API compliant daemon for automated testing
This is a simple, REST-API compliant daemon which makes automated testing
on hardware possible by removing the need for physical intervention as
Q.A.D allows inputs to be injected via http/https requests. This both
eliminates the need to physically interact with the rig and allows for
tasks to be carried out entirely automatically.
Q.A.D. can also take a screenshot and send it back to invoker. It can be
integrated with openQA for automated testing.

I use it as part of my $dayjob and will maintain it.

-- 
Regards
Sudip

Bug#1043287: O: mono-debugger-libs -- Mono soft debugger interface libraries

[Bastian Germann]

Package: wnpp

mono-debugger-libs' maintainer has retired. I am hereby orphaning the package.

Bug#1043286: O: sdb -- a command line client for Mono's soft debugger

[Bastian Germann]

Package: wnpp

sdb's maintainer has retired. I am hereby orphaning the package.

Bug#1043235: crystal: Package `crystal` misses important dependencies

[David Suarez]

Hi,

Yep, you are right, at some point (probably my fault), we lose the
correct depends. Will release a new version with the fixes as soon as
possible.

About interpreter support, I can't remember, but at some point I
disabled it because it was not working. Will try to re-enable it again
(https://salsa.debian.org/deiv/crystal/-/commit/329e1a0b7046b21eeb04efbb20e0a8c4e8a89c1a).

In relation to shards, yep I have it in my TODO to package it, as my
free time allows me.

Thanks for pointing out the problems ! :)

El lun, 7 ago 2023 a las 21:09, Beta () escribió:
>
> Package: crystal
> Version: 1.9.2+dfsg
> Severity: important
> X-Debbugs-Cc: b...@manas.tech
>
> Dear Maintainer,
>
>   It was [brought to our
>   
> attention](https://forum.crystal-lang.org/t/whats-up-with-the-debian-packages/5913)
>   that the official debian package for crystal 1.9.2+dfsg-1 is not
>   usable as is, as it is not requiring the libevent-dev library.
>
>   Let me say upfront that I understand that the issue is likely dragged
>   from the previous version of the package (1.6.2+dfsg-1 IIRC). Another,
>   related issue, is that it does not ship `shards`, another important
>   part of the Crystal ecosystem.
>
>   As official maintainer of the [official crystal 
> package](https://software.opensuse.org/download.html?project=devel%3Alanguages%3Acrystal=crystal),
>  we are very happy to see that Crystal is being updated to its recent 
> version, and we would like to help to improve it. One way is to add the 
> dependencies. To give you an idea, here is what the official package `apt 
> info` says:
>
> ```
> Package: crystal
> Version: 1.9.2-1+2.15
> Priority: extra
> Section: devel
> Maintainer: Crystal Team 
> Installed-Size: 133 MB
> Provides: crystal1.9
> Depends: gcc, pkg-config, libpcre3-dev, libpcre2-dev, libevent-dev
> Recommends: libssl-dev, libz-dev, libxml2-dev, libgmp-dev, libyaml-dev
> Conflicts: crystal
> Homepage: https://crystal-lang.org
> Download-Size: 31.8 MB
> APT-Sources: 
> http://download.opensuse.org/repositories/devel:/languages:/crystal/Debian_Unstable
>   Packages
> Description: Crystal is a general-purpose, object-oriented programming 
> language.
>  With syntax inspired by Ruby, it is a compiled language with static 
> type-checking,
>  serving both, humans and computers.
> ```
>
>   (Note: libpcre3-dev is not really required though, it could be in the
> Recommends section, as it is there for backwards compatibility.)
>
>   Another interesting addition is to compile it with interpreter
> support (passing `interpreter=1` to `make`).
>
>   Feel free to contact me for any information regarding this issue. The
>   Crystal team would love to see the compiler working out-of-the-box in
>   debian-based distros.
>
> Thanks for your work!
> Beta
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.15.49-linuxkit (SMP w/6 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
> Versions of packages crystal depends on:
> ii  libc6   2.37-6
> pn  libevent-2.1-7  
> pn  libgc-dev   
> pn  libgc1  
> ii  libgcc-s1   13.1.0-6
> pn  libllvm14   
> ii  libpcre2-8-010.42-2
> ii  libstdc++6  13.1.0-6
> pn  pkg-config  
>
> crystal recommends no packages.
>
> Versions of packages crystal suggests:
> pn  crystal-doc  
> pn  crystal-samples  

Bug#1043285: dscverify: feature request: --print-files

[Neil Roza]

Package: devscripts
Version: 2.23.4
Severity: wishlist
X-Debbugs-Cc: n...@rtr.ai

Dear Maintainer,

I have need of a tool that, for each given '*.changes' file, every file listed
therein is both verified and printed. Here's a shell script fragment that does
what I want:

find . -type f -name '*.changes' \
-exec dscverify {} + \
-exec grep -Eo '[[:graph:]]+[.](deb|dsc)$' {} +

Somewhere in the course of writing that 'grep' regex, it occurred to me: Why
doesn't 'dscverify' do this? If 'dscverify' already parses '*.changes',
'*.dsc', and '*.buildinfo' better than I can, then perhaps it could be extended
to print the files being verified. Maybe it should grow a new option
'--print-files' to support exactly that.

Anywho, I'm happy to help if someone can show me where and how to submit a
patch.

Regards,
Neil

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBSIGN_KEYID=0x2c3988ebe7fe30ae4fe64210646d2a5102c01999
SALSA_CI_CONFIG_PATH="recipes/debian.yml@salsa-ci-team/pipeline"

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.22
ii  fakeroot  1.31-1.2
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
ii  gpgv  2.2.40-1.1
ii  libc6 2.36-9+deb12u1
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.68-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.2-1+b1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.6.1
ii  curl7.88.1-10+deb12u2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput1.1.3
ii  equivs  2.3.1
ii  libdistro-info-perl 1.5
ii  libdpkg-perl1.21.22
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.26-3
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-3
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck3.3.5-1
ii  lintian 2.116.3
ii  man-db  2.11.2-2
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.6.0
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.1-0.1
ii  unzip   6.0-28
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.2

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
ii  autopkgtest  5.28
pn  bls-standalone   
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.4
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-3
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.15-4
pn  mmdebstrap   
pn  mozilla-devscripts   
ii  mutt 2.2.9-1+b1
ii  openssh-client [ssh-client]  1:9.2p1-2
pn  piuparts 
pn  postgresql-client
pn  pristine-lfs 
pn  quilt
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#1043284: RM: haskell-gi-gtk [armhf] -- ROM; FTBFS on armhf; likely GHC bug

[Scott Talbert]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: haskell-gi-...@packages.debian.org
Control: affects -1 + src:haskell-gi-gtk

Bug#1043283: resize-rootfs service takes a very long time with a Bookworm image: Timed out for waiting the udev queue being empty

[Daniel Leidert]

Package: vmdb2
Version: 0.27+really.0.26-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The images I built in the past started very quickly. In a recent Image based on
Debian Bookworm, the boot process needs several minutes. The `systemd-analyze
blame` command shows over 4 minutes of the process being caused by the
resize-rootfs service. The logs contain this:

[..]
Aug 08 12:30:11 production resize-rootfs[289]: Checking that no-one is using 
this disk right now ... FAILED
Aug 08 12:30:11 production resize-rootfs[289]: This disk is currently in use - 
repartitioning is probably a bad idea.
Aug 08 12:30:11 production resize-rootfs[289]: Umount all file systems, and 
swapoff all swap partitions on this disk.
Aug 08 12:30:11 production resize-rootfs[289]: Use the --no-reread flag to 
suppress this check.
Aug 08 12:30:12 production resize-rootfs[289]: Disk /dev/vda: 8 GiB, 8589934592 
bytes, 16777216 sectors
Aug 08 12:30:12 production resize-rootfs[289]: Units: sectors of 1 * 512 = 512 
bytes
Aug 08 12:30:12 production resize-rootfs[289]: Sector size (logical/physical): 
512 bytes / 512 bytes
Aug 08 12:30:12 production resize-rootfs[289]: I/O size (minimum/optimal): 512 
bytes / 512 bytes
Aug 08 12:30:12 production resize-rootfs[289]: Disklabel type: dos
Aug 08 12:30:12 production resize-rootfs[289]: Disk identifier: 0x3ae6c4c9
Aug 08 12:30:12 production resize-rootfs[289]: Old situation:
Aug 08 12:30:12 production resize-rootfs[289]: Device Boot  Start  End  
Sectors  Size Id Type
Aug 08 12:30:12 production resize-rootfs[289]: /dev/vda1 8192   819199  
 811008  396M ef EFI (FAT-12/16/32)
Aug 08 12:30:12 production resize-rootfs[289]: /dev/vda2   827392 16777215 
15949824  7,6G 83 Linux
Aug 08 12:30:12 production resize-rootfs[289]: /dev/vda1:
Aug 08 12:30:12 production resize-rootfs[289]: New situation:
Aug 08 12:30:12 production resize-rootfs[289]: Disklabel type: dos
Aug 08 12:30:12 production resize-rootfs[289]: Disk identifier: 0x3ae6c4c9
Aug 08 12:30:12 production resize-rootfs[289]: Device Boot  Start  End  
Sectors  Size Id Type
Aug 08 12:30:12 production resize-rootfs[289]: /dev/vda1 8192   827391  
 819200  400M ef EFI (FAT-12/16/32)
Aug 08 12:30:12 production resize-rootfs[289]: /dev/vda2   827392 16777215 
15949824  7,6G 83 Linux
Aug 08 12:30:12 production resize-rootfs[289]: The partition table has been 
altered.
Aug 08 12:30:12 production resize-rootfs[289]: Calling ioctl() to re-read 
partition table.
Aug 08 12:30:12 production resize-rootfs[289]: Re-reading the partition table 
failed.: Das Gerät oder die Ressource ist belegt
Aug 08 12:30:12 production resize-rootfs[289]: The kernel still uses the old 
table. The new table will be used at the next reboot or after you run 
partprobe(8) or partx(8).
Aug 08 12:30:12 production resize-rootfs[289]: Syncing disks.
Aug 08 12:32:22 production resize-rootfs[465]: Timed out for waiting the udev 
queue being empty.
Aug 08 12:34:22 production resize-rootfs[467]: Timed out for waiting the udev 
queue being empty.
Aug 08 12:34:22 production resize-rootfs[470]: resize2fs 1.47.0 (5-Feb-2023)
Aug 08 12:34:22 production resize-rootfs[470]: The filesystem is already 
1993728 (4k) blocks long.  Nothing to do!
Aug 08 12:34:22 production systemctl[471]: Removed 
"/etc/systemd/system/systemd-remount-fs.service.requires/resize-rootfs.service".
[..]

Two observations: The first check actually fails in both Bookworm and Bullseye.
However, the Bookworm image contains the two additional lines:

Aug 08 12:32:22 production resize-rootfs[465]: Timed out for waiting the udev 
queue being empty.
Aug 08 12:34:22 production resize-rootfs[467]: Timed out for waiting the udev 
queue being empty.

which seem to cause the delay.

I have not yet been able to examine the situation further. I'll try as soon as
I find some time.

Regards, Daniel


- -- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldstable-updates'), (500, 
'oldstable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-1-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32.14.gcdfe14e-5
ii  debootstrap 1.0.128+nmu5
ii  e2fsprogs   1.47.0-2
ii  kpartx  0.9.4-5
ii  parted  3.6-3
ii  python3 3.11.4-5+b1
ii  python3-jinja2  3.1.2-1
ii  python3-yaml6.0.1-1
ii  qemu-utils  1:8.0.3+dfsg-5

Versions of packages vmdb2 recommends:
ii  ansible   7.7.0+dfsg-1
ii  dosfstools4.2-1
ii  qemu-user-static  1:8.0.3+dfsg-5

vmdb2 suggests no packages.

- -- no debconf information

-BEGIN PGP 

Bug#1043209: call updatedb.plocate explicitly

[Alexandre Detiste]

I have commited to git the change you requested.
This will be in Trixie but not in Bookworm.

The package is fully backportable but I don't have the needed credentials.

This is the only backport we ever had:
>[2016-02-16] Accepted cruft-ng 0.4.4~bpo8+1 (source amd64) into 
>jessie-backports, jessie-backports (Paul Wise)



When I read 
https://sources.debian.org/src/findutils/4.9.0-5/debian/locate.cron.daily/
I understand calling "updatedb" directly when it actually is
"updatedb.findutils",
can never work: all the PRUNExx etc... variable won't be defined.

So the "--slave /usr/bin/updatedb updatedb /usr/bin/updatedb.findutils \"
stanza here 
https://sources.debian.org/src/findutils/4.9.0-5/debian/locate.postinst/
is useless/botched-up.
updatedb.{mlocate|plocate} do what they are expected to do and
updatedb.findutils not.
So the 3 alternatives are unequal.

All the "locate" bugs are really old no, so I guess nobody cares:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=locate

Greetings

Le lun. 7 août 2023 à 16:10, Matus UHLAR - fantomas
 a écrit :
> I have configured locate.findutils to be my "locate" due to different
> behaviour when providing multiple file arguments.
>
> I know it's slower, and I can live with that.
>
> However, cruft-ng calling "updatedb" updates incorrect database this way, it
> also produces errors.

Bug#1042842: [Pkg-xen-devel] Bug#1042842: network interface names wrong in domU (>10 interfaces)

[Valentin Kleibel]

On [0], you can read "In both cases the device naming is subject to the 
usual guest or backend domain facilities for renaming network devices".

It says "naming/renaming", but you can assume "detecting".

I also checked which net_ids udev knows about and the only things that 
pop up are:

ID_NET_NAMING_SCHEME=v247
ID_NET_NAME_MAC=enx00163efd832b
ID_OUI_FROM_DATABASE=Xensource, Inc.


Is it from dom0 or domU ?
Are you using "net.ifnames=0" on the domU kernel command line ?
"v247" looks like systemd "predictive naming scheme" (eth -> enX).
 From bookworm on, domUs vifs get named enXN (enX0, enX1, ...).
Read on :
https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#xen-network


This is from the domU, running bullseye with a bookworm dom0.

See how ethN interfaces get messed up, like in your setup, but 
predictable names would work, as you can see in "altname enXN" :

eth1 (:01) -> enX1
eth2 (:10) -> enX10
eth3 (:02) -> enX2


I could not get our bullseye domU to show the "predictable names" even 
though i tried installing the bullseye-backports kernel 6.1.
After you wrote this i installed udev 252.5 from backports and it now 
uses the correct enXn interface names, even with kernel 5.10.


So, my answer does not tell you if something changed in Xen itself, only 
in Debian.
But I guess it relates to what Xen devs told us : vifs detection order 
cannot be relied upon, that's why "predictable names" were invented.
The vif detection part is related to the domains kernels, not Xen itself 
(at least that's what I understood).


Using eth0 nowadays is a bit like using /dev/sda for hard drives, it's 
considered legacy as it may create problems in some setups, like yours 
(ie. for disks, it's recommended to use UUIDs or /dev/disk/by-*).


I hope this answers your question.


Thank you, yes it does.

In our case the dom0 was updated to bookworm while the domU is still 
running bullseye.

-> updated Xen so the vif detection order changed (which we relied on)
-> the predictable network names for Xen don't work with bullseye

So my new resolution for bullseye domUs on a bookworm dom0 is to install 
udev from backports and change the domUs network config to use the new 
enXn naming scheme instead of ethn.

Bug#844688:

[Vicky Mathew]

My Name is Vicky Mathew Nelson, from the United State Of America. I want us
to be friends, okay please write to me now.

Bug#1043282: freeradius: TLS-Client-Cert-Common-Name contains incorrect value

[Åke Holmlund]

Package: freeradius
Version: 3.2.1+dfsg-4
Severity: important

Dear Maintainer,

We have a setup with TLS authentication where we use the CN of the client 
certificate ti check in LDAP if that CN has access to our VPN service. This was 
working fine in bullseye but breaks in bookworm. The reason is that 
TLS-Client-Cert-Common-Name no longer contains the CN from the client 
certificate but the CN from the CA certificate.

This is a known bug in freeradius 3.2.1 (see 
https://github.com/FreeRADIUS/freeradius-server/issues/4785) and is fixed in 
3.2.2. I REALLY hope this can be fixed ASAP in bookworm because we have had to 
skip the LDAP check to get our VPN working again and that is not a good thing.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
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 freeradius depends on:
ii  freeradius-common  3.2.1+dfsg-4
ii  freeradius-config  3.2.1+dfsg-4
ii  libc6  2.36-9+deb12u1
ii  libcrypt1  1:4.4.33-2
ii  libct4 1.3.17+ds-2
ii  libfreeradius3 3.2.1+dfsg-4
ii  libgdbm6   1.23-3
ii  libjson-c5 0.16-2
ii  libpam0g   1.5.2-6
ii  libperl5.365.36.0-7
ii  libreadline8   8.2-1.3
ii  libsqlite3-0   3.40.1-2
ii  libssl33.0.9-1
ii  libsystemd0252.12-1~deb12u1
ii  libtalloc2 2.4.0-f2
ii  libwbclient0   2:4.17.9+dfsg-0+deb12u3
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages freeradius recommends:
ii  freeradius-utils  3.2.1+dfsg-4

Versions of packages freeradius suggests:
pn  freeradius-krb5
ii  freeradius-ldap3.2.1+dfsg-4
pn  freeradius-mysql   
pn  freeradius-postgresql  
pn  freeradius-python3 
ii  snmp   5.9.3+dfsg-2

-- debconf information excluded

Bug#1043281: Aborts with "illegal hardware instruction" on i586 AMD Geode

[Marc Haber]

On Wed, Aug 09, 2023 at 12:09:50AM +1200, martin f krafft wrote:
> Anywhow, I cannot use sudo on either anymore, because if I do:
> 
> ```
> emily:~% sudo -l
> #(132 pts/0) 08 14:05:20.790
> [1]29199 illegal hardware instruction  sudo -l

Is this probably a duplicate of #1004894?

If so, this probably boils down on a GCC bug, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1043256: man.local: missing font transformation for 'C'

[Colin Watson]

Control: reassign -1 zip

On Mon, Aug 07, 2023 at 08:02:11PM -0500, G. Branden Robinson wrote:
> In my opinion, this bug should be reassigned to the zip package.

Agreed.  Reassigning there.

> Also, the correct term is "font translation", not "font transformation".
> 
> https://www.gnu.org/software/groff/manual/groff.html.node/Selecting-Fonts.html
> 
> At 2023-08-07T22:11:43+, Bjarni Ingi Gislason wrote:
> > Package: man-db
> > Version: 2.11.2-3
> > Severity: normal
> > 
> > Dear Maintainer,
> > man zip > /dev/null 
> > 
> >* What was the outcome of this action?
> > 
> > troff::175: warning: cannot select font 'C'
> > ...
> 
> Can reproduce.  This warning occurs many times, along with two others.
> 
> troff:zip.1:1675: warning: cannot select font 'N'
> troff:zip.1:2636: warning: escape character ignored before 'i'
> 
> These two appear to be due to typos.
> 
> >* What outcome did you expect instead?
> > 
> > No warnings.
> 
> These messages arise due to errors in the page sources; the formatter is
> unable to do what is being asked of it.
> 
> > File "/etc/groff/man.local" needs a font transformation
> > 
> > .if n .ftr C R
> 
> Colin Watson rejected this idea when Python docutils-generated man pages
> exhibited the same problem.  This issue has now been fixed upstream in
> python-docutils--the right place, in my opinion--and uploaded to Debian.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041809
> 
> zip(1) appears to have been composed directly by a human.  The page is
> (strictly speaking) buggy, and use of the `\fC` escape sequence is not
> portable across *roff implementations.  It is also ineffectual on
> terminal output devices regardless of implementation.
> 
> There are a number of related problems here.
> 
> * It's impossible to change font family or type size in an nroff
>   document.  Nevertheless, it is attempted commonly enough that GNU
>   troff (and all other troffs I know of) silently ignore such attempts.
> * Not all troffs even support the _concept_ of "font families"; you will
>   not find it in Ossanna troff or Kernighan troff.
> * Portable man pages must use only fonts named `R`, `I`, and `B`.  It is
>   consequently better to use man(7)'s facilities for switching fonts.
> * Even on typesetting devices, a font named `C` is not guaranteed to
>   exist.  As far as I can tell from my research over the years, this
>   font name was never supported by the troff in BSD Unix until it
>   replaced its AT troff with GNU troff.
> * AT device-independent troff, in lines of descent from Kernighan
>   troff (ca. 1980), _sometimes_ supported a font named `C`.  Sometimes
>   it was called `CW` instead.  Sometimes both were available.  Sometimes
>   it wasn't available at all.
> * There is no portable interface for testing the availability of a font
>   in the output device.  GNU troff supports `.if F` for this purpose;
>   AT troff and at least some of its descendants do not.
> 
> It appears to me that in most or all cases, zip(1) uses this 'C' font
> mark up literal input, like examples of command-line usage, on their own
> output lines.  That's good, because it suggests that the page can easily
> migrate to the EX/EE man(7) extension, first developed in Research Ninth
> Edition Unix (1986) and adopted by groff in 2007-2009.
> 
> To retain portability, since Info-ZIP likely wants to retain support for
> a huge variety of systems, the page could take the approach recently
> adopted by lexgrog(1) in the man-db project.
> 
> It looks like the upstream package hasn't been updated in 15 years.  I'm
> happy to prepare some patches to improve its man pages for the Debian
> package.  It looks like most of the corrections relevant to this bug
> report can be straightforwardly automated with sed(1).
> 
> I'm also happy to contribute some further correctness and portability
> issues to the page per groff_man_style(7).
> 
> Let me know.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1042842: [Pkg-xen-devel] Bug#1042842: network interface names wrong in domU (>10 interfaces)

[zithro]

On 08 Aug 2023 12:08, Valentin Kleibel wrote:

I posted on xen-devel, you can follow from :
https://lists.xenproject.org/archives/html/xen-devel/2023-08/msg00244.html
(Unfortunately, the formatting is weird via html, split the IRC part 
on "- ").


Thank you for posting upstream.


No prob, although if that very answer does not answer your question, I 
guess you'd be better off replying on xen-devel ML (reply to my post or 
at least reference it).


All documentation i found found on the Xen wiki suggests that interfaces 
are connected vifX.Y <-> ethY. [0] [1]
The only other way i know of for identifying the interfaces are MAC 
Addresses which can be randomly assigned if you don't configure them.


On [0], you can read "In both cases the device naming is subject to the 
usual guest or backend domain facilities for renaming network devices".

It says "naming/renaming", but you can assume "detecting".

I also checked which net_ids udev knows about and the only things that 
pop up are:

ID_NET_NAMING_SCHEME=v247
ID_NET_NAME_MAC=enx00163efd832b
ID_OUI_FROM_DATABASE=Xensource, Inc.


Is it from dom0 or domU ?
Are you using "net.ifnames=0" on the domU kernel command line ?
"v247" looks like systemd "predictive naming scheme" (eth -> enX).
From bookworm on, domUs vifs get named enXN (enX0, enX1, ...).
Read on :
https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#xen-network

Either i am missing the way you're supposed to do this, or there is a 
bug somewhere in the toolchain.
Unfortunately i'm not able to pinpoint the source of the issue, any help 
would be appreciated.


I made some tests with a domU using many interfaces, like :

[...]
vif = [ 'bridge=xbr-tst,mac=00:16:3e:de:bd:00,type=vif,vifname=domu-a' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:01,type=vif,vifname=domu-b' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:02,type=vif,vifname=domu-c' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:03,type=vif,vifname=domu-d' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:04,type=vif,vifname=domu-e' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:05,type=vif,vifname=domu-f' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:06,type=vif,vifname=domu-g' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:07,type=vif,vifname=domu-h' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:08,type=vif,vifname=domu-i' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:09,type=vif,vifname=domu-j' ,
'bridge=xbr-tst,mac=00:16:3e:de:bd:10,type=vif,vifname=domu-k' ,
]
[...]

-
This is dom0's corresponding dmesg:

[...]
xbr-tst: port 3(domu-b) entered blocking state
xbr-tst: port 3(domu-b) entered disabled state
device domu-b entered promiscuous mode
xbr-tst: port 4(domu-i) entered blocking state
xbr-tst: port 4(domu-i) entered disabled state
device domu-i entered promiscuous mode
[...]

Here you can see :
port 3 <-> domu-b
port 4 <-> domu-i

We learn here that dom0 did not detect vifs serially.

-
In the domU, "ip link" shows :

[...]
eth0
link/ether 00:16:3e:de:bd:00
altname enX0
eth1
link/ether 00:16:3e:de:bd:01
altname enX1
eth2
link/ether 00:16:3e:de:bd:10
altname enX10
eth3
link/ether 00:16:3e:de:bd:02
altname enX2
[...]

See how ethN interfaces get messed up, like in your setup, but 
predictable names would work, as you can see in "altname enXN" :

eth1 (:01) -> enX1
eth2 (:10) -> enX10
eth3 (:02) -> enX2

So, my answer does not tell you if something changed in Xen itself, only 
in Debian.
But I guess it relates to what Xen devs told us : vifs detection order 
cannot be relied upon, that's why "predictable names" were invented.
The vif detection part is related to the domains kernels, not Xen itself 
(at least that's what I understood).


Using eth0 nowadays is a bit like using /dev/sda for hard drives, it's 
considered legacy as it may create problems in some setups, like yours 
(ie. for disks, it's recommended to use UUIDs or /dev/disk/by-*).


I hope this answers your question.

Bug#1043281: Aborts with "illegal hardware instruction" on i586 AMD Geode

[martin f krafft]

Package: sudo
Version: 1.9.13p3-3
Severity: normal

I have two systems running the AMD Geode processor¹ and consequently 
the non-PAE kernel:

```
Linux gig 5.10.0-23-686 #1 SMP Debian 5.10.179-2 (2023-07-14) i586 GNU/Linux
```
and
```
Linux emily 6.1.0-10-686 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27) 
i586 GNU/Linux
```

Both have had the bookworm upgrade, but I've not rebooted the former 
yet, hence the 5.x kernel.

Anywhow, I cannot use sudo on either anymore, because if I do:

```
emily:~% sudo -l
#(132 pts/0) 08 14:05:20.790
[1]29199 illegal hardware instruction  sudo -l
```

which shows up in `dmesg` like so:

```
2023-08-08T14:06:32.666253+02:00 emily kernel: [206827.519200] traps: 
sudo[29332] trap invalid opcode ip:4ac030 sp:bfb3eedc error:0 in 
sudo[4ab000+2e000]
```

The system otherwise works fine, it's just `sudo` that's not usable.

¹) Here's the CPU data
```
emily:~% cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 10
model name  : Geode(TM) Integrated Processor by AMD PCS
stepping: 2
cpu MHz : 498.036
cache size  : 128 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 
3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips: 996.07
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:
```

-- 
 .''`.   martin f. krafft 
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1043118: victoriametrics: FTBFS: test failure

[Denys Holius]

Hello folks!

The latest version of VictoriaMetrics v1.92.0 
 should be marked 
as LTS but it has some backwards-incompatible changes. Meanwhile v1.87.6 
 was marked as 
LTS and maybe this version contains bugfix.


1. Could you please point me to a documentation which I can use to
   reproduce this bug?
2. Maybe we can make a bugfix or patch and send a PR to
   https://salsa.debian.org/go-team/packages/victoriametrics ?

On 06.08.23 12:16, Sebastian Ramacher wrote:

Source: victoriametrics
Version: 1.79.5+ds1-2
Severity: serious
Tags: ftbfs sid trixie
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=victoriametrics=amd64=1.79.5%2Bds1-2%2Bb6=1691274080=0

=== RUN   TestMergeForciblyStop
2023-08-05T22:21:13.980Zpanic   
VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows must 
accept at least one row
--- FAIL: TestMergeForciblyStop (0.00s)
panic: BUG: Inmemory.InitFromRows must accept at least one row [recovered]
panic: BUG: Inmemory.InitFromRows must accept at least one row

goroutine 31839 [running]:
testing.tRunner.func1.2({0x6f7a60, 0xc003b2e4b0})
/usr/lib/go-1.20/src/testing/testing.go:1526 +0x24e
testing.tRunner.func1()
/usr/lib/go-1.20/src/testing/testing.go:1529 +0x39f
panic({0x6f7a60, 0xc003b2e4b0})
/usr/lib/go-1.20/src/runtime/panic.go:884 +0x213
github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logMessage({0x742b44, 
0x5}, {0xc00507f300, 0x37}, 0x0?)

/<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:269
 +0x965
github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevelSkipframes(0x1, 
{0x742b44, 0x5}, {0x75c548?, 0xc00503fcc8?}, {0x0?, 0x90?, 0x72aba0?})

/<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:137
 +0x1a5
github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevel(...)

/<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:129
github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.Panicf(...)

/<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:125
github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.(*inmemoryPart).InitFromRows(0xc7ccf0,
 {0x0, 0x0, 0x0})

/<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/inmemory_part.go:37
 +0x5e
github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.newTestBlockStreamReader(0xca6150?,
 {0x0, 0x0, 0x0})

/<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/block_stream_reader_test.go:151
 +0x48
github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.TestMergeForciblyStop(0xc004101380)

/<>/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/merge_test.go:358
 +0xce
testing.tRunner(0xc004101380, 0x7e12e8)
/usr/lib/go-1.20/src/testing/testing.go:1576 +0x10b
created by testing.(*T).Run
/usr/lib/go-1.20/src/testing/testing.go:1629 +0x3ea
FAILgithub.com/VictoriaMetrics/VictoriaMetrics/lib/storage  10.215s

Cheers

Bug#1043280: libayatana-appindicator3-0.1-cil: Please drop gtk-sharp3 reverse dependencies

[Bastian Germann]

Package: libayatana-appindicator3-0.1-cil
Severity: wishlist
Version: 0.5.92-1

Your package (build)-depends on gtk-sharp3 and makes it a key package.
However, the libayatana-appindicator3-0.1-cil{-dev} packages are not used at 
all in Debian.
Please drop them so that the RC-buggy gtk-sharp3 can be autoremoved.

Bug#1043221: RFS: xutils-dev/1:7.7+7 [Team] -- X Window System utility programs for development

[Héctor Orón Martínez]

Hello,

  Based on your package and Manuel changes I pushed the following to Git...
  
https://salsa.debian.org/xorg-team/app/xutils-dev/-/commit/64b07596fbc43441cf555d9e4eeb8f2e35312967

  I want to check other bugs in the BTS before following up with an
upload to unstable.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#1043279: musicbrainzngs build-depends on dropped package

[Peter Green]

Package: musicbrainzngs
Version: 0.7.1-4
Severity: serious
Tags: trixie, sid
Justification: rc policy - "Packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

musicbrainzngs build-depends on python-libdiscid-doc which is no longer built by
the python-libdiscid source package. It is still present in unstable as a cruft
package, but is completely gone from testing.

Bug#1008159: [PATCH] More MIME file types and URI scheme handlers in thunderbird.desktop

[Max Nikulin]

On 05/08/2023 13:08, Carsten Schoenert wrote:


Could you please cut all these additions into own peaces/patches?
By this it's more visible what the addition of adding a specific handler
is made of. And using git blame will make it easier to find what content
was added by which commit.


See the attached files. They do not include text/x-calendar present in 
the original patch. I am in doubts if it frequently appears in the wild.


Frankly speaking, I have see a little value in splitting a commit that 
changes just single line. I would not even try to add multiple MimeType 
entries even if they would be supported by some frameworks. I believe 
the comment was detailed enough to review entries of the list.


I decided to try git sparse-checkout and I was significantly more 
optimistic how much data I have to get to make a series of commits 
changing just single line. 1G is too much from my point of view. Perhaps 
shallow clone could reduce it by several times.From 686cdc23ac3b6019db6fb2b7ebbc685fd08b6353 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 8 Aug 2023 17:55:59 +0700
Subject: [PATCH 1/4] d/thunderbird.desktop: Add IANA MIME type for .vcf vcard

Add registered text/vcard MIME type (RFC6350) in addition to
text/x-vcard.
---
 debian/thunderbird.desktop | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird.desktop b/debian/thunderbird.desktop
index 7ac4b218cb..c3e4be07ff 100644
--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -9,7 +9,7 @@ Type=Application
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird
-- 
2.25.1

From 190d4f66d5e04eb6b21f7da1de575b624d4fc1a9 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 8 Aug 2023 18:08:33 +0700
Subject: [PATCH 2/4] d/thunderbird.desktop: Add mid: URI to MIME types

Allow to handle mid: links supported since Thunderbird-87.
See RFC 2392 Content-ID and Message-ID Uniform Resource Locators.
(Closes: #1008159)
---
 debian/thunderbird.desktop | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird.desktop b/debian/thunderbird.desktop
index c3e4be07ff..96f79da0c2 100644
--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -9,7 +9,7 @@ Type=Application
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/vcard;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;text/calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird
-- 
2.25.1

From 5bd7a4741b38369e72b023ed473e03432a484ec4 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 8 Aug 2023 18:11:15 +0700
Subject: [PATCH 3/4] d/thunderbird.desktop: Add webcal: URI to MIME types

Allow to handle webcal: and webcals: links (iCalendar).
---
 debian/thunderbird.desktop | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird.desktop b/debian/thunderbird.desktop
index 96f79da0c2..d3f4b492fd 100644
--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -9,7 +9,7 @@ Type=Application
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;text/calendar;text/vcard;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird
-- 
2.25.1

From 1cd3524b4dd3036bfdb8759db9a7dad4b05914f4 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 8 Aug 2023 18:14:05 +0700
Subject: [PATCH 4/4] d/thunderbird.desktop: Add news: URI to MIME types

Allow to handle links to USENET articles having news: URI scheme

---
 debian/thunderbird.desktop | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird.desktop b/debian/thunderbird.desktop
index d3f4b492fd..b036ff5412 100644
--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -9,7 +9,7 @@ Type=Application
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/vcard;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/news;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird
-- 

Bug#1043278: libshumate-dev: file conflict in Multi-Arch package

[Matthias Geiger]

Package: libshumate-dev
Severity: normal
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I noticed this after uploading the latest libshumate version. The
Multi-Arch hinter states the following: "libshumte-dev conflicts on
/usr/share/gir-1.0/Shumate-1.0.gir on mips64el <-> amd64, arm64, armel
and 5 five more." 

This is a similar issue as #905715.

I'd appreciate help regarding this issue so I can fix this.

best,

Matthias


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

Kernel: Linux 6.4.7-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libshumate-dev depends on:
ii  gir1.2-shumate-1.0  1.0.3-2
ii  libcairo2-dev   1.16.0-7
ii  libglib2.0-dev  2.76.3-1
ii  libgtk-4-dev4.10.3+ds-1
ii  libshumate-1.0-11.0.3-2
ii  libsoup-3.0-dev 3.2.2-2
ii  libsqlite3-dev  3.40.1-2

libshumate-dev recommends no packages.

libshumate-dev suggests no packages.

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmTSIwMVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1OigQAKzE/vyKZ797WMMUIZgi8HrV8aB4
39c5qmkLUE8DGmTUflWYGw4ya4tvwG9s3nB7quECe3Yok8kdqOVRWeKgJFYGldsf
EF0qk+Dvp0rLSNj8cCPMHL962DBAgJ3Bhp5TNOEKxPnhcWE70lMq3rI6T3HZHvqh
4nZrUAKUWl0d753PnjMJWlhRohCgIpYjGoNQ0qKLKeIUNdzWW9S2ZozP+E6pZzVT
aTVuER1ItC4iSjcHk9RlzBpjAwv4isx88/u6TmLI6QQdRLuBILN0hT6i5RBLaJzR
ARJBg6ab9wGnQqJ1fSy5h2ofXIb8MDIqBa+blO5q4NHQQ/5nVr70Unah0wy/tSSu
FZQo8HZbjz36Vvrb3aeDAFbbzDKy/Cshs5N8m5N3gdinUv3g7ddnDYahGTk7SvqX
ux5s5YrVH6kitNmSc7CL4QdgxXt509836noGEERJ7MzpDGyDmdpqaKtwlosBXQrs
eypa46sc33mhZu7D4lV2chSBcdY3QQRlX4jwIGV/j1IzWrvWRu8RrzSonpAPKVZT
mKqPGUJeYT9CTDlAAskLn6YeEKeG/rKvI2rlph7XvPxd2PguPA0UTcQKP7UmrhoH
H5wdnOF2HMvliv4VBL7uqbli71wWmqbZqhTNgQ1cz3Znyi2rUQC1PHQOs7Xnt9IW
FLd0UzZ/zVd1iThM
=vwyh
-END PGP SIGNATURE-

Bug#1037419: closed by Julien Cristau (Re: Bug#1037419: mirror submission for mirrors.hostiserver.com)

[Igor Butsan]

Hello,
We’ve changed our config file to sync from debian.snt.utwente.nl 

Thank you

> On 31 Jul 2023, at 18:06, Debian Bug Tracking System  
> wrote:
> 
> This is an automatic notification regarding your Bug report
> which was filed against the mirrors package:
> 
> #1037419: mirror submission for mirrors.hostiserver.com
> 
> It has been closed by Julien Cristau .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Julien Cristau 
>  by
> replying to this email.
> 
> 
> -- 
> 1037419: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037419
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 
> From: Julien Cristau 
> Subject: Re: Bug#1037419: mirror submission for mirrors.hostiserver.com
> Date: 31 July 2023, 18:02:34 CEST
> To: Norby , 1037419-d...@bugs.debian.org
> 
> 
> On Mon, Jun 12, 2023 at 02:24:15PM +, Norby wrote:
>> Site: mirrors.hostiserver.com
> 
> According to your mirror's trace file, you're syncing from ftp.nl.debian.org.
> 
> o we recommend mirrors not sync directly from service aliases such as
>  ftp..debian.org (only http is guaranteed to be available at
>  ftp..d.o sites).  Maybe change your config to sync from
>  the site currently backing the ftp..debian.org service you sync
>  from?
> 
> Closing, feel free to resubmit afterwards.
> 
> Cheers,
> Julien
> 
> 
> From: "Norby" 
> Subject: mirror submission for mirrors.hostiserver.com
> Date: 12 June 2023, 16:24:15 CEST
> To: sub...@bugs.debian.org
> 
> 
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirrors.hostiserver.com
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Norby 
> Country: NL Netherlands
> Sponsor: IT Services company s.r.o. https://www.hostiserver.com
> 
> 
> 
> 
> Trace Url: http://mirrors.hostiserver.com/debian/project/trace/
> Trace Url: 
> http://mirrors.hostiserver.com/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://mirrors.hostiserver.com/debian/project/trace/mirrors.hostiserver.com
> 
> 

Bug#1043201: slirp: immediate exit at startup

[Roberto Lumbreras]

Hi Ferenc,

timeout is defined as "struct timeval":

   struct timeval {
   time_t   tv_sec;   /* Seconds */
   suseconds_t  tv_usec;  /* Microseconds */
   };

timeout.tv_used is suseconds_t == time_t == int, so I can't understand why
it's unsigned in your case.

If you dig in src/main.c there are more lines with timeout.tv_used being
compared with negative numbers, your patch may work but I think it has to
be something else.

Have you tried just compiling the slirp package? Maybe it's a problem with
libc6 linking, https://tracker.debian.org/pkg/slirp warns that slirp "Fails
to build during reproducibility testing". I'm looking into this.

-- 
Regards,
Roberto Lumbreras
Debian developer