On Jul 22 2023, Rene Engelhard wrote:
> Hi,
>
> Am 22.07.23 um 16:09 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
> Does opensuse have some public git/$VCS?
https://buil
On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard wrote:
>
> Am 22.07.23 um 14:02 schrieb Andreas Schwab:
> > On Jun 18 2023, Rene Engelhard wrote:
> >
> >> For riscv64 I already pointed that out in the thread starting at
> >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
>
Hi,
Am 22.07.23 um 16:09 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Does opensuse have some public git/$VCS?
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreo
On Jul 22 2023, Rene Engelhard wrote:
> Am 22.07.23 um 15:53 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Does opensuse have some public git/$VCS?
>> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
>
> Thanks...
>
> B
On Jul 22 2023, Rene Engelhard wrote:
> Does opensuse have some public git/$VCS?
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
> (Though I would more bet of some system evironment thingy)
Perhaps it is a matter of using a good java. Have
Am 22.07.23 um 15:53 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Does opensuse have some public git/$VCS?
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64
Thanks...
But maybe I am too blind.
I don't see the actual spe
Hi,
Am 22.07.23 um 15:07 schrieb Andreas Schwab:
Which gives the smoketest test failure here I pointed out (again) in my
other mail.
$ find /usr/lib64/libreoffice/ -name "*smoke*"
/usr/lib64/libreoffice/program/classes/smoketest.jar
How can I run that?
You can't from that, ttbomk. You miss o
Hi,
Am 22.07.23 um 15:02 schrieb Andreas Schwab:
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
On Jul 22 2023, Rene Engelhard wrote:
> Hi,
>
> Am 22.07.23 um 14:28 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
>>> though)
>> On openSUSE Factory, libreoffice is built with the usual compiler fl
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.
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
On Jul 22 2023, Rene Engelhard wrote:
> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
> though)
On openSUSE Factory, libreoffice is built with the usual compiler flags,
wich includes full optimisation and hardening.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fi
On Jul 22 2023, Rene Engelhard wrote:
> Just not registering or unregistering *any* extension.
What does that mean? I haven't seen any errors about extensions.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for somethi
Hi,
Am 22.07.23 um 14:34 schrieb Andreas Schwab:
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.
Hi,
Am 22.07.23 um 14:28 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
though)
On openSUSE Factory, libreoffice is built with the usual compiler flags,
wich includes full optimisation and hardening.
Wh
Hi,
Am 22.07.23 um 14:25 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
Just not registering or unregistering *any* extension.
What does that mean? I haven't seen any errors about extensions.
Do you run the testsuite?
Especially the smoketest?
And you are replying to exac
Hi,
Am 22.07.23 um 14:09 schrieb Rene Engelhard:
And that included packaged extensions so if they install but don't work
that's a grave bug.
And that includes LibreOffice-bundled extensions like the
english,hungarian,russian grammar checker for example. Ot external
finnish spellchecking, hyp
On Jun 18 2023, Rene Engelhard wrote:
> For riscv64 I already pointed that out in the thread starting at
> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
> other architectures there is the mail now. riscv64 is different because
> the failures are even more big than any ot
Hi,
Am 22.07.23 um 14:02 schrieb Andreas Schwab:
On Jun 18 2023, Rene Engelhard wrote:
For riscv64 I already pointed that out in the thread starting at
https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
other architectures there is the mail now. riscv64 is different becau
On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 25.06.23 um 13:37 schrieb Rene Engelhard:
> > > what about the
> > > following:
> > > - make all test failures fatal on a*64 (since upstream tests these), and
> > > - make smoketest failures fatal on all architectures (in
Hi,
Am 03.07.23 um 21:31 schrieb Rene Engelhard:
Am 25.06.23 um 13:37 schrieb Rene Engelhard:
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 m
Hi,
Am 25.06.23 um 13:37 schrieb Rene Engelhard:
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
http
Hi,
Am 20.06.23 um 10:25 schrieb 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->Cha
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, ple
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
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->Cha
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 w
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 bu
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 w
On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard 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 r
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 i
Hi,
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
On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote:
>...
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
>...
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep
On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard wrote:
>
> Hi,
>
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
> > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
> >> ...
> >> I won't be of much help here unfortunately, except
> >> maybe testing patches, but then again there's porter
On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
>...
> I won't be of much help here unfortunately, except
> maybe testing patches, but then again there's porterboxes
>...
You are the only one who could realistically debug many of these.
E.g. on armel it says:
Fatal exception: Si
Hi,
Am 19.06.23 um 23:19 schrieb Adrian Bunk:
On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
...
I won't be of much help here unfortunately, except
maybe testing patches, but then again there's porterboxes
...
You are the only one who could realistically debug many of these.
On Sunday 2023-06-18 23:37, Rob Landley wrote:
>On 6/18/23 14:58, Rene Engelhard wrote:
>>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3
>>> and
>>> the AGPL have been rejected soundly by most developers" and talked about
>>> how he
>>> regretted the move and the dam
On 6/18/23 15:19, Rene Engelhard wrote:
> Besides that it would also have been clear from actually reading the IRC
> log which incidentially also says
Good to know what the expectations for participation are.
>> This is the same GPLv3 package that Red Hat just dropped support for?
>
> As I said
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote:
>On 6/18/23 14:58, Rene Engelhard wrote:
>>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3
>>> and
>>> the AGPL have been rejected soundly by most developers" and talked about
>>> how he
>>> regretted the m
On 6/18/23 14:58, Rene Engelhard wrote:
>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and
>> the AGPL have been rejected soundly by most developers" and talked about how
>> he
>> regretted the move and the damage it had done to the project,
>> https://archive.org/det
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 genera
Hi,
Am 18.06.23 um 21:28 schrieb Rob Landley:
Of course I mean "getting those architectures removed from unstable"
*for libreoffice*.
This is the same GPLv3 package that Red Hat just dropped support for?
GPLv3 doesn't have anything to do with this here.
https://lwn.net/Articles/933525/
Inde
On 6/18/23 03:45, Rene Engelhard wrote:> Am 18.06.23 um 10:32 schrieb Rene
Engelhard:
I don't really like sweeping it under the carpet again and would
actually pursue the "getting those architectures removed from unstable"
way pointed out and (implicitely) approved/suggested by the r
> Le 18 juin 2023 à 13:37, Steve McIntyre a écrit :
>
> On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote:
>> Hi,
>>
>>> Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz:
>>> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
Also note I am not talking about the
On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote:
>Hi,
>
>Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz:
>> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
>> > Also note I am not talking about the debian-ports architectures. Those I
>> > forgot and I have no problem
Hi again.
Am 18.06.23 um 10:32 schrieb Rene Engelhard:
I don't really like sweeping it under the carpet again and would
actually pursue the "getting those architectures removed from unstable"
way pointed out and (implicitely) approved/suggested by the release
team...
You want Debian to drop sup
Hi,
Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz:
On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
Also note I am not talking about the debian-ports architectures. Those I
forgot and I have no problems making them stay into "testsuite ran but
results ignored" set.
Why did you
Hello!
On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
> Also note I am not talking about the debian-ports architectures. Those I
> forgot and I have no problems making them stay into "testsuite ran but
> results ignored" set.
Why did you send this mail exclusively to debian-ports then?
Hi,
I originally wanted to send the mail after all the architectures got
result but now even after 6d mips64el didn't try it so I send it now.
Prompted by riscv64 supposed to be added to the archive and even
as a release arch for trixie - see
https://lists.debian.org/debian-devel-announce/2023/
49 matches
Mail list logo
