When I run the libreoffice command while a soffice.bin process is
running (e.g. as a consequence of bug 1087368), LibreOffice does not
start: the command just returns without any error.

severity 1087383 wishlist

tag 1087383 + wontfix

thanks


Hi,

Am 12.11.24 um 17:08 schrieb Vincent Lefevre:
so basically starting to try a new soffice.bin

So what? A LibreOffice is running, so... If you had a libreoffice running as a daemon listening to connctions that is the same

This works as designed, afaik.

There is not really multiple soffice.bins in parallel, it will always talk to the already running one.


-> No bug. I'll be nice and keep this open but mark it as wishlist and "not fixable" doesn't exist so wontfix.


Regards,


Rene

No, it does *not* behave as documented. See the "libreoffice --help"
output.

"Using without special arguments:
Opens the start center, if it is used without any arguments."

Other usages such as providing a file argument or using --writer to
create an empty Writer document have no effect either, while a window
should have been opened.

The fact that LibreOffice is already running in the background is just
internals. It still needs to behave as documented and in a useful way.
With the current status, there is no way to open a LibreOffice window.

Hi,

Am 13. November 2024 01:25:35 MEZ schrieb Vincent Lefevre <vincent@vinc17.net>:

All that implies a not yet running LO.

Kill the stray soffice.bin?

It is all over the net that you can't do GUI and soffice.bin listening/daemon/headless/whatever at the same time.

That is touching fundamentals LO upstream will definitely not change as long as this "issue" already exists...

Regards

René

Am 13. November 2024 08:59:26 MEZ schrieb "René Engelhard" <rene@rene-engelhard.de>:

Or at least not a LO hot "hidden"/headless.

Regards

René

This is not what the "libreoffice --help" says. It says nothing about
running LO.

In any case, in these days of multitasking, this is horribly broken.

Well, this is not something the end user is expected to do.

According to the upstream bug

https://bugs.documentfoundation.org/show_bug.cgi?id=165417

(Comment 1), LibreOffice is working as intended, and the issue comes
from unoconv itself:

"That tool itself shouldn't use the default LibreOffice profile - that
would avoid interference between it and the interactive LibreOffice
instance. But that is a bug of that tool."

Since this has a major effect on a separate application (LibreOffice),
I'm raising the bug severity.

Note: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087368
makes this problem much worse, but this is an independent bug.
Even if Debian bug 1087368 were fixed now:
  * An ongoing conversion would affect LibreOffice (with GUI).
  * The -l option permanently breaks LibreOffice (with GUI),
    i.e. as long as the server is running.

It isn't even possible to choose a different LibreOffice profile from
the unoconv command line (as a workaround).

and now with the current unoconv version.

BTW, I forgot to Cc the maintainer at the time of the reassign. :(
I suppose that this new message should be sufficient. I'm keeping
the contents below for this reason.

The upstream repository has been archived a few weeks ago (March 31).
And I can see that unoconv has been deprecated since 2021-11-12[*],
i.e. more than 3 years ago. So it became completely unsupported
upstream.

[*] https://forum.jsreport.net/topic/2805/create-pdf-from-word-template-unoconv-deprecated