Bug#1026404: /usr/bin/kwin_x11: kwin-x11 : stops after some time

[Erwan David]

Package: kwin-x11
Version: 4:5.26.4-1
Severity: normal
File: /usr/bin/kwin_x11

AFter some time in session, kwin stops, leaving the desktop without window 
manager.

I get this in logs :
déc. 19 16:40:33 ot-port-145 kwin_x11[1835]: The X11 connection broke: I/O 
error (code 1)
déc. 19 16:40:33 ot-port-145 kwin_x11[1835]: XIO:  fatal IO error 0 (Success) 
on X server ":0"
déc. 19 16:40:33 ot-port-145 kwin_x11[1835]:   after 3380199 requests 
(3380199 known processed) with 0 events remaining.
déc. 19 16:40:33 ot-port-145 kwin_x11[1835]: 
file:///usr/share/kwin/outline/plasma/outline.qml:14: TypeError: Cannot read 
property 'longDuration' of null
déc. 19 16:40:33 ot-port-145 systemd[1634]: plasma-kwin_x11.service: Consumed 
11min 29.355s CPU time.

No other X client stops



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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, 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 kwin-x11 depends on:
ii  kwin-common4:5.26.4-1
ii  libc6  2.36-6
ii  libepoxy0  1.5.10-1
ii  libgcc-s1  12.2.0-10
ii  libkdecorations2-5v5   4:5.26.4-1
ii  libkf5configcore5  5.100.1-1
ii  libkf5configgui5   5.100.1-1
ii  libkf5configwidgets5   5.100.0-1
ii  libkf5coreaddons5  5.100.0-1
ii  libkf5crash5   5.100.0-1
ii  libkf5globalaccel-bin  5.100.0-1
ii  libkf5globalaccel5 5.100.0-1
ii  libkf5i18n55.100.0-1
ii  libkf5notifications5   5.100.0-1
ii  libkf5plasma5  5.100.1-1
ii  libkf5service-bin  5.100.0-1
ii  libkf5service5 5.100.0-1
ii  libkf5windowsystem55.100.0-1
ii  libkwineffects14   4:5.26.4-1
ii  libkwinglutils14   4:5.26.4-1
ii  libqaccessibilityclient-qt5-0  0.4.1-1+b1
ii  libqt5core5a   5.15.6+dfsg-5
ii  libqt5dbus55.15.6+dfsg-5
ii  libqt5gui5 5.15.6+dfsg-5
ii  libqt5qml5 5.15.6+dfsg-2
ii  libqt5quick5   5.15.6+dfsg-2
ii  libqt5widgets5 5.15.6+dfsg-5
ii  libqt5x11extras5   5.15.6-2
ii  libstdc++6 12.2.0-10
ii  libx11-6   2:1.8.1-2
ii  libxcb-composite0  1.15-1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.15-1
ii  libxcb-render0 1.15-1
ii  libxcb-shape0  1.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb11.15-1
ii  libxi6 2:1.8-1+b1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

Bug#1024492: Acknowledgement (libffi: large structs need to be passed by value on hppa)

[John David Anglin]

Hi,

There are two additional updates for libffi on hppa. See:
https://github.com/libffi/libffi/issues/755
https://github.com/libffi/libffi/issues/756

The current installed version (+b2) has the patches for the above issues.

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net

Bug#1024271: python-cffi: FTBFS on hppa - c/test_c.py test faults and drops core

[John David Anglin]

Hi Stefano,

On 2022-11-17 3:37 p.m., Stefano Rivera wrote:

Generally speaking python-cffi test failures point to libffi bugs. So,
I'd start by trying to verify the behaviour of the underlying behaviour
in libffi, from C.

The attached patch to python-cffi fixes the test failures on hppa. Please add 
to patches
for python-cffi and push upstream if okay.

A couple of years ago the libffi port for hppa-linux was changed from using a 
trampoline
executed on the stack to the function descriptor technique used by ia64. This 
doesn't
require an executable stack and is simpler. However, function pointers need to 
have the
PLABEL bit set in the pointer. As a result, a simple cast can't be used to 
convert closure
pointers to function pointers.

python-cffi uses its own closure allocation so the problem can't be fixed in 
libffi.

I added a macro CFFI_FN to do the conversion. It shouldn't affect other 
architectures.
There is a similar define in libffi.

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net
--- ./c/_cffi_backend.c.save2022-12-18 13:56:40.706730405 +
+++ ./c/_cffi_backend.c 2022-12-18 13:57:03.306944998 +
@@ -60,6 +60,13 @@
 # endif
 #endif
 
+/* Convert from closure pointer to function pointer. */
+#if defined(__hppa__) && !defined(__LP64__)
+#define CFFI_FN(f) ((void (*)(void))((unsigned int)(f) | 2))
+#else
+#define CFFI_FN(f) ((void (*)(void))f)
+#endif
+
 
 /* Define the following macro ONLY if you trust libffi's version of
  * ffi_closure_alloc() more than the code in malloc_closure.h.
@@ -3191,7 +3198,7 @@
 
 Py_BEGIN_ALLOW_THREADS
 restore_errno();
-ffi_call(_descr->cif, (void (*)(void))(cd->c_data),
+ffi_call(_descr->cif, (void (*)(void)) CFFI_FN(cd->c_data),
  resultdata, buffer_array);
 save_errno();
 Py_END_ALLOW_THREADS
@@ -6394,7 +6401,7 @@
 goto error;
 Py_INCREF(ct);
 cd->head.c_type = ct;
-cd->head.c_data = (char *)closure_exec;
+cd->head.c_data = (char *)CFFI_FN(closure_exec);
 cd->head.c_weakreflist = NULL;
 closure->user_data = NULL;
 cd->closure = closure;

Bug#1026250: [phpmyadmin-sql-parser] Autopkgtest fails on PHP 8.2 due to deprecations

[David Prévot]

Package: php-phpmyadmin-sql-parser
Version: 5.5.0-1
Severity: important
Control: block 1014460 by -1

Hi William,

The testsuite is currently failing on PHP 8.2 due to stderr output.
Using the following stanza in debian/tests/control should be enough to
hide this issues.

Restrictions: allow-stderr


autopkgtest [14:26:42]: test phpunit: ---]
phpunit  FAIL stderr: PHP Deprecated:  Creation of dynamic property 
PhpMyAdmin\SqlParser\Components\Expression::$file is deprecated in 
/usr/share/php/PhpMyAdmin/SqlParser/Components/Expression.php on line 400
autopkgtest [14:26:42]: test phpunit:  - - - - - - - - - - results - - - - - - 
- - - -
autopkgtest [14:26:42]: test phpunit:  - - - - - - - - - - stderr - - - - - - - 
- - -
PHP Deprecated:  Creation of dynamic property 
PhpMyAdmin\SqlParser\Components\Expression::$file is deprecated in 
/usr/share/php/PhpMyAdmin/SqlParser/Components/Expression.php on line 400
[…]
PHP Deprecated:  Creation of dynamic property 
PhpMyAdmin\SqlParser\Statements\RenameStatement::$from is deprecated in 
/usr/share/php/Zumba/JsonSerializer/JsonSerializer.php on line 459
PHP Deprecated:  Creation of dynamic property 
PhpMyAdmin\SqlParser\Statements\RenameStatement::$from is deprecated in 
/usr/share/php/PhpMyAdmin/SqlParser/Statement.php on line 407
PHP Deprecated:  Creation of dynamic property 
PhpMyAdmin\SqlParser\Components\Expression::$file is deprecated in 
/usr/share/php/PhpMyAdmin/SqlParser/Components/Expression.php on line 400
autopkgtest [14:26:42]:  summary
phpunit  FAIL stderr: PHP Deprecated:  Creation of dynamic property 
PhpMyAdmin\SqlParser\Components\Expression::$file is deprecated in 
/usr/share/php/PhpMyAdmin/SqlParser/Components/Expression.php on line 400

https://qa.debian.org/excuses.php?experimental=1=php-defaults

Regards

David


signature.asc
Description: PGP signature

Bug#1026235: tar: ftbfs with recent glibc

[John David Anglin]

On 2022-12-16 5:33 p.m., Florian Weimer wrote:

* John David Anglin:


On 2022-12-16 4:24 p.m., Florian Weimer wrote:

* John David Anglin:


I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64
This would avoid the overflow converting tv_sec from 64 to 32 bits.

It's an ABI break.  You probably can enable it in the tar build safely
because it's not a library.  But doing it by default across the
distribution is difficult because it changes the meaning of time_t in
header files.

But it seems we already have an ABI break since tar built before the
recent glibc changes.

No, not an ABI break.  A regression.  I suspect the glibc bugfix exposed
that the tar test was failing all along.

If we are sure that the glibc bugfix just exposed the tar problem, then this 
issue can be closed.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1026235: tar: ftbfs with recent glibc

[John David Anglin]

On 2022-12-16 4:24 p.m., Florian Weimer wrote:

* John David Anglin:


I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64
This would avoid the overflow converting tv_sec from 64 to 32 bits.

It's an ABI break.  You probably can enable it in the tar build safely
because it's not a library.  But doing it by default across the
distribution is difficult because it changes the meaning of time_t in
header files.

But it seems we already have an ABI break since tar built before the recent 
glibc changes.

Regards,
Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1026235: tar: ftbfs with recent glibc

[John David Anglin]

Source: libc6
Version: 2.36-6
Severity: normal

Dear Maintainer,

See the following BZ for tar:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204

__USE_TIME_BITS64 now needs to be defined on most 32-bit
architectures to build tar even when _FILE_OFFSET_BITS=64
is selected. The folowing error occurs from glibc:
+tar: dir/f2038-01-19T03\:14\:08.9: Cannot stat: Value too large for defined 
data type

The following two commits changed the handling of file times:

commit dd4131c8322891a0ad7cfb661efa41aecc02b581
Author: Aurelien Jarno 
Date:   Tue Nov 1 20:43:55 2022 +0100

linux: Fix fstatat on MIPSn64 (BZ #29730)

Commit 6e8a0aac2f883 ("time: Fix overflow itimer tests on 32-bit
systems") changed in_time_t_range to assume a 32-bit time_t. This broke
fstatat on MIPSn64 that was using it with a 64-bit time_t due to
difference between stat and stat64. This commit fix that by adding a
MIPSn64 specific version, which bypasses the EOVERFLOW tests.

Resolves: BZ #29730

Reviewed-by: Adhemerval Zanella  
(cherry picked from commit 7457b7eef8dfe8cc48e55b9f9837df6dd397b80d)

commit 7b7dfbb0cbdffebf0233c650627a4861212fbb60
Author: Adhemerval Zanella 
Date:   Wed Oct 19 19:14:04 2022 -0300

linux: Fix generic struct_stat for 64 bit time (BZ# 29657)

The generic Linux struct_stat misses the conditionals to use
bits/struct_stat_time64_helper.h in the __USE_TIME_BITS64 for
architecture that uses __TIMESIZE == 32 (currently csky and nios2).

Since newer ports should not support 32 bit time_t, the generic
implementation should be used as default.

For arm, hppa, and sh a copy of default struct_stat is added,
while for csky and nios a new one based on generic is used, along
with conditionals to use bits/struct_stat_time64_helper.h.

The default struct_stat is also replaced with the generic one.

Checked on aarch64-linux-gnu and arm-linux-gnueabihf.

(cherry picked from commit 7a6ca82f8007ddbd43e2b8fce806ba7101ee47f5)

I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64
This would avoid the overflow converting tv_sec from 64 to 32 bits.

Regards,
Dave

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

-- debconf information excluded

Bug#1021278: (no subject)

[David da Silva Polverari]

fixed 1021278 3.0.2-2
thanks

Bug#1021278:

[David Polverari]

fixed 1021278 3.0.2-1
thanks

Bug#1017518: new upstream (8.3)

[David Lamparter]

On Sun, Dec 11, 2022 at 12:55:46AM +0100, Marco d'Itri wrote:
> On Aug 17, Daniel Baumann  wrote:
> > it would be nice if you could upgrade to the current upstream version of
> > frr (8.3).
> There has not been any progress on this or #1016978 in months, the 
> package is not in testing and the freeze is close.
> Does frr need a new maintainer?

In a way, yes;  we had made an agreement with Ondřej Surý but that seems
to have broken down.  I'm happy to work on Debian packaging for FRR, but
I can't upload myself due to not being a DM/DD, and the brain cost of
socially interacting with someone else to pipe things through is too
high for me to take.  (Sadly due to my personality traits, even just
handling mails is immensely expensive for me...)

Do you have any suggestions on a way forward?


-equi/David

Bug#1025875: wireshark: FTBFS on hppa - suite_decryption and suite_wslua test fails

[John David Anglin]

Source: wireshark
Version: 4.0.2-1
Severity: normal

Dear Maintainer,

See:
https://buildd.debian.org/status/fetch.php?pkg=wireshark=hppa=4.0.2-1=1670723453=0

The wslua fail seems to be a known issue:
https://gitlab.com/wireshark/wireshark/-/issues/15945

The decryption fail seems to be a big endian issue as it fails on s390,
powerpc, and ppc64 as well.

On some release architectures, these fails are suppressed:

override_dh_auto_test:
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
$(MAKE) -C obj-* test-programs
ifneq (,$(filter armel armhf mips mipsel s390x,$(DEB_HOST_ARCH)))
# reported as https://gitlab.com/wireshark/wireshark/-/issues/15945
-dh_auto_test
else
dh_auto_test
endif
endif

If they are not going to be addressed, please add hppa to the above list.

Regards,
Dave Anglin


-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#1025799: telegram-desktop: New version 4.4.1 available

[david]

Package: telegram-desktop
Version: 4.3.4+ds-2
Severity: wishlist

Dear Maintainer,

The new version of telegram 4.4.1 includes threads for groups that doesn't work
well with current sid version (4.3.4). Please, it would be good having it in
Debian. Thanks.

-- 
David

-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libabsl20220623   20220623.1-1
ii  libavcodec59  7:5.1.2-1
ii  libavformat59 7:5.1.2-1
ii  libavutil57   7:5.1.2-1
ii  libc6 2.36-6
ii  libgcc-s1 12.2.0-9
ii  libglib2.0-0  2.74.2-1
ii  libglibmm-2.68-1  2.74.0-1
ii  libhunspell-1.7-0 1.7.1-1
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libkf5coreaddons5 5.100.0-1
ii  liblz4-1  1.9.4-1
ii  libminizip1   1.1-8+b1
ii  libopenal11:1.19.1-2
ii  libopus0  1.3.1-2
ii  libqrcodegencpp1  1.8.0-1.1
ii  libqt5core5a [qtbase-abi-5-15-6]  5.15.6+dfsg-5
ii  libqt5gui55.15.6+dfsg-5
ii  libqt5network55.15.6+dfsg-5
ii  libqt5qml55.15.6+dfsg-2
ii  libqt5quickwidgets5   5.15.6+dfsg-2
ii  libqt5svg55.15.6-2
ii  libqt5waylandcompositor5  5.15.6-2
ii  libqt5widgets55.15.6+dfsg-5
ii  librlottie0-1 0.1+dfsg-4
ii  libsigc++-3.0-0   3.2.0-5
ii  libssl3   3.0.7-1
ii  libstdc++612.2.0-9
ii  libswresample47:5.1.2-1
ii  libswscale6   7:5.1.2-1
ii  libvpx7   1.12.0-1
ii  libwayland-client01.21.0-1
ii  libx11-6  2:1.8.1-2
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-record01.15-1
ii  libxcb-screensaver0   1.15-1
ii  libxcb1   1.15-1
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxrandr22:1.5.2-2+b1
ii  libxtst6  2:1.2.3-1.1
ii  libxxhash00.8.1-1
ii  qt5-image-formats-plugins 5.15.6-2
ii  zlib1g1:1.2.11.dfsg-4.1

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans   1.11-2
ii  libwebkit2gtk-4.0-37  2.38.2-1+b1
ii  libwebkit2gtk-4.1-0   2.38.2-1+b1

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal   1.15.0-3
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1

-- no debconf information
[2022.12.09 12:13:36] Launched version: 4004001, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2022.12.09 12:13:36] Executable dir: /home/david/Telegram/, name: Telegram
[2022.12.09 12:13:36] Initial working dir: /home/david/Telegram/
[2022.12.09 12:13:36] Working dir: /home/david/.local/share/TelegramDesktop/
[2022.12.09 12:13:36] Command line: ./Telegram
[2022.12.09 12:13:36] Executable path before check: 
/home/david/Telegram/Telegram
[2022.12.09 12:13:36] Logs started
[2022.12.09 12:13:36] Launcher filename: 
org.telegram.desktop._d968f04c9b5a97f122a98df2c879dcfd.desktop
[2022.12.09 12:13:36] Connecting local socket to 
/tmp/624a675f36acb59580aca91d905e70f1-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2022.12.09 12:13:36] This is the only instance of Telegram, starting server 
and app...
[2022.12.09 12:13:36] Moved logging from 
'/home/david/.local/share/TelegramDesktop/log_start0.txt' to 
'/home/david/.local/share/TelegramDesktop/log.txt'!
[2022.12.09 12:13:36] Primary screen DPI: 96
[2022.12.09 12:13:36] System tray available: [FALSE]
[2022.12.09 12:13:36] Font: from ':/gui/fonts/DAOpenSansRegular.ttf' loaded 
'DAOpenSansRegular'
[2022.12.09 12:13:36] Font: from ':/gui/fonts/DAVazirRegular.ttf' loaded 
'DAVazirRegular'
[2022.12.09 12:13:36] Font: from ':/gui/fonts/DAOpenSansRegularItalic.ttf' 
loaded 'DAOpenSansRegularItalic'
[2022.12.09 12:13:36] Font: from ':/gui/fonts/DAVazirRegular.ttf' loaded 
'DAVazirRegular'
[2022.12.09 12:13:36] Font: from ':/gui/fonts/DAOpenSansSemiboldAsBold.ttf' 
loaded

Bug#1025736: nodejs: Always segfaults on riscv64

[David Ventura]

al SIGSEGV, Segmentation fault.  
#0  0x00ff99fcdab2 in 
v8::internal::Code::RelocateFromDesc(v8::internal::ByteArray, 
v8::internal::Heap*, v8::internal::CodeDesc const&) () from 
/lib/riscv64-linux-gnu/libnode.so.108
[Current thread is 1 (Thread 0xff98acaec0 (LWP 17623))] 
   
(gdb) bt
   
#0  0x00ff99fcdab2 in 
v8::internal::Code::RelocateFromDesc(v8::internal::ByteArray, 
v8::internal::Heap*, v8::internal::CodeDesc const&) () from 
/lib/riscv64-linux-gnu/libnode.so.108
#1  0x00ff99e9d980 in 
v8::internal::Factory::CodeBuilder::BuildInternal(bool) () from 
/lib/riscv64-linux-gnu/libnode.so.108
#2  0x00ff99d6538e in 
v8::internal::baseline::BaselineCompiler::Build(v8::internal::LocalIsolate*) () 
from /lib/riscv64-linux-gnu/libnode.so.108
#3  0x00ff99d74296 in 
v8::internal::GenerateBaselineCode(v8::internal::Isolate*, 
v8::internal::Handle) () from 
/lib/riscv64-linux-gnu/libnode.so.108
#4  0x00ff99db66f6 in 
v8::internal::Compiler::CompileSharedWithBaseline(v8::internal::Isolate*, 
v8::internal::Handle, 
v8::internal::Compiler::ClearExceptionFlag, v8::internal::IsCompiledScope*) () 
from /lib/riscv64-linux-gnu/libnode.so.108
#5  0x00ff99db6b7a in 
v8::internal::Compiler::CompileBaseline(v8::internal::Isolate*, 
v8::internal::Handle, 
v8::internal::Compiler::ClearExceptionFlag, v8::internal::IsCompiledScope*) () 
from /lib/riscv64-linux-gnu/libnode.so.108
#6  0x00ff99d63a5a in 
v8::internal::baseline::BaselineBatchCompiler::CompileBatch(v8::internal::Handle)
 () from /lib/riscv64-linux-gnu/libnode.so.108
#7  0x00ff99e5b1b2 in 
v8::internal::TieringManager::OnInterruptTick(v8::internal::Handle)
 () from /lib/riscv64-linux-gnu/libnode.so.108
#8  0x00ff9a1b7a70 in 
v8::internal::Runtime_BytecodeBudgetInterruptWithStackCheck(int, unsigned 
long*, v8::internal::Isolate*) () from /lib/riscv64-linux-gnu/libnode.so.108
#9  0x00ff99bf68dc in ?? () from /lib/riscv64-linux-gnu/libnode.so.108
(gdb)   


  

```

This is _likely_ unrelated, but I faced a "similar" (stack-related issues) bug 
with golang, patch:

https://go-review.googlesource.com/c/go/+/409055/6/src/runtime/lfstack_64bit.go#40

bug report:

https://github.com/golang/go/issues/54104

Thanks,
David


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

Kernel: Linux 6.0.0-5-riscv64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nodejs depends on:
ii  libc6   2.36-6
ii  libnode108  18.12.1+dfsg-2+0.riscv64.1

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   18.12.1+dfsg-2+0.riscv64.1

Versions of packages nodejs suggests:
pn  npm  

-- debconf information excluded

Bug#1022540: build-essential: please add riscv64 support

[David Heidelberg]

Hello!

If there isn't any specific blocker, I would like to get into a state 
where I don't have to hack our CI with the following Ubuntu injection:


```
apt-get install -y gcc-riscv64-linux-gnu g++-riscv64-linux-gnu
wget 
http://mirrors.kernel.org/ubuntu/pool/universe/b/build-essential/crossbuild-essential-riscv64_12.8ubuntu1.1_all.deb

dpkg -i crossbuild-essential-riscv64_12.8ubuntu1.1_all.deb
```

Thank you for your work on crossbuild!

David

--
David Heidelberg
Consultant Software Engineer

Bug#1025157: missing /usr/bin/lorem

[David G]

Package: libtext-lorem-perl
Version: 0.34-2

Version 0.3-2 and earlier included /usr/bin/lorem, which provided a
useful command-line interface to the library.
This is missing in version 0.34-1 and later.

Bug#1024672: slim: New upstream

[David (Plasma) Paul]

Source: slim
Version: 1.3.6-5.3
Severity: wishlist

Dear Maintainer,

Please consider switching the slim package's upstream to the new
development being done by Rob Pearce at
.

To quote him on that page:

"The SLiM project used to be hosted on Berlios.de with a mirror on
SourceForge. Then the code got moved to Github. Then all the
maintainers lost interest and it died. Nine years later, I'm still
using it as I find it the most easily configurable, most lightweight
option for the small Linux systems I build. But with upstream being
dead and Gentoo needing 13 patch files to make it work, there was a
risk it would vanish from the repository. So I've forked it, applied
all the patches, plus some of my own, and started my own spin-off here."


-- 
Plasma

Bug#1024666: supertuxkart: New version 1.4 available

[david]

Package: supertuxkart
Version: 1.3+dfsg1-3
Severity: wishlist

Dear Maintainer,

When it will be in Debian?

Thank you :)

-- 
David

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

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

Versions of packages supertuxkart depends on:
ii  libbluetooth3  5.65-1+b1
ii  libc6  2.36-5
ii  libcurl3-gnutls7.86.0-2
ii  libfreetype6   2.12.1+dfsg-3
ii  libgcc-s1  12.2.0-9
ii  libharfbuzz0b  5.2.0-2+b1
ii  libjpeg62-turbo1:2.1.2-1+b1
ii  libmbedcrypto7 2.28.1-1
ii  libmcpp0   2.7.2-5
ii  libopenal1 1:1.19.1-2
ii  libpng16-161.6.38-2
ii  libsdl2-2.0-0  2.24.2+dfsg-1
ii  libsqlite3-0   3.40.0-1
ii  libsquish0 1.15-1+b11
ii  libstdc++6 12.2.0-9
ii  libvorbisfile3 1.3.7-1
ii  supertuxkart-data  1.3+dfsg1-3
ii  zlib1g 1:1.2.11.dfsg-4.1

supertuxkart recommends no packages.

supertuxkart suggests no packages.

-- no debconf information

Bug#1024580: r-bioc-affxparser: FTBFS on hppa - cannot handle R_PARISC_PCREL17F

[John David Anglin]

Source: r-bioc-affxparser
Version: 1.70.0-1
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

Build fails here:
g++ -std=gnu++14 -shared -L/usr/lib/R/lib -o affxparser.so 
fusion/calvin_files/data/src/CDFData.o 
fusion/calvin_files/data/src/CDFProbeGroupInformation.o 
fusion/calvin_files/data/src/CDFProbeInformation.o 
fusion/calvin_files/data/src/CDFProbeSetInformation.o 
fusion/calvin_files/data/src/CDFQCProbeInformation.o 
fusion/calvin_files/data/src/CDFQCProbeSetInformation.o 
fusion/calvin_files/data/src/CELData.o 
fusion/calvin_files/data/src/CHPBackgroundZone.o 
fusion/calvin_files/data/src/CHPData.o 
fusion/calvin_files/data/src/CHPExpressionEntry.o 
fusion/calvin_files/data/src/CHPMultiDataData.o 
fusion/calvin_files/data/src/CHPTilingData.o 
fusion/calvin_files/data/src/CHPQuantificationData.o 
fusion/calvin_files/data/src/CHPQuantificationDetectionData.o 
fusion/calvin_files/data/src/CHPGenotypeEntry.o 
fusion/calvin_files/data/src/CHPUniversalEntry.o 
fusion/calvin_files/data/src/ColumnInfo.o 
fusion/calvin_files/data/src/DataGroup.o 
fusion/calvin_files/data/src/DataGroupHeader.o 
fusion/calvin_files/data/src/DataSet.o 
fusion/calvin_files/data/src/DataSetHeader.o 
fusion/calvin_files/data/src/FileHeader.o 
fusion/calvin_files/data/src/GenericData.o 
fusion/calvin_files/data/src/GenericDataHeader.o 
fusion/calvin_files/exception/src/ExceptionBase.o 
fusion/calvin_files/fusion/src/CalvinAdapter/CalvinCELDataAdapter.o 
fusion/calvin_files/fusion/src/CalvinAdapter/CalvinCHPDataAdapter.o 
fusion/calvin_files/fusion/src/FusionBPMAPData.o 
fusion/calvin_files/fusion/src/FusionCDFData.o 
fusion/calvin_files/fusion/src/FusionCDFQCProbeSetNames.o 
fusion/calvin_files/fusion/src/FusionCELData.o 
fusion/calvin_files/fusion/src/FusionCHPData.o 
fusion/calvin_files/fusion/src/FusionProbeSetResults.o 
fusion/calvin_files/fusion/src/GCOSAdapter/GCOSCELDataAdapter.o 
fusion/calvin_files/fusion/src/GCOSAdapter/GCOSCHPDataAdapter.o 
fusion/calvin_files/fusion/src/FusionCHPLegacyData.o 
fusion/calvin_files/fusion/src/FusionCHPMultiDataAccessor.o 
fusion/calvin_files/fusion/src/FusionCHPMultiDataData.o 
fusion/calvin_files/fusion/src/FusionCHPTilingData.o 
fusion/calvin_files/fusion/src/FusionCHPGenericData.o 
fusion/calvin_files/fusion/src/FusionCHPQuantificationData.o 
fusion/calvin_files/fusion/src/FusionCHPQuantificationDetectionData.o 
fusion/calvin_files/parameter/src/ParameterNameValueType.o 
fusion/calvin_files/parsers/src/CDFFileReader.o 
fusion/calvin_files/parsers/src/CelFileReader.o 
fusion/calvin_files/parsers/src/CHPFileReader.o 
fusion/calvin_files/parsers/src/CHPMultiDataFileReader.o 
fusion/calvin_files/parsers/src/CHPTilingFileReader.o 
fusion/calvin_files/parsers/src/CHPQuantificationFileReader.o 
fusion/calvin_files/parsers/src/CHPQuantificationDetectionFileReader.o 
fusion/calvin_files/parsers/src/DataGroupHeaderReader.o 
fusion/calvin_files/parsers/src/DataGroupReader.o 
fusion/calvin_files/parsers/src/DataSetHeaderReader.o 
fusion/calvin_files/parsers/src/DataSetReader.o 
fusion/calvin_files/parsers/src/FileHeaderReader.o 
fusion/calvin_files/parsers/src/FileInput.o 
fusion/calvin_files/parsers/src/GenericDataHeaderReader.o 
fusion/calvin_files/parsers/src/GenericFileReader.o 
fusion/calvin_files/utils/src/AffymetrixGuid.o 
fusion/calvin_files/utils/src/DateTime.o 
fusion/calvin_files/utils/src/FileUtils.o 
fusion/calvin_files/utils/src/StringUtils.o 
fusion/calvin_files/utils/src/checksum.o fusion/file/BPMAPFileData.o 
fusion/file/BPMAPFileWriter.o fusion/file/CDFFileData.o 
fusion/file/CELFileData.o fusion/file/CHPFileData.o fusion/file/FileIO.o 
fusion/file/FileWriter.o fusion/file/TsvFile/ClfFile.o 
fusion/file/TsvFile/PgfFile.o fusion/file/TsvFile/TsvFile.o 
fusion/util/AffxByteArray.o fusion/util/AffxConv.o fusion/util/MsgStream.o 
fusion/util/Util.o fusion/util/Err.o fusion/util/Fs.o fusion/util/Verbose.o 
fusion/util/RowFile.o fusion/util/TableFile.o fusion/util/Convert.o 
R_affx_cel_parser.o R_affx_cdf_parser.o R_affx_cdf_extras.o 
R_affx_bpmap_parser.o R_affx_clf_pgf_parser.o R_affx_chp_parser.o 000.init.o 
-L/usr/lib/R/lib -lR
/usr/bin/ld: 
fusion/calvin_files/data/src/CHPQuantificationData.o(.text._ZN20affymetrix_calvin_io21CHPQuantificationData10AddColumnsERNS_13DataSetHeaderEb+0x6c):
 cannot reach 
231f__ZN20affymetrix_calvin_io13DataSetHeader14AddAsciiColumnERKNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEEi+0,
 recompile with -ffunction-sections
/usr/bin/ld: 
fusion/calvin_files/data/src/CHPQuantificationData.o(.text._ZN20affymetrix_calvin_io21CHPQuantificationData10AddColumnsERNS_13DataSetHeaderEb+0x6c):
 cannot handle R_PARISC_PCREL17F for 
_ZN20affymetrix_calvin_io13DataSetHeader14AddAsciiColumnERKNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEEi
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [/usr/share/R/share/make/shlib.mk:10: affxparser.so] Error 1

Full log is here:

Bug#1024492: libffi: large structs need to be passed by value on hppa

[John David Anglin]

Source: libffi
Version: 3.2.1-9
Severity: normal
Tags: patch

Dear Maintainer,

The following tests fail on hppa:
=== libffi tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../testsuite/config/default.exp as tool-and-target-specific interface 
file.
Running ../../testsuite/libffi.bhaible/bhaible.exp ...
Running ../../testsuite/libffi.call/call.exp ...
FAIL: libffi.call/struct_by_value_3.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_3.c -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.call/struct_by_value_4.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_4.c -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.call/struct_by_value_big.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_big.c -W -Wall -Wno-psabi -O2 execution test
Running ../../testsuite/libffi.closures/closure.exp ...
Running ../../testsuite/libffi.complex/complex.exp ...
Running ../../testsuite/libffi.go/go.exp ...

=== libffi Summary ===

# of expected passes1482
# of unexpected failures6
# of unsupported tests  30
make[3]: *** [Makefile:466: check-DEJAGNU] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libffi=hppa=3.4.4-1=106326=0

This is upstream issue #749:
https://github.com/libffi/libffi/issues/749

Attached is patch to fix the problem on hppa. It is similar to patch
applied to fix issue on sparc64.

Please apply until issue is fixed in upstream source.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.0.9 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/src/pa/ffi.c b/src/pa/ffi.c
index 95e6694..186bf69 100644
--- a/src/pa/ffi.c
+++ b/src/pa/ffi.c
@@ -376,10 +376,26 @@ extern void ffi_call_pa32(void (*)(UINT32 *, extended_cif 
*, unsigned),
 void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void **avalue)
 {
   extended_cif ecif;
+  size_t i, nargs = cif->nargs;
+  ffi_type **arg_types = cif->arg_types;
 
   ecif.cif = cif;
   ecif.avalue = avalue;
 
+  /* If we have any large structure arguments, make a copy so we are passing
+ by value.  */
+  for (i = 0; i < nargs; i++)
+{
+  ffi_type *at = arg_types[i];
+  int size = at->size;
+  if (at->type == FFI_TYPE_STRUCT && size > 8)
+   {
+ char *argcopy = alloca (size);
+ memcpy (argcopy, avalue[i], size);
+ avalue[i] = argcopy;
+   }
+}
+
   /* If the return value is a struct and we don't have a return
  value address then we need to make one.  */
 

Bug#1024457: "apt changelog" fails to display the complete changelog

[David Kalnischkies]

Control: severity -1 important

On Sat, Nov 19, 2022 at 10:42:01PM +0200, Adrian Bunk wrote:
> Severity: serious

Well, no. You haven't provided a reason and I fail to find an obvious
one as apt's key functionality is hardly effected by a not (by default)
working changelog sub-command… could Debian release with this "bug"
unfixed? Certainly, given that it might/likely fails for other reasons
like the online repository not actually providing changelogs.

That said, severity hardly makes a difference for us anyhow as somehow
assigning severity doesn't magically assign free time as well (at "best"
higher values have a negative effect), so grave or wishlist doesn't
really matter, but I suppose important is closer to your hope of getting
that fixed before the release some way.


> debhelper recently started removing older changelog entries from
> binary packages, but the way to get them with apt does not work:

https://salsa.debian.org/apt-team/apt/-/merge_requests/261


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1024271: python-cffi: FTBFS on hppa - c/test_c.py test faults and drops core

[John David Anglin]

On 2022-11-18 4:00 a.m., stefa...@debian.org wrote:

Hi John (2022.11.17_23:22:15_+)

If the python-cffi test checks the passing of structs larger than 8
bytes, then maybe there is a problem:

 From a quick look at the test suite, there are a lot of tests that do
that.

I submitted a patch upstream to fix the libffi test failures on hppa and 
rebuilt libffi for hppa:
https://buildd.debian.org/status/fetch.php?pkg=libffi=hppa=3.4.4-1%2Bb1=1668799491=0

The testsuite is now clean.  Unfortunately, the python-cffi test still fails in 
the same way:

dave@mx3210:~/debian/python-cffi/python-cffi-1.15.1$ gdb -c core
GNU gdb (Debian 12.1-4) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "hppa-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
[New LWP 25666]
Core was generated by `python3.10 -m pytest c/ testing/'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  0xf8d03f94 in ?? ()
(gdb) bt
#0  0xf8d03f94 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) disass 0xf8d03f94-8,0xf8d03f94+8
Dump of assembler code from 0xf8d03f8c to 0xf8d03f9c:
   0xf8d03f8c:  break 0,0
   0xf8d03f90:  depd,z,* r18,39,44,r22
=> 0xf8d03f94:  #f8d03f90
   0xf8d03f98:  depd,z,*= r18,35,52,r22
End of assembler dump.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1024389: python3-ledger: sefault during garbage collection

[David Bremner]

Marcin Owsiany  writes:

> Package: python3-ledger
> Version: 3.2.1-8+b5
> Severity: normal
>
> Dear Maintainer,
>
> Here is a short repro script, that generates a segmentation violation on
> completion. I include a backtrace from GDB, but unfortunately I could not find
> debugging symbols for the ledger extension nor libboost-python.
>

Did you try python3-ledger-dbgsym? You need to enable the debian-debug
archive [1]

[1]: https://wiki.debian.org/HowToGetABacktrace

Bug#1012506: Fix for 64bit big-endian systems

[David Bürgin]

Hello Martin,

thank you for the patches.

Martin Grimm:
> Building opendkim with --with-gnutls disables support for ed25519, so I've 
> taken a closer look at the problematic code and found the culprit code.
> 
> The error comes from the call to the openssl function RSA_sign in 
> libopendkim/dkim.c:3945:
> 
> RSA_sign takes as fifth argument a reference to an unsigned int (4 byte) 
> variable to return the length of the signature.
> The opendkim-code uses a reference to the variable l of type size_t (unsigned 
> long, 8 bytes on s390x) casted as (signed) int reference for this.
> This is fatal for a big endian system.
> 
> I've attached to patches:
> 1.) fix-RSA_sign-call.patch: fixes the call to RSA_sign by using a temporary 
> variable ui_l of the correct type unsigned int to get back the length from 
> RSA_sign and savely assigns the returned value to l after the call.
> 2.) fix-printf-types.patch: fixes several calls of printf in dkim.c that use 
> the signed int specifier "%d" to print size_t arguments. For C99-code "%zu" 
> should be used for size_t variables.

Regarding patch 1: I don’t have access to an s390x machine and I don’t
want to spend too much time assessing this patch. I can apply it, but
please confirm that you have verified that this is the right fix and
that it does not impact the current working build. If someone else can
try it and report back, that would be useful, too.

Regarding patch 2: There are lots of compiler warnings today (eg also
for our current use of OpenSSL APIs). I can apply the patch, but
generally code cleanup is something I prefer done upstream (yeah, I
know …) instead of maintained as Debian patches.

Ciao,
David

Bug#1024271: python-cffi: FTBFS on hppa - c/test_c.py test faults and drops core

[John David Anglin]

On 2022-11-18 4:00 a.m., stefa...@debian.org wrote:

Also, FWIW: before this test suite crash, we had a different test
failure on hppa:https://foss.heptapod.net/pypy/cffi/-/issues/186

Probably, not relevant.  At the time of this commit,

commit 8eb2d2b05626b1cbbed100725bc440709499e8a6
Author: Moxie Bot 
Date:   Mon Feb 24 10:29:20 2020 -0500

    Revamp PA_LINUX and PA_HPUX target closures to use function descriptors.

    2020-02-23  John David Anglin 

The libffi testsuite was not clean.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1024362: ITP: elpa-ol-notmuch -- Emacs org-mode links to notmuch messages and searches

[David Bremner]

Package: wnpp
Severity: wishlist
Owner: David Bremner 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org

* Package name: elpa-ol-notmuch
  Version : 2.0.0
  Upstream Author (Maintainer) : Jonas Bernoulli
* URL : https://git.sr.ht/~tarsius/ol-notmuch/
* License : GPL3+
  Programming Lang: Emacs lisp
  Description : Emacs org-mode links to notmuch messages and searches

This functionality was split from elpa-org-contrib.

I plan to maintain it with the Debian Emacsen team

Bug#1019830: codeblocks: Please transition to wxwidgets3.2

[David Prévot]

Hi,

Le 18/11/2022 à 06:36, Olly Betts a écrit :

On Fri, Nov 18, 2022 at 11:06:07AM +0800, Bo YU wrote:

On Fri, Nov 18, 2022 at 3:34 AM Olly Betts  wrote:


[…]

| I suggest you to pick the current trunk code (r13000), it is not a
| release but it is more stable than 20.03

So they're explicitly saying that r13000 is a better option than what's
currently in testing and unstable.


Maybe the upstream will release stable version before sid freeze, so we can
wait some time to see what happens.

[…]

If upstream make a release before the freeze it should be an easy update
from r13000 to that; if they don't then we release with r13000, which is
better than 20.03 anyway.


Agreed. I’m currently low in spare time myself, but would appreciate any 
team upload (please just add yourself to Uploaders) or NMU if you have 
some cycle to spare!


Cheers

taffit



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024271: python-cffi: FTBFS on hppa - c/test_c.py test faults and drops core

[John David Anglin]

Hi Stefano,

On 2022-11-17 3:37 p.m., Stefano Rivera wrote:

Hi John (2022.11.16_21:17:59_+)

Generally speaking python-cffi test failures point to libffi bugs. So,
I'd start by trying to verify the behaviour of the underlying behaviour
in libffi, from C.

If the python-cffi test checks the passing of structs larger than 8 bytes, then 
maybe there is a problem:
https://github.com/libffi/libffi/issues/749

The hppa libffi code passes these by value.

This seems to have changed in this commit:
commit e4c5d46b0abaa8a12e97f0e0673e3efdda59fab8
Author: Anthony Green 
Date:   Mon Sep 5 12:19:57 2022 -0400

    Pass large structs by value

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1024308: [pkg-php-pear] Bug#1024308: symfony: autopkgtest regression

[David Prévot]

Control: tags -1 ftbfs
Control: clone -1 -2
Control: reassign -2 php-symfony-polyfill 1.26.0-3
Control: retitle -2 php-symfony-polyfill: autopkgtest regression

Le 17/11/2022 à 12:20, Paul Gevers a écrit :

Source: symfony
Version: 5.4.15+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, between 3 November and 
13 November it started to fail in testing. In unstable, the window seems 
to be somewhere between 11 and 13 November, with some failures for 
experimental packages (php-psr-simple-cache/3.0.0-1).


php-symfony-polyfill is affected by the same issue (that currently 
prevents me from providing the latest upstream version), probably 
related to icu latest 72 upstream version.


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024271: python-cffi: FTBFS on hppa - c/test_c.py test faults and drops core

[John David Anglin]

Source: python-cffi
Version: 1.15.1-3
Severity: normal
Tags: ftbfs

Dear Maintainer,

For example, see the following build log:
https://buildd.debian.org/status/fetch.php?pkg=python-cffi=hppa=1.15.1-3=1668250642=0

Running the test under gdb, I get the following backtrace:
(gdb) set args -m pytest c/ testing/
(gdb) r
Starting program: /usr/bin/python3.10 -m pytest c/ testing/
warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.
= test session starts ==
platform linux -- Python 3.10.8, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /home/dave/debian/python-cffi/python-cffi-1.15.1
plugins: openfiles-0.5.0, mock-3.8.2, remotedata-0.3.3, arraydiff-0.5.0, 
hypothesis-6.36.0, astropy-0.10.0, astropy-header-0.2.2, doctestplus-0.12.1, 
filter-subpackage-0.1.1, cov-4.0.0
collected 2043 items

c/test_c.py [Detaching after fork from child process 23024]
[Detaching after fork from child process 23025]
[Detaching after fork from child process 23026]
 [  2%]
...[Detaching after fork from child process 23027]
.[Detaching after fork from child process 23028]
.[Detaching after fork from child process 23029]
.[Detaching after fork from child process 23030]
.
Program received signal SIGILL, Illegal instruction.
0xfaa0ef90 in ?? ()
(gdb) bt
#0  0xfaa0ef90 in ?? ()
#1  0xf55120dc in ffi_call_pa32 () at ../src/pa/linux.S:102
#2  0xf5511b08 in ffi_call (cif=, fn=,
rvalue=, avalue=) at ../src/pa/ffi.c:404
#3  0xf19fa240 in cdata_call (cd=0xf8e07cc8, args=,
kwds=) at c/_cffi_backend.c:3192
#4  0x00045a0c in _PyObject_MakeTpCall (tstate=0xf1a07614, callable=0x0,
args=, nargs=-114179252,
keywords=) at ../Objects/call.c:215
#5  0x00034af8 in _PyObject_VectorcallTstate (kwnames=0x0,
nargsf=, args=, callable=,
tstate=) at ../Include/cpython/abstract.h:112
#6  _PyObject_VectorcallTstate (kwnames=0x0, nargsf=,
args=, callable=, tstate=)
at ../Include/cpython/abstract.h:99
#7  PyObject_Vectorcall (kwnames=0x0, nargsf=,
args=, callable=)
at ../Include/cpython/abstract.h:123
#8  call_function (kwnames=0x0, oparg=,
pp_stack=, trace_info=0xf8f08088, tstate=0xf931c340)
at ../Python/ceval.c:5891
#9  _PyEval_EvalFrameDefault (tstate=0xf931c340, f=0x0,
throwflag=) at ../Python/ceval.c:4213
--Type  for more, q to quit, c to continue without paging--q
Quit

(gdb) directory /home/dave/debian/python3.10/python3.10-3.10.8/Objects
Source directories searched: 
/home/dave/debian/python3.10/python3.10-3.10.8/Objects:$cdir:$cwd
(gdb) directory /home/dave/debian/libffi/libffi-3.4.4/src/pa
Source directories searched: 
/home/dave/debian/libffi/libffi-3.4.4/src/pa:/home/dave/debian/python3.10/python3.10-3.10.8/Objects:$cdir:$cwd
(gdb) bt
#0  0xfaa0ef90 in ?? ()
#1  0xf55120dc in ffi_call_pa32 () at ../src/pa/linux.S:102
#2  0xf5511b08 in ffi_call (cif=, fn=,
rvalue=, avalue=) at ../src/pa/ffi.c:404
#3  0xf19fa240 in cdata_call (cd=0xf8e07cc8, args=,
kwds=) at c/_cffi_backend.c:3192
#4  0x00045a0c in _PyObject_MakeTpCall (tstate=0xf1a07614, callable=0x0,
args=, nargs=-114179252,
keywords=) at ../Objects/call.c:215
#5  0x00034af8 in _PyObject_VectorcallTstate (kwnames=0x0,
nargsf=, args=, callable=,
tstate=) at ../Include/cpython/abstract.h:112
#6  _PyObject_VectorcallTstate (kwnames=0x0, nargsf=,
args=, callable=, tstate=)
at ../Include/cpython/abstract.h:99
#7  PyObject_Vectorcall (kwnames=0x0, nargsf=,
args=, callable=)
at ../Include/cpython/abstract.h:123
#8  call_function (kwnames=0x0, oparg=,
pp_stack=, trace_info=0xf8f08088, tstate=0xf931c340)
at ../Python/ceval.c:5891
#9  _PyEval_EvalFrameDefault (tstate=0xf931c340, f=0x0,
throwflag=) at ../Python/ceval.c:4213
--Type  for more, q to quit, c to continue without paging--
#10 0x000e7854 in _PyEval_EvalFrame (throwflag=0, f=(-142,), tstate=0xf1a07614)
at ../Include/internal/pycore_ceval.h:46
#11 _PyEval_Vector (tstate=0xf1a07614, con=0x0, locals=,
args=, argcount=, kwnames=)
at ../Python/ceval.c:5065
#12 0x00045880 in _PyFunction_Vectorcall (func=,
stack=, nargsf=, kwnames=)
at ../Objects/call.c:342
#13 0x000455cc in PyVectorcall_Call (callable=(-142,), tuple=,
kwargs=) at ../Objects/call.c:255
#14 0x000e43d8 in do_call_core (tstate=0x0, trace_info=0xf8df9a88,
func=(-142,), callargs=,
kwdict=) at ../Python/ceval.c:5915
#15 0x0002f97c in _PyEval_EvalFrameDefault (tstate=0xf931c340, f=0x0,
throwflag=) at ../Python/ceval.c:4277
#16 0x000e7854 in _PyEval_EvalFrame (throwflag=0, f=(-142,), tstate=0xf1a07614)
at ../Include/internal/pycore_ceval.h:46
#17 _PyEval_Vector (tstate=0xf1a07614, con=0x0, locals=,
args=, argcount=, kwnames=)
at ../Python/ceval.c:5065
#18 0x00045880 in _PyFunction_Vectorcall (func=,
stack=, nargsf=, kwnames=)
at ../Objects/call.c:342
--Type  for 

Bug#1023566: libharfbuzz0b: undefined symbol: FT_Get_Transform - impossible to install matlab

[David Williams]

This appears to be a problem with the Matlab installer providing its own
versions of libraries rather than libharfbuzz0b.

Please see:
https://uk.mathworks.com/matlabcentral/answers/364551-why-is-matlab-unable-to-run-the-matlabwindow-application-on-linux
for workarounds.

Best regards,
Dave Williams

On Sun, 06 Nov 2022 20:03:59 +0100 Nicola  wrote:
> Package: libharfbuzz0b
> Version: 5.2.0-2
> Severity: important
>
> Dear Maintainer,
>
> undefined symbol: FT_Get_Transform
>
> It makes impossible to install matlab
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (950, 'testing'), (400, 'unstable'), (300, 'experimental'),
(10, 'stable')
> 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=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE
not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libharfbuzz0b depends on:
> ii  libc6   2.35-3
> ii  libfreetype62.12.1+dfsg-3
> ii  libglib2.0-02.74.0-3
> ii  libgraphite2-3  1.3.14-1
>
> libharfbuzz0b recommends no packages.
>
> libharfbuzz0b suggests no packages.
>
> -- no debconf information
>
>
This email and its attachments may contain confidential and/or privileged 
information.  If you have received them in error you must not use, copy or 
disclose their content to any person.  Please notify the sender immediately and 
then delete this email from your system.  This e-mail has been scanned for 
viruses, but it is the responsibility of the recipient to conduct their own 
security measures. Airbus Operations Limited is not liable for any loss or 
damage arising from the receipt or use of this e-mail.

Airbus Operations Limited, a company registered in England and Wales, 
registration number, 3468788.  Registered office:  Pegasus House, Aerospace 
Avenue, Filton, Bristol, BS34 7PA, UK.

Bug#1023792: slowmovideo: It doesn't work on Debian testing

[david]

Package: slowmovideo
Version: 0.5+git20190116-3+b2
Severity: important

Dear Maintainer,

When launching slowmoUI I get next error:

slowmoUI: symbol lookup error: /lib/libgdal.so.28: undefined symbol: 
_ZN6libdap3DDS7var_endEv

And program doesn't work at all :(

-- 
David

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

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

Versions of packages slowmovideo depends on:
ii  ffmpeg  7:5.1.2-1
ii  libc6   2.36-4
ii  libgcc-s1   12.2.0-9
ii  libopencv-core4.5   4.5.1+dfsg-5
ii  libopencv-imgcodecs4.5  4.5.1+dfsg-5
ii  libopencv-superres4.5   4.5.1+dfsg-5
ii  libopencv-video4.5  4.5.1+dfsg-5
ii  libqt5core5a5.15.6+dfsg-2
ii  libqt5gui5  5.15.6+dfsg-2
ii  libqt5script5   5.15.6+dfsg-2
ii  libqt5widgets5  5.15.6+dfsg-2
ii  libqt5xml5  5.15.6+dfsg-2
ii  libstdc++6  12.2.0-9

slowmovideo recommends no packages.

slowmovideo suggests no packages.

-- no debconf information

Bug#1023633: python3-scalene: can't import (or execute) scalene

[David M. Cooke]

Package: python3-scalene
Version: 1.4.1-1
Severity: important
X-Debbugs-Cc: david.m.co...@gmail.com

Dear Maintainer,

Running scalene, either with the CLI command `scalene`, or `python3.10 -m
scalene`, or `python3.9 -m scalene`, causes this (or similiar) import error:

Traceback (most recent call last):
  File "/usr/bin/scalene", line 33, in 
sys.exit(load_entry_point('scalene==1.4.1', 'console_scripts',
'scalene')())
  File "/usr/bin/scalene", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1006, in _find_and_load_unlocked
  File "", line 688, in _load_unlocked
  File "", line 883, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/scalene/__main__.py", line 4, in

from scalene import scalene_profiler
  File "/usr/lib/python3/dist-packages/scalene/scalene_profiler.py", line 46,
in 
from scalene.scalene_mapfile import ScaleneMapFile
  File "/usr/lib/python3/dist-packages/scalene/scalene_mapfile.py", line 6, in

from scalene import get_line_atomic  # type: ignore
ImportError: cannot import name 'get_line_atomic' from 'scalene'
(/usr/lib/python3/dist-packages/scalene/__init__.py)

The problem is easily traced to the included get_line_atomic C extension
being installed to /usr/lib/scalene/lib, which is not on Python's search
path for modules.  Extension modules should be installed alongside their
pure-Python companions, in /usr/lib/python3/dist-packages (see: every other
Python package with a C extension.)

This also explains why the generated manpage is a duplicate of `python3 -h`.


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

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

Versions of packages python3-scalene depends on:
ii  libc62.36-4
ii  libgcc-s112.2.0-9
ii  libstdc++6   12.2.0-9
ii  python3  3.10.6-1
ii  python3-cloudpickle  2.0.0-1
ii  python3-numpy1:1.21.5-1+b1
ii  python3-rich 12.4.4-1

Versions of packages python3-scalene recommends:
ii  python3-ipython  8.5.0-1
ii  python3-pynvml   11.515.75-1

python3-scalene suggests no packages.

-- no debconf information

Bug#1023501: busybox-static: version 1:1.35.0-3 breaks boot on hppa

[John David Anglin]

Package: busybox-static
Version: 1:1.35.0-2
Severity: normal

Dear Maintainer,

With 1:1.35.0-3, boot ends in initramfs:

Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... 
   
mdadm: No arrays found in config file or automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
mdadm: error opening /dev/md?*: No such file or directory
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  LABEL=ROOT2 does not exist.  Dropping to a shell!


BusyBox v1.35.0 (Debian 1:1.35.0-3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

dave@mx3210:~$ cat /proc/cmdline
root=LABEL=ROOT2 console=ttyS0 HOME=/ rootfstype=xfs clocksource=jiffies 
TERM=xterm palo_kernel=2/vmlinuz

The LABEL=ROOT2 does exist:
dave@mx3210:~$ ls /dev/disk/by-label
BOOT2  DAVE  HOME2  ROOT2  VAR2

There are no mdadm arrays on system.

Reverting to 1:1.35.0-2 and updating affected initrd.img files fixes 

Bug#1019805: 4pane: Please transition to wxwidgets3.2

[david]

>On Fri, 4 Nov 2022, da...@4pane.co.uk wrote:
>
>>>> My apologies for the delay in replying. While the fix itself was easy, I
>>>> wanted to incorporate it into the forthcoming 4pane release, avoiding the
>>>> hassle of an extra RFS.
>>>>
>>>> I've now done this and uploaded it to mentors
>>>> (https://mentors.debian.net/package/4pane/ and
>>>> https://mentors.debian.net/debian/pool/main/4/4pane/4pane_8.0-1.dsc).
>>>> However that gives only a few days for a sponsor to appear before 4pane is
>>>> autoremoved on 8/11. So if you, or someone you know, would be able to do
>>>> this I'd be most grateful. Or if it's possible to delay the autoremoval...
>>>
>>> I'm happy to sponsor.
>>
>> That's great! Thank you.
>>
>>> However, the first thing I notice is that the package
>>> still Build-Depends on libwxgtk3.0-gtk3-dev...
>>> Scott
>>
>> Argh! I'd not noticed that. Now fixed and re-uploaded.
>>
>> I didn't add libwxgtk3.0-gtk3-dev to Build-Conflicts, but it doesn't seem to
>> be necessary: a test build picked the 3.2-dev even though both were present.
>> However I can easily do so if you prefer.
>
>Uploaded.
>
>Can you please commit that Build-Depends change to your packaging repo and
>also tag it "debian/8.0-1"?

Done.

Many thanks for the upload!

David

Bug#1019805: 4pane: Please transition to wxwidgets3.2

[david]

>On Fri, 4 Nov 2022, da...@4pane.co.uk wrote:
>
>> My apologies for the delay in replying. While the fix itself was easy, I
>> wanted to incorporate it into the forthcoming 4pane release, avoiding the
>> hassle of an extra RFS.
>>
>> I've now done this and uploaded it to mentors
>> (https://mentors.debian.net/package/4pane/ and
>> https://mentors.debian.net/debian/pool/main/4/4pane/4pane_8.0-1.dsc). However
>> that gives only a few days for a sponsor to appear before 4pane is
>> autoremoved on 8/11. So if you, or someone you know, would be able to do
>> this I'd be most grateful. Or if it's possible to delay the autoremoval...
>
>I'm happy to sponsor. 

That's great! Thank you.

> However, the first thing I notice is that the package
>still Build-Depends on libwxgtk3.0-gtk3-dev...
>Scott

Argh! I'd not noticed that. Now fixed and re-uploaded.

I didn't add libwxgtk3.0-gtk3-dev to Build-Conflicts, but it doesn't seem to be
necessary: a test build picked the 3.2-dev even though both were present.
However I can easily do so if you prefer.

David

Bug#822061: kalarm: KF5 version requires plasma-workspace to work properly

[David Jarvie]

This bug is no longer applicable. KAlarm no longer uses ktimezoned with Qt5 
because it now uses QTimeZone.

-- 
David Jarvie.
KDE developer, KAlarm author.

Bug#1023381: [php-codesniffer] Failing tests with PHP 8.2

[David Prévot]

Package: php-codesniffer
Version: 3.7.1-1
Severity: important
Control: block 1014460 by -1

There are some tests failure under PHP 8.2 (rc5).

https://qa.debian.org/excuses.php?experimental=1=php-defaults


signature.asc
Description: PGP signature

Bug#1023370: [php-parser] Failing tests with PHP 8.2

[David Prévot]

Package: php-parser
Version: 4.15.1-1
Severity: important
Control: block 1014460 by -1

There are some tests failure under PHP 8.2 (rc5).

https://qa.debian.org/excuses.php?experimental=1=php-defaults


signature.asc
Description: PGP signature

Bug#1023354: [icingaweb2] No php8.2 support

[David Prévot]

Package: icinga2
Version: 2.11.1-1
Severity: important
Control: block 1014460 by -1

Hi Bas,

As you noted recently [1], “icingaweb2 explicitly doesn't support php8.2
upstream yet, their php8.1”, so documenting it as a blocker to the
transition.

1: https://bugs.debian.org/1014460#33

Regards

David


signature.asc
Description: PGP signature

Bug#1023353: [php-faker] Failing tests with PHP 8.2

[David Prévot]

Package: php-faker
Version: 1.20.0+dfsg-1
Severity: important
Control: block 1014460 by -1

Hi Robin,

There are some tests failure under PHP 8.2 (rc5).

https://qa.debian.org/excuses.php?experimental=1=php-defaults

Even if there have been no updated version upstream since July, it
looks like the repository is still active, so hopefully “just”
cherry-picking the needed fixes will be enough.

Here are the current failures:

> There were 2 failures:
> 
> 1) Faker\Test\Core\DateTimeTest::testCentury
> Failed asserting that two strings are equal.
> --- Expected
> +++ Actual
> @@ @@
> -'XIX'
> +'XIII'
> 
> /tmp/autopkgtest-lxc.msk17iv_/downtmp/build.9oU/src/test/Faker/Core/DateTimeTest.php:222
> 
> 2) 
> Faker\Test\GeneratorTest::testUniqueReturnsUniqueGeneratorThatGeneratesUniqueValues
> Failed asserting that two arrays are equal.
> --- Expected
> +++ Actual
> @@ @@
>  Array (
> -0 => 'foo'
> -1 => 'bar'
> +0 => 'bar'
> +1 => 'foo'
>  2 => 'baz'
>  )
> 
> /tmp/autopkgtest-lxc.msk17iv_/downtmp/build.9oU/src/test/Faker/GeneratorTest.php:283
> 
> --

Regards

David


signature.asc
Description: PGP signature

Bug#1023310: josm: Debian version prompts for external updates even though that would break Debian

[David Calman]

Package: josm
Version: 0.0.svn18570+dfsg-1~bpo11+1
Severity: normal
X-Debbugs-Cc: alt.people.davidcal...@gmail.com

Dear Maintainer,

I ran JOSM and it said to update to 18583, which it said was the newest
stable version. That's not even in sid yet, much less stable-backports.
Something official Debian materials say to do is "don't break Debian",
"don't make a Frankendebian", "always install from apt if it's there",
and so on. I wonder if someone more familiar with Debian policies than
me can upgrade the severity to serious upon finding chapter and verse.

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

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
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 josm depends on:
ii  default-jre [java9-runtime] 2:1.11-72
ii  fonts-noto  20201225-1
ii  jmapviewer  2.16+dfsg-1~bpo11+1
ii  libcommons-compress-java1.20-1
ii  libgettext-commons-java 0.9.6-6
ii  openjdk-11-jre [java9-runtime]  11.0.16+8-1~deb11u1
ii  openjfx 11.0.11+0-1
ii  proj-data   7.2.1-1

Versions of packages josm recommends:
ii  josm-l10n  0.0.svn18570+dfsg-1~bpo11+1

josm suggests no packages.

-- no debconf information

Bug#1003729: packages.debian.org: Still missing, worried for bullseye

[David Calman]

Package: www.debian.org
Followup-For: Bug #1003729
X-Debbugs-Cc: alt.people.davidcal...@gmail.com

Dear Maintainer,

It's still missing from packages.debian.org. I'm now worried that Bullseye
will be the same way.

Bug#1023195: /usr/bin/kwin_x11: kwin-x11 : shortcuts for "Move window to Screen xxx" not working anymore

[Erwan David]

Package: kwin-x11
Version: 4:5.26.0-1
Severity: normal
File: /usr/bin/kwin_x11

I have shortcuts to move windows to a different screen. SInce 5.26 (I think ?)
they do not work anymore. I tried changing them and it does not work
either. Changing from the menu on the title bar works.



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable-security'), (600, 'unstable'), 
(500, 'oldstable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, 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 kwin-x11 depends on:
ii  kwin-common4:5.26.0-1
ii  libc6  2.35-4
ii  libepoxy0  1.5.10-1
ii  libgcc-s1  12.2.0-3
ii  libkdecorations2-5v5   4:5.26.0-1
ii  libkf5configcore5  5.98.0-1
ii  libkf5configgui5   5.98.0-1
ii  libkf5configwidgets5   5.98.0-1
ii  libkf5coreaddons5  5.98.0-1
ii  libkf5crash5   5.98.0-1
ii  libkf5globalaccel-bin  5.98.0-1
ii  libkf5globalaccel5 5.98.0-1
ii  libkf5i18n55.98.0-1+b1
ii  libkf5notifications5   5.98.0-1
ii  libkf5plasma5  5.98.0-1
ii  libkf5service-bin  5.98.0-1
ii  libkf5service5 5.98.0-1
ii  libkf5windowsystem55.98.0-1
ii  libkwineffects14   4:5.26.0-1
ii  libkwinglutils14   4:5.26.0-1
ii  libqaccessibilityclient-qt5-0  0.4.1-1+b1
ii  libqt5core5a   5.15.6+dfsg-2
ii  libqt5dbus55.15.6+dfsg-2
ii  libqt5gui5 5.15.6+dfsg-2
ii  libqt5qml5 5.15.6+dfsg-2
ii  libqt5quick5   5.15.6+dfsg-2
ii  libqt5widgets5 5.15.6+dfsg-2
ii  libqt5x11extras5   5.15.6-2
ii  libstdc++6 12.2.0-3
ii  libx11-6   2:1.8.1-2
ii  libxcb-composite0  1.15-1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.15-1
ii  libxcb-render0 1.15-1
ii  libxcb-shape0  1.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb11.15-1
ii  libxi6 2:1.8-1+b1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

Bug#1020758: closed by Debian FTP Masters (reply to Emmanuel Bouthenot ) (Bug#1020758: fixed in msmtp 1.8.22-1)

[David Nebauer]

Thank you very much.

--
Regards,
David

On Sat, 29 Oct 2022 at 06:18, Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the msmtp package:
>
> #1020758: msmtp: upgrade to current upstream version
>
> It has been closed by Debian FTP Masters  
> (reply to Emmanuel Bouthenot ).
>
> 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 Emmanuel Bouthenot 
> ) by
> replying to this email.
>
>
> --
> 1020758: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020758
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 1020758-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 28 Oct 2022 20:47:54 +
> Subject: Bug#1020758: fixed in msmtp 1.8.22-1
> Source: msmtp
> Source-Version: 1.8.22-1
> Done: Emmanuel Bouthenot 
>
> We believe that the bug you reported is fixed in the latest version of
> msmtp, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1020...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Emmanuel Bouthenot  (supplier of updated msmtp package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Fri, 28 Oct 2022 19:57:41 +
> Source: msmtp
> Architecture: source
> Version: 1.8.22-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Emmanuel Bouthenot 
> Changed-By: Emmanuel Bouthenot 
> Closes: 944188 945024 995012 996789 999789 1000761 1017455 1020758
> Changes:
>  msmtp (1.8.22-1) unstable; urgency=medium
>  .
>* New upstream release (Closes: #1020758)
>  - Add support for generating RFC-2822 Message-ID header (Closes: #945024)
>* Remove SetGID bit on msmtp for security reasons. See debian/NEWS for 
> further
>  information (Closes: #995012, #944188)
>* Bump Standards-Version to 4.6.1.0
>* Refresh lintian overrides for msmtp-mta
>* Update German debconf template translation, thanks to Helge Kreutzmann
>  (Closes: #999789)
>* Update Dutch debconf template translation, thanks to Frans Spiesschaert
>  (Closes: #996789)
>* Update Portuguese debconf template translation, thanks to Américo 
> Monteiro
>  (Closes: #1000761)
>* Update Spanish debconf template translation, thanks to Camaleón
>  (Closes: #1017455)
>* Scripts (msmtpq and msmtpqueue) are now installed in /usr/libexec/msmtp
>  instead of /usr/share/doc/msmtp/examples previously.
> Checksums-Sha1:
>  b4aad8ffd63c3d57e309d3032b43a0ce52f4ae22 2200 msmtp_1.8.22-1.dsc
>  d7dc9030a88b795bcdf7aaf9ac0a032e56bd3e54 390692 msmtp_1.8.22.orig.tar.xz
>  3c119fd59e0ae56aeb2557368c3e9bd577ced4fe 488 msmtp_1.8.22.orig.tar.xz.asc
>  8ba3cb7d5dfba1c3b3423e0cb3913c4c13f507cf 20840 msmtp_1.8.22-1.debian.tar.xz
>  929b63465c35201318c60891ed2266baef8a2fd5 9394 msmtp_1.8.22-1_source.buildinfo
> Checksums-Sha256:
>  f33297dde8cb64c977bb209d9604a30fe2f0c3ea72d51156cc98ebdc1b388e0d 2200 
> msmtp_1.8.22-1.dsc
>  1b04206286a5b82622335e4eb09e17074368b7288e53d134543cbbc6b79ea3e7 390692 
> msmtp_1.8.22.orig.tar.xz
>  8d45cd975546902a51beae66fbf08ad2d30a20a4385f34471cd7a16cb6a87705 488 
> msmtp_1.8.22.orig.tar.xz.asc
>  1d97066ca433b708048385a321173d55498a3b1e2030f003442df15f2dc99a37 20840 
> msmtp_1.8.22-1.debian.tar.xz
>  a8b63a9de782ca7a9472917e81ebd2131df33c48b88d2f09c0ea3ef67fbb5753 9394 
> msmtp_1.8.22-1_source.buildinfo
> Files:
>  66ee8badd560e8927dca282a3338d5bf 2200 mail optional msmtp_1.8.22-1.dsc
>  8d4ab680f16e9736e24c749015ae858b 390692 mail optional 
> msmtp_1.8.22.orig.tar.xz
>  a98f2259e072dd7203902dd048661fba 488 mail optional 
> msmtp_1.8.22.orig.tar.xz.asc
>  6aa63a57b942ad34682e907576310dfc 20840 mail optional 
> msmtp_1.8.22-1.debian.tar.xz
>  08427da3f77a829681a268e75466e5c0 9394 mail optional 
> msmtp_1.8.22-1_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEETQ1Tfow3vJnf8QuHSwd3I5KdQsMFAmNcNf0ACgkQSwd3I5Kd
> QsMKQA//Zr+8/gP

Bug#1022976: Acknowledgement (plasma-workspace-data: digital clock widget lacks a module)

[Erwan David]

Sorry, upgrade to 5.26 had been partial ending it (with an apt 
dist-upgrade) solved the problem.

Bug#1022976: plasma-workspace-data: digital clock widget lacks a module

[Erwan David]

Package: plasma-workspace-data
Version: 4:5.26.0-2
Severity: normal

digital clock widget gives following error (worked in plasma 5.25)

file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/main.qml:15:1:
 module "org.kde.plasma.workspace.calendar" is not installed


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable-security'), (600, 'unstable'), 
(500, 'oldstable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, 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

-- no debconf information

Bug#1022830: apt ignores versioned provides if non-matching version is installed via another dep

[David Kalnischkies]

reassign -1 libruby3.1,ruby-csv
retitle -1 libruby3.1 and ruby-csv are providing different things under the 
same name

On Thu, Oct 27, 2022 at 12:32:16AM +0900, Marc Dequènes wrote:
> I had a weird FTBFS in #1022340 and it looks like the resolver is just
> skipping the versioned dep because another dep provides the same virtual
> package. Unfortunately it does not resolve the required version and should
> install the non-virtual package providing the right version (they are
> co-installable). More info in the referenced BR.
[…]
> Could you have a look please?

$ apt-cache showpkg ruby-csv
[…]
Reverse Provides:
libruby3.1 3.1.2-3 (= 3.2.2)
libruby3.0 3.0.4-8 (= 3.1.9)
libruby2.7 2.7.4-1+deb11u1 (= 3.1.2)


You are right that libruby3.0 which provides 3.1.9 is not enough to
satisfy the build-dependency of redmine, but libruby3.1 is installed,
too, and that certainly does satisfy ruby-csv (>= 3.2.0). It is
therefore correct for apt to not install the real ruby-csv package
as that dependency is already satisfied.

You might or might not be able to workaround this with Build-Conflicts,
but in the end libruby3.1 and ruby-csv should really agree on what they
are providing at what version or not… hence reassigning to both.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

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#1022199: apt: certificate verification fails after adding custom root certificates through ca-certificates

[David Kalnischkies]

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


signature.asc
Description: PGP signature

Bug#1022701: plank: Plank does not reset to the edge of the screen when the resolution changes

[David mohammed]

Package: plank
Version: 0.11.89-4+b1
Severity: important
X-Debbugs-Cc: davidmoham...@gmail.com

Dear Maintainer,

Whenever the resolution increases - for example changing in virtualbox from 
800x600 to something higher, or moving from a laptop screen to a 4K screen when 
the laptop lid is closed on a dock, plank does not reset itself back to the 
edge of the screen.  Instead, plank stays floating where the original edge used 
to be.

This is a painpoint because a user has to logout and login again - or reach for 
a terminal to kill plank and run it from the terminal again.

During investigation I found that it was due to a Debian specific plank patch

0001_changed-plank-positioning-according-to-workarea.patch

By rebuilding plank without that patch, plank works correctly when the 
resolution changes

So to my issue - why does Debian include this patch? It hasn't been accepted 
upstream but possibly because plank development seems to have gone very quiet.

Could Debian drop this patch?

Alternatively - I am very happy to rework this specific patch for Debian if the 
issue reported is GNOME Shell / Budgie-Desktop specific

(i.e. I am using budgie-desktop on Debian bookworm)

I am thinking possibly something like this bit of pseudo code (obviously 
converted to Vala)

if (the desktop environment is "GNOME Based") then
  run the original code
else
  run the new patch code
endif


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

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

Versions of packages plank depends on:
ii  libc62.35-3
ii  libcairo21.16.0-6
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.74.0-3
ii  libgnome-menu-3-03.36.0-1
ii  libgtk-3-0   3.24.34-3
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libplank10.11.89-4+b1
ii  libwnck-3-0  43.0-2

plank recommends no packages.

Versions of packages plank suggests:
pn  libplank-doc  

-- no debconf information

Bug#1009230: RFP: difftastic -- diff that understands syntax

[David Heidelberg]

Bump, would be great to have it!


On Sat, 9 Apr 2022 12:38:30 +0200 Jakub Wilk  wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name : difftastic
> Version : 0.25.0
> Upstream Author : Wilfred Hughes 
> * URL : https://github.com/Wilfred/difftastic
> * License : Expat
> Programming Lang: Rust
> Description : diff that understands syntax
>
> Difftastic is an experimental diff tool that compares files based on
> their syntax.
>
> --
> Jakub Wilk
>
>

--
David Heidelberg
Consultant Software Engineer

Matrix: @okias:matrix.org

Bug#1022246: device-tree-compiler: FTBFS on hppa - assembler issues

[John David Anglin]

Source: device-tree-compiler
Version: 1.6.1-4
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

Build fails here:
 AS tests/trees.o
tests/trees.S: Assembler messages:
tests/trees.S:256: Error: junk at end of line, first unrecognized character is 
`''
tests/trees.S:257: Error: junk at end of line, first unrecognized character is 
`''
tests/trees.S:258: Error: junk at end of line, first unrecognized character is 
`''
tests/trees.S:219: Error: invalid operands (*UND* and .data sections) for `-'

The GNU assembler on hppa differs in a number of ways with the assembler
on other architectures:

1) The end-of-line character is `!'. `;' introduces a comment.
2) The `.string' directive doesn't add a null termination character.
3) It is strict about the format for characters and junk at end of line.

With the attached patch, the device-tree-compiler package builds successfully
on hppa:
https://buildd.debian.org/status/fetch.php?pkg=device-tree-compiler=hppa=1.6.1-4=1666457482=0

Please push upstream and add to debian/patches if okay.

Thanks,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.16+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Index: device-tree-compiler-1.6.1/flattree.c
===
--- device-tree-compiler-1.6.1.orig/flattree.c
+++ device-tree-compiler-1.6.1/flattree.c
@@ -124,7 +124,7 @@ static void asm_emit_cell(void *e, cell_
 {
FILE *f = e;
 
-   fprintf(f, "\t.byte 0x%02x; .byte 0x%02x; .byte 0x%02x; .byte 0x%02x\n",
+   fprintf(f, "\t.byte 0x%02x\n\t.byte 0x%02x\n\t.byte 0x%02x\n\t.byte 
0x%02x\n",
(val >> 24) & 0xff, (val >> 16) & 0xff,
(val >> 8) & 0xff, val & 0xff);
 }
@@ -133,10 +133,17 @@ static void asm_emit_string(void *e, con
 {
FILE *f = e;
 
+#if defined(__hppa__)
+   if (len != 0)
+   fprintf(f, "\t.stringz\t\"%.*s\"\n", len, str);
+   else
+   fprintf(f, "\t.stringz\t\"%s\"\n", str);
+#else
if (len != 0)
fprintf(f, "\t.string\t\"%.*s\"\n", len, str);
else
fprintf(f, "\t.string\t\"%s\"\n", str);
+#endif
 }
 
 static void asm_emit_align(void *e, int a)
@@ -438,7 +445,11 @@ static void dump_stringtable_asm(FILE *f
 
while (p < (strbuf.val + strbuf.len)) {
len = strlen(p);
+#if defined(__hppa__)
+   fprintf(f, "\t.stringz \"%s\"\n", p);
+#else
fprintf(f, "\t.string \"%s\"\n", p);
+#endif
p += len+1;
}
 }
Index: device-tree-compiler-1.6.1/tests/trees.S
===
--- device-tree-compiler-1.6.1.orig/tests/trees.S
+++ device-tree-compiler-1.6.1/tests/trees.S
@@ -1,6 +1,78 @@
 #include 
 #include "testdata.h"
 
+#ifdef __hppa__
+#define FDTLONG(val) \
+   .byte   ((val) >> 24) & 0xff ! \
+   .byte   ((val) >> 16) & 0xff ! \
+   .byte   ((val) >> 8) & 0xff ! \
+   .byte   (val) & 0xff!
+
+#define TREE_HDR(tree) \
+   .balign 8   ! \
+   .globl  tree! \
+tree:  \
+   FDTLONG(FDT_MAGIC)  ! \
+   FDTLONG(tree##_end - tree) ! \
+   FDTLONG(tree##_struct - tree) ! \
+   FDTLONG(tree##_strings - tree) ! \
+   FDTLONG(tree##_rsvmap - tree) ! \
+   FDTLONG(0x11)   ! \
+   FDTLONG(0x10)   ! \
+   FDTLONG(0)  ! \
+   FDTLONG(tree##_strings_end - tree##_strings) ! \
+   FDTLONG(tree##_struct_end - tree##_struct) !
+
+#define RSVMAP_ENTRY(addrh, addrl, lenh, lenl) \
+   FDTLONG(addrh)  ! \
+   FDTLONG(addrl)  ! \
+   FDTLONG(lenh)   ! \
+   FDTLONG(lenl)
+
+#define EMPTY_RSVMAP(tree) \
+   .balign 8   ! \
+tree##_rsvmap: ! \
+   RSVMAP_ENTRY(0, 0, 0, 0) \
+tree##_rsvmap_end: !
+
+#define PROPHDR(tree, name, len) \
+   FDTLONG(FDT_PROP)   ! \
+   FDTLONG(len)! \
+   FDTLONG(tree##_##name - tree##_strings) !
+
+#define PROP_EMPTY(tree, name) \
+   PROPHDR(tree, name, 0)  !
+
+#define PROP_INT(tree, name, val) \
+   PROPHDR(tree, name, 4) \
+   FDTLONG(val)!
+
+#define PROP_INT64(tree, name, valh, vall) \
+   PROPHDR(tree, name, 8) \
+   FDTLONG(valh)   ! \
+   FDTLONG(vall)   !
+
+#define PROP_STR(tree, name, str) \
+   PROPHDR(tree, name, 55f - 54f) \
+54:\
+   .stringzstr ! \
+55:\
+   .balign 4   !
+
+#define BEGIN_NODE(name) \
+   FDTLONG(FDT_BEGIN_NODE) ! \
+   .stringzname! \
+   .balign 4   !
+
+#define END_NODE \
+   

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[David Prévot]

Hi Ondřej, Mike and Horde team, PHP PEAR and Composer team, and Release 
team.


Le 21/07/2022 à 13:22, David Prévot a écrit :

Le 14/07/2022 à 15:23, Paul Gevers a écrit :
Control: forwarded -1 
https://release.debian.org/transitions/html/php8.2.html

[…]
php-defaults was updated in experimental, allowing us to spot some 
regressions thanks to autopkgtests.


There is a new URL/view, thanks Paul for the hint:

https://qa.debian.org/excuses.php?experimental=1=php-defaults

There are still over twenty packages that need fixing in the Horde camp, 
probably most of them could use a “Restrictions: allow-stderr” 
workaround in debian/tests/control.


Thanks in advance if you can try and help fixing those issues. You’re 
more than welcome to report bugs against packages in order to document 
the problem, and eventual hints to get them fixed.


Severity: important
Control: block 1014460 by -1


I’ve filed three bugs like that (for php-nesbot-carbon, shaarli and 
cacti), am crossing fingers that the latest php-proxy-manager upload 
will fix its issue, and hope that the recent issue that popped up with 
phpunit, phpunit-type and php-doctrine-common (that looks similar) will 
fix itself soon enough too (upstream being usually pretty reactive). 
php-log is still not in testing, so not a blocker.


I believe there are no more blockers that could be spotted with debci. 
Since not all packages have tests, and those tests can’t spot every 
regressions, there will probably be more issues, but I believe it looks 
good for now (especially compared to previous transitions). I believe 
the first (non RC) PHP 8.2 release is expected upstream in a month, so, 
if that’s the targeted version for Bookworm, I hope this transition 
could happen as soon as possible.


Ondřej, there were some missing php8.1-* packages that needed NEW 
processing last time, have all php8.2-* packages been processed this time?


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022229: Failing tests with PHP 8.2

[David Prévot]

Package: cacti
Version: 1.2.22+ds1-1
Severity: important
Control: block 1014460 by -1

Hi Paul,

There are some tests failure under PHP 8.2.

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults

A quick look shows some deprecation messages, but no activity upstream
on the related files.

Regards

David


signature.asc
Description: PGP signature

Bug#1022228: Failing tests with PHP 8.2

[David Prévot]

Package: shaarli
Version: 0.12.1+dfsg-5
Severity: important
Control: block 1014460 by -1

Hi James,

There are some tests failure under PHP 8.2.

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults

Even if there have been no updated version upstream for two years, it
looks like the repository is still active, so hopefully “just”
cherry-picking the needed fixes will be enough.

Regards

David


signature.asc
Description: PGP signature

Bug#1022227: Failing tests with PHP 8.2

[David Prévot]

Package: php-nesbot-carbon
Version: 2.59.1-2
Severity: important
Control: block 1014460 by -1

Hi Robin,

There are some tests failure under PHP 8.2.

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults

Hopefully “just” updating the package to the latest version will make
those go away.

Regards

David


signature.asc
Description: PGP signature

Bug#1022149: ktimetracker total data loss

[David Jarvie]

This looks of it could be the same issue as bug 1021938, which is due to a 
regression in libical version 3.0.15.
--
David Jarvie
KAlarm author, KDE developer

Bug#1021278: pngcheck: CVE-2020-35511

[David da Silva Polverari]

Sorry, I made a mistake when trying to send the link to the closed bug
[1]. You can find the right link below.

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

Regards,
David.

Bug#1021278: pngcheck: CVE-2020-35511

[David da Silva Polverari]

Hi,

I adjusted the affected versions in the BTS, but I couldn't find any
patch for it. The reference to buffer overflows seem related to
CVE-2020-27818, so I wonder whether it is a duplicate or not.

If it is, it was already closed in [1].

[1] CVE-2020-27818

Regards,
David

Bug#1014304: nvidia-tesla-450-driver: Not all hardware works with nvidia-graphics-drivers-tesla-470

[David Headland]

Hi Andreas,

I'll have to say, I didn't even think to try something newer after the 
problems I'd had last time. I do apologise, that was my mistake. 510 
seems to work a treat, thanks very much indeed for suggesting it — 
please feel free to ignore my previous comments!


All the best,
-David.

On 20/10/2022 16:43, Andreas Beckmann wrote:

Control: reassign -1 nvidia-tesla-470-driver
Control: tag -1 upstream

On 20/10/2022 16.54, David Headland via pkg-nvidia-devel wrote:

Package: nvidia-tesla-450-driver
Version: 450.203.03-1



As per bug 981114, unfortunately the 470 driver does not work with my
hardware, whereas the 450 driver does - I have to switch monitors
regularly, and with anything newer than 450 this then causes a loss of
sync on the display.


Have you tried the 510 driver series? (Either as nvidia-driver in sid or 
as nvidia-tesla-driver in sid or testing.)



I suppose there's not a lot that can be done about this, it doesn't
seem to affect many people so I may just have to bite the bullet and
change my video card, but I wanted to at least point this out here.



Andreas

Bug#1014304: nvidia-tesla-450-driver: Not all hardware works with nvidia-graphics-drivers-tesla-470

[David Headland]

Package: nvidia-tesla-450-driver
Version: 450.203.03-1
Followup-For: Bug #1014304

Dear Maintainer,

As per bug 981114, unfortunately the 470 driver does not work with my
hardware, whereas the 450 driver does - I have to switch monitors
regularly, and with anything newer than 450 this then causes a loss of
sync on the display.

I suppose there's not a lot that can be done about this, it doesn't
seem to affect many people so I may just have to bite the bullet and
change my video card, but I wanted to at least point this out here.

All the best,
-David.


-- Package-specific info:
uname -a:
Linux scrat 5.19.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1 (2022-09-24) 
x86_64 GNU/Linux

/proc/version:
Linux version 5.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-6) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP 
PREEMPT_DYNAMIC Debian 5.19.11-1 (2022-09-24)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  450.203.03  Wed Jun 29 00:05:08 
UTC 2022
GCC version:  gcc version 11.3.0 (Debian 11.3.0-8) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP108 [GeForce GT 
1030] [10de:1d01] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd GP108 [GeForce GT 1030] 
[1458:375c]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Oct 20 15:47 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Oct 20 15:47 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Oct 20 15:47 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Oct 20 15:47 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Oct 20 15:47 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Oct 20 15:47 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Oct 20 15:47 pci-:01:00.0-render -> ../renderD128
video:x:44:dh,mythtv

Alternative 'nvidia':
nvidia - manual mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/tesla-450
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvcuvid.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so
  slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
  slave nvidia--libnvidia-allocator.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.1
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-ptxjitcompiler.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1
  slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy
  slave nvidia--nvidia-application-profiles-key-documentation is 
/usr/share/nvidia/nvidia-application-profiles-key-documentation
  slave nvidia--nvidia-blacklists-nouveau.conf is 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh
  slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump
  slave nvidia--nvidia-drm-outputclass.conf is 
/etc/nvidia/nvidia-drm-outputclass.conf
  slave nvidia--nvidia-drm_gbm.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/gbm/nvidia-drm_gbm.so
  slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf
  slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf
  slave nvidia--nvidia-options.conf is /etc/modprobe.d/nvidia-options.conf
  slave nvidia--nvidia-settings is /usr/bin/nvidia-settings
  slave nvidia--nvidia-settings.1.gz is /usr/share/man/man1/nvidia-settings.1.gz
  slave nvidia--nvidia-settings.desktop is 
/usr/share/applications/nvidia-settings.desktop
  slave nvidia--nvidia-smi is /usr/bin/nvidia-smi
  slave nvidi

Bug#1022114: RFH: highlight -- Universal source code to formatted text converter

[David Bremner]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: affects -1 src:highlight

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I request assistance with maintaining the highlight package.

I have not really been keeping up with new upstream releases and could
use a co-maintainer.

The package description is:
 A utility that converts sourcecode to HTML, XHTML, RTF, LaTeX, TeX,
 SVG, XML or terminal escape sequences with syntax highlighting.  It
 supports several programming and markup languages.  Language
 descriptions are configurable and support regular expressions.  The
 utility offers indentation and reformatting capabilities.  It is
 easily possible to create new language definitions and colour themes.


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmNRIyoACgkQA0U5G1Wq
FSGyjQ/8CbUEHtTj0Rad0xZAdVULj9B3EqJN9H35YyUatq85rbdJ69p1cMLgWiu0
hQbypoCRyn+swf30+Slc7X8tIlmKoqxkDJOiqGl5uLdgEUmMB5Ael89ZUCQU+yh5
m2BPAYWb6AuU0uJPPXBGIfIcw54ZtzzGMarvgd7PTlxEOYBaSZo+mkzO4YB/AoXc
xLSSXUp8mW3kqQoQEtyJ5NlwfFVoaERUIJcJXHurtd3wWk8NCbqau+10/m/oyem8
AzRHzEzu8FsIadYlK6jyvCtcuHY6WwEVnA++qsWd92CjBza2nmb2bjS8bgRRC/JS
K/gcK2bf2zA2J4o6BKJgfSmTO9rzp0hb4CwYv/91ecM/rNB8mBvUIYzZn1caKbGZ
N758k9HcyMDywEdZ8Ue2fl0hmYg0/skO7FJEB2TIfnAhqJlQ6n+MexRLIVTAJ8zW
1omcULUhnW3c6IdK8WmM6DuX76iO1QGkrslMU3opsKvy8G4jOyp8l3qh3oqd6uWj
hXknT5lPaE936qd6xDn2dy4niB07W0FhSWBpb9jb3nb5G1pkoWbx/iRjmRT+v0KU
QB50EoNYZDVWw9AyI0wTkU3NwanWWIggG6lpripCoirxaqlDkkJxe5VH0N9fZncZ
irLYONNifkBHonshPaDgIYGTN5U55NlaVPs58p95GGvNw+61dmg=
=GkDM
-END PGP SIGNATURE-

Bug#765740: Hope support for multiple ESPs can be upstreamed from Ubuntu -> Debian

[David Orman]

I've attempted the same with no success, I do not believe this has been 
integrated, at least as of Debian 11.5. I do hope this is upstreamed at some 
point, as it's a big win for those setting up systems without hardware raid but 
require the ability to survive OS disk failures and still boot without a lot of 
manual setup.

On Wed, 11 Aug 2021 10:38:45 -0400 Frank Myhr  wrote:
> I ran into this yesterday while installing Bullseye on a UEFI system 
> with multiple drives and ESPs. Here are a couple of links describing how 
> Ubuntu's multi-ESP works:
> 
> https://unix.stackexchange.com/questions/621942/mirroring-efi-system-partition-esp-on-ubuntu
> 
> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1466150
> 
> I tried running
> dpkg-reconfigure grub-efi-amd64
> on my multi-ESP Bullseye system in the hope that the Ubuntu support may 
> have been upstreamed, but alas it has not yet happened. I'll ask on 
> Ubuntu list as well whether someone is working on upstreaming.
> 
> 

Bug#932347: kalarm: Multiple akonadi_kalarm_resource processes are spawned on kalarm start and consume lot of CPU

[David Jarvie]

Note that from version 20.08 onwards (i.e. Bullseye or later), kalarm no 
longer uses Akonadi for calendar access, so this problem can no longer occur. 

-- 
David Jarvie.
KDE developer, KAlarm author.

Bug#1022066: olive-editor: New versions of olive are not packaged for Debian

[david]

Package: olive-editor
Version: 20220815+ds-3
Severity: wishlist

Dear Maintainer,

I have visited olive editor web and seen that new versions are delivered on
a monthly basis, more or less. Version in Debian is very obsolete and I'd like
to have them available.

Thank you very much.

-- 
David

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

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

Versions of packages olive-editor depends on:
ii  ffmpeg 7:5.1.2-1
ii  frei0r-plugins 1.8.0-1+b1
ii  libavcodec59   7:5.1.2-1
ii  libavfilter8   7:5.1.2-1
ii  libavformat59  7:5.1.2-1
ii  libavutil577:5.1.2-1
ii  libc6  2.35-3
ii  libgcc-s1  12.2.0-3
ii  libopencolorio2.1  2.1.2+dfsg1-4
ii  libopenexr-3-1-30  3.1.5-4
ii  libopenimageio2.3  2.3.18.0+dfsg-5
ii  libportaudio2  19.6.0-1.2
ii  libqt5core5a   5.15.4+dfsg-5
ii  libqt5dbus55.15.4+dfsg-5
ii  libqt5gui5 5.15.4+dfsg-5
ii  libqt5multimedia5-plugins  5.15.4-2
ii  libqt5widgets5 5.15.4+dfsg-5
ii  libstdc++6 12.2.0-3
ii  libswresample4 7:5.1.2-1
ii  libswscale67:5.1.2-1

olive-editor recommends no packages.

olive-editor suggests no packages.

-- no debconf information

Bug#836873: kalarm: The Akonadi personal information management service is not operational

[David Jarvie]

Note that from version 20.08 onwards (i.e. Bullseye or later), kalarm no 
longer uses Akonadi for calendar access, so this problem no longer exists. 
Akonadi is now only used for functions such as migration of resources from 
previous versions, birthday import and email functions. Failure of Akonadi 
will only affect those particular functions.

-- 
David Jarvie.
KDE developer, KAlarm author.

Bug#1021938: kalarm: .local/share/kalarm/expired.ics is not a valid iCalendar file

[David Jarvie]

This is due to a regression in libical version 3.0.15. It is fixed in libical 
3.0.16 (which is in unstable). See https://bugs.kde.org/show_bug.cgi?
id=460442.

-- 
David Jarvie.
KDE developer, KAlarm author.

Bug#1022050: ukui-control-center: FTBFS on hppa - stub table overflow

[John David Anglin]

Source: ukui-control-center
Version: 3.0.5.1-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

The build fails linking libkeyboard.so:
rm -f libkeyboard.so
g++ -Wl,-O1 -Wl,-rpath-link,/usr/lib/hppa-linux-gnu -shared -o libkeyboard.so 
switchbutton.o hoverwidget.o closebutton.o imageutil.o fixlabel.o iconlabel.o 
titlelabel.o keyboardcontrol.o kbdlayoutmanager.o debug.o geometry_components.o 
geometry_parser.o kbpreviewframe.o keyaliases.o keyboard_config.o 
keyboardlayout.o keyboardpainter.o keysym2ucs.o keysymhelper.o symbol_parser.o 
x11_helper.o xkb_rules.o moc_switchbutton.o moc_hoverwidget.o moc_closebutton.o 
moc_fixlabel.o moc_iconlabel.o moc_titlelabel.o moc_keyboardcontrol.o 
moc_kbdlayoutmanager.o moc_kbpreviewframe.o moc_keyboardpainter.o 
moc_x11_helper.o  -L/usr/lib/hppa-linux-gnu -lX11 -lxkbfile -lmatekbd 
-Wl,--export-dynamic -lgmodule-2.0 -pthread -lgdk-3 -lpangocairo-1.0 
-lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgio-2.0 
-lgobject-2.0 -lglib-2.0 -lxklavier -lgsettings-qt 
/usr/lib/hppa-linux-gnu/libQt5Svg.so /usr/lib/hppa-linux-gnu/libQt5Widgets.so 
/usr/lib/hppa-linux-gnu/libQt5X11Extras.so 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5WindowSystem.so
 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5GuiAddons.so
 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5ConfigGui.so
 /usr/lib/hppa-linux-gnu/libQt5Gui.so /usr/lib/hppa-linux-gnu/libQt5Xml.so 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5CoreAddons.so
 /usr/lib/hppa-linux-gnu/libQt5Concurrent.so 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5ConfigCore.so
 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5I18n.so
 /usr/lib/hppa-linux-gnu/libQt5Core.so -lGL -lpthread
g++ -c -pipe -Wno-error -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -Wall -Wextra 
-D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_PLUGIN -DQT_WIDGETS_LIB -DQT_GUI_LIB 
-DQT_XML_LIB -DQT_DBUS_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -I. 
-I../../../../ukui-control-center-3.0.5.1 -I../../../commonComponent 
-I/usr/include/hppa-linux-gnu/qt5/QGSettings -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/hppa-linux-gnu/glib-2.0/include -I/usr/include/hppa-linux-gnu/qt5 
-I/usr/include/hppa-linux-gnu/qt5/QtWidgets 
-I/usr/include/hppa-linux-gnu/qt5/QtGui -I/usr/include/hppa-linux-gnu/qt5/QtXml 
-I/usr/include/hppa-linux-gnu/qt5/QtDBus 
-I/usr/include/hppa-linux-gnu/qt5/QtConcurrent 
-I/usr/include/hppa-linux-gnu/qt5/QtCore -I. -I. 
-I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -o moc_fixlabel.o 
moc_fixlabel.cpp
g++ -c -pipe -Wno-error -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -Wall 
-Wextra -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_PLUGIN -DQT_WIDGETS_LIB 
-DQT_X11EXTRAS_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_DBUS_LIB -DQT_CORE_LIB 
-I. -I../../../commonComponent -I../../../../ukui-control-center-3.0.5.1 
-I/usr/include/hppa-linux-gnu/qt5/QGSettings -I/usr/include/hppa-linux-gnu/qt5 
-I/usr/include/hppa-linux-gnu/qt5/QtWidgets 
-I/usr/include/hppa-linux-gnu/qt5/QtX11Extras 
-I/usr/include/hppa-linux-gnu/qt5/QtGui -I/usr/include/KF5/KConfig 
-I/usr/include/KF5/KConfigCore -I/usr/include/KF5/KI18n 
-I/usr/include/hppa-linux-gnu/qt5/QtConcurrent 
-I/usr/include/hppa-linux-gnu/qt5/QtDBus 
-I/usr/include/hppa-linux-gnu/qt5/QtCore -I. -I. 
-I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -o moc_iconlabel.o 
moc_iconlabel.cpp
/usr/bin/ld: 
geometry_parser.o(.text._ZN5boost6fusion4consINS_6spirit2qi13sequential_orINS1_INS3_14literal_stringIRA5_KcLb1EEENS1_IS9_NS0_4nil_EEENS1_INS3_12literal_charINS2_13char_encoding8standardELb1ELb0EEESA_EEEC2ERKSD_RKSI_[_ZN5boost6fusion4consINS_6spirit2qi13sequential_orINS1_INS3_14literal_stringIRA5_KcLb1EEENS1_IS9_NS0_4nil_EEENS1_INS3_12literal_charINS2_13char_encoding8standardELb1ELb0EEESA_EEEC5ERKSD_RKSI_]+0x48):
 cannot reach 
2bb4__ZN5boost6spirit2qi13sequential_orINS_6fusion4consINS1_14literal_stringIRA5_KcLb1EEENS4_IS9_NS3_4nil_EEC1ERKSD_+0,
 recompile with -ffunction-sections
/usr/bin/ld: 
geometry_parser.o(.text._ZN5boost6fusion4consINS_6spirit2qi13sequential_orINS1_INS3_14literal_stringIRA5_KcLb1EEENS1_IS9_NS0_4nil_EEENS1_INS3_12literal_charINS2_13char_encoding8standardELb1ELb0EEESA_EEEC2ERKSD_RKSI_[_ZN5boost6fusion4consINS_6spirit2qi13sequential_orINS1_INS3_14literal_stringIRA5_KcLb1EEENS1_IS9_NS0_4nil_EEENS1_INS3_12literal_charINS2_13char_encoding8standardELb1ELb0EEESA_EEEC5ERKSD_RKSI_]+0x48):
 cannot handle R_PARISC_PCREL17F for 
_ZN5boost6spirit2qi13sequential_orINS_6fusion4consINS1_14literal_stringIRA5_KcLb1EEENS4_IS9_NS3_4nil_EEC1ERKSD_
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

The failure to handle the R_PARISC_PCREL17F relocation indicates that the
stub table for long call stubs has overflowed.  

Bug#1022023: xrdp: FTBFS on hppa - test timeout

[John David Anglin]

Source: xrdp
Version: 0.9.19-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

See:
https://buildd.debian.org/status/fetch.php?pkg=xrdp=hppa=0.9.19-1%2Bb2=1665886290=0
https://buildd.debian.org/status/fetch.php?pkg=xrdp=hppa=0.9.19-1%2Bb2=1665932047=0
https://buildd.debian.org/status/fetch.php?pkg=xrdp=hppa=0.9.19-1%2Bb2=1666130404=0

Seems similar to the issue reported for armhf.

Probably can be fixed by increasing the timeout value.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#933574: chicken: FTBFS on hppa - stack exhausted running csi

[John David Anglin]

Dear Maintainer,

The stack overflows because the stack is incorrectly configured to
grow downward when in fact the stack on hppa grows upward.  When this
is fixed, build is successful:
https://buildd.debian.org/status/fetch.php?pkg=chicken=hppa=5.3.0-1=1666123017=0

Please push fix upstream and install patch if needed.

Thanks,
Dave Anglin

Index: chicken-5.3.0/Makefile.linux
===
--- chicken-5.3.0.orig/Makefile.linux
+++ chicken-5.3.0/Makefile.linux
@@ -94,7 +94,11 @@ chicken-config.h: chicken-defaults.h
 	echo "#define HAVE_ALLOCA_H 1" >>$@
 	echo "#define HAVE_ERRNO_H 1" >>$@
 	echo "#define HAVE_SYSEXITS_H 1" >>$@
+ifeq ($(ARCH),hppa)
+	echo "#define C_STACK_GROWS_DOWNWARD 0" >>$@
+else
 	echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@
+endif
 ifdef GCHOOKS
 	echo "#define C_GC_HOOKS" >>$@
 endif
Index: chicken-5.3.0/config-arch.sh
===
--- chicken-5.3.0.orig/config-arch.sh
+++ chicken-5.3.0/config-arch.sh
@@ -34,6 +34,7 @@ case "`uname -m`" in
 	*) echo "ppc.sysv";;
 	esac;;
 amd64|x86_64) echo "x86-64";;
+parisc*) echo "hppa";;
 riscv*) echo "riscv";;
 *) ;;
 esac


signature.asc
Description: PGP signature

Bug#1021952: libloc: FTBFS on hppa and alpha - test-network fails

[John David Anglin]

Source: libloc
Version: 0.9.15-2.1
Severity: normal
Tags: ftbfs

Dear Maintainer,

The test-network tests fails and the build fails:

FAIL: src/test-network
==

libloc: loc_network_list_dump:0: 2001:db8::/33
libloc: loc_network_list_dump:1: 2001:db8:8000::/34
libloc: loc_network_list_dump:2: 2001:db8:c000::/35
libloc: loc_network_list_dump:3: 2001:db8:e000::/36
libloc: loc_network_list_dump:4: 2001:db8:f000::/37
libloc: loc_network_list_dump:5: 2001:db8:f800::/38
libloc: loc_network_list_dump:6: 2001:db8:fc00::/39
libloc: loc_network_list_dump:7: 2001:db8:fe00::/40
libloc: loc_network_list_dump:8: 2001:db8:ff00::/41
libloc: loc_network_list_dump:9: 2001:db8:ff80::/42
libloc: loc_network_list_dump:   10: 2001:db8:ffc0::/43
libloc: loc_network_list_dump:   11: 2001:db8:ffe0::/44
libloc: loc_network_list_dump:   12: 2001:db8:fff0::/45
libloc: loc_network_list_dump:   13: 2001:db8:fff8::/46
libloc: loc_network_list_dump:   14: 2001:db8:fffc::/47
libloc: loc_network_list_dump:   15: 2001:db8:fffe::/48
libloc: loc_network_new_from_string: Could not parse network :::/32: 
Invalid argument
libloc: loc_database_open: Opened database in 3.0320ms
Could not look up 2001:db8::
Received subnet1 = 2001:db8::/33
Received subnet2 = 2001:db8:8000::/33
FAIL src/test-network (exit status: 1)

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libloc=hppa=0.9.15-2.1=1665832762=0

A similar fail occurs on alpha.

I tried to debug this.  It appears the call to loc_database_lookup_from_string
fails in this hunk of code:

// Lookup an address in the subnet
err = loc_database_lookup_from_string(db, "2001:db8::", );
if (err) {
fprintf(stderr, "Could not look up 2001:db8::\n");
exit(EXIT_FAILURE);
}
loc_network_unref(network1);

In an attempt to get more info, I added "--enable-debug" to the
configure command.  With this addition, the test succeeds and the build
is successful:

https://buildd.debian.org/status/fetch.php?pkg=libloc=hppa=0.9.15-2.1=1666035323=0

Until this bug is resolved, could you add "--enable-debug" to the configure
options on hppa?

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#1021853: sysprof: FTBFS on hppa - mmap aliasing issue

[John David Anglin]

Source: sysprof
Version: 3.46.0-2
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

The test test-mapped-ring-buffer fails on hppa:

 2/4 =
test: test-mapped-ring-buffer
start time:   14:55:16
duration: 0.40s
result:   killed by signal 6 SIGABRT
command:  GSETTINGS_BACKEND=memory G_DEBUG=gc-friendly MALLOC_PERTURB_=142 
NO_AT_BRIDGE=1 MALLOC_CHECK_=2 G_TEST_SRCDIR=/<>/src/tests 
G_TEST_BUILDDIR=/<>/obj-hppa-linux-gnu/src/tests 
/<>/obj-hppa-linux-gnu/src/tests/test-mapped-ring-buffer
--- stdout ---
# random seed: R02Sb35445e48e2cfa93f89f3c5793901662
1..3
# Start of MappedRingBuffer tests
Bail out! ERROR:../src/tests/test-mapped-ring-buffer.c:43:test_basic_movements: 
'reader' should not be NULL
--- stderr ---
**
ERROR:../src/tests/test-mapped-ring-buffer.c:43:test_basic_movements: 'reader' 
should not be NULL
==

Full build log is here:
https://buildd.debian.org/status/fetch.php?pkg=sysprof=hppa=3.46.0-3=1665759904=0

In map_head_and_body_twice(), the second mmap call fails:

mmap2(NULL, 135168, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xf64a2000
mmap2(0xf64b3000, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0x1000) 
= -1 EINVAL (Invalid argument)

Due to cache issues, all shared mapping of a page must be equivalently
mapped.  This requires page mappings to be at the same virtual address
modulo 4 MB.  Due to a kernel limitation, all mappings to a file must
be equivalent.

The test can be fixed by rounding the buffer_size used in the mapped
ring buffer to 4 MB on hppa.  This makes the two mmap mappings equivalent.

Please send the fix upstream and install if okay.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.15+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Index: sysprof-3.46.0/src/libsysprof-capture/mapped-ring-buffer.c
===
--- sysprof-3.46.0.orig/src/libsysprof-capture/mapped-ring-buffer.c
+++ sysprof-3.46.0/src/libsysprof-capture/mapped-ring-buffer.c
@@ -35,6 +35,7 @@
 
 #define DEFAULT_N_PAGES 32
 #define BUFFER_MAX_SIZE ((UINT32_MAX/2)-_sysprof_getpagesize())
+#define SHM_COLOUR 0x0040
 
 enum {
   MODE_READER= 1,
@@ -172,9 +173,16 @@ mapped_ring_buffer_new_reader (size_t bu
 
   page_size = _sysprof_getpagesize ();
 
-  /* Add 1 page for coordination header */
   if (buffer_size == 0)
 buffer_size = page_size * DEFAULT_N_PAGES;
+
+#ifdef __hppa__
+  /* Round buffer_size up to the shared memory colour boundary */
+  buffer_size += SHM_COLOUR - 1;
+  buffer_size &= ~(SHM_COLOUR - 1);
+#endif
+
+  /* Add 1 page for coordination header */
   buffer_size += page_size;
 
   /* Create our memfd (or tmpfs) for writing */

Bug#1021842: emacs: trampoline compilation error when running buttercup self-tests

[David Bremner]

Package: emacs
Version: 1:28.2+1-1
Severity: important
X-Debbugs-Cc: debian-emac...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Here's the reproducer (tested on a couple of different debian testing
/ unstable machines). This is with Debian's build of emacs 28.2. I
cannot replicate the issue with upstream emacs 28.2 built from source

#--
tempdir=$(mktemp -d)
cd $tempdir
git clone https://github.com/jorgenschaefer/emacs-buttercup.git
cd emacs-buttercup
export HOME=/nope
rm *.elc
emacs -Q -batch -L . -f batch-byte-compile buttercup.el buttercup-compat.el
emacs -Q -batch -L . -l buttercup -f buttercup-run-discover
#--

For me this yields errors of the following form

Traceback (most recent call last):
  normal-top-level()
  command-line()
  command-line-1(("-L" "." "-l" "buttercup" "-f" "buttercup-run-discover"))
  buttercup-run-discover()
  buttercup-run()
  buttercup--run-suites((#s(buttercup-suite "The buttercup--enclosed-expr fu...
  mapc(buttercup--run-suite (#s(buttercup-suite "The buttercup--enclosed-exp...
  buttercup--run-suite(#s(buttercup-suite "For stale `elc' file checks" nil ...
  buttercup--run-suite(#s(buttercup-suite "`buttercup-check-for-stale-elc'" ...
  buttercup--run-spec(#s(buttercup-spec "should do nothing for `el' files" #...
  buttercup--update-with-funcall(#s(buttercup-spec "should do nothing for `e...
  apply(buttercup--funcall (closure ((elc-time . 2) (el-time . 3) t) nil (sp...
  buttercup--funcall((closure ((elc-time . 2) (el-time . 3) t) nil (spy-on '...
  apply((closure ((elc-time . 2) (el-time . 3) t) nil (spy-on 'file-attribut...
  (closure ((elc-time . 2) (el-time . 3) t) nil (spy-on 'file-attributes :an...
  spy-on(file-attributes :and-call-fake (closure ((elc-time . 2) (el-time . ...
  buttercup--spy-on-and-call-replacement(file-attributes (lambda ( args...
  comp-subr-trampoline-install(file-attributes)
  comp-trampoline-compile(file-attributes)
  error("Cannot find suitable directory for output in `native-comp-eln-load-...
error: (error "Cannot find suitable directory for output in 
‘native-comp-eln-load-path’")





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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:28.2+1-1

emacs recommends no packages.

emacs suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmNLCgUACgkQA0U5G1Wq
FSH2+hAAsJ4cDWeqp2qV1uPpUmrhKbaei9A9W4qOvOfksXWn17NfCGyw8vVYzvkr
vcpPQ7KaKy3tALTAENalsUyM7nF+KHQAQQmLOFET0Fwy3Qhx14ZCUbE3+mGy7bMQ
pNt8+0vzcmJ1Oq4J4/81AdZqC6LDwrDTayl7gvOscQLuNhrKz8IrgQtkiNOIBbTl
0KkK3ZvtGqdfprBChziDnzGrWVxLsh5xcenTTh4N5/ysFq+zgPHb/Yp048wLdy+7
wn+eu4z/0xY9EYjixn50YjwRuTFDnCOM764Q71nV6KdveWYWDQScu1aIxQzi+wVM
DutpmmRD4wPnwG3ePVFAz0zsAFhxYt1jXhGzAUkYV/gFxY+eHH31V4I6wUJhLmv1
7ji//z2+1xcDQA+5whs30iq84Q9iT5yeHgJVYSWD30ALeg23/pSnBEWsG6AXWTbV
xAMYlUBW2wLpVocuBtINm/93qLhXJktM8o3ZZcKtjuQM/YqXhTaUfWtvfNRIq1Py
VvMDzA2TZVPJCqL/isLnPR9yIprf7F4UZcmDxEQFmXKj1T8o679zDAqHvUmQiZn3
+uuVjNUTLRzDeBCF6wctY4TgIAj2ARDtsojFLkkc0txZ/VAZPOsPGvzCvqFeuunG
Q9gnpKU0oU35wDll5WG7FDZ7HMShbjPZG+DjpnL+V5CkrbcByTg=
=8U6X
-END PGP SIGNATURE-

Bug#1021758: josm: pt_assistant causes the font in ImproveWay to be unacceptably large

[David Calman]

Package: josm
Version: 0.0.svn18570+dfsg-1~bpo11+1
Severity: normal
X-Debbugs-Cc: alt.people.davidcal...@gmail.com

Dear Maintainer,

I use ImproveWay a lot because when I map a highway in OpenStreetMap
I want the curves to be as smooth as possible. I also downloaded
pt_assistant because it seemed at the time to be the best of the
public transit plug-ins. Unfortunately, this causes the text in
ImproveWay to be unacceptably large, and on occasion also italicized.

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

Kernel: Linux 5.10.0-17-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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 josm depends on:
ii  default-jre [java9-runtime] 2:1.11-72
ii  fonts-noto  20201225-1
ii  jmapviewer  2.16+dfsg-1~bpo11+1
ii  libcommons-compress-java1.20-1
ii  libgettext-commons-java 0.9.6-6
ii  openjdk-11-jre [java9-runtime]  11.0.16+8-1~deb11u1
ii  openjfx 11.0.11+0-1
ii  proj-data   7.2.1-1

Versions of packages josm recommends:
ii  josm-l10n  0.0.svn18570+dfsg-1~bpo11+1

josm suggests no packages.

-- no debconf information

Bug#1021606: libyuv: FTBFS on hppa - broken googletest

[John David Anglin]

Source: libyuv
Version: 0.0~git20220923.b9adaef-1
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

The following tests fail on hppa:

[--] Global test environment tear-down
[==] 3211 tests from 8 test suites ran. (1597834 ms total)
[  PASSED  ] 3169 tests.
[  FAILED  ] 42 tests, listed below:
[  FAILED  ] LibYUVConvertTest.TestNoDither
[  FAILED  ] LibYUVConvertTest.TestDither
[  FAILED  ] LibYUVConvertTest.I420ToARGBToRGB565_Any
[  FAILED  ] LibYUVConvertTest.I420ToARGBToRGB565_Unaligned
[  FAILED  ] LibYUVConvertTest.I420ToARGBToRGB565_Invert
[  FAILED  ] LibYUVConvertTest.I420ToARGBToRGB565_Opt
[  FAILED  ] LibYUVConvertTest.I422ToARGBToRGB565_Any
[  FAILED  ] LibYUVConvertTest.I422ToARGBToRGB565_Unaligned
[  FAILED  ] LibYUVConvertTest.I422ToARGBToRGB565_Invert
[  FAILED  ] LibYUVConvertTest.I422ToARGBToRGB565_Opt
[  FAILED  ] LibYUVConvertTest.ARGBToAR30ToARGB_Any
[  FAILED  ] LibYUVConvertTest.ARGBToAR30ToARGB_Unaligned
[  FAILED  ] LibYUVConvertTest.ARGBToAR30ToARGB_Invert
[  FAILED  ] LibYUVConvertTest.ARGBToAR30ToARGB_Opt
[  FAILED  ] LibYUVConvertTest.ABGRToAR30ToABGR_Any
[  FAILED  ] LibYUVConvertTest.ABGRToAR30ToABGR_Unaligned
[  FAILED  ] LibYUVConvertTest.ABGRToAR30ToABGR_Invert
[  FAILED  ] LibYUVConvertTest.ABGRToAR30ToABGR_Opt
[  FAILED  ] LibYUVConvertTest.AR30ToARGBToABGR_Any
[  FAILED  ] LibYUVConvertTest.AR30ToARGBToABGR_Unaligned
[  FAILED  ] LibYUVConvertTest.AR30ToARGBToABGR_Invert
[  FAILED  ] LibYUVConvertTest.AR30ToARGBToABGR_Opt
[  FAILED  ] LibYUVConvertTest.AR30ToABGRToARGB_Any
[  FAILED  ] LibYUVConvertTest.AR30ToABGRToARGB_Unaligned
[  FAILED  ] LibYUVConvertTest.AR30ToABGRToARGB_Invert
[  FAILED  ] LibYUVConvertTest.AR30ToABGRToARGB_Opt
[  FAILED  ] LibYUVConvertTest.ARGBToAB30ToARGB_Any
[  FAILED  ] LibYUVConvertTest.ARGBToAB30ToARGB_Unaligned
[  FAILED  ] LibYUVConvertTest.ARGBToAB30ToARGB_Invert
[  FAILED  ] LibYUVConvertTest.ARGBToAB30ToARGB_Opt
[  FAILED  ] LibYUVConvertTest.ABGRToAB30ToABGR_Any
[  FAILED  ] LibYUVConvertTest.ABGRToAB30ToABGR_Unaligned
[  FAILED  ] LibYUVConvertTest.ABGRToAB30ToABGR_Invert
[  FAILED  ] LibYUVConvertTest.ABGRToAB30ToABGR_Opt
[  FAILED  ] LibYUVConvertTest.AB30ToARGBToABGR_Any
[  FAILED  ] LibYUVConvertTest.AB30ToARGBToABGR_Unaligned
[  FAILED  ] LibYUVConvertTest.AB30ToARGBToABGR_Invert
[  FAILED  ] LibYUVConvertTest.AB30ToARGBToABGR_Opt
[  FAILED  ] LibYUVConvertTest.AB30ToABGRToARGB_Any
[  FAILED  ] LibYUVConvertTest.AB30ToABGRToARGB_Unaligned
[  FAILED  ] LibYUVConvertTest.AB30ToABGRToARGB_Invert
[  FAILED  ] LibYUVConvertTest.AB30ToABGRToARGB_Opt

42 FAILED TESTS
  YOU HAVE 40 DISABLED TESTS

I believe these are caused by broken googletest on big-endian architectures.
Please add hppa to the list of arches with broken googletest.

Thanks,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.14+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
--- rules.save  2022-10-11 17:05:53.037246365 +
+++ rules   2022-10-11 17:06:19.267489103 +
@@ -26,7 +26,7 @@
 endif
 
 # Known broken googletest
-ifneq (,$(filter $(DEB_HOST_ARCH), armel s390x powerpc ppc64 sparc64))
+ifneq (,$(filter $(DEB_HOST_ARCH), armel hppa s390x powerpc ppc64 sparc64))
   LIBYUV_TEST_FLAG = OFF
 endif
 

Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[David Kalnischkies]

On Mon, Oct 10, 2022 at 08:50:49AM +0800, Paul Wise wrote:
> On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote:
> > I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'.
> 
> That sounds interesting and would be nice generally, however...
> 
> > On a sidenote: What the Depends ensures which the Enhances doesn't is
> > that they are upgraded in lockstep. As in, if for some reason foo (or
> > foo-dbgsym) have their version appear at different points in the archive
> > apt would hold back on a Depends while with Enhances this dependency
> > would be broken and hence auto-remove kicks in.
> 
> For the rolling Debian suites, the main and dbgsym archives are often
> out of sync, the dbgsym packages updates sometimes appear first and
> sometimes second. Keeping foo/foo-dbgsym in sync is strongly needed

Oh, are they? I thought they would be better in sync. Never noticed,
but I tend to have extremely luck avoiding any kind of apt problem… 


Anyway, that is solvable. An 'upgrade' e.g. keeps back an upgrade if
that would break a Recommends. Seems reasonable to keep it back also
if it would break a previously satisfied Enhances as loosing the
features of a plugin due to an automatic upgrade seems super-bad.

For full-upgrade we could go with a rule specifically targeted at
packages from the 'debug' section with such Enhances dependencies.
If you have multiple architectures of an M-A:same package installed
they keep each other in check as well as long as the "old" version
is still downloadable. So that shouldn't be too hard™…

The downside is that both are heuristics which are solver dependent, as
such aptitude likely and external solvers surely won't support that
(without implementing similar solution optimisation logic).

That said, this isn't really different from "miss-using" Depends for it
to have it be hold-back as is not working with every solver in every
situation either. For apt I am actually somewhat surprised if it does in
the general case as the -dbgsym should have close to no power (as
nothing depends on it), while the thing it has debug symbols for probably
has things depending on it, so if it comes to upgrading foo or keeping
it back it should favour upgrading foo (and hence removing foo-dbgsym)
in most cases currently (full-upgrade that is, upgrade of course not).


Anyway, if that is an acceptable/desirable option we should probably
move any apt machinery discussion into its own bugreport and away from
d-d@ and debhelper. For this thread I would say its enough to decide if
using Enhances in this way is acceptable for everyone.

If and how apt (and/or other tools) make then use of the data is up to
them in the end.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1021505: mir: FTBFS on hppa - symbols

[John David Anglin]

Source: mir
Version: 1.8.2+dfsg-3
Severity: normal
Tags: ftbfs

Dear Maintainer,

For example, see:
https://buildd.debian.org/status/fetch.php?pkg=mir=hppa=1.8.2%2Bdfsg-4=1665340087=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[David Kalnischkies]

 idea for
various reasons (hence why apt likes to go on a remove spree if that is
deemed more beneficial), but that would lead us too far off-topic here…


So, could that be an acceptable Option c) ?


Best regards

David Kalnischkies

¹ this example was explicitly chosen as its possible that you
  want to use them independently. I don't see a lot of reasons for
  independent usage of e.g. asc and asc-music even if its of
  course possible.


signature.asc
Description: PGP signature

Bug#1021479: RFS: openarc/1.0.0~beta3+dfsg-1~exp3 -- Authenticated Received Chain (ARC) milter

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : openarc
   Version  : 1.0.0~beta3+dfsg-1~exp3
   Upstream contact : The Trusted Domain Project 
 * URL  : https://github.com/trusteddomainproject/OpenARC
 * License  : GPL-3+ with AutoConf exception, BSD-2-clause and SOSL
 * Vcs  : https://salsa.debian.org/debian/openarc
   Section  : mail

The source builds the following binary packages:

  openarc - Authenticated Received Chain (ARC) milter
  libopenarc-dev - Authenticated Received Chain (ARC) library (development 
files)
  libopenarc0 - Authenticated Received Chain (ARC) library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/openarc/openarc_1.0.0~beta3+dfsg-1~exp3.dsc

Changes since the last upload:

 openarc (1.0.0~beta3+dfsg-1~exp3) experimental; urgency=medium
 .
   * Update debian/watch to monitor GitHub tags instead of releases page.
   * Bump Standards-Version to 4.6.1 without further changes.

Thank you,
David

Bug#1021453: magics++: Please disable dependency on libodc-dev and odc on hppa

[John David Anglin]

Source: magics++
Version: 4.12.1-2
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

The hppa runtime is 32-bit, so the dependencies on odc need to be
disabled.

The attached change fixes the build of magics++ on hppa.

Please install.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.14+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
--- control.save2022-10-08 17:49:35.318524304 +
+++ control 2022-10-08 17:51:01.099290711 +
@@ -12,8 +12,8 @@
  libemos-dev (>=  2:4.3.9), libgeotiff-dev,
  libeccodes-dev (>= 2.13.0-3),
  libeccodes-tools,
- libodc-dev [!powerpc !armel !armhf !i386 !mipsel],
- odc [!powerpc !armel !armhf !i386 !mipsel],
+ libodc-dev [!powerpc !armel !armhf !hppa !i386 !mipsel],
+ odc [!powerpc !armel !armhf !hppa !i386 !mipsel],
  libemos-bin, 
  libopenjp2-7-dev,
  libaec-dev,
@@ -65,7 +65,7 @@
 Depends: libmagplus3v5 ( = ${binary:Version} ), 
  ${misc:Depends}, ${ecbuild:Depends},
  python3, libmagics++-metview-dev, libterralib-dev, magics++,
- libodc-dev [!powerpc !armel !armhf !i386 !mipsel]
+ libodc-dev [!powerpc !armel !armhf !hppa !i386 !mipsel]
 Recommends: pkg-config
 Description: Development files for ECMWF  plotting software MAGICS++
  Magics++ is the latest generation of the ECMWF's Meteorological plotting

Bug#1021440: emboss: FTBFS on hppa - no java

[John David Anglin]

Source: emboss
Version: 6.6.0+dfsg-11
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

The emboss package does not currently build on hppa because of a lack
of java support.

The attached patch adds support for the nojava profile and fixes building
on hppa except for the jemboss package which need java.

See for build log:
https://buildd.debian.org/status/fetch.php?pkg=emboss=hppa=6.6.0%2Bdfsg-11=1665246248=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.14+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
--- control.save2022-02-18 13:43:27.0 +
+++ control 2022-10-08 14:29:05.879080150 +
@@ -5,7 +5,7 @@
 Section: science
 Priority: optional
 Build-Depends: debhelper-compat (= 13),
-#  javahelper,
+#  javahelper [!hppa] ,
libx11-dev,
x11proto-core-dev,
libgdchart-gd2-xpm-dev,
@@ -19,8 +19,8 @@
sharutils,
tcsh | csh | c-shell,
 # Needed until the following is solved: 
https://sourceforge.net/tracker/?func=detail=3033326_id=93650=605031
-   default-jdk,
-   ant
+   default-jdk [!hppa] ,
+   ant [!hppa] 
 # #Build-Depends-Indep: default-jdk
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/med-team/emboss
@@ -142,6 +142,7 @@
 
 Package: jemboss
 Architecture: all
+Build-Profiles: 
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  emboss,
--- rules.save  2022-10-07 22:14:29.265495688 +
+++ rules   2022-10-08 14:35:04.872301169 +
@@ -16,6 +16,13 @@
 VERSION=$(DEB_VERSION_UPSTREAM)
 RENAMED := cons pscan
 
+# Disable java packages on architecture that don't have
+# an openjdk port.
+nojava_archs = hppa
+ifneq (,$(filter $(DEB_HOST_ARCH), $(nojava_archs)))
+export DEB_BUILD_PROFILES += nojava
+endif
+
 EMBOSS-TMP  = $(CURDIR)/debian/emboss_tmp
 EMBOSS  = $(CURDIR)/debian/emboss
 EMBOSS-TEST = $(CURDIR)/debian/emboss-test
@@ -25,8 +32,11 @@
 CONFFLAGS   += --libdir=/usr/lib/emboss/lib
 CONFFLAGS   += --includedir=/usr/lib/emboss/include
 CONFFLAGS   += --enable-systemlibs
+
+ifeq ($(filter nojava,$(DEB_BUILD_PROFILES)),)
 CONFFLAGS   += --with-java=/usr/lib/jvm/default-java/include
 CONFFLAGS   += --with-javaos=/usr/lib/jvm/default-java/include/linux
+endif
 
 CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
@@ -42,9 +52,11 @@
 
 override_dh_auto_build:
dh_auto_build -- AJAX_FIXED_ROOT=\\\"/usr/share/EMBOSS\\\" 
CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(DEB_LDFLAGS)"
+ifeq ($(filter nojava,$(DEB_BUILD_PROFILES)),)
# Add 2 extra files wanted in jemboss.jar
cd jemboss/lib && make jemboss.jar
cd jemboss && jar uf lib/jemboss.jar resources/version 
resources/*.properties
+endif
 
 override_dh_clean:
rm -rf debian/emboss_tmp
@@ -88,6 +100,7 @@
### While the next call repeats a statement from install-arch it is 
needed to get the
### data dir right into place.  Make should be clever enough to not 
duplicate the process
$(MAKE) -C emboss install DESTDIR=$(EMBOSS-TMP)
+ifeq ($(filter nojava,$(DEB_BUILD_PROFILES)),)
$(MAKE) -C jemboss install DESTDIR=$(CURDIR)/debian/jemboss 
bindir=/usr/bin
# install target seems to remove executable flag which is claimed by 
lintian
find debian/jemboss/usr/share/EMBOSS/jemboss/utils -type f -not 
-executable -name "*sh" -exec chmod a+x \{\} \;
@@ -95,6 +108,7 @@
rm debian/jemboss/usr/share/EMBOSS/jemboss/LICENSE
# resources.jar not needed as we use the data files in 
/usr/share/EMBOSS/data/
rm -f debian/jemboss/usr/share/EMBOSS/jemboss/resources/resources.jar
+endif
 
### Installation of the test suite
cp -a test debian/emboss-test/usr/share/EMBOSS/

Bug#1010875: ust: Bogus Build-Dependency makes package BD-Uninstallable on hppa

[John David Anglin]

I believe the attached change fixes the BD-Uninstallable issue on hppa.  The 
problem is the nojava
profile is not considered in determining build dependencies.  It is only 
checked at build time.

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net
--- control.save2022-10-08 15:17:22.584793346 +
+++ control 2022-10-08 15:25:28.799377710 +
@@ -3,11 +3,11 @@
 Maintainer: Jon Bernard 
 Uploaders: Michael Jeanson 
 Build-Depends: debhelper-compat (= 12),
-  default-jdk  | default-jdk-headless ,
+  default-jdk [!hppa]  | default-jdk-headless [!hppa] ,
   dh-python,
   dpkg-dev (>= 1.16.1),
-  javahelper ,
-  liblog4j1.2-java ,
+  javahelper [!hppa] ,
+  liblog4j1.2-java [!hppa] ,
   libnuma-dev,
   liburcu-dev (>= 0.12~),
   pkg-config,

Bug#1021404: qt6-base: FTBFS on hppa - Unknown Q_PROCESSOR_xxx macro

[John David Anglin]

Source: qt6-base
Version: 6.3.1+dfsg-10
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

The build fails here:

[357/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o -c 
/<>/src/corelib/text/qregularexpression.cpp
[358/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o -c 
/<>/src/corelib/io/qfilesystemwatcher.cpp
[359/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 

Bug#1010875: ust: Bogus Build-Dependency makes package BD-Uninstallable on hppa

[John David Anglin]

Source: ust
Version: 2.13.4-1
Followup-For: Bug #1010875

Dear Maintainer,

Changing the control file to use "" instead of ""
resolves the dependency problem on hppa.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#1017377: libstb: incomplete clean target

[David Paul]

On Tue, 27 Sep 2022 12:39:17 -0400
Boyuan Yang  wrote:

> On Mon, 15 Aug 2022 00:54:23 -0500 "David (Plasma) Paul"
>  wrote:
> > Source: libstb
> > Version: 0.0~git20210910.af1a5bc+ds-1
> > Severity: minor
> > X-Debbugs-CC: davidp...@librem.one
...
> > The 'clean' target for the libstb Makefile is incomplete and leaves
> > behind two files, stb_c_lexer.c and stb_divide.c, generated by the
> > '%.c' target.
> > 
> > I have prepared a patch to correct this. I will submit the patch
> > momentarily once I update the changelog entry with the bug number
> > created by this report.  
> 
> While we will fix this issue in Debian, I am just wondering, have you
> reported this issue (possibly together with the patch) to upstream
> project?

I haven't. Given that my patch is limited to editing a Makefile that is
not in the upstream source and is instead added by the Debian
packaging, I saw little reason to do so. Upstream is, of course,
welcome to incorporate the Makefile into the upstream source tree, but
AFAICT the upstream-recommended way of using libstb is to simply copy
individual header files into a program source tree as-needed.

-- 
Plasma

Bug#725434: workaround for injected TMPDIR

[David Schmitt]

This also affects sbuild. To avoid the issue, I've added the following to
my ~/.sbuildrc:

$external_commands = {
"chroot-setup-commands" => [
'runuser -u sbuild -- mkdir -v -m 1777 -p "/tmp/user/1000"',
    ],
};

Regards, David

Bug#1021308: gitolite3: repository "disappears" after upgrade from 3.6.6-1 to 3.6.12-1

[David Bremner]

Control: tag -1 unreproducible

I've tagged this as unreproducible because I don't think there's a
recipe here that permits me to understand what the actual bug in
gitolite is.

Eventually I might find time to investigate it more myself, but if you
want to speed things up, you could provice a sequence of steps that
doesn't involve any private configuration.

BTW, upgrading directly from oldoldstable to stable without going
through oldstable is not supported in general. I don't know if this is
related to your issue, but you can try going to oldstable (3.6.11-2)
first.

It may also help to provide the correct version of all of the
information you say is wrong in the original report.

Bug#1021310: libsdl2: FTBFS on hppa - testevdev: FAILED: 1

[John David Anglin]

On 2022-10-05 11:11 a.m., Simon McVittie wrote:

It seems to be reliable on release architectures, including i386 which is
32-bit and s390x which is big-endian.

Seems to be a 32-bit big-endian issue as same fail occurs on powerpc but not 
ppc64 or ppc64el.
Possibly, wrong word in 64-bit type is being tested on hppa and powerpc.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1021312: qtquickcontrols-opensource-src: FTBFS on hppa - Tests_TreeView::test_pressAndHold

[John David Anglin]

Source: qtquickcontrols-opensource-src
Version: 5.15.6-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Testsuite fails with following error:

PASS   : qtquickcontrols::Tests_TreeView::test_keys_navigation()
FAIL!  : qtquickcontrols::Tests_TreeView::test_pressAndHold() Compared values 
are not the same
   Actual   (): 0
   Expected (): 1
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(274)]
PASS   : qtquickcontrols::Tests_TreeView::test_selection_contiguousSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_extendedSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_multiSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_noSelection()
XFAIL  : qtquickcontrols::Tests_TreeView::test_selection_singleSelection() BUG 
selected state not updated with Command/Control when SingleSelection
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(402)]
XFAIL  : qtquickcontrols::Tests_TreeView::test_selection_singleSelection() BUG 
selected state not updated with Command/Control when SingleSelection
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(404)]
PASS   : qtquickcontrols::Tests_TreeView::test_selection_singleSelection()
PASS   : qtquickcontrols::Tests_TreeView::cleanupTestCase()
Totals: 498 passed, 1 failed, 6 skipped, 0 blacklisted, 410752ms
* Finished testing of qtquickcontrols *
make[5]: *** [Makefile:318: check] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src=hppa=5.15.6-2=1664978713=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1021310: libsdl2: FTBFS on hppa - testevdev: FAILED: 1

[John David Anglin]

Source: libsdl2
Version: 2.24.0+dfsg-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Build fails in testsuite:

Thinkpad USB keyboard with Trackpoint - Trackpoint...
Expected 0x0003
MOUSE
KEYBOARD
Got  0x
No information...
OK
testevdev: FAILED: 1
testfilesystem...
INFO: base path: '/<>/debian/build-tests/'
INFO: pref path: 
'/<>/debian/.debhelper/generated/_source/home/.local/share/libsdl/test_filesystem/'
INFO: pref path: 
'/<>/debian/.debhelper/generated/_source/home/.local/share/test_filesystem/'
testfilesystem: OK
...
testdisplayinfo: OK
make[2]: *** [Makefile:416: check] Error 1
make[2]: Leaving directory '/<>/debian/build-tests'
dh_auto_test: error: cd debian/build-tests && make -j4 check 
"TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 V=1 returned exit code 2
make[1]: *** [debian/rules:142: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:81: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libsdl2=hppa=2.24.1%2Bdfsg-1=1664977752=0

Similar fail occurs on powerpc.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1021282: haskell-charset: FTBFS on hppa - profiling libraries for package hashable-1.3.5.0

[John David Anglin]

Source: haskell-charset
Version: 0.3.9-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

The build fails here:
[4 of 9] Compiling Data.CharSet.Posix.Ascii ( src/Data/CharSet/Posix/Ascii.hs, 
dist-ghc/build/Data/CharSet/Posix/Ascii.p_o )
Failed to load interface for ‘Data.Hashable.Generic.Instances’
Perhaps you haven't installed the profiling libraries for package 
‘hashable-1.3.5.0’?
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 852.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build 
--builddir=dist-ghc returned exit"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 596
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build 
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm 
line 470
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build", 
"--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 650
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=haskell-charset=hppa=0.3.9-1%2Bb2=1664915625=0

For some reason, only libghc-hashable-dev is installed. The profile package
libghc-hashable-prof is not installed.

Some other haskell packages fail in a similar way on hppa.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#1021250: libcom-err2: sudo apt install wine32 fail to install

[David Gonzalo Rodriguez]

Package: libcom-err2
Version: 1.46.5-2~bpo11+2
Severity: important
Tags: upstream
X-Debbugs-Cc: z80u...@gmail.com




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

Kernel: Linux 5.15.60-1-pve (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcom-err2 depends on:
ii  libc6  2.31-13+deb11u4

libcom-err2 recommends no packages.

libcom-err2 suggests no packages.


I install proxmox on Debian on that computer (
https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye ) and
some extra packages and adding the "contrib non-free" for every deb and deb-src
line on /etc/apt/sources.list

sudo apt install gparted gnome-disk-utility firefox-esr mate-desktop-
environment-extra gparted gnome-disk-utility firefox-esr mate-desktop-
environment-extra firmware-linux-free firmware-amd-graphics firmware-linux-
nonfree firmware-realtek proxmox-ve postfix open-iscsi corosync

sudo apt apt remove os-prober

Bug#1021183: opendkim: Opendkim complaining insecure keys by assumption

[David Bürgin]

Patrik Schindler:
> Each and every time, Opendkim wakes up by work from Postfix, it creates
> a log entry:
> 
> key data is not secure: .private is in group 133 which has multiple
> users (e.g., "postfix")
> 
> This issue has been existing since 2015 (when I added DKIM to my mailflow) and
> the according Debian release.
> 
> Opendkim has its own group and for proper access rights from postfix, added
> postfix to the opendkim group. If I don't set this, I get
> 
> Oct  3 14:17:33 myhost postfix/smtpd[123464]: warning: connect to Milter 
> service unix:/var/run/opendkim/opendkim.sock: Permission denied
> 
> Setting RequireSafeKeys to "no" not prevent the message from appearing, but
> just prevents Opendkim from exiting because of this condition.
> 
> I think that group rights should not trigger this behavior, but instead only
> when "other" is allowed to read the private key.

Can you include the steps to reproduce this? I don’t see this behaviour
on my installation (opendkim 2.11.0~beta2-5).

Some of my configuration bits below:

$ grep -i -e keyfile -e userid -e umask -e socket -e requiresafekeys 
/etc/opendkim.conf
KeyFile /etc/dkimkeys/2020.private
UserID  opendkim
UMask   007
Socket  local:/var/spool/postfix/opendkim/opendkim.sock

$ sudo ls -ld /etc/dkimkeys{,/2020.private}
drwx-- 2 opendkim opendkim 4096 Aug 25  2021 /etc/dkimkeys
-rw--- 1 opendkim opendkim 1679 Nov 20  2020 /etc/dkimkeys/2020.private

$ sudo ls -ld /var/spool/postfix/opendkim{,/opendkim.sock}
drwxr-x--- 2 opendkim opendkim 27 Sep 29 16:32 /var/spool/postfix/opendkim
srwxrwx--- 1 opendkim opendkim  0 Sep 29 16:32 
/var/spool/postfix/opendkim/opendkim.sock

$ groups postfix | grep -o opendkim
opendkim

Bug#1020189: helpful-el: FTBFS: make: *** [debian/rules:4: binary] Error 25

[David Bremner]

Lucas Nussbaum  writes:

> Source: helpful-el
> Version: 0.19-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

this seems unrelated to native compilation, probably needs an upstream
fix for emacs 28

Bug#1020192: cycle-quotes: FTBFS: make: *** [debian/rules:4: build] Error 25

[David Bremner]

Lucas Nussbaum  writes:

> Source: cycle-quotes
> Version: 0.1-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>

this seems unrelated to native compilation. It probably needs an
upstream fix for emacs 28. Unfortunately upstream seems dead / static.

Bug#1020143: yasnippet: FTBFS: make[1]: *** [debian/rules:7: override_dh_auto_build] Error 255

[David Bremner]

Lucas Nussbaum  writes:

> Source: yasnippet
> Version: 0.14.0+git20200603.5cbdbf0d-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>

This seems unrelated to native compilation. At a guess, it is because
emacs now includes a new enough org-mode to trigger the previous bug
that caused someone to add a Build-Conflicts with elpa-org.

Bug#1020193: pcre2el: FTBFS: make: *** [debian/rules:4: binary] Error 25

[David Bremner]

Lucas Nussbaum  writes:

> Source: pcre2el
> Version: 1.8-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>

This bug seems unrelated to native compilation, consider checking for an
emacs 28 related fix upstream.

d

Bug#1020195: elisp-bug-hunter: FTBFS: make: *** [debian/rules:4: binary] Error 25

[David Bremner]

Lucas Nussbaum  writes:

> Source: elisp-bug-hunter
> Version: 1.3.1+repack-5
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This bug seems unrelated to native compilation, probably an API change
in emacs28. Consider checking for an upstream fix...

d

Bug#1020029: emacs-deferred: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[David Bremner]

Lucas Nussbaum  writes:

> Source: emacs-deferred
> Version: 0.5.1-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>

This bug seems unrelated to native compilation. Most likely some API
change in emacs 28. Perhaps check for a fix upstream?

d

Bug#1020857: libc6: 2.35-1 breaks gdb on hppa

[John David Anglin]

More info is here:
https://sourceware.org/bugzilla/show_bug.cgi?id=29635

Bug breaks glibc build (gdb attach tests fail) and probably binutils build 
(test regressions).

The problem is the dp register is sometimes not initialized for the main 
application before
initializers are run.

The attached patch fixes issue.  It restores code removed in the fix for the 
tst-audit2 failure
some months ago.  I will commit upstream as soon as more testing completes.  
I'm currently
building a +b1 version of 2.35-1 with change.

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net
diff --git a/sysdeps/hppa/dl-machine.h b/sysdeps/hppa/dl-machine.h
index c865713be1..1d51948566 100644
--- a/sysdeps/hppa/dl-machine.h
+++ b/sysdeps/hppa/dl-machine.h
@@ -347,6 +347,16 @@ elf_machine_runtime_setup (struct link_map *l, struct 
r_scope_elem *scope[],
its return value is the user program's entry point.  */
 
 #define RTLD_START \
+/* Set up dp for any non-PIC lib constructors that may be called.  */  \
+static struct link_map * __attribute__((used)) \
+set_dp (struct link_map *map)  \
+{  \
+  register Elf32_Addr dp asm ("%r27"); \
+  dp = D_PTR (map, l_info[DT_PLTGOT]); \
+  asm volatile ("" : : "r" (dp));  \
+  return map;  \
+}  \
+   \
 asm (  \
 "  .text\n"\
 "  .globl _start\n"\
@@ -426,6 +436,13 @@ asm (  
\
   direct loader invocation.  Thus, argc and argv must be   \
   reloaded from from _dl_argc and _dl_argv.  */\
\
+   /* Load main_map from _rtld_local and setup dp. */  \
+"  addil   LT'_rtld_local,%r19\n"  \
+"  ldw RT'_rtld_local(%r1),%r26\n" \
+"  bl  set_dp, %r2\n"  \
+"  ldw 0(%r26),%r26\n" \
+"  copy%ret0,%r26\n"   \
+   \
/* Load argc from _dl_argc.  */ \
 "  addil   LT'_dl_argc,%r19\n" \
 "  ldw RT'_dl_argc(%r1),%r20\n"\
@@ -438,13 +455,10 @@ asm ( 
\
 "  ldw 0(%r20),%r24\n" \
 "  stw %r24,-44(%sp)\n"\
\
-   /* Call _dl_init(main_map, argc, argv, envp). */\
-"  addil   LT'_rtld_local,%r19\n"  \
-"  ldw RT'_rtld_local(%r1),%r26\n" \
-"  ldw 0(%r26),%r26\n" \
-   \
/* envp = argv + argc + 1 */\
 "  sh2add  %r25,%r24,%r23\n"   \
+   \
+   /* Call _dl_init(main_map, argc, argv, envp). */\
 "  bl  _dl_init,%r2\n" \
 "  ldo 4(%r23),%r23\n" /* delay slot */\
\