Bug#1027753: closed by Andreas Rönnquist (Re: Bug#1027753: geeqie crashes on ssh-forwared remote X)

[Lars Rohwedder]

The bug itself is _not_ fixed. The command-line option is just a
workaround, so geeqie is usable again, but it (or one of the used
libraries) still contains the bug.

So the severity might be lower and might be moved to the causing
library, but a segfault is still a thing that should be fixed. Don't you
think so?

Lars R.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027900: parole 4.16.0-2 does not start

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2023-01-04 at 15:12 +0300, Сергей Фёдоров wrote:
> parole 4.16.0-2 when running in the terminal emulator outputs :
> free(): invalid pointer
> Emergency stop
> 
> parole 4.16.0-1 is up and running.

Yes indeed, so we have an issue with -1 which doesn't build, and -2 which
doesn't run...

We'll try to investigate when possible.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmPHo6QACgkQ3rYcyPpX
RFso8wf/a4WKNKwWJ0klpyxStGxtoGL2TVFU1JdB8I+iMsVdIjC+4DoZleLs55Tx
fMas2p0AdP7YrO7xcpHrdBLU4fcqHdmAGe3p5nda6oFhew2JfBVal5CCaZR74n80
kxUg3SIMiA8TGBiOk68x7dO6ukyYmWlzlcBVGnnoDLJbhNv71ZSsQDQ7UEYAllCx
9ZoIej0Yvev7eYomcRQQUiwehosBY+D/efaeQYNnZhnTaLkacWl6rzNZUYaSLoX3
H0xPBh/L2h9aGNYVR6aOdxj3juYeICVlFi876rcPLftVidtmoUgbcdgFx13fQzTW
AEYqe9m+qCFzE+ofdiViAa/ksRSKFQ==
=jQTc
-END PGP SIGNATURE-

Bug#1028691: dask.distributed: FTBFS: unsatisfiable build-dependencies: python3-dask (>= 2022.02.0), python-numpy-doc

[Sebastiaan Couwenberg]

Control: tags -1 pending

python-numpy-doc has been dropped from the build dependencies in git, 
but the package FTBFS due to test failures. Those might be fixed in a 
new upstream release, but that may introduce regressions in its rdeps.


Kind Regards,

Bas

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

Bug#1029124: adduser: french transalation update of manual

[Guillonneau Jean-Paul]

Package: adduser
Version: 3.118
Severity: wishlist

Dear Maintainer,

Please find attached the french update of the translation of the manpage of
adduser, proofread by the
debian-l10n-french mailing list contributors.

Regards.


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

Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 adduser depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  passwd 1:4.8.1-1

adduser recommends no packages.

Versions of packages adduser suggests:
ii  liblocale-gettext-perl  1.07-4+b1
ii  perl5.32.1-4+deb11u2

-- debconf information:
  adduser/title:
# adduser's manual pages translation to French
# Copyright (C) 2004 Software in the Public Interest
# This file is distributed under the same license as the adduser package
#
# Nicolas François , 2008.
# David Prévot , 2010.
# Jean-Paul Guillonneau , 2016-2023.
msgid ""
msgstr ""
"Project-Id-Version: adduser 3.115\n"
"POT-Creation-Date: 2023-01-04 08:44+0100\n"
"PO-Revision-Date: 2023-01-18 08:09+0100\n"
"Last-Translator: Jean-Paul Guillonneau \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: vim\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

# type: TH
#. type: TH
#: ../adduser.8:16
#, no-wrap
msgid "ADDUSER"
msgstr "ADDUSER"

# type: TH
#. type: TH
#: ../adduser.8:16 ../adduser.conf.5:13 ../deluser.8:13 ../deluser.conf.5:12
#, no-wrap
msgid "Debian GNU/Linux"
msgstr "Debian GNU/Linux"

# type: SH
#. type: SH
#: ../adduser.8:17 ../adduser.conf.5:14 ../deluser.8:14 ../deluser.conf.5:13
#, no-wrap
msgid "NAME"
msgstr "NOM"

# type: Plain text
#. type: Plain text
#: ../adduser.8:19
msgid "adduser, addgroup - add or manipulate users or groups"
msgstr ""
"adduser, addgroup – Ajouter ou manipuler des utilisateurs ou des groupes"

# type: SH
#. type: SH
#: ../adduser.8:19 ../deluser.8:16
#, no-wrap
msgid "SYNOPSIS"
msgstr "SYNOPSIS"

# type: TH
#. type: SY
#: ../adduser.8:20 ../adduser.8:43 ../adduser.8:59 ../adduser.8:88
#: ../adduser.8:96 ../adduser.8:99
#, no-wrap
msgid "adduser"
msgstr "adduser"

# type: TP
#. type: OP
#: ../adduser.8:21
#, no-wrap
msgid "--add-extra-groups"
msgstr "--add-extra-groups"

#. type: OP
#: ../adduser.8:22
#, no-wrap
msgid "--allow-all-names"
msgstr "--allow-all-names"

# type: TP
#. type: OP
#: ../adduser.8:23
#, no-wrap
msgid "--allow-bad-names"
msgstr "--allow-bad-names"

#. type: OP
#: ../adduser.8:24 ../adduser.8:45
#, no-wrap
msgid "--comment"
msgstr "--comment"

#. type: OP
#: ../adduser.8:24 ../adduser.8:45
#, no-wrap
msgid "comment"
msgstr "commentaire"

# type: TP
#. type: OP
#: ../adduser.8:25 ../adduser.8:46 ../adduser.8:61 ../adduser.8:71
#: ../adduser.8:83 ../adduser.8:89 ../deluser.8:21 ../deluser.8:34
#: ../deluser.8:44 ../deluser.8:52 ../deluser.8:60
#, no-wrap
msgid "--conf"
msgstr "--conf"

#. type: OP
#: ../adduser.8:25 ../adduser.8:46 ../adduser.8:61 ../adduser.8:71
#: ../adduser.8:83 ../adduser.8:89 ../deluser.8:21 ../deluser.8:34
#: ../deluser.8:44 ../deluser.8:52 ../deluser.8:60
#, no-wrap
msgid "file"
msgstr "fichier"

# type: TP
#. type: OP
#: ../adduser.8:26 ../adduser.8:47 ../adduser.8:62 ../adduser.8:72
#: ../adduser.8:90 ../deluser.8:22 ../deluser.8:35 ../deluser.8:45
#: ../deluser.8:53 ../deluser.8:61
#, no-wrap
msgid "--debug"
msgstr "--debug"

# type: TP
#. type: OP
#: ../adduser.8:27
#, no-wrap
msgid "--disabled-login"
msgstr "--disabled-login"

# type: TP
#. type: OP
#: ../adduser.8:28
#, no-wrap
msgid "--disabled-password"
msgstr "--disabled-password"

# NOTE: ce serait mieux d'avoir exactement la même chaîne que dans deluser
# type: TP
#. type: OP
#: ../adduser.8:29 ../adduser.8:63 ../adduser.8:73
#, no-wrap
msgid "--firstgid"
msgstr "--firstgid"

#. type: OP
#: ../adduser.8:29 ../adduser.8:30 ../adduser.8:31 ../adduser.8:34
#: ../adduser.8:35 ../adduser.8:39 ../adduser.8:48 ../adduser.8:54
#: ../adduser.8:63 ../adduser.8:65 ../adduser.8:73 ../adduser.8:75
#: ../adduser.8:82
#, no-wrap
msgid "id"
msgstr "ID"

# NOTE: ce serait mieux d'avoir exactement la même chaîne que dans deluser
# type: TP
#. type: OP
#: ../adduser.8:30
#, no-wrap
msgid "--firstuid"
msgstr "--firstuid"

#. type: OP
#: ../adduser.8:31 ../adduser.8:48 ../adduser.8:64 ../adduser.8:74
#: ../adduser.8:82
#, no-wrap
msgid "--gid"
msgstr "--gid"

# type: TP
#. type: OP
#: ../adduser.8:32 ../adduser.8:50
#, no-wrap
msgid "--home"
msgstr "--home"

#. type: OP
#: ../adduser.8:32 ../adduser.8:50 ../deluser.8:20 ../deluser.8:33
#, no-wrap
msgid "dir"
msgstr "rép"

# 

Bug#996839: [PATCH v2] perf script flamegraph: Avoid d3-flame-graph package dependency

[Ian Rogers]

On Tue, Jan 17, 2023 at 7:17 AM Andreas Gerstmayr  wrote:
>
> On 12.01.23 23:00, Ian Rogers wrote:
> > Currently flame graph generation requires a d3-flame-graph template to
> > be installed. Unfortunately this is hard to come by for things like
> > Debian [1]. If the template isn't installed then ask if it should be
> > downloaded from jsdelivr CDN. The downloaded HTML file is validated
> > against an md5sum. If the download fails, generate a minimal flame
> > graph with the javascript coming from links to jsdelivr CDN.
> >
> > v2. Change the warning to a prompt about downloading and add the
> >  --allow-download command line flag. Add an md5sum check for the
> >  downloaded HTML.
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839
> >
> > Signed-off-by: Ian Rogers 
>
> Thank you for the changes. I've tested v2 with:
>
> * d3-flame-graph package installed
> * template not installed, download template from jsdelivr
> * download from jsdelivr, with --allow-download
> * invalid checksum
> * unreachable jsdelivr, creating a minimal template
>
> Everything works great except when I'm invoking "perf script flamegraph
> -a -F 99 sleep 10" (combining perf report + perf script):
>
> [root@agerstmayr-thinkpad tmp]# perf script flamegraph -a -F 99 sleep 10
> 
> [...]
> 
> Warning: Flame Graph template
> '/usr/share/d3-flame-graph/d3-flamegraph-base.html'
> does not exist. To avoid this please install a package such as the
> js-d3-flame-graph or libjs-d3-flame-graph, specify an existing flame
> graph template (--template PATH) or use another output format (--format
> FORMAT).
> Do you wish to download a template from cdn.jsdelivr.net? (this warning
> can be suppressed with --allow-download) [yn] Traceback (most recent
> call last):
>File "/usr/libexec/perf-core/scripts/python/flamegraph.py", line 157,
> in trace_end
>  s = input("Do you wish to download a template from
> cdn.jsdelivr.net? (this warning can be suppressed with --allow-download)
> [yn] ").lower()
>
> ^^^
> OSError: [Errno 9] Bad file descriptor
> Fatal Python error: handler_call_die: problem in Python trace event handler
> Python runtime state: initialized
>
> Current thread 0x7ff4053a3cc0 (most recent call first):
>
>
> Extension modules: systemd._journal, systemd._reader, systemd.id128
> (total: 3)
> /usr/libexec/perf-core/scripts/python/bin/flamegraph-report: line 3:
> 2135491 Aborted (core dumped) perf script -s
> "$PERF_EXEC_PATH"/scripts/python/flamegraph.py -- "$@"
>
>
> iirc when running "perf script flamegraph" the perf.data gets piped to
> stdin of the flamegraph script, so we can't ask the user in this case.
> You can check this condition with `self.args.input == "-". Not sure
> what's the best action in this case, maybe just exit?

Thanks Andreas,

There's no way to handle command line arguments to the script in
"live" mode and so I sent a v3 where the script warns and then
quit()s. The only other option would have been to assume downloading,
and we'd agreed to avoid that. Hopefully v3 is in the right shape now.

Thanks again,
Ian

>
> Cheers,
> Andreas
>
>
> > ---
> >   tools/perf/scripts/python/flamegraph.py | 96 +++--
> >   1 file changed, 74 insertions(+), 22 deletions(-)
> >
> > diff --git a/tools/perf/scripts/python/flamegraph.py 
> > b/tools/perf/scripts/python/flamegraph.py
> > index b6af1dd5f816..086619053e4e 100755
> > --- a/tools/perf/scripts/python/flamegraph.py
> > +++ b/tools/perf/scripts/python/flamegraph.py
> > @@ -19,12 +19,34 @@
> >   # pylint: disable=missing-function-docstring
> >
> >   from __future__ import print_function
> > -import sys
> > -import os
> > -import io
> >   import argparse
> > +import hashlib
> > +import io
> >   import json
> > +import os
> >   import subprocess
> > +import sys
> > +import urllib.request
> > +
> > +minimal_html = """
> > +   > href="https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.css;>
> > +
> > +
> > +  
> > +  https://d3js.org/d3.v7.js";>
> > +   > src="https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.min.js";>
> > +  
> > +  const stacks = [/** @flamegraph_json **/];
> > +  // Note, options is unused.
> > +  const options = [/** @options_json **/];
> > +
> > +  var chart = flamegraph();
> > +  d3.select("#chart")
> > +.datum(stacks[0])
> > +.call(chart);
> > +  
> > +
> > +"""
> >
> >   # pylint: disable=too-few-public-methods
> >   class Node:
> > @@ -50,16 +72,6 @@ class FlameGraphCLI:
> >   self.args = args
> >   self.stack = Node("all", "root")
> >
> > -if 

Bug#996839: [PATCH v3] perf script flamegraph: Avoid d3-flame-graph package dependency

[Ian Rogers]

Currently flame graph generation requires a d3-flame-graph template to
be installed. Unfortunately this is hard to come by for things like
Debian [1]. If the template isn't installed then ask if it should be
downloaded from jsdelivr CDN. The downloaded HTML file is validated
against an md5sum. If the download fails, generate a minimal flame
graph with the javascript coming from links to jsdelivr CDN.

v3. Adds a warning message and quits before download in live mode.
v2. Change the warning to a prompt about downloading and add the
--allow-download command line flag. Add an md5sum check for the
downloaded HTML.

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

Signed-off-by: Ian Rogers 
---
 tools/perf/scripts/python/flamegraph.py | 107 +++-
 1 file changed, 85 insertions(+), 22 deletions(-)

diff --git a/tools/perf/scripts/python/flamegraph.py 
b/tools/perf/scripts/python/flamegraph.py
index b6af1dd5f816..cf7ce8229a6c 100755
--- a/tools/perf/scripts/python/flamegraph.py
+++ b/tools/perf/scripts/python/flamegraph.py
@@ -19,12 +19,34 @@
 # pylint: disable=missing-function-docstring
 
 from __future__ import print_function
-import sys
-import os
-import io
 import argparse
+import hashlib
+import io
 import json
+import os
 import subprocess
+import sys
+import urllib.request
+
+minimal_html = """
+  https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.css;>
+
+
+  
+  https://d3js.org/d3.v7.js";>
+  https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.min.js";>
+  
+  const stacks = [/** @flamegraph_json **/];
+  // Note, options is unused.
+  const options = [/** @options_json **/];
+
+  var chart = flamegraph();
+  d3.select("#chart")
+.datum(stacks[0])
+.call(chart);
+  
+
+"""
 
 # pylint: disable=too-few-public-methods
 class Node:
@@ -50,16 +72,6 @@ class FlameGraphCLI:
 self.args = args
 self.stack = Node("all", "root")
 
-if self.args.format == "html" and \
-not os.path.isfile(self.args.template):
-print("Flame Graph template {} does not exist. Please install "
-  "the js-d3-flame-graph (RPM) or libjs-d3-flame-graph (deb) "
-  "package, specify an existing flame graph template "
-  "(--template PATH) or another output format "
-  "(--format FORMAT).".format(self.args.template),
-  file=sys.stderr)
-sys.exit(1)
-
 @staticmethod
 def get_libtype_from_dso(dso):
 """
@@ -128,16 +140,63 @@ class FlameGraphCLI:
 }
 options_json = json.dumps(options)
 
+template_md5sum = None
+if self.args.format == "html":
+if os.path.isfile(self.args.template):
+template = f"file://{self.args.template}"
+else:
+if not self.args.allow_download:
+print(f"""Warning: Flame Graph template 
'{self.args.template}'
+does not exist. To avoid this please install a package such as the
+js-d3-flame-graph or libjs-d3-flame-graph, specify an existing flame
+graph template (--template PATH) or use another output format (--format
+FORMAT).""",
+  file=sys.stderr)
+if self.args.input == "-":
+print("""Not attempting to download Flame Graph 
template as script command line
+input is disabled due to using live mode. If you want to download the
+template retry without live mode. For example, use 'perf record -a -g
+-F 99 sleep 60' and 'perf script report flamegraph'. Alternatively,
+download the template from:
+https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/templates/d3-flamegraph-base.html
+and place it at:
+/usr/share/d3-flame-graph/d3-flamegraph-base.html""",
+  file=sys.stderr)
+quit()
+s = None
+while s != "y" and s != "n":
+s = input("Do you wish to download a template from 
cdn.jsdelivr.net? (this warning can be suppressed with --allow-download) [yn] 
").lower()
+if s == "n":
+quit()
+template = 
"https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/templates/d3-flamegraph-base.html;
+template_md5sum = "143e0d06ba69b8370b9848dcd6ae3f36"
+
 try:
-with io.open(self.args.template, encoding="utf-8") as template:
-output_str = (
-template.read()
-.replace("/** @options_json **/", options_json)
-.replace("/** @flamegraph_json **/", stacks_json)
-)
-except IOError as err:
-print("Error reading template file: {}".format(err), 
file=sys.stderr)
-

Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles

[Ross Vandegrift]

On Fri, Dec 16, 2022 at 03:48:00PM -0800, Ross Vandegrift wrote:
> At a high level the issue is: firewalld.service forces network-pre.target 
> after
> sysinit.target, but cloud-init.service forces the other way around.  In 
> detail,
> using < to represent Before, the imposed orderings look like:
> 
> - from firewalld:
>   sysinit.target < dbus.service < firewalld.service < network-pre.target
> - from cloud-init:
>   cloud-init-local.service < network-pre.target < 
> systemd-networkd-wait-online.service < cloud-init.service < sysinit.target
> 
> There's a few approaches to resolving this.  As far as I can tell, the only
> immediately viable one (at the bottom) requires users to manually fix this
> and accept some trade-offs.  Anyone have any better ideas?

We discussed this issue on the recent cloud-team meeting and had some
revised options.

> Modify firewalld to run before sysinit.target 
> -
[snip]

This one still seems impossible.

> Modify cloud-init to run after sysinit.target
> -
[snip]

The main downside of this one, is that cloud-init will be running too
late to configure block devices.  But this feature didn't always work
well.  So maybe we'd affect a non-working feature.

I've confirmed that cloud-init's block device setup is working well on
AWS at least.  So I think this will break working cloud-init features.
IMO, that means it is not viable.

> Locally override firewalld.service's order
> --
[snip]

This remains unattractive since unsuspecting users will be left with
broken images and no clear path to fix the problem.


Modify dbus to run later


We discussed a way improve things by shuffling dbus later, but I didn't
take good enough notes, and I can't reconstruct the details.  Sorry for
forgetting - Bastian do you recall the details?


Add Breaks or Conflicts to prevent coinstallation
-

None of the alternatives seem reasonable and installing cloud-init and
firewalld cannot produce a working Debian image.  So we should prevent
this state.

We thought Conflicts might be required because once both are unpacked,
the problematic cycle technically exists.  Though it may not cause harm
unless both services are (re-)started simultaneously.

Ross

Bug#1029108: tuxguitar: limit build architectures

[tony mancill]

On Tue, Jan 17, 2023 at 11:59:07AM -0800, tony mancill wrote:
> Package: tuxguitar
> Version: 1.5.6+dfsg1-1
> Severity: important
> 
> tuxguitar is FTBFS on multiple architectures:
> 
> https://buildd.debian.org/status/logs.php?pkg=tuxguitar=1.5.6%2Bdfsg1-1
> 
> We should either address the FTBFS or limit the build architectures in
> the next upload.

The initial buildd build failed for arm64, but it's successful for me
locally in a clean chroot.  Once I figure out why it's failing on the
buildd, I intend to restrict the build archs to amd64 and arm64.


signature.asc
Description: PGP signature

Bug#1029117: libtasn1-6: Convert d/copyright to machine-readable format

[Andreas Metzler]

Control: tags -1 -patch

On 2023-01-17 Bastian Germann  wrote:
> Source: libtasn1-6
> Version: 4.19.0-2
> Tags: patch

> Please consider converting the debian/copyright file to the machine-readable 
> format.
> I have attached a converted file that also adds the missing X11 and FSFAP 
> license and some copyright lines.

Good morning,

DEP-5 per file copyright is quite unmanageable (i.e. enormously
time-consuming if done properly) for non-tiny pieces of software if done
manually by editing debian/copyright.

I will happily apply patches that do the right thing with
"cme update dpkg-copyright", i.e. with debian/fill.copyright.blanks.yml
debian/copyright-scan-patterns.yml and debian/fix.scanned.copyright but
just doing a one-time conversion with huge maintenance costs afterwards
is not productive use of time.

cme seems to be only piece of softwar in Debian thatv tries to tackle
this, but the degree of handholding required via debian/*copyright* is
still huge.

cu Andreas

Bug#1027656: leaflet autoremoval

[Jonas Smedegaard]

Quoting Yadd (2023-01-18 06:40:14)
> On 1/16/23 09:34, Jonas Smedegaard wrote:
> > [replying via bugreport, to have the conversation public]
> > 
> > Quoting Sebastiaan Couwenberg (2023-01-16 05:54:07)
> >> Do either of you have time to look into fixing #1026688 which will cause
> >> autoremoval of leaflet and its rdeps?
> > 
> > I should be able to take time for that before its removal - but am happy
> > if others beat me to it.
> 
> Hi,
> 
> done, was just a missing rollup-3 patch (rollup.config updated to CJS)

Thanks!

 - 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#1027656: leaflet autoremoval

[Yadd]

On 1/16/23 09:34, Jonas Smedegaard wrote:

[replying via bugreport, to have the conversation public]

Quoting Sebastiaan Couwenberg (2023-01-16 05:54:07)

Do either of you have time to look into fixing #1026688 which will cause
autoremoval of leaflet and its rdeps?


I should be able to take time for that before its removal - but am happy
if others beat me to it.


Hi,

done, was just a missing rollup-3 patch (rollup.config updated to CJS)

Cheers,
Yadd

Bug#1029122: scm: ftbfs on mipsel

[Bo YU]

Source: scm
Version: 5f2-3
Severity: serious 

Dear Maintainer,

The upload[0] cause a regression with build failure on mipsel:

```
...
make checklit
make[3]: Entering directory '/<>'
./scmlit -fr4rstest.scm -e'(test-sc4)(test-delay)(gc)' \
-e '(or (null? errs) (quit 1))' < /dev/null
remove
#define SHORT_INT
in scmfig.h and recompile scm
make[3]: *** [Makefile:553: checklit] Error 1
```

The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=scm=mipsel=5f3-3=1673937776=0

I have fixed the issue on my local machine and upload it after testing it.
Thanks.

[0]: 
https://tracker.debian.org/news/1409807/accepted-scm-5f3-3-source-into-unstable/
-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#766863: Intent to NMU darkstat to fix longstanding l10n bug

[Emil Mikulic]

I'm not planning a new release. Go for it!

Bug#1029121: bullseye-pu: package lxc/4.0.6-2+deb11u2

[Mathias Gibbens]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org, gib...@debian.org
Control: affects -1 + src:lxc

[ Reason ]
The version of lxc in bullseye is affected by the low-severity
CVE-2022-47952 which was fixed in the recent release of lxc 5.0.2
(uploaded to unstable yesterday). As the fix was trivial to apply to
the version of lxc in bullseye, I think it would be beneficial to
include it in the next point release.

[ Impact ]
Affected versions of lxc suffer a minor information leak which allows a
local user to infer whether any file exists, even within a protected
directory tree.

[ Tests ]
A manual proof-of-concept test is provided in the upstream commit
fixing this issue.

[ Risks ]
There are no changes to any of the logic of lxc; the error messages
which are returned are modified to be identical in every error case,
preventing the information leak.

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

[ Changes ]
Backport upstream commit 1b0469530d7a38b8f8990e114b52530d1bf7f3b8,
which fixes CVE-2022-47952. (The line numbers in the diff shifted
slightly, otherwise no changes to the patch.)

[ Other info ]
The source debdiff is attached.
diff -Nru lxc-4.0.6/debian/changelog lxc-4.0.6/debian/changelog
--- lxc-4.0.6/debian/changelog	2022-01-13 19:57:39.0 +
+++ lxc-4.0.6/debian/changelog	2023-01-18 02:53:46.0 +
@@ -1,3 +1,9 @@
+lxc (1:4.0.6-2+deb11u2) bullseye; urgency=medium
+
+  * Backport fix for CVE-2022-47952
+
+ -- Mathias Gibbens   Wed, 18 Jan 2023 02:53:46 +
+
 lxc (1:4.0.6-2+deb11u1) bullseye; urgency=medium
 
   * lxc-download: Switch GPG server.
diff -Nru lxc-4.0.6/debian/patches/fix-CVE-2022-47952.patch lxc-4.0.6/debian/patches/fix-CVE-2022-47952.patch
--- lxc-4.0.6/debian/patches/fix-CVE-2022-47952.patch	1970-01-01 00:00:00.0 +
+++ lxc-4.0.6/debian/patches/fix-CVE-2022-47952.patch	2023-01-18 02:53:23.0 +
@@ -0,0 +1,69 @@
+From 1b0469530d7a38b8f8990e114b52530d1bf7f3b8 Mon Sep 17 00:00:00 2001
+From: Maher Azzouzi 
+Date: Sun, 25 Dec 2022 13:50:25 +0100
+Subject: [PATCH] Patching an incoming CVE (CVE-2022-47952)
+
+lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may
+allow local users to infer whether any file exists, even within a
+protected directory tree, because "Failed to open" often indicates
+that a file does not exist, whereas "does not refer to a network
+namespace path" often indicates that a file exists. NOTE: this is
+different from CVE-2018-6556 because the CVE-2018-6556 fix design was
+based on the premise that "we will report back to the user that the
+open() failed but the user has no way of knowing why it failed";
+however, in many realistic cases, there are no plausible reasons for
+failing except that the file does not exist.
+
+PoC:
+> % ls /l
+> ls: cannot open directory '/l': Permission denied
+> % /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic delete lol lol /l/h/tt h h
+> cmd/lxc_user_nic.c: 1096: main: Failed to open "/l/h/tt" <- file does not exist.
+> % /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic delete lol lol /l/h/t h h
+> cmd/lxc_user_nic.c: 1101: main: Path "/l/h/t" does not refer to a network namespace path < file exist!
+
+Signed-off-by: MaherAzzouzi 
+Acked-by: Serge Hallyn 
+---
+ src/lxc/cmd/lxc_user_nic.c | 15 ++-
+ 1 file changed, 6 insertions(+), 9 deletions(-)
+
+diff --git a/src/lxc/cmd/lxc_user_nic.c b/src/lxc/cmd/lxc_user_nic.c
+index a91e2259d5..69bc6f17d1 100644
+--- a/src/lxc/cmd/lxc_user_nic.c
 b/src/lxc/cmd/lxc_user_nic.c
+@@ -1088,20 +1088,17 @@ int main(int argc, char *argv[])
+ 	} else if (request == LXC_USERNIC_DELETE) {
+ 		char opath[LXC_PROC_PID_FD_LEN];
+ 
+-		/* Open the path with O_PATH which will not trigger an actual
+-		 * open(). Don't report an errno to the caller to not leak
+-		 * information whether the path exists or not.
+-		 * When stracing setuid is stripped so this is not a concern
+-		 * either.
+-		 */
++		// Keep in mind CVE-2022-47952: It's crucial not to leak any
++		// information whether open() succeeded of failed.
++
+ 		netns_fd = open(args.pid, O_PATH | O_CLOEXEC);
+ 		if (netns_fd < 0) {
+-			usernic_error("Failed to open \"%s\"\n", args.pid);
++			usernic_error("Failed while opening netns file for \"%s\"\n", args.pid);
+ 			_exit(EXIT_FAILURE);
+ 		}
+ 
+ 		if (!fhas_fs_type(netns_fd, NSFS_MAGIC)) {
+-			usernic_error("Path \"%s\" does not refer to a network namespace path\n", args.pid);
++			usernic_error("Failed while opening netns file for \"%s\"\n", args.pid);
+ 			close(netns_fd);
+ 			_exit(EXIT_FAILURE);
+ 		}
+@@ -1115,7 +1112,7 @@ int main(int argc, char *argv[])
+ 		/* Now get an fd that we can use in setns() calls. */
+ 		ret = open(opath, 

Bug#1026669: request-tracker5: FTBFS: can't locate java: No such file or directory

[Ángel]

The error here is that ./debian/build-final-ckeditor.sh fails with
« can't locate java: No such file or directory »

This script is actually calling ckbuilder ( jexec /usr/bin/ckbuilder --
build ... )

However, the package correctly lists ckbuilder as a build-dep, and
ckbuilder itself depends on java ( default-jre | java{7..11}-runtime)

The full build log shows that java *was* installed, *and* that it
provided the usual suspects:

> update-alternatives: using /usr/lib/jvm/java-17-openjdk-
> amd64/bin/java to provide /usr/bin/java (java) in auto mode
> update-alternatives: using /usr/lib/jvm/java-17-openjdk-
> amd64/bin/jpackage to provide /usr/bin/jpackage (jpackage) in auto
> mode
> update-alternatives: using /usr/lib/jvm/java-17-openjdk-
> amd64/bin/keytool to provide /usr/bin/keytool (keytool) in auto mode
> update-alternatives: using /usr/lib/jvm/java-17-openjdk-
> amd64/bin/rmiregistry to provide /usr/bin/rmiregistry (rmiregistry)
> in auto mode
> update-alternatives: using /usr/lib/jvm/java-17-openjdk-
> amd64/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode

Bug#1029120: coreutils: csplit: handles {*} repetitions inconsistently

[наб]

Package: coreutils
Version: 9.1-1
Severity: normal

Dear Maintainer,

Consider the standard repetition:
-- >8 --
$ seq 999 | csplit - /10/1 {99}
21
271
8
8
8
8
8
400
400
400
400
400
400
400
400
csplit: ‘/10/1’: match not found on repetition 15
356
$ seq 999 | csplit - 88 {99}
252
340
352
352
352
352
352
352
352
352
352
csplit: ‘88’: line number out of range on repetition 11
128
-- >8 --

Good! POSIX agrees:
  An error shall be reported if an operand does not reference
  a line between the current position and the end of the file.
(the operand being /10/1 or 88, resp., as re-applied via {99}).

So why, then:
-- >8 --
$ seq 999 | csplit - /10/1 {*}
21
271
8
8
8
8
8
400
400
400
400
400
400
400
400
356
$ seq 999 | csplit - 88 {*}
252
340
352
352
352
352
352
352
352
352
352
csplit: ‘88’: line number out of range on repetition 11
128
-- >8 --

The manual defines {*} as
  {*}repeat the previous pattern as many times as possible
but then inconsistently uses it as
  88{∞}
  /10/1 {until no more matches}

Best,
наб

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 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 coreutils depends on:
ii  libacl1  2.3.1-2
ii  libattr1 1:2.5.1-3
ii  libc62.36-7
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b4

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1027686: transition: rakudo

[M. Zhou]

I have uploaded moarvm, nqp, and rakudo to unstable.
They turned green on release architectures.
The ppc64el buildd lags a little bit but I believe the result will be
green as well based on the previous no-change build in experimental.

On Sun, 2023-01-15 at 19:09 +0100, Sebastian Ramacher wrote:
> Control: tags -1 = confirmed
> 
> On 2023-01-15 18:49:24 +0100, Dominique Dumont wrote:
> > On Sunday, 15 January 2023 15:21:55 CET Sebastian Ramacher wrote:
> > > > I've found where compiler-id is computed. I'm going patch
> > > > rakudo in
> > > > experimental so that compiler-id depends only on source files
> > > > and nqp
> > > > version. This patch will land in experimental.
> > > 
> > > Okay, please let me know once it's available in experimental.
> > 
> > Done with rakudo 2022.12-1~exp3
> > 
> > I've patched the compiler id to be a sha1 of "Debian- > version>".
> > 
> > I've verified that compiler id is the same for the arch that are
> > built.
> > 
> > Is it still time to trigger a transition to fix all raku modules ?
> > (there's no 
> > impact outside of raku modules)
> 
> Thanks, please go ahead.
> 
> Cheers

Bug#1029118: Possible typo in "#if !(defined(yylex) ..."

[Thomas Dickey]

On Wed, Jan 18, 2023 at 12:45:50AM +, Bjarni Ingi Gislason wrote:
> Package: byacc
> Version: byacc - 2.0 20221229
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>   Compiling groff

(in a quick check, I compiled the version from 2022/12/28
on my Debian/oldstable without seeing this problem - but I see
the issue is compiler options).
 
> 
> 
> output.c:   putl_code(fp, "#if !(defined(yylex) || defined(YYSTATE))\n");
> 
>   "yylex" is a name of a function but "#... defined(...)" applies to
> macros not functions(?).

That's intentional (not a bug).  It's done to allow changing the function
signature -- but not if there's already a macro to confuse things.

Here's more context:

/* Parameters sent to lex. */
#ifdef YYLEX_PARAM
# define YYLEX_DECL() yylex(void *YYLEX_PARAM)
# define YYLEX yylex(YYLEX_PARAM)
#else
# define YYLEX_DECL() yylex(void)
# define YYLEX yylex()
#endif

#if !(defined(yylex) || defined(YYSTATE))
int YYLEX_DECL();
#endif

Changing that YYSTATE to YYLEX will turn off the declaration.

YYSTATE is a lex symbol (#define'd), so it seemed a better choice than
the flex-specific FLEX_SCANNER symbol which Guy Harris used in the first
version of this ifdef.

The intent here is to not use the declaration if the lex/flex code is
inserted before that point (reducing redefinition problems).

> 
> 
>   When compiling, a warning is issued:
> 
>   CXX  src/preproc/eqn/eqn-eqn.o
> src/preproc/eqn/eqn.cpp:73:23: warning: redundant redeclaration of 'int
> yylex()' in same scope [-Wredundant-decls]
>73 | # define YYLEX_DECL() yylex(void)
>   |   ^

yes - that's a problem.  There's been no universally-guaranteed prototype
for yylex, so applications add one.  (There was some update on the Austin
review a couple of years ago, but the recommendation from that would run
into the same problem -- and it introduced other problems).

For this case, I could add a third symbol, which would "only" be set by
the caller (not a lex/flex symbol that one might trip over).

> src/preproc/eqn/eqn.cpp:78:5: note: in expansion of macro 'YYLEX_DECL'
>78 | int YYLEX_DECL();
>   | ^~
> ../src/preproc/eqn/eqn.ypp:31:5: note: previous declaration of 'int
> yylex()'
>31 | int yylex(void);
>   | ^
>   CXXLDeqn
> 
> 
> 
>   When I change "yylex" to "YYLEX" in the "putl_code(...)" line there
> is no warning.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.0.12-1 (SMP w/2 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
> LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages byacc depends on:
> ii  libc6  2.36-8
> 
> byacc recommends no packages.
> 
> byacc suggests no packages.

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


signature.asc
Description: PGP signature

Bug#1029119: coreutils: csplit: makes an empty file when an expression goes backwards, must error per POSIX

[наб]

Package: coreutils
Version: 9.1-1
Severity: normal

Dear Maintainer,

Quoth Issue 7 (and Issue 8 Draft 2.1), XCU, csplit, OPERANDS:
  An error shall be reported if an operand does not reference
  a line between the current position and the end of the file.

Why, then:
-- >8 --
$ seq 999 | csplit - /10/ /^0$/
18
csplit: ‘/^0$/’: match not found
3870
-- >8 --
but
-- >8 --
$ seq 999 | csplit - /10/ 2
18
0
3870
-- >8 --
?

Cf. NetBSD, which gets both right:
-- >8 --
$ seq 999 | csplit - /10/ /^0/
18
csplit: ^0: no match
$ seq 999 | csplit - /10/ 2
18
csplit: 2: can't go backwards
-- >8 --

Best,
наб

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 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 coreutils depends on:
ii  libacl1  2.3.1-2
ii  libattr1 1:2.5.1-3
ii  libc62.36-7
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b4

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#207095: so hard to get dates

[Dan Jacobson]

On https://github.com/GPSBabel/gpsbabel/issues/981#issuecomment-1385579428
I was racking my brains again to show them the dates.

Bug#1029112: Surprise build issue with ibus-libzhuyin

[Osamu Aoki]

Hi,

Debian official packages are required to build without downloading external
files during their build.  (Builddd is in isolated network environment only with
access to the Debian package repository.


> Tags: ftbfs

So if it requires wget file access, it is ftbfs.  Don't make build script to do
this.   ... (continue to the bottom).

> Making all in model
> make[4]: Entering directory '/<>/data/model'
> wget http://downloads.sourceforge.net/libzhuyin/models/model13.text.tar.gz
> /bin/bash: line 1: wget: command not found
> 
> And yes, it's true that wget is not included in Build-Depends. But 
> previously that has not been needed. This is from the buildlog for the 
> latest successful build:
> 
> Making all in model
> make[4]: Entering directory '/<>/data/model'
> rm -f phrase_index.bin pinyin_index.bin addon_phrase_index.bin 
> addon_pinyin_index.bin bigram.db tsi.bin
> gen_binary_files --table-dir ../../data/model
> import_interpolation --table-dir ../../data/model < 
> ../../data/model/interpolation2.text
> gen_unigram --table-dir ../../data/model
> 
> or just:
> 
> Making check in model
> make[3]: Entering directory '/<>/data/model'
> make[3]: Nothing to be done for 'check'.
> 
> I have not found any code changes which would explain the new behavior. 
> And when trying (in an Ubuntu PPA) to add wget to Build-Depends, it 
> failed to resolve the download URL. (It builds fine on my harddisk, though.)
> 
> I figured out that this patch would help it build successfully:
> 
> --- a/data/Makefile.am
> +++ b/data/Makefile.am
> @@ -27,7 +27,6 @@
> 
>    SUBDIRS = \
>    icons \
> -    model \
>    $(NULL)
> 
>    appdatadir = @datadir@/appdata
> 
> But since I don't know how that would affect the functionality of the 
> package, I have left it in its failed state for now.
> 
> In other words: I need help to solve this.


If I were you, I will build package "without this mod in an environment with
wget included as Build-dep" and "with this mod only without wget in chroot". 
Then I will check resulting binary packages.

If these generated packages contain different model data, then you need to
modify code to use pre-existing data and download such model data in advance to
be included in debian/ directory.  Of course, you need to check license terms of
such model data and document it.

If these contain same model data, your proposed fix should be OK.

Regards,

Osamu

Bug#1029118: Possible typo in "#if !(defined(yylex) ..."

[Bjarni Ingi Gislason]

Package: byacc
Version: byacc - 2.0 20221229
Severity: normal

Dear Maintainer,

   * What led up to the situation?

  Compiling groff



output.c:   putl_code(fp, "#if !(defined(yylex) || defined(YYSTATE))\n");

  "yylex" is a name of a function but "#... defined(...)" applies to
macros not functions(?).



  When compiling, a warning is issued:

  CXX  src/preproc/eqn/eqn-eqn.o
src/preproc/eqn/eqn.cpp:73:23: warning: redundant redeclaration of 'int
yylex()' in same scope [-Wredundant-decls]
   73 | # define YYLEX_DECL() yylex(void)
  |   ^
src/preproc/eqn/eqn.cpp:78:5: note: in expansion of macro 'YYLEX_DECL'
   78 | int YYLEX_DECL();
  | ^~
../src/preproc/eqn/eqn.ypp:31:5: note: previous declaration of 'int
yylex()'
   31 | int yylex(void);
  | ^
  CXXLDeqn



  When I change "yylex" to "YYLEX" in the "putl_code(...)" line there
is no warning.

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

Kernel: Linux 6.0.12-1 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages byacc depends on:
ii  libc6  2.36-8

byacc recommends no packages.

byacc suggests no packages.

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

[Helge Deller]

On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson  wrote:

Here's a slightly different patch to implement basically the same thing


Yes, I like this patch better too.

Helge

Bug#1013756: (No Subject)

[danielle.davout]

Hi, I had the same bug, so I try to follow the instructions given in

https://github.com/alsa-project/alsa-python/commit/a64a6cc703d08db5c223a16bf812a569534ba464

I could "hear" some improvements (some sound), but now I am face to

'''Traceback (most recent call last):
File "/usr/share/solfege/solfege/exercises/idbyname.py", line 296, in 
new_question
self.do_at_question_start_show_play()
File "/usr/share/solfege/solfege/abstract.py", line 1077, in 
do_at_question_start_show_play
self.m_t.m_P.play_question()
File "/usr/share/solfege/solfege/lessonfile.py", line 1413, in play_question
question[varname].play(self, question)
File "/usr/share/solfege/solfege/lessonfile.py", line 573, in play
self.__play(lessonfile_ref, question,
File "/usr/share/solfege/solfege/lessonfile.py", line 601, in __play
soundcard.synth.play_track(t1, t2, t3)
File "/usr/share/solfege/solfege/soundcard/alsa_sequencer.py", line 51, in 
play_track
self.play_midieventstream(MidiEventStream(*tracks))
File "/usr/share/solfege/solfege/soundcard/alsa_sequencer.py", line 94, in 
play_midieventstream
event.time = tTypeError: integer or float expected...
Thanks

Bug#1028528: transition: libcotp

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-01-12 11:45:45 +, Francisco Vilmar Cardoso Ruviaro wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I would like to update libcotp in unstable to the 2.0.0-1.
> 
> I would like to request a transition slot for libcotp, changing the
> library name from libcotp12 to libcotp2. The version 2.0.0

Why is the SONAME going backwards?

Cheers

> introducing the ABI change has been in experimental since 2023-01-10.
> 
> I have successfully rebuilt the reversed dependencies on amd64.
> 
> $ reverse-depends -b src:libcotp
> Reverse-Build-Depends
> * otpclient (for libcotp-dev)
> 
> There is already a tracker available here:
> 
> https://release.debian.org/transitions/html/auto-libcotp.html
> 
> Thanks!
> -- 
> Francisco Vilmar Cardoso Ruviaro 
> 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00




-- 
Sebastian Ramacher

Bug#928912: README.Debian updated in 5.1.8.1-1

[Jeremy Sowden]

Control: fixed -1 shorewall/5.1.8.1-1

The explanation in README.Debian of how to enable shorewall on boot was
updated to include systemd in 5.1.8.1-1.

J.


signature.asc
Description: PGP signature

Bug#1029097: pam: FTBFS on hurd-i386

[Svante Signell]

On Tue, 2023-01-17 at 18:49 +, Sam Hartman wrote:
> > > > > > "Svante" == Svante Signell 
> > > > > > writes:
>     Svante> modules_pam_nologin_tst-pam_nologin-retval.c.diff
> disabling
>     Svante> two subtests failing on GNU/Hurd.  -
> 
> Why do these subtests fail?
> 
tst-pam_nologin-retval.c:185: Assertion failed: PAM_SYSTEM_ERR (0x4) ==
pam_authenticate(pamh, 0) (0x6)
tst-pam_nologin-retval.c:189: Assertion failed: PAM_SYSTEM_ERR (0x4) ==
pam_acct_mgmt(pamh, 0) (0x6)

>     Svante> 
>     Svante> debian_libpam-modules-bin.install.hurd-i386.patch
> creating
>     Svante> an install file for Hurd excluding two systemd-specific
>     Svante> files not needed.
> 
> Why is installing these files harmful?
> I'm reluctant to take  this patch unless it actually breaks something
> and there's no other way to do it.
> If I take this patch, then I'll have to remember to update the hurd
> install list every time something changes.

I did not say they are harmful. They just weren't built/available in
the build tree during the installation of libpam-modules-bin, so that
failed.

(I've tried to add stuff like (arch=!hurd-any) ... to the .install
file. It seems like that such attempts does not work, as they for e.g.
.symbol files.)

I found the two missing files here though: modules/pam_namespace/
pam_namespace_helper
pam_namespace.service

Dunno why they are not found under the debian/ directory.

Thanks!

Bug#1029117: libtasn1-6: Convert d/copyright to machine-readable format

[Bastian Germann]

Source: libtasn1-6
Version: 4.19.0-2
Tags: patch

Please consider converting the debian/copyright file to the machine-readable 
format.
I have attached a converted file that also adds the missing X11 and FSFAP 
license and some copyright lines.Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Comment:
 This package was debianized by Ivo Timmermans  on
 Sat, 15 Jun 2002 23:37:29 +0200 by Matthias Urlichs .
 .
 It is now maintained by Andreas Metzler , Eric Dorland
  and James Westby 
 .
 The library itself is licensed as LGPL-2.1+, the build system,
 test-suite, and command-line tools (package libtasn1-bin) are GPL-3+.
Source:
 It was downloaded from https://ftp.gnu.org/gnu/libtasn1/
Upstream-Contact:
 Fabio Fiorina 
 Simon Josefsson 
 Nikos Mavrogiannopoulos 

Files: *
Copyright: (C) 2000-2022 Free Software Foundation, Inc.
License: GPL-3+

Files: lib/*
   fuzz/corpus2array.c
   m4/ax_code_coverage.m4
   src/gl/intprops-internal.h
   src/gl/getopt_int.h
   src/gl/idx.h
   src/gl/getopt-ext.h
   src/gl/intprops.h
   src/gl/getopt.c
   src/gl/explicit_bzero.c
   src/gl/getopt1.c
   src/gl/stdckdint.in.h
   src/gl/getopt-core.h
   src/gl/filename.h
Copyright: (C) 2000-2022 Free Software Foundation, Inc.
License: LGPL-2.1+
 * This file is part of LIBTASN1.
 *
 * The LIBTASN1 library is free software; you can redistribute it
 * and/or modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 * 02110-1301, USA
Comment:
 On Debian GNU/Linux systems, the complete text of the GNU Lesser
 General Public License can be found in
 `/usr/share/common-licenses/LGPL'; the text of the earliest applying version
 of the license (2.1) can be found in `/usr/share/common-licenses/LGPL-2.1'.

Files: doc/gdoc
Copyright:
 Copyright (c) 2002-2021 Simon Josefsson
 Copyright (c) 2001, 2002 Nikos Mavrogiannopoulos
 Copyright (c) 1998 Michael Zucchi
 Copyright (c) 2013 Adam Sampson
License: GPL-3+

Files: tests/object-id-encoding.c
Copyright: (C) 2019 Nikos Mavrogiannopoulos
License: GPL-3+

Files: tests/object-id-decoding.c
   tests/ocsp-basic-response.c
   tests/spc_pe_image_data.c
Copyright: (C) 2016 Red Hat, Inc.
License: GPL-3+

Files: gtk-doc.make
Copyright: (C) 2003 James Henstridge
   2004-2007 Damon Chaplin
   2007-2017 Stefan Sauer
License: GPL-3+

License: GPL-3+
 * This file is part of LIBTASN1.
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see .
Comment:
 On Debian GNU/Linux systems, the complete text of the GNU General Public
 License version 3 can be found in /usr/share/common-licenses/GPL-3.

Files: doc/*.texi
   doc/*.1
   doc/reference/*
Copyright: (c) 2001-2022 Free Software Foundation, Inc.
License: GFDL-NIV-1.3+
  Permission is granted to copy, distribute and/or modify this
  document under the terms of the GNU Free Documentation License,
  Version 1.3 or any later version published by the Free Software
  Foundation; with no Invariant Sections, no Front-Cover Texts, and no
  Back-Cover Texts. A copy of the license is included in the section
  entitled "GNU Free Documentation License".
Comment:
 On Debian systems a copy of the complete text of the GNU FDL 1.3
 can be found in /usr/share/common-licenses/GFDL-1.3.

Files: AUTHORS INSTALL NEWS THANKS
   doc/TODO doc/man/*
Copyright: Copyright (C) 2002-2022 Free Software Foundation, Inc.
License: FSFAP
 Copying and distribution of this file, with or without modification,
 are permitted in any medium without royalty provided the copyright
 notice and this notice are preserved.

Files: build-aux/install-sh
Copyright: (C) 1994 X Consortium
License: X11
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation 

Bug#1027760: gortr appears to be unmaintained

[Marco d'Itri]

Control: severity -1 important
Control: affects -1 cfrpki

On Jan 03, Marco d'Itri  wrote:

> gortr has not been updated upstream in over two years and probably most
> users at this point have switched to stayrtr for good.
But cfrpki build-depends on golang-github-cloudflare-gortr-dev, so let's 
ignore this for the time being.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1029116: hw-detect: check-missing-firmware fails will attempting to reload kernel module on MT7922 WiFi card

[Cyril Brulebois]

Hi Stuart,

and thanks for your report.

Stuart Hayhurst  (2023-01-17):
> Source: hw-detect
> Version: 1.152
> Severity: important
> X-Debbugs-Cc: stuart.a.hayhu...@gmail.com
> 
> Running "Detect network interfaces" hangs the installer, and with a
> bit of troubleshooting, it's caused when check-missing-firmware
> removes and loads the kernel module for my WiFi chip (mt7921e driver)

This wouldn't be the first issue about this modprobe dance, but I'm not
sure why the kernel would go haywire… I'm definitely looking into
firmware related issues these days, so maybe I'll be able to reproduce
it somewhere, and/or find a different solution to account for the newly
installed firmware (current plan would be to keep hw-detect ± as is
while introducing support for non-free-firwmare).


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


signature.asc
Description: PGP signature

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Didier 'OdyX' Raboud]

Control: found -1 6.1.6-1
Control: found -1 6.1.4-1
Control: severity -1 serious

Hello there,

Le mardi, 17 janvier 2023, 15.32:37 h CET Diederik de Haas a écrit :
> On Monday, 16 January 2023 22:33:05 CET Didier 'OdyX' Raboud wrote:
> > This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't
> > light up", so feel free to close the bug; I'll test if I get the same
> > symptoms on an unpatched kernel anyway :-)
> 
> If this issue doesn't occur with the unpatched kernel, that would be VERY
> important extra information!
> https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1724186 may be the
> same or similar finding?
> 
> If that issue doesn't occur with the unpatched kernel, could you add your
> finding to that upstream/forwarded issue?

Now that I got my kernel build in place; I can actually confirm that:

On my Thinkpad X13 Gen 2a, without any dongle, hub or docking station (on 
battery), with a KDE Plasma Wayland session:

* 6.0.0-6-amd64 (6.0.12-1)
  suspends and resumes correctly
* 6.1.0-1-amd64 (6.1.4-1, unpatched)
  doesn't finish suspending
* 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, not patched)
  doesn't finish suspending
* 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, patched),
  doesn't finish suspending

All three 6.1 kernels (whether patched or not) don't bring the laptop to the 
suspended state (power led 'breathing', fans off), but it's kept in an "on" 
state (power led on, fans on), from which I found that I *can* wake the laptop 
up by short-pressing the power button; the screens gets back to life and show 
my lockscreen. But from there, I can't move the mouse nor do anything else. 
Alt-SysRq-r + ctrl-alt-f2 give me a tty, but any comeback to tty1 only blank 
(not even a blank screen, just a freeze).

This seems to point to a quite severe regression in amdgpu or other amd-
related code; I can't suspend-and-resume the laptop anymore on any 6.1 kernel, 
on battery, without anything attached to it.

I'll forward the above findings to the bug you pointed to, hoping it could 
help upstream too!

Best,

OdyX

Bug#996799: twitterwatch - upload needed

[Emmanuel Arias]

Hi,

On Tue, Jan 17, 2023 at 6:16 PM Malik  wrote:

> Hello Emmanuel,
>
> currently upstream-author has no plan to update or release any further
> releases for this project [1]
>
Ok

>
>

> [1] https://gitlab.com/chaica/twitterwatch/-/issues/1
>
> kind regards,
> Malik
>

If you leave the package as is it now, when a new release exists, d/watch
won't note it.
So, I'd change the d/watch to the Gitlab repository. Also Homepage link.

Cheers,
Emmanuel

Bug#1028821: pysurfer was still affected by numpy 1.24

[Étienne Mollier]

Control: reassign -1 pysurfer 0.11.0-3
Control: retitle -1 pysurfer ftbfs with numpy 1.24
Control: found -1 0.11.0-3
Control: fixed -1 0.11.0-4

Hi,

I'm under the impression I was not well inspired to reassing the
present bug to mayavi2, because pysurfer still used to ftbfs
after the mayavi2 update.  Thankfully this has been fixed by Bas
patch and Nilesh's upload already.

Besides, it seems that I accidentally entangled a migration
between mayavi2 and pysurfer, which is forbidden at this stage
of the release I believe.  If need be, I'll check with the
Release Team.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#1029093: solaar doesn't enable plugdev when plugdev requested

[Stephen Kitt]

Control: forcemerge 1028922 -1
Control: severity 1028922 important

Hi Mason,

On Tue, 17 Jan 2023 11:05:46 -0500, Mason Loring Bliss 
wrote:
> My previous bug, BZ#1028922, was closed inappropriately, given that the
> bug is not fixed in Bookworm, and will impact Bullseye users until Bullseye
> leaves support.

The Debian bug tracker (which isn’t Bugzilla ;-) takes version information
into account; if you look at the diagram on the right-hand side of
https://bugs.debian.org/1028922 you’ll see that the only fixed version is the
version currently in unstable, and that the versions currently in stable
(Bullseye) and testing (Bookworm) are marked as unfixed. Likewise, if you
compare https://bugs.debian.org/solaar;dist=stable and
https://bugs.debian.org/solaar;dist=unstable you’ll see that the former still
lists 1028922 as outstanding, i.e. unresolved.

I’m merging this bug with 1028922 and upgrading the importance of the latter,
so that it can be fixed in an upcoming Bullseye point release (if the stable
release managers approve).

Regards,

Stephen


pgpYWWwnXEZiU.pgp
Description: OpenPGP digital signature

Bug#1029115: linux-apfs-rw: autopkgtest failure on armel, armhf and i386

[Salvatore Bonaccorso]

Hi,

On Tue, Jan 17, 2023 at 10:22:41PM +0100, Paul Gevers wrote:
> Source: linux-apfs-rw
> Version: 0+git20221028+ds-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fails-always
> 
> Dear maintainer(s),
> 
> You recently added an autopkgtest to your package linux-apfs-rw, great.
> However, it fails on armel, armhf and i386. Currently this failure is
> blocking the migration to testing [1]. Can you please investigate the
> situation and fix it?
> 
> I copied some of the output at the bottom of this report.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=linux-apfs-rw
> 
> https://ci.debian.net/data/autopkgtest/testing/armel/l/linux-apfs-rw/30094133/log.gz
> 
> I: Removing binary package apfs-dkms, to get clean state.
> I: Installing binary package apfs-dkms
> Reading package lists...
> Building dependency tree...
> Reading state information...
> The following NEW packages will be installed:
>   apfs-dkms
> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 96.0 kB of archives.
> After this operation, 605 kB of additional disk space will be used.
> Get:1 http://deb.debian.org/debian unstable/main armel apfs-dkms all
> 0+git20221028+ds-2 [96.0 kB]
> debconf: delaying package configuration, since apt-utils is not installed
> Fetched 96.0 kB in 0s (1502 kB/s)
> Selecting previously unselected package apfs-dkms.
> (Reading database ... (Reading database ... 5%
> (Reading database ... 10%
> (Reading database ... 15%
> (Reading database ... 20%
> (Reading database ... 25%
> (Reading database ... 30%
> (Reading database ... 35%
> (Reading database ... 40%
> (Reading database ... 45%
> (Reading database ... 50%
> (Reading database ... 55%
> (Reading database ... 60%
> (Reading database ... 65%
> (Reading database ... 70%
> (Reading database ... 75%
> (Reading database ... 80%
> (Reading database ... 85%
> (Reading database ... 90%
> (Reading database ... 95%
> (Reading database ... 100%
> (Reading database ... 29846 files and directories currently installed.)
> Preparing to unpack .../apfs-dkms_0+git20221028+ds-2_all.deb ...
> Unpacking apfs-dkms (0+git20221028+ds-2) ...
> Setting up apfs-dkms (0+git20221028+ds-2) ...
> autoinstall for dkms modules has been disabled.
> I: Checking for missing dkms dependency by trying to deinstall dkms
> dpkg: dependency problems prevent removal of dkms:
>  apfs-dkms depends on dkms (>= 2.1.0.0).
> 
> dpkg: error processing package dkms (--remove):
>  dependency problems - not removing
> Errors were encountered while processing:
>  dkms
> I: No Linux header packages are installed.
> I: Installing all available ones from src:linux 6.0.12-1:
> I:   install linux-headers-6.0.0-6-marvell
> I:   install linux-headers-6.0.0-6-rpi
> I:   install linux-headers-marvell
> I:   install linux-headers-rpi
> Reading package lists...
> Building dependency tree...
> Reading state information...
> The following additional packages will be installed:
>   linux-compiler-gcc-12-arm linux-headers-6.0.0-6-common linux-kbuild-6.0
> The following NEW packages will be installed:
>   linux-compiler-gcc-12-arm linux-headers-6.0.0-6-common
>   linux-headers-6.0.0-6-marvell linux-headers-6.0.0-6-rpi
>   linux-headers-marvell linux-headers-rpi linux-kbuild-6.0
> 0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
> Need to get 12.8 MB of archives.
> After this operation, 64.8 MB of additional disk space will be used.
> Get:1 http://deb.debian.org/debian testing/main armel
> linux-compiler-gcc-12-arm armel 6.0.12-1 [556 kB]
> Get:2 http://deb.debian.org/debian testing/main armel
> linux-headers-6.0.0-6-common all 6.0.12-1 [9655 kB]
> Get:3 http://deb.debian.org/debian testing/main armel linux-kbuild-6.0 armel
> 6.0.12-1 [789 kB]
> Get:4 http://deb.debian.org/debian testing/main armel
> linux-headers-6.0.0-6-marvell armel 6.0.12-1 [881 kB]
> Get:5 http://deb.debian.org/debian testing/main armel
> linux-headers-6.0.0-6-rpi armel 6.0.12-1 [867 kB]
> Get:6 http://deb.debian.org/debian testing/main armel linux-headers-marvell
> armel 6.0.12-1 [1144 B]
> Get:7 http://deb.debian.org/debian testing/main armel linux-headers-rpi
> armel 6.0.12-1 [1140 B]
> debconf: delaying package configuration, since apt-utils is not installed
> Fetched 12.8 MB in 0s (31.3 MB/s)
> Selecting previously unselected package linux-compiler-gcc-12-arm.
> (Reading database ... (Reading database ... 5%
> (Reading database ... 10%
> (Reading database ... 15%
> (Reading database ... 20%
> (Reading database ... 25%
> (Reading database ... 30%
> (Reading database ... 35%
> (Reading database ... 40%
> (Reading database ... 45%
> (Reading database ... 50%
> (Reading database ... 55%
> (Reading database ... 60%
> (Reading database ... 65%
> (Reading database ... 70%
> (Reading database ... 75%
> (Reading database ... 80%
> 

Bug#1029103: coreutils: csplit: -z misdocumented

[Pádraig Brady]

Fair point.
I'll clarify like:

commit 70dc90c579adc972644c9047543ff1dc611b89cc (HEAD -> master)
Author: Pádraig Brady 
Date:   Tue Jan 17 21:31:31 2023 +

doc: csplit: more accurate --elide-empty-files help

* src/csplit.c (usage): Use "suppress" rather than "remove"
when describing -z so it's more apparent that the effect
is a particular numbered file is not created, rather than
being removed later.  I.e., don't suggest -z may induce
gaps in file numbering.

diff --git a/src/csplit.c b/src/csplit.c
index da4b36a7c..9a31697b6 100644
--- a/src/csplit.c
+++ b/src/csplit.c
@@ -1471,7 +1471,7 @@ Read standard input if FILE is -\n\
   fputs (_("\
   -n, --digits=DIGITSuse specified number of digits instead of 2\n\
   -s, --quiet, --silent  do not print counts of output file sizes\n\
-  -z, --elide-empty-filesremove empty output files\n\
+  -z, --elide-empty-filessuppress empty output files\n\
 "), stdout);
   fputs (HELP_OPTION_DESCRIPTION, stdout);
   fputs (VERSION_OPTION_DESCRIPTION, stdout);

Bug#1029116: hw-detect: check-missing-firmware fails will attempting to reload kernel module on MT7922 WiFi card

[Stuart Hayhurst]

Source: hw-detect
Version: 1.152
Severity: important
X-Debbugs-Cc: stuart.a.hayhu...@gmail.com

Running "Detect network interfaces" hangs the installer, and with a bit of 
troubleshooting, it's caused when check-missing-firmware removes and loads the 
kernel module for my WiFi chip (mt7921e driver)

check-missing-firmware: removing and loading kernel module mt7921e
Jan 17 21:16:49 check-missing-firmware: installing firmware package 
/media/firmware/firmware-misc-nonfree_20221214-3_all.deb
Jan 17 21:16:53 check-missing-firmware: removing and loading kernel module 
mt7921e
Jan 17 21:16:53 kernel: [ 1290.681036] [ cut here ]
Jan 17 21:16:53 kernel: [ 1290.681044] WARNING: CPU: 0 PID: 6956 at 
kernel/workqueue.c:3066 __flush_work.isra.0+0x270/0x280
Jan 17 21:16:53 kernel: [ 1290.681066] Modules linked in: nls_ascii nls_cp437 
vfat fat mt7921e(-) mt7921_common mt76_connac_lib mt76 mac80211 libarc4 
cfg80211 rfkill isofs cdrom dm_mod sd_mod uas usb_storage scsi_mod scsi_common 
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi 
snd_hda_intel snd_intel_dspcfg snd_acp6x_pdm_dma snd_soc_acp6x_mach 
snd_intel_sdw_acpi snd_soc_dmic snd_hda_codec snd_soc_core nvme snd_hda_core 
snd_compress snd_pci_acp6x snd_hwdep nvme_core snd_pcm xhci_pci sdhci_pci 
snd_timer t10_pi snd_pci_acp5x cqhci xhci_hcd hid_sensor_custom 
snd_rn_pci_acp3x crc64_rocksoft snd crc64 snd_acp_config sdhci hid_multitouch 
video snd_soc_acpi crc_t10dif hid_sensor_hub hid_generic usbcore mmc_core 
crc32_pclmul evdev i2c_hid_acpi snd_pci_acp3x usb_common soundcore i2c_hid 
crct10dif_common battery wmi hid
Jan 17 21:16:53 kernel: [ 1290.681174] CPU: 0 PID: 6956 Comm: modprobe Tainted: 
GE  6.1.0-1-amd64 #1  Debian 6.1.4-1
Jan 17 21:16:53 kernel: [ 1290.681180] Hardware name: LENOVO 82QF/LNVNB161216, 
BIOS K5CN35WW 09/23/2022
Jan 17 21:16:53 kernel: [ 1290.681183] RIP: 0010:__flush_work.isra.0+0x270/0x280
Jan 17 21:16:53 kernel: [ 1290.681191] Code: 8b 04 25 c0 fb 01 00 48 89 44 24 
40 48 8b 73 30 8b 4b 28 e9 e3 fe ff ff 40 30 f6 4c 8b 3e e9 21 fe ff ff 0f 0b 
e9 3a ff ff ff <0f> 0b e9 33 ff ff ff e8 b4 40 95 00 0f 1f 40 00 0f 1f 44 00 00 
55
Jan 17 21:16:53 kernel: [ 1290.681195] RSP: 0018:aab880e8fc20 EFLAGS: 
00010246
Jan 17 21:16:53 kernel: [ 1290.681199] RAX:  RBX: 
9a00d4257bd8 RCX: 
Jan 17 21:16:53 kernel: [ 1290.681202] RDX: 0001 RSI: 
 RDI: aab880e8fc68
Jan 17 21:16:53 kernel: [ 1290.681204] RBP: 9a00d4257bd8 R08: 
 R09: 
Jan 17 21:16:53 kernel: [ 1290.681206] R10:  R11: 
0001 R12: 
Jan 17 21:16:53 kernel: [ 1290.681207] R13: aab880e8fc20 R14: 
0001 R15: c082c108
Jan 17 21:16:53 kernel: [ 1290.681210] FS:  7fd893d77740() 
GS:9a03afc0() knlGS:
Jan 17 21:16:53 kernel: [ 1290.681213] CS:  0010 DS:  ES:  CR0: 
80050033
Jan 17 21:16:53 kernel: [ 1290.681215] CR2: 7fd893e569f0 CR3: 
00010171 CR4: 00750ef0
Jan 17 21:16:53 kernel: [ 1290.681218] PKRU: 5554
Jan 17 21:16:53 kernel: [ 1290.681220] Call Trace:
Jan 17 21:16:53 kernel: [ 1290.681224]  
Jan 17 21:16:53 kernel: [ 1290.681233]  __cancel_work_timer+0xff/0x190
Jan 17 21:16:53 kernel: [ 1290.681242]  rfkill_unregister+0x3c/0xe0 [rfkill]
Jan 17 21:16:53 kernel: [ 1290.681256]  wiphy_unregister+0x66/0x3b0 [cfg80211]
Jan 17 21:16:53 kernel: [ 1290.681315]  ? _raw_spin_lock_irqsave+0x23/0x50
Jan 17 21:16:53 kernel: [ 1290.681323]  ? _raw_spin_unlock_irqrestore+0x23/0x40
Jan 17 21:16:53 kernel: [ 1290.681327]  ? skb_dequeue+0x6e/0x80
Jan 17 21:16:53 kernel: [ 1290.681334]  ieee80211_unregister_hw+0xd4/0x100 
[mac80211]
Jan 17 21:16:53 kernel: [ 1290.681391]  mt7921_pci_remove+0x44/0x110 [mt7921e]
Jan 17 21:16:53 kernel: [ 1290.681401]  pci_device_remove+0x36/0xa0
Jan 17 21:16:53 kernel: [ 1290.681409]  
device_release_driver_internal+0x1b2/0x230
Jan 17 21:16:53 kernel: [ 1290.681417]  driver_detach+0x44/0x90
Jan 17 21:16:53 kernel: [ 1290.681420]  bus_remove_driver+0x55/0xe0
Jan 17 21:16:53 kernel: [ 1290.681428]  pci_unregister_driver+0x2a/0xb0
Jan 17 21:16:53 kernel: [ 1290.681434]  __do_sys_delete_module+0x1d5/0x320
Jan 17 21:16:53 kernel: [ 1290.681442]  do_syscall_64+0x5b/0xc0
Jan 17 21:16:53 kernel: [ 1290.681449]  ? do_syscall_64+0x67/0xc0
Jan 17 21:16:53 kernel: [ 1290.681453]  ? syscall_exit_to_user_mode+0x17/0x40
Jan 17 21:16:53 kernel: [ 1290.681457]  ? do_syscall_64+0x67/0xc0
Jan 17 21:16:53 kernel: [ 1290.681460]  ? do_syscall_64+0x67/0xc0
Jan 17 21:16:53 kernel: [ 1290.681464]  ? 
fpregs_assert_state_consistent+0x22/0x50
Jan 17 21:16:53 kernel: [ 1290.681471]  ? exit_to_user_mode_prepare+0x3c/0x1c0
Jan 17 21:16:53 kernel: [ 1290.681474]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
Jan 17 21:16:53 kernel: [ 1290.681479] RIP: 0033:0x7fd893e838f7
Jan 17 21:16:53 kernel: [ 

Bug#1029115: linux-apfs-rw: autopkgtest failure on armel, armhf and i386

[Paul Gevers]

Source: linux-apfs-rw
Version: 0+git20221028+ds-2
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package linux-apfs-rw, great. 
However, it fails on armel, armhf and i386. Currently this failure is 
blocking the migration to testing [1]. Can you please investigate the 
situation and fix it?


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

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

Paul

[1] https://qa.debian.org/excuses.php?package=linux-apfs-rw

https://ci.debian.net/data/autopkgtest/testing/armel/l/linux-apfs-rw/30094133/log.gz

I: Removing binary package apfs-dkms, to get clean state.
I: Installing binary package apfs-dkms
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  apfs-dkms
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 96.0 kB of archives.
After this operation, 605 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main armel apfs-dkms all 
0+git20221028+ds-2 [96.0 kB]

debconf: delaying package configuration, since apt-utils is not installed
Fetched 96.0 kB in 0s (1502 kB/s)
Selecting previously unselected package apfs-dkms.
(Reading database ... (Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 29846 files and directories currently installed.)
Preparing to unpack .../apfs-dkms_0+git20221028+ds-2_all.deb ...
Unpacking apfs-dkms (0+git20221028+ds-2) ...
Setting up apfs-dkms (0+git20221028+ds-2) ...
autoinstall for dkms modules has been disabled.
I: Checking for missing dkms dependency by trying to deinstall dkms
dpkg: dependency problems prevent removal of dkms:
 apfs-dkms depends on dkms (>= 2.1.0.0).

dpkg: error processing package dkms (--remove):
 dependency problems - not removing
Errors were encountered while processing:
 dkms
I: No Linux header packages are installed.
I: Installing all available ones from src:linux 6.0.12-1:
I:   install linux-headers-6.0.0-6-marvell
I:   install linux-headers-6.0.0-6-rpi
I:   install linux-headers-marvell
I:   install linux-headers-rpi
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  linux-compiler-gcc-12-arm linux-headers-6.0.0-6-common linux-kbuild-6.0
The following NEW packages will be installed:
  linux-compiler-gcc-12-arm linux-headers-6.0.0-6-common
  linux-headers-6.0.0-6-marvell linux-headers-6.0.0-6-rpi
  linux-headers-marvell linux-headers-rpi linux-kbuild-6.0
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.8 MB of archives.
After this operation, 64.8 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian testing/main armel 
linux-compiler-gcc-12-arm armel 6.0.12-1 [556 kB]
Get:2 http://deb.debian.org/debian testing/main armel 
linux-headers-6.0.0-6-common all 6.0.12-1 [9655 kB]
Get:3 http://deb.debian.org/debian testing/main armel linux-kbuild-6.0 
armel 6.0.12-1 [789 kB]
Get:4 http://deb.debian.org/debian testing/main armel 
linux-headers-6.0.0-6-marvell armel 6.0.12-1 [881 kB]
Get:5 http://deb.debian.org/debian testing/main armel 
linux-headers-6.0.0-6-rpi armel 6.0.12-1 [867 kB]
Get:6 http://deb.debian.org/debian testing/main armel 
linux-headers-marvell armel 6.0.12-1 [1144 B]
Get:7 http://deb.debian.org/debian testing/main armel linux-headers-rpi 
armel 6.0.12-1 [1140 B]

debconf: delaying package configuration, since apt-utils is not installed
Fetched 12.8 MB in 0s (31.3 MB/s)
Selecting previously unselected package linux-compiler-gcc-12-arm.
(Reading database ... (Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 29875 files and directories currently installed.)
Preparing to unpack .../0-linux-compiler-gcc-12-arm_6.0.12-1_armel.deb ...
Unpacking linux-compiler-gcc-12-arm (6.0.12-1) ...

Bug#1029113: postfix: updated German po-file

[Markus Hiereth]

Package: postfix
Version: 3.7.3-4
Severity: normal

Dear Maintainer,

find the attached german messages for the debconf dialogue. The two 
fuzzy strings were checked and improved. The po-file has been proof-read by the 
German language team.

Best regards
Markus

-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-9-686-pae (SMP w/1 CPU thread)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
# Translation of postfix debconf templates to German
# This file is distributed under the same license as the postfix package.
# Copyright (C) Helge Kreutzmann , 2006-2008, 2012, 2014, 
2016.
# Markus Hiereth , 2016, 2018, 2022, 2023
msgid ""
msgstr ""
"Project-Id-Version: postfix 3.7.3-4\n"
"Report-Msgid-Bugs-To: post...@packages.debian.org\n"
"POT-Creation-Date: 2021-12-28 14:12-0500\n"
"PO-Revision-Date: 2023-01-15 22:00+0100\n"
"Last-Translator: Markus Hiereth \n"
"Language-Team: debian-l10n-german \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Update configuration to avoid compatibility warnings?"
msgstr ""
"Um Warnungen zu Inkompatibiltäten zu vermeiden, die Konfiguration "
"aktualisieren?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"This upgrade of Postfix changes some default values in the configuration. As "
"part of this upgrade, the following will be changed: (1) chrooted components "
"will be changed from '-' to 'y' in master.cf, and (2) myhostname will be set "
"to a fully-qualified domain name if it is not already such. The install will "
"be aborted if you do not allow the change."
msgstr ""
"Diese Aktualisierung von Postfix ändert einige Standardwerte der "
"Konfiguration. Dazu gehört: (1) in master.cf wird bei chrooted-Komponenten "
"der Wert '-' durch 'y' ersetzt. (2) »myhostname« wird, falls die Variable "
"noch nicht die Anforderungen an einen voll-qualifizierten Domainnamen (FQDN) "
"erfüllt, in eine solche überführt. Sollten Sie diese Änderungen nicht "
"zulassen, wird die Installation abgebrochen."

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Update main.cf for daemon_directory change?"
msgstr "main.cf für eine Änderung von »daemon_directory« aktualisieren?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"This upgrade of Postfix changes where daemons are located, and your Postfix "
"configuration explicitly specifies the old location. The install will be "
"aborted if you do not allow the change."
msgstr ""
"Dieses Upgrade von Postfix ändert den Ort von Hintergrundprozessen, Ihre "
"Postfix-Konfiguration spezifiziert allerdings ausdrücklich den alten Ort. "
"Sollten Sie diese Änderungen nicht zulassen, wird die Installation "
"abgebrochen."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Update dynamicmaps.cf for 3.0?"
msgstr "dynamicmaps.cf für 3.0 aktualisieren?"

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"Postfix version 3.0 changes how dynamic maps are delivered, and your "
"dynamicmaps.cf does not reflect that. Accept this option to convert "
"dynamicmaps.cf to the version required for 3.0."
msgstr ""
"Mit Postfix Version 3.0 ändert sich, wie dynamische Zuordnungen "
"bereitgestellt werden, Ihre dynamicmaps.cf widerspiegelt dies jedoch nicht. "
"Akzeptieren Sie diese Option, um dynamicmaps.cf in die für 3.0 benötigte "
"Version zu konvertieren."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Ignore incorrect hostname entry?"
msgstr "Fehlerhaften Hostnamen-Eintrag ignorieren?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"The string '${enteredstring}' does not follow RFC 1035 and does not appear "
"to be a valid IP address."
msgstr ""
"Die Zeichenkette »${enteredstring}« entspricht nicht RFC 1035 und scheint "
"keine gültige IP-Adresse zu sein."

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"RFC 1035 states that 'each component must start with an alphanum, end with "
"an alphanum and contain only alphanums and hyphens. Components must be "
"separated by full stops.'"
msgstr ""
"RFC 1035 fordert, dass »jede Komponente mit einem alphanumerischen Zeichen "
"beginnen und enden muss und ansonsten auch nur aus alphanumerischen Zeichen "
"und Bindestrichen bestehen darf. Alle Komponenten müssen jeweils durch einen "
"Punkt getrennt werden«."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Please check and confirm if you want to keep your entry."
msgstr ""
"Bitte kontrollieren und bestätigen Sie, falls Sie Ihren Eintrag beibehalten 
möchten."

#. Type: select
#. Choices
#. Translators beware! 

Bug#1029114: git: CVE-2022-23521 CVE-2022-41903

[Salvatore Bonaccorso]

Source: git
Version: 1:2.30.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:2.39.0-1

Hi,

The following vulnerabilities were published for git.

CVE-2022-23521[0]:
| gitattributes parsing integer overflow

CVE-2022-41903[1]:
| heap overflow in `git archive` and `git log --format`

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#996799: twitterwatch - upload needed

[Malik]

Hello Emmanuel,

currently upstream-author has no plan to update or release any further
releases for this project [1]

[1] https://gitlab.com/chaica/twitterwatch/-/issues/1

kind regards,
Malik

Am So., 15. Jan. 2023 um 13:28 Uhr schrieb Emmanuel Arias <
eam...@yaerobi.com>:

> Hi,
>
> On Sun, Jan 15, 2023 at 12:24:43PM +0100, Malik wrote:
> > Hello Emannauel,
> >
> > Thank you for the suggestions.
> >
> > I was not sure how to handle the new homepage [1]  since there are no
> tags
> > or releases maintained by the upstream maintainer, should I delete the
> > watchfile? or can I watch the version in the setup.py ?
>
> Oh, I didn't note it. Perhaps it's a good reason to contact to upstream
> and ask for them. Don't remove d/watch file.
>
> >
> > And for the tests, should I mock the calls to the "internet" since those
> > would be skipped if conceited to the internet
>
> Yes, or skip them.
> >
> >
> > [1]: https://gitlab.com/chaica/twitterwatch/-/tags
> >
> > regards,
> > Malik
> >
>
> Cheers,
> Emmanuel
>


-- 
Malik Mlitat

Bug#1029112: Surprise build issue with ibus-libzhuyin

[Gunnar Hjalmarsson]

Package: src:ibus-libzhuyin
Version: 1.10.2-1
Severity: serious
Tags: ftbfs

Hello!

ibus-libzhuyin 1.10.2-1 failed to build. This is the relevant part of 
the buildlog:


Making all in model
make[4]: Entering directory '/<>/data/model'
wget http://downloads.sourceforge.net/libzhuyin/models/model13.text.tar.gz
/bin/bash: line 1: wget: command not found

And yes, it's true that wget is not included in Build-Depends. But 
previously that has not been needed. This is from the buildlog for the 
latest successful build:


Making all in model
make[4]: Entering directory '/<>/data/model'
rm -f phrase_index.bin pinyin_index.bin addon_phrase_index.bin 
addon_pinyin_index.bin bigram.db tsi.bin

gen_binary_files --table-dir ../../data/model
import_interpolation --table-dir ../../data/model < 
../../data/model/interpolation2.text

gen_unigram --table-dir ../../data/model

or just:

Making check in model
make[3]: Entering directory '/<>/data/model'
make[3]: Nothing to be done for 'check'.

I have not found any code changes which would explain the new behavior. 
And when trying (in an Ubuntu PPA) to add wget to Build-Depends, it 
failed to resolve the download URL. (It builds fine on my harddisk, though.)


I figured out that this patch would help it build successfully:

--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -27,7 +27,6 @@

  SUBDIRS = \
  icons \
-model \
  $(NULL)

  appdatadir = @datadir@/appdata

But since I don't know how that would affect the functionality of the 
package, I have left it in its failed state for now.


In other words: I need help to solve this.

--
Rgds,
Gunnar

Bug#1028192: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

[Sebastian Reichel]

Hi,

On Sat, 14 Jan 2023 21:53:59 + Martin  wrote:
> Control: severity -1 normal
> 
> The problem disappeared magically for all users who reported it before.
> I assume, that there is a hidden bug in libproxy, that only appears in
> certain circumstances. Downgrading for now.

I just got the new package through testing and now gajim segfaults
ony my system with stacktrace pointing to libproxy. So this is not
magically solved.

-- Sebastian


signature.asc
Description: PGP signature

Bug#924862: Enable shaderc support in mpv

[Shmerl]

Now that shaderc was added to Debian unstable / testing, can you please
enable building mpv with it?

See: https://tracker.debian.org/pkg/shaderc

Thanks!

Shmerl.

Bug#1029111: rtl8723bt-firmware: please move to non-free-firmware/kernel section

[Cyril Brulebois]

Package: rtl8723bt-firmware
Severity: important
Tags: patch

Hi,

The installer team is currently implementing a plan to make firmware
packages installed from non-free-firmware, which would mean no longer
having to enable non-free just to install firmware packages (and keep
them up-to-date).

The attached patch prepares rtl8723bt-firmware for this plan.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru rtl8723bt-firmware-20181104/debian/changelog 
rtl8723bt-firmware-20181104/debian/changelog
--- rtl8723bt-firmware-20181104/debian/changelog2022-05-26 
09:32:47.0 +0200
+++ rtl8723bt-firmware-20181104/debian/changelog2023-01-17 
21:05:17.0 +0100
@@ -1,3 +1,10 @@
+rtl8723bt-firmware (20181104-2) UNRELEASED; urgency=medium
+
+  * Move source and binary from non-free/kernel to non-free-firmware/kernel
+following the 2022 General Resolution about non-free firmware.
+
+ -- Cyril Brulebois   Tue, 17 Jan 2023 20:05:17 +
+
 rtl8723bt-firmware (20181104-1) unstable; urgency=medium
 
   * Initial release. (Closes: #1011744)
diff -Nru rtl8723bt-firmware-20181104/debian/control 
rtl8723bt-firmware-20181104/debian/control
--- rtl8723bt-firmware-20181104/debian/control  2022-05-26 09:32:47.0 
+0200
+++ rtl8723bt-firmware-20181104/debian/control  2023-01-17 21:05:17.0 
+0100
@@ -1,5 +1,5 @@
 Source: rtl8723bt-firmware
-Section: non-free/kernel
+Section: non-free-firmware/kernel
 Priority: optional
 Maintainer: Bastian Germann 
 Rules-Requires-Root: no

Bug#1029110: firmware-ast: Please move to non-free-firmware/kernel section

[Cyril Brulebois]

Package: firmware-ast
Severity: important
Tags: patch

Hi,

The installer team is currently implementing a plan to make firmware
packages installed from non-free-firmware, which would mean no longer
having to enable non-free just to install firmware packages (and keep
them up-to-date).

The attached patch prepares firmware-ast for this plan.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
>From 701bd7112cfb508804e164c79405af687b2c8f1d Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Mon, 16 Jan 2023 23:53:51 +
Subject: [PATCH] Move to non-free-firmware/kernel section.

Move source and binary from non-free/kernel to non-free-firmware/kernel
following the 2022 General Resolution about non-free firmware.
---
 debian/changelog | 7 +++
 debian/control   | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index f04d8f8..8049ebe 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+firmware-ast (20140808-7) UNRELEASED; urgency=medium
+
+  * Move source and binary from non-free/kernel to non-free-firmware/kernel
+following the 2022 General Resolution about non-free firmware.
+
+ -- Cyril Brulebois   Mon, 16 Jan 2023 23:52:40 +
+
 firmware-ast (20140808-6) sid; urgency=medium
 
   * Uploading to sid.
diff --git a/debian/control b/debian/control
index 8508697..0342243 100644
--- a/debian/control
+++ b/debian/control
@@ -1,5 +1,5 @@
 Source: firmware-ast
-Section: non-free/kernel
+Section: non-free-firmware/kernel
 Priority: optional
 Maintainer: Daniel Baumann 
 Build-Depends:
@@ -13,7 +13,7 @@ Vcs-Git: 
https://git.progress-linux.org/users/daniel.baumann/debian/packages/fir
 XS-Autobuild: yes
 
 Package: firmware-ast
-Section: non-free/kernel
+Section: non-free-firmware/kernel
 Architecture: all
 Multi-Arch: foreign
 Depends:
-- 
2.30.2

Bug#1029109: cimg: build dependency gone after tiff transition

[Paul Gevers]

Source: cimg
Version: 3.1.6+dfsg-6
Severity: serious
User: debian...@lists.debian.org
Usertag: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting issues with your packages. Normally your build 
dependencies shouldn't be removed from testing without removal all 
reverse build dependencies too, nor should a package be allowed to 
migrate unless all build dependencies are candidate for migration too. 
However, somehow we ended up in the current state and your source 
package is missing some Build-Depends for some while now. Not being able 
to build from source in a suite is an RC bug in that suite.


Your package Build-Depends on a particular SONAME of the tiff library, 
but that was dropped in the last tiff transition. Are you sure you need 
to Build-Depends on the library, it's already pulled in via the tiff 
header package.


Can you please solve the situation by either helping the maintainer of 
your Build-Depends to enable migration to testing, or by working around 
the lack of this build dependency?


Paul

[1] https://qa.debian.org/dose/debcheck/src_testing_main/index.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028957: librocrand-dev: rocrand_INCLUDE_DIR does not exist

[Cordell Bloor]

Thanks for taking a look at this, Étienne.

On 1/15/23 11:16, Étienne Mollier wrote:

Not sure it will help, but I suppose I could first bump the
rocrand package up to 5.2.3 to be consistent with the build
chain.  It should still be easy to do while we're not in the
next stage of the freeze on February 12th.


I would not worry too much about exactly matching the HIP version, 
though. While rocrand 5.3 was in development, the hip 5.3 library didn't 
exist. The upstream developers would have been building and testing on 
hip 5.2 (or earlier) during most of the development cycle.


IMO, it's perfectly fine to update to any version of rocrand that passes 
its test suite. My suggestion is 5.3.3, since it matches the other 
mathlibs in Debian, but 5.4.2 would also be fine and 5.2.3 could 
probably be made to work with minor patches.



The upstream hipRAND repo does't have any tags (and therefore getting tarballs
with uscan might be tricky?). If tags would help, I can work with upstream to
get them added retroactively for rocm-5.1.0 and later. Just let me know.

For a regular package it would be possible to use git commit IDs
instead, but that leads to hard to read version numbers.  In the
case of MUT, strolling through the example from rocm-hipamd, I
see it may be necessary to restrict the version number of the
side tarball to be the same as the main source package.  So...
yes please?  :)

The tags have now been added to hipRAND. 
https://github.com/ROCmSoftwarePlatform/hipRAND/tags


Sincerely,
Cory Bloor

Bug#1029108: tuxguitar: limit build architectures

[tony mancill]

Package: tuxguitar
Version: 1.5.6+dfsg1-1
Severity: important

tuxguitar is FTBFS on multiple architectures:

https://buildd.debian.org/status/logs.php?pkg=tuxguitar=1.5.6%2Bdfsg1-1

We should either address the FTBFS or limit the build architectures in
the next upload.

Bug#854209: Update Description

[Soren Stoutner]

Once this bug has been fixed, it would probably make sense to update the 
Lintian description to indicate that the problematic file can be appropriately 
relicensed to a DFSG compatible license, with a link to this bug report for 
information about the details.

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1028451: 2nd DisplayPort doesn't get video

[Paul Gevers]

Hi,

On 17-01-2023 07:14, Salvatore Bonaccorso wrote:

I will bite the bullet (taking full responsibility for it if
necessary, don't blame the other kernel team members) and ask here now
the release team: Can we let linux 6.1.4-1 despite the RC bug
reported, migrate to testing, so we can move on to 6.1.y?


I have added the hints. linux should migrate in the 22:00 UTC britney run.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029107: vfu: problem with long cyrillic file names

[Anonymous 648]

Package: vfu
Version: 4.21-1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

1) Create file with long latin name
touch 
lng_name.ext

2) Create file with long cyrillic(non latin) name
touch 
жж.ext
 

3) Run vfu 

Cyrillic name gets cut off. Please check screenshot attached.


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

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

Versions of packages vfu depends on:
ii  bzip2 1.0.8-4
ii  libc6 2.31-13+deb11u5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libpcre3  2:8.39-13
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  unzip 6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#1029066: diffoscope: FTBFS if no internet is available (using internet connection during build)

[Vagrant Cascadian]

Control: found 1029066 230

On 2023-01-17, Gianfranco Costamagna wrote:
> Hello, your package FTBFS when internet is not available during control file 
> regeneration phase
...
> debian/tests/control.sh
> Generating the debian/tests/control file...
...
> ERROR: Could not find a version that satisfies the requirement setuptools 
> (from versions: none)
> ERROR: No matching distribution found for setuptools
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib/python3/dist-packages/pep517/meta.py", line 72, in load
>  path = Path(build_as_zip(builder))
>  ^
>File "/usr/lib/python3/dist-packages/pep517/meta.py", line 59, in 
> build_as_zip
>  builder(dest=out_dir)
>File "/usr/lib/python3/dist-packages/pep517/meta.py", line 53, in build
>  env.pip_install(system['requires'])
>File "/usr/lib/python3/dist-packages/pep517/envbuild.py", line 103, in 
> pip_install
>  check_call(
>File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
>  raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m', 'pip', 
> 'install', '--ignore-installed', '--prefix', 
> '/tmp/pep517-build-env-i1vz1wye', 'setuptools', 'wheel']' returned non-zero 
> exit status 1.
> Files debian/tests/control and debian/tests/control.tmp differ
>
> The generated control file differs from the actual one.
> A sourceful upload of this package is needed.
>
> Differences:
> --- debian/tests/control  2023-01-13 07:05:01.0 +
> +++ debian/tests/control.tmp  2023-01-17 02:06:59.340564039 +
> @@ -7,7 +7,7 @@
>   #   $ mv debian/tests/control.tmp debian/tests/control
>   
>   Tests: pytest-with-recommends
> -Depends: python3-all, diffoscope, black, python3-pytest, python3-h5py, file, 
> linux-image-amd64 [amd64] | linux-image-generic [amd64], abootimg, acl, 
> apksigcopier, apksigner, apktool [!ppc64el !s390x], binutils-multiarch, 
> bzip2, caca-utils, colord, coreboot-utils, db-util, default-jdk-headless | 
> default-jdk | java-sdk, device-tree-compiler, docx2txt, e2fsprogs, enjarify, 
> ffmpeg, fontforge-extras, fonttools, fp-utils [!ppc64el !s390x], genisoimage, 
> gettext, ghc, ghostscript, giflib-tools, gnumeric, gnupg, gnupg-utils, 
> hdf5-tools, html2text, imagemagick, jsbeautifier, libarchive-tools, 
> libxmlb-dev, llvm, lz4 | liblz4-tool, lzip, mono-utils, ocaml-nox, odt2txt, 
> oggvideotools [!s390x], openssh-client, openssl, pgpdump, poppler-utils, 
> procyon-decompiler, python3-pdfminer, r-base-core, rpm2cpio, sng, sqlite3, 
> squashfs-tools, tcpdump, u-boot-tools, unzip, wabt, xmlbeans, xxd, xz-utils, 
> zip, zstd, androguard, python3-argcomplete, python3-binwalk, 
> python3-defusedxml, python3-distro, python3-guestfs, python3-jsondiff, 
> python3-progressbar, python3-pypdf, python3-debian, python3-pyxattr, 
> python3-rpm, python3-tlsh
> +Depends: python3-all, diffoscope, black, python3-pytest, python3-h5py, file, 
> linux-image-amd64 [amd64] | linux-image-generic [amd64], abootimg, acl, 
> apksigcopier, apksigner, apktool [!ppc64el !s390x], binutils-multiarch, 
> bzip2, caca-utils, colord, coreboot-utils, db-util, default-jdk-headless | 
> default-jdk | java-sdk, device-tree-compiler, docx2txt, e2fsprogs, enjarify, 
> ffmpeg, fontforge-extras, fonttools, fp-utils [!ppc64el !s390x], genisoimage, 
> gettext, ghc, ghostscript, giflib-tools, gnumeric, gnupg, gnupg-utils, 
> hdf5-tools, html2text, imagemagick, jsbeautifier, libarchive-tools, 
> libxmlb-dev, llvm, lz4 | liblz4-tool, lzip, mono-utils, ocaml-nox, odt2txt, 
> oggvideotools [!s390x], openssh-client, openssl, pgpdump, poppler-utils, 
> procyon-decompiler, python3-pdfminer, r-base-core, rpm2cpio, sng, sqlite3, 
> squashfs-tools, tcpdump, u-boot-tools, unzip, wabt, xmlbeans, xxd, xz-utils, 
> zip, zstd,

Confirmed that it also affects the version in bookworm:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope.html

And according to test history, may go back to much earlier versions
(222+)... although there were some other possible FTBFS issues that may
have affected older versions, and I don't immediately see a way to look
at the logs from older versions.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027613: update

[M. Zhou]

Control: severity -1 important

I think this FTBFS mostly stems from the toolchain.

1. before the bug is filed, it builds successfully on amd64
2. On the day I recieved this bug report, I reproduced it
3. after some toolchain updates, I cannot reproduce it anymore

Bug#1029106: make: new upstream release (4.4)

[Jakub Wilk]

Source: make-dfsg
Severity: wishlist

--
Jakub Wilk

Bug#1018775: fix is in 1.13.0

[Bastian Germann]

Control: fixed -1 1.13.0-1

The upstream version that claims to fix this is already in Debian.

Bug#1029079: akonadi-backend-mysql: Build against default-mysql-{client,server}-core 1.1.0

[Patrick Franz]

Hi Sedat,

On Tue, 17 Jan 2023 14:51:56 +0100 Sedat Dilek  
wrote:
> I removed akonadi-backend-mysql from my Debian/unstable AMD64 box as I 
> need a higher version of mariadb.

There is no need to remove akonadi-backend-mysql from Sid and I also 
don't see why we would need to rebuild it.
During the upgrade of MariaDB, the package default-mysql-server-core is 
unconfigured for a short moment, but that's it. The log should tell you 
that it's configured afterwards.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1014125: libheif: CVE-2020-23109

[Bastian Germann]

Control: fixed -1 1.8.0-1

This is claimed to be fixed with 
https://github.com/strukturag/libheif/commit/bca0162018df9a32d21c05aad1fa203881fa7813
which was included in v1.7.0

Bug#1029105: /usr/bin/getmails: 32: Bad substitution

[Robbie Harwood (frozencemetery)]

Package: getmail6
Version: 6.18.11-1
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

When running getmails, I get this:

$ getmails
/usr/bin/getmails: 32: Bad substitution
$

and it bails out without downloading any mail.

Of course it's still possible to run getmail itself without the wrapper
script.

Be well,
--Robbie

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/12 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 getmail6 depends on:
ii  python3  3.10.6-3+b1

getmail6 recommends no packages.

getmail6 suggests no packages.

-- no debconf information

Bug#1029097: pam: FTBFS on hurd-i386

[Sam Hartman]

> "Svante" == Svante Signell  writes:
Svante> modules_pam_nologin_tst-pam_nologin-retval.c.diff disabling
Svante> two subtests failing on GNU/Hurd.  -

Why do these subtests fail?

Svante> 
Svante> debian_libpam-modules-bin.install.hurd-i386.patch creating
Svante> an install file for Hurd excluding two systemd-specific
Svante> files not needed.

Why is installing these files harmful?
I'm reluctant to take  this patch unless it actually breaks something
and there's no other way to do it.
If I take this patch, then I'll have to remember to update the hurd
install list every time something changes.


signature.asc
Description: PGP signature

Bug#1029101: Acknowledgement (fontconfig-config: 2.14.1 upload breaks testSimpleText of libreoffice)

[Rene Engelhard]

severity 1029101 important
retitle 1029101 please Enable RGB stripes layout for sub-pixel rendering 
on KDE only

thanks

[ sorry for "spamming" ]

Hi,

Am 17.01.23 um 19:04 schrieb Rene Engelhard:
it still fails. Probably it ignores it since it's already set in /etc 
and that already matches?


OK, got it. I need to "delete" it.

  

mode="delete">rgb

  


Then it passes and it shouldn't  break with 2.13 either since deleting 
somethng non-existing works ;-)


Will reassign a clone to libreoffice to fix that test failure.

Regards,


Rene

Bug#1028439:

[deb-bug . oluj0xj403ou050siy9dpk2z]

As this is still open and breaking many computers: Here is one more hand to 
confirm.

Would you mind explaining what an 's.d.o downgrade' entails? I used the 
snapshot archive and pinned the offender, then used aptitude and skipped 
through solutions until I found an acceptable one. (apt wants to kill all of 
X!). That is a pretty convoluted and unreliable process. 'dontbreakdebian' also 
says to never mess around like that.
There is no official SOP as far as I'm aware.

The process on Fedora given here 
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8007 seems a lot more 
straightforward.

I understand this is 'testing' - but Debian testing > Arch regular and many 
people even consider sid to be usable everyday (see 'siduction').

Can we please revert this package instantly while we wait for an upstream fix? 
Testing is so darn stable usually, many 'normal' people use it in prod. This is 
a very severe bug in my book, right next to that kernel one a few months ago 
killing screens. Unless you're rather deep into Debian, you're never going to 
find the workaround, and likely just move on.

Bug#927302: Please send me more ads 梁

[Smantha Mwebaze]

Bug#1029101: Acknowledgement (fontconfig-config: 2.14.1 upload breaks testSimpleText of libreoffice)

[Rene Engelhard]

Hi again,

Am 17.01.23 um 18:28 schrieb Rene Engelhard:
I tried to adapt the test to expected values but failed. When I adapt 
some values stuff even further breaks, and at the 50% test I then had no 
idea what to do.)


LO has already a fc_local.conf:

./instdir/share/fonts/truetype/fc_local.conf

but when I add the stuff from the patch  there

rene@frodo:~/Debian/Pakete/LibreOffice/libreoffice/libreoffice-7.4.4.2$ 
cat ./instdir/share/fonts/truetype/fc_local.conf





  Symbol
  
OpenSymbol
  

  


  KDE

mode="append">rgb

  


it still fails. Probably it ignores it since it's already set in /etc 
and that already matches?


Regards,


Rene

Bug#1029083: mrcal FTBFS with nocheck profile: ModuleNotFoundError: No module named 'numpy'

[Dima Kogan]

Thanks for checking, Helmut. After talking to you on the mailing list I
had already solved the problem, but haven't made an upload yet. Doing
that right now. Thanks.

https://lists.debian.org/debian-cross/2023/01/msg1.html

Bug#1029063: reportbug: linux-image-6.0.0-6-amd64 remains unconfigured because of errors

[Diederik de Haas]

On Tuesday, 17 January 2023 18:12:30 CET Andreas Beckmann wrote:
> On Tue, 17 Jan 2023 10:56:33 +0100 Bastian Blank  wrote:
> > > Error! Bad return status for module build on kernel: 6.0.0-6-amd64
> > > (x86_64)
> > > Consult /var/lib/dkms/anbox-binder/1/build/make.log for more
> > > information.
> 
> That does not look like a module packaged in Debian ...

These kind of issues get regularly filed against the Debian kernel and it does 
not matter whether the dkms module is packaged in Debian or not. If the dkms 
module is packaged in Debian, we assign it to the specific dkms package.

> > dkms fails the installation if anything it tries to build does not work.
> > This must go, reassigning accordingly.
> 
> What should dkms do instead? Out-of-tree modules break frequently on new
> kernel upstream major versions, that is completely out of dkms' control.
> 
> There are two points in time where these errors could show up:
> * ) at package installation/upgrade time because building the module
>  failed (there is a small chance of the build succeeding ater reboot
>  if a badly packaged module only supports building against the
>  running kernel)
> * ) at reboot due to a missing kernel module
> 
> A failing module could build be 'harmless' if it's e.g. just the
> soundcard driver missing (unless you depend on text-to-speech) but in
> the worst case it's the root file system that is not supported...

It seems fine to print (in all caps afaic) that there is an issue.

But it should not cause the kernel package install/upgrade to fail.
And that does seem in dkms' control afaict.

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

Bug#1029103: coreutils: csplit: -z misdocumented

[наб]

Package: coreutils
Version: 9.1-1
Severity: normal

Dear Maintainer,

Quoth csplit(1):
-- >8 --
   -z, --elide-empty-files
  remove empty output files
-- >8 --

So given:
-- >8 --
$ (cd nz; printf '%s\n' q w e r t | csplit - 1 4)
0
6
4
$ find nz
nz
nz/xx02
nz/xx01
nz/xx00
$ head nz/*
==> nz/xx00 <==

==> nz/xx01 <==
q
w
e

==> nz/xx02 <==
r
t
-- >8 --

What do you expect the equivalent with -z to be?
Naturally, the manual says "remove", so I'd expect xx01 and xx02
to remain unchanged, but xx00 to be gone.

Let's see:
-- >8 --
$ (cd z; printf '%s\n' q w e r t | csplit -z - 1 4)
6
4
$ find z
z
z/xx01
z/xx00
$ head z/*
==> z/xx00 <==
q
w
e

==> z/xx01 <==
r
t
-- >8 --

Hm. Smells to me like the empty sexions are just ignored entirely
not removed afterward.

наб

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 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 coreutils depends on:
ii  libacl1  2.3.1-2
ii  libattr1 1:2.5.1-3
ii  libc62.36-7
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b4

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 pending

These are indeed implementation-private modules, adding them does not
requires the use of private headers. The fix has been implemented in
commit 5e44bf5ab207edfbe481090e75478a750271a548. I'll be pushing the
package ASAP.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1029101: Acknowledgement (fontconfig-config: 2.14.1 upload breaks testSimpleText of libreoffice)

[Rene Engelhard]

Hi,

addendum:

I tried to adapt the test to expected values but failed. When I adapt 
some values stuff even further breaks, and at the 50% test I then had no 
idea what to do.)


For reference,  this is the test:

https://cgit.freedesktop.org/libreoffice/core/tree/vcl/qa/cppunit/text.cxx?h=libreoffice-7.4.4.2#n164 
ff.



Regards,


Rene

Bug#1028201: [Debian-on-mobile-maintainers] Bug#1028201: riseup-vpn unable to find a usable polkit agent under phosh

[Evangelos Ribeiro Tzaras]

Hi,

On Sun, 2023-01-08 at 18:54 +0530, Pirate Praveen via Debian-on-mobile-
maintainers wrote:
> Package: riseup-vpn,phosh
> severity: grave
> 
> On mobian under phosh (librem 5), riseup-vpn gives error.
> output of riseup-vpn attached.
> 
> phosh provides polkit-1-auth-agent
> 
> phosh 0.23
> riseup-vpn 0.21.11+ds1-2+b1

I've tried to reproduce this by running 
$ pkexec echo bla

On both my Pinephone running Mobian, as well as on my Librem 5 running PureOS
the polkit authentication dialog is presented.

If you send a SIGUSR1 to phosh you can enable debug logging.
You should find something like the following in your journal:

Jan 17 18:10:04 hades phosh[1264]: New prompt for Authentication is needed to
run `/usr/bin/echo' as the super user
Jan 17 18:10:04 hades phosh[1264]: Adding PHOSH_STATE_MODAL_SYSTEM_PROMPT to
shells state. New state: PHOSH_STATE_MODAL_SYSTEM_PROMPT

While I've not tried it with riseup this test should already indicate whether
polkit authentication itself is working in phosh itself.


-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#1028034: Fwd: Re: pipewire | Multi-profile bluetooth headphones show only a2dp profile (#2936)

[Dylan Aïssi]

Hello,

Le ven. 6 janv. 2023 à 21:48, Dylan Aïssi  a écrit :
>
> Le ven. 6 janv. 2023 à 19:57, Bob Hauck  a écrit :
> >
> > There was apparently a bug already filed and closed about this. Subsequent 
> > to my report I received the following note that there is a commit to master 
> > that fixes the issue.
> >> Distro maintainers including the Debian one were notified on December 27th 
> >> that they should consider applying the commit c7b3ef0d but it was during 
> >> the holiday season and only a maybe, so I'm not sure if that fix was 
> >> deployed to Debian or not.
> >
>
> I just uploaded a new package version with this upstream fix.
> 0.3.63-2 should be available soon in debian/unstable.
>

Debian/testing provides pipewire 0.3.63-4 that contains the upstream fix.
Can you confirm that your issue is fixed?

Thanks,
Dylan

Bug#1029102: Aborted (segmentation fault) when starting ssr

[Enrico Zini]

Package: soundscaperenderer
Version: 0.5.0~dfsg-6
Severity: important

Hello,

thank you for packaging soundscaperenderer!

I installed the package and tried to run it, but immediately got a
segfault:

  $ ssr
  Cannot connect to server socket err = Connection refused
  Cannot connect to server request channel
  jackdmp 1.9.21
  Copyright 2001-2005 Paul Davis and others.
  Copyright 2004-2016 Grame.
  Copyright 2016-2022 Filipe Coelho.
  jackdmp comes with ABSOLUTELY NO WARRANTY
  This is free software, and you are welcome to redistribute it
  under certain conditions; see the file COPYING for details
  Cannot create RT messagebuffer thread: Operation not permitted (1)
  Retrying messagebuffer thread without RT scheduling
  Messagebuffer not realtime; consider enabling RT scheduling for user
  no message buffer overruns
  Cannot create RT messagebuffer thread: Operation not permitted (1)
  Retrying messagebuffer thread without RT scheduling
  Messagebuffer not realtime; consider enabling RT scheduling for user
  no message buffer overruns
  Cannot create RT messagebuffer thread: Operation not permitted (1)
  Retrying messagebuffer thread without RT scheduling
  Messagebuffer not realtime; consider enabling RT scheduling for user
  no message buffer overruns
  JACK server starting in realtime mode with priority 10
  self-connect-mode is "Don't restrict self connect requests"
  audio_reservation_init
  Acquire audio card Audio0
  creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
  configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
  ALSA: final selected sample format for capture: 32bit integer little-endian
  ALSA: use 2 periods for capture
  ALSA: final selected sample format for playback: 32bit integer little-endian
  ALSA: use 2 periods for playback
  Cannot use real-time scheduling (RR/10) (1: Operation not permitted)
  AcquireSelfRealTime error
  terminate called after throwing an instance of 'std::runtime_error'
what():  Can't set scheduling priority for thread!
  /usr/bin/ssr: line 52: 1189382 Aborted (core dumped) 
$SSR_EXECUTABLE "${OPTIONS[@]}"
  Unknown error...
  terminate called after throwing an instance of 'Jack::JackTemporaryException'
what():  


Enrico

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

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

Versions of packages soundscaperenderer depends on:
ii  jackd 5+nmu1
ii  libc6 2.36-8
ii  libecasoundc1v5   2.9.3-4+b1
ii  libfftw3-single3  3.3.10-1
ii  libgcc-s1 12.2.0-13
ii  libgl11.6.0-1
ii  libglu1-mesa [libglu1]9.0.2-1.1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-1
ii  libqt5core5a  5.15.7+dfsg-2
ii  libqt5gui55.15.7+dfsg-2
ii  libqt5opengl5 5.15.7+dfsg-2
ii  libqt5widgets55.15.7+dfsg-2
ii  libsndfile1   1.2.0-1
ii  libstdc++612.2.0-13
ii  libxml2   2.9.14+dfsg-1.1+b2
ii  soundscaperenderer-common 0.5.0~dfsg-6

Versions of packages soundscaperenderer recommends:
ii  ecasound  2.9.3-4+b1

soundscaperenderer suggests no packages.

-- no debconf information

Bug#1013222: Private headers

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Tue, 17 Jan 2023 at 14:15, Rodney Dawes  wrote:
>
> On Tue, 2023-01-17 at 13:43 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > Yes, but still not using Qt 6, so no need on our side to create more
> > work for us while not yet there. It would be much much easier if they
> > just used _stable_ API. And that's where we get back to upstream,
> > plugins, etc. Create _stable_ API and everything goes smooth.
>
> Chicken, meet egg.

Yes :-)

> It would be much easier if Qt didn't require using private API to do
> anything useful at this level. But here we are.

Exactly.

> Of course maliit isn't using Qt6 *yet* because in trying to do so, I
> came across this issue already reported in Debian, which I use as my
> main platform, and which has never presented such problem when
> developing these projects before. Had the necessary private development
> files already been available, we wouldn't even be having this
> discussion, and I would already have maliit-framework building on Qt6
> (not least because I'm pretty sure I already did have it building as a
> quick experiment, but when revisiting this yesterday, discovered the
> private portion of qt6-wayland had been removed).


I can offer you two solutions:

1. Come aboard maintaining Qt 6. Once you get a pair of Qt upgrades
and you want to support private headers for the whole of the Qt 6
lifetime, you are welcome to add them and support them.
2. Break the chicken and egg issue by building your own Qt. You can
use the debian packages as a base.

Cheers, Lisandro.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1029101: fontconfig-config: 2.14.1 upload breaks testSimpleText of libreoffice

[Rene Engelhard]

Package: fontconfig-config
Version: 2.14.1-3
Severity: serious
Justification: causes FTBFS
Tags: patch

Dear Maintainer,

See
https://buildd.debian.org/status/fetch.php?pkg=libreoffice=amd64=1%3A7.4.4-1=1673962775=0:

[_RUN_] VclTextTest::testSimpleText
./vcl/qa/cppunit/text.cxx:222:VclTextTest::testSimpleText
double equality assertion failed
- Expected: 42
- Actual  : 37
- Delta   : 4

Indeed that also happens when I build it locally (unfortunately the C++
autopkgtests had to be disabled in libreoffice, otherwise they would
have catched it, too)

Downgrading to 2.13.1-4.5 "fixes" it.

Since other distributions already *do* ship 2.14.1 I looked what they
had and I came around

https://src.fedoraproject.org/rpms/fontconfig/c/25e368d9d2888159b5eb9acf3839821a4fe81c40?branch=rawhide

Indeed, when I added that ... into the already existing 
/etc/fonts/conf.d/10-sub-pixel-rgb.conf
the test passes.

Filing this as serious as it causes (autopkg)test failures. Which is bad
this late in the release cycle, especially for packages involved in
transitions like python3-defaults...

Regards,

Rene

Bug#1029100: libxpm: diff for NMU version 1:3.5.12-1.1

[Salvatore Bonaccorso]

Package: libxpm
Version: 1:3.5.12-1
Severity: normal
Tags: patch  pending
X-Debbugs-CC: po...@debian.org,jcris...@debian.org


Dear maintainer,

I've prepared an NMU for libxpm (versioned as 1:3.5.12-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -u libxpm-3.5.12/debian/changelog libxpm-3.5.12/debian/changelog
--- libxpm-3.5.12/debian/changelog
+++ libxpm-3.5.12/debian/changelog
@@ -1,3 +1,17 @@
+libxpm (1:3.5.12-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CVE-2022-46285: Infinite loop on unclosed comments
+  * Fix CVE-2022-44617: Runaway loop with width of 0 and enormous height
+  * configure: add --disable-open-zfile instead of requiring -DNO_ZPIPE
+  * Fix CVE-2022-4883: compression commands depend on  $PATH
+  * Prevent a double free in the error code path
+  * Use gzip -d instead of gunzip
+  * debian/rules: configure: Set explicitly runtime paths for {,un}compress
+and gzip.
+
+ -- Salvatore Bonaccorso   Mon, 16 Jan 2023 21:01:44 +0100
+
 libxpm (1:3.5.12-1) unstable; urgency=medium
 
   [ Andreas Boll ]
diff -u libxpm-3.5.12/debian/patches/series libxpm-3.5.12/debian/patches/series
--- libxpm-3.5.12/debian/patches/series
+++ libxpm-3.5.12/debian/patches/series
@@ -1 +1,6 @@
-# placeholder
+Fix-CVE-2022-46285-Infinite-loop-on-unclosed-comment.patch
+Fix-CVE-2022-44617-Runaway-loop-with-width-of-0-and-.patch
+configure-add-disable-open-zfile-instead-of-requirin.patch
+Fix-CVE-2022-4883-compression-commands-depend-on-PAT.patch
+Prevent-a-double-free-in-the-error-code-path.patch
+Use-gzip-d-instead-of-gunzip.patch
diff -u libxpm-3.5.12/debian/rules libxpm-3.5.12/debian/rules
--- libxpm-3.5.12/debian/rules
+++ libxpm-3.5.12/debian/rules
@@ -4,4 +4,7 @@
 	dh $@ --with quilt --builddirectory=build/
 
+override_dh_auto_configure:
+	dh_auto_configure -- XPM_PATH_COMPRESS=/usr/bin/compress XPM_PATH_UNCOMPRESS=/bin/uncompress XPM_PATH_GZIP=/bin/gzip
+
 override_dh_install:
 	dh_install --fail-missing -XlibXpm.la
only in patch2:
unchanged:
--- libxpm-3.5.12.orig/debian/patches/Fix-CVE-2022-44617-Runaway-loop-with-width-of-0-and-.patch
+++ libxpm-3.5.12/debian/patches/Fix-CVE-2022-44617-Runaway-loop-with-width-of-0-and-.patch
@@ -0,0 +1,150 @@
+From 198839ca64dc117b35339f38c83d483ab6b561b6 Mon Sep 17 00:00:00 2001
+From: Alan Coopersmith 
+Date: Sat, 7 Jan 2023 12:44:28 -0800
+Subject: Fix CVE-2022-44617: Runaway loop with width of 0  and enormous height
+
+When reading XPM images from a file with libXpm 3.5.14 or older, if a
+image has a width of 0 and a very large height, the ParsePixels() function
+will loop over the entire height calling getc() and ungetc() repeatedly,
+or in some circumstances, may loop seemingly forever, which may cause a
+denial of service to the calling program when given a small crafted XPM
+file to parse.
+
+Closes: #2
+
+Reported-by: Martin Ettl 
+Signed-off-by: Alan Coopersmith 
+---
+ src/data.c  | 20 ++--
+ src/parse.c | 31 +++
+ 2 files changed, 41 insertions(+), 10 deletions(-)
+
+diff --git a/src/data.c b/src/data.c
+index bfad4ff..7524e65 100644
+--- a/src/data.c
 b/src/data.c
+@@ -195,19 +195,23 @@ xpmNextString(xpmData *data)
+ 	register char c;
+ 
+ 	/* get to the end of the current string */
+-	if (data->Eos)
+-	while ((c = *data->cptr++) && c != data->Eos);
++	if (data->Eos) {
++	while ((c = *data->cptr++) && c != data->Eos && c != '\0');
++
++	if (c == '\0')
++		return XpmFileInvalid;
++	}
+ 
+ 	/*
+ 	 * then get to the beginning of the next string looking for possible
+ 	 * comment
+ 	 */
+ 	if (data->Bos) {
+-	while ((c = *data->cptr++) && c != data->Bos)
++	while ((c = *data->cptr++) && c != data->Bos && c != '\0')
+ 		if (data->Bcmt && c == data->Bcmt[0])
+ 		ParseComment(data);
+ 	} else if (data->Bcmt) {	/* XPM2 natural */
+-	while ((c = *data->cptr++) == data->Bcmt[0])
++	while (((c = *data->cptr++) == data->Bcmt[0]) && c != '\0')
+ 		ParseComment(data);
+ 	data->cptr--;
+ 	}
+@@ -216,9 +220,13 @@ xpmNextString(xpmData *data)
+ 	FILE *file = data->stream.file;
+ 
+ 	/* get to the end of the current string */
+-	if (data->Eos)
++	if (data->Eos) {
+ 	while ((c = Getc(data, file)) != data->Eos && c != EOF);
+ 
++	if (c == EOF)
++		return XpmFileInvalid;
++	}
++
+ 	/*
+ 	 * then get to the beginning of the next string looking for possible
+ 	 * comment
+@@ -234,7 +242,7 @@ xpmNextString(xpmData *data)
+ 	Ungetc(data, c, file);
+ 	}
+ }
+-return 0;
++return XpmSuccess;
+ }
+ 
+ 
+diff --git a/src/parse.c b/src/parse.c
+index 037fc66..64f51ba 100644
+--- a/src/parse.c
 b/src/parse.c
+@@ -427,6 +427,13 @@ ParsePixels(
+ {
+ unsigned int *iptr, *iptr2 = NULL; /* found by Egbert Eich */
+ unsigned int a, x, y;
++int ErrorStatus;
++
++if ((width == 0) && (height != 0))
++	return (XpmFileInvalid);
++
++if ((height == 0) && (width != 0))
++	return 

Bug#1013222: Private headers

[Rodney Dawes]

On Tue, 2023-01-17 at 13:43 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Yes, but still not using Qt 6, so no need on our side to create more
> work for us while not yet there. It would be much much easier if they
> just used _stable_ API. And that's where we get back to upstream,
> plugins, etc. Create _stable_ API and everything goes smooth.

Chicken, meet egg.

It would be much easier if Qt didn't require using private API to do
anything useful at this level. But here we are.

Of course maliit isn't using Qt6 *yet* because in trying to do so, I
came across this issue already reported in Debian, which I use as my
main platform, and which has never presented such problem when
developing these projects before. Had the necessary private development
files already been available, we wouldn't even be having this
discussion, and I would already have maliit-framework building on Qt6
(not least because I'm pretty sure I already did have it building as a
quick experiment, but when revisiting this yesterday, discovered the
private portion of qt6-wayland had been removed).

Bug#1029099: soundgrain does not start

[Enrico Zini]

Package: soundgrain
Version: 6.0.1-3
Severity: important

Hello,

Thank you for packaging soundgrain!

I ran `apt install soundgrain` then tried to start it:

$ soundgrain
Traceback (most recent call last):
  File "/usr/bin/soundgrain", line 60, in 
app = SoundGrainApp(redirect=False)
  File "/usr/bin/soundgrain", line 41, in __init__
self.frame = MainFrame(None, -1, pos=(0, 20), size=(sizex, sizey),
  File "/usr/share/soundgrain/Resources/MainFrame.py", line 220, in __init__
self.controls = ControlPanel(self, self.panel)
  File "/usr/share/soundgrain/Resources/ControlPanel.py", line 193, in __init__
rec1Box.Add(self.but_folder, 1, wx.ALIGN_CENTER_VERTICAL | wx.EXPAND | 
wx.RIGHT, 10)
wx._core.wxAssertionError: C++ assertion "CheckSizerFlags(!((flags) & 
(wxALIGN_RIGHT | wxALIGN_CENTRE_HORIZONTAL | wxALIGN_BOTTOM | 
wxALIGN_CENTRE_VERTICAL)))" failed at ./src/common/sizer.cpp(2288) in 
DoInsert(): wxALIGN_RIGHT | wxALIGN_CENTRE_HORIZONTAL | wxALIGN_BOTTOM | 
wxALIGN_CENTRE_VERTICAL will be ignored in this sizer: wxEXPAND overrides 
alignment flags in box sizers

DO NOT PANIC !!

If you're an end user running a program not developed by you, please ignore 
this message, it is harmless, and please try reporting the problem to the 
program developers.

You may also set WXSUPPRESS_SIZER_FLAGS_CHECK environment variable to suppress 
all such checks when running this program.

If you're the developer, simply remove this flag from your code to avoid 
getting this message. You can also call 
wxSizerFlags::DisableConsistencyChecks() to globally disable all such checks, 
but this is strongly not recommended.


Running it with WXSUPPRESS_SIZER_FLAGS_CHECK=1 makes it work, with a
number of Gtk warnings:

$ WXSUPPRESS_SIZER_FLAGS_CHECK=1 soundgrain
[...]
(soundgrain:1181640): Gtk-WARNING **: 18:07:40.898: for_size smaller than 
min-size (8 < 14) while measuring gadget (node check, owner GtkCheckButton)

(soundgrain:1181640): Gtk-WARNING **: 18:07:40.900: for_size smaller than 
min-size (8 < 14) while measuring gadget (node check, owner GtkCheckButton)

(soundgrain:1181640): Gtk-WARNING **: 18:07:41.603: for_size smaller than 
min-size (8 < 14) while measuring gadget (node check, owner GtkCheckButton)


Enrico


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

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

Versions of packages soundgrain depends on:
ii  python3   3.10.6-3+b1
ii  python3-markdown  3.4.1-2
ii  python3-pyo   1.0.4-1+b4
ii  python3-wxgtk4.0  4.2.0+dfsg-1+b3

soundgrain recommends no packages.

soundgrain suggests no packages.

-- no debconf information

Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate

[Lisandro Damián Nicanor Pérez Meyer]

Probably the "Private" name here is misleading: this might be a
private module but not directly related with public headers (ie, an
implementation detail).

Bug#1029063: reportbug: linux-image-6.0.0-6-amd64 remains unconfigured because of errors

[Andreas Beckmann]

On Tue, 17 Jan 2023 10:56:33 +0100 Bastian Blank  wrote:

> Error! Bad return status for module build on kernel: 6.0.0-6-amd64 (x86_64)
> Consult /var/lib/dkms/anbox-binder/1/build/make.log for more information.


That does not look like a module packaged in Debian ...


dkms fails the installation if anything it tries to build does not work.
This must go, reassigning accordingly.


What should dkms do instead? Out-of-tree modules break frequently on new 
kernel upstream major versions, that is completely out of dkms' control.


There are two points in time where these errors could show up:
* ) at package installation/upgrade time because building the module
failed (there is a small chance of the build succeeding ater reboot
if a badly packaged module only supports building against the
running kernel)
* ) at reboot due to a missing kernel module

A failing module could build be 'harmless' if it's e.g. just the 
soundcard driver missing (unless you depend on text-to-speech) but in 
the worst case it's the root file system that is not supported...



Andreas

Bug#1028904: pillow: Lost tiff support after binNMU with tiff 4.5.0

[Sebastiaan Couwenberg]

On Mon, 16 Jan 2023 16:43:23 +0100 Bastian Germann wrote:

I am uploading a NMU with the attached debdiff to DELAYED/10 to fix this.


You can reschedule this to 5 days.

From the NMU guidelines:

"
 * Upload fixing only release-critical and important bugs: 5 days
"

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#when-and-how-to-do-an-nmu 



Kind Regards,

Bas

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

Bug#1013222: Private headers

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 17 Jan 2023 at 13:41, Rodney Dawes  wrote:
>
> And to add to the point, currently the qt6-wayland package is broken in
> Debian, even just trying to find it via CMake, because some of these
> files have been removed. The following error is from simply checking
> for the WaylandClient Qt component via:
>
> find_package(Qt6 6.2 REQUIRED COMPONENTS Core WaylandClient)

Thanks! I just filed a bug for that. Public modules should not require
private headers, not the first time we see this kind of issues.

Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate

[Lisandro Damián Nicanor Pérez Meyer]

Source: qt6-wayland
Version: 6.4.2~rc1-2
Severity: normal
X-Debbugs-Cc: dobey.p...@gmail.com, lisan...@debian.org

With a CMakeLists.txt having:

find_package(Qt6 REQUIRED COMPONENTS WaylandClient)

Runnning CMake issues:

```
-- Could NOT find Qt6WaylandGlobalPrivate (missing: Qt6WaylandGlobalPrivate_DIR)
CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:167 
(find_package):
  Found package configuration file:


/usr/lib/x86_64-linux-gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake

  but it set Qt6WaylandClient_FOUND to FALSE so package "Qt6WaylandClient" is
  considered to be NOT FOUND.  Reason given by package:

  Qt6WaylandClient could not be found because dependency
  Qt6WaylandGlobalPrivate could not be found.

  Configuring with --debug-find-pkg=Qt6WaylandGlobalPrivate might reveal
  details why the package was not found.

  Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some
  of the path variables that find_package uses to try and find the package.

Call Stack (most recent call first):
  CMakeLists.txt:16 (find_package)
```

A public module should not require a private one, so either
WaylandClient has a CMake error or it is not really public.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.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

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Christoph Martin]

I have created a repository on salsa:

https://salsa.debian.org/python-team/packages/yq

I am not shure, what is the best way to create a python package.
Is there a template for python packages?

Am 16.01.23 um 12:14 schrieb Christoph Martin:




I had a try with the Go variant, because this is used in a project, that 
we use. But a lot of Go dependencies are missing in Debian.


So, I also vote for the python variant.

Who is interested in packaging it?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029080: Info received (Bug#1029080: linux-image-5.10.0-20-amd64: Boot failure "PM: Image not found (code -22)" where power management is NOT used)

[Claire Osborne]

Hi,

Sorry - can this be closed please.

I am going to diplomatically say that a network engineer suffered a failure 
between mouse and keyboard - who did not appreciate that /etc/fstab is an 
integral part of the system boot process.

My apologies if this has wasted anyone's time.

Kind regards

Claire

--
Claire Osborne (she/her)
Senior Systems Engineer
Information Technology | Canterbury Christ Church University
Anselm, North Holmes Road, Canterbury, Kent, CT1 1QU
Registered Company limited by guarantee (No: 4793659) | Registered Charity (No: 
1098136)

-Original Message-
From: Debian Bug Tracking System  
Sent: 17 January 2023 15:36
To: Claire Osborne 
Subject: Bug#1029080: Info received (Bug#1029080: linux-image-5.10.0-20-amd64: 
Boot failure "PM: Image not found (code -22)" where power management is NOT 
used)

CAUTION: This email originated from outside of CCCU. Do not click links or open 
attachments unless you recognise the sender and know the content is safe.


Thank you for the additional information you have supplied regarding this Bug 
report.

This is an automatically generated reply to let you know your message has been 
received.

Your message is being forwarded to the package maintainers and other interested 
parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Kernel Team 

If you wish to submit further information on this problem, please send it to 
1029...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish to report a 
problem with the Bug-tracking system.

--
1029080: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D1029080=05%7C01%7Cclaire.osborne%40canterbury.ac.uk%7C2cab687c48eb41d8985508daf8a0903b%7C0320b2da22dd4dab8c216e644ba14f13%7C0%7C0%7C638095665767562029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=agzC8xxxWkcoE5YnvSZ5B0DtXPRB0EdmmjjI85zD9no%3D=0
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1013222: Private headers

[Rodney Dawes]

And to add to the point, currently the qt6-wayland package is broken in
Debian, even just trying to find it via CMake, because some of these
files have been removed. The following error is from simply checking
for the WaylandClient Qt component via:

find_package(Qt6 6.2 REQUIRED COMPONENTS Core WaylandClient)


-- Could NOT find Qt6WaylandGlobalPrivate (missing:
Qt6WaylandGlobalPrivate_DIR)
CMake Warning at /usr/lib/x86_64-linux-
gnu/cmake/Qt6/Qt6Config.cmake:167 (find_package):
  Found package configuration file:

/usr/lib/x86_64-linux-
gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake

  but it set Qt6WaylandClient_FOUND to FALSE so package
"Qt6WaylandClient" is
  considered to be NOT FOUND.  Reason given by package:

  Qt6WaylandClient could not be found because dependency
  Qt6WaylandGlobalPrivate could not be found.

  Configuring with --debug-find-pkg=Qt6WaylandGlobalPrivate might
reveal
  details why the package was not found.

  Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of
some
  of the path variables that find_package uses to try and find the
package.

Call Stack (most recent call first):
  CMakeLists.txt:24 (find_package)


CMake Error at CMakeLists.txt:24 (find_package):
  Found package configuration file:

/usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake

  but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be
NOT
  FOUND.  Reason given by package:

  Failed to find required Qt component "WaylandClient".

  Expected Config file at
  "/usr/lib/x86_64-linux-
gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake"
  exists

  

  Configuring with --debug-find-pkg=Qt6WaylandClient might reveal
details why
  the package was not found.

  Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of
some
  of the path variables that find_package uses to try and find the
package.



-- Configuring incomplete, errors occurred!

Bug#1013222: Private headers

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Tue, 17 Jan 2023 at 13:32, Rodney Dawes  wrote:
>
> On Tue, 2023-01-17 at 13:03 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > Believe me I understand your frustration. But at the same time you
> > don't know the pain it takes to maintain Qt as private headers get
> > exposed.
>
> Actually, I do know. I work on Ubuntu Touch, where we maintained our
> own Qt packages on top of Ubuntu. I've also worked on Plasma Mobile on
> Manjaro, which ships the KDE patch collection on Qt5, which pulled in
> some backported changes from Qt6, which broke ABI in the private API
> side, causing much frustration. Being focused on mobile, there is also
> the OpenGL vs GLES build issues.

You do definitely know the landscape then :)

> > Key Plasma packages are normally an exception, and Telegram desktop is
> > definitely not a key plasma package. And again, yes, we would love to
> > provide **everything**. But I sincerely do not see that happening
> > until someone has proper Qt maintenance as his/her day job.
>
> If the situation of Qt/KDE in Debian is as bad as you say, can we not
> reach out to Kubuntu/Neon devs to help out with it? Or maybe the Debian
> UBports Team could help, given the heavy dependence on Qt which the
> Lomiri stack has?

The main Qt 5 maintainer is also Ubuntu's maintainer. From time to
time people from Ubuntu try to help us, with various degrees of
success, and here we are. Note that we do stress a lot what we think a
Debian package should be, and sometimes that clashes with other
distros expectations (and that's fine!).

> I wasn't implying that telegram-desktop is a key
> Plasma package, however, maliit-framework and maliit-keyboard are, I
> would think.

Yes, but still not using Qt 6, so no need on our side to create more
work for us while not yet there. It would be much much easier if they
just used _stable_ API. And that's where we get back to upstream,
plugins, etc. Create _stable_ API and everything goes smooth.

> > That being said the plan is to switch to Plasma with Qt 6 in Trixie
> > (aka Debian 13), so I guess that after the freeze is over adding
> > Qt-Wayland's private headers will be a must.
>
> But if nothing else in Debian would require these before the freeze,
> why would it need to wait, since nothing would break as a result?

No *key* package. As soon as we add private headers we gain non-key
packages trying to use them, and thus more man power at the time of
updating Qt.


> Especially, given how anything that would require them is already
> broken, so not having the private headers is already an issue (hence
> this bug report).

No, see above.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1029096: bat: please rename batcat to bat

[Andrea Pappacoda]

Package: bat
Version: 0.22.1-1+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, could you please consider renaming back the batcat binary to bat? This used
to be necessary because /usr/bin/bat was also used by the bareos-bat package,
but it has been removed[1] a while back and the /usr/bin/bat file has remained
free since the release of bullseye.

Since the batcat name might be already in use, I suggest installing a symlink
or a compatibility script in /usr/bin/batcat that redirects to /usr/bin/bat,
like this:

#!/bin/sh
>&2 printf 'Invoking bat as %s is deprecated, please use bat instead\n'
"$0"
exec bat "$@"

[1]: https://bugs.debian.org/1000906


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

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

Versions of packages bat depends on:
ii  libc62.36-8
ii  libgcc-s112.2.0-13
ii  libgit2-1.5  1.5.0+ds-6

bat recommends no packages.

bat suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCY8bQVhQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3pwYjAP0UqtlMyIsVzVioyglJh8MpNPwZV1mn
/gAoPV5u1oaheQEA5P5OpbPTCvidBbd/u5Uij+hGMkBeQdIrVugQFmX78Qc=
=IDdx
-END PGP SIGNATURE-

Bug#1029095: libselinux: claim /run/setrans directory

[Christian Göttsche]

Package: libselinux1
Version: 3.1-3
Severity: important
Tags: security

Libselinux by default, since Debian does not specify DISABLE_SETRANS
at compile time, tries to translate security contexts within non-raw
interfaces, e.g. getfilecon(3).  The purpose is to translate MCS/MLS
labels into human readable via mcstransd(8).  The translation happens
via communication over the public accessible UNIX socket
/var/run/setrans/.setrans-unix, created by mcstransd(8).  mcstransd(8)
however is not installed by default, not a dependency of another
package, nor recommended or suggested by one.  Thus mcstransd(8) is
probably not running on many (most?) SELinux enabled systems and
thereby the directory /var/run/setrans is not created.  This leaves
the opportunity for (compromised) programs to create it and the UNIX
socket to take control of the security context translation.  It might
not be prevented by the SELinux policy since most daemons are allowed
to create entries in /var/run and UNIX socket communication between
daemons is common.  As a solution the directory /var/run/setrans
should be created at boot by a trusted party with the default context
according to the loaded policy (e.g. setrans_runtime_t), which no
other daemon than mcstransd(8) should have the permission to create
sockets inside.  For example Fedora uses the tmpfiles.d(5) snippet:

d /run/setrans 0755 root root

, see 
https://src.fedoraproject.org/rpms/libselinux/c/8b8064a26e06c128e2c0374b9039038842f51557.

Bug#1029094: ITP: python-cgelib -- Python3 code to be utilized across the CGE tools

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-cgelib -- Python3 code to be utilized across the CGE tools
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-cgelib
  Version : 0.7.3
  Upstream Author : Frank Møller Aarestrup, Technical University of Denmark
* URL : https://bitbucket.org/genomicepidemiology/cgelib
* License : Apache-2.0
  Programming Lang: Python
  Description : Python3 code to be utilized across the CGE tools
 This package will in time replace the cgecore package. The package
 contains classes and functions intended to be utilized across the tools
 provide by the Center for Genomic Epidemiology. It is for instance
 needed by resfinder package.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-cgelib

Bug#1029089: mandoc: -Thtml renders .Em as a hyperlink

[Michael Stapelberg]

Can you report this upstream at https://mandoc.bsd.lv/contact.html please?

On Tue, 17 Jan 2023 at 16:18, Colin Watson  wrote:

> Package: mandoc
> Version: 1.14.6-1+b1
> Severity: normal
>
> I was in the process of referring a user to
> https://manpages.debian.org/bullseye/germinate/germinate.1.en.html, and
> I happened to notice that some things are rendered oddly.  This input:
>
>   The contents of the Ubuntu distribution, and others, are managed by
> means of
>   .Em seeds .
>
> ... is rendered as follows by "mandoc -Thtml":
>
>   The contents of the Ubuntu distribution, and others, are
> managed
>   by means of
>id="seeds">seeds.
>
> Perhaps there's some reason for this, but it looks odd - the effect is a
> hyperlink to the same place in the document - and it seems to deviate
> from the documented semantics of .Em.  mdoc(7) says:
>
>  Em word ...
>   Request an italic font.  If the output device does not provide
> that,
>   underline.
>
>   This is most often used for stress emphasis (not to be confused
> with
>   importance, see Sy).  In the rare cases where none of the
> semantic
>   markup macros fit, it can also be used for technical terms and
>   placeholders, except that for syntax elements, Sy and Ar are
>   preferred, respectively.
>
>   Examples:
> Selected lines are those
> .Em not
> matching any of the specified patterns.
> Some of the functions use a
> .Em hold space
> to save the pattern space for subsequent retrieval.
>
>   See also No, Ql, and Sy.
>
> ... while groff_mdoc(7) says:
>
>Emphasis Macro
>  Text may be stressed or emphasized with the ‘.Em’ macro.  The usual
> font
>  for emphasis is italic.
>
>Usage: .Em ⟨argument⟩ ...
>
> .Em does not  does not
> .Em exceed 1024 . exceed 1024.
> .Em vide infra ) ) ,  vide infra)),
>
>  The default width is 10n.
>
> Maybe this is just an accidental consequence of something else and can
> be fixed; I don't see a reason why we need more than italic-font
> emphasis here.  But if it's deliberate, please could there at least be a
> portable way to suppress the spurious hyperlinks?
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.19.0-26-generic (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND,
> TAINT_OOT_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
> Versions of packages mandoc depends on:
> ii  libc6   2.36-8
> ii  zlib1g  1:1.2.13.dfsg-1
>
> mandoc recommends no packages.
>
> mandoc suggests no packages.
>
> -- no debconf information
>
> Thanks,
>
> --
> Colin Watson   [cjwat...@debian.org]
>


-- 
Best regards,
Michael

Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Xchroot 2.7.4 has also come with many new features. Dbus session 
creation and /dev/shm mounting satisfy the need even of exigent GUI 
programs like the Otter browser. It has a /media and subdirectory 
automounter which is especially useful for mirroring mounts of removable 
media. It is even possible to run a whole desktop session like KDE, 
Gnome or Xfce in an xchroot container. Desktop link creation for the GUI 
menu is included. The program has evolved much since Debian fellows have 
initially persuaded me to make the program open source. That time there 
was interest in the development of xchroot regarding Debian.

Bug#1013222: Private headers

[Rodney Dawes]

On Tue, 2023-01-17 at 13:03 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Believe me I understand your frustration. But at the same time you
> don't know the pain it takes to maintain Qt as private headers get
> exposed.

Actually, I do know. I work on Ubuntu Touch, where we maintained our
own Qt packages on top of Ubuntu. I've also worked on Plasma Mobile on
Manjaro, which ships the KDE patch collection on Qt5, which pulled in
some backported changes from Qt6, which broke ABI in the private API
side, causing much frustration. Being focused on mobile, there is also
the OpenGL vs GLES build issues.

> Key Plasma packages are normally an exception, and Telegram desktop is
> definitely not a key plasma package. And again, yes, we would love to
> provide **everything**. But I sincerely do not see that happening
> until someone has proper Qt maintenance as his/her day job.

If the situation of Qt/KDE in Debian is as bad as you say, can we not
reach out to Kubuntu/Neon devs to help out with it? Or maybe the Debian
UBports Team could help, given the heavy dependence on Qt which the
Lomiri stack has? I wasn't implying that telegram-desktop is a key
Plasma package, however, maliit-framework and maliit-keyboard are, I
would think.

> That being said the plan is to switch to Plasma with Qt 6 in Trixie
> (aka Debian 13), so I guess that after the freeze is over adding
> Qt-Wayland's private headers will be a must.

But if nothing else in Debian would require these before the freeze,
why would it need to wait, since nothing would break as a result?
Especially, given how anything that would require them is already
broken, so not having the private headers is already an issue (hence
this bug report).

Bug#1028201: riseup-vpn unable to find a usable polkit agent under phosh

[Praveen Arimbrathodiyil]

Control: severity -1 important

On 17/01/23 2:30 pm, Guido Günther wrote:

Hi,

On Sun, Jan 08, 2023 at 06:54:17PM +0530, Pirate Praveen wrote:

Package: riseup-vpn,phosh
severity: grave

On mobian under phosh (librem 5), riseup-vpn gives error.
output of riseup-vpn attached.


I don't think the severity is justified for phosh as it's certianly not
unusable or mostly so. I tihnk the same is true for riseup-net.


ok reduced severity to important


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028964: noweb: Want to use documentclass scrbook instead of book

[Hubert Chathi]

On Mon, 16 Jan 2023 19:54:57 +0100, Mechtilde Stehmann  
said:

> Hello Hubert, then I will prepare it for an upload.  What is your
> preferred way?  Should I do it as anew revision and register my name
> into debian/control?  Or should I do it as NMU?

Since src/tex/noweb.sty is a generated file, you should also add your
changes to src/tex/support.nw.

If you are interested in co-maintaining noweb, feel free to add yourself
as an uploader to debian/control.  I do not use noweb any more, so help
maintaining it from someone else interested is welcome.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#1029093: solaar doesn't enable plugdev when plugdev requested

[Mason Loring Bliss]

Package: solaar
Version: 1.1.8+dfsg-1

My previous bug, BZ#1028922, was closed inappropriately, given that the
bug is not fixed in Bookworm, and will impact Bullseye users until Bullseye
leaves support.

Solaar notes this on configuration:

> Please specify how non-root users should be given access to the Logitech
> receiver devices.
>
> If systemd or consolekit are in use, they can apply ACLs to make them
> accessible via Solaar for the user logged in on the current seat. Right
> now, NEITHER daemon is running.
>
> If neither of these daemons is in use, or if the receiver should also be
> accessible for remotely logged in users, it is possible to grant access
> for members of the "plugdev" system group.
>
> If you do use the "plugdev" group, don't forget to make sure all the
> appropriate users are members of that group. You can add new members to
> the group by running, as root:
>adduser  plugdev
> For the group membership to take effect, the affected users need to log
> out and back in again.
>
> Use plugdev group?
>
>   

However, even if "yes" is selected, the line that includes plugdev is
commented out in the udev rules file shipped with the package,
/lib/udev/rules.d/60-solaar.rules:

# Grant members of the "plugdev" group access to receiver (useful for SSH users)
#MODE="0660", GROUP="plugdev"

...which results in plugdev not being set as the group for matching
devices, instead leaving them with the default 0600 root:root, which
plugdev users cannot access. If this line is manually uncommented Solaar
works as intended with plugdev users.

The easiest fix might be to simply be to note this in the configuration
dialog, as it'd be reasonable for users wanting this to work with plugdev
to understand that an additional manual step is required.

Observed on Debian Bookworm with Solaar 1.1.8+dfsg-1.
Observed on Debian Bullseye with Solaar 1.0.4+dfsg-1.

-- 
Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft!
(if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I


signature.asc
Description: PGP signature

Bug#1013222: Private headers

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 17 Jan 2023 at 01:38, Rodney Dawes  wrote:
>
> On Mon, 2023-01-16 at 23:35 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > Maintaining Qt already takes a lot of time, adding private headers
> > only makes things worse. So if you want to do porting and the headers
> > are not yet there you will have to build Qt itself or fix the problem
> > where it really belongs: upstream.
>
> Upstream? Where it's not a problem, because they ship and install the
> private headers?

Private headers are non stable API, and that's a problem.

> No, this is an issue in Debian, because the headers are being
> specifically excluded from packaging, rather than installed. Other
> distributions provide these files without such politics. Why is it so
> hard to maintain in Debian?

The way Debian works (transitions) and man power. It is not politics,
it's man power.

> Fedora, OpenSUSE, Arch, etc… all have these
> files available for installation and developing against. So, surely the
> "maintenance burden" is not so high, right? Debian has britney to run
> autopackage tests, specifically to prevent things breaking, no? Those
> things still are going to break, when those files aren't provided,
> since they can no longer build, no?

That's actually the point: the maintenance burden **IS** high. Yes,
even with britney testing stuff, we still need to manually
build/trigger builds for all affected packages (all that use private
headers), file bugs, cross fingers that maintainers will fix them or
provide fix ourselves. Else we can't ask for a transition slot.

Qt is currently (and has been mostly during all these years)
maintained by one or two people. Currently Qt5 is maintained by Dmitry
and Qt 6 by Patrick, and some people helping whenever possible (like
me, nowadays). It's a huge task, one that would be better served by
someone dedicated to it, which is not our case.

So yes: man power IS an issue, and private headers only adds more man
power requirements.

Believe me I understand your frustration. But at the same time you
don't know the pain it takes to maintain Qt as private headers get
exposed.

> There is nothing speculative here. The files are required to build many
> things against Qt, regardless of whether it is version 5 or 6.
>
> Leaving the files out, only makes it harder for anyone to rely on
> distribution provided packages. These are necessary for shipping KDE
> Plasma 6, and many other things, in Debian.

Key Plasma packages are normally an exception, and Telegram desktop is
definitely not a key plasma package. And again, yes, we would love to
provide **everything**. But I sincerely do not see that happening
until someone has proper Qt maintenance as his/her day job.

That being said the plan is to switch to Plasma with Qt 6 in Trixie
(aka Debian 13), so I guess that after the freeze is over adding
Qt-Wayland's private headers will be a must.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1029092: Don't update mysql-defaults in Debian testing/Bookworm too early

[Otto Kekäläinen]

Package: mysql-defaults
Version: 1.1.0
Severity: serious
Owner: Otto Kekäläinen 

Don't allow mysql-defaults into testing/Bookworm before MariaDB
1:10.11.1-1 has entered it first. There is no package
'mariadb-server-core' in MariaDB 1:10.6.11-2 and thus the defaults
pointer would fail.

This severity 'serious' bug should prevent the migration
automatically. Close this bug when migration is free to proceed.

Bug#790883: Possible workaround

[Marcin Owsiany]

The command from the original report fails for me with openssl 3.0.7 with
>>bad decrypt<< even with the newline.

I came up with a slightly different set of commands that reproduce this
behaviour, and which also includes -pbkdf2 that now seems to be required to
avoid a warning.

porridge@fujitsu:~$ echo peekaboo | openssl enc -aes-256-cbc -pbkdf2 -pass
pass:bar  -base64
U2FsdGVkX190F0Gf0mikyIDlIh9oDADRLtCA0wSMEHg=
porridge@fujitsu:~$ echo -n U2FsdGVkX190F0Gf0mikyIDlIh9oDADRLtCA0wSMEHg= |
openssl enc -aes-256-cbc -pbkdf2 -pass pass:bar -d -base64
error reading input file

I also learned about the -A flag which seems to make openssl work in this
case:

porridge@fujitsu:~$ echo -n U2FsdGVkX190F0Gf0mikyIDlIh9oDADRLtCA0wSMEHg= |
openssl enc -aes-256-cbc -A -pbkdf2 -pass pass:bar -d -base64
peekaboo

However even in the manpage it is mentioned to be buggy:

   The -A option when used with large files doesn't work properly.

I also found an upstream issue about base64 handling which seems to be
closely related to this bug report:
https://github.com/openssl/openssl/issues/18780
Jean-Michel, if you consider this a good enough workaround for your use
case, please consider closing this bug.

Marcin

Bug#1026200: Please package LilyPond 2.24.0 if possible

[Anthony Fok]

On Sat, Jan 14, 2023 at 2:36 PM Jonas Hahnfeld  wrote:
>
> On Wed, 2022-12-28 at 22:16 +0100, Jonas Hahnfeld wrote:
> > On Fri, 16 Dec 2022 15:27:32 +1100 John Zaitseff
> >  wrote:
> > > Package: lilypond
> > > Severity: wishlist
> > >
> > > I know it's a lot to ask for :-), but now that LilyPond 2.24.0 has
> > > been released, it would be good to have it in Debian.  Let me know
> > > if I can help bring this about!
> >
> > Yes, please  actually, aligning our release of LilyPond 2.24.0 with
> > Debian's freeze plans was very intentional:
> > https://lists.gnu.org/archive/html/lilypond-devel/2022-05/msg00099.html
> >
> > That said, I just realized that guile-2.2-libs has been *removed* as
> > part of #1023560 while it is the preferred version of Guile for this
> > release of LilyPond. What are the chances of getting this back into the
> > repos?
>
> Ping, also CC'ing Rob Browning for Guile.

Hello Jonas (and Rob) and all,

Thank you so much for the bug report and reminders, which are much
needed and appreciated!  I had been away from my Debian duties and
missed the initial report, but finally saw he January 12th message
from Jean Abou Samra who added:

> The Guile version makes a difference to the Scheme code you can write,
> so compatibility issues are not hypothetical. Furthermore, I think
> Guile 2.2 would still have value independently from LilyPond:
> right now, compiling Guile 3.0 for Windows requires lots of patches
> to be found in work-in-progress experimental branches, so
> if you want to write portable software, you more or less need
> to use Guile 2.2.

Thank you so much for Cc'ing Rob regarding Guile-2.2.

Rob, as you can see, there is a real need for Guile 2.2 for LilyPond
2.24.0 (December 2022), this coming from LilyPond's Core Developer
Jonas Hahnfeld and "Factotum" and Jean Abou Samra.  If it is OK with
you, Rob, I would be more than happy to adopt guile-2.2 and maintain
it for the entire lifetime of Debian 12 (bookworm), and hopefully by
Debian 13 (trixie), LilyPond will be ready for guile-3.0.  :-)\
Many thanks for your understanding!

Warm regards,

Anthony

Bug#1029091: RFS: boxbackup/0.13~~git20221201.g166b3fa-1 -- client for the BoxBackup remote backup system

[Ileana Dumitrescu]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "boxbackup":

 * Package name : boxbackup
   Version  : 0.13~~git20221201.g166b3fa-1
   Upstream contact : Ben Summers 
 * URL  : http://boxbackup.org
 * License  : GPL-2+, BSD-3-Clause or GPL-2+, BSD-4-Clause, 
GPL-3, ISC or BSD-4-Clause, BSD-3-Clause, ISC, Expat

 * Vcs  : https://salsa.debian.org/debian/boxbackup
   Section  : utils

The source builds the following binary packages:

  boxbackup-server - server for the BoxBackup remote backup system
  boxbackup-client - client for the BoxBackup remote backup system

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


  https://mentors.debian.net/package/boxbackup/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/boxbackup/boxbackup_0.13~~git20221201.g166b3fa-1.dsc


Changes since the last upload:

 boxbackup (0.13~~git20221201.g166b3fa-1) unstable; urgency=medium
 .
   * New upstream version 0.13~~git20221201.g166b3fa
   * debian/control: bump Standards-Version to 4.6.2 (no changes)
   * debian/copyright: update debian copyright year to 2023
   add common-licenses paths
   * debian/patches: refresh existing patches
 add correct-apos-in-manpages.diff to allow correct
 apostrophe format in manpages
 add description header to openssl_provider.diff
   * debian/source/lintian-overrides: add to remove false positive warnings
   * debian/watch: remove gpgmode=none
   update to version 4

Regards,
--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature