Re: unbreaking LibreOffices tests on at least release architectures

[Paul Wise]

On Tue, 2023-06-20 at 22:46 +0200, Kurt Roeckx wrote:

> Can I suggest that if you file a few bugs and add some information in
> it so that maybe someone can look at it? If it only affects one
> architecture, send a mail to that list asking for help.

PS: when filing architecture-specific bugs, please also set the BTS
usertags and XCC the ports lists for the architectures effected.

https://wiki.debian.org/Teams/Debbugs/ArchitectureTags

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: unbreaking LibreOffices tests on at least release architectures

[Kurt Roeckx]

Can I suggest that if you file a few bugs and add some information in it so 
that maybe someone can look at it? If it only affects one architecture, send a 
mail to that list asking for help.

Kurt

Re: unbreaking LibreOffices tests on at least release architectures

[Rene Engelhard]

Hi,

Am 20.06.23 um 16:52 schrieb Kurt Roeckx:

On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:

Hi,

Am 19.06.23 um 23:29 schrieb Rene Engelhard:

The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.

And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.

There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.

That said, that is the smoketest on mipsel:

The problem with a mail like this is that it really doesn't help anybody
in understanding the problem. As porter, it will probably take a lot of
time to get to the point where you can start looking at what the problem
might be. It contains lots of information, but it's not clear what the
problem is and what needs to be looked at.

Except by just starting to build and run into an issue

(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory
'/run/user/2952/dconf': Permission denied.  dconf will not work properly.

(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory
'/run/user/2952/dconf': Permission denied.  dconf will not work properly.

(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory
'/run/user/2952/dconf': Permission denied.  dconf will not work properly.

Is this something the porter should look at? Is is relevant?


No. That also happens everywhere, also on amd64/arm64.



Fatal exception: Signal 11

It's a segfault,

I know :)

this should normally be trivial for you to debug,
but is probably complicated for a porter to find out how to do things
like attaching a debugger to the relevant process.


Well, the command line is there, but I see the point.

Still one could talk about this... I yet have to hear from any porter 
talking about actual issues (and the buildlogs *are* there).



Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]

Is this some openjdk problem, not a problem in libreoffice problem?


In this specific case probably openjdk. I was juat answering Adrian on 
the smoketest.


Actually I run a --disable-java build on eller right now.


./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()

So the (TCP?) connection is not alive? Why not? That doesn't seem to be
platform specific. Is that a problem in the test suite, and not
libreoffice itself?


Because libreoffice crashed, "obviously", so there of course is no 
connection anymore.


The point here is that it even crashes at startup so probably being 
completely broken. (and I am not surprised)



unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048

(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()

##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException

And then the test suite crashes because it can't actually deal
with the previous the assertion failure, and the segfault above
is not relevant at all?


It crashes because libreoffice crashed, the connection is not there and 
therefore not alive. Yes, I can read that.


As said, I was just pointing at a smoketest example.



The most likely thing is that this is not a platform specific issue,
but a either a general issue that just shows up on some platforms for
whatever reason, or some problem in an other piece of software that
libreoffice is using that does have a pratform specific issue.



This specific one might be, yes.


That's probably not true for the other architectures' failures. (E.g. 
the Bus error I mentioned earlier or the powerpcs having 
"Trace/breakpoint trap (core dumped)" or s390x or armel crashing in 
loading tiff files.


And that is all only the first failure on earch archs, there's more, 
there's gazillions of failures in  the architectures' build logs.



Regards,


Rene

Re: unbreaking LibreOffices tests on at least release architectures

[Kurt Roeckx]

On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
> Hi,
> 
> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
> > > The pragmatic option would be to run only a smoketest for build success
> > > on architectures not tested by upstream.
> > 
> > And have Format->Character in Impress crash with Bus error like on
> > mipsel? That doesn't sound too good for basic quality.
> > 
> > There is a "smoketest" but it does just basic start. open, close stuff.
> > Not even basic usage.
> 
> That said, that is the smoketest on mipsel:

The problem with a mail like this is that it really doesn't help anybody
in understanding the problem. As porter, it will probably take a lot of
time to get to the point where you can start looking at what the problem
might be. It contains lots of information, but it's not clear what the
problem is and what needs to be looked at.

> (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory
> '/run/user/2952/dconf': Permission denied.  dconf will not work properly.
> 
> (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory
> '/run/user/2952/dconf': Permission denied.  dconf will not work properly.
> 
> (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory
> '/run/user/2952/dconf': Permission denied.  dconf will not work properly.

Is this something the porter should look at? Is is relevant? 

> Fatal exception: Signal 11

It's a segfault, this should normally be trivial for you to debug,
but is probably complicated for a porter to find out how to do things
like attaching a debugger to the relevant process.

> Stack:
> /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
> /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
> /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]

Is this some openjdk problem, not a problem in libreoffice problem?

> ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
> assertion failed
> - Expression: connection_.isStillAlive()

So the (TCP?) connection is not alive? Why not? That doesn't seem to be
platform specific. Is that a problem in the test suite, and not
libreoffice itself?

> unknown:0:(anonymous namespace)::Test::test
> tearDown() failed
> - An uncaught exception of type com.sun.star.lang.DisposedException
> - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
> 
> (anonymous namespace)::Test::test finished in: 76764ms
> smoketest.cxx:187:Assertion
> Test name: (anonymous namespace)::Test::test
> assertion failed
> - Expression: connection_.isStillAlive()
> 
> ##Failure Location unknown## : Error
> Test name: (anonymous namespace)::Test::test
> tearDown() failed
> - An uncaught exception of type com.sun.star.lang.DisposedException

And then the test suite crashes because it can't actually deal
with the previous the assertion failure, and the segfault above
is not relevant at all?

The most likely thing is that this is not a platform specific issue,
but a either a general issue that just shows up on some platforms for
whatever reason, or some problem in an other piece of software that
libreoffice is using that does have a pratform specific issue.


Kurt

Re: unbreaking LibreOffices tests on at least release architectures

[Kirsten Bromilow]

Stop sending these emails please! 

Sent from my iPhone

> On 20 Jun 2023, at 09:42, Adrian Bunk  wrote:
> 
> On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
>> Hi,
>> 
>> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
 The pragmatic option would be to run only a smoketest for build success
 on architectures not tested by upstream.
>>> 
>>> And have Format->Character in Impress crash with Bus error like on
>>> mipsel? That doesn't sound too good for basic quality.
>>> 
>>> There is a "smoketest" but it does just basic start. open, close stuff.
>>> Not even basic usage.
>> 
>> That said, that is the smoketest on mipsel:
>> ...
> 
> Assuming the smoketest currently also fails on riscv64, what about the 
> following:
> - make all test failures fatal on a*64 (since upstream tests these), and
> - make smoketest failures fatal on all architectures (including ports)
> 
>> Regards,
>> 
>> Rene
> 
> cu
> Adrian
> 

Re: unbreaking LibreOffices tests on at least release architectures

[Adrian Bunk]

On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
> Hi,
> 
> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
> > > The pragmatic option would be to run only a smoketest for build success
> > > on architectures not tested by upstream.
> > 
> > And have Format->Character in Impress crash with Bus error like on
> > mipsel? That doesn't sound too good for basic quality.
> > 
> > There is a "smoketest" but it does just basic start. open, close stuff.
> > Not even basic usage.
> 
> That said, that is the smoketest on mipsel:
>...

Assuming the smoketest currently also fails on riscv64, what about the 
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)

> Regards,
> 
> Rene

cu
Adrian

Re: Bug#995159: hfsprogs: Directory hardlink problems cannot be repaired.

[John Paul Adrian Glaubitz]

Hi Daniel!

On Tue, 2023-06-20 at 07:11 +0200, Daniel Höpfl wrote:
> Your answer is still faster than anything from Apple.

Took me still way too long.

> Just note that your links go to an unofficial repo.
> The official repository is at 
> .

You're absolutely right and I only noticed this after sending the reply
to your bug report. I will have to rebase my Linux patches.

> HFS does not look like one of the projects that care about pull 
> requests:
> 

I saw your pull request and I think that Apple is simply not monitoring
this repository. I am trying to find someone at Apple that can help us
here, both with the license and community improvements. It certainly
won't be easy though.

Adrian

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