Package Details: libreoffice-dev-bin 25.2.3.1-1

Git Clone URL: https://aur.archlinux.org/libreoffice-dev-bin.git (read-only, click to copy)
Package Base: libreoffice-dev-bin
Description: A free and powerful office suite - development branch
Upstream URL: https://www.libreoffice.org/
Licenses: MPL-2.0, LGPL-3.0-or-later
Provides: libreoffice, libreoffice-en-US
Submitter: twa022
Maintainer: xiota
Last Packager: xiota
Votes: 19
Popularity: 0.000000
First Submitted: 2016-12-16 03:01 (UTC)
Last Updated: 2025-04-17 05:03 (UTC)

Dependencies (12)

Required by (168)

Sources (2)

Pinned Comments

roundedbun commented on 2024-10-26 12:33 (UTC) (edited on 2025-01-14 06:15 (UTC) by roundedbun)

Gnome Sushi can't provide thumbnail of Office Document because there is no file named libreoffice in /usr/bin/, the workaround was create hardlink like this: $ sudo ln /usr/bin/libreoffice25.2 /usr/bin/libreoffice

xiota commented on 2024-05-25 22:06 (UTC) (edited on 2024-06-16 17:29 (UTC) by xiota)

Please do not comment and flag for the same issue at the same time. Only the flag is needed for version bumps and simple packaging issues.

Latest Comments

1 2 3 4 Next › Last »

callegar commented on 2025-02-28 12:20 (UTC)

I think that the pre-release binaries distributed by the document foundation need libxcrypt-compat to be added as a dependency, otherwise the python interpreter that is bundled with libreoffice does not work.

callegar commented on 2025-02-26 15:48 (UTC)

Nevermind, the package does not seem to include the kf6 vcl plugin at all, nor the gtk4 one. Any clue why? The kf6 vcl plugin seems rather important on KDE, because kf5 has issues on plasma 6.

callegar commented on 2025-02-26 15:42 (UTC)

May I suggest that the PYTHONHOME variable is set in a slightly different way? Either:

  • as it is now in a /usr/bin/libreoffice25.2 script, but with this script sourcing rather than exec-ing /opt/libreoffice25.2/program/soffice

  • directly placing the assignment of PYTHONHOME in /opt/libreoffice25.2/program/soffice and then linking to it from /usr/bin/libreoffice25.2

The reason why, is the current approach makes a script (/usr/bin/libreoffice25.2) call another script (/opt/libreoffice25.2/program/soffice) that eventually calls the soffice binary. This double indirection breaks things like

SAL_USE_VCLPLUGIN=kf6 libreoffice25.2

because the SAL_USE_VCLPLUGIN variable gets lost at the invocation of the second shell. Yes, you can export, but that is not nice in aliases.

xiota commented on 2025-02-10 21:20 (UTC)

@callegar Instructions at wiki.documentfoundation.org/QA/BugReport say, "Choose the version of the application in which the bug appeared... You can ignore the section latest known-working version."

I have not seen any project that requires users test old pre-releases that have already been superseded by an actual release. I wouldn't bother reporting issues to projects with such requirements because no one is going to backport fixes to old pre-releases.

That said, this package is constructed so that only a small amount of information at the beginning of the PKGBUILD needs to be changed to do what you want. If you frequently need to build different versions, you can create separate files, like PKGBUILD.old:

_pkgtype=-old-bin
_pkgnamefmt=LibreOffice

pkgver=24.8.3.1
pkgrel=1

source <(
  sed -E -e 's&^pkgver=.*&&' \
    -e 's&^pkgrel=.*$&&' \
    PKGBUILD
)

pkgdesc="${pkgdesc% - *}"

git should ignore extra files during sync. Build with makepkg -Cfp PKGBUILD.old.

callegar commented on 2025-02-08 12:48 (UTC)

@xiota Thanks for the PYTHONHOME work! For what concerns the other point, namely making multiple prerelease packages, I understand your point and the risk of the old packages cluttering aur. Yet, I think that there can be value in having at most 3 items: prerelease of still, prerelease of fresh, and prerelease of next fresh. A few days ago that would have been 24_2, 24_8, 25_2, now, since 25.2 is released just 24_8 and 25_2. So anything else could just be removed not to clutter the aur. The rationale is that it is really not that infrequent to encounter bugs in LibO and when you submit a bug to their tracker, the typical question is "have you tried the pre-release of your branch and of the next branch"? It is very easy to do that test on deb and rpm based distros, but it is currently not similarly easy to do all those checks on arch. Currently, I have the git repo for your aur package cloned locally and branches made by myself for the prereleases that I need to test. Yet I wonder if having all the pre-releases could help testing and bug reporting to LibO from arch users, who typically are very good at explaining issues and providing reproducible examples. Obviously the best would be having LibO upstream iteself providing the arch packages alongside the deb and rpm ones, but you cannot have everything ;-)

xiota commented on 2025-02-07 21:18 (UTC)

@roundedbun The path sushi uses for libreoffice appears to be hardcoded at sushi-utils.c#L164. Maybe they would be willing to make it configurable if you request it.

@callegar I'm testing a revision to set PYTHONHOME. If all goes well, will commit it in a little bit. As for making multiple prerelease packages, doesn't really make sense to me because each prerelease eventually becomes a release. The old packages would clutter AUR and likely be poorly maintained.

callegar commented on 2025-02-06 19:37 (UTC)

I believe that the pre-releases of LibO on which this package is based are made so that they can be installed alongside each other. For instance, you should be able to have the latest 24.8 pre-release installable alongside the latest 25.2 pre-release.

Thus I wonder if it would not make sense to double this package into:

  • libreoffice-prerelease-248-bin
  • libreoffice-prerelease-252-bin

... similarly to what the Document foundation does. For instance, if I look into the LibreOfficeDev_24.8.0.0.alpha1_Linux_x86-64_rpm.tar.gz, the rpms that I find in there look like libobasis25.2-base-25.2.0.3-3.x86-64.rpm assuring that libobasis25.2-base can be installed alongside libobasis24.8-base from the 24.8 prereleases.

callegar commented on 2025-02-06 18:48 (UTC)

Apparently, I need to launch this libreoffice with PYTHONHOME=/opt/libreoffice25.2/program/python-core-3.10.16 libreoffice25.2 to have it work correctly. Otherwise, some extensions (E.g. APSO) are not recognized properly and the program complains.

Is someone else experiencing this?

xiota commented on 2024-10-26 16:40 (UTC) (edited on 2024-10-26 16:41 (UTC) by xiota)

@roundedbun This package doesn't use /usr/bin/libreoffice so it can be installed alongside extra/libreoffice-still or extra/libreoffice-fresh. I am pinning your previous comment to notify other users of the workaround. If someone finds a solution that doesn't conflict with other packages, it can be considered for inclusion.

roundedbun commented on 2024-10-26 12:33 (UTC) (edited on 2025-01-14 06:15 (UTC) by roundedbun)

Gnome Sushi can't provide thumbnail of Office Document because there is no file named libreoffice in /usr/bin/, the workaround was create hardlink like this: $ sudo ln /usr/bin/libreoffice25.2 /usr/bin/libreoffice

1 2 3 4 Next › Last »