From The Document Foundation Wiki
< QA‎ | Bibisect
Jump to: navigation, search

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


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 #VM 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.

Distro 43all 43only 50max
Ubuntu 13.10 (Saucy) have to install libjpeg62 for included versions older than 3.5 (sudo apt-get install libjpeg62) should work out-of-the-box
Ubuntu 12.04 LTS (Precise) have to install libjpeg62 for included versions older than 3.5 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) yum install libcurl, export LD_PRELOAD=/usr/lib64/
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 .tar.xz file from Canonical's servers and then extract the git repository using:

tar -xf bibisect-43all.tar.xz


To verify one of our repos, you'll need the gpg-key of the person/organization who produced it.

For example, to verify the 43all repo, you'll need the gpg-key from and will want to check the signature as follows:

gpg --keyserver --recv-keys XXXXXXXX # replace XXXXXXXX with the OpenPGP keys from web page
gpg --verify bibisect-43all.tar.xz.sig

Using Git

As an example, the dbgutil daily bibisect is available from TDF servers. You may clone the bibisect repository as you would any other git repository:

git clone git://

Please be aware that the original download may be several gigabytes, so 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 :-(

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.

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

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 origin/master

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. bibisect-43all.tar.xz 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

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

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:

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:

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 <>
    Date:   Thu Dec 8 12:29:59 2011 +0100

        commit 2d19e9bb07ccff3134f855812dddfda5c07b1fe4
        Author:     Jan Holesovsky <>
        AuthorDate: Wed Nov 16 14:17:03 2011 +0100
        Commit:     Jan Holesovsky <>
        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).

The developers will also appreciate having the log output in the same comment:

git bisect log

Here's an example of how the log output might appear to you:

   git bisect start 'latest' 'oldest'
   # good: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3
   git bisect good 2faf4bc12ab490370d2196dedbc8091f9b09d0a5
   # bad: [b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4] source-hash-ce60138d339a5eb2a174a5d27063249acf2cac42
   git bisect bad b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4
   # good: [0a28a62d53e996cf66d86e9bfb63ddc6ade75b7e] source-hash-71cbcb62028295a98ceee60cb4c4ee425bafcd2e
   git bisect good 0a28a62d53e996cf66d86e9bfb63ddc6ade75b7e
   # bad: [9625329ea5a7e3e8475cd21c07726beec20573bd] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
   git bisect bad 9625329ea5a7e3e8475cd21c07726beec20573bd
   # good: [89d91bb6074026dc0894bcdc6aaf8f6124102da7] source-hash-fb754a0df859e30255c25af8fa19bfaa75f257e7
   git bisect good 89d91bb6074026dc0894bcdc6aaf8f6124102da7

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.

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)


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

Suggested setup:

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

Short (and sweet) Instructions - Linux Only

  1. Download repo (multiple gigs, 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-get install git libjpeg62
  4. Enter the directory of the unpacked repo
    cd [downloaded directory location]
  5. Start bisecting
    git bisect start latest oldest
  6. Launch Libreoffice in the current revision
  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 & 7 until you get a message like
    5a52acff89c733acbd4be6896748c76a010cb507 is the first bad commit
  9. Get the log of the operation and Copy/paste it to bug report
    git bisect log


The repositories here cover a combined range from 3.5beta0 through the 5.0 branch point (approximately).

Built on Version Maintainer Auto-fed? Commit range from Commit range to Commits in range Number of builds Download links Download size Bibisected bugs in range Comments
Ubuntu 12.04 x64
Bjoern Michaelsen No core commit d6cde02d core commit c15927f2 60733 755 builds Canonical: repo signature 12Gb 542+[1] this replaces the old 42all repository (3.5 to 4.3)
Bjoern Michaelsen No core commit 22029c7e core commit c15927f2 13951 220 builds Canonical: repo signature 3.6Gb only the range from 4.2 branch point to 4.3 branch point[2]
Ubuntu 14.04 x64
Robinson Tryon No core commit dea4a3b9 core commit 2b5b04e1 11075 394 builds tdf download 3.7G

(3.2G download)

The range from 4.3 branch point to 4.4 beta1 tag
Ubuntu 14.04 x64
MJFrancis Static core commit efca6f15 core commit 863d38fb 9971 8969 builds tdf download 5.5G The range from 4.0 branch point to 4.1 branch point. See #Using the max repository series
Ubuntu 14.04 x64
MJFrancis Static core commit a2c9d4f8 core commit 22ea573b 12145 11048 builds tdf download 8.2G The range from 4.1 branch point to 4.2 branch point. See #Using the max repository series
Ubuntu 14.04 x64
MJFrancis Static core commit c15927f2 core commit 3f94c9e9 11091 ? 9644 builds ? tdf download 7.4G The range from 4.2 branch point to 4.3 branch point. See #Using the max repository series
Ubuntu 14.04 x64
MJFrancis Static core commit c15927f2 core commit 3f94c9e9 11091 9644 builds tdf download 7.4G The range from 4.3 branch point to 4.4 branch point. See #Using the max repository series
Ubuntu 14.04 x64
MJFrancis Static core commit 57d6b92b core commit 0db96caf 10009 8174 builds tdf download 6.8G The range from 4.4 branch point to 5.0 branch point. See #Using the max repository series
Linux 64bit
Norbert Thiebaud Yes core commit 5b168b3f TDF: repo libreoffice-5-2-branch-point to latest master.
Linux 64bit
Xisco Fauli Yes core commit 4136757b TDF: repo libreoffice-5-3-branch-point to latest master.
Linux 64bit
Xisco Fauli Yes core commit 487d0388 TDF: repo libreoffice-5-4-branch-point to latest master.
Linux x86_64 dbgutil
Miklos Vajna Yes TDF: repo Latest libreoffice-x-y branchpoint to latest master.
Xisco Fauli No (useful to add to it?) 172 releases tdf download 6.0G Release builds of OOo 3.3.0, LO 3.3.0 - LO5.2.3.3- libreoffice-

Older dbgutil daily repos

  1. another 250+ bugs reference bibisect, but do not have the bug tagged. Possibly just forgotten to tag
  2. this one replaces the two smaller partial repos: 4.2 branch point to alpha1 and alpha1 to 4.3 branch point -- those will likely be removed soon

How to fix ' cannot open shared object file'

I experienced this problem with bibisect-50max repository

1. Check whether librtmp is installed

locate librtmp


2. Create a link

sudo ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/

How to fix ' cannot open shared object file'

This happens with bibisect-linux-64-5.3 due to in the repository being linked to this particular library since commit core commit 72e6f08c.

1. Insall libboost_filesystem in your distribution

2. Create a link

sudo ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/