Bibisecting on Linux

    From The Document Foundation Wiki
    < QA‎ | Bibisect

    TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

    This page provides information about using our Bibisect repositories on computers running GNU/Linux.

    Introduction

    Our bibisect repositories were originally built on Ubuntu 64bit machines. In general, all of these repos will run on most modern 64bit GNU/Linux distros (e.g. Fedora, SuSE, Debian, etc.), although some additional packages may be required.

    If you're testing cross-platform, one option is to set up a virtual machine running your target OS (see #Virtual Machines below).

    Choosing a Bibisect repository

    As you can see in the #Versions table below, there are many different bibisect repositories covering different commit ranges. If you find a bug in LibreOffice 4.4.4, you'll want to download the 50max repository, as it covers: "The range from 4.4 branch point to 5.0 branch point"

    It's possible that the bug in LO 4.4.4 predates the 4.4 branch point, at which point you'll want to download an additional (earlier) bibisect repository. We maintain separate bibisect repositories to both speed up the use of the repository, and to make it possible to download just one piece of the commit range.

    Don't have a bug to bibisect yet? Find documented regressions in the list here.

    Setting up Environment

    Before we download the bibisect repository, let's make sure your machine has the right software installed. For all OSes, you'll need to install

    • git

    The table below shows some of the additional software you'll need to add to get each of these bibisect repositories running properly on your system. (These instructions likely also apply to a "releases" repository like linux-64-releases.)

    Distro 43all 43only 50max linux-dbgutil-daily-till51,linux-dbgutil-daily-till52
    Ubuntu 22.04 (Jammy) If you get the error about libpng12.so.0 not found, you can install it with a PPA: 
    sudo add-apt-repository ppa:linuxuprising/libpng12 && sudo apt update && sudo apt install libpng12-0
    Ubuntu 18.04 (Bionic) Have to install libjpeg62 for included versions older than 3.5: 
    wget -q -O /tmp/libpng12.deb https://mirrors.kernel.org/ubuntu/pool/main/libp/libpng/libpng12-0_1.2.54-1ubuntu1_amd64.deb && dpkg -i /tmp/libpng12.deb && rm /tmp/libpng12.deb)

    If Java6 is needed, it's not in the repos anymore, but can be installed following these steps:

    1. get Java6.bin from Oracle
    2. run or double-click to extract
    3. move folder to /usr/lib/jvm/
    4. register with: 
      sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.6.0_45/bin/java" 1
    		 should work out-of-the-box
    Ubuntu 12.04 LTS (Precise) have to install libjpeg62 for included versions older than 3.5: 
    sudo apt-get install libjpeg62
    		 should work out-of-the-box
    openSUSE 12.1 no ?
    Fedora have to build libjpeg8 from source and LD_PRELOAD it (for versions older than 3.5) 
    dnf install libcurl
    export LD_PRELOAD=/usr/lib64/libcurl.so.4
    If that is not enough: 
    export LD_PRELOAD=/usr/lib64/libcurl.so.4:/usr/lib64/libnss3.so:/usr/lib64/libnssutil3.so
    		 dnf install harfbuzz, export LD_PRELOAD=/usr/lib64/libharfbuzz.so.0
    Debian sid Have to install librtmp0 and its dependencies. These are available in the debian wheezy repository.

    Downloading Bibisect Repository

    Because we are a distributed, community project, we have created and hosted bibisect repositories on different servers. Although the exact procedures for downloading the repositories may differ slightly, most repositories may be retrieved via regular download from a web server or directly via git. Links can be found in the "Download Link" column in the version table below.

    From a Web Server

    Using the 43all repository as an example, we can download the git bundle from the TDF server, and clone in into a new git repository using the instructions found on that page.

    Using Git

    Live repositories are available from our Bibisect hosting. You may clone a bibisect repository the same way as you do with any other git repository: 

       > git clone https://bibisect.libreoffice.org/linux-64-6.2.git

    Please be aware that the original download may be several gigabytes, so please make sure you're on a fast Internet connection and are reasonably certain that you will not experience network interruption. Because of the mechanics of git repositories, if the initial clone is interrupted, I believe that you'll have to start the clone all over again :-( Otherwise you can download the bundle and refresh later. (Check the instruction on the repository webpage for details.) You can also use a shallow clone as workaround: 

       # Use --depth=1 for the first clone, 
   # which is usually less than 1GB (or even 300MB for certain repos):
   > git clone --depth=1 https://bibisect.libreoffice.org/linux-64-6.2.git
   
   # then use git pull and a deeper depth:
   > cd linux-64-6.2
   > git pull --depth=1000 # and then 2000, 5000, 10000...
   
   # and then if you are confident with your network connection, 
   # then convert it to a complete one using --unshallow:
   > git pull --unshallow

    After the first clone, further updates to the git repository will be smaller, and will depend on how frequently the Tinderbox adds commits to the repository and how many days you wait before updating your repository.

    Update your repository with 

       > git checkout master && git pull

    Bibisecting the Bug

    With a bug and test procedures in hand, and a downloaded and unpacked git repository ready to go, it's finally time to start bibisecting!

    From now on latest will reference the latest commit in the repository, and oldest will reference the earliest one. Most repositories have tags defined for latest/oldest commits, if they aren't, the hashes can be acquired using the following commands, and copying them from the first entries from the respective result list: 

    git log
git log --reverse

    Open a terminal, cd to your git repository, and checkout the latest commit: 

    git checkout latest
./opt/program/soffice

    In bibisect-linux-64-5.2, and more recent repositories, you need to use the following commands instead: 

    git checkout origin/master
./instdir/program/soffice

    If the bug does not appear in that version, put a comment on the bug saying "Regression does not appear in latest version of <name of bibisect repository>, e.g. linux-43all.git and must be younger" and add the tags bibisected and bibisectedNewer as Keywords. You've now completed your bibisection! If there is a newer bibisect repository available, please consider downloading it and testing the bug again.

    If the bug does appear in the latest version, continue.

    After testing with the latest build, we next test with the oldest build included in the repo and check that the regression is not there: 

    git checkout oldest
./opt/program/soffice

    In bibisect-linux-64-5.3, bibisect-linux-64-5.4 and more recent repositories, you need to use the following commands instead: 

    git checkout oldest
./instdir/program/soffice

    If the bug is already present at this point, it is not a regression in the range covered by the repo, but an even older bug.

    First, put a comment on the bug saying "Regression does appear in oldest version of <name of bibisect repository> and must be older"

    If you are using the 43all repo, then:

    1. Add the word preBibisect to the Keywords, and
    2. Set the version of LibreOffice in the bug report to 3.5beta0 (which is the earliest version you can set).

    If you are using another (newer) bibisect repo, please try downloading and testing with 43all.

    If the bug does not appear in the oldest version, this means it is a regression in the range covered by the download and we can corner it down very well (hooray!). We will now leverage one of git's built-in tools to perform a binary search: 

    git bisect start latest oldest

    In bibisect-linux-64-5.3, bibisect-linux-64-5.4 and more recent repositories, you need to use the following commands instead: 

    git bisect start origin/master oldest

    Then repeat these commands: 

    ./opt/program/soffice
git bisect good # if the bug is not there
git bisect bad  # if the bug is there

    In bibisect-linux-64-5.3, bibisect-linux-64-5.4 and more recent repositories, you need to use the following commands instead: 

    ./instdir/program/soffice
git bisect good # if the bug is not there
git bisect bad  # if the bug is there

    NB: From time to time, the currently check-out version of LibreOffice may fail to start. This can happen because, although the bibisect repo includes only successful builds, a successful build is not guaranteed to really work. In those cases, you'll want to skip a particular build: 

    git bisect skip # if you cannot get far enough to try the bug

    After several repetitions, git will print out something like this: 

        9625329ea5a7e3e8475cd21c07726beec20573bd is the first bad commit
    commit 9625329ea5a7e3e8475cd21c07726beec20573bd
    Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
    Date:   Thu Dec 8 12:29:59 2011 +0100

        source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
       
        commit 2d19e9bb07ccff3134f855812dddfda5c07b1fe4
        Author:     Jan Holesovsky <kendy@suse.cz>
        AuthorDate: Wed Nov 16 14:17:03 2011 +0100
        Commit:     Jan Holesovsky <kendy@suse.cz>
        CommitDate: Wed Nov 16 14:21:33 2011 +0100
       
            Kill one usage of chrel.sed to fix build.

    We'll want to append this useful information to the bug report. (The source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 line is the important piece, but please copy-in the entire message to a new comment).

    With our testing complete, please add bibisected to the Keywords so that this bug will no longer appear in the list of bugs that need bibisecting.

    Linux Notes

    Tags in bibisect repos

    The 43all repo has tags like last35onmaster, last36onmaster that mark the last build on master before that release was branched off. If you have a bug that you already know has been introduced between 4.0 and 4.1, you can do: 

    git bisect start last41onmaster last40onmaster

    To just search in that range. Note that the branch-off of a major release is much earlier than the first final release (usually between alpha and beta). So even a bug in the first major release might be well have been introduced _after_ branchoff. It should still be bibisectable on master on the way to the next release as almost all commits on the release branch go to master first. So: handle with care.

    Reliably running old builds

    The oldest builds in 43all repo refuse to work with JRE 8 or newer. They are verified as working in an Ubuntu 14.04 installation with JRE 6.

    As a rule of thumb, using a Ubuntu 14.04 virtual machine will guarantee a pleasant experience with 43all repo and others from the same time range.

    You might bump into a quirk in the oldest builds of 43all: after checkout, the binary refuses to run on the first attempt. The solution is just to run it a second time.

    Special considerations for daily dbgutil repository

    Each version has a file build-info.txt, and the first line of that file has the source-hash of that that build. It is helpful if you include the source hashes of the last good version and the first bad version in your report of bibisect results.

    Using the max repository series

    Be sure to read the README which indicates that in order to begin using this bibisect, first run: 

    git reset --hard latest

    The "max" repositories (43max, 44max, 50max) contain one commit for each source commit of the corresponding master range, with the exceptions that:

    • Changes which only affected an architecture other than 64bit Linux are omitted
    • Ranges of broken builds are collapsed to a single commit

    When broken builds have been skipped, a comment will be present in the commit message: 

       (Bibisect: This commit covers source commit(s) ...... which failed to build)

    In this case, the specific source commit has not been identified, and the result still requires further investigation.

    In all other cases, the result can be taken as equivalent to having run "git bisect" on the source tree, and this should be represented by adding bisected and bibisected in the Keywords.


    Youtube Video Tutorial

    A short video tutorial (Youtube) by Florian Reisinger.

    • (Apologies for the audio quality of this screencast)

    Virtual Machines

    Testing GNU/Linux bugs inside a virtual machine (VM) is a great way to leverage the large number of bibisect repositories available for this platform if you're using Windows or macOS as your host OS.

    Suggested setup:

    • Virtualization Software: VirtualBox
    • Guest OS: Ubuntu 14.04 x86_64 (Desktop version)
    • (Virtual) Hard drive: at least 40 GB (some bibisect repositories are over 10 GB each)

    Many other options exist. One way to quickly set up various VMs for a number of OS's versions is to use quickemu (and quickgui on top if you want to have a graphical interface).

    Short (and sweet) Instructions - Linux Only

    1. Download repo (multiple GB, don't worry - just one time) - See #Versions
    2. Unpack repo to somewhere useful
    3. Open terminal and make sure git and libjpeg62 are installed. On Ubuntu it would be 
      sudo apt install git libjpeg62
    4. Enter the directory of the unpacked repo 
      cd [downloaded directory location]
    5. Start bisecting 
      git bisect start master oldest
    6. Launch LibreOffice in the current revision 
      ./instdir/program/soffice
    7. Try replicating bug for this revision
      1. if it doesn't exist 
        git bisect good
      2. if it does exist 
        git bisect bad
    8. Repeat step 6 and 7 until you get a message like 
      5a52acff89c733acbd4be6896748c76a010cb507 is the first bad commit

    Versions

    The repositories here cover a combined range from 3.5beta0 through master.


    Built on Version Maintainer Commit range from Commit range to Commits in range Number of builds Download links Download size Comments
    Ubuntu 12.04 x64
    43all     		Bjoern Michaelsen d6cde02d c15927f2 60733 755 builds repo 12 GB this replaces the old 42all repository (3.5 to 4.3)
    Ubuntu 14.04 x64
    41max     		MJFrancis efca6f15 863d38fb 9971 8969 builds repo 5.5 GB The range from 4.0 branch point to 4.1 branch point. See #Using the max repository series
    Ubuntu 14.04 x64
    42max     		MJFrancis a2c9d4f8 22ea573b 12145 11048 builds repo 8.2 GB The range from 4.1 branch point to 4.2 branch point. See #Using the max repository series
    Ubuntu 14.04 x64
    43max     		MJFrancis c15927f2 3f94c9e9 11091 ? 9644 builds ? repo 7.4 GB The range from 4.2 branch point to 4.3 branch point. See #Using the max repository series
    Ubuntu 14.04 x64
    44max     		MJFrancis c15927f2 3f94c9e9 11091 9644 builds repo 7.4 GB The range from 4.3 branch point to 4.4 branch point. See #Using the max repository series
    Ubuntu 14.04 x64
    50max     		MJFrancis 57d6b92b 0db96caf 10009 8174 builds repo 6.8 GB The range from 4.4 branch point to 5.0 branch point. See #Using the max repository series
    Linux 64bit
    bibisect-linux-64-5.2     		Xisco Fauli 3ca42d8d 6238f71d 8897 builds TDF: repo libreoffice-5-1-branch-point to libreoffice-5-2-branch-point and then libreoffice-5-2
    Linux 64bit
    bibisect-linux-64-5.3     		Norbert Thiebaud 5b168b3f e5ebc3d7 7490 builds TDF: repo libreoffice-5-2-branch-point to libreoffice-5-3-branch-point and then libreoffice-5-3
    Linux 64bit
    bibisect-linux-64-5.4     		Xisco Fauli 4136757b 328f3e7e 8869 builds TDF: repo libreoffice-5-3-branch-point to libreoffice-5-4-branch-point and then libreoffice-5-4
    Linux 64bit
    bibisect-linux-64-6.0     		Xisco Fauli 487d0388 TDF repo, China git-bundle mirror 7.4 GB libreoffice-5-4-branch-point to libreoffice-6-0-branch-point and then libreoffice-6-0
    Linux 64bit
    bibisect-linux-64-6.1     		Xisco Fauli 6eeac353 TDF repo, China git-bundle mirror 9.1 GB libreoffice-6-0-branch-point to libreoffice-6-1-branch-point and then libreoffice-6-1
    Linux 64bit
    bibisect-linux-64-6.2     		Xisco Fauli 3a801799 TDF repo, China git-bundle mirror 9.7 GB libreoffice-6-1-branch-point to libreoffice-6-2-branch-point and then libreoffice-6-2
    Linux 64bit
    bibisect-linux-64-6.3     		Xisco Fauli a8afeb7c TDF repo, China git-bundle mirror 7.9 GB libreoffice-6-2-branch-point to libreoffice-6-3-branch-point and then libreoffice-6-3
    Linux 64bit
    bibisect-linux-64-6.4     		Xisco Fauli c98b1f1c TDF: repo, China git-bundle mirror 7.1 GB libreoffice-6-3-branch-point to libreoffice-6-4-branch-point and then libreoffice-6-4. With KDE5 support!
    Linux 64bit
    bibisect-linux-64-7.0     		Xisco Fauli 9bc848cf TDF: repo 7.8 GB libreoffice-6-4-branch-point to libreoffice-7-0-branch-point and then libreoffice-7-0.
    Ubuntu 18.04.4 64bit (should work on other systems with glibc >= 2.27)
    bibisect-linux-64-7.0-CN     		Kevin Suo 9bc848cf libreoffice-7-0-branch-point ~3 source hashes per build. linux-64-7.0-CN.git-bundle (China) 17 GB Server located in China, With EN, zh_CN and zh_TW UI enabled.
    Linux 64bit
    bibisect-linux-64-7.1     		Xisco Fauli 574c5709 TDF: repo 7.2 GB libreoffice-7-0-branch-point to to libreoffice-7-1-branch-point and then libreoffice-7-1.
    Fedora 30
    bibisect-linux-64-7.1-CN     		Kevin Suo libreoffice-7-0-branch-point libreoffice-7-1-branch-point ~3 source hashes per build. linux-64-7.1-CN.git-bundle (China) 11 GB Server located in China, With EN, zh_CN and zh_TW UI enabled.
    Linux 64bit
    bibisect-linux-64-7.2     		Xisco Fauli 738bcf5e ffa09959 TDF: repo 8.1 GB libreoffice-7-1-branch-point to libreoffice-7-2-branch-point and then libreoffice-7-2.
    Linux 64bit
    bibisect-linux-64-7.3     		Xisco Fauli ff2ba77f TDF: repo, China git-bundle mirror 7.2 GB libreoffice-7-2-branch-point to libreoffice-7-3-branch-point and then libreoffice-7-3.
    Linux 64bit
    bibisect-linux-64-7.4     		Xisco Fauli 436f14c2 TDF: repo 8.2 GB libreoffice-7-3-branch-point to libreoffice-7-4-branch-point and then libreoffice-7-4.
    Linux 64bit
    bibisect-linux-64-7.5     		Xisco Fauli c94961c6 6414 TDF: repo 8.4 GB libreoffice-7-4-branch-point to libreoffice-7-5-branch-point and then libreoffice-7-5.
    Linux 64bit
    bibisect-linux-64-7.6     		Xisco Fauli 1c629ca0 TDF: repo ?? GB libreoffice-7-5-branch-point to libreoffice-7-6-branch-point and then libreoffice-7-6.
    Linux 64bit
    bibisect-linux-64-24.2     		Xisco Fauli 6f227b0d TDF: repo ?? GB libreoffice-7-6-branch-point to libreoffice-24-2-branch-point and then libreoffice-24-2.
    Linux 64bit
    bibisect-linux-64-24.8     		Xisco Fauli 898d5d47 TDF: repo ?? GB libreoffice-24-2-branch-point to libreoffice-24-8-branch-point and then libreoffice-24-8.
    Linux 64bit
    bibisect-linux-64-25.2     		Xisco Fauli 798b43c4 TDF: repo ?? GB libreoffice-24-8-branch-point to master.
    Fedora 34 64bit (should work on other systems with glibc >= 2.33)
    bibisect-linux-64-7.3-CN     		Kevin Suo libreoffice-7-2-branch-point libreoffice-7-3-branch-point ~3 source hashes per build. linux-64-7.3-CN.git-bundle (China) 6.0 GB Server located in China, With EN, zh_CN and zh_TW UI enabled.
    Fedora 34 64bit (should work on other systems with glibc >= 2.33)
    bibisect-linux-64-7.4-CN     		Kevin Suo libreoffice-7-3-branch-point libreoffice-7-4-branch-point 1 source hashes per build (ignoring unrelated commits such as submodule updates and typo fixing etc) Git Repository (China) (Auto build start at 06:00 UTC+8 everyday) Server located in China, With EN, zh_CN and zh_TW UI enabled.
    Linux x86_64 dbgutil
    dbgutil     		Miklos Vajna TDF: repo (machine died, so not much of 6.3 is available.) Latest libreoffice-x-y branchpoint to latest master.
    Releases
    releases     		Xisco Fauli 378+ releases TDF: repo 11+ GB Release builds of OOo 3.3.0, LO 3.3.0 - LO 7.3.4.2. Note that the executables in this repo are all under opt/

    Older dbgutil daily repos

    • 6.2 -> 6.3 is only available till 2018-12-18, then I (Miklos) lost the man-power to keep maintaining it
    • 6.1 -> 6.2: repo (4.8G)
    • 6.0 -> 6.1: repo (5.3G)
    • 5.4 -> 6.0: repo (5.1G)
    • 5.3 -> 5.4: repo (4.8G)
    • 5.2 -> 5.3: repo (4.3G)
    • 5.1 -> 5.2: repo (4.1G)
    • 5.0 -> 5.1: repo (4.5G)
    • 4.4 -> 5.0: repo (4.7G)
    • 4.3 -> 4.4: repo (4.5G)
    • 4.2 -> 4.3: repo (4.3G)
    • 4.1 -> 4.2: repo (3.4G)
    • even older versions


    Troubleshooting

    How to fix 'libboost_filesystem-mt.so.1.53.0: cannot open shared object file'

    This happens with bibisect-linux-64-5.3 due to liborcus-0.11.so.0 in the repository being linked to this particular library since 72e6f08c.

    1. Install libboost_filesystem in your distribution
    2. Create a link:
    sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so /usr/lib/x86_64-linux-gnu/libboost_filesystem-mt.so.1.53.0

    How to fix GTK errors of not starting LibreOffice

    The error 'libvclplug_gtk3lo.so: undefined symbol: gtk_widget_path_iter_set_object_name' happens with bibisect-linux-64-5.2 due to a problem with GTK3.

    1. Launch LibreOffice in GTK2: SAL_USE_VCLPLUGIN=gtk instdir/program/soffice

    LibreOffice may not start GUI from older repos 4.2 or 4.4 if ran on newer OS with updated GTK3.

    2. Launch LibreOffice (which is in 'opt' in older versions) without GTK: SAL_USE_VCLPLUGIN=gen opt/program/soffice

    How to fix 'lookup error: /lib/x86_64-linux-gnu/libgcrypt.so.20: undefined symbol: gpgrt_b64dec_proc, version GPG_ERROR_1.0'

    This happens in parts of bibisect-linux-64-5.4 / 6.0 at least in Ubuntu 22.04, and got fixed by commit 1bb07b76.

    Workaround for Ubuntu 22.04

    1. Download libgcrypt20 package for Ubuntu 20.04
    2. Extract it using the command: dpkg -x <dpkg package> <target directory>
    3. From <target directory>/lib/x86_64-linux-gnu/, move the library file and the symlink to a separate directory, e.g. $HOME/oldlib
    4. Start LibreOffice like: LD_LIBRARY_PATH=$HOME/oldlib ./soffice

    Working around backward compatibility issues

    As history marches on, it becomes difficult to run old LibreOffice versions on the latest Linux distributions. One solution is to run virtual machines with old distributions, but the setup and overall experience can be a bit tedious. Another way is to use containers. Distrobox is a tool that allows to easily set up containers and run graphical applications in them. It uses either podman or docker to manage the containers.

    Arguably the easiest way to start is by installing podman which will then be picked up by Distrobox. The container manager can be explicitly defined by configuration.

    Install the xhost package (check the name as it varies between distributions).

    Add the following to the ~/.bashrc of your host machine and restart your terminal: 

    xhost +si:localuser:$USER

    Create ~/distroboxhomes to store the home directories of the containers. Create subdirectories for the container homes.

    For running bibisect repos 5.2 and newer, you can pick Fedora 30. In the pre-init hooks you can add libreoffice to broadly take care of dependencies, but you need some additional ones. 

    distrobox create --name fedora30 --image fedora:30 --pre-init-hooks "sudo dnf install -y git java-1.8.0-openjdk.x86_64 dbus-glib kf5-kcoreaddons.x86_64 kf5-ki18n.x86_64 kf5-kconfig.x86_64 kf5-kwindowsystem.x86_64 kf5-kio.x86_64 libreoffice" --home $HOME/distroboxhomes/fedora30

    In the .bash_profile of fedora30 in the distroboxhomes directory, you have to add 

    unset XDG_DATA_DIRS

    Otherwise the gtk2/3 backends will not launch. You can also add convenience aliases for the different UIs: 

    alias libogen='SAL_USE_VCLPLUGIN=gen instdir/program/soffice'
alias libogtk3='SAL_USE_VCLPLUGIN=gtk3 instdir/program/soffice'
alias libokf5='SAL_USE_VCLPLUGIN=kf5 instdir/program/soffice'

    For the oldest bibisect repos, you can use CentOS 7. 

    distrobox create --name centos7 --image centos:7 --init-hooks "sudo yum install -y epel-release git java-1.7.0-openjdk.x86_64 java-1.8.0-openjdk.x86_64 libreoffice libpng12" --home $HOME/distroboxhomes/centos7

    In the centos7 .bash_profile, in addition to unset XDG_DATA_DIRS you can include an alias that allows running the builds from 50max repo: 

    alias libo50='LD_PRELOAD=/usr/lib64/libcurl.so.4:/usr/lib64/libnss3.so:/usr/lib64/libnssutil3.so SAL_USE_VCLPLUGIN=gen opt/program/soffice'

    For more efficient navigation in the command line with Ctrl to jump between word boundaries and deleting words, you can create an .inputrc file in the centos7 home like so: 

    # C-backspace
"\C-h": backward-kill-word

# C-delete
"\e[3;5~": kill-word

# Move with C-right, left
"\e[1;5C": forward-word
"\e[1;5D": backward-word

    In fedora30 only Ctrl-Backspace binding is missing by default.

    Now you enter a container with 

    distrobox enter fedora30

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/Bibisect/Linux&oldid=765396"