Bug#1013156: gdcm: vtk[6,7] removal

[Andreas Tille]

Hi,

in the bug log there is some discussion to drop C# and Java VTK
bindings.  This would mean to drop the packages libvtkgdcm-cil and
libvtkgdcm-java.  I'm perfectly fine with this and I just pushed
a change in d/control where I replaced s/vtk7/vtk9/ globally.  The
build[1] is currently failing at a probably simple Java issue:

/usr/lib/jvm/default-java/include/jni.h:45:10: fatal error: jni_md.h: No such 
file or directory
   45 | #include "jni_md.h"
  |  ^~
compilation terminated.

I have no idea whether we might keep on supporting the Java bindings if
this can be solved.  But I'm pretty sure we should act on droping
what needs to be droped in a timely manner to make sure gdcm will
remain in testing.

Any help is welcome.

Kind regards

Andreas.

[1] https://salsa.debian.org/med-team/gdcm/-/jobs/3424711

-- 
http://fam-tille.de

Bug#1018954: Can't open perl script "/usr/share/vtk9/doxygen//doc_header2doxygen.pl": No such file or directory

[Andreas Tille]

Hi,

is there any chance to provide doc_header2doxygen.pl
in VTK9 packages?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#1022348: gpgme1.0: FTBFS: Could not find gpg-error-config. Please install the libgpg-error development package.

[Andreas Metzler]

Control: tags -1 patch
Control: tags -1 fixed-upstream

On 2022-10-25 Andreas Metzler  wrote:
> Control: forwarded -1 https://dev.gnupg.org/T6204

> On 2022-10-23 Lucas Nussbaum  wrote:
> > Source: gpgme1.0
> > Version: 1.18.0-1
> [...]
> > > Could not find gpg-error-config.  Please install the libgpg-error 
> > > development package.
> > > make[4]: *** [Makefile:760: all-local] Error 1
> [...]

> There is a patch in upstream GIT ae9258fbf3b9d434495ef11fc184a91fe7c4ca57 but
> it breaks when @GPG_ERROR_CFLAGS@ expands to nothing which happens on
> Debian.

Which has been promptly fixed. Find attached debdiffs for a proposed
upload. - I can also massage this into a mergew-request or push
directly to https://salsa.debian.org/debian/gpgme Just give me a
heads-up.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru gpgme1.0-1.18.0/debian/changelog gpgme1.0-1.18.0/debian/changelog
--- gpgme1.0-1.18.0/debian/changelog	2022-09-29 02:31:10.0 +0200
+++ gpgme1.0-1.18.0/debian/changelog	2022-10-26 06:56:43.0 +0200
@@ -1,3 +1,16 @@
+gpgme1.0 (1.18.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add 0010-build-python-Don-t-use-gpg-error-config-gpgme-config.patch
+and 0013-python-Fix-configure-generating-setup.py.patch from upstream
+GIT master to fix FTBFS after removal of gpg-error-config.
+Closes: #1022348
+  * Without gpg-error-config gpgme-config is not installed by the upstream
+build system anymore. Adapt libgpgme-dev.install, drop related lintian
+override and Debian specific manpage.
+
+ -- Andreas Metzler   Wed, 26 Oct 2022 06:56:43 +0200
+
 gpgme1.0 (1.18.0-1) unstable; urgency=medium
 
   * new upstream version
diff -Nru gpgme1.0-1.18.0/debian/gpgme-config.1 gpgme1.0-1.18.0/debian/gpgme-config.1
--- gpgme1.0-1.18.0/debian/gpgme-config.1	2022-09-06 20:52:33.0 +0200
+++ gpgme1.0-1.18.0/debian/gpgme-config.1	1970-01-01 01:00:00.0 +0100
@@ -1,94 +0,0 @@
-.TH "GPGME" "1" "08 July 2012" "gpgme" "User commands"
-
-.SH NAME
-gpgme\-config \- script to get information about the installed version of GPGME
-
-.SH SYNOPSIS
-.B  gpgme\-config
-.RB [ \-\-api\-version ]
-.RB [ \-\-cflags ]
-.RB [ \-\-exec\-prefix ]
-.RB [ \-\-get\-gpg ]
-.RB [ \-\-get\-gpgsm ]
-.RB [ \-\-host ]
-.RB [ \-\-libs ]
-.RB [ \-\-prefix ]
-.RB [ \-\-thread=pthread ]
-.RB [ \-\-version ]
-
-.SH DESCRIPTION
-.PP
-\fBgpgme\-config\fP is a tool that is used to configure to determine
-the compiler and linker flags that should be used to compile
-and link programs that use \fIGPGME\fP. It is also used internally
-to the .m4 macros for GNU autoconf that are included with \fIGPGME\fP.
-
-.SH OPTIONS
-.PP
-\fBgpgme\-config\fP accepts the following options:
-.TP
-.B \-\-api\-version
-Print the currently installed API version of \fIGPGME\fP to standard output.
-.TP
-.B \-\-cflags
-Print the compiler flags that are necessary to compile a \fIGPGME\fP program.
-.TP
-.B \-\-exec\-prefix
-Print the exec prefix that was used to configure the \fIGPGME\fP build.
-.TP
-.B \-\-get\-gpg
-Print the path to the
-.BR gpg (1)
-binary used to configure the \fIGPGME\fP build.
-.TP
-.B \-\-get\-gpgsm
-Print the path to the
-.BR gpgsm (1)
-binary used to configure the \fIGPGME\fP build.
-.TP
-.B \-\-host
-Print host information.
-.TP
-.B \-\-libs
-Print the linker flags that are necessary to link a \fIGPGME\fP program.
-.TP
-.B \-\-prefix
-Print the prefix that was used to configure the \fIGPGME\fP build.
-.TP
-.B \-\-thread=pthread
-Switch for the
-.B \-\-cflags
-and
-.B \-\-libs
-options for the thread-enabled \fIGPGME\fP version.
-.TP
-.B \-\-version
-Print the currently installed version of \fIGPGME\fP to standard output.
-
-.SH AUTHORS
-.PP
-.PP
-The
-.I GPGME
-library is written by many contributors, including Werner Koch, Marcus
-Brinkmann, Andre Heinecke, Justus Winter, and Karl-Heinz Zimmer.
-.PP
-This manual page page was written by \fBJose Carlos Garcia Sogo\fR
-\&<\@debian.org\&> and \fBDaniel Leidert\fR <\@wgdd.de\&>
-for the Debian distribution (but may be used by others).
-
-.SH BUGS
-.PP
-Please report bugs to .
-
-.SH COPYRIGHT
-\fBgpgme\-tool\fP is Copyright \(co 2015-2016 g10 Code GmbH License
-GPLv2+: GNU GPL version 2 or later 
-.PP
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law.
-
-.SH "SEE ALSO"
-.BR gpgme\-tool (1),
-.BR /usr/include/gpgme.h ,
-.B info gpgme
diff -Nru gpgme1.0-1.18.0/debian/libgpgme-dev.install gpgme1.0-1.18.0/debian/libgpgme-dev.install
--- gpgme1.0-1.18.0/debian/libgpgme-dev.install	2022-09-06 20:52:33.0 +0200
+++ gpgme1.0-1.18.0/debian/libgpgme-dev.install	2022-10-26 06:56:43.0 +0200
@@ -1,4 +1,3 @@
-usr/bin/gpgme-config
 usr/bin/gpgme-tool
 usr/include/gpgme.h
 usr/lib/*/libgpgme.a
diff -Nru 

Bug#1022793: libcache-memcached-fast-perl: autopkgtest regression: missing symbols

[Paul Gevers]

Source: libcache-memcached-fast-perl
Version: 0.28-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Control: block 1019353 by -1

Dear maintainer(s),

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


 passfail
libcache-memcached-fast-perl from testing0.28-1
versioned deps [0]   from testingfrom unstable
all others   from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. On 
top of that it is blocking the perl transition. Can you please 
investigate the situation and fix it?


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

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
libcache-memcached-fast-perl/0.28-1. I.e. due to versioned dependencies 
or breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=libcache-memcached-fast-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcache-memcached-fast-perl/27459794/log.gz


t/perl-namespace.t .. # Seeded srand with seed '20221023' from local date.
not ok 1

# Failed test at t/perl-namespace.t line 30.
# +--+---+---+---+
# | PATH | GOT   | CHECK | LNs   |
# +--+---+---+---+
# |  | ARRAY(0x55c74144e770) |  | 3, 30 |
# | [*]  |   | ISA   | 4 |
# | [*]  |   | dl_load_flags | 4 |
# +--+---+---+---+
1..1
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests t/serialize.t ... # Seeded srand with seed 
'20221023' from local date.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021193:

[Keith Packard]

I looked for exactly this bug as I fixed the same issue in
binutils-riscv-unknown-elf today, but somehow I missed it.

This should be fixed in version 18 by using dpkg-query instead of
hand-hacked shell bits:

upstream_version := $(shell dpkg-query -W -f="\$${source:Upstream-Version}\n" 
binutils-source)

-- 
-keith


signature.asc
Description: PGP signature

Bug#1022792: lintian: Hyphen in upstream version causes false positive in bad-jar-name check

[Olek Wojnar]

Package: lintian
Version: 2.115.3
Severity: normal

Dear Maintainer,

While performing an initial build for libzstd-jni-java I discovered that
lintian was giving a false positive for the package. I verified manually
that the jar file is named correctly. My package uses an upstream
versioning convention that includes a hyphen and I belive that this
convention is breaking the test's regex[1].

Please let me know if there's any additional information that you need.

Thank you!

-Olek

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Languages/Java.pm#L116

Bug#1022788: cockpit: FTBFS on armel/mipsel/mips64el: dh_auto_test failures

[Martin Pitt]

Hello Michael, hello Lis,

Michael Biebl [2022-10-26  1:41 +0200]:
> cockpit seems to fail its test suite on the aforementioned architectures

Thanks for the report!

> on armel:
> ~
> Bail out! GLib-FATAL-WARNING: GChildWatchSource: Exit status of a child 
> process was requested but ECHILD was received by waitpid(). See the 
> documentation of g_child_watch_source_new() for possible causes.
>
> (test-channelresponse:13227): GLib-WARNING **: 11:53:58.590: 
> GChildWatchSource: Exit status of a child process was requested but ECHILD 
> was received by waitpid(). See the documentation of 
> g_child_watch_source_new() for possible causes.
> **

Argh, this keeps haunting us. We already tried to fix that in [1] and [2], but
no way. Why must glib be so unpredictable? 

Lis, WDYT about just running this particular check in upstream CI (env var or
so?), and not during downstream `make check`?

Thanks,

Martin

[1] https://github.com/cockpit-project/cockpit/pull/17728
[2] https://github.com/cockpit-project/cockpit/pull/17755

Bug#1022791: tripwire --check segfaults on startup (probably needs rebuild)

[Russ Allbery]

Package: tripwire
Version: 2.4.3.7-4+b3
Severity: grave
X-Debbugs-Cc: r...@debian.org

Looks like tripwire needs another rebuild against the latest libc6.
tripwire --check and tripwire --init both segfault once they start
analyzing the file system.  Rebuilding the package with no changes
causes it to work again.

(This is probably the standard problem with statically linked binaries
loading nsswitch modules from libc versions other than the one that
they're statically linked with.)

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 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 tripwire depends on:
ii  debconf [debconf-2.0]   1.5.79
ii  postfix [mail-transport-agent]  3.7.3-2

tripwire recommends no packages.

tripwire suggests no packages.

-- Configuration Files:
/etc/cron.daily/tripwire changed [not included]
/etc/tripwire/twcfg.txt changed [not included]
/etc/tripwire/twpol.txt changed [not included]

-- debconf information:
* tripwire/installed:
* tripwire/rebuild-config: true
  tripwire/change-in-default-policy:
* tripwire/rebuild-policy: true
* tripwire/use-localkey: true
  tripwire/upgrade: true
  tripwire/local-passphrase-incorrect: false
* tripwire/use-sitekey: true
* tripwire/site-passphrase-incorrect: true
  tripwire/broken-passphrase:
  tripwire/email-report:

Bug#1022790: usrmerge: Typo in "convert-usrmerge will not be run automatically" message

[Wookey]

Package: usrmerge
Version: 33
Severity: minor


Installing usrmerge in a chroot gave this error message:
Setting up usrmerge (33) ...
Warning: overlayfs detected, /usr/lib/usrmerge/convert-usrmerge will not
be run automatically. See #1008202 for details.

If this is a container then it can be converted by unpacking the image,
entering it with chroot(8), installling usrmerge and then repacking the
image again. at /usr/lib/usrmerge/convert-usrmerge line 399.
E: usrmerge failed.


There should not be 3 'l's in 'installling'

--
Wookey

Bug#1022789: texinfo: UTF-8 is not the default input encoding

[Vincent Lefevre]

Package: texinfo
Version: 6.8-6+b1
Severity: normal

/usr/share/doc/texinfo/NEWS.gz says

  . UTF-8 is the default input encoding

but this is not true in Debian.

For instance,


\input texinfo@c -*-texinfo-*-
@documentencoding UTF-8

@node Top
@node Test

@minus{}

@bye


compiled with makeinfo gives U+2212 MINUS SIGN, but


\input texinfo@c -*-texinfo-*-

@node Top
@node Test

@minus{}

@bye


gives U+002D HYPHEN-MINUS.

Since UTF-8 is supposed to be the default input encoding,
whether "@documentencoding UTF-8" is present or not should
not make any difference.

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

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

Versions of packages texinfo depends on:
ii  libc6   2.35-1
ii  libtext-unidecode-perl  1.30-3
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  perl5.36.0-4
ii  perl-base [perlapi-5.36.0]  5.36.0-4
ii  tex-common  6.18

texinfo recommends no packages.

Versions of packages texinfo suggests:
ii  texlive-base   2022.20220923-1
ii  texlive-fonts-recommended  2022.20220923-1
ii  texlive-latex-base 2022.20220923-1
ii  texlive-plain-generic  2022.20220923-2

-- no debconf information

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

Bug#1022781: Unable to lock an existing session

[Antoni Villalonga]

Hi Martin,

Your bug report is appreciated.

On Tue, Oct 25, 2022 at 08:33:23PM +0200, martin f krafft wrote:
> Package: xautolock
> Version: 1:2.2-7
> Severity: critical
> Tags: security
> 
> This is not software you can rely on to lock your screen:

I guess the exit value of your `xautolock -locknow` execution is not zero. At
it's defined as EXIT_FAILURE (EXIT_FAILURE=1 in stdlib.c).

Check the exit value and you can relay again with this lovely ancient software
:)

> ```
> lotus:~% xautolock -locknow
> Could not locate a running xautolock.
> lotus:~% ps aux | grep '[x]autolo'
> madduck   172688  0.0  0.0   6584  2756 ?SOct23   0:34 xautolock 
> -time 3 -locker exec /usr/bin/xsecurelock -notify 30 -notifier notify-send 
> Locking the screen in 30 seconds
> ```

The message "Could not locate a running xautolock." (src/message.c:286) only
show up when `type` is not `XA_INTEGER` (19. Defined in
/usr/include/X11/Xatom.h from x11proto-dev).

I can't reproduce this situation even after testing on Bookworm and Sid.

Can you give us more details about your system setup?
It seems your system is based on Debian testing/unstable.
Are you using xorg locally using a single single logged in?



I'll appreciate if you can add the following line just before (
"if (type == XA_INTEGER)") and rebuild xautolock...
src/message.c:250:  printf("DEBUG checkConnectionAndSendMessage | 
XGetWindowProperty type: %d\n", type);

After that, run "xautolock -locknow" and you'll get a message with the `type`
value.

> Strace didn't disclose any file the process might be looking for.

My strace for 'xautolock -locknow' run looks like:
  | 122 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
  | 123 connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
  | [...]
  | 390 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{
  | 391 writev(3, [{iov_base="\22\0\7\0\1\0\200\0Y\1\0\0\37\
  | 392 poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3,
  | 393 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{
  | 394 recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN 
  | 395 recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN 
  | 396 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{
  | 397 writev(3, [{iov_base="\20\0\7\0\21\0\200\0XAUTOLOCK_
  | 398 poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3,
  | 399 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{
  | 400 recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN 
  | 401 recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN 
  | 402 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{
  | 403 writev(3, [{iov_base="\24\0\6\0g\7\0\0\227\1\0\0\0\0
  | 404 poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3,
  | 405 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{
  | 406 recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN 
  | 407 recvmsg(3, {msg_namelen=0}, 0)  = -1 EAGAIN 
  | 408 kill(1234567, 0)= -1 ESRCH (

Around line 390 is where checkConnectionAndSendMessage() calls 
RootWindowOfScreen().
And at line 402 XGetWindowProperty() is called.
In my execution 'type'==19, so a kill(pid, 0) is called to check the pid is 
available.

I've run strace as:
  % strace -s 1000 --output=xautolock-strace.txt xautolock -locknow

Thanks again for your report.
Hope you can run an strace and give back more info about your system setup.

Best regards,

-- 
Antoni Villalonga
https://friki.cat/

Bug#1022142: Info received (Bug#1022142: linux-image-6.0.0-1-amd64: Cannot boot kernels after 5.10, unless in 'recovery mode')

[Phil Dibowitz]

Update. If I remove `amdgpu.dpm=0` then newer kernels will boot (though 
this option works on older kernels).



--
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#1022788: cockpit: FTBFS on armel/mipsel/mips64el: dh_auto_test failures

[Michael Biebl]

Source: cockpit
Version: 276.1-1
Severity: serious

cockpit seems to fail its test suite on the aforementioned architectures

on armel:
~
(cockpit-bridge:13294): cockpit-bridge-WARNING **: 11:53:58.528: couldn't 
create runtime dir: /run/user/2952: Permission denied
cockpit-bridge-Message: 11:53:58.577: incompatible: package requires a later 
version of cockpit: 999.5 > 277
cockpit-bridge-Message: 11:53:58.577: requires: package has an unknown 
requirement: unknown
cockpit-bridge-Message: 11:53:58.582: couldn't get polkit authority: Error 
initializing authority: Could not connect: No such file or directory
# cockpit-protocol-DEBUG: cockpit-bridge: reading input 1
# cockpit-protocol-DEBUG: cockpit-bridge: received a 358 byte payload
# cockpit-ws-DEBUG: received init message
# cockpit-protocol-DEBUG: cockpit-bridge: queued 67 byte payload
# cockpit-protocol-DEBUG: cockpit-bridge: want more data
# cockpit-protocol-DEBUG: cockpit-bridge: queued 302 byte payload
# cockpit-protocol-DEBUG: cockpit-bridge: queued 35 byte payload
# cockpit-protocol-DEBUG: cockpit-bridge: queued 34 byte payload
# cockpit-protocol-DEBUG: cockpit-bridge: end of input
# cockpit-protocol-DEBUG: cockpit-bridge: pipe closing when output queue empty
# cockpit-protocol-DEBUG: cockpit-bridge: couldn't write: Broken pipe
# cockpit-protocol-DEBUG: cockpit-bridge: closing pipe: terminated
# cockpit-protocol-DEBUG: cockpit-bridge: killing child: 13294
Bail out! GLib-FATAL-WARNING: GChildWatchSource: Exit status of a child process 
was requested but ECHILD was received by waitpid(). See the documentation of 
g_child_watch_source_new() for possible causes.

(test-channelresponse:13227): GLib-WARNING **: 11:53:58.590: GChildWatchSource: 
Exit status of a child process was requested but ECHILD was received by 
waitpid(). See the documentation of g_child_watch_source_new() for possible 
causes.
**
cockpit-ws:ERROR:src/ws/test-channelresponse.c:526:test_resource_failure: Got 
unexpected message: GChildWatchSource: Exit status of a child process was 
requested but ECHILD was received by waitpid(). See the documentation of 
g_child_watch_source_new() for possible causes. instead of cockpit-ws-Message: 
*: external channel failed: *
Bail out! 
cockpit-ws:ERROR:src/ws/test-channelresponse.c:526:test_resource_failure: Got 
unexpected message: GChildWatchSource: Exit status of a child process was 
requested but ECHILD was received by waitpid(). See the documentation of 
g_child_watch_source_new() for possible causes. instead of cockpit-ws-Message: 
*: external channel failed: *
FAIL test-channelresponse (exit status: 134)


on mips* the test suite is killed after 150min of inactivity

This currently prevents testing migration, thus filing with RC severity.

Bug#1004638: openjfx: diff for NMU version 11.0.11+0-1.1

[Sebastian Ramacher]

Control: tags 1004638 + patch
Control: tags 1004638 + pending
Control: tags 1013009 + patch
Control: tags 1013009 + pending

Dear maintainer,

I've prepared an NMU for openjfx (versioned as 11.0.11+0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru openjfx-11.0.11+0/debian/changelog openjfx-11.0.11+0/debian/changelog
--- openjfx-11.0.11+0/debian/changelog	2021-02-03 16:18:39.0 +0100
+++ openjfx-11.0.11+0/debian/changelog	2022-10-26 00:07:14.0 +0200
@@ -1,3 +1,16 @@
+openjfx (11.0.11+0-1.1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Philipp Kern ]
+  * Drop build-dependency on ffmpeg, openjfx isn't source-compatible with
+ffmpeg 5.0. Closes: #1004638.
+  * Build-depend on g++-11, source not compatible with g++ 12.
+Closes: #1013009.
+(Both patches taken from Ubuntu, thanks to Steve Langasek)
+
+ -- Sebastian Ramacher   Wed, 26 Oct 2022 00:07:14 +0200
+
 openjfx (11.0.11+0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru openjfx-11.0.11+0/debian/control openjfx-11.0.11+0/debian/control
--- openjfx-11.0.11+0/debian/control	2021-02-03 16:14:56.0 +0100
+++ openjfx-11.0.11+0/debian/control	2022-10-26 00:06:27.0 +0200
@@ -10,13 +10,12 @@
default-jdk,
default-jdk-doc,
flex,
+   g++-11,
gperf,
gradle (>= 4.4),
gradle-debian-helper (>= 2.0),
junit4,
libasound2-dev,
-   libavcodec-dev,
-   libavformat-dev,
libgl1-mesa-dev,
libgstreamer-plugins-base1.0-dev,
libgstreamer1.0-dev,
diff -Nru openjfx-11.0.11+0/debian/patches/disable-ffmpeg.patch openjfx-11.0.11+0/debian/patches/disable-ffmpeg.patch
--- openjfx-11.0.11+0/debian/patches/disable-ffmpeg.patch	1970-01-01 01:00:00.0 +0100
+++ openjfx-11.0.11+0/debian/patches/disable-ffmpeg.patch	2022-10-26 00:06:27.0 +0200
@@ -0,0 +1,24 @@
+Description: Don't build ffmpeg plugin when ffmpeg is disabled
+Author: Steve Langasek 
+Last-Update: 2022-09-21
+Bug-Debian: https://bugs.debian.org/1004638
+
+Index: openjfx-11.0.11+1/build.gradle
+===
+--- openjfx-11.0.11+1.orig/build.gradle
 openjfx-11.0.11+1/build.gradle
+@@ -3715,14 +3715,6 @@ project(":media") {
+ }
+ }
+ }
+-} else {
+-// Building fxavcodec plugin (libav plugin)
+-exec {
+-commandLine ("make", "${makeJobsFlag}", "-C", "${nativeSrcDir}/gstreamer/projects/linux/avplugin")
+-args("CC=${mediaProperties.compiler}", "LINKER=${mediaProperties.linker}",
+- "OUTPUT_DIR=${nativeOutputDir}", "BUILD_TYPE=${buildType}",
+- "BASE_NAME=avplugin", IS_64 ? "ARCH=x64" : "ARCH=x32")
+-}
+ }
+ }
+ }
diff -Nru openjfx-11.0.11+0/debian/patches/series openjfx-11.0.11+0/debian/patches/series
--- openjfx-11.0.11+0/debian/patches/series	2021-02-03 14:56:03.0 +0100
+++ openjfx-11.0.11+0/debian/patches/series	2022-10-26 00:06:27.0 +0200
@@ -18,3 +18,4 @@
 no-error_deprecated-declarations.patch
 32-gradle-compatibility.patch
 36-disable-swt-on-32bit-arch.patch
+disable-ffmpeg.patch
diff -Nru openjfx-11.0.11+0/debian/rules openjfx-11.0.11+0/debian/rules
--- openjfx-11.0.11+0/debian/rules	2021-02-03 16:09:51.0 +0100
+++ openjfx-11.0.11+0/debian/rules	2022-10-26 00:06:27.0 +0200
@@ -3,6 +3,8 @@
 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
+export CXX=g++-11
+
 # FIXME: looks like s390x is recognized as a 32bit arch ...
 # more heap on s390x needed
 ifneq (,$(filter $(DEB_HOST_ARCH), s390x))

Bug#1022748: libqt5gui5: hide() + show() + hide() on a dialog frame hides it forever under X

[Alexander Kernozhitsky]

> After some testing, I determined that the bug is not present in
> 5.15.5+dfsg-3 but is present in 5.15.6+dfsg-1.

Control: tags -1 patch fixed-upstream
Control: found -1 5.15.6+dfsg-1
Control: notfound -1 5.15.5+dfsg-3

Okay, I have finally found the bug. It was introduced in the following commit:

https://github.com/qt/qtbase/commit/290b405872602de931646fe4f769eff208f9bbef

The fix is as follows:

https://github.com/qt/qtbase/commit/d27a6235246764bef1d61905ef96feeeddc65cd8
https://github.com/qt/qtbase/commit/f9e4402ffeef791e66b7b2f2cc332000df7f5cd4

Please consider adding this patch into Debian.

For convenience, I am attaching the cherry-picked patch that is needed to 
apply.

-- 
Alexander Kernozhitskydiff --git a/src/plugins/platforms/xcb/qxcbwindow.cpp b/src/plugins/platforms/xcb/qxcbwindow.cpp
index da179591e9..9acef9b5e9 100644
--- a/src/plugins/platforms/xcb/qxcbwindow.cpp
+++ b/src/plugins/platforms/xcb/qxcbwindow.cpp
@@ -93,6 +93,8 @@ enum {
 
 QT_BEGIN_NAMESPACE
 
+Q_LOGGING_CATEGORY(lcQpaWindow, "qt.qpa.window");
+
 Q_DECLARE_TYPEINFO(xcb_rectangle_t, Q_PRIMITIVE_TYPE);
 
 #undef FocusIn
@@ -555,6 +557,7 @@ void QXcbWindow::destroy()
 }
 
 m_mapped = false;
+m_recreationReasons = RecreationNotNeeded;
 
 if (m_pendingSyncRequest)
 m_pendingSyncRequest->invalidate();
@@ -564,11 +567,6 @@ void QXcbWindow::setGeometry(const QRect )
 {
 QPlatformWindow::setGeometry(rect);
 
-if (shouldDeferTask(Task::SetGeometry)) {
-m_deferredGeometry = rect;
-return;
-}
-
 propagateSizeHints();
 
 QXcbScreen *currentScreen = xcbScreen();
@@ -693,10 +691,12 @@ void QXcbWindow::setVisible(bool visible)
 
 void QXcbWindow::show()
 {
-if (shouldDeferTask(Task::Map))
-return;
-
 if (window()->isTopLevel()) {
+if (m_recreationReasons != RecreationNotNeeded) {
+qCDebug(lcQpaWindow) << "QXcbWindow: need to recreate window" << window() << m_recreationReasons;
+create();
+m_recreationReasons = RecreationNotNeeded;
+}
 
 // update WM_NORMAL_HINTS
 propagateSizeHints();
@@ -746,10 +746,6 @@ void QXcbWindow::show()
 
 void QXcbWindow::hide()
 {
-if (shouldDeferTask(Task::Unmap))
-return;
-
-m_wmStateValid = false;
 xcb_unmap_window(xcb_connection(), m_window);
 
 // send synthetic UnmapNotify event according to icccm 4.1.4
@@ -909,9 +905,6 @@ QXcbWindow::NetWmStates QXcbWindow::netWmStates()
 
 void QXcbWindow::setWindowFlags(Qt::WindowFlags flags)
 {
-if (shouldDeferTask(Task::SetWindowFlags))
-return;
-
 Qt::WindowType type = static_cast(int(flags & Qt::WindowType_Mask));
 
 if (type == Qt::ToolTip)
@@ -919,6 +912,12 @@ void QXcbWindow::setWindowFlags(Qt::WindowFlags flags)
 if (type == Qt::Popup)
 flags |= Qt::X11BypassWindowManagerHint;
 
+Qt::WindowFlags oldflags = window()->flags();
+if ((oldflags & Qt::WindowStaysOnTopHint) != (flags & Qt::WindowStaysOnTopHint))
+m_recreationReasons |= WindowStaysOnTopHintChanged;
+if ((oldflags & Qt::WindowStaysOnBottomHint) != (flags & Qt::WindowStaysOnBottomHint))
+m_recreationReasons |= WindowStaysOnBottomHintChanged;
+
 const quint32 mask = XCB_CW_OVERRIDE_REDIRECT | XCB_CW_EVENT_MASK;
 const quint32 values[] = {
  // XCB_CW_OVERRIDE_REDIRECT
@@ -941,8 +940,6 @@ void QXcbWindow::setWindowFlags(Qt::WindowFlags flags)
 
 setTransparentForMouseEvents(flags & Qt::WindowTransparentForInput);
 updateDoesNotAcceptFocus(flags & Qt::WindowDoesNotAcceptFocus);
-
-m_isWmManagedWindow = !(flags & Qt::X11BypassWindowManagerHint);
 }
 
 void QXcbWindow::setMotifWmHints(Qt::WindowFlags flags)
@@ -1142,9 +1139,6 @@ void QXcbWindow::setWindowState(Qt::WindowStates state)
 if (state == m_windowState)
 return;
 
-if (shouldDeferTask(Task::SetWindowState))
-return;
-
 // unset old state
 if (m_windowState & Qt::WindowMinimized)
 xcb_map_window(xcb_connection(), m_window);
@@ -1894,10 +1888,6 @@ void QXcbWindow::handleUnmapNotifyEvent(const xcb_unmap_notify_event_t *event)
 if (event->window == m_window) {
 m_mapped = false;
 QWindowSystemInterface::handleExposeEvent(window(), QRegion());
-if (!m_isWmManagedWindow) {
-m_wmStateValid = true;
-handleDeferredTasks();
-}
 }
 }
 
@@ -2212,98 +2202,30 @@ void QXcbWindow::handleLeaveNotifyEvent(const xcb_leave_notify_event_t *event)
 handleLeaveNotifyEvent(event->root_x, event->root_y, event->mode, event->detail, event->time);
 }
 
-bool QXcbWindow::shouldDeferTask(Task task)
-{
-if (m_wmStateValid)
-return false;
-
-m_deferredTasks.append(task);
-return true;
-}
-
-void QXcbWindow::handleDeferredTasks()
-{
-Q_ASSERT(m_wmStateValid == true);
-if (m_deferredTasks.isEmpty())
-return;
-
-bool map = false;
-bool unmap = false;
-
-QVector tasks;
-for 

Bug#1022748: libqt5gui5: hide() + show() + hide() on a dialog frame hides it forever under X

[Alexander Kernozhitsky]

> After some testing, I determined that the bug is not present in
> 5.15.5+dfsg-3 but is present in 5.15.6+dfsg-1.

Control: tags -1 patch fixed-upstream
Control: found -1 5.15.6+dfsg-1
Control: notfound -1 5.15.5+dfsg-3

Okay, I have finally found the bug. It was introduced in the following commit:

https://github.com/qt/qtbase/commit/290b405872602de931646fe4f769eff208f9bbef

The fix is as follows:

https://github.com/qt/qtbase/commit/d27a6235246764bef1d61905ef96feeeddc65cd8
https://github.com/qt/qtbase/commit/f9e4402ffeef791e66b7b2f2cc332000df7f5cd4

Please consider adding this patch into Debian.

For convenience, I am attaching the cherry-picked patch that is needed to 
apply.

-- 
Alexander Kernozhitskydiff --git a/src/plugins/platforms/xcb/qxcbwindow.cpp b/src/plugins/platforms/xcb/qxcbwindow.cpp
index da179591e9..9acef9b5e9 100644
--- a/src/plugins/platforms/xcb/qxcbwindow.cpp
+++ b/src/plugins/platforms/xcb/qxcbwindow.cpp
@@ -93,6 +93,8 @@ enum {
 
 QT_BEGIN_NAMESPACE
 
+Q_LOGGING_CATEGORY(lcQpaWindow, "qt.qpa.window");
+
 Q_DECLARE_TYPEINFO(xcb_rectangle_t, Q_PRIMITIVE_TYPE);
 
 #undef FocusIn
@@ -555,6 +557,7 @@ void QXcbWindow::destroy()
 }
 
 m_mapped = false;
+m_recreationReasons = RecreationNotNeeded;
 
 if (m_pendingSyncRequest)
 m_pendingSyncRequest->invalidate();
@@ -564,11 +567,6 @@ void QXcbWindow::setGeometry(const QRect )
 {
 QPlatformWindow::setGeometry(rect);
 
-if (shouldDeferTask(Task::SetGeometry)) {
-m_deferredGeometry = rect;
-return;
-}
-
 propagateSizeHints();
 
 QXcbScreen *currentScreen = xcbScreen();
@@ -693,10 +691,12 @@ void QXcbWindow::setVisible(bool visible)
 
 void QXcbWindow::show()
 {
-if (shouldDeferTask(Task::Map))
-return;
-
 if (window()->isTopLevel()) {
+if (m_recreationReasons != RecreationNotNeeded) {
+qCDebug(lcQpaWindow) << "QXcbWindow: need to recreate window" << window() << m_recreationReasons;
+create();
+m_recreationReasons = RecreationNotNeeded;
+}
 
 // update WM_NORMAL_HINTS
 propagateSizeHints();
@@ -746,10 +746,6 @@ void QXcbWindow::show()
 
 void QXcbWindow::hide()
 {
-if (shouldDeferTask(Task::Unmap))
-return;
-
-m_wmStateValid = false;
 xcb_unmap_window(xcb_connection(), m_window);
 
 // send synthetic UnmapNotify event according to icccm 4.1.4
@@ -909,9 +905,6 @@ QXcbWindow::NetWmStates QXcbWindow::netWmStates()
 
 void QXcbWindow::setWindowFlags(Qt::WindowFlags flags)
 {
-if (shouldDeferTask(Task::SetWindowFlags))
-return;
-
 Qt::WindowType type = static_cast(int(flags & Qt::WindowType_Mask));
 
 if (type == Qt::ToolTip)
@@ -919,6 +912,12 @@ void QXcbWindow::setWindowFlags(Qt::WindowFlags flags)
 if (type == Qt::Popup)
 flags |= Qt::X11BypassWindowManagerHint;
 
+Qt::WindowFlags oldflags = window()->flags();
+if ((oldflags & Qt::WindowStaysOnTopHint) != (flags & Qt::WindowStaysOnTopHint))
+m_recreationReasons |= WindowStaysOnTopHintChanged;
+if ((oldflags & Qt::WindowStaysOnBottomHint) != (flags & Qt::WindowStaysOnBottomHint))
+m_recreationReasons |= WindowStaysOnBottomHintChanged;
+
 const quint32 mask = XCB_CW_OVERRIDE_REDIRECT | XCB_CW_EVENT_MASK;
 const quint32 values[] = {
  // XCB_CW_OVERRIDE_REDIRECT
@@ -941,8 +940,6 @@ void QXcbWindow::setWindowFlags(Qt::WindowFlags flags)
 
 setTransparentForMouseEvents(flags & Qt::WindowTransparentForInput);
 updateDoesNotAcceptFocus(flags & Qt::WindowDoesNotAcceptFocus);
-
-m_isWmManagedWindow = !(flags & Qt::X11BypassWindowManagerHint);
 }
 
 void QXcbWindow::setMotifWmHints(Qt::WindowFlags flags)
@@ -1142,9 +1139,6 @@ void QXcbWindow::setWindowState(Qt::WindowStates state)
 if (state == m_windowState)
 return;
 
-if (shouldDeferTask(Task::SetWindowState))
-return;
-
 // unset old state
 if (m_windowState & Qt::WindowMinimized)
 xcb_map_window(xcb_connection(), m_window);
@@ -1894,10 +1888,6 @@ void QXcbWindow::handleUnmapNotifyEvent(const xcb_unmap_notify_event_t *event)
 if (event->window == m_window) {
 m_mapped = false;
 QWindowSystemInterface::handleExposeEvent(window(), QRegion());
-if (!m_isWmManagedWindow) {
-m_wmStateValid = true;
-handleDeferredTasks();
-}
 }
 }
 
@@ -2212,98 +2202,30 @@ void QXcbWindow::handleLeaveNotifyEvent(const xcb_leave_notify_event_t *event)
 handleLeaveNotifyEvent(event->root_x, event->root_y, event->mode, event->detail, event->time);
 }
 
-bool QXcbWindow::shouldDeferTask(Task task)
-{
-if (m_wmStateValid)
-return false;
-
-m_deferredTasks.append(task);
-return true;
-}
-
-void QXcbWindow::handleDeferredTasks()
-{
-Q_ASSERT(m_wmStateValid == true);
-if (m_deferredTasks.isEmpty())
-return;
-
-bool map = false;
-bool unmap = false;
-
-QVector tasks;
-for 

Bug#1005309: RFS: runit-services/0.5.0 [ITP] -- UNIX init scheme with service supervision (services)

[Lorenzo]

New version that uses triggers of runit package is uploaded.


The source builds the following binary packages:

  runit-services - UNIX init scheme with service supervision (services)

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

  https://mentors.debian.net/package/runit-services/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.0.dsc

git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next


Regards,
Lorenzo

Bug#1022385: [Pkg-electronics-devel] Bug#1022385: pcb-rnd: FTBFS: diff: out.copper_p2.svg: No such file or directory

[Bdale Garbee]

Lucas Nussbaum  writes:

> Source: pcb-rnd
> Version: 3.0.5-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221023 ftbfs-bookworm
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks for the report!  The problem has been found and fixed by pcb-rnd
upstream, and will be included in the pcb-rnd 3.0.6 release, due in
about one week from now.  I'll plan to package that and upload it as
soon as it is released.

Bdale


signature.asc
Description: PGP signature

Bug#1019892: tftp-hpa: NMU 5.2+20150808-1.4

[Bastian Germann]

I have uploaded another NMU.diff -Nru tftp-hpa-5.2+20150808/debian/changelog 
tftp-hpa-5.2+20150808/debian/changelog
--- tftp-hpa-5.2+20150808/debian/changelog  2022-10-25 22:43:20.0 
+0200
+++ tftp-hpa-5.2+20150808/debian/changelog  2022-10-25 22:20:18.0 
+0200
@@ -1,3 +1,12 @@
+tftp-hpa (5.2+20150808-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Versioned Breaks and Replaces on tftp (Closes: #1022722).
+  * d/copyright: Drop the BSD advertisement clause.
+  * Move the package to 3.0 format.
+
+ -- Bastian Germann   Tue, 25 Oct 2022 22:20:18 +0200
+
 tftp-hpa (5.2+20150808-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tftp-hpa-5.2+20150808/debian/control 
tftp-hpa-5.2+20150808/debian/control
--- tftp-hpa-5.2+20150808/debian/control2022-10-25 22:43:20.0 
+0200
+++ tftp-hpa-5.2+20150808/debian/control2022-10-25 22:20:18.0 
+0200
@@ -1,6 +1,6 @@
 Source: tftp-hpa
 Section: net
-Priority: extra
+Priority: optional
 Maintainer: Ron Lee 
 Build-Depends: debhelper (>= 9), autoconf, autotools-dev, libwrap0-dev, 
po-debconf
 Standards-Version: 3.9.6.1
@@ -24,7 +24,6 @@
 
 Package: tftp-hpa-dbg
 Section: debug
-Priority: extra
 Architecture: linux-any kfreebsd-any
 Depends: tftp-hpa (= ${binary:Version}), tftpd-hpa (= ${binary:Version})
 Description: HPA's tftp (debug)
diff -Nru tftp-hpa-5.2+20150808/debian/copyright 
tftp-hpa-5.2+20150808/debian/copyright
--- tftp-hpa-5.2+20150808/debian/copyright  2022-10-25 22:43:20.0 
+0200
+++ tftp-hpa-5.2+20150808/debian/copyright  2022-10-25 22:20:18.0 
+0200
@@ -53,10 +53,7 @@
  2. Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and the following disclaimer in the
 documentation and/or other materials provided with the distribution.
- 3. All advertising materials mentioning features or use of this software
-must display the following acknowledgement:
-  This product includes software developed by the University of
-  California, Berkeley and its contributors.
+ 3. 
  4. Neither the name of the University nor the names of its contributors
 may be used to endorse or promote products derived from this software
 without specific prior written permission.
diff -Nru tftp-hpa-5.2+20150808/debian/patches/extern-sigjmp_buf.patch 
tftp-hpa-5.2+20150808/debian/patches/extern-sigjmp_buf.patch
--- tftp-hpa-5.2+20150808/debian/patches/extern-sigjmp_buf.patch
1970-01-01 01:00:00.0 +0100
+++ tftp-hpa-5.2+20150808/debian/patches/extern-sigjmp_buf.patch
2022-10-25 22:20:18.0 +0200
@@ -0,0 +1,11 @@
+--- tftp-hpa-5.2+20150808.orig/tftp/tftp.c
 tftp-hpa-5.2+20150808/tftp/tftp.c
+@@ -48,7 +48,7 @@
+ #define PKTSIZESEGSIZE+4
+ char ackbuf[PKTSIZE];
+ int timeout;
+-sigjmp_buf toplevel;
++extern sigjmp_buf toplevel;
+ sigjmp_buf timeoutbuf;
+ 
+ static void nak(int, const char *);
diff -Nru tftp-hpa-5.2+20150808/debian/patches/series 
tftp-hpa-5.2+20150808/debian/patches/series
--- tftp-hpa-5.2+20150808/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ tftp-hpa-5.2+20150808/debian/patches/series 2022-10-25 22:20:18.0 
+0200
@@ -0,0 +1 @@
+extern-sigjmp_buf.patch
diff -Nru tftp-hpa-5.2+20150808/debian/source/format 
tftp-hpa-5.2+20150808/debian/source/format
--- tftp-hpa-5.2+20150808/debian/source/format  1970-01-01 01:00:00.0 
+0100
+++ tftp-hpa-5.2+20150808/debian/source/format  2022-10-25 22:20:18.0 
+0200
@@ -0,0 +1 @@
+3.0 (quilt)
diff -Nru tftp-hpa-5.2+20150808/tftp/tftp.c tftp-hpa-5.2+20150808/tftp/tftp.c
--- tftp-hpa-5.2+20150808/tftp/tftp.c   2022-10-25 22:43:20.0 +0200
+++ tftp-hpa-5.2+20150808/tftp/tftp.c   2015-08-08 06:24:45.0 +0200
@@ -48,7 +48,7 @@
 #define PKTSIZESEGSIZE+4
 char ackbuf[PKTSIZE];
 int timeout;
-extern sigjmp_buf toplevel;
+sigjmp_buf toplevel;
 sigjmp_buf timeoutbuf;
 
 static void nak(int, const char *);

Bug#1019591: libpod: CVE-2022-2989

[Salvatore Bonaccorso]

Hi,

On Tue, Oct 25, 2022 at 03:41:12PM -0400, Antoine Beaupré wrote:
> fixed 101959 4.2.0+ds1-1
> thanks
> 
> > Please adjust the affected versions in the BTS as needed.
> 
> I *believe* the fix for this is:
> 
> https://github.com/containers/podman/pull/15696
> https://github.com/containers/podman/commit/21540161f20daffd884eba99b2cc31373c9a0ec4
> 
> at least that's what
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2121445
> 
> ... links to now.
> 
> So I *think* this is fixed in 4.2.0+ds1-1 and later, currently in
> experimental. But there's a bunch of confidential tickets on the redhat
> side of things, so it's not clear to me if the fix is complete or what.

But looking at the 4.2.0+ds1-3 it does not seem to be integrated
actually in 4.2.0 upstream, but rather probbly in a RHEL specific
branch tagged v4.2.0-rhel.

Upstream there is 

https://github.com/containers/podman/commit/5c7f28336171f0a5137edd274e45608120d31289
 (v4.3.0-rc1)

Regards,
Salvatore

Bug#1019416: Raising severity of remaining wxwidgets3.2 transition blockers

[Olly Betts]

severity 1019833 serious
thanks

(I raised the severity of most of these yesterday, but missed packages
where an upload to experimental has closed the bug while it's not yet
fixed in unstable.)

Accounting for packages which are fixed in experimental or in git we're
now under 30 packages left to do, so raising the severity to "serious".

Justification: https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Please start to investigate making this transition if you haven't already.
In most cases it's proving to be an easy update, but in minority of
cases where there are obstacles it's much better to find that out sooner
rather than later.

Cheers,
Olly

Bug#630086: reportbug does not sign attachments

[Daniel Kahn Gillmor]

Control: retitle 630086 reportbug does not sign attachments, headers, or 
pseudoheaders
Control: found 630086 11.5.1

On Fri 2011-06-10 10:16:12 -0700, Jameson Graef Rollins wrote:
> Package: reportbug
> Version: 5.1.1
> Severity: normal
>
> When using --gpg (or the "sign" config variable) reportbug is not
> signing attachments to the bug report.

In addition to this, the pseudoheaders and the message headers are also
not properly signed, which means that the signed message section itself
could be replayed against different packages, versions, or with a
different subject.  pseudoheaders and message headers are a critical
part of the message context.

For other problems with inline PGP signatures, see:

   https://dkg.fifthhorseman.net/blog/inline-pgp-considered-harmful.html
   
https://www.ietf.org/archive/id/draft-ietf-lamps-e2e-mail-guidance-03.html#name-avoiding-non-mime-cryptogra

Reportbug should use a PGP/MIME signature that covers all the essential
data of the message, rather than an inline signature.

Making matters worse, the signing code appears to pass an interpolated
string to os.system, which contains arbitrary text from the --keyid
option, which means shell metacharacters in --keyid will result in
arbitrary code execution.

Finally, rather than relying on /usr/bin/gpg or /usr/bin/pgp, reportbug
should be able to sign with any Stateless OpenPGP ("sop") implementation
(e.g. sqop, pgpainless-cli, gosop, or any other sop implementation that
we can land in debian) by indicating a path to the signing secret key
instead of a key ID.

  --dkg


signature.asc
Description: PGP signature

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Simon McVittie]

Package: libc6-dev
Version: 2.35-4
Severity: normal
X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, 
jrt...@debian.org
User: debian-m...@lists.debian.org
Usertags: mips mipsel

All mips*el executables and libraries appear to have an executable stack,
resulting in very large numbers of Lintian warnings, particularly for
packages with many small ELF objects like
.

Jessica Clarke looked into this and found that this is intentionally done
by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat:
https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143

Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably
doesn't need to go that far into backwards compatibility? If the mips
porters agree, then glibc on mips*el should stop forcing an executable
stack, either by increasing the minimal kernel version or by patching
this out. That will provide some security hardening on mips*el.

Or, if the mips porters consider this backwards compatibility to be
more important than the security hardening of a non-executable stack,
then Lintian should stop issuing warnings about the executable stack on
mips*el to improve its signal/noise ratio.

Thanks,
smcv

Bug#1022786: glirc: unsatisfiable build-dependency libghc-attoparsec-dev (<< 0.14)

[Ralf Treinen]

Source: glirc
Version: 2.36-3
Severity: serious

Hi,

glirc build-depends on libghc-attoparsec-dev (<< 0.14). However, the
current version of that package in sid is 0.14.4-2+b1.

-Ralf.

Bug#1022785: guacamole-client: build-depends on removed libangular-maven-plugin-java

[Ralf Treinen]

Source: guacamole-client
Version: 0.9.9+dfsg-1
Severity: serious

Hi, guacamole-client build-depends on libangular-maven-plugin-java but
that package only exists in oldoldstable.

-Ralf.

Bug#1022784: log4cplus: Enable LOG4CPLUS_QT5

[Bastian Germann]

Source: log4cplus
Severity: wishlist
Version: 2.0.8-1

Hi,

Would it be possible to enable LOG4CPLUS_QT5 in the build?

Thanks,
Bastian

Bug#1019591: libpod: CVE-2022-2989

[Antoine Beaupré]

fixed 101959 4.2.0+ds1-1
thanks

> Please adjust the affected versions in the BTS as needed.

I *believe* the fix for this is:

https://github.com/containers/podman/pull/15696
https://github.com/containers/podman/commit/21540161f20daffd884eba99b2cc31373c9a0ec4

at least that's what

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

... links to now.

So I *think* this is fixed in 4.2.0+ds1-1 and later, currently in
experimental. But there's a bunch of confidential tickets on the redhat
side of things, so it's not clear to me if the fix is complete or what.

a.
-- 
Power is always dangerous.
Power attracts the worst and corrupts the best.
- Edward Abbey

Bug#1022783: librust-curl-dev: impossible to install

[Daniel Kahn Gillmor]

Control: reassign 1022783 librust-spin-dev 0.9.4-1
Control: affects 1022783 + librust-curl-dev

On Tue 2022-10-25 21:28:38 +0200, Jonas Smedegaard wrote:
> Package is impossible to install:
>
> # apt install librust-curl-dev
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  librust-spin-dev : Depends: librust-portable-atomic-0.3-dev but it is not 
> installable
> E: Unable to correct problems, you have held broken packages.

I'm pretty sure this is about librust-spin-dev 0.9.4-1, not about
librust-curl-dev, because when i have librust-spin-dev 0.5.2-1
installed, librust-curl-dev 0.4.44-1 installs just fine.

   --dkg


signature.asc
Description: PGP signature

Bug#1022783: librust-curl-dev: impossible to install

[Jonas Smedegaard]

Package: librust-curl-dev
Version: 0.4.44-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package is impossible to install:

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

The following packages have unmet dependencies:
 librust-spin-dev : Depends: librust-portable-atomic-0.3-dev but it is not 
installable
E: Unable to correct problems, you have held broken packages.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNYOOYACgkQLHwxRsGg
ASHiOBAAngUhWWyarE2JMWL/ZaBQG40Iqfwe1h35ZYgsQa97twtFrB5ma1JQOKfi
uPGfHkHi0WClgB1ctIcAH0NNOBmdc9ELnhwMU+EyqX61aKypwFf6a5fz58vWOXar
DVU5CdnJQB9vUQthEbQjHeMuQLK+NtGnu84v+hKyIBLYty+CmPyejX5OdbgHrlG3
gbZAzg2kZUkOLlN12TwTc0pqM7Ggygd2E57vkjes3keBVI7DZhHtfcHlvoKdu2sP
bNvxZ/RWCECjMRhQn10zewvZ1FcpAPLp3Ach1dfHgBSkfY5yyJsBcOhzyCloVZed
YP+zbsONHFF4fvZYA4bR8R1Vuy9jIiijd707BnZHE+7GAbsx7zpswFL+2kZRRcIN
16BozXqsdh9iVKvs+ZI9VRFDQrAhrm8XH2dVrSyIvgKCDO3DTBd/tpz++N/A8QNb
iurtgtlEp1MfLrtqrl8Vg48VjX2D58Xhmsryf4c9uitX5VYtAm3bmfoS3Xw+2uk6
LRhCgs+nBgLUEG9Jok57ER8QbNPFVB/bux0BzgnjWFA4yXyKqmLY9f8i+yfguhF+
/htU8omX2t35Ww5OfVWc66+Beck706iZZrEcJPCTxv5g5Wn28TSF3YuNv+EpjTXZ
plLPeM4PvhZJ8HKninMMp5WAPoBeRrQGaNE10oIvSbA3AlvMGWo=
=PD+V
-END PGP SIGNATURE-

Bug#1022777: tpm2-pytss: please make the build reproducible

[Chris Lamb]

forwarded 1022777 https://github.com/tpm2-software/tpm2-pytss/pull/376
thanks

I've forwarded this upstream here:

  https://github.com/tpm2-software/tpm2-pytss/pull/376


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

While we wait for answers as to whether these dictionaries can be used by the 
Chromium package and how they might possibly be integrated with upstream 
Hunspell, I would recommend that we move forward with packaging them in /usr/
share/hunspell-bdic.  This location provides flexibility for whatever ends up 
happening with upstream Hunspell and Chromium.

The question at this point is if they should be generated at package creation 
or if they should be generated during install.  It appears that the majority 
leans towards generating them at package creation.  Is there anyone who feels 
strongly the other way?

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

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

Bug#1022782: python-transliterate: Failed autopkgtest: missing python3-six test-dep

[Boyuan Yang]

Source: transliterate
Version: 1.10.2-4
Tags: sid  bookworm
Severity: important

Dear Debian python-transliterate package maintainer,

Your package has an implicit autopkgtest test-dependency on python3-six, yet
it is not reflected in debian/tests/control. This caused autopkgtest
regression when python-pytest-conv is upgraded to 4.0.0-1 when the latter
one dropped indirect dependency on python3-six. It should be explicitly
added.

Thanks,
Boyuan Yang


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

Bug#1022781: Unable to lock an existing session

[martin f krafft]

Package: xautolock
Version: 1:2.2-7
Severity: critical
Tags: security

This is not software you can rely on to lock your screen:

```
lotus:~% xautolock -locknow
Could not locate a running xautolock.
lotus:~% ps aux | grep '[x]autolo'
madduck   172688  0.0  0.0   6584  2756 ?SOct23   0:34 xautolock 
-time 3 -locker exec /usr/bin/xsecurelock -notify 30 -notifier notify-send 
Locking the screen in 30 seconds
```

Strace didn't disclose any file the process might be looking for.

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

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

Versions of packages xautolock depends on:
ii  libc6 2.35-3
ii  libx11-6  2:1.8.1-2
ii  libxext6  2:1.3.4-1+b1
ii  libxss1   1:1.2.3-1

Versions of packages xautolock recommends:
pn  xtrlock | xscreensaver | i3lock | suckless-tools  

xautolock suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#961583: xfce4: `xfce4` package maybe needs `fonts-dejavu-core` as a dependancy

[Akbarkhon Variskhanov]

Control: tags -1 moreinfo

This is most likely not an Xfce-related problem. A similar bug was
reported in Ubuntu[1]. Please consider adding more information or the
full output.

[1] https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1592405

On Tue, 26 May 2020 10:42:30 + "Msd"  wrote:
> Package: xfce4
> Version: 4.12.5
> Severity: important
>
> Dear Maintainer,
>
> What led up to the situation?
>
> 1. Install Debian 10 without any graphical session
>
> 2. Install FreedomBox (useless ?)
>
> https://wiki.debian.org/FreedomBox/Hardware/Debian
>
> I imagine this step is useless to reproduce the problem but it is what I've 
> done before.
>
> 3. Install xfce4
>
> `apt install xfce4`
>
> fonts-dejavu-core is not installed.
>
> update-initramfs fails because 
> /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.tff does not exist
>
> Installing fonts-dejavu-core solves the problem.
>
> -- System Information:
> Debian Release: 10.4
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
> 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=fr_FR (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages xfce4 depends on:
> ii gtk2-engines-xfce 3.2.0-4
> ii libxfce4ui-utils 4.12.1-3
> ii thunar 1.8.4-1
> ii xfce4-appfinder 4.12.0-2
> ii xfce4-panel 4.12.2-1
> ii xfce4-pulseaudio-plugin 0.4.1-1
> ii xfce4-session 4.12.1-6
> ii xfce4-settings 4.12.4-1
> ii xfconf 4.12.1-1
> ii xfdesktop4 4.12.4-2
> ii xfwm4 4.12.5-1
>
> Versions of packages xfce4 recommends:
> ii desktop-base 10.0.2
> ii tango-icon-theme 0.8.90-7
> ii thunar-volman 0.9.1-1
> ii xfce4-notifyd 0.4.3-1
> ii xorg 1:7.7+19
>
> Versions of packages xfce4 suggests:

Bug#1022561: ftp.debian.org: lintian autorejects: add no-phrase

[Jakub Wilk]

FWIW, "no-phrase" was renamed from "maintainer-name-missing", and the 
latter is already on the list.


--
Jakub Wilk

Bug#1022780: libobject-remote-perl: FTBFS on various architectures: test failures

[Niko Tyni]

Package: libobject-remote-perl
Version: 0.004001-2
Severity: serious
Tags: ftbfs
User: debian-p...@lists.debian.org
Usertags: perl-5.36-transition

This package fails its test suite with Perl 5.36 on various architectures
including i386, armel, armhf and ppc64el. This also makes the package fail
to build from source on those architectures.

t/basic.t . 
Attempt to reload XSLoader.pm aborted.
Compilation failed in require at 
/usr/lib/arm-linux-gnueabi/perl-base/Cwd.pm line 79.
Compilation failed in require at 
/usr/lib/arm-linux-gnueabi/perl-base/File/Spec/Unix.pm line 4.
BEGIN failed--compilation aborted at 
/usr/lib/arm-linux-gnueabi/perl-base/File/Spec/Unix.pm line 4.
Compilation failed in require at 
/usr/lib/arm-linux-gnueabi/perl-base/File/Spec.pm line 20.
Compilation failed in require at 
/usr/share/perl5/Object/Remote/Connector/STDIO.pm line 3.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Object/Remote/Connector/STDIO.pm line 3.
Compilation failed in require at /usr/share/perl5/Object/Remote/Node.pm 
line 4.
BEGIN failed--compilation aborted at /usr/share/perl5/Object/Remote/Node.pm 
line 4.
Compilation failed in require at (eval 1) line 29966.
BEGIN failed--compilation aborted at (eval 1) line 29966.
Channel closed without seeing Shere: eof at 
/usr/share/perl5/Object/Remote/Future.pm line 46.
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run 

The reasons are fairly involved. Apologies for the wall of text.

Executive summary: it's a long standing hidden Debian specific bug due
to our Perl include path changes, somewhat accidentally mitigated on
amd64 and some other architectures, and now triggered on the others due
to an unrelated and innocent change in XSLoader.


As I understand it, the module spawns another Perl process either locally
or remotely and then sends it the code to run, including any necessary
non-core modules, so that nothing needs to be installed from CPAN on
the remote side.

Clearly this cannot work for architecture specific code if the remote
Perl process is running on a different architecture. So it looks like
arch specific modules are purposefully filtered away from the code bundle,
although I can't see this mentioned in the documentation.

Now, the first problem here is filtering away the core modules. This is
implemented by looking at loaded module filenames in %INC and matching
them for the core include directory ($Config{privlib}). Unfortunately
we have a Debian specific modification where /usr/bin/perl has the
directory /usr/lib//perl-base early on the search path with
a copy of part of the standard library [1], and the logic misses those
and considers them as non-core modules.


The above problem is mitigated on many architectures by the
check for arch specific modules, which matches the filename
against the known architecture specific directories in %Config
(archlib, vendorarch, sitearch), $Config{archname} (with values like
x86_64-linux-gnu-thread-multi or i686-linux-gnu-thread-multi-64int) and
$Config{myarchname} (with values like x86_64-linux or i686-linux). The
archname/myarchname part works (and is presumably intended) for the
module directory structure created by ExtUtils::MakeMaker and friends
for any extra include directories like ones managed with local::lib.

As mentioned, the perl-base modules live in /usr/lib//perl-base,
where  is the Debian "multiarch triplet" [2] with values
like x86_64-linux-gnu or i386-linux-gnu.  On architectures where
$Config{myarchname} happens to match the multiarch triplet, the perl-base
modules get filtered away as something of a side effect. This includes
the most common x86_64 architecture known in Debian as "amd64", but not
for instance the Debian "i386" or "armhf" architectures.


All of the above has been the case since 2015 or so when the perl-base
specific include path was introduced in Debian. It just hasn't caused any
visible problems until now; possibly the extra core modules in the code
bundle are not that architecture specific after all, and/or nobody just
uses a mix of different architectures or Perl versions with Object::Remote
(which sounds very probable.) Sending some extra core modules over has
apparently just caused a bit of unintended overhead.

The final straw that caused the regression with Perl 5.36 here is
that XSLoader started to 'use strict'. To see why, we need to look
at the code bundling (or "fatpacking") implementation a bit. This is
lib/Object/Remote/FatNode.pm and it creates a string of code that is
sent to the remote side where it gets eval'ed in. The code string is
a series of here documents each containing the code of one module.
These here documents are read into scalar Perl variables, turned into
in-memory file handles [3], and eventually processed by 'require'. The
in-memory handles need PerlIO::Scalar behind the scenes, which needs
XSLoader.pm, which now needs strict.pm.

So when strict.pm is 

Bug#1022779: dosbox: could dosbox-x be a future to dosbox?

[Patrice Duroux]

Package: dosbox
Version: 0.74-3-4+b1
Severity: wishlist

Dear Maintainer,

The dosbox-x project (https://dosbox-x.com/) is currently version 0.84.3
(2022.09.0)
and seems to be SDL 2 compatible.
Have you tried it?

Thanks,
Patrice


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

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

Versions of packages dosbox depends on:
ii  libasound2   1.2.7.2-1
ii  libc62.35-4
ii  libgcc-s112.2.0-7
ii  libgl1   1.5.0-1
ii  libpng16-16  1.6.38-2
pn  libsdl-net1.2
pn  libsdl-sound1.2  
pn  libsdl1.2debian  
ii  libstdc++6   12.2.0-7
ii  libx11-6 2:1.8.1-2
ii  zlib1g   1:1.2.11.dfsg-4.1

dosbox recommends no packages.

dosbox suggests no packages.

-- no debconf information

Bug#1022209: diffoscope: highlight text-only differences in HTML files

[Chris Lamb]

forwarded 1022209 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/318
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/318


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1022210: diffoscope: highlight whitespace-only differences in text data

[Chris Lamb]

forwarded 1022210 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/319
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/319


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#989626: diffoscope: when comparing fonts with .ttx files, convert the font to .ttx first

[Chris Lamb]

forwarded 989626 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/315
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/315


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1022146: diffoscope: detect ordering-only differences in XML files

[Chris Lamb]

forwarded 1022146 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/317
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/317


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1022145: diffoscope: detect ordering-only differences in text files

[Chris Lamb]

forwarded 1022145 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/316
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/316


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1022778: samba: Upgrade failed: unhandled file move /etc/pam.d/samba both in samba and samba-common

[Boyuan Yang]

Package: samba
Severity: grave
Version: 2:4.16.6+dfsg-2
X-Debbugs-CC: m...@tls.msk.ru

Dear Debian samba maintainers,

The following dpkg error will occur when upgrading samba to 2:4.16.6+dfsg-2
from 2:4.16.5+dfsg-2+b1:

...
Preparing to unpack .../samba_2%3a4.16.6+dfsg-2_amd64.deb ...
Unpacking samba (2:4.16.6+dfsg-2) over (2:4.16.5+dfsg-2+b1) ...
dpkg: error processing archive
/var/cache/apt/archives/samba_2%3a4.16.6+dfsg-2_amd64.deb (--unpack):
 trying to overwrite '/etc/pam.d/samba', which is also in package samba-
common 2:4.16.6+dfsg-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
...

I believe piuparts will also report this problem shortly. Please consider
fixing it. Thanks!


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

Bug#1022777: tpm2-pytss: please make the build reproducible

[Chris Lamb]

Source: tpm2-pytss
Version: 1.2.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
tpm2-pytss could not be built reproducibly.

This is because it embedded the current "build" year by calling out
to datetime.datetime.utcnow() when building the documentation. 

Patch attached that seeds this value from SOURCE_DATE_EPOCH if it
exists in the surrounding environment.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2022-10-25 10:32:58.818873778 
-0700
@@ -0,0 +1,26 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2022-10-25
+
+--- tpm2-pytss-1.2.0.orig/docs/conf.py
 tpm2-pytss-1.2.0/docs/conf.py
+@@ -12,6 +12,7 @@
+ #
+ import os
+ import sys
++import time
+ import datetime
+ import subprocess
+ 
+@@ -57,7 +58,10 @@ import tpm2_pytss
+ 
+ project = "tpm2-pytss"
+ author = "tpm2-software"
+-copyright = f"2019 - {datetime.datetime.today().year}, {author}"
++build_date = datetime.datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++)
++copyright = f"2019 - {build_date.year}, {author}"
+ 
+ # The short X.Y version
+ version = get_version(root="..", relative_to=__file__)
--- a/debian/patches/series 2022-10-25 10:25:20.122542133 -0700
--- b/debian/patches/series 2022-10-25 10:32:57.862874412 -0700
@@ -1 +1,2 @@
 debian-hacks/docs-Use-internal-ressources-for-intersphinx.patch
+reproducible-build.patch

Bug#943367: light-locker shows only the cursor on a black screen after unlocking

[Akbarkhon Variskhanov]

Control: tags -1 moreinfo

Could be related to #896925. In any case, more info (such as logs in
~/.xsession-errors) would be helpful.

Bug#1019425: dkms 3.0.6-2 not signing modules

[Holger Schröder]

Hi.

I have found the problem why it does not work. It is because of this line:


eval '"$sign_file" sha512 "$mok_signing_key" "$mok_certificate"
"$built_module"'


Here I get hash_algo sha512 signed which doesn't work on my box and my
laptop. If I change this to sha256 secure-boot works as desired. Why
this is so I can not say, this is beyond my knowledge. Also if this is a
bug or not I can't say.

Sorry for my crap english :-)


Cheers Holger...

Bug#1022775: [Pkg-samba-maint] Bug#1022775: samba: breaks apt upgrade

[Michael Tokarev]

Control: tag -1 + confirmed pending
Control: severity -1 serious

25.10.2022 19:59, Nicolas Patrois wrpte:
...

  tentative de remplacement de « /etc/pam.d/samba », qui appartient aussi au
paquet samba-common 2:4.16.6+dfsg-2


wug.  Fixing it. I wonder how it happened to escape
my local installation?..

/mjt

Bug#1022776: samba: unable to upgarde to 2:4.16.6+dfsg-2

[Patrice Duroux]

Package: samba
Version: 2:4.16.6+dfsg-2
Severity: normal

Dear Maintainer,

Here is the output:

# apt install samba
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  samba-dsdb-modules
Suggested packages:
  bind9 bind9utils ctdb ldb-tools ntp | chrony smbldap-tools ufw
The following NEW packages will be installed:
  samba samba-dsdb-modules
0 upgraded, 2 newly installed, 0 to remove and 2 not upgraded.
Need to get 1 616 kB of archives.
After this operation, 19,6 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 https://deb.debian.org/debian sid/main amd64 samba amd64 2:4.16.6+dfsg-2
[1 313 kB]
Get:2 https://deb.debian.org/debian sid/main amd64 samba-dsdb-modules amd64
2:4.16.6+dfsg-2 [303 kB]
Fetched 1 616 kB in 0s (7 991 kB/s)
Selecting previously unselected package samba.
(Reading database ... 571037 files and directories currently installed.)
Preparing to unpack .../samba_2%3a4.16.6+dfsg-2_amd64.deb ...
Unpacking samba (2:4.16.6+dfsg-2) ...
dpkg: error processing archive
/var/cache/apt/archives/samba_2%3a4.16.6+dfsg-2_amd64.deb (--unpack):
 trying to overwrite '/etc/pam.d/samba', which is also in package samba-common
2:4.16.6+dfsg-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Selecting previously unselected package samba-dsdb-modules:amd64.
Preparing to unpack .../samba-dsdb-modules_2%3a4.16.6+dfsg-2_amd64.deb ...
Unpacking samba-dsdb-modules:amd64 (2:4.16.6+dfsg-2) ...
Errors were encountered while processing:
 /var/cache/apt/archives/samba_2%3a4.16.6+dfsg-2_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


Thanks,
Patrice


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

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

Versions of packages samba depends on:
ii  adduser3.129
ii  init-system-helpers1.65.2
ii  libbsd00.11.7-1
ii  libc6  2.35-4
ii  libcups2   2.4.2-1+b2
ii  libgnutls303.7.8-2
ii  libldap-2.5-0  2.5.13+dfsg-2+b1
ii  libldb22:2.5.2+samba4.16.6-2
ii  libpam-modules 1.5.2-5
ii  libpam-runtime 1.5.2-5
ii  libpopt0   1.19+dfsg-1
ii  libtalloc2 2.3.4-1
ii  libtasn1-6 4.19.0-2
ii  libtdb11.4.7-1
ii  libtevent0 0.13.0-1
ii  procps 2:3.3.17-7.1
ii  python33.10.6-1
ii  python3-dnspython  2.2.1-2
ii  python3-samba  2:4.16.6+dfsg-2
ii  samba-common   2:4.16.6+dfsg-2
ii  samba-common-bin   2:4.16.6+dfsg-2
ii  samba-libs 2:4.16.6+dfsg-2
ii  sysvinit-utils [lsb-base]  3.05-6
ii  tdb-tools  1.4.7-1

Versions of packages samba recommends:
ii  attr1:2.5.1-1
ii  logrotate   3.20.1-1+b1
ii  python3-markdown3.4.1-2
iu  samba-dsdb-modules  2:4.16.6+dfsg-2
ii  samba-vfs-modules   2:4.16.6+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
pn  ntp | chrony   
pn  smbldap-tools  
pn  ufw
ii  winbind2:4.16.6+dfsg-2

Bug#1022775: samba: breaks apt upgrade

[Nicolas Patrois]

Package: samba
Version: 2:4.16.5+dfsg-2+b1
Severity: normal

Dear Maintainer,

The last upgrade of samba breaks the apt upgrade.
The following lines are in French but they might be understandable.
"apt remove samba" fails as well.

# apt --fix-broken install
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Correction des dépendances... Fait
Les paquets supplémentaires suivants seront installés :
  samba
Paquets suggérés :
  bind9 bind9utils ctdb ldb-tools smbldap-tools
Paquets recommandés :
  samba-dsdb-modules
Les paquets suivants seront mis à jour :
  samba
1 mis à jour, 0 nouvellement installés, 0 à enlever et 2 non mis à jour.
25 partiellement installés ou enlevés.
Il est nécessaire de prendre 1 370 ko dans les archives.
Après cette opération, 5 120 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n]
Réception de :1 http://ftp.fr.debian.org/debian unstable/main i386 samba i386
2:4.16.6+dfsg-2 [1 370 kB]
1 370 ko réceptionnés en 1s (2 324 ko/s)
Récupération des rapports de bogue… Fait
Analyse des informations Trouvé/Corrigé… Fait
(Lecture de la base de données... 987782 fichiers et répertoires déjà
installés.)
Préparation du dépaquetage de .../samba_2%3a4.16.6+dfsg-2_i386.deb ...
Dépaquetage de samba (2:4.16.6+dfsg-2) sur (2:4.16.5+dfsg-2+b1) ...
dpkg: erreur de traitement de l'archive
/var/cache/apt/archives/samba_2%3a4.16.6+dfsg-2_i386.deb (--unpack) :
 tentative de remplacement de « /etc/pam.d/samba », qui appartient aussi au
paquet samba-common 2:4.16.6+dfsg-2
dpkg-deb: erreur: coller subprocess was killed by signal (Relais brisé (pipe))
Samba is not being run as an AD Domain Controller: Masking samba-ad-dc.service
Please ignore the following error about deb-systemd-helper not finding those
services.
WARNING samba-ad-dc.service should be masked. The install may fail.
insserv: warning: current start runlevel(s) (empty) of script `nmbd' overrides
LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `nmbd'
overrides LSB defaults (0 1 6).
nmbd.service is a disabled or a static unit not running, not starting it.
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 145.
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/samba_2%3a4.16.6+dfsg-2_i386.deb
update-alternatives: utilisation de « /usr/bin/firefox-esr » pour fournir
« /usr/bin/x-www-browser » (x-www-browser) en mode manuel
update-alternatives: utilisation de « /usr/bin/iceweasel » pour fournir
« /usr/bin/x-www-browser » (x-www-browser) en mode manuel
update-alternatives: avertissement: création de /usr/share/man/man1/x-www-
browser.1.gz abandonnée car le fichier associé
/usr/share/man/man1/iceweasel.1.gz (du groupe de liens x-www-browser) n'existe
pas
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf present, but not attached

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

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

Versions of packages samba depends on:
ii  adduser3.129
ii  init-system-helpers1.65.2
ii  libbsd00.11.7-1
ii  libc6  2.35-4
ii  libcups2   2.4.2-1+b2
ii  libgnutls303.7.8-2
ii  libldap-2.5-0  2.5.13+dfsg-2+b1
iu  libldb22:2.5.2+samba4.16.6-2
ii  libpam-modules 1.5.2-5
ii  libpam-runtime 1.5.2-5
ii  libpopt0   1.19+dfsg-1
ii  libtalloc2 2.3.4-1
ii  libtasn1-6 4.19.0-2
ii  libtdb11.4.7-1
ii  libtevent0 0.13.0-1
ii  procps 2:3.3.17-7.1
ii  python33.10.6-1
ii  python3-dnspython  2.2.1-2
iu  python3-samba  2:4.16.6+dfsg-2
iu  samba-common   2:4.16.6+dfsg-2
iu  samba-common-bin   2:4.16.6+dfsg-2
iu  samba-libs 2:4.16.6+dfsg-2
ii  sysvinit-utils [lsb-base]  3.05-6
ii  tdb-tools  1.4.7-1

Versions of packages samba recommends:
ii  attr1:2.5.1-1
ii  logrotate   3.20.1-1+b1
ii  python3-markdown3.4.1-2
pn  samba-dsdb-modules  
iu  samba-vfs-modules   2:4.16.6+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p15+dfsg-2~1.2.1+dfsg1-8
pn  smbldap-tools  
ii  ufw0.36.1-4.1
iu  winbind

Bug#1022704: ccache: broken in cross-architecture chroot

[Raphaël Halimi]

Le 25/10/2022 à 18:40, Joel Rosdahl a écrit :

Thanks!

Now I understand the problem and will work on a fix.

The issue is sharing the inode cache file between architectures. A workaround is
to either use separate temporary directories for the architectures (or different
cache directories when the temporary directory defaults to the cache directory,
which is the case for you), or to disable the inode cache by setting

 inode_cache = false

in the config file.


Hi,

I'm glad I could help you despite my lack of knowledge in this area.

I confirm that disabling the inode cache does work, I'll use this 
workaround while waiting for a fixed version to be released. Thanks !


Regards,

--
Raphaël Halimi

Bug#1022766: dpkg-shlibdeps: repeatedly emits duplicate warnings

[Guillem Jover]

Hi!

On Tue, 2022-10-25 at 14:23:18 +0200, Andreas Beckmann wrote:
> Package: dpkg-dev
> Version: 1.21.9
> Severity: normal

> While checking the nvida-cuda-toolkit buildd logs [1], I came across a
> long sequence of repeated error messages:
> 
> pkg-shlibdeps: warning: can't extract name and version from library name 
> 'libfoobar.so'
> 
> There are about 40 repetitions of this warning (with no further messages
> interleaved) for most of the libraries, but I don't know what this
> number corresponds to.
> Since nvida-cuda-toolkit just repacks upstream binary libraries we
> unfortunately have to cope with a lot of libraries without proper sonames.

> [1] https://buildd.debian.org/status/package.php?p=nvidia-cuda-toolkit

Ah, I guess something like the attached patch might do? In addition to
somewhat improving performance. :)

Thanks,
Guillem
From 12e690ec338d7ba2e808ae7f6ba7c31e060b0e8e Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 25 Oct 2022 18:36:16 +0200
Subject: [PATCH] dpkg-shlibdeps: Cache soname check against shlibs files

Closes: #1022766
---
 scripts/dpkg-shlibdeps.pl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/dpkg-shlibdeps.pl b/scripts/dpkg-shlibdeps.pl
index 6c8a2d3ab..47e79ca13 100755
--- a/scripts/dpkg-shlibdeps.pl
+++ b/scripts/dpkg-shlibdeps.pl
@@ -172,7 +172,8 @@ my %global_soname_notfound;
 my %global_soname_used;
 my %global_soname_needed;
 
-# Symfile and objdump caches
+# Shlibs, Symfile and objdump caches
+my %shlibs_cache;
 my %symfile_cache;
 my %objdump_cache;
 my %symfile_has_soname_cache;
@@ -721,6 +722,10 @@ sub split_soname {
 sub extract_from_shlibs {
 my ($soname, $shlibfile) = @_;
 
+if (exists $shlibs_cache{$shlibfile}{$soname}) {
+return $shlibs_cache{$shlibfile}{$soname};
+}
+
 my $shlibs_re = qr{
 ^\s*
 (?:(\S+):\s+)?  # Optional type
@@ -738,6 +743,7 @@ sub extract_from_shlibs {
 unless (defined $libname) {
 	warning(g_("can't extract name and version from library name '%s'"),
 	$soname);
+$shlibs_cache{$shlibfile}{$soname} = undef;
 	return;
 }
 # Open shlibs file
@@ -769,6 +775,7 @@ sub extract_from_shlibs {
 	}
 }
 close($shlibs_fh);
+$shlibs_cache{$shlibfile}{$soname} = $dep;
 return $dep;
 }
 
-- 
2.37.2

Bug#1022774: ITP: itinerary -- Digital travel assistant protecting your privacy

[Hefee]

Package: wnpp
Severity: wishlist
Owner: Hefee 
X-Debbugs-Cc: debian-de...@lists.debian.org, he...@debian.org

* Package name: itinerary
  Version : 22.08.2
  Upstream Author : Volker Krause 
* URL : https://invent.kde.org/pim/itinerary
* License : LGPL-2.0+
  Programming Lang: C++ with Qt and QML
  Description : Digital travel assistant protecting your privacy

 Getting your itinerary presented in a unified, well structured and always up
 to date fashion rather than advertisement overloaded HTML email monstrosities
 or countless vendor-specific apps.

It will be maintained under the Debian Qt/KDE Maintainers Team’s
umbrella.

Bug#1022773: [fetchmail] corruption of email with base64 encoding

[Bas Vermulst]

Package: fetchmail

Version: 6.4.0.beta4

 
Summary:

I use fetchmail to get emails from a few servers. These emails are then parsed 
by kopano-dagent. Some emails from some senders got corrupted consistently, and 
I’ve tracked the issue down to fetchmail corrupting long single-line base64 
strings by inserting invalid characters NUL and ETX.

 
Detailed description:

For base64-encoded emails that were not sent with a character limit for each 
line, Fetchmail will insert characters NUL and ETX if the line becomes 
sufficiently long (it does trigger around 1 characters per line or so), and 
then insert a line break. This, consecutively, breaks the email parsing by 
kopano-dagent, which throws an error when it sees NUL (0x) and ETX (0x0003) 
in the base64-encoded string – which is a valid error, since those are not 
base64 string characters. This also holds for attachments in base64-encoding, 
which will break.

 
Of course, the error is effectively triggered by non-compliant senders who do 
not terminate lines after a reasonable number of characters. This doesn’t mean 
these messages should be corrupted, especially for a simple solution like 
correctly inserting line breaks without adding erroneous characters.

 
Proposed solution:

do not insert line breaks (probably meaning the buffer size should increase)

-or-

ensure line breaks are correctly inserted for base64 encoded messages after a 
reasonable amount of characters

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

Thanks!

Now I understand the problem and will work on a fix.

The issue is sharing the inode cache file between architectures. A workaround is
to either use separate temporary directories for the architectures (or different
cache directories when the temporary directory defaults to the cache directory,
which is the case for you), or to disable the inode cache by setting

inode_cache = false

in the config file.

Regards,
Joel

Bug#1021292: Enabling branch protection on amd64 and arm64

[Wookey]

On 2022-10-25 16:10 +0100, Simon McVittie wrote:
> On Tue, 25 Oct 2022 at 15:34:26 +0100, Wookey wrote:
> > These are hardware features (new instructions) that 'tag' pointers and
> > branch targets to make it much harder for malicious code to implement
> > ROP (return oriented programming) and JOP (Jump oriented programming)
> > attacks.
> > 
> > They have been implemented on both architectures in such a way that
> > they can be generally enabled and are simply ignored on hardware that
> > doesn't support them (the new instructions are in the NOP space). 
> 
> Does this have the same restrictions as CET, which gcc briefly enabled
> on x86 by default, but had to roll back[1] and later enable on a smaller
> subset of architectures[2], because the new instructions are only NOPs
> on x86_64 and modern i386, and are non-baseline (illegal instruction)
> on older or more-embedded i386 like the ones in our current i386 baseline?

I'm not sure (I know a lot more about the arm64 side of this than the
amd64 side), but we are only enabling this on amd64, not i386. amd64
binaries don't run on i386 so I don't think any practical issue
actually arises. You have reminded me that I guess it should be turned
on for x32 too.

> If yes, we'll have to be careful to only enable this on architectures
> where our baseline allows it. IIRC, Geode and VIA CPUs are the ones that
> usually cause trouble for i386.

Right, and that's the plan.

The patch looks approx like this:
+# Branch protection
+if ($use_feature{hardening}{branch}) {
+my $flag;
+if ($cpu eq 'arm64') {
+$flag = '-mbranch-protection=standard';
+} elsif ($cpu eq 'amd64') {
+$flag = '-fcf-protection';
+}
+$flags->append($_, $flag) foreach @compile_flags;
+}

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1022348: gpgme1.0: FTBFS: Could not find gpg-error-config. Please install the libgpg-error development package.

[Andreas Metzler]

Control: forwarded -1 https://dev.gnupg.org/T6204

On 2022-10-23 Lucas Nussbaum  wrote:
> Source: gpgme1.0
> Version: 1.18.0-1
[...]
> > Could not find gpg-error-config.  Please install the libgpg-error 
> > development package.
> > make[4]: *** [Makefile:760: all-local] Error 1
[...]

There is a patch in upstream GIT ae9258fbf3b9d434495ef11fc184a91fe7c4ca57 but
it breaks when @GPG_ERROR_CFLAGS@ expands to nothing which happens on
Debian.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#941930: smbclient: protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX with maxprotocol=NT1

[Michael Tokarev]

Control: tag -1 + confirmed upstream
Control: found -1 2:4.17.2+dfsg-1
Control: found -1 2:4.16.6+dfsg-2

On Mon, 07 Oct 2019 19:13:12 +0200 luca  wrote:

Package: smbclient
Version: 2:4.11.0+dfsg-10
Severity: normal

Dear Maintainer,

after update in testing of samba pkgs version 2:4.11.0+dfsg-10 maxprotocol=NT1
seems no more working as aspected

--
$ smbclient 192.168.0.101\\tmp
Unable to initialize messaging context
Enter BDEV\ilprof's password:
Try "help" to get a list of possible commands.
smb: \>
--

but with maxprotocol=NT1

--
$ smbclient 192.168.0.101\\tmp -m NT1
Unable to initialize messaging context
protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX
--


This seems to be a problem with command-line parameter parsing of smbclient,
or parameter logic.

In man smb.conf, there's "client min protocol" parameter, which is SMB2_02
in current version (4.16) of samba.  And smbclient has its own option,
-m, or --max-protocol, which is used here.

It looks like smbclient *might* error out at least in case min protocol is
larger than the specified max protocol.  Or better yet, fix min protocol to
be the same as max protocol in this case (unless it is explicitly set in
the smb.conf file).

In order for smbclient to actually use NT1 protocol, one have to also specify
"client min prococol = NT1" - either in smb.conf or in additional --option
command-line option.

I dunno why upstream did it this way - either by design, or it wasn't intended
to be this way.

Let's ask upstream..

/mjt

Bug#1022772: 1.4.9+dfsg-2

[Nilesh Patra]

Source: btllib
Version: 1.4.9+dfsg-1
Severity: important
Control: forwarded -1 https://github.com/bcgsc/btllib/issues/62

Hi,

btllib fails to build on i386, this affects nthash which B-D
on it.


https://buildd.debian.org/status/fetch.php?pkg=btllib=i386=1.4.9%2Bdfsg-2=121292=0

Thanks!

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

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

Bug#1021292: Enabling branch protection on amd64 and arm64

[Simon McVittie]

On Tue, 25 Oct 2022 at 15:34:26 +0100, Wookey wrote:
> These are hardware features (new instructions) that 'tag' pointers and
> branch targets to make it much harder for malicious code to implement
> ROP (return oriented programming) and JOP (Jump oriented programming)
> attacks.
> 
> They have been implemented on both architectures in such a way that
> they can be generally enabled and are simply ignored on hardware that
> doesn't support them (the new instructions are in the NOP space). 

Does this have the same restrictions as CET, which gcc briefly enabled
on x86 by default, but had to roll back[1] and later enable on a smaller
subset of architectures[2], because the new instructions are only NOPs
on x86_64 and modern i386, and are non-baseline (illegal instruction)
on older or more-embedded i386 like the ones in our current i386 baseline?

If yes, we'll have to be careful to only enable this on architectures
where our baseline allows it. IIRC, Geode and VIA CPUs are the ones that
usually cause trouble for i386.

Of course, raising the i386 baseline would mitigate or solve that, at the
cost of dropping support for some CPUs.

[1] 
https://tracker.debian.org/news/1254900/accepted-gcc-11-1120-4-source-into-unstable/
[2] 
https://tracker.debian.org/news/1256872/accepted-gcc-11-1120-5-source-into-unstable/

smcv

Bug#1022771: glibc: FTBFS on hppa - malloc/tst-scratch_buffer fails with gcc-12

[John David Anglin]

Source: glibc
Version: 2.34-3
Severity: normal
Tags: ftbfs

Dear Maintainer,

The malloc/tst-scratch_buffer test fails with gcc-12:

+-+
| Encountered regressions that don't match expected failures. |
+-+
FAIL: malloc/tst-scratch_buffer

--
FAIL: malloc/tst-scratch_buffer
original exit status 1
tst-scratch_buffer.c:167: error: blob comparison failed
  blob length: 1040 bytes
  left (evaluated from r):
  
"\000\000\000\020\000\000\004\000\000\000\004\020A>\005\230"
  40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 
40 40 40 40 40 40 40 40 40 40 40 40 00 00 00 10 00 00 04 00 00 00 04 10 41 3E 
05 98
  right (evaluated from buf.data):
  

Bug#1022770: ITP: ruby-omniauth-rails-csrf-protection -- A gem that provides CSRF protection on OmniAuth request endpoint on Rails application.

[Abraham Raji]

package: wnpp
Severity: wishlist
Owner: Abraham Raji 

*Package Name  : ruby-omniauth-rails-csrf-protection
 Version   : 1.0.1
 Upstream Author   : Cookpad Inc.
*URL   : 
https://github.com/cookpad/omniauth-rails_csrf_protection

*License   : Expat
 Programming Lang  : Ruby
*Description   : A gem that provides CSRF protection on OmniAuth 
request endpoint on Rails application.


This gem provides a mitigation against [CVE-2015-9284] (Cross-Site 
Request Forgery on the request phase when using OmniAuth gem with a Ruby 
on Rails application) by implementing a CSRF token verifier that 
directly uses ActionController::RequestForgeryProtection code from Rails.


.

This gem is required for the gitlab 15.4.0 update.

- Abraham


OpenPGP_0xF67DA33EE71DFDA9.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022174: closed by Debian FTP Masters (reply to Andreas Beckmann ) (Bug#1021974: fixed in nvidia-graphics-drivers-tesla-470 470.141.03-3)

[mh]

Am Mon, 24 Oct 2022 16:24:08 +
schrieb "Debian Bug Tracking System" :

> This is an automatic notification regarding your Bug report
> which was filed against the src:nvidia-graphics-drivers-tesla-470
> package:
>
> #1022174: linux-image-6.0.0-1-amd64: nvidia 470 modul builds
> successfully, but does not get loaded on boot -> no X
>
> It has been closed by Debian FTP Masters
>  (reply to Andreas Beckmann
> ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP
> Masters  (reply to Andreas Beckmann
> ) by replying to this email.
>
>

Confirmed. New Version solves the problem.

Bug#1021292: Enabling branch protection on amd64 and arm64

[Wookey]

I have been in discussion with Guillem about enabling the various
branch protection mechanisms available on newer x86 and arm CPUs.

These are hardware features (new instructions) that 'tag' pointers and
branch targets to make it much harder for malicious code to implement
ROP (return oriented programming) and JOP (Jump oriented programming)
attacks.

They have been implemented on both architectures in such a way that
they can be generally enabled and are simply ignored on hardware that
doesn't support them (the new instructions are in the NOP space). 

These features have been enabled in other distros for some time and
we've done an archive rebuild of arm64 to check that there was not
significant breakage. 

There is a lot of discussion of the details of this and the pros/cons
of enabling this by default in the thread so I will try to keep this
mail as a summary and suggest you go read
https://lists.debian.org/debian-dpkg/2022/05/msg00022.html
and https://lists.debian.org/debian-dpkg/2022/06/msg0.html
if you want to know how it works, and all the details.

We decided that the best thing to do was create a new hardening flags
feature called 'branch' to add to the existing set. This enables
-mbranch-protection=standard on arm64, and
-fcf-protection on amd64
(yes it would have been nice if the gcc people had used common flags across the 
arches, but there you go)
If/when other arches get similar functionality those would be enabled under 
this heading too
(Are there any already that I don;t know about?)

There is a dpkg branch containing this feature here:
https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/dpkg-buildflags-feature-branch

And a bug to track progress here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021292

So the immediate issue now is whether or not to enable this by default
in bookworm?  It's a significant protection on newish hardware, which
those who've worked on it (and I now, having investigated) believe
should be on by default. We have a general policy of enabling
reaosnably low-cost security features by default, and this is one of
those. It's a fairly low-risk thing to do, especially as others have
gone before us (Rhel made -fcf-protection the gcc default in 2018, and
Suse in Oct 2021. Suse turned on branch-protection=standard (ie
BTI+PAC) on arm64 in nov 2020), but it is changing the defaults.

Like all dpkg-buildflags it can easily be disabled for a particular
package and there is a kernel option to turn it off on a particular
machine if issues are encountered (and no doubt we will find a couple).

I hope that all makes sense.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1022769: debian-debug: incomplete Contents-* files

[Jakub Wilk]

Package: ftp.debian.org

The Contents-* files in the unstable-debug suite are tiny:

   $ curl -s 
http://debug.mirrors.debian.org/debian-debug/dists/unstable-debug/main/Contents-amd64.gz
 | zcat | wc -l
   497

I'm pretty sure sure there's a lot more files in -dbgsym packages.

--
Jakub Wilk

Bug#1022767: samba: Should not build-depend on librados-dev on ppc64 and x32

[Michael Tokarev]

Control: tag -1 + moreinfo unreproducible

25.10.2022 16:41, John Paul Adrian Glaubitz wrote:

Source: samba
Version: 2:4.16.6+dfsg-2
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi!

After ceph support was disabled on ppc64 and x32 as requested in #1012165
and #1020781, there is still a dependency on librados-dev left in debian/
control for ppc64 and x32.


Hmm.

Just-uploaded 2:4.16.6+dfsg-2 has this in d/control:

$ egrep 'libceph|librados)' debian/control
libcephfs-dev [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el 
s390x],
librados-dev [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el 
s390x],

There's no x32 or ppc64.

Or do you mean ppc64el should be removed *too*?

I know nothing about variants of powerpc. And I don't see buildds in Debian
doing builds for ppc64el. At least it is not shown on usual build status
pages.  What exactly is failing for you?

Thanks,

/mjt

Bug#1022768: nmu: libgdal-grass_1:1.0.1-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org

nmu libgdal-grass_1:1.0.1-1 . ANY . unstable . -m "Rebuild with grass (>= 
8.2.0-2)"

The GRASS version check fails since the new build in unstable. See:

 
https://salsa.debian.org/debian-gis-team/gdal-grass/-/blob/master/debian/README.source

Kind Regards,

Bas 

Bug#1002789: python-pycdlib: FTBFS: failed tests

[Thomas Goirand]

Control: severity -1 important

Can't reproduce ...

Bug#1022767: samba: Should not build-depend on librados-dev on ppc64 and x32

[John Paul Adrian Glaubitz]

Source: samba
Version: 2:4.16.6+dfsg-2
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi!

After ceph support was disabled on ppc64 and x32 as requested in #1012165
and #1020781, there is still a dependency on librados-dev left in debian/
control for ppc64 and x32.

Since librados-dev might become uninstallable in the future on ppc64 and
x32 since ceph continues to FTBFS on these architectures, the librados-dev
build dependency should be removed as well by removing both architectures
from the whitelist in debian/control.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#967447: gpa: depends on deprecated GTK 2

[Andreas Rönnquist]

On Fri, 18 Mar 2022 07:44:16 + Stefan Kropp  wrote:
> Few month ago I have started to change the implementation of gpa
> from gtk2 to gtk3. I will check if I can find the patch file.
> 

Hi!

Sorry, I haven't noticed your message in quite some time - and I have
actually started some porting myself - see

https://github.com/gusnan/gpa

where I have a branch port-gtk3. It would be great consolidate our
efforts. However - I must say that I don't know if upstream has any
interest in GPA any longer, and I not quite interested in becoming the
upstream.

My message to the gnupg devel mailinglist here:

https://lists.gnupg.org/pipermail/gnupg-devel/2022-October/035151.html

best
-- Andreas Rönnquist
gus...@debian.org

Bug#1003479: swig: Missing support for php8.1

[Sebastiaan Couwenberg]

On Sun, 16 Oct 2022 08:51:35 + Philipp Kern wrote:

On Mon, Jan 10, 2022 at 10:21:11PM +0100, Vincent Danjean wrote:
> Looking at upstream, support for php8 will be present in swig 4.1.0 that is
> not yet released.

It looks like it's due to be released in a week (2022-10-24).


4.1.0 was released yesterday:

 https://sourceforge.net/p/swig/mailman/message/37725738/

Kind Regards,

Bas

Bug#1022766: dpkg-shlibdeps: repeatedly emits duplicate warnings

[Andreas Beckmann]

Package: dpkg-dev
Version: 1.21.9
Severity: normal

While checking the nvida-cuda-toolkit buildd logs [1], I came across a
long sequence of repeated error messages:

pkg-shlibdeps: warning: can't extract name and version from library name 
'libfoobar.so'

There are about 40 repetitions of this warning (with no further messages
interleaved) for most of the libraries, but I don't know what this
number corresponds to.
Since nvida-cuda-toolkit just repacks upstream binary libraries we
unfortunately have to cope with a lot of libraries without proper sonames.

Andreas

[1] https://buildd.debian.org/status/package.php?p=nvidia-cuda-toolkit

Bug#1020641: dhcpcd5: dhcpcd > 7.1.0 don't work well with dhcpcd-gtk

[Martin-Éric Racine]

On Tue, Oct 25, 2022 at 11:25 AM Martintxo  wrote:
> Tl/dr: the bug is in the dhcpcd5 package systemd service file...

If you are starting dhcpcd using ifupdown via /etc/network/interfaces
or using dhcpcd-gtk, you probably only need dhcpcd-base.

If you remove dhcpcd5 and only keep dhcpcd-base, does that fix your problem?

Martin-Éric

Bug#1019554: Bug#1021496: anacron: cron.daily stopped executing a month ago

[Lance Lin]

Reporters,

May I report this bug (and the merged #'s) as closed?

Several people have reported the issue as fixed after enabling and starting the 
service.

Best,

Lance Lin 
GPG Fingerprint:  4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7

signature.asc
Description: OpenPGP digital signature

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Hi Moritz,

Le 25/10/2022 à 11:15, Moritz Muehlenhoff a écrit :

Hi Clément,


Sadly, upstream rectified and confirms it affects 2.2 [0], and has been
tested and reproduced on Bullseye. We do need to fix it. Upstream has a few
suggestions, but I guess our choices are either uploading 2.5 to stable, if
that's possible. python-stem at least will need to be updated as well, from
1.8.0 to 1.8.1 which luckily is bugfix only.

With the upstream confirmation about affected states I had a look at the 
remaining
issues affecting Bullseye:


Thanks!


CVE-2022-21694 
(https://github.com/onionshare/onionshare/security/advisories/GHSA-h29c-wcm8-883h)
is not a vulnerability by itself, it's a lack of a feature at most. We can 
ignore it for
Bullseye.


Agreed, that's my reasoning too.


CVE-2022-21688 
(https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v)
is just a stop gap, the actual issue is in QT and I'll reach out to upstream 
for more information
when this was fixed in QT so that it can be backported to Bullseye's QT 
packages.

Agreed. The fix for CVE-2022-21690 will provide a workaround as well.


This leaves:
https://security-tracker.debian.org/tracker/CVE-2022-21690
https://security-tracker.debian.org/tracker/CVE-2022-21689
https://security-tracker.debian.org/tracker/CVE-2021-41868

I think it's fair to ignore CVE-2021-41868 for Bullseye, it sounds like an edge 
case
and invasive to fix.
I'm not sure how much of an edge case it is. But I agree it's fair. We 
could provide a backport for users needing secure authentication, so 
they could use onion v3 auth for this usage (I didn't check yet how easy 
a backport would be, but I expect it'd be simple except maybe for the 
poetry build system part).




This leaves CVE-2022-21690 and CVE-2022-21689 which have isolated patches which 
could be backported?


Yes.


Given that the primary use case for onionshare will be tails, my suggestion 
would be that CVE-2022-21689
and CVE-2022-21690 get backported fixes for the next Bullseye point release 
(which Tails will sync up
to). What do you think?


There are some users of onionshare beside in Tails, but that sounds like 
a viable plan.


Cheers,

--
nodens

Bug#1022763: Acknowledgement (/usr/share/man/man1/tail.1.gz: documentation: tail(1): -NUM is undocumented)

[Alejandro Colomar]

Ahh, I see it documented in the texinfo(5) documentation:

{
For compatibility tail also supports an obsolete usage ‘tail -[num][bcl][f] 
[file]’, which is recognized only if it does not conflict with the usage 
described above. This obsolete form uses exactly one option and at most one 
file. In the option, num is an optional decimal number optionally followed by a 
size letter (‘b’, ‘c’, ‘l’) to mean count by 512-byte blocks, bytes, or lines, 
optionally followed by ‘f’ which has the same meaning as -f.

}

Being an obsolete feature, it might make sense to omit it in the manual page, to 
avoid too much noise, as long as it can't interfere with non-obsolete options.


Cheers,
Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022765: gnome-passwordsafe: Crash when opening a database (presumably because {} is in custom_property field)

[Krassy Boykinov]

Package: gnome-passwordsafe
Version: 6.5-5
Severity: important

Crashes when opening my file with ~50 entries and comments for a lot of
them

This happened after updating pykeepass yesterday

2022-10-24 11:50:54 upgrade python3-pykeepass:all 4.0.1-1 4.0.3-1


Creating a new empty database and unlocking it later on does not cause
any problems

Here is a syslog excerpt
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
Traceback (most recent call last):
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/gsecrets/unlock_database.py", line 270, 
in _unlock_callback
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
database = UnlockedDatabase(self.window, database_manager)
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/gsecrets/unlocked_database.py", line 99, 
in __init__
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
self.show_browser_page(self.current_element)
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/gsecrets/unlocked_database.py", line 
178, in show_browser_page
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
new_page = UnlockedDatabasePage(self, group)
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/gsecrets/widgets/unlocked_database_page.py", 
line 60, in __init__
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
self.populate_list_model()
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/gsecrets/widgets/unlocked_database_page.py", 
line 180, in populate_list_model
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
entries = self.group.entries
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/gsecrets/safe_element.py", line 288, in 
entries
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
return [SafeEntry(self._db_manager, entry) for entry in self._group.entries]
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/gsecrets/safe_element.py", line 288, in 

> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
return [SafeEntry(self._db_manager, entry) for entry in self._group.entries]
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/gsecrets/safe_element.py", line 330, in 
__init__
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
otp_uri = entry.get_custom_property("otp")
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]:   File 
"/usr/lib/python3/dist-packages/pykeepass/entry.py", line 255, in 
get_custom_property
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
assert key not in reserved_keys, '{} is a reserved key'.format(key)
> Okt 25 13:21:15 machine org.gnome.World.Secrets.desktop[6808]: 
AssertionError: otp is a reserved key


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
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 gnome-passwordsafe depends on:
ii  secrets  6.5-5

gnome-passwordsafe recommends no packages.

gnome-passwordsafe suggests no packages.

-- no debconf information

Bug#1022764: ffmpeg: Please disable checkasm-sw_scale on ppc64 as well

[John Paul Adrian Glaubitz]

Source: ffmpeg
Version: 7:5.1.2-1
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello!

Like with ppc64el, the test checkasm-sw_scale fails on ppc64.

Could you disable it on ppc64 as well?

Note: filter-overlay_yuv420p10 needs to be disabled on ppc64 as well since
  it's a big-endian target.

The attached patch makes the appropriate changes to debian/rules.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig   2022-10-01 00:52:37.0 -0700
+++ debian/rules2022-10-25 03:57:54.336885863 -0700
@@ -227,9 +227,13 @@
CONFIG += --ignore-tests=checkasm-sw_scale,filter-scale2ref_keep_aspect
 endif
 # https://trac.ffmpeg.org/ticket/9855
-ifneq (,$(filter hppa m68k powerpc ppc64 sparc64 s390x,$(DEB_HOST_ARCH_CPU)))
+ifneq (,$(filter hppa m68k powerpc sparc64 s390x,$(DEB_HOST_ARCH_CPU)))
CONFIG += --ignore-tests=filter-overlay_yuv420p10
 endif
+ifeq (ppc64,$(DEB_HOST_ARCH))
+   CONFIG += --ignore-tests=checkasm-sw_scale,filter-overlay_yuv420p10
+endif
+
 
 # Set cross-build prefix for compiler, pkg-config...
 ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))

Bug#1022763: /usr/share/man/man1/tail.1.gz: documentation: tail(1): -NUM is undocumented

[Alejandro Colomar]

Package: coreutils
Version: 9.1-1
Severity: normal
File: /usr/share/man/man1/tail.1.gz
Tags: upstream
X-Debbugs-Cc: a...@kernel.org, a...@nginx.com, l...@nginx.com

Dear maintainer,

`tail -1` works equivalently to `tail -n1`, but is undocumented.  As
far as I can see, it's not in POSIX, but is available in several
systems.  I guessed that it's not documented because it looks like a
backwards-compatibility feature not intended to be used by new scripts,
but still it would be good to document it, and maybe mark it as a
deprecated feature.  Could you please add it to the manual page?

Cheers,

Alex

Reported-by: Alejandro Colomar 
Reported-by: Liam Crilly 


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

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

Versions of packages coreutils depends on:
ii  libacl1  2.3.1-1
ii  libattr1 1:2.5.1-1
ii  libc62.35-3
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#546219: memtest86+: fails to load from pxelinux with default filename

[Felix Zielcke]

On Fri, 11 Sep 2009 11:13:35 -0700 Vagrant Cascadian
 wrote:
> Package: memtest86+
> Version: 2.01-1.1
> Severity: normal
> 
> when trying to network boot memtest86+.bin using pxelinux (from
> syslinux-common), it fails to run. on machines with a floppy drive,
it polls
> the floppy drive repeatedly. eventually, it spits out out "8000" over
and over
> again.
> 
> a workaround is to symlink or copy memtest86+.bin to memtest86+, and
it works
> fine, although having to rename or symlink the binary to network boot
> memtest86+ seems a bit of unnecessary hassle.
> 
> i also experienced the same problem with version 2.11-3 of
memtest86+, as well
> as versions of memtest86 in lenny and sid.
> 
> thanks for maintaining memtest86+, we use it extensively at Freegeek!
> http://freegeek.org
> 
> live well,
>   vagrant
> 
> 

Hi,

this bug is very old.
Can you or anybody else confirm if current version 5.31 or better 6.00
in sid works now fine with pxelinux? 

Bug#1022762: Please enable python bindings

[Jakob Haufe]

Source: libsigrok
Version: 0.5.2-3
Severity: wishlist

Subject says it all. It would be nice if libsigrok could be built with
its python bindings enabled.

Cheers,
sur5r

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

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



-- 
ceterum censeo microsoftem esse delendam.


pgpndFEdOGuFb.pgp
Description: OpenPGP digital signature

Bug#1022761: openrefine: Version 3.6.2 has been released

[Francesco Frassinelli]

Package: openrefine
Version: 3.6.1-1
Severity: wishlist
X-Debbugs-Cc: francesco.frassine...@nina.no

Dear Maintainer,

Version 3.6.2 of OpenRefine has been released at the beginning of October 2022. 
It would be nice to have it available on Debian.
Java 11 or greater is now required.


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

Kernel: Linux 5.4.0-128-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages openrefine depends on:
ii  curl7.85.0-1
ii  default-jre [java9-runtime] 2:1.11-72
ii  jython  2.7.2+repack1-4
ii  libapache-jena-java 4.5.0-1
ii  libapache-poi-java  4.0.1-4
ii  libclojure-java 1.10.3-1
ii  libcommons-codec-java   1.15-1
ii  libcommons-collections3-java3.2.2-2
ii  libcommons-collections4-java4.2-1
ii  libcommons-compress-java1.21-1
ii  libcommons-fileupload-java  1.4-1
ii  libcommons-io-java  2.11.0-2
ii  libcommons-lang-java2.6-10
ii  libcommons-lang3-java   3.12.0-2
ii  libcommons-text-java1.10.0-1
ii  libcommons-validator-java   1:1.6-2
ii  libgoogle-api-services-drive-java   1.32.1-2
ii  libgoogle-api-services-sheets-java  1.32.1-3
ii  libgoogle-http-client-java  1.42.0-1
ii  libguava-java   29.0-6
ii  libhttpclient5-java 5.1.3-1
ii  libhttpcore-java4.4.15-1
ii  libjackson2-annotations-java2.13.0-1
ii  libjackson2-core-java   2.13.0-2
ii  libjackson2-databind-java   2.13.2.2-1
ii  libjasypt-java  1.9.3-1
ii  libjaxb-api-java2.3.1-1
ii  libjetty9-java  9.4.49-1.1
ii  libjsoup-java   1.15.3-1
ii  libjsr305-java  0.1~+svn49-11
ii  libjuniversalchardet-java   2.4.0-3
ii  liblanguage-detector-java   0.6-2
ii  liblog4j2-java  2.17.2-1
ii  libmarc4j-java  2.9.2-1
ii  libmariadb-java 2.7.6-1
ii  libodfdom-java  0.9.0~RC2-2
ii  libokhttp-java  3.13.1-3
ii  libopenrefine-butterfly-java1.2.3-1
ii  libopenrefine-opencsv-java  2.4-2
ii  libopenrefine-vicino-java   1.2-3
ii  libowasp-encoder-java   1.2.3-2
ii  libpostgresql-jdbc-java 42.5.0-1
ii  libservlet-api-java 4.0.1-2
ii  libslf4j-java   1.7.32-1
ii  libsweble-common-java   3.0.8-3
ii  libsweble-wikitext-java 3.1.9-2
ii  libwikidata-toolkit-java0.13.3-1
ii  libxerial-sqlite-jdbc-java  3.39.2.0+dfsg-1
ii  openjdk-11-jre [java9-runtime]  11.0.16+8-1
ii  procps  2:3.3.17-7+b1
ii  velocity1.7-6

openrefine recommends no packages.

openrefine suggests no packages.

-- no debconf information

Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found

[Francesco Frassinelli]

Package: openrefine
Version: 3.6.1-1
Severity: important
X-Debbugs-Cc: francesco.frassine...@nina.no

Dear Maintainer,

I started openrefine and try to connect to it using the web brower 
(http://localhost:), but I got the following error:




Error 404 Not Found

HTTP ERROR 404 Not Found

URI:/
STATUS:404
MESSAGE:Not Found
SERVLET:-





I tried different paths, such as /openrefine, /server/webapp, but I get the 
same error. There is no mention in the documentation about using a different 
root path.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.4.0-128-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages openrefine depends on:
ii  curl7.85.0-1
ii  default-jre [java9-runtime] 2:1.11-72
ii  jython  2.7.2+repack1-4
ii  libapache-jena-java 4.5.0-1
ii  libapache-poi-java  4.0.1-4
ii  libclojure-java 1.10.3-1
ii  libcommons-codec-java   1.15-1
ii  libcommons-collections3-java3.2.2-2
ii  libcommons-collections4-java4.2-1
ii  libcommons-compress-java1.21-1
ii  libcommons-fileupload-java  1.4-1
ii  libcommons-io-java  2.11.0-2
ii  libcommons-lang-java2.6-10
ii  libcommons-lang3-java   3.12.0-2
ii  libcommons-text-java1.10.0-1
ii  libcommons-validator-java   1:1.6-2
ii  libgoogle-api-services-drive-java   1.32.1-2
ii  libgoogle-api-services-sheets-java  1.32.1-3
ii  libgoogle-http-client-java  1.42.0-1
ii  libguava-java   29.0-6
ii  libhttpclient5-java 5.1.3-1
ii  libhttpcore-java4.4.15-1
ii  libjackson2-annotations-java2.13.0-1
ii  libjackson2-core-java   2.13.0-2
ii  libjackson2-databind-java   2.13.2.2-1
ii  libjasypt-java  1.9.3-1
ii  libjaxb-api-java2.3.1-1
ii  libjetty9-java  9.4.49-1.1
ii  libjsoup-java   1.15.3-1
ii  libjsr305-java  0.1~+svn49-11
ii  libjuniversalchardet-java   2.4.0-3
ii  liblanguage-detector-java   0.6-2
ii  liblog4j2-java  2.17.2-1
ii  libmarc4j-java  2.9.2-1
ii  libmariadb-java 2.7.6-1
ii  libodfdom-java  0.9.0~RC2-2
ii  libokhttp-java  3.13.1-3
ii  libopenrefine-butterfly-java1.2.3-1
ii  libopenrefine-opencsv-java  2.4-2
ii  libopenrefine-vicino-java   1.2-3
ii  libowasp-encoder-java   1.2.3-2
ii  libpostgresql-jdbc-java 42.5.0-1
ii  libservlet-api-java 4.0.1-2
ii  libslf4j-java   1.7.32-1
ii  libsweble-common-java   3.0.8-3
ii  libsweble-wikitext-java 3.1.9-2
ii  libwikidata-toolkit-java0.13.3-1
ii  libxerial-sqlite-jdbc-java  3.39.2.0+dfsg-1
ii  openjdk-11-jre [java9-runtime]  11.0.16+8-1
ii  procps  2:3.3.17-7+b1
ii  velocity1.7-6

openrefine recommends no packages.

openrefine suggests no packages.

-- no debconf information

Bug#1022758: [Pkg-zsh-devel] Bug#1022758: Bug#1022758: zsh doesn't recognise double quotes with an exclamation mark

[Axel Beckert]

Hi,

Michael Prokop wrote:
> close 1022758

Thanks for the swift reaction, Mika! :-)

> "!" has a special meaning in zsh, so this behaves as expected and
> documented. You need to use single quotes or drop "!" from
> $histchars, if you want to disable this behavior.

Please also note that other shells have this feature, too, even GNU
Bash.

But Bash is less picky and accepts the erroneous

  echo "Hello!"

command. It though still would expand e.g. a followup

  echo "Hello!e"

to

  echo "Helloecho "Hello!""

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1022199: apt: certificate verification fails after adding custom root certificates through ca-certificates

[Marc Riudalbas Clemente]

Good morning,

I tested the same setup on a Buster system and it works perfectly.

Same CA, same intermediates, same configuration and same file locations. 
Also with update-ca-certificates.


And, however, if there was a problem with the algorithm implementing the 
EC curves on certificates I am using, the verification should not fail 
for all certificates, but only for the one I added. Correct me if I'm wrong.


Best regards,

Marc

On 25.10.22 08:01, David Kalnischkies wrote:

On Sun, Oct 23, 2022 at 11:03:19PM +0200, Julian Andres Klode wrote:

apt just calls gnutls_certificate_set_x509_system_trust() and
gnutls_set_default_priority() so this should not be our issue.

Also, on a side note, I have a custom CA (without an immediate) and apt
and co are happy with it. The other difference to my setup is that
I place my certificate in /usr/local/share/ca-certificates/ which avoids
further configuration as update-ca-certificates will pick them up
directly from there (see its manpage).

It might help if you can check if the chaining is part of the problem
or what else might be specific to your setup. Perhaps its the algorithms
used and e.g. gnutls not implementing the EC curves you used (or
something like that or not at all – its just something I ran into in
the past, although not with gnutls, that worked back then…).


Best regards

David Kalnischkies


--
aiticon GmbH
Stephanstraße 1
60313 Frankfurt am Main

t. +49 69 795 83 83-0
f. +49 69 795 83 83-28

Geschäftsführer: Matthias Herlitzius
Amtsgericht Frankfurt am Main · HRB 79310
USt.-ID-Nr.: DE 218319776

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[наб]

One day I'll actually attach a patch when I say I do.
From e920daac585c51deb6a65b332f921a0b02d90123 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Mon, 24 Oct 2022 17:19:31 +0200
Subject: [PATCH 1/2] faq.tmpl: fix deadlinks
X-Mutt-PGP: OS

Closes: #1021709
Closes: #960597
---
 faq.tmpl | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/faq.tmpl b/faq.tmpl
index c221fa9..6dd8e43 100644
--- a/faq.tmpl
+++ b/faq.tmpl
@@ -12,10 +12,8 @@
   package, since version 0.70 (buster and later), there is
   a dman command which fetches pages from this site
   dynamically. If you can't install the package directly for some
-  reason, you can also download and run
-  the https://anonscm.debian.org/git/collab-maint/debian-goodies.git/plain/dman?id=19924c907a8b907eaea3c0d942c5ae780ef6111e;>source
-  code. Review the source before running to make sure it hasn't
-  been compromised!
+  reason, you can also download and run it
+  https://salsa.debian.org/debian/debian-goodies/-/blob/master/dman;>directly.
 
 
 Where to report problems in manpages?
@@ -29,9 +27,9 @@ need to be reported:
 If the manpage renders correctly in some manpage viewers, but not
   on https://manpages.debian.org;>manpages.debian.org,
   this might likely be a limitation/bug
-  with http://mdocml.bsd.lv/;>mdocml (the renderer we
-  use). http://mdocml.bsd.lv/contact.html;>Report at
-  mdocml.
+  with http://mandoc.bsd.lv/;>mandoc (the renderer we
+  use). http://mandoc.bsd.lv/contact.html;>Report at
+  mandoc.
 If the manpage contains wrong content, and was added by the Debian
   package maintainer, report at
   the https://bugs.debian.org/;>Debian bug tracker.
@@ -73,14 +71,10 @@ need to be reported:
   itself, https://github.com/Debian/debiman/pulls;>pull
   requests are welcome on Github. If the problem is in the content
   of one of those static pages, you may need to make changes to the
-  https://anonscm.debian.org/git/srv-manpages/debian-assets.git/;>static
-  assets repository. Pushing to that repository requires access to
-  the srv-manpages group, which is granted through a
-  request on
-  the https://alioth.debian.org/projects/srv-manpages/;>Alioth
-  project. You can also simply send a patch by email on
+  https://salsa.debian.org/manpages-team/debian-assets;>static
+  assets repository  send a MR on salsa or patch to
   the https://lists.debian.org/debian-doc/;>Debian
-  Documentation Mailing List if this is a one-off change.
+  Documentation Mailing List.
 
 
 
@@ -112,8 +106,8 @@ need to be reported:
   platform for your own need. The source code
   is https://github.com/Debian/debiman/;>hosted on Github
   and the site-specific text for this site
-  is https://anonscm.debian.org/git/srv-manpages/debian-assets.git/;>hosted
-  on Alioth, which may be useful as an example of how to customize
+  is https://salsa.debian.org/manpages-team/debian-assets;>hosted
+  on Salsa, which may be useful as an example of how to customize
   this text in your own instance.
 
 
-- 
2.30.2

From ef239f002616557339e295ea99d1f0d9daa43643 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Mon, 24 Oct 2022 17:22:20 +0200
Subject: [PATCH 2/2] faq.tmpl: by {,the} Debiman cron job
X-Mutt-PGP: OS

---
 faq.tmpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/faq.tmpl b/faq.tmpl
index 6dd8e43..583a3cb 100644
--- a/faq.tmpl
+++ b/faq.tmpl
@@ -78,7 +78,7 @@ need to be reported:
 
 
 
-  Changes to the static assets are picked up by Debiman cron job,
+  Changes to the static assets are picked up by the Debiman cron job,
   which runs every 4 hours. Then the changes are propagated through a
   Debian static mirror infrastructure, which adds an additional
   delay. Changes to templates are not propagated until manpages
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1022758: [Pkg-zsh-devel] Bug#1022758: zsh doesn't recognise double quotes with an exclamation mark

[Michael Prokop]

close 1022758
thanks

Hi,

* Tanmay [Tue Oct 25, 2022 at 03:20:54PM +0530]:

> When I type `echo 'Hello!'`, it prints `Hello` but when I use double quotes
> instead of single quotes, there is no output and the shell waits for the
> quote to end.
> Here is  a transcript!
> 
> $ echo 'Hello!'
> Hello
> $ echo "Hello!"
> dquote>
> 
> I suggest that the shell should recognise the quotes.
> I am using Ubuntu 20.04 and kernel 5.15.0-52-generic.

"!" has a special meaning in zsh, so this behaves as expected and
documented. You need to use single quotes or drop "!" from
$histchars, if you want to disable this behavior.

See section `QUOTING` in `man zshall`, quoting from there

| Inside double quotes (""), parameter and command substitution occur,
| and `\' quotes the characters `\', ``', `"', `$', and the first
| character of $histchars (default `!').

regards
-mika-


signature.asc
Description: PGP signature

Bug#1022714: dvisvgm: fails to build with Ghostscript 10: undefined reference to `gs_error_names'

[Adrian Bunk]

On Tue, Oct 25, 2022 at 11:16:40AM +0200, Hilmar Preuße wrote:
> Control: tags -1 + help
> 
> Am 24.10.2022 um 14:57 teilte Jonas Smedegaard mit:
> 
> Hi,
> 
> > The dvisvgm package fails to build from source when linking against
> > Ghostscript 10:
> > 
> > libtool: link: g++ -Wall -Wnon-virtual-dtor -I../libs/clipper 
> > -I../libs/variant/include -I/usr/include/freetype2 -I/usr/include/libpng16 
> > -g -O2 -ffile-prefix-map=/build/dvisvgm-2.14=. -fstack-protector-strong 
> > -Wformat -Werror=format-security -Wno-mismatched-tags -Wl,-z -Wl,relro -o 
> > dvisvgm dvisvgm.o  ./.libs/libdvisvgm.a ../libs/clipper/libclipper.a 
> > -lfreetype ../libs/ff-woff/libfontforge.a -lwoff2enc -lbrotlienc -lcrypto 
> > -lz -lxxhash -lpotrace -lgs -lkpathsea
> > /usr/bin/ld: ./.libs/libdvisvgm.a(Ghostscript.o): in function 
> > `Ghostscript::error_name(int)':
> > ./src/Ghostscript.cpp:382: undefined reference to `gs_error_names'
> > 
> 
> > It seems to me that dvisvgm attempts to extract private information
> > from the libgs library, which is no longer provided since release 10
> > of Ghostscript.
> > 
> 
> Upstream has a commit for this:
> 
> https://github.com/mgieseki/dvisvgm/commit/9bf81fd0b6e7876e5079e917ed7e12163b9e7f7f
> 
> The commit message is: "dropped usage of gs_error_names() because it's no
> longer accessible as of GS 10.0.0"
> 
> I can confirm that dvisvgm builds again, after applying the patch. I'm not a
> C programmer, but the patch looks harmless to me. Could anybody confirm?

In general, trusting what upstream has already applied is a good default
(and you will usually anyway get this in the next upstream version).

> Hilmar

cu
Adrian

Bug#1022759: lintian: don't emit source-nmu-has-incorrect-version-number for stable updates

[Emilio Pozuelo Monfort]

Package: lintian
Version: 2.104.0
Severity: normal
X-Debbugs-Cc: debian-rele...@lists.debian.org

Hi,

When preparing stable or security updates, the convention is to use debXuY
whether it is a NMU or not, without making it e.g. deb11u1.1. Thus please
stop emitting this tag when a stable update is detected.

no-nmu-in-changelog should keep being emitted.

Thanks,
Emilio

Bug#1022758: zsh doesn't recognise double quotes with an exclamation mark

[Tanmay]

Package: zsh
Version: 5.8

When I type `echo 'Hello!'`, it prints `Hello` but when I use double quotes
instead of single quotes, there is no output and the shell waits for the
quote to end.
Here is  a transcript!

$ echo 'Hello!'
Hello
$ echo "Hello!"
dquote>

I suggest that the shell should recognise the quotes.
I am using Ubuntu 20.04 and kernel 5.15.0-52-generic.

Bug#1022126: mpt3sas broken with xen dom0

[Marc-Robin Wendt]

Hello,

same problem here with linux-image-5.10.0-19-amd64 version 5.10.149-2.

Went back to kernel linux-image-5.10.0-17-amd64 ver. 5.10.136-1, which
still works fine.

Greetings

Marc

Bug#1012538: knocked out usability - module 'collections' has no attribute 'Callable'

[Apostolos Kefalas]

On Thu, 9 Jun 2022 09:43:39 +0200 Christoph Berg  wrote:
> Re: Tyler Schwend
> > The Debian packaged version is much older than the current version.
> 
> The problem with chirp is that upstream isn't moving to python 3, the
> porting branch seems stalled:
> 
> http://d-rats.com/hg/hgwebdir.cgi/chirp.hg/branches
> 
> Christoph DF7CB
> 
> 

Hello,

lately chirp received some major work towards python3

https://github.com/kk7ds/chirp/tree/py3

it would be great to reach bookworm.


Regards
Apostolos

Bug#1022714: dvisvgm: fails to build with Ghostscript 10: undefined reference to `gs_error_names'

[Hilmar Preuße]

Control: tags -1 + help

Am 24.10.2022 um 14:57 teilte Jonas Smedegaard mit:

Hi,

The dvisvgm package fails to build from source when linking against 
Ghostscript 10:


libtool: link: g++ -Wall -Wnon-virtual-dtor -I../libs/clipper 
-I../libs/variant/include -I/usr/include/freetype2 -I/usr/include/libpng16 -g 
-O2 -ffile-prefix-map=/build/dvisvgm-2.14=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-mismatched-tags -Wl,-z -Wl,relro -o dvisvgm 
dvisvgm.o  ./.libs/libdvisvgm.a ../libs/clipper/libclipper.a -lfreetype 
../libs/ff-woff/libfontforge.a -lwoff2enc -lbrotlienc -lcrypto -lz -lxxhash 
-lpotrace -lgs -lkpathsea
/usr/bin/ld: ./.libs/libdvisvgm.a(Ghostscript.o): in function 
`Ghostscript::error_name(int)':
./src/Ghostscript.cpp:382: undefined reference to `gs_error_names'




It seems to me that dvisvgm attempts to extract private information
from the libgs library, which is no longer provided since release 10
of Ghostscript.



Upstream has a commit for this:

https://github.com/mgieseki/dvisvgm/commit/9bf81fd0b6e7876e5079e917ed7e12163b9e7f7f

The commit message is: "dropped usage of gs_error_names() because it's 
no longer accessible as of GS 10.0.0"


I can confirm that dvisvgm builds again, after applying the patch. I'm 
not a C programmer, but the patch looks harmless to me. Could anybody 
confirm?


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Moritz Muehlenhoff]

Hi Clément,

> Sadly, upstream rectified and confirms it affects 2.2 [0], and has been
> tested and reproduced on Bullseye. We do need to fix it. Upstream has a few
> suggestions, but I guess our choices are either uploading 2.5 to stable, if
> that's possible. python-stem at least will need to be updated as well, from
> 1.8.0 to 1.8.1 which luckily is bugfix only.

With the upstream confirmation about affected states I had a look at the 
remaining
issues affecting Bullseye:

CVE-2022-21694 
(https://github.com/onionshare/onionshare/security/advisories/GHSA-h29c-wcm8-883h)
is not a vulnerability by itself, it's a lack of a feature at most. We can 
ignore it for
Bullseye.

CVE-2022-21688 
(https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v)
is just a stop gap, the actual issue is in QT and I'll reach out to upstream 
for more information
when this was fixed in QT so that it can be backported to Bullseye's QT 
packages.

This leaves:
https://security-tracker.debian.org/tracker/CVE-2022-21690
https://security-tracker.debian.org/tracker/CVE-2022-21689
https://security-tracker.debian.org/tracker/CVE-2021-41868

I think it's fair to ignore CVE-2021-41868 for Bullseye, it sounds like an edge 
case
and invasive to fix.

This leaves CVE-2022-21690 and CVE-2022-21689 which have isolated patches which 
could be backported?

Given that the primary use case for onionshare will be tails, my suggestion 
would be that CVE-2022-21689
and CVE-2022-21690 get backported fixes for the next Bullseye point release 
(which Tails will sync up
to). What do you think?

Cheers,
Moritz

Bug#1020319: openldap: FTBFS on sparc64 due to unaligned access in testsuite

[John Paul Adrian Glaubitz]

Hi!

On 9/20/22 00:16, John Paul Adrian Glaubitz wrote:

openldap FTBFS on sparc64 due to an unaligned access in the testsuite:


Test succeeded
test000-rootdse completed OK for mdb after 1 seconds.



Starting test001-slapadd for mdb...

running defines.sh
Running slapadd to build slapd database...
Bus error
slapadd failed (138)!

test001-slapadd failed for mdb after 0 seconds

(exit 138)


It looks like this issue has been silently fixed in OpenLDAP 2.6.x.

It's no longer reproducible on git master and upstream closed the bug.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1022757: RM: src:fizmo -- NVIU; replaced by other real packages

[Bo YU]

Package: ftp.debian.org
Severity: normal

According to [0], the src:fizmo package should be removed from archive
because "fizmo-ncursesw" and "fizmo-console" which provide a virtual fizmo
package. The src:fizmo has RC reportbug[0] and should not fix it again.
Once this once, I will close the [0] also. thanks.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877015#10


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

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

[Colomban Wendling]

Hello,

This is still an issue as of today regarding the bullseye-security 
section being missing.


See for example the linux-image-amd64 or firefox-esr packages:

linux-image-amd64:
- https://packages.debian.org/search?keywords=linux-image-amd64 
(bullseye shows 5.10.140-1)
- apt policy: 5.10.149-2 http://security.debian.org/debian-security 
bullseye-security/main amd64 Packages


firefox-esr:
- https://packages.debian.org/search?keywords=firefox-esr (bullseye 
shows 91.13.0esr-1~deb11u1)
- apt policy: 102.4.0esr-1~deb11u1 
http://security.debian.org/debian-security bullseye-security/main amd64 
Packages


I have unfortunately no insight on how this could be fixed, but it's 
rather inconvenient as packages.debian.org is thus effectively not a 
trustable source for Bullseye.


Regards,
Colomban

Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

[benmorris]

Thanks Francois!

Yes, this does seem to have been my problem. I'm not yet sure how Pulse 
got reinstalled, but I probably should have checked for that.

Bug#1022756: gdbm: Open-FD-leak in reorganize()

[Philipp Hahn]

Source: gdbm
Version: 1.18.1-4
Severity: normal

Dear Maintainer,

gdbm_reorganize() leaks open file descriptors. It can be re-produces by
using the python3-gdbm binding:

  python3 -c 'import os,subprocess;import dbm.gnu;DB = "./db.gdbm";db = 
dbm.gnu.open(DB, "csu");db.reorganize();db.close();subprocess.call(f"lsof -p 
{os.getpid()}|grep {DB}", shell=True)'

> python 2119 phahn  DEL-W  REG254,0 6293029 ./db.gdbm
> python 2119 phahn  DEL-W  REG254,0 6293042 ./db.gdbm

For each call to reorganize() the DB is copied to a new file which is
then again memory-mapped. This takes one FD each time.

# dpkg -s libgdbm6
Package: libgdbm6
Source: gdbm
Version: 1.18.1-4

# dpkg -s python3-gdbm
Package: python3-gdbm
Source: python3-stdlib-extensions
Version: 3.7.3-1

Debian-9-Stretch 1.8.3-14
Debian-10-Buster 1.18.1-4 (affected)
Debian-11-Bullseye   1.19-2 (affected)
Debian-12-Bookworm   1.23-3 (fixed)


I have bisected the issue:
git bisect start '--term-new' 'fixed' '--term-old' 'broken'
# fixed: [331f05ac9c58d358806fe1bcba88a01467ab0895] Bugfix
git bisect fixed 331f05ac9c58d358806fe1bcba88a01467ab0895
# broken: [778cc81d55aecd6344d577919cec73e4e6980e2e] Version 1.18
git bisect broken 778cc81d55aecd6344d577919cec73e4e6980e2e
# broken: [611cac791f192834d49cd1bd8cfab76a190bfc40] Document new gdbmtool 
options
git bisect broken 611cac791f192834d49cd1bd8cfab76a190bfc40
# fixed: [3052f2b51eaa9ba047d43ae97581ae1fd895c131] Add missing include
git bisect fixed 3052f2b51eaa9ba047d43ae97581ae1fd895c131
# fixed: [e4089536f849644b12d9647aff12f2dac312b940] Version 1.21 released
git bisect fixed e4089536f849644b12d9647aff12f2dac312b940
# broken: [038872b1582c6b99cc352551875aba0e81f6b5f0] Minor fix
git bisect broken 038872b1582c6b99cc352551875aba0e81f6b5f0
# fixed: [a62815cdf0b60725d6445968ce3d5c39e912eb9c] Update docs
git bisect fixed a62815cdf0b60725d6445968ce3d5c39e912eb9c
# fixed: [cc7051ae2ea384863937083a3a60a5a008d511a5] gdbmshell: get rid of 
remaining globals
git bisect fixed cc7051ae2ea384863937083a3a60a5a008d511a5
# fixed: [d19407eaa4b00a724c4ff3744c2f49269183da26] gdbmtool: bugfixes
git bisect fixed d19407eaa4b00a724c4ff3744c2f49269183da26
# fixed: [f77b0273db2d1f0cc1ba2d3256acfab1bda1f584] Fix duplicated mmap in 
gdbm_recover
git bisect fixed f77b0273db2d1f0cc1ba2d3256acfab1bda1f584
# first fixed commit: [f77b0273db2d1f0cc1ba2d3256acfab1bda1f584] Fix duplicated 
mmap in gdbm_recover

Sadly that patch is not easy to backport because GDBM changes some
fundamental details, e.g. "New bucket cache" in v1.21 and "Bucket cache
switched from balanced tree to hash table" in v1.23

A similar bug was reported for Python
, which links to
 which is ALSO
required but not enough.

I have back-ported that patch and so far it works fine, but a second set
of eyes or even a review from upstream would be good.


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

Kernel: Linux 5.10.0-18-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From ffeafe9692da956703d28f1f16c81a027a0e6869 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Sergey Poznyakoff 
Date: Mon, 8 Apr 2019 22:17:10 +0300
Subject: [PATCH 1/2] Preserve locking type during database reorganization

* src/recover.c (_gdbm_finish_transfer): Preserve locking type.
---
 src/recover.c | 1 +
 1 file changed, 1 insertion(+)

diff --git src/recover.c src/recover.c
index 7cc20a2..f1603d9 100644
--- src/recover.c
+++ src/recover.c
@@ -155,6 +155,7 @@ _gdbm_finish_transfer (GDBM_FILE dbf, GDBM_FILE new_dbf,
   free (dbf->bucket_cache);
}
 
+   dbf->lock_type = new_dbf->lock_type;
dbf->desc  = new_dbf->desc;
dbf->header= new_dbf->header;
dbf->dir   = new_dbf->dir;
-- 
2.30.2

>From 40c6da6ca9972ff0b9d7d084fe118c765808fef6 Mon Sep 17 00:00:00 2001
Message-Id: 
<40c6da6ca9972ff0b9d7d084fe118c765808fef6.185456.git.h...@univention.de>
In-Reply-To: 

References: 

From: Sergey Poznyakoff 
Date: Wed, 11 Aug 2021 23:01:37 +0300
Subject: [PATCH 2/2] Fix duplicated mmap in gdbm_recover

* src/recover.c (_gdbm_finish_transfer): Reuse memory mapping
from the intermediate dbm structure.
---
 src/recover.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git src/recover.c src/recover.c
index f1603d9..893e0a2 100644
--- src/recover.c
+++ src/recover.c
@@ -169,14 +169,14 @@ _gdbm_finish_transfer (GDBM_FILE dbf, GDBM_FILE new_dbf,
dbf->bucket_changed= new_dbf->bucket_changed;
dbf->second_changed= new_dbf->second_changed;
 
+  

Bug#1021732: [Pkg-privacy-maintainers] Bug#1021732: Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...

[Georg Faerber]

Hi nodens,

On 22-10-25 09:16:29, Clément Hermann wrote:
> Do you mind if I cherry-pick the upstream fix and upload today ?
> This is blocking the perl 5.36 transition.

I do not, please do, and thanks in advance. Please push your changes,
including the tag.

Cheers,
Georg

Bug#1021732: [Pkg-privacy-maintainers] Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...

[Clément Hermann]

Hi Georg,

Le 14/10/2022 à 11:12, Georg Faerber a écrit :

Control: forwarded -1 https://0xacab.org/jvoisin/mat2/-/issues/178
Control: tags -1 + fixed-upstream upstream

Hi Paul,

On 22-10-13 19:52:35, Paul Gevers wrote:

With a recent upload of libimage-exiftool-perl the autopkgtest of mat2
fails in testing when that autopkgtest is run with the binary packages
of libimage-exiftool-perl from unstable.

Thanks for your report.



Do you mind if I cherry-pick the upstream fix and upload today ?
This is blocking the perl 5.36 transition.

Thanks!

--
nodens