Bug#1030346: elpa-transient: FTBFS with TeXInfo 7.0.x

[Hilmar Preusse]

Source: elpa-transient
Version: 0.3.7-1
Severity: important
Tags: ftbfs
Usertags: texinfo70

Dear Maintainer,

the package fails to build from source when using TeX Info 7.0.x. This
happens due to this change:

,
| 7.0 (7 November 2022)
| * texi2any
|  . HTML output:
|  . use manual_name_html as output directory for split HTML instead of
|manual_name or manual_name.html
`

The easiest solution is probably to collect the docs from the new
location, specified in d/elpa-transient-doc.docs, but that needs to be
verified.

For now TeXInfo 7.0 is available in experimental. This bug is not RC
for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and
the bug will become RC.

Hilmar

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

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

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1030332: libcamera0.0.3:amd64: crashes wireplumber/pipewire sometimes when camera appears

[Dylan Aïssi]

Hello,

Le ven. 3 févr. 2023 à 01:27, Tomas Janousek  a écrit :
>
> When a USB camera appears (usbguard allow-device …, or just
> echo 1 >/sys/…/authorized), the pipewire and/or wireplumber processes 
> sometimes segfault in libcamera. Not always, but doing usbguard block-device 
> followed by usbguard allow-device a couple times makes them crash eventually. 
> I can reproduce this with the integrated camera on two different ThinkPads 
> made a couple years apart, the T25 and P14s Gen2i.
>

What versions of pipewire and wireplumber do you use?

Can you try to reproduce with libcamera 0.0.4 in experimental? But because of
a soname change, you would need to rebuild pipewire against the new libcamera.

Best,
Dylan

Bug#1030345: DAEMON_ARGS in /etc/init.d/salt-minion prevents salt-minion startup

[Samuli Airaksinen]

Package: salt-minion
Version: 2018.3.4+dfsg1-6+deb10u2

In /etc/init.d/salt-minion , the line

DAEMON_ARGS="-d"

causes the minion to freeze upon startup. The -d switch, which runs the 
minion in the background, is ok when /usr/bin/salt-minion is ran 
interactively, but causes the minion to freeze when launched via service.


The switch is also warned against at 
https://ansible-cn.readthedocs.io/en/latest/topics/troubleshooting/minion.html 
. In Debian Buster the salt-minion service is also launched without the 
-d argument.


There is no error message. The last log message in log_levels "trace" 
and "garbage" is: "Getting lsb_release distro information", after which 
the minion remains unresponsive.


Emptying the DAEMON_ARGS fixes the problem and enables salt-minion to 
start properly.



Proposed patch:

@@ -15,7 +15,7 @@
 DESC="salt minion control daemon"
 NAME=salt-minion
 DAEMON=/usr/bin/salt-minion
-DAEMON_ARGS="-d"
+DAEMON_ARGS=""
 PIDFILE=/var/run/$NAME.pid
 SCRIPTNAME=/etc/init.d/$NAME
Forwarded from https://bugs.devuan.org/543

Bug#1030344: filename on command line gets mangled

[Zefram]

Package: nodejs
Version: 12.22.12~dfsg-1~deb11u3
Severity: normal

The node(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it understands filenames:

$ echo 'process.stdout.write("sadness\n");' > $'L\xef\xbf\xbdon.js'
$ echo 'process.stdout.write("joy\n");' > $'L\xe9on.js'
$ node $'L\xe9on.js'
sadness
$

In this example I've created two different script files, with different
but related names, I've told node(1) to run one of them, and it's run
the wrong one.  One can see via strace(1) that node(1) doesn't use the
correct filename for any file operations at all; it completely substitutes
the erroneous filename.  The use of the wrong filename doesn't depend on
the file of that wrong name existing: if there is no file of that name
then node(1) will fail to find any script to execute, and will generate
an error message that shows the erroneous filename.

This bug occurs whenever the supplied filename doesn't have the syntax of
UTF-8 encoding of text, containing only Unicode codepoints of which node
approves.  The nature of the manglement is that each octet that doesn't
look like valid UTF-8 gets replaced with the three octets $'\xef\xbf\xbd',
which is the UTF-8 encoding of U+fffd "replacement character".  It appears
that the supplied filename is being UTF-8 decoded, with decoding
errors muffled and the replacement character silently substituted in,
and then the lossily-decoded filename is re-encoded in correct UTF-8,
and the result of that process is the filename that gets actually used.
As far as I can see the manglement comes only from UTF-8 decoding:
there isn't also any Unicode normalisation.

This could cause a security problem in some circumstances that are only
slightly strange.  Suppose a privileged program is using node(1) to run
scripts that partly derive from untrusted user input.  Suppose the program
has created an innocuous script to run, has permitted an untrusted user
to determine part of the filename for that script, and has ensured that
the supplied filename is innocuous from a Unix point of view but isn't
preventing the use of filenames with high-half octets.  Suppose further
that an untrusted user can cause the same program to create another file,
of content that the program doesn't intend to execute, under the mangled
name, which is equally innocuous from a Unix point of view.  Then it
could execute code determined by a malicious user, due entirely to node(1)
misinterpreting a filename.  I'm not aware of any specific program that
can be exploited in this way, and I haven't based the declared severity
of this bug report on this security issue.

Preferably, node(1) should use the script file of the name that was
supplied on the command line.  It must pass to the file syscalls the
same octet string that was supplied as a command line argument, without
assuming anything about its syntax.

If it cannot be made to handle arbitrary filenames correctly, then
node(1) must at least detect that it can't handle the specified filename.
It must signal an error on any filename it can't handle, and not use
any mangled form of the filename for any purpose.  Furthermore, this
limitation must be documented.

-zefram

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

Control: tags -1 - moreinfo

Hi again, Simon!

On 2023-01-26 15:50, Simon McVittie wrote:

Another option would be to change the gnome-terminal patch so that if
the locale is Arabic *and* the default font is either "Monospace" or
"Ubuntu Mono", we replace it with "DejaVu Sans Mono" of the same
size. That would be a more narrowly-scoped version that at least
doesn't interfere with users' ability to set a different size,
although it would still require non-upstreamable patches in multiple
packages.


I like that approach and have now rewritten the patch:

https://salsa.debian.org/gnome-team/gnome-terminal/-/merge_requests/9

I chose to set "Monospace" when needed instead of specifying "DejaVu 
Sans Mono" explicitly.


As regards other packages, my thought is to limit this kind of tweak to 
the terminals we ship by default, i.e. gnome-terminal currently and 
maybe gnome-console later.


While the importance of the patch is much greater in Ubuntu (with Ubuntu 
Mono as default), personally I think it may be useful in Debian too 
after all:


* Consider an Arabic Debian user who opens Tweaks and picks some 
beautiful monospace font with e.g. the text editor in mind. With the 
patch applied, that user would not screw up the rendering of Arabic in 
gnome-terminal unknowingly.


* With the patch also in Debian, we avoid to add to the Ubuntu/Debian 
delta, which is always desirable. :)


So even if the target branch of the MR is ubuntu/master, it would be 
great if you could review it with Debian in mind. If I get a green light 
from you, I will add the patch to Debian instead.


--
Cheers,
Gunnar

Bug#1030343: The desktop files contains in Categories the keyword 'Utility' twice

[Joerg Schiermeier, Bielefeld/Germany]

Package: wxhexeditor
Version: 0.24+repack-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hello!

The desktop file for Linux (/usr/share/applications/wxHexEditor.desktop) has 
two times the categories: 'Utility'
See this:
Categories=Utility;TextEditor;Utility;

Please see the documentation about desktop files here:


The doubled category should only appear once.

- -- 
Yours sincerely
Joerg Schiermeier



- -- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 5 (daedalus/ceres)
Release:5
Codename:   daedalus ceres
Architecture: x86_64

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages wxhexeditor depends on:
ii  libc6 2.33-1
ii  libdisasm00.23-6+b1
ii  libgcc-s1 [libgcc1]   11.2.0-13
ii  libgomp1  11.2.0-13
ii  libmhash2 0.9.9.9-9
ii  libstdc++611.2.0-13
ii  libwxbase3.0-0v5  3.0.5.1+dfsg-2+b1
ii  libwxgtk3.0-gtk3-0v5  3.0.5.1+dfsg-2+b1

wxhexeditor recommends no packages.

wxhexeditor suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Comment: This was created by GnuPG for Linux.

iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAmHHoiYACgkQodFQ9YsO
8GMyxhAAn7U1vWiBM6gcGYIsW52daWkT5DMlmqemNHwikaek66hl2deiI9ggkfx8
xiZuntG+q7PlDG9sXE6IxkB5emdeBJsu3i2bPqG+qcm8xAR5PzE+CH51BhCSNyNr
4rZtbWyDmFiOCKqul/+GHVLJzbhdLzAJyt1s9LhJ8TuoQmjf2C4ZMsOpHiZbNz0w
4HKdjFrrv1LFGQe2XKBDlGb246hkKXAuy6Nf00J2mhcA3XyAIF/LfgHCmFFxVhCX
Ri5GNNYB5RdQj0vJv/SbM4GyW88NrrH/hOi1sBSaDc3L7KOw7Yt2HKhoJNImrTyr
i54XlC5ooUEXf/gk0tyNCAGLJFGoslibRYoF1VIn4GR9cJxoJ3MwsZW+kZkJYFIe
4em4S4J4NpfIvpnv/qXsE8UVbtM6wXhH9c5YVjl79mSpvb4q/uv7l0x3IOJoXwwD
zjkNIwAF01km4m20ohoFSiWBc38yeM0RP3lKtNwkoGsb/AngFQzn6zVzfvTIoiyV
D8mZaGvjBAzuy0EBMr5/OZAOO73bN5QDmeNXfx/7vrJDHYsIt8Ma8J8uxiK5a5/Y
fwlCniG59Pao0KArBswCaVEHne0sGEUwt8A5D5T4N00r/At5L+JDTxgvSFHdYZNh
/krkNM/loyTLWpqXPJh9UciEgO0YjUs1LRFjqfu902J3hF02R/g=
=2DjO
-END PGP SIGNATURE-
Forwarded from https://bugs.devuan.org/647

Bug#1020576: Clarify why sagemath package is broken

[Tobias Hansen]

Control: retitle -1 "FTBFS with setuptools >= 64"
Control: block 1028345 by -1
Control: block 1013399 by -1
Control: block 1022254 by -1
Control: block 1022278 by -1
Control: block 1028433 by -1
Control: block 1025874 by -1

Just to clarify that the issue is simply that I can't build sagemath due to the 
setuptools issue described above. Everything else is just a symptom of not 
being able to rebuild the package.

Best,
Tobias

Bug#1029129: gnome-control-center: gnome control center segfault on boot (dmesg)

[Bernhard Übelacker]

On Wed, 18 Jan 2023 11:26:42 +0100 xevilstar  wrote:

I am getting the following message in dmesg at boot

[Wed Jan 18 07:40:37 2023] gnome-control-c[14186]: segfault at 55a65c093a45 ip 
7f206782b8f3 sp 7ffe36eef7d0 error 4 in 
libgobject-2.0.so.0.7500.0[7f2067801000+32000] likely on CPU 9 (core 4, socket 
0)
[Wed Jan 18 07:40:37 2023] Code: 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 48 89 fd 
53 48 85 ff 0f 84 cf 00 00 00 48 8b 07 48 89 f3 48 85 c0 0f 84 cd 00 00 00 <4c> 
8b 20 49 81 fc fc 03 00 00 0f 86 0d 01 00 00 4c 89 e7 48 83 e7

I'd love for it to disappear and I'd like the problem to be solved 
even tho the control center seems to work afterwards




Hello,
if you still experience this issue, would it be possible
to install the package systemd-coredump?
Then a automatic backtrace would be written to the journal,
or be retrieved by coredumpctl.
That could give the maintainer a better starting point.



Kind regards,
Bernhard

coredumpctl list
coredumpctl gdb 

Bug#1030342: EMAIL address *has* to contain an "@"

[Jürgen A . Erhard]

Package: uptimed
Version: 1:0.4.6-3
Severity: minor

/usr/sbin/sendmail -t accepts unqualified addresses.  uptimed doesn't,
but doesn't document it anywhere, as far as I can tell.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 5 (daedalus/ceres)
Release:5
Codename:   daedalus ceres
Architecture: x86_64

Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages uptimed depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  init-system-helpers1.63devuan1
ii  libc6  2.33-7

uptimed recommends no packages.

uptimed suggests no packages.

-- Configuration Files:
/etc/uptimed.conf changed [not included]

-- debconf information excluded
Forwarded from https://bugs.devuan.org/684

Bug#1013935: dogtag-pki: flaky autopkgtest: regularly times out on amd64, armhf and s390x

[Adrian Bunk]

On Thu, Feb 02, 2023 at 10:07:24PM +0100, Paul Gevers wrote:
> Hi Adrian,
> 
> On 02-02-2023 21:32, Adrian Bunk wrote:
> > On Mon, Jun 27, 2022 at 08:31:53PM +0200, Paul Gevers wrote:
> > > I looked at the results of the autopkgtest of you package because it was
> > > showing up on our "slow" page [1]. I noticed that there were several runs
> > > that took 2:47 (our timeout time), while successful runs more in the order
> > > of minutes.
> > > ...
> > 
> > Lookking at debci results with recent versions, this problem seems to be
> > fixed now?
> 
> It was a mistake that the block was lifted, but indeed, you might be right.
> 
> > There only seems to be an unrelated(?) error
> >Installation failed: Server did not start after 60s
> > on !amd64 that results in fast failures.
> 
> But that is an RC issue on it's own, because dogtag-pki used to pass on all
> architectures and autopkgtest regression is listed on
> https://release.debian.org/testing/rc_policy.txt

But that's a different issue, and one that could be workarounded with
  Architecture: amd64
for the autopkgtest.

> Paul

cu
Adrian

Bug#1030341: nextcloud-desktop-cmd: nextcloudcmd contains em-dashes instead of double dashes

[Nicolas George]

Package: nextcloud-desktop-cmd
Version: 3.1.1-2+deb11u1
Severity: normal
X-Debbugs-Cc: nicolas.geo...@ens.fr

Hi. `man nextcloudcmd` says:

   —user, -u [user]
  Use user as the login name.

But:

$ nextcloudcmd —user george [snip]
nextcloudcmd - command line Nextcloud client tool
[snip usage info]

$ nextcloudcmd -user george [snip]
nextcloudcmd - command line Nextcloud client tool
[snip usage info]

$ nextcloudcmd --user george [snip]
Password for user george:

The man page (including its source file) contains an em-dash character
U+2014 instead of a double dash. It is not limited to the --user option.


-- 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 6.0.0-0.deb11.6-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=fr_FR.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 nextcloud-desktop-cmd depends on:
ii  libc6 2.31-13+deb11u5
ii  libgcc-s1 10.2.1-6
ii  libnextcloudsync0 3.1.1-2+deb11u1
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5network55.15.2+dfsg-9
ii  libqt5sql5-sqlite 5.15.2+dfsg-9
ii  libstdc++610.2.1-6
ii  nextcloud-desktop-common  3.1.1-2+deb11u1
ii  nextcloud-desktop-l10n3.1.1-2+deb11u1

nextcloud-desktop-cmd recommends no packages.

nextcloud-desktop-cmd suggests no packages.

-- no debconf information

Bug#1030340: Please update pikepdf to latest release 6.2.9

[Amr Ibrahim]

Package: pikepdf

Hello,

Please update pikepdf to the latest release, 6.2.9.

https://github.com/pikepdf/pikepdf

Best,
Amr

Bug#1030044: gbp-pq: Unreproducible and noisy patches due to different diff settings/algorithms

[Guido Günther]

Hi,
On Mon, Jan 30, 2023 at 05:36:43PM +0100, Gioele Barabucci wrote:
> Package: git-buildpackage
> Version: 0.9.30
> 
> Dear maintainers of git-buildpackage,
> 
> The patches exported by `gbp-pq` can be wildly different depending on the
> value set in the git option `diff.algorithm`.
> 
> Thus packages where co-maintainers happen to use different `diff.algorithm`
> values undergo a lot of unneeded "diff churn", making it impossible to
> follow the history of the Debian-specific patches.
> 
> This issue can be fixed by forcing the use of a specific diff algorithm
> inside `gbp-pq`, for example by using `--diff-algorithm=histogram` in
> `gbp.git.Repository.diff`.

Yeah, that's kind of expected as no attempt is made to force
options. One possibility would be to have `gbp clone` dump a set of
options into `.git/config` when cloning the repo. Forcing this in a
hardcoded way would disallow people to tweak these which can make
sense depending on the project.

> Another setting that can reduce diff churn and should be forced by `gbp-pq`
> is `diff.rename`, that should be set to `copies`.

Why's that?

Cheers,
 -- Guido

Bug#1030336: nvidia-driver: Since yesterday upgrade to 515 (from 510) Darktable does not work weel under OpenCL.

[Andreas Beckmann]

On 03/02/2023 09.29, pierre via pkg-nvidia-devel wrote:

Package: nvidia-driver
Version: 515.86.01-1



* What led up to the situation?
Upgrading Nvidia-driver from 510 to 515


In about a week the latest 525 driver should arrive in testing. Please 
try again with that version (not yet in experimental). Until then you 
can work around by disabling OpenCL.


Andreas

Bug#1030339: NotImplementedError: --remove-background is temporarily not implemented

[Amr Ibrahim]

Package: ocrmypdf
Version: 14.0.1+dfsg1-1
Severity: normal
Tags: upstream

Hello,

I get this error when using the option --remove-background:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/ocrmypdf/_sync.py", line 393, in
run_pipeline
optimize_messages = exec_concurrent(context, executor)
^^
  File "/usr/lib/python3/dist-packages/ocrmypdf/_sync.py", line 280, in
exec_concurrent
executor(
  File "/usr/lib/python3/dist-packages/ocrmypdf/_concurrent.py", line 87, in
__call__
self._execute(
  File "/usr/lib/python3/dist-
packages/ocrmypdf/builtin_plugins/concurrency.py", line 141, in _execute
result = future.result()
 ^^^
  File "/usr/lib/python3.11/concurrent/futures/_base.py", line 449, in result
return self.__get_result()
   ^^^
  File "/usr/lib/python3.11/concurrent/futures/_base.py", line 401, in
__get_result
raise self._exception
  File "/usr/lib/python3.11/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
 ^^
  File "/usr/lib/python3/dist-packages/ocrmypdf/_sync.py", line 196, in
exec_page_sync
ocr_image, preprocess_out = make_intermediate_images(
^
  File "/usr/lib/python3/dist-packages/ocrmypdf/_sync.py", line 139, in
make_intermediate_images
preprocess_out = preprocess(
 ^^^
  File "/usr/lib/python3/dist-packages/ocrmypdf/_sync.py", line 108, in
preprocess
image = preprocess_remove_background(image, page_context)
^
  File "/usr/lib/python3/dist-packages/ocrmypdf/_pipeline.py", line 477, in
preprocess_remove_background
raise NotImplementedError("--remove-background is temporarily not
implemented")
NotImplementedError: --remove-background is temporarily not implemented


Upstream bug: https://github.com/ocrmypdf/OCRmyPDF/issues/944

Best,
Amr


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

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

Versions of packages ocrmypdf depends on:
ii  ghostscript10.0.0~dfsg-9+b1
ii  icc-profiles-free  2.0.1+dfsg-1.1
ii  python33.11.1-2
ii  python3-coloredlogs15.0.1-1
ii  python3-deprecation2.1.0-2
ii  python3-img2pdf0.4.4-3
ii  python3-packaging  23.0-1
ii  python3-pdfminer   20221105+dfsg-1
ii  python3-pikepdf6.0.0+dfsg-1+b2
ii  python3-pil9.4.0-1.1+b1
ii  python3-pkg-resources  65.6.3-1
ii  python3-pluggy 1.0.0+repack-1
ii  python3-reportlab  3.6.12-1
ii  python3-tqdm   4.64.1-1
ii  python3-typing-extensions  4.4.0-1
ii  tesseract-ocr  5.3.0-2
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages ocrmypdf recommends:
pn  pngquant  
ii  unpaper   7.0.0-0.1

Versions of packages ocrmypdf suggests:
pn  img2pdf  
pn  ocrmypdf-doc 
pn  python-watchdog  

-- no debconf information

Bug#1026259: Status

[RattusRattus]

Dear team,

- Did I submit to the correct location?
- Is there anything additional information that you require?

BR

--
/RattusRattus
Debian is not always the answer, however it is surprising how many times 
it is...

Bug#1030338: README needs updating.

[Γιώργος Κωστόπουλος]

Package: bsdgames
Version: 2.17-25

/usr/share/doc/bsdgames/README.gz needs updating in order to reflect
the recent (?) changes.

Specifically, README on the paragraph "This package contains the
following games:", mentions:
1) "banner: display a message in big letters" and
2) "dm: dungeon master, regulates games playing"

which are not included at the package nowadays.

README needs to remove them from this catalog too.

Bug#1030337: skanpage starts but does not show a window

[Uwe Steinmann]

Package: skanpage
Version: 22.12.1-1+b1
Severity: important

Dear Maintainer,

when I call skanpage on the command line it prints to stdout

kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "New 
document" msgid_plural: "" msgctxt: ""
QQmlApplicationEngine failed to load component
qrc:/qml/MainWindow.qml:328:5: Type ShareWindow unavailable
qrc:/qml/ShareWindow.qml:13:1: module "org.kde.purpose" is not installed

but never opens a window.

  Uwe


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

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

Versions of packages skanpage depends on:
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libkf5configcore55.102.0-1
ii  libkf5configgui5 5.102.0-1
ii  libkf5coreaddons55.102.0-1
ii  libkf5crash5 5.102.0-1
ii  libkf5i18n5  5.102.0-1
ii  libksanecore122.12.1-1
ii  liblept5 1.82.0-3+b3
ii  libqt5core5a 5.15.8+dfsg-2
ii  libqt5gui5   5.15.8+dfsg-2
ii  libqt5printsupport5  5.15.8+dfsg-2
ii  libqt5qml5   5.15.8+dfsg-2
ii  libqt5quick5 5.15.8+dfsg-2
ii  libqt5widgets5   5.15.8+dfsg-2
ii  libstdc++6   12.2.0-14
ii  libtesseract55.3.0-2

skanpage recommends no packages.

skanpage suggests no packages.

-- no debconf information

Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Vagrant Cascadian (2023-02-03 00:18:58)
> On 2023-02-01, Jérôme Charaoui wrote:
> > I don't know how common that is in build environments, but it's not 
> > something that I have or think I should have in my build (sbuild) or 
> > test (autopkgtest) environments.
> 
> I was able to reproduce the issue with sbuild.
> 
> This appears to be because sbuild copies the host's /etc/passwd and
> /etc/group into the chroot when it builds... and presumably the buildd
> environment does this as well (and all DSA machines have the puppet user
> available?)... and so the puppet user is in fact available in those cases,
> but not others...
> 
> I was able to workaround the issue with:
> 
>   sbuild --chroot-setup-commands='adduser --gecos ,,, --disabled-password 
> puppet' ...
> 
> Is there an option in sbuild to not copy the passwd/group information into
> the chroot? What are the implications of that?

I think we are not so much talking about a limitation of sbuild but about a
limitation of the sbuild schroot backend. When above you say that sbuild copies
/etc/passwd and /etc/group into the chroot, what you probably mean is that
sbuild-createchroot appends the output of `getent passwd sbuild` and `getent
group sbuild` to /etc/passwd and /etc/group, respectively? It would be news to
me if sbuild at any point copies all of /etc/passwd or /etc/group into the
chroot at any point. Do you see this somewhere happening in the code?

Remember that the sbuild-createchroot utility is only really useful if you use
the sbuild schroot backend (which is also the default backend and also the
backend that is used on the buildds). Since you are asking whether passwd/group
information can somehow not be copied into the chroot, you probably are not
interested in a change in the buildd infrastructure but just a local change?

In that case, maybe consider not using the schroot backend but the unshare
backend. The latter has the advantage that you do not need any special setup of
the chroot at all. Any chroot tarball that contains apt can be used by the
unshare backend. Quick introduction (assuming you are on amd64):

$ mkdir -p ~/.cache/sbuild
$ mmdebstrap --variant=buildd unstable ~/.cache/sbuild/unstable-amd64.tar.xz
$ sbuild --chroot-mode=unshare ...

Note that in contrast to the schroot backend, you do not need to become the
superuser at any point.

Thanks!

cheers, josch

Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules

[Norwid Behrnd]

Postscript:

If you already edit `debian/changelog` (`UNRELEASED` -> `unstable`), the
trailing spaces in this file equally can be removed in the same session, too.

Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules

[Norwid Behrnd]

Hello Min Sun,

is there a particular reason why you opt for / stick to distribution
`UNRELEASED` for a package already monitored by the tracker?[1]  It is the
entry e.g., `dch -i` puts into file `/debian/changelog` when you start to work
on a new version (increment) of a package.  After all other other work on your
side is done, an eventual change to the string `unstable` (then lower case
only) is one of the keys necessary to let results of your work enter branch
`unstable`, and later `testing`, etc.

Regards,

Norwid

[1] https://tracker.debian.org/pkg/libcommons-validator-java

Bug#1026922:

[Huang Dawei]

I’d suppose there is a misunderstanding: HTTP_PROXY is used to specify the 
proxy options of all HTTP connections, and HTTPS_PROXY is used by HTTPS 
connections. Only in this way the names of ALL_PROXY and NO_PROXY could make 
sense.

---
Dawei Huang

Bug#1029281: [Pkg-openssl-devel] Bug#1029281: Bug#1029281: openssl: loongarch64 is little endian

[zhangdandan]

Dear Sebastian,


So it has been tested, thank you.
There will be an upload on TUE evenning of 3.0.8 and I plan to include
it there.

Okay. Thank you for considering this patch.

Thanks,
Dandan Zhang

Bug#1026922: golang-go: more action needed

[debbug . 1026922]

Package: golang-go
Version: 2:1.15~1
Followup-For: Bug #1026922
X-Debbugs-Cc: debbug.1026...@sideload.33mail.com

> This is exactly feature that Go upstream provides for a long time.
> If you think differently, you should open a "proposal" in Go upstream,
> https://github.com/golang/proposal#the-proposal-process

“Feature” is the wrong word here. Use of incorrect terminology &
misstating a usage is a plainly obvious defect. The incorrectness of
(e.g.) calling a “potato” a “tomato” leaves no room for
subjectivity. It’s a bug. Consequently, a bug report was filed (not a
feature proposal).

To say it’s been that way “a long time” is known as a /Conventional
Wisdom/ fallacy. The bug does not become less of a bug over time. The
only effect that time has in this case is to do more damage, as more
and more code creates dependencies on the defect. Go lang itself is
also a quite young language, coming into existence in 2009. So nothing
about the language has existed for “a long time”.

Directing users to report bugs upstream goes against Debian
conventions. It’s the duty of the maintainer to mirror bugs upstream:

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

Not everyone has MS Github. Not everyone is willing to have
transactions with Microsoft. I cannot login to Github because the 2fa
process forces me to check an account that blocks access to the
verification code with a broken CAPTCHA.

Please follow the Debian procedure and mirror this bug report
upstream; not as a proposed new feature but as a bug report.

Thank you.