Bug#1069210: dh-elpa: Support nested directory in elpa installation

[Xiyue Deng]

Xiyue Deng  writes:

> Currently there is a behavior difference between elpafied packages and
> upstream ELPA packages on `load-path' handling: for elpafied packages,
> all nested directories are added to `load-path', while for upstream ELPA
> only the root directory is added.  Normally this should not be an issue,
> but when trying to elpafy auctex, it's nested directory "style/"
> contains many modules whose names collide with standard modules and
> hence broken Eglot.  This sounds like a bad practice of the package, but
> it would still be good to match upstream behavior so as to minimize
> surprises.  Will try to figure this out.

Well it took me quite a while to realize what's going on.

Initially I thought there were some handling in package.el that somehow
treated the dh-elpa installation path differently than
`package-user-dir'.  With extensive code search regarding `load-path',
`package-directory-list', `package-user-dir', as well as other relevant
functions/variables, and I even tried to consult on
emacs-de...@gnu.org[1] where Michael gave multiple suggestions and
pointers, still I didn't find anything.

Well, not until I tried to search for `load-path' in the whole Emacs
source when I noticed the function
`normal-top-level-add-subdirs-to-load-path', which were added to a
`subdirs.el' file which does what its name suggests.  Then it didn't
take long for me I to find the file
`/usr/share/emacs/site-lisp/subdirs.el', and the mystery is solved: this
file causes all the sub-directories of the directory with this file
being added to `load-path', including everything under the dh-elpa
installation path `elpa{,-src}'.

So, this means that as long as dh-elpa uses
`/usr/share/emacs/site-lisp/elpa{,-src}' as the installation path for
elpafied packages, all its subdirectories will be added to `load-path'
automatically, which is currently different with how package.el handles
ELPA package - it only adds the path holding the *-autoloads.el file to
`load-path'.

Right now I think there are two obvious directions forward:

* Move elpa{,-src} out of the path with a subdirs.el file, which means
  it should not use `/usr/share/emacs/site-lisp/elpa{,-src}', but
  something like `/usr/share/emacs/elpa{,-src}' or
  `/usr/share/emacs/${version}/elpa{,-src}'.  This would mean a big
  migration for all elpafied packages due to the directory change.

  - With the current ongoing discussion on fixing the loading /
configuration dependencies, a migration may happen anyway, so
probably both can be done?

* Patch the generated subdirs.el to skip any elpa{,-src} directories.
  I don't expect that upstream will accept such a change, so we'll
  probably have to carry this patch, which would not be ideal anyway.

There may be other ways.  Any advices are welcome!

P.S.  It's worth mentioning that when discussing with upstream, it is
unclear whether upstream will consider adding sub-directories of an ELPA
package to `load-path'.  Currently there are not much such use case, and
for the existing one case of auctex it'll cause some breakage, so the
likeliness is low for now.

[1] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00658.html
-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1071489: tracker.debian.org: please upgrade Lintian to the latest

[Martin-Éric Racine]

Package: tracker.debian.org
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The Lintian on tracker.debian.org complains that 4.7.0 is 
newer-standards-version.

Can you please upgrade it to the latest version?

Thanks!
Martin-Éric


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZK4hAACgkQrh+Cd8S0
17ZFURAAp9KXen+WQbxVK+guJxZGlyounwk1mUh/Y1wU1nTNkYZUc4FiUmUbboo+
suzPRjMaovnsXZtDkhBWaz0jLRf/F4ZleLW2WoEgd9t61+PnAOJ2J3GR4kfoYTT0
Dh/jBX6IWVGfhcT7U7rcrfIZHrn7Vi1+58T9mN4WnW6ja19M5ruBbmOik9Bt+zol
pBKEdSFdlNORt+b1yO7Kvz/vQOaOUZrtOUfEBl8L23LPJPger1P0BVcl1410hHXs
I1kq3fHT7+2wzpEaiziTbVH/eLWaOEAZCIkvqbKXfQbS5n8GvaIXFhcYN3PtEJJO
qfcrSZth7fMH0YOd9klkQ4i4C8SFI5R6FqPUIkifTb4xKfAa6GBU8tG7WxGz8Sja
rqSWr1A4uw+Q8A1MAjlLOVZGNYx71tN25nGcYdWtwnW0sYxTouAbsl+c7iLSIPu5
MIuNtnPb4kB1iSVJdF4vgfZ5DVk9THh72neCUe40tiq3IlPA1qjFs8Gzstr7V6UX
m9wbqxHAAhVwQt/fIlRd0cFcWkq2/1de3Fpi4BabC6M8RtiXvD7tDG4eBv/m7gfc
OFLqhzHIcA72rLs4SoIiaFkMO1YiHgnP1Ko301crS92gfZdTgLBG8ofbaE9PbkuY
8MNjLtPPBrQUWuj6w/7cGsK6u7he0qCEjK7+fP4b6dXz49axuIw=
=hj3T
-END PGP SIGNATURE-

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Johannes Schauer Marin Rodrigues]

Quoting Helmut Grohne (2024-05-20 07:17:54)
> Hi Chris,
> 
> On Mon, May 20, 2024 at 01:02:32AM +0200, Chris Hofstaedtler wrote:
> > "..., when using telinit from systemd-sysv"
> > 
> > It would seem like a reasonable assumption that systemd-sysv's
> > telinit uses systemd-specific stuff, like SIGTERM.
> 
> That also is an interesting angle to it. sbuild didn't ask for systemd-sysv
> to be installed.

this might shift the bug back to glibc postinst, no? Currently, it just checks
the exit of ischroot before calling telinit. But maybe it should be doing some
more involved checks about what PID 1 is? It could then make sure to only call
systemd telinit if systemd is pid 1. And sysvinit telinit if sysvinit is pid 1
and not call telinit at all in unknown cases. Is it too much to ask for glibc
postinst to know about the PID 1 providers?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1071488: udisks2: Syslog filled with "Error probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sdx': Unexpected sense data returned:"

[Scott Ward]

Package: udisks2
Version: 2.9.4-4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * 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?

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.1.0-21-amd64 (SMP w/2 CPU threads; PREEMPT)
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 udisks2 depends on:
ii  dbus   1.14.10-1~deb12u1
ii  libacl12.3.1-3
ii  libatasmart4   0.19-5
ii  libblockdev-fs22.28-2
ii  libblockdev-loop2  2.28-2
ii  libblockdev-part2  2.28-2
ii  libblockdev-swap2  2.28-2
ii  libblockdev-utils2 2.28-2
ii  libblockdev2   2.28-2
ii  libc6  2.36-9+deb12u7
ii  libglib2.0-0   2.74.6-2+deb12u2
ii  libgudev-1.0-0 237-2
ii  libmount1  2.38.1-5+deb12u1
ii  libpolkit-agent-1-0122-3
ii  libpolkit-gobject-1-0  122-3
ii  libsystemd0252.22-1~deb12u1
ii  libudisks2-0   2.9.4-4
ii  libuuid1   2.38.1-5+deb12u1
ii  parted 3.5-3
ii  udev   252.22-1~deb12u1

Versions of packages udisks2 recommends:
ii  dosfstools   4.2-1
ii  e2fsprogs1.47.0-2
ii  eject2.38.1-5+deb12u1
ii  exfatprogs   1.2.0-1+deb12u1
ii  libblockdev-crypto2  2.28-2
ii  libpam-systemd   252.22-1~deb12u1
ii  ntfs-3g  1:2022.10.3-1+b1
ii  polkitd  122-3

Versions of packages udisks2 suggests:
pn  btrfs-progs  
pn  f2fs-tools   
pn  libblockdev-mdraid2  
ii  mdadm4.2-5
ii  nilfs-tools  2.2.9-1
pn  reiserfsprogs
pn  udftools 
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-zram 
pn  xfsprogs 

-- no debconf information

This started happening after I upgraded from Debian 11 to Debian 12.  This copy 
of Debian is running as a VM under VMWare ESXi and I have a number of USB hard 
drives connected to it.   This message is coming from two of them, one a 
Western Digital and one an older Buffalo.  
I've seen this bug reported in other venues (i.e. other distributions) but it 
never seems to get fixed, although in one report it looks like a maintainer 
said they were simply going
to supress the message, which would be good.  The message appears at about 6 
minute intervals and is several individual lines which makes filtering it out 
with grep difficult. 
Here is an example of the message:

May 20 01:00:50 lhNAS udisksd[65284]: Error probing device: Error sending ATA 
command IDENTIFY DEVICE to '/dev/sdm': Unexpected sense data returned:
  : f0 00 01 00  50 00 01 0a  80 00 00 
00  00 1d 00 00P...
  0010: 00 00 00 00  00 00 00 00  00 00 00 
00  00 00 00 00
   (g-io-error-quark, 0)

Reports in other venues say the issue is most common with Western Digital 
drives.   I've tried changing the loglevel in /etc/udisks2/udisks2.conf but 
that doesn't stop the 
messages even when set to the "Alert" level.   
 
Functionality isn't affected, but if you have a number of hard drives causing 
this message to be put out every 6 minutes it gets very difficult to find 
anything else in the log,
especially since you have to use multiple filters to get rid of them all.   
This message should be eliminated or set to notice level and the loglevel 
directive in the
config file then needs to be fixed to actaully affect messages going into the 
syslog.  

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Helmut Grohne]

Hi Chris,

On Mon, May 20, 2024 at 01:02:32AM +0200, Chris Hofstaedtler wrote:
> "..., when using telinit from systemd-sysv"
> 
> It would seem like a reasonable assumption that systemd-sysv's
> telinit uses systemd-specific stuff, like SIGTERM.

That also is an interesting angle to it. sbuild didn't ask for
systemd-sysv to be installed. It was installed due to Build-Depends of
some package. A different package might depend on sysvinit-core where
telinit writes to /run/initctl. Other telinit may do different things.
Handling all of telinit internals in one pid1 does not seem reasonable
to me, so the consequence of this would be that you shouldn't install
telinit in a build chroot and we could file bugs about any package doing
so. A particular consequence of this would be that you couldn't use
libpam-systemd or dbus-user-session in transitive Build-Depends. We'd
render a significant number of packages bd-uninstallable.

On the other hand, you have exactly the same problems when switching
your pid1 implementation (where we urgently advise rebooting to avoid
these kind of problems). That said, a sysvinit-core telinit likely
wouldn't break a container's tini/dumb-init nor break a systemd running
as pid1.

Helmut

Bug#1071487: gacutil.1: some remarks and editorial changes for this man page

[Bjarni Ingi Gislason]

Package: mono-gac
Version: 6.8.0.105+dfsg-3.6
Severity: minor
Tags: patch

Dear Maintainer,

  here are some notes and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint gacutil.1": (possibly shortened list)

mandoc: gacutil.1:1:2: ERROR: skipping end of block that is not open: ..
mandoc: gacutil.1:1:5: STYLE: whitespace at end of input line
mandoc: gacutil.1:11:2: WARNING: missing date, using "": TH
mandoc: gacutil.1:15:2: WARNING: skipping paragraph macro: PP after SH
mandoc: gacutil.1:16:40: STYLE: whitespace at end of input line
mandoc: gacutil.1:32:2: WARNING: skipping paragraph macro: PP empty
mandoc: gacutil.1:44:74: STYLE: whitespace at end of input line
mandoc: gacutil.1:47:71: STYLE: whitespace at end of input line
mandoc: gacutil.1:57:2: STYLE: fill mode already enabled, skipping: fi

-.-.

chk_man: Next line: execute doclifter -w -v gacutil.1
gacutil.1 uses man macros...
gacutil.1:1: error - uninterpreted '.\"' command
"gacutil.1": warning - portability warning: nonportable requests 'end, .\"' 
seen.

"gacutil.1", line 120: there were 1 errors during translation

-.-.

Remove space characters at the end of lines.

Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

1:..\" 
16:.B gacutil [-user] [command] [options] 
44:The -root option is used to specify the "libdir" value of an installation 
47:To access assemblies installed to a prefix other than the mono prefix, 

-.-.

Mark a full stop (.) and the exclamation mark (!) with "\&",
if it does not mean an end of a sentence.
This is a preventive action,
the paragraph could be reshaped, e.g., after changes.

When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.

This marking is robust, and independent of the position on the line.

It corresponds to "\ " in TeX, and to "@:" in Texinfo.


36: Installs an assembly into the global assembly cache. 

-.-.

Remove space in the first column, if not indented.
Use ".in +n" and ".in" to end it; ".nf" and ".fi" to end
it, for an extra indention.

gacutil.1:36: Installs an assembly into the global assembly cache. 


-.-.

Change a HYPHEN-MINUS (code 0x2D) to a minus(-dash) (\-),
if it
is in front of a name for an option,
is a symbol for standard input,
is a single character used to indicate an option,
or is in the NAME section (man-pages(7)).
N.B. - (0x2D), processed as a UTF-8 file, is changed to a hyphen
(0x2010, u[2010]) in the output.

16:.B gacutil [-user] [command] [options] 
34:.I -i  [-check_refs] [-package NAME] [-root ROOTDIR] [-gacdir 
GACDIR]
39:The -package option can be used to also create a directory in in
44:The -root option is used to specify the "libdir" value of an installation 
46:Typical automake usage is "-root $(DESTDIR)$(prefix)/lib".
50:The -gacdir option is included for backward compatibility but is not
51:recommended for new code. Use the -root option instead.
53:The -check_refs option is used to ensure that the assembly being
59:.I "-l" [assembly_name] [-root ROOTDIR] [-gacdir GACDIR]
65:.I "-u"  [-package NAME] [-root ROOTDIR] [-gacdir 
GACDIR]
84:.I "-us"  [-package NAME] [-root ROOTDIR] [-gacdir GACDIR]
88:the GAC with a matching name, it is removed. Unlike the -u option this
91:Example: -us myDll.dll
94:.I "-ul"  [-package NAME] [-root ROOTDIR] [-gacdir 
GACDIR]
99:Example -ul assembly_list.txt

-.-.

Find a repeated word

! 39 --> in

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

22:Notice that they are not directly available 

Bug#1071486: ITP: aiohappyeyeballs -- Happy Eyeballs connection helper for asyncio

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: aiohappyeyeballs
  Version : 2.3.2
  Upstream Author : J. Nick Koston 
* URL : https://github.com/aio-libs/aiohappyeyeballs
* License : PSF-2.0
  Programming Lang: Python
  Description : Happy Eyeballs connection helper for asyncio

  Implements the Happy Eyeballs algorithm for asyncio, facilitating rapid
  connection establishment by attempting both IPv4 and IPv6 connections
  simultaneously. This approach ensures that the connection is established
  quickly and efficiently, even if one protocol is slower or unavailable.
  .
  Happy Eyeballs, also known as Fast Fallback, addresses the problem of
  connectivity issues in dual-stack applications (supporting both IPv4 and
  IPv6). By attempting both protocols in parallel and preferring IPv6, it
  minimizes delays caused by IPv6 brokenness and enhances user experience
  by promptly selecting the most responsive connection.
  .
  This library is particularly useful when using DNS caching or resolving
  names through methods other than traditional DNS, such as zeroconf. It
  allows for creating connections using pre-resolved addrinfo, bypassing
  the limitations of the standard `loop.create_connection()` method which
  requires unresolved names.

I plan to maintain this package as part of the Python team.

Bug#1071485: ITP: chacha20poly1305-reuseable -- Reusable ChaCha20Poly1305 for asyncio

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: chacha20poly1305-reuseable
  Version : 0.12.1
  Upstream Author : J. Nick Koston 
* URL : https://github.com/bdraco/chacha20poly1305-reuseable
* License : Apache-2.0
  Programming Lang: Python
  Description : Reusable ChaCha20Poly1305 for asyncio

  Provides a reusable implementation of the ChaCha20Poly1305 encryption
  algorithm for asyncio.
  .
  This allows for efficient encryption and decryption operations within
  asynchronous Python applications.
  .
  Example usage:
  .
   >>> from chacha20poly1305_reuseable import ChaCha20Poly1305Reusable
   >>> key = ChaCha20Poly1305Reusable.generate_key()
   >>> chacha = ChaCha20Poly1305Reusable(key)
   >>> nonce = b"0" * 12
   >>> ciphertext = chacha.encrypt(nonce, b"some_data", b"")
   >>> plaintext = chacha.decrypt(nonce, ciphertext, b"")

I plan to maintain this package as part of the Python team.

Bug#1071484: libksysguard: please add support for loong64

[liuxiang]

Source: libksysguard
Severity: normal
X-Debbugs-Cc: liuxi...@loongson.cn

Dear Maintainer,

   please add support for loong64,
   thank you

liuxiang

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -ruN libksysguard-5.27.11-orig/debian/control 
libksysguard-5.27.11/debian/control
--- libksysguard-5.27.11-orig/debian/control2024-05-19 16:53:41.0 
+0800
+++ libksysguard-5.27.11/debian/control 2024-05-20 11:38:28.831090335 +0800
@@ -38,7 +38,7 @@
qtbase5-dev (>= 5.15.2~),
qtdeclarative5-dev (>= 5.15.2~),
qttools5-dev,
-   qtwebengine5-dev (>= 5.15.2~) [amd64 arm64 armhf i386],
+   qtwebengine5-dev (>= 5.15.2~) [amd64 arm64 armhf i386 loong64],
zlib1g-dev,
 Standards-Version: 4.7.0
 Homepage: https://invent.kde.org/plasma/libksysguard

Bug#1071483: deb-systemd-helper.1p: some remarks for editorial changes for this man page

[Bjarni Ingi Gislason]

Package: init-system-helpers
Version: 1.66
Severity: minor

Dear Maintainer,

  here are some notes about fixes for the manual.

  The man page is created be Man::Pod.  The source file and the processing
command may need to be fixed.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint deb-systemd-helper.1p": (possibly shortened list)

mandoc: deb-systemd-helper.1p:89:82: STYLE: input text line longer than 80 
bytes: The \*(L"enable\*(R"...
mandoc: deb-systemd-helper.1p:90:86: STYLE: input text line longer than 80 
bytes: package). On the fir...
mandoc: deb-systemd-helper.1p:93:85: STYLE: input text line longer than 80 
bytes: The \*(L"mask\*(R" a...
mandoc: deb-systemd-helper.1p:96:87: STYLE: input text line longer than 80 
bytes: The \*(L"was-enabled...
mandoc: deb-systemd-helper.1p:100:87: STYLE: input text line longer than 80 
bytes: The \*(L"debian-inst...
mandoc: deb-systemd-helper.1p:109:86: STYLE: input text line longer than 80 
bytes: systemd unit files. ...

-.-.

Mark a full stop (.) and the exclamation mark (!) with "\&",
if it does not mean an end of a sentence.
This is a preventive action,
the paragraph could be reshaped, e.g., after changes.

When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.

This marking is robust, and independent of the position on the line.

It corresponds to "\ " in TeX, and to "@:" in Texinfo.


104:\&\fBdeb-systemd-helper\fR's state file, removing obsolete entries (e.g. 
service

-.-.

Add a comma (or \&) after "e.g." and "i.e.", or use English words
(man-pages(7).
Abbreviation points should be protected against being interpreted as
an end of sentence, if they are not, and that independent of the
current place on the line.

104:\&\fBdeb-systemd-helper\fR's state file, removing obsolete entries (e.g. 
service
105:files that are no longer shipped by the package) and adding new entries 
(e.g.

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

90:package). On the first \*(L"enable\*(R", a state file is created which will 
be deleted
98:updated service file. See http://bugs.debian.org/717603 for details.
100:The \*(L"debian-installed\*(R" action is also not present in systemctl. It 
returns 0 if
103:The \*(L"update-state\*(R" action is also not present in systemctl. It 
updates
104:\&\fBdeb-systemd-helper\fR's state file, removing obsolete entries (e.g. 
service
109:systemd unit files. It is specifically \s-1NOT\s0 intended to be used 
interactively by
110:users. Instead, users should run systemd and use systemctl, or not bother 
about
117:messages to stderr (thus visible in dpkg runs). Please include these when

-.-.

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.

deb-systemd-helper.1p: line 83 length 161
\&\fBdeb-systemd-helper\fR enable | disable | purge | mask | unmask | 
is-enabled | was-enabled | debian-installed | update-state | reenable \fIunit 
file\fR ...

deb-systemd-helper.1p: line 86 length 81
\&\fBdeb-systemd-helper\fR is a Debian-specific helper script which 
re-implements

deb-systemd-helper.1p: line 89 length 82
The \*(L"enable\*(R" action will only be performed once (when first installing 
the

deb-systemd-helper.1p: line 90 length 86
package). On the first \*(L"enable\*(R", a state file is created which will be 
deleted

deb-systemd-helper.1p: line 93 length 85
The \*(L"mask\*(R" action will keep state on whether the service was 
enabled/disabled

deb-systemd-helper.1p: line 96 length 87
The \*(L"was-enabled\*(R" action 

Bug#682434: git: t9010-svn-fe.sh fails with Interrupted system call

[Jonathan Nieder]

Herbert Xu wrote:

> This was fixed by:
>
> commit 282bdbd228a5e6f86ca7eec488d852d3dd3f2957
> Author: Herbert Xu 
> Date:   Thu May 28 21:31:45 2020 +1000
>
> redir: Retry open64 on EINTR

Thanks for following through!  Much appreciated.

Sincerely,
Jonathan

Bug#1071479: git package is uninstallable on x32

[Jonathan Nieder]

Hi,

Jan Engelhardt wrote:

> root@f3:/tmp# apt-get install git
[...]
>  git : Depends: git-man (< 1:2.42.0-.) but 1:2.43.0-1 is to be installed

This means the latest version hasn't built on x32 in the last several
months.  https://buildd.debian.org/status/package.php?p=git says the
build deps are not installable; do you know why?

[...]
> Since I really don't care about manual pages for chroots,
> can we perhaps drop the git -> git-man hard requirement?

git-man is required for "git help" to work, so it is a real
dependency.  If it helps in porting, then it could make sense to
specifically drop the dependency to Recommends on that arch, but like
mentioned above, my preference would be to get the port in a state
that allows building again instead.

Thanks and hope that helps,
Jonathan

Bug#1071482: compress.1: some remarks and editorial changes for this man page

[Bjarni Ingi Gislason]

Package: ncompress
Version: 5.0-1
Severity: minor
Tags: patch

Dear Maintainer,

  here are some notes and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint compress.1": (possibly shortened list)

mandoc: compress.1:46:2: WARNING: skipping paragraph macro: PP after SH
mandoc: compress.1:86:17: STYLE: whitespace at end of input line
mandoc: compress.1:105:19: STYLE: whitespace at end of input line
mandoc: compress.1:108:22: STYLE: whitespace at end of input line
mandoc: compress.1:153:10: STYLE: whitespace at end of input line
mandoc: compress.1:158:47: STYLE: whitespace at end of input line
mandoc: compress.1:205:16: STYLE: whitespace at end of input line
mandoc: compress.1:207:22: STYLE: whitespace at end of input line
mandoc: compress.1:213:5: STYLE: whitespace at end of input line
mandoc: compress.1:243:13: STYLE: whitespace at end of input line
mandoc: compress.1:257:7: STYLE: whitespace at end of input line
mandoc: compress.1:273:9: WARNING: undefined escape, printing literally: \1
mandoc: compress.1:274:55: STYLE: whitespace at end of input line

-.-.

Change '-' (\-) to '\(en' (en-dash) for a numeric range.

compress.1:125:vol. 17, no. 6 (June 1984), pp. 8\-19.
compress.1:166:is reduced by 50\-60%.

-.-.

Change (or include a "FIXME" paragraph about) misused SI (metric)
numeric prefixes (or names) to the binary ones, like Ki (kibi), Mi
(mebi), Gi (gibi), or Ti (tebi), if indicated.
If the metric prefixes are correct, add the definitions or an
explanation to avoid misunderstanding.

275:a small process data space (64KB or less, as exhibited by the DEC PDP

-.-.

Mark a full stop (.) and the exclamation mark (!) with "\&",
if it does not mean an end of a sentence.
This is a preventive action,
the paragraph could be reshaped, e.g., after changes.

When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.

This marking is robust, and independent of the position on the line.

It corresponds to "\ " in TeX, and to "@:" in Texinfo.


125:vol. 17, no. 6 (June 1984), pp. 8\-19.
253:(e.g. a symbolic link, socket, FIFO, device file), it is

-.-.

Add a comma (or \&) after "e.g." and "i.e.", or use English words
(man-pages(7).
Abbreviation points should be protected against being interpreted as
an end of sentence, if they are not, and that independent of the
current place on the line.

253:(e.g. a symbolic link, socket, FIFO, device file), it is

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

64:In particular, it will ignore symbolic links. If a file has multiple
107:will operate recursively. If any of the file names specified on the command
262:for more information. Use the

-.-.

Remove reverse slash (\) in front of a period (.) that is to be printed
as such, and can not come a control character in the first column of a line.
This is a sign, that the man page was transformed from another source
file with a program, whose name is NOT mentioned in a comment.

195:.BR \-b \.
217:.IR bits \.
248:.BR \-v \.)

-.-.

Use the name of units in text; use symbols in tables and
calculations.
The rule is to have a (no-break, \~) space between a number and
its units (see "www.bipm.org/en/publications/si-brochure")

275:a small process data space (64KB or less, as exhibited by the DEC PDP

-.-.

Split a punctuation from a single argument, if a two-font macro is meant

50:.I uncompress.real.
79:.I uncompress.real.
152:.I uncompress.real,

-.-.

troff::273: warning: ignoring escape character before '1'


-- System Information:
Debian Release: 

Bug#1071481: system: Info Center> Devices > Firmware Security no display

[Lindsay Keir]

Package: systemsettings
Version: 4:5.27.5-2
Severity: minor
File: system
X-Debbugs-Cc: lind...@duck.com

Dear Maintainer,


The Info Center > Devices > Firmware Security tells me fwupdmgr is not
installed.

I installed
*   aha
*   fwupd-amd64-signed
*   fwupd-amd64-signed-template
*   fwupdate
The error messages went away; but the panel just / and continued to display a
twirly thingee.

I Installed
*   gnome-firmware
which works.



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

Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemsettings depends on:
ii  kio 5.103.0-1
ii  kpackagetool5   5.103.0-1
ii  libc6   2.36-9+deb12u7
ii  libkf5activities5   5.103.0-1
ii  libkf5auth5 5.103.0-1
ii  libkf5authcore5 5.103.0-1
ii  libkf5completion5   5.103.0-1
ii  libkf5configcore5   5.103.0-2
ii  libkf5configgui55.103.0-2
ii  libkf5configwidgets55.103.0-1
ii  libkf5coreaddons5   5.103.0-1
ii  libkf5crash55.103.0-1
ii  libkf5dbusaddons5   5.103.0-1
ii  libkf5i18n5 5.103.0-1
ii  libkf5iconthemes5   5.103.0-1
ii  libkf5itemmodels5   5.103.0-1
ii  libkf5itemviews55.103.0-1
ii  libkf5kcmutils5 5.103.0-3
ii  libkf5kiocore5  5.103.0-1
ii  libkf5kiogui5   5.103.0-1
ii  libkf5kiowidgets5   5.103.0-1
ii  libkf5kirigami2-5   5.103.0-1
ii  libkf5notifications55.103.0-1
ii  libkf5package5  5.103.0-1
ii  libkf5runner5   5.103.0-1
ii  libkf5service-bin   5.103.0-1
ii  libkf5service5  5.103.0-1
ii  libkf5widgetsaddons55.103.0-1
ii  libkf5windowsystem5 5.103.0-1
ii  libkf5xmlgui5   5.103.0-1
ii  libkworkspace5-54:5.27.5-2+deb12u1
ii  libqt5core5a5.15.8+dfsg-11
ii  libqt5gui5  5.15.8+dfsg-11
ii  libqt5qml5  5.15.8+dfsg-3
ii  libqt5quick55.15.8+dfsg-3
ii  libqt5quickwidgets5 5.15.8+dfsg-3
ii  libqt5widgets5  5.15.8+dfsg-11
ii  libstdc++6  12.2.0-14
ii  qml-module-org-kde-kcm  5.103.0-1
ii  qml-module-org-kde-kcmutils 5.103.0-3
ii  qml-module-org-kde-kirigami25.103.0-1
ii  qml-module-org-kde-kitemmodels  5.103.0-1
ii  qml-module-org-kde-newstuff 5.103.0-1
ii  qml-module-qtquick-controls 5.15.8-2
ii  qml-module-qtquick-layouts  5.15.8+dfsg-3
ii  qml-module-qtquick-shapes   5.15.8+dfsg-3
ii  qml-module-qtquick2 5.15.8+dfsg-3

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information

Bug#1071372: emacs: it hangs saving .gpg files (without using cpu)

[Vincent Lefevre]

On 2024-05-20 01:03:00 +0200, Vincent Lefevre wrote:
> The issue remains after downgrading the emacs packages to testing
> (1:29.3+1-2).

And it disappears after downgrading the packages of gnupg2 source
to 2.2.40-3.

The issue about the file disappearing does not occur with "emacs -Q"
(I'll have to find the exact cause). This is a more general issue,
but this bug about emacs hanging just makes it much worse.

I'm using

(defun find-backup-file-name (fn)
   (list (concat "~/.poub/" (file-name-nondirectory fn) "~")))

and there's actually a backup there, but this should be regarded as
very temporary, as I sometimes clean up this directory. Files should
never expected to be *only* there. I suspect wrong logic in Emacs,
because with the downgraded gnupg, the file disappearance occurs
only after the first save (according to strace, Emacs does a rename
to create the backup instead of copying the file).

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

Bug#1071480: libldap: sends some IPv6 addresses as server name

[Elliott Mitchell]

Seems there were two bugs in #1070033.  The part for OpenLDAP is pretty
simple.  When detecting an IPv6 address (via ':' in the string),
the function `ldap_int_tls_connect()` triggers a `break;`, but this
requires `numeric=1` to still be in effect.  Since IPv6 addresses are
hexadecimal, this isn't always true.

Patch attached.  Given how small it is, any license acceptable to the
Debian project is acceptable to me.  I'll let the maintainer forward it
to the OpenLDAP project.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445


From: Elliott Mitchell 
Date: Sun, 19 May 2024 09:49:36 -0700
Subject: [PATCH] tls: fix handling of numeric IPv6 addresses for SNI

A colon in the SNI is a strong indicator of an IPv6 address.  Since IPv6
addresses are hexadecimal, `numeric` may already be false and falling
through to the test doesn't work.  Address this by preemptively setting
`sni` to invalid (NULL).

Fixes: b8f34888 ("ITS#9176 check for numeric addrs before passing SNI")
---
 libraries/libldap/tls2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libraries/libldap/tls2.c b/libraries/libldap/tls2.c
index f9dcbfc8d..d433e6508 100644
--- a/libraries/libldap/tls2.c
+++ b/libraries/libldap/tls2.c
@@ -399,8 +399,10 @@ ldap_int_tls_connect( LDAP *ld, LDAPConn *conn, const char *host )
 		int numeric = 1;
 		unsigned char *c;
 		for ( c = (unsigned char *)sni; *c; c++ ) {
-			if ( *c == ':' )	/* IPv6 address */
+			if ( *c == ':' ) {	/* IPv6 address */
+sni = NULL;
 break;
+			}
 			if ( *c == '.' )
 continue;
 			if ( !isdigit( *c )) {
-- 
2.39.2

Bug#1071479: git package is uninstallable on x32

[Jan Engelhardt]

Package: git
Version: 1:2.42.0-1

On Debian/x32 of the day, it is impossible to install the git package:

root@f3:/tmp# apt-get install git
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 git : Depends: git-man (< 1:2.42.0-.) but 1:2.43.0-1 is to be installed
   Recommends: ssh-client
E: Unable to correct problems, you have held broken packages.
root@f3:/tmp# apt-mark showheld
root@f3:/tmp#


-- sources.list (1 entry) --
deb https://deb.debian.org/debian-ports sid main


None of
http://ftp.gwdg.de/pub/linux/debian/debian/pool/main/g/git/
http://ftp.de.debian.org/debian-ports/pool/main/g/git/
http://ftp.de.debian.org/debian-ports/pool-x32/main/g/git/
carry git-man-2.42 anymore.

Since I really don't care about manual pages for chroots,
can we perhaps drop the git -> git-man hard requirement?

Bug#1071478: node-clean-css: failing tests, might be fixed in version 5.3.3

[Jérémy Lal]

Package: node-clean-css
Version: 5.3.2+~5.6.2-1
Severity: important

Hi,

https://ci.debian.net/packages/n/node-clean-css/testing/amd64/46859971/

seems to be
https://github.com/clean-css/clean-css/commit/0c31301
released as part of clean-css 5.3.3

Regards,
Jérémy


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

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 node-clean-css depends on:
ii  node-source-map  0.7.0++dfsg2+really.0.6.1-15

node-clean-css recommends no packages.

node-clean-css suggests no packages.

-- no debconf information

Bug#1071477: node-bunyan: fails to log 'src' when running in Node 20

[Jérémy Lal]

Source: node-bunyan
Version: 2.0.5+~cs4.4.3-3
Severity: important

https://github.com/trentm/node-bunyan/issues/714

fixed by

https://github.com/trentm/node-bunyan/pull/715

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

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

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Chris Hofstaedtler]

On Sun, May 19, 2024 at 11:12:35PM +0200, Helmut Grohne wrote:
> Hi Luca,
> 
> On Sun, May 19, 2024 at 06:04:38PM +0100, Luca Boccassi wrote:
> > On Sun, 19 May 2024 18:42:17 +0200 Helmut Grohne 
> > wrote:
> > > the init process should handle SIGTERM more like an init system would
> > handle that
> > 
> > This seems the obvious answer to me. sbuild is setting up a system such
> > that its component runs as pid1, so it needs to behave like a pid1. We
> > know this is special and requires supporting a number of interfaces. If
> > a program doesn't, then it shouldn't be running as pid1 in a namespace.
> 
> Did you mean "... so it needs to behave like a systemd"?

"..., when using telinit from systemd-sysv"

It would seem like a reasonable assumption that systemd-sysv's
telinit uses systemd-specific stuff, like SIGTERM.

Chris

Bug#1071476: neochat: Neochat will not start, due to old kirigami-addons

[Salvo "LtWorf" Tomaselli]

Package: neochat
Version: 23.08.5-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: ltw...@debian.org

Dear Maintainer,

neochat won't start.

I have uploaded kirigami-addons, and made a new upload of neochat.

This bug is so that it will not migrate.

Best

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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 neochat depends on:
ii  kio 5.115.0-5
ii  libc6   2.38-11
ii  libcmark0.30.2  0.30.2-6+b1
ii  libkf5configcore5   5.115.0-2
ii  libkf5configgui55.115.0-2
ii  libkf5configwidgets55.115.0-2
ii  libkf5coreaddons5   5.115.0-2
ii  libkf5dbusaddons5   5.115.0-2
ii  libkf5i18n5 5.115.1-2
ii  libkf5kiocore5  5.115.0-5
ii  libkf5kiogui5   5.115.0-5
ii  libkf5kiowidgets5   5.115.0-5
ii  libkf5kirigami2-5   5.115.0-2
ii  libkf5notifications55.115.0-2
ii  libkf5sonnetcore5   5.115.0-2
ii  libkf5windowsystem5 5.115.0-2
ii  libqt5core5t64  5.15.10+dfsg-7.2+b1
ii  libqt5dbus5t64  5.15.10+dfsg-7.2+b1
ii  libqt5gui5t64   5.15.10+dfsg-7.2+b1
ii  libqt5keychain1 0.14.3-1
ii  libqt5multimedia5   5.15.10-2+b2
ii  libqt5network5t64   5.15.10+dfsg-7.2+b1
ii  libqt5qml5  5.15.10+dfsg-2+b2
ii  libqt5quick55.15.10+dfsg-2+b2
ii  libqt5quickcontrols2-5  5.15.10+dfsg-2+b2
ii  libqt5sql5-sqlite   5.15.10+dfsg-7.2+b1
ii  libqt5widgets5t64   5.15.10+dfsg-7.2+b1
ii  libquotient0.8  0.8.1.2-2
ii  libstdc++6  14.1.0-1
ii  qml-module-org-kde-kirigami-addons-labs-mobileform  0.11.0-1
ii  qml-module-org-kde-kirigami25.115.0-2
ii  qml-module-org-kde-kitemmodels  5.115.0-2
ii  qml-module-org-kde-kquickimageeditor0.3.0-1+b1
ii  qml-module-org-kde-notifications5.115.0-2
ii  qml-module-org-kde-purpose  5.115.0-2
ii  qml-module-org-kde-qqc2desktopstyle 5.115.0-2
ii  qml-module-org-kde-quickcharts  5.115.0-2
ii  qml-module-org-kde-sonnet   5.115.0-2
ii  qml-module-org-kde-syntaxhighlighting   5.115.0-2
ii  qml-module-qt-labs-platform 5.15.10+dfsg-2+b2
ii  qml-module-qt-labs-qmlmodels5.15.10+dfsg-2+b2
ii  qml-module-qtlocation   5.15.10+dfsg-3+b2
ii  qml-module-qtmultimedia 5.15.10-2+b2
ii  qml-module-qtqml5.15.10+dfsg-2+b2
ii  qml-module-qtqml-models25.15.10+dfsg-2+b2
ii  qml-module-qtquick-controls25.15.10+dfsg-2+b2
ii  qml-module-qtquick-layouts  5.15.10+dfsg-2+b2
ii  qml-module-qtquick-particles2   5.15.10+dfsg-2+b2
ii  qml-module-qtquick-window2  5.15.10+dfsg-2+b2
ii  qml-module-qtquick2 5.15.10+dfsg-2+b2

neochat recommends no packages.

neochat suggests no packages.

-- no debconf information

Bug#1071372: emacs: it hangs saving .gpg files (without using cpu)

[Vincent Lefevre]

Control: found -1 1:29.3+1-2

On 2024-05-20 00:45:40 +0200, Vincent Lefevre wrote:
> On 2024-05-18 01:22:03 +0200, Alex Andreotti wrote:
> > [...] Probably a "recent" apt upgrade broke it but I don't know
> > exactly which one, before this problem I used to save .gpg files
> > often
> 
> Here, there was no such issue on May 1, where I had emacs 1:29.3+1-2.
> But gnupg2 has also been upgraded from 2.2.40-3 to 2.2.43-3, though.

The issue remains after downgrading the emacs packages to testing
(1:29.3+1-2).

Note: When Emacs hangs, the gpg process is still running. Something
of the form:

  gpg --no-tty --status-fd 1 --yes --use-agent --enable-progress-filter 
--command-fd 0 --output epg-outputsyl2kr --encrypt -r ***

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

Bug#1071372: emacs: it hangs saving .gpg files (without using cpu)

[Vincent Lefevre]

Control: severity -1 critical

due to data loss.

I have the same issue. Worse, in one of my tests, where I tried
various things before quitting Emacs (without saving the file,
because this is just not possible due to this bug), like switching
the current buffer (which had no effect), the file got removed!
However, I can't reproduce that, and I don't remember what I did
exactly. I suspect that Emacs got in an inconsistent state.

Well, after typing "C-x C-s", the file is no longer there, and
I cannot see any backup! A C-g restores it, but apparently, not
after some condition. Anyway, the fact that the file is temporarily
removed is a major issue.

On 2024-05-18 01:22:03 +0200, Alex Andreotti wrote:
> Package: emacs
> Version: 1:29.3+1-3
> Severity: normal
> X-Debbugs-Cc: alex.andreo...@gmail.com
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> For years I have normally used emacs (GUI) to create gpg files (.org.gpg or 
> .md.gpg) where I save relatively sensitive information using a key installed 
> in the system (with password). Last week when I created a file and saved it, 
> emacs asked me to mark the key to use, and when I pressed OK to save the file 
> it hung. Probably a "recent" apt upgrade broke it but I don't know exactly 
> which one, before this problem I used to save .gpg files often

Here, there was no such issue on May 1, where I had emacs 1:29.3+1-2.
But gnupg2 has also been upgraded from 2.2.40-3 to 2.2.43-3, though.

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

Bug#1071429: dpkg: `dpkg-db-backup.timer` starts `dpkg-db-backup.service` in hot path of boot

[Guillem Jover]

Hi!

On Sun, 2024-05-19 at 07:09:24 +0200, Paul Menzel wrote:
> Package: dpkg
> Version: 1.22.6
> Severity: normal

> Trying to decrease the boot time of a desktop system (pressing the power
> button to GDM login screen), I noticed `dpkg-db-backup.service` in the
> hotpath:

[…]

> It’d be great if this could be moved out the hot path, for example, by
> running it at least ten(?) minutes after the system has been started.

I'm not sure systemd provides something to implement the requested
behavior though. The closest I see is RandomizedDelaySec, but that
will not guarantee the delay. If you can suggest a specific change
then we can discuss that, otherwise, I'm afraid this might need to
be closed?

Thanks,
Guillem

Bug#1071475: ITP: rdf2rml -- visual graph modelling using RDF semantic graph notation

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rdf2rml
  Version : 0~20240410
  Upstream Contact: Vladimir Alexiev (valexiev) 
* URL : https://github.com/VladimirAlexiev/rdf2rml
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : visual graph modelling using RDF semantic graph notation

 The rdf2rml provides two command-line tools:
 .
  * rdf2rml - convert RDF example to R2RML script
  * rdfpuml - convert RDF to PlantUML diagram
 .
 rdfpuml makes true diagrams directly from Turtle examples
 using PlantUML and GraphViz.
 .
 rdf2rml generates R2RML transformations from examples,
 which saves about 15x in complexity
 and ensures compliance of the actual conversion to the model.
 Typically the example is an rdfpuml model.
 .
 Diagram readability is of prime concern.
 .
 Resource Description Framework (RDF) is a standard model
 for data interchange on the Web.

This package will be maintained in the collaborative Debian section of
salsa, at .

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZKdg4ACgkQLHwxRsGg
ASGRoxAAkM4Be1fiF/YTCdkF9EomWdprqRPFp17neSS2We/QNZNtXn8SHJfqCP0D
CHe63ZJo0dQPpVxOmsklLM02qffC5hwKTZaBj7HpBk0rW2aylb+a1ragJV6/dkkS
T4oJRKpbokEH9+toXaSbl1ghi1GRmMfcFG1IpKyZzf36V3qUS/1lMddQ1r/ZEbJm
vMgAyNVkq/pYsew/IvkAYDSiIzBAPqhAO9/ZbNZbHsWErKMtrym4QulnZwmZTdex
b09B3JbuxCJoa/sk9AM99evS+2jrwRMOpe54pAOXQtMqLIhmgfxk8UmOiLtMI6vO
W2gtHKo1lZn8Ogsms6d4xKNMfIHz3ZfBf1gOhbt/Ayn6dXH00SphztdhQQnKncKq
AcD4GQm4CMU5vb9VKdAKRXwPj2tCVrCqjaJJOEbANBqDOp9g6x9vJ1mxvTnIFx0V
XAChweqiaB1xTMk+lSFamcZDtVpeaJAImWy17ikDZtBvrrRCl0FVRn/2TqSFYHYz
6EWvMxfph9As2Jzr4XR4lXOi0DH67ToktexQrDsbopVPppqgkxcJ+FHvBskOMQXp
PMc5Yo3gDMFxupDwXULaaF4XO0wq2sLZp8xzY8cgK6H+yTuwIlyXD+DBsvz2AAHF
RxrI8035RdVfi9puCXHVuy1+9vEvSHeoLTTW/Cb2+FcRW+O1Yl4=
=pXRE
-END PGP SIGNATURE-

Bug#1071452: Revised PR for dnsdbq posted to github

[David Waitzman]

--
David Waitzman
Principal Distributed Systems Engineering
d...@domaintools.com

Bug#1071474: roundcube: xx

[Guilhem Moulin]

Source: roundcube
Version: 1.6.6+dfsg-2
Severity: important
Control: found -1 1.6.5+dfsg-1~deb12u1
Control: found -1 1.4.15+dfsg.1-1~deb11u2
Control: found -1 1.3.17+dfsg.1-1~deb10u5
Tags: security upstream

Roundcube webmail upstream has recently released 1.6.7 [0] which fixes
the following vulnerabilities:

 *  Fix command injection via crafted im_convert_path/im_identify_path
on Windows.

https://github.com/roundcube/roundcubemail/commit/7da322371fd00a54670a5d6679faae0fcbd3f229
 *  Fix cross-site scripting (XSS) vulnerability in handling list
columns from user preferences.

https://github.com/roundcube/roundcubemail/commit/9ca8aa6680c579132e0d1fa59447df8d524ec91c
 *  Fix cross-site scripting (XSS) vulnerability in handling SVG animate
attributes.

https://github.com/roundcube/roundcubemail/commit/ba252dc5e2946506cb8d0b50b2b7bf95ab51876f

AFAICT no CVE-ID has been published for these issues, I'll request them.

-- 
Guilhem.

[0] https://roundcube.net/news/2024/05/19/security-updates-1.6.7-and-1.5.7


signature.asc
Description: PGP signature

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Helmut Grohne]

Hi Luca,

On Sun, May 19, 2024 at 06:04:38PM +0100, Luca Boccassi wrote:
> On Sun, 19 May 2024 18:42:17 +0200 Helmut Grohne 
> wrote:
> > the init process should handle SIGTERM more like an init system would
> handle that
> 
> This seems the obvious answer to me. sbuild is setting up a system such
> that its component runs as pid1, so it needs to behave like a pid1. We
> know this is special and requires supporting a number of interfaces. If
> a program doesn't, then it shouldn't be running as pid1 in a namespace.

Die you mean "... so it needs to behave like a systemd"?

sysvinit does not document SIGTERM as a supported signal.
https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html
Neither does runit.
https://manpages.debian.org/bookworm/runit/runit.8.en.html#SIGNALS
Nor did upstart.
https://sources.debian.org/src/upstart/0.6.6-1/init/main.c/#L249
Or dumb-init (forwards all signals to its children).
Or tini (forwards all signals to its children).
https://github.com/krallin/tini/blob/master/src/tini.c#L525
Or busybox (see busybox init --help).
But openrc-init and it then performs a shutdown.
https://sources.debian.org/src/openrc/0.54-2/src/openrc-init/openrc-init.c/#L210

As far as my research goes, this handling of SIGTERM is specific to
systemd and not a generic assumption of pid1.

Helmut

Bug#1071473: transition: opencascade

[Tobias Frost]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: opencasc...@packages.debian.org
Control: affects -1 + src:opencascade
User: release.debian@packages.debian.org
Usertags: transition
Control: block 1071284 by -1
Control: block 1071223 by -1
Control: block 1071470 by -1
Control: block 1071451 by -1
Control: block 1071471 by -1

Hi Release team,

opencascade has a new release with breaking ABI, upstream versionied them as
7.8. The transition tracker [1] correctly picked it up already after the upload
to experimental.

[1] https://release.debian.org/transitions/html/auto-opencascade.html

building the reverse depenencies most FTBFS due to library naming changes,
but I was able to come up with patches for most, but they will require sourceful
uploads. Freecad will require either backporting the upstream fixes or package
a new upstream snapshot.

This is the result of the compilation tests:

Dependency level 2:

f3d ✔
freecad (sid only)  FTBFS, fixed in upstream git.
horizon-eda patch available, #1071284
kicad   ✔
netgen  patch available, #1071223
slic3r-prusa (sid only) patch available, #1071470

Dependency level 3:
gmshpatch available, #1071451

Dependency level 4:
deal.ii patch available, #1071471

-- 
Cheers,
tobi


signature.asc
Description: PGP signature

Bug#953896: psensor: new upstream version 1.2.1

[Ricardo Mones]

Hi Xiao,

On Fri, 17 May 2024 10:31:31 +0800
xiao sheng wen(肖盛文)  wrote:

> Control:|retitle -1 new upstream version 1.2.1
> 
> |Hi,
> 
>      The psensor new upstream version 1.2.1 release on 2020-29-06:
> 
> https://gitlab.com/jeanfi/psensor/-/raw/v1.2.1/NEWS
> 
> To jeanfi:
> 
>     Do you still interested on Debian packaging of psensor?
>   If you has no time, we can help to do NMU.

Jean-Philippe has not uploaded psensor since 2016 and it's the only package
he was maintaining. I may be wrong, but at this point I doubt he's interested
in packaging the new version.

With my MIA hat on, if there's no news from him in a week or so, and you're
still interested, feel free to adopt the package yourself.

best regards,
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «You will be attacked by a beast who has the body of a wolf, the tail 
 of a lion, and the face of Donald Duck.»


pgpIsOs3tqfRj.pgp
Description: OpenPGP digital signature

Bug#1071431: [Pkg-openssl-devel] Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))

[Sebastian Andrzej Siewior]

On 2024-05-19 16:18:59 [+0200], Jean-Guilhem Cailton wrote:
> I should have added that the "apt full-upgrade" run that left the system
> with a broken sudo was interrupted by an error, also due to the missing
> libcrypto.so.3, and ended with:
> 
> "
> Préparation du dépaquetage de .../5-postgresql-16_16.3-1_amd64.deb ...
> systemctl: error while loading shared libraries: libcrypto.so.3: cannot open
> shared object file: No such file or directory
> dpkg: avertissement: le sous-processus ancien paquet postgresql-16 script
> pre-removal a renvoyé un état de sortie d'erreur 127
> dpkg: tentative d'exécution du script du nouveau paquet à la place...
> systemctl: error while loading shared libraries: libcrypto.so.3: cannot open
> shared object file: No such file or directory
> dpkg: erreur de traitement de l'archive
> /tmp/apt-dpkg-install-klPmRf/5-postgresql-16_16.3-1_amd64.deb (--unpack) :
>  le sous-processus nouveau postgresql-16 paquet pre-removal script a renvoyé
> un état de sortie d'erreur 127
> Des erreurs ont été rencontrées pendant l'exécution :
>  /tmp/apt-dpkg-install-klPmRf/5-postgresql-16_16.3-1_amd64.deb
> Erreur : Le délai d’attente est dépassé
> needrestart is being skipped since dpkg has failed
> E: Sub-process /usr/bin/dpkg returned an error code (1)

You seem to have packages installed which are not in Debian anymore.
From a quick glance that is
- postgresql-14
- postgresql-15

The problem is basically that those packages require libssl3 while
everything else in-system depends on libssl3t64 and this conflicts with
libssl3. Both provide the same .so library file.

Can you try if this update is doable having only packages available in
Debian? The command "apt list ?obsolete" lists package which are no
longer in the archive. Please ensure that you have no packages from
third-party repo installed.

Sebastian

Bug#1071472: nvidia-cudnn: curl has no option called --no-check-certificate

[Santiago Vila]

Package: nvidia-cudnn
Version: 8.9.2.26~cuda12+3
Tags: patch

Dear maintainer:

While building packages in the near future, for QA purposes, I noticed
that package "pytorch-cuda" failed to build with this error message:

-
Setting up nvidia-cudnn (8.9.2.26~cuda12+3) ...
[...]
curl: option --no-check-certificate: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
-

I believe this bug was introduced in commit [866f3c5] of nvidia-cudnn,
when support for curl was added.

The attached patch (untested) might help.

[ Note: Building in the future for QA purposes is still desired,
please do not remove this option... ]

Thanks.--- a/update-nvidia-cudnn
+++ b/update-nvidia-cudnn
@@ -151,8 +151,10 @@ download_cudnn () {
 # detect downloader and download
 if (command -v curl > /dev/null); then
 local cmd="curl --continue-at - -L ${URL} --output ${dest}"
+local nocheck="--insecure"
 elif (command -v wget > /dev/null); then
 local cmd="wget --continue --verbose --show-progress=off -c ${URL} -O 
${dest}"
+local nocheck="--no-check-certificate"
 else
 echo "$0: Error: no downloader available."
 exit 255
@@ -160,7 +162,7 @@ download_cudnn () {
 # already exists?
 if ! test -f ${dest}; then
 echo ${cmd} >&2
-bash -c "${cmd}" || bash -c "${cmd} --no-check-certificate" >&2
+bash -c "${cmd}" || bash -c "${cmd} ${nocheck}" >&2
 else
 echo Skipping download as file already exists: ${dest} >&2
 fi

Bug#1071469: Acknowledgement (tracker.debian.org: out of sync with the archive (breakage in debian.org mail infrastructure))

[Louis-Philippe Véronneau]

severity 1071469 normal
thanks

I dug a little bit more and it seems the outage happened between 
2024-05-17 ~2200 and and 2024-05-18 0110UTC.


The only packages that have been uploaded during that time period and 
that seem to be affected are:


* sccache 0.8.0-2
* whipper 0.10.0-3
* slepc 3.20.2+dfsg1-1

Since it's a pretty small number of packages, I'm downgrading the 
severity :)


--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1071471: src:deal.ii: FTBFS with opencascade 7.8

[Tobias Frost]

Source: deal.ii
Severity: important
Tags: patch ftbfs

Dear maintainer,

deal.ii FBTFS with opencascade 7.8, which renames a few libraries.

Attached patch fixes the FTBFS, unfortunatly it is not backward compatible
and it should only be applied after the transistion has been started.

-- 
tobi


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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- a/cmake/modules/FindDEAL_II_OPENCASCADE.cmake
+++ b/cmake/modules/FindDEAL_II_OPENCASCADE.cmake
@@ -69,8 +69,8 @@
 # These seem to be pretty much the only required ones.
 set(_opencascade_libraries
   TKBO TKBool TKBRep TKernel TKFeat TKFillet TKG2d TKG3d TKGeomAlgo
-  TKGeomBase TKHLR TKIGES TKMath TKMesh TKOffset TKPrim TKShHealing TKSTEP
-  TKSTEPAttr TKSTEPBase TKSTEP209 TKSTL TKTopAlgo TKXSBase
+  TKGeomBase TKHLR TKDEIGES TKMath TKMesh TKOffset TKPrim TKShHealing TKDESTEP
+  TKDESTL TKTopAlgo TKXSBase
   )
 
 set(_libraries "")

Bug#1071470: src:slic3r-prusa: FTBFS with opencasacade 7.8.1

[Tobias Frost]

Source: slic3r-prusa
Severity: important
Tags: patch ftbfs

Dear maintainer,

the new opencascade version 7.8.1 changes some library names, making 
slic3r-prusa fail. The attached patch fixes the compilation issue. (Source is 
gentoo, 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5a345e202892c9358921d7a70cd54624bf17e42c)

-- 
tobi

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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/src/occt_wrapper/CMakeLists.txt b/src/occt_wrapper/CMakeLists.txt
index d8dd8e1..d27055f 100644
--- a/src/occt_wrapper/CMakeLists.txt
+++ b/src/occt_wrapper/CMakeLists.txt
@@ -22,11 +22,8 @@ generate_export_header(OCCTWrapper)
 find_package(OpenCASCADE REQUIRED)
 
 set(OCCT_LIBS
-TKXDESTEP
-TKSTEP
-TKSTEP209
-TKSTEPAttr
-TKSTEPBase
+TKDESTEP
+TKDESTL
 TKXCAF
 TKXSBase
 TKVCAF

Bug#1071465: xmlrpc-c: update package name for a SONAME bump

[Alexandre Detiste]

Ho sorry indeed.

A binNMU should be enough to fix rtorrent.

Its used by other packages, please see #1070965 as an example.
>

Bug#1071469: tracker.debian.org: out of sync with the archive (breakage in debian.org mail infrastructure)

[Louis-Philippe Véronneau]

Package: tracker.debian.org
Severity: important

Hi,

It seems that a debian.org mail infrastructure breakage happened 
sometime between 2024-05-17 and 2024-05-18:


---
adsb>	there was some d.o mail breakage for a couple of hours overnight 
friday/saturday, possible it got caught up in that


adsb>turns out that losing your TLSA records doesn't go so well

adsb>	I'm not sure how easy resurrecting any of that information is, or 
where from

---

This means a bunch of emails like `source.changes ACCEPTED into 
unstable` ones weren't sent. I'm guessing tracker.debian.org relies on 
those email in some way, since the uploads made during this time period 
aren't currently shown on the interface.


An example is the 0.10.0-3 whipper upload I made to unstable [1]. The 
upload did go through, I never got any mail back and tracker.debian.org 
doesn't list the upload [2].


I don't know how many packages were affected by this, but having 
tracker.debian.org out of sync with the actual state of the archive 
isn't great, as people rely on it :)


Cheers,

[1]: 
https://metadata.ftp-master.debian.org/changelogs//main/w/whipper/whipper_0.10.0-3_changelog

[2]: https://tracker.debian.org/pkg/whipper

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1071468: linux-image-amd64: mess left when kernel installation fails (grub treats the uninstalled kernel as existing)

[Manny]

Package: linux-image-amd64
Version: 6.6.13-1~bpo12+1
Severity: normal
X-Debbugs-Cc: debbug.linux-am...@sideload.33mail.com

A kernel installation failed due to a corrupt deb file that could not
be unpacked. That was reported here:

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

Apparently whatever generic installation mechanism is used, it fails
to properly treat a botched delivery. That is, even though the deb
file for kernel version 6.6.13-1~bpo12+1 is only 1480 bytes and so
corrupt it cannot even be unpacked, the package was erroneously
flagged as installed, at least in part:

===8<
  $ dpkg -l | grep 6.6.13-1~bpo12+1
  iU  linux-headers-6.6.13+bpo-amd64   6.6.13-1~bpo12+1 amd64 Header files for 
Linux 6.6.13+bpo-amd64
  ii  linux-headers-6.6.13+bpo-common  6.6.13-1~bpo12+1 all   Common header 
files for Linux 6.6.13+bpo
  iU  linux-headers-amd64  6.6.13-1~bpo12+1 amd64 Header files for 
Linux amd64 configuration (meta-package)
  iF  linux-image-6.6.13+bpo-amd64 6.6.13-1~bpo12+1 amd64 Linux 6.6 for 
64-bit PCs (signed)
  iU  linux-image-amd646.6.13-1~bpo12+1 amd64 Linux for 64-bit 
PCs (meta-package)
  ii  linux-kbuild-6.6.13+bpo  6.6.13-1~bpo12+1 amd64 Kbuild 
infrastructure for Linux 6.6.13+bpo
  ii  linux-libc-dev   6.6.13-1~bpo12+1 all   Linux support 
headers for userspace development
===8<

Perhaps “iU” and “iF” are correct flags in the first column (it’s
unclear because “man dpkg” does not document these). But grub
alterations were carried out despite the failure and the default
kernel became the version that could not even be unpacked from the deb
file (6.6.13-1~bpo12+1). So it’s not just a failure of that kernel but
also a failure in the installation logic, perhaps in apt. Though I
doubt apt would influence grub, so I’m filing this in the virtual pkg
linux-image-amd64 for lack of a better place.

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

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

Versions of packages linux-image-amd64 depends on:
ih  linux-image-6.6.13+bpo-amd64  6.6.13-1~bpo12+1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#1071447: iproute2: IPv6 route in VRF context fails with 'Invalid source address' due to default VRF check.

[Luca Boccassi]

Control: tags -1 upstream

On Sun, 19 May 2024 15:39:05 +0200 Tharyrok  wrote:
> Package: iproute2
> X-Debbugs-Cc: d...@tharyrok.eu
> Version: 6.9.0-1
> Severity: normal
> Tags: ipv6
> 
> Dear Maintainer,
> 
> I am encountering an issue when adding an IPv6 route within a VRF 
> context on Debian using ifupdown2. The problem occurs when I attempt
to 
> add an unreachable default route with a specific source address. I 
> receive an "Invalid source address" error. However, this issue does
not 
> occur with IPv4 routes under similar conditions.

Please report this upstream, there are no patches in Debian so the
behaviour is just what upstream provides.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071430: dkms modules compile twice when installing new linux-image and linux-headers packages

[Bastian Blank]

Control: tags -1 wontfix

On Sun, May 19, 2024 at 03:09:03PM +1000, Craig Sanders wrote:
> When installing a new kernel (images & headers) packages, dkms modules for
> that kernel version are compiled twice - once for the linux image package, and
> again (almost immediately afterwards) for the linux headers package.

I don't think we can do anything about this right now.  But less so in
the linux package.

Tagging wontfix for now, as this requires some serious restructuring.
The same problem also applies to initramfs building.

Bastian

-- 
Women are more easily and more deeply terrified ... generating more
sheer horror than the male of the species.
-- Spock, "Wolf in the Fold", stardate 3615.4

Bug#1071467: linux-image-6.6.13+bpo-amd64: installation botched, tiny and corrupt deb file

[Bastian Blank]

Control: tags -1 moreinfo
Control: severity -1 normal

On Sun, May 19, 2024 at 08:58:57PM +0200, Manny wrote:
> To install linux-image-6.6.13+bpo-amd64, this command was executed:
> 
>   $ apt -t bookworm-backports install linux-image-amd64
> 
> I have a transcript of the session but it’s probably not worth
> posting. It’s in the binary format produced by the “script”
> command. The deb file is only 1,480 bytes, which is obviously a
> non-starter. The final output was this:
> 
>   Download is performed unsandboxed as root as file 
> '/root/linux-image-amd64_6.6.13-1~bpo12+1_amd64.deb' couldn't be accessed by 
> user '_apt'. - pkgAcquire::Run (13: Permission denied)

What do you want to say?  This message is from apt and is pretty clearly
a missconfiguration, why does it try to find a package from the Debian
archive in your home?

The size of this deb should be correct, this is a meta-package, aka it
only depends on other packages.

I don't see any problem description here.

Bastian

-- 
The joys of love made her human and the agonies of love destroyed her.
-- Spock, "Requiem for Methuselah", stardate 5842.8

Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition

[Bastian Blank]

Control: tags -1 moreinfo
Control: severity -1 important

On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote:
> booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device 
> fails
> to mount the root partition. I just tried the kernel from sid and it seems 
> indeed \
> affected. The 6.7 kernel from trixie is instead booting fine even after
> regenerating all initrds.

Please provide proper error messages.

Also dracut is not the default option, so please check with
initramfs-tools as well.

Bastian
-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown

Bug#1071467: linux-image-6.6.13+bpo-amd64: installation botched, tiny and corrupt deb file

[Manny]

Package: src:linux
Version: 6.6.13-1~bpo12+1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debbug.linux-am...@sideload.33mail.com

To install linux-image-6.6.13+bpo-amd64, this command was executed:

  $ apt -t bookworm-backports install linux-image-amd64

I have a transcript of the session but it’s probably not worth
posting. It’s in the binary format produced by the “script”
command. The deb file is only 1,480 bytes, which is obviously a
non-starter. The final output was this:

  Download is performed unsandboxed as root as file 
'/root/linux-image-amd64_6.6.13-1~bpo12+1_amd64.deb' couldn't be accessed by 
user '_apt'. - pkgAcquire::Run (13: Permission denied)

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

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

Versions of packages linux-image-6.6.13+bpo-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.6.13+bpo-amd64 recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.6.13+bpo-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-13+deb12u1
pn  linux-doc-6.6   

Versions of packages linux-image-6.6.13+bpo-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20230210-5
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1071200: git-buildpackage: gbp import-orig: support filtering based on debian/clean

[Guido Günther]

Hi dkg,
On Thu, May 16, 2024 at 10:15:52AM -0400, Daniel Kahn Gillmor wrote:
> Hi Guido--
> 
> On Thu 2024-05-16 08:39:27 +0200, Guido Günther wrote:
> > Great! This matches my preferred way too.
> 
> ☺  Thanks for walking through the options here with me!
> 
> > Wouldn't d/copyright's `Files-Excluded:` work here too? I'm using that
> > for similar purposes as it even allows to use `gbp import-orig --uscan`
> > and have things filtered out. `debian/clean` could parse the pattern from
> > there.
> 
> Hm, I don't know what the semantics are for Files-Excluded, or what
> other side effects they have.  The documentation for the
> machine-readable copyright format:
> 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> 
> doesn't even include the word "Excluded", let alone "Files-Excluded"
> (see #685506, sigh).  According to
> https://wiki.debian.org/UscanEnhancements#Deleting_Files_using_Files-Excluded_field_in_debian.2Fcopyright
> the Files-Excluded field actually affects the tarball by causing uscan
> to re-pack it without those files.
> 
> Doing the tarball re-packing would mean breaking the upstream tarball's
> cryptographic signature, so i'm not sure i want to do that.  The goal
> here is to increase attributability and provenance, and breaking the
> upstream cryptographic signature seems to work against that goal.

But you'd break that when filtering out files? I think what keeps me
confused: the tarball uploaded to Debian is the filtered one and hence
has a different checksum, no? 

> 
> > What if you'd read the filter list in the `clean` target?
> 
> Hm, while i depend on gbp for my regular packaging workflow, one of the
> things i like about it is how it wraps itself around other packaging
> workflows.  If i remove debian/gbp.conf from my package's source, the
> source can still build just fine using dpkg-buildpackage or debuild.
> I'd like to keep that property.

I understand that point.

> 
> > I think what you propose is doing it the other way around: Have gbp
> > run `debian/rules clean` to have a programatical way of filtering?
> 
> right, that would do the job, and is probably the more principled way to
> do it than merely parsing debian/clean.  It would work regardless of

It would also have the upside that packages invoking `dh_clean … path1
path2` would still work.

Another reason to not parse debian/clean verbatim is that we'd also need
to support dh's substitution variables and would forever need to follow
what dh does (and we might even need to pay attention to the dh compat
level of the package) as otherwise things would break on people.

> whether the packaging used debhelper or not.  Does that seem like a
> plausible way to operate gbp import-orig?

That would be an approach. Implementation wise the "tricky" bit is
that you don't have debian/ on the upstream branch you want to filter so
dh_clean or `debian/rules clean` won't work as is . So we'd need to
overlay that (which is certainly doable, just wanted to point it out).

So that's a lot of effort for s.th. that can already be done via either
gbp.conf or FilesExcluded. I'm not against it, just looking at the pros
and cons.

Cheers,
 -- Guido

Bug#900364: paraview: Paraview viewer mishandles fractional Qt screen scaling

[Drew Parsons]

Package: paraview
Followup-For: Bug #900364
Control: tags 900364 moreinfo

Fractional scaling seems to be working now, at least for eDP-1 > 1.

Can you confirm if the problem is fixed in paraview 5.11.2 or later?

Bug#1071017: FTBFS: source-copy.cpp:615:31: error: ‘void obs_sceneitem_get_info(const obs_sceneitem_t*, obs_transform_info*)’ is deprecated [-Werror=deprecated-declarations]

[Eriberto Mota]

The current new upstream release (0.2.3) also will FTBFS.

Eriberto

Bug#842405: paraview: can't load hdf5 file: vtkSISourceProxy: Failed to create vtkXdmfReader

[Drew Parsons]

Package: paraview
Followup-For: Bug #842405
Control: tags 842405 moreinfo

HDF5 is a general data format, it has no natural viewing format.

When you load a file into paraview you need to specify which reader
you want to open it with. Which reader are you expecting to use with
your .h5 file?

Your test file does not crash with H5PartReader or HDF5 Rage Reader.

Bug#820453: paraview: "Help -> ParaView Guide" gives error

[Drew Parsons]

Package: paraview
Followup-For: Bug #820453

"Help -> ParaView Guide" now (5.11.2) provides a (functioning) url
link to https://docs.paraview.org/en/v5.11.2/
which opens normally in the web browser.

Not so helpful if you don't have internet access, but at least it's
not giving an error now.  Perhaps we can close this bug.

Bug#1067023: ITP: vaultwarden -- Bitwarden compatible server written in Rust

[Philippe SWARTVAGHER]

Hello,

Any news about this ITP? I would very much appreciate to have
Vaultwarden available in Debian.

I found this GitHub repository
https://github.com/dionysius/vaultwarden-deb, which seems to be a good
starting point (and I even asked why they don't send it to Debian:
https://github.com/dionysius/vaultwarden-deb/discussions/10).

Let me know if I can help.

Philippe.

Bug#1071466: gpg-from-sq: clear-sign failed: Signing key maps to different keys

[Holger Levsen]

Package: gpg-from-sq
Version: 0.8.0-5
Severity: normal

Dear Maintainer ;)

when trying to upload I got this failure:

gpg: /tmp/debsign.ctzWuMYi/rust-sequoia-directories_0.1.0-1.dsc: clear-sign 
failed: Signing key hol...@debian.org maps to 2 different keys: 
["480E51BAFB08CB4175CC91B15072D036AC583520", 
"B8BF54137B09D35CF026FE9D091AB856069AAA1C"]
debsign: gpg error occurred!  Aborting

I suppose this is not a rare configuration.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It ain't no revolution, just because you can dance to it.


signature.asc
Description: PGP signature

Bug#982601: python3-paraview Conflicts: python3-vtk9

[Drew Parsons]

Package: paraview
Version: 5.11.2+dfsg-6+b9
Followup-For: Bug #982601
X-Debbugs-Cc: Petter Reinholdtsen 

Petter, paraview might never be aligned with vtk.

See https://gitlab.kitware.com/paraview/paraview/-/issues/18751

If facet-analyser needs to be able to work with either (both)
python3-paraview or python3-vtk9, then it will need to check the
specific VTK version and adjust the API it's using to accommodate the
discrepancy.

Bug#1071465: xmlrpc-c: update package name for a SONAME bump

[Sudip Mukherjee]

Hi Alexandre,

On Sun, 19 May 2024 at 18:17, Alexandre Detiste
 wrote:
>
> Hi,
>
>> libxmlrpc_util.so.4
>
>
> I think it's a private library only meant for the one cli tool included in 
> the sale package.
>
> I ll check next week.

Its used by other packages, please see #1070965 as an example.


-- 
Regards
Sudip

Bug#1071465: xmlrpc-c: update package name for a SONAME bump

[Alexandre Detiste]

Hi,

libxmlrpc_util.so.4
>

I think it's a private library only meant for the one cli tool included in
the sale package.

I ll check next week.

Greetings

>

Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition

[Linux regression tracking (Thorsten Leemhuis)]

On Sat, 18 May 2024 22:25:14 +0200 Matteo Settenvini
 wrote:
> 
> booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device 
> fails
> to mount the root partition. I just tried the kernel from sid and it seems 
> indeed \
> affected. The 6.7 kernel from trixie is instead booting fine even after
> regenerating all initrds.
> 
> According to bl...@debian.org, this is likely due to
> https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66

Would be great to know what the actual problem is. Are there any error
messages from systemd or the kernel?

The upstream bug (https://github.com/systemd/systemd/pull/32892 ) about
this also does not state what goes wrong (either in general or certain
situations).

Such details would likely be needed to convince the btrfs upstream devs
to revert the change or apply a workaround -- especially as I'm pretty
sure there are already a lot of btrfs systems with systemd and 6.8
(release upstream 2+ month ago and regularly used in Arch, Fedora and
Tumbleweed for weeks now) out there and working just fine (including the
Fedora machine one I write from).

Thorsten

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Luca Boccassi]

On Sun, 19 May 2024 18:42:17 +0200 Helmut Grohne 
wrote:
> the init process should handle SIGTERM more like an init system would
handle that

This seems the obvious answer to me. sbuild is setting up a system such
that its component runs as pid1, so it needs to behave like a pid1. We
know this is special and requires supporting a number of interfaces. If
a program doesn't, then it shouldn't be running as pid1 in a namespace.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071465: xmlrpc-c: update package name for a SONAME bump

[Sudip Mukherjee]

Source: xmlrpc-c
Version: 1.59.03-1
Severity: serious
Justification: Policy 8.1
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

The latest update had a SONAME bump of libxmlrpc_util.so which changed from
libxmlrpc_util.so.3 to libxmlrpc_util.so.4, so your package name should have
been changed according to the Debian policy.
But the package also contains libxmlrpc.so.3 which did not have a SONAME
bump.
Please consider splitting up the package so that libxmlrpc_util.so.4 is in
its own package with the packagename matching the SONAME.

-- 
Regards
Sudip

Bug#1071464: ITP: libsyntax-infix-smartmatch-perl -- simplified smartmatch module

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libsyntax-infix-smartmatch-perl
  Version : 0.005
  Upstream Author : Leon Timmermans 
* URL : https://metacpan.org/release/Syntax-Infix-Smartmatch
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : simplified smartmatch module

Syntax::Infix::Smartmatch implements a new, much simplified version of
smartmatch. In particular the behavior only depends on the right side
argument.

Syntax::Infix::Smartmatch is currently still experimental and the details of
its behavior may still change.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#1071463: pygmsh: autopkgtest regression with pytest 8 on i386

[Timo Röhling]

Source: pygmsh
Version: 7.1.17-4
Severity: serious
User: debian-rele...@lists.debian.org
Usertags: bsp-2024-05-mdc-ber

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package starting hanging in the autopkgtest on i386 with pytest 8, 
resulting in a timeout.

See https://ci.debian.net/packages/p/pygmsh/testing/i386/46854179/ as example.

Cheers
Timo


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZKLIsACgkQzIxr3RQD
9MpR0g//WVf5f11r+XYrCspMB2fxm+Z3JNaPh0F+s5zb7Rhwalrjd9k5V+wFy4YO
ebwczCSDHDcg+QTp2ShCj1AZ0LtNi9rVuiGuKoiWou3Up4xYNBjtQ2AnzgVK0gOO
/kWWIwIgFqK7n1mMNRQlEQHl4WEKvkg5yTVVF/YmJ4PDwgbhZRjsGjupM5uv7uVO
4wopGPU4nC/IpBbpiNaQQdou+JpRQbHJZztgQnNR000SIVdy2OJSfaSLlkmGRGxb
vipw1AoCIugJV+6r9rJh6Zn+flZtqdz1eN4Zc/nsaSX2r+WF8CSnTHVw7RIOG8iT
NTI0HDhZelSb2s2q+Awb/yqOXzbEnqszZ1rN6mPME7z9STu2PXIwKhxzMM67p2Ky
GMiknL1v/51AnhNKZxB5iDPsoEnvEK/lJB/fB94AnWW1SjrhnzZxLGIj1e00RkS1
AHJnI6v7epPHSQzT6t1kJVR/VjOn7ptOr3CvhyhzXLr85a9QrTaaEY/ybToTMZ1C
95btUQeCkWMhOC5PXFlkN+1Nx6G5FAvzx2wy5oEfiLbXAL+6X8LUFOxWDG2E4loa
wHlGj/mMrmuWw/UvL3Aw2WLO+Hts4OYdSbWv6z2hLl/YF/ZLGaEyLrmPqya/7SAL
Il/0wMuJ8zk6NV5rWLsOcBNvWvFQsIwudyaXKqMVySscO0PFS0s=
=yFnQ
-END PGP SIGNATURE-

Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Helmut Grohne]

Package: sbuild,debianutils,libc6,systemd-sysv
Severity: important

Hello lots of maintainers,

I am faced with a very crazy interaction bug. Roughly speaking, when you
use sbuild to build a package and your build-depends happen to include
systemd-sysv and you happen to install (cross building) or upgrade
libc6, installing build-depends reliably fails. Since upgrading libc6 is
a thing, I guess that this now affects buildds and is why I file this at
important severity. Regenerating buildd chroots, will "heal" buildds, so
it is self-recovering there.

Without further ado, let's dive into the details. The issue is
reproducible using mmdebstrap:

mmdebstrap unstable --verbose --architectures amd64,arm64 --variant=apt 
/dev/null --include=systemd-sysv,libc6:arm64 --essential-hook='ln -sf 
/bin/false $1/usr/bin/ischroot'

This is using a cross build setting, because libc6 is installed early
during bootstrap and reproducing the bug takes configuring libc6 after
systemd-sysv has been unpacked. So I simply install a foreign libc6 and
apt happens to configure it late enough in my tests. So we now look into
libc6.postinst. We take the "$1" = "configure" branch. We eventually run
into:

| # Restart init.  Currently handles chroots, systemd and upstart, and
| # assumes anything else is going to not fail at behaving like
| # sysvinit:
| TELINIT=yes
| if ischroot 2>/dev/null; then
| # Don't bother trying to re-exec init from a chroot:
| TELINIT=no

I note that mmdebstrap creates a number of namespaces and then
externally runs apt. If I understand things correctly, it also runs an
external dpkg --root ... without --force-scripts-chrootless. Hence dpkg
performs a chroot for every maintainer script and ischroot correctly
detects this, so we would be setting TELINIT=no if I were not replacing
it in the --essential-hook.

In sbuild, the namespace setup is different. apt is entirely run inside
the namespace. ischroot compares /proc/1/mountinfo to
/proc/self/mountinfo. If both are readable and equal, it concludes that
we're not in a chroot. If they differ, it concludes that we are in a
chroot. For mmdebstrap, pid 1 happens to be a mmdebstrap process in the
initial namespace and the ischroot process sees fewer mounts. Hence it
concludes success there. For sbuild, pid 1 is a runuser process already
running chrooted. Hence the mountinfo files equal and ischroot concludes
that we are not running in a chroot.

| elif [ -n "${DPKG_ROOT:-}" ]; then
| # Do not re-exec init if we are operating on a chroot from outside:
| TELINIT=no

In neither case DPKG_ROOT is non-empty.

| elif [ -d /run/systemd/system ]; then
| # Restart systemd on upgrade, but carefully.
| # The restart is wanted because of LP: #1942276 and Bug: #993821
| # The care is needed because of https://bugs.debian.org/753725
| # (if systemd --help fails the system might still be quite broken but
| # that seems better than the kernel panic that results if systemd
| # cannot reexec itself).
| TELINIT=no

In neither case /run/systemd/system exists.

| if systemd --help >/dev/null 2>/dev/null; then
| systemctl daemon-reexec
| else
| echo "Error: Could not restart systemd, systemd binary not 
working" >&2
| fi
| fi
| if [ "$TELINIT" = "yes" ]; then
| telinit u 2>/dev/null || true ; sleep 1
| fi

And finally we run telinit u when running inside sbuild or faking
ischroot in mmdebstrap. Running telinit u doesn't go well. This actually
has been a known problem with different symptoms recently. Earlier,
cross build nodes would get stuck in libc6.postinst hanging in telinit
forever. The reason was that telinit was re-executing itself over and
over again attempting to forward to another init system but always
returning back to itself. This has been fixed by Luca Boccassi:

https://github.com/systemd/systemd/pull/31251 and #1063147

telinit no longer reexecs itself and rather does what it is supposed to
do: kill(1, SIGTERM). Sadly this doesn't go well. In case of sbuild, we
kill the runuser process. It exits non-zero and sbuild considers this a
failure to install Build-Depends. This is bad.

So I'm not exactly sure which part is broken here. We might argue that
sbuild is setting up a container that looks too much like a container
and should have pid 1 outside the chroot area or that the init process
should handle SIGTERM more like an init system would handle that. We
might argue that ischroot should detect init-less application container
environments. We might argue that libc6 should ischroot is not meant for
detecting application containers and libc6.postinst asks the wrong
question and should be skipping telinit for such environments as well.
We might argute that telinit should not kill a pid 1 that isn't systemd.

At this time, I am really unsure which of these four packages we
consider at fault. 

Bug#1071461: nibabel: nose-style setup/teardown is no longer supported in pytest 8

[Timo Röhling]

Source: nibabel
Version: 5.2.1-1
Severity: serious
User: debian-rele...@lists.debian.org
Usertags: bsp-2024-05-mdc-ber

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package uses setup() and teardown() functions which used to be part of the 
nose compatibility layer in pytest. However, these functions have been 
deprecated since pytest 7.2 and support for nose has been permanently removed 
as of pytest 8:

https://docs.pytest.org/en/8.1.x/deprecations.html#setup-teardown

You can probably just replace setup() and teardown() by setup_method() and 
teardown_method(), respectively.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZKK00ACgkQzIxr3RQD
9MoL0Q//SQhorKZGmcLjv2ObqEbVIrD2OFMzfTtaE0XoarNIhSlr17e/odtfv3Ua
rtzqkVyF3TruaD2rjMnwGsK6fAGG+La8xVDDmSe2vAIqhZespaxSoatVqtdH9gMN
dxexaq944j+mvOP0kkSsmf1K1xmEr2TlmdkVJ5zGYFrkTVvdIzuqxODhu7eb5qah
eZINi2Ht+MNM/mW851XZWMuDCLJsw14JmzFl3S0CRMABJYudS+9cNJYsrACOa7Sl
sPdUbsA6d+SQVOCVgLD1qfMcOuKhRLTqIi1K09YEGaFc5QmDX/sd0pVHeCZ6+o/K
fSwc0Q+dFqmPzo2m4eBuxjCjjHUQKtpbIXI7fwD1oyLbI80OVE9GWS0Ll45K2xzw
kWmxBIARpXrhvbzEBOcntR5pyh9MsDRJQzNnPe/c5d80YDUfORPwi0fuRpC1rxbr
ktBVuI8wo55J2Vt3cN47v6NLlRPKaVU9UX3ePoRdNDk/HkvBa5J8iSNpaUqHu4an
66HyGf1LaLOWF+CYD78JMvu1rYiihD/CY9h6KuKF2gFjPhSaqoS4UopmZRPQV+4E
MlFLjmJli5GpvHTHjPRQULjvN8EgX1Xrha7UAxt/Ffe0PWcMBokvH8lqIFyzZ2oO
ThInCbz+XBOkpYtGgjLYuAZNfzg8JOpcqgzvCJuW9EiihHzW2QU=
=VeVj
-END PGP SIGNATURE-

Bug#1058920: arcanist: Evaluate adoption of new upstream Phorge (to support PHP 8.1+ and security fixes)

[Yongmin]

On Mon, 18 Dec 2023 13:05:49 +0100 Sylvestre Ledru  wrote:
> 
> I am not interested in maintaining arcanist (or phab) anymore. 
> Contributions are welcome :)
> 
> Cheers, S
> 

I guess this is equivalent of Orphaning[1] the package? Since you know if this 
is O or RFA better than anyone else, I think you should be the one filing the 
bug. :-0

So long, and thanks for all the fish!

[1]: https://www.debian.org/devel/wnpp/#tag-severity


revi | 레비
- he/him 
- What time is it in my timezone? 
- In this Korean name , the family 
name is Hong .
https://revi.xyz

Bug#1071460: ITP: libexcel-valuereader-xlsx-perl -- module for extracting values from Excel workbooks in XLSX format

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libexcel-valuereader-xlsx-perl
  Version : 1.14
  Upstream Author : Laurent Dami 
* URL : https://metacpan.org/release/Excel-ValueReader-XLSX
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for extracting values from Excel workbooks in XLSX 
format

Excel::ValueReader::XLSX reads the contents of an Excel file in XLSX format.
Unlike other modules like Spreadsheet::ParseXLSX or Spreadsheet::XLSX,
there is no support for reading formulas, formats or other Excel internal
information; all you get are plain values -- but you get them much
faster!

Excel::ValueReader::XLSX has two possible implementation backends for parsing
XLSX files: Excel::ValueReader::XLSX::Backend::Regex, based on regular
expressions, or Excel::ValueReader::XLSX::Backend::LibXML, based on the
libxml2 library.

The Regexp backend uses regular expressions to parse the XML content. The
libxml2 backend uses XML::LibXML::Reader to parse the XML content. It is
probably safer but about three times slower than the Regex backend (but still
much faster than Spreadsheet::ParseXLSX).

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#1071459: wireplumber-doc: un-expanded references to $datadir and $sysconfdir

[Michael Gold]

Package: wireplumber-doc
Version: 0.5.2-3

Dear Maintainer,

The "Locations of WirePlumber’s files" page refers to $sysconfdir and
$datadir in several places, and says:
$syscondir and $datadir refer to meson’s directory options
[https://mesonbuild.com/Builtin-options.html#directories]
and are hardcoded at build time

/usr/share/doc/wireplumber/html/daemon/locations.html

On the meson page, searching for $datadir gives "share" as the location,
and one has to read the section above that to see it's relative to a
"prefix", which may be /usr, /usr/local, or something else.

This variability may be useful when the documentation's posted online.
When included in a binary package, I think it would be better to have
the variables pre-expanded.  In other words, replace every instance of
$datadir with /usr/share and $sysconfdir with /etc, and remove the
"meson's directory options" sentence.

- Michael


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

Kernel: Linux 6.8.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-- debconf-show failed



signature.asc
Description: PGP signature

Bug#1071457: wireplumber-doc: whether XDG variables have default values is not stated

[Michael Gold]

Package: wireplumber-doc
Version: 0.5.2-3

Dear Maintainer,

The "Locations of WirePlumber’s files" page refers to XDG environment
variables (such as $XDG_DATA_HOME) in several places, and links to the
specification.  However, it doesn't say what happens if one of those
variables is not set.  The specification says a default "should" be
used, which is to say that using a default is optional.

WirePlumber does seem to use the default values, and that should be
documented.

- Michael


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

Kernel: Linux 6.8.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-- debconf-show failed



signature.asc
Description: PGP signature

Bug#1071458: wireplumber-doc: "in order of priority" statements are unclear

[Michael Gold]

Package: wireplumber-doc
Version: 0.5.2-3

Dear Maintainer,

The "Locations of WirePlumber’s files" page is unclear about priority
in two places.  The page starts with this statement:
WirePlumber’s default locations of its configuration files are
the following, in order of priority:
1. $XDG_CONFIG_HOME/wireplumber
2. $XDG_CONFIG_DIRS/wireplumber
3. $sysconfdir/wireplumber
4. $XDG_DATA_DIRS/wireplumber
5. $datadir/wireplumber
[…]
At runtime, WirePlumber will seek out the directory with the highest
priority that contains the required configuration file.

/usr/share/doc/wireplumber/html/daemon/locations.html

Similar wording is used for "Location of scripts".  "Highest" could mean
numerically largest, closest to the top of the list, or something else.
I recommend changing this to something like "in descending order of
priority"; user files taking priority over system files makes sense, and
seems to be the behaviour.

The "DIR" environment variables, by contrast, are well explained:
If multiple directories are specified, the first one has the highest
priority and the last one has the lowest.

- Michael


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

Kernel: Linux 6.8.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

-- debconf-show failed



signature.asc
Description: PGP signature

Bug#1068632: dh-exec still broken

[Kip Warner]

Hello Debian Bug Tracking System,

I would like to keep this bug report open still.

I did try Craig's potential fix here:

   
https://salsa.debian.org/debian/dh-exec/-/commit/6f273ea8c362eea825a418c5a110a8dcd3959bfa

I can confirm that it does not work. dh_missing does not report any
warnings anymore, but the resulting package does not contain anything
that I specified in my .install file.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1053285: AttributeError: 'PlatformioCLI' object has no attribute 'resultcallback'

[Markus Grunwald]

On Sat, 30 Sep 2023 20:58:29 +0200 Gregor Riepl  wrote:

Package: platformio
Version: 4.3.4-3
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/platformio/platformio-core/issues/4075
X-Debbugs-Cc: onit...@gmail.com



The current version of PlatformIO in Debian no longer works with python3-click
due to the following incompatibility:
AttributeError: 'PlatformioCLI' object has no attribute 'resultcallback'. Did
you mean: 'result_callback'?

This issue has been fixed in PlatformIO 5.2.1.
Preferably, update to the latest upstream version (6.1.11 currently).


Pretty, pretty please fix this bug. Or remove the package if it's 
unmaintained...


cu
--
Markus

Bug#1071456: autopkgtest-virt-qemu: autopkgtest [15:14:50]: ERROR: testbed failure: sent `auxverb_debug_fail', got `timeout', expected `ok...'

[Wouter Verhelst]

Package: autopkgtest
Version: 5.35
Severity: normal

I ran

> sudo autopkgtest-build-qemu --architecture amd64 sid 
> /opt/chroots/autopkgtest-qemu.img

followed by

> autopkgtest . --test-name=initrd-boot -- qemu 
> /opt/chroots/autopkgtest-qemu.img

in a directory that is a checkout of https://salsa.debian.org/wouter/nbd.git

It installed the test dependencies, and then failed on:

> autopkgtest [16:55:00]: Setting up user "user" to sudo without password...
> qemu-system-x86_64: terminating on signal 15 from pid 150414 
> (/usr/bin/python3)
> autopkgtest [17:00:02]: ERROR: testbed failure: sent `auxverb_debug_fail', 
> got `timeout', expected `ok...'

which I did not expect...

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.9.3
ii  libdpkg-perl1.22.6
ii  mawk1.3.4.20240123-1
ii  procps  2:4.0.4-4
ii  python3 3.11.8-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.34-1

Versions of packages autopkgtest suggests:
ii  docker.io20.10.25+dfsg1-3
pn  fakemachine  
ii  genisoimage  9:1.1.11-3.5
pn  incus
ii  lxc  1:6.0.0a-1
pn  lxd  
ii  ovmf 2024.02-2
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.7
ii  qemu-efi-aarch64 2024.02-2
ii  qemu-efi-arm 2024.02-2
pn  qemu-efi-riscv64 
ii  qemu-system  1:8.2.3+ds-2+b1
ii  qemu-utils   1:8.2.3+ds-2+b1
ii  schroot  1.6.13-3+b3
ii  util-linux   2.40.1-1
ii  vmdb20.40-1
ii  zerofree 1.1.1-1+b1

-- no debconf information

Bug#1071455: python-html-sanitizer: python3-lxml-html-clean is now a separate package

[Rebecca N. Palmer]

Package: python-html-sanitizer
Version: 2.2-1

lxml.html.clean has been moved from python3-lxml to a new package 
python3-lxml-html-clean (as discussed in 
https://bugs.launchpad.net/lxml/+bug/1958539).  This package uses 
lxml.html.clean but only declares a relationship on python3-lxml.


I don't know how central the functionality that requires lxml.html.clean 
is, and hence whether Depends, Recommends or Suggests is appropriate.


In the longer term, if you are using lxml.html.clean for security 
against code injection, be aware that it is not a very secure approach. 
lxml upstream recommend moving to something stronger e.g. python3-bleach 
or nh3.

Bug#1071454: html-text: python3-lxml-html-clean is now a separate package

[Rebecca N. Palmer]

Package: html-text
Version: 0.5.2-2

lxml.html.clean has been moved from python3-lxml to a new package 
python3-lxml-html-clean (as discussed in 
https://bugs.launchpad.net/lxml/+bug/1958539).  This package uses 
lxml.html.clean but only declares a relationship on python3-lxml.


I don't know how central the functionality that requires lxml.html.clean 
is, and hence whether Depends, Recommends or Suggests is appropriate.


In the longer term, if you are using lxml.html.clean for security 
against code injection, be aware that it is not a very secure approach. 
lxml upstream recommend moving to something stronger e.g. python3-bleach 
or nh3.

Bug#1071453: napari: python3-lxml-html-clean is now a separate package

[Rebecca N. Palmer]

Source: napari
Version: 0.5.0~a1-6

lxml.html.clean has been moved from python3-lxml to a new package 
python3-lxml-html-clean (as discussed in 
https://bugs.launchpad.net/lxml/+bug/1958539).  This package uses 
lxml.html.clean but only declares a relationship on python3-lxml.


I don't know how central the functionality that requires lxml.html.clean 
is, and hence whether Depends, Recommends or Suggests is appropriate.


In the longer term, if you are using lxml.html.clean for security 
against code injection, be aware that it is not a very secure approach. 
lxml upstream recommend moving to something stronger e.g. python3-bleach 
or nh3.

Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition

[Luca Boccassi]

Control: reassign -1 src:linux
Control: severity -1 grave

On Sun, 19 May 2024 15:25:06 +0200 Salvatore Bonaccorso
 wrote:
> Control: reassign -1 src:systemd
> 
> On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote:
> > Package: src:linux
> > Version: 6.8.9-1
> > Severity: important
> > Tags: upstream
> > 
> > Dear Maintainer,
> > 
> > booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root
device fails
> > to mount the root partition. I just tried the kernel from sid and
it seems indeed \
> > affected. The 6.7 kernel from trixie is instead booting fine even
after
> > regenerating all initrds.
> > 
> > According to bl...@debian.org, this is likely due to
> >
https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66
> > 
> > See https://lwn.net/Articles/973997/
> 
> The deprecation was there for a while indeed and dropped by upstream
> for 6.8-rc1. But it looks systemd is adressing this with
> 
>
https://github.com/systemd/systemd/commit/e3828d7103a99a15a1e947ba3063294ead590631
> 
> As we wont apply a local Debian patch unless upstream Linux decides
to
> facilitate this by adding a noop option back, then I think it's best
> to reassign this bug to systemd and close it once the above change is
> applied.

Sorry, but I am reassigning back and bumping severity to stop
migration, as this is a kernel regression, as a stable userspace
interface was removed, which breaks booting existing systems. Hence I
am quite sure the new kernel should not move to testing for the time
being.
We might (or might not, still to be seen, given detecting mount options
that a kernel support is an absolute mess and it risks breaking booting
with the LTS kernels) put in a workaround in userspace in a while, but
this really should be reverted in the kernel. If mount options are no
longer required, they should simply remain as no-ops.

-- 
Kind regards,
Luca Boccassi


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

Bug#1071368: [gpgv] cmd-arg parse error with apt/aptitude update

[Lyndon Brown]

On Sun, 2024-05-19 at 07:41 +0200, Andreas Metzler wrote:
> Thanks for the quick reply. You have installed gpgv-from-sq which
> diverts "our" gpgv. (I will check a little bit more and reassign to
> apt.)

Oh okay. I'd assumed that gpgv had dropped support for the argument
either accidentally through a mistake with build args, or in a planned
way that overlooked use by apt, I wasn't expecting some third party
drop in to suddenly get installed with an imperfect emulation, I didn't
even know there were alternative implementations available. I did
notice the installation of the 'sq' packages but it happened as part of
a normal upgrade, I didn't ask for them, and I assumed that it was just
another splitting up of code to minimise attack surface after the
recent high profile supply chain attack against ssh.

So the 'sq' packages are actually a Rust-based alternative, that's
great, big fan of Rust. However somehow it's gotten pulled in as a
replacement now, without explicitly asking for it, when it's not
actually fully ready for use as a replacement in Debian considering
it's emulation is incomplete and it impacts something as critical as
apt.

Why did it get installed? Here's my apt log from early morning 2024-05-
17 having run `aptitude upgrade`:

Install: gpgv-sq:amd64 (0.8.0-5, automatic), gpgv-from-sq:amd64 (0.8.0-
5, automatic), sq:amd64 (0.33.0-3, automatic)
Upgrade: libwireshark17t64:amd64 (4.2.4-1, 4.2.5-1), libwireshark-
data:amd64 (4.2.4-1, 4.2.5-1), udev:amd64 (256~rc2-1, 256~rc2-3),
systemd-oomd:amd64 (256~rc2-1, 256~rc2-3), libgdk-pixbuf2.0-bin:amd64
(2.42.10+dfsg-3+b3, 2.42.12+dfsg-1), systemd-container:amd64 (256~rc2-
1, 256~rc2-3), libnss-myhostname:amd64 (256~rc2-1, 256~rc2-3), libpam-
systemd:amd64 (256~rc2-1, 256~rc2-3), busybox:amd64 (1:1.36.1-6+b1,
1:1.36.1-7), gir1.2-gdkpixbuf-2.0:amd64 (2.42.10+dfsg-3+b3,
2.42.12+dfsg-1), python3-typing-extensions:amd64 (4.10.0-1, 4.11.0-1),
libjavascriptcoregtk-4.1-0:amd64 (2.44.1-1+b1, 2.44.2-1),
libsystemd0:amd64 (256~rc2-1, 256~rc2-3), gir1.2-javascriptcoregtk-
4.1:amd64 (2.44.1-1+b1, 2.44.2-1), python3-requests:amd64 (2.31.0+dfsg-
1, 2.31.0+dfsg-2), gir1.2-javascriptcoregtk-6.0:amd64 (2.44.1-1+b1,
2.44.2-1), libnss-systemd:amd64 (256~rc2-1, 256~rc2-3), gir1.2-webkit2-
4.1:amd64 (2.44.1-1+b1, 2.44.2-1), libgdk-pixbuf-2.0-0:amd64
(2.42.10+dfsg-3+b3, 2.42.12+dfsg-1), libjavascriptcoregtk-6.0-1:amd64
(2.44.1-1+b1, 2.44.2-1), libwiretap14t64:amd64 (4.2.4-1, 4.2.5-1),
systemd:amd64 (256~rc2-1, 256~rc2-3), libudev1:amd64 (256~rc2-1,
256~rc2-3), libnss-mymachines:amd64 (256~rc2-1, 256~rc2-3), wireshark-
common:amd64 (4.2.4-1, 4.2.5-1), gpgv:amd64 (2.2.43-3, 2.2.43-5),
systemd-resolved:amd64 (256~rc2-1, 256~rc2-3), python3-numpy:amd64
(1:1.26.4+ds-8, 1:1.26.4+ds-9), libyuv0:amd64 (0.0.1888.20240509-3,
0.0.1888.20240509-4), libwebkit2gtk-4.1-0:amd64 (2.44.1-1+b1, 2.44.2-
1), libnss-resolve:amd64 (256~rc2-1, 256~rc2-3), libwsutil15t64:amd64
(4.2.4-1, 4.2.5-1), gir1.2-webkit-6.0:amd64 (2.44.1-1+b1, 2.44.2-1),
libsystemd-shared:amd64 (256~rc2-1, 256~rc2-3), systemd-sysv:amd64
(256~rc2-1, 256~rc2-3), libwebkitgtk-6.0-4:amd64 (2.44.1-1+b1, 2.44.2-
1), wireshark:amd64 (4.2.4-1, 4.2.5-1), linux-libc-dev:amd64 (6.7.12-1,
6.8.9-1), libgdk-pixbuf2.0-common:amd64 (2.42.10+dfsg-3, 2.42.12+dfsg-
1)

Having a quick look now at `gpgv-from-sq` and `gpgv-sq` in `aptitude -
i`, I see nothing depending on the former, and only the former depends
on the latter. There's also the `sq` package... I see `dpkg-dev` (which
I have installed) lists `sq` as an alternative to a dependency on both
`gpgv` and `gnupg`. Hmm.

Ah, I recall that some gpg packages were held back from upgrade during
this time. Only the `gpgv` package got upgraded in the above log. Only
later in the day did the rest get upgraded:

Install: linux-image-6.8.9-amd64:amd64 (6.8.9-1, automatic), linux-
headers-6.8.9-common:amd64 (6.8.9-1, automatic), linux-kbuild-
6.8.9:amd64 (6.8.9-1, automatic), linux-headers-6.8.9-amd64:amd64
(6.8.9-1, automatic)
Upgrade: gpg:amd64 (2.2.43-3, 2.2.43-6), linux-headers-amd64:amd64
(6.7.12-1, 6.8.9-1), gnupg:amd64 (2.2.43-3, 2.2.43-6), gpg-wks-
server:amd64 (2.2.43-3, 2.2.43-6), gpg-agent:amd64 (2.2.43-3, 2.2.43-
6), linux-image-amd64:amd64 (6.7.12-1, 6.8.9-1), gpgv:amd64 (2.2.43-5,
2.2.43-6), gpgsm:amd64 (2.2.43-3, 2.2.43-6), dirmngr:amd64 (2.2.43-3,
2.2.43-6), 7zip:amd64 (24.05+dfsg-2, 24.05+dfsg-3), gnupg-utils:amd64
(2.2.43-3, 2.2.43-6), gnupg-l10n:amd64 (2.2.43-3, 2.2.43-6), gpg-wks-
client:amd64 (2.2.43-3, 2.2.43-6), gpgconf:amd64 (2.2.43-3, 2.2.43-6),
intel-microcode:amd64 (3.20240312.1, 3.20240514.1)

So it seems that with some of the gpg packages held back, including
`gnupg`, `aptitude upgrade` chose to pull in `sq` as a replacement. :/

Bug#1071452: dnsdbq FTBFS on 32bit with 64bit time_t

[Adrian Bunk]

Source: dnsdbq
Version: 2.6.6-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=dnsdbq=2.6.6-1

...
time.c: In function ‘timeval_str’:
time.c:83:36: error: format ‘%ld’ expects argument of type ‘long int’, but 
argument 3 has type ‘__suseconds64_t’ {aka ‘long long int’} [-Werror=format=]
   83 | sprintf(dst, ".%03ld", src->tv_usec % 1000);
  |^   ~~~
  |||
  |long int __suseconds64_t 
{aka long long int}
  |%03lld
time.c:85:36: error: format ‘%ld’ expects argument of type ‘long int’, but 
argument 3 has type ‘__suseconds64_t’ {aka ‘long long int’} [-Werror=format=]
   85 | sprintf(dst, ".%06ld", src->tv_usec % 100);
  |^   ~~
  |||
  |long int __suseconds64_t 
{aka long long int}
  |%06lld
cc1: all warnings being treated as errors
make[1]: *** [Makefile:76: time.o] Error 1

Bug#1071451: src:gmsh: FTBFS with new opencascade 7.8.1

[Tobias Frost]

Source: gmsh
Severity: important
Tags: patch ftbfs

Dear maintainer,

gmsh FTBFS with the new opencascade 7.8.1 as the CMakeLists.txt missed to list 
one library,
and therefore many symbols are not resolved at build time:

Excerpt of build log:

/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`STEPCAFControl_Reader::STEPCAFControl_Reader()'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`STEPCAFControl_Reader::ChangeReader()'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`HeaderSection_FileDescription::SetImplementationLevel(opencascade::handle
 const&)'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`APIHeaderSection_MakeHeader::FdValue() const'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`HeaderSection_FileName::SetTimeStamp(opencascade::handle
 const&)'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`APIHeaderSection_MakeHeader::APIHeaderSection_MakeHeader(int)'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`HeaderSection_FileName::SetOriginatingSystem(opencascade::handle
 const&)'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`StepData_StepModel::AddHeaderEntity(opencascade::handle 
const&)'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`HeaderSection_FileName::SetPreprocessorVersion(opencascade::handle
 const&)'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`StepData_StepModel::Header() const'
collect2: error: ld returned 1 exit status
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`STEPCAFControl_Reader::Transfer(opencascade::handle const&, 
Message_ProgressRange const&)'
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`HeaderSection_FileName::SetName(opencascade::handle 
const&)'
collect2: error: ld returned 1 exit status
/usr/bin/ld: libgmsh.so.4.12.2: undefined reference to 
`STEPControl_Writer::Write(char const*)'
make[4]: *** [CMakeFiles/t13_cpp.dir/build.make:190: t13_cpp] Error 1
make[4]: Leaving directory '/build/gmsh-4.12.2+ds1/debian/build'
make[3]: *** [CMakeFiles/Makefile2:1759: CMakeFiles/t13_cpp.dir/all] Error 2
make[4]: *** [CMakeFiles/t14_cpp.dir/build.make:190: t14_cpp] Error 1
make[4]: Leaving directory '/build/gmsh-4.12.2+ds1/debian/build'


The attached patch makes the packages compile here locally - the patch *should*
be backward compatible with the older opencascade currently in sid.

-- 
tobi

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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1331,7 +1331,7 @@
 if(FREETYPE_FOUND)
   if(OCC_VERSION AND OCC_VERSION VERSION_GREATER_EQUAL "7.8.0")
 set(OCC_CAF_LIBS_REQUIRED
-TKXCAF TKLCAF TKVCAF TKCAF TKV3d TKService TKCDF)
+TKXCAF TKLCAF TKVCAF TKCAF TKV3d TKService TKCDF TKDESTEP )
   else()
 set(OCC_CAF_LIBS_REQUIRED
 TKXDESTEP TKXDEIGES TKXCAF TKLCAF TKVCAF TKCAF TKV3d TKService 
TKCDF)

Bug#985478: [v2 PATCH] options: Always reset OPTIND in getoptsreset

[Herbert Xu]

On Sun, May 19, 2024 at 02:23:23PM +0100, Harald van Dijk wrote:
>
> This interacts terribly with the not fully reliable but nevertheless fairly
> commonly used "local OPTIND". When the local OPTIND goes out of scope and
> the prior value of OPTIND is restored, the expectation is not that option
> processing restarts from the beginning.

Dash doesn't actually need "local OPTIND".  In fact, if you do
"local OPTIND" then dash will already be broken because even
if OPTIND is reset to the same value, the other internal state
optoff will end up being wrong.

However, it's not hard to make dash ignore "local OPTIND" and
make it work as if it wasn't there.

---8<---
Always reset OPTIND if it is modified by the user, regardless of
its value.

Do not call getoptsreset when returning from a function because
of "local OPTIND" as this simply trashes the caller's getopts
state.

Reported-by: наб 
Reported-by: Harald van Dijk 
Signed-off-by: Herbert Xu 

diff --git a/src/options.c b/src/options.c
index 4d0a53a..c74e4fe 100644
--- a/src/options.c
+++ b/src/options.c
@@ -393,7 +393,7 @@ setcmd(int argc, char **argv)
 
 void getoptsreset(const char *value)
 {
-   shellparam.optind = number(value) ?: 1;
+   shellparam.optind = 1;
shellparam.optoff = -1;
 }
 
diff --git a/src/var.c b/src/var.c
index df432b5..b06b36c 100644
--- a/src/var.c
+++ b/src/var.c
@@ -93,7 +93,7 @@ struct var varinit[] = {
{ 0,VSTRFIXED|VTEXTFIXED,   "PS1=$ ",   0 },
{ 0,VSTRFIXED|VTEXTFIXED,   "PS2=> ",   0 },
{ 0,VSTRFIXED|VTEXTFIXED,   "PS4=+ ",   0 },
-   { 0,VSTRFIXED|VTEXTFIXED,   defoptindvar,   getoptsreset },
+   { 0,VSTRFIXED|VTEXTFIXED|VNOFUNC,   defoptindvar,   getoptsreset },
 #ifdef WITH_LINENO
{ 0,VSTRFIXED|VTEXTFIXED,   linenovar,  0 },
 #endif
@@ -535,7 +535,7 @@ poplocalvars(void)
ckfree(vp->text);
vp->flags = lvp->flags;
vp->text = lvp->text;
-   if (vp->func)
+   if (vp->func && !(vp->flags & VNOFUNC))
(*vp->func)(varnull(vp->text));
}
ckfree(lvp);
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)

[Paul Gevers]

Hi,

On 19-05-2024 2:55 p.m., 陈 晟祺 wrote:

My concern now is that the results do not seem to be stable or reproducible.


That's an reoccurring problem in lots of places, yes.


Is there any convention in handling such situation? E.g., should I mark all 
zfs-test-suite-x
as flaky and treat them as reference only?


It depends ;)

The disadvantage of marking the whole test stanza as flaky means that it 
won't block regressions at all. Depending on how the test (I mean per 
stanza in d/t/control) is set up, it makes more sense to mark individual 
tests as flaky then the whole suite/stanza. However, if there's not 
enough granularity, that doesn't really help.


Then there's the infrastructure argument. If your test is not a cheap 
one, running a long test only to fail flaky is a rather high price for 
very little gain. Then it might make more sense to not run the test by 
default (add a unknown restriction for example) and only use the test 
for manual checking, where you can judge (or rerun) the test as you 
judge fit.


In the end it's your decision. All I can say is that tests that are 
flaky enough (my level is roughly worse than 1/8) and not marked as such 
are considered RC buggy.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))

[Jean-Guilhem Cailton]

I should have added that the "apt full-upgrade" run that left the system 
with a broken sudo was interrupted by an error, also due to the missing 
libcrypto.so.3, and ended with:


"
Préparation du dépaquetage de .../5-postgresql-16_16.3-1_amd64.deb ...
systemctl: error while loading shared libraries: libcrypto.so.3: cannot 
open shared object file: No such file or directory
dpkg: avertissement: le sous-processus ancien paquet postgresql-16 
script pre-removal a renvoyé un état de sortie d'erreur 127

dpkg: tentative d'exécution du script du nouveau paquet à la place...
systemctl: error while loading shared libraries: libcrypto.so.3: cannot 
open shared object file: No such file or directory
dpkg: erreur de traitement de l'archive 
/tmp/apt-dpkg-install-klPmRf/5-postgresql-16_16.3-1_amd64.deb (--unpack) :
 le sous-processus nouveau postgresql-16 paquet pre-removal script a 
renvoyé un état de sortie d'erreur 127

Des erreurs ont été rencontrées pendant l'exécution :
 /tmp/apt-dpkg-install-klPmRf/5-postgresql-16_16.3-1_amd64.deb
Erreur : Le délai d’attente est dépassé
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

"

Bug#1071450: capsh.1: Some remarks and editorial changes for this man page

[Bjarni Ingi Gislason]

Package: libcap2-bin
Version: 1:2.66-5
Severity: minor
Tags: patch

Dear Maintainer,

  here are some notes and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint capsh.1": (possibly shortened list)

mandoc: capsh.1:34:7: WARNING: undefined escape, printing literally: \+
mandoc: capsh.1:54:6: WARNING: undefined escape, printing literally: \+

-.-.


Use the correct macro for the font change of a single argument or
split the argument into two.

247:.BI \-\-strict

-.-.

Use a macro to change to the italic font, instead of \fI, if
possible (see man-pages(7)).
The macros have the italic corrections, but "\c" removes the "\/" part,
which is in the macro.
So "\/" must be added between the italic argument and the "\c" string.

  Or

add the italic corrections.

6:[\fIOPTION\fR]...
240:\fIcap_xxx\fP, one can provide a decimal number and \fBcapsh\fP will
257:\fBcapsh\fP, and display all descriptions that include \fIphrase\fP.
320:The text conventions used for \fIxxx\fP are those of

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

N.B

  The number of lines affected is too large to be in the patch.

9:this tool. This tool provides a handy wrapper for certain types
10:of capability testing and environment creation. It also provides some
15:order they are provided. They are as follows:
30:with trailing arguments. Note, you can use
35:Uses \fBcap_launch\fP(3) to fork a child to execute the shell. When
42:again with the remaining arguments. Useful for testing
44:behavior. Note, PATH is searched when the running
46:was found via the shell's PATH searching. If the
51:as that running initially. This behavior is an intended feature as it
56:\fBcapsh\fP. When this child exits, \fBcapsh\fP exits with the status
69:Remove the listed capabilities from the prevailing bounding set. The
73:function. Use of this feature requires that
81:equal those provided in the comma separated list. For this action to
91:Assume the identity of the named user. That is, look up the user's
113:security mode. This is a set of securebits and prevailing capability
132:system call. This argument may require explicit preparation of the
138:function to set the UID of the current process. This performs all
140:process. Following this command the prevailing effective capabilities
163:Set the supplementary groups to the numerical list provided. The
166:system call. See
172:to the super-user. However, it is normally the case that when the
175:to some lesser user, then capabilities are dropped. For these
179:system call. This feature is known as
181:support. The way to activate it using this program is with this
182:argument. Setting the value to 1 will cause
184:to be active. Setting it to 0 will cause keep-caps to deactivate for
185:the current process. In all cases,
189:is performed. See
201:header file. The program will list these bits via the
221:seconds. The child will sleep that long and then exit with status
222:0. The purpose of this command is to support exploring the way
223:processes are killable in the face of capability changes. See the
225:command. Only one fork can be active at a time.
232:with the specified signal. The command then waits for the child to exit.
239:capability makes available to a running program. Note, instead of
249:\fB\-\-caps=\fP and \fB\-\-inh=\fP arguments. That is, when the
252:in the Permitted set. The strict mode defaults to off. Supplying this
260:This is a convenience feature. If you look at
282:As the kernel evolves, more capabilities are added. This option can be used
283:to verify the existence of a capability on the system. For example,

Bug#1071449: bookworm-pu: package sendmail/8.17.1.9-2+deb12u1

[Bastien Roucariès]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: sendm...@packages.debian.org
Control: affects -1 + src:sendmail
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
sendmail was affected by CVE-2023-51765

[ Impact ]
close CVE-2023-51765 and reject NUL mail

[ Tests ]
CVE-2023-51765 fix was tested manually and cross checked

[ Risks ]
Code is complex and rejecting NUL is slighly RFC non conformant

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Fix CVE-2023-51765 (Closes: #1059386):
sendmail allowed SMTP smuggling in certain configurations.
Remote attackers can use a published exploitation
technique to inject e-mail messages with a spoofed
MAIL FROM address, allowing bypass of an SPF protection
mechanism. This occurs because sendmail supports
. but some other popular e-mail servers
do not. This is resolved with 'o' in srv_features.
  * Enable _FFR_REJECT_NUL_BYTE for rejecting mail that
include NUL byte
  * By default enable rejecting mail that include NUL byte.
set confREJECT_NUL to 'true' by default .
User could disable by setting confREJECT_NUL to false.
(Closes: #1070190). Close a variant of CVE-2023-51765
aka SMTP smuggling.


[ Other info ]
No regression bugs in sid/trixie since at least two week
diff -Nru sendmail-8.17.1.9/debian/cf/ostype/debian.m4.in sendmail-8.17.1.9/debian/cf/ostype/debian.m4.in
--- sendmail-8.17.1.9/debian/cf/ostype/debian.m4.in	2023-01-11 22:26:28.0 +
+++ sendmail-8.17.1.9/debian/cf/ostype/debian.m4.in	2024-05-13 18:44:56.0 +
@@ -65,6 +65,9 @@
 dnl #
 define(`confDEF_USER_ID', `mail:mail')dnl
 dnl #
+ifelse(eval(index(sm_ffr, `-D_FFR_REJECT_NUL_BYTE') >= 0), `1',dnl
+`define(`confREJECT_NUL',`true')')dnl
+dnl #
 dnl #-
 dnl # mailer paths and options
 dnl #-
diff -Nru sendmail-8.17.1.9/debian/changelog sendmail-8.17.1.9/debian/changelog
--- sendmail-8.17.1.9/debian/changelog	2023-01-11 22:26:28.0 +
+++ sendmail-8.17.1.9/debian/changelog	2024-05-13 18:44:56.0 +
@@ -1,3 +1,24 @@
+sendmail (8.17.1.9-2+deb12u1) bookworm-security; urgency=high
+
+  * QA upload
+  * Fix CVE-2023-51765 (Closes: #1059386):
+sendmail allowed SMTP smuggling in certain configurations.
+Remote attackers can use a published exploitation
+technique to inject e-mail messages with a spoofed
+MAIL FROM address, allowing bypass of an SPF protection
+mechanism. This occurs because sendmail supports
+. but some other popular e-mail servers
+do not. This is resolved with 'o' in srv_features.
+  * Enable _FFR_REJECT_NUL_BYTE for rejecting mail that
+include NUL byte
+  * By default enable rejecting mail that include NUL byte.
+set confREJECT_NUL to 'true' by default .
+User could disable by setting confREJECT_NUL to false.
+(Closes: #1070190). Close a variant of CVE-2023-51765
+aka SMTP smuggling.
+
+ -- Bastien Roucari??s   Mon, 13 May 2024 18:44:56 +
+
 sendmail (8.17.1.9-2) unstable; urgency=medium
 
   * QA upload.
diff -Nru sendmail-8.17.1.9/debian/configure.ac sendmail-8.17.1.9/debian/configure.ac
--- sendmail-8.17.1.9/debian/configure.ac	2023-01-11 22:26:28.0 +
+++ sendmail-8.17.1.9/debian/configure.ac	2024-05-13 18:44:56.0 +
@@ -466,6 +466,7 @@
 sm_envdef="$sm_envdef -DHASFLOCK=1";
 sm_libsm_envdef="$sm_libsm_envdef -DHAVE_NANOSLEEP=1";
 sm_ffr="$sm_ffr -D_FFR_QUEUE_SCHED_DBG"; # %% TESTING 
+sm_ffr="$sm_ffr -D_FFR_REJECT_NUL_BYTE";
 #
 # version specific setup
 if test "$sm_version_major" = "8.17"; then
diff -Nru sendmail-8.17.1.9/debian/NEWS.Debian sendmail-8.17.1.9/debian/NEWS.Debian
--- sendmail-8.17.1.9/debian/NEWS.Debian	1970-01-01 00:00:00.0 +
+++ sendmail-8.17.1.9/debian/NEWS.Debian	2024-05-13 18:44:56.0 +
@@ -0,0 +1,19 @@
+sendmail (8.17.1.9-2+deb12u1) bookworm-security; urgency=medium
+
+  Sendmail was affected by SMTP smurgling (CVE-2023-51765).
+  Remote attackers can use a published exploitation technique
+  to inject e-mail messages with a spoofed MAIL FROM address,
+  allowing bypass of an SPF protection mechanism.
+  This occurs because sendmail supports some combinaison of
+  .
+  .
+  This particular injection vulnerability has been closed,
+  unfortunatly full closure need to reject mail that
+  contain NUL.
+  .
+  This is slighly non conformant with RFC and could
+  be opt-out by setting confREJECT_NUL to 'false'
+  in sendmail.mc file.
+
+ -- Bastien Roucari??s   Sun, 12 May 2024 19:38:09 +
+
diff -Nru sendmail-8.17.1.9/debian/patches/0024-CVE-2023-51765.patch sendmail-8.17.1.9/debian/patches/0024-CVE-2023-51765.patch

Bug#1071448: dipy: FTBFS on 32 bit archs with ArrayMemoryError

[Timo Röhling]

Source: dipy
Version: 1.9.0-2
Severity: serious
Tags: ftbfs
User: debian-rele...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package does not build on armhf, armel, and i386 because one tests 
allocates a rather large array (which fails on the buildd machines):


  >   data = 255 * rng.random((197, 233, 189, 15))
  E   numpy.core._exceptions._ArrayMemoryError: Unable to allocate 993. 
  MiB for an array with shape (197, 233, 189, 15) and data type float64


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZKAkUACgkQzIxr3RQD
9Moqnw//QjkAG+RG9VH78jKUefxRe2eNmmH/zSChSdTAMzit4UrY/TcFgP1H/nIF
ZhbsjlDPNvu3Wxsf7zLORHgN+trRV69Na3RLECKqxb+ImHIShMZKPd3IYKcKRPC/
XysUUGozWSixnNiD+PfhK8Eo2kh4odpwz9WiygAy0cH0oVGP+S6z6y7/BkKDjrxE
45aVDrCCDcbjsSoXOrGh6AIEYQxQ27sxoLptU+M2fS1WMd+TWmnQ3J4rJSf/0psa
SetJ2Vm87kdgfIvPLjYY7XmFJ6dTcalt54Z0KTLQfBb0fO81THPDKm5AJX0dtimy
QMCSDQYh9j+HO5LmhR3y4bswf3jxrDDCeOQ21QXln+UVG/q+nDjtQIwWyA6cj6za
V9T2ERS5e+eMK13VkxVHLE3SEy/bwhoctj271m2370pLI6guYeLMO5bMdoeikyFg
voH3peV08RWz22wOfymX3DK8DmcwWUDcQf8BVIv5MAv8mWVVaqzUnn5pt4o4h5aL
Ul9WgFaGoCLi+Sp0VSIsFzQEzrO4hWRB+RaDeaAklRHTeAdSjg+/9959j36ZwkIy
A2bDtVWtAEhYEuNj3LUUjzs0OR8gu4uTdt6Tjpb0HM2jSL3CyiIddLs+tw1Fe7ev
GweUn20QAa3HF40GfWXaUS75pwap2BpyG5IQcyjWtD7W7ihDIbY=
=SYkm
-END PGP SIGNATURE-

Bug#1071446: keepalived diff

[Michal Arbet]

Adding diff for package build

Thanks
Michal Arbet
Openstack Engineer

Ultimum Technologies a.s.
Na Poříčí 1047/26, 11000 Praha 1
Czech Republic

+420 604 228 897
michal.ar...@ultimum.io
*https://ultimum.io *

LinkedIn  | Twitter
 | Facebook

diff --git a/debian/changelog b/debian/changelog
index be91689..7c4d164 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+keepalived (1:2.2.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add --enable-log-file to configure
+
+ -- Michal Arbet   Thu, 16 May 2024 13:15:59 +0200
+
 keepalived (1:2.2.8-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/rules b/debian/rules
index 06f3bd6..11eeddb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,7 +7,7 @@
dh  $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-snmp --enable-sha1 --enable-snmp-rfcv2 --enable-snmp-rfcv3 --enable-dbus --enable-json --enable-bfd --enable-regex --with-init=systemd
+   dh_auto_configure -- --enable-snmp --enable-sha1 --enable-snmp-rfcv2 --enable-snmp-rfcv3 --enable-dbus --enable-json --enable-bfd --enable-regex --enable-log-file --with-init=systemd
 
 
 override_dh_auto_install:

Bug#1071447: iproute2: IPv6 route in VRF context fails with 'Invalid source address' due to default VRF check.

[Tharyrok]

Package: iproute2
X-Debbugs-Cc: d...@tharyrok.eu
Version: 6.9.0-1
Severity: normal
Tags: ipv6

Dear Maintainer,

I am encountering an issue when adding an IPv6 route within a VRF 
context on Debian using ifupdown2. The problem occurs when I attempt to 
add an unreachable default route with a specific source address. I 
receive an "Invalid source address" error. However, this issue does not 
occur with IPv4 routes under similar conditions.


/etc/network/interfaces Configuration:
auto routing
iface routing
     address 127.0.0.1/8
     address ::1/128
     vrf-table 1011

auto dummy0
iface dummy0
     link-type dummy
     pre-up /usr/sbin/ip link add dummy0 type dummy
     post-down /usr/sbin/ip link del dummy0 type dummy
     address 169.254.0.10/32
     address fd6c:3502:f677::10/128
     vrf routing

Steps to Reproduce:
1. Add the IPv6 route in the VRF context: ip -6 route add unreachable 
default src fd6c:3502:f677::10 vrf routing

    Result: Error: Invalid source address.

2. Add the IPv4 route in the VRF context: ip route add unreachable 
default src 169.254.0.10 vrf routing

    Result: No error, and the routing table is updated correctly:

    # ip route show vrf routing
    unreachable default src 169.254.0.10
    127.0.0.0/8 dev routing proto kernel scope link src 127.0.0.1

3. Adding another dummy interface not in the VRF context:
    auto dummy1
    iface dummy1
    link-type dummy
    pre-up /usr/sbin/ip link add dummy1 type dummy
    post-down /usr/sbin/ip link del dummy1 type dummy
    address fd6c:3502:f677::10/128

4. Retry adding the IPv6 route in the VRF context: ip -6 route add 
unreachable default src fd6c:3502:f677::10 vrf routing

    Result: No error, and the routing table is updated correctly:

    # ip -6 route show vrf routing
    ::1 dev routing proto kernel metric 256 pref medium
    fd6c:3502:f677::10 dev dummy0 proto kernel metric 256 pref medium
    fe80::/64 dev dummy0 proto kernel metric 256 pref medium
    multicast ff00::/8 dev dummy0 proto kernel metric 256 pref medium
    unreachable default dev lo src fd6c:3502:f677::10 metric 1024 pref 
medium


The issue seems to be related to the source address check being 
performed in the default VRF context instead of the specified VRF 
context when adding an IPv6 route. This behavior is inconsistent with 
the IPv4 routing behavior in a VRF context.


Please let me know if further information is required or if there are 
any patches or tests I can perform to assist in resolving this issue.


Best regards,
Tharyrok

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

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

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.86
ii  libbpf1    1:1.4.1-1
ii  libc6  2.38-11
ii  libcap2    1:2.66-5
ii  libcap2-bin    1:2.66-5
ii  libdb5.3t64    5.3.28+dfsg2-7
ii  libelf1t64 0.191-1+b1
ii  libmnl0    1.0.5-2+b1
ii  libselinux1    3.5-2+b2
ii  libtirpc3t64   1.3.4+ds-1.3
ii  libxtables12   1.8.10-3

iproute2 recommends no packages.

Versions of packages iproute2 suggests:
ii  python3  3.11.8-1

-- debconf information:
   iproute2/setcaps: false


OpenPGP_0xE3739989CBBA86C4.asc
Description: OpenPGP public key

Bug#985478: [PATCH] options: Always reset OPTIND in getoptsreset

[Harald van Dijk]

On 19/05/2024 12:19, Herbert Xu wrote:

On Wed, Jan 04, 2023 at 04:50:34PM +, Harald van Dijk wrote:


Personally, I do think it is better if shells allow assigning arbitrary
values to OPTIND, including unsetting it, and only have the getopts command
raise an error if the value is non-numeric, but that is my personal opinion
and I don't see much of a problem if dash decides to go the other way,
unless POSIX makes it explicit that it is not permitted for shells to do
this. FWIW, I did make that change for my version, 
,
if that change is desired for dash it is easy to apply.


I've decided to make getoptsreset always do the reset, regardless
of the value of OPTIND.  Why else would you assign it anyway?


This interacts terribly with the not fully reliable but nevertheless 
fairly commonly used "local OPTIND". When the local OPTIND goes out of 
scope and the prior value of OPTIND is restored, the expectation is not 
that option processing restarts from the beginning.


Cheers,
Harald van Dijk

Bug#1071446: keepalived's log-file option not working

[Michal Arbet]

Package: keepalived
Version: 1:2.2.8-1
Severity: normal
X-Debbugs-Cc: michal.ar...@ultimum.io

Dear Maintainer,

Keepalived has --log-file option to allow log to the file.
This option is not available in debian package because it's
built without this option (dh_autoconfigure without --enable-log-file)
and reason is that in past there was a CVE-2018-19046 reported.

But it seems it's  now resolved as below:

https://github.com/acassen/keepalived/issues/1048

Commits fixing the original issue:

https://github.com/acassen/keepalived/commit/ac8e2ef053de273ce7a0cf0cb611e599dca4b298
https://github.com/acassen/keepalived/commit/26c8d6374db33bcfcdcd758b1282f12ceef4b94f
https://github.com/acassen/keepalived/commit/17f944144b3d9c5131569b1cc988cc90fd676671

So I think --enable-log-file can be added to configure now.

Thanks,
Michal Arbet (kevko)



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

Kernel: Linux 6.1.0-18-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages keepalived depends on:
ii  init-system-helpers  1.65.2
ii  iproute2 6.1.0-3
ii  libc62.36-9+deb12u4
ii  libglib2.0-0 2.74.6-2
ii  libmnl0  1.0.4-3
ii  libnftnl11   1.2.4-2
ii  libnl-3-200  3.7.0-0.2+b1
ii  libnl-genl-3-200 3.7.0-0.2+b1
ii  libpcre2-8-0 10.42-1
pn  libsnmp40
ii  libssl3  3.0.11-1~deb12u2
ii  libsystemd0  252.22-1~deb12u1

Versions of packages keepalived recommends:
pn  ipvsadm  

keepalived suggests no packages.

Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition

[Salvatore Bonaccorso]

Control: reassign -1 src:systemd

On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote:
> Package: src:linux
> Version: 6.8.9-1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device 
> fails
> to mount the root partition. I just tried the kernel from sid and it seems 
> indeed \
> affected. The 6.7 kernel from trixie is instead booting fine even after
> regenerating all initrds.
> 
> According to bl...@debian.org, this is likely due to
> https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66
> 
> See https://lwn.net/Articles/973997/

The deprecation was there for a while indeed and dropped by upstream
for 6.8-rc1. But it looks systemd is adressing this with

https://github.com/systemd/systemd/commit/e3828d7103a99a15a1e947ba3063294ead590631

As we wont apply a local Debian patch unless upstream Linux decides to
facilitate this by adding a noop option back, then I think it's best
to reassign this bug to systemd and close it once the above change is
applied.

Regards,
Salvatore

Bug#1070683: should work with systemd socket activation

[Andreas B. Mundt]

Control: severity -1 wishlist

Hi Tomas,

atftpd should work with both IP versions already when using the
default Debian installation with systemd socket activation.  I
hesitate to apply your patch right now, as I am not that familiar with
the code:  For example, AF_INET is used at other places in the code
too.

Best regards,

  Andi

Bug#935923: libmodbus: FTBFS on hppa - unit-test-server: no process found

[Helge Deller]

I did some analysis, and this bug was quite interesting...
Patch which fixes it (and probably armel too) is below.

a) The "unit-test-server: no process found" error is misleading.
It does not indicate that the server or client test program did
not start, but it just means the "killall" program in the unit-tests.sh
shell script could not find the "unit-test-server" process any longer
(which is correct, since it executed and exited quite fine).
The patch below pipes errors of killall to /dev/null to avoid it.

b)
The main problem, is the timeout of 7ms in unit-test-client.c around
line 681.
On SMP parisc machines where more than one CPU is running, the internal
timers are not as fine-grained as on single-CPU machines, or as x86
machines. That leads that it's not guaranteed, that chars gets delivered
in a 2ms boundary timeframe (7ms total - 5ms wait time = 2ms delivery time max).
I increased the timeout to 15ms, and now the tests succeed.


Can you please include the patch below and bring it upstream?

Thanks,
Helge


diff -up ./tests/unit-test-client.c.org ./tests/unit-test-client.c
--- ./tests/unit-test-client.c.org  2024-05-19 12:40:47.23200 +
+++ ./tests/unit-test-client.c  2024-05-19 12:43:34.64400 +
@@ -679,11 +679,12 @@ int main(int argc, char *argv[])
 usleep(11 * 5000);
 modbus_flush(ctx);
 
-/* Timeout of 7ms between bytes */
-modbus_set_byte_timeout(ctx, 0, 7000);
+/* Timeout of 15ms between bytes (allow slow machines or machines
+  with unreliable SMP timers to succeed) */
+modbus_set_byte_timeout(ctx, 0, 15000);
 rc = modbus_read_registers(
 ctx, UT_REGISTERS_ADDRESS_BYTE_SLEEP_5_MS, 1, tab_rp_registers);
-printf("2/2 Adapted byte timeout (7ms > 5ms): ");
+printf("2/2 Adapted byte timeout (15ms > 5ms): ");
 ASSERT_TRUE(rc == 1, "");
 }
 
diff -up ./tests/unit-tests.sh.org ./tests/unit-tests.sh
--- ./tests/unit-tests.sh.org   2024-05-19 12:39:00.57200 +
+++ ./tests/unit-tests.sh   2024-05-19 12:39:22.90400 +
@@ -14,6 +14,6 @@ echo "Starting client"
 ./unit-test-client > $client_log 2>&1
 rc=$?
 
-killall unit-test-server
+killall unit-test-server 2>/dev/null
 exit $rc
 

Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)

[陈 晟祺]

Hi,

> 2024年5月19日 13:51，Paul Gevers  写道：
> 
> I already noticed yesterday and had it run; it failed. (Currently) top one 
> here: https://ci.debian.net/packages/z/zfs-linux/testing/amd64/
> 

My concern now is that the results do not seem to be stable or reproducible.

Seven tests have been run since yesterday, of which two failed on 
zfs-test-suite-foo.
Most of these failures may be false positive, and a re-run typically makes them 
pass.
Almost every single test in the failed list can pass independently, but the 
whole test
sequence is failure-prone. 

I have also observed similar behavior when testing locally (and also in 
upstream CI).
Is there any convention in handling such situation? E.g., should I mark all 
zfs-test-suite-x
as flaky and treat them as reference only?

Thanks,
Shengqi Chen

Bug#1045435: mozc: Fails to build source after successful build

[Kentaro HAYASHI]

Control: tags -1 patch

Hi, I've attached the patch to fix double build.

* 0001-Fix-source-after-successful-build.patch

Regards,


On Sun, 13 Aug 2023 21:21:00 +0200 Lucas Nussbaum
 wrote:
> Source: mozc
> Version: 2.28.4715.102+dfsg-2.2
> Severity: minor
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-sab-20230813 ftbfs-source-after-build
> User: debian...@lists.debian.org
> Usertags: qa-doublebuild
> 
>From 987fc8f5ffe6a9bb2f9d163b557db67b0180d655 Mon Sep 17 00:00:00 2001
From: Kentaro Hayashi 
Date: Sun, 19 May 2024 21:49:36 +0900
Subject: [PATCH] Fix source after successful build

Closes: #1045435

Use extend-diff-ignore to ignore "binary file contents changed"
error with src/unix/fcitx5/po/*.mo.

Signed-off-by: Kentaro Hayashi 
---
 debian/rules  | 1 +
 debian/source/options | 2 ++
 2 files changed, 3 insertions(+)
 create mode 100644 debian/source/options

diff --git a/debian/rules b/debian/rules
index 24402713..b0738aed 100755
--- a/debian/rules
+++ b/debian/rules
@@ -80,6 +80,7 @@ override_dh_auto_clean:
 	-rm -rf src/chrome/skk/skk_util_test.target.mk
 
 	-rm -f src/unix/fcitx5/org.fcitx.Fcitx5.Addon.Mozc.metainfo.xml
+	-rm -rf src/out_linux*
 	dh_auto_clean
 
 override_dh_auto_install:
diff --git a/debian/source/options b/debian/source/options
new file mode 100644
index ..87cfd41e
--- /dev/null
+++ b/debian/source/options
@@ -0,0 +1,2 @@
+# ignore changes on src/unix/fcitx5/po/*.mo
+extend-diff-ignore = ".+\.mo$"
-- 
2.43.0

Bug#1071445: ITP: python-ulid-transform -- Fast ULID transformations

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-ulid-transform
  Version : 0.9.0
  Upstream Author : J. Nick Koston 
* URL : https://github.com/bdraco/ulid-transform
* License : MIT
  Programming Lang: Python
  Description : Fast ULID transformations

  Provides functionalities for creating and transforming ULIDs (Universally
  Unique Lexicographically Sortable Identifiers). Utilises a Cython-based
  implementation for optimal performance, with a fallback to pure Python if
  Cython is unavailable.
  .
  Example usage:
  .
   >>> import ulid_transform
   >>> ulid_transform.ulid_hex()
   '01869a2ea5fb0b43aa056293e47c0a35'
   >>> ulid_transform.ulid_now()
   '0001HZX0NW00GW0X476W5TVBFE'
   >>> ulid_transform.ulid_at_time(1234)
   '00016JC62D620DGYNG2R8H'
   >>> ulid_transform.ulid_to_bytes('0001HZX0NW00GW0X476W5TVBFE')
   b'\x00\x00c\xfe\x82\xbc\x00!\xc0t\x877\x0b\xad\xad\xee'

I plan to maintain this package as part of the Python team.

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

[Julian Gilbey]

Hi Nilesh,

On Sun, May 19, 2024 at 12:27:02PM +0530, Nilesh Patra wrote:
> Julian Gilbey :
> >  I have come across a number of packages with a line in their
> >  debian/rules like:
> >  
> >  ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
> >  
> >  This should be "nodoc", according to the "nodoc" entry in
> >  https://wiki.debian.org/BuildProfileSpec#Registered_profile_names
> >  
> >  It would be good to check for this error.
> 
> This mostly looks like a typo and I am kinda sure that you'd find typos like
> this all over many places. I am a bit unsure if checks for this is something 
> we
> as a new lintian warning is something that we even need?

Perhaps, perhaps not.  It's not something that's easily spotted by
eye unless you're explicitly looking for it.

> Louis-Philippe Véronneau :
> > ...
> > I've created a patch on Salsa that creates a new Lintian check for this.
> > 
> > https://salsa.debian.org/lintian/lintian/-/merge_requests/504
> 
> And if we do --  I checked the MR and it does not look extensible. If in
> future there comes another class of typos, it will result in a new patch of 
> this
> kind. Instead, is it possible to have a list of offending terms like this in a
> data list and warn the user about them via a lintian warning?
> 
> For instance, we have data/fields/obsolete-packages for listing obsolete
> packages and showing the user about the obsolete packages and their
> replacements. Do you think a similar implementation for this
> (data/fields/bad-buildprofiles ?) makes sense?

Now *that's* a really nice approach.  But here I'd suggest doing the
opposite: checking for valid build options (and note: this is a check
for DEB_BUILD_OPTIONS, not for DEB_BUILD_PROFILES).  There is a very
short list of standard build options: those listed in
dpkg-buildpackage(1) (parallel=n, nocheck, noopt, nostrip, terse,
hardening=..., reproducible=..., abi=..., future=..., qa=...,
optimize=..., sanitize=...) and
https://wiki.debian.org/BuildProfileSpec: nodoc

Best wishes,

   Julian

Bug#1071444: ITP: python-fnvhash -- Pure Python FNV hash implementation

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-fnvhash
  Version : 0.1.0
  Upstream Author : Lorenz Schori 
* URL : https://github.com/znerol/py-fnvhash
* License : MIT
  Programming Lang: Python
  Description : Pure Python FNV hash implementation

  Pure Python implementation of the FNV (Fowler-Noll-Vo) hash family. Offers
  100% test coverage and is suitable for applications where portability is
  more important than performance.
  .
  FNV is a non-cryptographic hash function that is fast and has excellent
  dispersion, making it suitable for hash tables and checksums.
  .
  Example usage:
  .
   >>> from fnvhash import fnv1a_32
   >>> hex(fnv1a_32(b'foo'))
   '0xa9f37ed7'

I plan to maintain this package as part of the Python team.

Bug#1071443: unable to login as root at tty

[Antonio Russo]

Source: selinux-policy-default
Version: 2:2.20221101-9
Severity: normal
X-Debbugs-Cc: aeru...@aerusso.net

Dear Maintainer,

On a fresh bookworm installation, I have enabled selinux following [1]. I 
enabled
enforcing mode, and tried to log in at the console tty (tty1, tty2, and tty6).
journalctl -f shows an authentication error.

Moreover, audit2why -al indicated that agetty was being denied when trying to
use checkpoint_restore.  I used audit2allow -m local to create a policy and
then compile and load it.  This eliminated the selinux denial audit event, but
did not change the overall behavior: I cannot login as root at any ttys.

I can, however, log in as regular user, and use su to elevate to root 
privileges,
though.  Creating a /etc/securetty file with tty0-tty6 and console does not
change the situation.  I've tried relabeling the filesystem several times.

The remaining audit2why -al all seem innocuous:
NetworkManager, run-parts, utmp, apcupds, ModemManager, wall

The only possibly suspect one is comm="(spawn)" accessing files under /proc
(scontext=system_u:system_r:udev_t:s0), thought I would think that's not
a problem.

I'm at a loss for what could be different between enforcing and permissive
mode, and I'm not even sure what logs to look at.

Best,
Antonio


[1] https://wiki.debian.org/SELinux/Setup

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071442: ITP: python-async-interrupt -- Interrupt context manager for asyncio

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-async-interrupt
  Version : 1.1.1
  Upstream Author : J. Nick Koston 
* URL : https://github.com/bdraco/async_interrupt
* License : Apache-2.0
  Programming Lang: Python
  Description : Interrupt context manager for asyncio

  This Python module provides a context manager that can be used to interrupt
  a block of code as soon as possible when a future is done.
  .
  The purpose of async_interrupt is to raise an exception as soon as possible
  to avoid any race conditions. It is based loosely on async_timeout by Andrew
  Svetlov and cpython asyncio.timeout.
  .
  Usage:
  .
   async with interrupt(future, ValueError, "message"):
   future.set_result(None)
   await asyncio.sleep(0)
  .
  This package is useful in scenarios where an exception needs to be raised
  immediately to prevent race conditions during asynchronous operations.

I plan to maintain this package as part of the Python team.

Bug#1038937: nq package out of date with upstream, 0.5 was released more than a year ago

[Preuße]

Control: block -1 by 1005961

On 03.05.2024 21:47, Christoph Biedl wrote:

Hi,


nq 0.5 was released March 26, 2022 and contains several bug fixes and 
improvements.
nq 0.3.1 was released March 7, 2018, and is what is in all of stable, testing, 
and unstable.
Please update this package.


Upon request by upstream and following the statements given in
,
also there's the LowNMU flag ... I'll upload 0.5-0.1 in the next days.
To improve quality and as it was a no-brainer, I'll also add an autopkgtest.

I took over the task to do an NMU. The RFS bug is open, unfortunately 
#1005961 needs to solved first.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#985478: [PATCH] options: Always reset OPTIND in getoptsreset

[Herbert Xu]

On Wed, Jan 04, 2023 at 04:50:34PM +, Harald van Dijk wrote:
>
> Personally, I do think it is better if shells allow assigning arbitrary
> values to OPTIND, including unsetting it, and only have the getopts command
> raise an error if the value is non-numeric, but that is my personal opinion
> and I don't see much of a problem if dash decides to go the other way,
> unless POSIX makes it explicit that it is not permitted for shells to do
> this. FWIW, I did make that change for my version, 
> ,
> if that change is desired for dash it is easy to apply.

I've decided to make getoptsreset always do the reset, regardless
of the value of OPTIND.  Why else would you assign it anyway?

---8<---
Always reset OPTIND if it is modified by the user, regardless of
its value.

Reported-by: наб 
Signed-off-by: Herbert Xu 

diff --git a/src/options.c b/src/options.c
index 4d0a53a..c74e4fe 100644
--- a/src/options.c
+++ b/src/options.c
@@ -393,7 +393,7 @@ setcmd(int argc, char **argv)
 
 void getoptsreset(const char *value)
 {
-   shellparam.optind = number(value) ?: 1;
+   shellparam.optind = 1;
shellparam.optoff = -1;
 }
 
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#1057407: texworks: Intent to drop poppler-qt6 on i386

[Preuße]

On 04.12.2023 14:43, Jeremy Bícha wrote:

Hi Jeremy,


As the maintainer of Debian's poppler source package, I would like to
drop poppler's Qt6 packages on i386.


I just uploaded texworks 0.6.9 and for i386 the status on the buildd is

Dependency installability problem for texworks on i386:

texworks build-depends on:
- libpoppler-qt6-dev:i386
libpoppler-qt6-dev depends on missing:
- libpoppler-dev:i386 (= 24.02.0-4)

So, texworks won't be built for i386 and won't be available for unstable 
and testing. Is that OK, can we close that bug now?


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071441: sway: can't launch x11 apps on vmware virtualmachine

[Christophe LELOUP]

Package: sway
Version: 1.9-1+b1
Severity: important
X-Debbugs-Cc: leloup.christophe+poube...@gmail.com

Dear Maintainer,

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

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

   i launch xeyes

   * What was the outcome of this action?

   sway crash

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 sway depends on:
ii  libc62.38-11
ii  libcairo21.18.0-3+b1
ii  libevdev21.13.1+dfsg-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-1
ii  libgl1-mesa-dri  24.0.7-1
ii  libglib2.0-0t64  2.80.2-1
ii  libinput10   1.25.0-1+b2
ii  libjson-c5   0.17-1+b1
ii  libpango-1.0-0   1.52.2+ds-1
ii  libpangocairo-1.0-0  1.52.2+ds-1
ii  libpcre2-8-0 10.42-4+b1
ii  libpixman-1-00.42.2-1+b1
ii  libsystemd0  255.5-1
ii  libudev1 255.5-1
ii  libwayland-client0   1.22.0-2.1+b1
ii  libwayland-cursor0   1.22.0-2.1+b1
ii  libwayland-server0   1.22.0-2.1+b1
ii  libwlroots12t64  0.17.1-2.1
ii  libxcb-icccm40.4.1-1.1+b1
ii  libxcb1  1.15-1
ii  libxkbcommon01.6.0-1+b1
ii  polkitd  124-2
ii  swaybg   1.2.1-1

Versions of packages sway recommends:
ii  foot  1.17.2-2
ii  sway-backgrounds  1.9-1
ii  wmenu 0.1.7-1

Versions of packages sway suggests:
pn  swayidle
pn  swaylock
pn  xdg-desktop-portal-gtk  
pn  xdg-desktop-portal-wlr  

-- no debconf information

Bug#1071440: inkscape: crash on create a new file

[Damir R. Islamov]

Package: inkscape
Version: 1.3+ds-1+b1
Severity: normal

Dear Maintainer,

Inkscape crashes on creating a new file.
Info in below.


 0# Inkscape::Application::crash_handler(int) in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so.1.3.0.0
 1# 0x7F0D25E58580 in /lib/x86_64-linux-gnu/libc.so.6
 2# 0x7F0D25700EC9 in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0
 3# 0x7F0D257018B1 in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0
 4# g_dbus_connection_register_object in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0
 5# g_dbus_connection_export_menu_model in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0
 6# 0x7F0D1F0919C2 in 
/usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so
 7# Gtk::Widget_Class::realize_callback(_GtkWidget*) in 
/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
 8# g_closure_invoke in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
 9# 0x7F0D255D79C0 in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
10# 0x7F0D255D9281 in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
11# g_signal_emit_valist in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
12# g_signal_emit in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
13# gtk_widget_realize in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgtk-3.so.0
14# InkscapeWindow::setup_view() in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so.1.3.0.0
15# InkscapeWindow::InkscapeWindow(SPDocument*) in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so.1.3.0.0
16# InkscapeApplication::window_open(SPDocument*) in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so.1.3.0.0
17# InkscapeApplication::create_window(SPDocument*, bool) in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so.1.3.0.0
18# InkscapeApplication::process_document(SPDocument*, 
std::__cxx11::basic_string, std::allocator 
>) in /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so.1.3.0.0
19# InkscapeApplication::on_activate() in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so.1.3.0.0
20# Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) in 
/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
21# g_closure_invoke in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
22# 0x7F0D255D7BE9 in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
23# 0x7F0D255D9281 in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
24# g_signal_emit_valist in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
25# g_signal_emit in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
26# 0x7F0D256F5290 in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0
27# g_application_run in 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0
28# main in /usr/bin/inkscape
29# __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:74
30# __libc_start_main at ../csu/libc-start.c:347
31# _start in /usr/bin/inkscape

System info
Inkscape 1.3 (0e150ed6c4, 2023-07-21)

GLib version: 2.80.2
GTK version:  3.24.41
glibmm version:   2.66.7
gtkmm version:3.24.9
libxml2 version:  2.9.14
libxslt version:  1.1.35
Cairo version:1.18.0
Pango version:1.52.2
HarfBuzz version: 8.3.0

OS version:   Debian GNU/Linux trixie/sid



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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 inkscape depends on:
ii  lib2geom1.3.0  1.3-2
ii  libatkmm-1.6-1v5   2.28.4-1+b1
ii  libboost-filesystem1.83.0  1.83.0-2.1+b1
ii  libc6  2.38-11
ii  libcairo-gobject2  1.18.0-3+b1
ii  libcairo2  1.18.0-3+b1
ii  libcairomm-1.0-1v5 1.14.5-1
ii  libcdr-0.1-1   0.1.7-1+b1
ii  libepoxy0  1.5.10-1+b2
ii  libfontconfig1 2.15.0-1.1
ii  libfreetype6   2.13.2+dfsg-1+b4
ii  libgc1 1:8.2.6-1
ii  libgcc-s1  14.1.0-1
ii  libgdk-pixbuf-2.0-02.42.12+dfsg-1
ii  libglib2.0-0t64