lo-menubar 0.1.1 from updates repositories makes plasma-desktop to crash

This looks like the fix Bug #754562 broke more stuff.

We've moved the lo-menubar update out of precise-updates and back to precise-proposed until this can be investigated further. Tags added for precise and quantal since the same version is there. I haven't tested this in quantal though.

Can someone please test this with plasma-desktop in quantal? 0.1.1 has been in quantal since the beginning of May, it would be nice to bisect this a bit.

I installed plasma-desktop and the appmenu widget, lo-menubar doesn't cause a crash in quantal so marking as invalid for quantal.

This might be a bad interaction between libreoffice 3.5.4 and lo-menubar 0.1.1 as quantal doesn't have a newer version of libreoffice yet

Thank you for your bug report, could you try if that happens with lo-menubar 0.1.0-0ubuntu4 from precise and libreoffice 3.5.4? are you sure it didn't happen with stock precise versions? we should probably discard the lo-menubar SRU if that's the one creating the issue since libreoffice 3.5.4 has some important fixes and we don't want to block that update on menubar issues

The same thing. I'm now downgrading libreoffice to see whether the issue is in a change from libreoffice 3.5.3 (updates) to 3.5.4 (proposed), instead of from lo-menubar 0.1.0 to 0.1.1

Could anyone replicate the bug or I'm the only one suffering this issue?

Thanks for testing, I'm not sure how to test, I tried to install plasma-widget-menubar here but didn't managed to figure how to run it (without having to install a full KDE desktop which is quite some to download)

Plasma-widget-menubar is meant to run inside a Plasma (KDE) session, so I
don't think there's another way to test.

I just tested it in another computer and found that this actually works fine there (proposed packages of libreoffice and lo-menubar). I must have some configuration or something else in my system that breaks it :/

I'll try to investigate further and report here if I find the solution for the case anybody else suffers the same.

Thanks and sorry for all the noise...

I actually had the combination in proposed crash for me as well, I haven't tried to replicate in a clean VM though.

hum, it's still unclear if that issue is a new one with those updates or a random one, we should try to figure that out because it would be a shame to block the libreoffice update on that

I'd like to test further, but not clear to me how

I checked in a third computer and the bug is also there.

First approximation of what distinguishes the three computers:

- the two that suffer the bug are 64-bit sytems compared to the one that doesn't (32-bit)

- only the 32-bit was a fresh install, the other two (64-bit) were upgraded to precise from oneiric (one of them); and from natty, to oneiric, to precise (the other one)

it would be good to test fresh 64-bit installs and upgraded 32-bit, to see what's going on...

Marking confirmed because even though it's the same reporter, it's two different machines.

Not reproducable with a fresh LibreOffice 3.5.5~rc3 on a Vanilla Precise 64-Bit.

This is what I see here:
- install vanilla 12.04 LTS
- install kubuntu-desktop and lo-menubar
- reboot
- plasma-widget-menubar show libreoffice menus, although not too reliable
- add-apt-repository ppa:libreoffice/ppa
- apt-get update && apt-get upgrade
- plasma-widget-menubar show libreoffice menus, although not too reliable
- add precise-proposed
- apt-get update && apt-get upgrade
- plasma-widget-menubar show only File-close for LibreOffice

Thus:
- I cannot reproduce the original described issue
- the issue I see (see only File->Close) was triggered by adding precise-proposed, which did not update LibreOffice (as the version from the PPA is newer)

To me this suggests it is highly unlikely to be related to LibreOffice.

doing after the above steps:
- removing ppa
- apt-get remove libreoffice-core && apt-get autoremove
- apt-get update
- apt-get install libreoffice

Now with this (LibreOffice 3.5.4 from proposed), I still get the same behaviour as with 3.5.5: no hangs, lo-menubar only shows File->Close.

Conclusions from what I see here locally:
- LibreOffice 3.5.5 behaved fine without proposed
- LibreOffice 3.5.5 behaved bad with proposed
- LibreOffice 3.5.3 behaved fine without proposed
- the only regression observed by me was introduced by non-LibreOffice proposed packages
- the original bug description could not be reproduced at all here

the previous summary basically mention the known regression in the lo-menubar update, knowing that this bug:

- is happening only for users of the optional universe lo-menubar
- has not been confirmed by anyone else than the submitter
- seems a KDE bug in any case, whatever stupid libreoffice or lo-menubar are doing KDE should not get down on a buggy menu exported to its menubar

is it worth blocking the libreoffice SRU on that? what would the SRU team like to see to resolve that situation? it seems currently the trade off is in disfavor of our users, blocking an important update for all users for a potential issue impacting some users running an universe binary?

I just noticed that the "see only File->Close" behaviour was cause by lo-menubar being uninstalled (doh) along with libreoffice.
Still: LibreOffice 3.5.4 from proposed and lo-menubar from proposed work (with known issues, but without regessions).

Are you not seeing the plasma desktop crash with libreoffice 3.5.4 from proposed and lo-menubar installed (either the release version or the one in -proposed)?

No, up until now I have not yet seen a crash:
- libreoffice 3.5.4-0ubuntu1
- lo-menubar-0.1.1-0ubuntu1
on Ubuntu Precise 64-Bit with proposed enabled.

Hah, found a way to trigger this. Definitely a Heisenbug, so I have no clear reproduction scenario. Crashing/Aborting LibreOffice seems to provoke it (e.g. start it from a terminal a few times and Ctrl-C it). Once plasma-widget-menubar is confusing by such a crash, its pretty reproducable: Happens on ~every start after that.

However, doing the same with LibreOffice 3.5.3, I can get the same result, so not a regression.

Now that you can reproduce it, did you find a workaround or now you are stack like me with the issue?

avlas, can you please check whether this issue is also reproducible for you
with the libreoffice 3.5.3 in precise-updates?

On Mon, Jul 16, 2012 at 02:10:28PM -0000, Sebastien Bacher wrote:
> the previous summary basically mention the known regression in the lo-
> menubar update, knowing that this bug:

> - is happening only for users of the optional universe lo-menubar
> - has not been confirmed by anyone else than the submitter
> - seems a KDE bug in any case, whatever stupid libreoffice or lo-menubar are doing KDE should not get down on a buggy menu exported to its menubar

> is it worth blocking the libreoffice SRU on that? what would the SRU
> team like to see to resolve that situation? it seems currently the trade
> off is in disfavor of our users, blocking an important update for all
> users for a potential issue impacting some users running an universe
> binary?

"It only happens if you have package X from universe installed" is not an
excuse for introducing a regression in an SRU. SRUs are expected to be
*free* of known regressions.

For the libreoffice SRU to proceed, we need to establish that bug #1021946
is not a regression in libreoffice 3.5.4 vs 3.5.3. Björn's testing points
in this direction, but we should confirm it to be sure.

yes, I tested it and thought I put the result but actually not... exactly the same thing happened to me in libreoffice 3.5.3. it seems once you are into the problem, you're somehow stacked with it

fresh install doesn't seem to be affected, maybe until some crashes in plasma-desktop or libreoffice, as reported above :/

Interestingly enough, now with kde 4.9 lo-menubar doesn't make plasma to crash, unfortunately it doesn't seem to work either, and the menu appears within libreoffice windows as if lo-menubar wasn't installed.

[Expired for lo-menubar (Ubuntu Precise) because there has been no activity for 60 days.]