/usr/lib/libreoffice/program/soffice.bin:11:ScSelectionTransferObj::~ScSelectionTransferObj:ScSelectionTransferObj::~ScSelectionTransferObj:com::sun::star::uno::Reference:Qt5MimeData::~Qt5MimeData:Qt5MimeData::~Qt5MimeData

[errors.ubuntu.com bug bridge]

[Verification and regression analysis is all handled via the main SRU bug of LP: #1913353 (for groovy) and LP: #1906684 (for focal)]

The Ubuntu Error Tracker has been receiving reports about a problem regarding libreoffice. This problem was most recently seen with package version 1:6.4.6-0ubuntu0.20.04.1, the problem page at https://errors.ubuntu.com/problem/cfc41540ed80c870e8fb93c32ad7df0b7391f1b7 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports.
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/.

[Heather Ellsworth (hellsworth)]

Description:
In Kubuntu 20.04 there have been some cases of the following stacktrace and threadtrace (reported anonymously in the user's background) in 6.4.3, 6.4.4, and 6.4.5 but not too many really (~40 per release).

However, there has been a very large increase in the same error being reported (~17k) since users have been updating to 6.4.6.

Could someone please take a look at the following stacktrace and threadtrace outputs? It's great to get these errors reported anonymously to help find real issues, but the downside is I have no idea what the user was doing when this crash occurred.

Stacktrace: https://paste.ubuntu.com/p/Dgw89Hfpqb/
Thread Stacktrace: https://paste.ubuntu.com/p/nVvmPjxZm2/

There is also an associated launchpad bug: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1897784

Steps to Reproduce:
Unsure what the user is doing when the crash occurs.

Actual Results:
It looks like libreoffice crashes because of this at the top of the stacktrace:
#1 0x00007fc9721f1a9a in KCrash::defaultCrashHandler (sig=11) at ./src/kcrash.cpp:582
        crashRecursionCounter = 2

Expected Results:
Libreoffice should not crash.

Reproducible: Always

User Profile Reset: No

Additional Info:
version is: 6.4.6-0ubuntu0.20.04.1 which is just repackaged 6.4.6.2

[Heather Ellsworth (hellsworth)]

The stacktrace suggests this is happening on KDE systems:

#1 0x00007fc9721f1a9a in KCrash::defaultCrashHandler (sig=11) at ./src/kcrash.cpp:582
        crashRecursionCounter = 2

[julien2412 (serval2412-6)]

Michael: thought you might be interested in this one. Perhaps it's already fixed in master or 7.0 branch and just need some backports for 6.4.7. Of course, if we still got the time considering https://wiki.documentfoundation.org/ReleasePlan/6.4...

[Michael Weghorn (michaelweghorn)]

The only relatively recent commit related to QMimeData handling (i.e. mostly copy & paste and drag'n'drop) is the fix for tdf#131533, but that fix is in 6.4.4 already.

I'm wondering whether the increase of reported crashes is actually due to some change in LibreOffice qt5/kf5 code or rather the side-effect of something completely different (like more users having installed Kubuntu 20.04 since then, or some completely different commit that changed timing in some place, ...).

@jmux: Any ideas?

[Jan-Marek Glogowski (jmglogow)]

No. (In reply to Michael Weghorn from comment #2)
> The only relatively recent commit related to QMimeData handling (i.e. mostly
> copy & paste and drag'n'drop) is the fix for tdf#131533, but that fix is in
> 6.4.4 already.
>
> @jmux: Any ideas?

We know the fix for tdf#131533 is rather fishy and more of a workaround, then a real fix. But if we have the same backtraces before 6.4.4 (and I checked that libreoffice_6.3.3-0ubuntu1.debian.tar.xz doesn't carry that fix), we can - kind of - rule that out. Also all the backtraces just indicate Calc (ScSelectionTransferObj), not any other LO modules (at least Writer), which is strange. Maybe an active selection in Calc is just more common on shutdown, then in other applications? OTOH a copy in Calc keeps the selection, even if you move the "cursor rectangle". There is also nothing suspicious new on https://crashreport.libreoffice.org/stats/version/6.4.6.2

And the only "fix" in vcl/qt5 between 6.4.2 and 6.4.3 is commit 1000169ebca79478a05b4c23e760d99bd77e739e ("Qt5 unify font attribute conversions"), which I would also rule out as the origin of any bug (famous last words).

There is also no other fix in vcl/ or sc/ since commit cbac26c52ccbe59c51c6631cb8c4b0a314a9848a / 6.4.0, which looks suspicious at all w.r.t. the backtrace at a first glance. And the whole lazy clipboard stuff was already in 6.3. And your fix for tdf#129809 was already in 6.4.2.

Still nothing would explain the current peak, I can see in https://errors.ubuntu.com since https://errors.ubuntu.com/?release=Ubuntu%2020.04&package=libreoffice-core&from=2020-08-24&to=2020-09-25, which matches the publishing date from https://launchpad.net/ubuntu/+source/libreoffice/1:6.4.6-0ubuntu0.20.04.1 .

So I checked the diff of the 6.4.6 fix range for sc and interestingly it contains commit 8718d243edc9400b0e0131b096702af8d33df327 (rhbz#1847031 null-deref), which fixes a null-deref in ~ScTransferOb. That should really just fix a bug, not cause one, but eventually this just papers-over some real bug in the other fixes, which now hits Qt in some way. Because ScTransferObj is part of libsclo, which can't exists with "pScMod == nullptr".

$ git log --pretty=oneline f2e448175cee92fc695413e7281223e9f23e30ee~1..origin/libreoffice-6-4-6 | wc -l
123

Now I really would like to have a reproducer, which eventually should also happen on master... and tdf#130559 is the only additional thing in sc that looks strange, but that's just 17 out of the 123 patches.

Someone from Kubuntu could "mine" the crash reports, if there is anything reproducible in it. And I have to get the RHEL bug report from someone (Caolan, eventually).

So while I first suspected something non-LO, it now smells like a LO bug, independent of VCL, evetually.

[Jan-Marek Glogowski (jmglogow)]

Created attachment 165976
rhbz#1847031 cleaned crash bt

That whole bt looks broken. RH has no reproducer either, so the fix is just a guess. Version was libreoffice-6.4.4.2-2.fc32.x86_64, as you can see in the bt paths.

The bt itself looks "wrong". The user did a right-click on a Calc cell, that would open the context menu, but at that point, when the Gtk event is processed, a lot more stuff is already "gone", like all the aGuard objects have nullptr, so no mutex in them. So I guess this is just for reference, but won't help.

[Jan-Marek Glogowski (jmglogow)]

Created attachment 165978
Kubuntu shutdown crash bt

It appears that one can just DL the text with a Launchpad login. So this is just a copy from the BT as reference. For whatever reason the clipboard object is still active, while the module is already gone, which is causing the crash.

An other question is, what other packages were published that day, just in the case it's eventually no LO bug (I still think it is).

[Heather Ellsworth (hellsworth)]

It's hard to pin down what other new packages could have made it onto the users system because of the way Ubuntu rolls out releases in a "phased" manner:

https://wiki.ubuntu.com/StableReleaseUpdates#Phasing

This is happening simultaneously for all sorts of packages too, at various stages in the phasing process. So unfortunately, there's no way to really get a sense of other new packages that might be causing the issue.

[Jan-Marek Glogowski (jmglogow)]

FWIW: I have installed Ubuntu's LO 6.4.6 in my focal schroot. I'm running Debian Buster with KDE on the host in X11. I couldn't produce any crash with the LO in the chroot, doing Calc selections and copy and paste operations, D'n'D and also some external copy actions.

[Olivier Tilloy (osomon)]

This looks similar to https://bugs.documentfoundation.org/show_bug.cgi?id=131083, which the reporter could originally trigger fairly reliably, but ended up marking resolved because after installing updates the crash went away for them.

The steps to reproduce were to simply open libreoffice calc, use the mouse to create a vertical selection of two or more consecutive cells, and then click the cross in the window decorations to close calc. This would trigger the crash at least once in every ten runs, according to the reporter.

I tested this a good number of times in a fully up-to-date Kubuntu 20.04 amd64 VM, without triggering any crash.

According to the crash report on errors.ubuntu.com, the crash is still being reported on a daily basis with libreoffice 1:6.4.6-0ubuntu0.20.04.1.

[Olivier Tilloy (osomon)]

This bug looks similar to https://bugs.documentfoundation.org/show_bug.cgi?id=131083, which the reporter could initially reproduce quite reliably, but ended up closing after they couldn't reproduce any longer. This was originally reported against 6.4.0.3, and wasn't observed in 7.0.0.0.alpha0+.

In the errors.ubuntu.com tracker, the earliest version exhibiting the crash is 6.4.3, and there are new reports daily with 6.4.6.

[Michael Weghorn (michaelweghorn)]

(In reply to Olivier Tilloy from comment #8)
> This bug looks similar to
> https://bugs.documentfoundation.org/show_bug.cgi?id=131083, which the
> reporter could initially reproduce quite reliably, but ended up closing
> after they couldn't reproduce any longer. This was originally reported
> against 6.4.0.3, and wasn't observed in 7.0.0.0.alpha0+.
>
> In the errors.ubuntu.com tracker, the earliest version exhibiting the crash
> is 6.4.3, and there are new reports daily with 6.4.6.

Indeed. The backtrace there seems to be comparable, s. tdf#131083 comment 22 (and the full valgrind log, attachment 158370).

According to tdf#131083 comment 26, the reporter was able to reproduce more or less reliably in his initial installation, but not in a fresh one afterwards, suggesting that *might* have been some issue with the installation.

I'm afraid there is probably little we can do without knowing how to reproduce or whether it even happens at all with newer LO versions...

[Jan-Marek Glogowski (jmglogow)]

(In reply to Olivier Tilloy from comment #8)
> This bug looks similar to
> https://bugs.documentfoundation.org/show_bug.cgi?id=131083

Nice find. Summary of bug 131083:

Happened reproducible for the user with LO Ubuntu build 6.4.0-0ubuntu7 and LO Tinderbox build 45ca47ac39c03df4de52d627a764f16068b1eab0 (7.0.0.0.alpha0+ is reported for all development builds before branch off / alpha1 / beta) and just with kf5 in KDE / Plasma 2, not with Xubuntu (Xfce? which VCL in About? I would assume gtk3). Happens with the empty / default document.

Bug 131083 comment 13 states: "I'm testing both Kubuntu and Xubuntu in a VM environment (VirtualBox 6.1.4)."

You can get a comparable (but not equal!) build to the Tinderbox one via https://bibisect.libreoffice.org/linux-64-7.0 commit fc089b4dda133f1fd03922b713708e53af6c16fa.

Reproduce:

1. start Calc
2. mark F10/11 vertically
3. exit LO
4. choose not to save

Questions for each point (which might be related or not):

1. How is Calc started? Desktop link, command line (which one?), via start center? Does it happen with non-default profile via -env:UserInstallation=file:///tmp/test?
2. How are the cells marked? Mouse only, keyboard? Which cell first? Does it crash with other cells?
3. Exit crash just happens via window decorations? Or also via menu? Or by using Alt+F4 or Ctrl+Q? Or also by closing the Calc document and then the start center?
4. Why does Calc think the document was modified?

Point 4 is AFAIK already exposing the real bug.

General question: any additional output in a terminal? New entries in ~/.xsession-errors?
Is this just happening with the localized KDE (the reporter uses de-DE.UTF-8)?

An other eventually related crash I found (fixed?) is bug 131533 in LO 6.4.4. The implemented fix / patch is just a workaround, as I couldn't come up with a minimal reproducer without LO. There are some additional comments (see last ones) with info in https://gerrit.libreoffice.org/c/core/+/90990.

According to bug 131083 comment 15, an old LO profile doesn't seem to be the cause of this, as the crash could be reproduced after deleting the profile. Since it didn't crash with the first try, it still might somehow be related. Would still be nice to get a known crashing profile for testing / reference, in the case there is some setting in it, leading to the crash.
Bug 131083 comment 26 states the problem to reproduce the bug. "Made the installed DEB packages identical" I guess just means the package list, like "dpkg --get-selections", not the exact versions.

An other bug that just comes to my mind and which was actually fixed for 6.4.0 is bug 104717. That changes the selection / clipboard handling in Calc. Quoting from my commit message: "Calc also removes the system selection when clearing the selection. Other applications keep the primary selection valid, until the application or document closes, so do the same in Calc." So maybe this introduces some case, where the primary selection isn't correctly cleared on shutdown. This is not KDE specific, but the QClipboard handling / API is very different from either Gtk+ or X11, so there might be some broken case now, where we don't clean the selection on module s...

[gruberm (gruberm)]

I'm the original reporter of bug 131083.

Maybe I can shed some light, though I'm again not able to reproduce it in a fresh Kubuntu Focal with 6.4.6.2 (made about 20 attempts).

> 1. How is Calc started?

I started it via the KDE start menu.

> 2. How are the cells marked? Mouse only, keyboard?

I used mouse only.

> Which cell first?

Click on F10, then drag down to F11 to mark both.

> Does it crash with other cells?

AFAIR yes, it's the marking that created the problem.
I just used F10/F11 as reproducable test path.

> 3. Exit crash just happens via window decorations? Or also via menu?
> Or by using Alt+F4 or Ctrl+Q? Or also by closing the Calc document
> and then the start center?

AFAIR I only used the X button on the window decoration.

4. Why does Calc think the document was modified?

At least for my case that was a misconception when I initially created crash.ods as potential test case, see comment 24 in my original bug report.

[P (p92)]

Description:
calc crash often observed upon exit after having saved a modified sheet

Steps to Reproduce:
1.open an existing sheet
2.modify some cells
3.press SAVE icon
4.close the window with X on the top right corner

Actual Results:
calc crash

Expected Results:
nothing should crash

Reproducible: Sometimes

User Profile Reset: No

Additional Info:
Version: 7.0.3.1
Build ID: 00(Build:1)
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5
Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Ubuntu package version: 1:7.0.3-0ubuntu0.20.10.1
Calc: threaded

[P (p92)]

profile has been reset and bug is still here

[P (p92)]

Created attachment 170116
debug trace

[Miguelangelrv (miguelangelrv)]

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

[julien2412 (serval2412-6)]

Mariosv: why do you consider this as a dup?
Indeed debug trace seems pure qt5 pb whereas tdf#140677 can be reproduced in gtk3 (I don't reproduce tdf#104677 myself).
I've updated my local repo and it's building right now but I'll give a try to this one with kf5 rendering.

[julien2412 (serval2412-6)]

Pascal: on pc Debian x86-64 with master sources updated today + kf5 rendering, I don't reproduce this.

Do you reproduce this with a brand new file?
Do you reproduce this with an existing file which just contains "test" in A1?

Could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ?
If you still reproduce this, could you try this:
- open terminal/console
- export SAL_USE_VCLPLUGIN=gen
- launch Calc and give a new try
?

[Miguelangelrv (miguelangelrv)]

Too much similarity, but only a supposition on my side.

You can know better than me.

[julien2412 (serval2412-6)]

I don't reproduce this with kf5 rendering too.
I can't help here=>uncc myself.

[P (p92)]

well since I have installed dbg packages to complete symbol resolution in backtrace, I cannot reproduce the crash anymore...
putting in standby until I can.

[Telesto (telesto)]

Adding bug 137139 to see also

[P (p92)]

Created attachment 170140
same crash but with writer

I had 3 crash with writer closing a modified saved doc this morning, one of which is the same as the one I send yesterday with closing calc.
The 2 other crashes are identical to each other but not the same as the one here.

[Michael Weghorn (michaelweghorn)]

Does that happen with specific documents only? Can you share one and try to give more hints on how to potentially reproduce more reliably?

While it's of course ideal to have steps to reproduce 100 % reliably for further analysis, steps to reproduce "somewhat reliably" are also very helpful already. This sounds very much like tdf#137139, but I hadn't been able to provoke such a crash back then when testing for a while.

[P (p92)]

Created attachment 170179
test document

try to change some already existing cells in this calc
then save with the save button
then exit with the X in the window corner

it might take some tries before it crashes at exit

[Qa-admin-q (qa-admin-q)]

[Automated Action] NeedInfo-To-Unconfirmed

[Michael Weghorn (michaelweghorn)]

(In reply to Pascal from comment #12)
> Created attachment 170179 [details]
> test document
>
> try to change some already existing cells in this calc
> then save with the save button
> then exit with the X in the window corner
>
> it might take some tries before it crashes at exit

Thanks, I tried more than 20 times but it didn't crash here. Can you possibly attach a screencast?

(In reply to Pascal from comment #10)
> Created attachment 170140 [details]
> same crash but with writer
>
> I had 3 crash with writer closing a modified saved doc this morning, one of
> which is the same as the one I send yesterday with closing calc.
> The 2 other crashes are identical to each other but not the same as the one
> here.

Interesting, the backtrace also shows 'ScSelectionTransferObj::~ScSelectionTransferObj', which is clearly Calc-related. Did you have any other documents open in addition to the Writer one? And/Or have you copied data from Calc to somewhere else previously?

[P (p92)]

OK you might have found the mechanism !

You must be on Kubuntu (maybe)
You setup klipper to only have an history count of 1 (paste buffer history count)

you start calc
you open the joined doc
you select a few cells in it
you press ctrl-c (to copy)

then you close the calc window with the X on the corner
=> crash

[P (p92)]

bugs #140728 #140698 might be related to the same trigger problem

[Michael Weghorn (michaelweghorn)]

(In reply to Pascal from comment #15)
> OK you might have found the mechanism !
>
> You must be on Kubuntu (maybe)
> You setup klipper to only have an history count of 1 (paste buffer history
> count)
>
> you start calc
> you open the joined doc
> you select a few cells in it
> you press ctrl-c (to copy)
>
> then you close the calc window with the X on the corner
> => crash

Great, thanks!

I used cells D7 to F12 for selection and can reproduce this now with LO as provided in Debian testing (package libreoffice 1:7.0.4-3) with the steps from comment 15:

Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Debian package version: 1:7.0.4-3
Calc: threaded

but not with a self-compiled LibreOffice master debug build

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: c7b898df4d452746399621f6adc8e7da088f0f3a
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

And it doesn't crash when setting Klipper history size to 2 instead.

[Michael Weghorn (michaelweghorn)]

Turns out that it did not always crash with the steps from comment 15, but adding an extra step made it always crash with affected versions for me:

1) setup klipper to only have an history count of 1 (paste buffer history count)
2) start calc
3) open attachment 170179
4) select cells D7 to F12
5) press ctrl-c (to copy)
6) open "Help" -> "About LibreOffice"
7) copy version information, then close the "About dialog" again
8) close LO using the "X" button on the top right

Result of bibisecting with libreoffice-7-2 repo shows that the crash has been fixed by this commit already:

    commit 20305894243e24eb383ab9feefebf4a0e9f2644f
    Author: Mike Kaganski <email address hidden>
    Date: Sun Feb 14 11:24:42 2021 +0100

        nullptr dereference

        Change-Id: I6a2ffddfd67784ddc2194dafba7d3eaeb6e4e12e
        Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110854
        Tested-by: Jenkins
        Reviewed-by: Mike Kaganski <email address hidden>

Cherry-picks for LibreOffice 7.0 and 7.1 now pending in Gerrit:

https://gerrit.libreoffice.org/c/core/+/112084
https://gerrit.libreoffice.org/c/core/+/112083

[Michael Weghorn (michaelweghorn)]

*** Bug 137139 has been marked as a duplicate of this bug. ***

[Rico Tzschichholz (ricotz)]

Upstream bug is https://bugs.documentfoundation.org/show_bug.cgi?id=140700

[Libreoffice-commits (libreoffice-commits)]

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/f5f5582fa065000a187a92b47ca44498d1f30c09

tdf#140700 nullptr dereference

It will be available in 7.1.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/ef41f5d2106b68544a078bfac85018e37cab90d1

tdf#140700 nullptr dereference

It will be available in 7.0.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Łukasz Zemczak (sil2100)]

Hello errors.ubuntu.com, or anyone else affected,

Accepted libreoffice into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libreoffice/1:7.0.5-0ubuntu0.20.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Łukasz Zemczak (sil2100)]

Hello errors.ubuntu.com, or anyone else affected,

Accepted libreoffice into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libreoffice/1:6.4.7-0ubuntu0.20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted libreoffice (1:6.4.7-0ubuntu0.20.04.1) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

libreoffice/1:6.4.7-0ubuntu0.20.04.1 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#libreoffice

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Łukasz Zemczak (sil2100)]

Groovy verified per LP: #1913353.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libreoffice - 1:7.0.5-0ubuntu0.20.10.1

---------------
libreoffice (1:7.0.5-0ubuntu0.20.10.1) groovy; urgency=medium

  * New upstream release (LP: #1913353)

  [ Rico Tzschichholz ]
  * Update yaru icon style "2021-01-31"
  * Move libreoffice-sdbc-hsqldb to Recommends (LP: #1916786)
  * Fix Calc crash in ScSelectionTransferObj (LP: #1897784)
  * Drop fix-bluez-external.diff and unowinreg-static-libgcc.diff,
    applied upstream

  [ Heather Ellsworth ]
  * Add timeout to uicheck-sw test to allow it to handle timeouts under
    load better (LP: #1785262)

libreoffice (1:7.0.4-3) unstable; urgency=medium

  * debian/tests/control.in: *really* add libreoffice-writer dependency
    to uicheck-sc test

libreoffice (1:7.0.4-2) unstable; urgency=medium

  * debian/test/control: make uicheck-sc depend on libreoffice-writer, too
    (the openDialogs/uno.Show:License Dialog test opens a new "Writer/Web"
    document...)

libreoffice (1:7.0.4-1) unstable; urgency=medium

  * LibreOffice 7.0.4 final release (identical to rc2)

  * debian/patches/pdfium-m68k.diff: fix pdfium build on m68k

  * debian/rules, debian/control*in: s/noinsttests/noinsttest/, thanks
    lintian
  * debian/rules:
    - revert clang (>= 1:11) build-dep for buster-backports; doesn't exist in
      buster and we resort back to gcc
    - don't rm LICENSE.html, it is used by
      Help -> License Information -> Show License
  * debian/control.mediawiki.in: remove Homepage: (closes: #978713)
  * debian/*.mime: stop quoting %s (closes: #950319)

libreoffice (1:7.0.4~rc2-1) unstable; urgency=medium

  * New upstream release candidate

libreoffice (1:7.0.4~rc1-1) unstable; urgency=medium

  * New upstream release candidate

  * debian/patches/unowinreg-static-libgcc.diff: use -static-libgcc, see
    LO master commit 01241113947fc7bd7f7b765dd897bb023c8ca99c

  * debian/rules:
    - set MYSQL_FLAVOUR=mariadb (as it's used anyway, and upstreams internal
      copy is mariadb-connector-c anyway) and build-depend on libmariadb-dev
      instead of libmariadbclient-dev-compat (closes: #975481)
    - build-depend on clang (>= 1:11) on armel
    - fix nocheck -b builds...
    - use nowindows build profile for (not) building unowinreg
  * debian/rules, debian/control*in:
    - honour noinsttests build profile for (not) building
      -subsequentcheckbase/-smoketest-test-data
  * debian/rules, debian/control*in:
    - move unowinreg.dll into /usr/lib/i686-w64-mingw32 (the mingw g++
      compiler installs its .dlls into /usr/lib/gcc/i686-w64-mingw32)

 -- Rico Tzschichholz <email address hidden> Mon, 15 Mar 2021 19:01:12 +0100

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for libreoffice has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Łukasz Zemczak (sil2100)]

Focal verified via LP: #1906684.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libreoffice - 1:6.4.7-0ubuntu0.20.04.1

---------------
libreoffice (1:6.4.7-0ubuntu0.20.04.1) focal; urgency=medium

  * New upstream release (LP: #1906684)
  * Move libreoffice-sdbc-hsqldb to Recommends (LP: #1916786)
  * Fix Calc crash in ScSelectionTransferObj (LP: #1897784)

 -- Rico Tzschichholz <email address hidden> Mon, 15 Mar 2021 19:12:01 +0100