This page provides information about using our Bibisect repositories on computers running MS Windows.
- 1 Introduction
- 2 Limitations
- 3 Choosing a Bibisect repository
- 4 Setting up Environment
- 5 Downloading Bibisect Repository
- 6 Bibisecting the Bug
- 7 Pesky pycache files
- 8 Windows-specific Notes
- 9 Youtube Video Tutorial
- 10 VM
- 11 Versions
- 12 Testing Versions
- 13 How to fix 'instdir/cache/opengl_device.log' error
Our bibisect repositories were originally built on Ubuntu 64bit machines, and most of our repositories still target GNU/Linux systems. We now have a few repositories built for Windows, and are adding more in time.
If you're testing cross-platform and wish to test Windows bugs on a different OS, one option is to set up a virtual machine running macOS (see #VM below).
Unlike GNU/Linux and macOS, there are some speed issues with Git running on Windows. The speed of git may somewhat influence the speed at which one can switch between LibreOffice versions while bibisecting, but will not affect the operation of LibreOffice or the speed of the program.
Choosing a Bibisect repository
As you can see in the #Versions table below, there aren't many bibisect repositories for Windows yet, but we are working on that.
With fewer repositories, it's much easier to finish the bibisecting process. Right now we have just one active repo:
If a Windows-only regression isn't present in that repository, then the bibisection process is done!
(Note: Once we have multiple bibisect repositories, we can update this section based on the info from the GNU/Linux and macOS pages)
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. On Windows, we suggest that you install Cygwin.
We have notes about installing Cygwin here:
- If you're running 64bit Windows, install the 64bit Cygwin package, otherwise use the 32bit installer
- You'll want the following cygwin packages: git, ssh
msvcr120.dll Visual C++ Redistributable Packages for Visual Studio 2013 is required for LibreOffice 5.0 or higher.
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.
From a Web Server
All of our currently available Windows bibisect repositories are available as git repositories. If we make one available as a web download, it'll look like this:
Download the .tar.xz file from the appropriate TDF server, and then extract the git repository using:
> tar -xf Win-32-X.y.tar.xz
To verify one of our repos, you'll need the gpg-key of the person/organization who produced it.
Here's an example of verification with one of our Linux repos: (you'd need the gpg-key from https://launchpad.net/~bjoern-michaelsen):
> gpg --keyserver keyserver.ubuntu.com --recv-keys XXXXXXXX # replace XXXXXXXX with the OpenPGP keys from web page > gpg --verify bibisect-43all.tar.xz.sig
Some repos are available from our Gerrit hosting. You may clone a bibisect repository as you would any other git repository:
> git clone git://gerrit.libreoffice.org/bibisect-win32-5.0
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 :-(
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!
Open a terminal, cd to your git repository, and checkout the latest commit:
> git checkout latest > instdir/program/soffice
If "latest" tag does not exist, you can use "master". If no tags exist in the repository, you can check the instructions for creating them.
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-win32-5.0 and must be younger" and add bibisected and bibisectedNewer to the 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 > 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 bibisect-win32-5.0 repo, then:
- Add the word preBibisect to the Keywords, and
- Set the version of LibreOffice in the bug report to 184.108.40.206.alpha0+ Master
If you are using another (newer) bibisect repo, please try downloading and testing with bibisect-win32-5.0.
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
Then repeat these commands:
> 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 <email@example.com> Date: Thu Dec 8 12:29:59 2011 +0100 source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 commit 2d19e9bb07ccff3134f855812dddfda5c07b1fe4 Author: Jan Holesovsky <firstname.lastname@example.org> AuthorDate: Wed Nov 16 14:17:03 2011 +0100 Commit: Jan Holesovsky <email@example.com> 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 the tag bibisected to the Keywords so that this bug will no longer appear in the list of bugs that need bibisecting.
Sometimes a bibisect repo does not have any tags. In this situation you can git bisect start using the latest and oldest commit hashes, but you might find it convenient to create tags for them. Sometimes only the latest tag is missing in which case you can use "master".
> git log
Copy the commit hash from the topmost commit and use it for the tagging command (replace example hash with what you've got in your clipboard):
> git tag latest e3f920c8fe63c14ebb83ca9c4a86247043b054df
> git log --reverse
Again, copy the topmost commit hash and:
> git tag oldest 633bfe84509c1953415e5dd0f564098a16890131
Now you can list your tags with:
> git tag -l
Pesky pycache files
Sometimes when trying to do a git checkout, you might be nagged to stash or commit some pycache files. In this case it helps to run this in the bibisect folder:
find . | grep -E "(__pycache__|\.pyc|\.pyo$)" | xargs rm -rf
Youtube Video Tutorial
Testing Windows bugs inside a VM is a great way to leverage the large number of bibisect repositories available for this platform if you're using macOS or GNU/Linux as your host OS.
- Virtualization Software: VirtualBox
- Guest OS: Windows 7 or later
- (Virtual) Hard drive: at least 40GB (some bibisect repositories are over 10GB each)
|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|
|Windows 32bit||bibisect-win32-4.3||Cloph||No||TDF: archive||libreoffice-4-2-branch-point up to libreoffice-4-3-branch-point. Fetch commit notes: git fetch origin refs/notes/commits:refs/notes/commits Do regular bibisect with tag oldest and latest, and if you end up on a commit that has a note attached, do as it says (continue between the tags fixup_oldest and fixup_latest)|
|Windows 32bit||bibisect-win32-4.4||Cloph||No||TDF: archive||libreoffice-4-3-branch-point up to libreoffice-4-4-branch-point with an interval of ~8 commits.|
|Windows 32bit||bibisect-win32-5.0||Norbert Thiebaud||Yes||TDF: repo||libreoffice-4-4-branch-point to libreoffice-5-0-branch-point and then libreoffice-5-0|
|Windows 32bit||bibisect-win32-5.1||Norbert Thiebaud||Yes||TDF: repo||libreoffice-5-0-branch-point to libreoffice-5-1-branch-point and then libreoffice-5-1|
|Windows 32bit||bibisect-win32-5.2||Norbert Thiebaud||Yes||core commit 49c2b980||core commit e5ebc3d7||8819 builds||TDF: repo||libreoffice-5-1-branch-point to libreoffice-5-2-branch-point and then libreoffice-5-2|
|Windows 32bit||bibisect-win32-5.3||Norbert Thiebaud||Yes||core commit 5b168b3f||core commit e7738ab7||8039 builds||TDF: repo||libreoffice-5-2-branch-point to libreoffice-5-3-branch-point and then libreoffice-5-3|
|Windows 32bit||bibisect-win32-5.4||Xisco Fauli||Yes||core commit 4136757b||core commit 534fd9aa||7647 builds||TDF: repo||libreoffice-5-3-branch-point to libreoffice-5-4-branch-point and then libreoffice-5-4|
|Windows 32bit||bibisect-win32-6.0||Xisco Fauli||Yes||core commit 487d0388||TDF: repo||libreoffice-5-4-branch-point to libreoffice-6-0-branch-point and then libreoffice-6-0|
|Windows 32bit||bibisect-win32-6.1||Xisco Fauli||Yes||core commit 6eeac353||TDF: repo||libreoffice-6-0-branch-point to libreoffice-6-1-branch-point and then libreoffice-6-1|
|Windows 32bit||bibisect-win32-6.2||Xisco Fauli||Yes||core commit 3a801799||TDF: repo||libreoffice-6-1-branch-point to libreoffice-6-2-branch-point and then libreoffice-6-2|
|Windows 32bit||bibisect-win32-6.3||Xisco Fauli||Yes||core commit a8afeb7c||TDF: repo||libreoffice-6-2-branch-point to libreoffice-6-3-branch-point and then libreoffice-6-3|
|Windows 64bit||bibisect-win64-6.4||Xisco Fauli||Yes||core commit c98b1f1c||TDF: repo||libreoffice-6-3-branch-point to latest master.|
These are for testing purposes only.
|Build 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|
|WIN||win 2013-12-13_2013-12-19||Cloph?||No||?||?||?||?||TDF: repo||3.5GB||not active, for testing only|
How to fix 'instdir/cache/opengl_device.log' error
This happens with bibisect-win32-6.2 due to an untracked file
error: The following untracked working tree files would be overwritten by checkout: instdir/cache/opengl_device.log Please move or remove them before you switch branches. Aborting