Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: unbreaking LibreOffices tests on at least release architectures
0 views
Skip to first unread message
Rene Engelhard
Jun 18, 2023, 4:30:03 PM6/18/23
to
Hi again,
some more comments.
Am 18.06.23 um 21:28 schrieb Rob Landley:
> No, that's how I read it too. You said getting the _architectures_
> removed, not
> getting libreoffice removed from those architectures.
That is hilarious. The subject says we are talking about LibreOffice
here, not generally about Debian.
I might have written architectures, but from the context it should have
been clear. Anyway, I corrected it.
>> Of course I mean "getting those architectures removed from unstable"
>> *for libreoffice*.
here.
Besides that it would also have been clear from actually reading the IRC
log which incidentially also says
"17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask
for removal from architectures where reasonable tests fail
17:25 < elbrus> extreme case you only ship on amd64 and arm64"
(libreoffice) *removal from architectures*
> This is the same GPLv3 package that Red Hat just dropped support for?
As I said in my other reply, even if it was GPLv3 it wouldn't be
relevant at all.
LibreOffice is not GPLv3 though and never was.
> How long has the problem you're treating as a crisis been brewing?
Basically ever since people ported, the tests back then pass and then
new tests broke and noone seriously cared until me as not-porter needed
to sweep it under the carpet eo get it "ready" for release (because it
otherwise was supposed to be removed).
Or since people added a new arch in LibreOffice but didn't dare of
finishing it so that even the important tests pass.
Even if it works now, who says that with ignored tests something
fundamental breaks (like python thingies in riscv64, which is a integral
part of many LO things). Or some basic functionality? Causing a RC bug
which is unfixable for me.
Replying with something completely unrelated doesn't help here. No idea
why you bring up GPLv3 or RH stopping support for it (which is bad for
this case, though, since at least they did fix some tests on s390x etc.,
but we actually do have porters, too) here on a mail which just aims at
porting LibreOffice / making it actually pass its tests to improve quality.
Regards,
Rene
some more comments.
Am 18.06.23 um 21:28 schrieb Rob Landley:
> No, that's how I read it too. You said getting the _architectures_
> removed, not
> getting libreoffice removed from those architectures.
That is hilarious. The subject says we are talking about LibreOffice
here, not generally about Debian.
I might have written architectures, but from the context it should have
been clear. Anyway, I corrected it.
>> Of course I mean "getting those architectures removed from unstable"
>> *for libreoffice*.
here.
Besides that it would also have been clear from actually reading the IRC
log which incidentially also says
"17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask
for removal from architectures where reasonable tests fail
17:25 < elbrus> extreme case you only ship on amd64 and arm64"
(libreoffice) *removal from architectures*
> This is the same GPLv3 package that Red Hat just dropped support for?
As I said in my other reply, even if it was GPLv3 it wouldn't be
relevant at all.
LibreOffice is not GPLv3 though and never was.
> How long has the problem you're treating as a crisis been brewing?
Basically ever since people ported, the tests back then pass and then
new tests broke and noone seriously cared until me as not-porter needed
to sweep it under the carpet eo get it "ready" for release (because it
otherwise was supposed to be removed).
Or since people added a new arch in LibreOffice but didn't dare of
finishing it so that even the important tests pass.
Even if it works now, who says that with ignored tests something
fundamental breaks (like python thingies in riscv64, which is a integral
part of many LO things). Or some basic functionality? Causing a RC bug
which is unfixable for me.
Replying with something completely unrelated doesn't help here. No idea
why you bring up GPLv3 or RH stopping support for it (which is bad for
this case, though, since at least they did fix some tests on s390x etc.,
but we actually do have porters, too) here on a mail which just aims at
porting LibreOffice / making it actually pass its tests to improve quality.
Regards,
Rene
Jeffrey Walton
Jun 20, 2023, 12:30:04 AM6/20/23
to
On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard <re...@debian.org> wrote:
>
> Am 20.06.23 um 00:03 schrieb Jeffrey Walton:
> >
> > You can usually uncover them by building the package with CFLAGS=" ...
> > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
> > ". The UBsan sanitizer operates on real data. There are no false
> > positives.
>
> I'd personally assume this isn't UB since upstream builds with UBsan for
> testing (admittedly not on mipsel, though). But once can investigate here...
Yeah, there's a caveat: you have to have complete self tests. If the
project lacks complete self tests, then you may not uncover the bug.
You can run the program in production with a sanitizer build. It may
uncover cases that were lacking in the test cases.
And it's unfortunate some arches lack Asan and UBsan support. They are
such powerful tools. Sometimes you can tease-out the UB on a different
arch. Sometimes you can't.
Jeff
>
> Am 20.06.23 um 00:03 schrieb Jeffrey Walton:
> >
> > You can usually uncover them by building the package with CFLAGS=" ...
> > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
> > ". The UBsan sanitizer operates on real data. There are no false
> > positives.
>
> I'd personally assume this isn't UB since upstream builds with UBsan for
> testing (admittedly not on mipsel, though). But once can investigate here...
Yeah, there's a caveat: you have to have complete self tests. If the
project lacks complete self tests, then you may not uncover the bug.
You can run the program in production with a sanitizer build. It may
uncover cases that were lacking in the test cases.
And it's unfortunate some arches lack Asan and UBsan support. They are
such powerful tools. Sometimes you can tease-out the UB on a different
arch. Sometimes you can't.
Jeff
Adrian Bunk
Jun 20, 2023, 4:50:03 AM6/20/23
to
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
> 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
Paul Wise
Jun 20, 2023, 10:20:04 PM6/20/23
to
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
> 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
Laurent Siksous
Jul 4, 2023, 10:00:03 AM7/4/23
to
LibreOffice c'est un logiciel qui ne devrait même pas exister !
Adrian Bunk <bu...@debian.org> writes:
> On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote:
>> Hi,
>>
>> Am 25.06.23 um 13:37 schrieb Rene Engelhard:
>> https://buildd.debian.org/status/package.php?p=libreoffice
>>
>> It does
>> - bridgetest
>> - smoketest
>> - pyuno
>>
>> What fails for release archs astonishingly is only mips(64)el.
>
> It also failed on riscv64 (and powerpc), so that seems to be
> a criteria that catches the known-broken builds.
>
>>...
>> This test extension to be installed is a Java extension.
>> So I am running a nojava build on eller now... I don't really like disabling
>> Java since this opens Pandoras box but for mips64el we probably could do
>> that.
>
> It would also hint at a MIPS problem in LibreOffice,
> which might or might not be specific to Java.
>
> AFAIK OpenJDK on MIPS does not have any known major issues.
>
> The Zero build of OpenJDK on MIPS is of course slow,
> but that's also true on armel where the build succeeded.
>
>> Regards,
>>
>> Rene
>
> cu
> Adrian
>
> BTW: The MIPS-specific discussion should continue on debian-mips instead
> of debian-ports.
--
Laurent Siksous
78 Rue de Châtillon
RENNES, Ille-et-Vilaine, 35000
France
T: +33650544050
---
“Some people worry that artificial intelligence will make us feel
inferior, but then, anybody in his right mind should have an
inferiority complex every time he looks at a flower.”
—Alan Kay
Adrian Bunk <bu...@debian.org> writes:
> On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote:
>> Hi,
>>
>> > > 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)
>>
>> That was implemented (+ two more important tests) in experimental. See
>> > > following:
>> > > - make all test failures fatal on a*64 (since upstream tests these), and
>> > > - make smoketest failures fatal on all architectures (including ports)
>>
>> https://buildd.debian.org/status/package.php?p=libreoffice
>>
>> It does
>> - bridgetest
>> - smoketest
>> - pyuno
>>
>> What fails for release archs astonishingly is only mips(64)el.
>
> It also failed on riscv64 (and powerpc), so that seems to be
> a criteria that catches the known-broken builds.
>
>>...
>> This test extension to be installed is a Java extension.
>> So I am running a nojava build on eller now... I don't really like disabling
>> Java since this opens Pandoras box but for mips64el we probably could do
>> that.
>
> It would also hint at a MIPS problem in LibreOffice,
> which might or might not be specific to Java.
>
> AFAIK OpenJDK on MIPS does not have any known major issues.
>
> The Zero build of OpenJDK on MIPS is of course slow,
> but that's also true on armel where the build succeeded.
>
>> Regards,
>>
>> Rene
>
> cu
> Adrian
>
> BTW: The MIPS-specific discussion should continue on debian-mips instead
> of debian-ports.
--
Laurent Siksous
78 Rue de Châtillon
RENNES, Ille-et-Vilaine, 35000
France
T: +33650544050
---
“Some people worry that artificial intelligence will make us feel
inferior, but then, anybody in his right mind should have an
inferiority complex every time he looks at a flower.”
—Alan Kay
Andreas Schwab
Jul 22, 2023, 9:00:04 AM7/22/23
to
On Jul 22 2023, Rene Engelhard wrote:
> And that includes LibreOffice-bundled extensions like the
> english,hungarian,russian grammar checker for example. Ot external finnish
> spellchecking, hyphenation and grammer checking. Or turkish spellchecing.
>
> And those are extensions written in python which neither register when
> registering manually nor when being installed as bundled extensions (see
> the discussion in this thread, not going to reiterate)
How can I test that? I have never used libreoffice before, so I don't
know what to look for.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
> And that includes LibreOffice-bundled extensions like the
> english,hungarian,russian grammar checker for example. Ot external finnish
> spellchecking, hyphenation and grammer checking. Or turkish spellchecing.
>
> And those are extensions written in python which neither register when
> registering manually nor when being installed as bundled extensions (see
> the discussion in this thread, not going to reiterate)
How can I test that? I have never used libreoffice before, so I don't
know what to look for.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Andreas Schwab
Jul 22, 2023, 9:30:04 AM7/22/23
to
On Jul 22 2023, Rene Engelhard wrote:
> https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual
> thing. And the IRC log shows that even libreoffice-lightproof-en etc don't
> appear as bundled extensions.
$ unopkg list --bundled
All deployed bundled extensions:
Identifier: org.openoffice.en.hunspell.dictionaries
Version: 2022.05.01
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Lightproof.components
is registered: yes
Media-Type: application/vnd.sun.star.uno-components
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Linguistic.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
0 new messages