[SRU] libreoffice 7.6.4 for mantic

[Rico Tzschichholz]

[Impact]

 * LibreOffice 7.6.4 is in its forth bugfix release of the 7.6 line:
     https://wiki.documentfoundation.org/ReleasePlan/7.6#7.6.4_release

 * Version 7.6.2 is currently released in mantic. For a list of fixed bugs compared to 7.6.2 see the list of bugs fixed in the release candidates of 7.6.4 (that's a total of 157 bugs):
     https://wiki.documentfoundation.org/Releases/7.6.3/RC1#List_of_fixed_bugs
     https://wiki.documentfoundation.org/Releases/7.6.3/RC2#List_of_fixed_bugs
     https://wiki.documentfoundation.org/Releases/7.6.4/RC1#List_of_fixed_bugs

     7.6.4 RC1 is identical to the 7.6.4 release

 * Given the nature of the project, the complexity of the codebase and the high level of quality assurance upstream, it is preferable to SRU a minor release rather than cherry-pick selected bug fixes.

[Testing]

 * Upstream testing. Bugs fixed upstream typically include unit/regression tests, and the release itself is extensively exercised (both in an automated manner and manually).

  * A recent set of upstream's automated jenkins testing can be found here:
    https://ci.libreoffice.org/job/gerrit_76/1558/

  * More information about the upstream QA testing can be found here:
    * Automated tests
      https://wiki.documentfoundation.org/QA/Testing/Automated_Tests
    * Automated UI tests
      https://wiki.documentfoundation.org/Development/UITests
    * Regression tests
      https://wiki.documentfoundation.org/QA/Testing/Regression_Tests
    * Feature tests
      https://wiki.documentfoundation.org/QA/Testing/Feature_Tests

 * Launchpad testing. The libreoffice packages include autopkgtests that were run and verified as passing.
    Tested build can be found at https://launchpad.net/~ricotz/+archive/ubuntu/ppa/+sourcepub/15417677/+listing-archive-extra
    * [amd64] https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-ricotz-ppa/mantic/amd64/libr/libreoffice/20231208_113305_ce7d3@/log.gz
    * [arm64] https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-ricotz-ppa/mantic/arm64/libr/libreoffice/20231208_181454_f665b@/log.gz
    * [armhf] ... (autopkgtests infra problems on this arch)
    * [ppc64el] https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-ricotz-ppa/mantic/ppc64el/libr/libreoffice/20231208_140510_db345@/log.gz
    * [riscv64] not available
    * [s390x] https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-ricotz-ppa/mantic/s390x/libr/libreoffice/20231208_142154_9eaf6@/log.gz
 * General smoke testing of all the applications in the office suite were carried out by going through the manual testplan as documented by: https://wiki.ubuntu.com/Process/Merges/TestPlans/libreoffice

[Regression Potential]

 * A minor release with a total of 157 bug fixes always carries the potential for introducing regressions, even though it is a bugfix-only release, meaning that no new features were added, and no existing features were removed.

 * A combination of autopkgtests and careful smoke testing as described above should provide reasonable confidence that no regressions sneaked in.

[Mauricio Faria de Oliveira (mfo)]

Hi Rico,

Thanks for the nice and detailed SRU template, and all the testing.

While looking at this, particularly the changes in the packaging,
there are a few points that seem to warrant clarification, since
are apparently not related/supporting the upstream bug fixes, or
are not justified as to why included in a SRU (ie, which issues
or bugs are being addressed).

I checked most of these points with Andreas yesterday, and he too
agreed more details would be required before proceeding with this.

Could please address the points below? That's very appreciated.

Thanks again for all the effort on this!

cheers,
Mauricio

...

Changes:

$ debdiff libreoffice_7.6.2-0ubuntu1.dsc libreoffice_7.6.3-0ubuntu0.23.10.1.dsc | filterdiff -i '*/debian/*'

There are some changes in debian/ that may warrant some clarification
as they do not fit into the SRU policy for minor release updates
(ie, bug-fix only) or to be related to the bugs fixed by upstream
(ie, to support a bug-fix).

I've looked for similarities in the changelog of previous releases,
but apparently haven't found them as precedents. This is the first
time I'm looking at this package, so I might be missing something.

I'll note specific changes in changelog/rules below, for clarity.

1)

d/changelog

 18 + - don't try to install dbreport config modules into
 19 + -uiconfig-report-builder if the report builder is disabled

d/rules

413 +ifeq "$(ENABLE_REPORTBUILDER)" "y"
414 mv $(PKGDIR)-common/$(OODIR)/share/config/soffice.cfg/modules/dbreport \
415 $(PKGDIR)-uiconfig-report-builder/$(OODIR)/share/config/soffice.cfg/modules
416 +else
417 + rm -rf $(PKGDIR)-common/$(OODIR)/share/config/soffice.cfg/modules/dbreport
418 +endif

Is this possibly a separate bug, as apparently it's not related to
an upstream bug fix; it would be nice to have some clarification.

Maybe this is covered in the SRU policy under "it is also acceptable to upload new microreleases with many bug fixes without individual Launchpad bugs for each of them", but I considered such 'many bug fixes' to be related to the upstream bugs, and this change is on packaging.

2)

d/changelog

 20 + - switch OOO_BASE_ARCHS/OOO_REPORTBUILDER_ARCHS variables
 21 + (build base on all architectures instead of Java architectures
 22 + and report-builder-* only on archs where Java is enabled, not on
 23 + "all base archs"); there's -sdbc-{mysql,postgresql,firebird} anyway

d/rules

356 -OOO_BASE_ARCHS := $(OOO_JAVA_ARCHS)
357 +OOO_BASE_ARCHS := $(OOO_ARCHS)
358 $(eval $(call gen_no_archs,OOO_BASE_ARCHS))
359 -OOO_REPORTBUILDER_ARCHS := $(OOO_BASE_ARCHS)
360 +OOO_REPORTBUILDER_ARCHS := $(OOO_JAVA_ARCHS)

Similarly; it would be nice to have some clarification,
and perhaps explain the trailing note about '-sdbc-* anyway'.

3)

d/changelog

 24 + - don't try to build Jar_{OOoRunner,test,ConnectivityTools} if Java is
 25 + disabled as an extra safety net (instead of checking for junit only)

Similary, it would be nice to have some clarification.

d/rules

399 -ifeq "$(BUILD_TEST_PACKAGES)" "y"
400 - ifeq "$(ENABLE_JUNIT4)" "y"
401 +ifeq "$(ENABLE_JAVA)" "y"
402 + ifeq "$(BUILD_TEST_PA...

[Rico Tzschichholz (ricotz)]

Hello,

thank you for the detailed review.

The packaging changes are addressing packaging errors and required changes for CMIS support.

4) 5) follow the upstream CMIS changes
Upstream bumped the internal requirement of libcmis which finally allows the proper CMIS service support. Unfortunately it had to be disabled before because it was broken. Upstream chose Openssl as official choice for this feature/combination which was followed here. But it would be possible to continue using gnutls if the SRU requires it.

1) 2) 3) 6) are packaging bugs regarding Java support
Those are needed to allow Java support to be disabled on specific archs if needed. Fortunately this wasn't required yet while the already applied mitigations to the bridgetests still are sufficient. (This would affect armhf, ppc64el and s390x. Those are not supported by upstream)

[Rico Tzschichholz (ricotz)]

For reference https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/log/?h=wip/mantic-7.6

[Rico Tzschichholz (ricotz)]

I have prepared another build which drops the dependency change to "libcurl4-openssl-dev" and keeps "libcurl4-gnutls-dev".

I have updated the description accordingly.

[Mauricio Faria de Oliveira (mfo)]

Hi Rico,

Thanks for the clarifications!

> 1) 2) 3) 6) are packaging bugs regarding Java support
> Those are needed to allow Java support to be disabled on specific archs if needed.
> Fortunately this wasn't required yet while the already applied mitigations to the bridgetests still are sufficient.

So, it does look like this is not _required_ right now, correct?
(i.e., no archs are getting Java support disabled in this SRU.)

I take this from your comment ("if needed" and "wasn't required yet")
_and_ `d/rules` assignments of OOO_BASE_ARCHS and OOO_REPORTBUILDER_ARCHS,
which remain the same value ("amd64 arm64 armhf ppc64el riscv64 s390x").

In this case, I guess such changes should not be included in this SRU,
but left for when it is actually needed; maybe others can comment too.

And perhaps a separate bug report with more details would be recommended,
but please do not work on this at the moment, while others don't comment.

> 4) 5) follow the upstream CMIS changes
> Upstream bumped the internal requirement of libcmis which finally allows the proper CMIS service support.
> Unfortunately it had to be disabled before because it was broken.

Understood.

I reviewed some of the docs/changes related to this, and this scenario
is more complex, since this (CMIS support) is a feature, with different
considerations for SRU (e.g., support in LTS and newer interim releases).

I'll have to ask for others with more experience in such case to comment,
but these are some thoughts for now:

CMIS is a standard related to a feature for opening/saving files on remote servers [1].
"LibreOffice supports many document servers ... that implement the OASIS CMIS standard."

[1] https://help.libreoffice.org/7.6/en-US/text/shared/guide/cmis-remote-files.html

In general, features only land in the development release, until feature freeze [2],
but there are cases for stable releases as well, when considering LTS releases: [3]

[2] https://wiki.ubuntu.com/FeatureFreeze
[3] https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases

"""
For Long Term Support releases we sometimes want to introduce new features.
...
To avoid regressions on upgrade, any such feature must then also be added to any newer supported Ubuntu release.
...
For new upstream versions of packages which provide new features, but don't fix critical bugs, a backport should be requested instead.
"""

So, theoretically, enabling CMIS in Mantic could meet the requirement to have it
in Jammy, and it is (jammy-updates 1:7.3.7-0ubuntu0.22.04.3 has ENABLE_CMIS=y).

It just turns out to be disabled in Lunar (lunar-updates 4:7.5.8-0ubuntu0.23.04.1
has ENABLE_LIBCMIS=n, I guess it might be due to issues/broken as you mentioned?),
so there's some intermediary release with it disabled.

> (continuing)
> Upstream chose Openssl as official choice for this feature/combination which was followed here.
> But it would be possible to continue using gnutls if the SRU requires it.

Ack, thanks for clarifying.
In this case, if libcurl4-gnutls/openssl were only being used due to ENABLE_CMIS,
which is disabled in mantic-release, then maybe we could change it, as it would be
effectively the only usage of it.
But it turns...

[Rico Tzschichholz (ricotz)]

I am going to wait for a decision about the CMIS feature re-enablement.

Please have a look at the 7.5.9 SRU for lunar at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2044369 which will also re-enable CMIS support.

Regarding the Java related packaging fixes, it is unfortunate that they create some confusion.

Upstream has changed its release schedule for 7.6.4 which got released today and I will update this SRU once more to track this new 7.6.x release.

[Rico Tzschichholz (ricotz)]

For reference https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/log/?h=wip/mantic-7.6

[Launchpad Janitor (janitor)]

This bug was fixed in the package libreoffice - 4:7.6.4-0ubuntu0.23.10.1

---------------
libreoffice (4:7.6.4-0ubuntu0.23.10.1) mantic-security; urgency=medium

  * New upstream release (LP: #2044019)
  * SECURITY UPDATE: Improper input validation enabling arbitrary Gstreamer
    pipeline injection
    - CVE-2023-6185
  * SECURITY UPDATE: Link targets allow arbitrary script execution
    - CVE-2023-6186

  [ Rico Tzschichholz ]
  * debian/patches/fix-arm64-tests.diff:
    - Dropped while it got fixed upsteam
  * debian/patches/fix-armhf-linker.diff:
    - Included upsteam now
  * Update replace-source-sans-in-templates.diff

  [ Rene Engelhard ]
  * debian/rules:
    - readd fonts-crosextra-caladea build-dep; Cambria usage is back
    - re-enable cmis; bump libcmis build-dep to >= 0.6.1
  * debian/control.in:
    - duplicate Replaces: as Breaks: in -uiconfig-*
  * Update patches/we-dont-have-the-needed-fonts.diff and
    patches/adapt-for-new-carlito.diff

 -- Rico Tzschichholz <email address hidden> Thu, 07 Dec 2023 22:10:12 +0100