libreoffice-6.1.5.2 is broken (fails to open any files)

[zetok]

Issue description

After updating 'libreoffice-6.1.4.2' to 'libreoffice-6.1.5.2' it failed to open all ODT documents I've tried, claiming that they don't exist.

I've reverted to previous version (6.1.4.2) and it opens the same files without issue.

Steps to reproduce

1. Update to libreoffice-6.1.5.2
2. Try to open an ODT document

Technical details

• system: "x86_64-linux"
• host os: Linux 5.0.1-gentoo, Gentoo, noversion
• multi-user?: yes
• sandbox: no
• version: nix-env (Nix) 2.0.4
• channels(zetok): "nixpkgs-19.09pre173147.03050e9749e" warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels' does not exist, ignoring
• nixpkgs: `/home/zetok/.nix-defexpr/channels/nixpkgs

[zetok]

I've just checked, and libreoffice-fresh (6.2.1.2) is also affected by the same problem.

[7c6f434c]

Thank you for your report. On something that is almost NixOS I seem to be able to open a random ODT file. So I want to find a difference (and maybe update the wrapper to handle this difference…)

I assume if you create a new .ODT file it also fails to be opened? Could you please specify a concrete checked-failing ODT file (upload, or something available like LibreOffice tests)?

Also just in case: could you please a fresh user and launch LibreOffice via full store path?

Thank you.

[zetok]

I assume if you create a new .ODT file it also fails to be opened?

This actually worked just fine when saving with default name Untitled 1.odt. After mv Untitled\ 1.odt 'name with unicode ≠²≠¢³€¢…«»·€§ðæŋ’əµ.odt' LO failed to open the file.

Apparently all the files that I've tried to open either had some unicode characters in their filename, or in some part of the path to them.

As for uploading test case, even converting an empty file with unicode in it to ODT fails:

$ touch 'name with цырылиц.txt'
$ libreoffice --headless --convert-to odt 'name with цырылиц.txt'
Warning: failed to read path from javaldx
Fontconfig warning: "/etc/fonts/fonts.conf", line 5: unknown element "its:rules"
Fontconfig warning: "/etc/fonts/fonts.conf", line 6: unknown element "its:translateRule"
Fontconfig error: "/etc/fonts/fonts.conf", line 6: invalid attribute 'translate'
Fontconfig error: "/etc/fonts/fonts.conf", line 6: invalid attribute 'selector'
Fontconfig error: "/etc/fonts/fonts.conf", line 7: invalid attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/fonts.conf", line 7: invalid attribute 'version'
Fontconfig warning: "/etc/fonts/fonts.conf", line 9: unknown element "description"
Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf
Error: source file could not be loaded

Converting an empty file without unicode characters in path works.

NB: LO 6.1.5.2 displays malformed unicode characters, while 6.2.1.2 displays the correct unicode characters in the GUI error message.

[7c6f434c]

As for uploading test case, even converting an empty file with unicode in it to ODT fails:

1. Thanks for the test script

2. $ touch 'name with цырылиц.txt' $ libreoffice --headless --convert-to odt 'name with цырылиц.txt'

Works for me (and my initial test was by conincidence with a file with a name in Russian)

3. Do I understand correctly that a freshly created user with a en_US.UTF-8 locale gets the same problem?

[zetok]

Do I understand correctly that a freshly created user with a en_US.UTF-8 locale gets the same problem?

~Yep, on a fresh user with LANG=en_GB.UTF-8 and LC_MESSAGES=en_US.UTF-8 trying to open a file with unicode in filename results in an error.

Other locale variables are not set.

With LANG=C LO 6.2.1.2 opens the file, but there's another problem with tooltip:

[7c6f434c]

And with en_US instead of en_GB? I also wonder if setting LOCALE_ARCHIVE to point to Nixpkgs-provided glibcLocales (more precisely, /lib/locale/locale-archive inside that package) would help.

[zetok]

And with en_US instead of en_GB?

This also fails.

[7c6f434c]

Let's exclude crazy versions

with import <nixpkgs> {};
runCommand "test-lo" {
  buildInputs = [
    libreoffice tigervnc xorg.xprop xorg.twm
  ];

} ''
  export LOCALE_ARCHIVE="${glibcLocales}/lib/locale/locale-archive"
  export LANG=en_GB.UTF-8
  export LC_MESSAGES=en_US.UTF-8
  export FONTCONFIG_FILE=${makeFontsConf {
     fontDirectories = [ dejavu_fonts ];
  }}

  export HOME="$out/home"
  mkdir -p "$HOME"
  cd "$out"

  ascii_string="qwe"
  lgc_string="bвδ"
  echo "$lgc_string" > "$lgc_string.txt"
  echo "$ascii_string" > "$ascii_string.txt"

  libreoffice --headless --convert-to odt "./$ascii_string.txt"
  libreoffice --headless --convert-to odt "./$lgc_string.txt"

  ls
''

This creates two .odt files just fine for me (I have pushed and improved wrapper that doesn't complain as much inside build sandbox, but even with the old wrapper it should work).

Does this work for you?

[zetok]

Yes.

[7c6f434c]

Hm. Next thing: fresh user, empty home directory, $NIX_PATH set up as it should be on your system.

echo "bвγ" > "bвγ.txt"
env -i PATH="$(nix-instantiate -E 'with import <nixpkgs> {}; lib.makeBinPath [ libreoffice gnugrep utillinux coreutils gnused ]' --eval-only | tr -d '"')" LANG=en_GB.UTF-8 LC_MESSAGES=en_US.UTF-8 LOCALE_ARCHIVE="$(nix-build '<nixpkgs>' -A glibcLocales)"/lib/locale/locale-archive FONTCONFIG_FILE="$(nix-build -E "with import <nixpkgs> {}; makeFontsConf {fontDirectories = [ dejavu_fonts ];}")" HOME=$PWD libreoffice --headless --convert-to odt bвγ.txt

This should have a very limited leak from the environment…

[zetok]

This also successfully converts the file.

[7c6f434c]

And without -i as the first argument to env it fails, right?

[zetok]

~Yes.~

[zetok]

No, wait, it still works without -i (I did rm * and forgot to recreate the file).

[7c6f434c]

Hm, does it work under your normal user in an empty directory with that file (with and without -i)?

[zetok]

Yes.

[7c6f434c]

Well, in that case you can try removing variables one by one and find out which one makes all the difference.

[7c6f434c]

Any news on what caused the failure?

[zetok]

I've just noticed that there's a message when LO fails to open a file via GUI:

(soffice:32088): GLib-GObject-CRITICAL **: 17:04:27.535: g_object_get_data: assertion 'G_IS_OBJECT (object)' failed

The error doesn't occur with LANG=C on a new user. It also occurs every time on a normal user regardless of the LANG variable.

---

Actually, there seem to be 2 issues here: one where LO fails to convert a file via CLI, and one where LO fails to open a file via GUI. Since neither of those worked, I thought that it was the same issue, but I've just found out that even though export LANG=C fixes converting, the GUI still doesn't work with it set on a user I want it to work.

no – LO doesn't open the file yes – LO opens the file

• LANG=en_GB.UTF-8:
  • normal user:
  • CLI: no
  • GUI: no
  • new user:
  • CLI: no
  • GUI: no
• LANG=C:
  • normal user:
  • CLI: yes
  • GUI: no
  • new user:
  • CLI: yes
  • GUI: yes

---

I've tried to unset quite a few env variables on normal user, but it didn't seem to make any difference.

[zetok]

And I've just tried to unset all env vars except the ones that are absolutely needed with:

for ev in $(env | sed -E 's/([a-zA-Z0-9_]*)=.*/\1/')
do
    if [ $ev != "HOME" ] && [ $ev != "PATH" ] && [ $ev != "DISPLAY" ]
    then
        unset $ev
        echo
        echo "Unset: '$ev'"
        echo
        libreoffice
    fi
done

And LO with my user still fails to open the file via GUI.

[7c6f434c]

Well, I think the env -i … invocation I provided is the optimal environment for test.

I am a bit lost: if you use that kind of env , with and without -i, from your normal user and from a fresh one — how GUI behaves? Your table seems to be just about $LANG without $LOCALE_ARCHIVE, and I think Nix-packaged glibc more or less requires the latter variable.

[zetok]

Oh, it looks like setting LOCALE_ARCHIVE fixes it for normal user without changing other variables. And while at it, it looks like I can just use the one from underlying system, instead of the one provided by Nix:

export LOCALE_ARCHIVE=/usr/lib/locale/locale-archive

[7c6f434c]

I was optimising for the chance of having a reproduction I can run locally, so Nixpkgs locale archive was better; but indeed it should be OK (most of the time — if glibc upgrades locale-archive format, all bets are off) to use the system one.

I would generally say that Nixpkgs + interactive programs → please set $LOCALE_ARCHIVE.

Are there any remaining problems with $LOCALE_ARCHIVE set?

[zetok]

I would generally say that Nixpkgs + interactive programs → please set $LOCALE_ARCHIVE.

I think that this sort of thing should be taken care of by the package manager/included wrapper script for the package, as it seems to be unreasonable to expect from user to know that some environment variable(s) need to be set in order for program to work where said program doesn't need those environment variables to work with other package managers.

Are there any remaining problems with $LOCALE_ARCHIVE set?

AFAICS there are none.

[7c6f434c]

It is possible to have system locale archive in a format incompatible with Nixpkgs glibc (the fact that this is a rare situation doesn't make it much better). Wrapping all the packages with a full locale archive is not done because of 120MiB size of the maximum locale archive (it is possible to use a smaller one with only the languages used on the system). Documentation is just lacking, and that is just unfortunate, indeed.

[7c6f434c]

Some previous discussions: https://github.com/NixOS/nixpkgs/issues/6878 https://github.com/NixOS/nix/issues/599

[Ekleog]

(triage) Closing as duplicate of https://github.com/NixOS/nixpkgs/issues/6878 , as all that remains appear to document the locale issues.