Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Rene Engelhard]

Hi,

Am 25.04.24 um 18:37 schrieb Andreas B. Mundt:

On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote:

Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:

For now, we traced the issue back to libreoffice-kf5.  If this package
is removed, neither the document disappears on closing libreoffice nor
the popup is shown when 'nobrl' is removed from the mount options.

Which doesn't do IO itself though? But maybe the KDE file picker (over kio)
does something weird? But saving (ttbomk) isn't done by the file picker
itself?

I just tried a trixie XFCE desktop and cannot reproduce the issue
there.  Then I installed KDE and switched the DE. In KDE again the
issue is reproducable, removing libreoffice-kf5 makes the problem go
away.  Installing libreoffice-kf5 again: Issue is back.

Shrugs.

However, back in XFCE, even with libreoffice-kf5 installed, the issue
does not show up.


Because in XFCE you don't get the KDE File Picker but the Gtk one.

Unless you force kf5, which I don't think you do.


  The different file chooser GUIs seem to trigger the
issue.

Interesting.

Removing libreoffice-kf5 or switching to XFCE results in a
different file chooser, which somehow causes the problem.  So the bug
is probably not in libreoffice-kf5 …


-kf5 does contain the KDE file picker used in LibreOffice.


In any case, try with >= 24.2.2 (so sid). If that commit was it (which I 
somehow doubt, see my previous reply) sid should work.


Regards,


Rene

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Rene Engelhard]

Hi,

Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:

For now, we traced the issue back to libreoffice-kf5.  If this package
is removed, neither the document disappears on closing libreoffice nor
the popup is shown when 'nobrl' is removed from the mount options.


Which doesn't do IO itself though? But maybe the KDE file picker (over 
kio) does something weird? But saving (ttbomk) isn't done by the file 
picker itself?



There also is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935182 
since some time.



It looks a bit like the issue found in [2].


Which doesn't touch any KDE stuff either. In fact it caused 32bit builds 
to fail[1] and I don't know what more regressions this caused. I would 
be wary of "just" backporting it in a point release...



Regards,

Rene

[1] by relying on internal glibc/kernel types, see 
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/libreoffice_24.2.2_rc1-2/patches/fix-32bit-build.diff?ref_type=tags 
-


 later updated upstream for 
https://cgit.freedesktop.org/libreoffice/core/commit/sal/osl/unx/file.cxx?id=434065478d35fe8e144aec916ac06438c0150270

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Rene Engelhard]

close 1069835 4:24.2.2-1

forwarded 1069835 https://bugs.documentfoundation.org/show_bug.cgi?id=55004

tag 1069835 + moreinfo

thanks


Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:

Package: libreoffice-kf5


Version?



Severity: grave


Come on... Not downgrading just yet, but I don't believe it's grave.


we run Debian bookworm KDE plasma clients with home directories
mounted from an SMB share.  From time to time, users reported that

Ah, bookworm. You should have mentioned it in Version:

libreoffice documents have disappeared completely when closing
libreoffice.  We were now able to reproduce the issue on both,
the current bookworm and bookworm-backports version of libreoffice.

Mount an SMB share. I use the following in fstab:
   //SHARE/DIR /media/share cifs user,nobrl,user=USER,password=PASS 0 0

Open/create an ODT document, write some text, save the file and check
it's appearance on the share.  Then click Insert → Image and (perhaps
with the image still selected in the document) close libreoffice.
The file disappears on the share.  This is almost always reproducible
(we tested multiple SMB servers) if not, just open the file again,
insert another image, Ctrl-S, Ctrl-Q, the file is gone!

If 'nobrl' is removed from the mount options (but we need it for other
programs to work properly), instead of the file disappearing, a popup
shows:

   Error saving the document Untitled 1:
   Error creating object.
   Could not create backup copy.

This looks like already reported upstream [1].

For now, we traced the issue back to libreoffice-kf5.  If this package
is removed, neither the document disappears on closing libreoffice nor
the popup is shown when 'nobrl'
It looks a bit like the issue found in [2].


So fixed in sid?

(If I only could update the bookworm backport to 24.2.2+, but given it's 
sstill stuck behind time_t...)



Regards,


Rene

Bug#1068609: (no subject)

[Rene Engelhard]

fixed 1068609 4:24.2.2-2
notfixed 1068609 4:24.2.2-3
thanks

4:24.2.2-2 has it fixed of course, not 4:24.2.2-3:

libreoffice (4:24.2.2-2) unstable; urgency=medium

  * debian/patches/split-sdbc-firebird-mariadb.diff: create extra
{mysqlc,firebird_sdbc}.xcd as for evoab. Otherwise configuration
parts of it ends up (or not in indep builds) in libreoffice-commons
main.xcd
  * debian/rules:
- install new {mysqlc,firebird_sdbc}.xcd into the respective
  packages
- build-depend on liborcus-dev (>> 0.19.2-3+b1) as for libxmlsec1-dev
  * debian/libreoffice-sdbc-{mysql,firebird}.ucf: add
  * debian/control.in: add Breaks: -sdbc-{mysql,firebird} (<< 4:24.2.2-2)
to libreoffice-common

 -- Rene Engelhard   Sat, 30 Mar 2024 09:30:30 +

even though -2 was never attempted on armhf due to that build-dep (-3 
was built then)

Bug#1068609: failure log for reference

[Rene Engelhard]

Hi,

for the sake of this bug (since it misses the mail history) this is the 
FTBFS:


Test name: testContentGnumeric::TestBody
assertion failed
- Expression: 
xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument")


Failures !!!
Run: 64   Failure total: 1   Failures: 1   Errors: 0

4:24.2.2-1 build failed with an orcus not rebult for time_t and after 
that it succeeded (-3 forced an appropriate build-dep)


4:24.2.0-1 from testing now fails in that way after the orcus bin-NMU 
(0.19.2-3+b2) migrated.


Regards,

Rene

Bug#1068609: libreoffice: FTBFS on arrmhf: testContentGnumeric assertion failed,- Expression: xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument")

[Rene Engelhard]

Source: libreoffice

Version: 4:24.2.0-1

Severity: serious

Tags: trixie ftbfs


Hi,

Am 30.03.24 um 12:56 schrieb Rene Engelhard:

Am 30.03.24 um 08:49 schrieb Rene Engelhard:
That would mean a bin-NMU of liborcus would work and then a rebuild 
of libreoffice (gb, but I need a new upload anyway)


So we probably missed a rename? (Or more for stuff silently using 
time-date?)


boost1.83 (iostream)? liborcus? Both?


I prepared a time_t rename of liborcus. Can upload it (to NEW...) any 
time.
A bin-NMU would also work, except for a needed runtime dependency, 
then again it's "only" the gnumeric filter...). I wouldn't mind a 
simple bin-NMU at least.


That one got done on April 1 :)

> Ran the full tests with it. Passed.

(Unfortunately) that (expectedly) now causes the reverse issue in 
testing. Just verified in a local build.


Fortunately the startup of LO works fine (tried on my machine here) so 
it's probably "just" gnumeric (and maybe other gnumeric-using filters) 
affected.



Filing a bug for reference. This is fixed in 4:24.2.2-3, will mark it as 
such when I get the bug number.



Regards,

Rene

Bug#1068479: cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)

[Rene Engelhard]

Hi,

Am 07.04.24 um 20:59 schrieb José Luis González:

Am 06.04.24 um 00:34 schrieb José Luis González:

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.

?

  It's definitely there. Format -> Paragraph has spacing "after/before".

I meant spacing between paragraphs, not spacing after and before
paragraphs. The report was crystal clear.

No, it wasn't.

The difference, for those who didn't realize is space after paragraph
happens always, and between only between them, being the regular
separation between paragraphs (the other is formatting, and isn't
useful as a substitute because it adds something undesirable at the end
of the document or between paragraphs and other kinds of block
elements).


Aha.


Still not RC.


You could have replied to my mails, though.


As said here and proved by screenshots in en,de and es this is present.

Why should anybody provide a screenshot of a feature that is missing?
What would be the screenshot of? Vacuum?


Read again, I didn't ask for screenshots.



Closing this non-bug.

The non-bug that should be closed is your brain pretending a RC bug
doesn't exist, especially since you fully knew it was a bug, and you
closed it just because it bothers you having a RC one in the package.
If you don't want to maintain the package leave the position for other
who does, and stop ruining Debian's Quality and bothering me.


Even if there was a bug it's not RC.


From: José Luis González 
To: sub...@bugs.debian.org
Subject: libreoffice-writer: space between paragraphs missing in spacing and 
indentation
Date: Sat, 6 Apr 2024 00:34:12 +0200
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)

Package: libreoffice-writer
Version: 4:7.4.7-1+deb12u1
Severity: serious

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.

Serious severity because the bug has a major effect on the usability of
the package, without rendering it completely unusable, considering
paragraphs are a key feature in a word processor, and spacing is
something very very basic for them and incredibly necessary.


And again: That is the definition of important at most, not serious.


Read the bug severities.


Regards,


Rene

Bug#1068595: libreoffice-writer: insert space missing

[Rene Engelhard]

tag 1068595 + moreinfo

thanks


Am 07.04.24 um 20:02 schrieb José Luis González:

Space insertion is missing in the insert menu.


Huh? What?


Normal space is "Space".

Non breaking space is Insert -> Formatting Mark -> Non breaking space if 
you want to use the menu. One can argue that it's not visible enough but 
that's by no means important.



Or what space do you  mean?


What are you aiming at with your non-bugs?


Regards,


Rene

Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation

[Rene Engelhard]

Hi,

Am 06.04.24 um 11:43 schrieb Rene Engelhard:

Am 06.04.24 um 11:31 schrieb Rene Engelhard:

Am 06.04.24 um 11:11 schrieb Rene Engelhard:

See https://people.debian.org/~rene/libreoffice/1068479-works.png


Just for avoidance of doubt since the screenshot is in German:

[...]

And the first part is the indentation: ("Einzug"):
- Before
- After
- First Line


Sorry, ignore that one, you were just aiming at the spacing before/after 
the paragraph, not the indentation (not enough coffee yet).


Still, as shown before the spacing before/after the paragraph is there.

Regards,

Rene

Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation

[Rene Engelhard]

Hi again,

Am 06.04.24 um 11:11 schrieb Rene Engelhard:

Am 06.04.24 um 11:03 schrieb Rene Engelhard:

Am 06.04.24 um 00:34 schrieb José Luis González:

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.


?

It's definitely there. Format -> Paragraph has spacing "after/before".

See here (yes, from stable):


Got lost.

See https://people.debian.org/~rene/libreoffice/1068479-works.png


Just tried in es_ES.UTF-8 (since that is what your other report used) 
and C (english) and also there:


https://people.debian.org/~rene/libreoffice/1068479-works-es.png
https://people.debian.org/~rene/libreoffice/1068479-works-en.png

So not reproducible in either spanish or english locale either.

Regards,

Rene

Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation

[Rene Engelhard]

Hi,

Am 06.04.24 um 11:31 schrieb Rene Engelhard:

Am 06.04.24 um 11:11 schrieb Rene Engelhard:

See https://people.debian.org/~rene/libreoffice/1068479-works.png


Just for avoidance of doubt since the screenshot is in German:

That is the second part "Absatz".
First is "above", second is "below" (the paragraph)


And the first part is the indentation: ("Einzug"):
- Before
- After
- First Line

Regards,

Rene

Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation

[Rene Engelhard]

Hi,

Am 06.04.24 um 11:03 schrieb Rene Engelhard:

Am 06.04.24 um 00:34 schrieb José Luis González:

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.


?

It's definitely there. Format -> Paragraph has spacing "after/before".

See here (yes, from stable):


Got lost.

See https://people.debian.org/~rene/libreoffice/1068479-works.png

Regards,

Rene

Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation

[Rene Engelhard]

Hi again,

Am 06.04.24 um 11:11 schrieb Rene Engelhard:

Am 06.04.24 um 11:03 schrieb Rene Engelhard:

Am 06.04.24 um 00:34 schrieb José Luis González:

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.


?

It's definitely there. Format -> Paragraph has spacing "after/before".

See here (yes, from stable):


Got lost.

See https://people.debian.org/~rene/libreoffice/1068479-works.png


Just for avoidance of doubt since the screenshot is in German:

That is the second part "Absatz".
First is "above", second is "below" (the paragraph)

Regards,

Rene

Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation

[Rene Engelhard]

tag 1068479 + moreinfo

tag 1068479 + unreproducible

severity 1068479 important

thanks


Hi,


Am 06.04.24 um 00:34 schrieb José Luis González:

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.


?

It's definitely there. Format -> Paragraph has spacing "after/before".

See here (yes, from stable):


Serious severity because the bug has a major effect on the usability of
the package, without rendering it completely unusable, considering
paragraphs are a key feature in a word processor, and spacing is
something very very basic for them and incredibly necessary.


Don't overfinflate severities. That is the definition of important

"5 important   a bug which has a major effect on the usability of a 
package, without rendering it completely unusable to everyone.
6 serious is a severe violation of Debian policy (that is, the 
problem is a violation of a 'must' or 'required' directive); may or may 
not affect the
  usability of the package. Note that non-severe policy 
violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package 
maintainers may
  also designate other bugs as 'serious' and thus 
release-critical; however, end users should not do so.). For the 
canonical list of issues
  deserving a serious severity you can refer to this 
webpage: https://release.debian.org/testing/rc_policy.txt .


"

This matches 5, not 6.


And it's unreproducible.


Regards,


Rene

Bug#1036805: Processed: Severity for 1036805 was serious and we even released with it

[Rene Engelhard]

severity 1036805 important

thanks


Hi,

> Serious severity because it has a major effect on the usability of the
> package without rendering it completely unusable, not minor

No, it's not.

"serious" has it's own meaning though and that's not it.

At most it's important but I don't buy this since as I said back then it 
looked fine here.


And you didn't even reply to the mail. Ignoring the moreinfo tag.


Ii's also not the fine style to not CC the actual bug so  the text gets 
actually sent there.



Regards,


Rene

Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4

[Rene Engelhard]

Hi,


Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977857


Regards,


Rene

Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4

[Rene Engelhard]

reassign 1068023 libreoffice-gtk4

thanks


Hi,

Am 29.03.24 um 21:04 schrieb Rene Engelhard:


Package: libreoffice


if it happens only with gtk4, isn't it better suited at libreoffice-gtk4?



I use other gtk applications (e.g. evince, audacity, inkscape, firefox)
in this same environment with no problems.

But those are gtk3, not gtk4. No idea whether using gtk4 makes a 
difference here.



Regards,


Rene

Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4

[Rene Engelhard]

Package: libreoffice
Version: 4:24.2.0-1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I have qtwayland5 5.15.10-2+b1 installed.  I do not have XWayland
installed at all.  I'm running from within a Wayland session, using sway
1.9-1 as a compositor.

When i try to launch libreoffice using the gtk4 VCLPLUGIN, i get a
complaint that it doesn't want to launch because there is no X11 error:


```
0 dkg@alice:~$ SAL_USE_VCLPLUGIN=gtk4 libreoffice
Failed to open display
/usr/lib/libreoffice/program/soffice.bin X11 error: Can't open display: 
  Set DISPLAY environment variable, use -display option

   or check permissions of your X-Server
   (See "man X" resp. "man xhost" for details)
0 dkg@alice:~$ ```

In this case, no libreoffice session starts up.

On the other hand, i get some warnings when using the qt5 plugin, but it
actually starts up with no problem:

```
0 dkg@alice:~$ SAL_USE_VCLPLUGIN=qt5 libreoffice
Failed to open display
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
0 dkg@alice:~$ ```

I use other gtk applications (e.g. evince, audacity, inkscape, firefox)
in this same environment with no problems.

--dkg


-- Package-specific info:
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----=
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
ii  libreoffice-qt5  4:24.2.0-1   amd64office productivity suite -- Qt 
5 integration

Java (javaldx):
/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64

Java:
http://openoffice.org/2004/java/framework/1.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>

file:///usr/lib/jvm/java-17-openjdk-amd64


Configuration filePackage Exists Changed
/etc/libreoffice/registry/writer.xcd  libreoffice-writer  Yes No
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----=
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
ii  libreoffice-qt5  4:24.2.0-1   amd64office productivity suite -- Qt 
5 integration

Java (javaldx):
/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64

Java:
http://openoffice.org/2004/java/framework/1.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>

file:///usr/lib/jvm/java-17-openjdk-amd64


Configuration filePackage Exists Changed
/etc/libreoffice/registry/calc.xcdlibreoffice-calcYes No
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----=
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
ii  libreoffice-qt5  4:24.2.0-1   amd64office productivity suite -- Qt 
5 integration

Java (javaldx):
/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64

Java:
http://openoffice.org/2004/java/framework/1.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>

file:///usr/lib/jvm/java-17-openjdk-amd64


Configuration filePackage Exists Changed
/etc/libreoffice/registry/base.xcdlibreoffice-base   

Bug#1065893: libreoffice: Please drop dependencies on python3-distutils

[Rene Engelhard]

Hi again,

Am 10.03.24 um 19:59 schrieb Rene Engelhard:
BTW, What is the replacement for it? setuptools._distutils? As in the 
following patch?


OK, so discussion on IRC gave:

19:51 < tumbleweed> _rene_: distutils is removed in 3.12
19:51 < tumbleweed> if you need distutils, try installing setuptools, it 
provides a distutils shim

20:00 < _rene_> setuptools._distutils, yes
20:00 < _rene_> but yet import distutils works in 3.12 :)
20:00 < _rene_> and afaicr from debconf in kochi we didn't want to force 
distutils removal yet for python3.12-as-default, only after it?
20:03 < _rene_> tumbleweed: does https://www.rene-engelhard.de/~rene/d 
look sane?
20:04 < tumbleweed> _rene_: yes, it works because setuptools provide a 
shim to make it work
20:04 < _rene_> 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065893#19)
20:04 -zwiebelbot:#debian-release- Debian#1065893: libreoffice: Please 
drop dependencies on python3-distutils - https://bugs.debian.org/1065893
20:05 < tumbleweed> just build-depend on python3-setuptools and you 
don't need the rest of your patch

20:05 < _rene_> I see, ok
20:05 < tumbleweed> obviously upstream should stop using distutils, but 
you've got time there
20:06 < tumbleweed> the answer isn't to use setuptools._distutils, but 
rather sysconfig

20:06 < _rene_> should have been in the bugreport
20:07 < tumbleweed> fwiw, the bof notes say: 
https://salsa.debian.org/debconf-team/public/data/dc23/-/blob/main/etherpad/txt/27-python-bof.txt#L20

20:10 < _rene_> hmm, indeed. but dh-python already does that.
20:10 < tumbleweed> the problem for you was more than just a dependency
20:10 < _rene_> so if it provided a shim to make plain import distutils 
work one could just make it Provides: python3-disturils

20:10 < _rene_> distutils
20:11 < _rene_> aka make the real package virtual and stuff continues to 
work

20:11 < tumbleweed> err, what am I saying
20:11 < tumbleweed> did you try just dropping the dependency on 
python3-distutils?
20:11 < _rene_> I can't remove it from the disk due to everything 
python'ish being removed, too with it
20:12 < _rene_> The following packages will be REMOVED: dh-python 
python3-dev python3-distutils python3-setuptools

20:12 -!- andibmu [~a...@i5387a7d5.versanet.de] has joined #debian-release
20:12 < tumbleweed> I mean from your build-depends so you don't get in 
your build chroot
20:13 < _rene_> how does that help if I still need dh-python and 
python3-dev? (and gobject-introspection)

20:13 < tumbleweed> they don't need distutils. Nothing does in 3.12
20:13 < _rene_> just now doing it in a chroot where I can do stuff and 
do a manual debuild -Pnogir
20:13 < _rene_> why does dh-python and python3-dev then get removed on 
apt remove python3-distutils?

20:14 < _rene_> (and the gobject-introspection stuff.)
20:15 < tumbleweed> oh, right, dh-python does still depend on it
20:15 < tumbleweed> fine. As long as you drop *your* dependency, we 
should be OK when everyone else drops theirs

20:15 < _rene_> and apt -t experimental install python3-dev also does
20:15 < _rene_> The following NEW packages will be installed: 
python3-dev python3-distutils

20:16 < tumbleweed> that's OK

so just exchanging the build-dep would be fine. You could have just said 
so in the report for people who are not that into python stuff.


Will be fixed in next experimental upload.

Regards,

Rene

Bug#1065893: libreoffice: Please drop dependencies on python3-distutils

[Rene Engelhard]

Hi,

Am 10.03.24 um 19:44 schrieb Rene Engelhard:


and similar stuff in upstreams configure.
    python_include=`$PYTHON -c "import distutils.sysconfig; 
print(distutils.sysconfig.get_config_var('INCLUDEPY'));"`
    python_version=`$PYTHON -c "import distutils.sysconfig; 
print(distutils.sysconfig.get_config_var('VERSION'));"`
    python_libs=`$PYTHON -c "import distutils.sysconfig; 
print(distutils.sysconfig.get_config_var('LIBS'));"`
    python_libdir=`$PYTHON -c "import distutils.sysconfig; 
print(distutils.sysconfig.get_config_var('LIBDIR'));"`


to be precise.


BTW, What is the replacement for it? setuptools._distutils? As in the 
following patch?


diff --git a/changelog b/changelog
index 968af9a3b..9d16707d6 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,10 @@
+libreoffice (4:24.2.2~rc1-3) UNRELEASED; urgency=medium
+
+  * debian/patches/distutils-is-obsolete.diff, debian/rules: use
+    setuptools._distutils instead of distutils (closes: #1065893)
+
+ -- Rene Engelhard   Sun, 10 Mar 2024 19:57:14 +0100
+
 libreoffice (4:24.2.2~rc1-2) experimental; urgency=medium

   * debian/patches/fix-32bit-build.diff: as name says; from upstream
diff --git a/patches/series b/patches/series
index 75a4f68d2..47b80676f 100644
--- a/patches/series
+++ b/patches/series
@@ -50,3 +50,4 @@ fix-system-abseil-build.diff
 fix-riscv64-bridge.diff
 pdfium-ports.diff
 fix-32bit-build.diff
+distutils-is-obsolete.diff
diff --git a/rules b/rules
index aa981c5b1..a47940395 100755
--- a/rules
+++ b/rules
@@ -1086,7 +1086,7 @@ ifeq "$(ENABLE_PYTHON)" "y"
 PYMAJOR:=$(shell $(PYTHON) -c "import sys; print (sys.version_info[0])")
 PYMINOR:=$(shell $(PYTHON) -c "import sys; print (sys.version_info[1])")
 PYMINORPLUS1:=$(shell $(PYTHON) -c "import sys; print 
(sys.version_info[1]+1)")
-PYTHON_SITE:=debian/python3-uno/$(shell $(PYTHON) -c 'from distutils 
import sysconfig; print(sysconfig.get_python_lib())')
+PYTHON_SITE:=$(shell $(PYTHON) -c 'from setuptools._distutils import 
sysconfig; print(sysconfig.get_python_lib())')

 endif

 BUILD_DEPS += , $(PYTHON)
@@ -2953,9 +2953,9 @@ else
 endif

 ifeq "$(PACKAGE_BASE)" "y"
-    mkdir -p debian/python3-access2base/$(shell $(PYTHON) -c 'from 
distutils import sysconfig; print(sysconfig.get_python_lib())')

+    mkdir -p debian/python3-access2base/$(PYTHON_SITE) }
 mv $(PKGDIR)-common/$(OODIR)/program/access2base.py \
-        debian/python3-access2base/$(shell $(PYTHON) -c 'from distutils 
import sysconfig; print(sysconfig.get_python_lib())')

+        debian/python3-access2base/$(PYTHON_SITE)
 else
 rm -rf $(PKGDIR)-common/$(OODIR)/share/basic/Access2Base
 t=`mktemp -q`; grep -v Access2Base 
$(PKGDIR)-common/$(OODIR)/share/basic/dialog.xlc > \

@@ -2966,9 +2966,9 @@ else
 endif

 # ScriptForge
-    mkdir -p debian/python3-scriptforge/$(shell $(PYTHON) -c 'from 
distutils import sysconfig; print(sysconfig.get_python_lib())')

+    mkdir -p debian/python3-scriptforge/$(PYTHON_SITE) \
 mv $(PKGDIR)-common/$(OODIR)/program/scriptforge.py \
-        debian/python3-scriptforge/$(shell $(PYTHON) -c 'from distutils 
import sysconfig; print(sysconfig.get_python_lib())')

+        debian/python3-scriptforge/$(PYTHON_SITE)

 ifeq "$(PACKAGE_SDK)" "y"
 # move gengal stuff into -dev-gui
@@ -3354,16 +3354,16 @@ endif

 ifeq "$(ENABLE_PYTHON)" "y"
 # PyUNO packaging
-    install -d $(PYTHON_SITE)
+    install -d debian/python3-uno/$(PYTHON_SITE)
 # prepend stuff so that it works when the module is not in LOs
 # directories but in $(PYTHON_SITE). Can't be a patch (anymore)
 # as otherwise the python-based unittests fail miserably.
-    echo "import sys, os" > $(PYTHON_SITE)/uno.py
-    echo "sys.path.append('/$(OODIR)/program')" >> $(PYTHON_SITE)/uno.py
-    echo "os.putenv('URE_BOOTSTRAP', 
'vnd.sun.star.pathname:/$(OODIR)/program/fundamentalrc')" >> 
$(PYTHON_SITE)/uno.py

-    cat debian/python3-uno/$(OODIR)/program/uno.py >> $(PYTHON_SITE)/uno.py
+    echo "import sys, os" > debian/python3-uno/$(PYTHON_SITE)/uno.py
+    echo "sys.path.append('/$(OODIR)/program')" >> 
debian/python3-uno/$(PYTHON_SITE)/uno.py
+    echo "os.putenv('URE_BOOTSTRAP', 
'vnd.sun.star.pathname:/$(OODIR)/program/fundamentalrc')" >> 
debian/python3-uno/$(PYTHON_SITE)/uno.py
+    cat debian/python3-uno/$(OODIR)/program/uno.py >> 
debian/python3-uno/$(PYTHON_SITE)/uno.py

 rm -f debian/python3-uno/$(OODIR)/program/uno.py
-    mv debian/python3-uno/$(OODIR)/program/unohelper.py $(PYTHON_SITE)
+    mv debian/python3-uno/$(OODIR)/program/unohelper.py 
debian/python3-uno/$(PYTHON_SITE)

 touch debian/python3-uno/$(OODIR)/program/pythonloader.unorc
 chmod u+w debian/python3-uno/$(OODIR)/program/pythonloader.u

Bug#1065893: libreoffice: Please drop dependencies on python3-distutils

[Rene Engelhard]

tag 1065893 - ftbfs

tag 1065893 + moreinfo

thanks


Hi,

Am 10.03.24 um 18:49 schrieb Graham Inggs:

Severity: important
Tags: ftbfs
Nope. As demonstrated below it does NOT FTBFS if I ran it to the end. 
Actually did once.

This package has dependencies, build-dependencies and/or autopkgtest
dependencies on python3-distutils.  The python3-distutils binary
package will soon be dropped from python3-stdlib-extensions.

# apt remove python3-distutils
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  gir1.2-girepository-2.0 gir1.2-girepository-2.0-dev 
libgirepository-1.0-1 libjs-jquery libjs-sphinxdoc libjs-underscore 
libpython3-dev libpython3.11-dev
  python3-lib2to3 python3-mako python3-markdown python3-markupsafe 
python3-pkg-resources python3.11-dev

Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  dh-python gobject-introspection gobject-introspection-bin 
libgirepository-1.0-dev libgirepository1.0-dev python3-dev 
python3-distutils python3-setuptools

0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.
After this operation, 5736 kB disk space will be freed.
Do you want to continue? [Y/n]


and dh-python gobject-introspection libgirepository1.0-dev python3-dev 
are definitely needed as build -dependencies-



In fact, there is no module for Python 3.12 in python3-distutils, so
these dependencies may already be unnecessary.


Wrong. both debian/rules and LibreOffices configure use distutils to 
figure out the module install directory path for example.


e.g. PYTHON_SITE:=debian/python3-uno/$(shell $(PYTHON) -c 'from 
distutils import sysconfig; print(sysconfig.get_python_lib())')


and similar stuff in upstreams configure.


And that one is not done on 3.12 yet since LibreOffice (for reasons!) 
only builds for default python. Which is 3.11.



After install python3 python3-dev from experimental (so 3.12):

$ python3
Python 3.12.2 (main, Feb 25 2024, 17:51:42) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils;
>>> from distutils import sysconfig; print(sysconfig.get_python_lib())
/usr/lib/python3/dist-packages
>>> print(distutils)
(/usr/lib/python3/dist-packages/setuptools/_distutils/__init__.py)>

>>>

and doing a libreoffice build with debuild -Pnogir (since we need 
gobject-introspection etc. which isn't yet built for default 3.12 either):


$ debuild -Pnogir

[...]

checking for a Python interpreter with version >= 3.3... python3
checking for python3... /usr/bin/python3
checking for python3 version... 3.12
checking for python3 platform... linux
checking for GNU default python3 prefix... ${prefix}
checking for GNU default python3 exec_prefix... ${exec_prefix}
checking for python3 script directory (pythondir)... 
${PYTHON_PREFIX}/lib/python3.12/site-packages
checking for python3 extension module directory (pyexecdir)... 
${PYTHON_EXEC_PREFIX}/lib/python3.12/site-packages


[...]

in upstreams configure.


I think this bugreport is too early.


Regards,


Rene

Bug#1065461: libreoffice-common: disabling libreoffice-evolution has moved evolocal.odb to libreoffice-common

[Rene Engelhard]

Hi,

Am 05.03.24 um 00:47 schrieb Andreas Beckmann:

   Preparing to unpack .../libreoffice-common_4%3a24.2.1-3_all.deb ...
   Unpacking libreoffice-common (4:24.2.1-3) over (4:24.2.0-1) ...
   dpkg: error processing archive 
/var/cache/apt/archives/libreoffice-common_4%3a24.2.1-3_all.deb (--unpack):
trying to overwrite '/usr/lib/libreoffice/presets/database/evolocal.odb', 
which is also in package libreoffice-evolution 4:24.2.0-1
   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
   rmdir: failed to remove '/var/lib/libreoffice/share/prereg/': No such file 
or directory
   rmdir: failed to remove '/var/lib/libreoffice/share/': No such file or 
directory
   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
directory
   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
   Errors were encountered while processing:
/var/cache/apt/archives/libreoffice-common_4%3a24.2.1-3_all.deb

I'm not sure whether Breaks+Replaces are the correct solution here, or
whether -common should rather not ship the file regardless of (not)
building -evolution ...


The latter, imho.

ifeq "$(ENABLE_EVO2)" "y"
    mkdir -p $(PKGDIR)-evolution/$(OODIR)/presets/database
    mkdir -p $(PKGDIR)-evolution/$(OODIR)/share/registry
    mv $(PKGDIR)-common/$(OODIR)/presets/database/evolocal.odb \
    $(PKGDIR)-evolution/$(OODIR)/presets/database
else
    rm -f $(PKGDIR)-common/$(OODIR)/presets/database/evolocal.odb
endif

Added the else part just now.


If you add B+R now, you will also need to add them in the opposite
direction once -evolutions gets reenabled.


libphonenumber is fixed now, so I can re-enable it now and not have it 
blocking builds.



But I need to do the Replaces: libreoffice-common in -evolution anyways now?


Regards,


Rene

Bug#1065448: libreoffice-common: soffice builds of pdf files are unreproducible

[Rene Engelhard]

forwarded 1065448 https://bugs.documentfoundation.org/show_bug.cgi?id=160033

thanks


Hi,

Am 04.03.24 um 21:58 schrieb Rene Engelhard:


Package: libreoffice-common
Version: 4:24.2.0-1
Severity: normal
Tags: upstream


Then you should have filed it upstream :). Didn't write the reportbug 
text for no reason :)



Did now: https://bugs.documentfoundation.org/show_bug.cgi?id=160033

When creating pdf files from odt files, soffice writes a CreationDate 
field

which contains the actual build date/time. This varies with every build.
For an example, see the bottom of
https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/winff.html 



soffice could use the creation date of the input odt file,
or even SOURCE_DATE_EPOCH instead of the current system date.

I think there wven was an option to actually not export this at all (or 
I misremember) but it's probably not exposed to --convert-to etc. unless 
extra configuration.



Anyway, forwarded.


Regards,


Rene

Bug#1065448: libreoffice-common: soffice builds of pdf files are unreproducible

[Rene Engelhard]

Package: libreoffice-common
Version: 4:24.2.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: pe...@pblackman.plus.com

Dear Maintainer,

When creating pdf files from odt files, soffice writes a CreationDate field
which contains the actual build date/time. This varies with every build.
For an example, see the bottom of
https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/winff.html

soffice could use the creation date of the input odt file,
or even SOURCE_DATE_EPOCH instead of the current system date.

Regards,
Peter


-- Package-specific info:
Configuration file    Package Exists Changed
/etc/libreoffice/registry/Langpack-en-US.xcd  libreoffice-common Yes No
/etc/libreoffice/registry/lingucomponent.xcd  libreoffice-common Yes No
/etc/libreoffice/registry/main.xcd    libreoffice-common Yes No
/etc/libreoffice/registry/pdfimport.xcd   libreoffice-common Yes No
/etc/libreoffice/registry/res/fcfg_langpack_e libreoffice-common Yes No
/etc/libreoffice/registry/xsltfilter.xcd  libreoffice-common Yes No

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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-common depends on:
ii  libnumbertext-data   1.0.11-4
ii  libreoffice-style-colibre    4:24.2.0-1
ii  libreoffice-uiconfig-common  4:24.2.0-1
ii  ucf  3.0043+nmu1
ii  ure  4:24.2.0-1

Versions of packages libreoffice-common recommends:
ii  apparmor    3.0.12-1+b2
ii  fonts-liberation    1:2.1.5-3
ii  libexttextcat-data  3.4.7-1
ii  poppler-data    0.4.12-1
ii  python3-uno 4:24.2.0-1
ii  xdg-utils   1.1.3-4.1

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-colibre [libreoffice-style]  4:24.2.0-1
pn  python3-scriptforge    

-- no debconf information

Bug#1064776: bogusly redirects Bugs to debian-openoffice@lists.debian.org instead of the BTS

[Rene Engelhard]

Source: libreoffice

Version: 4:24.2.0-1

Severity: serious

Control: close -1 4:24.2.0-3


Am 23.02.24 um 17:14 schrieb Rene Engelhard:

Hi,

Am 23.02.24 um 08:02 schrieb HIGUCHI Daisuke (VDR dai):

Sorry, resending to BTS, not to debian-openoffice.


No problem, that -1 redirects the bug reports to debian-openoffice is 
a bug.


(Fixed in later versions but those are stuck after the t64 transition.)


Making a (RC) bug out of this.


Regards,


Rene

Bug#1064494: libreoffice-calc: forcing "Wrap text automatically" when moving cells

[Rene Engelhard]

Hi,

Am 23.02.24 um 08:02 schrieb HIGUCHI Daisuke (VDR dai):

Sorry, resending to BTS, not to debian-openoffice.


No problem, that -1 redirects the bug reports to debian-openoffice is a bug.

(Fixed in later versions but those are stuck after the t64 transition.)


Regards,


Rene

Bug#1020482: libreoffice-dictionaries: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Rene Engelhard]

tag 1020482 + pending
thanks

Am 24.01.24 um 23:44 schrieb Soren Stoutner:

Control: tags -1 + patch


I submitted an MR at:


https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-dictionaries/-/merge_requests/6
 




Merged (and uploaded after fixing the changelog)

Regards,

Rene

Bug#1061242: libreoffice-impress: impress cannot start. Its display an error loading a dll that is installed

[Rene Engelhard]

Hi,

oops.

Am 21.01.24 um 15:35 schrieb Rene Engelhard:
Here the new libxml2 removes functions and symbol versions used by 
gazillions of packages over the whole of the Debian archive.


And no, the exact point of Debian library package names is that they 
HAVE to change on ABI changes. Especially on a library like this which 
is used by virtually anything.


See https://www.debian.org/doc/debian-policy/ch-sharedlibs.h


https://www.debian.org/doc/debian-policy/ch-sharedlibs.html , obviously :)

Regards,

Rene

Bug#1061242: libreoffice-impress: impress cannot start. Its display an error loading a dll that is installed

[Rene Engelhard]

Hi,

Am 21.01.24 um 15:27 schrieb Eric Valette:

On 21/01/2024 14:49, Rene Engelhard wrote:

Exactly that is the point of #1059040. The binary packages have to be 
renamed. (Then rebuild against libxml2-WHATEVERNEW). Then a rebuild 
LO will have a proper dependency on libxml2-WHATEVERNEW.


I agree that package with different APIs should bump their major .so 
version, but not obviously change their name. At least, that has not 
always been like that (more than 20 years...).



API != ABI. (New) API is different.

Here the new libxml2 removes functions and symbol versions used by 
gazillions of packages over the whole of the Debian archive.


And no, the exact point of Debian library package names is that they 
HAVE to change on ABI changes. Especially on a library like this which 
is used by virtually anything.


See https://www.debian.org/doc/debian-policy/ch-sharedlibs.h


No. The bug is in libxml2.

I disagree on this. Many ddl did not change their name when they have 
API breakage only bump major so that symbolic links does not get 
resolved.


Again API != ABI.


That is a bug in libxml2 regardless. See the discussion there, 
especially the comment about "partial updates", which this is.



libxml2 has to restore ABI compatibility or rename the package. (I would 
also argue as you if it was some minor thing or stuff removed noone 
really uses but that is not the case here, as said in the libxml2 bug it 
breaks stuff at runtime all over the place)



Regards,


Rene

Bug#1061242: libreoffice-impress: impress cannot start. Its display an error loading a dll that is installed

[Rene Engelhard]

Hi,

Am 21.01.24 um 14:44 schrieb Eric Valette:



ii  libxml2 2.12.3+dfsg-0exp1


And this one *from experimental* changed ABI (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059040). Don't 
install it on systems you don't want breakage in.


Bingo you got it. However this means that dependencies are wrong 
somewhere. As soon as it enter unstable, the problem will be there if 
dependencies/rebuild are not managed correctly


Exactly that is the point of #1059040. The binary packages have to be 
renamed. (Then rebuild against libxml2-WHATEVERNEW). Then a rebuild LO 
will have a proper dependency on libxml2-WHATEVERNEW.


The libxml2 package as of now must not install unstable at current state.

Indeed the current package name of libxml2 is a problem and fullfills 
unstables depends, but see below.



It is expected that stuff built with 2.9.x doesn't necessarily work 
with 2.12. And here libsdlo.so *does* link against libxml:


Missing dependency < dependency at least.

Yeah.  But for that you need a palantir. For an unknown amount of 
packages in the archive?


No. The bug is in libxml2.


Regards,


Rene

Bug#1020482: libreoffice-dictionaries: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Rene Engelhard]

Am Sat, Oct 14, 2023 at 11:50:25AM -0700 schrieb Soren Stoutner:
> Would you be interested in a patch to implement this functionality?

You can do that, for sure.

(Actually during debconf last year I did a quick and dirty solution to
this - excluding the special-case-needed ones, but dropped the ball on
it. Can resurrect it, though)

Regards,

Rene

Bug#1060255: Instead of certain text, squares are displayed in the interface

[Rene Engelhard]

tag 1060255 + unreproducible

tag 1060255 + moreinfo

thanks


Hi,

Am 08.01.24 um 11:32 schrieb Артём:

Package: libreoffice-l10n-ru
Version: 4:7.4.7-1+deb12u1
Severity: |important|
|Tags: ||l10n|
|
|
For example, in LibreOffice Start Center, some text in the options

Which "text in the options"? You mean the buttons?

does not display correctly.


Works fine here, (assuming LANG=ru_RU.UTF-8. You omitted all of the 
helpful information reportbug would give.)



FWIW, I just looked, for cyrillic languages I don't see "default fonts" 
defined.  Neither in the configs inside libreoffice-l10n-ru:


$ grep -i font /etc/libreoffice/registry/Langpack-ru.xcd 
/etc/libreoffice/registry/res/fcfg_langpack_ru.xcd 
/etc/libreoffice/registry/res/registry_ru.xcd
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name="private:resource/toolbar/fontworkobjectbar">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name="private:resource/toolbar/fontworkshapetype">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name="private:resource/toolbar/fontworkobjectbar">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name="private:resource/toolbar/fontworkshapetype">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name="ooo-emphasis-font">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name="ooo-emphasis-font-color">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name="ooo-emphasis-font-size">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name="ooo-emphasis-font-style">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkGalleryFloater">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkSameLetterHeights">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkAlignmentFloater">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkCharacterSpacingFloater">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-plain-text">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-wave">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-inflate">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-stop">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-curve-up">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-curve-down">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-triangle-up">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-triangle-down">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-fade-right">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-fade-left">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-fade-up">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-fade-down">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-slant-up">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-slant-down">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-fade-up-and-right">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-fade-up-and-left">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-chevron-up">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-chevron-down">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-arch-up-curve">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-arch-down-curve">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-arch-left-curve">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-arch-right-curve">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-circle-curve">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-open-circle-curve">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-arch-up-pour">
/etc/libreoffice/registry/res/registry_ru.xcd:    oor:name=".uno:FontworkShapeType.fontwork-arch-down-pour">
/etc/libreoffice/registry/res/registry_ru.xcd:    

Bug#974220: libreoffice-writer: Double paste in Writer

[Rene Engelhard]

forwarded 974220 https://bugs.documentfoundation.org/show_bug.cgi?id=140652

tag 974220 + upstream

thanks


Am 05.01.24 um 15:01 schrieb Claudio Ferreira:

Yes. I have this software. Is common in the Brazilian market.

I tried now to past a text and it works as expected. For me, this bug 
can be closed.


Thanks for confirming. Let's keep it open and mark it as forwarded to 
the bug James mentioned.



Regards,


Rene

Bug#1059158: libreoffice-core-nogui: Can't open a spreadsheet from python uno because libforuilo.so is missing.

[Rene Engelhard]

retitle 1059158 libreoffice-core-nogui: Can't open a spreadsheet from 
python uno on 32bits because libforuilo.so is missing.


thanks


Hi,

Am 20.12.23 um 18:42 schrieb Gerard Henri Pille:

* What exactly did you do (or not do) that was effective (or
  ineffective)?


So this is even 32bit specific since on 64bit libforuilo.so is subsumed 
by libvmergedlo.so. (Which cannot be done on 32bit since libmergedlo.so 
is probably too big for 32bit to actually link it). Using arm64 (yes, 
even on rpi) would have rules this exact bug out ;)



But given libforuilo.so is inside libmergedlo.so in 64bit archs anyway 
we can just include it here since as said i's included in 64bits 
packages nevertheless.



Already in git (you got the mails).

No idea when this actually will end up in stable, though :)


Regards,


Rene

Bug#1052740: graphite2: FTBFS: graph_legend.dot:1: error: Problems running dot: exit code=1, command='dot', arguments='"/<>/build/doc/doxygen/html/graph_legend.dot" -Tpng -o "/<

[Rene Engelhard]

Hi,

Am 23.12.23 um 11:43 schrieb Rene Engelhard:

Hi,
Am 23.12.23 um 02:40 schrieb Bastian Germann:

graph_legend.dot should have quotes around the font name references.

Ah, thanks. Unfortunately this is a generated file...


And yes, I also noticed that the FreeSans.ttf is at fault. Indeed I 
actually played around with it but that didn't give anything.



Thinking abit it this value set already is default anyway, so we can 
just remove it and it still works (and passes the problem), now running 
into the (unrelated) LaTeX issue.



Regards,


Rene

Bug#1052740: graphite2: FTBFS: graph_legend.dot:1: error: Problems running dot: exit code=1, command='dot', arguments='"/<>/build/doc/doxygen/html/graph_legend.dot" -Tpng -o "/<

[Rene Engelhard]

Hi,
Am 23.12.23 um 02:40 schrieb Bastian Germann:

graph_legend.dot should have quotes around the font name references.

Ah, thanks. Unfortunately this is a generated file...

This is probably a doxygen bug.
Probably. That's why there's no action here. TBH I don't think this is 
the only occurance archive-wise?

A workaround would be removing doxygen from Build-Depends
and the two doxgen output files from debian/libgraphite2-doc.docs


Thought abozt  this, too. But that would loose the API documentation


Regards,


Rene

Bug#1059158: libreoffice-core-nogui: Can't open a spreadsheet from python uno because libforuilo.so is missing.

[Rene Engelhard]

[ please keep the bug in CC to record discussions like this ]


Hi,

Am 20.12.23 um 21:08 schrieb Gerard H. Pille:
I chose core-nogui since I found the missing lib in libreoffice-core.  
I found no info on libforuilo. 

Internal LO component-
User Interface for LibreOffice? 

Yes.

And the "for"?


formula.

> Perhaps not too many people are using python uno for libreoffice on a 
headless system?


That too, but IMHO in this case it's just a blatant bug upstream that 
someting which doesn't need a GUI on a --disable-gui build actually 
needs GUI libraries.


(In upstreams --disable-gui build they'd still be there, we explicitely 
remove them, because otherwise we get all those libs and that makes the 
difference size-wise GUI/nogui not really big..)



Regards,


Rene

Bug#1059158: libreoffice-core-nogui: Can't open a spreadsheet from python uno because libforuilo.so is missing.

[Rene Engelhard]

forwarded 1059158 https://bugs.documentfoundation.org/show_bug.cgi?id=158795

thanks


Hi,

Am 20.12.23 um 18:42 schrieb Gerard Henri Pille:


Package: libreoffice-core-nogui


So -calc-nogui. Since with only -core-nogui nothing seriously should open at 
all anyway :)


 Version: 4:7.4.7-1


You definitely shouldn't use that one but properly maintain that system and 
install the security update which is there since 1.5 weeks.


* What led up to the situation?
tried to open an existing spreadsheet using python uno
* What exactly did you do (or not do) that was effective (or
  ineffective)?
after adding libforuilo.so found in the libreoffice-core, to 
/usr/lib/libreoffice/program, opening an existing spreadsheet succeeded
* What was the outcome of this action?
no document was opened, no feedback
* What outcome did you expect instead?
that it was possible to open an existing or new spreadsheet using 
loadComponentFromURL


Sigh. All that stuff needing *ui stuff where they actually don't need ui 
files because it's built with --disable-gui. That is the third one like 
this.


See also http://bugs.debian.org/1058653


Regards,


Rene

Bug#1058653: libreoffice-writer-nogui: fails to convert ODT to PDF "Error: source file could not be loaded"

[Rene Engelhard]

Hi,

Am 14.12.23 um 07:57 schrieb Rene Engelhard:

Hi,

Am 14.12.23 um 06:01 schrieb tony mancill:

A FTBFS bug [1] cropped up in gpredict recently that appears to be to a
change in libreoffice-writer-nogui.  The build step that fails is:

$ soffice --strace --writer --headless --convert-to pdf gpredict-user-manual.odt
Warning: failed to launch javaldx - java may not function correctly
Error: source file could not be loaded

strace output shows a failed attempt to find libcuilo.so (shipped with
libreoffice-core) just before "Error: source file could not be loaded"
is output.  Should libcuilo.so be included in libreoffice-core-nogui?


No it should not because it is *common UI*.


That LibreOffice upstream adds options and then let it bit-rot to the 
point that that they don't work as intended without adding totally 
unrelated stuff unfortunately is a fact. :(


Here it is adding a dependency on UI stuff for something not needing UI.


Quickly filed https://bugs.documentfoundation.org/show_bug.cgi?id=158695 now

Regards,

Rene

Bug#1058653: libreoffice-writer-nogui: fails to convert ODT to PDF "Error: source file could not be loaded"

[Rene Engelhard]

Hi,

Am 14.12.23 um 06:01 schrieb tony mancill:

A FTBFS bug [1] cropped up in gpredict recently that appears to be to a
change in libreoffice-writer-nogui.  The build step that fails is:

$ soffice --strace --writer --headless --convert-to pdf gpredict-user-manual.odt
Warning: failed to launch javaldx - java may not function correctly
Error: source file could not be loaded

strace output shows a failed attempt to find libcuilo.so (shipped with
libreoffice-core) just before "Error: source file could not be loaded"
is output.  Should libcuilo.so be included in libreoffice-core-nogui?


No it should not because it is *common UI*.


That LibreOffice upstream adds options and then let it bit-rot to the 
point that that they don't work as intended without adding totally 
unrelated stuff unfortunately is a fact. :(


Here it is adding a dependency on UI stuff for something not needing UI.

In the meanwhile  I actually reget having added -nogui for this reason.



For the time-being, we are working around this by using
libreoffice-writer as the build-dep,

That is wrong imho.

but the -nogui package should be
sufficient and has worked in the past.


Yeah. Or just adding libreoffice-core (since you *can* mix them.) See also

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


Regards,


Rene

Bug#1057434: libreoffice-numbertext 1.0.11-3 is broken; 1.0.10-1 works as expected

[Rene Engelhard]

retitle 1057434 libreoffice-numbertext: NUMBERTEXT() gives Err: 504
thanks

Am 05.12.23 um 18:56 schrieb Rene Engelhard:

When trying to use the =NUMBERTEXT(5) formula in Libreoffice Calc, you get an
'Err: 504' error in those cells.

Confirmed..


Cause is

$ debdiff libreoffice-numbertext_1.0.11-1_all.deb 
libreoffice-numbertext_1.0.11-3_all.deb

[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in first .deb but not in second
-
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_Roman.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_Suzhou.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_af.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_bg.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_ca.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_cs.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_da.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_de.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_el.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_en.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_eo.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_es.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_et.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_fa.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_fi.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_fr.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_ga.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_gl.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_he.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_hr.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_hu.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_hu_Hung.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_id.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_is.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_it.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_ja.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_ko.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_lb.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_lg.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_lt.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_lv.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_mr.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_ms.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_mt.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_mul.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_nl.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_no.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_pl.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_pt.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_ro.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_ru.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_sh.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_sl.py
-rw-r--r--  root/root 
/usr/lib/libreoffice/share/extensions/numbertext/pythonpath/numbertext_sq.py
-rw-r--r--  root/root 
/usr/lib/libreoffice

Bug#1057434: libreoffice-numbertext 1.0.11-3 is broken; 1.0.10-1 works as expected

[Rene Engelhard]

tag 1057434 + confirmed

retitle 1057434 libreoffice-numbertext 1.0.11-3 is broken; NUMBERTEXT(5) 
gives Err: 504


thanks

Hi,

Am 05.12.23 um 02:27 schrieb Alexandre Bonneau:

Package: libreoffice-numbertext
Version: 1.0.11-3
Severity: grave

When trying to use the =NUMBERTEXT(5) formula in Libreoffice Calc, you get an
'Err: 504' error in those cells.

Confirmed..

When reverting back to libreoffice-numbertext 1.0.10-1, all the functions using
the NUMBERTEXT function are correctly parsed.


Why are you reverting back to something which isn't anywhere except on 
snapshots because eben stable contains 1.0.11-1?


(Which does work, just tested).


Regards,


Rene

Bug#1057178: FTBFS: unsatisfiable build-deps in testing on mdds and liborcus

[Rene Engelhard]

Source: libreoffice
Version: 4:7.5.9~rc1-1
Severity: serious
Tags: wontfix trixie

Hi,

apparently mdds 2.1/liborcus 0.19 migrated to testing even though
Build-Depends clearly say

   libmdds-dev (<< 2.1~),
   libmdds-dev (>= 2.0),

and

   liborcus-dev (<< 0.18~),
   liborcus-dev (>= 0.17.2),

and testings LO depending on liborcus-0.17.0. The latter is probably due
to the smooth transitions, but the former now causes this to be
unbuildable.

Filing for documentation purposes. Obviously fixed in sid, thankfully 
4:7.5.9~rc1-1
is the end of a branch.

Regards,

Rene

Bug#1056104: libreoffice: please enable ENABLE_WASM_STRIP_PINGUSER

[Rene Engelhard]

tag 1056104 + wonffix
thanks

Hi,

Am 17.11.23 um 18:30 schrieb Rene Engelhard:

So it would boil down to

rene@frodo:~/LibreOffice/git/master/debian$ git diff rules
diff --git a/rules b/rules
index e7152c60..ed7a8157 100755
--- a/rules
+++ b/rules
@@ -2247,6 +2247,7 @@ config_host.mk:
     MARIADBCONFIG=$(MARIADBCONFIG) \
     FIREBIRD_CFLAGS=$(FIREBIRD_CFLAGS) 
FIREBIRD_LIBS=$(FIREBIRD_LIBS) \

     ./autogen.sh $(CONFIGURE_FLAGS)
+   sed -i "s/ENABLE_WASM_STRIP_PINGUSER 
0/ENABLE_WASM_STRIP_PINGUSER 1/" config_host/config_wasm_strip.h


  build:
     $(CURDIR)/debian/rules build-arch
@@ -2270,6 +2271,7 @@ ifeq "$(BUILD_NOGUI_PACKAGES)" "y"
     --without-doxygen --without-javadoc \
     --with-galleries=no --with-theme="$(DEFAULT_IMAGE)" \
     --disable-gui --disable-introspection --disable-qt5 
--disable-kf5
+   sed -i "s/ENABLE_WASM_STRIP_PINGUSER 
0/ENABLE_WASM_STRIP_PINGUSER 1/" config_host/config_wasm_strip.h


     PATH=$(BUILD_PATH) LD_LIBRARY_PATH=$(BUILD_LD_LIBRARY_PATH) 
ARCH_FLAGS=$(ARCH_FLAGS) TMP=`mktemp -q -d` $(MAKE) build-non-l10n-only


That is actually not enough, one also needs to add a similar line for 
config_host.mk to be more complete and disable the affected lib.


sed -i 
"s/ENABLE_WASM_STRIP_PINGUSER=$$/ENABLE_WASM_STRIP_PINGUSER=TRUE/" 
config_host.mk


But AFAICS both of this also affects the "Tip of the day", so I am even 
more relucatant to actually set this..


Regards,

Rene




I am not sure this is worthwile.


  Thanks for considering.


Not for oldstable ;-)


Regards,


Rene

Bug#1056104: libreoffice: please enable ENABLE_WASM_STRIP_PINGUSER

[Rene Engelhard]

severity 1056104 wishlist

thanks

Am 16.11.23 um 23:52 schrieb Cyril Brulebois:

LibreOffice features a prompt that pops up every now and then, asking
users to get involved or to donate. I'm not sure asking repeatedly is
reasonable,


Not sure.

We need people who care about portability. upstream definitely does not.

(And the Debian "porters" don't either, at least they are missing in any 
action. OK, they are probably not in LibreOffices userbase and thus 
don't see it, but others might..)



and it seems like ENABLE_WASM_STRIP_PINGUSER would be
appropriate to turn that off.


Which would need to be hacked in since it's only flagged by 
--enable-wasm-strip which as the name says is for WebAssembly 
(cross-)compile and thus can't be done generically (and strips out a 
sh*load of stuff)...


So it would boil down to

rene@frodo:~/LibreOffice/git/master/debian$ git diff rules
diff --git a/rules b/rules
index e7152c60..ed7a8157 100755
--- a/rules
+++ b/rules
@@ -2247,6 +2247,7 @@ config_host.mk:
    MARIADBCONFIG=$(MARIADBCONFIG) \
    FIREBIRD_CFLAGS=$(FIREBIRD_CFLAGS) FIREBIRD_LIBS=$(FIREBIRD_LIBS) \
    ./autogen.sh $(CONFIGURE_FLAGS)
+   sed -i "s/ENABLE_WASM_STRIP_PINGUSER 
0/ENABLE_WASM_STRIP_PINGUSER 1/" config_host/config_wasm_strip.h


 build:
    $(CURDIR)/debian/rules build-arch
@@ -2270,6 +2271,7 @@ ifeq "$(BUILD_NOGUI_PACKAGES)" "y"
    --without-doxygen --without-javadoc \
    --with-galleries=no --with-theme="$(DEFAULT_IMAGE)" \
    --disable-gui --disable-introspection --disable-qt5 
--disable-kf5
+   sed -i "s/ENABLE_WASM_STRIP_PINGUSER 
0/ENABLE_WASM_STRIP_PINGUSER 1/" config_host/config_wasm_strip.h


    PATH=$(BUILD_PATH) LD_LIBRARY_PATH=$(BUILD_LD_LIBRARY_PATH) 
ARCH_FLAGS=$(ARCH_FLAGS) TMP=`mktemp -q -d` $(MAKE) build-non-l10n-only



I am not sure this is worthwile.

  
  Thanks for considering.


Not for oldstable ;-)


Regards,


Rene

Bug#1056074: libreoffice: FTBFS: boost1.83 transition

[Rene Engelhard]

Hi,

Am 16.11.23 um 21:14 schrieb Rene Engelhard:

-


Failed to install: No such file or directory at 
/<>/solenv/bin/ooinstall line 102.

-


No, totally unrelated. (And I wonder how you got into this at all.)


And besides that, if it was that that it already built everything and is 
at install stage. So probably nothing boost-releated anyways.


if ($ENV{BUILD_TYPE} =~ m/ODK/) {
print "Running SDK installer\n";
system ("cd $ENV{SRC_ROOT}/instsetoo_native/util ; " .
"perl -w $ENV{SRCDIR}/solenv/bin/make_installer.pl " .
"-f $ENV{BUILDDIR}/instsetoo_native/util/openoffice.lst -l 
en-US -p LibreOffice_SDK " .

"-u $tmp_dir " .
"-buildid $BUILD $destdir $strip $msi " .
"-simple $path") && die "Failed to install: $!";
}

so it looks like the tree was incomplete or otherwise else an expected 
file/directory is not there? Still not boost-related :)


I am 100% sure this will be unreproducible in any case when I tried it.

Regards,

Rene

Bug#1056074: libreoffice: FTBFS: boost1.83 transition

[Rene Engelhard]

tag 1056074 + moreinfo

tag 1056074 + unreproducible

thanks


Hi,

Am 16.11.23 um 20:46 schrieb gl...@debian.org:

Source: libreoffice
Version: 4:7.5.8-1
Severity: normal
User:gl...@debian.org
Usertags: boost183 ftbfs-boost183-transition

Hi,

we are preparing the transition of all libs on the new boost 1.83. During the
rebuild of packages against this library it was identified that probably your
package fails to build.

"probably"?

As the newer version is already available in Debian as we tested, we can not
be sure whether it is still relevant. But anyway.

Then be before filing bugs.

Relevant part (hopefully):

-


Failed to install: No such file or directory at 
/<>/solenv/bin/ooinstall line 102.

-


No, totally unrelated. (And I wonder how you got into this at all.)


Also note that 
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-7-5=7e61545966c61102aad56bbf10bae2edfbfa9226 
*is* in 7.5.8 so boost 1.81 should work.


boost 1.82 needed no actual code changes upstream 
(https://cgit.freedesktop.org/libreoffice/core/commit/?id=8daa8eef06fa485f5271503921585a3fbef26567).


No one tried boost 1.83 yet afaik.



To reproduce this behavior, you can install  -dev Boost packages from the
experimental repository, as shown in the following command:

   apt install libboost-dev -t experimental


The full build log is available from:
http://qa-logs.debian.net/2023/10/27/libreoffice_7.5.8~rc1-2_unstable_boost181.log


404


If you are unable to reproduce this, please provide a build log and diff it
so that we can identify any relevant changes that may have occurred in the 
meantime.


That routinely will be useless since my paths in the build log will 
probably not match yours. And I am not doing sbuild which does 
<>.



Regards,


Rene

Bug#1054376: liborcus: FTBFS on hppa - segmentation fault in orcus-test-xml-mapped

[Rene Engelhard]

Hi,

Am 01.11.23 um 16:37 schrieb John David Anglin:

The attached change fixes orcus_test_xml_mapped test on hppa hardware:
https://buildd.debian.org/status/fetch.php?pkg=liborcus=hppa=0.17.2-4=1698851675=0


Erm? Please don't tell me you apply stuff on packages extra to what's in 
the archive proper and reuse the same version number?


That's a recipe for deasaster and confusion.


Anyways, it's fixed upstream so will be in 0.19.2 whenever it will be 
released. (0.17.x in sid is dead and only will get updates for 
transitions or release-critical stuff, which is one definitely is not)


Regards,


Rene

Bug#1055048: libreoffice-writer: [table] Can’t create overlapping lines

[Rene Engelhard]

tag 1055048 + moreinfo
Thanks

 Am 30. Oktober 2023 09:12:05 MEZ schrieb Nicolas Patrois 
:
>Package: libreoffice-writer
>Version: 4:7.5.8~rc1-2
>Severity: normal
>Tags: upstream
>
>Dear Maintainer,
>
>I have problems when I try to create overlapping lines in tables.
(...)

Since 7.5.8 is almost end of life upstream (final will be this week and it is 
the last 7.5.x release...).

What about 7.6.2? (Available in experimental)

Regards

René

Bug#1054376: liborcus: FTBFS on hppa - segmentation fault in orcus-test-xml-mapped

[Rene Engelhard]

Hi,

Am 23.10.23 um 00:10 schrieb John David Anglin:

The build fails on real hppa hardware (i.e., not qemu):
[...]
Exactly the same binary runs successfully under qemu.

Maybe there is a timing issue in the orcus::file_content::~file_content
destructor?


That is something for you as hppa porter (or upstream) to answer.


Regards,


Rene

Bug#1054239: libixion FTBFS with gcc 13 on i386

[Rene Engelhard]

Hi,

Am 19.10.23 um 19:08 schrieb Adrian Bunk:

Source: libixion
Version: 0.17.0-3

0.17.0-3

Severity: serious
Tags: ftbfs trixie sid patch

https://buildd.debian.org/status/fetch.php?pkg=libixion=i386=0.19.0-1=1697292545=0


So not 0.17.0.

Or does it also happen on sid? Yes, it does.. Mentioning this could have 
been helpful otherwise I assumed just an error in Version:



...
FAIL: document-test
===

test_basic_calc: --begin
document-test: document_test.cpp:50: void test_basic_calc(): Assertion 
`doc.get_numeric_value(A1) == 1.1' failed.
FAIL document-test (exit status: 134)

FAIL: general-test
==

test_size: --begin
test size
* int: 4
* long: 4
* double: 8
* size_t: 4
* string_id_t: 4 (min:0; max:4294967295)
* celltype_t: 1
* formula_cell: 4
* formula_tokens_t: 12
test_size: --end (duration: 0 sec)
test_string_to_double: --begin
test_string_to_double: --end (duration: 0 sec)
test_string_pool: --begin
string count: 4
* 0: 'Table1' (0x57251a98)
* 1: 'Table2' (0x57251ab0)
* 2: 'Category' (0x57251ac8)
* 3: 'Value' (0x57251ae0)
string map count: 4
* key: 'Value' (0x57251ae0; 5), value: 3
* key: 'Category' (0x57251ac8; 8), value: 2
* key: 'Table2' (0x57251ab0; 6), value: 1
* key: 'Table1' (0x57251a98; 6), value: 0
test_string_pool: --end (duration: 0 sec)
test_formula_tokens_store: --begin
test_formula_tokens_store: --end (duration: 0 sec)
test_matrix: --begin
test_matrix: --end (duration: 0 sec)
test_matrix_non_numeric_values: --begin
general-test: general_test.cpp:166: void 
{anonymous}::test_matrix_non_numeric_values(): Assertion `mtx.get_numeric(0, 0) 
== 1.1' failed.
FAIL general-test (exit status: 134)


Testsuite summary for libixion 0.19.0

# TOTAL: 6
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

See src/libixion/test-suite.log

make[6]: *** [Makefile:1101: test-suite.log] Error 1

Yeah, saw this in the experimental upload.



There are two ways to fix this:


--- debian/rules.old2023-10-19 17:03:33.109096000 +
+++ debian/rules2023-10-19 17:03:52.569079353 +
@@ -5,6 +5,8 @@
  
  include /usr/share/dpkg/architecture.mk
  
+export DEB_CXXFLAGS_MAINT_APPEND += -fexcess-precision=fast

+
  %:
dh $@
  


Will do that one, thanks.


Regards,


Rene

Bug#1053670: libreoffice-gtk3: Color changes in Libreoffice Draw stopped working with libreoffice-gtk3 installed

[Rene Engelhard]

tag 1053670 + unreproducible

tag 1053670 + moreinfo

thanks


Hi,

Am 08.10.23 um 15:08 schrieb Kerstin Hoef-Emden:

Probably an update of libreoffice and its components.


Probably?

The last update of "libreoffice and its components" was for 12.1 in July.


If it appeared recently I'd guess some library update... Maybe in 12.2?



  I wanted to prepare a
single picture for a presentation with Libreoffice Draw and realized that
changes of text color stopped working.

Works here. Both in my normal system and in a clean stable VM.

Also filled areas of e.g. circles did
not show the chosen color. Instead all fillings appeared white, colored text
remained black.


Dito.



Also I realized that input
becomes extremely slow, with libreoffice-gtk3 installed. The fan of my cpu
speeds up and letters appear with a long delay while typing in.
That suggests some graphics driver issue? Did something get updated with 
that?

* What exactly did you do (or not do) that was effective (or
  ineffective)?

I purged libreoffice with "apt purge libreoffice*" from the system and
reinstalled it. Thereafter the problem was gone, but the windows and menus had
tiny hardly readable text and low contrast due to a gray background.


Well, yes, that's how LO looks without Gtk3 integration.


Regards,


Rene

Bug#1051968: libreoffice: Libreoffice on MATE doesn't install libreoffice-gnome

[Rene Engelhard]

severity 1051968 wishlist

reassign 1051968 tasksel

retitle 1051968 please make task-mate-desktop install libreoffice-gnome

thanks


Hi,

Am 15.09.23 um 04:33 schrieb Charles Boling:

Package: libreoffice
Severity: normal
Tags: patch

Dear Maintainer,

(Sorry if wrong pkg; had trouble finding dependency
Also, yes, I used the term "patch" very loosely.)

Yes, there is no patch here anyway. :)

Problem:
Fresh debian installation includes LibreOffice, but when installed in the MATE
environment, it installs the libreoffice-gtk package but does NOT install
the libreoffice-gnome package.


You mean you have chosen "MATE Desktop Environment" in the installer in 
the "task selection" (a.k.a tasksel)?




How I noticed:
LO was unable to open e.g. "sftp://; files.
If opened from LO, it was as if you hit ESC instead of ENTER on open dialog
-- nothing happened.
If opened from file browser (Caja), it launched LO which then immediately 
exited.

How I fixed:
Manually installed libreoffice-gnome


See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933271. One 
can always install libreoffice-gnome, too.



The "libreoffice" package suggests libreoffice-gnome | 
libreoffice-plasma but indeed  the MATE task just does



Package: task-mate-desktop
Source: tasksel
Version: 3.73
Installed-Size: 9
Maintainer: Debian Install System Team 
Architecture: all
Depends: tasksel (= 3.73), task-desktop, mate-desktop-environment, lightdm
Recommends: gimp, synaptic, libreoffice-writer, libreoffice-calc, 
libreoffice-impress, libreoffice-help-en-us, mythes-en-us, 
hunspell-en-us, hyphen-en-us, network-manager-gnome, orca, libreoffice-gtk3

Description-en: MATE
 This task package is used to install the Debian desktop, featuring
 the MATE desktop environment, and with other packages that Debian users
 expect to have available on the desktop.
Description-md5: 11325f7ae02031b05c57d0b5e0d607c0
Section: tasks
Priority: optional
Filename: pool/main/t/tasksel/task-mate-desktop_3.73_all.deb
Size: 1200
MD5sum: 97a791eba1c4446482466b6a218490f0
SHA256: 90db4b36c0ef18f8fad2cc878173efb78f1e3fee36bb33b7bda3abd69ce65380


But that (understandably, leaving out Base etc) bypasses the 
"libreoffice" metapackage (except that that suggests is not shown when 
being installed by the installer anyway...)



Maybe we definitely should add it in task-mate-desktop... I prepared a 
merge request for tasksel...



I don't know where to go to tweak this in the distro, but I suspect you do!


That would be tasksel.


Regards,


Rene

Bug#1051474: libreoffice: Please add embeded code copies to embeded-code-copies on security tracker debian.tar.xz/tarballs

[Rene Engelhard]

severity 1051474 important

thanks

Hi,

Am 08.09.23 um 19:19 schrieb Bastien Roucariès:

Source: libreoffice
Severity: serious
Tags: security
Justification: Document embdeded code copy + copyright
X-Debbugs-Cc: Debian Security Team 


Since when is that serious? It isn't. There have been no complains from 
anyone in the security team in any of the last security updates?


(None of which affected any of the internal copies used,)

The policy says "should". And it it it followed.

The most stuff isn't used as internal code copies, only the unavoidable 
ones is. And TTBOMK the security team DOES know it.


> Could you document that you embded a few tar ball under the security 
tracker ?


You mean I should send MRs to it?

>Moreover you do not document where you downloaded these file a comment 
under

copyright will be helpful (README.source say how to retrieve it not the link to
get).


The fetch it manually and put it there.  (Which normally would be done 
from upstreams build systeem for ALL tarballs, even those not used..)


(It basically always is https://dev-www.libreoffice.org/src/ (which 
mirrors stuff they got from the website):


Makefile:        $(call 
fetch_Download_item_unchecked,https://download.documentfoundation.org/libreoffice/src/$(shell 
echo $(gb_LO_VER) | sed -e 
"s/\([0-9]*\.[0-9]*\.[0-9]*\).*/\1/"),libreoffice-$(i)-$(gb_LO_VER).tar.xz))



Regards,


Rene

Bug#1045940: libixion: Fails to build source after successful build

[Rene Engelhard]

fixed 1045940 0.18.1-1
thanks

Am 14.08.23 um 20:09 schrieb Rene Engelhard:

Am 14.08.23 um 18:05 schrieb Rene Engelhard:

make[1]: Leaving directory '/<>'

    dh_autoreconf_clean
    dh_clean
rm: cannot remove './doc/_doxygen': Is a directory
rm: cannot remove './doc/tmp': Is a directory
dh_clean: error: rm -f -- debian/libixion-dev.substvars 
debian/libixion-0.17-0.substvars debian/python3-ixion.substvars 
debian/libixion-doc.substvars ./doc/_doxygen ./doc/tmp debian/files 
returned exit code 1

make: *** [debian/rules:9: clean] Error 25
dpkg-buildpackage: error: debian/rules clean subprocess returned 
exit status 2


E: Command 'cd /<> && runuser -u user42 -- 
dpkg-buildpackage --sanitize-env -us -uc -rfakeroot -S' failed to run.


So dh_clean fails. I'd buy your argument if it was before/after 
dh_cllean or something is left-over but this is quite obviously not a 
bug here.


OK, I got teached that removing dirs need / and apparently did it since 
ever. Then I still wonder why it wasn't caught in the "ftbfs when built 
two times in a row" builds in the last years


Interesting this doesn't appear in experimentals libixion even though 
that neither having the /...


Regards,

Rene

Bug#1045940: libixion: Fails to build source after successful build

[Rene Engelhard]

reassign 1045940 debhelper

affects 1045940 src:libixion

severity 1045940 normal

thanls


Hi,


Am 13.08.23 um 21:20 schrieb Lucas Nussbaum:

Source: libixion


No.

> This is probably a clear violation of Debian Policy section 4.9 
(clean target),

but this is filed as severity:minor for now, because a discussion on
debian-devel showed that we might want to revisit the requirement of a working
'clean' target.


And this is clearly not a fault here.

make[1]: Leaving directory '/<>'

dh_autoreconf_clean
dh_clean
rm: cannot remove './doc/_doxygen': Is a directory
rm: cannot remove './doc/tmp': Is a directory
dh_clean: error: rm -f -- debian/libixion-dev.substvars 
debian/libixion-0.17-0.substvars debian/python3-ixion.substvars 
debian/libixion-doc.substvars ./doc/_doxygen ./doc/tmp debian/files returned 
exit code 1
make: *** [debian/rules:9: clean] Error 25
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2

E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage 
--sanitize-env -us -uc -rfakeroot -S' failed to run.


So dh_clean fails. I'd buy your argument if it was before/after 
dh_cllean or something is left-over but this is quite obviously not a 
bug here.



Regards,


Rene

Bug#1042994: libreoffice-draw experimental: LibreOffice Draw (and LO Impress) do not start

[Rene Engelhard]

tag 1042994 + unreproducible

tag 1042994 + moreinfo

thanks


Hi,

Am 04.08.23 um 01:22 schrieb Thomas Florek:
Launching LO Draw (and also LO Impress) did not work, either from the 
plasma desktop or from the console.


Works fine here. (Clean sid VM with experimentals LO)


Even tried extra in KDE (X11 and wayland).


I see you have non-Debian packages installed. try with a clean Debian?


Regards,


Rene

Bug#1041837: closed by René Engelhard (Re: Bug#1041837: libreoffice-draw: undeclared file conflict with libreoffice-impress-nogui <= trixie: /usr/lib/libreoffice/share/config/

[Rene Engelhard]

Control: found -1 4:7.5.4~rc1-1

Control: fixed -1 4:7.6.0~rc1-1


Am 24.07.23 um 19:27 schrieb Helmut Grohne:

Control: reopen -1
Control: found -1 4:7.5.5-2
Control: found -1 4:7.5.5~rc1-2

On Mon, Jul 24, 2023 at 08:09:07AM +, Debian Bug Tracking System wrote:

08:26 < helmut> _rene_: re libreoffice (short on time atm): seems like I messed 
something up, please close my report. (...)

Further context here. On IRC you also said that this was fixed in
experimental. 20:51  * _rene_ lost hope


What? I didn't say anything on IRC about this.

And I said experimental (NEW). I even pointed to libreoffice-uiconfig-* 
of 7.6 (-> NEW)



Also note that experimentals version is LOWER than sids.

So obviously "fixed in experimental" does not make any sense here otherwise.


In contrast *YOU* said it could be closed. I followed.



/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/sidebarslidebackground.ui
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/layoutlist.xml
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/objectlist.xml
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/styles.xml


All of those are in -draw *and* draw-nogui (and those two conflict, so OK).

That's where they belong (well, probably not needed in -nogui but anyway.)


What looks missing indeed is some Replaces, I bumped them to go sure 
hopefully.


And as said in 7.6 it's fixed since the uiconfig-impress package should 
have the correct Replaces:



Regards,


Rene

Bug#1041837: libreoffice-draw: undeclared file conflict with libreoffice-impress-nogui <= trixie: /usr/lib/libreoffice/share/config/soffice.cfg/simpress/*.xml

[Rene Engelhard]

Hi,


Am 24.07.23 um 06:52 schrieb Helmut Grohne:


libreoffice-draw installs
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/layoutlist.xml
and
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/objectlist.xml
which are also contained in libreoffice-impress-nogui from bullseye to
trixie.


Mmh, indeed.


Already fixed in experimental (well, NEW since ~ 2 months) already though:

Package: libreoffice-uiconfig-impress
Section: misc
Architecture: all
Replaces: libreoffice-common (<< 4:7.6.0~beta1),
  libreoffice-draw (<< 4:7.6.0~rc1),
  libreoffice-draw-nogui (<< 4:7.6.0~rc1),
  libreoffice-impress (<< 4:7.6.0~rc1),
  libreoffice-impress-nogui (<< 4:7.6.0~rc1)


Leaves "just" sid.


Regards,


Rene

Bug#1019862: invisible mouse pointer: still an issue in bookworm 12.1

[Rene Engelhard]

Hi,

Am 22.07.23 um 16:17 schrieb Andreas B. Mundt:

Hi Rene, all,

first, many thanks for maintaining libreoffice!  We are running the
KDE plasma desktop environment in our school and observe probably the
same issue here:


Sure? The description in the original bug doesn't talk about mouse cursors?

Theer's that wayland message, indeed, but..


   Especially in libreoffice draw, when selecting for
example the 'lines and arrows'-tool, the mouse pointer usually becomes
a cross and a line on the drawing area.  However, it becomes invisible
in KDE/Plasma on wayland.  I found the following related upstream bug
reports with patches already, but unfortunatelly they are not applied
to the libreoffice 7.4 series or to qt6-wayland (cc Debian Qt/KDE
Maintainers):

   https://bugs.documentfoundation.org/show_bug.cgi?id=15
   
https://git.libreoffice.org/core/+/091f56e50748e3fd807b9bae88652b68834aac3a%5E%21
So fixed in 7.5.2 then... I could upload a backport if 7.5 even migrated 
to testing

The related qt6 report is here:

   https://bugreports.qt.io/browse/QTBUG-95434
   
https://codereview.qt-project.org/c/qt/qtwayland/+/461361/3/src/client/qwaylandcursor.cpp


But that is Qt6, but Qt5. The kf5 plugin uses Qt5 "of course".


You say "or to qt6-wayland".

If at all - for KDE -, this needs to be fixed in Qt5 (in whatever 
package is equivalent to said qt6-wayland) additonally tp qt6-wayland.



Regards,


Rene

Bug#1041546: marked as done (libreoffice: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException')

[Rene Engelhard]

Hi,

Am 20.07.23 um 19:06 schrieb Debian Bug Tracking System:

Your message dated Thu, 20 Jul 2023 20:04:13 +0300
with message-id 

and subject line solved
has caused the Debian Bug report #1041546,
regarding libreoffice: terminate called after throwing an instance of 
'com::sun::star::container::NoSuchElementException'
to be marked as done.


You write:

"I am rarely using it and never touching config or anything. It just
upgraded automatically for a long time."


This should work... But automatically if it involves version updates 
IMHO is a bad idea in any case. One just does it for stable and 
security, maybe


"So there is simple solution:

apt-get purge libreoffice*
apt-get install libreoffice

And now it successfully starts.  Sorry."


OK. :)


Regards,


Rene

Bug#1041546: libreoffice: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException'

[Rene Engelhard]

Hi,

Am 20.07.23 um 18:42 schrieb Rene Engelhard:

To compare: You can't also break apache config or merge new config stuff

   ^ not

Regards,


Rene

Bug#1041546: libreoffice: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException'

[Rene Engelhard]

Hi,

To clarify and compare the scenario:

So wjhat did you change there and did you merge stuff added there when 
ucf prompted you do do so?

[...]
Please try with a clean config, merginConfiguration file Package Exists 
Changed g actual updates into them when you update. That is *YOUR* 
reponsibility as an admin.


In any case, "of course" a clean LO in sid starts up just fine.


To compare: You can't also break apache config or merge new config stuff 
in there and complain that apache doesn't start anymore. Or for any 
other service.


This config is in /etc because it's configuration. Like e.g. apache2.
You could change it, yes. (even though it affects stuff in the user 
config only if that user config never got created already...)
But that doesn't mean you can do anything with it, and this doesn't mean 
you  can leave out stuff there added in newer LibreOffice versions 
because as we see stuff relies on keys present.


That's why this uses ucf. It has even a three-way merge option...

Regards,


Rene

Bug#1041546: libreoffice: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException'

[Rene Engelhard]

severity 1041546 important

tag  1041546 + moreinfo

tag 1041546 + unreproducible

thanks


Hi,

Am 20.07.23 um 18:19 schrieb Vladmimir Stavrinov:

Package: libreoffice
Version: 4:7.5.5~rc2-1
Severity: grave
Justification: renders package unusable


I do not think so.



Just won't start (hang forever) while issuing the subject.


NoSuchElementException?


/etc/libreoffice/registry/writer.xcd  libreoffice-writer  YesYes


So wjhat did you change there and did you merge stuff added there when 
ucf prompted you do do so?


Probably even manually.

That config is not willy-nilly, it is also needed for proper startup.

I bet you didn't merge needed keys for startup.


Configuration filePackage Exists Changed
/etc/libreoffice/registry/calc.xcdlibreoffice-calcYesYes

Same here.

Configuration filePackage Exists Changed
/etc/libreoffice/registry/draw.xcdlibreoffice-drawYesYes
/etc/libreoffice/registry/graphicfilter.xcd   libreoffice-drawYes
Yes1041546


and here.


ii  glx-alternative-nvidia   1.2.2  
amd64allows the selection of NVIDIA as GLX provider
ii  libegl-nvidia-tesla-470-0:amd64  470.199.02-1   
amd64NVIDIA binary EGL library (Tesla 470 version)
ii  libgl1-nvidia-tesla-470-glvnd-glx:amd64  470.199.02-1   
amd64NVIDIA binary OpenGL/GLX library (GLVND variant) 
(Tesla 470 version)
ii  libgles-nvidia-tesla-470-1:amd64 470.199.02-1   
amd64NVIDIA binary OpenGL|ES 1.x library (Tesla 470 version)
ii  libgles-nvidia-tesla-470-2:amd64 470.199.02-1   
amd64NVIDIA binary OpenGL|ES 2.x library (Tesla 470 version)
ii  libglx-nvidia-tesla-470-0:amd64  470.199.02-1   
amd64NVIDIA binary GLX library (Tesla 470 version)
ii  libnvidia-egl-wayland1:amd64 1:1.1.10-1 
amd64Wayland EGL External Platform library -- shared library
ii  libnvidia-tesla-470-cfg1:amd64   470.199.02-1   
amd64NVIDIA binary OpenGL/GLX configuration library (Tesla 
470 version)
ii  libnvidia-tesla-470-cuda1:am1041546d64  470.199.02-1
   amd64NVIDIA CUDA Driver Library (Tesla 470 version)
ii  libnvidia-tesla-470-eglcore:amd64470.199.02-1   
amd64NVIDIA binary EGL core libraries (Tesla 470 version)
ii  libnvidia-tesla-470-glcore:amd64 470.199.02-1   
amd64NVIDIA binary OpenGL/GLX core libraries (Tesla 470 
version)
ii  libnvidia-tesla-470-glvkspirv:amd64  470.199.02-1   
amd64NVIDIA binary Vulkan Spir-V compiler library (Tesla 
470 version)
ii  libnvidia-tesla-470-ml1:amd64470.199.02-1   
amd64NVIDIA Management Library (NVML) runtime library 
(Tesla 470 version)
ii  libnvidia-tesla-470-ptxjitcompiler1:amd64470.199.02-1   
amd64NVIDIA PTX JIT Compiler library (Tesla 470 version)
ii  libnvidia-tesla-cfg1:amd64   525.125.06-1   
amd64NVIDIA binary OpenGL/GLX configuration library (Tesla 
version)
ii  nvidia-egl-common525.125.06-1   
amd64NVIDIA binary EGL driver - common files
ii  nvidia-installer-cleanup 20220217+3 
amd64cleanup after driver installation with the 
nvidia-installer
ii  nvidia-kernel-common 20220217+3 
amd64NVIDIA binary kernel module support files
ii  nvidia-modprobe  535.54.03-1
amd64utility to load NVIDIA kernel modules and create 
device nodes
ii  nvidia-persistenced  525.85.05-1
amd64daemon to maintain persistent software state in the 
NVIDIA driver
ii  nvidia-settings-tesla-470470.161.03-1   
amd64tool for configuring the NVIDIA graphics driver (Tesla 
470 version)
ii  nvidia-support   20220217+3 
amd64NVIDIA binary graphics driver support files
ii  nvidia-tesla-470-alternative 470.199.02-1   
amd64allows the selection of NVIDIA as GLX provider (Tesla 
470 version)
ii  nvidia-tesla-470-driver  470.199.02-1   
amd64NVIDIA metapackage 

Bug#1041490: libreoffice-common: AppArmor profile for libreoffice-oosplach needs wayland abstraction

[Rene Engelhard]

tag 1041490 + moreinfo

thanks


Hi,


Am 19.07.23 um 19:05 schrieb Jonathan Leivent:

* What led up to the situation?

Attempt to run libreoffice in a Wayland compositor desktop without XWayland 
support


What happens then?



* What exactly did you do (or not do) that was effective (or
  ineffective)?

Disabled the libreoffice AppArmor profiles


Which one?

2 profiles are in complain mode.
   libreoffice-oosplash
   libreoffice-soffice

Those who would matter during startup (as you imply below) are only in 
complain mode, not enforcing..



* What outcome did you expect instead?

Yes.


That answer doesn't fit the question :)


Regards,


Rene

Bug#1041340: RM: libreoffice [mipsel] -- ROM; broken

[Rene Engelhard]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libreoff...@packages.debian.org, debian-m...@lists.debian.org, 
Timo Jyrinki , Olly Betts , Debian UBports 
Team 
Control: affects -1 + src:libreoffice
Control: affects -1 + src:lloconv
Control: affects -1 + src:libreoffice-voikko
Control: affects -1 + src:lomiri-docviewer-app

Hi,

please remove libreoffice from mipsel.

% dak rm -ABRn libreoffice -a mipsel
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

gir1.2-lokdocview-0.1 |  4:7.4.5-3 | mipsel
liblibreofficekitgtk |  4:7.4.5-3 | mipsel
libofficebean-java |  4:7.4.5-3 | mipsel
libreoffice |  4:7.4.5-3 | mipsel
libreoffice-base |  4:7.4.5-3 | mipsel
libreoffice-base-core |  4:7.4.5-3 | mipsel
libreoffice-base-drivers |  4:7.4.5-3 | mipsel
libreoffice-calc |  4:7.4.5-3 | mipsel
libreoffice-core |  4:7.4.5-3 | mipsel
libreoffice-dev |  4:7.4.5-3 | mipsel
libreoffice-dev-gui |  4:7.4.5-3 | mipsel
libreoffice-draw |  4:7.4.5-3 | mipsel
libreoffice-evolution |  4:7.4.5-3 | mipsel
libreoffice-gnome |  4:7.4.5-3 | mipsel
libreoffice-gtk3 |  4:7.4.5-3 | mipsel
libreoffice-impress |  4:7.4.5-3 | mipsel
libreoffice-kf5 |  4:7.4.5-3 | mipsel
libreoffice-math |  4:7.4.5-3 | mipsel
libreoffice-plasma |  4:7.4.5-3 | mipsel
libreoffice-qt5 |  4:7.4.5-3 | mipsel
libreoffice-report-builder-bin |  4:7.4.5-3 | mipsel
libreoffice-sdbc-firebird |  4:7.4.5-3 | mipsel
libreoffice-sdbc-hsqldb |  4:7.4.5-3 | mipsel
libreoffice-sdbc-mysql |  4:7.4.5-3 | mipsel
libreoffice-sdbc-postgresql |  4:7.4.5-3 | mipsel
libreoffice-writer |  4:7.4.5-3 | mipsel
libreofficekit-dev |  4:7.4.5-3 | mipsel
libuno-cppu3 |  4:7.4.5-3 | mipsel
libuno-cppuhelpergcc3-3 |  4:7.4.5-3 | mipsel
libuno-purpenvhelpergcc3-3 |  4:7.4.5-3 | mipsel
libuno-sal3 |  4:7.4.5-3 | mipsel
libuno-salhelpergcc3-3 |  4:7.4.5-3 | mipsel
python3-uno |  4:7.4.5-3 | mipsel
uno-libs-private |  4:7.4.5-3 | mipsel
   ure |  4:7.4.5-3 | mipsel
  ure-java |  4:7.4.5-3 | mipsel

Maintainer: Debian LibreOffice Maintainers 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
libreoffice-voikko: libreoffice-voikko
lloconv: lloconv
meta-gnome3: gnome

# Broken Build-Depends:
daps: libreoffice-draw
gpredict: libreoffice-writer
libreoffice-voikko: libreoffice-core
lloconv: libreofficekit-dev
lomiri-docviewer-app: libreofficekit-dev
msc-generator: libreoffice
openlp: python3-uno
zemberek-ooo: libreoffice-dev

Dependency problem found.

- libreoffice-voikko, lloconv and lomiri-docviewer-app also need to be removed

% for i in libreoffice-voikko lloconv lomiri-docviewer-app; do dak rm -ABRn $i 
-a mipsel; done
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libreoffice-voikko |   5.0-4+b1 | mipsel

Maintainer: Timo Jyrinki 

--- Reason ---

--

Checking reverse dependencies...
# Broken Build-Depends:
ibus-typing-booster: libreoffice-voikko

Dependency problem found.

W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

   lloconv |6.1.1-1 | mipsel

Maintainer: Olly Betts 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

lomiri-docviewer-app | 3.0.3+dfsg-1 | mipsel

Maintainer: Debian UBports Team 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

- daps is Arch: all and thus gets built on amd64 (or on other archs, but
  surely not on mips*), so this is a false positive.
  Same for openlp and zemberek-ooo.
  Also ibus-typing-booster is in the same situation regarding libreoffice-voikko
- gpredict is #983763
- msc-generator already does a libreoffice [amd64], so not affected by
  this removal at all
- meta-gnome3 has yet to get a bug

Rationale:

mipsel is completely broken, long story at [1].
Upstream who added it (RedHat) confirmed no interest to do anything on
it.

Regards,

Rene

[1] see
https://buildd.debian.org/status/package.php?p=libreoffice=experimental:

[build MOD] testtools
S=/<> && I=$S/instdir && W=$S/workdir &&  mkdir -p $W/Module/ && 
touch $W/Module/testtools
### bool does not match! failed
### char does not match! failed
### byte does not match! failed
### short does not match! failed
### unsigned short does not match! failed
### long does not match! failed
### unsigned long does not match! failed
### hyper does not match! failed
### unsigned hyper does not match! failed
### enum does not match! failed
### byte2 does not match! failed
### short2 does not match! failed
struct comparison test 

Bug#1040982: libexttextcat: New upstream release (3.4.6, 08-Nov-2021)

[Rene Engelhard]

Hi,

Am 13.07.23 um 18:08 schrieb Florian Ernst:

there is a new upstream release available at
, adding support for
some more languages / variants.


Oops, indeed. November 2021.. Bummer...


Regards,


Rene

Bug#1039906: libreoffice: FTBFS on riscv64: uitest throws "index out of range"

[Rene Engelhard]

Hi,

Am 10.07.23 um 22:45 schrieb Rene Engelhard:

[build UIT] cui_tabpages

[...]

Tests run: 2
Tests failed: 0
Tests errors: 0
Tests skipped: 0


That said, before that a make uicheck in cui or a make uicheck toplevel 
gets:


[build ECH] CustomTarget/instsetoo_native/setup/setuprc
/bin/sh: 1: git: not found
[build ECH] CustomTarget/instsetoo_native/setup/versionrc
/bin/sh: 1: git: not found
[build LOC] top level modules: libreoffice
[build CUS] instsetoo_native/setup
[build PKG] instsetoo_native_setup
[build BIN] instsetoo_native
[build UIT] cui_dialogs
[build UIT] cui_tabpages
[build UIT] conditional_format
testSvxCharEffectsPage (chardlg.Test.testSvxCharEffectsPage) ... 
testThemePage (themepage.Test.testThemePage) ... OfficeConnection: 
connecting to: 
uno:pipe,name=pytest60b76514-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
testSvxCharEffectsPageTheme (chardlg.Test.testSvxCharEffectsPageTheme) 
... OfficeConnection: connecting to: 
uno:pipe,name=pytest61580f0a-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
testSvxCharEffectsPageWriter (chardlg.Test.testSvxCharEffectsPageWriter) 
... OfficeConnection: connecting to: 
uno:pipe,name=pytest61f5ecac-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
testSvxCharEffectsPageWriterAutomatic 
(chardlg.Test.testSvxCharEffectsPageWriterAutomatic) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytest62935cda-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
test_tdf145978 (macroselectordlg.tdf145978.test_tdf145978) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytest6330c6c8-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
testGetFormat (pastedlg.Test.testGetFormat) ... OfficeConnection: 
connecting to: 
uno:pipe,name=pytest63ce3dea-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR

==
ERROR: testSvxCharEffectsPage (chardlg.Test.testSvxCharEffectsPage)
--
Traceback (most recent call last):
  File "/home/rene/libreoffice-7.5.5~rc1/uitest/uitest/framework.py", 
line 25, in setUp

self.connection.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 175, in setUp

conn.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 56, in setUp

self.xContext = self.connect(socket)

  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 103, in connect

raise Exception("soffice has stopped.")
Exception: soffice has stopped.

==
ERROR: testSvxCharEffectsPageTheme 
(chardlg.Test.testSvxCharEffectsPageTheme)

--
Traceback (most recent call last):
  File "/home/rene/libreoffice-7.5.5~rc1/uitest/uitest/framework.py", 
line 25, in setUp

self.connection.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 175, in setUp

conn.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 56, in setUp

self.xContext = self.connect(socket)

  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 103, in connect

raise Exception("soffice has stopped.")
Exception: soffice has stopped.

==
ERROR: testSvxCharEffectsPageWriter 
(chardlg.Test.testSvxCharEffectsPageWriter)

--
Traceback (most recent call last):
  File "/home/rene/libreoffice-7.5.5~rc1/uitest/uitest/framework.py", 
line 25, in setUp

self.connection.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 175, in setUp

conn.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 56, in setUp

self.xContext = self.connect(socket)

  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 103, in connect

raise Exception("soffice has stopped.")
Exception: soffice has stopped.
[...]

so it's at least better than before (and this bug is fixed) but still it 
has problems :)


(The UITests fwiw are not ran anymore on riscv64 per default)

Regards,

Rene

Bug#1039906: libreoffice: FTBFS on riscv64: uitest throws "index out of range"

[Rene Engelhard]

Hi,

forgot one sentence.

Am 10.07.23 um 22:45 schrieb Rene Engelhard:
So I had the idea to try a export DEB_BUILD_OPTIONS="noopt" build 
(resulting into -O0) and it looks better:


So I guess I'll workaround this by building with -O0. (riscv64 isn't 
alone there, see


https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules#L746
(upto line 771)

Regards,

Rene

Bug#1039906: libreoffice: FTBFS on riscv64: uitest throws "index out of range"

[Rene Engelhard]

tag 1039906 - moreinfo

thanks


Hi,

Am 29.06.23 um 17:29 schrieb Rene Engelhard:
It seems that the exception only throws in current Debian package. If 
I build LibreOffice (both 7.6 and 7.5 version) with external tarballs 

and upstream compiler flags, see below
(that means, I pass parameters to autogen.sh as less as possible), 
this bug disappears. Therefore maybe some system-internal component 
are not configured correctly.


> [...]

It occurred to me that dpkg-buildflags forces -O2 whereas LO does

rene@frodo:~/LibreOffice/git/libreoffice-7-6$ cat 
solenv/gbuild/platform/LINUX_RISCV64_GCC.mk

# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
#
# This file is part of the LibreOffice project.
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#

#please make generic modifications to unxgcc.mk or linux.mk
gb_COMPILEROPTFLAGS := -Os

include $(GBUILDDIR)/platform/linux.mk

# vim: set noet sw=4:
rene@frodo:~/LibreOffice/git/libreoffice-7-6$

which probably was cargo-culted over when porting from other 
solenv/platform/*.mk, but anyways :)



So I had the idea to try a export DEB_BUILD_OPTIONS="noopt" build 
(resulting into -O0) and it looks better:


rene@debian-riscv64-porterbox-01 ~/libreoffice-7.5.5~rc1/cui
 % make UITest_cui_tabpages

[build UIT] cui_tabpages
S=/home/rene/libreoffice-7.5.5~rc1 && I=$S/instdir && W=$S/workdir &&  
rm -rf $W/UITest/cui_tabpages/ && mkdir -p 
$W/UITest/cui_tabpages//user/user && cp 
$S/qadevOOo/qa/registrymodifications.xcu 
$W/UITest/cui_tabpages//user/user/ &&  rm -fr 
$W/UITest/cui_tabpages/done.core && mkdir -p 
$W/UITest/cui_tabpages/user/ && mkdir $W/UITest/cui_tabpages/done.core 
&& cd $W/UITest/cui_tabpages/done.core &&   ( 
TEST_LIB=$W/LinkTarget/Library/libtest.so 
URE_BOOTSTRAP=vnd.sun.star.pathname:$I/program/fundamentalrc 
PYTHONPATH="$S/uitest:$S/unotest/source/python:$I/program:$S/cui/qa/uitest/tabpages/" 
TestUserDir="file://$W/UITest/cui_tabpages/" PYTHONDONTWRITEBYTECODE=0   
MAX_CONCURRENCY=4 MOZILLA_CERTIFICATE_FOLDER=dbm: 
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp 
LIBO_LANG=C   /usr/bin/python3 $S/uitest/test_main.py 
--soffice="path:$I/program/soffice" 
--userdir=file://$W/UITest/cui_tabpages/user 
--dir=$S/cui/qa/uitest/tabpages/  2>&1)
testThemePage (themepage.Test.testThemePage) ... OfficeConnection: 
connecting to: 
uno:pipe,name=pyteste5c58cc0-1f61-11ee-8c20-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
['OnNew']
OnCreate
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnFocus
['OnNew']
OnViewCreated
['OnNew']
OnModeChanged
['OnNew']
DialogExecute
['DialogClosed']
OnModeChanged
['OnNew']
OnModeChanged
['OnNew']
DialogClosed
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['DialogExecute']
OnModeChanged
['OnNew']
OnModeChanged
['OnNew']
DialogExecute
['DialogClosed']
OnModeChanged
['DialogExecute']
OnModeChanged
['OnNew']
OnModeChanged
['DialogExecute']
DialogClosed
['OnNew']
DialogClosed
['OnNew']
OnTitleChanged
['OnNew']
OnViewClosed
['OnNew']
OnUnload
['OnNew']
OnUnfocus
Execution time for themepage.Test.testThemePage: 20.341
at ./framework/source/helper/ocomponentenumeration.cxx:83
tearDown: calling terminate()...
...done
ok
testSvxColorTabPageTheme (tpcolor.Test.testSvxColorTabPageTheme) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytestfe6faaa8-1f61-11ee-8c20-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
['OnNew']
OnCreate
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnFocus
['OnNew']
OnViewCreated
['OnNew']
OnModeChan

Bug#1039906: libreoffice: FTBFS on riscv64: uitest throws "index out of range"

[Rene Engelhard]

Hi,

Am 29.06.23 um 17:29 schrieb Rene Engelhard:
Though that does not really matter, see [1]. We are supposed not to use 


Forgot to add that.

https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

Regards,

Rene

Bug#1039906: libreoffice: FTBFS on riscv64: uitest throws "index out of range"

[Rene Engelhard]

tag 1039906 + moreinfo

found 1039906 4:7.5.4-1

forwarded 1039906 
https://bugs.documentfoundation.org/show_bug.cgi?id=155937


thanks



Almost all the uitest cases throws such exception:

My gut feeling points to python. I mean it's not really test specific 
but on "Almost all the uitest" (which all are python).

ERROR: testThemePage (themepage.Test.testThemePage)
--
Traceback (most recent call last):
  File "/<>/cui/qa/uitest/tabpages/themepage.py", line 
19, in testThemePage
    with self.ui_test.create_doc_in_start_center("impress") as 
component:

  File "/usr/lib/python3.11/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/<>/uitest/uitest/test.py", line 195, in 
create_doc_in_start_center

    self.close_doc()
  File "/<>/uitest/uitest/test.py", line 221, in close_doc
    frames[0].activate()
    ~~^^^
IndexError: index out of range


I know, that's why I wrote 
https://lists.debian.org/debian-riscv/2023/06/msg0.html in the first 
place
This exception is always throwed when closing the doc window. As I 
described in bugzilla[1], the bug should be located between c++ and 
python environment.

Which is the bridges. Or python itself. I think.


It seems that the exception only throws in current Debian package. If 
I build LibreOffice (both 7.6 and 7.5 version) with external tarballs 
(that means, I pass parameters to autogen.sh as less as possible), 
this bug disappears. Therefore maybe some system-internal component 
are not configured correctly.


For reference: Which exact options?

Though that does not really matter, see [1]. We are supposed not to use 
some  random copies of libraries. Here in this case they also just build 
it using non-default build systems, thus even skipping their testsuite. 
(Which I or Debian or the respective upstream then fixed up)



Anyway, even then it does not make sense at all to ship a obsolete 
(3.8!) python version since then anything using pyUNO then would need to 
build with that python, too. And there's stuff in Debian using pyUNO.




I am building a debug version of LibreOffice with sbuild to debug uitest.


Yes, please.


Or try with a newer python? Unfortunately LibreOffice is not yet ready 
for python 3.12...



Regards,


Rene

Re: Getting hunspell 1.7.2 into unstable

[Rene Engelhard]

Hi,


Am 18.06.23 um 13:49 schrieb Changwoo Ryu:

2023년 6월 18일 (일) 오후 8:00, Rene Engelhard 님이 작성:

Should I add a Breaks: hunspell-ko (<< 0.7.94) here? Strictly speaking
it's not needed since it's a test failing not the dict being unusable,
but we could go the "better safe than sorry" route anyways.

No need. The problem still exists in hunspell-ko 0.7.94 but it's just
ignored as it's not that important.

Hmm.. OK. But thinking about it:

Then we still would need to wait for hunspell to be uploaded to sid
after hunspell-dict-ko migrated because otherwise the same autopkgtest
would block on sid->testing (or just wait until it magically works out
itself).

Isn't it supposed to run the failed autopkgtest again, when
hunspell-dict-ko gets migrated to testing? I'm not sure.


Yeah, it's supposed to...


Mind if I add it never



Regards,

--
Chan

theless? At least also saves as documentation that
there is "something".

That's OK. It's your call.


OK.


Regards,


Rene

Re: Getting hunspell 1.7.2 into unstable

[Rene Engelhard]

Hi,

Am 18.06.23 um 12:52 schrieb Changwoo Ryu:

2023년 6월 18일 (일) 오후 7:39, Rene Engelhard 님이 작성:

But I saw you uploaded hunspell-dict-ko 0.7.94 which incidentally has
someting hunspell 1.7.2-related (did I mention I don't like the stuff
being in Korean instead of English).

At least the tests pass with hunspell 1.7.2 and hunspell-dict-ko in my
VM now.

Yes. The version intentionally ignores the tests which failed.


I see.



Still needed? Or was it a fix in hunspell-dict-ko in  the end? Or just a
workaround?

It's not related to hunspell-dict-ko. And I don't think that's a bug.
It's how glibc iconv() works; dlload'ing  its encoding conversion
libs.


Yes, for the iconv thingy. I was talking about the actual failure :)



Should I add a Breaks: hunspell-ko (<< 0.7.94) here? Strictly speaking
it's not needed since it's a test failing not the dict being unusable,
but we could go the "better safe than sorry" route anyways.

No need. The problem still exists in hunspell-ko 0.7.94 but it's just
ignored as it's not that important.


Hmm.. OK. But thinking about it:

Then we still would need to wait for hunspell to be uploaded to sid 
after hunspell-dict-ko migrated because otherwise the same autopkgtest 
would block on sid->testing (or just wait until it magically works out 
itself).


Mind if I add it nevertheless? At least also saves as documentation that 
there is "something".



Regards,


Rene

Re: Getting hunspell 1.7.2 into unstable

[Rene Engelhard]

Hi,

Am 13.06.23 um 18:49 schrieb Rene Engelhard:

Am 12.06.23 um 19:32 schrieb Changwoo Ryu:

This failure is not from hunspell-dict-ko. hunspell just failed to
call iconv() in that environment.


Yeah, see  the code point in question, just wondering how that happens. 
Probably because of the minimal (buildd) chroot, works in my full 
unstable task-german-desktop et. al. unstable qemu VM.


(And current git unfortunately doesn't change the situation).


But I saw you uploaded hunspell-dict-ko 0.7.94 which incidentally has 
someting hunspell 1.7.2-related (did I mention I don't like the stuff 
being in Korean instead of English).


At least the tests pass with hunspell 1.7.2 and hunspell-dict-ko in my 
VM now.



Guess I need to report a bug at hunspell then.


Still needed? Or was it a fix in hunspell-dict-ko in  the end? Or just a 
workaround?


Should I add a Breaks: hunspell-ko (<< 0.7.94) here? Strictly speaking 
it's not needed since it's a test failing not the dict being unusable, 
but we could go the "better safe than sorry" route anyways.


Regards,


Rene

Bug#1037737: libreoffice: ftbfs with GCC-13

[Rene Engelhard]

Hi again,

Am 14.06.23 um 14:47 schrieb Rene Engelhard:

S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/GenCxxObject/UnpackedTarball/skia/src/gpu/ganesh/vk/
$W/Dep/GenCxxObject/UnpackedTarball/skia/src/gpu/ganesh/vk/ && cd
/<> && clang++ -DBOOST_ERROR_CODE_HEADER_ONLY
-DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DLINUX -DNDEBUG
-DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -DX86_64 -D_FORTIFY_SOURCE=2
-D_PTHREADS -D_REENTRANT -Wdate-time -Wdate-time -D_FORTIFY_SOURCE=2
-DSKIA_IMPLEMENTATION=1 -DSKIA_DLL
-DSK_USER_CONFIG_HEADER="<$S/config_host/config_skia.h>"
-DSYSTEM_ZLIB -DZLIB_CONST -flto=thin -fvisibility=hidden -Wall
-Wno-missing-braces -Wnon-virtual-dtor -Wendif-labels -Wextra
-Wundef -Wunreachable-code -Wshadow -Wunused-macros
-finput-charset=UTF-8 -fmessage-length=0 -fno-common -pipe
-Wdeprecated-copy-dtor -Wduplicated-cond -Wlogical-op
-Wshift-overflow=2 -Wunused-const-variable=1 -Wno-cast-function-type
-fvisibility-inlines-hidden -fPIC -Wshadow -Woverloaded-virtual
-std=c++17 -pthread -g -O2 -f
file-prefix-map=/<>=. -ffat-lto-objects
-fstack-protector-strong -Wformat -Werror=format-security
-DEXCEPTIONS_ON -fexceptions -O2 -w -DLIBO_INTERNAL_ONLY -c
$W/UnpackedTarball/skia/src/gpu/ganesh/vk/GrVkSampler.cpp -o
$W/GenCxxObject/UnpackedTarball/skia/src/gpu/ganesh/vk/GrVkSampler.o
-MMD -MT
$W/GenCxxObject/UnpackedTarball/skia/src/gpu/ganesh/vk/GrVkSampler.o
-MP -MF
$W/Dep/GenCxxObject/UnpackedTarball/skia/src/gpu/ganesh/vk/GrVkSampler.d_ 
-I$S/include -I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux -I$S/config_host -isystem 
/usr/include/freetype2 -isystem /usr/include/libpng16 -isystem /usr/include/freetype2 
-isystem /usr/include/libpng16 -isystem /usr/include/libpng16 -I$W/UnpackedTarball/skia 
-I$W/UnpackedTarball/skia/include/third_party/skcms/ 
-I$W/UnpackedTarball/skia/third_party/vulkanmemoryallocator/ 
-I$W/UnpackedTarball/skia/include/third_party/vulkan/ -I$S/external/skia/inc/ 
&& mv $W/Dep/GenCxxObject/Unp
ackedTarball/skia/src/gpu/ganesh/vk/GrVkSampler.d_
$W/Dep/GenCxxObject/UnpackedTarball/skia/src/gpu/ganesh/vk/GrVkSampler.d
test -f
/<>/workdir/UnpackedTarball/skia/src/gpu/ganesh/vk/GrVkSamplerYcbcrConversion.cpp || (echo 
"Missing generated source file 
/<>/workdir/UnpackedTarball/skia/src/gpu/ganesh/vk/GrVkSamplerYcbcrConversion.cpp" 
&& false)


On a side-note this is clang++, not g++. But I assume since upgrade of 
gcc and g++ from experimental also upgrades cpp it's cpp which is more 
strict here for the missing #include.


Anyways, as said: already fixed.

Regards,

Rene

Re: Getting hunspell 1.7.2 into unstable

[Rene Engelhard]

Hi,

Am 12.06.23 um 19:32 schrieb Changwoo Ryu:

This failure is not from hunspell-dict-ko. hunspell just failed to
call iconv() in that environment.


Yeah, see  the code point in question, just wondering how that happens. 
Probably because of the minimal (buildd) chroot, works in my full 
unstable task-german-desktop et. al. unstable qemu VM.


(And current git unfortunately doesn't change the situation).


Guess I need to report a bug at hunspell then.


Regards,


Rene

Re: Getting hunspell 1.7.2 into unstable

[Rene Engelhard]

Hi,

Am 12.06.23 um 18:58 schrieb Changwoo Ryu:

2023년 6월 11일 (일) 오후 7:34, Rene Engelhard 님이 작성:

This blocks (well, theoretically not, but then it'd block in unstable)
the upload of hunspell 1.7.2 which has many bugfixes and improvements
(and which the new version of r-cran-hunspell - due to embedding
internal headers - also needs now, so that one is also blocked. (CC'ed)).

Can you have a look?

May be a hunspell bug, may be a hunspell-dict-ko bug. It at least works
with hunspell 1.7.1.

hunspell 1.7.2 seems to break 3-word compound rules that
hunspell-dict-ko has used. I see the hunspell release note has a note
about the compoundings change.

Hmm.

I'd just ignore that test case for now. As a relief, what the 3-word
compound rules implement is not that important.


I'd try whether current git has some fixes in it but then I still get 
into the same issue as I think I outlined once:


rene@frodo:~/hunspell-dict-ko-0.7.93$ make hosttest 
HOST_DICT_PATH=/usr/share/hunspell/ko

make -C tests test DICT=/usr/share/hunspell/ko
make[1]: Entering directory '/home/rene/hunspell-dict-ko-0.7.93/tests'
echo | hunspell -d /usr/share/hunspell/ko | head -1
Hunspell 1.7.2 - hunspell-dict-ko 0.7.93 (requires Hunspell 1.3.1) 
https://spellcheck-ko.github.io/

python3 checkhunspellversion.py
Testing 001-pos-dependent-inflection.test...
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8
error - iconv: ANSI_X3.4-1968 -> UTF-8

Getting hunspell 1.7.2 into unstable

[Rene Engelhard]

Hi,

I think I pointed that out when hunspell 1.7.2+really1.7.2-4 was out and 
the  test results came in. Might be overseen or simply postponed due to 
the (upcoming) freeze anyways.


Let's have a try at it again :)

the experimental pseudo-excuses for hunspell say:

Experimental: Pseudo-Excuse for hunspell
Migration status for hunspell (1.7.2+really1.7.1-2 to 
1.7.2+really1.7.2-5): BLOCKED: Rejected/violates migration 
policy/introduces a regression

Issues preventing migration:
autopkgtest for hunspell-dict-ko/0.7.93-1: amd64: Regression ♻ 
(reference ♻), arm64: Regression ♻ (reference ♻), armel: Regression ♻ 
(reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ 
(reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ 
(reference ♻)
autopkgtest for libreoffice/blocked-on-ci-infra: armel: Ignored failure, 
i386: Ignored failure, ppc64el: Ignored failure, s390x: Ignored failure

Implicit dependency: hunspell r-cran-hunspell
Depends: hunspell r-cran-hunspell
Excuses generated on: Sat Jun 10 02:26:07 2023 UTC

(https://qa.debian.org/excuses.php?experimental=1=hunspell)

When looking at the actual log there I see

[...]
Hunspell 1.7.2 - hunspell-dict-ko 0.7.93 (requires Hunspell 1.3.1) 
https://spellcheck-ko.github.io/

python3 checkhunspellversion.py
Testing 001-pos-dependent-inflection.test...
Testing 002-irregular-inflection.test...
Testing 003-abbreviated-inflection.test...
Testing 004-compound-removing-rieul.test...
Testing 005-vowel-harmony.test...
Testing 006-descriptive-josa.test...
Testing 007-noun-suffix-and-josa.test...
Testing 008-dependent-josa.test...
Testing 009-auxiliary-verb.test...
009-auxiliary-verb.test:17: Y 사과인듯하네: & 사과인듯하네 15 0: 사과인 듯하네, 
사과인듯하네, 사관인듯하네, 사과인듯하나, 사과인듯하니, 사기인듯하네, 사고인듯하네, 
사구인듯하네, 사교인듯하네, 사과인듯하냐, 사계인듯하네, 사과인듯하게, 사과인듯하데, 
다과인듯하네, 사과일듯하네
009-auxiliary-verb.test:18: Y 선생님이신듯하고: & 선생님이신듯하고 1 0: 선생님이신 
듯하고

Testing 010-jamo-swap.test...
Testing 011-abbreviated-verb-suggestion.test...
Testing 012-wrong-inflection.test...
Testing 013-yeoncheol-buncheol.test...
Testing 014-sai-sios.test...
Testing 015-beginning-sound-rule.test...
Testing 016-numbers.test...
make[1]: *** [Makefile:9: test] Error 1
make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.kiimxcwu/downtmp/build.Xkj/src/tests'

make: *** [Makefile:53: hosttest] Error 2
/tmp/autopkgtest-lxc.kiimxcwu/downtmp/wrapper.sh: Killing leaked 
background processes: 1672

PID TTY  STAT   TIME COMMAND
   1672 ?R  0:01 hunspell -i UTF-8 -d /usr/share/hunspell/ko
autopkgtest [02:29:48]: test command1: ---]
autopkgtest [02:29:48]: test command1:  - - - - - - - - - - results - - 
- - - - - - - -

command1 FAIL non-zero exit status 2
autopkgtest [02:29:48]: test command1:  - - - - - - - - - - stderr - - - 
- - - - - - -
009-auxiliary-verb.test:17: Y 사과인듯하네: & 사과인듯하네 15 0: 사과인 듯하네, 
사과인듯하네, 사관인듯하네, 사과인듯하나, 사과인듯하니, 사기인듯하네, 사고인듯하네, 
사구인듯하네, 사교인듯하네, 사과인듯하냐, 사계인듯하네, 사과인듯하게, 사과인듯하데, 
다과인듯하네, 사과일듯하네
009-auxiliary-verb.test:18: Y 선생님이신듯하고: & 선생님이신듯하고 1 0: 선생님이신 
듯하고

make[1]: *** [Makefile:9: test] Error 1
make: *** [Makefile:53: hosttest] Error 2
autopkgtest [02:29:48]:  summary
command1 FAIL non-zero exit status 2

(sorry, no proper encoding here probably, neither is it in the original 
log, though, probably you have better output...)


https://ci.debian.net/data/autopkgtest/unstable/amd64/h/hunspell-dict-ko/34163061/log.gz

This blocks (well, theoretically not, but then it'd block in unstable) 
the upload of hunspell 1.7.2 which has many bugfixes and improvements
(and which the new version of r-cran-hunspell - due to embedding 
internal headers - also needs now, so that one is also blocked. (CC'ed)).


Can you have a look?

May be a hunspell bug, may be a hunspell-dict-ko bug. It at least works 
with hunspell 1.7.1.


There was a known bug for looong words (see 
https://tracker.debian.org/news/1406316/accepted-hunspell-172really172-4-source-into-experimental/:

 hunspell (1.7.2+really1.7.2-4) experimental; urgency=medium
 .
   * add patch from LibreOffice to allow longer words in hunspell-ko
 (https://github.com/hunspell/hunspell/issues/903)
) but that one is fixed, before that the failures in autopkgtest was 
even longer.


I'd file a bug at github but it seems everything is korean there (which 
I dislike, open source/free software stuff has to be done in english 
imho, and I am not a english native speaker either)


Regards,

Rene

Bug#1007031: "patch" available

[Rene Engelhard]

Am Thu, Mar 10, 2022 at 10:30:41PM +0100 schrieb Lucas Nussbaum:
> Please also see
> https://lists.debian.org/debian-devel/2022/03/msg00096.html , where it
> was noticed that the conversion for this package is trivial, and builds
> bit-by-bit identical binary packages.

Wrong. Those instructins assume a single debian patch which this one is
not. It has patches and I explicitely do NOT want a single debian patch.

And some patches are -p0, some -p1 and I think one even is -p2 from the
log.

So no, it's not as trivial as you want to say. Please look at packages
before you comment - which you here obviously did not and just posted a
hilaroioud "patch" link to all regardless of their nature.

Regards,

Rene

Bug#1036904: bookworm-pu: package libreoffice/4:7.4.7-1

[Rene Engelhard]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libreoff...@packages.debian.org
Control: affects -1 + src:libreoffice

Hi,

[ Reason ]
Update to "current" version. (Latest version of stable branch)

Same reasoning as of #1035056.

This updates LibreOffice to the last version in the (dead, EOL is June 12) 
7.4.x line[1]
to fix a sh*load of bugs. List of bugs fixed: See [2]

Quoting from #1035056:

"there have been *hundreds* of bugs fixed since. Cherry-picking fixes
for the most prominent crashes just isn’t practical considering
especially how many bugs were fixed"

Same reasoing here.

[ Impact ]
Unfixed bugs.

[ Tests ]
LibreOffice has a testsuite.

[ Risks ]
New upstream versions always have risk in contrast to what "x s" wants
to claim in #1035056. It's the last release of a stable bugfix series,
though.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [ ]  the issue is verified as fixed in unstable

(not verified to be fixed in unstable yet since we are still in the
freeze and I am not allowed to upload to sid)

The 7.4.7 upstream release will (as of plans right now) never make trixie
or even unstable at all since it's dead by then; will directly jump to
7.5.4-1. (Unless something last-minute happens)

[ Changes ]
1.  upstream update 7.4.5 -> 7.4.7. The two patches removed are security
fixes which were already in 7.4.6 and 7.4.7 and now of course removed.
No need to mention that in the changelog, it's implied by "New upstream
release" that patches upstream are dropped.

2. the libreoffice-sdbc-postgresql has a Dependency on -core, not (as
the other database drivers) -core-nogui | -core) so can't be installed
with -nogui. But that one could come handy for mail merges or so if your
data source is a pgsql. Didn't do it because of the freeze.

3. Even when running under nogui LO wants an .ui file at a --convert-to
call. The fix (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028290)
is just to exclude that from rm so it works. And actually also
would make https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024840
fixable. Although that admittedly is quote moot for stable since that
won't affect it because 1024840 is no stable material anyway. But it
might make sense to include nevertheless for people using --convert-to
on ppt(x) in other means although most of them would use -impress and
not -impress-nogui I guess ;)

[ Other info ]
I can back out the fix for 3. The other two are simply not discussable
given #1035056.

The whole diff is
  1784 files changed, 52460 insertions(+), 52070 deletions(-)
but the sole upstream update is
 1776 files changed, 52442 insertions(+), 50892 deletions(-)
of which ~1400 is just the translations, just the "core" is
 388 files changed, 8359 insertions(+), 4481 deletions(-)

The whole diff is 17M, so I am not attaching it here. It is at
https://people.debian.org/~rene/libreoffice/7.4/7.4.7.debdiff

I know this is completely bending the rules, but so is #1035056, too
If you wish I can make this also -0deb12u1, but as there will be no
7.4.7-1 probably thia is not exactly needed.

Regards,

Rene

[1] https://wiki.documentfoundation.org/ReleasePlan/7.4

[2] https://wiki.documentfoundation.org/Releases/7.4.6/RC1#List_of_fixed_bugs
https://wiki.documentfoundation.org/Releases/7.4.6/RC2#List_of_fixed_bugs
https://wiki.documentfoundation.org/Releases/7.4.7/RC1#List_of_fixed_bugs
https://wiki.documentfoundation.org/Releases/7.4.7/RC2#List_of_fixed_bugs

Bug#1036805: libreoffice's toolbar buttons became hard to see after upgrading to Debian 12

[Rene Engelhard]

tag 1036805 + moreinfo

# unless it's really a problem, look fine here

severity 1036805 minor

thanks


Am 26.05.23 um 19:22 schrieb José Luis González:

Package: libreoffice-writer
Version: 4:7.4.5-2
Severity: important

After upgrading to Debian 12, writer's toolbar buttons became hard
to see,

Pretty subjective. Especially without any prooof or screenshot or so.

looking liquid.


Screenshot?


Which icon set? Which desktop? I assume GNOME?



I have checked with the other components and it's happening with all.


Of course, it's one iconset..

Please, reassign if appropriate.

>  You could have assigned it to -common if you didn't know which 
iconset (libreoffice-style-*) you have installed (or use, that one is in 
the Settings), but a individual component is so obviously wrong...


And this is a case of "I didn't do any research, let the maintainer 
reassign it" which imho is bad.



Regards,


Rene

Bug#1036766: unblock: libreoffice/4:7.4.5-3

[Rene Engelhard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libreoff...@packages.debian.org, t...@security.debian.org
Control: affects -1 + src:libreoffice

Please unblock package libreoffice

[ Reason ]
1. Main reason is CVE-2023-2255 and CVE-2023-0950.

2. I had two changelog commits in my tree.
   One is just documentation () and the other one fixes a simple
   spelling error which lintian loudly complains about.
   (cf. 
https://udd.debian.org/lintian/?email1libreoffice==html_error=on_warning=on_tag=spelling-error-in-changelog#all)
   That should be a no-brainer.

3. My tree also included the commit to make ulimit -c calls not fatal.
   Since the bookworm update on ci this fails in lxc. There was a config
   change (to be) deployed to prevent that but either it didn't happen
   or was reverted. It still fails.
   So we probably should include it, experimental has it for ages
   already.

[ Impact ]
for 1. vulnerable LibreOffice

   While we could do this via bookworm-security probably I think we can avoid 
this since we do have
   enough time..

for 3. autopkgtests still failing on ci.d.n inside lxc

[ Tests ]
Not sure whether the automatic tests cover this part.
It obviously builds ;)

[ Risks ]
The diff is big but the patch is taken verbatim from upstream 7.5
branch with just minor adaptions which are not risky (CVE-2023-2255)
and upstream 7.4.6 (CVE-2023-0950)

The ulimit -c changes are already in experimental.

The changelog fix/the addition do not have any risk at all (and it is
also already in experimental)

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libreoffice/4:7.4.5-3
age-days 2 libreoffice/4:7.4.5-3

diff -Nru libreoffice-7.4.5/debian/changelog libreoffice-7.4.5/debian/changelog
--- libreoffice-7.4.5/debian/changelog  2023-02-05 18:40:59.0 +0100
+++ libreoffice-7.4.5/debian/changelog  2023-05-22 18:00:45.0 +0200
@@ -1,3 +1,17 @@
+libreoffice (4:7.4.5-3) unstable; urgency=high
+
+  * debian/patches/sc-stack-parameter-count.diff: fix CVE-2023-0950
+("Array Index UnderFlow in Calc Formula Parsing")
+  * debian/rules, debian/tests/*: don't fail if ulimit -c unlimited fails 
+(like in ci.d.n infrastructure after the bookworm upgrade...)
+  * debian/patches/CVE-2023-2255.diff:
+fix CVE-2023-2555 ("Remote documents loaded without prompt via IFrame")
+  * debian/changelog:
+- mention CVE-2022-38745 in 1:7.3.1-1s changelog
+- fix typo in last upload (s/choosen/chosen/), thanks lintian
+
+ -- Rene Engelhard   Mon, 22 May 2023 18:00:45 +0200
+
 libreoffice (4:7.4.5-2) unstable; urgency=medium
 
   * fontconfig-2.14.1-no-RGB-stripes-layout-for-sub-pixel-rendering.diff:
@@ -5,7 +19,7 @@
   * debian/control.in:
 - ... but build-conflict against affected fontconfig-configs (with
   ) instead since it now removes the offending config per default
-  (buildd chroot...) if not choosen otherwise via debconf (see #103)
+  (buildd chroot...) if not chosen otherwise via debconf (see #103)
   * debian/rules:
 - Do not add documentation symlinks when not building documentation,
   thanks Vagrant Cascadian (closes: #1030270)
@@ -502,6 +516,8 @@
 libreoffice (1:7.3.1-1) unstable; urgency=medium
 
   * LibreOffice 7.3.1 final release
+- fixes CVE-2022-38745: "Empty entry in Java class path risks arbitrary
+  code execution"
 
  -- Rene Engelhard   Thu, 03 Mar 2022 17:24:16 +
 
diff -Nru libreoffice-7.4.5/debian/patches/CVE-2023-2255.diff 
libreoffice-7.4.5/debian/patches/CVE-2023-2255.diff
--- libreoffice-7.4.5/debian/patches/CVE-2023-2255.diff 1970-01-01 
01:00:00.0 +0100
+++ libreoffice-7.4.5/debian/patches/CVE-2023-2255.diff 2023-05-20 
12:21:27.0 +0200
@@ -0,0 +1,946 @@
+From 683e4de0de8dde7c5570c67cbd2bae17b6d7f0e0 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= 
+Date: Tue, 11 Apr 2023 10:13:37 +0100
+Subject: set Referer on loading IFrames
+
+so tools, options, security, options,
+"block any links from document not..."
+applies to their contents.
+
+Change-Id: I04839aea6b07a4a76ac147a85045939ccd9c3c79
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150225
+Tested-by: Jenkins
+Reviewed-by: Stephan Bergmann 
+---
+ sfx2/source/doc/iframe.cxx | 13 ++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+From 49a554471cddc3e52ae381f864e689fe4a8c6131 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= 
+Date: Thu, 13 Apr 2023 11:31:17 +0100
+Subject: put floating frames under managed links control
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+like we do for sections and ole objects that link to their content
+
+individual commits in trunk are:
+
+extract a OCommonEmbeddedObject::SetInpl

Bug#1036366: libreoffice: fails to embed font subset, PDF not printable, no option to disable subsetting nor embedding

[Rene Engelhard]

Hi,

Am 20.05.23 um 23:52 schrieb Thorsten Glaser:

Rene Engelhard dixit:


You as DD should know that stable won't get any updates for this anymore. (And
it will be oldstable in a short time anyway, even.)

So, who cares?

me :)

So reporting this against stable does not make any sense at all.

It does: it records the issue, so others will know,

True

and requests
the maintainers (both in Debian and upstream) to do something about
it at least in future versions.


No, upstream doesn't do it when it just appears here. And I could 
forward it, but how does  that help?


I don't have enough info and no time to play proxy for every question.





Please try with bookworms package (that one has stable backports, but is

Please do so. You’re in a much better position than I am, I don’t
even have a bookworm/sid system and don’t plan on getting one either.


I don't even understand the problem. So you as the submitter is better 
suited to do this.




(And I still think such bugs should be reported upstream directly)

And I still counter that you are in a much better position than me to
do so.


I disagree. You know best what's the problem and what not :)



  I don’t have the bandwidth to do that, I already lost over an
hour fighting this (I ended up having to hack the font, renaming it in
FontForge), and every day I don’t need to touch an office program is a
better day.


I don't use it either...



I cannot

respond to the questions they will surely have and I cannot test their
proposed fixes either.

Exactly the same for a "simple" maintainer of the package without knowing the 
exact problem...

Regards,


Rene

Bug#998940: Bug#965794: python-ooolib: diff for NMU version 0.0.22-5.1

[Rene Engelhard]

Hi,

Am 20.05.23 um 12:58 schrieb Andreas Metzler:

How hard is it to communicate? Why didn't you simply write to the
bugreport that you wanted the pkg to be autormed instead of letting
me waste my time?


The waste of time wsn't on my part. From all the QA data visible on DDPO 
this should have been abvious.


Admittedly, I shouldn't have just answered Adrian on his last reset *on 
the day it was supposed to be removed* but just also here, by bad there.



Still...


I have removed the upload.


No, you haven't. I had already.


Regards,


Rene

Bug#965794: python-ooolib: diff for NMU version 0.0.22-5.1

[Rene Engelhard]

Hi,

Am 20.05.23 um 11:38 schrieb Andreas Metzler:

I've prepared an NMU for python-ooolib (versioned as 0.0.22-5.1) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.


How is it unclear that noone seriously cares about this package?

Old upstream version, popcon 4, ignored by the maintainer. The fix is 
clear, I just want to get it AUTORMed. How difficult is it to understand 
that?



As I already said to Adrian when he last tagged the bug: stop resetting 
the autorm counter.


(which you did now again, sigh.)

 Besides that: it would miss the hard freeze anyway with medium urgency 
so it's a total waste of time.



Regards,


Rene

Bug#1036366: libreoffice: fails to embed font subset, PDF not printable, no option to disable subsetting nor embedding

[Rene Engelhard]

tag 1036366 + moreinfo

thanks

Hi,

Am 20.05.23 um 01:57 schrieb Thorsten Glaser:

Package: libreoffice-writer
Version: 1:7.0.4-4+deb11u6
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de


You as DD should know that stable won't get any updates for this 
anymore. (And it will be oldstable in a short time anyway, even.)


So reporting this against stable does not make any sense at all.

Please try with bookworms package (that one has stable backports, but is 
end-of-life upstream soonish[1])  - or even better: something more 
uptodate getting upstream development: experimentals 7.5 (which also is 
in "important bugfixes" mode only now, though[1]) - or even 7.6.0 
alpha1[1][2].


I think I saw commits for font subsetting passing by when I checked the 
commit log for other things..)



(And I still think such bugs should be reported upstream directly)

Regards,


Rene


Oh, and I noticed #965236 is also still open, meaning PDF files

generated by LibreOffice aren’t legal to distribute…


Similiar for that one ;)


Regards,


Rene


[1] https://wiki.documentfoundation.org/ReleasePlan/7.4 and 
https://wiki.documentfoundation.org/ReleasePlan/7.5 and 
https://wiki.documentfoundation.org/ReleasePlan/7.6


[2] http://people.debian.org/~rene/libreoffice/7.6/releases and/or 
http://people.debian.org/~rene/libreoffice/7.6/snapshots

Bug#1028290: libreoffice-impress-nogui cannot convert to PNG

[Rene Engelhard]

Hi,

Am 01.05.23 um 00:41 schrieb Rene Engelhard:

It *seems* to be this in your nogui-strace:

94919 21:08:29.439478 openat(AT_FDCWD, 
"/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/tabviewbar.ui", O_RDONLY) = -1 ENOENT (No such file or directory)
94919 21:08:29.439573 --- SIGSEGV {si_signo=SIGSEGV, 
si_code=SEGV_MAPERR, si_addr=NULL} ---
94919 21:08:29.439478 openat(AT_FDCWD, 
"/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/tabviewbar.ui", O_RDONLY) = -1 ENOENT (No such file or directory)
94919 21:08:29.439573 --- SIGSEGV {si_signo=SIGSEGV, 
si_code=SEGV_MAPERR, si_addr=NULL} ---

[...]

Yes, it's definitely tabviewbar.ui which suffices and makes it work:

rene@debianunstable:~$ soffice --convert-to A.png A.pptx
Warning: failed to launch javaldx - java may not function correctly
Unspecified Application Error
rene@debianunstable:~$ su -
Passwort:
root@debianunstable:~# cd /home/rene/
root@debianunstable:/home/rene# mkdir -p 
/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui
root@debianunstable:/home/rene# cp 
usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/tabviewbar.ui 
/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui

[from libreoffice-impress deb dpkg-deb -x'ed]
root@debianunstable:/home/rene#
Abgemeldet
rene@debianunstable:~$ soffice --convert-to A.png A.pptx
Warning: failed to launch javaldx - java may not function correctly
convert /home/rene/A.pptx as a Impress document -> /home/rene/A.A.png 
using filter : impress_png_Export

Overwriting: /home/rene/A.A.png
rene@debianunstable:~$

Forwarded upstream.
No idea whether it'll be acted on (and how), maybe we really need to 
split those files into a -uiconfig-impress or somesuch and make 
-impress-nogui Recommend or even Depend on it


Regards,

Rene

Bug#1028290: libreoffice-impress-nogui cannot convert to PNG

[Rene Engelhard]

Hi,

Am 12.01.23 um 17:38 schrieb Rene Engelhard:

This one also works but only with the binary in the instdir-nogui, *not*
if I install the resulting .debs:


Ah, hmm, so that really points to a packaging problem or a problem which 
only exhibitx due to packaging.


 From looking at the initial straces briefly I have an idea but that 
might just be a red herring...


While debugging another issue boiling down to a missing .ui file[1] I 
looked at this one.


It *seems* to be this in your nogui-strace:

94919 21:08:29.439478 openat(AT_FDCWD, 
"/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/tabviewbar.ui", 
O_RDONLY) = -1 ENOENT (No such file or directory)
94919 21:08:29.439573 --- SIGSEGV {si_signo=SIGSEGV, 
si_code=SEGV_MAPERR, si_addr=NULL} ---
94919 21:08:29.439478 openat(AT_FDCWD, 
"/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/tabviewbar.ui", 
O_RDONLY) = -1 ENOENT (No such file or directory)
94919 21:08:29.439573 --- SIGSEGV {si_signo=SIGSEGV, 
si_code=SEGV_MAPERR, si_addr=NULL} ---


And indeed, for libreoffice-*-nogui we do

find 
debian/libreoffice-*-nogui/$(OODIR)/share/config/soffice.cfg -name 
"*.ui" -exec rm {} \;


since those are files for the UI (and thus shoud not(tm) needed if 
there's no (G)UI...)


Now the question is whether we start shipping those UI-Files in nogui 
(which sounds awkward) or try to ship enough that a --convert-to works...


Regards,

Rene

[1] 
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/64bef88bf381d7cce8914bcc7bdd7259dde0ca02

Bug#1034792: libreoffice-sdbc-postgresql: cannot be coinstalled with libreoffice-nogui, which recommends it

[Rene Engelhard]

Hi,

Am 24.04.23 um 17:09 schrieb Dalton Durst:

The dependency chain in question looks something like this:

libreoffice-nogui
 Depends: libreoffice-core-nogui
 Recommends: libreoffice-sdbc-postgresql
 Depends: libreoffice-core
 Conflicts: libreoffice-core-nogui

Can libreoffice-sdbc-postgresql be used with libreoffice-core-nogui?


Maybe, if you get the connect string into there via some API call. No 
idea whether it is possible.


Or if it's referenced in a existing .odb..


If
so, should -sdbc-postgresql have an Or-relation between -core and
-core-nogui? Or, is there another more tenable solution for this case?


Yes, maybe it's just an oversight when -nogui was introduced.

I would at least think that if scripting some mailmerge having the 
actual driver for the database (if it's postgres) might make sense...



Regards,


Rene

Bug#1033506: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u6

[Rene Engelhard]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libreoff...@packages.debian.org
Control: affects -1 + src:libreoffice

Hi,

This fixes "CVE-2022-38745. Empty entry in Java class path risks
arbitrary code execution" just disclosed by Apache OpenOffice.

libreoffice 7.0.4 in bullseye (and buster, but that is EOL) also is affected.

The security team thinks this doesn't warrant a DSA and should be done
here.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
https://cgit.freedesktop.org/libreoffice/core/commit/?id=5e8f64e50f97d39e83a3358697be14db03566878
(which is fixed in  7.2.6 and 7.3.1) backported.

Debdiff:

diff -Nru libreoffice-7.0.4/debian/changelog libreoffice-7.0.4/debian/changelog
--- libreoffice-7.0.4/debian/changelog  2022-11-27 19:37:58.0 +0100
+++ libreoffice-7.0.4/debian/changelog  2023-03-25 14:04:55.0 +0100
@@ -1,3 +1,10 @@
+libreoffice (1:7.0.4-4+deb11u6) bullseye; urgency=medium
+
+  * debian/patches/avoid-empty-java.class.path.diff: apply upstream patch
+avoiding empty -Djava.class.path= (CVE-2022-38745)
+
+ -- Rene Engelhard   Sat, 25 Mar 2023 14:04:55 +0100
+
 libreoffice (1:7.0.4-4+deb11u5) bullseye; urgency=medium

   * debian/patches/hrk-euro-default.diff: default to EUR for .hr
diff -Nru libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff 
libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff
--- libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff   
1970-01-01 01:00:00.0 +0100
+++ libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff   
2023-03-25 14:04:55.0 +0100
@@ -0,0 +1,90 @@
+From 5e8f64e50f97d39e83a3358697be14db03566878 Mon Sep 17 00:00:00 2001
+From: Stephan Bergmann 
+Date: Mon, 21 Feb 2022 11:55:21 +0100
+Subject: Avoid unnecessary empty -Djava.class.path=
+
+Change-Id: Idcfe7321077b60381c0273910b1faeb444ef1fd8
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130242
+Tested-by: Jenkins
+Reviewed-by: Stephan Bergmann 
+---
+ jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx | 16 +---
+ jvmfwk/source/framework.cxx |  8 ++--
+ jvmfwk/source/fwkbase.cxx   |  3 +++
+ 3 files changed, 22 insertions(+), 5 deletions(-)
+
+diff --git a/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx 
b/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
+index 29de226211f1..e55b914edf13 100644
+--- a/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
 b/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
+@@ -712,17 +712,22 @@ javaPluginError jfw_plugin_startJavaVirtualMachine(
+ // all versions below 1.5.1
+ options.emplace_back("abort", reinterpret_cast(abort_handler));
+ bool hasStackSize = false;
++#ifdef UNX
++// Until java 1.5 we need to put a plugin.jar or javaplugin.jar (<1.4.2)
++// in the class path in order to have applet support:
++OString sAddPath = getPluginJarPath(pInfo->sVendor, 
pInfo->sLocation,pInfo->sVersion);
++#endif
+ for (int i = 0; i < cOptions; i++)
+ {
+ OString opt(arOptions[i].optionString);
+ #ifdef UNX
+-// Until java 1.5 we need to put a plugin.jar or javaplugin.jar 
(<1.4.2)
+-// in the class path in order to have applet support:
+ if (opt.startsWith("-Djava.class.path="))
+ {
+-OString sAddPath = getPluginJarPath(pInfo->sVendor, 
pInfo->sLocation,pInfo->sVersion);
+ if (!sAddPath.isEmpty())
++{
+ opt += OStringChar(SAL_PATHSEPARATOR) + sAddPath;
++sAddPath.clear();
++}
+ }
+ #endif
+ if (opt == "-Xint") {
+@@ -767,6 +772,11 @@ javaPluginError jfw_plugin_startJavaVirtualMachine(
+ }
+ #endif
+ }
++#ifdef UNX
++if (!sAddPath.isEmpty()) {
++options.emplace_back("-Djava.class.path=" + sAddPath, nullptr);
++}
++#endif
+
+ std::unique_ptr sarOptions(new 
JavaVMOption[options.size()]);
+ for (std::vector::size_type i = 0; i != options.size(); ++i) {
+diff --git a/jvmfwk/source/framework.cxx b/jvmfwk/source/framework.cxx
+index 4163eea57b7c..8aa85082b838 100644
+--- a/jvmfwk/source/framework.cxx
 b/jvmfwk/source/framework.cxx
+@@ -195,8 +195,12 @@ javaFrameworkError jfw_startVM(
+ //In direct mode the options are specified by bootstrap 
variables
+ //of the form UNO_JAVA_JFW_PARAMETER_1 .. 
UNO_JAVA_JFW_PARAMETER_n
+ vmParams = jfw::BootParams::getVMParameters();
+-sUserClassPath =
+-"-Djava.class.path=" + jfw::BootParams::getClasspath();
++   

Re: Cut and Paste looses formatting when copying from one table to another table

[Rene Engelhard]

Hi,

Am 26.02.23 um 12:02 schrieb Rainer Dorsch:

The issue does not occur on a Manjaro Stable system with Libreoffice 7.5.0

Maybe fixed in 7.5.0?

The systems don't share the home directory though. Is the are a way to make
libreoffice ignoring all user settings?

You can start with safe mode..

Any hint what could be wrong is welcome.


See above, it can just be a upstream bug. You can try with 
bookworm/sid+experimental in a VM? Or wait until there will be 7.5.x in 
bookworm-backports (yes, explicitely NOT bullseye-backports).



Too bad there was never really a chance to  get 7.5.x into bookworm 
given the freeze schedule.


/7.5.0 might have worked if one was really courageos but then we'd have 
a serious problem on any bigger surprise. Usually .0s are not really 
good anyway, .1 woul bd a given and that really misses the deadline 
completely)



Regards,


Rene

Bug#1031578: lightproof: FTBFS in testing: make[1]: *** [debian/rules:38: override_dh_auto_install] Error 1

[Rene Engelhard]

Hi,

No, it does not.

In a clean cowbuilder testing chroot:


Also not inside sbuild (in a freshly created sbuild testing chroot).


Regards,


Rene

Bug#1031578: lightproof: FTBFS in testing: make[1]: *** [debian/rules:38: override_dh_auto_install] Error 1

[Rene Engelhard]

clone 1031578 -1
retitle -1 ru/hu fail to build with python 3.11: re.error: global flags 
not at the start of the expression at position 28

block -1 by 1031578
tag -1 - unreproducible
tag -1 + help
thanks

Hi,

Am 19.02.23 um 08:49 schrieb Rene Engelhard:
The real issue though seems to be a fallout of the python3 transition 
and that it breaks with python 3.11:


for cfg in `find src -name "*.cfg"`; do \
     python3 make.py $cfg; \
done
/home/rene/lightproof-1.6/make.py:39: DeprecationWarning: The 
SafeConfigParser class has been renamed to ConfigParser in Python 3.2. 
This alias will be removed in Python 3.12. Use ConfigParser directly 
instead.

   fArgs = cp.SafeConfigParser()
/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py:170: 
FutureWarning: Possible nested set at position 5
   compr = re.compile(sc)
Traceback (most recent call last):
   File 
"/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py", line 170, in mysplit

     compr = re.compile(sc)
     ^^
   File "/usr/lib/python3.11/re/__init__.py", line 227, in compile
     return _compile(pattern, flags)
    
   File "/usr/lib/python3.11/re/__init__.py", line 294, in _compile
     p = _compiler.compile(pattern, flags)
     ^
   File "/usr/lib/python3.11/re/_compiler.py", line 743, in compile
     p = _parser.parse(p, flags)
     ^^^
   File "/usr/lib/python3.11/re/_parser.py", line 980, in parse
     p = _parse_sub(source, state, flags & SRE_FLAG_VERBOSE, 0)
     ^^
   File "/usr/lib/python3.11/re/_parser.py", line 455, in _parse_sub
     itemsappend(_parse(source, state, verbose, nested + 1,
     ^^
   File "/usr/lib/python3.11/re/_parser.py", line 841, in _parse
     raise source.error('global flags not at the start '
re.error: global flags not at the start of the expression at position 28

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "/home/rene/lightproof-1.6/make.py", line 43, in 
     dist(i[:-4], fArgs._sections['args'])
   File "/home/rene/lightproof-1.6/make.py", line 15, in dist
     code = pythonpath.lightproof_compile___implname__.c(f.read(), 
a['lang'])

^
   File 
"/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py", line 270, in c

     item = mysplit(lines[i].strip(), i + 1, oldlinenums[lines[i]], debug)
^^
   File 
"/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py", line 174, in mysplit

     raise Exception(str(e), oldline)
Exception: ('global flags not at the start of the expression at position 
28', 126)


missing config file or options: src/hu_HU/hu_HU.cfg
/home/rene/lightproof-1.6/make.py:39: DeprecationWarning: The 
SafeConfigParser class has been renamed to ConfigParser in Python 3.2. 
This alias will be removed in Python 3.12. Use ConfigParser directly 
instead.

   fArgs = cp.SafeConfigParser()
/usr/lib/python3.11/zipfile.py:1547: UserWarning: Duplicate name: 
'META-INF/manifest.xml'

   return self._open_to_write(zinfo, force_zip64=force_zip64)
/home/rene/lightproof-1.6/make.py:39: DeprecationWarning: The 
SafeConfigParser class has been renamed to ConfigParser in Python 3.2. 
This alias will be removed in Python 3.12. Use ConfigParser directly 
instead.

   fArgs = cp.SafeConfigParser()
Traceback (most recent call last):
   File 
"/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py", line 170, in mysplit

     compr = re.compile(sc)
     ^^
   File "/usr/lib/python3.11/re/__init__.py", line 227, in compile
     return _compile(pattern, flags)
    
   File "/usr/lib/python3.11/re/__init__.py", line 294, in _compile
     p = _compiler.compile(pattern, flags)
     ^
   File "/usr/lib/python3.11/re/_compiler.py", line 743, in compile
     p = _parser.parse(p, flags)
     ^^^
   File "/usr/lib/python3.11/re/_parser.py", line 980, in parse
     p = _parse_sub(source, state, flags & SRE_FLAG_VERBOSE, 0)
     ^^
   File "/usr/lib/python3.11/re/_parser.py", line 455, in _parse_sub
     itemsappend(_parse(source, state, verbose, nested + 1,
     ^^
   File "/usr/lib/python3.11/re/_parser.py", line 841, in _parse
     raise source.error('global flags not at the start '
re.error: global flags not at th

Bug#1031578: lightproof: FTBFS in testing: make[1]: *** [debian/rules:38: override_dh_auto_install] Error 1

[Rene Engelhard]

tag 1031578 + unreproducible

thanks


Hi,

Am 18.02.23 um 23:06 schrieb Lucas Nussbaum:

During a rebuild of all packages in testing (bookworm), your package failed
to build on amd64.


No, it does not.

In a clean cowbuilder testing chroot:

$ apt-get -b source lightproof
Reading package lists... Done
Skipping already downloaded file 'lightproof_1.6-2.dsc'
Skipping already downloaded file 'lightproof_1.6.orig.tar.gz'
Skipping already downloaded file 'lightproof_1.6-2.debian.tar.xz'
Need to get 0 B of source archives.
Skipping unpack of already unpacked source in lightproof-1.6
dpkg-buildpackage: info: source package lightproof
dpkg-buildpackage: info: source version 1.6-2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Rene Engelhard 
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .

 fakeroot debian/rules clean
dh clean
dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/rene/lightproof-1.6'
find . -name "*.pyc" -exec rm {} \;
find . -name "*.oxt" -exec rm {} \;
dh_clean
dh_clean: warning: Compatibility levels before 10 are deprecated (level 
9 in use)

# manually needed as long as we don't build -editor
rm -rf debian/libreoffice-lightproof-editor
rm -f debian/libreoffice-lightproof-editor.substvars
make[1]: Leaving directory '/home/rene/lightproof-1.6'
   dh_clean
dh_clean: warning: Compatibility levels before 10 are deprecated (level 
9 in use)

 debian/rules build
dh build
dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
   dh_update_autotools_config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/home/rene/lightproof-1.6'
for cfg in `find src -name "*.cfg"`; do \
    python3 make.py $cfg; \
done
/home/rene/lightproof-1.6/make.py:39: DeprecationWarning: The 
SafeConfigParser class has been renamed to ConfigParser in Python 3.2. 
This alias will be removed in Python 3.12. Use ConfigParser directly 
instead.

  fArgs = cp.SafeConfigParser()
/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py:170: 
FutureWarning: Possible nested set at position 5

  compr = re.compile(sc)
Traceback (most recent call last):
  File 
"/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py", 
line 170, in mysplit

    compr = re.compile(sc)
    ^^
  File "/usr/lib/python3.11/re/__init__.py", line 227, in compile
    return _compile(pattern, flags)
   
  File "/usr/lib/python3.11/re/__init__.py", line 294, in _compile
    p = _compiler.compile(pattern, flags)
    ^
  File "/usr/lib/python3.11/re/_compiler.py", line 743, in compile
    p = _parser.parse(p, flags)
    ^^^
  File "/usr/lib/python3.11/re/_parser.py", line 980, in parse
    p = _parse_sub(source, state, flags & SRE_FLAG_VERBOSE, 0)
    ^^
  File "/usr/lib/python3.11/re/_parser.py", line 455, in _parse_sub
    itemsappend(_parse(source, state, verbose, nested + 1,
    ^^
  File "/usr/lib/python3.11/re/_parser.py", line 841, in _parse
    raise source.error('global flags not at the start '
re.error: global flags not at the start of the expression at position 28

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/rene/lightproof-1.6/make.py", line 43, in 
    dist(i[:-4], fArgs._sections['args'])
  File "/home/rene/lightproof-1.6/make.py", line 15, in dist
    code = pythonpath.lightproof_compile___implname__.c(f.read(), 
a['lang'])

^
  File 
"/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py", 
line 270, in c

    item = mysplit(lines[i].strip(), i + 1, oldlinenums[lines[i]], debug)
^^
  File 
"/home/rene/lightproof-1.6/pythonpath/lightproof_compile___implname__.py", 
line 174, in mysplit

    raise Exception(str(e), oldline)
Exception: ('global flags not at the start of the expression at position 
28', 126)


missing config file or options: src/hu_HU/hu_HU.cfg
/home/rene/lightproof-1.6/make.py:39: DeprecationWarning: The 
SafeConfigParser class has been renamed to ConfigParser in Python 3.2. 
This alias will be removed in Python 3.12. Use ConfigParser directly 
instead.

  fArgs = cp.SafeConfigParser()
/usr/lib/python3.11/zipfile.py:1547: UserWarning: Duplicate name: 
'META-INF/manifest.xml'

  return self._open_to_write(zinfo, force_zip64=force_zip64)
/home/rene/lightproof-1.6/make.py:39: DeprecationWarning: The 
SafeConfigParse

Bug#1031199: liblangtag-common: Bratislava is in wrong timezone, should be cet, not bts

[Rene Engelhard]

tag 1031199 + moreinfo
thanks

Hi,

Am 13. Februar 2023 07:12:24 MEZ schrieb Mato :
>Package: liblangtag-common
>Version: 0.6.4-2
(...)
>Last update

You mean the one in August last year?

> introduced timezone error, where Bratislava is in wrong
>timezone now. tzdata package is correct. It affects desktop display
>time.

This doesn't make sense.

I don't think liblangtag has any Timezone info, just guessing "tagging" of 
languages, not time - and wasn't updated in months anyway.

Look in your logs what got updated and what might be responsible here.

Regards

René 
>-- System Information:
>Debian Release: bookworm/sid
>  APT prefers testing
>  APT policy: (500, 'testing')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
>LANGUAGE=en_US:en
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>-- no debconf information
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Can't change the values in the sub-option under, Writing Aids / Available language modules, from English (USA) to English (UK)

[Rene Engelhard]

Hi,

Am 24.01.23 um 07:24 schrieb Susmita/Rajib:

However, the values in the sub-menus under the Libre Office / Options
/ Language Settings / Writing Aids / Available language modules, can't
be changed from English (USA) to English (UK), particularly for the
sub-menus as shown in the said screenshot.
Which sub menus? There is no submenu there, this is "what is installed 
for the language".This is *display*

I have two queries:
(A) Could a change from English (USA) to English (UK), particularly
for the sub-menus as shown in the said screenshot be done?


Sure you can? And install the appropriate -en-gb packages. (And note for 
hyphenation patterns it's hyphen-en. Thesaurus for en_GB doesn't exist, 
neither for Grammar.)


Nowwhere anyone says any language has all of those available or 
registered. :)


(And also note that the language the text you format in also counts.)


Or do I
have to deactivate all the installed additional language pack and
install some other packages for using English(UK) rather than English
(USA)?

No.

(B) Also another essential Question:
Is there a way to have print in a text file all the packages installed
and the settings of my local Libre Office installation without using
the sub-menus under the Options tab?


You can change system defaults in /etc. I'd suggest not to if you need 
to post to a forum or ask about this here - or be sure you take updates 
of other stuff in new versions over or stuff most probably will break.


That then is the admins' (i.e. _your_ responsibility)

(Other than that the user config just contains changed values to the 
default.)



And note this is not support mailing list.


Regards,


Rene

Bug#1029534: libreoffice-common: breaks libreoffice-core from the same version

[Rene Engelhard]

Hi,

Am 23.01.23 um 23:04 schrieb Sven Joachim:

The Breaks in libreoffice-common need to be adjusted for the recent
epoch bumps.  Among others, libreoffice-common Breaks
libreoffice-core (>= 1:7.5~), making libreoffice-core 4:7.4.4-7
not installable.

Yeah, that one I noticed yesterday already.

Good luck figuring out what other relationships need to be changed, and
take your time.


Thanks :) Just doing a build and we will see... :)


Regards,


Rene

Bug#1028290: libreoffice-impress-nogui cannot convert to PNG

[Rene Engelhard]

Hi,

Am 12.01.23 um 09:29 schrieb Gábor Németh:

make[1]: *** No rule to make target
'/lo/external/tarballs/boost_1_79_0.tar.xz', needed by
'/lo/workdir/UnpackedTarget/boost_1_79_0.tar.xz'.  Stop.

Hm, so Boost is not mentioned in the deps? OK, repeat with:
Not mentioned because it's the internal copy which is downloaded 
normally, but obviously disabled here (because we don't use any internal 
lib unless really necessary)

2. Debian source build

This one also works but only with the binary in the instdir-nogui, *not*
if I install the resulting .debs:


Ah, hmm, so that really points to a packaging problem or a problem which 
only exhibitx due to packaging.


From looking at the initial straces briefly I have an idea but that 
might just be a red herring...


Regards,

Rene

Bug#1028290: libreoffice-impress-nogui cannot convert to PNG

[Rene Engelhard]

Hi,

Am 9. Januar 2023 11:02:33 MEZ schrieb "Gábor Németh" :
>For a sanity check, I compiled the upstream from tag 7.4.4.2 with only
>the `--disable-gui` flag, and it worked.

Interesting. Also could be our way to populate -nogui which is a bit Jacky 

> I suspected that maybe omitting
>one of the --with-system-... flags in the long-long autogen.sh cmdline
>as done by the l-i-nogui package's d/rules would resolve the issue, but
>I got bogged down (it is not really scalable or I have made an error
>somewhere in the middle), and didn't come any closer to solving it.

And that will not be changed anyway:
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

Did you build it with all the system libs upstream and still the upstream build 
works?

Regards

René 
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.