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 again,

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


OK, so discussion on IRC gave:

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

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

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

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

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

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

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

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

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

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

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

20:16 < tumbleweed> that's OK

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


Will be fixed in next experimental upload.

Regards,

Rene

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

[Rene Engelhard]

Hi,

Am 10.03.24 um 19:44 schrieb Rene Engelhard:


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


to be precise.


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


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

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

 endif

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

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

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

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

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

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

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

+        debian/python3-scriptforge/$(PYTHON_SITE)

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

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

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

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

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

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

[Rene Engelhard]

Hi,

Am 10.03.24 um 19:44 schrieb Rene Engelhard:


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


to be precise.


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


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

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

 endif

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

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

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

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

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

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

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

+        debian/python3-scriptforge/$(PYTHON_SITE)

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

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

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

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

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

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

[Rene Engelhard]

tag 1065893 - ftbfs

tag 1065893 + moreinfo

thanks


Hi,

Am 10.03.24 um 18:49 schrieb Graham Inggs:

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

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

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

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

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


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



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


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


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


and similar stuff in upstreams configure.


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



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

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

>>>

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


$ debuild -Pnogir

[...]

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


[...]

in upstreams configure.


I think this bugreport is too early.


Regards,


Rene

Bug#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

Re: 32 bit build failure (smb, narrowing)

[Rene Engelhard]

Hi,

Am 08.03.24 um 08:23 schrieb Rene Engelhard:
Can you have a look, please? I had a brief one, but that is a simple 
define which shoudln't break. Then the switch does

     switch (aFileStatFs.f_type) {
which uses
     struct statfs aFileStatFs;

So it probably is a type difference in the kernel struct already for 32 
vs 64 bit?


Obviously I am too blind, there is even a if comparison before:

/* get filesystem info */
struct statfs aFileStatFs;
if (statfs(path.getStr(), ) < 0)

But as gcc complains about the (usage of the) define I don't guess 
that's it?


Regards,

Rene

32 bit build failure (smb, narrowing)

[Rene Engelhard]

Hi,

see 
https://buildd.debian.org/status/fetch.php?pkg=libreoffice=i386=4%3A24.2.2~rc1-1=1709881487=1:


/<>/sal/osl/unx/file.cxx: In function ‘void 
osl_file_adjustLockFlags(const rtl::OString&, int*, sal_uInt32*)’:
/<>/sal/osl/unx/file.cxx:71:26: error: narrowing conversion 
of ‘4283649346’ from ‘unsigned int’ to ‘int’ [-Wnarrowing]

   71 | #define CIFS_SUPER_MAGIC 0xFF534D42
  |  ^~
/<>/sal/osl/unx/file.cxx:795:14: note: in expansion of 
macro ‘CIFS_SUPER_MAGIC’

  795 | case CIFS_SUPER_MAGIC:
  |  ^~~~
/<>/sal/osl/unx/file.cxx:72:26: error: narrowing conversion 
of ‘4266872130’ from ‘unsigned int’ to ‘int’ [-Wnarrowing]

   72 | #define SMB2_SUPER_MAGIC 0xFE534D42
  |  ^~
/<>/sal/osl/unx/file.cxx:796:14: note: in expansion of 
macro ‘SMB2_SUPER_MAGIC’

  796 | case SMB2_SUPER_MAGIC:
  |  ^~~~
make[2]: *** [/<>/solenv/gbuild/LinkTarget.mk:340: 
/<>/workdir/CxxObject/sal/osl/unx/file.o] Error 1


This is due to

commit a8814b5921676b1c01a19b0af243712c55fb0307
Author: Kevin Ottens 
Date:   Fri Feb 2 15:39:36 2024 +0100

tdf#55004 Fix backup copy creation for files on mounted samba shares

There is an unfortunate interaction between file locking and backup
creation at save time.

openFilePath has logic to lock a file when opening. This goes through
fcntl to set a write lock on the file. Later on, when the user wants to
save changes, a backup copy might be created (very likely now since 
this

is the defaults in the settings). To create this backup, the file is
opened again for reading. Unfortunately this open call fails due to the
lock (even though it is a write lock).

This commit changes the behavior. osl_file_adjustLockFlags now 
checks if

the file is on a mounted samba share. If that's the case we force the
osl_File_OpenFlag_NoLock flag. No issue is then exhibited at backup
creation, allowing the save to proceed properly.

Change-Id: Ieab252f9f68598834e13339fc5fcea440f0a4c2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162935
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 
(cherry picked from commit 63efbc8ad8aae12b54e649c1495d1233c1a9b33f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163549

Can you have a look, please? I had a brief one, but that is a simple 
define which shoudln't break. Then the switch does

switch (aFileStatFs.f_type) {
which uses
struct statfs aFileStatFs;

So it probably is a type difference in the kernel struct already for 32 
vs 64 bit?


Regards,

Rene

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Hi,

Am 08.03.24 um 00:12 schrieb Eric Valette:

On 07/03/2024 21:16, Rene Engelhard wrote:
ct more people.


But not so much for dependency issues like this. Which is my sole 
point. In 99,9% of cases this won't even migrate to testing. And 
unstable won't be released - testing will.


What is your point? Without known bugs or new versions packages 
migrate from unstable to testing automatically.




You should be happy people debug code


*debug code*, yes. debug *actual* (dependency) issues, yes.


I did my part for example with this one, that maintainer denied first 
but fixed later in his next upload as suggested...


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


Well, you haven't seen the various discussion how to fix smbclient on IRC...

Not really. This is an affect of

   * d/genshlibs: run dh_makeshlibs on libsmbclient0
 (Closes: #1065349)

where the side effect is that one gets the provides via

Package: libsmbclient0
Provides: ${t64:Provides}
X-Time64-Compat: libsmbclient

That is the correct fix (with a similar result of what you suggests), 
not what you suggested in the first mail, though.


Besides that your wrote:

You cannot install libsmbclient0 without breaking libsmbclient if the
version of libsmbclient is not at least 2:4.19.5+dfsg-3. It will then
replace libsmbclient.

BUT the package libsmbclient 2:4.19.5+dfsg-3 is never going to be
generated nor latter versions unless the names change back to
libsmbclient. So the condition will never happen.

That is plain wrong. Breaks: is not waiting for anything be there. It's 
just a lesser version of Conflicts


> And as you state, if the time_t type is already 64 bits why should

package depending on libsmbclient need to be regenerated?

Here again you show that you don't get why this is done at all. And you 
again ignore release archs in your reasoning completely.


(Whether one likes that those are release archs or not, is not relevant 
here.):



Exactly because of armel/armhf where the time_t was not 64bit before.

libsmbclient r-deps *have* to be rebuilt. On armel/armhf for sure. For 
the rest there's Provides:



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Am 08.03.24 um 00:12 schrieb Eric Valette:

On 07/03/2024 21:16, Rene Engelhard wrote:
ct more people.


But not so much for dependency issues like this. Which is my sole 
point. In 99,9% of cases this won't even migrate to testing. And 
unstable won't be released - testing will.


What is your point? Without known bugs or new versions packages 
migrate from unstable to testing automatically.


Except if their dependencies break in testing. Or dependencies of other 
packages are broken by migrating.


That is something the testing scripts check - amongst other stuff.


Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Hi,

Am 07.03.24 um 21:07 schrieb Eric Valette:

On 07/03/2024 20:55, Rene Engelhard wrote:

unstable is unstable. Don't use it if you can't handle stuff like 
this. And yes, be it even for more days or however it takes.



The usual mantra. However, if no one use unstable and debug it to make 
it work correctly, maintainers will discover existing bug very late in 
the process and they will impact more people.


But not so much for dependency issues like this. Which is my sole point. 
In 99,9% of cases this won't even migrate to testing. And unstable won't 
be released - testing will.




You should be happy people debug code


*debug code*, yes. debug *actual* (dependency) issues, yes.

Insisting on (bogus) bug reports about dependency issues out of 
maintainer control which will "magically" be solved once the release 
team does the required bin-NMU: no.



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Hi,

Am 07.03.24 um 20:33 schrieb Eric Valette:
On 07/03/2024 19:58, Rene Engelhard wrote: 


> My point also was  that your reopening of the bug is wrong since the 
maintainer can't do anything about it.
E.g. if libreoffice wasn't rebuilt against most t64 r-deps since it a) 
also has libraries needing the rename which I b) did when the transition 
starts c) had a new release anyway. If that did't happen and LO wasn't 
rebuilt for the t64 libraries it now needs I'd have reacted the same way 
as for the bug you reopened. Can't do anything about that, the binNMUs 
will happen somwehen when ready.




And you probably need to get out of your amd64 bubble, see below


My "bubble" probably represent in volume 99% of debian 
users/installations so that is a big bubble! 
True. My laptop also is one (but incidentially runs stable as main 
system until the freeze when it will start running testing. rinse and 
repeat). I personally have a sid only in said sid VM.
I admit that unstable installation volume is far less than stable but 
the proportion of people using unstable on arm/xxx is probably 
identical as stable.


I don't think so, actually.  It's probably lesser on sid for arm than 
the stable vs. unstable ratio of amd64. But it doesn't really matter 
anyway. arm* is release architectures and so need to get the rebuilds 
anyway at some time.
I completely can understand that the RT doesn't do those bin-NMUs per 
arch (when?) but just when it's actually ready.


Well well, you annoy 99% of unstable debian users. 


unstable is unstable. Don't use it if you can't handle stuff like this. 
And yes, be it even for more days or however it takes.



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Am 07.03.24 um 19:21 schrieb Eric Valette:

On 07/03/2024 18:57, Rene Engelhard wrote:

That one is tracked and will get appropriate bin-NMUs from  the 
release team, I am sure.


It is right that this uninstallability is "being part of the normal 
things due to transition".



I'm sure it will be done at some point. However, I just point out that 
on amd64


Maybe, though in my sid VM with all tasks installed plasma-workspace 
fails to upgrade, claiming about gdb-minmal | gdb not to be installed 
whereas both of that install, but that doesn't help it futher. Didn't 
debug, no KDE person.


My point also was  that your reopening of the bug is wrong since the 
maintainer can't do anything about it. He will not schedule the bin-NMU 
(actually can't, and a manual binary only build will just make it 
blocked from entering testing, requiring a bin-NMU _again_). As he said 
it IS "being part of the normal things due to transition".


Even if it it like that for a week now or longer.


And you probably need to get out of your amd64 bubble, see below

this is the last set of packages that are uninstallable currently on 
all my systems (except the one when i manually edited the control 
file) and this has been so since 29 february.


And I guess it will be for some longer since the archs where t64 
actually matters (armel/armhf) has most of the affected packages not 
being rebuilt since it's stuck behind uninstallable stuff and needs 
manual bootstrap uploads.



I completely can understand that the RT doesn't do those bin-NMUs per 
arch (when?) but just when it's actually ready.



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Am 07.03.24 um 09:55 schrieb Eric Valette:

On 07/03/2024 07:25, Kevin Bowling wrote:


As of this evening these are the packages that currently have broken
deps on amd64 for me:
gstreamer1.0-plugins-good gstreamer1.0-pulseaudio
libkf5akonadisearch-bin libkf5akonadisearch-plugins occt-misc



Someone already opened a bug for libkf5akonadisearch-bin 
libkf5akonadisearch-plugins that has been closed as "being part of the 
normal things due to transition" but I reopened it as:


The maintainer transitionned the "abi name" to "abi name"t64 but many 
package still depend on old "abi name" and are not going to be rebuild 
unless someone force it.



https://release.debian.org/transitions/html/auto-akonadi-search.html


That one is tracked and will get appropriate bin-NMUs from  the release 
team, I am sure.


It is right that this uninstallability is "being part of the normal 
things due to transition".



Regards,


Rene

Bug#1065461: marked as pending in libreoffice

[Rene Engelhard]

Control: tag -1 pending

Hello,

Bug #1065461 in libreoffice reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/6bf7040a13e3693e23a356f5aeff0121620c2ac0


rm -f $(PKGDIR)-common/$(OODIR)/presets/database/evolocal.odb id 
ENABLE_EVOAB!=y (closes: #1065461)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065461

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

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

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

Re: unexpected riscv64 build success on buildd / NaN payload

[Rene Engelhard]

Hi,

Am 27.02.24 um 19:26 schrieb Rene Engelhard:
Then I more wonder why it failed the test on -03 and "worked" on -05 now 
where the difference is just -O0 vs. -O2.


I did "quick" tests (with some "shortcut" hacks to get the test ran 
without building everything).


Anyways:

Indeed:

- milkv: O2 "works", O0 fails
- ricci: O2 "works", O0 fails

I could swear in my tests before I did enable O2 in the experimental 
upload it also failed there.


I guess gcc did change

Reverting that change (O0 is closer to Os which is in the upstream 
makefile anyway) for now to be sure. I am totally not sure that keeping

O2 here and thus having the test pass is a good idea, especially since
if the hardware does not have that feature. Does it?

@admin, @wb-team: nevermind
Rest should probably be done in -riscv.

Regards,

Rene

Bug#1064890: marked as pending in xmlsec1

[Rene Engelhard]

Control: tag -1 pending

Hello,

Bug #1064890 in xmlsec1 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/xml-sgml-team/xmlsec1/-/commit/7b889d09d445ea288d713da3c3342f46df51067f


dh_installexamples -plibxmlsec1-dev (closes: #1064890)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1064890

Bug#1064890: marked as pending in xmlsec1

[Rene Engelhard]

Control: tag -1 pending

Hello,

Bug #1064890 in xmlsec1 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/xml-sgml-team/xmlsec1/-/commit/7b889d09d445ea288d713da3c3342f46df51067f


dh_installexamples -plibxmlsec1-dev (closes: #1064890)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1064890

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

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

Re: unexpected riscv64 build success on buildd / NaN payload

[Rene Engelhard]

Hi,

Am 27.02.24 um 19:05 schrieb Aurelien Jarno:

On 2024-02-27 10:59, René Engelhard wrote:

Is rv-osuosl-05 hardware which supports this? (db.debian.org/machines.cgi doesn't really 
shed any light here; they all say "Hifive Unmatched").

Just running a build on my machine again, too.


All riscv64 buildds and porterbox, including rv-osuosl-05, are using
Hifive Unmatched boards as the LDAP says:
https://www.sifive.com/boards/hifive-unmatched


Yeah, I got that...


Nothing has changed recently on the hardware side.


So there is no actual difference between 03 and 05? Interesting...

Then I more wonder why it failed the test on -03 and "worked" on -05 now 
where the difference is just -O0 vs. -O2.


Just trying on ricci, too.

Regards,

Rene

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

[Rene Engelhard]

Source: libreoffice

Version: 4:24.2.0-1

Severity: serious

Control: close -1 4:24.2.0-3


Am 23.02.24 um 17:14 schrieb Rene Engelhard:

Hi,

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

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


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


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


Making a (RC) bug out of this.


Regards,


Rene

Bug#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#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

Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit? (part 2)

[Rene Engelhard]

Hi,

Am 14.02.24 um 15:50 schrieb Escuelas Linux:
Running 'make' alone fails because all warnings are treated as errors, 
so I added the following parameters



make CFLAGS="-Wno-error" CXXFLAGS="-Wno-error -g1"



Again: --disable-werror.

No need to fiddle with CFLAGS/CXXFLAGS to add -Wno-error.



However, it still stops with the following error:



(snip)

We use system-coin*. (As you did later too which disabled  this 
third-party module). And yes, that one might  have include fixes etc., 
didn't check but pretty likely.




(mdds)


So I copied the newly created mdds folder to liborcus with


cp -r mdds/ 
/home/linux/Downloads/libreoffice-24.2.0.3/workdir/UnpackedTarball/liborcus/src/liborcus/



Interesting. I use system-mdds and system-orcus BUT for 
bookworm-backports I do use internal ones (since it needs newer ones not 
in stable) and this just works, too.


[...]

(coin again)



And appeared a lot of errors that look like:


-

rdf_model.c:1891:17: error: invalid use of incomplete typedef 
'librdf_model' {aka 'struct librdf_model_s'}


1891 | return model->factory->transaction_get_handle(model);


rdfinit.c:162:10: error: invalid use of incomplete typedef 
'librdf_world' {aka 'struct librdf_world_s'}


162 | world->genid_base = 1;

-


Now I installed librdf0-dev and its dependencies, and added the 
following lines to autogen.input:



--with-system-redland


As you probably guessed we do that also ;)


And if there is build fixes (also for 32bit) those packages get it. As 
upstream doesn't do 32bit builds anymore I am quite sure (and we see 
this) that the internal modules might get  problems with that.


Regards,


Rene

Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit? (part 2)

[Rene Engelhard]

Hi,

Am 14.02.24 um 17:48 schrieb Rene Engelhard:

Am 14.02.24 um 17:40 schrieb Rene Engelhard:
lobasis is a totally nonsensical name to begin with, exposing 
internals (basis what?) to the public noone needs.




More accurate: Once-have-been internals. There one was a oobasis 
directory in OOo. That's where the name get cargo-culted over.


See 
https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep=basis=50 :)


And I never saw the reason why more -coreXY packages (except maybe epm 
limits?)


Regards,

Rene

Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit? (part 2)

[Rene Engelhard]

Hi,

Am 14.02.24 um 17:40 schrieb Rene Engelhard:
lobasis is a totally nonsensical name to begin with, exposing internals 
(basis what?) to the public noone needs.


NO distro calls their packages, ebuilds or whatever lobasis. Neither do 
they come out of LOs build system directly (as those packages do). So 
this question doesn about why it's not called lobasis doesn't really 
make sense.


As I said: the name of the software if LibreOffice -> libreoffice for 
package names (which are defined to be lowercase.).


Regards,

Rene

Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit? (part 2)

[Rene Engelhard]

Hi,

Am 14.02.24 um 17:04 schrieb Escuelas Linux:

[ the LO .debs date after Debian did packages and that was carried over 
since ever. oobasisX.Y was done in some OOo time when they thougt they 
should do some "debs", after which they just shipped rpms you needed to 
use alien for ]


Just one more question. Why are the Debian packages of LibreOffice so 
different from the packages produced by the LO source? LO produces a 
bunch of libobasis* packages, while Debian does not offer a single 
libobasis* package, and they do not even match in name or even 
apparent purpose with those produced by LO source.


libreoffice-core


lobasis is a totally nonsensical name to begin with, exposing internals 
(basis what?) to the public noone needs.



Besides that the software is called libreoffice and not lobasis ;) (It 
contains lo, yes, but...)


Perhaps Debian uses LO source as a base, but also manages a custom 
layer to build its deb packages differently? If so, what would be the 
advantages of the Debian packages over the ones generated by LO source?


Integration. Proper packaging. (LO has no "real" packages, it has "stuff 
just packed up in .deb format). Proper dependencies where needed. Lesser 
duplication/getting security fixes directly instead of getting them in a 
later release by syncing third-party libs by just having it use the 
system version of the lib.


More architectures supported (as you say yourself, no i386 there, no 
arm32, ..)


And stuff Debian policy mandates which upstream doesn't do :)


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

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

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

Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit?

[Rene Engelhard]

Hi agai,

Am 08.02.24 um 06:37 schrieb Rene Engelhard:

[...] Debian. LTO works.


Need to correct myself on this. LTO actually is disabled ...
And because of exactly this case I (also) don't use --enable-mergelibs 
on 32bit architectures.


... because of this (since for each of the individual libraries it does 
not really make sense, does it?)


Regards,


Rene

Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit? (part 2)

[Rene Engelhard]

Hi,

please don't break threads.

Am 10.02.24 um 00:53 schrieb Escuelas Linux:


-"Debian still ships LibreOffice on 32bit archs, as do other 
distributions."



Oh! Thanks for the tip! I was not aware that Debian even has binary 
LibreOffice 24.2 32-bit packages, albeit in the unstable branch.



You should check.

Also in testing and even for bookworm-backports:

https://packages.debian.org/search?suite=bookworm-backports=libreoffice


-"I do -g1 in Debian. LTO works".


Where should I add the -g1 parameter?


There once was --enable-symbols=SMALL. Once was dropped upstream, I 
added it back and use that one:


https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/patches/debian-debug.diff?ref_type=heads 
together with


https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules?ref_type=heads#L1015 
and


https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules?ref_type=heads#L1046


So Setting CXXFLAGS appropriately should just work.

-"And somehow the testtools bridgetest fails when building with gcc >= 
13, 12 works. Haven't found a solution yet.)"



I'm using gcc 13! Maybe this could be the cause of my compilation 
failures?



No, yours is the 4GB limit.

Which also is the case with PAE since that (ttbomk) does NOT affect how 
many memory *one process* has available.


Just that the system itself can handle more.


Regards,


Rene

Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit?

[Rene Engelhard]

Hi again,


more info:

Am 08.02.24 um 06:37 schrieb Rene Engelhard:

Hi,

Am 07.02.24 um 20:49 schrieb Dan Horák:

On Wed, 7 Feb 2024 12:51:06 -0600
Escuelas Linux  wrote:

  The release notes for the latest version of LibreOffice (24.2) 
state that



"The minimum requirements for building and running LibreOffice on Linux
have been raised from Red Hat Enterprise Linux 7/CentOS 7 to Red Hat
Enterprise Linux 8/CentOS 8 (or equivalent)".


Since Red Hat/CentOS 8 does not have a 32-bit edition, I wonder if my
problems compiling for 32-bit are due to a possible lack of support.


There is no upstream proactive 32bit testing since longer before that 
baseline bump. (Stuff I report once in a while get fixed, though, 
usually).


Debian still ships LibreOffice on 32bit archs, as do other distributions.


https://buildd.debian.org/status/fetch.php?pkg=libreoffice=i386=4%3A24.2.0-1=1706716725=0


make check fails. I do a minimal set (testtools bridgetest, smoketest, 
sal, the other public libraries) to at least not get something 
fundamentally broken.


https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules?ref_type=heads#L2444

(And somehow the testtools bridgetest fails when building with gcc >= 
13, 12 works. Haven't yet found a solution.)



Regards,


Rene

Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit?

[Rene Engelhard]

Hi,

Am 07.02.24 um 20:49 schrieb Dan Horák:

On Wed, 7 Feb 2024 12:51:06 -0600
Escuelas Linux  wrote:


  The release notes for the latest version of LibreOffice (24.2) state that


"The minimum requirements for building and running LibreOffice on Linux
have been raised from Red Hat Enterprise Linux 7/CentOS 7 to Red Hat
Enterprise Linux 8/CentOS 8 (or equivalent)".


Since Red Hat/CentOS 8 does not have a 32-bit edition, I wonder if my
problems compiling for 32-bit are due to a possible lack of support.


There is no upstream proactive 32bit testing since longer before that 
baseline bump. (Stuff I report once in a while get fixed, though, usually).


Debian still ships LibreOffice on 32bit archs, as do other distributions.

But it's slowly dying, yes


I have been compiling LibreOffice for Linux 32-bit since the Foundation
stopped releasing 32-bit binaries. I have been able to solve problems,
sometimes on my own, sometimes with the generous help of people on this
very mailing list.

But now I'm stuck.

I am using Debian 12 Bookworm 32-bit as my OS base. I downloaded all the
dependencies asked for on the BuildingOnLinux Foundation wiki.

Since trying to compile 24.2 with a simple 'make' treats all warnings as
errors, I tried using

--disable-werror for configure/autogen.sh

[...]
But it stops at one of the last stages with this message:


"/usr/bin/ld: Error: /tmp/ccDBatVc.ltrans0.ltrans.o(.data.rel.ro) is too
big (0x3ef58 bytes)

/usr/bin/ld: Could not set dynamic section sizes: memory exhausted

collect2: Error: ld returned 1 exit state

make[1]: ***
[/home/linux/Downloads/libreoffice-24.2.0.3/Library_merged.mk:11:
/home/linux/Downloads/libreoffice-24.2.0.3/instdir/program/libmergedlo.so]
Error"


Since I have allocated 12 GB of RAM in the virtual machine, I don't know
why the memory is exhausted.

because 32-bit system means max 4GB of address space for a process and
ld runs as a single process

you can try disabling or reducing the size of debuginfo to reduce the
size of the *.o files if it's used, you can disable LTO and there are
some options for ld to reduce its memory consumption a bit


All correct. I do -g1 in Debian. LTO works.

And because of exactly this case I (also) don't use --enable-mergelibs 
on 32bit architectures.



Regards,


Rene

[Desktop-packages] [Bug 2039021]

[Rene Engelhard]

sorry, works. setting to FIXED again

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/2039021

Title:
  NO-GUI headless convert-to function error in 7.6.1.2 60(Build:2)

Status in LibreOffice:
  Fix Released
Status in libreoffice package in Ubuntu:
  New

Bug description:
  Original bug report to LibreOffice team:
  https://bugs.documentfoundation.org/show_bug.cgi?id=157424

  7.6.1.2 60(Build:2) no-gui version, Ubuntu Server  20.04 LTS gives
  error.

  soffice --headless --convert-to pdf path/to/file --> Error: source
  file could not be loaded

  Ubuntu 20.04 LTS Desktop version has no error with the same version,
  only on Server. The installation difference is libreoffice vs
  libreoffice-nogui. Previous version doesent produces this error:
  7.5.6.2 50(Build:2) work perfect.

  Lots of no-gui version fails in Ubuntu Server 20.04 LTS with "Error:
  source file could not be loaded" message.

  Specific examples:

  - LibreOffice 6.4.7.2 40(Build:2)  --> Same error with xlsx with --convert-to 
html
  - LibreOffice 7.5.3.2 50(Build:2)  --> Same error with xlsx with --convert-to 
html

  !!! Only LibreOffice 7.5.6.2 50(Build:2) works perfectly in both case.
  !!! Example outputs:

  soffice --headless --convert-to pdf teszt.docx
  convert /home/zsolt/teszt.docx -> /home/zsolt/teszt.pdf using filter : 
writer_pdf_Export

  soffice --headless --convert-to html teszt.xlsx
  convert /home/zsolt/teszt.xlsx -> /home/zsolt/teszt.html using filter : HTML 
(StarCalc)

  Fortunately *ppa:libreoffice/libreoffice-still* contains the good
  version so i had to change the repos in all servers

To manage notifications about this bug go to:
https://bugs.launchpad.net/df-libreoffice/+bug/2039021/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 2039021]

[Rene Engelhard]

there's still

[pid 1261847] openat(AT_FDCWD,
"/usr/lib/libreoffice/program/libcuilo.so", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)

in the strace and after installing libreoffice-core the conversion
succeeds.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/2039021

Title:
  NO-GUI headless convert-to function error in 7.6.1.2 60(Build:2)

Status in LibreOffice:
  Confirmed
Status in libreoffice package in Ubuntu:
  New

Bug description:
  Original bug report to LibreOffice team:
  https://bugs.documentfoundation.org/show_bug.cgi?id=157424

  7.6.1.2 60(Build:2) no-gui version, Ubuntu Server  20.04 LTS gives
  error.

  soffice --headless --convert-to pdf path/to/file --> Error: source
  file could not be loaded

  Ubuntu 20.04 LTS Desktop version has no error with the same version,
  only on Server. The installation difference is libreoffice vs
  libreoffice-nogui. Previous version doesent produces this error:
  7.5.6.2 50(Build:2) work perfect.

  Lots of no-gui version fails in Ubuntu Server 20.04 LTS with "Error:
  source file could not be loaded" message.

  Specific examples:

  - LibreOffice 6.4.7.2 40(Build:2)  --> Same error with xlsx with --convert-to 
html
  - LibreOffice 7.5.3.2 50(Build:2)  --> Same error with xlsx with --convert-to 
html

  !!! Only LibreOffice 7.5.6.2 50(Build:2) works perfectly in both case.
  !!! Example outputs:

  soffice --headless --convert-to pdf teszt.docx
  convert /home/zsolt/teszt.docx -> /home/zsolt/teszt.pdf using filter : 
writer_pdf_Export

  soffice --headless --convert-to html teszt.xlsx
  convert /home/zsolt/teszt.xlsx -> /home/zsolt/teszt.html using filter : HTML 
(StarCalc)

  Fortunately *ppa:libreoffice/libreoffice-still* contains the good
  version so i had to change the repos in all servers

To manage notifications about this bug go to:
https://bugs.launchpad.net/df-libreoffice/+bug/2039021/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 2039021]

[Rene Engelhard]

no, sorry, the convert of gpredict (see http://bugs.debian.org/1058653)
still fails with the patch applied

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/2039021

Title:
  NO-GUI headless convert-to function error in 7.6.1.2 60(Build:2)

Status in LibreOffice:
  Confirmed
Status in libreoffice package in Ubuntu:
  New

Bug description:
  Original bug report to LibreOffice team:
  https://bugs.documentfoundation.org/show_bug.cgi?id=157424

  7.6.1.2 60(Build:2) no-gui version, Ubuntu Server  20.04 LTS gives
  error.

  soffice --headless --convert-to pdf path/to/file --> Error: source
  file could not be loaded

  Ubuntu 20.04 LTS Desktop version has no error with the same version,
  only on Server. The installation difference is libreoffice vs
  libreoffice-nogui. Previous version doesent produces this error:
  7.5.6.2 50(Build:2) work perfect.

  Lots of no-gui version fails in Ubuntu Server 20.04 LTS with "Error:
  source file could not be loaded" message.

  Specific examples:

  - LibreOffice 6.4.7.2 40(Build:2)  --> Same error with xlsx with --convert-to 
html
  - LibreOffice 7.5.3.2 50(Build:2)  --> Same error with xlsx with --convert-to 
html

  !!! Only LibreOffice 7.5.6.2 50(Build:2) works perfectly in both case.
  !!! Example outputs:

  soffice --headless --convert-to pdf teszt.docx
  convert /home/zsolt/teszt.docx -> /home/zsolt/teszt.pdf using filter : 
writer_pdf_Export

  soffice --headless --convert-to html teszt.xlsx
  convert /home/zsolt/teszt.xlsx -> /home/zsolt/teszt.html using filter : HTML 
(StarCalc)

  Fortunately *ppa:libreoffice/libreoffice-still* contains the good
  version so i had to change the repos in all servers

To manage notifications about this bug go to:
https://bugs.launchpad.net/df-libreoffice/+bug/2039021/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

core.git: bin/lo-xlate-lang

[Rene Engelhard (via logerrit)]

 bin/lo-xlate-lang |1 +
 1 file changed, 1 insertion(+)

New commits:
commit 82e90e1b2a8873334f1fcd00dde769e45af37b5b
Author: Rene Engelhard 
AuthorDate: Sat Jan 27 18:03:37 2024 +0100
Commit: René Engelhard 
CommitDate: Tue Jan 30 21:03:34 2024 +0100

add hy to bin/lo-xlate-lang

Change-Id: I1205da81fc179affa58478860928e74a501d4c0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162644
Tested-by: René Engelhard 
Tested-by: Jenkins
Reviewed-by: René Engelhard 

diff --git a/bin/lo-xlate-lang b/bin/lo-xlate-lang
index 06530621731a..9b939012e99a 100755
--- a/bin/lo-xlate-lang
+++ b/bin/lo-xlate-lang
@@ -177,6 +177,7 @@ __DATA__
 :am:amharic
 :gug:guarani
 :szl:upper_silesian
+:hy:armenian
 01:en-US:english_american
 03:pt:portuguese
 07:ru:russian

core.git: Branch 'libreoffice-24-2' - bin/lo-xlate-lang

[Rene Engelhard (via logerrit)]

 bin/lo-xlate-lang |1 +
 1 file changed, 1 insertion(+)

New commits:
commit be1a96a9090f7b71598882f6f9a2ac5bf1ce6e58
Author: Rene Engelhard 
AuthorDate: Sat Jan 27 18:03:37 2024 +0100
Commit: Christian Lohmaier 
CommitDate: Mon Jan 29 11:38:07 2024 +0100

add hy to bin/lo-xlate-lang

Change-Id: I1205da81fc179affa58478860928e74a501d4c0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162618
Tested-by: René Engelhard 
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier 

diff --git a/bin/lo-xlate-lang b/bin/lo-xlate-lang
index 06530621731a..9b939012e99a 100755
--- a/bin/lo-xlate-lang
+++ b/bin/lo-xlate-lang
@@ -177,6 +177,7 @@ __DATA__
 :am:amharic
 :gug:guarani
 :szl:upper_silesian
+:hy:armenian
 01:en-US:english_american
 03:pt:portuguese
 07:ru:russian

core.git: desktop/test

[Rene Engelhard (via logerrit)]

 desktop/test/deployment/update/platform/linux_loongarch64.oxt |binary
 desktop/test/deployment/update/platform/linux_riscv64.oxt |binary
 desktop/test/deployment/update/platform/linux_sparc64.oxt |binary
 3 files changed

New commits:
commit 979ec95a0af2457e71b82d50e3fd9c34a3cf7701
Author: Rene Engelhard 
AuthorDate: Tue Jul 11 17:16:54 2023 +0200
Commit: Stephan Bergmann 
CommitDate: Sun Jan 28 19:16:37 2024 +0100

add sparc64, riscv64 and loongarch64 test extensions

forgotten in 3cb45765f2accfa749cc56a087059600ec467f28 and
bc9487f745befde6534fd46058e119256952323d and 
d3625d968901eb93a9680db8d1165f70de3fd64e

Probably academic since none of  those archs will have something in LO
doing online-update anyway, but...

Change-Id: I10bcc909df42ee7f51f2135b60fbb33c135f2554
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 

diff --git a/desktop/test/deployment/update/platform/linux_loongarch64.oxt 
b/desktop/test/deployment/update/platform/linux_loongarch64.oxt
new file mode 100644
index ..3353ea1f0334
Binary files /dev/null and 
b/desktop/test/deployment/update/platform/linux_loongarch64.oxt differ
diff --git a/desktop/test/deployment/update/platform/linux_riscv64.oxt 
b/desktop/test/deployment/update/platform/linux_riscv64.oxt
new file mode 100644
index ..3268e59a3a4a
Binary files /dev/null and 
b/desktop/test/deployment/update/platform/linux_riscv64.oxt differ
diff --git a/desktop/test/deployment/update/platform/linux_sparc64.oxt 
b/desktop/test/deployment/update/platform/linux_sparc64.oxt
new file mode 100644
index ..4bd1afdd6508
Binary files /dev/null and 
b/desktop/test/deployment/update/platform/linux_sparc64.oxt differ

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#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,

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,

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

[Desktop-packages] [Bug 2039021]

[Rene Engelhard]

This is the same as
https://bugs.documentfoundation.org/show_bug.cgi?id=158695

*** This bug has been marked as a duplicate of bug 158695 ***

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/2039021

Title:
  NO-GUI headless convert-to function error in 7.6.1.2 60(Build:2)

Status in LibreOffice:
  Invalid
Status in libreoffice package in Ubuntu:
  New

Bug description:
  Original bug report to LibreOffice team:
  https://bugs.documentfoundation.org/show_bug.cgi?id=157424

  7.6.1.2 60(Build:2) no-gui version, Ubuntu Server  20.04 LTS gives
  error.

  soffice --headless --convert-to pdf path/to/file --> Error: source
  file could not be loaded

  Ubuntu 20.04 LTS Desktop version has no error with the same version,
  only on Server. The installation difference is libreoffice vs
  libreoffice-nogui. Previous version doesent produces this error:
  7.5.6.2 50(Build:2) work perfect.

  Lots of no-gui version fails in Ubuntu Server 20.04 LTS with "Error:
  source file could not be loaded" message.

  Specific examples:

  - LibreOffice 6.4.7.2 40(Build:2)  --> Same error with xlsx with --convert-to 
html
  - LibreOffice 7.5.3.2 50(Build:2)  --> Same error with xlsx with --convert-to 
html

  !!! Only LibreOffice 7.5.6.2 50(Build:2) works perfectly in both case.
  !!! Example outputs:

  soffice --headless --convert-to pdf teszt.docx
  convert /home/zsolt/teszt.docx -> /home/zsolt/teszt.pdf using filter : 
writer_pdf_Export

  soffice --headless --convert-to html teszt.xlsx
  convert /home/zsolt/teszt.xlsx -> /home/zsolt/teszt.html using filter : HTML 
(StarCalc)

  Fortunately *ppa:libreoffice/libreoffice-still* contains the good
  version so i had to change the repos in all servers

To manage notifications about this bug go to:
https://bugs.launchpad.net/df-libreoffice/+bug/2039021/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Re: Ability to further support 32bit architectures

[Rene Engelhard]

Hi,

Am 13.01.24 um 13:59 schrieb rhys:

No.

You are AGAIN assuming what I am talking about.

Maybe because of how you write...

I know the difference between a 32-bit processor and a 64-bit processor.


Obviously you don't. Or at least are not aware about consequences.


Since you still offer 32bit machines of which Debian has enough of. (64 
bit kernel probably but it doesn't matter) where it does not matter at all.



You ignore the stated fact in this thread that on a 32bit processor one 
process can't get more than 3GB or even less of RAM (regardless of what 
memory extension stuff exists).


In  https://lists.debian.org/debian-kernel/2024/01/msg00191.html (where 
the quoting is a problem, one doesn't know what is yours and what not) 
you ignored what YunQiang said in the post you replied to:


https://lists.debian.org/debian-kernel/2024/01/msg00189.html

Quoting again just for you:

"[...] It is about some limitation of 32bit.
2 examples for it:
   1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
   https://en.wikipedia.org/wiki/Year_2038_problem
   2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
   In fact on most system the value is less than 4GiB:
  on intel32, it is 3GiB
  on mips32, it is 2GiB
   But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
   The RAM does install in your Rack, but you can NOT use it.
  https://en.wikipedia.org/wiki/3_GB_barrier

"

And THAT (2.) is the problem here for linking big applications/compile 
units. Not the lack of machines.


And that is a limitation of *the architecture*.

Putting more "32bit machines" on it do not change anything of that 
except that there were more machines which cannot build big stuff.



Regards,


Rene

Re: Ability to further support 32bit architectures

[Rene Engelhard]

Hi,

Am 13.01.24 um 13:59 schrieb rhys:

No.

You are AGAIN assuming what I am talking about.

Maybe because of how you write...

I know the difference between a 32-bit processor and a 64-bit processor.


Obviously you don't. Or at least are not aware about consequences.


Since you still offer 32bit machines of which Debian has enough of. (64 
bit kernel probably but it doesn't matter) where it does not matter at all.



You ignore the stated fact in this thread that on a 32bit processor one 
process can't get more than 3GB or even less of RAM (regardless of what 
memory extension stuff exists).


In  https://lists.debian.org/debian-kernel/2024/01/msg00191.html (where 
the quoting is a problem, one doesn't know what is yours and what not) 
you ignored what YunQiang said in the post you replied to:


https://lists.debian.org/debian-kernel/2024/01/msg00189.html

Quoting again just for you:

"[...] It is about some limitation of 32bit.
2 examples for it:
   1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
   https://en.wikipedia.org/wiki/Year_2038_problem
   2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
   In fact on most system the value is less than 4GiB:
  on intel32, it is 3GiB
  on mips32, it is 2GiB
   But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
   The RAM does install in your Rack, but you can NOT use it.
  https://en.wikipedia.org/wiki/3_GB_barrier

"

And THAT (2.) is the problem here for linking big applications/compile 
units. Not the lack of machines.


And that is a limitation of *the architecture*.

Putting more "32bit machines" on it do not change anything of that 
except that there were more machines which cannot build big stuff.



Regards,


Rene

Re: Ability to further support 32bit architectures

[Rene Engelhard]

Hi,

Am 13.01.24 um 13:59 schrieb rhys:

No.

You are AGAIN assuming what I am talking about.

Maybe because of how you write...

I know the difference between a 32-bit processor and a 64-bit processor.


Obviously you don't. Or at least are not aware about consequences.


Since you still offer 32bit machines of which Debian has enough of. (64 
bit kernel probably but it doesn't matter) where it does not matter at all.



You ignore the stated fact in this thread that on a 32bit processor one 
process can't get more than 3GB or even less of RAM (regardless of what 
memory extension stuff exists).


In  https://lists.debian.org/debian-kernel/2024/01/msg00191.html (where 
the quoting is a problem, one doesn't know what is yours and what not) 
you ignored what YunQiang said in the post you replied to:


https://lists.debian.org/debian-kernel/2024/01/msg00189.html

Quoting again just for you:

"[...] It is about some limitation of 32bit.
2 examples for it:
   1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
   https://en.wikipedia.org/wiki/Year_2038_problem
   2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
   In fact on most system the value is less than 4GiB:
  on intel32, it is 3GiB
  on mips32, it is 2GiB
   But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
   The RAM does install in your Rack, but you can NOT use it.
  https://en.wikipedia.org/wiki/3_GB_barrier

"

And THAT (2.) is the problem here for linking big applications/compile 
units. Not the lack of machines.


And that is a limitation of *the architecture*.

Putting more "32bit machines" on it do not change anything of that 
except that there were more machines which cannot build big stuff.



Regards,


Rene

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

[Rene Engelhard]

tag 1060255 + unreproducible

tag 1060255 + moreinfo

thanks


Hi,

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

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

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

does not display correctly.


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



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


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

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

[Rene Engelhard]

tag 1060255 + unreproducible

tag 1060255 + moreinfo

thanks


Hi,

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

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

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

does not display correctly.


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



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


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

Bug#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 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

Re: 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 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

Re: 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,

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

Re: 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 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.

Re: 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#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

Re: 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#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

core.git: configure.ac

[Rene Engelhard (via logerrit)]

 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit a9008aa942c1f98f8b00b2bd2f73edc576713e92
Author: Rene Engelhard 
AuthorDate: Mon Jan 1 18:13:20 2024 +0100
Commit: Thorsten Behrens 
CommitDate: Mon Jan 1 23:28:32 2024 +0100

update LIBO_THIS_YEAR

Change-Id: I023baa2238c6cdbbd54a7e6b0fcdb128510bbd4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161522
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens 

diff --git a/configure.ac b/configure.ac
index 1c2a9c86cf5e..737ad29d7364 100644
--- a/configure.ac
+++ b/configure.ac
@@ -520,7 +520,7 @@ AC_DEFINE_UNQUOTED(LIBO_VERSION_MICRO,$LIBO_VERSION_MICRO)
 AC_DEFINE_UNQUOTED(LIBO_VERSION_PATCH,$LIBO_VERSION_PATCH)
 
 git_date=`git log -1 --pretty=format:"%cd" --date=format:'%Y' 2>&/dev/null`
-LIBO_THIS_YEAR=${git_date:-2023}
+LIBO_THIS_YEAR=${git_date:-2024}
 AC_DEFINE_UNQUOTED(LIBO_THIS_YEAR,$LIBO_THIS_YEAR)
 
 dnl ===

core.git: Branch 'libreoffice-24-2' - configure.ac

[Rene Engelhard (via logerrit)]

 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit a63480d6e5f11bd258431e1cfbb98c594ce4a741
Author: Rene Engelhard 
AuthorDate: Mon Jan 1 18:13:20 2024 +0100
Commit: Thorsten Behrens 
CommitDate: Mon Jan 1 23:28:47 2024 +0100

update LIBO_THIS_YEAR

Change-Id: I023baa2238c6cdbbd54a7e6b0fcdb128510bbd4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161419
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens 

diff --git a/configure.ac b/configure.ac
index d841c7cc76fa..ef27ed166df5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -520,7 +520,7 @@ AC_DEFINE_UNQUOTED(LIBO_VERSION_MICRO,$LIBO_VERSION_MICRO)
 AC_DEFINE_UNQUOTED(LIBO_VERSION_PATCH,$LIBO_VERSION_PATCH)
 
 git_date=`git log -1 --pretty=format:"%cd" --date=format:'%Y' 2>&/dev/null`
-LIBO_THIS_YEAR=${git_date:-2023}
+LIBO_THIS_YEAR=${git_date:-2024}
 AC_DEFINE_UNQUOTED(LIBO_THIS_YEAR,$LIBO_THIS_YEAR)
 
 dnl ===

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