Bug#976805: Progress?

[M. Zhou]

https://salsa.debian.org/pkg-security-team/imhex
I forgot the current status. In my fuzzy memory there
are some new dependencies to be packaged.

On Sat, 2022-07-30 at 11:07 -0700, Dima Kogan wrote:
> Hi. Is this coming along? What needs to happen to get this into the
> repos? Do you need help?
> 
> Thanks!

Bug#1016462: ITP: wtforms-test -- unit test helpers for WTForms forms

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
j...@nahmias.net, kon...@fastmonkeys.com

* Package name: wtforms-test
  Version : 0.1.1
  Upstream Author : Konsta Vesterinen 
* URL : https://github.com/kvesteri/wtforms-test
* License : BSD
  Programming Lang: Python
  Description : pytest helpers for WTForms

 WTForms-Test provides various pytest unittest helpers for testing WTForms
 based forms. Includes checks for a field's existence on a form, and various
 attributes on a field such as: validators, min/max length, description,
 optional/required, etc...

Bug#1015845: about gtkhash ITA

[肖盛文]

Hi Jeremy,

    The gtkhash upstream author had update the issue "Add support for
GTK 4 #41"

https://github.com/tristanheaven/gtkhash/issues/41

Perhaps the gtkhash will support GTK4 in the next.


在 2022/7/29 18:42, Jeremy Bicha 写道:
> The next version of Nautilus, 43, will switch to GTK4. I believe this
> will break all Nautilus extensions. I intend to file a bug about it
> for all packaged Nautilus extensions soon.
>
> The gtkhash package would still be useful since it offers extensions
> for other file managers.
>
> Thank you,
> Jeremy Bicha
Regards,

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016461: ITP: wtforms-alchemy -- Tools for creating WTForms forms from SQLAlchemy models

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
j...@nahmias.net, kon...@fastmonkeys.com

* Package name: wtforms-alchemy
  Version : 0.18.0
  Upstream Author : Konsta Vesterinen 
* URL : https://github.com/kvesteri/wtforms-alchemy
* License : BSD
  Programming Lang: Python
  Description : Tools for creating WTForms forms from SQLAlchemy models

 WTForms-Alchemy provides a helper class that let you create a Form class
 from a SQLAlchemy model. It does not try to replace all the functionality
 of wtforms.ext.sqlalchemy, only the model_form function of
 wtforms.ext.sqlalchemy by a much better solution. Other functionality of
 .ext.sqlalchemy such as QuerySelectField and QuerySelectMultipleField can be
 used along with WTForms-Alchemy.
 .
 The benefits of WTForms-Alchemy ModelForm over wtforms.ext.sqlachemy’s
 model_form include:
 .
  * Provides explicit declaration of ModelForms (much easier to override
certain columns)
  * Form generation supports Unique and NumberRange validators
  * Form inheritance support (along with form configuration inheritance)
  * Automatic SelectField type coercing based on underlying column type
  * By default uses wtforms_components SelectField for fields with choices.
This field understands None values and renders nested datastructures as
optgroups.
  * Provides better Unique validator
  * Supports custom user defined types as well as type decorators
  * Supports SQLAlchemy-Utils datatypes
  * Supports ModelForm model relations population
  * Smarter field exclusion
  * Smarter field conversion
  * Understands join table inheritance
  * Better configuration

Bug#1016460: ITP: wtforms-json -- smart json support for WTForms

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
kon...@fastmonkeys.com, j...@nahmias.net

* Package name: wtforms-json
  Version : 0.3.5
  Upstream Author : Konsta Vesterinen 
* URL : https://github.com/kvesteri/wtforms-json
* License : BSD
  Programming Lang: Python
  Description : smart json support for WTForms

 WTForms-JSON is a WTForms extension for JSON data handling. It:
 .
  * Adds support for booleans (WTForms doesn’t know how to handle
False boolean values)
  * Adds support for None type FormField values
  * Adds support for None type Field values
  * Support for patch data requests with patch_data Form property
  * Function for converting JSON data into dict that WTForms
understands (flatten_json() function)

This package is a dependency for superset.
I plan to maintain this as part of the Debian Python Team (DPT).

Bug#1016459: firefox: Missing debug symbols for /usr/lib/firefox/libxul.so

[Leonard Lausen]

Package: firefox
Version: 103.0-1
Severity: important
X-Debbugs-Cc: leon...@lausen.nl

Dear Maintainer,

I'm reporting an upstream bug regarding faulty GPU detection on aarch64
systems, which requires analysis of a coredump involving
/usr/lib/firefox/libxul.so, but debug symbols are missing.

I understand there used to be a firefox-dbgsym package, but it exists no more,
at least not for v103. Could you please reintroduce the dbgsym package or
ensure that the firefox package contains sufficient debug symbols, including
the symbols for /usr/lib/firefox/libxul.so?

gdb firefox ~/core.6030
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00777dd63310 in ?? () from /usr/lib/firefox/libxul.so
(gdb) bt
#0  0x00777dd63310 in  () at /usr/lib/firefox/libxul.so
#1  0x007784b69e2c in __run_exit_handlers
(status=1, listp=0x7784ca3660 <__exit_funcs>, 
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at 
exit.c:108
#2  0x007784b69fbc in __GI_exit (status=) at exit.c:139
#3  0x00777925fda4 in  () at /usr/lib/aarch64-linux-gnu/libpci.so.3
#4  0x007779260108 in pci_init () at /usr/lib/aarch64-linux-gnu/libpci.so.3
#5  0x00777dd72afc in  () at /usr/lib/firefox/libxul.so
#6  0x00777dd734ac in  () at /usr/lib/firefox/libxul.so
#7  0x00777dd66f00 in  () at /usr/lib/firefox/libxul.so
#8  0x00777dd6ddcc in  () at /usr/lib/firefox/libxul.so
#9  0x00777dd6e364 in  () at /usr/lib/firefox/libxul.so
#10 0x00653977d098 in  ()
#11 0x00653977c470 in  ()
#12 0x007784b54614 in __libc_start_main
 (main=0x653977c310, argc=1, argv=0x7ff4f01e98, init=, 
fini=, rtld_fini=, stack_end=) at 
../csu/libc-start.c:332
#13 0x00653977c778 in _start ()


For reference, the faulty GPU detection in question generates the following 
output:

  [GFX1-]: No GPUs detected via PCI 
  [GFX1-]: glxtest: process failed (received signal 11)

Thank you!

-- Package-specific info:

-- Extensions information

-- Addons package information

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.19.0-stb-cbq (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils  5.7-0.2
ii  fontconfig   2.13.1-4.4
ii  libasound2   1.2.7.2-1
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-8
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-2
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.1.0-7
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-2
ii  libglib2.0-0 2.72.3-1
ii  libgtk-3-0   3.24.34-1
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.81-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  libstdc++6   12.1.0-7
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:3.3.17-7+b1
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages firefox recommends:
ii  libavcodec59  7:5.0.1-3+b1

Versions of packages firefox suggests:
pn  fonts-lmodern  
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20-1
ii  pulseaudio 15.0+dfsg1-4+b1

-- no debconf information

Bug#1015845: about gtkhash ITA

[肖盛文]

Control: retitle 1015845 ITA: gtkhash -- GTK+ utility for computing
checksums and more


Hi Arnaud,

    Thanks for you reply.

The gtkhash had release new version 1.4,

I'll do update and review the patches in kali:
https://gitlab.com/kalilinux/packages/gtkhash/-/tree/kali/master/debian/patches


Regards,

在 2022/7/29 16:06, Arnaud Rebillout 写道:
> Hello Sheng Wen,
>
> please feel free to ITA this package. I don't have much time to work
> on it myself.
>
> Don't forget to have a look at
> https://gitlab.com/kalilinux/packages/gtkhash and cherry-pick any
> commit you need from there!
>
> Thanks for reaching out, and thanks for taking care of gtkhash,
>
> Regards,
>

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016458: bullseye-pu: package dovecot/2.3.13+dfsg1-2+deb11u1

[Noah Meyerhans]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Dovecot 2.3.13+dfsg1-2+deb11u1 contains a backported fix for #1016351
(CVE-2022-30550).  The fix is cherry-picked from upstream and is identical
to the fix recently uploaded to unstable in dovecot_2.3.19.1+dfsg1-2.  The
stable security team and the package maintainers have determined that this
issue does not warrant a DSA and should be fixed in the next bullseye
point release.

Debdiff is attached.  Note that it contains one additional minor change to
switch the salsa gitlab ci configuration to use bullseye runners.

noah
diff -Nru dovecot-2.3.13+dfsg1/debian/changelog 
dovecot-2.3.13+dfsg1/debian/changelog
--- dovecot-2.3.13+dfsg1/debian/changelog   2021-07-20 08:05:19.0 
-0700
+++ dovecot-2.3.13+dfsg1/debian/changelog   2022-07-31 17:47:06.0 
-0700
@@ -1,3 +1,10 @@
+dovecot (1:2.3.13+dfsg1-2+deb11u1) bullseye; urgency=medium
+
+  * [4b5dac8] d/patches: cherry-pick fix for CVE-2022-30550 (Closes: #1016351)
+  * [597ba7f] salsa-ci: build with bullseye
+
+ -- Noah Meyerhans   Sun, 31 Jul 2022 17:47:06 -0700
+
 dovecot (1:2.3.13+dfsg1-2) unstable; urgency=high
 
   * Import upstream fixes for security issues (Closes: #990566):
diff -Nru 
dovecot-2.3.13+dfsg1/debian/patches/auth-Add-a-comment-about-updating-userdb_find.patch
 
dovecot-2.3.13+dfsg1/debian/patches/auth-Add-a-comment-about-updating-userdb_find.patch
--- 
dovecot-2.3.13+dfsg1/debian/patches/auth-Add-a-comment-about-updating-userdb_find.patch
 1969-12-31 16:00:00.0 -0800
+++ 
dovecot-2.3.13+dfsg1/debian/patches/auth-Add-a-comment-about-updating-userdb_find.patch
 2022-07-31 17:47:06.0 -0700
@@ -0,0 +1,22 @@
+From: Timo Sirainen 
+Date: Mon, 16 May 2022 14:58:45 +0200
+Subject: auth: Add a comment about updating userdb_find()
+
+---
+ src/auth/userdb.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+Index: dovecot/src/auth/userdb.c
+===
+--- dovecot.orig/src/auth/userdb.c
 dovecot/src/auth/userdb.c
+@@ -162,7 +162,8 @@ userdb_preinit(pool_t pool, const struct
+   userdb->id = ++auth_userdb_id;
+   userdb->iface = iface;
+   userdb->args = p_strdup(pool, set->args);
+-
++  /* NOTE: if anything else than driver & args are added here,
++ userdb_find() also needs to be updated. */
+   array_push_back(_modules, );
+   return userdb;
+ }
diff -Nru 
dovecot-2.3.13+dfsg1/debian/patches/auth-Fix-handling-passdbs-with-identical-driver-args-but-.patch
 
dovecot-2.3.13+dfsg1/debian/patches/auth-Fix-handling-passdbs-with-identical-driver-args-but-.patch
--- 
dovecot-2.3.13+dfsg1/debian/patches/auth-Fix-handling-passdbs-with-identical-driver-args-but-.patch
 1969-12-31 16:00:00.0 -0800
+++ 
dovecot-2.3.13+dfsg1/debian/patches/auth-Fix-handling-passdbs-with-identical-driver-args-but-.patch
 2022-07-31 17:47:06.0 -0700
@@ -0,0 +1,130 @@
+From: Timo Sirainen 
+Date: Mon, 9 May 2022 15:23:33 +0300
+Subject: auth: Fix handling passdbs with identical driver/args but different
+ mechanisms/username_filter
+
+The passdb was wrongly deduplicated in this situation, causing wrong
+mechanisms or username_filter setting to be used. This would be a rather
+unlikely configuration though.
+
+Fixed by moving mechanisms and username_filter from struct passdb_module
+to struct auth_passdb, which is where they should have been in the first
+place.
+---
+ src/auth/auth-request.c |  6 +++---
+ src/auth/auth.c | 18 ++
+ src/auth/auth.h |  5 +
+ src/auth/passdb.c   | 15 ++-
+ src/auth/passdb.h   |  4 
+ 5 files changed, 28 insertions(+), 20 deletions(-)
+
+Index: dovecot/src/auth/auth-request.c
+===
+--- dovecot.orig/src/auth/auth-request.c
 dovecot/src/auth/auth-request.c
+@@ -553,8 +553,8 @@ auth_request_want_skip_passdb(struct aut
+ struct auth_passdb *passdb)
+ {
+   /* if mechanism is not supported, skip */
+-  const char *const *mechs = passdb->passdb->mechanisms;
+-  const char *const *username_filter = passdb->passdb->username_filter;
++  const char *const *mechs = passdb->mechanisms;
++  const char *const *username_filter = passdb->username_filter;
+   const char *username;
+ 
+   username = request->fields.user;
+@@ -567,7 +567,7 @@ auth_request_want_skip_passdb(struct aut
+   return TRUE;
+   }
+ 
+-  if (passdb->passdb->username_filter != NULL &&
++  if (passdb->username_filter != NULL &&
+   !auth_request_username_accepted(username_filter, username)) {
+   auth_request_log_debug(request,
+  request->mech != NULL ? AUTH_SUBSYS_MECH
+Index: dovecot/src/auth/auth.c

Bug#1016395: Kernel 5.18.15 does not fix it.

[Linas Vepstas]

I just attempted a hand-build of kernel 5.18.15 and it exhibits exactly the
same failure, the same stack traces. (hand-built means cp /boot/config;
make old-config; make deb-pkg; dpkg -i)

--linas

Bug#1016457: clif: non-DFSG source code in clif

[Joao Eriberto Mota Filho]

Package: clif
Version: 0.90.2-1
Severity: serious
Tags: upstream
Justification: Policy 2.2.1
X-Debbugs-Cc: eribe...@debian.org

The file ch-lex.c doesn't have a license on its header. However, starting at
line 927, I noticed the following text:

--
/*  Copyright (c) 1989 AT */
/*All Rights Reserved   */

/*  THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT */
/*  The copyright notice above does not evidence any*/
/*  actual or intended publication of such source code. */

#pragma ident   "@(#)ncform 6.8 95/02/11 SMI"
--

It's clear to me that part of the file includes a non-free source code.

Eriberto

Bug#1016456: coreutils: who default isn't -s, -s doesn't force "only name, line, and time" output

[наб]

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

Quoth who(1):
-- >8 --
   -s, --short
  print only name, line, and time (default)
-- >8 --

Compare who -H:
-- >8 --
NAME LINE TIME COMMENT
nabijaczleweli pts/02022-07-31 14:33 (192.168.1.109)
nabijaczleweli pts/22022-07-31 16:22 (192.168.1.109)
nabijaczleweli pts/32022-07-31 16:22 (192.168.1.109)
misiopts/42022-07-31 16:23 (192.168.1.1)
-- >8 --
(and note that the columnation is broken like in pinky (#1016117)).

Problem 1:is not the default output.


Quoth POSIX Issue 7:
-- >8 --
-s
[XSI] [Option Start] List only the
, , and  fields.
This is the default case. [Option End]
-- >8 --

I think it's reasonable to have the default output also have ,
but it's non-conformant to have no way (I think?) to hide it.

This also contradicts the manual.

Best,
наб

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

[Forest]

On Sun, 31 Jul 2022 12:30:42 +0200, Diederik de Haas wrote:

>From the partial logs you shared it appeared that your network also went down 
>after (quite) some time,

If you're referring to my 5.14.0-1 kernel log, I can't offer any insight, as
I only tried that kernel briefly, nearly a year ago.

If you mean the 5.10 kernel, let me clarify:

1. 5.10 reliably brings up eth0 early enough for dropbear sshd to work. 
2. I ssh to dropbear, enter the LUKS passphrase, and the root filesystem is
unlocked.
3. When eth0 fails, it's always shortly after that, still during system
startup.
4. Once I notice, attach a serial terminal, and reload the kernel module,
eth0 comes up and stays up. It doesn't go down again later.

I find it curious that eth0 comes up reliably and then *sometimes* goes down
shortly afterward.  I don't know if it's completely random or something
later in the startup process is triggering it.

Obviously, a delay between eth0 first coming up and when it goes down could
be partly from the time it takes me to ssh and type a LUKS passphrase.

>What's odd then is that that commit has been applied/backported to the 5.10 
>kernel under commit 97653ba562b9b28e30a3fcff42531e05a434d58c which is part of 
>5.10.82, so also 5.10.127-2 ...

Ah, I didn't notice that patch having been backported with a different
commit ID.  Thanks for mentioning it.

Bug#1016323: gnuplot: FTBFS: dvips: DVI file can't be opened: gnuplot.dvi: No such file or directory

[Hilmar Preuße]

Control: reassign -1 src:gnuplot


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016323: gnuplot: FTBFS: dvips: DVI file can't be opened: gnuplot.dvi: No such file or directory

[Hilmar Preuße]

Am 31.07.2022 um 15:38 teilte Adrian Bunk mit:

Control: reassign -1 src:gnuplot

Hi,


It works after downgrading texlive-latex-base to 2022.20220605-1.

Testcase:

$ cat test.tex
\documentclass{article}
\usepackage[utf8x]{inputenc}
\usepackage{hyperref}
\begin{document}
.
\end{document}
Many thanks for your minimal example. According to upstream (David 
Carlisle) one should avoid using utf8x and instead switch to utf8 
instead (see [1]). Consider to replace utf8x to utf8. Feel free to call 
back if this does not solve the issue.


Hilmar

[1] https://tex.stackexchange.com/q/652187/50836
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016055: fmtutil failed. Output has been stored in

[Hilmar Preuße]

Am 31.07.2022 um 15:50 teilte Klaus Ethgen mit:

Hi,


Some additional informations:

Yesterday I found files from texlive-pictures with 0 bytes size. I
reinstalled that package and the files have correct size now.

This sounds like a full file system during installation, which can lead 
to various issues like this. I suggest to close the issue as "caused by 
full file system".


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014633: linux-headers-5.19.0-rc4-common: file check-local-export does not exist

[Andreas Beckmann]

Followup-For: Bug #1014633

What about adding a superficial autopkgtest that tries to compile a
dummy third-party kernel module using kbuild? That should help noticing
such breakage earlier.


Andreas

Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case

[Sean Whitton]

Package: cryptsetup-initramfs
Version: 2:2.3.7-1+deb11u1

Dear maintainer,

I'm building disk images with an ext4 rootfs on LVM on LUKS.  I put a
PARTUUID in the /etc/crypttab of the image's rootfs, like this:

  erebus_crypt PARTUUID=13b9dfdf-04a2-4c97-a241-fe6cdfe76f68 none 
luks,discard,initramfs

I then run 'update-initramfs -u' while chrooted into the image's rootfs,
and the cryptsetup-initramfs scripts put this line in cryptroot/crypttab
in the initramfs:

  erebus_crypt /dev/mapper/loop0p2 none luks,discard,initramfs

So, the PARTUUID= source is being mapped to a /dev/mapper source, which
I think is the work of the fix for #902943.  It's the same for UUID=.

The problem is that /dev/mapper/loop0p2 is valid only on the
image-building host, and not on the host that will actually try to boot
the image.  Indeed, that's the whole reason I am using a PARTUUID, so
that it will stay valid.  So it looks like the fix for #902943 has
broken this sort of use case.  It would be great to have some way to
cause the PARTUUID to be passed through unchanged.

Thanks.

-- 
Sean Whitton

Bug#1016424: “Error: /invalidfileaccess in --file--” when converting PBM file to PDF

[Jonas Smedegaard]

Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=705699

Quoting anonymous coward (2022-07-31 21:46:27)
> > Therefore please report the issue upstream.
> 
> I just happened to have an account on the upstream bug tracker that
> still works, so I reported here:
> 
>   https://bugs.ghostscript.com/show_bug.cgi?id=705699

Thanks!

[ notes on how I should do my work in Debian snipped ]


 - Jonas

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

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

signature.asc
Description: signature

Bug#1016129: (no subject)

[Thorsten Glaser]

tags 1016129 + patch buster bullseye bookworm sid
thanks

Upstream discussion managed to find the precise fix for pcap 1.10
compatibility that’s missing in Debian’s version:
https://github.com/fgont/ipv6toolkit/issues/78#issuecomment-1197453179

debdiff (±version) attached. Would you prefer for me to NMU, do a
maintainer-agreed regular upload (as -2), or handle this yourself,
Octavio?

Tagging bullseye *and* buster because this must be fixed in these
releases as well:

• the bullseye package, as-is, is broken, so this is an RC fix there
• buster “as-is” works but if libpcap0.8 is upgraded, either via
  buster-backports or by mixing buster and bullseye packages, it’ll
  break (and we cannot retrofit a matching Breaks to libpcap0.8 in
  bullseye any more now it’s released) so buster’s will either need
  the patch applied or a versioned depends on libpcap0.8 (<< 1.10)

Will you communicate with the SRM or do you wish for me to handle that?

Thanks in advance,
//mirabilos
-- 
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
   veni, vidi, fixi(t) ;-)diff -Nru ipv6toolkit-2.0+ds.1/debian/changelog 
ipv6toolkit-2.0+ds.1/debian/changelog
--- ipv6toolkit-2.0+ds.1/debian/changelog   2020-08-05 06:21:55.0 
+0200
+++ ipv6toolkit-2.0+ds.1/debian/changelog   2022-07-31 21:43:23.0 
+0200
@@ -1,3 +1,10 @@
+ipv6toolkit (2.0+ds.1-1.1~~) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for pcap 1.10 compatibility (Closes: #1016129)
+
+ -- Thorsten Glaser   Sun, 31 Jul 2022 21:43:23 +0200
+
 ipv6toolkit (2.0+ds.1-1) unstable; urgency=medium
 
   * Refreshed patches using gbp pq export. Added:
diff -Nru 
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
 
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
--- 
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
  1970-01-01 01:00:00.0 +0100
+++ 
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
  2022-07-31 21:43:17.0 +0200
@@ -0,0 +1,25 @@
+Applied-Upstream: commit:03b0fdd42cf36c0070472afbb9b81a9ca62e1109
+From: Fernando Gont 
+Subject: Set pcap timeout to 1 for all platforms.
+Author: Leonard Marschke (lmm-git)
+
+--- a/tools/libipv6.h
 b/tools/libipv6.h
+@@ -123,12 +123,17 @@ struct filters{
+   #define PCAP_NETMASK_UNKNOWN0x
+ #endif
+ 
++/* XXX:
++At some point we were setting the timeout differently for different 
platforms. Should double-check, but doesn't seem to make sense.
++
+ #if defined (__FreeBSD__) || defined(__NetBSD__) || defined (__OpenBSD__) || 
defined(__APPLE__) || defined(__FreeBSD_kernel__) || defined(sun) || 
defined(__sun)
+   #define PCAP_TIMEOUT1
+ #else
+   #define PCAP_TIMEOUT0
+ #endif
++*/
+ 
++#define   PCAP_TIMEOUT1
+ 
+ #define PCAP_IPV6_FILTER  "ip6"
+ #define PCAP_TCPV6_FILTER "ip6 and tcp"
diff -Nru ipv6toolkit-2.0+ds.1/debian/patches/series 
ipv6toolkit-2.0+ds.1/debian/patches/series
--- ipv6toolkit-2.0+ds.1/debian/patches/series  2020-08-05 06:21:55.0 
+0200
+++ ipv6toolkit-2.0+ds.1/debian/patches/series  2022-07-31 21:42:09.0 
+0200
@@ -5,3 +5,4 @@
 0005-Silence-compiler-warnings.patch
 0006-Silence-misleading-indentation-warnings.patch
 0007-strncpy-len-must-include-the-terminating-nul-byte.patch
+03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch

Bug#1016454: megadepth: autopkgtest failure on s390x: segmentation fault

[Paul Gevers]

Source: megadepth
Version: 1.2.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package megadepth, great. 
However, it fails on s390x. Currently this failure is blocking the 
migration to testing [1]. Can you please investigate the situation and 
fix it?


I copied some of the output at the bottom of this report.

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/s390x/m/megadepth/23583699/log.gz

Running Tests
Test 1
building whole annotation region map done
2 chromosomes for annotated regions read
0 chromosomes for annotated regions read, collapsed
total number of annotations in collapsed: 0
Processing BAM: "tests/test_noprefix.bam"
/tmp/autopkgtest-lxc.gmfzuwos/downtmp/build.jJn/src/debian/tests/run-unit-test: 
line 33:  1590 Segmentation fault  megadepth tests/test_noprefix.bam 
--prefix test.bam --threads 4 --bigwig --auc --min-unique-qual 10 
--annotation tests/test_exons.bed --frag-dist --alts --include-softclip 
--only-polya --read-ends --test-polya --no-annotation-stdout 
--no-auc-stdout --filter-out 260 --add-chr-prefix human

autopkgtest [04:42:40]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016453: python-tornado breaks python-bonsai autopkgtest: 'TornadoLDAPConnectionTest' object has no attribute 'should_close_asyncio_loop'

[Paul Gevers]

Source: python-tornado, python-bonsai
Control: found -1 python-tornado/6.2.0-1
Control: found -1 python-bonsai/1.3.0+ds-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
python-tornado from testing6.2.0-1
python-bonsai  from testing1.3.0+ds-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

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


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

Paul

[1] https://qa.debian.org/excuses.php?package=python-tornado

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-bonsai/24205871/log.gz

=== FAILURES 
===
 TornadoLDAPConnectionTest.test_add_and_delete 
_


self = testMethod=test_add_and_delete>


def tearDown(self) -> None:
# Native coroutines tend to produce warnings if they're not
# allowed to run to completion. It's difficult to ensure that
# this always happens in tests, so cancel any tasks that are
# still pending by the time we get here.
asyncio_loop = self.io_loop.asyncio_loop  # type: ignore
if hasattr(asyncio, "all_tasks"):  # py37
tasks = asyncio.all_tasks(asyncio_loop)  # type: ignore
else:
tasks = asyncio.Task.all_tasks(asyncio_loop)
# Tasks that are done may still appear here and may contain
# non-cancellation exceptions, so filter them out.
tasks = [t for t in tasks if not t.done()]  # type: ignore
for t in tasks:
t.cancel()
# Allow the tasks to run and finalize themselves (which means
# raising a CancelledError inside the coroutine). This may
# just transform the "task was destroyed but it is pending"
# warning into a "uncaught CancelledError" warning, but
# catching CancelledErrors in coroutines that may leak is
# simpler than ensuring that no coroutines leak.
if tasks:
done, pending = self.io_loop.run_sync(lambda: 
asyncio.wait(tasks))

assert not pending
# If any task failed with anything but a CancelledError, 
raise it.

for f in done:
try:
f.result()
except asyncio.CancelledError:
pass

# Clean up Subprocess, so it can be used again with a new ioloop.
Subprocess.uninitialize()
with warnings.catch_warnings():
warnings.simplefilter("ignore", DeprecationWarning)
self.io_loop.clear_current()
if not isinstance(self.io_loop, _NON_OWNED_IOLOOPS):
# Try to clean up any file descriptors left open in the ioloop.
# This avoids leaks, especially when tests are run repeatedly
# in the same process with autoreload (because curl does not
# set FD_CLOEXEC on its file descriptors)
self.io_loop.close(all_fds=True)
>   if self.should_close_asyncio_loop:
E   AttributeError: 'TornadoLDAPConnectionTest' object has no 
attribute 'should_close_asyncio_loop'


/usr/lib/python3/dist-packages/tornado/testing.py:282: AttributeError
__ TornadoLDAPConnectionTest.test_connection 
___


self = 

def tearDown(self) -> None:
# Native coroutines tend to produce warnings if they're not
# allowed to run to completion. It's difficult to ensure that
# this always happens in tests, so cancel any tasks that are
# still pending by the time we get here.
asyncio_loop = self.io_loop.asyncio_loop  # type: ignore
if hasattr(asyncio, "all_tasks"):  # py37
tasks = asyncio.all_tasks(asyncio_loop)  # type: ignore
else:
tasks = asyncio.Task.all_tasks(asyncio_loop)
# Tasks that are done may still appear here and may contain
# non-cancellation exceptions, so filter them out.
tasks = [t for t in tasks if not t.done()]  # type: ignore
for t in tasks:
t.cancel()
# Allow the tasks to run and finalize themselves (which means
# raising a CancelledError inside the coroutine). This may
# just transform the "task was destroyed but it is pending"

Bug#1016452: loggerhead: autopkgtest regression: No module named 'loggerhead.tests'

[Paul Gevers]

Source: loggerhead
Version: 1.19~bzr524-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
loggerhead from testing1.19~bzr524-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/l/loggerhead/24205849/log.gz

running 0 tests...
brz selftest: /usr/bin/brz
   /usr/lib/python3/dist-packages/breezy
   bzr-3.2.2 python-3.10.5 Linux-5.10.0-16-amd64-x86_64-with-glibc2.33

unittest.loader._FailedTest.breezy.plugins.loggerheadERROR1ms
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/breezy/plugins/loggerhead/__init__.py", 
line 112, in load_tests

from .loggerhead.tests import test_suite
ModuleNotFoundError: No module named 'breezy.plugins.loggerhead.loggerhead'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/breezy/plugins/loggerhead/__init__.py", 
line 114, in load_tests

from loggerhead.tests import test_suite
ModuleNotFoundError: No module named 'loggerhead.tests'

==
ERROR: unittest.loader._FailedTest.breezy.plugins.loggerhead
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):
  File 
"/usr/lib/python3/dist-packages/breezy/plugins/loggerhead/__init__.py", 
line 112, in load_tests

from .loggerhead.tests import test_suite
ModuleNotFoundError: No module named 'breezy.plugins.loggerhead.loggerhead'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/breezy/plugins/loggerhead/__init__.py", 
line 114, in load_tests

from loggerhead.tests import test_suite
ModuleNotFoundError: No module named 'loggerhead.tests'

--
Ran 1 test in 0.087s

FAILED (errors=1)
autopkgtest [12:12:39]: test testsuite



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015904: r-cran-profvis_0.3.7+dfsg-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sat, Jul 30, 2022 at 07:06:38PM + schrieb Thorsten Alteholz:
> please also mention profvis/inst/htmlwidgets/lib/profvis/scroll.js in your 
> debian/copyright.

Fixed in new upload.

Thanks a lot for thorough checking

 Andreas. 

-- 
http://fam-tille.de

Bug#1016450: gdcm: autopkgtest failure on s390x

[Paul Gevers]

Source: gdcm
Version: 3.0.13-2
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package gdcm, great. However, 
it fails on s390x. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it? Please 
be aware that s390x is big-endian and the only be architecture we run 
autopkgtests for.


I copied some of the output at the bottom of this report.

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/s390x/g/gdcm/23826805/log.gz

Running Tests
PASS
MediaStorage is 1.2.840.10008.5.1.4.1.1.6.1 [Ultrasound Image Storage]
TransferSyntax is 1.2.840.10008.1.2 [Implicit VR Little Endian: Default 
Transfer Syntax for DICOM]
gdcminfo: ./Source/MediaStorageAndFileFormat/gdcmLookupTable.cxx:173: 
virtual void 
gdcm::LookupTable::SetLUT(gdcm::LookupTable::LookupTableType, const 
unsigned char*, unsigned int): Assertion 
`Internal->Length[type]*(BitSample/8) == length' failed.
/tmp/autopkgtest-lxc.q54akkws/downtmp/build.vE1/src/debian/tests/run-unit-test: 
line 26:  6180 Aborted gdcminfo gdcm-US-ALOKA-16.dcm

autopkgtest [10:00:10]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016451: shorewall takes more than 300 seconds to start if /etc/shorewall/blrules contains a lot of lines

[pseudo]

Package: shorewall
Version: 5.2.3.4-1
Severity: minor
Tags: upstream

Dear debian Maintainer,


   * What led up to the situation?
I installed shorewall, everything worked fine.
Since I filled /etc/shorewall/blrules with ~4000 lines, shorewall takes 
huge time to start
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
Packet Filter takes 0.3 sec to start with the same blacklist.
   * What's relevant logs?
Here is /var/log/shorewall-init.log
[...]
Jul 31 21:04:43Conntrack rule "CT:helper:pptp:PO - - tcp 1723" Compiled
Jul 31 21:04:43Conntrack rule "CT:helper:sane:PO - - tcp 6566" Compiled
Jul 31 21:04:43Conntrack rule "CT:helper:sane:PO - - tcp 6566" Compiled
Jul 31 21:04:43Conntrack rule "CT:helper:sip:PO - - udp 5060" Compiled
Jul 31 21:04:43Conntrack rule "CT:helper:sip:PO - - udp 5060" Compiled
Jul 31 21:04:43Conntrack rule "CT:helper:snmp:PO - - udp 161" Compiled
Jul 31 21:04:43Conntrack rule "CT:helper:snmp:PO - - udp 161" Compiled
Jul 31 21:04:43Conntrack rule "CT:helper:tftp:PO - - udp 69" Compiled
Jul 31 21:04:43Conntrack rule "CT:helper:tftp:PO - - udp 69" Compiled
Jul 31 21:04:43 Compiling MAC Filtration -- Phase 2...
Jul 31 21:04:43 Applying Policies...
Jul 31 21:04:43Policy ACCEPT from fw to net using chain fw-net
Jul 31 21:04:43 ..Expanding inline action 
/usr/share/shorewall/action.Broadcast...
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type BROADCAST" 
Compiled
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type ANYCAST" 
Compiled
Jul 31 21:04:43 ..End inline action /usr/share/shorewall/action.Broadcast
Jul 31 21:04:43 ..Expanding inline action 
/usr/share/shorewall/action.Multicast...
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type MULTICAST" 
Compiled
Jul 31 21:04:43 ..End inline action /usr/share/shorewall/action.Multicast
Jul 31 21:04:43Policy DROP from net to fw using chain net-fw
Jul 31 21:04:43Policy ACCEPT from net to net using chain net-net
Jul 31 21:04:43 Generating Rule Matrix...
Jul 31 21:04:43Handling complex zones...
Jul 31 21:04:43Entering main matrix-generation loop...
Jul 31 21:04:43Finishing matrix...
Jul 31 21:04:43 ..Expanding inline action 
/usr/share/shorewall/action.Broadcast...
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type BROADCAST" 
Compiled
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type ANYCAST" 
Compiled
Jul 31 21:04:43 ..End inline action /usr/share/shorewall/action.Broadcast
Jul 31 21:04:43 ..Expanding inline action 
/usr/share/shorewall/action.Multicast...
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type MULTICAST" 
Compiled
Jul 31 21:04:43 ..End inline action /usr/share/shorewall/action.Multicast
Jul 31 21:04:43 ..Expanding inline action 
/usr/share/shorewall/action.Broadcast...
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type BROADCAST" 
Compiled
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type ANYCAST" 
Compiled
Jul 31 21:04:43 ..End inline action /usr/share/shorewall/action.Broadcast
Jul 31 21:04:43 ..Expanding inline action 
/usr/share/shorewall/action.Multicast...
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type MULTICAST" 
Compiled
Jul 31 21:04:43 ..End inline action /usr/share/shorewall/action.Multicast
Jul 31 21:04:43 ..Expanding inline action 
/usr/share/shorewall/action.Broadcast...
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type BROADCAST" 
Compiled
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type ANYCAST" 
Compiled
Jul 31 21:04:43 ..End inline action /usr/share/shorewall/action.Broadcast
Jul 31 21:04:43 ..Expanding inline action 
/usr/share/shorewall/action.Multicast...
Jul 31 21:04:43 Rule " DROP - - - ;; -m addrtype --dst-type MULTICAST" 
Compiled
Jul 31 21:04:43 ..End inline action /usr/share/shorewall/action.Multicast
Jul 31 21:04:43Chain NET_IF_iop deleted
Jul 31 21:04:43Chain A_DROP deleted
Jul 31 21:04:43Chain NET_IF_oop deleted
Jul 31 21:04:43Chain NET_IF_fop deleted
Jul 31 21:04:43Chain net-net deleted
Jul 31 21:04:43 Optimizing Ruleset...
Jul 31 21:04:43 
  Table raw pass 1, 2 referenced chains, level 4a...
Jul 31 21:04:43 
  Table raw pass 2, 2 referenced chains, level 4b...
Jul 31 21:04:43 
  Table raw pass 2, 2 referenced user chains, level 16...
Jul 31 21:04:43 
  Table raw pass , 0 referenced user chains, level 8...
Jul 31 21:04:43Table raw Optimized -- Passes = 1
Jul 31 21:04:43 
Jul 31 21:04:43 
  Table nat pass 1, 4 referenced chains, level 4a...
Jul 31 21:04:43 
  Table nat pass 2, 4 referenced chains, level 4b...
Jul 31 21:04:43 
  Table nat pass 2, 4 referenced user chains, level 16...
Jul 31 21:04:43 
  Table nat pass , 0 referenced user chains, level 8...
Jul 31 21:04:43Table nat Optimized -- Passes = 1
Jul 31 21:04:43 

Bug#1016424: “Error: /invalidfileaccess in --file--” when converting PBM file to PDF

[anonymous coward]

Package: ghostscript
Version: 9.53.3~dfsg-7+deb11u2
Followup-For: Bug #1016424
X-Debbugs-Cc: debbug.1016...@sideload.33mail.com

> Therefore please report the issue upstream.

I just happened to have an account on the upstream bug tracker that
still works, so I reported here:

  https://bugs.ghostscript.com/show_bug.cgi?id=705699

But I should say this it’s not normal procedure for Debian maintainers
to ask bug reporters to mirror their report upstream according to the
section “Don't file bugs upstream” on this page:

  https://www.debian.org/Bugs/Reporting

If upstream had been a place like Github (or even worse: gitlab.com),
I would not have created an account on those forges to report a bug.
In principle, it should be automated so a Debian maintainer can mirror
bugs upstream with a simple keystroke or click, ideally.

Bug#1016449: samba: CVE-2022-2031 CVE-2022-32742 CVE-2022-32744 CVE-2022-32745 CVE-2022-32746

[Salvatore Bonaccorso]

Source: samba
Version: 2:4.16.3+dfsg-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for samba.

CVE-2022-2031[0]:
| Samba AD users can bypass certain restrictions associated with
| changing passwords

CVE-2022-32742[1]:
| Server memory information leak via SMB1

CVE-2022-32744[2]:
| Samba AD users can forge password change requests for any user

CVE-2022-32745[3]:
| Samba AD users can crash the server process with an LDAP add or modify
| request

CVE-2022-32746[4]:
| Samba AD users can induce a use-after-free in the server process
| with an LDAP add or modify request

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-2031
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2031
[1] https://security-tracker.debian.org/tracker/CVE-2022-32742
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32742
[2] https://security-tracker.debian.org/tracker/CVE-2022-32744
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32744
[3] https://security-tracker.debian.org/tracker/CVE-2022-32745
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32745
[4] https://security-tracker.debian.org/tracker/CVE-2022-32746
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32746

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1016448: undertow: CVE-2022-1319 CVE-2021-3629

[Moritz Mühlenhoff]

Source: undertow
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for undertow.

CVE-2022-1319[0]:
https://bugzilla.redhat.com/show_bug.cgi?id=2073890


CVE-2021-3629[1]:
| A flaw was found in Undertow. A potential security issue in flow
| control handling by the browser over http/2 may potentially cause
| overhead or a denial of service in the server. The highest threat from
| this vulnerability is availability. This flaw affects Undertow
| versions prior to 2.0.40.Final and prior to 2.2.11.Final.

https://bugzilla.redhat.com/show_bug.cgi?id=1977362

Make sure to also address followup tracked as CVE-2022-1259:
https://bugzilla.redhat.com/show_bug.cgi?id=2072339


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-1319
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1319
[1] https://security-tracker.debian.org/tracker/CVE-2021-3629
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3629

Please adjust the affected versions in the BTS as needed.

Bug#1016447: reportbug: olad includes Angular 1.3.14, but Debian replaces this with a dependency on 1.8.2 (which isn't compatible)

[Ken Harris]

Package: ola
Version: 0.10.8.nojsmin-2
Severity: normal

Dear Maintainer,

When visiting the "New" local OLA server at
, clicking on the page for any Universe
only shows the first tab.  Clicking any other tab (Faders, Keypad,
etc) sends you back to the home page.

OLA includes a copy of Angular 1.3.14 at ola/olad/www/new/libs/, but
Debian's package removes this and replaces it with a dependency on
package "libjs-angularjs", which is currently at version 1.8.2, and
incompatible with OLA's Angular 1.3.14 interface.

Replacing the "angular.min.js" and "angular-route.min.js" symlinks in
this package with the original files (from ola's upstream repo) fixes
the problem completely.



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

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

Versions of packages ola depends on:
ii  adduser  3.118
ii  libc62.33-7
ii  libgcc-s110.2.1-6
ii  libjs-angularjs  1.8.2-2
ii  libjs-bootstrap  3.4.1+dfsg-2
ii  libjs-jquery 3.5.1+dfsg+~3.5.5-7
ii  libncurses6  6.2+20201114-2
ii  libola1  0.10.8.nojsmin-2
ii  libprotobuf233.12.4-1
ii  libstdc++6   10.2.1-6
ii  libtinfo66.2+20201114-2
ii  lsb-base 11.1.0

ola recommends no packages.

Versions of packages ola suggests:
ii  bash-completion  1:2.11-2

-- no debconf information

Bug#1016446: 389-ds-base: CVE-2022-1949

[Moritz Mühlenhoff]

Source: 389-ds-base
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for 389-ds-base.

CVE-2022-1949[0]:
| An access control bypass vulnerability found in 389-ds-base. That
| mishandling of the filter that would yield incorrect results, but as
| that has progressed, can be determined that it actually is an access
| control bypass. This may allow any remote unauthenticated user to
| issue a filter that allows searching for database items they do not
| have access to, including but not limited to potentially userPassword
| hashes and other sensitive data.

https://bugzilla.redhat.com/show_bug.cgi?id=2091781
https://github.com/389ds/389-ds-base/issues/5170

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-1949
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1949

Please adjust the affected versions in the BTS as needed.

Bug#1016445: 389-ds-base: CVE-2022-0918

[Moritz Mühlenhoff]

Source: 389-ds-base
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for 389-ds-base.

CVE-2022-0918[0]:
| A vulnerability was discovered in the 389 Directory Server that allows
| an unauthenticated attacker with network access to the LDAP port to
| cause a denial of service. The denial of service is triggered by a
| single message sent over a TCP connection, no bind or other
| authentication is required. The message triggers a segmentation fault
| that results in slapd crashing.

https://bugzilla.redhat.com/show_bug.cgi?id=2055815
https://github.com/389ds/389-ds-base/issues/5242
https://github.com/389ds/389-ds-base/commit/caad47ab207d7c5d61521ec4d33091db559c315a
 (master)
https://github.com/389ds/389-ds-base/commit/f46ab49c9f06b503f5ec8147f2c01dcacdb6a375
 (389-ds-base-2.0.16)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0918
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0918

Please adjust the affected versions in the BTS as needed.

Bug#1016444: snd: build depends on libnotcurses-dev not available in bookworm

[Paul Gevers]

Source: snd
Version: 22.3-1
Severity: serious
Control: block -1 by 1001661

Dear maintainer,

libnotcurses-dev hasn't been in bookworm/testing for nearly three
months. Your package build depends on it, so your package can't be
rebuild in bookworm. It's also blocking the migration of the version
in unstable. As you noted in the notcurses bug, your package seems
buildable without the dependency so I think for now that's the best
way forward.

I didn't want to downgrade 1001661 because the latest version had
three timeouts in March, so the issue doesn't seem solved yet. To
confirm I triggered 10 new runs and 1 of them timed out. The ratio
just isn't good enough.

Paul

Bug#1016443: gpac: CVE-2022-29339 CVE-2022-29340 CVE-2022-29537 CVE-2022-30976 CVE-2022-1035 CVE-2022-1172 CVE-2022-1222 CVE-2022-1441 CVE-2022-1795

[Moritz Mühlenhoff]

Source: gpac
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for gpac.

CVE-2022-29339[0]:
| In GPAC 2.1-DEV-rev87-g053aae8-master, function BS_ReadByte() in
| utils/bitstream.c has a failed assertion, which causes a Denial of
| Service. This vulnerability was fixed in commit 9ea93a2.

https://github.com/gpac/gpac/commit/9ea93a2ec8f555ceed1ee27294cf94822f14f10f
https://github.com/gpac/gpac/issues/2165

CVE-2022-29340[1]:
| GPAC 2.1-DEV-rev87-g053aae8-master. has a Null Pointer Dereference
| vulnerability in gf_isom_parse_movie_boxes_internal due to improper
| return value handling of GF_SKIP_BOX, which causes a Denial of
| Service. This vulnerability was fixed in commit 37592ad.

https://github.com/gpac/gpac/commit/37592ad86c6ca934d34740012213e467acc4a3b0
https://github.com/gpac/gpac/issues/2163

CVE-2022-29537[2]:
| gp_rtp_builder_do_hevc in ietf/rtp_pck_mpeg4.c in GPAC 2.0.0 has a
| heap-based buffer over-read, as demonstrated by MP4Box.

https://github.com/gpac/gpac/issues/2173
https://github.com/gpac/gpac/commit/1773b7a34bc08734aee7d3f5dfe65d06389fe15a

CVE-2022-30976[3]:
| GPAC 2.0.0 misuses a certain Unicode utf8_wcslen (renamed
| gf_utf8_wcslen) function in utils/utf.c, resulting in a heap-based
| buffer over-read, as demonstrated by MP4Box.

https://github.com/gpac/gpac/issues/2179
https://github.com/gpac/gpac/commit/915e2cba715f36b7cc29e2117831ca143d78

CVE-2022-1035[4]:
| Segmentation Fault caused by MP4Box -lsr in GitHub repository
| gpac/gpac prior to 2.1.0-DEV.

https://huntr.dev/bounties/851942a4-1d64-4553-8fdc-9fccd167864b
https://github.com/gpac/gpac/commit/3718d583c6ade191dc7979c64f48c001ca6f0243

CVE-2022-1172[5]:
| Null Pointer Dereference Caused Segmentation Fault in GitHub
| repository gpac/gpac prior to 2.1.0-DEV.

https://huntr.dev/bounties/a26cb79c-9257-4fbf-98c5-a5a331efa264/
https://github.com/gpac/gpac/issues/2153
https://github.com/gpac/gpac/commit/55a183e6b8602369c04ea3836e05436a79fbc7f8

CVE-2022-1222[6]:
| Inf loop in GitHub repository gpac/gpac prior to 2.1.0-DEV.

https://huntr.dev/bounties/f8cb85b8-7ff3-47f1-a9a6-7080eb371a3d
https://github.com/gpac/gpac/commit/7f060bbb72966cae80d6fee338d0b07fa3fc06e1

CVE-2022-1441[7]:
| MP4Box is a component of GPAC-2.0.0, which is a widely-used third-
| party package on RPM Fusion. When MP4Box tries to parse a MP4 file, it
| calls the function `diST_box_read()` to read from video. In this
| function, it allocates a buffer `str` with fixed length. However,
| content read from `bs` is controllable by user, so is the length,
| which causes a buffer overflow.

https://github.com/gpac/gpac/issues/2175
https://github.com/gpac/gpac/commit/3dbe11b37d65c8472faf0654410068e5500b3adb

CVE-2022-1795[8]:
| Use After Free in GitHub repository gpac/gpac prior to v2.1.0-DEV.

https://huntr.dev/bounties/9c312763-41a6-4fc7-827b-269eb86efcbc
https://github.com/gpac/gpac/commit/c535bad50d5812d27ee5b22b54371bddec411514

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-29339
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29339
[1] https://security-tracker.debian.org/tracker/CVE-2022-29340
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29340
[2] https://security-tracker.debian.org/tracker/CVE-2022-29537
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29537
[3] https://security-tracker.debian.org/tracker/CVE-2022-30976
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30976
[4] https://security-tracker.debian.org/tracker/CVE-2022-1035
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1035
[5] https://security-tracker.debian.org/tracker/CVE-2022-1172
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1172
[6] https://security-tracker.debian.org/tracker/CVE-2022-1222
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1222
[7] https://security-tracker.debian.org/tracker/CVE-2022-1441
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1441
[8] https://security-tracker.debian.org/tracker/CVE-2022-1795
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1795

Please adjust the affected versions in the BTS as needed.

Bug#990419: closed by Debian FTP Masters (reply to Jérôme Charaoui ) (Bug#990419: fixed in puppetdb 7.10.1-1)

[Moritz Mühlenhoff]

Am Sun, Jul 31, 2022 at 11:42:01AM +0200 schrieb Salvatore Bonaccorso:
> Hi Jérôme,
> 
> On Sat, Jul 16, 2022 at 12:42:05AM +, Debian Bug Tracking System wrote:
> >  puppetdb (7.10.1-1) experimental; urgency=medium
> >  .
> >* New upstream version 7.10.1 (Closes: #990419, #1012577)
> 
> When you fix known CVEs can you please include those in the
> debian/changelog, this makes the tracking for the security team much
> easier.

And please also add CVE-2021-27023 to the next changelog, that CVE is
also fixed in the 7.x uploads: https://puppet.com/security/cve/cve-2021-27023
 
Cheers,
Moritz

Bug#1016442: imagemagick: CVE-2022-32545 CVE-2022-32546 CVE-2022-32547

[Moritz Mühlenhoff]

Source: imagemagick
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for imagemagick.

CVE-2022-32545[0]:
| A vulnerability was found in ImageMagick, causing an outside the range
| of representable values of type 'unsigned char' at coders/psd.c, when
| crafted or untrusted input is processed. This leads to a negative
| impact to application availability or other problems related to
| undefined behavior.

https://github.com/ImageMagick/ImageMagick/issues/4962
https://github.com/ImageMagick/ImageMagick/pull/4963
https://github.com/ImageMagick/ImageMagick6/commit/450949ed017f009b399c937cf362f0058eacc5fa
 (6.9.12-43)

CVE-2022-32546[1]:
| A vulnerability was found in ImageMagick, causing an outside the range
| of representable values of type 'unsigned long' at coders/pcl.c, when
| crafted or untrusted input is processed. This leads to a negative
| impact to application availability or other problems related to
| undefined behavior.

https://github.com/ImageMagick/ImageMagick/issues/4985
https://github.com/ImageMagick/ImageMagick/pull/4986
https://github.com/ImageMagick/ImageMagick6/commit/29c8abce0da56b536542f76a9ddfebdaab5b2943
 (6.9.12-44)

CVE-2022-32547[2]:
| In ImageMagick, there is load of misaligned address for type 'double',
| which requires 8 byte alignment and for type 'float', which requires 4
| byte alignment at MagickCore/property.c. Whenever crafted or untrusted
| input is processed by ImageMagick, this causes a negative impact to
| application availability or other problems related to undefined
| behavior.

https://github.com/ImageMagick/ImageMagick/issues/5033
https://github.com/ImageMagick/ImageMagick/pull/5034
https://github.com/ImageMagick/ImageMagick6/commit/dc070da861a015d3c97488fdcca6063b44d47a7b
 (6.9.12-45)

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-32545
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32545
[1] https://security-tracker.debian.org/tracker/CVE-2022-32546
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32546
[2] https://security-tracker.debian.org/tracker/CVE-2022-32547
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32547

Please adjust the affected versions in the BTS as needed.

Bug#1014773: Possible workaround

[Insightfill]

I've seen this too, and on a clean install. The note about "Nvidia drivers"
was good and provided a workaround. Under Settings, turning off
"Performance>Use hardware acceleration when available" seems to have
stopped the problem. This corresponds to the config setting
"layers.acceleration.disabled=true".

Everything feels a little more sluggish, but it's better than crashing.
Thanks for the hint.

-- 
-SG

Bug#1016441: kubernetes: CVE-2021-25743

[Moritz Mühlenhoff]

Source: kubernetes
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for kubernetes.

CVE-2021-25743[0]:
| kubectl does not neutralize escape, meta or control sequences
| contained in the raw data it outputs to a terminal. This includes but
| is not limited to the unstructured string fields in objects such as
| Events.

https://github.com/kubernetes/kubernetes/issues/101695

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-25743
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25743

Please adjust the affected versions in the BTS as needed.

Bug#1002295: Uploaded the files

[Bastian Germann]

On Sun, 31 Jul 2022 14:31:05 + Scorpion2185  
wrote:

I uploaded the files.
Is it now fine? No tags for this project.


I give up on this. Maybe someone else sees the benefit of this package in 
Debian. I certainly don't.

Bug#1016440: haskell-hledger FTBFS: dh_installman: error: Cannot find (any matches for) "embeddedfiles/hledger_csv.5"

[Adrian Bunk]

Source: haskell-hledger
Version: 1.25-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-hledger=1.25-1

...
dh_installman -phledger 
dh_installman: error: Cannot find (any matches for) 
"embeddedfiles/hledger_csv.5" (tried in .)

dh_installman: error: Aborting due to earlier error
make: *** [/usr/share/cdbs/1/rules/debhelper.mk:236: binary-install/hledger] 
Error 25

Bug#1014022: kalendar segfaults immediately on start

[Patrick Franz]

Control: severity -1 important
Control: reassign -1 akonadi
thanks

Hi,

I cannot reproduce this. When I start kalendar with a fresh user on a 
default installation, it starts as expected for me.

Looking at the output, it seems like an akonadiserver issue rather than 
a kalendar issue, reassigning it therefore.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1016439: buster-pu: package procmail/3.22-26+deb10u1

[Santiago Vila]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: sanv...@debian.org

Dear release managers:

I've applied this small procmail fix to buster as well, hopefully to be 
part of the next point release, whenever it will be.


This was done to bullseye previously:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014221

As in the bullseye case, this is the type of bug I don't want to see in
stable or oldstable.

The debdiff is attached.

Thanks.diff -Nru procmail-3.22/debian/changelog procmail-3.22/debian/changelog
--- procmail-3.22/debian/changelog  2017-11-16 23:42:36.0 +0100
+++ procmail-3.22/debian/changelog  2022-07-31 20:10:00.0 +0200
@@ -1,3 +1,11 @@
+procmail (3.22-26+deb10u1) buster; urgency=medium
+
+  * Fix NULL pointer dereference. Closes: #769938.
+Reported by Jakub Wilk using American Fuzzy Lop.
+Patch from Stephen R. van den Berg.
+
+ -- Santiago Vila   Sun, 31 Jul 2022 20:10:00 +0200
+
 procmail (3.22-26) unstable; urgency=medium
 
   * Fix buffer overflow in loadbuf(). Closes: #876511.
diff -Nru procmail-3.22/debian/patches/31 procmail-3.22/debian/patches/31
--- procmail-3.22/debian/patches/31 1970-01-01 01:00:00.0 +0100
+++ procmail-3.22/debian/patches/31 2022-07-31 19:32:00.0 +0200
@@ -0,0 +1,19 @@
+From: Stephen R. van den Berg 
+Subject: Cater for mails containing an incomplete From_ line.
+Bug-Debian: http://bugs.debian.org/769938
+X-Debian-version: 3.22-27
+
+--- a/src/from.c
 b/src/from.c
+@@ -117,7 +117,10 @@
+ themail.p[extra]='\0';  /* terminate it for strchr */
+   }
+  while(!(rstart=strchr(themail.p,'\n')));
+- extra=rstart?extra-(++rstart-themail.p):0;
++ if (rstart)
++   extra -= ++rstart - themail.p;
++ else
++   extra = 0, rstart = themail.p;
+}
+   else
+{ size_t tfrl= ++rstart-themail.p; /* length of existing From_ line */
diff -Nru procmail-3.22/debian/patches/series 
procmail-3.22/debian/patches/series
--- procmail-3.22/debian/patches/series 2017-11-16 23:41:45.0 +0100
+++ procmail-3.22/debian/patches/series 2022-07-31 19:00:00.0 +0200
@@ -29,3 +29,4 @@
 28
 29
 30
+31

Bug#1013495: asio: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Timo Röhling]

Control: reassign -1 libssl-dev 3.0.4-2
Control: fixed -1 3.0.5-1
Control: affects -1 src:asio
Control: tags -1 - sid

Hi,

On Fri, 24 Jun 2022 09:03:31 +0200 Lucas Nussbaum  wrote:

Source: asio
Version: 1:1.22.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220624 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

This bug no longer affects unstable, only bookworm. Further
investigation revealed that the segfault is triggered by libssl-dev
3.0.4-2 (building in bookworm with libssl-dev 3.0.5-1 works fine).

Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1006457:

[Andres Salomon]

The builds are almost identical, except for the compiler (clang 11) and 
build environment used. Clang 13 has been backported to stable (it's 
currently in stable-proposed-updates, and should be in the bullseye 
11.5 release).


The next chromium upload should be built against clang-13, which may 
behave better for you.


On Sun, Jul 31, 2022 at 17:15, Leonard Lausen  wrote:
This issue seems specific to the ~deb11u1 or ~deb11u2 packages. For 
example, both 97.0.4692.99-1~deb11u2 and 103.0.5060.134-1~deb11u1 
crash but both 97.0.4692.99-1 and 103.0.5060.134-1 work. Could you 
please explain the difference between these builds?


(103.0.5060.134-1 does not work with --ozone-platform-hint=wayland 
which is a separate issue affecting aarch64 builds tracked in 
Bug#1016438)

Bug#1016435: Fw: openvpn (2.6.0~git20220518+dco-3) depends on systemd

[Chris Hofstaedtler]

* Dr. Markus Waldeck :
> Package: openvpn


> I tried to install openvpn (2.6.0~git20220518+dco-3) on testing and noticed 
> that systemd is a dependency now.

openvpn Depends on systemd | systemd-tmpfiles. This is an artifact
of installing a tmpfiles.d snippet, and expected.
Depends: systemd(-tmpfiles) does not hinder anyone from using a
non-systemd init. The systemd "init" is really in the systemd-sysv
package.

Chris

PS: not depending on systemd or at least libsystemd0 is almost
impossible on a modern system.

Bug#1006457:

[Leonard Lausen]

This issue seems specific to the ~deb11u1 or ~deb11u2 packages. For example, 
both 97.0.4692.99-1~deb11u2 and 103.0.5060.134-1~deb11u1 crash but both 
97.0.4692.99-1 and 103.0.5060.134-1 work. Could you please explain the 
difference between these builds?

(103.0.5060.134-1 does not work with --ozone-platform-hint=wayland which is a 
separate issue affecting aarch64 builds tracked in Bug#1016438)

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Yukiharu YABUKI]

Aoki-san.

Thank you for your suggestion.

I did 'ps axjf'. This output was too big. I selected from output.

1) gdm3

  1108710871087 ? -1 Ssl  0
0:00 /usr/sbin/gdm3 1087233710871087 ? -1
Sl   0   0:00  \_ gdm-session-worker [pam/gdm-password] 2337
253225322532 tty22532 Ssl+  1000   0:00
\_ /usr/libexec/gdm-x-session --register-session --run-script i3 2532
253425322532 tty22532 Sl+   1000   7:13
\_ /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gd 2532
260425322532 tty22532 S+1000   0:04  \_ i3
2604269026902690 ? -1 Ss1000
0:00  \_ /usr/bin/ssh-agent /usr/bin/im-launch i3

2) ibus-daemon

  1  385641  385641  385641 ? -1 Ssl   1000   0:15
ibus-daemon -xrd 385641  385651  385641  385641 ? -1 Sl
1000   0:00  \_ /usr/libexec/ibus-dconf 385641  385652  385641
385641 ? -1 Sl1000   0:03  \_ /usr/libexec/ibus-ui-gtk3
385641  385653  385641  385641 ? -1 Sl1000   0:04
\_ /usr/libexec/ibus-extension-gtk3 385641  385679  385641
385641 ? -1 Sl1000   0:00
\_ /usr/libexec/ibus-engine-simple 385641  385777  385641
385641 ? -1 Sl1000   0:09  \_
python3 /usr/share/ibus-anthy/engine/main.py --ibus 1  385655  385641
385641 ? -1 Sl1000   0:11 /usr/libexec/ibus-x11
--kill-daemon

3) ps axjf

  1814581448144 ? -1 S 1000
0:00 /bin/sh -c uxterm 8145814681448144 ? -1
S 1000   0:00  \_ xterm -class UXTerm -title uxterm -u8 8146
815081508150 pts/7 845149 Ss1000   0:00  \_ bash
8150  845149  8451498150 pts/7 845149 S+   0   0:00
\_ sudo ps axjf 845149  845293  845293  845293 pts/19845294 Ss
0   0:00  \_ sudo ps axjf 845293  845294  845294  845293
pts/19845294 R+   0   0:00  \_ ps axjf


--
Yukiharu YABUKI 

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Dominique Dumont]

On Sunday, 31 July 2022 16:35:12 CEST Jérémy Lal wrote:
> Indeed, sorry for my somewhat irritated tone - it just happens that it was
> the second time libuv1 was updated during a nodejs transition, and the
> upstream bug it creates on nodejs hasn't been fixed yet, so it shoots the
> transition in the guts.
> Nodejs depends heavily on libuv1...

I understand your furstration. Sorry about the mess.

> Maybe a simple approach would be to upload libuv1 updates to experimental
> first, and wait a week to see how it scares the others :)

That I can do.

All the best.

Bug#1016438: chromium: Ozone wayland platfrom broken on aarch64 build after 97.0.4692.99-1

[Leonard Lausen]

Package: chromium
Version: 98.0.4758.80-1
Severity: important
X-Debbugs-Cc: leon...@lausen.nl

Dear Maintainer,

the aarch64 build of version 97.0.4692.99-1 can be successfully run with
--ozone-platform-hint=wayland and hardware acceleration works in this setting.
Unfortunately, from 98.0.4758.80-1 onwards all the way to the latest available
103.0.5060.134-1, --ozone-platform-hint=wayland is broken and chromium fails to
start (no window appears) when running --ozone-platform-hint=wayland.

Could there be a regression in the build configuration between version 97 and 
98?

Attempting to start the chromium 98 and 103 builds with Ozone Wayland Platform 
prints errors like

  [40197:40197:0730/170137.393978:ERROR:gpu_init.cc(486)] Passthrough is not 
supported, GL is egl, ANGLE is
  [40197:40197:0730/170137.679681:ERROR:gbm_wrapper.cc(292)] Failed to export 
buffer to dma_buf: No such file or directory (2)
  [40197:40197:0730/170137.681056:ERROR:gbm_pixmap_wayland.cc(75)] Cannot 
create bo with format= RGBA_ and usage=SCANOUT
  
[40197:40197:0730/170137.681871:ERROR:gpu_memory_buffer_factory_native_pixmap.cc(198)]
 Failed to create pixmap 1536x1280, RGBA_, usage SCANOUT
  [40197:40197:0730/170137.682767:ERROR:gbm_wrapper.cc(292)] Failed to export 
buffer to dma_buf: No such file or directory (2)
  [40197:40197:0730/170137.683567:ERROR:gbm_pixmap_wayland.cc(75)] Cannot 
create bo with format= RGBA_ and usage=GPU_READ
  
[40197:40197:0730/170137.684044:ERROR:gpu_memory_buffer_factory_native_pixmap.cc(198)]
 Failed to create pixmap 1536x1280, RGBA_, usage GPU_READ
  
[40197:40197:0730/170137.684419:ERROR:shared_image_backing_factory_gl_image.cc(355)]
 CreateSharedImage: Failed to create bindable image
  [40197:40197:0730/170137.684715:ERROR:shared_image_factory.cc(770)] 
CreateSharedImage: could not create backing.
  [40197:40197:0730/170137.685672:ERROR:shared_context_state.cc(543)] Failed to 
make current since context is marked as lost
  
[40197:40197:0730/170137.686140:ERROR:skia_output_surface_impl_on_gpu.cc(1703)] 
Failed to make current.
  [40197:40197:0730/170137.687022:ERROR:shared_context_state.cc(543)] Failed to 
make current since context is marked as lost
  
[40197:40197:0730/170137.687478:ERROR:skia_output_surface_impl_on_gpu.cc(1703)] 
Failed to make current.
  [40197:40197:0730/170137.688920:ERROR:shared_context_state.cc(543)] Failed to 
make current since context is marked as lost
  
[40197:40197:0730/170137.689612:ERROR:skia_output_surface_impl_on_gpu.cc(1703)] 
Failed to make current.
  [40197:40197:0730/170137.690294:ERROR:shared_context_state.cc(543)] Failed to 
make current since context is marked as lost
  
[40197:40197:0730/170137.690672:ERROR:skia_output_surface_impl_on_gpu.cc(1703)] 
Failed to make current.
  [40197:40197:0730/170137.691283:ERROR:raster_decoder.cc(1244)]   
RasterDecoderImpl: Context lost during MakeCurrent.
  [40197:40197:0730/170137.701335:ERROR:shared_image_stub.cc(519)] 
SharedImageStub: context already lost
  [40197:40197:0730/170137.705387:ERROR:shared_image_stub.cc(519)] 
SharedImageStub: context already lost
  [40143:40236:0730/170137.709873:ERROR:nss_util.cc(349)] After loading Root 
Certs, loaded==false: NSS error code: -8018
  [40197:40197:0730/170137.781652:ERROR:gbm_wrapper.cc(292)] Failed to export 
buffer to dma_buf: No such file or directory (2)


Whereas with chromium 97 with Ozone Wayland Platform  

  [44179:44179:0730/174942.364802:ERROR:gpu_init.cc(457)] Passthrough is not 
supported, GL is egl, ANGLE is
  [44179:44179:0730/174942.374620:ERROR:sandbox_linux.cc(378)] 
InitializeSandbox() called with multiple threads in process gpu-process.

While --ozone-platform-hint=x11 works for these newer builds, it is not an
acceptable alternative as only software rendering without hardware acceleration
is functional on those builds.  Specifically, with Ozone Wayland Platform,
chrome://gpu lists "GL_VENDOR: freedreno" "GL_RENDERER: FD618", which indicates
working hardware acceleration, whereas the Ozone X11 Platform lists
"GL_RENDERER ANGLE (freedreno, FD618, OpenGL 3.3 (Core Profile) Mesa 22.1.3)"
and "GL_VERSION OpenGL ES 2.0.0 (ANGLE 2.1.0 git hash: unknown hash)"
indicating the lack of hardware acceleration due to the use of ANGLE.

Below system information is generated while running the last functional build,
97.0.4692.99-1.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.19.0-rc8-stb-cbq (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  chromium-common 97.0.4692.99-1
ii  libasound2  1.2.6.1-2+b1
ii  libatk-bridge2.0-0  2.38.0-4
ii  libatk1.0-0 2.38.0-1
ii  libatomic1  12.1.0-2
ii  libatspi2.0-0   2.44.1-1
ii  libc6  

Bug#1016434: yubiserver security support?

[Chrysostomos Nanakos]

Hi,
just realised that upstream had an issue, fixed it already.

Also going forward updating the package.

Thanks,
Chrysostomos.

On 2022-07-31 19:07, Chris Hofstaedtler wrote:

Source: yubiserver

Hi,

yubiserver sure looks like a security sensitive package. However
upstream appears to have vanished, and maybe the Debian Maintainer
as well?

Security Team: do you think yubiserver should be in bookworm given
these uncertainties?

Thanks,
Chris

Bug#1016437: Provide lto-dump default version

[Jochen Sprickerhof]

Package: gcc
Version: 4:12.1.0-3
Severity: wishlist
Tags: patch

Hi doko,

can you please provide a default version for lto-dump?
The attached patch should do.

Cheers Jochen


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

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

Versions of packages gcc depends on:
ii  cpp 4:12.1.0-3
ii  gcc-12  12.1.0-7

Versions of packages gcc recommends:
ii  libc6-dev [libc-dev]  2.33-8

Versions of packages gcc suggests:
ii  autoconf  2.71-2
ii  automake  1:1.16.5-1.3
pn  bison 
pn  flex  
ii  gcc-doc   5:11.2.0-2
pn  gcc-multilib  
ii  gdb   12.1-3
ii  libtool   2.4.7-4
ii  make  4.3-4.1
ii  manpages-dev  5.13-1

-- no debconf information
>From 410d505de3dbe5f8e20ee09b44f4b0556a7605b6 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Sun, 31 Jul 2022 19:04:07 +0200
Subject: [PATCH] Provide lto-dump default version

---
 debian/rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/rules b/debian/rules
index 27049c1..a69d82c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -803,6 +803,8 @@ ifeq ($(with_native),yes)
  /usr/bin/gcc-$(PV_GCC) /usr/bin/$(DEB_HOST_GNU_TYPE)-gcc \
  /usr/bin/gcov-$(PV_GCC) /usr/bin/gcov \
  /usr/bin/gcov-$(PV_GCC) /usr/bin/$(DEB_HOST_GNU_TYPE)-gcov \
+ /usr/bin/lto-dump-$(PV_GCC) /usr/bin/lto-dump \
+ /usr/bin/lto-dump-$(PV_GCC) /usr/bin/$(DEB_HOST_GNU_TYPE)-lto-dump \
  /usr/lib/gcc/$(DEB_HOST_GNU_TYPE)/$(PV_GCC)/liblto_plugin.so 
/usr/lib/bfd-plugins/liblto_plugin.so \
  /usr/share/doc/gcc-$(PV_GCC)/README.Bugs 
/usr/share/doc/cpp/README.Bugs \
  $(if $(filter $(DEB_HOST_ARCH), $(gcc49_archs)),, \
@@ -839,6 +841,7 @@ ifeq ($(with_native),yes)
  /usr/share/man/man1/gcc-$(PV_GCC).1.gz 
/usr/share/man/man1/$(DEB_HOST_GNU_TYPE)-gcc.1.gz \
  /usr/share/man/man1/gcov-$(PV_GCC).1.gz /usr/share/man/man1/gcov.1.gz 
\
  /usr/share/man/man1/gcov-$(PV_GCC).1.gz 
/usr/share/man/man1/$(DEB_HOST_GNU_TYPE)-gcov.1.gz \
+ /usr/share/man/man1/lto-dump-$(PV_GCC).1.gz 
/usr/share/man/man1/$(DEB_HOST_GNU_TYPE)-lto-dump.1.gz \
  $(if $(filter $(DEB_HOST_ARCH), $(gcc49_archs)),, \
/usr/share/man/man1/gcov-tool-$(PV_GCC).1.gz 
/usr/share/man/man1/gcov-tool.1.gz \
/usr/share/man/man1/gcov-tool-$(PV_GCC).1.gz 
/usr/share/man/man1/$(DEB_HOST_GNU_TYPE)-gcov-tool.1.gz \
@@ -1050,6 +1053,7 @@ install.%: pre-install
  /usr/share/doc/cpp-$(CROSS_PKG_GNU_TYPE) 
/usr/share/doc/gcc-$(CROSS_PKG_GNU_TYPE) \
  /usr/bin/$(CROSS_GNU_TYPE)-gcc-$(PV_GCC_$(CROSS_ARCH)) 
/usr/bin/$(CROSS_GNU_TYPE)-gcc \
  /usr/bin/$(CROSS_GNU_TYPE)-gcov-$(PV_GCC_$(CROSS_ARCH)) 
/usr/bin/$(CROSS_GNU_TYPE)-gcov \
+ /usr/bin/$(CROSS_GNU_TYPE)-lto-dump-$(PV_GCC_$(CROSS_ARCH)) 
/usr/bin/$(CROSS_GNU_TYPE)-lto-dump \
  /usr/share/doc/gcc-$(PV_GCC)-$(CROSS_PKG_GNU_TYPE)-base/README.Bugs 
/usr/share/doc/cpp-$(CROSS_PKG_GNU_TYPE)/README.Bugs \
  $(if $(filter $(CROSS_ARCH), $(gcc49_archs)),, \
/usr/bin/$(CROSS_GNU_TYPE)-gcov-dump-$(PV_GCC_$(CROSS_ARCH)) 
/usr/bin/$(CROSS_GNU_TYPE)-gcov-dump \
@@ -1075,6 +1079,7 @@ install.%: pre-install
  dh_link -pgcc-$(CROSS_PKG_GNU_TYPE) \

/usr/share/man/man1/$(CROSS_GNU_TYPE)-gcc-$(PV_GCC_$(CROSS_ARCH)).1.gz 
/usr/share/man/man1/$(CROSS_GNU_TYPE)-gcc.1.gz \

/usr/share/man/man1/$(CROSS_GNU_TYPE)-gcov-$(PV_GCC_$(CROSS_ARCH)).1.gz 
/usr/share/man/man1/$(CROSS_GNU_TYPE)-gcov.1.gz \
+   
/usr/share/man/man1/$(CROSS_GNU_TYPE)-lto-dump-$(PV_GCC_$(CROSS_ARCH)).1.gz 
/usr/share/man/man1/$(CROSS_GNU_TYPE)-lto-dump.1.gz \
$(if $(filter $(CROSS_ARCH), $(gcc49_archs)),, \
  
/usr/share/man/man1/$(CROSS_GNU_TYPE)-gcov-tool-$(PV_GCC_$(CROSS_ARCH)).1.gz \
  /usr/share/man/man1/$(CROSS_GNU_TYPE)-gcov-tool.1.gz \
-- 
2.36.1

Bug#1016412: dh-make: manpage.1.ex: Incorrect formatting for dash

[G. Branden Robinson]

Hi Mike,

At 2022-07-31T11:54:13-0400, Mike Bianchi wrote:
> I come into this very late and without having studied the on-going
> discussion.  For this I apologize.
> 
> > However, since many manual pages in existence are incorrect, and
> > they use '-'  >>> when they should use '\-' <<< ...
> 
> Let me take exception to the claim that  '-'  should be '\-' .  

...and permit me to rebut you!  ;-)

> In manual pages of UNIX/Linux commands, system calls, libraries, etc.
> all the examples are for strings and negative numbers expressed in
> ASCII characters.
>   man(1)
>   execve(2)
>   fileno(3)
>  :

Well, no, they're not.

Let's go to what I have earlier referred to exaggeratedly as the
"Ur-source of all correct practice", the Unix Version 7 Programmer's
Manual (1979).  Surveying its man pages we find exhibits like the
following.

Believe it or not, this is a _brief_ sampling.  I've drawn exhibits from
every section of the manual and attempt to show usage of \- in several
correct context.  (The sharp eye will spot an authentic solecism.)

man5/passwd.5-.SH NAME
man5/passwd.5:passwd \- password file
man5/passwd.5-.SH DESCRIPTION

man5/filsys.5-Thus is i-list is
man5/filsys.5:.IR s_isize \-2
man5/filsys.5-blocks long.

man5/filsys.5-array contains, in
man5/filsys.5:.I "s_free[1], ... , s_free[s_nfree\-1],"
man5/filsys.5-up to NICFREE free block numbers.

man5/a.out.5-if the program was loaded
man5/a.out.5:with the `\-s' option
man5/a.out.5-of

man5/mpxio.5-the operating system aligns records
man5/mpxio.5:on short (i.e. 16\-bit) boundaries
man5/mpxio.5-by skipping bytes when necessary.

man5/mpxio.5-.ti -.5i
man5/mpxio.5:M_WATCH \- a process `wants to attach' on this channel.
man5/mpxio.5-The second parameter is the 16-bit

man6/reversi.6-[ [
man6/reversi.6:.B \-r
man6/reversi.6-]

man6/ching.6-six straight
man6/ching.6:(\-\-\-)
man6/ching.6-and broken
man6/ching.6:(\-\ \-)
man6/ching.6-lines.

man6/ching.6-(lines)
man6/ching.6:using yarrow\-stalks
man6/ching.6-or tossed coins.

man6/ching.6-which drives a simulated
man6/ching.6:coin\-toss divination.
man6/ching.6-The answer is then piped through

man6/arithmetic.6-[
man6/arithmetic.6:.B +\-x/
man6/arithmetic.6-] [ range ]

man6/arithmetic.6-to be generated;
man6/arithmetic.6:.B +\-x/
man6/arithmetic.6-respectively cause

man6/arithmetic.6-problems will be mixed in random order; default is
man6/arithmetic.6:.B +\-
man6/arithmetic.6-.PP

man8/boot.8-177412
man8/boot.8:005040  clr \-(r0)  / rkda cleared by start
man8/boot.8:010040  mov r0,\-(r0)
man8/boot.8:012740  mov $5,\-(r0)
man8/boot.8-05

man8/boot.8-176726
man8/boot.8:005040  clr \-(r0)
man8/boot.8:005040  clr \-(r0)
man8/boot.8:005040  clr \-(r0)
man8/boot.8:010040  mov r0,\-(r0)
man8/boot.8:012740  mov $5,\-(r0)
man8/boot.8-05

man1/lint.1-[
man1/lint.1:.B \-abchnpuvx
man1/lint.1-]

man1/ld.1-Except for
man1/ld.1:.BR \-l ,
man1/ld.1-they should appear before the file names.
man1/ld.1-.TP
man1/ld.1:.B  \-s
man1/ld.1-`Strip' the output, that is, remove the symbol table

man1/awk.1-and are built using the operators
man1/awk.1:+, \-, *, /, %,  and concatenation (indicated by a blank).
man1/awk.1:The C operators ++, \-\-, +=, \-=, *=, /=, and %=
man1/awk.1-are also available in expressions.

man1/awk.1-or by using the
man1/awk.1:.BI \-F c
man1/awk.1-option.

man1/awk.1-.nf
man1/awk.1: { for (i = NF; i > 0; \-\-i) print $i }
man1/awk.1-.fi

man1/quot.1m-.TP
man1/quot.1m:.B \-n
man1/quot.1m-Cause the pipeline
man1/quot.1m:.B "ncheck filesystem | sort +0n | quot \-n filesystem
man1/quot.1m-to produce a list of all files and their owners.
man1/quot.1m-.TP
man1/quot.1m:.B \-c
man1/quot.1m-Print three columns giving file size in blocks, number of

man1/make.1-.I makefile
man1/make.1:is `\-', the standard input is taken.
man1/make.1-More than one
man1/make.1:.B \-f
man1/make.1-option may appear

man7/term.7-.nf
man7/term.7:.ta \w'450\-12\-8  'u
man7/term.7-1620DIABLO 1620 (and others using HyType II)
man7/term.7:1620\-12same, in 12-pitch mode
man7/term.7-300 DASI/DTC/GSI 300 (and others using HyType I)
man7/term.7:300\-12 same, in 12-pitch mode
man7/term.7-300sDASI/DTC 300/S
man7/term.7:300s\-12same, in 12-pitch mode
man7/term.7-33  TELETYPE\*R Model 33
man7/term.7-37  TELETYPE Model 37
man7/term.7:40\-2   TELETYPE Model 40/2
man7/term.7-43  TELETYPE Model 43
man7/term.7-450 DASI 450 (same as Diablo 1620)
man7/term.7:450\-12 same, in 12-pitch mode
man7/term.7:450\-12\-8  same, in 12-pitch, 8 lines/inch mode
man7/term.7-735 Texas Instruments TI735 (and TI725)

man2/kill.2-.PP
man2/kill.2:If the process number is \-1, and the user is the super-user,
man2/kill.2-the signal is broadcast universally

man2/kill.2-Zero is returned if the process is killed;
man2/kill.2:\-1 is returned if the process does not

Bug#1016410: Should pmdk-convert be built on all architectures where pmdk is available?

[Adam Borowski]

On Sun, Jul 31, 2022 at 12:30:31PM +0300, Adrian Bunk wrote:
> Package: pmdk-convert
> Version: 1.7-1

> pmdk is also available on ppc64el and riscv64 where pmdk-convert
> is currently not being built.

There's no version with a different on-memory file format to convert
from on these archs.  The last compat break was between 1.6 and 1.7.
Moreover, the format is not portable between different cacheline and
page sizes (ie, ppc64el) and no one expressed a desire for such
conversions yet.

> Should pmdk-convert be built on all architectures where pmdk
> is available?

I added arm64 only because 1. it has same layout as x86 (cacheline 64,
page 4096) thus you can copy pools over, and 2. as a porting check.

In theory the same can be said about riscv64, but considering limitations
of hardware expected in the next couple of years... naaah.

Another problem is, even the top version of pmdk embedded in -convert
predates ppc64 porting, and that'd require some upstream[ish] work.

Thus, I'd add new archs only when there is something for them to do.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver!
⠈⠳⣄

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

0.64.2 draft 1 needs embedding 113 crates (94 missing, 1 broken, 8 outdated, 10 
ahead); builds in ~58 minutes; runs but functionality not yet properly tested

Main tasks now are to keep package up-to-date with upstream releases, and
to package more of the crates currently embedded.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary packages I built - then I will share those.

As developer (but no need to be official member of Debian!), you can
join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/safe-network/-/blob/debian/latest/debian/TODO


 - Jonas

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

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

signature.asc
Description: signature

Bug#1016424: “Error: /invalidfileaccess in --file--” when converting PBM file to PDF

[Jonas Smedegaard]

Quoting anonymous coward (2022-07-31 16:11:44)
> Package: ghostscript
> Version: 9.53.3~dfsg-7+deb11u2
> Severity: normal
> X-Debbugs-Cc: debbug.ghostscr...@sideload.33mail.com
> 
> Ghostscript fails to convert PBM files to PDF. Attempts were made with
> 3 different PBM files:
> 
>   1) scanner-made PDF → (pdfimages -all) → (unpaper) → PBM → 
> (ghostscript/pdfwrite) → error
>   2) tex → (LaTeX) → PDF → (ghostscript/pbm) → PBM → (ghostscript/pdfwrite) → 
> error
>   3) (imagemagick) → PBM → (ghostscript/pdfwrite) → error
> 
> This seems to show that PBMs of any kind produce an error when using
> the PDFwrite driver.

Thanks for reporting this issue.

None of the patched carried for the Debian build of Ghostscript is
likely causing any deviation related to this, so it is most likely a bug
upstream (assuming upstream considers this a supported us of
Ghostscript).

Therefore please report the issue upstream.

Kind regards,


 - Jonas

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

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

signature.asc
Description: signature

Bug#879296: Correcting statement about fabo

[Bastian Germann]

X-Debbugs-Cc: w...@debian.org

Hi Daniel,

On Tue, 24 Oct 2017 00:08:02 +0200 Tobias Frost  wrote:

Fathi Boudra  has not been working on the clucene-core package 
for
quite some time.


Would you like to step up as a maintainer for clucene-core?
Else, please orphan the package.

Thanks,
Bastian

Bug#1016436: lldb-14: lldb malfunctions due to faulty python path (ModuleNotFoundError: No module named 'lldb.embedded_interpreter')

[Steve M. Robbins]

Package: lldb-14
Version: 1:14.0.6-2
Severity: normal

Dear Maintainer,

There is a misconfiguration somewhere in the build, that embeds a non-existent
python path:

  $ lldb -P
  /usr/lib/local/lib/python3.10/dist-packages

This causes lldb to emit an error when starting:

$ lldb
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'

See https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1972855 for 
full description and a workaround.



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

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

Versions of packages lldb-14 depends on:
ii  libc62.33-8
ii  libclang-cpp14   1:14.0.6-2
ii  libedit2 3.1-20210910-1
ii  libgcc-s112.1.0-7
ii  liblldb-14   1:14.0.6-2
ii  libllvm141:14.0.6-2
ii  libncurses6  6.3+20220423-2
ii  libstdc++6   12.1.0-7
ii  libtinfo66.3+20220423-2
ii  libxml2  2.9.14+dfsg-1+b1
ii  llvm-14-dev  1:14.0.6-2
ii  python3-lldb-14  1:14.0.6-2
ii  zlib1g   1:1.2.11.dfsg-4

lldb-14 recommends no packages.

lldb-14 suggests no packages.

-- no debconf information

Bug#1015897: gobby: Gobby is crashing right after calling it

[Philipp Kern]

Hi,

On 26.07.22 11:28, Andreas Tille wrote:

Am Tue, Jul 26, 2022 at 09:58:49AM +0200 schrieb Philipp Kern:

On 23.07.22 15:09, Andreas Tille wrote:

** (gobby:197027): WARNING **: 15:06:06.692: Failed to create root directory: 
Permission denied
Subsequent storage operations will most likely fail


How do your permissions on ~/.config


drwxr-xr-x  90 andreas andreas  4096 26. Jul 11:24 .config


and ~/.config/gobby look like?


drwxr-xr-x  2 andreas andreas  4096 20. Jul 10:11 gobby

$ ls -lR .config/gobby
.config/gobby:
insgesamt 8
-rw-r--r-- 1 andreas andreas  52 23. Aug 2020  documents.xml
-rw-r--r-- 1 andreas andreas 298 23. Aug 2020  hosts.xml
-rw-r--r-- 1 andreas andreas   0 12. Aug 2013  known_hosts
-rw-r--r-- 1 andreas andreas   0 23. Aug 2020  recent_hosts


Does the
latter exist now?


It existed - but if I remove it no such dir is create newly.


And how about ~/.infinote-records and your homedir?

FWIW, it does not crash for me on a new installation on bookworm.

Kind regards
Philipp Kern

Bug#1016435: Fw: openvpn (2.6.0~git20220518+dco-3) depends on systemd

[Dr. Markus Waldeck]

Package: openvpn

Hi Bernhard,

That's not intended, please file a bug so I don't lose track of it.

I tried to install openvpn (2.6.0~git20220518+dco-3) on testing and noticed 
that systemd is a dependency now.

This was not the case with 2.6.0~git20220518+dco-2 amd64.

# dpkg -l openvpn
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture Description
 
+++-==-===--=
ii  openvpn2.6.0~git20220518+dco-2 amd64virtual private network 
daemon

Thanks in advance!

Dr. Markus Waldeck

Bug#1016434: yubiserver security support?

[Chris Hofstaedtler]

Source: yubiserver

Hi,

yubiserver sure looks like a security sensitive package. However
upstream appears to have vanished, and maybe the Debian Maintainer
as well?

Security Team: do you think yubiserver should be in bookworm given
these uncertainties?

Thanks,
Chris

Bug#1016433: Duplicate

[Philippe SWARTVAGHER]

Sorry, I didn’t notice it was already reported in bugs 1011739 and 1010421 
against ldc...

Bug#1016412: dh-make: manpage.1.ex: Incorrect formatting for dash

[Mike Bianchi]

I come into this very late and without having studied the on-going discussion.
For this I apologize.


> However, since many manual pages in existence are incorrect, and they 
> use '-'  >>> when they should use '\-' <<< ...

Let me take exception to the claim that  '-'  should be '\-' .  

In manual pages of UNIX/Linux commands, system calls, libraries, etc. all the
examples are for strings and negative numbers expressed in ASCII characters.
man(1)
execve(2)
fileno(3)
   :

   To my mind the correct solution to the  '-'  controversy is to format
   everything at is an ASCII expression in an ASCII font which has no
   concept of '\-' .

((I come from the days when all UNIX documentation was formated using nroff.))

Mike Bianchi



On Sun, Jul 31, 2022 at 02:04:23PM +0200, Alejandro Colomar (man-pages) wrote:
> Hi Baptiste,
> 
> On 7/31/22 13:49, Baptiste Beauplat wrote:
> > Hi Alejandro,
> > 
> > On 2022/07/31 12:35 PM, Alejandro Colomar wrote:
> >> The template page 'manpage.1.ex' uses '-' instead of '\-' for a
> >> dash that should be a Latin minus sign (as it's in the context of
> >> command options).  Using '-' would produce a hyphen, which if
> >> copy, wouldn't be interpreted correctly by a command.
> >>
> >> The offending line in the file is 41:
> >>
> >> options starting with two dashes ('-')
> > 
> > When I run the following command on the manpage :
> > 
> > man ./manpage.1.ex | xxd
> > 
> > The resulting text from the dash line 41 is converted to the correct 2d
> > minus ascii char.
> > 
> > The same is true for the two examples following that text, which are
> > correctly shown as \-\- in the source.
> > 
> > I am missing something? Or maybe the fact that this text is in a .SH
> > section make it work correctly?
> 
> Upstream groff(1) renders '-' and '\-' differently, as they should.
> However, since many manual pages in existence are incorrect, and they 
> use '-' when they should use '\-', Debian modifies the behavior by 
> downgrading hyphens into Latin minus sign.
> 
> Let's fix the page in the hope that Debian can some day remove that 
> workaround.
> 
> See the relevant part of :
> 
> .  \" Debian: Strictly, "-" is a hyphen while "\-" is a minus sign, and the
> .  \" former may not always be rendered in the form expected for things like
> .  \" command-line options.  Uncomment this if you want to make sure that
> .  \" manual pages you're writing are clear of this problem.
> .  if '\*[.T]'utf8' \
> .char - \[hy]
> 
> Cheers,
> 
> Alex
> 
> -- 
> Alejandro Colomar
> Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
> http://www.alejandro-colomar.es/

Bug#1010807: isc-dhcp: ftbfs on riscv64 arch

[Chris Hofstaedtler]

* Paul Wise :
> Since isc-dhcp is orphaned upstream, perhaps removing it from Debian is
> the right solution. There was a thread about that on debian-devel:
> 
> https://www.isc.org/blogs/dhcp-client-relay-eom/
> https://lists.debian.org/msgid-search/cbed3fa8-cee2-11ec-a5ca-491f092f2...@msgid.mathom.us

The client and the relay are, but the server is not "orphaned
upstream". So even if client and relay go away, I imagine this still
needs some form of fix.

Chris

Bug#1016433: FTBFS: undefined reference during linking

[Philippe SWARTVAGHER]

Source: gir-to-d
Version: 0.22.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: phil.sw...@gmx.fr

Dear Maintainer,

On an up-to-date Sid, gir-to-d fails to build from source:

% apt source gir-to-d
...
% sudo apt build-dep gir-to-d
...
% cd gir-to-d-0.22.0
% debuild -us -uc
...
[20/20] ldc2  -of=girtod girtod.p/source_girtod.d.o 
girtod.p/source_gtd_DefReader.d.o girtod.p/source_gtd_GlibTypes.d.o 
girtod.p/source_gtd_GirAlias.d.o girtod.p/source_gtd_GirConstant.d.o 
girtod.p/source_gtd_GirEnum.d.o girtod.p/source_gtd_GirField.d.o 
girtod.p/source_gtd_GirFunction.d.o girtod.p/source_gtd_GirPackage.d.o 
girtod.p/source_gtd_GirStruct.d.o girtod.p/source_gtd_GirType.d.o 
girtod.p/source_gtd_GirVersion.d.o girtod.p/source_gtd_GirWrapper.d.o 
girtod.p/source_gtd_IndentedStringBuilder.d.o girtod.p/source_gtd_Log.d.o 
girtod.p/source_gtd_LinkedHasMap.d.o girtod.p/source_gtd_WrapException.d.o 
girtod.p/source_gtd_XMLReader.d.o -L=--allow-shlib-undefined 
-link-defaultlib-shared -L=-z -L=relro -O -g -release -wi
FAILED: girtod
ldc2  -of=girtod girtod.p/source_girtod.d.o girtod.p/source_gtd_DefReader.d.o 
girtod.p/source_gtd_GlibTypes.d.o girtod.p/source_gtd_GirAlias.d.o 
girtod.p/source_gtd_GirConstant.d.o girtod.p/source_gtd_GirEnum.d.o 
girtod.p/source_gtd_GirField.d.o girtod.p/source_gtd_GirFunction.d.o 
girtod.p/source_gtd_GirPackage.d.o girtod.p/source_gtd_GirStruct.d.o 
girtod.p/source_gtd_GirType.d.o girtod.p/source_gtd_GirVersion.d.o 
girtod.p/source_gtd_GirWrapper.d.o 
girtod.p/source_gtd_IndentedStringBuilder.d.o girtod.p/source_gtd_Log.d.o 
girtod.p/source_gtd_LinkedHasMap.d.o girtod.p/source_gtd_WrapException.d.o 
girtod.p/source_gtd_XMLReader.d.o -L=--allow-shlib-undefined 
-link-defaultlib-shared -L=-z -L=relro -O -g -release -wi
/usr/bin/ld: girtod.p/source_gtd_GirPackage.d.o: in function 
`_D3gtd12LinkedHasMap__T13LinkedHashMapTAyaTCQBq11GirFunctionQnZQBo4Node11__xopEqualsMxFKxSQDkQDj__TQCyTQCmTQCmZQDkQBwZb':
/home/philippe/tmp/gir-to-d-0.22.0/obj-x86_64-linux-gnu/../source/gtd/LinkedHasMap.d:27:
 undefined reference to 
`_D6object__T8opEqualsTxC3gtd11GirFunctionQnTxQwZQBkFxQBexQBiZb'
collect2: error: ld returned 1 exit status
Error: /usr/bin/cc failed with status: 1
ninja: build stopped: subcommand failed.
dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v 
returned exit code 1
make: *** [debian/rules:8 : build] Erreur 25
dpkg-buildpackage: erreur: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui failed

I found this bug when trying to figure out why gir-to-d didn't migrate
to testing (see gir-to-d's excuses). The blocked migration of gir-to-d
blocks also several packages like tilix, gtk-d or glib-d.

Philippe.

Bug#964527: freebsd-buildutils: replace transitional bsdmainutils dependency

[Chris Hofstaedtler]

Hi,

> your package currently Depends on bsdmainutils, which has become a 
> transitional
> package.
> 
> Please change the dependency to one of the replacement packages:
[..]

Is there any progress on this? Could we please get this done?

Thanks,
Chris

Bug#964534: cppman: replace transitional bsdmainutils dependency

[Chris Hofstaedtler]

Hi,

> your package currently Depends on bsdmainutils, which has become a 
> transitional
> package.
> 
> Please change the dependency to one of the replacement packages:
[..]

Is there any progress on this? Could we please get this done?

Thanks,
Chris

Bug#1015254: transition: opencascade

[Tobias Frost]

On Sun, Jul 31, 2022 at 02:02:22PM +0200, Tobias Frost wrote:

(...)

> as NEW will be involved)

Silly me, NEW is not involved...

I've uploading 7.6.3 right now to experimental; as I removed the confirmed tag, 
please reACK
the "go ahead" -- I've tested that all r-depends that worked before are still 
compiling

-- 
tobi

Bug#1016432: Replace Build-Depends: bsdmainutils (transitional)

[Chris Hofstaedtler]

Source: calc

Dear Maintainer,

I've noticed your package Build-Depends on bsdmainutils, which is a
transitional package since bullseye. Please switch to one of the
packages replacing bsdmainutils instead.

Thanks,
Chris

Bug#1016431: Replace Build-Depends: bsdmainutils (transitional)

[Chris Hofstaedtler]

Source: sendmail

Dear Maintainer,

I've noticed your package Build-Depends on bsdmainutils, which is a
transitional package since bullseye. Please switch to one of the
packages replacing bsdmainutils instead.
Maybe bsdextrautils, if the program you are after is "ul".

Thanks,
Chris

Bug#1016430: netgen: New upstream version 6.2.2007 available / why is the version overriden with +really?

[Tobias Frost]

Source: netgen
Version: 6.2.2006+really6.2.1905+dfsg-2.1
Severity: important

Hi Kurt,

netgen is currently RC buggy (#1014964), which is fixed upstream.

However, the Debian appendix "+really6.2.1905+dfsg-5" scheme indicates that 
6.2.1905 has been uploaded
intentially, to override 6.2.2006 with 6.2.1905.

However, I could not find any documentation WHY that is (this should be really 
have been documented in d/copyright or with
a bug in the BTS, closed by the "+really" uplaod

So I wonder
 - what were the reasons for the "+really" upload?
 - are the reasons still valid, IOW, could an new upstream version be prepared?

Thanks for your feedback! 

-- 
tobi

Bug#1016429: Replace Build-Depends: bsdmainutils (transitional)

[Chris Hofstaedtler]

Source: libedit

Dear Maintainer,

I've noticed your package Build-Depends on bsdmainutils, which is a
transitional package since bullseye. Please switch to one of the
packages replacing bsdmainutils instead.
Glancing at the source I could not see which package is needed,
maybe bsdmainutils is not needed at all anymore?

Thanks,
Chris

Bug#1016428: Replace Build-Depends: bsdmainutils (transitional)

[Chris Hofstaedtler]

Source: loadlin

Dear Maintainer,

I've noticed your package Build-Depends on bsdmainutils, which is a
transitional package since bullseye. Please switch to bsdextrautils
instead.

Preferably during the bookworm development cycle.

Thanks,
Chris

Bug#1016427: RM: golint -- RoQA; Upstream discontinued

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: z...@debian.org, f...@debian.org

Hi,

The repo of golint https://github.com/golang/lint has been archived.
Upstream has discontinued the development. Please remove it from unstable.

Bug#964533: bsdmainutils

[Chris Hofstaedtler]

* Chris Hofstaedtler  [220731 15:29]:
> Please either remove bsdmainutils from Depends: (preferred for
> Debian), or use
> bsdextrautils | bsdmainutils
> if you must support oldstable or older.

Please also take care of Build-Depends.

Chris

Bug#964533: closed by Debian FTP Masters (reply to Hilko Bengen ) (Bug#964533: fixed in libguestfs 1:1.44.0-2)

[Chris Hofstaedtler]

Control: reopen 964533
Control: found 964533 1:1.46.2-2

Hi Hilko,

* Debian Bug Tracking System :
> #964533: libguestfs0: replace transitional bsdmainutils dependency

>  libguestfs (1:1.44.0-2) unstable; urgency=medium
>  .
>* Replace bsdmainutils dependency (Closes: #964531, 964533)


Thanks for working on this, but it appears the bsdmainutils
dependency got reintroduced in 49bd1b95. libguestfs0 now depends on
BOTH bsdmainutils and bsdextrautils.

Please either remove bsdmainutils from Depends: (preferred for
Debian), or use
bsdextrautils | bsdmainutils
if you must support oldstable or older.

Thanks,
Chris

Bug#1016285: mupdf: segmentation fault

[Bastian Germann]

Am 29.07.22 um 18:45 schrieb jindam, vani:

Kernel: Linux 3.18.91-16078765 (SMP w/4 CPU threads; PREEMPT)


Can somebody with a reasonably modern kernel version confirm this?

Bug#152195: Suggested --homeless option may now be redundant

[Jason Franklin]

Greetings:

I began implementing the solution to this bug just this morning.

There are two parts to the fix:
  1. Clarify the intent of --no-create-home in the man page.
  2. Implement the new --homeless option.

I think that #2 has become redundant given that new systems users are
now "homeless" by default. This was not the case when we first decided
to add the --homeless option.

I cannot think of a situation where one would want to have a "homeless"
non-system (normal) user. Thus, I now think adding this option would be
a mistake.

If it is okay, I will skip the implementation of --homeless and just
proceed with updating the documentation for the --no-create-home option.

Sound good?

-- 
Jason Franklin

Bug#1016426: broadcom-sta-dkms: No network detected with bcm4322 on MBP7,1

[Alex Beer]

Package: broadcom-sta-dkms
Version: 6.30.223.271-20
Severity: normal
X-Debbugs-Cc: emse...@gmail.com

Dear Maintainer,
I go no wifi network after boot ("nmcli d w l" list nothing), sometimes network 
are listed after suspend.
From dmseg:
[  119.095659] sr 1:0:0:0: [sr0] tag#7 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  119.095671] sr 1:0:0:0: [sr0] tag#7 Sense Key : Illegal Request [current] 
[  119.095676] sr 1:0:0:0: [sr0] tag#7 Add. Sense: Read of scrambled sector 
without authentication
[  119.095680] sr 1:0:0:0: [sr0] tag#7 CDB: Read(10) 28 00 00 2c 94 40 00 00 40 
00
[  119.095683] I/O error, dev sr0, sector 11686144 op 0x0:(READ) flags 0x80700 
phys_seg 2 prio class 0
[  119.206761] sr 1:0:0:0: [sr0] tag#23 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  119.206773] sr 1:0:0:0: [sr0] tag#23 Sense Key : Illegal Request [current] 
[  119.206777] sr 1:0:0:0: [sr0] tag#23 Add. Sense: Read of scrambled sector 
without authentication
[  119.206782] sr 1:0:0:0: [sr0] tag#23 CDB: Read(10) 28 00 00 2c 94 5e 00 00 
02 00
[  119.206784] I/O error, dev sr0, sector 11686264 op 0x0:(READ) flags 0x0 
phys_seg 1 prio class 0
[  119.206790] Buffer I/O error on dev sr0, logical block 1460783, async page 
read
[  120.502731] rfkill: input handler disabled
[  121.654995] UDF-fs: INFO Mounting volume 'DVDVolume', timestamp 2036/02/07 
10:58 (1000)
[  123.434454] sr 1:0:0:0: [sr0] tag#8 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  123.434467] sr 1:0:0:0: [sr0] tag#8 Sense Key : Illegal Request [current] 
[  123.434472] sr 1:0:0:0: [sr0] tag#8 Add. Sense: Read of scrambled sector 
without authentication
[  123.434476] sr 1:0:0:0: [sr0] tag#8 CDB: Read(10) 28 00 00 2c 94 40 00 00 40 
00
[  123.434479] I/O error, dev sr0, sector 11686144 op 0x0:(READ) flags 0x80700 
phys_seg 21 prio class 0
[  123.534452] sr 1:0:0:0: [sr0] tag#10 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  123.534463] sr 1:0:0:0: [sr0] tag#10 Sense Key : Illegal Request [current] 
[  123.534468] sr 1:0:0:0: [sr0] tag#10 Add. Sense: Read of scrambled sector 
without authentication
[  123.534473] sr 1:0:0:0: [sr0] tag#10 CDB: Read(10) 28 00 00 2c 94 41 00 00 
01 00
[  123.534475] I/O error, dev sr0, sector 11686148 op 0x0:(READ) flags 0x0 
phys_seg 1 prio class 0
[  123.534482] Buffer I/O error on dev sr0, logical block 2921537, async page 
read
[  187.686681] sr 1:0:0:0: [sr0] tag#10 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  187.686693] sr 1:0:0:0: [sr0] tag#10 Sense Key : Illegal Request [current] 
[  187.686697] sr 1:0:0:0: [sr0] tag#10 Add. Sense: Read of scrambled sector 
without authentication
[  187.686702] sr 1:0:0:0: [sr0] tag#10 CDB: Read(10) 28 00 00 0b d4 48 00 00 
40 00
[  187.686704] I/O error, dev sr0, sector 3100960 op 0x0:(READ) flags 0x80700 
phys_seg 2 prio class 0
[  188.646510] sr 1:0:0:0: [sr0] tag#11 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  188.646521] sr 1:0:0:0: [sr0] tag#11 Sense Key : Illegal Request [current] 
[  188.646526] sr 1:0:0:0: [sr0] tag#11 Add. Sense: Read of scrambled sector 
without authentication
[  188.646530] sr 1:0:0:0: [sr0] tag#11 CDB: Read(10) 28 00 00 0b d4 88 00 00 
40 00
[  188.646533] I/O error, dev sr0, sector 3101216 op 0x0:(READ) flags 0x80700 
phys_seg 10 prio class 0
[  188.734483] sr 1:0:0:0: [sr0] tag#12 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  188.734495] sr 1:0:0:0: [sr0] tag#12 Sense Key : Illegal Request [current] 
[  188.734500] sr 1:0:0:0: [sr0] tag#12 Add. Sense: Read of scrambled sector 
without authentication
[  188.734504] sr 1:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 0b d4 48 00 00 
02 00
[  188.734507] I/O error, dev sr0, sector 3100960 op 0x0:(READ) flags 0x0 
phys_seg 2 prio class 0
[  188.734513] Buffer I/O error on dev sr0, logical block 775240, async page 
read
[  188.734518] Buffer I/O error on dev sr0, logical block 775241, async page 
read
[  188.766693] sr 1:0:0:0: [sr0] tag#13 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  188.766706] sr 1:0:0:0: [sr0] tag#13 Sense Key : Illegal Request [current] 
[  188.766710] sr 1:0:0:0: [sr0] tag#13 Add. Sense: Read of scrambled sector 
without authentication
[  188.766715] sr 1:0:0:0: [sr0] tag#13 CDB: Read(10) 28 00 00 0b d4 48 00 00 
01 00
[  188.766718] I/O error, dev sr0, sector 3100960 op 0x0:(READ) flags 0x0 
phys_seg 1 prio class 0
[  188.766724] Buffer I/O error on dev sr0, logical block 775240, async page 
read
[  188.802496] sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK cmd_age=0s
[  188.802508] sr 1:0:0:0: [sr0] tag#0 Sense Key : Illegal Request [current] 
[  188.802513] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Read of scrambled sector 
without authentication
[  188.802517] sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 0b d4 48 00 00 01 
00
[  188.802520] I/O error, dev sr0, sector 3100960 op 0x0:(READ) flags 0x0 

Bug#876908: Is blcr completely useless?

[Bastian Germann]

Control: retitle -1 RM: blcr -- RoQA; unmaintained; broken for several releases
Control: reassign -1 ftp.debian.org
Control: block 575848 by -1

Please remove blcr from Debian. I do not think that there are users left at
this point and nobody reacted to Adrian's request.

On Fri, 5 Mar 2021 14:48:15 +0200 Adrian Bunk  wrote:

3.5 years later the situation looks unchanged,
please let me know if you see any reason for
still keeping blcr in Debian.

Adrian


On Tue, Sep 26, 2017 at 08:52:08PM +0100, Alan Woodland wrote:
> On 26 September 2017 at 20:28, Adrian Bunk  wrote:
> >
> > Source: blcr
> > Version: 0.8.5-2.1
> > Severity: serious
> > Tags: buster sid
> >
> > As far as I can see:
> > 1. blcr is dead upstream since 2013.
> > 2. blcr requires both userspace and kernel parts.
> > 3. The -dkms package is removed in unstable.
> > 4. The beta version in experimental has an RC bug against
> >the -dkms package that the module does not build
> >with the jessie (sic) kernel.
> >
> > mpich is linked with the userspace library,
> > but does that make any sense without the kernel part?
> 
> There was some activity in 2014 - 0.8.6 beta4, but the last I heard it

> still had some issues with PPC64 that meant it wasn't worth uploading
> to experimental and my plan was to hold out. Since there haven't been
> any new versions released since then I'm inclined to agree. That'll
> need a patch to the MPI build config though to stop linking against
> and requiring the blcr userspace libraries as a precursor to actually
> removing BLCR from sid.
> 
> In theory people could still be running old kernels to keep support

> alive and if that's the case then we should try to avoid breaking
> things, but certainly I've not actively been using BLCR in my work for
> quite some time now.
> 
> Alan

Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3

[Rene Engelhard]

Hi,

Am 31.07.22 um 12:33 schrieb Rene Engelhard:

[ Reason ]
It seems the volution adress book is broken since 2015 due to a evolution
change. Apparently noone noticed until 2021, where I backported the patch but 
then
actually forgot to request a stable update

[ Impact ]
It stays broken.

[ Tests ]
None, ttbomk. Except manually connecting to a evolution adress book.

[ Risks ]
Quite a big change which removes compat with old, not-compatible anymore
evolution and thus also has a bit of code cleanup upstream. But it's a
upstream commit and there ttbomk was no complaints afterwards that it
didn't work again.


This is now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016420 
(where the upstream bug which that one is marked as forwarded to has 
also the reasoning why support for < 3.16 was dropped which makes the 
patch bigger).


Regards,

Ren

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Jérémy Lal]

Le dim. 31 juil. 2022 à 16:27, Dominique Dumont  a
écrit :

> On Saturday, 30 July 2022 19:36:26 CEST you wrote:
> > libuv1 is a library, you're supposed to manage the transition:
> > https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>
> This page applies when the new version breaks the ABI or API. This was not
> the
> case. There was no symbol change. The SO version of libuv1 has not changed
> since the transition between libuv and libuv1.
>

Indeed, sorry for my somewhat irritated tone - it just happens that it was
the second time
libuv1 was updated during a nodejs transition, and the upstream bug it
creates on nodejs
hasn't been fixed yet, so it shoots the transition in the guts.
Nodejs depends heavily on libuv1...

> In particular, rebuild all reverse build dependencies and check they
> won't
> break is highly desirable.
> > There are tools and services in debian to do that (though honestly it's
> not
> so easy to setup).
>
> I'm already stretched quite thin. I'll see what I can do.
>
> In any case, I'd be happy to handover libuv1 to people willing to better
> maintain this package.


Maybe a simple approach would be to upload libuv1 updates to experimental
first,
and wait a week to see how it scares the others :)

Jérémy
Jérémy

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Dominique Dumont]

On Saturday, 30 July 2022 19:36:26 CEST you wrote:
> libuv1 is a library, you're supposed to manage the transition:
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions

This page applies when the new version breaks the ABI or API. This was not the 
case. There was no symbol change. The SO version of libuv1 has not changed 
since the transition between libuv and libuv1.

> In particular, rebuild all reverse build dependencies and check they won't 
break is highly desirable.
> There are tools and services in debian to do that (though honestly it's not 
so easy to setup).

I'm already stretched quite thin. I'll see what I can do.

In any case, I'd be happy to handover libuv1 to people willing to better 
maintain this package.

All the best.

Bug#1016425: gnudatalanguage: test-gdl autopkgtest is flaky

[Bas Couwenberg]

Source: gnudatalanguage
Version: 1.0.1-3
Severity: important
Tags: patch

Dear Maintainer,

The test-gdl autopkgtest is flaky and should be marked as such.

Please apply the attached patch.

Kind Regards,

Bas
diff -Nru gnudatalanguage-1.0.1/debian/changelog 
gnudatalanguage-1.0.1/debian/changelog
--- gnudatalanguage-1.0.1/debian/changelog  2021-12-11 13:06:20.0 
+0100
+++ gnudatalanguage-1.0.1/debian/changelog  2022-07-31 15:45:11.0 
+0200
@@ -1,3 +1,10 @@
+gnudatalanguage (1.0.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark test-gdl autopkgtest as flaky.
+
+ -- Bas Couwenberg   Sun, 31 Jul 2022 15:45:11 +0200
+
 gnudatalanguage (1.0.1-3) unstable; urgency=medium
 
   * Lift the usual restrictions on the size of the global offset table
diff -Nru gnudatalanguage-1.0.1/debian/tests/control 
gnudatalanguage-1.0.1/debian/tests/control
--- gnudatalanguage-1.0.1/debian/tests/control  2020-06-20 14:34:35.0 
+0200
+++ gnudatalanguage-1.0.1/debian/tests/control  2022-07-31 15:45:08.0 
+0200
@@ -1,6 +1,6 @@
 Tests: test-gdl
 Depends: gnudatalanguage, xauth, xvfb, plplot-driver-xwin
-Restrictions: allow-stderr
+Restrictions: allow-stderr, flaky
 
 Tests: test-GDL.py
 Depends: python3-gdl, python3-pytest, python3-numpy

Bug#1016422: eatmydata: wrapper script has missed library path change

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Sun, Jul 31, 2022 at 04:00:24PM +0200, Marcel Partap wrote:
> It still references `/usr/lib/libeatmydata` instead of `/usr/lib/arch` ..
> resulting in:
> 
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded
> (cannot open shared object file): ignored.

That's not it.

the wrapper script is using LD_LIBRARY_PATH to be backward-compatible
with places where libeatmydata.so was places in that
/usr/lib/libeatmydata directory.

Now that the .so has been moved to
/usr/lib/x86_64-linux-gnu/libeatmydata.so there is no need anymore to
have LD_LIBRARY_PATH at all, as that directory is part of the standard
search path.

Please double check what kind of environment you are trying to
eatmydata, perhaps you are in a multi-arch setting, and missing a copy
of the library for the appropriate architecture?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1016424: “Error: /invalidfileaccess in --file--” when converting PBM file to PDF

[anonymous coward]

Package: ghostscript
Version: 9.53.3~dfsg-7+deb11u2
Severity: normal
X-Debbugs-Cc: debbug.ghostscr...@sideload.33mail.com

Ghostscript fails to convert PBM files to PDF. Attempts were made with
3 different PBM files:

  1) scanner-made PDF → (pdfimages -all) → (unpaper) → PBM → 
(ghostscript/pdfwrite) → error
  2) tex → (LaTeX) → PDF → (ghostscript/pbm) → PBM → (ghostscript/pdfwrite) → 
error
  3) (imagemagick) → PBM → (ghostscript/pdfwrite) → error

This seems to show that PBMs of any kind produce an error when using
the PDFwrite driver.  Case 2 is interesting because it shows
Ghostscript’s own output is fed back into it and it can’t handle it.
Case 3 is demonstrated below because it requires no source file to
start with (ImageMagick gives a way to generate an arbitrary image
on-the-fly).  So it’s easy to reproduce as long as ImageMagick is
installed.

===8<--
  $ convert logo: -colors 2 -colorspace gray -normalize pbm:im_logo.pbm
  
  $ gs -sDEVICE=pdfwrite -q -r300 -dSCALE=1 -o im_logo.pdf -- 
/usr/share/ghostscript/9.53.3/lib/viewpbm.ps im_logo.pbm
  Error: /invalidfileaccess in --file--
  Operand stack:
 (im_logo.pbm)   (r)
  Execution stack:
 %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   
1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--   
--nostringval--   --nostringval--   %array_continue   --nostringval--
  Dictionary stack:
 --dict:734/1123(ro)(G)--   --dict:0/20(G)--   --dict:87/200(L)--   
--dict:0/20(L)--
  Current allocation mode is local
  Last OS error: Permission denied
  Current file position is 10282
  GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
===8<--

It’s worth noting that case 2 has no problem if the middle step uses
the ppmraw driver instead of the pbm driver. So I thought perhaps a
workaround would be to convert the PBM file produced by unpaper (case
1) to PPM, then feed the PPM file into GS -- but no, the same
“invalidfileaccess” occurs. I also retried case 3 but using a PPM
instead, which also failed:

===8<--
  $ convert logo: -colors 2 -colorspace gray  -normalize pbm:im_logo.ppm
  $ gs -sDEVICE=pdfwrite -q -r300 -dSCALE=1 -o im_logo_ppm.pdf -- 
/usr/share/ghostscript/9.53.3/lib/viewpbm.ps im_logo.ppm
Error: /invalidfileaccess in --file--
Operand stack:
   (im_logo.ppm)   (r)
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   
1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--   
--nostringval--   --nostringval--   %array_continue   --nostringval--
Dictionary stack:
   --dict:734/1123(ro)(G)--   --dict:0/20(G)--   --dict:87/200(L)--   
--dict:0/20(L)--
Current allocation mode is local
Last OS error: Permission denied
Current file position is 10282
GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
===8<--

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

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

Versions of packages ghostscript depends on:
ii  libc6   2.31-13+deb11u3
ii  libgs9  9.53.3~dfsg-7+deb11u2

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.53.3~dfsg-7+deb11u2

-- no debconf information

Bug#1016422: eatmydata: wrapper script has missed library path change

[Marcel Partap]

Package: eatmydata
Version: 130-2
Severity: normal
X-Debbugs-Cc: mpar...@gmx.net

It still references `/usr/lib/libeatmydata` instead of `/usr/lib/arch` ..
resulting in:

ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 eatmydata depends on:
ii  libeatmydata1  130-2

eatmydata recommends no packages.

eatmydata suggests no packages.

-- no debconf information

Bug#1016055: fmtutil failed. Output has been stored in

[Klaus Ethgen]

Some additional informations:

Yesterday I found files from texlive-pictures with 0 bytes size. I
reinstalled that package and the files have correct size now.

Gruß
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1016055: fmtutil failed. Output has been stored in

[Klaus Ethgen]

Hi,

Am So den 31. Jul 2022 um 13:26 schrieb Hilmar Preuße:
> You could try to run "fmtutil-sys --all" as user root. If that works try to
> start over using  "apt -f install".

Both successful but the apt did not reinstall anything. I believe as it
was in trigger and the broken package was already installed.

Gruß
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1015904: r-cran-urlchecker_1.0.1-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sat, Jul 30, 2022 at 07:06:38PM + schrieb Thorsten Alteholz:
> please also mention the GPL-2 of urlchecker/inst/tools/urltools.R in your 
> debian/copyright.

I've added an extra paragraph to d/copyright.  However, IMHO there is no
real point for a reject here since the "or later" statement of GPL-2+
should be fullfilled by GPL-3.  I'd be very happy if you would save
you and the Uploader some work in similar cases in future.

Thanks a lot anyway

 Andreas.

-- 
http://fam-tille.de

Bug#1016323: gnuplot: FTBFS: dvips: DVI file can't be opened: gnuplot.dvi: No such file or directory

[Adrian Bunk]

Control: reassign -1 texlive-latex-base 2022.20220722-1
Control: affects -1 src:gnuplot
Control: retitle -1 hyperref no longer working with the utf8x option of inputenc

On Fri, Jul 29, 2022 at 08:34:35PM +0200, Lucas Nussbaum wrote:
>...
> > ! Argument of ? has an extra }.
> >  
> > \par 
> > l.4045 \ProcessKeyvalOptions{Hyp}
>...

It works after downgrading texlive-latex-base to 2022.20220605-1.

Testcase:

$ cat test.tex 
\documentclass{article}
\usepackage[utf8x]{inputenc}
\usepackage{hyperref}
\begin{document}
.
\end{document}
$ latex test.tex 
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2022-06-01> patch level 5
L3 programming layer <2022-07-15>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def))
(/usr/share/texlive/texmf-dist/tex/latex/ucs/ucs.sty
(/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-global.def))
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty)
(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty)
(/usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
(/usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/generic/kvsetkeys/kvsetkeys.sty)
(/usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty)
(/usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty)
(/usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty)
(/usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
(/usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty)
(/usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
(/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty)))
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def)
(/usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty)
(/usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def)
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty)
(/usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
(/usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty))
(/usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty))
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hdvips.def
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pdfmark.def
(/usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty)
(/usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-dvips.def)
(./test.aux) (/usr/share/texlive/texmf-dist/tex/latex/ucs/ucsencs.def)
(./test.out) (./test.out)

Package hyperref Warning: Rerun to get /PageLabels entry.

! Argument of � has an extra }.
 
\par 
l.6 \end{document}
  
? 



cu
Adrian

Bug#1016421: installation-reports: does not accept IPv6 link-local address for default route

[Ansgar]

Package: installation-reports
Severity: normal
Tags: ipv6

Boot method: DVD image
Image version: Debian 11.3 (amd64/netinstall)
Date: 

Machine: IPv6-only VM in Hetzner cloud (https://cloud.hetzner.de)

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [E]

Hetzner asks to specify a link-local address as the default route
(fe80::1).  This works with `ip route` with the `onlink` flag, but d-i
says "Unrechable gateway: The gateway address you entered is
unreachable."

Ansgar

Bug#970060: r-cran-pkgdown_2.0.6-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sat, Jul 30, 2022 at 06:00:08PM + schrieb Thorsten Alteholz:
> please also mention at least Aidan Feldman in your debian/copyright.

Fixed in new upload - thanks for checking

  Andreas. 

-- 
http://fam-tille.de

Bug#1016420: libreoffice-evolution: Evolution address source indefinitely freezes UI

[Rene Engelhard]

Package: libreoffice-evolution
Severity: grave
Justification: renders package unusable
Control: forwarded -1 https://bugs.documentfoundation.org/show_bug.cgi?id=137101
Control: tag -1 + upstream
Control: tag -1 + fixed-upstream
Control: fixed -1 1:7.3.0~rc1-1
Control: block -1 by 1016413

Hi,

filing for documentation purposes. Sparing a version since it should
affect anything back to stretch and even earlier.

LibreOffice hangs indefinitely when connecting to an evolution address
book, blocking the UI.

See upstream bug
https://bugs.documentfoundation.org/show_bug.cgi?id=137101; this is
because of an ABI change in evolution no one really noticed until years
after it (and LO is not linking against libebook but dynamically loading it)

This is already upstream and a stable update is requested in #1016413

Regards,

Rene

Bug#910782: Fixed in the yet-to-be-released 5.97 upstream version

[Aurélien COUDERC]

https://invent.kde.org/frameworks/kwallet/-/
merge_requests/11[1]


[1] https://invent.kde.org/frameworks/kwallet/-/
merge_requests/11

Bug#1013079: installation-reports: GUI install option isn't visible on boot

[Philip Hands]

Holger Wansing  writes:

> Hi,
>
>> > - On Jun 17, 2022, at 7:43 AM, Philip Hands p...@hands.com wrote:
>> > > 
>> > >  https://openqa.debian.net/tests/60553#step/_boot_to_debianinstaller/2
>> > > 
>> > > if you look closely in the highlighted box, you can just about see
>> > > "Graphical install" as a black font on dark_blue background, but it's
>> > > very close to invisible.
>> > > 
>> > > It should have an inverted background on the selected item, which then
>> > > makes the black text easily visible, as seen in the last working test,
>> > > using a netinst ISO from 2022-06-07 17:27:
>> > > 
>> > >  https://openqa.debian.net/tests/59056#step/_boot_to_debianinstaller/1
>
> Since the URLs from above are no longer valid, I'm attaching two screenshots
> to show the issue (the first one from the last working 2022-06-07 image,
> the second from today's installer image).

Oh -- There's supposed to be a setting that keeps old tests if they've
been refereed to from certain URLs (and I thought I'd set that to
include the BTS, and had made a point of doing such an access to tag the
build as a keeper) but it seems not to have worked.

I shall see what I can do to fix that...

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#1013079: installation-reports: GUI install option isn't visible on boot

[Chris Hofstaedtler]

Control: reassign -1 debian-cd

Hi,

* Holger Wansing :
> > > - On Jun 17, 2022, at 7:43 AM, Philip Hands p...@hands.com wrote:
> > > > 
> > > >  https://openqa.debian.net/tests/60553#step/_boot_to_debianinstaller/2
> > > > 
> > > > if you look closely in the highlighted box, you can just about see
> > > > "Graphical install" as a black font on dark_blue background, but it's
> > > > very close to invisible.
> > > > 
> > > > It should have an inverted background on the selected item, which then
> > > > makes the black text easily visible, as seen in the last working test,
> > > > using a netinst ISO from 2022-06-07 17:27:
> > > > 
> > > >  https://openqa.debian.net/tests/59056#step/_boot_to_debianinstaller/1

I'm reassigning this to debian-cd, because:
- grub2 upstream has deleted support for grayscale PNGs. I don't
  think this is coming back.
- the menu on the installer ISOs uses a grayscale image to highlight
  the currently selected menu entry. As demonstrated in the bug
  report, this is now broken.

While technically grub2 broke this, I'd think the way forward is for
debian-cd to convert the highlight PNGs to non-grayscale.

FTR:
debian-cd/data/bookworm/hl_c.png: PNG image data, 20 x 20, 8-bit grayscale, 
non-interlaced

Hope this helps in resolving the issue,
Chris

Bug#1003397:

[Daichi Fukui]

Hello Iwamatsu-san,

> First, This is embedded with C4CORE.
> Do you have any plans to package this?
>  https://github.com/biojppm/c4core

Thanks for pointing this out.
Looks like we need to package c4core as well.
Yes, I'll do that.

But before starting it, let me share one thing as follows.
According to .gitmodule, c4core depends on cmake, debugbreak, and
fast_float [0].
Then, is it correct to say we need to package debugbreak and fast_float as
well as c4core?

As for other stuff you mentioned, I'll do them accordingly.

[0]
https://github.com/biojppm/c4core/blob/5ff3aa3a10c65c784d12716954e1e742376620d0/.gitmodules

Best,
Fukui

On Mon, 25 Jul 2022 at 06:58, Nobuhiro Iwamatsu 
wrote:

> Hi Daichi,
>
> I reviewed your package.
>
> First, This is emedded with C4CORE.
> Do you have any plans to package this?
>   https://github.com/biojppm/c4core
>
> debain/control:
>   development package is required., because this is a library.
>
> debian/patches:
>   Currently, this package does not have any patches. so this can delete.
>
> Best regards,
>   Nobuhiro
>
> 2022年7月20日(水) 23:09 Daichi Fukui :
>
> >
> > Hello Iwamatsu-san,
> >
> > I have drafted a source package of rapidyaml and put it onto my private
> repository in salsa:
> >
> > https://salsa.debian.org/dfukui/rapidyaml/-/tree/debian/0.4.1-1
> >
> > When you have time, can you review the source package and help me upload
> it to the archive?
> >
> > Best regards,
> > Fukui
>
>
>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6
>

Bug#1015742: Reverted droping symbols

[Andreas Tille]

Hi Boyuan Yang,

I admit symbols files are a maintenance burden for C++ libraries.
However, it helps to spot ABI changes for new upstream versions.  To
reduce the maintenance burden while keeping that ABI change detection
functionality I frequently maintain amd64 symbols only.  Motivated by
this bug report I have re-added the symbols you droped in your last
upload.

Hope this helps

 Andreas.

-- 
http://fam-tille.de

Bug#1016419: tag W-compiler-flags-hidden has different for html log and text log

[肖盛文]

Package: blhc
Version: 0.13-2
Severity: normal
X-Debbugs-Cc: atzli...@sina.com

Hi,
blhc W-compiler-flags-hidden tag has different for html log and text log.

For example:

1. download the html format log
wget -O html.log 
"https://buildd.debian.org/status/fetch.php?pkg=grub-customizer=riscv64=5.2.1-2=1659139651=0;

blhc html.log
NONVERBOSE BUILD: [ 50%] Building CXX object 
CMakeFiles/grub-customizer.dir/src/main/client.cpp.o
NONVERBOSE BUILD: [ 50%] Building CXX object 
CMakeFiles/grub-customizer.dir/src/Bootstrap/GtkApplication.cpp.o
NONVERBOSE BUILD: [ 50%] Building CXX object 
CMakeFiles/grub-customizer.dir/src/Bootstrap/GtkView.cpp.o
NONVERBOSE BUILD: [ 50%] Building CXX object 
CMakeFiles/grubcfg-proxy.dir/src/main/proxy.cpp.o
NONVERBOSE BUILD: [ 62%] Building CXX object 
CMakeFiles/grub-customizer.dir/src/Bootstrap/FactoryImpl/GlibThread.cpp.o
NONVERBOSE BUILD: [ 75%] Building CXX object 
CMakeFiles/grub-customizer.dir/src/Bootstrap/FactoryImpl/GLibRegex.cpp.o

2. download the text format log
wget -O text.log 
"https://buildd.debian.org/status/fetch.php?pkg=grub-customizer=riscv64=5.2.1-2=1659139651=1;
blhc text.log

There is not error infos output.

Is the blhc use html format log to check on qa.d.o?

BTW:
I find this bug from:
https://qa.debian.org/bls/packages/g/grub-customizer.html

Issues found in current buildd logs for grub-customizer:

W compiler-flags-hidden 1 (of 14) hidden (riscv64)

Found 1 issues.

Regards,
xiao sheng wen

-- System Information:
Distributor ID: Atzlinux
Description:Tongwandou (atzlinux) 11
Release:11.4
Codename:   bullseye
Architecture: x86_64

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

Versions of packages blhc depends on:
ii  libdpkg-perl  1.20.11

blhc recommends no packages.

blhc suggests no packages.

-- no debconf information

Bug#864423: Software RAID is not activated at boot time

[Cyril Brulebois]

Chris Hofstaedtler  (2022-07-30):
> Hi debian-boot,
> 
> * László Böszörményi (GCS)  [220730 15:34]:
> > On Sat, Jul 30, 2022 at 1:50 PM Chris Hofstaedtler  wrote:
> > > whats the status of dmraid? Do you have dmraid hardware or is this
> > > merely on life-support?
> >  Please note dmraid upstream is dead for more than ten years. I might
> > find an old i386 hardware that needs it.
> > But yes, it's only on life-support.
> 
> [..]
> 
> > > I'm wondering if we should remove dmraid support from the d-i as a
> > > first step. AFAICT Intel Software RAID is supported by mdraid, not
> > > sure if the other RAID platforms are still sold.
> >  Sounds like a good idea. This will show users early Debian doesn't
> > plan to ship it anymore.
> 
> I was digging around in the d-i code, and it appears for dmraid to
> be invoked, one has to boot with disk-detect/dmraid/enable. 
> 
> I have opened merge requests to remove the dmraid/sataraid code from
> d-i. The changes look like low risk to me, but obviously I have no
> idea. For the lack of a build environment I also didn't test them.
> 
> Given d-i does nothing with dmraid unless the boot flag is present,
> I want to ask if dmraid could also stop shipping its udeb, if thats
> ok with debian-boot?

Given how specific it is, opt-in, on a specific arch, and dead upstream,
looks like a wholesale removal would be the best way forward, yes.

Thanks for digging into that.


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


signature.asc
Description: PGP signature

Bug#1016055: fmtutil failed. Output has been stored in

[Hilmar Preuße]

Am 31.07.2022 um 12:15 teilte Klaus Ethgen mit:

Hi,


buf_size=10 xetex -ini -jobname=xelatex-dev -progname=xelatex-dev -etex
xelatex.ini


Successful run. I append the log file to the mail.


Try to play with different values for buf_size. On [1] they speak about
increasing the buf_size, meanwhile they decrease the values.


Even without the buf_size setting, xetex runs fine.

You could try to run "fmtutil-sys --all" as user root. If that works try 
to start over using  "apt -f install".


Hilmst
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature