Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sun, Apr 28, 2024 at 06:50:30PM +0100, Alberto Bertogli wrote:

I'm still trying to find a reasonable workaround.


I found a workaround to fix the compilation issue, by detecting and not 
building the 64-bit variants when there is asm aliasing for the relevant 
functions.


However, it is now failing some of the tests, because of some weird 
API/ABI issue with the size of off_t.


The calls to the wrapped function are okay, but then the underlying call 
to glibc's functions have the wrong argument sizes :(


So I'm still trying to figure out to make this work.

Alberto

Bug#1070246: libayatana-appindicator version of Debian package does not match the upstream version

[Carlos Alberto Lopez Perez]

Source: libayatana-appindicator
Severity: serious
Version: 0.5.92-1
Version: 0.5.93-1


The package of libayatana-appindicator on Debian is not building from the
right orig tarball as indicated on the package version.

Both package versions on Debian 12 and testing (versions 0.5.92-1 and 0.5.93-1)
are actually version 0.5.90 of upstream.

$ apt-cache policy libayatana-appindicator3-1
libayatana-appindicator3-1:
  Installed: 0.5.92-1
  Candidate: 0.5.92-1
  Version table:
 *** 0.5.92-1 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status

$ zcat /usr/share/doc/libayatana-appindicator3-1/changelog.gz|head
Overview of changes in libayatana-appindicator 0.5.90

  - Mono bindings: Change namespace from ayatana-appindicator-sharp3
to ayatana-appindicator3-sharp (and similar).
  - Port to CMake.
  - Default to GTK+-3.0 as default build flavour.
  - Add Travis CI configuration.
  - Add --keep-env option to dbus-test-runner calls. Allows propagating
e.g. a build HOME into the DBus test environment.


See how on the upstream changelog file it says version "0.5.90"

I have triple checked this by comparing the orig.tar.gz tarball from the Debian
packages VS the ones at 
https://github.com/AyatanaIndicators/libayatana-appindicator/tags

And the version shipped on Debian (both for 0.5.92-1 and 0.5.93-1) is actually 
the upstream 0.5.90 version

Please fix this

Thanks

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sun, Apr 28, 2024 at 01:02:26PM +0100, Alberto Bertogli wrote:
The problem seems to be that some of the functions that have 64-bit 
variants (e.g. pread64, pwrite64) have an assembler name declared for 
the regular variant in the header; while other platforms don't do that 
and have the two functions declared separately.


https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html

For example, this is the declaration of pread and pwrite in a 
post-preprocessed file, diff between x86_64 (without the bug, '-') and 
armel (with the bug, '+'):


```
@@ -1068,18 +,14 @@
extern ssize_t write (int __fd, const void *__buf, size_t __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
-# 389 "/usr/include/unistd.h" 3 4
-extern ssize_t pread (int __fd, void *__buf, size_t __nbytes,
-__off_t __offset)
-__attribute__ ((__access__ (__write_only__, 2, 3)));
-
-
+# 404 "/usr/include/unistd.h" 3 4
+extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off64_t __offset) __asm__ 
("" "pread64")
+__attribute__ ((__access__ (__write_only__, 2, 3)));
+extern ssize_t pwrite (int __fd, const void *__buf, size_t __nbytes, __off64_t __offset) __asm__ 
("" "pwrite64")
-extern ssize_t pwrite (int __fd, const void *__buf, size_t __n,
- __off_t __offset)
__attribute__ ((__access__ (__read_only__, 2, 3)));
# 422 "/usr/include/unistd.h" 3 4
extern ssize_t pread64 (int __fd, void *__buf, size_t __nbytes,
```

That's why it's the assembler (and not linking) stage that's 
complaining, because that means both functions end up named as the 
64-bit variant. This can be seen in the assembly file. Continuing to 
use pread/pread64 as an example, there is no definition for pread(), 
only pread64() twice: once for pread and one for pread64.


It's tricky to support this in a generic way, because it's difficult 
to detect this is even happening, as the assembler name operates at a 
compiler level so we can't just undo it.


More things that make this interesting.

This program:

```
#include 
#include 
#include 

int main() {
printf("pread: %p\n", pread);
printf("pread64: %p\n", pread64);
printf("pread64 is pread: %b\n", pread == pread64);

void *lib = dlopen(NULL, RTLD_NOW);
void *l_pread = dlsym(lib, "pread");
void *l_pread64 = dlsym(lib, "pread64");

printf("l_pread: %p\n", l_pread);
printf("l_pread64: %p\n", l_pread64);
printf("l_pread64 is l_pread: %b\n", l_pread == l_pread64);
}
```

Built with:
  cc -save-temps=obj -D_XOPEN_SOURCE=600 -D_LARGEFILE64_SOURCE=1  -std=c99 
-Wall demo.c

Prints this on x86_64 Debian testing (which does not show this bug):

```
pread: 0x7fc1970f0c10
pread64: 0x7fc1970f0c10
pread64 is pread: 1
l_pread: 0x7fc1970f0c10
l_pread64: 0x7fc1970f0c10
l_pread64 is l_pread: 1
```

And prints this on the armel chroot:

```
pread: 0xf7da6a90
pread64: 0xf7da6a90
pread64 is pread: 1
l_pread: 0xf7da68f8
l_pread64: 0xf7da6a90
l_pread64 is l_pread: 0
```

So on x86_64 both pread() and pread64() are the same function, yet the 
headers allow us to declare them individually.


But on armel, even though there is a separate implementation of pread() 
on libc, the headers prevent us from declaring them separately (because 
of the asm name declaration in unistd.h).


Just putting this here in case it helps someone else debug a similar 
problem in the future.


I'm still trying to find a reasonable workaround.

Thanks,
Alberto

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sat, Apr 20, 2024 at 10:30:20AM +0100, Alberto Bertogli wrote:

On Sat, Apr 20, 2024 at 12:00:00AM +0200, Santiago Vila wrote:

I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.


Oohhh this is good to know, I didn't know that was a viable option.  
Thank you for the suggestion!


I will try to reproduce it this way, I'll let you know how it goes.


I managed to reproduce this the way you suggested, on a Hetzner VM and 
an armel chroot.


The problem seems to be that some of the functions that have 64-bit 
variants (e.g. pread64, pwrite64) have an assembler name declared for 
the regular variant in the header; while other platforms don't do that 
and have the two functions declared separately.


https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html

For example, this is the declaration of pread and pwrite in a 
post-preprocessed file, diff between x86_64 (without the bug, '-') and 
armel (with the bug, '+'):


```
@@ -1068,18 +,14 @@
 
 extern ssize_t write (int __fd, const void *__buf, size_t __n)

 __attribute__ ((__access__ (__read_only__, 2, 3)));
-# 389 "/usr/include/unistd.h" 3 4
-extern ssize_t pread (int __fd, void *__buf, size_t __nbytes,
-__off_t __offset)
-__attribute__ ((__access__ (__write_only__, 2, 3)));
-
-
+# 404 "/usr/include/unistd.h" 3 4
+extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off64_t __offset) __asm__ 
("" "pread64")
 
 
+__attribute__ ((__access__ (__write_only__, 2, 3)));

+extern ssize_t pwrite (int __fd, const void *__buf, size_t __nbytes, __off64_t __offset) __asm__ 
("" "pwrite64")
 
 
-extern ssize_t pwrite (int __fd, const void *__buf, size_t __n,

- __off_t __offset)
 __attribute__ ((__access__ (__read_only__, 2, 3)));
 # 422 "/usr/include/unistd.h" 3 4
 extern ssize_t pread64 (int __fd, void *__buf, size_t __nbytes,
```

That's why it's the assembler (and not linking) stage that's 
complaining, because that means both functions end up named as the 
64-bit variant. This can be seen in the assembly file. Continuing to use 
pread/pread64 as an example, there is no definition for pread(), only 
pread64() twice: once for pread and one for pread64.


It's tricky to support this in a generic way, because it's difficult to 
detect this is even happening, as the assembler name operates at a 
compiler level so we can't just undo it.


I'll keep trying to find a viable workaround for this.

Thanks,
Alberto

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sat, Apr 20, 2024 at 12:00:00AM +0200, Santiago Vila wrote:

El 25/3/24 a las 20:12, Chris Lamb escribió:

Alberto Bertogli wrote:


If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.


Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.


Hi.

I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.


Oohhh this is good to know, I didn't know that was a viable option.  
Thank you for the suggestion!


I will try to reproduce it this way, I'll let you know how it goes.

Thank you!
        Alberto

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Mon, Mar 25, 2024 at 07:12:24PM +, Chris Lamb wrote:

Alberto Bertogli wrote:


If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.


Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.


I totally understand the access part, that's very reasonable on Debian's 
part.


But unfortunately, if I can't even run a local VM to try to reproduce 
the problem, it's too limiting for me. Especially considering the kind 
of issues libfiu often runs into, which tend to be a bit on the esoteric 
side :)




Hm, googling the actual error message a little, I think this might be
a bigger issue... or perhaps more accurately, at least one that has
potentially been also solved elsewhere:

 * Same think in lightdm: <https://bugs.debian.org/1067561>

 * Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils
   <https://www.spinics.net/lists/linux-media/msg230147.html>


Thank you for looking at this!

I think they could be similar; in particular the second one.

Maybe there's something like `#define pread pread64` in the 
architecture's headers that is triggering these errors?




Does this spark anything worth trying? :-)


Maybe seeing the preprocessor output and the actual (temporary) file 
getting the complaints could be useful in figuring out what's going on.


That said, even if we find what the problem is, we may keep finding 
other issues in the future. If I'm not able to have a VM for this
platform where I can try to reproduce problems, I'm not sure it's viable 
to support the package on it :(


Thanks!
Alberto

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sun, Mar 24, 2024 at 06:00:51PM +, Chris Lamb wrote:

Alberto Bertogli wrote:


I'll try to get a debian install to boot for armhf, but it'll take me a
bit because it's not straightforward (to put it mildly :).


Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.


Sorry, yes that's what I meant! To install it under qemu!

Unfortunately, I haven't been able to get it to work.

I managed to get bookworm installed, and then extracted the 
kernel+initrd from inside the virtual disk (as apparently that's 
needed), but the kernel won't boot due to: `Unhandled fault: synchronous 
abort (translation table walk)`.


At this point I'm not really keen on debugging whatever that armhf 
kernel issue is :(


If you know of a functional official image that I can use to try to 
reproduce the problem, or recently-tested steps I can follow to get a 
working qemu install, please let me know.


Thanks,
Alberto

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Mon, Mar 18, 2024 at 12:29:40PM +, Chris Lamb wrote:

Dear Alberto,


Hi!



Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.


Nothing obvious.

It's a bit strange because the "symbol X already defined" errors most 
likely come from the assembler when building the individual files, not 
from linking stage.


While it's impossible to be 100% sure because of the parallel build and 
the lack of command-output correlation in the logs, everything points to 
that being the case.


I'll try to get a debian install to boot for armhf, but it'll take me a 
bit because it's not straightforward (to put it mildly :).


How urgent/important is this issue?

Thanks,
        Alberto




- Original message -
From: Sebastian Ramacher 
To: Debian Bug Tracking System 
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: 
symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM

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

https://buildd.debian.org/status/fetch.php?pkg=libfiu=armhf=1.2-2=1710292712=0

cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I. -I../../libfiu/ -g 
-O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o
/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined
/tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined
/tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined
/tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined
/tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1
/tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined
/tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined
/tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined
/tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined
/tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1





    Alberto

Bug#1066411: webkit2gtk: FTBFS: SharedContextMutex.cpp:219:41: error: inlining failed in call to ‘always_inline’ ‘egl::SharedContextMutex* egl::SharedContextMutex::doTryLock() [with Mute

[Alberto Garcia]

On Thu, Mar 14, 2024 at 11:00:26AM -0400, Jeremy Bícha wrote:
> > - Several undefined references at link time.
> It is caused by a changed in dpkg in Unstable
> 
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Indeed, we were incorrectly adding that flag to CXXFLAGS. I'm
confirming that this fixes everything and I'll upload the new package
asap.

Thanks!

Berto

Bug#1066411: webkit2gtk: FTBFS: SharedContextMutex.cpp:219:41: error: inlining failed in call to ‘always_inline’ ‘egl::SharedContextMutex* egl::SharedContextMutex::doTryLock() [with Mute

[Alberto Garcia]

Control: retitle -1 webkit2gtk: FTBFS due to several undefined references

On Wed, Mar 13, 2024 at 01:05:55PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks, there are two build failures here:

- The one you reported (recursive inlining). This one is also
  affecting wpewebkit (#1066454) but I have a fix for it already.

- Several undefined references at link time. This is reported upstream
  as https://bugs.webkit.org/show_bug.cgi?id=270970 and is still not
  fixed.

I thought these were caused by the new version of gcc in sid but I
tried downgrading the packages and the problem is still there. In
trixie everything works fine.

Since the first problem is already taken care of I'm changing the
title of this bug to that of the second problem.

Berto

Bug#1063223: wpewebkit: NMU diff for 64-bit time_t transition

[Alberto Garcia]

On Thu, Feb 29, 2024 at 09:23:38AM +, Steve Langasek wrote:
> Please find attached a final version of this patch for the time_t
> transition.  This patch is being uploaded to unstable.

Thanks for the patch!

I have a question: soon I'll need to start transitioning the WPE
packages to a new API (we were blocked by the reverse dependencies)
which means libwpewebkit-1.1-0 -> libwpewebkit-2.0-0

Shall I add the 't64' suffix to the new binaries for clarity or is it
unnecessary? In principle they won't have a version without 64-bit
time_t (unless there's a backport which I'm not planning to do).

Berto

Bug#1062540: event-dance: NMU diff for 64-bit time_t transition

[Alberto Garcia]

On Mon, Feb 05, 2024 at 12:08:33PM +, Alberto Garcia wrote:
> > To ensure that inconsistent combinations of libraries with their
> > reverse-dependencies are never installed together, it is necessary
> > to have a library transition, which is most easily done by
> > renaming the runtime library package.
> If the ABI is broken is it normal that the shared library keeps the
> same name ?? (libevd-0.2.so.0 -> libevd-0.2.so.0.0.1)

Never mind, this was already answered in debian-devel:

   https://lists.debian.org/debian-devel/2024/02/msg00074.html

The changes look good to me.

Berto

Bug#1062540: event-dance: NMU diff for 64-bit time_t transition

[Alberto Garcia]

On Thu, Feb 01, 2024 at 09:16:08PM +, mwhud...@debian.org wrote:

> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary
> to have a library transition, which is most easily done by renaming
> the runtime library package.

If the ABI is broken is it normal that the shared library keeps the
same name ?? (libevd-0.2.so.0 -> libevd-0.2.so.0.0.1)

Berto

Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

[Alberto Garcia]

On Mon, Dec 11, 2023 at 02:55:50AM +0100, Kevin Price wrote:
> 3. There seems to be no network connectivity. No WiFi icon. "ping
> 8.8.8.8" returns IIRC network unreachable.

Hi, ThinkPad T14s AMD Gen1 user here, I'm also having lots of problems
with this kernel and this seems related. In particular I cannot even
shut down the system properly because it hangs when trying to stop
Network Manager, I'm attaching some logs.

I also noticed this kernel message during boot, it didn't happen with
earlier kernels:

   r8169 :02:00.0 eth0: rtl_ep_ocp_read_cond == 0 (loop: 10, delay: 1).

The test build from Salvatore seems to fix the problem for me too.

Berto
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne 
Root Complex [1022:1630]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne IOMMU 
[1022:1631]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe 
Dummy Host Bridge [1022:1632]
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe 
Dummy Host Bridge [1022:1632]
00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne 
PCIe GPP Bridge [1022:1634]
00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne 
PCIe GPP Bridge [1022:1634]
00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne 
PCIe GPP Bridge [1022:1634]
00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne 
PCIe GPP Bridge [1022:1634]
00:02.7 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne 
PCIe GPP Bridge [1022:1634]
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe 
Dummy Host Bridge [1022:1632]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir Internal 
PCIe GPP Bridge to Bus [1022:1635]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 51)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
[1022:790e] (rev 51)
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 
24: Function 0 [1022:1448]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 
24: Function 1 [1022:1449]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 
24: Function 2 [1022:144a]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 
24: Function 3 [1022:144b]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 
24: Function 4 [1022:144c]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 
24: Function 5 [1022:144d]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 
24: Function 6 [1022:144e]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 
24: Function 7 [1022:144f]
01:00.0 Non-Volatile memory controller [0108]: SK hynix Gold P31/PC711 NVMe 
Solid State Drive [1c5c:174a]
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0e)
02:00.1 Serial controller [0700]: Realtek Semiconductor Co., Ltd. RTL8111xP 
UART #1 [10ec:816a] (rev 0e)
02:00.2 Serial controller [0700]: Realtek Semiconductor Co., Ltd. RTL8111xP 
UART #2 [10ec:816b] (rev 0e)
02:00.3 IPMI Interface [0c07]: Realtek Semiconductor Co., Ltd. RTL8111xP IPMI 
interface [10ec:816c] (rev 0e)
02:00.4 USB controller [0c03]: Realtek Semiconductor Co., Ltd. RTL811x EHCI 
host controller [10ec:816d] (rev 0e)
03:00.0 Network controller [0280]: MEDIATEK Corp. MT7921 802.11ax PCI Express 
Wireless Network Adapter [14c3:7961]
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI 
Express Card Reader [10ec:522a] (rev 01)
05:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720202 USB 3.0 Host 
Controller [1912:0015] (rev 02)
06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Renoir [1002:1636] (rev d1)
06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir 
Radeon High Definition Audio Controller [1002:1637]
06:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 
17h (Models 10h-1fh) Platform Security Processor [1022:15df]
06:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 
Renoir/Cezanne USB 3.1 [1022:1639]
06:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 
Renoir/Cezanne USB 3.1 [1022:1639]
06:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc. [AMD] 
ACP/ACP3X/ACP6x Audio Coprocessor [1022:15e2] (rev 01)
06:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h/19h 
HD Audio Controller [1022:15e3]
Dec 12 11:37:56 debian systemd[1]: run-user-0.mount: Deactivated successfully.
Dec 12 11:37:56 debian systemd[1]: Unmounted run-user-0.mount - /run/user/0.
Dec 12 11:37:56 debian systemd[1]: run-user-116-gvfs.mount: Deactivated 
successfully.
Dec 12 11:37:56 debian 

Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2

[Alberto Bertogli]

On Sun, Oct 29, 2023 at 02:00:32PM +, Chris Lamb wrote:

Dear Alberto,


I think this is likely a problem I already fixed back in February in
commit 5dcc6d4.


Ah, cherry-picking that commit fixed it for me. I've gone ahead and
uploaded that to Debian in order to close this RC bug, but please do
feel free to also release a libfiu v1.2 as well.

That would have the added advantage of "clearing out" the other patch
we had to apply re. Link-Time Optimisation.


Great!

I've just released libfiu 1.2 then :)

Just in case, one of the possibly-impacting patches is updating to 
setuptools, that may need some adjustments in the build-depends:


https://blitiri.com.ar/git/r/libfiu/c/88b961aad6b1fcbc0e1decbf34a0bc9510600988/

Hopefully with that you can clear the other patch!

Thank you!
        Alberto

Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2

[Alberto Bertogli]

On Sat, Oct 28, 2023 at 09:58:14AM +0100, Chris Lamb wrote:

Hey Alberto,

Hope all is well with you. Just wondering if you received the below
re. a recently-filed bug report against libfiu. I can reproduce it
locally if that helps.


I got it, but I appreciate you forwarding it explicitly anyway just in 
case, and the confirmation of a reproduction!




./wrap-python 3 ./test-basic.py
Can't find python3 bindings, run make python3
make[3]: *** [Makefile:96: py-run-test-basic] Error 1


Looking at this, I don find any issues with the Makefile dependency 
chain itself.


I think this is likely a problem I already fixed back in February in 
commit 5dcc6d4.


https://blitiri.com.ar/git/r/libfiu/c/5dcc6d449dc86d4ba9abc99ac52fd5798e573738/

There have been a few commits since v1.1, I think a v1.2 is probably 
overdue at this point in any case.


Chris, do you want to confirm that patch fixes the issue in the Debian 
build environment? And if so I can just make a 1.2 including it. Do you 
think that would be the most practical course of action here?


Thank you!
Alberto

Bug#1054150: surf: no longer display web pages after webkitgtk upgrades

[Alberto Garcia]

On Wed, Oct 18, 2023 at 05:06:16PM +0900, Dominique Martinet wrote:

> After upgrading my system to the latest security updates surf no
> longer displays anything.

I had a look at this, the problem is caused by Surf's AppArmor
configuration.

I can make it run on my computer with something like this added to
/etc/apparmor.d/usr.bin.surf, but your mileage may vary:

  /sys/devices/virtual/dmi/id/chassis_type r,
  /etc/glvnd/egl_vendor.d/ r,
  /etc/glvnd/egl_vendor.d/** r,
  /usr/share/glvnd/egl_vendor.d/ r,
  /usr/share/glvnd/egl_vendor.d/** r,
  /usr/share/libdrm/* r,  

I think that Surf's AppArmor profile is just too restrictive for a
program that has so many dependencies.

Berto

Bug#1054150: surf: no longer display web pages after webkitgtk upgrades

[Alberto Garcia]

On Wed, Oct 18, 2023 at 05:06:16PM +0900, Dominique Martinet wrote:
> For bullseye, this package upgrade reliably triggers the issue, and
> installing old packages back makes surf work again:
> Unpacking libwebkit2gtk-4.0-37:amd64 (2.42.1-1~deb11u1) over 
> (2.40.5-1~deb11u1) ...
> Unpacking libjavascriptcoregtk-4.0-18:amd64 (2.42.1-1~deb11u1) over 
> (2.40.5-1~deb11u1) ...

I checked and every other WebKitGTK browser that I tested in bullseye
works fine (epiphany, luakit, midori, giara, and WebKitGTK's own
MiniBrowser), so I suspect that there's something odd that Surf is
doing.

Until this is investigated I would just run it with
WEBKIT_DISABLE_COMPOSITING_MODE=1. Surf could also be patched
downstream in Debian to force this, it also needs to force the x11
backend because its Wayland support is broken (see #1012739).

Berto

Bug#1037894: webkit2gtk: ftbfs with GCC-13

[Alberto Garcia]

On Tue, Sep 12, 2023 at 10:28:06AM +0200, Manuel A. Fernandez Montecelo wrote:
> > FYI I have successfully built webkit2gtk 2.40.3-2 in a sid chroot with
> > with gcc-13 13.1.0-7 from experimental.
> 
> Also it built fine with gcc-13 in riscv64, which was rebootstrapped
> in the last weeks and with gcc-13 as the default compiler since the
> start.
> 
> Build for the new archive:
> 
>   2.40.5-1 (sid)  Maybe-Successful  2023-08-28 19:38:30
>   rv-osuosl-03  2d 10h 31m  23.91 GB
> 
>   https://buildd.debian.org/status/logs.php?pkg=webkit2gtk=riscv64
> 
> So I think that this can be closed.

Matthias, what do you say, can we close this?

Berto

Bug#1050168: FTBFS: test_no_local_cert: tlsv13 alert certificate required

[Alberto Bertogli]

On Mon, Aug 21, 2023 at 05:32:53PM +0800, Shengjing Zhu wrote:

Source: kxd
Version: 0.15-4
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: albert...@blitiri.com.ar, z...@debian.org

I'm not sure if it's related to golang-defaults -> golang-1.21 recently.


[...]

Traceback (most recent call last):
 File "/<>/tests/run_tests", line 360, in test_no_local_cert
   self.assertEqual(err.reason, "SSLV3_ALERT_BAD_CERTIFICATE")
AssertionError: 'TLSV13_ALERT_CERTIFICATE_REQUIRED' != 
'SSLV3_ALERT_BAD_CERTIFICATE'
- TLSV13_ALERT_CERTIFICATE_REQUIRED
+ SSLV3_ALERT_BAD_CERTIFICATE


Thanks for filing this!

Yeah I think it's likely, this looks like a more specific and accurate 
error is now reported in this case, either due to the Go TLS library, or 
OpenSSL (which the tests use because they're written in Python).


I have a patch in the `next` branch that should update the test 
accordingly:


https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340/

https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340.patch

Would you mind giving it a try? It should solve the problem.

Thanks!
Alberto

Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.

[Alberto Garcia]

On Wed, May 03, 2023 at 01:32:18PM -0400, Jim Popovitch wrote:
> > Thanks for the report, we'll prepare an update asap.
> > 
> 
> Best wishes!

It took longer than I would have wished, but this is now fixed in
evolution 3.38.3-1+deb11u2

Berto

Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.

[Alberto Garcia]

So what happens is that the Evolution in bullseye is using a
deprecated WebKit API that was removed in the 2.40.x branch (the
function remains but it's a no-op now). Reverting that change in
WebKit is unfortunately not an option.

This was fixed in Evolution upstream a while ago[1] so bookworm is not
affected. The patch was backported to at least Evolution 3.28.5[2] and
3.40.4[3]. The latter can be applied fine to our version (3.38.3) and
fixes the problem for me, I'm putting Milan Crha on Cc for comments
since the patch is not trivial.

I'm also attaching the debdiff for Evolution with this patch included.

The other alternative would be to switch back to WebKitGTK 2.38.x but
that branch is not likely to receive any further security updates.

Berto

[1] https://gitlab.gnome.org/GNOME/evolution/-/issues/2001
[2] 
https://gitlab.com/redhat/centos-stream/rpms/evolution/-/blob/c8s/evolution-3.28.5-frame-flattenning.patch
[3] 
https://gitlab.com/redhat/centos-stream/rpms/evolution/-/blob/c9s/evolution-3.40.4-frame-flattenning.patch
diff -Nru evolution-3.38.3/debian/changelog evolution-3.38.3/debian/changelog
--- evolution-3.38.3/debian/changelog	2022-10-18 22:36:42.0 +0200
+++ evolution-3.38.3/debian/changelog	2023-05-04 00:33:14.0 +0200
@@ -1,3 +1,10 @@
+evolution (3.38.3-1+deb11u2) bullseye-security; urgency=medium
+
+  * Add a patch to make Evolution display email bodies properly when using
+WebKitGTK 2.40.x (Closes: #1035469).
+
+ -- Alberto Garcia   Thu, 04 May 2023 00:33:14 +0200
+
 evolution (3.38.3-1+deb11u1) bullseye; urgency=medium
 
   * Add a patch from upstream to move Google Contacts addressbooks to
diff -Nru evolution-3.38.3/debian/control evolution-3.38.3/debian/control
--- evolution-3.38.3/debian/control	2022-10-18 22:36:42.0 +0200
+++ evolution-3.38.3/debian/control	2023-05-04 00:33:14.0 +0200
@@ -6,7 +6,7 @@
 Section: gnome
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
-Uploaders: Iain Lane , Jeremy Bicha , Laurent Bigonville , Sebastien Bacher 
+Uploaders: Alberto Garcia , Iain Lane , Jeremy Bicha , Laurent Bigonville , Sebastien Bacher 
 Build-Depends: cmake,
debhelper (>= 11),
dh-sequence-gnome,
diff -Nru evolution-3.38.3/debian/patches/frame-flattening.patch evolution-3.38.3/debian/patches/frame-flattening.patch
--- evolution-3.38.3/debian/patches/frame-flattening.patch	1970-01-01 01:00:00.0 +0100
+++ evolution-3.38.3/debian/patches/frame-flattening.patch	2023-05-04 00:33:14.0 +0200
@@ -0,0 +1,478 @@
+From: Milan Crha 
+Subject: Handle frame flattening change in WebKitGTK 2.40.x
+Bug: https://bugs.webkit.org/show_bug.cgi?id=256266
+Bug-Debian: https://bugs.debian.org/1035469
+Origin: https://gitlab.com/redhat/centos-stream/rpms/evolution/-/blob/c9s/evolution-3.40.4-frame-flattenning.patch
+Index: evolution-3.38.3/data/webkit/e-web-view.js
+===
+--- evolution-3.38.3.orig/data/webkit/e-web-view.js
 evolution-3.38.3/data/webkit/e-web-view.js
+@@ -722,6 +722,38 @@ Evo.EnsureMainDocumentInitialized = func
+ 	Evo.initializeAndPostContentLoaded(null);
+ }
+ 
++Evo.mailDisplayUpdateIFramesHeightRecursive = function(doc)
++{
++	if (!doc)
++		return;
++
++	var ii, iframes;
++
++	iframes = doc.getElementsByTagName("iframe");
++
++	/* Update from bottom to top */
++	for (ii = 0; ii < iframes.length; ii++) {
++		Evo.mailDisplayUpdateIFramesHeightRecursive(iframes[ii].contentDocument);
++	}
++
++	if (!doc.scrollingElement || !doc.defaultView || !doc.defaultView.frameElement)
++		return;
++
++	if (doc.defaultView.frameElement.height == doc.scrollingElement.scrollHeight)
++		doc.defaultView.frameElement.height = 10;
++	doc.defaultView.frameElement.height = doc.scrollingElement.scrollHeight + 2 + (doc.scrollingElement.scrollWidth > doc.scrollingElement.clientWidth ? 20 : 0);
++}
++
++Evo.MailDisplayUpdateIFramesHeight = function()
++{
++	var scrolly = document.defaultView ? document.defaultView.scrollY : -1;
++
++	Evo.mailDisplayUpdateIFramesHeightRecursive(document);
++
++	if (scrolly != -1 && document.defaultView.scrollY != scrolly)
++		document.defaultView.scrollTo(0, scrolly);
++}
++
+ if (this instanceof Window && this.document) {
+ 	this.document.onload = function() { Evo.initializeAndPostContentLoaded(this); };
+ 
+@@ -807,9 +839,8 @@ Evo.mailDisplayResizeContentToPreviewWid
+ local_width -= 2; /* 1 + 1 frame borders */
+ 			} else if (!iframes.length) {
+ /* Message main body */
+-local_width -= 8; /* 8 + 8 margins of body without iframes */
+-if (level > 1)
+-	local_width -= 8;
++local_width -= level * 20; /* 10 + 10 margins of body without iframes */
++local_width -= 4;
+ 
+ Evo.addRuleIntoStyleSheetDocument(doc, "-e-mail-formatter-style-sheet", "body", "width: " + local_width + "px;");
+ Evo.addRuleIntoStyl

Bug#1031943: [pkg-netfilter-team] Bug#1031943: Should we do something?

[Alberto Molina Coballes]

I agree with Arturo, the proposed change should be harmless, but we
were not able to reproduce the issue in any of the test performed so I
was thinking to lower the severity and apply the patch but don't ask
to be included in bookworm.

Bug#1033230: webkit2gtk: version 2.39.90-1 lost its libgles2 runtime dependency

[Alberto Garcia]

On Mon, Mar 20, 2023 at 01:29:51PM +0100, Gianfranco Costamagna wrote:

> Hello, for some reasons, now webkit2gtk is not linking anymore
> libGLESv2.so.2 causing surf to fail autopkgtests on arm64 and armhf

Hmmm... the reason is that this is now handled via libepoxy, which
opens libGLESv2.so.2 on runtime using dlopen().

I think that I'll add the dependencies manually for now, but I wonder
if libepoxy should depend on those libraries instead?

Berto

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

On Mon, Mar 20, 2023 at 09:48:36AM -0400, Jeremy Bícha wrote:

> This was a mistake in cherry-picking from the Experimental branch
> where I had previously applied
> https://salsa.debian.org/gnome-team/gnome-builder/-/commit/f87150bc

Maybe it's not a bad idea to let gir:Depends handle this instead, also
for bookworm. But either option is fine with me.

Berto

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

Control: tags -1 patch

debdiff attached

Berto
diff -Nru gnome-builder-43.6/debian/changelog 
gnome-builder-43.6/debian/changelog
--- gnome-builder-43.6/debian/changelog 2023-03-16 01:29:37.0 +0100
+++ gnome-builder-43.6/debian/changelog 2023-03-20 12:45:40.0 +0100
@@ -1,3 +1,11 @@
+gnome-builder (43.6-3) unstable; urgency=medium
+
+  * Team upload
+  * debian/control.in: depend on gir1.2-webkit-6.0 instead of 5.0
+(Closes: #1033224)
+
+ -- Alberto Garcia   Mon, 20 Mar 2023 12:45:40 +0100
+
 gnome-builder (43.6-2) unstable; urgency=medium
 
   * debian/gbp.conf, debian/control.in: Branch for bookworm
diff -Nru gnome-builder-43.6/debian/control gnome-builder-43.6/debian/control
--- gnome-builder-43.6/debian/control   2023-03-16 01:29:37.0 +0100
+++ gnome-builder-43.6/debian/control   2023-03-20 12:45:40.0 +0100
@@ -6,7 +6,7 @@
 Section: editors
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Jeremy Bicha 
+Uploaders: Alberto Garcia , Jeremy Bicha 
 Build-Depends: appstream-util,
at-spi2-core ,
ca-certificates ,
@@ -77,7 +77,7 @@
  gir1.2-jsonrpc-1.0 (>= 3.42.0),
  gir1.2-panel-1 (>= 1.0.0),
  gir1.2-peas-1.0 (>= 1.34.0),
- gir1.2-webkit2-5.0,
+ gir1.2-webkit-6.0,
  python3-gi,
  libvala-dev,
  clang,
diff -Nru gnome-builder-43.6/debian/control.in 
gnome-builder-43.6/debian/control.in
--- gnome-builder-43.6/debian/control.in2023-03-16 01:29:37.0 
+0100
+++ gnome-builder-43.6/debian/control.in2023-03-20 12:45:40.0 
+0100
@@ -73,7 +73,7 @@
  gir1.2-jsonrpc-1.0 (>= 3.42.0),
  gir1.2-panel-1 (>= 1.0.0),
  gir1.2-peas-1.0 (>= 1.34.0),
- gir1.2-webkit2-5.0,
+ gir1.2-webkit-6.0,
  python3-gi,
  libvala-dev,
  clang,

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

Package: gnome-builder
Version: 43.6-2
Severity: serious
Justification: Policy 7.2

gnome-builder 43.6-2 switched the build dependency from WebtKitGTK 5.0
to 6.0 since the former API is no longer available and is going away.

However it still contains a dependency on gir1.2-webkit2-5.0, so it
effectively depends on both 5.0 and 6.0 API builds of WebKitGTK.

Related bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029206

Berto

Bug#1031943: [pkg-netfilter-team] Bug#1031943: ebtables: symlink removal removal code in the postinst does not seem to be working

[Alberto Molina Coballes]

Hi Adrian and Jeremy,

I was trying to reproduce the bug when I've read the reply from
Jeremy, but like Jeremy I've not been able to reproduce it in sid
(with or without merged usr).

The change you propose is perfect (I agree it should be "-h" instead
of "-e" for the test to check if the symlink exists), but it'd be good
to have additional information to reproduce the bug and fix it
properly.

Can you please provide more information about the bug?

Thanks!
Alberto

Bug#1016936: dwz: fails while building assaultcube

[Alberto Garcia]

On Wed, Aug 10, 2022 at 08:03:45AM +0200, Andreas Beckmann wrote:
> dwz: debian/assaultcube/usr/lib/games/assaultcube/ac_client: Unknown 
> debugging section .debug_addr
> dwz: debian/assaultcube/usr/lib/games/assaultcube/ac_server: Unknown 
> debugging section .debug_addr

FWIW this kind of errors can also happen with GCC with -gsplit-dwarf,
I just hit it in WebKitGTK:

   https://gcc.gnu.org/wiki/DebugFission

Berto

Bug#1022791: nmu: 2.4.3.7-4+b3

[Alberto Gonzalez Iniesta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu tripwire_2.4.3.7-4+b3 . ANY . unstable . -m "Rebuild with new libc (Closes 
#1022791)"

Tripwire is statically build and libc updates break it.

Thanks.

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#1004634: A way to include openscenegraph in bookworm?

[Alberto Luaces]

control: severity -1 important

I agree, thanks for noting that as well.  Let's see if I do this 
correctly, I always have problems recalling the details of operating 
with cont...@bugs.debian.org.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004634: A way to include openscenegraph in bookworm?

[Alberto Luaces]

No problem!

Yes, it was more of a philosophical issue.  That is the reason why I am 
leaving this bug report open, in case we get a patch in time or if some 
dependency really needs this plugin.


Regards,

Alberto


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004634: A way to include openscenegraph in bookworm?

[Alberto Luaces]

Hi, those are currently my thoughts as well.

I'm going to prepare a release like that, and we can see if any of the 
reverse dependencies is actively using this plugin; maybe some games as 
openmw are displaying movies, we will see.


Regards,

Alberto


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Alberto Garcia]

On Mon, Sep 26, 2022 at 04:00:30PM +0300, Adrian Bunk wrote:
> I had the worst possible outcome on the porterbox:
> The reference build succeeded unchanged.  :-(
> 
> I'll check again if your disabling of unified builds does not work.

I decided to upload 2.38.0-2 without unified builds, hopefully it'll
work.

Berto

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Alberto Garcia]

On Sun, Sep 25, 2022 at 10:03:15AM +0200, Mathieu Malaterre wrote:
> On Sat, Sep 24, 2022 at 7:42 PM Simon McVittie  wrote:
> > webkit2gtk repeatedly failed to compile on the mipsel buildds:
> 
> Here is the trick I used on those arches for openvdb:
> 
> [...]
> # Disable optimization on mipsel because the compiler is running out of memory
> # see #847752 / #879636
> ifneq (,$(filter $(DEB_BUILD_ARCH), armel armhf i386 mipsel hppa
> riscv64 sh4 x32))
>   CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
> endif

At the moment we are using -Os --param ggc-min-expand=10

   
https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.38.0-1/debian/rules#L66

I'll try disabling unified builds.

Berto

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Alberto Garcia]

On Sat, Sep 24, 2022 at 06:39:25PM +0100, Simon McVittie wrote:

> webkit2gtk repeatedly failed to compile on the mipsel buildds:
> 
> :
> > FAILED: 
> > Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-3a52ce78-32.cpp.o
> >  
> > /usr/bin/ccache /usr/bin/c++ [long command-line removed]
> > virtual memory exhausted: Cannot allocate memory
> 
> Can we perhaps disable the use of "unified" sources (fewer, larger
> translation units) for architectures where address space is
> limited?  Or maybe tell the compiler not to attempt memory-hungry
> optimizations, or something like that?

I was talking to Adrian Bunk about this a couple of days ago, he
was trying to build webkit in a mipsel buildd using different
alternatives.

Adrian, did you figure something out?

> I see this unreleased commit is available in git:
> https://salsa.debian.org/webkit-team/webkit/-/commit/e92e4c4654e6fd116ef30c5cc767cc25b675ed1f
> which might also help.

According to Adrian it probably won't (I didn't test it yet).

Berto

Bug#1004634: openscenegraph: FTBFS with ffmpeg 5.0

[Alberto Luaces]

Hi PaulLi,

this is highly appreciated.  Thanks a lot for your effort!

I have stored the patch in the repo for reference:

https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/commit/d5babb29f1233a9b111be88fd1037aebb5211c54

Regards,

Alberto

On 20/9/22 19:56, Ying-Chun Liu (PaulLiu) wrote:

Hi all,

I've patched the audio part. But not completed. The video part needs 
more changes. But I don't have enough time now.


Just attach the partial patch I made so that when someone has time or I 
have time then we can continue it.


Yours,
Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017274: marked as pending in kxd

[Alberto Bertogli]

Control: tag -1 pending

Hello,

Bug #1017274 in kxd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/kxd/-/commit/d1348471769b27e0770c3b892476fd286447f804


Don't run dwz after build (Closes: #1017274)

dwz does not properly support Go, and will fail on binaries built with Go 1.19.

This patch makes the build system skip the dwz step. This is the same
workaround used by the chasquid package.

This fixes FTBFS bug #1017274
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017274).


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1017274

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Tue, Nov 09, 2021 at 09:22:36PM +0100, Alberto Garcia wrote:

> FYI I decided to give this package for adoption. I'll request its
> removal from the archive if there are no volunteers to take over its
> maintenance after some time.
> 
> https://bugs.debian.org/998660

I just requested its removal:

https://bugs.debian.org/1018077

Berto

Bug#1016224: binutils-z80: FTBFS: stdlib.h:134:10: error: argument 1 is null but the corresponding size argument 3 value is [128, 9223372036854775807] [-Werror=nonnull]

[Alberto Garcia]

Control: tags -1 fixed-upstream

On Fri, Jul 29, 2022 at 06:20:14PM +0200, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.

> > In function ‘mbstowcs’,
> > inlined from ‘read_symbol_name’ at read.c:1670:11:
> > /usr/include/x86_64-linux-gnu/bits/stdlib.h:134:10: error: argument 1 is 
> > null but the corresponding size argument 3 value is [128, 
> > 9223372036854775807] [-Werror=nonnull]
> >   134 |   return __mbstowcs_alias (__dst, __src, __len);
> >   |  ^~

Hi,

this has been fixed in binutils upstream, is the normal binutils
package not affected?

   
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5858ac626e548772407c038b09b7837550b127dd

I can fix this in binutils-z80 but I'd rather have the fix in the
binutils-source package directly.

Berto

Bug#1010166: webkit2gtk: 2.36.1-1 apparent regression seen in devhelp autopkgtest

[Alberto Garcia]

On Mon, Apr 25, 2022 at 11:37:02AM -0400, Jeremy Bicha wrote:

> The new release of webkit2gtk won't migrate to Testing because of an
> autopkgtest regression in devhelp. I'm filing this bug to make sure
> that the maintainer notices the issue.

This has been fixed upstream but I think I'll just wait for the next
stable release instead of patching the current one.

Berto

Bug#1010352: wpewebkit: No longer provides libsoup2 version needed by gstreamer

[Alberto Garcia]

On Fri, Apr 29, 2022 at 06:56:45AM -0400, Jeremy Bicha wrote:

> wpewebkit has 2 reverse dependencies in Debian: cog and
> gstreamer1.0-wpe. Although cog was switched to use the new libsoup3,
> gstreamer1.0-wpe was not.

This is already fixed: https://bugs.debian.org/1009721

It was planned with the gst maintainer so it should have been seamless
but I guess we failed :-/

> Also, the package names in debian/control do not match the actual
> package names built. I believe this is a violation of Debian Policy.
> (Also it appears to break Ubuntu's NBS tracker.)

It lists both versions but we only build one or the other depending on
the target distro. If it causes breakage I guess I'll change it.

> I suggest you do like webkit2gtk and offer both libsoup2 and
> libsoup3 for now if you want to have the libsoup3 version available.

No need to do that since there's only two reverse dependencies.

Berto

Bug#1008424: audiofile: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Alberto Garcia]

reassign 1008424 src:flac 1.3.4-1
affects 1008424 src:audiofile
retitle 1008424 flac 1.3.4 makes audiofile FTBFS
forwarded 1008424 https://github.com/xiph/flac/issues/327
tags 1008424 patch
thanks

On Sat, Apr 23, 2022 at 01:48:17AM +0200, Alberto Garcia wrote:
> I submitted a bug report upstream: https://github.com/xiph/flac/issues/327

So it seems that the problem is in flac after all, I'm reassigning the
bug to that package.

Berto

Bug#1008424: audiofile: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Alberto Garcia]

On Mon, Apr 04, 2022 at 03:25:44PM +0200, Alberto Garcia wrote:

> > During a rebuild of all packages in sid, your package failed to
> > build on amd64.
> > 
> > > FAIL: FLAC
> 
> This started to happen after flac was updated from 1.3.3-2 to 1.3.4-1.

I bisected the changes in flac and the problems started here:

   commit 159cd6c41a6ec17b36d74043c45a3aa64de90d5e
   Author: Robert Kausch 
   Date:   Thu Oct 29 20:37:40 2020 +0100

   libFLAC/stream_decoder.c: Use current position as bound when seeking

I submitted a bug report upstream: https://github.com/xiph/flac/issues/327

Berto

Bug#1007829: [pkg-netfilter-team] Bug#1007829: arptables - Fails to install: Too many levels of symbolic links

[Alberto Molina Coballes]

Hi Thomas and thanks for resolving the bug.

A few days ago I tried to upload a new version fixing the bug, but it
was silently ignored. At the moment I'm very busy and I don't have
time to debug the problem by uploading packages to the archive, so
your help to solve the bug with a NMU is welcome :)

Alberto

Bug#1008424: audiofile: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Alberto Garcia]

On Sat, Mar 26, 2022 at 10:03:42PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > FAIL: FLAC

This started to happen after flac was updated from 1.3.3-2 to 1.3.4-1.

Downgrading the flac packages makes audiofile build fine again.

Berto

Bug#1007829: [pkg-netfilter-team] Bug#1007829: arptables - Fails to install: Too many levels of symbolic links

[Alberto Molina Coballes]

Thanks for reporting Bastian,

I've reproduced the issue, but it seems not related to dpkg, arptables
fails to install when iptables isn't installed. I must review and
update arptables postinst script where alternatives are used.

Alberto

Bug#1005810: epiphany-browser: crash on session_tab_free at ../src/ephy-session.c:605

[Alberto Garcia]

Control: tags -1 patch fixed-upstream
Control: forwarded -1 
https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/954

On Tue, Feb 15, 2022 at 04:29:52PM +0200, Andres Gomez wrote:
> After talking with the main WebKitGtk developer and maintainer,
> he pointed that the cause of the crash actually laid in
> epiphany-browser and, specifically, the reason for the crash had
> been already addressed upstream in the following issue:
> 
> https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/954

I'm attaching the debdiff with this fix. If this fixes the issue I
think we should upload it to bullseye.

Berto
diff -Nru epiphany-browser-3.38.2/debian/changelog epiphany-browser-3.38.2/debian/changelog
--- epiphany-browser-3.38.2/debian/changelog	2022-01-12 18:33:21.0 +0100
+++ epiphany-browser-3.38.2/debian/changelog	2022-02-23 17:34:35.0 +0100
@@ -1,3 +1,11 @@
+epiphany-browser (3.38.2-1+deb11u2) bullseye; urgency=medium
+
+  * d/p/glib-bug-workaround.patch:
+- Cherry pick upstream patch ff8ecbf6. This works around a bug in GLib
+  and fixes a UI process crash (Closes: #1005810).
+
+ -- Alberto Garcia   Wed, 23 Feb 2022 17:34:35 +0100
+
 epiphany-browser (3.38.2-1+deb11u1) bullseye-security; urgency=medium
 
   * d/p/encode-untrusted-data.patch:
diff -Nru epiphany-browser-3.38.2/debian/patches/glib-bug-workaround.patch epiphany-browser-3.38.2/debian/patches/glib-bug-workaround.patch
--- epiphany-browser-3.38.2/debian/patches/glib-bug-workaround.patch	1970-01-01 01:00:00.0 +0100
+++ epiphany-browser-3.38.2/debian/patches/glib-bug-workaround.patch	2022-02-23 17:31:38.0 +0100
@@ -0,0 +1,30 @@
+From: Michael Catanzaro 
+Subject: remove user data from task to workaround glib bug
+Origin: https://gitlab.gnome.org/GNOME/epiphany/-/commit/ff8ecbf673cd25f8ed34d4ccb29cc5d3d13cd683
+Bug-Debian: https://bugs.debian.org/1005810
+Index: epiphany-browser-3.38.2/src/ephy-session.c
+===
+--- epiphany-browser-3.38.2.orig/src/ephy-session.c
 epiphany-browser-3.38.2/src/ephy-session.c
+@@ -844,6 +844,12 @@ save_session_in_thread_finished_cb (GObj
+ gpointer  user_data)
+ {
+   g_application_release (G_APPLICATION (ephy_shell_get_default ()));
++
++  /* FIXME: this is a workaround for https://gitlab.gnome.org/GNOME/glib/-/issues/1346.
++   * After this GLib issue is fixed, we should instead pass save_data_free() as the
++   * GDestroyNotify parameter to g_task_set_task_data().
++   */
++  save_data_free (g_task_get_task_data (G_TASK (res)));
+ }
+ 
+ static gboolean
+@@ -1026,7 +1032,7 @@ ephy_session_save_idle_cb (EphySession *
+   session->save_cancellable = g_cancellable_new ();
+   task = g_task_new (session, session->save_cancellable,
+  save_session_in_thread_finished_cb, NULL);
+-  g_task_set_task_data (task, data, (GDestroyNotify)save_data_free);
++  g_task_set_task_data (task, data, NULL);
+   g_task_run_in_thread (task, save_session_sync);
+   g_object_unref (task);
+ 
diff -Nru epiphany-browser-3.38.2/debian/patches/series epiphany-browser-3.38.2/debian/patches/series
--- epiphany-browser-3.38.2/debian/patches/series	2022-01-12 18:33:21.0 +0100
+++ epiphany-browser-3.38.2/debian/patches/series	2022-02-23 17:28:18.0 +0100
@@ -3,3 +3,4 @@
 dont-make-compulsory.patch
 build-Allow-libportal-support-to-be-disabled.patch
 encode-untrusted-data.patch
+glib-bug-workaround.patch

Bug#1005518: frogr: FTBFS: ../data/meson.build:32:5: ERROR: Function does not take positional arguments.

[Alberto Garcia]

On Sun, Feb 13, 2022 at 08:27:19AM +0100, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > Configuring org.gnome.frogr.desktop.in using configuration
> > 
> > ../data/meson.build:32:5: ERROR: Function does not take positional 
> > arguments.

For reference, this is the reason why it fails:

   https://github.com/mesonbuild/meson/issues/9441

If you follow the link you'll see that lots of GNOME apps were
affected by this.

I'll prepare a fixed version of Frogr soon.

Berto

Bug#1005120: wpewebkit: Fails to build with gstreamer 1.20

[Alberto Garcia]

On Mon, Feb 07, 2022 at 10:53:56AM -0500, Jeremy Bicha wrote:
> wpewebkit fails to build from source, apparently because of the recent
> gstreamer 1.20 uploads.
> 
> -- Checking for module 'gstreamer-codecparsers-1.0 >= 1.14.0'
> --   No package 'gstreamer-codecparsers-1.0' found
> 
> That .pc file is provided by libgstreamer-plugins-bad1.0-dev so
> maybe you just need to Build-Depend on that.

As far as I'm aware gstreamer-codecparsers-1.0 is not needed in the
default build, the problem that I'm seeing here is this one:

   CMake Error at Source/cmake/GStreamerChecks.cmake:50 (message):
  GStreamerGL is needed for USE_GSTREAMER_GL.

GStreamerGL is however installed. The reason why this fails is this
one:

   # pkg-config --cflags gstreamer-gl-1.0
   Package gudev-1.0 was not found in the pkg-config search path.
   Perhaps you should add the directory containing `gudev-1.0.pc'

So I understand that libgstreamer-plugins-base1.0-dev would need to
depend on libgudev-1.0-dev, right Sebastian?

Berto

Bug#973715: fwupd-amd64-signed: apt-listbugs keep listing this bug as grave even tho it seems is fixed

[Alberto Fuentes]

Package: fwupd-amd64-signed
Followup-For: Bug #973715
X-Debbugs-Cc: paj...@gmail.com

fwupd-amd64-signed: apt-listbugs keep listing this bug as grave even tho it
seems is fixed

Im not sure why, but i believe is because it is fixed in a different package


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

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 fwupd-amd64-signed depends on:
pn  fwupd  

fwupd-amd64-signed recommends no packages.

fwupd-amd64-signed suggests no packages.

Bug#997757: marked as pending in kxd

[Alberto Bertogli]

Control: tag -1 pending

Hello,

Bug #997757 in kxd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/kxd/-/commit/060e537f720f6d2b7e3210bce867b774041fd727


Add modules information

Cherry-pick commit e5b1abe3b from upstream, which includes modules
information so that kxd can build with new Go compilers that require
this.

Closes: #997757


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/997757

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Mon, Sep 28, 2020 at 07:03:45PM +0200, Alberto Garcia wrote:
> I think that this project is essentially dead, there has never been
> a release and as you say there hasn't been changes in almost a year.
> 
> I have stopped using it myself and the reason why I didn't ask for
> its removal from Debian is that it's a very small package with a
> very low manteinance burden (and because popcon shows that it has
> some users).

FYI I decided to give this package for adoption. I'll request its
removal from the archive if there are no volunteers to take over its
maintenance after some time.

https://bugs.debian.org/998660

Berto

Bug#997757: kxd: FTBFS: go: go.mod file not found in current directory or any parent directory; see 'go help modules'

[Alberto Bertogli]

On Sun, Oct 24, 2021 at 01:37:43PM +0200, Lucas Nussbaum wrote:

Source: kxd
Version: 0.15-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20211023 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

make[1]: Entering directory '/<>'
go build -o ./out/kxd ./kxd
go build --tags netgo -a -o ./out/kxc ./kxc
go build -o ./out/kxgencert ./kxgencert
go: go.mod file not found in current directory or any parent directory; see 'go 
help modules'
make[1]: *** [Makefile:17: kxc] Error 1


This is because kxd has no go.mod file (it wasn't needed before).

I've added one upstream:

Browse: 
https://blitiri.com.ar/git/r/kxd/c/e5b1abe3b5dc235b083953e8fba01a0acf53e484/
Raw patch: 
https://blitiri.com.ar/git/r/kxd/c/e5b1abe3b5dc235b083953e8fba01a0acf53e484.patch

I'll add it to the Debian package later, unless someone else gets to it 
first :)


Thanks!
    Alberto

Bug#994910: Uploading ASAP

[Alberto Gonzalez Iniesta]

tags 994910 + pending
thanks

Hi, I'll make an upload to unstable ASAP.

Thanks,

Alberto

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Thu, Jun 03, 2021 at 01:37:45AM +0200, Jose wrote:
> > Can you install gstreamer1.0-plugins-good and try again?
> 
> That was the issue. Thank you for helping.
> 
> I don't understand why it was working before the libwebkit2gtk
> update.  Maybe this is a dependency that should be added to the
> epiphany package?

WebKitGTK requires gstreamer1.0-plugins-good in order to play audio.
In earlier versions if the plugins were not found it would simply not
play any audio but continue browsing (that's why the plugins are not a
hard dependency but a recommendation).

This changed in WebKitGTK 2.32, so we either have to make it a
dependency or make it work again without the plugins installed.

I'll fix this for bullseye, but I'm not sure if there will be a new
security update just for this.

Berto

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Wed, Jun 02, 2021 at 09:21:54PM +0200, Jose wrote:
> Berto,
> 
> Thanks.
> 
> Here is the full gdb bt after installing the debug symbols.
> 
> Please tell me if you'd like me to do any additional tests
> or debugging.
> 
> --josé

> #0  0x7f707b64e7bb in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x7f707b639535 in __GI_abort () at abort.c:79
> #2  0x7f7080746085 in CRASH_WITH_INFO(...) () at 
> DerivedSources/ForwardingHeaders/wtf/Assertions.h:713
> #3  0x7f7080746085 in 
> WebCore::MediaPlayerPrivateGStreamer::createAudioSink() ()
> at 
> ../Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1322

Can you install gstreamer1.0-plugins-good and try again?

Berto

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Wed, Jun 02, 2021 at 06:11:56PM +0200, Jose wrote:
> Hi Berto,
> 
> Sorry for the delay. Yopmail went down a little bit after I sent my
> initial report.
> 
> Discord still crashes for me. I'm attaching the gdb trace you
> requested. I opened epiphany with a blank home screen, then went
> to the discord site and clicked on "open discord in the browser"
> 
> As you can see, I have the same version of epiphany that you used
> in your own test:
> 
>   Installed: 3.32.1.2-3~deb10u1
>   Candidate: 3.32.1.2-3~deb10u1
> 
> I may be able to reproduce the error due to my using discord and belonging
> to some servers. This may make epiphany/webkit or the associated 
> javascript do some rendering or something I don't know that used to work
> and stopped after the libwebkit patch. It's just normal discord servers,
> nothing hacked or fancy afaik.

Yes, I guess the reason is the servers you belong to because I really
cannot reproduce the problem.

If you run Epiphany from the command line, does it show any error
message when it crashes? There's an abort() there which might give us
a clue (the rest of the backtrace if unfortunately not very useful
without the symbols).

Also, can you try with the Minibrowser?

$ /usr/lib/*/webkit2gtk-4.0/MiniBrowser https://discord.com

One more thing, you can also try without the JIT:

$ JavaScriptCoreUseJIT=0 epiphany

If this last one doesn't crash, can you tell me what CPU model does
your computer have?

> If you'd like me to download the debug symbols and generate another
> bt, please tell me so.

Unfortunately they don't seem to be available yet for your build:

http://debug.mirrors.debian.org/debian-debug/pool/main/w/webkit2gtk/

You would need to build them yourself (or I can also provide the debug
packages for you if you prefer).

Berto

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Tue, Jun 01, 2021 at 12:19:26PM +0200, jose wrote:

> Epiphany is based on libwebkit2. I access discord as a web app on
> epiphany.  To do so I go to the discord site [1] and click on "Open
> Discord in your browser".
> 
> Since the upgrade this systematically results in epiphany
> complaining with a "Something went wrong while displaying this
> page".

FWIW I just logged in to Discord just fine with webkit 2.32.1-1~deb10u1
and Epiphany 3.32.1.2-3~deb10u1.

Berto

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

On Fri, May 21, 2021 at 09:28:02PM +0200, Paul Gevers wrote:
> > In webkit2gtk 2.32.1-1 the dependency on xdg-desktop-portal-gtk was
> > downgraded to a recommendation so the test no longer fails.
> 
> balsa is close to autoremoval from bullseye because of this issue.
> Should xdg-desktop-portal-gtk really be a Depends? (Having the
> possibility to downgrade the dependency suggest it *is* not a
> dependency).
> 
> > The underlying cause is still there so I don't know if you want to
> > keep this bug report open to look for a proper solution.
> 
> If you're OK with keeping the downgraded dependency then I think
> this bug can be downgraded too.

Arguably this bug could be closed since the test no longer fails,
although I think it's useful to keep it open in order to track the
issue. But that's up to the Balsa maintainers in my opinion.

In any case I would definitely reduce the severity of the bug, I just
didn't want to do it on behalf of the original reporter :)

Berto

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

On Tue, Apr 27, 2021 at 11:27:32PM +0200, Alberto Garcia wrote:

> Nothing to do with webkit actually. The test launches Balsa, waits
> for two seconds and then takes a screenshot of the window. The bug
> happens because when xdg-desktop-portal-gtk is installed Balsa takes
> a very long time to start so those two seconds are not enough.

In webkit2gtk 2.32.1-1 the dependency on xdg-desktop-portal-gtk was
downgraded to a recommendation so the test no longer fails.

The underlying cause is still there so I don't know if you want to
keep this bug report open to look for a proper solution.

Berto

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

Control: found -1 balsa/2.6.1-1

On Tue, Apr 27, 2021 at 11:27:32PM +0200, Alberto Garcia wrote:
> The bug happens because when xdg-desktop-portal-gtk is installed
> Balsa takes a very long time to start so those two seconds are not
> enough.
> 
> g_application_register() calls g_dbus_proxy_new_sync(), and
> that times out. The problem seems to disappear if you unset
> DBUS_SESSION_BUS_ADDRESS, but that's a workaround I guess :)

I'm thinking that this should probably be fixed for bullseye. It may
not fail at the moment because xdg-desktop-portal-gtk is not installed
during the test, but webkit2gtk 2.32.x will make it to bullseye sooner
or later through a security release.

So I think it makes sense to at least apply the workaround?

I'm also attaching the full backtrace of the point where Balsa hangs
during the test.

Berto
(gdb) bt
#0  0x732113ff in __GI___poll (fds=0x55823e00, nfds=1, 
timeout=25000) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x733af0ae in g_main_context_poll (priority=, 
n_fds=1, fds=0x55823e00, timeout=, context=0x55866c00) 
at ../../../glib/gmain.c:4422
#2  g_main_context_iterate (context=0x55866c00, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4114
#3  0x733af40b in g_main_loop_run (loop=0x557e6c70) at 
../../../glib/gmain.c:4317
#4  0x735ff214 in initable_init (initable=0x5578cab0, 
cancellable=0x0, error=0x7fffda50) at ../../../gio/gdbusproxy.c:1903
#5  0x735608e2 in g_initable_new_valist (object_type=, 
first_property_name=0x7363283a "g-flags", 
var_args=var_args@entry=0x7fffd8a0, cancellable=cancellable@entry=0x0, 
error=error@entry=0x7fffda50) at ../../../gio/ginitable.c:248
#6  0x73560999 in g_initable_new 
(object_type=object_type@entry=93824994070512, 
cancellable=cancellable@entry=0x0, error=error@entry=0x7fffda50, 
first_property_name=first_property_name@entry=0x7363283a "g-flags") at 
../../../gio/ginitable.c:162
#7  0x73600913 in g_dbus_proxy_new_sync (connection=0x557180b0, 
flags=G_DBUS_PROXY_FLAGS_NONE, info=info@entry=0x0, 
name=name@entry=0x73d95460 "org.freedesktop.portal.Desktop", 
object_path=0x73d954a8 "/org/freedesktop/portal/desktop", 
interface_name=0x73e01cd0 "org.freedesktop.portal.Inhibit", 
cancellable=0x0, error=0x7fffda50) at ../../../gio/gdbusproxy.c:2093
#8  0x73d604ee in gtk_application_get_proxy_if_service_present 
(connection=, flags=, bus_name=0x73d95460 
"org.freedesktop.portal.Desktop", object_path=, 
interface=, error=0x7fffda50) at 
../../../../gtk/gtkapplication-dbus.c:132
#9  0x73d60678 in gtk_application_impl_dbus_startup 
(impl=0x55825500, register_session=1) at 
../../../../gtk/gtkapplication-dbus.c:461
#10 0x73a93690 in gtk_application_startup 
(g_application=0x557090f0) at ../../../../gtk/gtkapplication.c:307
#11 0x734a00a2 in g_closure_invoke 
(closure=closure@entry=0x557036e0, return_value=return_value@entry=0x0, 
n_param_values=1, param_values=param_values@entry=0x7fffdd10, 
invocation_hint=invocation_hint@entry=0x7fffdc90) at 
../../../gobject/gclosure.c:810
#12 0x734b20aa in signal_emit_unlocked_R 
(node=node@entry=0x55703710, detail=detail@entry=0, 
instance=instance@entry=0x557090f0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffdd10) at 
../../../gobject/gsignal.c:3669
#13 0x734b86cf in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffde90) at ../../../gobject/gsignal.c:3495
#14 0x734b8c3f in g_signal_emit 
(instance=instance@entry=0x557090f0, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3551
#15 0x735c4d92 in g_application_register 
(application=application@entry=0x557090f0, 
cancellable=cancellable@entry=0x0, error=error@entry=0x7fffdfb0) at 
../../../gio/gapplication.c:2204
#16 0x735c517a in g_application_real_local_command_line 
(application=0x557090f0, arguments=0x7fffe018, 
exit_status=0x7fffe014) at ../../../gio/gapplication.c:1106
#17 0x735c54ae in g_application_run (application=0x557090f0, 
argc=-8172, argc@entry=2, argv=argv@entry=0x7fffe188) at 
../../../gio/gapplication.c:2528
#18 0x555881e5 in main (argc=2, argv=0x7fffe188) at main.c:786

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

Control: notfound -1 webkit2gtk/2.32.0-2

On Tue, Apr 27, 2021 at 09:27:35PM +0200, Paul Gevers wrote:

> With a recent upload of webkit2gtk the autopkgtest of balsa fails
> in testing when that autopkgtest is run with the binary packages of
> webkit2gtk from unstable.

Nothing to do with webkit actually. The test launches Balsa, waits for
two seconds and then takes a screenshot of the window. The bug happens
because when xdg-desktop-portal-gtk is installed Balsa takes a very
long time to start so those two seconds are not enough.

g_application_register() calls g_dbus_proxy_new_sync(), and
that times out. The problem seems to disappear if you unset
DBUS_SESSION_BUS_ADDRESS, but that's a workaround I guess :)

I haven't debugged why this happens when xdg-desktop-portal-gtk is
installed.

More information here:

   https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/1923817

Berto

Bug#987448: webkit2gtk regression: liferea: CSS for the posts is broken

[Alberto Garcia]

On Sat, Apr 24, 2021 at 09:52:51AM +0800, Paul Wise wrote:
> The recent upgrade to webkit2gtk 2.32.0-2 broke the CSS that the
> liferea RSS reader uses to style the HTML it injects for post
> metadata.

So it seems that this is a problem in Liferea after all.

webkit2gtk is covered by security support and version 2.32 will
eventually make it into bullseye, so I guess we have to apply this
liferea fix there as well?

Berto

Bug#987448: webkit2gtk regression: liferea: CSS for the posts is broken

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=225036
Control: tags -1 upstream

On Sat, Apr 24, 2021 at 09:52:51AM +0800, Paul Wise wrote:

> The recent upgrade to webkit2gtk 2.32.0-2 broke the CSS that the
> liferea RSS reader uses to style the HTML it injects for post metadata.

Thanks, I can reproduce the problem easily. I just reported it
upstream.

Berto

Bug#977779: geary FTBFS on mipsel: test suite failure

[Alberto Garcia]

On Fri, Jan 29, 2021 at 02:11:00PM +0200, Adrian Bunk wrote:
> > But this a bug in the CPU, right? Do I understand correctly that the
> > package can fail depending on what CPU it is run on regardless of how
> > it was built?
> > 
> > I'm trying to understand what we can do in WebKit in order to fix or
> > work around this.
> 
> It is a bug in WebKit that a kernel configuration is assumed that is
> not even permitted on Loongson:
> https://sources.debian.org/src/webkit2gtk/2.31.1-1/Source/WTF/wtf/PageBlock.h/#L54
> https://sources.debian.org/src/linux/5.10.9-1/arch/mips/Kconfig/#L2213-L2215

My question is: I cannot choose a page size depending on the
particular MIPS CPU model because once the package is built it could
be run on a CPU with a different page size, is that right?

If that's the case then I should use a conservative value that is
guaranteed to work on all models (64KB, or is 16KB safe?).

> BTW: The 4kB setting for arm64 is also questionable, Ubuntu releases 
>  now additionally ship kernels with 64 kB page size:
>  
> https://launchpad.net/ubuntu/groovy/+package/linux-image-unsigned-5.8.0-41-generic-64k

Ok, I'll use 64KB then.

Berto

Bug#961814: marked as pending in golang-google-protobuf

[Alberto Bertogli]

On Fri, Jan 08, 2021 at 11:30:21PM +0800, Shengjing Zhu wrote:

On Fri, Jan 8, 2021 at 11:17 PM Alberto Bertogli
 wrote:


On Thu, Jan 07, 2021 at 11:12:24PM +0800, Shengjing Zhu wrote:
>On Thu, Jan 7, 2021 at 10:59 PM Alberto Bertogli
> wrote:
>> But those issues are not made worse by allowing golang-google-protobuf
>> to go in, right?
>>
>
>Let golang-google-protobuf go in is one thing, it's not difficult.
>However without golang-goprotobuf 1.4.x it's not useful currently. But
>it will be changed if upstream has switched to golang-google-protobuf
>only.

But IIUC that's what foka@'s lastest changes do - now the two packages
are independent so golang-google-protobuf can go in?

This would unblock:
1) Some upstream packages that have upgraded to the new library and are
using pregenerated pb.go without the dependency.
2) Packages that have moved/want to move to the new library and generate
pb.go as part of the build (without needing grpc).

And no packages are forced into anything, since upstream needs to do the
update explicitly anyway, the ones using golang-goprotobuf will continue
to function just fine.

I understand not all problems are fixed and some things remain, but it
seems it'd be a step in the right direction since at least some packages
will be able to move forward, without causing any new
complications/regressions.

Or am I missing something?



You are right. The only concern from my side is the usefulness of
golang-google-protobuf without upgrading golang-goprotobuf to 1.4.
If some packages are already ready for using golang-google-protobuf
solely, sure we should try.


Yeah, the reason I'm personally interested in this is I have one package 
I'm upstream for (chasquid) in this situation. I've already done the 
required patching and is blocked on this package.


I am also waiting on the change to move other projects forward for the 
same reason :)


Let me know if there's anything I can do, or how can I help!

Thanks again!
Alberto

Bug#977779: geary FTBFS on mipsel: test suite failure

[Alberto Garcia]

On Mon, Dec 21, 2020 at 11:30:14PM +0200, Adrian Bunk wrote:
> > I see that the build eventually succeeded:
> > 
> >
> > https://buildd.debian.org/status/logs.php?pkg=geary=3.38.1-1=mipsel
> > 
> > The webkit2gtk build is flaky itself in mipsel, we discussed this
> > already in the past (#962616), I wonder if this is the same root
> > problem?
> 
> This is the same problem.
> 
> Note that the build is not and never was flaky, it does 100%
> determinisitically fail on Loongson buildds and succeed on Octeon
> buildds.
> 
> Jiaxun Yang discovered this weekend that CeilingOnPageSize is wrong
> for Loongson which has 16 kB pagesize and this matches when the
> problems started in 2.28.1, but unfortunately fixing this does not
> seem to fix all problems.

But this a bug in the CPU, right? Do I understand correctly that the
package can fail depending on what CPU it is run on regardless of how
it was built?

I'm trying to understand what we can do in WebKit in order to fix or
work around this.

Berto

Bug#961814: marked as pending in golang-google-protobuf

[Alberto Bertogli]

On Thu, Jan 07, 2021 at 11:12:24PM +0800, Shengjing Zhu wrote:

On Thu, Jan 7, 2021 at 10:59 PM Alberto Bertogli
 wrote:

But those issues are not made worse by allowing golang-google-protobuf
to go in, right?



Let golang-google-protobuf go in is one thing, it's not difficult.
However without golang-goprotobuf 1.4.x it's not useful currently. But
it will be changed if upstream has switched to golang-google-protobuf
only.


But IIUC that's what foka@'s lastest changes do - now the two packages 
are independent so golang-google-protobuf can go in?


This would unblock:
1) Some upstream packages that have upgraded to the new library and are 
   using pregenerated pb.go without the dependency.
2) Packages that have moved/want to move to the new library and generate 
   pb.go as part of the build (without needing grpc).


And no packages are forced into anything, since upstream needs to do the 
update explicitly anyway, the ones using golang-goprotobuf will continue 
to function just fine.


I understand not all problems are fixed and some things remain, but it 
seems it'd be a step in the right direction since at least some packages 
will be able to move forward, without causing any new 
complications/regressions.


Or am I missing something?

Thanks!
Alberto

Bug#961814: marked as pending in golang-google-protobuf

[Alberto Bertogli]

On Thu, Jan 07, 2021 at 04:43:43PM +0800, Shengjing Zhu wrote:

On Thu, Jan 7, 2021 at 2:51 PM Anthony Fok  wrote:


Hi Shengjing,

On Tue, Jan 5, 2021 at 8:42 AM Shengjing Zhu  wrote:
>
> Hi Anthony,

Thanks for writing to me!  Sorry for the late reply.
I was going to re-open this with the pseudo header "Control: reopen
-1" to keep this new version out of testing (buster), but then I
decided to study the issue further, I think we are safe to move
forward, allowing golang-google-protobuf to enter testing, while
keeping the old golang-goprotobuf 1.3.x if necessary.

> The reason that I haven't uploaded new version of this package, is
> that using golang-google-protobuf usually means using
> golang-goprotobuf 1.4+ as well.

Looks like that is not the case any more.
While golang-google-protobuf and protoc-gen-go v1.25.0 would still
pull in the old golang-goprotobuf 1.4+ package in the generated file,
apparently for backward compatibility during the 6-month transition
period that Joe Tsai @dsnet set:

import (
proto "github.com/golang/protobuf/proto"
...
)

Well, I think we have good news!

1.25.0+git20201208.160c747 doesn't do that any more.
The import proto "github.com/golang/protobuf/proto" line is gone;
the "const _ = proto.ProtoPackageIsVersion4" is also gone.

The latest golang-google-protobuf makes a clean break from the past.
It is now self-contained, and no longer pulls in the legacy golang-goprotobuf.
It is just like what you predicted: once GitHub issue #1077 is fixed,
we can move forward.

Thank you for your packaging of golang-google-protobuf which also
allows the clean separation with the old golang-goprotobuf ecosystem.



The problem is currently all upstream still use golang-goprotobuf to
generate pb.go, not the plugin from
https://github.com/protocolbuffers/protobuf-go/tree/master/cmd/protoc-gen-go
If we choose to use this plugin ahead of upstream, and leave
golang-goprotobuf not updated(and not used in B-D), then things will
be fine. But upstream says there are still missing features like grpc
support, which are moved to grpc package itself. I haven't looked at
this part. However it will become a difficult transition, which
involves golang-google-grpc-dev, golang-google-genproto-dev, etc...


But those issues are not made worse by allowing golang-google-protobuf 
to go in, right?


What's blocking golang-google-protobuf from moving to testing now that 
the dependency on golang-goprotobuf is no longer there?


Is the issue that golang-google-protobuf source also builds a 
protoc-gen-go?


Why can't the latter be split, so upstreams that include pre-generated 
.pb.go (as is the official recommendation) can be included in Debian 
as-is using the corresponding dependency?


Thanks!
Alberto

Bug#977779: geary FTBFS on mipsel: test suite failure

[Alberto Garcia]

On Sun, Dec 20, 2020 at 09:09:17PM +0200, Adrian Bunk wrote:
> > Source: geary
> > Version: 3.38.1-1

> > The latest version of geary fails to build on mipsel [1]. The test
> > suite fails.
> 
> This is not specific to geary and not specific to this version of
> geary, the search is already ongoing for the regression that makes
> webkit2gtk and some rdeps FTBFS on some buildds on mipsel.

I see that the build eventually succeeded:

   https://buildd.debian.org/status/logs.php?pkg=geary=3.38.1-1=mipsel

The webkit2gtk build is flaky itself in mipsel, we discussed this
already in the past (#962616), I wonder if this is the same root
problem?

Berto

Bug#976936: wpewebkit: FTBFS on ppc64el: dh_auto_build: error: cd obj-powerpc64le-linux-gnu && LC_ALL=C.UTF-8 ninja -j160 -v returned exit code 1

[Alberto Garcia]

Control: tags -1 moreinfo

On Wed 09 Dec 2020 09:42:53 AM CET, Lucas Nussbaum wrote:
> Source: wpewebkit
> Version: 2.30.3-1
> Severity: serious
> Justification: FTBFS on ppc64el
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.

I can only see this in the build log:

> c++: fatal error: Killed signal terminated program cc1plus

This sounds like a bug in the compiler or some other external problem, I
haven't seen in the logs any indication that this is due to problems in
the code or the packaging.

Berto

Bug#957037: biboumi: ftbfs with GCC-10

[Alberto Luaces]

Package: biboumi
Followup-For: Bug #957037

I have checked that current upstream (9.0) builds flawlessly, and made my 
release available at https://salsa.debian.org/aluaces-guest/biboumi .

Can I be sponsored so we can upload to at least experimental?

Thanks!

Bug#957184: eurephia: diff for NMU version 1.1.0-6.1

[Alberto Gonzalez Iniesta]

Hi, Sudip.

Thanks for the upload. No need to cancel it :-)

On Mon, Nov 30, 2020 at 08:52:30PM +, Sudip Mukherjee wrote:
> Control: tags 957184 + patch
> Control: tags 957184 + pending
> --
> 
> Dear maintainer,
> 
> I've prepared an NMU for eurephia (versioned as 1.1.0-6.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should cancel it.
> 
> --
> Regards
> Sudip
> 
> diff -Nru eurephia-1.1.0/debian/changelog eurephia-1.1.0/debian/changelog
> --- eurephia-1.1.0/debian/changelog   2016-09-16 08:38:26.0 +0100
> +++ eurephia-1.1.0/debian/changelog   2020-11-30 20:44:45.0 +
> @@ -1,3 +1,11 @@
> +eurephia (1.1.0-6.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix ftbfs with GCC-10. (Closes: #957184)
> +- Use fcommon with CFLAGS.
> +
> + -- Sudip Mukherjee   Mon, 30 Nov 2020 20:44:45 
> +
> +
>  eurephia (1.1.0-6) unstable; urgency=medium
>  
>* Make build reproducible. Thanks Chris Lamb for the patch!
> diff -Nru eurephia-1.1.0/debian/rules eurephia-1.1.0/debian/rules
> --- eurephia-1.1.0/debian/rules   2015-07-07 16:04:12.0 +0100
> +++ eurephia-1.1.0/debian/rules   2020-11-29 22:27:12.0 +
> @@ -3,7 +3,7 @@
>   dh $@
>  
>  override_dh_auto_configure:
> - $(shell DEB_CFLAGS_MAINT_APPEND="-fPIC -std=gnu89" dpkg-buildflags 
> --export=configure) ./configure --prefix /usr --plug-in --fw-iptables 
> --db-sqlite3 --sqlite3-path /var/lib/eurephia --eurephiadm --openvpn-src 
> /usr/include/openvpn
> + $(shell DEB_CFLAGS_MAINT_APPEND="-fPIC -std=gnu89 -fcommon" 
> dpkg-buildflags --export=configure) ./configure --prefix /usr --plug-in 
> --fw-iptables --db-sqlite3 --sqlite3-path /var/lib/eurephia --eurephiadm 
> --openvpn-src /usr/include/openvpn
>  override_dh_auto_clean:
>   rm -rf configure.log
>   dh_auto_clean

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#975134: wpewebkit: FTBFS: ../Source/WebCore/platform/network/ResourceResponseBase.cpp:440:6: error: type precision mismatch in switch statement

[Alberto Garcia]

On Thu, Nov 19, 2020 at 10:39:08AM +0100, Lucas Nussbaum wrote:
> Source: wpewebkit
> Version: 2.30.2-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201119 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks, this is a known problem, see #973293 and the upstream gcc bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97634

We have a workaround for webkit, it'll be included in the next
release, which will probably happen this week.

Berto

Bug#971123: kxd: FTBFS: dh_auto_test: error: make -j4 test returned exit code 2

[Alberto Bertogli]

On Mon, Sep 28, 2020 at 08:58:41PM +0100, Alberto Bertogli wrote:

On Sun, Sep 27, 2020 at 08:45:30PM +0200, Lucas Nussbaum wrote:

Source: kxd
Version: 0.14-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200926 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


This is due to a change in x509 certificate handling in Go 1.15. It 
has been fixed in upstream release 0.15.


In this repo you can find an updated Debian package for kxd 1.15; I 
don't have access to upload it to salsa directly, and it would need a 
DD to do a review and upload in any case:


https://blitiri.com.ar/git/r/debian:kxd/


FYI the changes to update kxd to 1.15, which fixes this issue, are in 
the Salsa repository now, https://salsa.debian.org/debian/kxd


This just needs a DD to review and upload.

Thanks,
Alberto

Bug#952262: psgml: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Alberto Garcia]

Control: tags -1 patch pending

On Wed, Oct 21, 2020 at 04:10:41PM +0200, Alberto Garcia wrote:
> I confirm that the patch attached by Claudio Saavedra fixes the bug so
> I'll prepare an NMU (debdiff attached).

Uploaded to DELAYED/5

Berto

Bug#952262: psgml: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Alberto Garcia]

On Sun, Feb 23, 2020 at 02:22:05PM +0100, Lucas Nussbaum wrote:
> Source: psgml
> Version: 1.4.0-7.1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This bug has been open for almost a year and the package was removed
from testing 7 months go because of it.

I confirm that the patch attached by Claudio Saavedra fixes the bug so
I'll prepare an NMU (debdiff attached).

Berto
diff -u psgml-1.4.0/debian/changelog psgml-1.4.0/debian/changelog
--- psgml-1.4.0/debian/changelog
+++ psgml-1.4.0/debian/changelog
@@ -1,3 +1,11 @@
+psgml (1.4.0-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS due to malformed UTF-8 character (Closes: #952262):
+  - Applied patch for psgml.texi; thanks Claudio Saavedra.
+
+ -- Alberto Garcia   Wed, 21 Oct 2020 16:02:11 +0200
+
 psgml (1.4.0-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u psgml-1.4.0/psgml.texi psgml-1.4.0/psgml.texi
--- psgml-1.4.0/psgml.texi
+++ psgml-1.4.0/psgml.texi
@@ -1572,7 +1572,7 @@
 
 Set the variable @code{sgml-display-char-list-filename} to a file that
 contains mappings between all characters present in the presentation
-character set, and their "standard replacement text" names, e.g. "å"
+character set, and their "standard replacement text" names, e.g. "@U{00e5}"
 -> "[aring ]", e.t.c.
 
 The default value for this variable is `iso88591.map'. 

Bug#971123: kxd: FTBFS: dh_auto_test: error: make -j4 test returned exit code 2

[Alberto Bertogli]

On Sun, Sep 27, 2020 at 08:45:30PM +0200, Lucas Nussbaum wrote:

Source: kxd
Version: 0.14-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200926 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


This is due to a change in x509 certificate handling in Go 1.15. It has 
been fixed in upstream release 0.15.


In this repo you can find an updated Debian package for kxd 1.15; I 
don't have access to upload it to salsa directly, and it would need a DD 
to do a review and upload in any case:


https://blitiri.com.ar/git/r/debian:kxd/

Thanks,
Alberto

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Tue, Sep 22, 2020 at 09:51:14PM +0200, Alex ARNAUD wrote:

> > I think this version shouldn't be shipped with the next
> > release. Like the description says, it's "somewhat alpha".
> >
> > It works some times, but then stops working, it crashes,
> > and so on.
> 
> I've used the package purple-matrix on Debian 10 since at least 6
> months through Pidgin. It's not a perfect tool, have issues but in
> my opinion it is usable. Sometimes purple-matrix is disconnected
> or makes Pidgin to crash but it's quite rare. It's sufficient to
> restart Pidgin to make it working again.
> 
> I have two points why I think we should have it into next stable:
> 
>  * This is very difficult for a stable user to use purple-matrix. In my
>case, I have had to rebuilt the package due to dependencies and it's
>clearly something not easy for all.
>  * As a visual-impaired person, purple-matrix through Pidgin is the
>most accessible Matrix client I've used.
> 
> There are still reasons why we would like to keep it in unstable:
> 
>  * There are no commits in 2020
>  * The project doesn't publish new release and "just" push commits

Hi,

I think that this project is essentially dead, there has never been a
release and as you say there hasn't been changes in almost a year.

I have stopped using it myself and the reason why I didn't ask for its
removal from Debian is that it's a very small package with a very low
manteinance burden (and because popcon shows that it has some users).

But it seems that there are other alternatives nowadays. The official
Matrix website no longer lists purple-matrix, but there are however
other text-based clients such as weechat-matrix and gomuks. I cannot
evaluate how accessible they are, though.

Berto

Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation

[Carlos Alberto Lopez Perez]

On 11/06/2020 18:34, Michael Borg wrote:
> Yep I know but I cannot tell all my customers to run this workaround, some
> of our users are not experienced at all The only thing I see here is
> that I need to provide a hotfix ourselves. We cannot wait for days... You
> are saying we cannot make an exception and push this fix ASAP?

Pushing packages to Debian takes time. If you need something for today you need 
to fix it yourself.

You can downgrade to the old version of the package ca-certificates or install 
the missed certificate manually

This recipe allows to do that:

wget --no-check-certificate -c 
https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem
   \
&& mkdir /usr/local/share/ca-certificates/extra 
  \
&& mv GeoTrust_Global_CA.pem 
/usr/local/share/ca-certificates/extra/GeoTrust_Global_CA.crt   
 \
&& update-ca-certificates

And when you upgrade to the fixed version of ca-certificates you can remove the 
directory /usr/local/share/ca-certificates/extra 
and run the command update-ca-certificates again.



signature.asc
Description: OpenPGP digital signature

Bug#962616: webkit2gtk: FTBFS on mipsel

[Alberto Garcia]

On Thu, Jun 11, 2020 at 11:19:10AM +0300, Adrian Bunk wrote:

> > > | Exception: gtkdoc-scangobj produced a non-zero return code 250
> > > | Command:
> > > |   gtkdoc-scangobj --module=webkit2gtk-4.0
> > > | Error output:
> > > |   
> > > |
> > > | ninja: build stopped: subcommand failed.
> > 
> > I've seen this several times, and it seems to happen randomly, and
> > only on mipsel. I haven't been able to reproduce it in a buildd.
> > 
> > I suspect it's a bug in gtk-doc-tools ?
> 
> It fails on the Loongson buildds but succeeds on the others,
> and the problem started recently:
> https://buildd.debian.org/status/logs.php?pkg=webkit2gtk=mipsel

Ah, ok. FWIW I just built it again in eller.debian.org and everything
went fine.

Berto

Bug#962616: webkit2gtk: FTBFS on mipsel

[Alberto Garcia]

On Wed, Jun 10, 2020 at 08:08:27PM +0200, Sebastian Ramacher wrote:
> | Exception: gtkdoc-scangobj produced a non-zero return code 250
> | Command:
> |   gtkdoc-scangobj --module=webkit2gtk-4.0
> | Error output:
> |   
> |
> | ninja: build stopped: subcommand failed.

I've seen this several times, and it seems to happen randomly, and
only on mipsel. I haven't been able to reproduce it in a buildd.

I suspect it's a bug in gtk-doc-tools ?

Berto

Bug#961997: openscenegraph: Cannot migrate to testing (Not built on buildd)

[Alberto Luaces]

Hi,

> Please do a source-only upload to unstable

Yes, I always do, including this release.  But this time there was some
hiccup on the ftp queue that silently held the release, so the last
thing I tried was to see if the source-only upload was being the culprit.

> and coordinate transitions in
> the future. Be sure to read the related documentation:
> 
>  https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> 

Sorry about that, I missed that one.  Now I even remember that you
helped me with the last one :-)

In fact part of the reasons for updating was a request from the openmw
team.  I have seen that they say the FTBFS will be fixed with the new
release of openmw.  I will see if that is also true for flightgear.

Regards,

Alberto

Bug#956219: Error out when DISPLAY is unset

[Alberto Garcia]

On Sat, Apr 25, 2020 at 10:17:47AM +0200, Laurent Bigonville wrote:
> I'm reopening this as yelp still FTBFS with 2.28.2 with the same
> error, was the patch cherry-picked?

It was, but the problem seems to be different this time (a null
pointer):

process:35799): Gtk-CRITICAL **: 13:40:20.270: gtk_icon_theme_get_for_screen: 
assertion 'GDK_IS_SCREEN (screen)' failed

** (process:35799): WARNING **: 13:40:20.271: Unable to connect to dbus: Cannot 
autolaunch D-Bus without X11 $DISPLAY
Unable to init server: Could not connect: Connection refused
Segmentation fault

Thread 1 "libyelp-scan" received signal SIGSEGV, Segmentation fault.
0x7335cbd4 in wpe_renderer_backend_egl_destroy (backend=0x0) at 
./src/renderer-backend-egl.c:54
54  backend->base.interface->destroy(backend->base.interface_data);
(gdb) bt
#0  0x7335cbd4 in wpe_renderer_backend_egl_destroy (backend=0x0) at 
./src/renderer-backend-egl.c:54
#1  0x763bc8bb in 
WebCore::PlatformDisplayLibWPE::~PlatformDisplayLibWPE() ()
at ../Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp:66
#2  0x763bc8d9 in 
WebCore::PlatformDisplayLibWPE::~PlatformDisplayLibWPE() ()
at ../Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp:67
#3  0x77c59e27 in __run_exit_handlers
(status=0, listp=0x77dd8718 <__exit_funcs>, 
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
at exit.c:108
#4  0x77c59fda in __GI_exit (status=) at exit.c:139
#5  0x77c42e12 in __libc_start_main (main=
0x6480 , argc=1, argv=0x7fffdd78, init=, 
fini=, rtld_fini=, stack_end=0x7fffdd68) at 
../csu/libc-start.c:342
#6  0x7b7a in _start () at libyelp-scan.c:1025

This looks like the WPE backend (which WebKitGTK uses), but from the
backtrace I can't quite tell yet where exactly the root of the problem
is. We'll investigate it and make sure that yelp builds after we have
fixed it.

Thanks for the report and sorry for the annoyance !

Berto

Bug#955643: tripwire: FTBFS: dpkg-gencontrol: error: error occurred while parsing Built-Using field: glibc (= 2.30-4), libgcc1 (= ),

[Alberto Gonzalez Iniesta]

Hi, Lucas.

On Fri, Apr 03, 2020 at 09:56:02PM +0200, Lucas Nussbaum wrote:
> Source: tripwire
> Version: 2.4.3.7-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200402 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
>
> > dh_gencontrol -- -VBuilt-Using="glibc (= 2.30-4), libgcc1 (= ), "
> > dpkg-gencontrol: warning: Depends field of package tripwire: substitution 
> > variable ${shlibs:Depends} used, but is not defined
> > dpkg-gencontrol: warning: can't parse dependency libgcc1 (= )
> > dpkg-gencontrol: error: error occurred while parsing Built-Using field: 
> > glibc (= 2.30-4), libgcc1 (= ), 
> > dh_gencontrol: error: dpkg-gencontrol -ptripwire -ldebian/changelog 
> > -Tdebian/tripwire.substvars -Pdebian/.debhelper/tripwire/dbgsym-root 
> > "-VBuilt-Using=glibc (= 2.30-4), libgcc1 (= ), " -UPre-Depends -URecommends 
> > -USuggests -UEnhances -UProvides -UEssential -UConflicts 
> > -DPriority=optional -UHomepage -UImportant -UBuilt-Using 
> > -DAuto-Built-Package=debug-symbols -DPackage=tripwire-dbgsym 
> > "-DDepends=tripwire (= \${binary:Version})" "-DDescription=debug symbols 
> > for tripwire" "-DBuild-Ids=29bff36c96f9f7f161804f634705648d102836ba 
> > 3a7a08dca92e1782576544245bf22db1edd8f5c7 
> > a01ce61d78fff4d6276e5a8914e5ef3ed1dfee7a 
> > cc2f0ff87227a5dd8f907527250c554b8384d95c" -DSection=debug -UMulti-Arch 
> > -UReplaces -UBreaks returned exit code 25
> > dh_gencontrol: error: Aborting due to earlier error
> > make: *** [debian/rules:85: binary-arch] Error 25

I just build the package with sbuild without any issues. Here's the
relevant part:


dh_gencontrol -- -VBuilt-Using="glibc (= 2.30-4), gcc-10 (= 10-20200418-1), "
dpkg-gencontrol: warning: Depends field of package tripwire: substitution 
variable ${shlibs:Depends} used, but is not defined
dpkg-gencontrol: warning: Depends field of package tripwire: substitution 
variable ${shlibs:Depends} used, but is not defined
dh_md5sums
dh_builddeb
dpkg-deb: building package 'tripwire-dbgsym' in 
'../tripwire-dbgsym_2.4.3.7-1_amd64.deb'.
dpkg-deb: building package 'tripwire' in '../tripwire_2.4.3.7-1_amd64.deb'.
 dpkg-genbuildinfo --build=binary
 dpkg-genchanges --build=binary >../tripwire_2.4.3.7-1_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)

Build finished at 2020-04-19T14:14:59Z


I have no idea why in the rebuild this happened:
> > dh_gencontrol -- -VBuilt-Using="glibc (= 2.30-4), libgcc1 (= ), "
Instead of:
> dh_gencontrol -- -VBuilt-Using="glibc (= 2.30-4), gcc-10 (= 10-20200418-1), "

Maybe a glitch in the gcc-10 package?


-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#951984: tree-puzzle: FTBFS: mpi.h:322:57: error: static assertion failed: "MPI_Address was removed in MPI-3.0. Use MPI_Get_address instead."

[Alberto Garcia]

On Sun, Apr 05, 2020 at 07:37:28PM +0200, Alberto Garcia wrote:
> The attached patch fixes the build. The latest upstream release
> candidate still uses the old symbol btw.

I'm also attaching the full debdiff.

Berto
diff -Nru tree-puzzle-5.2/debian/changelog tree-puzzle-5.2/debian/changelog
--- tree-puzzle-5.2/debian/changelog	2018-10-16 11:06:43.0 +0200
+++ tree-puzzle-5.2/debian/changelog	2020-04-19 15:29:52.0 +0200
@@ -1,3 +1,11 @@
+tree-puzzle (5.2-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/fix-mpi3-build.patch:
+- Fix FTBFS due to the new MPI-3.0 API (Closes: #951984).
+
+ -- Alberto Garcia   Sun, 19 Apr 2020 15:29:52 +0200
+
 tree-puzzle (5.2-11) unstable; urgency=medium
 
   * debhelper 11
diff -Nru tree-puzzle-5.2/debian/patches/fix-mpi3-build.patch tree-puzzle-5.2/debian/patches/fix-mpi3-build.patch
--- tree-puzzle-5.2/debian/patches/fix-mpi3-build.patch	1970-01-01 01:00:00.0 +0100
+++ tree-puzzle-5.2/debian/patches/fix-mpi3-build.patch	2020-04-19 15:26:28.0 +0200
@@ -0,0 +1,22 @@
+From: Alberto Garcia 
+Subject: Replace obsolete MPI-2.0 API with their MPI-3.0 equivalents
+Bug-Debian: https://bugs.debian.org/951984
+Index: tree-puzzle-5.2/src/ppuzzle.c
+===
+--- tree-puzzle-5.2.orig/src/ppuzzle.c
 tree-puzzle-5.2/src/ppuzzle.c
+@@ -21,11 +21,14 @@
+ #endif
+ 
+ #define EXTERN extern
++#define OMPI_OMIT_MPI1_COMPAT_DECLS 1
+  
+ #include 
+ #include 
+ #include "ppuzzle.h"
+  
++#define MPI_Address MPI_Get_address
++#define MPI_Type_struct MPI_Type_create_struct
+ 
+ int PP_IamMaster;
+ int PP_IamSlave;
diff -Nru tree-puzzle-5.2/debian/patches/series tree-puzzle-5.2/debian/patches/series
--- tree-puzzle-5.2/debian/patches/series	2018-10-16 11:06:43.0 +0200
+++ tree-puzzle-5.2/debian/patches/series	2020-04-19 15:26:28.0 +0200
@@ -1,3 +1,4 @@
 20_no_copy_of_sprng.patch
 tests-need-bash.patch
 spelling.patch
+fix-mpi3-build.patch

Bug#954311: libglx-mesa0: still present in version 20.0.4-1

[alberto]

Package: libglx-mesa0
Version: 20.0.4-1
Followup-For: Bug #954311

Dear Maintainer,

this is to confirm that the problem that appeared in version 20.0.2-1, is
still present in version 20.0.4-1.


-- Package-specific info:
glxinfo:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_no_error, 
GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_no_error, 
GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, 
GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel (0x8086)
Device: Mesa Intel(R) HD Graphics 620 (KBL GT2) (0x5916)
Version: 20.0.4
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.4
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
GL_3DFX_texture_compression_FXT1, GL_AMD_conservative_depth, 
GL_AMD_depth_clamp_separate, GL_AMD_draw_buffers_blend, 
GL_AMD_gpu_shader_int64, GL_AMD_multi_draw_indirect, 
GL_AMD_performance_monitor, GL_AMD_pinned_memory, 
GL_AMD_query_buffer_object, GL_AMD_seamless_cubemap_per_texture, 
GL_AMD_shader_stencil_export, GL_AMD_shader_trinary_minmax, 
GL_AMD_texture_texture4, GL_AMD_vertex_shader_layer, 
GL_AMD_vertex_shader_viewport_index, GL_ANGLE_texture_compression_dxt3, 
GL_ANGLE_texture_compression_dxt5, GL_ARB_ES2_compatibility, 
GL_ARB_ES3_1_compatibility, GL_ARB_ES3_2_compatibility, 
GL_ARB_ES3_compatibility, GL_ARB_arrays_of_arrays, GL_ARB_base_instance, 
GL_ARB_blend_func_extended, GL_ARB_buffer_storage, 
GL_ARB_clear_buffer_object, GL_ARB_clear_texture, GL_ARB_clip_control, 
GL_ARB_compressed_texture_pixel_storage, GL_ARB_compute_shader, 
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_cull_distance, 
GL_ARB_debug_output, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, 
GL_ARB_derivative_control, GL_ARB_direct_state_access, 
GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, 
GL_ARB_draw_elements_base_vertex, 

Bug#952102: salmon: FTBFS: SalmonAlevin.cpp:780:6: error: ‘class rapmap::utils::MappingConfig’ has no member named ‘maxSlack’

[Alberto Garcia]

On Sun, Feb 23, 2020 at 09:02:55AM +0100, Lucas Nussbaum wrote:

> > /<>/src/SalmonAlevin.cpp: In function ‘void 
> > processReadsQuasi(alevin::paired_parser*, ReadExperimentT&, ReadLibrary&, 
> > alevin::AlnGroupVec&, std::atomic > unsigned int>&, std::atomic&, std::atomic > int>&, std::atomic&, std::atomic&, 
> > std::atomic&, RapMapIndexT*, std::vector&, 
> > ForgettingMassCalculator&, ClusterForest&, FragmentLengthDistribution&, 
> > BiasParams&, SalmonOpts&, std::mutex&, bool, std::atomic&, volatile 
> > bool&, AlevinOpts&, SoftMapT&, 
> > spp::sparse_hash_map, unsigned int>&)’:
> > /<>/src/SalmonAlevin.cpp:780:6: error: ‘class 
> > rapmap::utils::MappingConfig’ has no member named ‘maxSlack’
> >   780 |   mc.maxSlack = salmonOpts.consensusSlack;
> >   |  ^~~~
> > make[4]: *** [src/CMakeFiles/salmon.dir/build.make:274: 
> > src/CMakeFiles/salmon.dir/SalmonAlevin.cpp.o] Error 1

This usage of mc.maxSlack was already removed upstream last year, see

   
https://github.com/COMBINE-lab/salmon/commit/056f9c357a2b28ebcd5db923c53a1ea635bf88dd

I guess that the salmon package simply needs to be updated to the
most recent upstream version (latest is 1.1.0, Debian has 0.12.0 from
2018).

Berto

Bug#951984: tree-puzzle: FTBFS: mpi.h:322:57: error: static assertion failed: "MPI_Address was removed in MPI-3.0. Use MPI_Get_address instead."

[Alberto Garcia]

Control: tags -1 patch

On Sun, Feb 23, 2020 at 08:39:23AM +0100, Lucas Nussbaum wrote:

> >  2842 | #define MPI_Address(...)  
> > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_Address, MPI_Get_address)
> >  2850 | #define MPI_Type_struct(...)  
> > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_Type_struct, MPI_Type_create_struct)

So tree-puzzle uses two symbols from MPI-2.0 that have been deprecated
in MPI-3.0. Fortunately in both cases the only change is the name of
the symbol, and it's not necessary to do anything else.

See here for details:

   https://www.open-mpi.org/faq/?category=mpi-removed

The attached patch fixes the build. The latest upstream release
candidate still uses the old symbol btw.

Berto
From: Alberto Garcia 
Subject: Replace obsolete MPI-2.0 API with their MPI-3.0 equivalents
Bug-Debian: https://bugs.debian.org/951984
Index: tree-puzzle-5.2/src/ppuzzle.c
===
--- tree-puzzle-5.2.orig/src/ppuzzle.c
+++ tree-puzzle-5.2/src/ppuzzle.c
@@ -21,11 +21,14 @@
 #endif
 
 #define EXTERN extern
+#define OMPI_OMIT_MPI1_COMPAT_DECLS 1
  
 #include 
 #include 
 #include "ppuzzle.h"
  
+#define MPI_Address MPI_Get_address
+#define MPI_Type_struct MPI_Type_create_struct
 
 int PP_IamMaster;
 int PP_IamSlave;

Bug#955727: fotoxx: dcraw is required, but it is not yet a dependency

[Alberto Luaces]

Source: fotoxx
Version: 20.08-1
Severity: grave
Justification: renders package unusable

When starting the program, it checks if "dcraw" executable is found,
and if that it not the case, the program is closed, hence the severity
of the bug report.
   
The solution is to add the package "dcraw" to the list of
dependencies.

A patch is submitted as a MR in salsa.

Regards.

Bug#954287: libfiu: FTBFS on amd64/unstable: Segmentation fault (core dumped)

[Alberto Bertogli]

On Sat, Mar 28, 2020 at 11:52:37AM +, Alberto Bertogli wrote:

On Fri, Mar 27, 2020 at 11:58:05PM -, Chris Lamb wrote:

Hi Alberto,


libfiu now fails to build from source in unstable/amd64:

 […]

 ./wrap-python 3 ./test-set_prng_seed.py
 LD_LIBRARY_PATH=../../libfiu/
LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/open.bin
 LD_LIBRARY_PATH=../../libfiu/
LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/fread.bin
 rm tests/open.bin tests/fread.bin./wrap-python 3 ./test-fiu_ctrl.py
  tests/open64.bin tests/strdup.bin tests/pread.bin tests/pread64.bin
tests/malloc.bin./wrap-python 3 ./test-basic.py
  tests/mmap.bin tests/fprintf.bin tests/kill.bin tests/fopen.bin
 make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/generated'
 ./wrap-python 3 ./test-onetime.py
 ./wrap-python 3 ./test-set_prng_seed-env.py
 make[3]: *** [Makefile:96: py-run-test-failinfo_refcount]
Segmentation fault (core dumped)
 make[3]: *** Waiting for unfinished jobs
 make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/utils'
 rm test-enable_stack test-ferror test-enable_stack_by_name
 make[3]: Leaving directory '/tmp/buildd/libfiu-1.00/tests'
 make[2]: *** [Makefile:58: test] Error 2
 make[2]: Leaving directory '/tmp/buildd/libfiu-1.00'
 dh_auto_test: error: make -j9 test V=1 LC_ALL=C returned exit code 2
 make[1]: *** [debian/rules:33: override_dh_auto_test] Error 25
 make[1]: Leaving directory '/tmp/buildd/libfiu-1.00'
 make: *** [debian/rules:13: binary] Error 2
 dpkg-buildpackage: error: debian/rules binary subprocess returned
exit status 2

 […]

I suspect this to be Python 3.8 related. Alberto, any ideas? :)  The
full build log is attached if it helps.


Indeed it's related to Python 3.8 although I think it just surfaces a 
but that's always existed.


https://blitiri.com.ar/git/r/libfiu/c/ffa89556eda5fc05cd496150880519b575c2908e/
should fix it.

While at it I noticed a few other things so if this fixes the build in 
Debian too, I will probably include it in master and do a release in the 
next few days.


If you try the patch above, please let me know how it goes.

Thanks!
    Alberto

Bug#954287: libfiu: FTBFS on amd64/unstable: Segmentation fault (core dumped)

[Alberto Bertogli]

On Fri, Mar 27, 2020 at 11:58:05PM -, Chris Lamb wrote:

Hi Alberto,


libfiu now fails to build from source in unstable/amd64:

  […]

  ./wrap-python 3 ./test-set_prng_seed.py
  LD_LIBRARY_PATH=../../libfiu/
LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/open.bin
  LD_LIBRARY_PATH=../../libfiu/
LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/fread.bin
  rm tests/open.bin tests/fread.bin./wrap-python 3 ./test-fiu_ctrl.py
   tests/open64.bin tests/strdup.bin tests/pread.bin tests/pread64.bin
tests/malloc.bin./wrap-python 3 ./test-basic.py
   tests/mmap.bin tests/fprintf.bin tests/kill.bin tests/fopen.bin
  make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/generated'
  ./wrap-python 3 ./test-onetime.py
  ./wrap-python 3 ./test-set_prng_seed-env.py
  make[3]: *** [Makefile:96: py-run-test-failinfo_refcount]
Segmentation fault (core dumped)
  make[3]: *** Waiting for unfinished jobs
  make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/utils'
  rm test-enable_stack test-ferror test-enable_stack_by_name
  make[3]: Leaving directory '/tmp/buildd/libfiu-1.00/tests'
  make[2]: *** [Makefile:58: test] Error 2
  make[2]: Leaving directory '/tmp/buildd/libfiu-1.00'
  dh_auto_test: error: make -j9 test V=1 LC_ALL=C returned exit code 2
  make[1]: *** [debian/rules:33: override_dh_auto_test] Error 25
  make[1]: Leaving directory '/tmp/buildd/libfiu-1.00'
  make: *** [debian/rules:13: binary] Error 2
  dpkg-buildpackage: error: debian/rules binary subprocess returned
exit status 2

  […]

I suspect this to be Python 3.8 related. Alberto, any ideas? :)  The
full build log is attached if it helps.


Wondering if you got this? I just got a mail that libfiu will be
"autoremoved" from testing soon.


Ack on this!

Sorry I've been slow to respond, but will take a look at this this 
weekend.


I'll send another email once I know more.

Thanks!
Alberto

Bug#945875: openmw: Crash when saving

[Alberto Luaces]

severity 945875 normal
thanks

Adjusting severity for openscenegraph.

Bug#945875: openmw: Crash when saving

[Alberto Luaces]

On 27/3/20 10:57, Bret Curtis wrote:
> Man, it's be in there a month. It would be a pity to see OSG be broken
> in Buster, but hopefully we get it in before Ubuntu's LTS 20.04 Focal
> release. :/
> 
> I hope it gets uploaded soon.

Well, you know that people have lives outside this scene :-)

Nevertheless, if any DD is willing to do the uploading, we would also be
grateful -- just tell us beforehand in order to not collide.

Bug#945875: openmw: Crash when saving

[Alberto Luaces]

On 27/3/20 8:26, Bret Curtis wrote:
> The best way forward in resolving this bug is to get OpenSceneGraph
> package bumped to 3.6.5 right away. This requires the help of Alberto
> Fernández, it's package maintainer.
> https://tracker.debian.org/pkg/openscenegraph

Him, OSG 3.6.5 is ready
(https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/blob/master/debian/changelog),
I'm just waiting for Manuel to upload it.

Regards,

Alberto

Bug#952252: wpebackend-fdo: FTBFS: /bin/sh: 1: client-header: not found

[Alberto Garcia]

Control: tags -1 pending

On Sun, Feb 23, 2020 at 02:21:31PM +0100, Lucas Nussbaum wrote:
> Source: wpebackend-fdo
> Version: 1.4.0-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye

Known problem, it will be fixed in the next upload, thanks!

Berto

Bug#855541: Update: actually it works

[Alberto Garcia]

On Fri, Feb 21, 2020 at 04:05:51AM +0100, Jean-Philippe MENGUAL wrote:

> Ok I have just built the git release, now it works. So to maintain
> this package usable in Debian, you need to update it to the latest
> git release, from December, 28. Do you want a specific bug to
> request update? Without it, I think it is unusable now.

The Debian package is from the December 28 release (hence the version
number 0.0.0+git20191228-1). Which one are you trying?

Berto

Bug#951588: kontact: akonadi is not operational

[Alberto Fuentes]

Package: kontact
Version: 4:19.08.3-1
Severity: grave
Justification: renders package unusable

Application: Akonadi Control (akonadi_control), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7ff192558800 (LWP 1433258))]

Thread 5 (Thread 0x7ff189e1f700 (LWP 1433262)):
#0  0x7ff195d5abef in __GI___poll (fds=0x7ff1800021e0, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7ff19510710e in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7ff19510722f in g_main_context_iteration () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7ff1962e381b in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7ff19628c71b in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7ff1960cd731 in QThread::exec() () from /usr/lib/x86_64-linux-
gnu/libQt5Core.so.5
#6  0x7ff196bf14e6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7ff1960ce8b2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7ff195c52fb7 in start_thread (arg=) at
pthread_create.c:486
#9  0x7ff195d651af in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7ff18a703700 (LWP 1433261)):
#0  0x7ff195d5abef in __GI___poll (fds=0x55fdcd713ff0, nfds=2, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7ff19510710e in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7ff195107473 in g_main_loop_run () from /usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0
#3  0x7ff18b9c89e6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x7ff19512fd7d in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7ff195c52fb7 in start_thread (arg=) at
pthread_create.c:486
#6  0x7ff195d651af in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7ff18af04700 (LWP 1433260)):
#0  0x7ff195d5abef in __GI___poll (fds=0x55fdcd6ffb90, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7ff19510710e in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7ff19510722f in g_main_context_iteration () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7ff195107281 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7ff19512fd7d in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7ff195c52fb7 in start_thread (arg=) at
pthread_create.c:486
#6  0x7ff195d651af in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7ff1912c6700 (LWP 1433259)):
#0  0x7ff195d5abef in __GI___poll (fds=0x7ff1912c5ca8, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7ff194ff1cf7 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7ff194ff391a in xcb_wait_for_event () from /usr/lib/x86_64-linux-
gnu/libxcb.so.1
#3  0x7ff191eabca0 in ?? () from /usr/lib/x86_64-linux-
gnu/libQt5XcbQpa.so.5
#4  0x7ff1960ce8b2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7ff195c52fb7 in start_thread (arg=) at
pthread_create.c:486
#6  0x7ff195d651af in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7ff192558800 (LWP 1433258)):
[KCrash Handler]
#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#7  0x7ff195c90535 in __GI_abort () at abort.c:79
#8  0x55fdcbc662e2 in akMessageHandler (type=QtFatalMsg, msg=...,
context=...) at ./src/shared/akdebug.cpp:205
#9  akMessageHandler (type=, context=..., msg=...) at
./src/shared/akdebug.cpp:194
#10 0x55fdcbc6834e in (anonymous namespace)::RemoteLogger::dbusLogger
(type=QtFatalMsg, ctx=..., msg=...) at ./src/shared/akremotelog.cpp:178
#11 0x7ff1960c64b1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7ff1960c65c9 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x7ff196096a44 in QMessageLogger::fatal(char const*, ...) const () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x55fdcbc3c4e1 in AgentManager::AgentManager (this=0x7ffd636395f0,
verbose=, parent=) at /usr/include/x86_64-linux-
gnu/qt5/QtCore/qlogging.h:91
#15 0x55fdcbc3e374 in main (argc=, argv=) at
./src/akonadicontrol/main.cpp:76
[Inferior 1 (process 1433258) detached]



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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kontact depends on:

Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

[Alberto Molina Coballes]

Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1407
Control: severity -1 normal

Hi Christoph,

I'm quoting a email from Jamie Strandboge, who is both the
maintainer in Debian and the creator of ufw, and has kindly replied my
question about this bug:

[quote]
...

These rules were not generated by ufw. The current released version of
ufw does not do any management of the nat table. Furthermore,
iptables-restore rules in /etc/ufw/*rules do not contain any '-F's.

...

Now, the 'ufw-framework' man page documents how someone can adjust
/etc/ufw/{before,after}{,6}.rules files to customize the firewall with
iptables-restore directives for things that the ufw cli command does not
expose and it is not uncommon for people to add things to other tables.
The man page does *not* document use of -F in these files and instead
has examples like:

  *nat
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
  COMMIT

So I suspect what happened is the reporter used this mechanism to
customize the firewall and accidentally added the second, errant -F.
[/quote]

In any case, the bug exists and it has been reported upstream.

After some test, it seems that the problem is related to the flush of
the rules after adding some of them (do you really want to do that?),
because the next ruleset works well:

*nat
-F PREROUTING
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
-F POSTROUTING
COMMIT

And the same result will be obtained with:

*nat
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
COMMIT

Because the default iptables-restore behaviour is to flush (delete)
all previous contents of the respective tables.

I think you can workaround the bug rewriting your rules with special
care in the inclusion of '-F' rules.

I think it is correct that the error was initially reported with grave
severity, but after this analysis I think it is appropriate to lower
the severity to normal unless the segfault is discovered in a more
general case.

Regards,

Alberto