Bug#866784: Pick up this bug

[Jonas Smedegaard]

Quoting Soren Stoutner via Pkg-voip-maintainers (2023-06-14 02:20:52)
> I would like to try to work to get this bug fixed.  I understand that it a 
> fairly heavy mountain to move and will involve coordination with various 
> upstreams (libsrtp, chromium, qtwebengine) as well as the packagers of those 
> programs, but I have a strong desire to get the Qt WebEngine packages in 
> Debian into good shape and am willing to invest time into this bug to see if 
> an acceptable solution can be found.
> 
> For those who have more experience with the history of this problem, do you 
> have any suggestions as to where I should start?

Thanks for your interest in this issue!

I suggest - as also described in my previous emails here, to try patch
the Qt WebEngine code to get randomness elsewhere, because libsrtp was
not intented to provide that functionality and therefore the removal of
that private interface was deliberate.

Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#1037553: luatex.1: some formatting fixes for the manual

[Bjarni Ingi Gislason]

Package: texlive-binaries
Version: 2022.20220321.62855-5.1
Severity: minor
Tags: patch

Dear Maintainer,

here are some remarks and a fix for some formatting issues in the man
page of luatex(1).

Input file is luatex.1

#

Output from "mandoc  -T lint luatex.1"
mandoc: luatex.1:11:129: STYLE: input text line longer than 80 bytes: luatex, 
dviluatex, l...
mandoc: luatex.1:192:2: WARNING: line scope broken: TP breaks TP

#

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

85:in comparison to the standard web2c programs. The presence of \fB--lua\fR

#

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

104:.BI \-\-luaconly

#

Wrong distance between sentences.

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

  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.

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

47:next word is taken as the \fIFMT\fR to read, overriding all else. Any
83:similar fashion as in traditional pdf\*(TX and Aleph. But if the option
85:in comparison to the standard web2c programs. The presence of \fB--lua\fR
98:Start Lua\*(TX as a Lua interpreter. In this mode, it will set Lua's
101:just like the Lua interpreter. Lua\*(TX will exit immediately after
105:Start Lua\*(TX as a Lua byte compiler. In this mode, Lua\*(TX is exactly

#

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

luatex.1: line 11   length 129
luatex, dviluatex, luahbtex, luajittex, texlua, texluac \- An extended version 
of TeX using Lua as an embedded scripting language

#

Do not use "\s0" but an absolute number, as the size of the string could
be changed.

8:.if t .ds WB W\s-2EB\s0

#

--- luatex.12023-06-14 04:02:56.0 +
+++ luatex.1.new2023-06-14 04:23:51.0 +
@@ -5,10 +5,11 @@
 .if t .ds TX \fRT\\h'-0.1667m'\\v'0.20v'E\\v'-0.20v'\\h'-0.125m'X\fP
 .if n .ds TX TeX
 .if n .ds WB Web
-.if t .ds WB W\s-2EB\s0
+.if t .ds WB W\s-2EB\s+2
 .\"=
 .SH NAME
-luatex, dviluatex, luahbtex, luajittex, texlua, texluac \- An extended version 
of TeX using Lua as an embedded scripting language
+luatex, dviluatex, luahbtex, luajittex, texlua, texluac \- \
+An extended version of TeX using Lua as an embedded scripting language
 .\"=
 .SH SYNOPSIS
 .B luatex
@@ -44,8 +45,9 @@ interpret all non\-option arguments as a
 
 Alternatively, if the first non\-option argument begins with a \fB&\fR,
 the
-next word is taken as the \fIFMT\fR to read, overriding all else. Any
-remaining arguments are processed as above.
+next word is taken as the \fIFMT\fR to read,
+overriding all else.
+Any remaining arguments are processed as above.
 
 If no arguments or options are specified, prompt for input.
 
@@ -68,7 +70,7 @@ the \*(TX engine.
 In \fIPDF\fR mode, Lua\*(TX can natively handle the \fIPDF\fR, \fIJPG\fR,
 \fIJBIG2\fR, and \fIPNG\fR graphics formats.  Lua\*(TX cannot include
 PostScript or Encapsulated PostScript (EPS) graphics files; first convert
-them to PDF using \fBepstopdf\fR (1).
+them to PDF using \fBepstopdf\fR(1).
 
 The luajittex variant includes the Lua just-in-time compiler.
 
@@ -79,11 +81,14 @@ instead of Lua\*(TX's built-in shaper.
 .SH "OPTIONS"
 When the Lua\*(TX executable starts, it looks for the \fB\-\-lua\fR
 command-line option.
-If there is no \fB\-\-lua\fR option, the command line is interpreted in a
-similar fashion as in traditional pdf\*(TX and Aleph. But if the option
-is present, Lua\*(TX will enter an alternative mode of command-line parsing
-in comparison to the standard web2c programs. The presence of \fB--lua\fR
-makes most of other options unreliable, because the lua initialization
+If there is no \fB\-\-lua\fR option,
+the command line is interpreted in a
+similar fashion as in traditional pdf\*(TX and Aleph.
+But if the option is present,
+Lua\*(TX will enter an alternative mode of command-line parsing
+in comparison to the standard web2c programs.
+The presence of \fB\-\-lua\fR makes most of other options unreliable,
+because the lua initialization
 file can disable kpathsea and/or hook functions into various callbacks.
 .ig
 Here is the list of possibly affected switches/functionality, and why:
@@ -95,16 +100,21 @@ The lua initialization file.
 The following two options alter the executable behaviour:
 .TP
 .B \-\-luaonly
-Start Lua\*(TX as a Lua interpreter. 

Bug#1037550: installation-reports: Command /usr/sbin/bootloader-config failed to finish in 600 seconds.

[Chris Turner]

Thank you for the clarification.

On Wed, Jun 14, 2023 at 12:50 PM Cyril Brulebois  wrote:

> Chris Turner  (2023-06-14):
> > I beg your pardon, it was
> >
> >
> https://cdimage.debian.org/cdimage/release/current-live/amd64/iso-hybrid/debian-live-12.0.0-amd64-cinnamon.iso
> >
> > Does that make sense?
>
> That looks much more plausible, yes. :)
>
> As you can see in that directory, live images exist in several variants,
> and it's always best to know exactly which image one is reporting issues
> against (sometimes it doesn't matter which desktop environment is used,
> sometimes this means huge differences at run-time).
>
> Putting back the bug report and the live team in the loop (for further
> reference, using reply-all is best).
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#1037552: manpages: bad code

[Bjarni Ingi Gislason]

Package: docbook-xsl
Version: 1.79.2+dfsg-2
Severity: normal

Dear Maintainer,

  here are some remarks about the creation of man pages with an example
from "valgrind.1".



  Examples of bad formatting codes in the output from

DocBook XSL Stylesheets vsnapshot 

for a man page.

Example file is valgrind.1

Output from "mandoc  -T lint valgrind.1"

mandoc: valgrind.1:36:2: WARNING: skipping paragraph macro: PP after SH
mandoc: valgrind.1:38:304: STYLE: input text line longer than 80 bytes: is a 
flexible progra...

  and more.

###

Lines with \c before lines that contain only '\}'.
Here the '\c' is redundant.

The Code block

.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}

  should be in a macro or this should be enough

.IP \(bu 3m\" adjust width of the indent

#

Remove space characters at the end of lines.

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

838:==15380== 
842:==15380== 
863:==15377== 
868:==15377== 
890:==15363== 
913:==15370== 

#

Mark a full stop (.) with "\&",
if it does not mean an end of a sentence,
that is use ".\&".

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 manuals,
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.

DO NOT PUT "\&" randomly in front of a full stop).  Only when the full
stop is

1) at the start of a line

2) after a space character

that is

sed -e 's/^\./\\\&./' -e '/ \./ \\\&./g'

Similar applies to the single quote ('),
which is a control character in front of a command (request).

52:\fItoolname\fR, e\&.g\&. memcheck, cachegrind, callgrind, helgrind, drd, 
massif, dhat, lackey, none, exp\-bbv, etc\&.
102:\fB\-\-trace\-children\-skip=patt1,patt2,\&.\&.\&. \fR

#

Use a font macro (.I, .B) for a font change if possible.

See man-pages(7).

52:\fItoolname\fR, e\&.g\&. memcheck, cachegrind, callgrind, helgrind, drd, 
massif, dhat, lackey, none, exp\-bbv, etc\&.
88:\fIexec\fR
92:\fIfork\fR
94:\fIfork\fR
96:\fIfork\fR
98:\fIexec\fR
123:\fIfork\fR
125:\fI\-\-trace\-children=\fR\&. Use of this option is also strongly 
recommended if you are requesting XML output (\fI\-\-xml=yes\fR), since 
otherwise the XML from child and parent may become mixed up, which usually 
makes it useless\&.
218:\fIv\&.info open_fds\fR\&. Along with each file descriptor is printed a 
stack backtrace of where the file was opened and any details relating to the 
file descriptor such as the file name or socket details\&. Use
255:\fIFOO\fR\&. If the

#

Use the word "(in)valid" instead of "(il)legal" if not related to legal
matters.
See "www.gnu.org/prep/standards".
Think about translations into other languages!

valgrind.1:442:Enable/disable printing of illegal instruction diagnostics\&. 
Enabled by default, but defaults to disabled when
valgrind.1:446:When enabled, a warning message will be printed, along with some 
diagnostics, whenever an instruction is encountered that Valgrind cannot decode 
or translate, before the program is given a SIGILL signal\&. Often an illegal 
instruction indicates a bug in the program or missing support for the 
particular instruction in Valgrind\&. But some programs do deliberately try to 
execute an instruction that might be missing and trap the SIGILL signal to 
detect processor features\&. Using this flag makes it possible to avoid the 
diagnostic output that you would otherwise get in such cases\&.
valgrind.1:1925:\fIyes\fR, such loads do not produce an address error\&. 
Instead, loaded bytes originating from illegal addresses are marked as 
uninitialised, and those corresponding to legal addresses are handled in the 
normal way\&.
valgrind.1:1928:\fIno\fR, loads from partially invalid addresses are treated 
the same as loads from completely invalid addresses: an illegal\-address error 
is issued, and the resulting bytes are marked as initialised\&.

#

Add a hair space (\^) around "|" to increase readability

85:\fB\-\-trace\-children= [default: no] \fR
120:\fB\-\-child\-silent\-after\-fork= [default: no] \fR
128:\fB\-\-vgdb= [default: yes] \fR
215:\fB\-\-track\-fds= [default: no] \fR

#

Wrong distance between sentences.

APPLIES ALSO TO THE SOURCE FILE.

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

  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.

  The amount of space between sentences in the output can then be

Bug#1028436: transition: re2

[stefanor]

Hi Sebastian (2023.06.13_21:42:46_+)
> Please go ahead with the upload to unstable.

Uploaded, thanks!

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1037551: gnome-control-center: Google account stop working. Not able to re configure it.

[zezamoral]

Package: gnome-control-center
Version: 1:43.4.1-1
Severity: important
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,


   * What led up to the situation?
Google calendar info and files access stop working.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Simply account stop working some days ago and data not available.

   * What was the outcome of this action?
Stop working. Trying to re configuring account not working due the
window freeze after entering your email address and press next.

   * What outcome did you expect instead?
Getting calendar data and files access from nautilus or able to re
settings the online account without the web frame freeze when login the account
in gnome control center.


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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.08.8-6
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-2.2
ii  desktop-base  12.0.6
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:43.4.1-1
ii  gnome-desktop3-data   43.2-2
ii  gnome-settings-daemon 43.0-4
ii  gsettings-desktop-schemas 43.0-1
ii  libaccountsservice0   22.08.8-6
ii  libadwaita-1-01.2.2-1
ii  libc6 2.36-9
ii  libcairo2 1.16.0-7
ii  libcolord-gtk4-1  0.3.0-3.1
ii  libcolord21.4.6-2.2
ii  libcups2  2.4.2-3
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.14.1-4
ii  libgcr-base-3-1   3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-2
ii  libgnome-bg-4-2   43.2-2
ii  libgnome-bluetooth-ui-3.0-13  42.5-3
ii  libgnome-desktop-4-2  43.2-2
ii  libgnome-rr-4-2   43.2-2
ii  libgnutls30   3.7.9-2
ii  libgoa-1.0-0b 3.46.0-1
ii  libgoa-backend-1.0-1  3.46.0-1
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.37-2
ii  libgtk-4-14.8.3+ds-2
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.27-5
ii  libkrb5-3 1.20.1-2
ii  libmalcontent-0-0 0.11.0-4
ii  libmm-glib0   1.20.4-1
ii  libnm01.42.4-1
ii  libnma-gtk4-0 1.10.6-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libpolkit-gobject-1-0 122-3
ii  libpulse-mainloop-glib0   16.1+dfsg1-2+b1
ii  libpulse0 16.1+dfsg1-2+b1
ii  libpwquality1 1.4.5-1+b1
ii  libsecret-1-0 0.20.5-3
ii  libsmbclient  2:4.17.8+dfsg-2
ii  libsnapd-glib-2-1 1.63-5
ii  libudisks2-0  2.9.4-4
ii  libupower-glib3   0.99.20-2
ii  libwacom9 2.6.0-1
ii  libx11-6  2:1.8.4-2
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1.2
ii  webp-pixbuf-loader0.2.1-1

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-5+b1
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.28.1-1
ii  gnome-bluetooth-sendto42.5-3
ii  gnome-online-accounts 3.46.0-1
ii  gnome-remote-desktop  43.3-1
ii  gnome-user-docs   43.0-2
ii  gnome-user-share  43.0-1
ii  iso-codes 4.15.0-1
ii  libcanberra-pulse 0.30-10
ii  libnss-myhostname 252.6-1
ii  libspa-0.2-bluetooth  0.3.65-3
ii  malcontent-gui0.11.0-4
ii  network-manager-gnome 1.30.0-2
ii  polkitd   122-3
ii  power-profiles-daemon 0.12-1+b1
ii  realmd0.17.1-1
ii  rygel 0.42.1-1
ii  rygel-tracker 0.42.1-1
ii  system-config-printer-common  1.5.18-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   43.4-1
ii  gstreamer1.0-pulseaudio  1.22.0-5
ii  pkexec   122-3
ii  x11-xserver-utils7.7+9+b1

-- no debconf information

Bug#1037550: installation-reports: Command /usr/sbin/bootloader-config failed to finish in 600 seconds.

[Cyril Brulebois]

Chris Turner  (2023-06-14):
> I beg your pardon, it was
> 
> https://cdimage.debian.org/cdimage/release/current-live/amd64/iso-hybrid/debian-live-12.0.0-amd64-cinnamon.iso
> 
> Does that make sense?

That looks much more plausible, yes. :)

As you can see in that directory, live images exist in several variants,
and it's always best to know exactly which image one is reporting issues
against (sometimes it doesn't matter which desktop environment is used,
sometimes this means huge differences at run-time).

Putting back the bug report and the live team in the loop (for further
reference, using reply-all is best).


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


signature.asc
Description: PGP signature

Bug#1037522: iptux crashes when receiving a file

[肖盛文]

Hi,

    Thanks for your report.

Could you resize your iptux windows, then close and start iptux again?

Is there /home/cdfrey/.iptux/config.json exist?

Mine is:

cat ~/.iptux/config.json
{
    "main_window_height" : 510,
    "main_window_width" : 250,
    "trans_window_height" : 350,
    "trans_window_width" : 500,
    "version" : 1
}


在 2023/6/14 02:09, Chris Frey 写道:

Package: iptux
Version: 0.7.6-4

I installed iptux for the first time on two systems, one running
Debian Buster (0.7.6-1), the other running Debian Bullseye. (0.7.6-4)

I ran the Buster version in xfce4 from the applications menu.

On Bullseye, I accessed it through an xpra session, and ran iptux
from the command line.


If you don't use xpra, Is this bug reproduce?



I sent a few simple messages back and forth, and then attempted to
send a file from Buster to Bullseye.  The Bullseye version crashed
with this message:

cdfrey:~$ iptux &
[3] 1361101
cdfrey:~$
** (iptux:1361101): WARNING **: 13:56:45.513: config file 
/home/cdfrey/.iptux/config.json not found

(iptux:1361101): GLib-GObject-CRITICAL **: 13:57:28.425: g_object_get_data: 
assertion 'G_IS_OBJECT (object)' failed
Missing chrome or resource URL: resource://gre/modules/UpdateListener.jsm
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
corrupted double-linked list

It's not that important to me, but I figured I'd be a good Debian citizen
and at least report it. :-)

- Chris



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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037163: workrave-gnome: Incompatible with GNOME Shell 44

[Francois Marier]

On 2023-06-06 at 11:33:17, Jeremy Bícha (jeremy.bi...@canonical.com) wrote:
> If this bug is still not fixed, workrave will need to be removed from
> Debian Testing when the Debian GNOME team performs the GNOME Shell 44
> transition which could happen as early as next month. A workaround is
> to temporarily stop building the workrave-gnome binary package from
> the workrave source.

Looks like upstream has a fix:

  
https://github.com/rcaelers/workrave/commit/5fe6e9c0060cae3a4bf1210c92c26b01022ddb1e

I'll wait a bit to see if a new upstream release comes.

Francois

-- 
https://fmarier.org/

Bug#992258: packages.debian.org still not showing bullseye-security packages

[Cyril Brulebois]

Cyril Brulebois  (2023-06-13):
> Let's see if those help:
>   
> https://salsa.debian.org/webmaster-team/packages/-/compare/f673a47d01...4111b73ede

That wasn't sufficient, because of some earlier check/optimization. And
there was another thing that was missed, which would have prevented it
from working anyway.

New attempt:
  
https://salsa.debian.org/webmaster-team/packages/-/compare/cf3a6bc92c...4894715a8a

> As usual, I'm not forcing a refresh right away, and I'll let the next
> mirror pulse trigger reindexing. We should have a better idea in 6-12
> hours.

Still valid.


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


signature.asc
Description: PGP signature

Bug#1037544: emacs-common: CPerl mode: bad coloring when a comment block is used

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64056

This bug is still reproducible with cperl-mode.el from the Git master
branch. So I've also reported it upstream.

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

Bug#1037537: Upgrade To Bookworm Fails with Roundcube Update

[Bryan K. Walton]

On Tue, Jun 13, 2023 at 11:41:48PM +0200, Guilhem Moulin wrote:
> Control: tag -1 unreproducible moreinfo
> 
> On Tue, 13 Jun 2023 at 16:16:51 -0500, Bryan K. Walton via 
> Pkg-roundcube-maintainers wrote:
> > Today, I tried to upgrade my webserver to Debian 12.0 (bookworm).
> > Everything succeeded but Roundcube.
> 
> What was the previous Roundcube (and Debian itself) version?  Please
> also share your roundcube configuration file.  piuparts checks the
> upgrade path of the stock config (for all of DB backends) and that
> appear to be smooth.

Thank you for your reply!

Previous Roundcube version: 1.4.13+dfsg.1-1~deb11u1
Previous Debian version: 11.7

I've attached the Roundcube configuration file, as requested.  Please
note, for privacy reasons, I have replaced the real des_key value with a
series of "#" symbols.  The same applies to the host value in the
default_host setting.

Thanks!
Bryan Walton

Bug#1037550: installation-reports: Command /usr/sbin/bootloader-config failed to finish in 600 seconds.

[Cyril Brulebois]

Hi,

wizardfromoz  (2023-06-14):
> Boot method: USB
> Image version: 
> https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-12.0.0-amd64-DVD-1.iso
> Date: Mon Jun 12 10:36:38 2023

Are you sure about the image you're using?

> Install went fine to 68% then Error Installation Failed - Command 
> /usr/sbin/bootloader-config failed to finish in 600 seconds
> 
> SUGGESTION - extend timeout for bootloader-config from 10 minutes to 60 
> minutes
> 
> Please make sure that any installation logs that you think would
> be useful are attached to this report. (You can find them in the
> installer system in /var/log/ and later on the installed system
> under /var/log/installer.) Please compress large files using gzip.

As far as I can see, bootloader-config is a calamares-specific command,
so is shipped on live images, and not on the installer images. The one
you linked to is about the latter.

Cc-ing debian-live@ as a heads-up.


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


signature.asc
Description: PGP signature

Bug#1037544: emacs-common: CPerl mode: bad coloring when a comment block is used

[Vincent Lefevre]

On 2023-06-14 00:19:58 +0200, Vincent Lefevre wrote:
> When a comment block is used, i.e.
> 
> =begin comment
> 
> [code to comment]
> 
> =end comment
> 
> =cut
> 
> as described in the perlfaq7 man page, everything starting at the
> "=begin comment" line is in the comment color, even the code after
> the "=cut" line (which is no longer commented code).

Well, just after loading a file, coloring seem correct. But after
edition, it can quickly become incorrect.

To reproduce the bug:

1. Create a file with


#!/usr/bin/env perl

foo;

=begin comment

bar;

=end comment

=cut

print "OK\n";


2. Open it with "emacs -Q".
3. M-x cperl-mode
4. Go to the beginning of line "foo;".
5. C-k
6. Go to the beginning of line "bar;".
7. C-y

At step 7, the color of the line

  print "OK\n";

changes to the comment color.

This occurs whether the Emacs X11 interface is used or not.

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

Bug#1036389: sylpheed: notification window displayed as system dialog, not actually not displayed

[Ricardo Mones]

control: severity -1 wishlist
control: tags -1 moreinfo

On Sat, 20 May 2023 13:46:21 +0200
José Luis González  wrote:

> The problem seems to be that it's not displayed as a window, as the
> setting claims, but as a system dialog. Either an additional setting is
> added to choose a system dialog/notification or the behaviour is
> changed to a window, as the name implies. I would suggest a separate
> tickbox for both if retaining the sytem dialog is wanted.

I'm pretty sure a "system dialog" is also a window... care to explain why do
you make such difference between them? are you perhaps expecting a different
behaviour just because the label says "window"?

regards,
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «Sattinger's Law: It works better if you plug it in.»


pgpPROtKEYjVS.pgp
Description: Firma digital OpenPGP

Bug#1037550: installation-reports: Command /usr/sbin/bootloader-config failed to finish in 600 seconds.

[wizardfromoz]

Package: installation-reports
Severity: important
X-Debbugs-Cc: christurner1...@gmail.com

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-12.0.0-amd64-DVD-1.iso
Date: Mon Jun 12 10:36:38 2023

Machine: Dell Inspiron 5770 Laptop
Partitions: 

Filesystem Type  1K-blocks  Used  Available Use% Mounted on
udev   devtmpfs8088576 08088576   0% /dev
tmpfs  tmpfs   1627092  20841625008   1% /run
/dev/sda13 ext4   29754436  11586460   16631160  42% /
tmpfs  tmpfs   8135448 08135448   0% /dev/shm
tmpfs  tmpfs  5120 8   5112   1% /run/lock
/dev/sda1  vfat1045784518720 527064  50% /boot/efi
tmpfs  tmpfs   1627088961626992   1% /run/user/1000
/dev/sdc9  ext4   20466388  134297365971692  70% 
/media/chris/MJRO-KDE-WD
/dev/sdc6  ext4   2046638824   19401404   1% 
/media/chris/DistroReady1
/dev/sdc8  ext4   2046638824   19401404   1% 
/media/chris/DistroReady
/dev/sdc48 ext4   1954888444   18483884   1% 
/media/chris/Photorec
/dev/sdc5  ext4   20466388  138591925542236  72% 
/media/chris/MJRO18.4-Xfce-WD
/dev/sdc44 ext4  360126524 812928378772  98% 
/media/chris/FutureLinux-WD
/dev/sdc45 ext4  566548024 493761944   43933856  92% 
/media/chris/TS-HDD2-dev-sda
/dev/sdc7  ext4   20335316  154179043852460  81% 
/media/chris/2wayAdataDocs
/dev/sdc42 ext4   40973776   8434044   30426196  22% 
/media/chris/TSNitruxOriginal
/dev/sdc47 ext4  102101944  31031296   65811388  33% 
/media/chris/VeraMATE4VMs-WD
/dev/sdc41 ext4  102626052  32503136   64863664  34% 
/media/chris/Voyager4VMs-WD
/dev/sdc43 ext4  103023292  909350526828728  94% 
/media/chris/Ex-Adata-1
/dev/sdc46 ext4  145451076 1329227885067068  97% 
/media/chris/TS-SSD2-dev-sdb
/dev/sdc49 ext4 145212510028 1378288068   1% 
/media/chris/DistroReady35GiB
/dev/sdc40 ext4   20466388 8   19401420   1% 
/media/chris/DistroReady2
/dev/sdc38 ext4   30787492  11722248   17475996  41% 
/media/chris/Mageia9Alpha-Fix
/dev/sdc37 ext4   2046638824   19401404   1% 
/media/chris/DistroReady3
/dev/sdc32 ext4   20466256  120369407364356  63% 
/media/chris/LubuntuKudu-WD
/dev/sdc33 ext4   20466256  148986804502616  77% 
/media/chris/LinuxLite6.0-WD
/dev/sdc30 ext4   3078766824   29198396   1% 
/media/chris/Leave4PhotoRec
/dev/sdc36 ext4   2046638856   19401372   1% 
/media/chris/TestingTimeshift
/dev/sdc3  ext4   2046638824   19401404   1% 
/media/chris/DistroReady5
/dev/sdc28 ext4   30787668   7192480   22005940  25% 
/media/chris/SpiralCinn-WD
/dev/sdc39 ext4   25627028  153805608919364  64% 
/media/chris/UlyanaCinn-WD
/dev/sdc31 ext4   20466256  117949247606372  61% 
/media/chris/XubuntuJammy-WD
/dev/sdc34 ext4   20466256   8774700   10626596  46% 
/media/chris/BunsenlabsHelium
/dev/sdc35 ext4   20466256  129487366452560  67% 
/media/chris/Jammy-GNOME-WD
/dev/sdc27 ext4   2046638824   19401404   1% 
/media/chris/DistroReady6
/dev/sdc24 ext4   2046638824   19401404   1% 
/media/chris/DistroReady7
/dev/sdc25 ext4   40973776  12348412   26511828  32% 
/media/chris/Swagarch
/dev/sdc4  ext4   2046638824   19401404   1% 
/media/chris/DistroReady4
/dev/sdc26 ext4   20466388   9376144   10025284  49% 
/media/chris/Peppermint10-WD
/dev/sdc23 ext4   20466256   8955384   10445912  47% 
/media/chris/TrisquelMATE-WD
/dev/sdc29 btrfs  62914560  24299884   35962196  41% 
/media/chris/Garuda-Cinn-WD
/dev/sdc20 ext4   20466256   6770404   12630892  35% 
/media/chris/Gecko-Xfce-WD
/dev/sdc22 ext4   20466256  123024167098880  64% 
/media/chris/EmmabuntusXfceWD
/dev/sdc21 ext4   40973536  12503260   26356740  33% 
/media/chris/VanessaCinn-WD
/dev/sdc17 ext4   2046638824   19401404   1% 
/media/chris/DistroReady8
/dev/sdc18 ext4   35942016  20946392   13144232  62% 
/media/chris/CLDC-22.0.1
/dev/sdc12 ext4   20466256   9210872   10190424  48% 
/media/chris/ParrotHOME-WD
/dev/sdc13 ext4   2046638824   19401404   1% 
/media/chris/DistroReady9
/dev/sdc15 ext4   4097377624   38860216   1% 
/media/chris/DistroReady40GiB
/dev/sdc1  ext4   2046638824   19401404   1% 
/media/chris/DistroReady11
/dev/sdc10 ext4   20466388  126144326786996  66% 
/media/chris/MJRO-Cinn-WD
/dev/sdc11 ext4   2046638824   19401404   1% 

Bug#1037549: Support for RTL8156BG broken

[Jamie Bliss]

Package: linux-image-6.1.0-9-amd64
Version: 6.1.27-1

Currently, Debian tries to use the cdc_ncm driver with the RTL8156BG, which 
fails without useful error. (ifup says the interface doesn't exist, neither 
systemd nor dmesg log anything notable, ip addr reports a mac address.)

I think it's supposed to use the r8152 driver, but the magic strings to use it 
are missing, and firmware-realtek might not have the correct blob.

Additional notes for this diagnostic journey can be found at 
https://community.frame.work/t/responded-debian-11-ethernet-expansion-card-doesnt-work-after-install/24482/8

Based on my exploration of the kernel.org repos, this might need to be fixed by 
Realtek itself.

Bug#1037548: qbittorrent-nox: web interface doesn't display content, browsers download html instead

[allan grossman]

Package: qbittorrent-nox
Version: 4.5.3-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: wizard10...@gmail.com

Dear Maintainer,

* What led up to the situation?

Running Debian Unstable, upgraded qbittorrent-nox to version 4.5.3-2 and
restarted its systemd service.

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

Reinstalled qbittorent-nox and libtorrent-rasterbar2.0 - ineffective
Renamed ~/.config/qBittorrent so get a clean config - ineffective

* What was the outcome of this action?

No change.  Browsers still download html code instead of displaying html
content.

* What outcome did you expect instead?

I expected the web interface to display in a browser window.


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 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 qbittorrent-nox depends on:
ii  libc62.36-9
ii  libgcc-s113.1.0-5
ii  libqt5sql5-sqlite5.15.8+dfsg-12
ii  libqt6core6  6.4.2+dfsg-11
ii  libqt6network6   6.4.2+dfsg-11
ii  libqt6sql6   6.4.2+dfsg-11
ii  libqt6xml6   6.4.2+dfsg-11
ii  libssl3  3.0.9-1
ii  libstdc++6   13.1.0-5
ii  libtorrent-rasterbar2.0  2.0.9-1
ii  zlib1g   1:1.2.13.dfsg-1

qbittorrent-nox recommends no packages.

qbittorrent-nox suggests no packages.

-- no debconf information
[Unit]
Description=qBittorrent Daemon Service
After=network-online.target

[Service]
User=wizard
Group=wizard
ExecStart=/usr/bin/ionice -c2 -n7 /usr/bin/qbittorrent-nox --webui-port=8090
ExecStop=/usr/bin/killall -w qbittorrent-nox

[Install]
WantedBy=multi-user.target
[AddNewTorrentDialog]
DialogSize=@Size(900 665)
Enabled=false
RememberLastSavePath=false
SplitterState=@ByteArray(\0\0\0\xff\0\0\0\x1\0\0\0\x2\0\0\x1\x93\0\0\x1\0\0\xff\xff\xff\xff\x1\0\0\0\x1\0)
TopLevel=true
TreeHeaderState="@ByteArray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x6\x34\0\0\0\x3\0\0\0\x2\0\0\0\x64\0\0\0\x4\0\0\0\x64\0\0\0\x5\0\0\0\x64\0\0\x1,\0\0\0\x6\x1\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x6\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x3\xe8\0\xff\xff\xff\xff)"

[Application]
FileLogger\Age=1
FileLogger\AgeType=1
FileLogger\Backup=true
FileLogger\DeleteOld=true
FileLogger\Enabled=false
FileLogger\MaxSizeBytes=66560
FileLogger\Path=/home/wizard/.local/share/qBittorrent/logs

[AutoRun]
OnTorrentAdded\Enabled=false
OnTorrentAdded\Program=
enabled=false
program=

[BitTorrent]
Session\AddExtensionToIncompleteFiles=true
Session\AlternativeGlobalDLSpeedLimit=0
Session\AlternativeGlobalUPSpeedLimit=0
Session\AnnounceToAllTrackers=true
Session\AsyncIOThreadsCount=32
Session\BTProtocol=TCP
Session\CheckingMemUsageSize=320
Session\DefaultSavePath=/media/internal/temp
Session\DisableAutoTMMByDefault=false
Session\DisableAutoTMMTriggers\CategorySavePathChanged=false
Session\DisableAutoTMMTriggers\DefaultSavePathChanged=false
Session\ExcludedFileNames=
Session\FilePoolSize=1000
Session\GlobalMaxRatio=-1
Session\GlobalMaxSeedingMinutes=1
Session\IgnoreLimitsOnLAN=true
Session\Interface=wg-mullvad
Session\InterfaceAddress=0.0.0.0
Session\InterfaceName=wg-mullvad
Session\LSDEnabled=false
Session\MaxActiveDownloads=20
Session\MaxActiveTorrents=20
Session\MaxActiveUploads=20
Session\MaxConnections=1
Session\MaxConnectionsPerTorrent=1000
Session\MaxRatioAction=0
Session\MaxUploads=1000
Session\MaxUploadsPerTorrent=1000
Session\Port=54881
Session\Preallocation=true
Session\QueueingSystemEnabled=true
Session\SaveResumeDataInterval=10
Session\uTPRateLimited=false

[Core]
AutoDeleteAddedTorrentFile=Never

[DownloadFromURLDialog]
Size=@Size(501 220)

[GUI]
DownloadTrackerFavicon=false
Log\Enabled=false
Notifications\Enabled=true
Notifications\Timeout=-1
Notifications\TorrentAdded=false

[IPSubnetWhitelistOptionsDialog]
Size=@Size(360 450)

[LegalNotice]
Accepted=true

[MainWindow]
geometry="@ByteArray(\x1\xd9\xd0\xcb\0\x3\0\0\0\0\0$\0\0\0\x17\0\0\x6\x85\0\0\x3\xe1\0\0\0%\0\0\0;\0\0\x6\x84\0\0\x3\xde\0\0\0\0\0\0\0\0\a\x80\0\0\0%\0\0\0;\0\0\x6\x84\0\0\x3\xde)"
qt5\vsplitterState=@ByteArray(\0\0\0\xff\0\0\0\x1\0\0\0\x2\0\0\0\0\0\0\x6L\x1\xff\xff\xff\xff\x1\0\0\0\x1\0)

[Meta]
MigrationVersion=4

[Network]
Cookies=@Invalid()
PortForwardingEnabled=true
Proxy\OnlyForTorrents=false

[OptionsDialog]
HorizontalSplitterSizes=119, 634
LastViewedPage=2
Size=@Size(779 591)

[Preferences]
Advanced\DisableRecursiveDownload=false
Advanced\EnableIconsInMenus=true

Bug#1037547: fapolicyd: Installation of fapolicyd via apt caused everything to immediately become non-executable.

[Bill Hay]

Package: fapolicyd
Version: 1.1.7-5
Severity: important

Dear Maintainer,

I wanted to try out fapolicyd.

I typed apt install fapolicyd on my recently upgraded bookworm system

While installing it complained about being unable to do something with man 
pages.
Immediately after installing no external executables were executable.  In order 
to 
regain control of the system I had to stomp on the systemd file for fapolicyd 
via 
redirection from my shell and power cycle my laptop.

I expected to still be able to run most normal binaries

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

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

Versions of packages fapolicyd depends on:
ii  adduser  3.134
ii  libc62.36-9
ii  libcap-ng0   0.8.3-1+b3
ii  liblmdb0 0.9.24-1
ii  libmagic11:5.44-3
ii  libseccomp2  2.5.4-1+b3
ii  libssl3  3.0.9-1
ii  libudev1 252.6-1

fapolicyd recommends no packages.

fapolicyd suggests no packages.

-- no debconf information

Bug#1037546: open-vm-tools version 12.2.5 has been released - please rebase

[John Wolfe]

Package: open-vm-tools
Version: 2:12.2.5

open-vm-tools 12.2.5 was released on June 13, 2023.

There are no new features in the open-vm-tools 12.2.5 release. This is 
primarily a maintenance release that addresses a single critical problem:

  *  Address CVE-2023-20867 announced in 
https://www.vmware.com/security/advisories/VMSA-2023-0013.html

For complete details, see: 
https://github.com/vmware/open-vm-tools/releases/tag/stable-12.2.5

Release Notes are available at: 
https://github.com/vmware/open-vm-tools/blob/stable-12.2.5/ReleaseNotes.md

The granular changes that have gone into the 12.2.5 release are in the 
ChangeLog at: 
https://github.com/vmware/open-vm-tools/blob/stable-12.2.5/open-vm-tools/ChangeLog

Patches applicable to previous open-vm-tools releases are available at 
https://github.com/vmware/open-vm-tools/tree/CVE-2023-20867.patch

Bug#1022073: pam-u2f: new upstream release 1.2.1 available

[adam]

The fix for this vulnerability (CVE-2021-31924) was backported and included in 
the NMU version 1.1.0-1.1.

References:
- https://github.com/Yubico/pam-u2f/issues/175
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987545#39

There are still functionality issues with the version that is shipped in Debian 
which were fixed in 1.1.1, such as hardware compatibility, but there are not 
any known security issues in 1.1.0-1.1 that I am aware of.

On Wed, 22 Feb 2023 23:56:58 +0100 Enrique Garcia  wrote:
> Package: libpam-u2f
> Version: 1.1.0-1.1+b1
> Followup-For: Bug #1022073
> X-Debbugs-Cc: cqu...@arcor.de
> 
> The following blog from yubico, who are the developers of libpam-u2f 
> recommends
> using at least version 1.1.1 since there is a risk of local PIN bypass:
> 
> https://support.yubico.com/hc/en-us/articles/360016649099-Ubuntu-Linux-Login-
> Guide-U2F
> 
> The issue is in libpam-u2f 1.1.0, which is exactly the version shipped right
> now with Debian (bullseye, bookworm, sid)
-- 
Sent from my Palm Pilot. Please excuse my brevity.

Bug#1037544: emacs-common: CPerl mode: bad coloring when a comment block is used

[Vincent Lefevre]

Package: emacs-common
Version: 1:28.2+1-15
Severity: minor

When a comment block is used, i.e.

=begin comment

[code to comment]

=end comment

=cut

as described in the perlfaq7 man page, everything starting at the
"=begin comment" line is in the comment color, even the code after
the "=cut" line (which is no longer commented code).

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

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

Versions of packages emacs-common depends on:
ii  emacs-el 1:28.2+1-15
ii  emacsen-common   3.0.5
ii  init-system-helpers  1.64
ii  install-info 6.8-6+b1

emacs-common recommends no packages.

Versions of packages emacs-common suggests:
ii  emacs-common-non-dfsg  1:28.2+1-2
ii  ncurses-term   6.4-4

-- no debconf information

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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 13 Jun 2023 at 22:59, Luca Boccassi  wrote:
>
> On Tue, 13 Jun 2023 at 22:49, Russ Allbery  wrote:
> >
> > Luca Boccassi  writes:
> >
> > > That essentially means it's fine to use diversions and ship releases
> > > using them, so that's exactly what will happen as per Murphy's law.
> >
> > I think we're reaching a consensus that "must" is appropriate for the
> > systemd configuration files, so this discussion is about how to phrase the
> > general guidance that isn't specific to systemd.
> >
> > I'm therefore not really understanding the argument that you're trying to
> > make here.  Are you trying to say that we should just delete everything in
> > Policy that isn't a "must" because it serves no useful purpose?  If not,
> > then why are you taking this incredibly aggressive position that general
> > guidance is pointless unless it says "must"?
>
> Waait, maybe I misunderstood - I thought the change was requested for
> all additions, including systemd files? Is that not the case? (It
> would be obvious what it refers to on a merge request :-P )
> If I can keep a 'must' for systemd config files, then I'm ok with changing.

I.e.: if the attached version works, then that's good enough for me.

Kind regards,
Luca Boccassi
From ed947ae43dc48d4bee1b609fe3942ff1a01e7a6b Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Mon, 8 May 2023 03:21:14 +0100
Subject: [PATCH] Forbid using dpkg-divert/alternatives when there are native
 mechanisms

The supported mechanism for augmenting, changing, overriding and
disabling systemd configuration files is natively supported and fully
integrated in Debian, via drop-ins, hierarchical overrides, and
masking. dpkg-divert is not integrated in systemd tools so its use
is completely hidden in logs and status interfaces, and it is specific
to Debian and thus diverges from what users expect as implemented by
all other distros, going against one of the core goals of the systemd
project which is to provide a uniform interface regardless of distro
vendor or flavour.

Clarify that diversions and alternatives should only be used when
needed, with cooperation, and must not be used when there are native
mechanisms to obtain the same goals, and use systemd files as an
example.
---
 policy/ap-pkg-alternatives.rst |  3 +++
 policy/ap-pkg-diversions.rst   |  3 +++
 policy/ch-binary.rst   | 35 ++
 3 files changed, 41 insertions(+)

diff --git a/policy/ap-pkg-alternatives.rst b/policy/ap-pkg-alternatives.rst
index ffa2163..6f7780f 100644
--- a/policy/ap-pkg-alternatives.rst
+++ b/policy/ap-pkg-alternatives.rst
@@ -24,3 +24,6 @@ See the :manpage:`update-alternatives(8)` man page for details.
 If ``update-alternatives`` does not seem appropriate you may wish to
 consider using diversions instead.
 
+Do not use alternatives for ``systemd`` configuration files. See
+:doc:`ch-binary` for more information.
+
diff --git a/policy/ap-pkg-diversions.rst b/policy/ap-pkg-diversions.rst
index fe360d1..d299d04 100644
--- a/policy/ap-pkg-diversions.rst
+++ b/policy/ap-pkg-diversions.rst
@@ -81,3 +81,6 @@ when the file does not exist.
 Do not attempt to divert a conffile, as ``dpkg`` does not handle it
 well.
 
+Do not use diversions for files that have their own native override mechanisms,
+such as ``systemd`` unit files. See :doc:`ch-binary` for more information.
+
diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index e517f26..19635e7 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -371,6 +371,41 @@ against earlier versions of something that previously did not use
 ``update-alternatives``; this is an exception to the usual rule that
 versioned conflicts should be avoided.)
 
+Diversions are primarily intended as a tool for local administrators or local
+packages to override the behavior of Debian. While there are some circumstances
+where one Debian package may need to divert a file of another Debian package,
+those circumstances are rare and diversions should only be used as a last resort
+when no other suitable mechanism exists. Diversion of a file in one Debian
+package by another Debian package should be coordinated between the maintainers
+of those packages. Maintainers should strongly prefer using other overriding
+mechanisms, instead of diversions, whenever those other mechanisms are
+sufficient to accomplish the same goal. In other words, diversions in packages
+should be considered a last resort.
+
+One specific case of that rule is that configuration files used by
+``systemd`` components, such as `units,
+`_
+`udev rules,
+`_
+`tmpfiles.d,
+`_
+`modules-load.d,
+`_,

Bug#1037543: bugreport in terms of GNUPG

[John Danielsson]

Package: GNUPG
Version: 2.2

Dear Team,

I would like to report a bug regarding GNUPG export key feature.
Everytime I export a key using --export GPGID command manually from
terminal,
I am not able to import the key, while using the GNUPG gui from Gnome
successfully
exports the secretkey.

Best regards,

John

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 13 Jun 2023 at 22:49, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > That essentially means it's fine to use diversions and ship releases
> > using them, so that's exactly what will happen as per Murphy's law.
>
> I think we're reaching a consensus that "must" is appropriate for the
> systemd configuration files, so this discussion is about how to phrase the
> general guidance that isn't specific to systemd.
>
> I'm therefore not really understanding the argument that you're trying to
> make here.  Are you trying to say that we should just delete everything in
> Policy that isn't a "must" because it serves no useful purpose?  If not,
> then why are you taking this incredibly aggressive position that general
> guidance is pointless unless it says "must"?

Waait, maybe I misunderstood - I thought the change was requested for
all additions, including systemd files? Is that not the case? (It
would be obvious what it refers to on a merge request :-P )
If I can keep a 'must' for systemd config files, then I'm ok with changing.

Kind regards,
Luca Boccassi

Bug#1037542: bookworm-pu: package xerial-sqlite-jdbc/3.40.1.0+dfsg-1+deb12u1

[Pierre Gruet]

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

Dear Release team,

I would like to upload xerial-sqlite-jdbc to stable-proposed-updates.

[ Reason ]
Grave bug #1036706 has been filled a few days before the release of Bookworm.
This is a security bug associated to CVE-2023-32697. Although it has been
marked no-dsa by the security team, we exchanged a few emails and our
conclusion was the fix of this bug, which amounts to cherry-pick one commit of
upstream, should land in Bookworm during a point release.

[ Impact ]
CVE-2023-32697 would remain. The Debian-packaged reverse dependencies of the
package are mainly used in a single-user environment, but possibly it is also
used in a network environment by some users for their own programs, and this is
where there might be some hazard.

[ Tests ]
The package was built in a Bookworm chroot and its autopkgtest is passing.

[ Risks ]
Code is very simple, only 2 lines are changed. Upstream has published it
three weeks ago and it has issued new upstream versions since then.

[ 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 ]
Cherry-picking commit edb4b8adc2447bc04e05b9b908195a4bc7926242 from upstream,
which uses a random UUID instead of the hash of some fixed address in order to
define the DB file name.



Thanks for your help,

Best,

-- 
Pierre
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog 
xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog   2023-02-04 
14:24:45.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog   2023-06-13 
23:19:59.0 +0200
@@ -1,3 +1,9 @@
+xerial-sqlite-jdbc (3.40.1.0+dfsg-1+deb12u1) bookworm; urgency=medium
+
+  * Using a random UUID for the connection (Fixes CVE-2023-32697 in Bookworm)
+
+ -- Pierre Gruet   Tue, 13 Jun 2023 23:19:59 +0200
+
 xerial-sqlite-jdbc (3.40.1.0+dfsg-1) unstable; urgency=medium
 
   * New upstream version 3.40.1.0+dfsg
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch 
xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch
1970-01-01 01:00:00.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch
2023-06-13 23:17:23.0 +0200
@@ -0,0 +1,28 @@
+Description: fixing CVE-2023-32697
+Author: Pierre Gruet 
+Origin: upstream, 
https://github.com/xerial/sqlite-jdbc/commit/edb4b8adc2447bc04e05b9b908195a4bc7926242
+Bug: 
https://github.com/xerial/sqlite-jdbc/security/advisories/GHSA-6phf-6h5g-97j2
+Bug-Debian: https://bugs.debian.org/1036706
+Forwarded: not-needed
+Applied-Upstream: edb4b8adc2447bc04e05b9b908195a4bc7926242
+Last-Update: 2023-06-13
+
+--- a/src/main/java/org/sqlite/SQLiteConnection.java
 b/src/main/java/org/sqlite/SQLiteConnection.java
+@@ -13,6 +13,7 @@
+ import java.sql.ResultSet;
+ import java.sql.SQLException;
+ import java.util.Properties;
++import java.util.UUID;
+ import java.util.concurrent.Executor;
+ import org.sqlite.SQLiteConfig.TransactionMode;
+ import org.sqlite.core.CoreDatabaseMetaData;
+@@ -303,7 +304,7 @@
+ }
+ 
+ String tempFolder = new 
File(System.getProperty("java.io.tmpdir")).getAbsolutePath();
+-String dbFileName = String.format("sqlite-jdbc-tmp-%d.db", 
resourceAddr.hashCode());
++String dbFileName = String.format("sqlite-jdbc-tmp-%s.db", 
UUID.randomUUID());
+ File dbFile = new File(tempFolder, dbFileName);
+ 
+ if (dbFile.exists()) {
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series 
xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series  2023-02-02 
17:16:53.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series  2023-06-13 
23:10:58.0 +0200
@@ -7,3 +7,4 @@
 skip_OSInfoTest.patch
 tests_without_archunit-junit5_and_some_assertions.patch
 junit-jupiter-params_artifact.patch
+CVE-2023-32697.patch

Bug#1037535: libnet-twitter-perl: "Could not authenticate you." errors since 2023-06-13

[Vincent Lefevre]

On 2023-06-13 23:18:47 +0200, Vincent Lefevre wrote:
> It seems that something changed on Twitter, which yields the
> "Could not authenticate you." error with Net::Twitter. This
> started to happen a few hours ago.

I think that's it:

https://twitter.com/TwitterDev/status/1621026986784337922

"Starting February 9, we will no longer support free access to the
Twitter API, both v2 and v1.1. A paid basic tier will be available
instead"

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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Luca Boccassi  writes:

> That essentially means it's fine to use diversions and ship releases
> using them, so that's exactly what will happen as per Murphy's law.

I think we're reaching a consensus that "must" is appropriate for the
systemd configuration files, so this discussion is about how to phrase the
general guidance that isn't specific to systemd.

I'm therefore not really understanding the argument that you're trying to
make here.  Are you trying to say that we should just delete everything in
Policy that isn't a "must" because it serves no useful purpose?  If not,
then why are you taking this incredibly aggressive position that general
guidance is pointless unless it says "must"?

-- 
Russ Allbery (r...@debian.org)  

Bug#1037541: libguestfs: FTBFS: supermin: error: lstat: Value too large for defined data type: /var/tmp/supermin2b73c8.tmpdir/base.d/init

[Sebastian Ramacher]

Source: libguestfs
Version: 1:1.50.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libguestfs=i386=1%3A1.50.1-1=1686678530=0

tar: etc: implausibly old time stamp -9223372036854775808
tar: usr/sbin/guestfsd: implausibly old time stamp -9223372036854775808
tar: usr/sbin: implausibly old time stamp -9223372036854775808
tar: usr: implausibly old time stamp -9223372036854775808
supermin: build: visiting 
/<>/debian/build-4/appliance/supermin.d/excludefiles type 
uncompressed excludefiles
supermin: build: visiting 
/<>/debian/build-4/appliance/supermin.d/hostfiles type 
uncompressed hostfiles
supermin: build: visiting 
/<>/debian/build-4/appliance/supermin.d/init.tar.gz type gzip base 
image (tar)
tar: init: implausibly old time stamp -9223372036854775808
supermin: build: visiting 
/<>/debian/build-4/appliance/supermin.d/packages type uncompressed 
packages
supermin: build: visiting 
/<>/debian/build-4/appliance/supermin.d/udev-rules.tar.gz type 
gzip base image (tar)
tar: etc/udev/rules.d/99-guestfs-serial.rules: implausibly old time stamp 
-9223372036854775808
tar: etc/udev/rules.d: implausibly old time stamp -9223372036854775808
tar: etc/udev: implausibly old time stamp -9223372036854775808
tar: etc: implausibly old time stamp -9223372036854775808
supermin: mapping package names to installed packages
supermin: resolving full list of package dependencies
supermin: build: 247 packages, including dependencies
supermin: build: 10324 files
supermin: build: 5081 files, after matching excludefiles
supermin: build: 5084 files, after adding hostfiles
supermin: build: 5084 files, after removing unreadable files
supermin: build: 5085 files, after munging
supermin: kernel: looking for kernel using environment variables ...
supermin: kernel: looking for kernels in /lib/modules/*/vmlinuz ...
supermin: kernel: looking for kernels in /boot ...
supermin: kernel: kernel version of /boot/vmlinuz-6.1.0-9-686-pae = 
6.1.0-9-686-pae (from content)
supermin: kernel: picked modules path /lib/modules/6.1.0-9-686-pae
supermin: kernel: picked vmlinuz /boot/vmlinuz-6.1.0-9-686-pae
supermin: kernel: kernel_version 6.1.0-9-686-pae
supermin: kernel: modpath /lib/modules/6.1.0-9-686-pae
supermin: ext2: creating empty ext2 filesystem 
'/<>/debian/build-4/tmp/.guestfs-2952/appliance.d.cs96n5v2/root'
supermin: ext2: populating from base image
supermin: error: lstat: Value too large for defined data type: 
/var/tmp/supermin2b73c8.tmpdir/base.d/init
libguestfs: error: /usr/bin/supermin exited with error status 1, see debug 
messages above
libguestfs: closing guestfs handle 0x57dcea80 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf 
/<>/debian/build-4/tmp/libguestfsLo9Elv
make[2]: *** [Makefile:1763: quickcheck] Error 1
make[2]: Leaving directory '/<>/debian/build-4'
make[1]: *** [debian/rules:133: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'

Cheers
-- 
Sebastian Ramacher

Bug#1037537: Upgrade To Bookworm Fails with Roundcube Update

[Guilhem Moulin]

Control: tag -1 unreproducible moreinfo

On Tue, 13 Jun 2023 at 16:16:51 -0500, Bryan K. Walton via 
Pkg-roundcube-maintainers wrote:
> Today, I tried to upgrade my webserver to Debian 12.0 (bookworm).
> Everything succeeded but Roundcube.

What was the previous Roundcube (and Debian itself) version?  Please
also share your roundcube configuration file.  piuparts checks the
upgrade path of the stock config (for all of DB backends) and that
appear to be smooth.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1028436: transition: re2

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2023-01-10 19:22:20 -0400, Stefano Rivera wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: r...@packages.debian.org
> Control: affects -1 + src:re2
> 
> Sorry for a last minute request. I was just looking through my packages
> on the weekend and noticed that re2 had tagged a new release, but I
> hadn't seen it due to the GitHub layout change last year.
> 
> This is a very minor ABI break in the C++ library, caused by changing
> class layout.
> 
> The in the 6 months since the previous release, they've only made 22
> commits. Which also means that if it misses the freeze, it's probably
> not a big deal.
> 
> The new version is currently sitting in experimental bin-NEW.

Please go ahead with the upload to unstable.

Cheers
-- 
Sebastian Ramacher

Bug#1037540: Thunar (4.18.4-1) Segfaults If Using Tab Key While Using Split View

[Fjords]

Package: thunar
Version: 4.18.4-1
Severity: grave

Hello, Thunar has been regularly crashing if using the current stable 
build with split view enabled.


To reproduce this issue, open a new Thunar instance, enable split view, 
and have one of the directories contain images, focus on the 
image-containing directory, and then press the Tab key multiple times 
until it crashes. Terminal output: https://pastebin.com/2mpdYyUb


This has been apparently fixed upstream with 4.18.5, but linking it here 
anyway for your information: 
https://gitlab.xfce.org/xfce/thunar/-/issues/1067


Thank you.

Bug#1037539: multipath-tools: the /lib/udev/rules.d/60-multipath.rules file is missing

[Joshua Huber]

Package: multipath-tools
Version: 0.9.4-3
Severity: important
Tags: patch

Dear Maintainer,

Since verison 0.9.4-1, the multipath.rules udev file is no longer included in
the Debian package. Upstream changed from shipping a static file to a
file generated at build time (multipath.rules.in), and the debian packaging
didn't account for this change. I've come up with something that works, but
it might not be the best/correct solution according to packaging policy
and such.

The missing rules file results in missing udev device properties, such as
DM_MULTIPATH_DEVICE_PATH. This, at the very least, has the effect of:

1) Not skipping LVM device scanning on multipath path devices, which could
   result in a failure to bring up a multipath device. (or worse --
   I wouldn't be surprised if concurrently operating on a dm-multipath device
   and one or more of its child devices could cause data loss, if unlucky.)

2) Not removing partition table entries for multipath child devices.
   (the del-part-nodes rules apply if DM_MULTIPATH_DEVICE_PATH is set.)

If you need any more information, happy to provide it!

-- Package-specific info:
/etc/multipath.conf does not exist.


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

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

Versions of packages multipath-tools depends on:
ii  init-system-helpers1.65.2
ii  kpartx 0.9.4-3
ii  libaio10.3.113-4
ii  libc6  2.36-9
ii  libdevmapper1.02.1 2:1.02.185-2
ii  libedit2   3.1-20221030-2
ii  libjson-c5 0.16-2
ii  libsystemd0252.6-1
ii  libudev1   252.6-1
ii  liburcu8   0.13.2-1
ii  sg3-utils-udev 1.46-3
ii  sysvinit-utils [lsb-base]  3.06-4
ii  udev   252.6-1

multipath-tools recommends no packages.

Versions of packages multipath-tools suggests:
pn  multipath-tools-boot  

-- no debconf information

*** fix-missing-multipath-udev-rules.patch
commit 81d3e7e0a23bf7b384accd65d85070008ac7142a (HEAD -> master)
Author: Joshua Huber 
Date:   Tue Jun 13 14:15:30 2023 -0400

account for upstream multipath.rules changing to a generated file

diff --git a/debian/rules b/debian/rules
index 28839b67..e56419ae 100755
--- a/debian/rules
+++ b/debian/rules
@@ -47,9 +47,10 @@ override_dh_auto_install:
[ ! -f kpartx/del-part-nodes.rules ] || cp kpartx/del-part-nodes.rules 
debian/kpartx.del-part-nodes.udev
[ ! -f kpartx/dm-parts.rules ] || cp kpartx/dm-parts.rules 
debian/kpartx.dm-parts.udev
[ ! -f kpartx/kpartx.rules ] || cp kpartx/kpartx.rules 
debian/kpartx.udev
-   [ ! -f multipath/multipath.rules ] || cp multipath/multipath.rules 
debian/multipath.udev
[ ! -f multipath/11-dm-mpath.rules ] || cp multipath/11-dm-mpath.rules 
debian/dm-mpath.udev

+   cp -v debian/build-deb/multipath/multipath.rules 
debian/multipath-tools.multipath.udev
+
dh_auto_install --sourcedirectory=debian/build-deb -- 
DESTDIR=$(CURDIR)/debian/tmp
dh_auto_install --sourcedirectory=debian/build-udeb -- 
DESTDIR=$(CURDIR)/debian/tmp-multipath-udeb

Bug#1037538: gerbera: FTBFS with libupnp17

[Sebastian Ramacher]

Source: gerbera
Version: 1.1.0+dfsg-3.1
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=gerbera=amd64=1.1.0%2Bdfsg-3.1%2Bb2=1686649192=0

-- Found LFS: TRUE  
CMake Warning (dev) at 
/usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (UPnP) does
  not match the name of the calling package (LibUpnp).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/FindLibUpnp.cmake:39 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:372 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found UPnP: /usr/lib/x86_64-linux-gnu/libupnp.so (found version "17.1.8") 
CMake Error at CMakeLists.txt:389 (message):
  

  !! You are using a very old 1.8 snapshot.  Please upgrade to a 1.8.x
  release from upstream (https://github.com/mrjimenez/pupnp) !!



-- Configuring incomplete, errors occurred!

Cheers
-- 
Sebastian Ramacher

Bug#1037537: Upgrade To Bookworm Fails with Roundcube Update

[Bryan K. Walton]

Package: roundcube-core
Version: 1.6.1+dfsg-1

Today, I tried to upgrade my webserver to Debian 12.0 (bookworm).
Everything succeeded but Roundcube.  The upgrade of Roundcube fails with
the following:

Installing new version of config file /etc/roundcube/htaccess ...
Installing new version of config file /etc/roundcube/mimetypes.php ...
INFO: Running /usr/share/roundcube/bin/update.sh as user 'www-data'
dpkg: error processing package roundcube-core (--configure):
 installed roundcube-core package post-installation script subprocess returned 
error exit status 255
dpkg: dependency problems prevent configuration of roundcube-plugins:
 roundcube-plugins depends on roundcube-core (= 1.6.1+dfsg-1); however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube-plugins (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of roundcube:
 roundcube depends on roundcube-core (= 1.6.1+dfsg-1); however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 roundcube-core
 roundcube-plugins
 roundcube
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1037536: RM: edflib [s390x] -- ANAIS; explicit lack of big endian support

[Étienne Mollier]

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

Hi,

Since version 1.24, the edflib package introduces code to check
at runtime the architecture endianess, and bails out if it is
unhandled.  This manifests as an autopkgtest error on s390x
architecture:

gcc -Wall -Wextra -Wshadow -Wformat-nonliteral -Wformat-security 
-Wtype-limits -Wfatal-errors -g -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -c 
unittest.c -o unittest.o
gcc unittest.o -o edflib_test -ledf
Error, line 124 file unittest.c

The test chokes on a handle having a negative value.  The actual
value of the handle is -12 on s390x, which incidently matches
the error code for EDFLIB_ARCH_ERROR.  The README now explicitly
says big endian systems are not supported by edflib, so I guess
the package should not provided here anymore.

The only reverse dependency: edfbrowser, has already been
removed from s390x distribution on similar grounds, so no
surprises here to be honest.  

Have a nice day,  :)
Étienne.


signature.asc
Description: PGP signature

Bug#1037535: libnet-twitter-perl: "Could not authenticate you." errors since 2023-06-13

[Vincent Lefevre]

Package: libnet-twitter-perl
Version: 4.01043-2
Severity: grave
Justification: renders package unusable

It seems that something changed on Twitter, which yields the
"Could not authenticate you." error with Net::Twitter. This
started to happen a few hours ago.

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

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

Versions of packages libnet-twitter-perl depends on:
ii  libcarp-clan-perl  6.08-2
ii  libclass-load-perl 0.25-2
ii  libcrypt-ssleay-perl   0.73.06-2+b1
ii  libdata-visitor-perl   0.31-1
ii  libdatetime-format-strptime-perl   1.7900-1
ii  libdatetime-perl   2:1.59-1
ii  libdevel-stacktrace-perl   2.0400-2
ii  libdigest-hmac-perl1.04+dfsg-2
ii  libhtml-parser-perl3.81-1
ii  libio-socket-ssl-perl  2.083-1
ii  libjson-maybexs-perl   1.004004-1
ii  liblwp-protocol-https-perl 6.10-1
ii  libmoose-perl  2.2203-1
ii  libmoosex-role-parameterized-perl  1.11-2
ii  libnamespace-autoclean-perl0.29-2
ii  libnet-http-perl   6.22-1
ii  libnet-oauth-perl  0.28-4
ii  libtry-tiny-perl   0.31-2
ii  liburi-perl5.19-1
ii  libwww-perl6.70-1
ii  perl   5.36.0-7

libnet-twitter-perl recommends no packages.

libnet-twitter-perl suggests no packages.

-- no debconf information

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

Bug#1030979: nm-dispatcher[…]: /etc/network/if-up.d/10check-duplicate-ip: 86: cannot create /dev/stdout: No such device or address

[AlMa]

severity 1030979 important
thanks

Raising severity as the bug affects more than one person.  The bug is 
still there in Debian stable “bookworm” with ifupdown 0.8.41 and 
ifupdown-extra 0.33+nmu1:


Jun 13 21:00:24 AnonymizedMachineName gsd-sharing[1420]: Failed to 
StopUnit service: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.freedesktop.systemd1 exited with status 1
Jun 13 21:00:24 AnonymizedMachineName avahi-daemon[815]: Joining mDNS 
multicast group on interface wlp179s0.IPv4 with address 192.168.1.49.
Jun 13 21:00:24 AnonymizedMachineName avahi-daemon[815]: New relevant 
interface wlp179s0.IPv4 for mDNS.
Jun 13 21:00:24 AnonymizedMachineName avahi-daemon[815]: Registering new 
address record for 192.168.1.49 on wlp179s0.IPv4.
Jun 13 21:00:24 AnonymizedMachineName NetworkManager[880]:  
[1686682824.7500] device (wlp179s0): state change: ip-config -> ip-check 
(reason 'none', sys-iface-state: 'managed')
Jun 13 21:00:24 AnonymizedMachineName NetworkManager[880]:  
[1686682824.7541] device (wlp179s0): state change: ip-check -> 
secondaries (reason 'none', sys-iface-state: 'managed')
Jun 13 21:00:24 AnonymizedMachineName NetworkManager[880]:  
[1686682824.7545] device (wlp179s0): state change: secondaries -> 
activated (reason 'none', sys-iface-state: 'managed')
Jun 13 21:00:24 AnonymizedMachineName NetworkManager[880]:  
[1686682824.7551] manager: NetworkManager state is now CONNECTED_SITE
Jun 13 21:00:24 AnonymizedMachineName NetworkManager[880]:  
[1686682824.7562] device (wlp179s0): Activation: successful, device 
activated.
Jun 13 21:00:24 AnonymizedMachineName NetworkManager[880]:  
[1686682824.7571] manager: NetworkManager state is now CONNECTED_GLOBAL
Jun 13 21:00:24 AnonymizedMachineName gnome-shell[1314]: Error looking 
up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No 
entry for geolocation
Jun 13 21:00:24 AnonymizedMachineName nm-dispatcher[1603]: 
/etc/network/if-up.d/10check-duplicate-ip: 86: cannot create 
/dev/stdout: No such device or address

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Thorsten Glaser]

On Tue, 13 Jun 2023, Russ Allbery wrote:

>Ah, I think I understand what you're getting at.  You're talking about
>using the init script of a daemon as this sort of wrapper script for

Not really. I was talking about normal programs, not dæmons.
I have the expectation that these, when invoked, create their
necessary temporary files/directories when they are placed on
volatile storage, i.e. /tmp and /run and possibly /var/tmp.

>nothing we're talking about here changes that behavior, because nothing
>needs to be pre-created.

Ah, good then.

For dæmons, running them in chroots is usually more tricky
anyway. Ideally, just /etc/init.d/foo {stop|start} would
work, but there’s situations where that doesn’t suffice.
If maintainers can get the former working, fine.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1037534: rust-xml-rs: CVE-2023-34411

[Salvatore Bonaccorso]

Hi,

On Tue, Jun 13, 2023 at 10:55:24PM +0200, Salvatore Bonaccorso wrote:
> Source: rust-xml-rs
> Version: 0.8.3-1
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/netvl/xml-rs/pull/226
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for rust-xml-rs.
> 
> CVE-2023-34411[0]:
> | The xml-rs crate before 0.8.14 for Rust and Crab allows a denial of
> | service (panic) via an invalid  | nesting) in an XML document. The earliest affected version is 0.8.9.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2023-34411
> https://www.cve.org/CVERecord?id=CVE-2023-34411
> [1] https://github.com/netvl/xml-rs/pull/226
> [2] 
> https://github.com/netvl/xml-rs/commit/c09549a187e62d39d40467f129e64abf32efc35c

Actually, the issue is introduced with
https://github.com/netvl/xml-rs/commit/014d808be900c85a0afc5ccdfe668be040d175aa
in 0.8.9 so no Debian version would be affected. 

If you can confirm, please close the bug!

Regards,
Salvatore

Bug#1037534: rust-xml-rs: CVE-2023-34411

[Salvatore Bonaccorso]

Source: rust-xml-rs
Version: 0.8.3-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/netvl/xml-rs/pull/226
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rust-xml-rs.

CVE-2023-34411[0]:
| The xml-rs crate before 0.8.14 for Rust and Crab allows a denial of
| service (panic) via an invalid https://security-tracker.debian.org/tracker/CVE-2023-34411
https://www.cve.org/CVERecord?id=CVE-2023-34411
[1] https://github.com/netvl/xml-rs/pull/226
[2] 
https://github.com/netvl/xml-rs/commit/c09549a187e62d39d40467f129e64abf32efc35c

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037533: Inconsistent (default) SELinux setup

[Michal Berger]

Version: Debian12, Bookworm (kernel: 6.1.0-9-cloud-amd64)
Package: libselinux1:amd64
Impact: cosmetic

I have noticed that the kernels shipped with Debian (or at least the flavor
mentioned above) don't provide the CONFIG_SECURITY_SELINUX_BOOTPARAM. This
essentially means that there's no way to disable SELinux via the kernel's
cmdline.

Even though Debian, by default, does not use SELinux, it does ship the
libselinux which, for instance, systemd is happily linking to. It does go
through the selinux_init_load_policy() which means that the libselinux
attempts to not only mount selinuxfs (which it successfully does) but it
also attempts to load its .policy. Naturally, for the system which does not
depend on SELinux, such .policy would not exist. This ends up with a very
confusing message, coming from libselinux, which can be seen right after
systemd kicks in:

SELinux:  Could not open policy file <=
/etc/selinux/targeted/policy/policy.33:  No such file or directory

(libselinux automagically determines this .N suffix at the end so I guess
the actual path may differ across different versions).

Since we cannot disable SELinux on the kernel level, and there's no way to
prevent libselinux from mounting selinuxfs (I believe based on that action
it actually determines if SELinux is disabled or not since it does not
lookup the "selinux=" in kernel's cmdline, just the "enforcing=" bit), we
need to actually create its /etc/selinux/config and explicitly set
"SELINUX=disabled" inside.

To me, this is the inconsistent part. :) User which is not using SELinux at
all, is required to put its config in place, to make sure the above loading
of the .policy does not happen (and to prevent this error from popping up
on the console). In my opinion, Debian should either provide the
/etc/selinux/config from the very get-go (with SELinux disabled) or at
least enable the CONFIG_SECURITY_SELINUX_BOOTPARAM. :)

Regards,
Michal

Bug#1037447: pipewire[…]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?

[AlMa]

On another, very similar computer with Debian stable “bookworm“, I find 
similar “Can't find …” messages. Here, pipewire presents the annoying 
message first, i.e., before wireplumber:


Jun 13 21:00:20 AnonymizedMachineName systemd[1095]: Started 
wireplumber.service - Multimedia Service Session Manager.
Jun 13 21:00:20 AnonymizedMachineName systemd[1095]: Started 
pipewire-pulse.service - PipeWire PulseAudio.
Jun 13 21:00:20 AnonymizedMachineName kernel: a8293 19-000b: Allegro 
A8293 SEC successfully attached
Jun 13 21:00:20 AnonymizedMachineName systemd[1095]: Starting 
dbus.service - D-Bus User Message Bus...
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(--) Log file renamed from 
"/var/lib/gdm3/.local/share/xorg/Xorg.pid-1154.log" to 
"/var/lib/gdm3/.local/share/xorg/Xorg.0.log"
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
X.Org X Server 1.21.1.7
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
X Protocol Version 11, Revision 0
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
Current Operating System: Linux AnonymizedMachineName 6.1.0-9-amd64 #1 
SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=AnonymizedLongID ro vga=842
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
xorg-server 2:21.1.7-3 (https://www.debian.org/support)
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
Current version of pixman: 0.42.2
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
   Before reporting problems, check http://wiki.x.org
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
   to make sure that you have the latest version.
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
Markers: (--) probed, (**) from config file, (==) default setting,
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
   (++) from command line, (!!) notice, (II) informational,
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) Log file: "/var/lib/gdm3/.local/share/xorg/Xorg.0.log", Time: Tue 
Jun 13 21:00:20 2023
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Jun 13 21:00:20 AnonymizedMachineName systemd[1095]: Started 
dbus.service - D-Bus User Message Bus.
Jun 13 21:00:20 AnonymizedMachineName dbus-daemon[1152]: [session 
uid=119 pid=1152] Activating systemd to hand-off: service 
name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' requested by ':1.3' 
(uid=119 pid=1147 comm="/usr/libexec/tracker-extract-3")
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) No Layout section.  Using the first Screen section.
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) No screen section available. Using defaults.
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(**) |-->Screen "Default Screen Section" (0)
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(**) |   |-->Monitor ""
Jun 13 21:00:20 AnonymizedMachineName pipewire[1146]: mod.rt: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Jun 13 21:00:20 AnonymizedMachineName dbus-daemon[818]: [system] 
Activating via systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.25' (uid=119 pid=1148 
comm="/usr/bin/wireplumber")
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) No monitor specified for screen "Default Screen Section".
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
   Using a default monitor configuration.
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) Automatically adding devices
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) Automatically enabling devices
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) Automatically adding GPU devices
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) Automatically binding GPU devices
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(==) Max clients allowed: 256, resource mask: 0x1f
Jun 13 21:00:20 AnonymizedMachineName pipewire[1146]: mod.rt: found 
session bus but no portal
Jun 13 21:00:20 AnonymizedMachineName dbus-daemon[1152]: [session 
uid=119 pid=1152] Successfully activated service 'org.freedesktop.systemd1'
Jun 13 21:00:20 AnonymizedMachineName /usr/libexec/gdm-x-session[1154]: 
(WW) The directory "/usr/share/fonts/X11/cyrillic" 

Bug#1037532: [PATCH] Strip -Wl,-Bsymbolic-functions from LDFLAGS on Ubuntu

[Sergio Durigan Junior]

Source: git-annex
Version: 10.20230126-3
Severity: wishlist
Tags: patch

Hi,

Ref.: https://bugs.launchpad.net/ubuntu/+source/git-annex/+bug/2019992

git-annex unfortunately FTBFS on Ubuntu because of
-Wl,-Bsymbolic-functions.  The patch attached to this bug report
selectively strips this flag from LDFLAGS when building on Ubuntu.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

From 2232f3bf444c3e01d667cdd1ab7079cf31fc48f2 Mon Sep 17 00:00:00 2001
From: Sergio Durigan Junior 
Date: Tue, 13 Jun 2023 16:40:41 -0400
Subject: [PATCH] d/rules: Strip -Wl,-Bsymbolic-functions from LDFLAGS on
 Ubuntu.

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

diff --git a/debian/rules b/debian/rules
index eb63c7e7d..1d8d167a9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -27,6 +27,11 @@ export RELEASE_BUILD=1
 
 export ZSH_COMPLETIONS_PATH=/usr/share/zsh/vendor-completions
 
+ifeq (yes, $(shell dpkg-vendor --derives-from Ubuntu && echo yes))
+# See LP: #2019992
+export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic-functions
+endif
+
 %:
dh $@
 
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1037530: golang-github-gin-gonic-gin: CVE-2023-29401

[Salvatore Bonaccorso]

Source: golang-github-gin-gonic-gin
Version: 1.8.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/gin-gonic/gin/issues/3555
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-gin-gonic-gin.

CVE-2023-29401[0]:
| The filename parameter of the Context.FileAttachment function is not
| properly sanitized. A maliciously crafted filename can cause the
| Content-Disposition header to be sent with an unexpected filename
| value or otherwise modify the Content-Disposition header. For
| example, a filename of "setup.bat;x=.txt" will be sent as a
| file named "setup.bat". If the FileAttachment function is called
| with names provided by an untrusted source, this may permit an
| attacker to cause a file to be served with a name different than
| provided. Maliciously crafted attachment file name can modify the
| Content-Disposition header.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-29401
https://www.cve.org/CVERecord?id=CVE-2023-29401
[1] https://github.com/gin-gonic/gin/issues/3555
[2] 
https://github.com/gin-gonic/gin/commit/2d4bbec941551479b1fdf1e54ece03e6e82a7e72
 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037531: bookworm-pu: package boost1.81/1.81.0-5+deb12u1

[Sebastian Ramacher]

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

[ Reason ]
This upload fixes #1036986 by adding a dependency on the shared library
package to the -dev package. The same fix was applied as part of
1.81.0-5.1 in unstable.

[ Impact ]
Users are missing the corresponding shared library package when working
with the boost json library.

[ Tests ]
Double-checked that the binary packages have the correct dependencies.

[ Risks ]
Change is trivial.

[ 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 ]
The added dependency is the only change.

Cheers
-- 
Sebastian Ramacher
diff -Nru boost1.81-1.81.0/debian/changelog boost1.81-1.81.0/debian/changelog
--- boost1.81-1.81.0/debian/changelog   2023-05-14 22:52:13.0 +0200
+++ boost1.81-1.81.0/debian/changelog   2023-06-11 19:35:53.0 +0200
@@ -1,3 +1,10 @@
+boost1.81 (1.81.0-5+deb12u1) bookworm; urgency=medium
+
+  * debian/control: Add dependency on libboost-json1.81.0 for
+libboost-json1.81-dev (Closes: #1036986)
+
+ -- Sebastian Ramacher   Sun, 11 Jun 2023 19:35:53 +0200
+
 boost1.81 (1.81.0-5) unstable; urgency=medium
 
   * [0330664] Better handling of the upstream version number
diff -Nru boost1.81-1.81.0/debian/control boost1.81-1.81.0/debian/control
--- boost1.81-1.81.0/debian/control 2023-05-14 22:51:28.0 +0200
+++ boost1.81-1.81.0/debian/control 2023-06-11 19:35:53.0 +0200
@@ -1502,6 +1502,7 @@
 Depends: ${misc:Depends},
  libboost1.81-dev (= ${binary:Version}),
  libboost-container1.81-dev (= ${binary:Version}),
+ libboost-json1.81.0 (= ${binary:Version}),
  libboost-system1.81-dev (= ${binary:Version})
 Conflicts: libboost-json1.80-dev
 Description: C++ containers and algorithms that implement JSON

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74

[Dirk Eddelbuettel]

On 13 June 2023 at 13:15, Steve Langasek wrote:
| Control: reassign -1 r-cran-rstan r-cran-bh
| Control: found -1 r-cran-rstan/2.21.8-1
| 
| Unfortunately, at least in Ubuntu it appears the r-cran-rstan build still
| exhausts the 32-bit memory space even with boost 1.81.
| 
|   https://launchpad.net/ubuntu/+source/r-cran-rstan/2.21.8-1/+build/26010118

:-/

Not sure that it is fair to point at BH / Boost though.  Anyway.

CRAN no longer checks / compiles 32 bit so upstream may not care, but they
are a good team (if busy).  You could ping Ben, he is at
   Benjamin K Goodrich 

| It would be worth checking if there's a different result with the g++ in
| Debian.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1037529: ruby-jekyll-github-metadata: FTBFS with test failures when there's no network

[Steve Langasek]

Package: ruby-jekyll-github-metadata
Version: 2.15.0-1
Severity: serious
Tags: patch
Justification: Policy 4.9
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Hi Daniel,

ruby-jekyll-github-metadata has a test suite that relies on accessing the
github.com website at build time, so the package fails to build in an
offline environment.

[...]
Failures:

  1) Jekyll::GitHubMetadata::SiteGitHubMunger generating repo for org with 
displayname sets title to org's displayname
 Failure/Error: expect(site.config["title"]).to eql("Jekyll")

   expected: "Jekyll"
got: #

   (compared using eql?)

   Diff:
   @@ -1,4 +1,7 @@
   -"Jekyll"
   +#
 # ./spec/site_github_munger_spec.rb:177:in `block (3 levels) in '
 # 
/usr/share/rubygems-integration/all/gems/webmock-3.18.1/lib/webmock/rspec.rb:37:in
 `block (2 levels) in '
[...]

  
(https://launchpad.net/ubuntu/+source/ruby-jekyll-github-metadata/2.15.0-1/+build/26010086)

The attached patch filters out those source files whose tests fail when
offline.  I've uploaded it to Ubuntu to fix a build failure there.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ruby-jekyll-github-metadata-2.15.0/debian/ruby-tests.rake 
ruby-jekyll-github-metadata-2.15.0/debian/ruby-tests.rake
--- ruby-jekyll-github-metadata-2.15.0/debian/ruby-tests.rake   2023-02-09 
02:27:58.0 -0800
+++ ruby-jekyll-github-metadata-2.15.0/debian/ruby-tests.rake   2023-06-13 
13:27:27.0 -0700
@@ -2,7 +2,11 @@
 
 skip = [
   './spec/integration_spec.rb',
-  './spec/metadata_drop_spec.rb'
+  './spec/metadata_drop_spec.rb',
+  './spec/site_github_munger_spec.rb',
+  './spec/owner_spec.rb',
+  './spec/client_spec.rb',
+  './spec/repository_spec.rb'
 ]
 
 Gem2Deb::Rake::RSpecTask.new do |spec|

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sean Whitton]

Hello,

On Tue 13 Jun 2023 at 08:45PM +01, Luca Boccassi wrote:

> That essentially means it's fine to use diversions and ship releases
> using them, so that's exactly what will happen as per Murphy's law.
> [...]

I don't believe you've made any new arguments in the message to which
I'm replying.  Based on that, and the other activity this bug has seen,
I don't think it would be premature for us to start gathering formal
seconds of a version of your patch with my "should strongly prefer"
wording substituted for one part of it.
Would you like to prepare that patch, or shall one of Russ or I do so?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Ansgar]

On Tue, 2023-06-13 at 12:51 -0700, Russ Allbery wrote:
> I still am curious if it's safe to configure the same files in both
> tmpfiles.d and in the unit file, because it would make it much easier for
> those who want to support other init systems to do so.

Having this configured in two places would at least be confusing for
users: where would users need to change settings? In the unit file? In
the tmpfiles files? Both?

Ansgar

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Ansgar]

Matthew Garrett writes:
> With my non-CTTE hat on, I think this is a demonstration that Debian 
> *does* care about derivatives. It's important to ensure that derivatives 
> are aware of the subtle interactions between dpkg and usrmerge, 
> otherwise they may suffer from hard to diagnose issues on upgrades. The 
> message from dpkg says nothing about reverting to split-/usr, and 
> instead points at a wiki page. If our documentation on how to avoid 
> these issues is incomplete (ie, if we're only describing how to avoid it 
> by using split-/usr rather than describing the mitigations we've imposed 
> within Debian to avoid triggering the issues), perhaps a better approach 
> would be to improve that documentation? We don't benefit our users by 
> pretending there isn't a problem here.

Okay, I followed your recommendation and added a small warning to the
FAQ: https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff=78=79

Ansgar

Bug#1035883: Close out this report, please

[Jim Anderson]

I have looked at my other debian computers and the TMOUT setting works 
on them. I'm not sure why TMOUT does not work on my one computer, but it 
is not worth the effort to try to debug this issue for one system. 
Please consider this issue closed.



Jim A.

Bug#1024494: ITP: python3-fints -- python library for the FinTS protocol

[matthias . geiger1024]

Jun 13, 2023, 21:12 by b...@debian.org:

>
> Where is the ITP for mt-940?
>
> Please move the python-fints repository to the Python Team's namespace.
>
I haven't filed one yet because I ran into weird test failures with mt-940 and 
then kinda forgot about it tbh.
I will import fints this week. Thanks again for the sepaxml cleanup and upload.

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74

[Steve Langasek]

Control: reassign -1 r-cran-rstan r-cran-bh
Control: found -1 r-cran-rstan/2.21.8-1

Unfortunately, at least in Ubuntu it appears the r-cran-rstan build still
exhausts the 32-bit memory space even with boost 1.81.

  https://launchpad.net/ubuntu/+source/r-cran-rstan/2.21.8-1/+build/26010118

It would be worth checking if there's a different result with the g++ in
Debian.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Tue, 13 Jun 2023 at 20:51, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > That paragraph is in the context of StateDirectory= and
> > RuntimeDirectory=. These are unit files options, so it's up to
> > alternative init systems to provide alternative and integrate them in
> > the (eventual) init script, just as they are defined in the systemd
> > unit. I've mentioned those explicitly as you indicated earlier in this
> > thread:
>
> Ah!  Sorry, I did inded not understand the context correctly, and should
> have just not replied until I had a chance to read the context.  That's my
> fault.
>
> I agree with this statement with respect to systemd unit features.  This
> is a consequences of the fact that units are the preferred daemon
> configuration and package maintainers are allowed to use its features (GR
> 2019-002).  We should be encouraging them to use those features correctly
> and documenting how to do so, but that necessarily means that init scripts
> for use with other init systems will need to provide a version of the same
> feature in some other way.  We have had several GRs on this topic, and
> Policy does need to follow the outcome of those GRs unless someone
> overturns them with another GR.
>
> That being said:
>
> > Again, the rationale is: when there is a strong ownership model tied to
> > an individual service those are best as the lifecycle and permissions
> > are handled, when there is no owner or no specific owner or particular
> > metadata requirements then tmpfiles.d are best.
>
> I still am curious if it's safe to configure the same files in both
> tmpfiles.d and in the unit file, because it would make it much easier for
> those who want to support other init systems to do so.

As long as they both do the exact same thing, the one that runs last
is a no-op, I don't believe there would be any issue. But they have to
be kept in sync, not only w.r.t. directory name, but metadata too (ie:
ownership). See it this way: if the features provided by tmpfiles.d
and unit files (w.r.t. directories) were on a venn diagram, there
would be an intersection, yes, but there would not be a complete
overlap. There are things tmpfiles.d can do, that StateDirectory= and
friends cannot, and vice-versa.
In other words, for your stated goal of helping those who want to
support other init systems, it would only cover a subset of cases -
and these are real world cases, there are many services out there
making use of these features. We cannot be restricted, in terms of
unit files options, to what tmpfiles.d can provide, as that is not
realistic.

This is why I added that paragraph, indicating that other init systems
should provide equivalent functionality (and bear in mind I am not a
policy guru, so if 'should' is the wrong word I can change as needed,
it's perfectly fine as far as I'm concerned if other init systems
simply say, run everything as root and forget about security. It's
their choice what features they provide and I was not intending to
force them to do anything.).

Kind regards,
Luca Boccassi

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Matthew Garrett]

On Tue, Jun 13, 2023 at 09:14:53PM +0200, Ansgar wrote:
> On Tue, 2023-06-13 at 20:01 +0100, Matthew Garrett wrote:
> > After discussing this at our monthly meeting, we concluded that the 
> > technical committee isn't going to take action on this at the moment.
> > There's a legitimate technical consideration behind the warning, and 
> > it's necessary for derivatives to ensure that they handle the
> > associated scenarios properly.
> 
> Okay, I take that as "Debian doesn't care about derivatives". 
> Suggesting users to revert to split-/usr *will* break stuff for users
> once more code Debian assumes merged-/usr.

With my non-CTTE hat on, I think this is a demonstration that Debian 
*does* care about derivatives. It's important to ensure that derivatives 
are aware of the subtle interactions between dpkg and usrmerge, 
otherwise they may suffer from hard to diagnose issues on upgrades. The 
message from dpkg says nothing about reverting to split-/usr, and 
instead points at a wiki page. If our documentation on how to avoid 
these issues is incomplete (ie, if we're only describing how to avoid it 
by using split-/usr rather than describing the mitigations we've imposed 
within Debian to avoid triggering the issues), perhaps a better approach 
would be to improve that documentation? We don't benefit our users by 
pretending there isn't a problem here.

Bug#1035071: live-build: unable to boot Macs

[Rusty Grove]

I believe this can be closed. It worked for me after setting
"--bootloaders syslinux,grub-efi".

-- 




Confidentiality Notice: The material transmitted herein is intended 
only for the use of the addressee and may contain information that 
constitutes work product or is confidential and exempt from disclosure 
under applicable law. Distribution or copying of this communication or 
reliance upon its contents by unauthorized participants is strictly 
prohibited. If you have received this communication in error, please notify 
us immediately by telephone or email.

Bug#1035068: linux-image-6.1.0-7-amd64: occasionally no trackpad/trackpoint on resume from hibernate

[Rusty Grove]

I think this can be closed. Looking good without the systemd script.

On Mon, May 1, 2023 at 4:29 PM Diederik de Haas 
wrote:

> On Monday, 1 May 2023 20:40:11 CEST Rusty Grove wrote:
> > The script is something I did
>
> Can you test without that script then?
> IMO the proper way to deal with suspend/resume should be done by the
> system/
> kernel and it *could* be that your script is actually interfering with
> that.
>
> > I'm not quite sure what you mean by the sequence being in reverse...
>
> if you do in pre:
> unload A
> unload B
>
> Then you should do in post:
> load B
> load A
>
> but your script did
> load A
> load B
>
> HTH

-- 




Confidentiality Notice: The material transmitted herein is intended 
only for the use of the addressee and may contain information that 
constitutes work product or is confidential and exempt from disclosure 
under applicable law. Distribution or copying of this communication or 
reliance upon its contents by unauthorized participants is strictly 
prohibited. If you have received this communication in error, please notify 
us immediately by telephone or email.

Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

I can confirm that trashing the eln-cache and restarting emacs with
`markdown` in the block list works.

-- 
Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu.
Usenet dans ces conditions, c'est comme le web avec lynx, on prend
trop conscience du vide, c'est déprimant.
- JLC dans le Guide du linuxien pervers:
  "Coup de cafard..."

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Luca Boccassi  writes:

> That paragraph is in the context of StateDirectory= and
> RuntimeDirectory=. These are unit files options, so it's up to
> alternative init systems to provide alternative and integrate them in
> the (eventual) init script, just as they are defined in the systemd
> unit. I've mentioned those explicitly as you indicated earlier in this
> thread:

Ah!  Sorry, I did inded not understand the context correctly, and should
have just not replied until I had a chance to read the context.  That's my
fault.

I agree with this statement with respect to systemd unit features.  This
is a consequences of the fact that units are the preferred daemon
configuration and package maintainers are allowed to use its features (GR
2019-002).  We should be encouraging them to use those features correctly
and documenting how to do so, but that necessarily means that init scripts
for use with other init systems will need to provide a version of the same
feature in some other way.  We have had several GRs on this topic, and
Policy does need to follow the outcome of those GRs unless someone
overturns them with another GR.

That being said:

> Again, the rationale is: when there is a strong ownership model tied to
> an individual service those are best as the lifecycle and permissions
> are handled, when there is no owner or no specific owner or particular
> metadata requirements then tmpfiles.d are best.

I still am curious if it's safe to configure the same files in both
tmpfiles.d and in the unit file, because it would make it much easier for
those who want to support other init systems to do so.

-- 
Russ Allbery (r...@debian.org)  

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 13 Jun 2023 08:39:24 -0700 Russ Allbery  wrote:
> Sean Whitton  writes:
> 
> > I still find myself feeling queasy about adding this must-with-
caveat.
> > It feels like with the caveat you're trying to get something
between
> > "must" and "should", but then rather than build down from "must",
why
> > not build up from "should"?  I would like to propose:
> 
> > Maintainers should strongly prefer using other overriding
> > mechanisms, instead of diversions, whenever those other
mechanisms
> > are sufficient to accomplish the same goal.  In other words,
> > diversions in packages should be considered a last resort.
> 
> This sounds good to me.  The argument for building up from should
instead
> of down from must seems compelling.

That essentially means it's fine to use diversions and ship releases
using them, so that's exactly what will happen as per Murphy's law.

> I think that this accomplishes everything, in terms of guidance for
> our
> maintainers, that the must-with-caveat wording does.  But it avoids
> saying that using diversions over a native mechanism in and of itself
> renders a package RC-buggy, which doesn't seem right to me.
> 
> My own experience with diversions is limited, and so I accept that I
> may
> well be naively underestimating the badness of the edge cases.

Why would it not be RC-buggy? Not RC-buggy means we are happy if it
ships in a release. What does that buy us? Why wouldn't we want to
direct maintainers toward the better alternative, that is current
practice as of today, and instead let them reintroduce a mechanism that
we agree is inferior and was just removed from the distribution?

-- 
Kind regards,
Luca Boccassi


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

Bug#1037528: root[…]: ERROR: Interface --all does not seem to be present in the system

[AlMa]

Package: ifupdown
Version: 0.8.41

While examining the boot log, I discovered the following error message:

Jun 13 21:00:19 AnonymizedMachineName ModemManager[915]:  
ModemManager (version 1.20.4) starting in system bus...
Jun 13 21:00:19 AnonymizedMachineName NetworkManager[880]:  
[1686682819.8891] NetworkManager (version 1.42.4) is starting... 
(boot:AnonymizedLongID)
Jun 13 21:00:19 AnonymizedMachineName NetworkManager[880]:  
[1686682819.8891] Read config: /etc/NetworkManager/NetworkManager.conf 
(lib: no-mac-addr-change.conf)
Jun 13 21:00:19 AnonymizedMachineName systemd[1]: Started 
NetworkManager.service - Network Manager.
Jun 13 21:00:19 AnonymizedMachineName NetworkManager[880]:  
[1686682819.8919] bus-manager: acquired D-Bus service 
"org.freedesktop.NetworkManager"
Jun 13 21:00:19 AnonymizedMachineName systemd[1]: Starting 
NetworkManager-wait-online.service - Network Manager Wait Online...
Jun 13 21:00:19 AnonymizedMachineName NetworkManager[880]:  
[1686682819.9005] manager[0x563b69b6b000]: monitoring kernel firmware 
directory '/lib/firmware'.
Jun 13 21:00:19 AnonymizedMachineName NetworkManager[880]:  
[1686682819.9005] monitoring ifupdown state file '/run/network/ifstate'.
Jun 13 21:00:19 AnonymizedMachineName dbus-daemon[818]: [system] 
Activating via systemd: service name='org.freedesktop.hostname1' 
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.10' 
(uid=0 pid=880 comm="/usr/sbin/NetworkManager --no-daemon")
Jun 13 21:00:19 AnonymizedMachineName systemd[1]: Starting 
systemd-hostnamed.service - Hostname Service...
Jun 13 21:00:19 AnonymizedMachineName kernel: nouveau :65:00.0: DRM: 
allocated 2560x1440 fb: 0x20, bo 50cc3094
Jun 13 21:00:19 AnonymizedMachineName smartd[846]: Device: /dev/sda 
[SAT], is SMART capable. Adding to "monitor" list.
Jun 13 21:00:19 AnonymizedMachineName smartd[846]: Device: /dev/sda 
[SAT], state read from 
/var/lib/smartmontools/smartd.WDC_WD20EFAX_68FB5N0-WD_WX82A30EH19E.ata.state
Jun 13 21:00:19 AnonymizedMachineName smartd[846]: Device: /dev/nvme0, 
opened
Jun 13 21:00:19 AnonymizedMachineName smartd[846]: Device: /dev/nvme0, 
Samsung SSD 970 EVO 1TB, S/N:AnonymizedSerial, FW:AnonymizedFW, 1.00 TB
Jun 13 21:00:19 AnonymizedMachineName smartd[846]: Device: /dev/nvme0, 
is SMART capable. Adding to "monitor" list.
Jun 13 21:00:19 AnonymizedMachineName smartd[846]: Device: /dev/nvme0, 
state read from 
/var/lib/smartmontools/smartd.Samsung_SSD_970_EVO_1TB-AnonymizedSerial.nvme.state
Jun 13 21:00:19 AnonymizedMachineName smartd[846]: Monitoring 1 
ATA/SATA, 0 SCSI/SAS and 1 NVMe devices
Jun 13 21:00:19 AnonymizedMachineName systemd[1]: Started 
ModemManager.service - Modem Manager.
Jun 13 21:00:19 AnonymizedMachineName kernel: NET: Registered PF_QIPCRTR 
protocol family
Jun 13 21:00:19 AnonymizedMachineName root[986]: ERROR: Interface --all 
does not seem to be present in the system
Jun 13 21:00:19 AnonymizedMachineName ifup[986]: <27>Jun 13 21:00:19 
root[986]: ERROR: Interface --all does not seem to be present in the system
Jun 13 21:00:19 AnonymizedMachineName kernel: fbcon: nouveaudrmfb (fb1) 
is primary device
Jun 13 21:00:19 AnonymizedMachineName kernel: fbcon: Remapping primary 
device, fb1, to tty 1-63
Jun 13 21:00:19 AnonymizedMachineName ifup[989]: Device "--all" does not 
exist.
Jun 13 21:00:19 AnonymizedMachineName ifup[987]: WARNING: Cannot check 
for duplicate IP address in the network as the script could not find the 
ip address of --all. You can disable this test by setting DO_ARPING to 
'no' in /etc/default/network-test .


I searched for “--all”, but it all looks good:

# grep -r '\-\-all' /etc
/etc/network/if-up.d/20static-routes:if [ ${IFACE} = "--all" ]; then 
IFACE="[[:alnum:]]+"; fi
/etc/cron.d/mdadm:57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] 
&& [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all 
--idle --quiet; fi
/etc/X11/Xsession.d/95dbus_update-activation-env: 
dbus-update-activation-environment --verbose --systemd --all
/etc/init.d/mdadm:  log_daemon_msg "Restarting MD external metadata 
monitor" "mdmon --takeover --all"

/etc/init.d/mdadm:  $MDMON --takeover --all
/etc/init.d/networking: ifaces=$(for iface in $(ifquery --list 
--allow=hotplug)
/etc/init.d/networking: if [ -n "$(ifquery --list --exclude=lo)" 
] || [ -n "$(ifquery --list --allow=hotplug)" ]; then
/etc/init.d/acpid:# and a bug in modprobe --all --quiet which 
doesn't load all modules and

/etc/init.d/acpid:modprobe --all --use-blacklist $MODULES 2>/dev/null

What does this error message tell us, who is to blame, and how to repair 
this?


Is use NetworkManager and a WiFi connection, just in case it matters.

Gratefully,
AlMa

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Tue, 13 Jun 2023 10:55:38 -0700 Russ Allbery  wrote:

> >   Init systems other than ``systemd`` should allow providing the same
> >   functionality as appropriate for each system, for example managing the
> >   directories from the init script shipped by the package.
>
> This sort of requirement is exactly what we should be getting rid of
> by
> using systemd-tmpfiles uniformly instead.  We should be trying to
> minimize
> the extra work required to support non-systemd init systems in every
> package if we want non-systemd init systems to remain viable, because
> we
> know that work largely won't happen.
> 
> So, in other words, I haven't read the latest version of the patch
> yet,
> but if that wording is in there and I'm understanding the context
> correctly, I think that's the opposite of what we should be saying
> and we
> should take it out in favor of saying everything should just invoke
> systemd-tmpfiles or some equivalent implementation that uses the same
> configuration.
> 
> If other init systems arrange for systemd-tmpfiles to be run when
> appropriate (at boot, mostly), then there is no need to provide
> fallbacks
> via, for instance, init scripts with different functionality than the
> systemd units.  This is the whole reason why we did the work to
> package a
> standalone systemd-tmpfiles package that can be used regardless of
> the
> init system.

That paragraph is in the context of StateDirectory= and
RuntimeDirectory=. These are unit files options, so it's up to
alternative init systems to provide alternative and integrate them in
the (eventual) init script, just as they are defined in the systemd
unit. I've mentioned those explicitly as you indicated earlier in this
thread:

> However, reading that documentation, it sounds like most of the cases for
> other directories are handled by other systemd unit configuration
> directives.  We should say that explicitly here and reproduce the list of
> other directories that should be handled directly by the unit file if
> that's what we want people to do.

Again, the rationale is: when there is a strong ownership model tied to
an individual service those are best as the lifecycle and permissions
are handled, when there is no owner or no specific owner or particular
metadata requirements then tmpfiles.d are best.

-- 
Kind regards,
Luca Boccassi


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

Bug#1037527: intelrdfpmath: FTBFS in Ubuntu due to compiler strictness

[Steve Langasek]

Package: intelrdfpmath
Version: 2.0u2-8
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Dear maintainers,

The intelrdfpmath package is failing to build on all architectures in Ubuntu
because some test cases are being built with -Werror, and this is currently
stricter on Ubuntu than on Debian:

[...]
make[2]: Entering directory '/<>/TESTS'
x86_64-linux-gnu-gcc -O0 -D__intptr_t_defined -DLINUX -Werror 
-DDECIMAL_CALL_BY_REFERENCE=0 -DDECIMAL_GLOBAL_ROUNDING=0 
-DDECIMAL_GLOBAL_EXCEPTION_FLAGS=0 -UBID_BIG_ENDIAN -UHPUX_OS-o readtest 
readtest.c ../LIBRARY/libbidgcc000.a -lm 
readtest.c: In function ‘print_mismatch’:
readtest.c:1397:24: error: ‘ ’ directive writing 1 byte into a region of size 
between 0 and 1023 [-Werror=format-overflow=]
 1397 |   sprintf (line, "%s %s %s %s\n", func, op1, op2, op3);
  |^
readtest.c:1397:3: note: ‘sprintf’ output 5 or more bytes (assuming 3074) into 
a destination of size 1024
 1397 |   sprintf (line, "%s %s %s %s\n", func, op1, op2, op3);
  |   ^~~~
cc1: all warnings being treated as errors
make[2]: *** [makefile:126: readtest] Error 1
[...]

  (https://launchpad.net/ubuntu/+source/intelrdfpmath/2.0u2-8/+build/26010059)

While not currently a build failure in Debian, we can expect it to become
one with a future compiler update.

Unfortunately, using snprintf() to enforce bounds checking of the target
array doesn't avert this error, because format-truncation is also applied to
the buffer in snprintf().  But the attached patch lets the package build, by
both using snprintf() for more explict safety wrt buffer handling, and
turning off this particular error from gcc.

I've uploaded this to Ubuntu to let the package build there.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru intelrdfpmath-2.0u2/debian/patches/series 
intelrdfpmath-2.0u2/debian/patches/series
--- intelrdfpmath-2.0u2/debian/patches/series   2023-02-08 06:20:15.0 
-0800
+++ intelrdfpmath-2.0u2/debian/patches/series   2023-06-13 10:35:51.0 
-0700
@@ -3,3 +3,4 @@
 abs-declaration.patch
 wchar_t.patch
 mongo-inteldfp-s390x.patch
+snprintf-not-sprintf.patch
diff -Nru intelrdfpmath-2.0u2/debian/patches/snprintf-not-sprintf.patch 
intelrdfpmath-2.0u2/debian/patches/snprintf-not-sprintf.patch
--- intelrdfpmath-2.0u2/debian/patches/snprintf-not-sprintf.patch   
1969-12-31 16:00:00.0 -0800
+++ intelrdfpmath-2.0u2/debian/patches/snprintf-not-sprintf.patch   
2023-06-13 10:39:53.0 -0700
@@ -0,0 +1,38 @@
+Description: use snprintf not sprintf to make the compiler happy
+ With the gcc currently in Ubuntu, the package build fails because the
+ compiler can't tell whether this sprintf() will overflow the target.
+ Just use snprintf() to ensure that it can't.
+ .
+ But -Werror=format-truncation triggers *anyway* even on snprintf, so
+ disable this error as well.
+Author: Steve Langasek 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2023683
+Last-Update: 2023-06-13
+Forwarded: no
+
+Index: intelrdfpmath-2.0u2/TESTS/readtest.c
+===
+--- intelrdfpmath-2.0u2.orig/TESTS/readtest.c
 intelrdfpmath-2.0u2/TESTS/readtest.c
+@@ -1394,7 +1394,7 @@
+ 
+   printf ("// Input operand strings: %s %s %s\n", istr1, istr2, istr3);
+   fail_res++;
+-  sprintf (line, "%s %s %s %s\n", func, op1, op2, op3);
++  snprintf (line, 1024, "%s %s %s %s\n", func, op1, op2, op3);
+ printf ("// Ulp error: %e\n", ulp+ulp_add);
+   printf ("// Full input string: %s\n", full_line);
+ printf ("// Input string number: %d\n", line_counter);
+Index: intelrdfpmath-2.0u2/TESTS/makefile
+===
+--- intelrdfpmath-2.0u2.orig/TESTS/makefile
 intelrdfpmath-2.0u2/TESTS/makefile
+@@ -78,7 +78,7 @@
+ ifeq ($(CC),icc)
+ COPT = -Werror -Qoption,cpp,--extended_float_types
+ else
+-COPT = -Werror
++COPT = -Werror -Wno-error=format-truncation
+ endif
+ endif
+ 

Bug#1037526: bluetooth: Bluetooth dont work after bookworm upgrade

[Cláudio Brandão]

Package: bluetooth
Version: 5.66-1
Severity: normal
X-Debbugs-Cc: crau...@disroot.org

Dear Maintainer,

after the upgrade of Bullseye to Bookworm the bluetooth sevice don't works. I
can't connect bluetooth devices, because the service don't recognize them.

root@debian-dell-xps:/home/craudio# sudo service bluetooth status
● bluetooth.service - Bluetooth service
 Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; preset:
enabled)
 Active: active (running) since Tue 2023-06-13 16:33:13 -03; 3s ago
   Docs: man:bluetoothd(8)
   Main PID: 4663 (bluetoothd)
 Status: "Running"
  Tasks: 1 (limit: 9395)
 Memory: 808.0K
CPU: 24ms
 CGroup: /system.slice/bluetooth.service
 └─4663 /usr/libexec/bluetooth/bluetoothd

jun 13 16:33:13 debian-dell-xps bluetoothd[4663]:
src/main.c:btd_parse_kernel_experimental() Invalid KernelExperimental UUID:
false
jun 13 16:33:13 debian-dell-xps systemd[1]: Started bluetooth.service -
Bluetooth service.
jun 13 16:33:13 debian-dell-xps bluetoothd[4663]: Starting SDP server
jun 13 16:33:13 debian-dell-xps bluetoothd[4663]:
profiles/audio/vcp.c:vcp_init() D-Bus experimental not enabled
jun 13 16:33:13 debian-dell-xps bluetoothd[4663]: src/plugin.c:plugin_init()
Failed to init vcp plugin
jun 13 16:33:13 debian-dell-xps bluetoothd[4663]:
profiles/audio/mcp.c:mcp_init() D-Bus experimental not enabled
jun 13 16:33:13 debian-dell-xps bluetoothd[4663]: src/plugin.c:plugin_init()
Failed to init mcp plugin
jun 13 16:33:13 debian-dell-xps bluetoothd[4663]:
profiles/audio/bap.c:bap_init() D-Bus experimental not enabled
jun 13 16:33:13 debian-dell-xps bluetoothd[4663]: src/plugin.c:plugin_init()
Failed to init bap plugin
jun 13 16:33:13 debian-dell-xps bluetoothd[4663]: Bluetooth management
interface 1.22 initialized
root@debian-dell-xps:/home/craudio# nano /etc/bluetooth/main.conf


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

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

Versions of packages bluetooth depends on:
ii  bluez  5.66-1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
pn  bluez-cups   
pn  bluez-meshd  
ii  bluez-obexd  5.66-1

-- no debconf information

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Thorsten Glaser  writes:
> On Tue, 13 Jun 2023, Russ Allbery wrote:

>> namely if you're running anything in a chroot that needs directories
>> created in /tmp and /run, the chroot either needs to have a persistent
>> /tmp and /run or you have to arrange for it to run at least some init
>> scripts during boot.

> I very much disagree here. Both /tmp and /run are volatile, and for /tmp
> there usually even are cronjobs that delete old files, so programs that
> need anything in there must create it themselves at startup (via wrapper
> scripts if needed) if absent.

Ah, I think I understand what you're getting at.  You're talking about
using the init script of a daemon as this sort of wrapper script for
running it in a chroot, by invoking the init script outside of an init
system as root, but inside the chroot.

This works in some situations when the init script has no other
dependencies, but is going to start bit-rotting because init scripts are
less frequently tested and people are going to forget to add separate code
to handle cases that are already handled by tmpfiles.d or the systemd
unit.  The replacement is to first run systemd-tmpfiles --create in the
chroot and then manually run the init script as before.  That does add an
additional step to the (somewhat rare) case of running daemons in chroots,
but it has the advantage of not having to add runtime code to every
package to create directories (often incorrectly, without handling edge
cases), and it's not that different from what you'd need to do to start
daemons in chroots that have dependencies on other daemons.  (It would
also be easy to add to a generic wrapper script for starting a daemon in a
Debian chroot that does this for you.)

If you're just talking about programs that need temporary directories in
/tmp (not /run, which is owned by root) owned by the same user that the
program is running as, or programs that only run as root creating PID
files in /run, then that is unrelated to this bug so far as I can tell;
nothing we're talking about here changes that behavior, because nothing
needs to be pre-created.

-- 
Russ Allbery (r...@debian.org)  

Bug#1016815: Updating proofgeneral to recent upstream

[Patrice Duroux]

Package: proofgeneral
Version: 4.4.1~pre170114-1.2
Followup-For: Bug #1016815

Dear Maintainer,

Here is a patch for the d/watch file.

Thanks,
Patrice


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 proofgeneral depends on:
ii  emacs-gtk  1:28.2+1-15
ii  mmm-mode   0.5.8-4

proofgeneral recommends no packages.

Versions of packages proofgeneral suggests:
pn  proofgeneral-doc  
pn  prooftree 

-- no debconf information
diff --git a/proofgeneral-4.4.1~pre170114/debian/watch 
b/proofgeneral_4.4.1~pre170114.new/debian/watch
index 814a75f..fc369a6 100644
--- a/proofgeneral-4.4.1~pre170114/debian/watch
+++ b/proofgeneral_4.4.1~pre170114.new/debian/watch
@@ -1,7 +1,3 @@
-# See uscan(1) - scan/watch upstream sources for new releases of software
-
-# Compulsory line, this is a version 3 file
-version=3
-
-opts=uversionmangle=s/([.0-9]+)RC(\d)/$1rc$2/;s/([.0-9]+)((rc|pre)\d+)$/$1~$2/ 
\
-http://proofgeneral.inf.ed.ac.uk/releases/ProofGeneral-([0-9].*)\.(?:tgz|tbz2|tar\.(?:gz|bz2|xz))
+version=4
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+  https://github.com/ProofGeneral/PG/tags (?:.*?/)v?@ANY_VERSION@@ARCHIVE_EXT@

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Ansgar]

On Tue, 2023-06-13 at 20:01 +0100, Matthew Garrett wrote:
> After discussing this at our monthly meeting, we concluded that the 
> technical committee isn't going to take action on this at the moment.
> There's a legitimate technical consideration behind the warning, and 
> it's necessary for derivatives to ensure that they handle the
> associated scenarios properly.

Okay, I take that as "Debian doesn't care about derivatives". 
Suggesting users to revert to split-/usr *will* break stuff for users
once more code Debian assumes merged-/usr.

> While those underlying technical issues exist, we
> think it's premature for the committee to intervene on this specific 
> issue.

Okay, I guess the very long drama about this last year was not
sufficiently long and we did not discuss it in sufficient detail.

I'm a bit disappointed how the ctte appears to do as much as they can
to avoid deciding on this :-(

Ansgar

Bug#1002691: openssh-client: ssh-agent doesn't get autostarted under wayland

[Adrian Friedli]

Hi

On Mon, 27 Dec 2021 09:47:38 -0500 Michael Meier  
wrote:
> I'm using wayland with kde plasma on debian testing. Under wayland 
the ssh
> agent doesn't get auto started as it does under x-server. According 
to google
> that seems to be a known issue, but I couldn't find any bug report 
for debian.

> So here it is :-).

I'm using plasma wayland on bookworm and it works out of the box since 
at least half a year now :-)


user/ssh-agent.service specifies Before=graphical-session-pre.target
user/plasma-core.target specifies Wants=graphical-session-pre.target and 
After=graphical-session-pre.target

and these units are active on my machine:

| $ systemctl --user status graphical-session-pre.target
| ● graphical-session-pre.target - Session services which should run 
early before the graphical session is brought up
|  Loaded: loaded 
(/usr/lib/systemd/user/graphical-session-pre.target; static)

|  Active: active since Tue 2023-06-13 15:46:05 CEST; 4h 59min ago
|   Until: Tue 2023-06-13 15:46:05 CEST; 4h 59min ago
|    Docs: man:systemd.special(7)

| $ systemctl --user status plasma-core.target
| ● plasma-core.target - KDE Plasma Workspace Core
|  Loaded: loaded (/usr/lib/systemd/user/plasma-core.target; static)
|  Active: active since Tue 2023-06-13 15:46:10 CEST; 5h 11min ago
|   Until: Tue 2023-06-13 15:46:10 CEST; 5h 11min ago

I think this bug can be closed.

Cheers,
Adi

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Thorsten Glaser]

On Tue, 13 Jun 2023, Russ Allbery wrote:

>namely if you're running anything
>in a chroot that needs directories created in /tmp and /run, the chroot
>either needs to have a persistent /tmp and /run or you have to arrange for
>it to run at least some init scripts during boot.

I very much disagree here. Both /tmp and /run are volatile, and for /tmp
there usually even are cronjobs that delete old files, so programs that
need anything in there must create it themselves at startup (via wrapper
scripts if needed) if absent.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Thorsten Glaser  writes:

> what you described of course does not work for /tmp and /run.
> It is viable for /var/tmp etc.

Well, it does work for /tmp and /run as well as anything else can possibly
work for /tmp and /run inside a chroot, namely if you're running anything
in a chroot that needs directories created in /tmp and /run, the chroot
either needs to have a persistent /tmp and /run or you have to arrange for
it to run at least some init scripts during boot.

My experience is that mostly the sorts of stuff that needs specific
directories in /tmp and /run isn't run in a chroot, and when it is, often
they just use persistent /tmp and /run.

-- 
Russ Allbery (r...@debian.org)  

Bug#1037525: astromenace: update d/watch file

[Patrice Duroux]

Package: astromenace
Version: 1.3.2+repack-7
Severity: wishlist

Dear Maintainer,

You may consider the following MR:
https://salsa.debian.org/games-team/astromenace/-/merge_requests/2
for that.

Thanks,
Patrice


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 astromenace depends on:
ii  astromenace-data-src1.3.2+repack-3
ii  fonts-dejavu-core   2.37-6
ii  fonts-freefont-ttf  20211204+svn4273-2
ii  fonts-liberation1:1.07.4-11
ii  fonts-linuxlibertine5.3.0-6
ii  libalut01.1.0-6
ii  libc6   2.36-9
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgcc-s1   13.1.0-5
ii  libgl1  1.6.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libopenal1  1:1.19.1-2
ii  libsdl1.2debian 1.2.15+dfsg2-8
ii  libstdc++6  13.1.0-5
ii  libvorbisfile3  1.3.7-1
ii  libx11-62:1.8.4-2
ii  libxinerama12:1.1.4-3
ii  xz-utils5.4.1-0.2

astromenace recommends no packages.

astromenace suggests no packages.

-- no debconf information

Bug#922815: insserv: FATAL: service mountkernfs has to be enabled to use service keyboard-setup.sh

[Thomas Deutschmann]

On 2023-06-13 20:10, Thorsten Glaser wrote:

I personally tend to use:
apt-get --purge dist-upgrade

This takes care of purging the configuration files of packages
that get removed (take care, of course, to not let it remove
things you still need, like the old PostgreSQL version until
the cluster(s) have migrated).


Thank you, I didn't know about mixing "dist-upgrade" command with "purge"!



Now the system is really in a clean state with only debian12 packages
installed.


Is it? Remember that apt doesn’t know about leftover conffiles.

Try: dpkg -l | grep -v ^ii | cut -c 1-$COLUMNS


Yes, it is :)

I run similar commands during the cleanup when we noticed the gnutls 
problem. All non debian12 packages are now purged. Just to be sure that 
there really isn't any leftover or manually added file which could 
interfere in some unexpected ways I even feeded all files through dpkg.



--
Regards,
Thomas

Bug#1037524: libortp: still missing -lbctoolbox (was: Bug#994437: fixed in ortp 1:5.0.37-1)

[Frank Heckenbach]

Package: libortp-dev
Version: 1:5.1.64-2
Severity: normal


> This is an automatic notification regarding your Bug report
> which was filed against the libortp-dev package:
>
> #994437: libortp: missing -lbctoolbox
>
> It has been closed by Debian FTP Masters 
> (reply to Bernhard Schmidt ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters  pmas...@ftp-master.debian.org> (reply to Bernhard Schmidt  >) by
> replying to this email.

It's actually not fixed!

You added a "Requires.private" in the .pc, but that doesn't help.
"Requires" is required (sic!) because a program that links to ortp
apparently must also link to bctoolbox.

My original test program still applies:

% cat a.c
#include 

int main ()
{
  ortp_init ();
  ortp_set_log_level_mask (ORTP_LOG_DOMAIN, ORTP_FATAL);
}
% gcc a.c  `pkg-config --cflags --libs ortp`
/usr/bin/ld: /tmp/ccnMlrim.o: undefined reference to symbol 
'bctbx_set_log_level_mask'
/usr/bin/ld: /lib/x86_64-linux-gnu/libbctoolbox.so.1: error adding symbols: DSO 
missing from command line
collect2: error: ld returned 1 exit status
% gcc a.c  `pkg-config --cflags --libs ortp` -lbctoolbox
% ./a.out

Bug#1037502: missing ipv4/ipv6 commands

[Thorsten Alteholz]

On 13.06.23 17:00, Daniel Baumann wrote:

Unfortunately the debian package does not install /usr/bin/ipv4 or
/usr/bin/ipv6. Assuming you did that deliberately  (...)


*blush* no, I just forgot them :-(.

  Thorsten

Bug#1037523: gnome-shell-extension-pixelsaver doesn't work at all

[Al Ma]

Package: gnome-shell-extension-pixelsaver
Version: 1.30-1
Severity: grave
Installing and then activating gnome-shell-extension-pixelsaver has no effect. 
When the lowest buttom in the attached screenshot is clicked, no visible effect 
is observed. In the journallog I see this (up to the anonymized user name and 
machine name):
Jun 13 20:08:56 AnonymizedMachineName gnome-shell[2573]: [pixel-saver]: 
'appmenu' is not a valid button. Jun 13 20:08:56 AnonymizedMachineName 
gnome-shell[2573]: Usage of object.actor is deprecated for AppMenuButton 
get@resource:///org/gnome/shell/ui/environment.js:387:29 
enable@/usr/share/gnome-shell/extensions/pixel-sa...@deadalnix.me/app_menu.js:212:2
 
enable@/usr/share/gnome-shell/extensions/pixel-sa...@deadalnix.me/extension.js:62:10
 _callExtensionEnable@resource:///org/gnome/shell/ui/extensionSystem.js:184:32 
_onEnabledExtensionsChanged/<@resource:///org/gnome/shell/ui/extensionSystem.js:529:35
 
_onEnabledExtensionsChanged@resource:///org/gnome/shell/ui/extensionSystem.js:529:14
 
createCheckedMethod/<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:686:46
 enableExtension@resource:///org/gnome/shell/ui/extensionSystem.js:211:29 
EnableExtension@resource:///org/gnome/shell/ui/shellDBus.js:447:38 
_handleMethodCall@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:324:38
 _wrapJSObject/<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:401:34 
Jun 13 20:08:56 AnonymizedMachineName gnome-shell[2573]: Jun 13 20:08:56 
AnonymizedMachineName gnome-shell[2573]: Jun 13 20:08:56 AnonymizedMachineName 
gnome-shell[2573]: [pixel-saver]: Can't find original state for 
AnonymizedUserName@AnonymizedMachineName: ~ with id 0x2800020
The package is useless (on my machine, it fails to work in a visible way), 
hence the raised severity. I use  Debian stable 12 “bookworm”, gnome 1:42+1 
with X11.  The package should be repaired or removed from Debian altogether.
Gratefully,
AlMa

Bug#1037522: iptux crashes when receiving a file

[Chris Frey]

Package: iptux
Version: 0.7.6-4

I installed iptux for the first time on two systems, one running
Debian Buster (0.7.6-1), the other running Debian Bullseye. (0.7.6-4)

I ran the Buster version in xfce4 from the applications menu.

On Bullseye, I accessed it through an xpra session, and ran iptux
from the command line.

I sent a few simple messages back and forth, and then attempted to
send a file from Buster to Bullseye.  The Bullseye version crashed
with this message:

cdfrey:~$ iptux &
[3] 1361101
cdfrey:~$ 
** (iptux:1361101): WARNING **: 13:56:45.513: config file 
/home/cdfrey/.iptux/config.json not found

(iptux:1361101): GLib-GObject-CRITICAL **: 13:57:28.425: g_object_get_data: 
assertion 'G_IS_OBJECT (object)' failed
Missing chrome or resource URL: resource://gre/modules/UpdateListener.jsm
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
corrupted double-linked list

It's not that important to me, but I figured I'd be a good Debian citizen
and at least report it. :-)

- Chris

Bug#922815: insserv: FATAL: service mountkernfs has to be enabled to use service keyboard-setup.sh

[Thorsten Glaser]

On Tue, 13 Jun 2023, Thomas Deutschmann wrote:

>> You did upgrade to Debian 10, then Debian 11, in the middle, right?
>
> Yes, of course.

OK.

>  apt-get upgrade
>  apt-get full-upgrade

I personally tend to use:
   apt-get --purge dist-upgrade

This takes care of purging the configuration files of packages
that get removed (take care, of course, to not let it remove
things you still need, like the old PostgreSQL version until
the cluster(s) have migrated).

>  apt-get autoremove

Again, add --purge here and take care (though etckeeper helps).

> Now the system is really in a clean state with only debian12 packages
> installed.

Is it? Remember that apt doesn’t know about leftover conffiles.

Try: dpkg -l | grep -v ^ii | cut -c 1-$COLUMNS

This ought to show only the header and perhaps “held” packages
(first column “hi”); if it also shows “rc” in the first column
then you have leftover conffiles, which indeed can cause trouble;
run “dpkg --purge pkgname pkgname…” to clean them up.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Thorsten Glaser]

On Tue, 13 Jun 2023, Russ Allbery wrote:

>Thorsten Glaser  writes:
>
>> Therefore I belive that Policy ought to *not* recommend any solution
>> that depends on starting dæmons or init scripts to create temporary
>> files/directories that are necessary for programs to work.
>
>This is handled by this proposal, no?  That's the point of requiring
>integration with maintainer scripts (via triggers or direct invocation).
>My understanding is that this is exactly what dh_installtmpfiles already
>does, via generating an explicit call to systemd-tmpfiles --create.

Hmm, that sounds okay-ish, except…

>Or am I missing something?

what you described of course does not work for /tmp and /run.
It is viable for /var/tmp etc.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1037521: false positive NONVERBOSE BUILD for rust code in Python modules

[Jelmer Vernooij]

Package: blhc
Severity: minor

blhc reports false positives when analyzing build logs for Python
modules that include rust code.

Example:

$ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS} 
${WORKING_DIR}/*.build || [ $? -eq 1 ]
75:NONVERBOSE BUILD:Compiling autocfg v1.1.0
76:NONVERBOSE BUILD:Compiling proc-macro2 v1.0.60
79:NONVERBOSE BUILD:Compiling target-lexicon v0.12.3
82:NONVERBOSE BUILD:Compiling unicode-ident v1.0.0
84:NONVERBOSE BUILD:Compiling quote v1.0.27
90:NONVERBOSE BUILD:Compiling syn v1.0.109
92:NONVERBOSE BUILD:Compiling pyo3-build-config v0.19.0
98:NONVERBOSE BUILD:Compiling once_cell v1.17.0
101:NONVERBOSE BUILD:Compiling libc v0.2.146
104:NONVERBOSE BUILD:Compiling serde_derive v1.0.152
108:NONVERBOSE BUILD:Compiling pyo3-ffi v0.19.0
110:NONVERBOSE BUILD:Compiling lock_api v0.4.9
112:NONVERBOSE BUILD:Compiling parking_lot_core v0.9.3
114:NONVERBOSE BUILD:Compiling serde v1.0.152
116:NONVERBOSE BUILD:Compiling ryu v1.0.2
123:NONVERBOSE BUILD:Compiling memoffset v0.6.5
125:NONVERBOSE BUILD:Compiling indexmap v1.9.2
127:NONVERBOSE BUILD:Compiling smallvec v1.9.0
129:NONVERBOSE BUILD:Compiling cfg-if v1.0.0
131:NONVERBOSE BUILD:Compiling scopeguard v1.1.0
138:NONVERBOSE BUILD:Compiling pyo3-macros-backend v0.19.0
141:NONVERBOSE BUILD:Compiling pyo3 v0.19.0
143:NONVERBOSE BUILD:Compiling serde_json v1.0.87
145:NONVERBOSE BUILD:Compiling hashbrown v0.12.3
148:NONVERBOSE BUILD:Compiling unindent v0.1.8
150:NONVERBOSE BUILD:Compiling linked-hash-map v0.5.6
152:NONVERBOSE BUILD:Compiling yaml-rust v0.4.5
154:NONVERBOSE BUILD:Compiling indoc v1.0.4
159:NONVERBOSE BUILD:Compiling pyo3-macros v0.19.0
162:NONVERBOSE BUILD:Compiling parking_lot v0.12.1
166:NONVERBOSE BUILD:Compiling itoa v1.0.1
170:NONVERBOSE BUILD:Compiling serde_yaml v0.8.26
172:NONVERBOSE BUILD:Compiling lintian-brush v0.148.0 
(/builds/jelmer/lintian-brush/debian/output/source_dir)
174:NONVERBOSE BUILD:Compiling lintian-brush-py v0.0.0 
(/builds/jelmer/lintian-brush/debian/output/source_dir/lintian-brush-py)

https://salsa.debian.org/jelmer/lintian-brush/-/jobs/4307243


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

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

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

blhc recommends no packages.

blhc suggests no packages.

Bug#1037520: morris: update d/watch file

[Patrice Duroux]

Package: morris
Version: 0.2-6
Severity: wishlist

Dear Maintainer,

You may consider the following MR:
https://salsa.debian.org/games-team/morris/-/merge_requests/3
for that.

Thanks,
Patrice


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 morris depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libgcc-s113.1.0-5
ii  libglib2.0-0 2.76.3-1
ii  libgtk2.0-0  2.24.33-2
ii  libstdc++6   13.1.0-5

morris recommends no packages.

morris suggests no packages.

-- no debconf information

Bug#1037519: clanlib: update d/watch file

[Patrice Duroux]

Source: clanlib
Version: 1.0~svn3827-8
Severity: wishlist

Dear Maintainer,

You may consider the following MR:
https://salsa.debian.org/games-team/clanlib/-/merge_requests/2
for that.

Regards,
Patrice


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

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

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Ansgar  writes:
> On Tue, 2023-06-13 at 18:36 +0200, Marco d'Itri wrote:
>> On Jun 13, Bill Allombert  wrote:

>>> Conversely, sometimes I need to use chroots to test init scripts.
>>> start-stop-daemon should not refuse to run in a chroot if policy-
>>> rc.d allows
>>> it.

>> I suggest that you try systemd-nspawn for this purpose.

> Or podman or docker or various other things.

> Plain chroots and an unclean environment which violates various
> assumptions system startup scripts make are not a great way to test
> stuff.

Unless I'm very mistaken about how dh_installtmpfiles and systemd-tmpfiles
works (possible, I guess), I don't think we need to have this argument in
this bug.  If I am right in assuming that nothing about this proposal will
change how chroots work, arguing with people about why they use chroots is
just going to add heat without any light.

-- 
Russ Allbery (r...@debian.org)  

Bug#1037518: openjazz: update d/watch file

[Patrice Duroux]

Package: openjazz
Version: 20190106-3
Severity: wishlist

Dear Maintainer,

You may consider the following MR:
https://salsa.debian.org/games-team/openjazz/-/merge_requests/3
for that.

Regards,
Patrice


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 openjazz depends on:
ii  libc62.36-9
ii  libgcc-s1 [libgcc1]  13.1.0-5
ii  libmodplug1  1:0.8.9.0-3
ii  libsdl1.2debian  1.2.15+dfsg2-8
ii  libstdc++6   13.1.0-5
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages openjazz recommends:
ii  game-data-packager  73

openjazz suggests no packages.

-- no debconf information

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Mark Hindley  writes:

> I remain much less convinced that there is a consensus for requiring
> packages to use tmpfiles.d(5) for /var, /tmp and maybe /etc.

Well, for /tmp, /var/tmp, and /run, I think this is the right approach,
unless there is some other systemd unit configuration that is even better.
This is also already what we're doing across the archive, which is a
pretty strong indication of consensus.  The alternative for /tmp,
/var/tmp, and /run is to add manual mkdirs to systemd units or init
scripts (that normally then have to be run as root, even when the daemon
doesn't), and that's clearly inferior and a poor technical approach.

Given that, if we want to keep everything working with non-systemd init
systems, they're pretty much going to have to invoke systemd-tmpfiles
during boot or things are going to start breaking just because they're not
tested (or some equivalent; there was some discussion of adding support
for the tmpfiles.d format directly to dpkg so that dpkg is also aware of
what package owns these files).

I am considerably more dubious about /var and /etc in general.  I don't
think there's a consensus for managing files or directories there with
systemd-tmpfiles, and most packages just ship the directories in the
package.  I understand that this is part of the overall goal of making
Linux distributions only ship files in /usr, but the project as a whole
has not signed on to that goal yet.

However, what's being proposed here is something much narrower: we should
not be managing directories in those paths *with mkdir in maintainer
scripts*, and instead should use systemd-tmpfiles in that specific case.
For those rare cases where packages are manually creating directories in
shell instead of shipping them in the package for whatever reason,
switching to systemd-tmpfiles feels like an obviously correct improvement
as long as the maintainer script arranges for systemd-tmpfiles to be
invoked so that it will create the directories.  It allows us to move
something from imperative maintainer scripts that are very hard to analyze
to declarative files that have well-understood semantics and handle all
the edge cases that human-written maintainer scripts tend not to manage.
This change should also be invisible to other init systems since the files
and directories are still being created by the maintainer scripts as
always, just using a different program.

However, the really compelling use of systemd-tmpfiles is for /tmp, /run,
and /var/tmp, replacing all the various hacks and workarounds we have had
for decades to create those files during boot, at least in the cases where
the functionality isn't handled directly by a systemd unit.  It's that
behavior that I think deserves a should.

For the persistent directory case in /var and /etc, I think "encouraged"
(Policy advice) is more appropriate at this point, since creating the
directories in maintainer scripts is not *broken*, and we should not be
making those packages instantly buggy.

> The recent thread on debian-devel demonstrated a range of
> opinion. Thorsten and Bill have just raised valid points about chroots.

I don't understand the point about chroots.  It seemed to be based on a
fundmental misunderstanding of how systemd-tmpfiles works?  Thorsten
seemed to think it was a daemon; it's not.  It's essentially a fancy
version of mkdir + chmod + chown plus some other things that supports a
declarative syntax for specifying what directories should exist.  A good
analogy for a different type of operation would be start-stop-daemon
(except systemd-tmpfiles supports declarative configuration, which is even
better).

> Reading the proposed text as somebody who is particularly interested in
> non-systemd systems, I am struck by the inconsistency between

>   Init systems other than ``systemd`` should allow providing the same
>   functionality as appropriate for each system, for example managing the
>   directories from the init script shipped by the package.

This sort of requirement is exactly what we should be getting rid of by
using systemd-tmpfiles uniformly instead.  We should be trying to minimize
the extra work required to support non-systemd init systems in every
package if we want non-systemd init systems to remain viable, because we
know that work largely won't happen.

So, in other words, I haven't read the latest version of the patch yet,
but if that wording is in there and I'm understanding the context
correctly, I think that's the opposite of what we should be saying and we
should take it out in favor of saying everything should just invoke
systemd-tmpfiles or some equivalent implementation that uses the same
configuration.

If other init systems arrange for systemd-tmpfiles to be run when
appropriate (at boot, mostly), then there is no need to provide fallbacks
via, for instance, init scripts with different functionality than the
systemd units.  This is the whole reason why we did the work to package a
standalone 

Bug#1037517: console-setup-linux: wrong char for * A

[Jakub Wilk]

Package: console-setup-linux
Version: 1.221

In X,  * A produces "Å" (U+00C5 LATIN CAPITAL LETTER A WITH 
RING ABOVE).


But on the console, I get "Ĺ" (U+0139 LATIN CAPITAL LETTER L WITH ACUTE) 
instead.



-- System Information:

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.65.2
ii  initscripts 3.06-4
ii  kbd 2.5.1-1+b1
ii  keyboard-configuration  1.221

console-setup-linux recommends no packages.

Versions of packages console-setup-linux suggests:
ii  console-setup  1.221

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.82
ii  liblocale-gettext-perl  1.07-5
ii  xkb-data2.35.1-1

Versions of packages console-setup depends on:
ii  debconf [debconf-2.0]   1.5.82
ii  keyboard-configuration  1.221
ii  xkb-data2.35.1-1

Versions of packages console-setup suggests:
ii  locales2.36-9
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages console-setup-linux is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.5.1-1+b1
ii  systemd   252.6-1

/etc/console-setup/remap.inc changed [not included]

-- debconf information:
  keyboard-configuration/layoutcode: pl
  keyboard-configuration/modelcode: pc105
  keyboard-configuration/store_defaults_in_debconf_db: true
  keyboard-configuration/other:
  keyboard-configuration/switch: No temporary switch
  keyboard-configuration/unsupported_layout: true
* keyboard-configuration/altgr: The default for the keyboard layout
* keyboard-configuration/ctrl_alt_bksp: true
  keyboard-configuration/unsupported_options: true
  console-setup/guess_font:
* keyboard-configuration/unsupported_config_options: true
* console-setup/codeset47: . Combined - Latin; Slavic Cyrillic; Greek
  console-setup/store_defaults_in_debconf_db: true
* console-setup/fontsize-fb47: 8x16
* console-setup/fontface47: TerminusBold
* keyboard-configuration/variant: Polish
  keyboard-configuration/toggle: No toggling
* keyboard-configuration/layout: Poland
  console-setup/fontsize-text47: 8x16
  console-setup/framebuffer_only:
  debian-installer/console-setup-udeb/title:
  keyboard-configuration/variantcode:
* console-setup/charmap47: UTF-8
  console-setup/codesetcode: Uni2
  keyboard-configuration/xkb-keymap: pl
  console-setup/use_system_font:
* keyboard-configuration/compose: Menu key
  keyboard-configuration/optionscode: 
compose:menu,terminate:ctrl_alt_bksp,caps:escape
* keyboard-configuration/model: Generic 105-key PC
  keyboard-configuration/unsupported_config_layout: true
  console-setup/fontsize: 8x16

--
Jakub Wilk

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Ansgar]

On Tue, 2023-06-13 at 18:36 +0200, Marco d'Itri wrote:
> On Jun 13, Bill Allombert  wrote:
> 
> > Conversely, sometimes I need to use chroots to test init scripts.
> > start-stop-daemon should not refuse to run in a chroot if policy-
> > rc.d allows
> > it.
> I suggest that you try systemd-nspawn for this purpose.
> 

Or podman or docker or various other things.

Plain chroots and an unclean environment which violates various
assumptions system startup scripts make are not a great way to test
stuff.

Ansgar

Bug#1016903: Does this bug affect Bookworm on AMD64?

[Alex Lieflander]

I’m sorry if this is the wrong place to post this, but I’m still trying to 
figure everything out.

Am I correct in concluding that this bug doesn’t affect packages compiled for 
Bookworm on AMD64? What about packages on AMD64 (like libpcre2-32-0) with 
32-bit runtimes/versions/ABIs or packages (like fdupes) that depend on them?

Bug#1037516: ircd-hybrid hates winbindd users

[Joshua Hudson]

Package: ircd-hybrid
Version: 1:8.2.43+dfsg.1-1
Severity: important
Tags: newcomer upstream

Dear Maintainer,

When connecting to ircd-hybrid on localhost, users from a Windows domain get 
kicked out with invalid user.

I tracked this down to the source code; ircd-hybrid believes that \ is an 
invalid character in username
while ident reports the full username including the \ character in the middle.

Problem exists upstream.

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 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 ircd-hybrid depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9
ii  libcrypt1  1:4.4.33-2
ii  libgnutls303.7.9-2
ii  libltdl7   2.4.7-5
ii  lsb-base   11.6
ii  openssl3.0.9-1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages ircd-hybrid recommends:
ii  whois  5.5.17

Versions of packages ircd-hybrid suggests:
pn  anope  

-- Configuration Files:
/etc/ircd-hybrid/cert.cnf [Errno 13] Permission denied: 
'/etc/ircd-hybrid/cert.cnf'
/etc/ircd-hybrid/ircd.conf [Errno 13] Permission denied: 
'/etc/ircd-hybrid/ircd.conf'
/etc/ircd-hybrid/ircd.motd [Errno 13] Permission denied: 
'/etc/ircd-hybrid/ircd.motd'

-- debconf information:
  ircd-hybrid/upgrade_secure_links_warn: true
  ircd-hybrid/automatically_fix_config: false
  ircd-hybrid/restart_on_upgrade: true

Bug#1037515: openssh-client: ssh-agent does not start ssh-askpass for notifications under wayland

[Adrian Friedli]

Package: openssh-client
Version: 1:9.2p1-2
Severity: normal
X-Debbugs-Cc: a...@koalatux.ch

Dear Maintainer,

I am using a hardware token supporting FIDO2 for SSH. The hardware token
requires presence for every SSH connection. The ssh-agent starts
ssh-askpass to notify the user that presence is required. This works
well with X11, but with wayland no notification appears, but touching
the hardware token still works and the SSH connection can still be
established successfully.

Looking into the code[1] reveals that ssh-agent is checking for the
DISPLAY environment variable, otherwise it won't even start ssh-askpass.

As a work-around I now start ssh-agent with the env variable
SSH_ASKPASS_REQUIRE set to "force", I achieved this by creating the file
/etc/systemd/user/ssh-agent.service.d/override.conf with these two lines
as content:

[Service]
Environment="SSH_ASKPASS_REQUIRE=force"

At least with ksshaskpass as the selected alternative for ssh-askpass
this works.

Kind regards,
Adi


[1]: https://sources.debian.org/src/openssh/1%3A9.2p1-2/readpass.c/#L264-L269


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

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

Versions of packages openssh-client depends on:
ii  adduser   3.134
ii  libc6 2.36-9
ii  libedit2  3.1-20221030-2
ii  libfido2-11.12.0-2+b1
ii  libgssapi-krb5-2  1.20.1-2
ii  libselinux1   3.4-1+b6
ii  libssl3   3.0.9-1
ii  passwd1:4.13+dfsg1-1+b1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.2-1

Versions of packages openssh-client suggests:
pn  keychain   
ii  ksshaskpass [ssh-askpass]  4:5.27.5-2
pn  libpam-ssh 
pn  monkeysphere   

-- Configuration Files:
/etc/ssh/ssh_config changed [not included]

-- no debconf information

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Mark Hindley]

Sean,

On Tue, Jun 13, 2023 at 05:15:15PM +0100, Sean Whitton wrote:
> > In principle and just looking at the dependencies this seems a viable
> > solution.  It is very similar to the way we handle the logind and
> > default-logind virtual packages.
> 
> Thank you for reviewing.  Do you have a rough idea of how long it would
> be until you could confirm that this is viable, and implement it in sid?

There is a new upstream version of elogind[1] that is already packaged in
Devuan[2] although that uncovered up an upstream issue that I am waiting to be
resolved[3]. So, maybe by the end of this month?

However, that is only considering whether the packaging and dependencies can be
made to work (like Simon McVittie, I think they probably can).

I remain much less convinced that there is a consensus for requiring packages to
use tmpfiles.d(5) for /var, /tmp and maybe /etc. The recent thread on
debian-devel demonstrated a range of opinion. Thorsten and Bill have just raised
valid points about chroots.

So, whilst I am happy to test the dependency changes in elogind, enshrining this
as a 'should' in the Policy now seems, at least, premature.

Reading the proposed text as somebody who is particularly interested in
non-systemd systems, I am struck by the inconsistency between

  Init systems other than ``systemd`` should allow providing the same
  functionality as appropriate for each system, for example managing the
  directories from the init script shipped by the package.

and the fact that we no longer expect packages to include init scripts alongside
their systemd units and even accept their removal, even if other interested
people offer to maintain them and provide tested patches.

With best wishes

Mark

[1]  https://qa.debian.org/cgi-bin/watch?pkg=elogind

[2]  
https://pkginfo.devuan.org/cgi-bin/package-query.html?c=package=elogind=252.9-1~rc1

[3]  https://github.com/elogind/elogind/issues/258

Bug#932423: flameshot: Copy function of flameshot not working under Wayland

[Alexander Günthör]

Package: flameshot
Version: 12.1.0-2
Followup-For: Bug #932423

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.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages flameshot depends on:
ii  hicolor-icon-theme  0.17-2
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libqt5core5a5.15.8+dfsg-11
ii  libqt5dbus5 5.15.8+dfsg-11
ii  libqt5gui5  5.15.8+dfsg-11
ii  libqt5network5  5.15.8+dfsg-11
ii  libqt5svg5  5.15.8-3
ii  libqt5widgets5  5.15.8+dfsg-11
ii  libstdc++6  12.2.0-14

Versions of packages flameshot recommends:
ii  grim1.4.0+ds-2
ii  xdg-desktop-portal-gtk  1.14.1-1
ii  xdg-desktop-portal-kde  5.27.5-2

Versions of packages flameshot suggests:
ii  ca-certificates  20230311
ii  openssl  3.0.9-1

-- no debconf information

Bug#1015003: transmission-daemon: possible memory leaks in crypto-utils-openssl.c

[Pavel Kreuzt]

Package: transmission-daemon
Followup-For: Bug #1015003
X-Debbugs-Cc: pkre...@gmail.com

Recently upgraded from Bullseye to Bookworm and hit what I think is this issue. 
Transmission-daemon gets killed by OOM every few hours. To be fair, I have a 
really huge amount of torrents, but it was running fine on the older version. 
Now it consumes every bit of RAM (8GB available) it has access to. In a torrent 
seedbox like this, it is completely unusable. Will version 4.0 reach stable or 
should i look into backports?


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

Kernel: Linux 6.1.0-9-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 transmission-daemon depends on:
ii  adduser3.134
ii  libc6  2.36-9
ii  libcurl4   7.88.1-10
ii  libevent-2.1-7 2.1.12-stable-8
ii  libminiupnpc17 2.2.4-1+b1
ii  libnatpmp1 20150609-7.1+b2
ii  libssl33.0.9-1
ii  libsystemd0252.6-1
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4
ii  transmission-common3.00-2.1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages transmission-daemon recommends:
ii  transmission-cli  3.00-2.1+b1

transmission-daemon suggests no packages.

-- Configuration Files:
/etc/transmission-daemon/settings.json [Errno 13] Permiso denegado: 
'/etc/transmission-daemon/settings.json'

-- no debconf information

Bug#1037514: gnome-video-effects: The flip effect isnt work due to property method being deprecated

[Phelipe Matheus Couto de Aguiar]

Package: gnome-video-effects
Version: 0.5.0
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Dear Maintainer, I was using Cheese and the main effect should be
the flip effect, and I realise that it wasn't working, not even in
the effects table. So I investigated and saw that the problems where
located in /usr/share/gnome-video-effects/flip.effect that videoflip was
using a deprecated property which is method, the new one is called
video-direction, this changes can be seen in GStreamer documentations.



*** /tmp/tmpr4d_w7n2/bug_body

It was seen that even in Debian 12(bookworm) this problem was
persisting, and the same fix work to Deb12.


  * debian/patches/01-fix-for-flip-effect.patch:
- The property method of video-flip is deprecated
  so its necessary to change to the new one which
  is video-direction. You can see this changes in
  GStreamer documentation. (LP: #2023675)


Thanks for considering the patch.


-- System Information:
Debian Release: bookworm/sid
  APT prefers lunar-updates
  APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'), 
(100, 'lunar-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 6.2.0-20-generic (SMP w/8 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
diff -Nru gnome-video-effects-0.5.0/debian/control 
gnome-video-effects-0.5.0/debian/control
--- gnome-video-effects-0.5.0/debian/control2019-08-13 07:30:44.0 
-0400
+++ gnome-video-effects-0.5.0/debian/control2023-06-13 11:54:31.0 
-0400
@@ -5,9 +5,8 @@
 Source: gnome-video-effects
 Section: gnome
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian GNOME Maintainers 

-Uploaders: Emilio Pozuelo Monfort , Jeremy Bicha 
, Laurent Bigonville 
+Maintainer: Debian GNOME Maintainers 

+Uploaders: Emilio Pozuelo Monfort , Laurent Bigonville 

 Build-Depends: debhelper-compat (= 12),
gnome-pkg-tools (>= 0.11),
intltool (>= 0.40.0),
diff -Nru gnome-video-effects-0.5.0/debian/control.in 
gnome-video-effects-0.5.0/debian/control.in
--- gnome-video-effects-0.5.0/debian/control.in 2019-08-13 07:30:44.0 
-0400
+++ gnome-video-effects-0.5.0/debian/control.in 2023-06-13 11:54:31.0 
-0400
@@ -1,8 +1,7 @@
 Source: gnome-video-effects
 Section: gnome
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian GNOME Maintainers 

+Maintainer: Debian GNOME Maintainers 

 Uploaders: @GNOME_TEAM@
 Build-Depends: debhelper-compat (= 12),
gnome-pkg-tools (>= 0.11),
diff -Nru gnome-video-effects-0.5.0/debian/patches/01-fix-for-flip-effect.patch 
gnome-video-effects-0.5.0/debian/patches/01-fix-for-flip-effect.patch
--- gnome-video-effects-0.5.0/debian/patches/01-fix-for-flip-effect.patch   
1969-12-31 20:00:00.0 -0400
+++ gnome-video-effects-0.5.0/debian/patches/01-fix-for-flip-effect.patch   
2023-06-13 11:54:31.0 -0400
@@ -0,0 +1,13 @@
+## Description: add some description
+## Origin/Author: add some origin or author
+## Bug: bug URL
+Index: gnome-video-effects-0.5.0/effects/flip.effect.desktop.in
+===
+--- gnome-video-effects-0.5.0.orig/effects/flip.effect.desktop.in
 gnome-video-effects-0.5.0/effects/flip.effect.desktop.in
+@@ -2,4 +2,4 @@
+ Name=Flip
+ Comment=Flip the image, as if looking at a mirror
+ Category=Geometry;
+-PipelineDescription=videoflip method=horizontal-flip
++PipelineDescription=videoflip video-direction=horiz
diff -Nru gnome-video-effects-0.5.0/debian/patches/series 
gnome-video-effects-0.5.0/debian/patches/series
--- gnome-video-effects-0.5.0/debian/patches/series 1969-12-31 
20:00:00.0 -0400
+++ gnome-video-effects-0.5.0/debian/patches/series 2023-06-13 
11:54:31.0 -0400
@@ -0,0 +1 @@
+01-fix-for-flip-effect.patch

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Marco d'Itri]

On Jun 13, Bill Allombert  wrote:

> Conversely, sometimes I need to use chroots to test init scripts.
> start-stop-daemon should not refuse to run in a chroot if policy-rc.d allows
> it.
I suggest that you try systemd-nspawn for this purpose.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Thorsten Glaser  writes:

> Therefore I belive that Policy ought to *not* recommend any solution
> that depends on starting dæmons or init scripts to create temporary
> files/directories that are necessary for programs to work.

This is handled by this proposal, no?  That's the point of requiring
integration with maintainer scripts (via triggers or direct invocation).
My understanding is that this is exactly what dh_installtmpfiles already
does, via generating an explicit call to systemd-tmpfiles --create.

Or am I missing something?

-- 
Russ Allbery (r...@debian.org)  

Bug#1037513: wireplumber depends on user dbus session, should depend on dbus-user-session

[Michael Tokarev]

Package: wireplumber
Version: 0.4.13-1
Severity: normal

wireplumber relies on user session bus heavily, it does not work without.
The package should depend on dbus-user-session.  Usually, on a GUI system,
dbus-user-session is pulled by other software, so wireplumber Just Works.
But when no GUI is installed, an attempt to run wireplumber fails with
cryptic error messages (like unabie to run dbus-launch).  Installing
dbus-user-session makes it work as it shold.

This is also an additional note for #1019404, fwiw.

The issue is rather trivial to fix.

Thank you!

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'oldstable-security'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 
'oldstable'), (100, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.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 wireplumber depends on:
ii  init-system-helpers   1.65.2
ii  libc6 2.36-9
ii  libglib2.0-0  2.74.6-2
ii  libpipewire-0.3-0 0.3.65-3
ii  libwireplumber-0.4-0  0.4.13-1
ii  pipewire  0.3.65-3

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.65-3

Versions of packages wireplumber suggests:
ii  libspa-0.2-bluetooth  0.3.65-3
pn  wireplumber-doc   

-- no debconf information

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Sean Whitton]

Hello Mark,

On Tue 13 Jun 2023 at 01:51PM +01, Mark Hindley wrote:

> On Tue, Jun 06, 2023 at 11:58:07AM +0100, Simon McVittie wrote:
>> Exactly. My hope is that if we had:
>>
>> Package: systemd
>> Architecture: linux-any
>> Provides: default-systemd-tmpfiles, systemd-tmpfiles
>> Conflicts: systemd-tmpfiles
>> Replaces: systemd-tmpfiles
>>
>> Package: systemd-standalone-tmpfiles
>> Architecture: linux-any
>> Provides: systemd-tmpfiles
>> Conflicts: systemd-tmpfiles
>> Replaces: systemd-tmpfiles
>>
>> Package: elogind
>> Depends: systemd-standalone-tmpfiles# or Recommends?
>
> In principle and just looking at the dependencies this seems a viable
> solution.  It is very similar to the way we handle the logind and
> default-logind virtual packages.

Thank you for reviewing.  Do you have a rough idea of how long it would
be until you could confirm that this is viable, and implement it in sid?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1037512: why3: did not remove the /usr/share/emacs25/site-lisp/why3.el symlink on package removal

[Vincent Lefevre]

Package: why3
Version: 1.4.0-3
Severity: important

In March, I removed the why3 1.4.0-3 on my machine, but I now have
a dangling symlink:

/usr/share/emacs25/site-lisp/why3.el -> ../../emacs/site-lisp/why3.el

This symlink should be removed when the package is removed.

I don't know whether this has been fixed since...

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages why3 depends on:
ii  libc6  2.36-9
ii  libcairo2  1.16.0-7
pn  libcairo2-ocaml-gl0g4  
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libglib2.0-0   2.74.6-2
ii  libgtk-3-0 3.24.37-2
pn  libgtksourceview-3.0-1 
pn  liblablgtk3-ocaml-0um05
pn  liblablgtksourceview3-ocaml-3azu2  
ii  libpango-1.0-0 1.50.12+ds-1
pn  ocaml-base-4.13.1  
ii  tex-common 6.18
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages why3 recommends:
pn  cvc4 | spass | z3 | alt-ergo  

Versions of packages why3 suggests:
pn  why3-examples  

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

Bug#1037511: silverjuke: FTBFS with libupnp17

[Sebastian Ramacher]

Source: silverjuke
Version: 18.2.1-4
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=silverjuke=amd64=18.2.1-4%2Bb3=1686650401=0

g++ -DPACKAGE_NAME=\"silverjuke\" -DPACKAGE_TARNAME=\"silverjuke\" 
-DPACKAGE_VERSION=\"18.2.1\" -DPACKAGE_STRING=\"silverjuke\ 18.2.1\" 
-DPACKAGE_BUGREPORT=\"r...@b44t.com\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"silverjuke\" -DVERSION=\"18.2.1\" -DENABLE_NLS=1 -DHAVE_GETTEXT=1 
-DHAVE_DCGETTEXT=1 -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_ENDIAN_H=1 -I.  
-Isrc -I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.2 
-I/usr/include/wx-3.2 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/x86_64-linux-gnu 
-pthread-DPKGDATADIR=\"/usr/share/silverjuke\" 
-DPKGDOCDIR=\"/usr/share/doc/silverjuke\" -Wdate-time -D_FORTIFY_SOURCE=2 -Isrc 
-Wall -Wno-unused-but-set-variable -g
-I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.2 -I/usr/include/wx-3.2 
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o src/sjmodules/silverjuke-viewsettings.o `test -f 
'src/sjmodules/viewsettings.cpp' || echo './'`src/sjmodules/viewsettings.cpp
src/sjmodules/upnp.cpp: In member function ‘bool SjUpnpModule::InitLibupnp()’:
src/sjmodules/upnp.cpp:181:20: error: ‘UpnpInit’ was not declared in this 
scope; did you mean ‘UpnpInit2’?
  181 | if( (error=UpnpInit(NULL, 0)) != UPNP_E_SUCCESS ) {
  |^~~~
  |UpnpInit2
make[2]: *** [Makefile:3616: src/sjmodules/silverjuke-upnp.o] Error 1

Cheers
-- 
Sebastian Ramacher