Bug#1081259: libreoffice:FTBFS:build failure (test failed on riscv64)

[Rene Engelhard]

Hi again,

Am 10.09.24 um 06:15 schrieb Yue Gui:

The patch is in the attachment.


That "patch" just hides everything under the carpet on riscv64.

Whereas this check exactly was added upstream in knowledge riscv64 had that 
problem.

And yes, IMHO that needs to be tested, not blacked out on the arch it was done 
for.


As I said in my other mail (which I sent from my vaction "unauthenticated" so 
gmail rejected it) I still disabled it in 24.8.x packages, but with a prominent debconf 
note, which I think is better.


Regards,


Rene

Bug#1079858: ITS: textdraw

[Rene Engelhard]

Am 28.08.24 um 19:36 schrieb Andreas Tille:

Could you please give some example for what you conaiser "quite nicely"?


Not filing a RFS in the first place (with even already importing the stuff into 
a salvage team space, referring reasons

fr salvaging which *all* do not apply in this package[1]) and no open bugs which warrant 
any "salvaging".


But asking per mail whether it could be moved to "Debian".


Regards,


Rene


[1] I don't reply to obvious stuff wher ethere's no more info needed like the 
typo fix or the FTBCFS one (however uneeded that one is inself, maybe I should 
have done)

Bug#1079858: ITS: textdraw

[Rene Engelhard]

[ greeting intentionally left out ]

Am 28.08.24 um 10:53 schrieb Andreas Tille:

I would like to salvage your package textdraw by following the Package
Salvaging procedur which is described in Developers Reference[1].  Your
package is fulfilling the following criteria for the salvage process:

   - NMUs, especially if there has been more than one NMU in a row.

lol? There was only one for already dubious reasons.

   - Bugs filed against the package do not have answers from the
 maintainer.


What should I reply to a minor typo which could be fixed anytime but does not need to be 
and a "bug" for cross-building for a package which does not need to be 
cross-built since it's one gcc call?



   - There are QA issues with the package.


For example?




I have created a repository inside the salvage-team space[2].


Remove it, please. Or at least directly put it into Debina WITHOUT EVEN MENTIONING ANY 
"salvaging" BULLS*.



Your package showed up in the Bug of the Day[3] initiative.


I don't care. At all. There's useful stuff to do. This bug is the contrary.


Rene, as a personal note since we know for a long time:  I know you are
doing great work on a lot of way more important packages.  I simply
would love to see also those tiny, low maintenance packages available on
Salsa.  Its a really great example for the newcomers that should be
attracted by the Bug of the Day initiative.  Thanks a lot for all your
other work.


A personal note: If you did ask quite nicely I 'd have agreed. It might have 
make sense.

This pure nonsensical bug is not that and therefore this is not senseful.


Rene

Bug#1077806: libreoffice-core: libreoffice (i386) crashes on startup

[Rene Engelhard]

Hi,

Am 22.08.24 um 23:01 schrieb Andres Alla:

reede, 2. august 2024 20:01:10 EEST kirjutas Rene Engelhard:

Am 02.08.24 um 17:25 schrieb Andres Alla:

[]
I suspect it may be i386 specific.

I suspect, too. Works definitely on amd64.

It may be fixed in 24.8.0 but see below.

After some detouring I stumbled on upstream commit
https://github.com/LibreOffice/core/commit/542e590
that supposedly fixes this bug.

Interesting.

I now upgraded to 4:24.8.0~rc3-2 from experimental and everything works fine
with SAL_USE_VCLPLUGIN set either kf5 or gen.
4:24.2.5-3 from unstable also worked if libreoffice-plasma installed and
SAL_USE_VCLPLUGIN set to kf5; crashed if gen.


Well, as I said I tried with "gen" in my VM, too.


I am not sure why it did not show up on amd64 because it seems to be rather
KDE- than i386-specific.

As said hee it didn't even affect a clean i386 VM.

Now that I got it working, it is back to all original Debian, without these
weird packages.
  


OK, hopefully even without dmo :)


But should we close it with 4:24.8.0~rc3-2 then?

Regards,

Rene

Bug#1079598: Right-clicking 'New Style' in inactive Writer window opens menu in active window on another monitor.

[Rene Engelhard]

forwarded 1079598 https://bugs.documentfoundation.org/show_bug.cgi?id=162620

thanks


Hi,

Am 25.08.24 um 07:18 schrieb Fabrice Quenneville:

Upstream Bug Report I had already submitted before reading 
https://www.debian.org/Bugs/Reporting#reportbug saying not to report upstream 
first :
 - https://bugs.documentfoundation.org/show_bug.cgi?id=162620


Thanks anyway, Would forward it anyway and it's better IMHO to directly report 
it upstream here and me then forward it manually and play ping-pong.

So you IHO did it correct. Marking as forwarded to your upstream bug.


Regards,


Rene

Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

[Rene Engelhard]

Hi,

Am 17.08.24 um 05:58 schrieb Aron Xu:

After some research, I prefer making a t64-like transition for libxml2
for the following reasons:
  - Upstream is not prepared to bump the SONAME to something like
libxml3. Given the long history of this function library, determining
which APIs should be public and which should be private is
challenging.
[...]
I've prepared a preliminary debdiff and tested locally. What do you think?

-   dh_makeshlibs -plibxml2 -V 'libxml2 (>= 2.9.11)' -- -c4
+   dh_makeshlibs -plibxml2n -V 'libxml2 (>= 2.9.11)' -- -c4

Look wrong to me, should be libxml2 in the version, too.


--- libxml2-2.13.3+dfsg/debian/libxml2n.symbols 1970-01-01 08:00:00.0 
+0800
+++ libxml2-2.13.3+dfsg/debian/libxml2n.symbols 2024-08-16 22:13:37.0 
+0800
@@ -0,0 +1,146 @@
+libxml2.so.2 libxml2 #MINVER#
[...]

here, too.


Otherwise stuff built against the NEW ABI still gets dependencies fullfillable 
by old ones.


For the same reason

+Provides: libxml2 (= ${binary:Version})

is bad, that is the other way round and stuff using the old ABI will happily 
install with libxml2n.

(That Provides: was there in t64 where the ABI didn't change, aka all 64bit + 
i386)


And I *think* you need Breaks/Conflicts in addition to Replaces at the new 
libxml2n.


Regards,


Rene

Bug#1078568: RM: libreoffice-sdbc-hsqldb [armel] -- NBS; Java disabled

[Rene Engelhard]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libreoff...@packages.debian.org, r...@debian.org
Control: affects -1 + src:libreoffice

Hi,

please remove libreoffice-sdbc-hsqldb from unstable on armel, it is disabled 
since
4:24.2.5-2.

dak rm -a armel -R -s unstable -o libreoffice -n (without -n for you of
course) does what it should do:

$ dak rm -a armel -R -s unstable -o libreoffice -n
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libofficebean-java | 4:24.2.5-1 | armel
libreoffice | 4:24.2.5-1 | source
libreoffice-report-builder-bin | 4:24.2.5-1 | armel
libreoffice-sdbc-hsqldb | 4:24.2.5-1 | armel
  ure-java | 4:24.2.5-1 | armel

Regards,

Rene

Bug#1078569: RM: ure-java [armel] -- NBS; Java disabled

[Rene Engelhard]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libreoff...@packages.debian.org, r...@debian.org
Control: affects -1 + src:libreoffice

Hi,

please remove ure-java from unstable on armel, it is disabled since 
4:24.2.5-2.

dak rm -a armel -R -s unstable -o libreoffice -n (without -n for you of
course) does what it should do:

$ dak rm -a armel -R -s unstable -o libreoffice -n
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libofficebean-java | 4:24.2.5-1 | armel
libreoffice | 4:24.2.5-1 | source
libreoffice-report-builder-bin | 4:24.2.5-1 | armel
libreoffice-sdbc-hsqldb | 4:24.2.5-1 | armel
  ure-java | 4:24.2.5-1 | armel

Regards,

Rene

Bug#1078567: RM: libreoffice-report-builder-bin [armel] -- NBS; Java disabled

[Rene Engelhard]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libreoff...@packages.debian.org, r...@debian.org
Control: affects -1 + src:libreoffice

Hi,

please remove libreoffice-report-builder-bin from unstable on armel, it is 
disabled since 
4:24.2.5-2.

dak rm -a armel -R -s unstable -o libreoffice -n (without -n for you of
course) does what it should do:

$ dak rm -a armel -R -s unstable -o libreoffice -n
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libofficebean-java | 4:24.2.5-1 | armel
libreoffice | 4:24.2.5-1 | source
libreoffice-report-builder-bin | 4:24.2.5-1 | armel
libreoffice-sdbc-hsqldb | 4:24.2.5-1 | armel
  ure-java | 4:24.2.5-1 | armel

Regards,

Rene

Bug#1078566: RM: libofficebean-java [armel] -- NBS; Java disabled

[Rene Engelhard]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libreoff...@packages.debian.org, r...@debian.org
Control: affects -1 + src:libreoffice

Hi,

please remove libofficebean-java from unstable on armel, it is disabled since   
 
4:24.2.5-2.

dak rm -a armel -R -s unstable -o libreoffice -n (without -n for you of
course) does what it should do:

$ dak rm -a armel -R -s unstable -o libreoffice -n
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libofficebean-java | 4:24.2.5-1 | armel
libreoffice | 4:24.2.5-1 | source
libreoffice-report-builder-bin | 4:24.2.5-1 | armel
libreoffice-sdbc-hsqldb | 4:24.2.5-1 | armel
  ure-java | 4:24.2.5-1 | armel

Regards,

Rene

Bug#1078537: unblock: libreoffice/4:24.2.5-3

[Rene Engelhard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Deiban Korean L10N , Debian 
Accessibility Team 
Control: affects -1 + src:libreoffice

Hi,

Please hint package libreoffice in (unblock is strictly speaking wrong
here, but...)

This is blocked by autopkgtests:

∙ ∙ autopkgtest for h2orestart/0.6.6-1: amd64: Pass, arm64: Pass, armel: 
Regression or new test ♻ (reference ♻), armhf: Failed (not a regression), i386: 
Pass, ppc64el: Failed (not a regression)
∙ ∙ autopkgtest for libreoffice/4:24.2.5-3: amd64: Pass, arm64: Pass, 
armel: Test in progress (will not be considered a regression), armhf: Test in 
progress, i386: Test in progress (will not be considered a regression), 
ppc64el: Test in progress (will not be considered a regression)
∙ ∙ autopkgtest for natbraille/2.0rc3-15: amd64: No tests, superficial or 
marked flaky ♻ (reference ♻), arm64: No tests, superficial or marked flaky ♻ 
(reference ♻), armel: Regression or new test ♻ (reference ♻), armhf: Failed 
(not a regression), i386: No tests, superficial or marked flaky ♻ (reference 
♻), ppc64el: Failed (not a regression)

(cf. https://qa.debian.org/excuses.php?package=libreoffice)

-2 and -3 fix two (unreported) FTBFS with gcc 14 (-2) and openjdk-21 (I
assume) as default (-3). Whereas the openjdk 21 is a testsuite failure
("exception occurred: Could not create Java implementation loader at
./stoc/source/javaloader/javaloader.cxx:551") and thus I simply disabled
Java there too.

This is for armel only. And s390x, ppc64el, armhf has it already so now
armel also is consistent with armhf.

The autopkgtests of h2orestart and natbraille (Both arch: all) is there
since Java support in armel is gone now (as said as before for armhf
etc) and this was hinted in alreday for those.

I hope I got the syntax right, no idea whether that is correct for tests
in other packages affected by libreoffice. Adapt as needed, please :)

force-badtest libreoffice/4:24.2.5-3/armel

Regards,

Rene

Bug#1077806: libreoffice-core: libreoffice (i386) crashes on startup

[Rene Engelhard]

tag 1077806 + unreproducible

tag 1077806 + moreinfo

thanks


Hi,

Am 02.08.24 um 17:25 schrieb Andres Alla:

Package: libreoffice-core
Version: 4:24.2.5-1
Severity: important

Dear Maintainer,

libreoffice (i386) crashes on startup (backtrace attached).

Splash is shown and then nothing, application window does not show up. It is
the same in safe-mode.

I suspect it may be i386 specific.

I suspect, too. Works definitely on amd64.

System is Debian unstable, mix of i386 and amd64; i386 is primary
architecture, most of X desktop applications are i386, as is libreoffice.


*sigh*. Why are you using libreoffice for i386 then? And why people do think 
this mix makes sense in any wy?

(Yes, I know there is multiarch and I always didn't care because it always 
didn't make sense.)


4:7.4.7-1+deb12u3 from stable works somewhat, writer at least, calc crashes
because of some libxml discrepancy.

What exactly? That sounds like the (broken) libxml2 in unstable also needs an 
other conflict...

Installing amd64 version in that kind of mixed environment is not trivial
(aptitude could not find workable solution) but I did it through some abuse of
dpkg (+f1 packages in the list below, just added Multi-Arch: foreign to
control and repacked). Works just fine.

Then just don't mix it and use amd64?

List of packages below that reportbug generated corresponds to currently
installed and working amd64 version but is essentially same for i386.


This is not helpful. Post what you use, not what you think you use. If you 
can't, use a sane evironment.



Attached backtrace (of crashing i386 version) looks rather sparse to me, gdb
supposedly loaded symbols through debuginfod. Happy to debug further but would
need some guidance on where to look.


-- Andres Alla


-- 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)
un  libreoffice-qt5(no description available)

-- System Information:
Debian Release: trixie/sid
   APT prefers unstable
   APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64, armel

even armel there?

Kernel: Linux 6.9.10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.15.0-1.1
ii  fonts-opensymbol4:102.12+LibO24.2.5-1
ii  libabsl20230802 20230802.1-4
ii  libargon2-1 0~20190702+dfsg-4+b1
ii  libboost-locale1.83.0   1.83.0-3+b2
ii  libc6   2.39-6
ii  libcairo2   1.18.0-3+b1
ii  libclucene-contribs1t64 2.3.3.4+dfsg-1.2
ii  libclucene-core1t64 2.3.3.4+dfsg-1.2
ii  libcmis-0.6-6t640.6.2-2.1+b1
ii  libcups2t64 2.4.10-1
ii  libcurl4t64 8.9.0-3
ii  libdbus-1-3 1.14.10-4+b1
ii  libdconf1   0.40.0-4+b2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.10-1+b2
ii  libexpat1   2.6.2-1
ii  libexttextcat-2.0-0 3.4.7-1
ii  libfontconfig1  2.15.0-1.1
ii  libfreetype62.13.2+dfsg-1+b4
ii  libgcc-s1   14.1.0-5
ii  libglib2.0-0t64 2.80.4-1
ii  libgpgmepp6t64  1.18.0-4.1+b2
ii  libgraphite2-3  1.3.14-2
ii  libgstreamer-plugins-base1.0-0  1.24.6-dmo1
ii  libgstreamer1.0-0   1.24.6-1
ii  libharfbuzz-icu08.3.0-2+b1
ii  libharfbuzz0b   8.3.0-2+b1
ii  libhunspell-1.7-0   1.7.2+really1.7.2-10+b2
ii  libhyphen0  2.8.8-7+b1
ii  libice6 2:1.0.10-1+b1
ii  libicu7272.1-5
ii  libjpeg62-turbo 1:2.1.5-3
ii  liblcms2-2  2.14-2+b1
ii  libldap-2.5-0   2.5.18+dfsg-2
ii  libmythes-1.2-0 2:1.2.5-1+b1
ii  libnspr42:4.35-1.1+b1
ii  libnss3 2:3.102-1
ii  libnumbertext-1.0-0 1.0.11-4+b1
ii  libopenjp2-72.5.0-2+b3
ii  liborcus-0.18-0 0.19.2-3+b3
ii  liborcus-parser

Bug#1077268: hunspell LIBDIR, USEROOODIR and OOO are either obsolete or wrong

[Rene Engelhard]

Hi,

Am 27.07.24 um 17:52 schrieb Jiri Belka:

`hunspell -D' shows either MacOS, obsolete or incorrect paths:

Mac OS and obsolete ones, yes.

---%>---
$ hunspell -D
SEARCH PATH:
.::/usr/share/hunspell:/usr/share/myspell:

That is where the (system) dicts are

/usr/share/myspell/dicts:/Library/Spelling:/home/jiri/.openoffice.org/3/user/wordbook:/home/jiri/.openoffice.org2/user/wordbook:/home/jiri/.openoffice.org2.0/user/wordbook:/home/jiri/Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
/usr/share/hunspell/en_US
/usr/share/hunspell/cs_CZ
/usr/share/hunspell/cs
/usr/share/hunspell/it_IT
/usr/share/hunspell/it_CH
/usr/share/myspell/dicts/cs
/usr/share/myspell/dicts/cs_CZ
LOADED DICTIONARY:
/usr/share/hunspell/en_US.aff
/usr/share/hunspell/en_US.dic
---%<---


As seen here.



For example, hunspell in OpenBSD ports patches that in the following way:

---%>---
Index: src/tools/hunspell.cxx
--- src/tools/hunspell.cxx.orig
+++ src/tools/hunspell.cxx
@@ -116,28 +116,14 @@
  #include "../parsers/odfparser.hxx"

  #define LIBDIR\
-  "/usr/share/hunspell:"  \
-  "/usr/share/myspell:"   \
-  "/usr/share/myspell/dicts:" \
-  "/Library/Spelling"
+  "${PREFIX}/share/hunspell:" \
+  "${LOCALBASE}/share/myspell:" \
+  "${LOCALBASE}/share/myspell/dicts:" \
+  "${LOCALBASE}/share/mozilla-dicts"
  #define USEROOODIR {  \
-  ".openoffice.org/3/user/wordbook", \
-  ".openoffice.org2/user/wordbook",  \
-  ".openoffice.org2.0/user/wordbook",\
-  "Library/Spelling" }
+  ".config/libreoffice/4/user/wordbook" }
  #define OOODIR   \
-  "/opt/openoffice.org/basis3.0/share/dict/ooo:" \
-  "/usr/lib/openoffice.org/basis3.0/share/dict/ooo:" \
-  "/opt/openoffice.org2.4/share/dict/ooo:"   \
-  "/usr/lib/openoffice.org2.4/share/dict/ooo:"   \
-  "/opt/openoffice.org2.3/share/dict/ooo:"   \
-  "/usr/lib/openoffice.org2.3/share/dict/ooo:"   \
-  "/opt/openoffice.org2.2/share/dict/ooo:"   \
-  "/usr/lib/openoffice.org2.2/share/dict/ooo:"   \
-  "/opt/openoffice.org2.1/share/dict/ooo:"   \
-  "/usr/lib/openoffice.org2.1/share/dict/ooo:"   \
-  "/opt/openoffice.org2.0/share/dict/ooo:"   \
-  "/usr/lib/openoffice.org2.0/share/dict/ooo"
+  "${LOCALBASE}/lib/libreoffice/share/wordbook"
  #define HOME getenv("HOME")
  #define DICBASENAME ".hunspell_"
  #define LOGFILE "/tmp/hunspell.log"
---%<---


Why except solely for cosmetic?


* What led up to the situation?

I was checking how hunspell might work with LO dictionaries.

LO dictionaries *ARE* hunspell directories. LO looks in /usr/share/hunspell

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

Next, I checked if `hunspell' is able to read my LO dict, but it wasn't.

It does.  What exactly doesn't work? Still assuming system dicts. (If you mean 
user dicts like below, you need  to state that from the beginning.)

* What was the outcome of this action?

hunspell returns "bad (rejected) work - with '&', that is, with suggestion -
for a work
which is correct and present in my dictionary; an example:

---%>---
$ hunspell -d cs_CZ <<< "autobusáků"
Hunspell 1.7.2
& autobusáků 1 0: autobusů
---%<---

* What outcome did you expect instead?

I expected the previous command would return '*' as the word is present it my
LO user dict:

---%>---
$ grep -n 'autobusáků' ~/.config/libreoffice/4/user/wordbook/standard.dic
114:autobusáků
---%<---

The workaround is to use `-p
~/.config/libreoffice/4/user/wordbook/standard.dic', but I would
expect `hunspell' would use such a path automatically - see OpenBSD hunspell
diff.

---%>---
hunspell -d cs_CZ -p ~/.config/libreoffice/4/user/wordbook/standard.dic <<<
"autobusáků"
error - iconv: ISO8859-2 -> UTF-8
Hunspell 1.7.2
*
---%<---


Ah, you are talking about user dicts..


That might make sense, and then also the OpenBSD patch would make sensein part 
(one could just add the libreoffice dir)...


Regards,


Rene

Bug#1077190: Accepted curl 8.9.0-2 (source) into unstable

[Rene Engelhard]

Hi again,

Am 27.07.24 um 08:07 schrieb Rene Engelhard:

Am 27.07.24 um 08:00 schrieb Rene Engelhard:

b) even more, pbuilder disables the install of recommends. That means builds 
inside pbuilder still will fail.


This doesn't even work in sbuild (and thus  the buildds). After I gave back 
libreoffice I got

https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=all&ver=4%3A24.8.0%7Erc2-1&stamp=1722060303&raw=0


Nevermind, I noticed that one actually still took -1 even though said curl was 
already Installed and thus it should have taken it from incoming.
Ah, well.

But e.g.
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A24.8.0%7Erc2-1&stamp=1722060618&raw=0

also shows that with

Get:33 https://incoming.debian.org/debian-buildd buildd-unstable/main armhf 
libcurl4-openssl-dev armhf 8.9.0-2 [533 kB]

etc

it dosn't work.

Regards,

Rene

Bug#1077190: Accepted curl 8.9.0-2 (source) into unstable

[Rene Engelhard]

Hi,

Am 27.07.24 um 08:00 schrieb Rene Engelhard:

b) even more, pbuilder disables the install of recommends. That means builds 
inside pbuilder still will fail.


This doesn't even work in sbuild (and thus  the buildds). After I gave back 
libreoffice I got

https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=all&ver=4%3A24.8.0%7Erc2-1&stamp=1722060303&raw=0

so exactly the same as before.

Regards,
  
Rene
 

Bug#1077190: Accepted curl 8.9.0-2 (source) into unstable

[Rene Engelhard]

Hi,

Am 27.07.24 um 08:00 schrieb Rene Engelhard:

a) Is this needed for anything using liburls .pc. A pure --cflags now needs 
those.

Even when not doing static linking. Recommends here is wrong.

This needs to be a Depends.

b) even more, pbuilder disables the install of recommends. That means builds 
inside pbuilder still will fail.

[...]

c) And even when recommends would work, it allowed removal of the mentioned 
libs, also causing breakage (like in big
   transitions), breaking pkg-config --cflags again.


Regards,
 
Rene

Bug#1077190: Accepted curl 8.9.0-2 (source) into unstable

[Rene Engelhard]

reopen 1077197

reopen 1077190

thanks


Hi,


Am 27.07.24 um 06:34 schrieb Debian FTP Masters:

   * debian/control: make libcurl*-dev packages Recommends -dev packages.
 (Closes: #1077197, #1077190)


This is not  going to work.


a) Is this needed for anything using liburls .pc. A pure --cflags now needs 
those.

Even when not doing static linking. Recommends here is wrong.

This needs to be a Depends.

b) even more, pbuilder disables the install of recommends. That means builds 
inside pbuilder still will fail.

$ sudo pbuilder login --basetgz /var/cache/pbuilder/base.testing.armhf.tgz
[sudo] Passwort für rene:
W: /root/.pbuilderrc does not exist
W: cgroups are not available on the host, not using them.
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/base.testing.armhf.tgz]
I: copying local configuration
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: mounting /dev/pts/4 over /dev/console
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: entering the shell
I: File extracted to: /var/cache/pbuilder/build/2896014
root@rpi4:/# cat /etc/apt/
apt.conf.d/ keyrings/   sources.list    trusted.gpg.d/
auth.conf.d/    preferences.d/  sources.list.d/
root@rpi4:/# cat /etc/apt/apt.conf.d/
01autoremove  15pbuilder    70debconf
root@rpi4:/# cat /etc/apt/apt.conf.d/
01autoremove  15pbuilder    70debconf
root@rpi4:/# cat /etc/apt/apt.conf.d/15pbuilder
APT::Install-Recommends "false";



APT::AutoRemove::SuggestsImportant false;
APT::AutoRemove::RecommendsImportant false;
Acquire::Languages none;
root@rpi4:/#

Regards,


Rene

Bug#1077190: breaks build of uncounted packages

[Rene Engelhard]

severity 1077190 serious
thanks

Now really...

Am 26.07.24 um 18:04 schrieb Rene Engelhard:

Hi,

this bug means that uncounted packages (anything directly or indirectly using 
libcurl via pkg-config) now FTBFS in unstable.

Raising the severity ti serious

Regards,

Rene

Bug#1077190: breaks build of uncounted packages

[Rene Engelhard]

Hi,

this bug means that uncounted packages (anything directly or indirectly using 
libcurl via pkg-config) now FTBFS in unstable.

Raising the severity ti serious

Regards,

Rene

Bug#1076720: "Insert symbol" and libreoffice-gtk3

[Rene Engelhard]

retitle 1076720 "Insert symbol" in tabbed ui doesn't appear with 
libreoffice-gtk3


thanks


Hi,

Am 22.07.24 um 22:05 schrieb Stefano:
See attachment for the steps to reproduce on it_IT.UTF-8 locale. I am 
unsure what more information to offer 


I see.

That is not standard UI but the ribbon stuff they unfortunately added 
("Tabbed" / "A schede")...


I usually don't even try anything there, so people should mention  they 
use that. I use standard, "normal" UI :)


as this used to happen consistently on my setup before the upgrade to 
backport, just by clicking on the elements circled in the screenshot.


Even there I do get a "drop down" with symbols  there. Yes, stable with 
it_IT even.



So still unreproducible. In GNOME with gtk3.


But anyway, as it's fixed in newer versions...


Sorry for not making myself clearer earlier. The expected behavior is 
a new window opening up to select symbols(/special characters?). The 
actual behavior is nothing happening.


The expected behaviour is a "drop down" here, not a new window.


Regards,


Rene

Bug#1076720: "Insert symbol" and libreoffice-gtk3

[Rene Engelhard]

[ please don't uselessly mail stuff you don't need to CC. Especially 
submit@ and -done and control ]



Hi,

Am 22.07.24 um 20:09 schrieb Stefano:

The tab and button actually read "Inserisci" and "Simbolo", respectively.


Which tab and button?


*I* mean the menu, did you mean something else?


(I don't see Inserisci in the navigator bar either, in neither of the 
choices/icons etc.


In any case: *You* need to tell people how to reproduce.)

Special Character in the "Insert" toolbar also just works.


Regards,


Rene

Bug#1076720: "Insert symbol" and libreoffice-gtk3

[Rene Engelhard]

Hi,

Am 22.07.24 um 19:51 schrieb Stefano:



Which one? Maybe it's even locale-specific?
(tried de_DE and en_US here.)


it_IT


Hmm.


Inseirici -> Cattatere speciale...

also works here in it_IT.UTF-8 locale.


Regards,


Rene

Bug#1076720: "Insert symbol" and libreoffice-gtk3

[Rene Engelhard]

tag 1076720 + moreinfo

tag 1076720 + unreproducible

thanks


Hi,


Am 22.07.24 um 15:33 schrieb Stefano Volpe:

Package: libreoffice-gtk3
Version: 4:7.4.7-1+deb12u3

When libreoffice-gtk3 is not installed, the "Insert -> Symbols" menu of
LibreOffice Writer (4:7.4.7-1+deb12u3) can be opened correctly. When


There's none like this afaics. Did you man Insert -> Special Characters?


libreoffice-gtk3 is installed, such menu does not open, but no error in printed
on the terminal either.


Does here.


I am on Debian 6.1.99-1 (2024-07-15) i686 GNU/Linux. C library version is
2.36-9+deb12u7.


amd64 though (as it should be).


In any case, even if it was a bug, stable doesn't get any bugfixes 
except really important ones. Can you try whether a current 24.2 (as 
available in backports) works?



Regards,


Rene

Bug#1076014: RM: python-ooolib -- RoQA; explicitly unmaintained; RC-buggy

[Rene Engelhard]

Hi,

Am 09.07.24 um 17:04 schrieb Bastian Germann:

Please remove python-ooolib from unstable. It did not make it to bookworm 
because RC fixes
were actively removed by the only active uploader, who commented on the two RC 
bugs:
"How is it unclear that noone seriously cares about this package?
Old upstream version, popcon 4, ignored by the maintainer."

So please remove the package.


For avoidance of doubt: ACK.


Regards,


Rene

Bug#1059158: fixed in 4:7.4.7-1+deb12u3, too

[Rene Engelhard]

# mark bugs fixed in  4:7.4.7-1+deb12u3 correctly, didn't get done
# because they were already archived
unarchive 1059158
fixed 1059158 4:7.4.7-1+deb12u3
unarchive 1069835
fixed 1069835 4:7.4.7-1+deb12u3

Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3

[Rene Engelhard]

Hi again,

Am 17.06.24 um 20:29 schrieb Rene Engelhard:

Apologies if I'm missing something, but

+    - recommend kio >> 5.103.0-1 in -kf5

makes the package uninstallable on a default bookworm setup (i.e.
Recommends are installed by APT).

apt TTBOMK doesn't complain if a Recommends isn't fullfillable. I
also asked on #debian-devel about that because I wasn't sure either.

AFAICR I did this in sid before the matching sid Recommendation was
in place and no complaints from apt.

(Except telling me that "kio" is Recommended)

As per our IRC conversation, I'm still very surprised by this.


Looks like stable behaves different and/or I implicitely did 
dist-upgrade on sid anyway because of other stuff, too



Just tried:

[...]

For the record on IRC:

0:33 < adsb> and whether tools tend to do just upgrades or d-u (e.g 
unattended-upgrades, but also others)
20:33 < _rene_> the ideal way(tm) would just be to make kio do their 
stuff...
20:35 < _rene_> but if it helps I can back out the recommends. but that 
probably will make the actual bug in -kf5 still cause havoc

20:36 < _rene_> s/bug in -kf5/bug in kio still cause havoc with -kf5/
20:43 < _rene_> can't get unattended-upgrades to upgrade from my local 
(non-signed, non-Release, etc) apt repo to try that one

20:46 < adsb> ah
20:46 < _rene_> ah, there. orgin=*
20:46 < _rene_> Option --dry-run given, *not* performing real actions
20:46 < _rene_> Packages that will be upgraded: fonts-opensymbol 
libreoffice-base-core libreoffice-calc libreoffice-common 
libreoffice-core libreoffice-draw libreoffice-gnome libreoffice-gtk3 
libreoffice-help-common libreoffice-help-de libreoffice-help-en-us
libreoffice-impress libreoffice-kf5 libreoffice-l10n-de 
libreoffice-math libreoffice-plasma libreoffice-qt5 
libreoffice-style-breeze libreoffice-style-colibre
20:46 < _rene_> libreoffice-style-elementary libreoffice-writer 
libuno-cppu3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 
libuno-sal3 libuno-salhelpergcc3-3 python3-uno uno-libs-private ure

20:46 < _rene_> s/orgin/origin/
20:46 < adsb> promising
20:46 < _rene_> unatteded-upgrades seems to wrk
20:46 < _rene_> work
20:46 < adsb> I guess we can try it and see what qa tooling does
20:47 < _rene_> so I should upload and we can back out the recommends 
"in emergency"?

20:47 < adsb> sure
20:47 < _rene_> k
20:47 < adsb> neither way is great, as you say
20:48 < adsb> without the other half of the fix
20:48 < _rene_> didn't want to upload prematurely, even with your 
"half-ACK" in the bug :)

20:48 < _rene_> better safe than sorry :)
20:49 < adsb> coucouf: were you planning on submitting a p-u request for 
kio 5.103.0-1+deb12u1?

20:49 < _rene_> they wanted andi to do that
20:50 < _rene_> (fwiw, without --dry-run it actually upgrades all that)
20:50 < _rene_> all  that in a clean stable VM
20:50 < adsb> I don't really mind who requests it :)
20:50  * _rene_ neither :)
20:51 < _rene_>   Uploading libreoffice_7.4.7-1+deb12u3_source.changes: 
done.

20:51 < _rene_> Successfully uploaded packages.

Regards,

Rene

Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3

[Rene Engelhard]

Hi,

Am 17.06.24 um 19:05 schrieb Adam D. Barratt:

Control: tags -1 -moreinfo +confirmed

On Sat, 2024-06-15 at 17:44 +0200, Rene Engelhard wrote:

Hi,

Am 15.06.24 um 17:28 schrieb Adam D. Barratt:

Control: tags -1 + moreinfo

On Sat, 2024-05-25 at 10:35 +0200, Rene Engelhard wrote:

I'd like to fix 2 libreoffice bugs in stable. Most important is
the SMB fix (which - for kf5 - also needs a kio stable update,
but
those
can be done in parallel or kio later as there's no updated
(build)-dependency needed. Merely I added a Recommends: for
documentation purposes.

Apologies if I'm missing something, but

+    - recommend kio >> 5.103.0-1 in -kf5

makes the package uninstallable on a default bookworm setup (i.e.
Recommends are installed by APT).

apt TTBOMK doesn't complain if a Recommends isn't fullfillable. I
also asked on #debian-devel about that because I wasn't sure either.

AFAICR I did this in sid before the matching sid Recommendation was
in place and no complaints from apt.

(Except telling me that "kio" is Recommended)

As per our IRC conversation, I'm still very surprised by this.


Looks like stable behaves different and/or I implicitely did 
dist-upgrade on sid anyway because of other stuff, too



Just tried:


root@debian12:~# dpkg -l libreoffice-kf5
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
+++-===-=--=
ii  libreoffice-kf5 4:7.4.7-1+deb12u2 amd64    office productivity 
suite -- KDE Frameworks 5 integration


root@debian12:~# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer 
required:

  libwpe-1.0-1 libwpebackend-fdo-1.0-1
Use 'apt autoremove' to remove them.
The following packages have been kept back:
  libreoffice-base-core libreoffice-calc libreoffice-core 
libreoffice-draw libreoffice-gnome libreoffice-gtk3 libreoffice-impress 
libreoffice-kf5
  libreoffice-math libreoffice-plasma libreoffice-qt5 
libreoffice-writer python3-uno

The following packages will be upgraded:
  fonts-opensymbol libreoffice-common libreoffice-help-common 
libreoffice-help-de libreoffice-help-en-us libreoffice-l10n-de 
libreoffice-style-breeze
  libreoffice-style-colibre libreoffice-style-elementary libuno-cppu3 
libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 
libuno-salhelpergcc3-3

  uno-libs-private ure
16 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
Need to get 54.8 MB of archives.
After this operation, 9216 B disk space will be freed.
Do you want to continue? [Y/n] ^C
root@debian12:~# apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer 
required:

  libwpe-1.0-1 libwpebackend-fdo-1.0-1
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
  fonts-opensymbol libreoffice-base-core libreoffice-calc 
libreoffice-common libreoffice-core libreoffice-draw libreoffice-gnome 
libreoffice-gtk3
  libreoffice-help-common libreoffice-help-de libreoffice-help-en-us 
libreoffice-impress libreoffice-kf5 libreoffice-l10n-de libreoffice-math
  libreoffice-plasma libreoffice-qt5 libreoffice-style-breeze 
libreoffice-style-colibre libreoffice-style-elementary 
libreoffice-writer libuno-cppu3
  libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 
libuno-salhelpergcc3-3 python3-uno uno-libs-private ure

29 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 110 MB of archives.
After this operation, 50.2 kB of additional disk space will be used.
Do you want to continue? [Y/n] ^C
root@debian12:~# apt install libreoffice-kf5
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer 
required:

  libwpe-1.0-1 libwpebackend-fdo-1.0-1
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  fonts-opensymbol libreoffice-base-core libreoffice-calc 
libreoffice-common libreoffice-core libreoffice-draw libreoffice-gnome 
libreoffice-gtk3
  libreoffice-help-common libreoffice-help-de libreoffice-help-en-us 
libreoffice-impress libreoffice-l10n-de libreoffice-math libreoffice-plasma
  libreoffice-qt5 libreoffice-style-breeze libreoffice-style-colibre 
libreoffice-style-elementary libreoffice-writer libuno-cppu3 
libuno-cppuhelpergcc3-3
  libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3 
python3-uno u

Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3

[Rene Engelhard]

Hi,

Am 15.06.24 um 17:28 schrieb Adam D. Barratt:

Control: tags -1 + moreinfo

On Sat, 2024-05-25 at 10:35 +0200, Rene Engelhard wrote:

I'd like to fix 2 libreoffice bugs in stable. Most important is
the SMB fix (which - for kf5 - also needs a kio stable update, but
those
can be done in parallel or kio later as there's no updated
(build)-dependency needed. Merely I added a Recommends: for
documentation purposes.

Apologies if I'm missing something, but

+- recommend kio >> 5.103.0-1 in -kf5

makes the package uninstallable on a default bookworm setup (i.e.
Recommends are installed by APT).


apt TTBOMK doesn't complain if a Recommends isn't fullfillable. I also 
asked on #debian-devel about that because I wasn't sure either.



AFAICR I did this in sid before the matching sid Recommendation was in 
place and no complaints from apt.


(Except telling me that "kio" is Recommended)


But I can back that out, that's for documentation only anyways.


Regards,


Ren

Bug#1071834: same with zlib

[Rene Engelhard]

Hi,

same with zlib:

Package 'zlib', required by 'libxml-2.0', not found

(from https://ci.debian.net/packages/i/igraph/testing/amd64/47001876/)

Regards,

Rene

Bug#1071834: libxml2-dev: missing Depends on liblzma-dev (used by pkg-config file)

[Rene Engelhard]

Hi,

Am 25.05.24 um 14:00 schrieb Rene Engelhard:

root@frodo:/# pkg-config --cflags libxml-2.0
Package liblzma was not found in the pkg-config search path.
Perhaps you should add the directory containing `liblzma.pc'
to the PKG_CONFIG_PATH environment variable
Package 'liblzma', required by 'libxml-2.0', not found


This is the reason for some/many autopkgtest failures at
https://qa.debian.org/excuses.php?package=libxml2 and also means that 
any package using libxml2-dev without build-depending on anything else 
pulling it liblzma-dev by chance now FTBFS in unstable...


Regards,

Rene

Bug#1071834: libxml2-dev: missing Depends on liblzma-dev (used by pkg-config file)

[Rene Engelhard]

Package: libxml2-dev
Severity: serious
Version: 2.12.7+dfsg-1

root@frodo:/# dpkg -l | grep lzma
ii  liblzma5:amd64  5.6.1+really5.4.5-1 
  amd64XZ-format compression library

root@frodo:/# pkg-config --cflags libxml-2.0
Package liblzma was not found in the pkg-config search path.
Perhaps you should add the directory containing `liblzma.pc'
to the PKG_CONFIG_PATH environment variable
Package 'liblzma', required by 'libxml-2.0', not found

root@frodo:/# apt install liblzma-dev
[...]

Installing:
  liblzma-dev

Suggested packages:
  liblzma-doc

Summary:
  Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 0
  Download size: 293 kB
  Space needed: 803 kB / 4844 MB available

Get:1 http://deb.debian.org/debian unstable/main amd64 liblzma-dev amd64 
5.6.1+really5.4.5-1 [293 kB]

Fetched 293 kB in 0s (1580 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
debconf: delaying package configuration, since apt-utils is not installed
Error: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No 
such device)

Selecting previously unselected package liblzma-dev:amd64.
(Reading database ... 107997 files and directories currently installed.)
Preparing to unpack .../liblzma-dev_5.6.1+really5.4.5-1_amd64.deb ...
Unpacking liblzma-dev:amd64 (5.6.1+really5.4.5-1) ...
Setting up liblzma-dev:amd64 (5.6.1+really5.4.5-1) ...
root@frodo:/# pkg-config --cflags libxml-2.0
-I/usr/include/libxml2

If libxml-2.0.pc references liblzma, libxml2-dev needs to Depend on it.

Regards,

Rene

Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3

[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, k...@packages.debian.org
Control: affects -1 + src:libreoffice

Hi,

I'd like to fix 2 libreoffice bugs in stable. Most important is
the SMB fix (which - for kf5 - also needs a kio stable update, but those
can be done in parallel or kio later as there's no updated
(build)-dependency needed. Merely I added a Recommends: for
documentation purposes.

[ Reason ]
a) #1059158
   If using python3-uno, loadComponentFromURL apparently needs the
   internal libforuilo.so ("formula ui") library to actually open it
   since it tried to open that one.
   Unfortunately this file if left out in the -nogui packages because it
   is*ui.so. (In 32bit packages that is; in 64bit LO due to
   --enable-mergelibs this is already in a bigger library called
   libmergedlo.so)
b) 1069835
   We shouldn't leave people having documents on SMB shares loose their
   files :-)

[ Impact ]
a) opening calc files via python3-uno remaining broken
b) possible file loss for files on SMB shares

[ Tests ]
No test coverage. But a) is pretty straightforward abd b) was confirmed 
that it

fixes it by the submitter.

[ Risks ]
a) would be better fixed by upstream not requiring that but the bug I
filed upstream (https://bugs.documentfoundation.org/show_bug.cgi?id=158795)
didn't really get any serious attention.
b) more SMB surprises can be possible, though I have not seen any since
this is in unstable since 24.2.2 is there.
(And that exact patch caused a 32bit FTBFS which I backported the fix of 
which went into 24.2.2~rc1-2 packages and is upstream since 24.2.2 rc2 
anyways, too.)


[ 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 ]
a) see above. It it just excluded from the find which removes *.ui.so.
b) patches from upstream applied verbatim (from 24.2.2)

[ Other info ]
kio needs one update, too for complete fix of 1069835 in 
libreoffice-kf5. I see 
https://salsa.debian.org/qt-kde-team/kde/kio/-/commi 
t/082a2b7e9208a9d0a552049aafd898960fc15998

(debian/patches/fix_cifs_file_locks.patch).
According to 
https://salsa.debian.org/qt-kde-team/kde/kio/-/commit/9db715803c0c87298dbf70644b98a95bb984322c

this was already supposed to be "released to bookworm" but I don't see a
release.debian.org bug nor the package in p-u either.

Debdiff attached.

Regards,

Renediff -Nru libreoffice-7.4.7/debian/changelog libreoffice-7.4.7/debian/changelog
--- libreoffice-7.4.7/debian/changelog	2024-04-01 11:05:27.0 +0200
+++ libreoffice-7.4.7/debian/changelog	2024-05-24 21:06:45.0 +0200
@@ -1,3 +1,18 @@
+libreoffice (4:7.4.7-1+deb12u3) bookworm; urgency=medium
+
+  * debian/patches/Fix-backup-copy-creation-for-files-on-mounted-samba-shares.diff:
+as name says, from 24.2.2+ (closes: #1069835)
+  * debian/patches/fix-32bit-build.diff: as name says; fix 32bit build with
+above
+
+  * debian/rules:
+- don't remove libforuilo.so in -core-nogui. (closes: #1059158)
+  It's subsumed in libmerged on 64bit archs anyway which we definitely
+  need to keep anyway (similar as libuuilo.so).
+- recommend kio >> 5.103.0-1 in -kf5
+
+ -- Rene Engelhard   Fri, 24 May 2024 21:06:45 +0200
+
 libreoffice (4:7.4.7-1+deb12u2) bookworm-security; urgency=high
 
   * debian/patches/add-notify-for-script-use.diff: add fix for
diff -Nru libreoffice-7.4.7/debian/control libreoffice-7.4.7/debian/control
--- libreoffice-7.4.7/debian/control	2024-04-01 11:05:27.0 +0200
+++ libreoffice-7.4.7/debian/control	2024-05-22 18:16:51.0 +0200
@@ -5028,7 +5028,7 @@
  ${kf5-qt5-depends},
  ${misc:Depends},
  ${shlibs:Depends}
-Recommends: ${plasma-iconset-dep}
+Recommends: kio (>> 5.103.0-1), ${plasma-iconset-dep}
 Replaces: libreoffice-kde (<< 1:6.1.0~alpha1-1)
 Section: kde
 Enhances: libreoffice
diff -Nru libreoffice-7.4.7/debian/patches/fix-32bit-build.diff libreoffice-7.4.7/debian/patches/fix-32bit-build.diff
--- libreoffice-7.4.7/debian/patches/fix-32bit-build.diff	1970-01-01 01:00:00.0 +0100
+++ libreoffice-7.4.7/debian/patches/fix-32bit-build.diff	2024-05-22 09:46:59.0 +0200
@@ -0,0 +1,54 @@
+From 0f5dfaebd61b9cabbe9762865563c2296ebb0112 Mon Sep 17 00:00:00 2001
+From: Stephan Bergmann 
+Date: Fri, 8 Mar 2024 08:38:44 +0100
+Subject: [PATCH] Blind fix for Linux 32-bit builds
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+...which, according to
+<https://lists.freedesktop.org/archives/libreoffice/2024-March/091666.html> "32
+bit build failure (smb, narrowing)", started to fail with
+
+> /<>/sal/osl/unx/file.cxx: In fu

Bug#1070888: PLEASE IGNORE

[Rene Engelhard]

Hi,

Am 11.05.24 um 13:45 schrieb Emmanuel Charpentier:
In fact, both submission worked, but the second is but a duplicate of 
the first.


My apologies for the noise...


No problem, I already merged them. :)

 (Intestestingly 1070888 only made it to the BTS and not to the mailing 
list where 1070887 
 did...)



Regards,


Rene

Bug#1070862: and this looses files

[Rene Engelhard]

severity 1070862 serious
thanks

Hi,

this is even worse. It looses  the library file for the "non-main" 
libraries after cleanup:


Clean testing chroot.

# apt install libpoppler-dev libpoppler-cpp-dev
[...]

# apt update
# apt dist-upgrade
The following packages were automatically installed and are no longer 
required:

  libpoppler-cpp0t64 libpoppler126t64
Use 'sudo apt autoremove' to remove them.

Upgrading:
  gcc-14-base libaudit-common libc-bin libgcc-s1 libncursesw6 
libpoppler-dev libslang2  libtinfo6 nano ncurses-bin
  kmodlibaudit1   libc6libkmod2  libpoppler-cpp-dev 
libsharpyuv0   libstdc++6 libwebp7  ncurses-base zlib1g


Installing dependencies:
  ca-certificateslibldap-2.5-0  libnghttp2-14 libpoppler134 
librtmp1   libsasl2-moduleslibssh2-1t64 publicsuffix
  libcurl3t64-gnutls libldap-common libpoppler-cpp0v5 libpsl5t64 
libsasl2-2 libsasl2-modules-db openssl


Suggested packages:
  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal 
libsasl2-modules-ldap libsasl2-modules-otp libsasl2-modules-sql


Summary:
  Upgrading: 20, Installing: 15, Removing: 0, Not Upgrading: 0
  Download size: 11.3 MB
  Space needed: 10.1 MB / 133 GB available

Continue? [Y/n]
Get:1 http://deb.debian.org/debian sid/main amd64 ncurses-bin amd64 
6.5-2 [433 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 gcc-14-base amd64 
14-20240429-1 [43.9 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 libgcc-s1 amd64 
14-20240429-1 [72.4 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 libstdc++6 amd64 
14-20240429-1 [715 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 libc6 amd64 2.38-8 
[2771 kB]
Get:6 http://deb.debian.org/debian sid/main amd64 libc-bin amd64 2.38-8 
[610 kB]
Get:7 http://deb.debian.org/debian sid/main amd64 ncurses-base all 6.5-2 
[270 kB]
Get:8 http://deb.debian.org/debian sid/main amd64 libaudit-common all 
1:3.1.2-2.1 [11.4 kB]
Get:9 http://deb.debian.org/debian sid/main amd64 libaudit1 amd64 
1:3.1.2-2.1 [48.5 kB]
Get:10 http://deb.debian.org/debian sid/main amd64 libncursesw6 amd64 
6.5-2 [135 kB]
Get:11 http://deb.debian.org/debian sid/main amd64 libtinfo6 amd64 6.5-2 
[344 kB]
Get:12 http://deb.debian.org/debian sid/main amd64 zlib1g amd64 
1:1.3.dfsg+really1.3.1-1 [87.9 kB]

Get:13 http://deb.debian.org/debian sid/main amd64 kmod amd64 32-1 [95.7 kB]
Get:14 http://deb.debian.org/debian sid/main amd64 libkmod2 amd64 32-1 
[60.1 kB]

Get:15 http://deb.debian.org/debian sid/main amd64 nano amd64 8.0-1 [659 kB]
Get:16 http://deb.debian.org/debian sid/main amd64 openssl amd64 3.2.1-3 
[1360 kB]
Get:17 http://deb.debian.org/debian sid/main amd64 ca-certificates all 
20240203 [158 kB]
Get:18 http://deb.debian.org/debian sid/main amd64 libsasl2-modules-db 
amd64 2.1.28+dfsg1-6 [19.5 kB]
Get:19 http://deb.debian.org/debian sid/main amd64 libsasl2-2 amd64 
2.1.28+dfsg1-6 [56.9 kB]
Get:20 http://deb.debian.org/debian sid/main amd64 libldap-2.5-0 amd64 
2.5.17+dfsg-1 [186 kB]
Get:21 http://deb.debian.org/debian sid/main amd64 libnghttp2-14 amd64 
1.61.0-1+b1 [75.6 kB]
Get:22 http://deb.debian.org/debian sid/main amd64 libpsl5t64 amd64 
0.21.2-1.1 [56.8 kB]
Get:23 http://deb.debian.org/debian sid/main amd64 librtmp1 amd64 
2.4+20151223.gitfa8646d.1-2+b4 [58.5 kB]
Get:24 http://deb.debian.org/debian sid/main amd64 libssh2-1t64 amd64 
1.11.0-4.1+b2 [215 kB]
Get:25 http://deb.debian.org/debian sid/main amd64 libcurl3t64-gnutls 
amd64 8.7.1-5 [433 kB]
Get:26 http://deb.debian.org/debian sid/main amd64 libldap-common all 
2.5.17+dfsg-1 [31.5 kB]
Get:27 http://deb.debian.org/debian sid/main amd64 libpoppler134 amd64 
24.02.0-2 [1029 kB]
Get:28 http://deb.debian.org/debian sid/main amd64 libpoppler-cpp0v5 
amd64 24.02.0-2 [41.3 kB]
Get:29 http://deb.debian.org/debian sid/main amd64 libpoppler-cpp-dev 
amd64 24.02.0-2 [14.7 kB]
Get:30 http://deb.debian.org/debian sid/main amd64 libpoppler-dev amd64 
24.02.0-2 [8080 B]
Get:31 http://deb.debian.org/debian sid/main amd64 libsasl2-modules 
amd64 2.1.28+dfsg1-6 [66.0 kB]
Get:32 http://deb.debian.org/debian sid/main amd64 libsharpyuv0 amd64 
1.4.0-0.1 [113 kB]
Get:33 http://deb.debian.org/debian sid/main amd64 libslang2 amd64 
2.3.3-5 [551 kB]
Get:34 http://deb.debian.org/debian sid/main amd64 libwebp7 amd64 
1.4.0-0.1 [311 kB]
Get:35 http://deb.debian.org/debian sid/main amd64 publicsuffix all 
20231001.0357-0.1 [125 kB]

Fetched 11.3 MB in 2s (6218 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Extracting templates from packages: 100%
Preconfiguring pac

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

[Rene Engelhard]

# splt up the LO and kio parts properly

clone 1069835 -1

reassign -1 kio

retitle -1 kio: Don't leak existing file handles to newly spanwed KIO 
workers


block 1069835 by -1

# LOs part is done, at least for this one.

close 1069835 4:24.2.2-1

thanks


Am 03.05.24 um 10:54 schrieb Andreas B. Mundt:

On Fri, May 03, 2024 at 10:18:22AM +0200, Sune Stolborg Vuorela wrote:

On Friday, May 3, 2024 10:06:27 AM CEST you wrote:

On Thu, May 02, 2024 at 04:37:30PM +0200, Sune Stolborg Vuorela wrote:

[…]

If it works for you, I'll ask the debian kde maintainers to fix it.


It looks like it fixes the libreoffice issue (no modifications applied
to libreoffice).  With a patched kio package I was not able to
reproduce the issue.  Replacing just the kio binary package seems to
be sufficient.  We are going to test a bit more on other setups too.

Tested with libreoffice from bookworm-backports:  Fixed.

Cool. So that means we don't even need the LO part here?

The changes needed to libreoffice are already in Debian ( https://
gerrit.libreoffice.org/c/core/+/162935 ) - also by Kevin Ottens who also
authored this patch.

Great!


Yes, that is the one mentioned earlier and fixed in 24.2.2.


Cleaning those bugs up and making an own one for kio.


Regards,


Rene

Bug#1069835: needs a fix in KIO as well

[Rene Engelhard]

Hi,

Am 26.04.24 um 10:02 schrieb Sune Stolborg Vuorela:

https://invent.kde.org/frameworks/kio/-/commit/
45b306dc0653fa42672e8a49afe8f42d24585ed4

is also needed for it to work.


Thanks for mentioning this.


As talked about on IRC this morning, that commit is only for kf6s kio.

So unless that one is backported to kf5 we'd get the fix then if we 
shipped libreoffice-kf6 and KF6/Plasma6 is what is used.


(According to IRC it isn't sure whether this will be backported to kf5. 
Let's see)



Regards,


Rene

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#1069554: [Pkg-pascal-devel] Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

[Rene Engelhard]

Hi,

Am 24.04.24 um 21:35 schrieb Peter B:
Why is it bad?  The nogui's are lighter dependencies than the gui 
packages.
Exactly. That#s why they should be used in package building for 
converting stuff.
One or the other is needed. Surely better to use the nogui if its 
available?


It is available. As indep builds are not done on armel that it's not 
available on armel does not really matter :)



My point is  that you don't need the alternative.


Regards,


Rene

Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

[Rene Engelhard]

Hi Lucas,

this is no bug in the package AFAICS.

libreoffice-draw-nogui is clearly only in Build-Depends-Indep:

Build-Depends: debhelper-compat (= 13),
 fpc,
 libgtk2.0-dev,
 lcl,
 lcl-qt5,
Build-Depends-Indep:
 libreoffice-draw-nogui,
 libreoffice-writer,

So it's only needed for _all builds. So why would the build-deps  be 
uninstallable on armel? Or do your scripts do full builds and not 
--binary-arch/-B or whatever applicable?


(And yes, that nogui is not available on armel is a deliberate decision. 
It's dead, and nooone will hopefully want to use it for document 
conversion. And I don't want to force a full double build on armel.)


This bugreport now caused the following "fix" in winff:

Build-Depends-Indep:
 faketime,
 libreoffice-draw-nogui   | libreoffice-draw,
 libreoffice-writer-nogui | libreoffice-writer,

which I consider bad...

Regards,

Rene

Bug#1069123: RM: libreoffice != 24.3/experimental [armhf ppc64el s390x mips64el riscv64] -- ROM, NVIU; obsolete cruft

[Rene Engelhard]

Package: ftp.debian.org

Hi,

The following packages are cruft:

$ rmadison -s experimental -S libreoffice | grep -v 24\.2\.3
fonts-opensymbol | 4:102.12+LibO7.5.4~rc2-1  | 
experimental | all
fonts-opensymbol | 4:102.12+LibO7.5.5~rc1-2  | 
experimental | all
fonts-opensymbol | 4:102.12+LibO7.6.3~rc2-1  | 
experimental | all
fonts-opensymbol | 4:102.12+LibO24.2.0~rc2-1 | 
experimental | all
fonts-opensymbol | 4:102.12+LibO24.2.1~rc2-1 | 
experimental | all
gir1.2-lokdocview-0.1| 4:7.5.4~rc2-1 | 
experimental | mips64el
gir1.2-lokdocview-0.1| 4:24.2.1~rc2-1| 
experimental | riscv64
liblibreoffice-java  | 4:7.5.4~rc2-1 | 
experimental | all
liblibreoffice-java  | 4:7.5.5~rc1-2 | 
experimental | all
liblibreoffice-java  | 4:7.6.3~rc2-1 | 
experimental | all
liblibreoffice-java  | 4:24.2.0~rc2-1| 
experimental | all
liblibreoffice-java  | 4:24.2.1~rc2-1| 
experimental | all
liblibreofficekitgtk | 4:7.5.4~rc2-1 | 
experimental | mips64el
liblibreofficekitgtk | 4:24.2.1~rc2-1| 
experimental | riscv64
libofficebean-java   | 4:7.5.4~rc2-1 | 
experimental | mips64el
libofficebean-java   | 4:7.5.5~rc1-2 | 
experimental | armhf, ppc64el, s390x
libofficebean-java   | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice  | 4:7.5.4~rc2-1 | 
experimental | source, mips64el
libreoffice  | 4:7.5.5~rc1-2 | 
experimental | source
libreoffice  | 4:7.6.3~rc2-1 | 
experimental | source
libreoffice  | 4:24.2.0~rc2-1| 
experimental | source
libreoffice  | 4:24.2.1~rc2-1| 
experimental | source, riscv64
libreoffice-base | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-base | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-base-core| 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-base-core| 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-base-drivers | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-base-drivers | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-calc | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-calc | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-common   | 4:7.5.4~rc2-1 | 
experimental | all
libreoffice-common   | 4:7.5.5~rc1-2 | 
experimental | all
libreoffice-common   | 4:7.6.3~rc2-1 | 
experimental | all
libreoffice-common   | 4:24.2.0~rc2-1| 
experimental | all
libreoffice-common   | 4:24.2.1~rc2-1| 
experimental | all
libreoffice-core | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-core | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-dev  | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-dev  | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-dev-common   | 4:7.5.4~rc2-1 | 
experimental | all
libreoffice-dev-common   | 4:7.5.5~rc1-2 | 
experimental | all
libreoffice-dev-common   | 4:7.6.3~rc2-1 | 
experimental | all
libreoffice-dev-common   | 4:24.2.0~rc2-1| 
experimental | all
libreoffice-dev-common   | 4:24.2.1~rc2-1| 
experimental | all
libreoffice-dev-doc  | 4:7.5.4~rc2-1 | 
experimental | all
libreoffice-dev-doc  | 4:7.5.5~rc1-2 | 
experimental | all
libreoffice-dev-doc  | 4:7.6.3~rc2-1 | 
experimental | all
libreoffice-dev-doc  | 4:24.2.0~rc2-1| 
experimental | all
libreoffice-dev-doc  | 4:24.2.1~rc2-1| 
experimental | all
libreoffice-dev-gui  | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-dev-gui  | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-draw | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-draw | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-evolution| 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-evolut

Bug#1069121: RM: libuno-sal3 libuno-cppu3 ibuno-salhelpergcc3-3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 -- ROM, NBS; obsolete cruft pre-t64

[Rene Engelhard]

Package: ftp.debian.org


Hi,


please remove

rene@frodo:~$ rmadison -s unstable libuno-sal3 libuno-cppu3 
libuno-salhelpergcc3-3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3
libuno-cppu3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, 
ppc64el, s390x
libuno-cppuhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, 
armhf, i386, ppc64el, s390x
libuno-purpenvhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, 
armel, armhf, i386, ppc64el, s390x
libuno-sal3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, 
ppc64el, s390x
libuno-salhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, 
armhf, i386, ppc64el, s390x


on all those archs, they all have been renamed for t64. No idea why the 
auto-decrufter doesn't pick it up.


That also makes it possible to remove this cruft:

$ rmadison -s unstable -S libreoffice | grep 24\.2\.0
fonts-opensymbol | 4:102.12+LibO24.2.0-1 | unstable | all
liblibreoffice-java | 4:24.2.0-1 | unstable | all
libreoffice | 4:24.2.0-1 | unstable | source
libreoffice-common | 4:24.2.0-1 | unstable | all
libreoffice-dev-common | 4:24.2.0-1 | unstable | all
libreoffice-dev-doc | 4:24.2.0-1 | unstable | all
libreoffice-help-ca | 4:24.2.0-1 | unstable | all
libreoffice-help-common | 4:24.2.0-1 | unstable | all
libreoffice-help-cs | 4:24.2.0-1 | unstable | all
libreoffice-help-da | 4:24.2.0-1 | unstable | all
libreoffice-help-de | 4:24.2.0-1 | unstable | all
libreoffice-help-dz | 4:24.2.0-1 | unstable | all
libreoffice-help-el | 4:24.2.0-1 | unstable | all
libreoffice-help-en-gb | 4:24.2.0-1 | unstable | all
libreoffice-help-en-us | 4:24.2.0-1 | unstable | all
libreoffice-help-es | 4:24.2.0-1 | unstable | all
libreoffice-help-et | 4:24.2.0-1 | unstable | all
libreoffice-help-eu | 4:24.2.0-1 | unstable | all
libreoffice-help-fi | 4:24.2.0-1 | unstable | all
libreoffice-help-fr | 4:24.2.0-1 | unstable | all
libreoffice-help-gl | 4:24.2.0-1 | unstable | all
libreoffice-help-hi | 4:24.2.0-1 | unstable | all
libreoffice-help-hu | 4:24.2.0-1 | unstable | all
libreoffice-help-id | 4:24.2.0-1 | unstable | all
libreoffice-help-it | 4:24.2.0-1 | unstable | all
libreoffice-help-ja | 4:24.2.0-1 | unstable | all
libreoffice-help-km | 4:24.2.0-1 | unstable | all
libreoffice-help-ko | 4:24.2.0-1 | unstable | all
libreoffice-help-nl | 4:24.2.0-1 | unstable | all
libreoffice-help-om | 4:24.2.0-1 | unstable | all
libreoffice-help-pl | 4:24.2.0-1 | unstable | all
libreoffice-help-pt | 4:24.2.0-1 | unstable | all
libreoffice-help-pt-br | 4:24.2.0-1 | unstable | all
libreoffice-help-ru | 4:24.2.0-1 | unstable | all
libreoffice-help-sk | 4:24.2.0-1 | unstable | all
libreoffice-help-sl | 4:24.2.0-1 | unstable | all
libreoffice-help-sv | 4:24.2.0-1 | unstable | all
libreoffice-help-tr | 4:24.2.0-1 | unstable | all
libreoffice-help-vi | 4:24.2.0-1 | unstable | all
libreoffice-help-zh-cn | 4:24.2.0-1 | unstable | all
libreoffice-help-zh-tw | 4:24.2.0-1 | unstable | all
libreoffice-java-common | 4:24.2.0-1 | unstable | all
libreoffice-l10n-af | 4:24.2.0-1 | unstable | all
libreoffice-l10n-am | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ar | 4:24.2.0-1 | unstable | all
libreoffice-l10n-as | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ast | 4:24.2.0-1 | unstable | all
libreoffice-l10n-be | 4:24.2.0-1 | unstable | all
libreoffice-l10n-bg | 4:24.2.0-1 | unstable | all
libreoffice-l10n-bn | 4:24.2.0-1 | unstable | all
libreoffice-l10n-br | 4:24.2.0-1 | unstable | all
libreoffice-l10n-bs | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ca | 4:24.2.0-1 | unstable | all
libreoffice-l10n-cs | 4:24.2.0-1 | unstable | all
libreoffice-l10n-cy | 4:24.2.0-1 | unstable | all
libreoffice-l10n-da | 4:24.2.0-1 | unstable | all
libreoffice-l10n-de | 4:24.2.0-1 | unstable | all
libreoffice-l10n-dz | 4:24.2.0-1 | unstable | all
libreoffice-l10n-el | 4:24.2.0-1 | unstable | all
libreoffice-l10n-en-gb | 4:24.2.0-1 | unstable | all
libreoffice-l10n-en-za | 4:24.2.0-1 | unstable | all
libreoffice-l10n-eo | 4:24.2.0-1 | unstable | all
libreoffice-l10n-es | 4:24.2.0-1 | unstable | all
libreoffice-l10n-et | 4:24.2.0-1 | unstable | all
libreoffice-l10n-eu | 4:24.2.0-1 | unstable | all
libreoffice-l10n-fa | 4:24.2.0-1 | unstable | all
libreoffice-l10n-fi | 4:24.2.0-1 | unstable | all
libreoffice-l10n-fr | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ga | 4:24.2.0-1 | unstable | all
libreoffice-l10n-gd | 4:24.2.0-1 | unstable | all
libreoffice-l10n-gl | 4:24.2.0-1 | unstable | all
libreoffice-l10n-gu | 4:24.2.0-1 | unstable | all
libreoffice-l10n-gug | 4:24.2.0-1 | unstable | all
libreoffice-l10n-he | 4:24.2.0-1 | unstable | all
libreoffice-l10n-hi | 4:24.2.0-1 | unstable | all
libreoffice-l10n-hr | 4:24.2.0-1 | unstable | all
libreoffice-l10n-hu | 4:24.2.0-1 | unstable | all
libreoffice-l10n-id | 4:24.2.0-1 | unstable | all
libreoffice-l10n-in | 4:24.2.0-1 | unstable | all
libreoffice-l10n-is | 4:24.2.0-1 | unstable | all
libreoffice-l10n-it | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ja | 4:24.2.0-1 |

Bug#1069120: RM: ure-java libofficebean-java libreoffice-sdbc-hsqldb libreoffice-report-builder libreoffice-report-builder-bin [armhf ppc64el s390x] -- ROM, ANAIS; obsolete cruft

[Rene Engelhard]

Package: ftp.debian.org


Hi,


The following packages have been ANAIS for loong (sincd 7.6.x times.).


$ rmadison -s unstable ure-java libofficebean-java 
libreoffice-sdbc-hsqldb libreoffice-report-builder 
libreoffice-report-builder-bin | grep -v 24

libofficebean-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
libreoffice-report-builder | 4:7.5.9~rc1-1 | unstable | all
libreoffice-report-builder-bin | 4:7.5.9~rc1-1 | unstable | armhf, 
ppc64el, s390x

libreoffice-sdbc-hsqldb | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
ure-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x

but apparently are not recognized by the auto-cruft. Keeping all this 
*load of obsolete packages in sid:


$ rmadison -s unstable -S libreoffice | grep -v 24\.2
fonts-opensymbol | 4:102.12+LibO7.5.9~rc1-1 | unstable | all
liblibreoffice-java | 4:7.5.9~rc1-1 | unstable | all
libofficebean-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
libreoffice | 4:7.5.9~rc1-1 | unstable | source
libreoffice-common | 4:7.5.9~rc1-1 | unstable | all
libreoffice-dev-common | 4:7.5.9~rc1-1 | unstable | all
libreoffice-dev-doc | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-ca | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-common | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-cs | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-da | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-de | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-dz | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-el | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-en-gb | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-en-us | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-es | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-et | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-eu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-fi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-fr | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-gl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-hi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-hu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-id | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-it | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-ja | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-km | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-ko | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-nl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-om | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-pl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-pt | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-pt-br | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-ru | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-sk | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-sl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-sv | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-tr | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-vi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-zh-cn | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-zh-tw | 4:7.5.9~rc1-1 | unstable | all
libreoffice-java-common | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-af | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-am | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-ar | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-as | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-ast | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-be | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-bg | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-bn | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-br | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-bs | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-ca | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-cs | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-cy | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-da | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-de | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-dz | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-el | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-en-gb | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-en-za | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-eo | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-es | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-et | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-eu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-fa | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-fi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-fr | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-ga | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-gd | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-gl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-gu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-gug | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-he | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-hi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-hr | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-hu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-id | 4:7.5.9~rc1-1 | unstabl

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 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]

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]

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-b

Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Rene Engelhard]

Hi,

Am 25.03.24 um 19:17 schrieb Julian Gilbey:

   * Reading and writing file formats (like CSV, Apache ORC, and Apache
 Parquet)


liborcus supports this (Apache Parquet) if built with Apache Arrow. And 
thus makes LibreOffice being able to handle it.


I didn't invest any time in Apache Arrow since I am already too low on 
time anyway and I deemed it too a "low popularity" thing anyway.



So this is a plea for anyone looking for something really helpful to
do: it would be great to have a group of developers finally package
this!

Indeed.

There was some initial work done (see the RFP bug report for
details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
but that is fairly old now.  As Apache Arrow supports numerous
languages, it may well benefit from having a group of developers with
different areas of expertise to build it.  (Or perhaps it would make
more sense to split the upstream source into a collection of different
Debian source packages for the different supported languages.  I don't
know.)


Would definitely make transitions easier.


  Unfortunately I don't have the capacity to devote any time to
it myself.


Dito.


Regards,


Rene

Bug#1058545: due to #1058653

[Rene Engelhard]

block 1058545 by 1058653
tag 1058545 + patch
thanks

Hi,

This is due to

> dh_installdocs: error: Cannot find (any matches for) "doc/Esnacc.pdf" 
(tried in .)


which is due to

(cd /home/rene/esnacc-1.8.1/doc && unzip eSNACCManuals.zip && 
libreoffice --headless --convert-to pdf Esnacc.doc)

Archive:  eSNACCManuals.zip
  inflating: EsnaccOriginalMaterial.doc
  inflating: Esnacc.doc
Warning: failed to launch javaldx - java may not function correctly
Error: source file could not be loaded

(the last message is it, the javaldx warning is harmless)

failing.

Which is due to a bug in libreoffice which is fixed by

libreoffice (4:24.2.0-2) experimental; urgency=medium

  * debian/patches/sw-do-not-require-cui.diff: do not require cui in 
sw, from

upstream (closes: #1058653)

which is fixed but (well, it's followers) are held up by the time_t 
transition. (So this bug is not there anymore when building in sid)


Workaround (as other packages did) is to build-deped on 
libreoffice-writer for now (instead of libreoffice-writer-nogui).

Or just wait until said fix is in testing (whenever that may be)

Regards,

Rene

Bug#1066970: FTBFS: error: implicit declaration of function 'InitNibbleMem' [-Werror=implicit-function-declaration]

[Rene Engelhard]

Source: esnacc
Version: 1.8.1-3
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-impfuncdef

Hi,

esnacc FTBFS:

gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2 -I./asn1specs 
-I./asn1specs -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection -O0 -Wall -Wextra -c -o c-examples/simple/sbuf-sbuf-ex.o 
`test -f 'c-examples/simple/sbuf-ex.c' || echo 
'./'`c-examples/simple/sbuf-ex.c
/bin/bash ./libtool  --tag=CC   --mode=link gcc -I./asn1specs 
-I./asn1specs -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection -O0 -Wall -Wextra  -Wl,-z,relro -o 
c-examples/simple/sbuf asn1specs/c_examples_simple_sbuf-p-rec.o 
c-examples/simple/sbuf-sbuf-ex.o c-lib/libcasn1.la -lm
libtool: link: gcc -I./asn1specs -I./asn1specs -I./c-lib/inc -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection -O0 -Wall -Wextra -Wl,-z -Wl,relro -o 
c-examples/simple/.libs/sbuf asn1specs/c_examples_simple_sbuf-p-rec.o 
c-examples/simple/sbuf-sbuf-ex.o  c-lib/.libs/libcasn1.so -lm -pthread
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2 -I./c-lib/inc 
-g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection -O0 -Wall -Wextra -c -o 
c-examples/test-lib/testlib-test-lib.o `test -f 
'c-examples/test-lib/test-lib.c' || echo './'`c-examples/test-lib/test-lib.c

c-examples/test-lib/test-lib.c: In function 'main':
c-examples/test-lib/test-lib.c:68:5: error: implicit declaration of 
function 'InitNibbleMem' [-Werror=implicit-function-declaration]

   68 | InitNibbleMem (256, 256);
  | ^
[...]

This is most likely caused by a change in dpkg 1.22.6, that enabled
-Werror=implicit-function-declaration. For more information, see
https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Indeed a build with export DEB_BUILD_MAINT_OPTIONS=qa=-bug-implicit-func 
works. But better than disabling it would be to fix it of course ;)


Regards,

Rene

Bug#1066473: multitail: FTBFS: mt.c:707:25: error: implicit declaration of function ‘waddnwstr’; did you mean ‘waddnstr’? [-Werror=implicit-function-declaration]

[Rene Engelhard]

tag 1066473: + pending

thanks

Hi,

Am 13.03.24 um 12:53 schrieb Lucas Nussbaum:

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


Interesting. I almost wanted to tag it unreproducible since it didn't 
happen in my already-existing chroot... But it definitely does fail in 
cowbuilder build <.dsc> :/



Nope. Just works here. Yes, with dpkg-dev 1.22.6. In a manual chroot I 
have here and upgraded and in a cowbuilder build multitail_6.5.0-1.dsc




Relevant part (hopefully):

cc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall -Wno-unused-parameter -funsigned-char -O3 
-DLinux -DVERSION=\"6.5.0\" -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -DCONFIG_FILE=\"/etc/multitail.conf\" -MMD -MP -DUTF8_SUPPORT  -c -o mt.o 
mt.c
mt.c: In function ‘do_color_print’:
mt.c:707:25: error: implicit declaration of function ‘waddnwstr’; did you mean 
‘waddnstr’? [-Werror=implicit-function-declaration]
   707 | waddnwstr(win -> win, &wcur, 1);
   | ^
   | waddnstr
mt.c: In function ‘update_statusline’:
mt.c:1467:126: warning: format ‘%lld’ expects argument of type ‘long long int’, 
but argument 5 has type ‘off64_t’ {aka ‘long int’} [-Wformat=]
  1467 | mvwprintw(status -> win, 0, 
win_width - (strlen(timestamp) + cur_len), "%10lld - %s", fsize, timestamp);
   |
 ~^~
   |
  ||
   |
  |off64_t {aka 
long int}
   |
  long long int
   |
 %10ld
cc1: some warnings being treated as errors
make[2]: *** [: mt.o] Error 1


Actually upstream has

#if defined(UTF8_SUPPORT) && defined(NCURSES_WIDECHAR)
// FIXME warning: implicit declaration of function �~@~Xwaddnwstr�~@~Y 
is invalid in C99 [-Wimplicit-function-declaration]

// see /usr/include/ncurses.h
    waddnwstr(win -> win, &wcur, 1);
#else
    wprintw(win -> win, "%c", wcur);
#endif

so is aware...


Actually (thanks to discussion on IRC) it seems that

CPPFLAGS:=$(shell pkg-config --cflags ncurses)
NCURSES_LIB:=$(shell pkg-config --libs ncurses)

is empty even though it shouldn't be. So fix is to add that missing 
build-dep.



Regards,


Rene

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 
d

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#1065447: unneeded libreoffice Build-Depends (libreoffice, ure-java, default-jre), -writer and -calc are enough

[Rene Engelhard]

Source: winff
Severity: normal

Hi,

I just noticed winff - thanks to your bug report :):

I see

winff (1.6.2+dfsg-2) unstable; urgency=medium

  * Temporary home directory to run soffice (Closes: #759980)
  * Build dependencies (for javaldx)
  * Escape Dollar signs in file names (Closes: #1053373)

 -- Peter Blackman   Thu, 05 Oct 2023 
10:00:00 +0100


in the changelog and chekced. Because that looked extremely fishy. It is.

Build-Depends-Indep:
 libreoffice,
 ure-java,
 default-jre,

What for?

a) The javaldx warning is harmless unless you do run Java stuff. Which 
you don't if you convert stuff to pdf. You can just ignore this and you 
don't need to depend on Java stuff (which is not available on all archs)[1]


b) I don't believe you need libreoffice-base etc which gets pulled in by 
the libreoffice *metapackage*.


rene@frodo:~/winff-1.6.3+dfsg/winff/docs$ ls *.od?
WinFF.ca.odt  WinFF.es_AR.odg  WinFF.nl.odt
WinFF.en.odt  WinFF.fr.odt WinFF.pt_BR.odt

So you just need libreoffice-writer and libreoffice-draw. Tried in a 
local build with libreoffice-writer and -draw 4:24.2.1-3.


(Actually libreoffice-writer-nogui and libreoffice-draw-nogui would 
suffice but the fix for #1058653 is blocked by t64 transition. So let's

ignore that for now.)

Patch:

diff -Nru winff-1.6.3+dfsg/debian/changelog 
winff-1.6.3+dfsg/debian/changelog

--- winff-1.6.3+dfsg/debian/changelog   2024-02-19 14:00:00.0 +0100
+++ winff-1.6.3+dfsg/debian/changelog   2024-03-04 21:50:28.0 +0100
@@ -1,3 +1,10 @@
+winff (1.6.3+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * only build-depend on needed libreoffice-draw, libreoffice-writer;
+remove extraneous libreoffice, ure-java, default-jre
+
+ -- Rene Engelhard   Mon, 04 Mar 2024 20:50:28 +
+
 winff (1.6.3+dfsg-1) unstable; urgency=medium

   * New Upstream release (Closes: #1053373) (Closes: #1061586)
diff -Nru winff-1.6.3+dfsg/debian/control winff-1.6.3+dfsg/debian/control
--- winff-1.6.3+dfsg/debian/control 2023-10-04 22:29:34.0 +0200
+++ winff-1.6.3+dfsg/debian/control 2024-03-04 21:50:28.0 +0100
@@ -10,9 +10,8 @@
  lcl,
  lcl-qt5,
 Build-Depends-Indep:
- libreoffice,
- ure-java,
- default-jre,
+ libreoffice-draw,
+ libreoffice-writer,
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/pascal-team/winff

Regards,

Rene

[1] _all is Built on amd64 anyways, but still.

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#1065321: lasso: unfullfillable Build-Depends (unneeded explicit Build-Depends on libxmlsec1-openssl)

[Rene Engelhard]

Hi,

Am 02.03.24 um 18:42 schrieb Rene Engelhard:
So as  this library is now libxmlsec1t64-openssl this Build-Depends: is 
now unfullfillable.


At least for 32bit archs like armel/armhf (which don't have Provides: 
libxmlsec1-openssl) or a future package-named package due to ABI changes 
(like when we ever updated to 1.3.x)


Regards,

Rene

Bug#1065321: lasso: unfullfillable Build-Depends (unneeded explicit Build-Depends on libxmlsec1-openssl)

[Rene Engelhard]

Source: lasso
Severity: serious
Version: 2.8.2-1
Tags: patch
User: debian-...@lists.debian.org
Usertags: time-t

Hi,

I just saw lasso has

libxmlsec1-dev,
libxmlsec1-openssl,

in Build-Depends. What for? If this was versioned this could be 
understandable, but it isn't.


And given libxmlsec1-dev pulls in all the variants since

xmlsec1 (1.2.9-2) unstable; urgency=low

  * Add engine libraries to depends of dev package
  * Switch to mozilla libs provided by xulrunner package (Closes: #364382)
  * Confirm Debian standards 3.7.2

 -- John V. Belmonte   Thu, 08 Jun 2006 21:52:55 
-0400


- so for anything relevant - this is not needed.

So as  this library is now libxmlsec1t64-openssl this Build-Depends: is 
now unfullfillable.


Patch is trivial: remove that line :)

Regards,

Rene

Bug#1064890: [xml/sgml-pkgs] Bug#1064890: libxmlsec1-dev, libxmlsec1-doc: both ship /usr/share/doc/libxmlsec1-dev/examples/*

[Rene Engelhard]

Hi,

Am 27.02.24 um 11:43 schrieb Andreas Beckmann via debian-xml-sgml-pkgs:

Package: libxmlsec1-dev,libxmlsec1-doc
Version: 1.2.39-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

 From the attached log (scroll to the bottom...):

   Preparing to unpack .../libxmlsec1-doc_1.2.39-2_all.deb ...
   Unpacking libxmlsec1-doc (1.2.39-2) ...
   dpkg: error processing archive 
/var/cache/apt/archives/libxmlsec1-doc_1.2.39-2_all.deb (--unpack):
trying to overwrite '/usr/share/doc/libxmlsec1-dev/examples/Makefile', 
which is also in package libxmlsec1-dev 1.2.39-2
   Errors were encountered while processing:
/var/cache/apt/archives/libxmlsec1-doc_1.2.39-2_all.deb

These files are in conflict:

usr/share/doc/libxmlsec1-dev/examples/Makefile


*sigh*.

debuild -A installs into -doc

debuild -B installs into -dev

-> boom


Compared to sid:

rene@frodo:~$ dpkg -L libxmlsec1-dev | grep examples > dev
rene@frodo:~$ dpkg -L libxmlsec1-doc | grep examples > doc
rene@frodo:~$ diff -u dev doc
--- dev    2024-02-27 20:20:01.410212432 +
+++ doc    2024-02-27 20:20:06.382271127 +
@@ -1,42 +1,46 @@
-/usr/share/doc/libxmlsec1-dev/examples
-/usr/share/doc/libxmlsec1-dev/examples/Makefile
-/usr/share/doc/libxmlsec1-dev/examples/Makefile.w32
-/usr/share/doc/libxmlsec1-dev/examples/README.md
-/usr/share/doc/libxmlsec1-dev/examples/binary.dat
-/usr/share/doc/libxmlsec1-dev/examples/ca2cert.pem
-/usr/share/doc/libxmlsec1-dev/examples/cacert.pem
-/usr/share/doc/libxmlsec1-dev/examples/decrypt1.c
-/usr/share/doc/libxmlsec1-dev/examples/decrypt2.c
-/usr/share/doc/libxmlsec1-dev/examples/decrypt3.c
-/usr/share/doc/libxmlsec1-dev/examples/deskey.bin
-/usr/share/doc/libxmlsec1-dev/examples/encrypt1-res.xml
-/usr/share/doc/libxmlsec1-dev/examples/encrypt1-tmpl.xml
-/usr/share/doc/libxmlsec1-dev/examples/encrypt1.c
-/usr/share/doc/libxmlsec1-dev/examples/encrypt2-doc.xml
-/usr/share/doc/libxmlsec1-dev/examples/encrypt2-res.xml
-/usr/share/doc/libxmlsec1-dev/examples/encrypt2.c
-/usr/share/doc/libxmlsec1-dev/examples/encrypt3-doc.xml
-/usr/share/doc/libxmlsec1-dev/examples/encrypt3-res.xml
-/usr/share/doc/libxmlsec1-dev/examples/encrypt3.c
-/usr/share/doc/libxmlsec1-dev/examples/mywin32make.bat
-/usr/share/doc/libxmlsec1-dev/examples/rsacert.pem
-/usr/share/doc/libxmlsec1-dev/examples/rsakey.pem
-/usr/share/doc/libxmlsec1-dev/examples/rsapub.pem
-/usr/share/doc/libxmlsec1-dev/examples/sign1-res.xml
-/usr/share/doc/libxmlsec1-dev/examples/sign1-tmpl.xml
-/usr/share/doc/libxmlsec1-dev/examples/sign1.c
-/usr/share/doc/libxmlsec1-dev/examples/sign2-doc.xml
-/usr/share/doc/libxmlsec1-dev/examples/sign2-res.xml
-/usr/share/doc/libxmlsec1-dev/examples/sign2.c
-/usr/share/doc/libxmlsec1-dev/examples/sign3-doc.xml
-/usr/share/doc/libxmlsec1-dev/examples/sign3-res.xml
-/usr/share/doc/libxmlsec1-dev/examples/sign3.c
-/usr/share/doc/libxmlsec1-dev/examples/verify1.c
-/usr/share/doc/libxmlsec1-dev/examples/verify2.c
-/usr/share/doc/libxmlsec1-dev/examples/verify3.c
-/usr/share/doc/libxmlsec1-dev/examples/verify4-bad-res.xml
-/usr/share/doc/libxmlsec1-dev/examples/verify4-bad-tmpl.xml
-/usr/share/doc/libxmlsec1-dev/examples/verify4-res.xml
-/usr/share/doc/libxmlsec1-dev/examples/verify4-tmpl.xml
-/usr/share/doc/libxmlsec1-dev/examples/verify4.c
-/usr/share/doc/libxmlsec1-dev/examples/xmldsigverify.c
+/usr/share/doc/libxmlsec1/examples
+/usr/share/doc/libxmlsec1/examples/Makefile
+/usr/share/doc/libxmlsec1/examples/Makefile.w32
+/usr/share/doc/libxmlsec1/examples/README.md
+/usr/share/doc/libxmlsec1/examples/binary.dat
+/usr/share/doc/libxmlsec1/examples/ca2cert.pem
+/usr/share/doc/libxmlsec1/examples/cacert.pem
+/usr/share/doc/libxmlsec1/examples/decrypt1.c
+/usr/share/doc/libxmlsec1/examples/decrypt2.c
+/usr/share/doc/libxmlsec1/examples/decrypt3.c
+/usr/share/doc/libxmlsec1/examples/deskey.bin
+/usr/share/doc/libxmlsec1/examples/encrypt1-res.xml
+/usr/share/doc/libxmlsec1/examples/encrypt1-tmpl.xml
+/usr/share/doc/libxmlsec1/examples/encrypt1.c
+/usr/share/doc/libxmlsec1/examples/encrypt2-doc.xml
+/usr/share/doc/libxmlsec1/examples/encrypt2-res.xml
+/usr/share/doc/libxmlsec1/examples/encrypt2.c
+/usr/share/doc/libxmlsec1/examples/encrypt3-doc.xml
+/usr/share/doc/libxmlsec1/examples/encrypt3-res.xml
+/usr/share/doc/libxmlsec1/examples/encrypt3.c
+/usr/share/doc/libxmlsec1/examples/mywin32make.bat
+/usr/share/doc/libxmlsec1/examples/rsacert.pem
+/usr/share/doc/libxmlsec1/examples/rsakey.pem
+/usr/share/doc/libxmlsec1/examples/rsapub.pem
+/usr/share/doc/libxmlsec1/examples/sign1-res.xml
+/usr/share/doc/libxmlsec1/examples/sign1-tmpl.xml
+/usr/share/doc/libxmlsec1/examples/sign1.c
+/usr/share/doc/libxmlsec1/examples/sign2-doc.xml
+/usr/share/doc/libxmlsec1/examples/sign2-res.xml
+/usr/share/doc/libxmlsec1/examples/sign2.c
+/usr/share/doc/libxmlsec1/examples/sign3-doc.xml
+/usr/share/doc/libxml

Bug#1064776: bogusly redirects Bugs to debian-openoff...@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#1063733: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done

[Rene Engelhard]

Hi,

Am 11.02.24 um 22:10 schrieb Rene Engelhard:
I just tried a rebuild of libreoffice with 
DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens.


DEB_BUILD_MAINT_OPTIONS of course. I set the correct one (and 
libreoffice and xmlsec1 did pick it up) but just "thinkoed" it when 
reporting the bug.


Regards,

Rene

Bug#1063733: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done

[Rene Engelhard]

Source: gpgme1.0
Version: 1.18.0-4.1~exp1
Severity: important

[ let's no get into a discussion on  the sense of this transition. I 
actually believe this isn't needed and we can leave 32 bit die in 2038 
but anyways...


The transition is ongoing now in experimental. So be it ]


Hi,


I just tried a rebuild of libreoffice with 
DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens.


It failed in a certificate unit tests so I tried to rebuild the 
"certificate" related (build-)dependencies also with 
DEB_HOST_MAINT_OPTIONS="abi=+time64"



While doing so I noticed that gpgme1.0 doesn't define -D_TIME_BITS=64 
even when built for t64 (as in the experimental NMU renaming to t64) on 
the affected architectures (anything 32-bit except i386).


This is probably because it doesn't honout dpkg-buildflags.

But even if you don't like dpkg-buildflags that define has to be done.

Regards,

Rene

P.S::
Thankfully libreoffice is fine without a rebuilt gpgme1.0 somehow

Bug#1063734: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done

[Rene Engelhard]

Source: gnutls28
Version: 3.8.3-1.1~exp1
Severity: important

[ let's no get into a discussion on  the sense of this transition. I 
actually believe this isn't needed and we can leave 32 bit die in 2038 
but anyways...


The transition is ongoing now in experimental. So be it ]

Hi,

I just tried a rebuild of libreoffice with 
DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens.


It failed in a certificate unit tests so I tried to rebuild the 
"certificate" related (build-)dependencies also with 
DEB_HOST_MAINT_OPTIONS="abi=+time64"


While doing so I noticed that gnutls28 doesn't define -D_TIME_BITS=64 
even when built for t64 (as in the experimental NMU renaming to t64) on 
the affected architectures (anything 32-bit except i386).


This is probably because it doesn't honout dpkg-buildflags.

But even if you don't like dpkg-buildflags that define has to be done.

Regards,

Rene

P.S::
Thankfully libreoffice is fine with just xmlsec1 being rebuilt. But it 
uses the nss flabour, so stuff using gnutls might break, no idea

Bug#1063732: hurd-i386 twice in java_unsupported_architectures

[Rene Engelhard]

Package: java-common
Version: 0.75
Severity: minor

Hi,

$ grep java_unsupported_architectures /usr/share/java/java_defaults.mk
java_unsupported_architectures = hppa hurd-i386 kfreebsd-amd64 
kfreebsd-i386 hurd-i386 powerpcspe s390 sparc

[...]

hurd-i386 is here twice.

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#1059040: [xml/sgml-pkgs] Bug#1059040: libxml2: ABI change? (undefined references)

[Rene Engelhard]

Hi,

Am 12.01.24 um 17:56 schrieb Thorsten Glaser:

On Fri, 12 Jan 2024, Rafael Laboissière wrote:


experimental, the configure script does detect the absence of the
xmlNanoFTPNewCtxt function in the libxml2 library (version
2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions.
However, this rebuilt will not be automatically triggered without a
bump in the SONAME version of libxml2.

In summary, the introduction of version 2.12 of libxml2 in unstable
will need a proper and coordinated transition.

No, this will still break partial upgrades.


Indeed. First runtime error bug report I got:

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


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:    oor:name=".uno:FontworkShapeType.fontwork-arch-left-po

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Rene Engelhard]

Hi,

Am 07.01.24 um 04:38 schrieb Steve Langasek:

The ordering here would be:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
   flags

- the source packages which need an ABI change
   ("source-packages"+"lfs-and-depends-time_t") and do not already have
   versions in experimental, will have sourceful NMUs to experimental with
   the new binary package names in order to clear binary NEW, in coordination

- once these packages have all cleared binary NEW, the new dpkg defaults
   will be uploaded to unstable


And in the meanwhile in experimental it will be built with the old 
time_t on other architectures.


Since the new dpkg won't be picked up.

Not in the experimental builders unstable+experimental chroots which 
only install experimental packages when Build-Depends: need them.


(For an undefined time given how much the packages later in the chain 
wait in NEW)



Especially on armhf which is affected. Or will you do the source NMUs on 
armhf/i386? (For some packages where some features are disabled on 32bit 
this is probably not a good idea)



Regards,


Rene

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Rene Engelhard]

Hi,

Am 07.01.24 um 02:01 schrieb Steve Langasek:
If you say you are going to fix eventual breakage (and not ignoring 
the test

results!) and if that means fixing asm on all affected archs, then it's OK
:)

Well, yes; though I hope we would see some help from e.g. arm porters if
there were actually breakage of this nature.

Hope doesn't help when it got to the actual problem and this doesn't happen.

  Alternatively, maybe it would
be better to stop shipping libreoffice on 32-bit archs, in that case?  I'm


I'd like to avoid this. Getting rid of i386 is fine, noone needs it, 
armhf is a bit different.


(rpis etc - even though they could run arm64, but..)


not sure how usable libreoffice is these days on such archs.
popcon.debian.org doesn't appear to have the granularity to tell us if there
actually *are* users; and with only 615 armhf popcon reports (vs 215,562 on
amd64) we don't exactly have a statistically significant sample there.


Only recently I got 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059158. Maybe UI is 
not used much, but I can imagine people using it in paperless-ngx or 
other stuff.


I don't really want to bastardize those uses.


- the source packages which need an ABI change
 ("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to

I get that you probably want NMUs for not needing to ping every maintainer,
but this is bad.
That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
when tagged end of next week to not have this caught in the transition. (see
also below for the comment about new upstream versions in experimental.)

What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?

If at all - *both*. At the same time.

Most of these packages that are staged in experimental are going to be there
because of library transitions...


And ignore those who use experimental as a testbed of major new 
upstreams? Doesn't sound good.



 experimental with the new binary package names in order to clear binary
 NEW, in coordination

And what about skipped ones?  When will those be tried?

What do you mean here by "skipped ones"?

https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt
(which incidentially contains libreoffice)

Ah!  These are packages that have been omitted from the analysis because
they've been manually identified as packages that don't have C or
C++-compatible header files related to a shared library, and therefore even
if they do need updated for 64-bit time_t, they are not affected by CPPFLAGS
and are not part of this transition.  (I am not 100% sure this is accurate
for ObjC; in any case ObjC headers are impossible to analyze using
abi-compliance-checker so if ObjC libraries are possibly affected, someone
would have to figure out what to do with them.)


I have no idea on how you indentified it In the libreoffice case that is 
not true.



libreoffice-dev-(common) *does* contain C/C++ header files.

And most of them *do* correspond to the libuno* shared packages.

Just that they are not split per library because  that wouldn't really 
make sense since you need any of them anyway.



And I definitely see

e.g. /usr/include/libreoffice/osl/time.h (libuno-sal3)

No idea whether it actually will be broken by the change, but...


I'm not sure precisely why Adrien found it necessary/useful to add
libreoffice-dev to this exclude list,

Probably because he didn't look at the whole but just at  the package

  but I can confirm that it's
reasonable, as this particular package contains only a single header file
with #define's and no function prototypes; so in effect it has been manually
analyzed and determined to be unaffected.


But libreoffice-dev-common not (on which libreoffice-dev depends) which 
contains all the arch-indep headers. Just libreoffice-dev contains one 
header diferent between archs.



Regards,


Rene

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Rene Engelhard]

Hi,

Am 06.01.24 um 06:51 schrieb Steve Langasek:

- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags

[...]
What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?


How does that play together with the needed dpkg only in experimental?

You can't build stuff for unstable involving experimental packages 
(except manually with binary upload, which would block testing migration)



Regards,


Rene

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Rene Engelhard]

Hi Steve,

Am 06.01.24 um 06:51 schrieb Steve Langasek:

- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags

I  think at that point in time one should know what breaks and whatnot.
Archive rebuild?
(Probably in stages)

What kind of breakage are you looking to avoid here?  As mentioned in other

build failures/test failures.

points in the thread, regressions as a result of this change should be rare
and easy to fix.  I do not think it's a good use of time / CPU power to do
test rebuilds for this instead of just landing the transition.


Here especially LibreOffices bridge code worries me.

That one is tied to ABI and calling conventions. I don't see time_t 
mentioned there but "just" in the public libraries (sal), but I am not 
sure what making a type bigger will cause.


(And since already

 - i386 needs gcc-12 to build since otherwise the test fails

 - armhf (and other archs like ppc64el and s390x) need Java disabled[1] 
- without any help from any porter to prevent this - I *do* want to 
avoid breakage here.



If you say you are going to fix eventual breakage (and not ignoring the 
test results!) and if that means fixing asm on all affected archs, then 
it's OK :)




- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to

I get that you probably want NMUs for not needing to ping every maintainer,
but this is bad.
That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
when tagged end of next week to not have this caught in the transition. (see
also below for the comment about new upstream versions in experimental.)

What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?


If at all - *both*. At the same time.

But yes, that could work.

(In this specific case I an worrying that the transition will take some 
time, and that I am stuck with 7.6.x instead of uploading 24.2 when it 
is released.)



libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of
entanglement here is small anyway.
Except in poppler etc. transitions.. But yeah, nothing really uses the 
C++ libs nowadays.

I think the above proposal, to skip packages already in experimental from
the set of uploads to experimental, would address your concern.  It's not as
if there is going to be any time that it's ok to tell maintainers they can't
use experimental at all because we're doing this transition.


experimental with the new binary package names in order to clear binary
NEW, in coordination

And what about skipped ones?  When will those be tried?

What do you mean here by "skipped ones"?


https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt

(which incidentially contains libreoffice)


Regards,


Rene


[1] Ubuntu just ignores the test failures. No, not an option.

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Rene Engelhard]

Hi,

Am 05.01.24 um 09:17 schrieb Steve Langasek:

- Packages that could not be analyzed for whatever reason are still
   assumed to have an ABI that's sensitive to time_t and have to be included
   in the transition.  Happily, due to improvements in this run of the number
   of packages that could successfully be analyzed, the number of libraries
   in this category has dropped from 1541 to 929, of which 69 have no
   reverse-dependencies at all.  The final list of these header packages that
   could not be analyzed is attached, in case anyone still wants to identify
   that a library on this list whose ABI is not affected by time_t and should
   therefore be excluded from the transition.  Note, however, that no effort
   has been made to filter out dev packages from this list that come from
   source packages containing OTHER dev packages that are known to have ABI
   breakage; for a number of the packages listed, further analysis would not
   change the outcome.  (e.g. qt5-qmake failed to be analyzed, but
   qtbase-opensource-src also ships qtbase5-private-dev which shows time_t
   ABI sensitivity.)


[...]


My strawman proposal is to give this thread 2 weeks from today for feedback
and further refinement, and also to further reduce the number of
false-positives included in the transition.  Then, starting on Jan 18:

- dpkg will be uploaded to experimental with 64-bit time_t in the default
   flags


I  think at that point in time one should know what breaks and whatnot. 
Archive rebuild?


(Probably in stages)


- the source packages which need an ABI change
   ("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to


I get that you probably want NMUs for not needing to ping every 
maintainer, but this is bad.


That e.g. would cause me to upload libreoffice 24.2 rc2 to sid 
immediately when tagged end of next week to not have this caught in the 
transition. (see also below for the comment about new upstream versions 
in experimental.)



   experimental with the new binary package names in order to clear binary
   NEW, in coordination


And what about skipped ones?  When will those be tried?

Those also will need clear NEW if needed.

(And they might even FTBFS because the ABI did change and ABI-assuming 
test break? Though I don't assume so for time_t, but if time is passed 
around... I don't assume so, but...


At least that would be the case for libreoffice (and 
libreoffice-dev-common is in the affected set, which means some stuff 
relies on it...))


(Maybe even needing asm fixes)


- once these packages have all cleared binary NEW, the new dpkg defaults
   will be uploaded to unstable

- the sourceful NMUs of the libraries will be reuploaded to unstable
   (without binaries, so that they can be promoted to testing without
   additional uploads).
Please let me know of any problems with this plan.


Also a problem is that experimental also might already contain totally 
unrelated updates like new upstream versions...



Regards,


Rene

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#1059805: clucene-core: please apply LibreOffice patch to alllow not writing random timestamps into generated files, making them unreproducible

[Rene Engelhard]

Hi,

Am 03.01.24 um 16:47 schrieb James Addison:

Source: clucene-core
Followup-For: Bug #1059805
X-Debbugs-Cc: r...@debian.org, thorsten.behr...@allotropia.de

On Mon, 1 Jan 2024 18:24:19 +0100, Rene wrote:

LibreOffice created a patch to clucene to make their help pages
reproducible. Maybe we should include it here? (libreoffice in Debian
uses the system library instead of the embedded copy.)

A possible obstacle with that approach: the libreoffice code invokes the
additional API function to implements this when _not_ configured[1] to use the
system-provided clucene.


I know. :)

That is not really a reason, though. I am  happy to patch it to make it 
work (and build-depend on a matching clucene-core).


AFAICS this doesn't require a runtime dependency here since it writes 
some other value to a field at generation time, which is read anyway in 
the unpatched version even.



Actually  back then when Thorsten proposed it first I said "please make 
it a configure check"...



Regards,


Rene

Bug#1059805: clucene-core: please apply LibreOffice patch to alllow not writing random timestamps into generated files, making them unreproducible

[Rene Engelhard]

Source: clucene-core
Version: 2.3.3.4+dfsg-1.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps randomness
Affects: libreoffice-help-en-us libreoffice-help-ca libreoffice-help-cs 
libreoffice-help-da libreoffice-help-de libreoffice-help-dz libreoffice-help-el 
libreoffice-help-en-gb libreoffice-help-es libreoffice-help-et 
libreoffice-help-eu libreoffice-help-fi libreoffice-help-fr libreoffice-help-gl 
libreoffice-help-hi libreoffice-help-hu libreoffice-help-id libreoffice-help-it 
libreoffice-help-ja libreoffice-help-km libreoffice-help-ko libreoffice-help-nl 
libreoffice-help-om libreoffice-help-pl libreoffice-help-pt 
libreoffice-help-pt-br libreoffice-help-ru libreoffice-help-sk 
libreoffice-help-sl libreoffice-help-sv libreoffice-help-tr libreoffice-help-vi 
libreoffice-help-zh-cn libreoffice-help-zh-tw

Dear Maintainer,

LibreOffice created a patch to clucene to make their help pages
reproducible. Maybe we should include it here? (libreoffice in Debian
uses the system library instead of the embedded copy.)

See
https://cgit.freedesktop.org/libreoffice/core/patch/?id=ff071078ee5f13f0e9d430d6783444a631d232a0
(clucene-reprobuild.patch.1)

which adds a new method setting the "start position" (which then is used
in libreoffice to consistently set it 0)

Regards,

Rene

Bug#1059535: transition: abseil

[Rene Engelhard]

Hi,

Am 27.12.23 um 19:15 schrieb Benjamin Barenblat:

Although doing a transition now will break some packages in sid, I
believe waiting is likely to cause more issues. Upstreams (LibreOffice
in particular) are starting to use features from the new version of
Abseil,


Actually it's not LibreOffice but LibreOffice indirectly via pdfium 
(which makes chromium also be affected if it did build without using the 
embedded copy of abseil).



That said libreoffice builds (both sids and experimentals version). 
Tested on amd64 only, but



Regards,


Rene

Bug#1059040: libxml2: ABI change? (undefined references)

[Rene Engelhard]

Hi,

Am 25.12.23 um 22:57 schrieb Rene Engelhard:
I didn't file it for the plain build issue. Nevertheless, if it broke so 
many projects you probably should do a full-fledged rebuild and send 


Well, mitigated by 2.12.3, but still.

But again, this is completely off-topic to what I filed in this bug 
which is the ABI break.


Which *maybe* could be ignored. Maybe one can do Breaks: after a rebuild 
(then you might get a problem inbetween only when in this case 
libreoffice is to be rebuilt. But here libreoffice fails its tests even).


But not until one knows what is affected.

*You* need to do a test as the library maintainer/the one who wants to 
update it, not me.


Regards,

Rene

Bug#1059040: libxml2: ABI change? (undefined references)

[Rene Engelhard]

Hi,

Am 25.12.23 um 22:33 schrieb Rene Engelhard:

The tests are still failing and there is no patch anywhere yet, see


Sorry, link got lost: 
https://bugs.documentfoundation.org/show_bug.cgi?id=158423


and c) you ignore the actual issue here at hand and that is that the new 
libxml2 breaks the ABI, causing at least libxmlsec to be needed to be 
rebuilt.


I didn't file it for the plain build issue. Nevertheless, if it broke so 
many projects you probably should do a full-fledged rebuild and send 
patches before uploading to unstable and putting this on all maintainers 
(or by making them get a FTBFS bug by Lucas once a rebuild happens at 
which time people won't remember the libxml2 update)


In any case, *this* bug is about the ABI change: removed 
symbols/versions other stuff relies on.


Long story short: libxml2 2.12 has still a long road to go with much 
work on your side until you can upload it to unstable.


Regards,

Rene

Bug#1059040: libxml2: ABI change? (undefined references)

[Rene Engelhard]

Hi,

Am 25.12.23 um 16:31 schrieb Aron Xu:

Hi Rene,

On Wed, Dec 20, 2023 at 3:39 AM Rene Engelhard  wrote:

Am Tue, Dec 19, 2023 at 08:03:56PM +0100 schrieb Rene Engelhard:

LibreOffice builds (patch available), but doesn't yet build with 2.12.

"... but doesn't yet succeed the tests with 2.12"


That didn't change, see below.

[...]


Do we have removed symbols/removed versions here? (libxmlsec.so.1 was
not rebuilt)

After a rebuild of libxmlsec1 this link succeeds...


I see that you've committed this patch[1] to libreoffice, does this


Which is the above patch I mentioned to fix the *BUILD* with libxml2. 
After that applied I ran into the issue which resulted in thig bug 
report (see below in c))


The tests are still failing and there is no patch anywhere yet, see


It would actually be helpful to read because that one is said a) here 
and b) in the commit ("|Only the build, not the tests (yet)!")|



mean I can proceed to upload this version of libxml2 to unstable
without further action? Or is there anything else I should coordinate
with you to prevent breakage?


and c) you ignore the actual issue here at hand and that is that the new 
libxml2 breaks the ABI, causing at least libxmlsec to be needed to be 
rebuilt.



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