Регрессионное тестирование в Wine
(Распространяйте данное руководство по всем русскоязычным сборникам мануалов, это более чем приветствуется автором. Данный текст является переводом официального руководства, расположенного по адресу: http://wiki.winehq.org/RegressionTesting, с многочисленными исправлениями. В официальном руководстве есть несколько ошибок и неточностей, учтите, если собираетесь работать по нему. Впрочем, тут они тоже могут быть, если найдёте, можете смело исправлять.)
Авторский перевод некоторых англоязычных терминов и общих фраз:
- commit, patch — набор изменений
- revert the commit, revert the patch — удалить набор изменений из дерева исходных кодов (по другому, репозитория)
- broken compile — Компиляция, выдающая ошибки
Содержание
- 1 Вступление
- 2 Подготовка к проведению тестирования
- 3 Компиляция исходных кодов Wine
- 4 Выполнение команды bisect
- 5 Тестирование компиляции, выдающей ошибки
- 6 Автоматизация регрессионного тестирования
- 7 Сброс bisect
- 8 Удаление набора изменений из дерева исходных кодов
- 9 Проверка правильности результатов bisect
- 10 Применение патча к дереву исходных кодов
- 11 Обновление дерева исходных кодов Git
- 12 Устранение неполадок
- 13 Отключение оптимизации для ускорения компиляции
- 14 Отключение тестов для ускорения компиляции
- 15 Оформление отчёта об ошибке
Вступление
В этой статье описан один из вариантов проведения регрессионного тестирования, возможны и другие. Рекомендуется для прочтения пользователям Wine, желающим помощь его развитию, а также тем, кто желает глубже изучить систему управления версиями Git, поскольку часть статьи относится именно к ней.
В некоторых случаях, когда в основную ветвь Wine отправляется набор изменений в коде (англ. commit), предназначенный для исправления какой-либо ошибки или введения дополнительной функциональности, он вызывает новую ошибку. Такая ситуация называется регрессией. Чаще всего возникшая ошибка остаётся незамеченной до выхода новой версии Wine. И поскольку с момента появления данной ошибки до выпуска последующей версии в основную ветвь разработки могли быть сохранены несколько сотен наборов изменений, бывает сложно выяснить, какой именно набор стал причиной ошибки. Для этого и существует регрессионное тестирование.
Регрессионное тестирование позволяет найти изменение, являющееся источником ошибки. В Wine оно выполняется посредством команды bisect, встроенной в систему управления версиями Git.
Подготовка к проведению тестирования
Прежде всего проверьте, установлена ли в вашей системе Git.
git --version
Git должна быть установлена и иметь номер версии не ниже 1.4.1 (которая была выпущена в июле 2006). Если Git отсутствует, установите её при помощи системы управления пакетами. К примеру, в Ubuntu это можно сделать следующей командой:
sudo apt-get install git-core
Убедитесь, что номер версии не ниже 1.4.1, если у вас старая версия дистрибутива опереционной системы. Чтобы проведение регрессионного тестирования заняло меньше времени, установите программу ccache при помощи системы управления пакетами. В Ubuntu наберите команду:
sudo apt-get install ccache
После установки Git и ccache необходимо скачать исходные коды Wine:
git clone git://source.winehq.org/git/wine.git wine-git
Загрузка исходных кодов займёт несколько минут, их размер составляет чуть более 100 Мб. Если соединение блокируется сетевым экраном, вероятно, нужно заменить в адресе git: на http:.
Перейдите в созданную папку wine-git:
cd wine-git
Теперь можно начинать тестирование. Прежде всего необходимо убедиться, что ошибка не была уже исправлена в последней версии основной ветки разработки (англ. current git, тж. HEAD). Для этого потребуется скомпилировать исходные коды Wine.
Компиляция исходных кодов Wine
Компиляция в 32-разрядной операционной системе
Перед установкой необходимо выполнить сценарий configure.
CC="ccache gcc" ./configure --verbose
Если в операционной системе компиляция исходных кодов Wine никогда ранее не выполнялась, то сценарий configure, вероятно, сообщит об отсутствующих зависимых пакетах. Обязательно установите все указанные пакеты. Вновь запустите ./configure. Для установки требуемых пакетов в Ubuntu или Debian, запустите команду:
sudo apt-get build-dep wine wine-dev
или
sudo apt-get install git-core bison flex prelink libfreetype6-dev libx11-dev libasound2-dev gettext libfontconfig1-dev libxcomposite-dev libxcursor-dev libxext-dev libxi-dev libxinerama-dev libxrandr-dev libxrender-dev libxt-dev libxxf86vm-dev libtiff4-dev libjpeg62-dev libpng12-dev libgphoto2-2-dev libusb-dev libssl-dev libv4l-dev libhal-dev libdbus-1-dev libsane-dev libgl1-mesa-dev libglu1-mesa-dev libxml2-dev libxslt1-dev
Эта команда автоматически загрузит и установит требуемые пакеты.
После того, как все необходимые пакеты будут установлены, введите команду:
CC="ccache gcc" ./configure --verbose && make
Компиляция займёт некоторое время. В зависимости от производительности вашей системы она может продлиться от нескольких минут до нескольких часов. На большинстве современных ПК процесс занимает 20-30 минут. Если у вас многоядерный процессор, целесообразнее выполнить команду с параметром -jn, где n — количество ядер процессора. Например, на системе с двухядерным процессором команда примет вид:
CC="ccache gcc" ./configure --verbose && make -j3
После завершения компиляции не выполняйте команду make install, это может повредить установленную версию Wine. Для того, чтобы не ошибиться в выборе запускаемой версии, вводите полный путь (т.е. используйте ~/wine-git/wine вместо wine).
По окончании компиляции проверьте тестируемое приложение на наличие ошибки. Чтобы исключить возможное влияние установленной ранее версии Wine, тестирование проводится с пустой папкой .new_wine. Целесообразнее всего указать новую папку при помощи переменной среды:
export WINEPREFIX=$HOME/.new_wine
Замечание Заметьте, команда export работает только в командной оболочке Bourne shell (bash). Данная переменная среды сбрасывается каждый раз, когда вы завершаете текущую сессию bash, поэтому при последующих сессиях вам может потребоваться повторная установка этой переменной. После завершения регрессионного тестирования необходимо будет удалить папку, которая использовалась для тестирования: rm -rf ~/.new_wine
Также нужно будет сбросить переменную среды, чтобы задействовать папку ~/.wine, которая использовалась до регрессионного тестирования:
unset WINEPREFIX
Установите приложение в новую папку .new_wine (Wine создаст её автоматически):
./wine program_install.exe
Эта команда означает следующее: найти в текущей директории исполняемый файл с названием wine и выполнить его, передав ему в качестве параметра значение program_install.exe. Запустите приложение:
./wine "C:\Program Files\Program Name\program.exe"
Если обнаружилось, что ошибка уже исправлена, то в этом случае вы можете продолжать работу с Wine, который установлен в папку wine-git, или подождать выхода следующей версии. Если ошибка не исправлена, необходимо провести регрессионное тестирование.
Замечания:
- ошибка могла быть исправлена вследствие того, что вы использовали пустую папку .new_wine (в используемой до этого папке, возможно, находились неверно установленные или неработающие файлы приложения);
- при проведении регрессионного тестирования не требуется подключение к Интернету, поскольку у вас уже хранится вся необходимая информация.
Пути для запуска приложений в Wine
Установка программ в Wine является, по сути, частным случаем запуска, поскольку при этом происходит запуск установочного файла. По умолчанию установка приложений ведётся в папку .wine, которая расположена в домашней директории пользователя, причём на некоторых системах размер этой директории может быть ограничен, что необходимо учитывать при установке больших приложений. К примеру, путь к папке .wine у пользователя guest будет выглядеть следующим образом: /home/guest/.wine или ~/.wine. В папке .wine находится папка drive_c, она является аналогом диска С в Windows. Запускать программы можно несколькими способами:
- перейти в папку с программой и передать Wine название файла в качестве параметра (способ подходит как для программ, находящихся в папке drive_c, так и для программ, расположенных в Unix-директории):
cd ~/.wine/drive_c/Program\ Files/Program\ Name ./wine program.exe
- напрямую передать Wine путь до файла, отформатированный в соответствии со стандартом Windows (способ подходит только для программ, находящихся в папке drive_c):
./wine "C:\Program Files\Program Name\program.exe"
./wine start "C:\users\Public\Рабочий стол\Program.lnk"
Замечание: запускать в Wine файл, не являющийся .exe-файлом, следует через команду start, как указано в примере выше.
- напрямую передать Wine путь до файла, отформатированный в соответствии со стандартом Unix (данный способ нежелательно применять для уже установленных программ, используйте его для запуска msi-пакетов, установочных файлов типа SETUP.exe):
Запуск msi-пакета:
./wine start /Unix /home/guest/Packet.msi
Запуск exe:
./wine /home/guest/Packet.exe
Если команде start передаётся путь, отформатированный в соответствии со стандартом Unix, эту команду необходимо запускать с ключом /Unix.
Выполнение команды bisect
Предварительное замечание: если вы не помните версию Wine, в которой ошибка ещё не существовала, то наиболее быстрый способ найти эту версию — установить бинарные пакеты Wine. Это может помочь избежать ненужных компиляций старых версий Wine.
Предположим, вы обнаружили ошибку, которая появилась при обновлении с Wine 0.9.36 до Wine 0.9.37.
Следующая команда подготовит Git к тестированию этой ошибки.
git bisect start git bisect good wine-0.9.36 git bisect bad wine-0.9.37
В некоторых случаях вам может быть известно, в каком именно компоненте находится вызвавший ошибку набор изменений, и вы можете указать этот компонент. К примеру, чтобы сообщить Git, что проблема вызвана изменениями в компоненте wined3d, который работал в версии 0.9.38, но перестал работать после обновления до версии current, выполните команды
git bisect start dlls/wined3d git bisect good wine-0.9.38 git bisect bad
Система Git сообщит вам, что необходимо протестировать n наборов изменений (англ. commit). Это не значит, что необходимо n раз тестировать программу. Git выберет для тестирования набор изменений, который находится посередине между наборами со статусом good и bad. К примеру, если система сообщила вам, что необходимо протестировать 100 наборов, то для тестирования будет выбран 50й набор. После этого запустите компиляцию (не забудьте про параметр -j, если у вас многоядерный процессор):
CC="ccache gcc" ./configure --verbose && make
Если Wine не компилируется с выбранным набором (или возникли какие-то ошибки), пропустите выбранный набор следующей командой:
git bisect skip
Затем вновь запустите команду make. В случае повторной ошибки опять пропустите выбранный набор, до тех пор, пока компиляция не произойдёт успешно. Протестируйте приложение на ошибку. Если она присутствует, это означает, что вызвавший её набор изменений находится в числе первых 50 (более ранних), а не в числе последних 50 (которые были отправлены позднее). Сообщите системе Git о наличии ошибки при помощи команды
git bisect bad
Если же ошибка отсутствует, то проблемный набор находится в числе последних 50. Укажите, что ошибка отсутствует:
git bisect good
После этого Git выберет для тестирования набор, находящийся в середине оставшейся совокупности наборов. Вновь запустите компиляцию командами
CC="ccache gcc" ./configure --verbose && make
И снова протестируйте приложение. Если округлить в большую сторону двоичный логарифм от изначального числа n, которое вам сообщила Git, то вы получите приблизительное число тестирований, которые требуется провести. Двоичный логарифм от 100 примерно равен 6,6. Т.е. вам необходимо 7 раз перекомпилировать Wine и протестировать приложение. Повторяйте указанные операции до тех пор, пока Wine не идентифицирует проблемный набор изменений. Вывод в командной строке будет выглядеть следующим образом:
a460a2df43aa8eae10b1db028c6020829b009c54 is first bad commit commit a460a2df43aa8eae10b1db028c6020829b009c54 Author: Stefan Doesinger <stefandoesinger@gmx.at> Date: Sat Jun 9 14:27:41 2007 +0200 wined3d: Store the gl information in a per adapter structure and initialize it only once. :040000 040000 d8ae35832fcdbca8de07acae73b9e21564ced413 1720cc38fb598110071c9ee4f21f8f61b6f764c3 M dlls
Обратите внимание на строку, которая содержит хеш-сумму в формате SHA1 от проблемного набора изменений.
a460a2df43aa8eae10b1db028c6020829b009c54 is first bad commit
Если в выводе указано:
Bisecting: 0 revisions left to test after this
ЭТО ОЗНАЧАЕТ, ЧТО РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ ЕЩЁ НЕ ЗАВЕРШЕНО! Необходимо ещё один раз провести перекомпиляцию Wine и тестирование приложения. Как только вы идентифицировали проблемный набор изменений, оформите отчёт об ошибке на [1]. Обязательно укажите автора набора изменений в поле CC, а хеш-сумму в поле Regression SHA1. Эти сведения позволят разработчикам гораздо быстрее исправить ошибку. Если после проведения тестов вы ни разу не обнаружили ошибку, каждый раз выдавая статус "bisect good", и при этом последний вывод в терминале содержал сообщение "Release x.x.xx":
b821e839bb33ac8f56939cc582010ecf4d9c25d4 is first bad commit
commit b821e839bb33ac8f56939cc582010ecf4d9c25d4
Author: Alexandre Julliard <julliard@winehq.org>
Date: Fri Mar 21 16:41:33 2008 +0100
Release 0.9.58.
- 100644 100644 9123c03a3138b05cb8ebb5271f554bb76510cd09 3b88d88dcdfc8e148f8e7e0858bf0ca62c0bdff3 M ANNOUNCE
- 100644 100644 900c8932cb5aad58e928a5c3192ab95967dc0664 e001d501bec609c31c5a91ab185a06ef1662f4c8 M ChangeLog
- 100644 100644 5614cdd9b3c6af6d44027f067fcc423e49c49c91 36e035642c055736e2f833210f5db334a6706486 M VERSION
- 100755 100755 a516335cb3e4c67298f285adbdb2ede09da133be 51a9fd0b9741b28a588e2dd3bb57ae2be8805af2 M configure
то это означает, что вам необходимо выполнить сброс команды bisect и указать выпуск с номером x.x.xx в качестве стартового значения как не имеющий ошибки (git bisect good wine-x.x.xx). Столь отличный от других вывод терминала является не более чем описанием выпуска Wine. Иными словами, этот набор изменений представляет собой простой текст с сообщением о выходе новой версии Wine (он не содержит программного кода и не может являтся причиной ошибки, из-за которой вы проводите регрессионное тестирование). То, что вы во всех тестах указывали команду git bisect good, сообщает системе Git, что ни один из всех наборов изменений вплоть до wine-x.x.xx не содержит ошибки. Git проигнорирует эти наборы изменений, за исключением описания выпуска Wine, который может быть последней правкой перед описанием последующего выпуска.
Тестирование компиляции, выдающей ошибки
Если регрессионное тестирование производится в отношении компиляции Wine, т.е. вы ищете набор изменений, из-за которого при компиляции возникают ошибки, проделайте те же процедуры, что и в описанном выше пункте. В таком случае несложно автоматизировать регрессионное тестирование при помощи команды git bisect start и тестового сценария. Более подробно это описано в руководстве к Git: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
Автоматизация регрессионного тестирования
Если регрессию несложно обнаружить средствами командной строки (например, при компиляции возникают ошибки, приложение самопроизвольно закрывается до входа в меню, и т. д.), то для автоматизации процесса можно воспользоваться командой "git bisect run".
К примеру, если команда "winetricks dotnet11" самопроизвольно сбрасывается в версии 1.1.44, но в 1.1.43 она была работоспособна, введите:
git bisect start git bisect good wine-1.1.43 git bisect bad wine-1.1.44 git bisect run ./foo.sh
где foo.sh представляет собой скрипт следующего содержания:
#!/bin/sh CC="ccache gcc" ./configure --disable-tests || exit 125 make || exit 125 rm -rf $HOME/.wine || exit 125 WINE=$HOME/wine-git/wine winetricks -q dotnet11
При тестировании компиляции, выдающей ошибки, содержимое будет следующим:
#!/bin/sh CC="ccache gcc" ./configure --disable-tests || exit 125 make
Данный скрипт должен возвращать ненулевое значение в случае ошибки и нулевое в случае успешного выполнения. Если причина ошибки не в исходных кодах Wine (первый вариант содержимого скрипта), возвращается 125, и Git пропускает текущий набор изменений. Команды, перечисленные в foo.sh обрабатываются как цикл, по результатам выполнения отдельных команд в систему Git передаются следующие значения:
- при успешном выполнении команды (когда после неё нет " || exit 125") — "git bisect good";
- при ошибке (когда после команды нет " || exit 125") — "git bisect bad";
- при успешном выполнении команды (когда после неё есть " || exit 125") — выполнение следующей команды, возврата в Git не происходит;
- при ошибке (когда после команды есть " || exit 125") — "git bisect skip".
Иными словами, если статус выполнения скрипта равен 125, Git запускает "git bisect skip", если 0 — "git bisect good", от 1 до 127, кроме 125 — "git bisect bad."
Сброс bisect
Когда вы завершите тестирование, вам может потребоваться протестировать что-либо ещё. Чтобы сбросить состояние репозитория Git, введите:
git bisect reset
Если вы попытаетесь запустить новую команду bisect до сброса текущей, будет выведена ошибка "won't bisect on seeked tree".
Кроме того, вам может потребоваться выполнить команду
git checkout master
Она возвратит репозиторий в состояние, сответствующее ветке, заданной по умолчанию (если вы этого не сделаете, то следующее выполнение команды git pull, вероятно, выдаст следующее сообщение об ошибке: "You asked me to pull without telling me which branch you want to merge with", т.е. вы не сообщили, с какой веткой собираетесь производить слияние кода).
Удаление набора изменений из дерева исходных кодов
Замечание Иногда удалить определённый набор изменений невозможно (при этом выдаётся сообщение вида "Hunk #1 FAILED at 94."); в таких случаях можно проверить поведение приложения до того, как в дереве исходных кодов появился проблемный набор изменений, и после его появления. Об этом более подробно в разделе Проверка правильности результатов bisect
Если в результате регрессионного тестирования вы нашли набор изменений, вызвавший ошибку, но разработчик ответил вам, что не считает этот набор причиной ошибки, то он может попросить вас удалить этот набор из репозитория.
Во-первых, сбросьте bisect, если вы этого ещё не сделали:
git bisect reset
После этого удалите набор при помощи следующей команды, указав хеш-сумму sha1 данного набора:
git show b821e839bb33ac8f56939cc582010ecf4d9c25d4 | patch -p1 -R
Повторно скомпилируйте Wine и протестируйте приложение. После завершения тестирования сбросьте состояние репозитория к последнему набору изменений Wine.
git reset --hard HEAD
Проверка правильности результатов bisect
Если у вас есть сомнения в том, что bisect точно определила проблемный набор изменений, то вы можете проверить поведение тестируемой программы в двух состояниях дерева исходных кодов Wine: первое - сразу после того, как был применён набор изменений, а второе - как раз перед его применением. Перевести дерево исходных кодов в первое состояние можно следующей командой:
git checkout b821e839bb33ac8f56939cc582010ecf4d9c25d4
Указанный набор изменений будет занесён в переменную HEAD, которая указывает на вершину ветки исходного кода. После чего выполните компиляцию и проверьте наличие ошибки. Она должна присутствовать. Затем переведите дерево исходных кодов во второе состояние:
git checkout b821e839bb33ac8f56939cc582010ecf4d9c25d4^
Обратите внимание на символ "^". Он указывает системе Git, что необходимо сделать активным набор изменений, предшествующий тому, на который ссылается HEAD. Скомпилируйте Wine и протестируйте приложение. Ошибка должна отсутствовать. Если в первом случае ошибка присутствовала, а во втором нет, то проблемный набор изменений определён верно.
После завершения проверки наберите команду
git checkout origin && git reset --hard HEAD
Это сбросит HEAD в исходное состояние.
Применение патча к дереву исходных кодов
Предположим, что разработчик разместил в теме патч, и хочет, чтобы вы его протестировали. На первый взгляд эта процедура может показаться чрезвычайно сложной, но на самом деле всё довольно просто. Загрузите патч (чаще всего он прикрепляется в той же теме в Bugzilla, но иногда его отправляют по e-mail) и скопируйте его в папку ~/wine-git. Затем выполните:
patch -p1 < название_патча.diff
Эта команда применит патч к дереву исходных кодов. Вывод должен выглядеть примерно так:
dlls/wined3d has been patched.
Когда процедура завершится, снова скомпилируйте Wine:
./configure && make
Протестируйте приложение. Как видите, это оказалось не так уж и сложно. Если вы собираетесь тестировать другие программы, то наличие патча в дереве исходных кодов уже не потребуется. Чтобы выполнить сброс состояния дерева исходных кодов (удалить все применённые патчи), выполните:
git reset --hard origin
Эта команда сбрасывает все внесённые вами наборы изменений (в том числе и патчи).
Обновление дерева исходных кодов Git
Теперь давайте предположим, что по прошествии некоторого времени было размещено сообщение об исправлении в последней версии Git ошибки, за статусом которой вы следите. Если вы хотите это проверить, необходимо обновить репозиторий Git и скомпилировать новую версию Wine. Чтобы выполнить обновление, введите:
git fetch ; git rebase origin
Как только процедура завершится, запустите компиляцию:
CC="ccache gcc" ./configure && make
И протестируйте приложение. Оно должно работать.
Устранение неполадок
Смотрите статью http://wiki.winehq.org/TroubleshootingBisectProblems
Если при компиляции или запуске ранней версии Wine у вас возникают неполадки, ознакомьтесь со статьёй http://wiki.winehq.org/ReverseRegressionTesting.
Отключение оптимизации для ускорения компиляции
Во время компиляции Wine очень много времени тратится на оптимизацию сгенерированного кода. Существует возможность существенно сократить время компиляции, отключив оптимизацию. Для этого при запуске скрипта configure укажите в командной строке значение CFLAGS="-g -O0". Выглядеть это будет следующим образом:
CC="ccache gcc" CFLAGS="-g -O0" ./configure --verbose && make
На компьютере с Intel e7200 с компилятором gcc-4.2.1 выполнение команды make -j3 обычно занимает 9 минут, а при отключённой оптимизации — 5 минут.
Отключение тестов для ускорения компиляции
Во время компиляции очень много времени тратится на компиляцию аттестационных тестов. Несмотря на то, что эти тесты имеют высокую ценность, для регрессионного тестирования они не нужны (нам уже известно о существовании определённой ошибки, поэтому аттестация не нужна).
Александр Жульяр внёс патч, позволяющий отключить компиляцию всего набора тестов во время регрессионного тестирования. В Wine 1.1.9 и более новых версиях для отключения компиляции тестов можно просто ввести команду
CC="ccache gcc" ./configure --disable-tests
Если стартовая версия Wine (не имеющая ошибки, со статусом "good") имеет номер меньший, чем 1.1.9, потребуется незначительная модификация исходного кода. Данный патч работает ориентировочно до версии 1.1.3:
diff --git a/dlls/Makefile.in b/dlls/Makefile.in
index d7b0976..2b4b779 100644
--- a/dlls/Makefile.in
+++ b/dlls/Makefile.in
@@ -332,7 +332,7 @@ SUBDIRS = \
winequartz.drv \
winex11.drv
-BUILDSUBDIRS = $(BASEDIRS) $(EXTRADIRS) $(TESTSUBDIRS)
+BUILDSUBDIRS = $(BASEDIRS) $(EXTRADIRS)
INSTALLSUBDIRS = $(BASEDIRS) $(EXTRADIRS) $(IMPLIBSUBDIRS)
DOCSUBDIRS = $(BASEDIRS) $(EXTRADIRS)
diff --git a/programs/Makefile.in b/programs/Makefile.in
index 3c128e1..72dbdb8 100644
--- a/programs/Makefile.in
+++ b/programs/Makefile.in
@@ -41,7 +41,6 @@ SUBDIRS = \
winemenubuilder \
winemine \
winepath \
- winetest \
winevdm \
winhelp \
winver \
--
1.4.4.2
Если номер версии находится в промежутке между 1.1.3 и 1.1.9, тогда вместо вышеуказанного используйте следующий патч:
diff --git a/dlls/Makefile.in b/dlls/Makefile.in
index 6680673..e998a38 100644
--- a/dlls/Makefile.in
+++ b/dlls/Makefile.in
@@ -9,9 +9,8 @@ INSTALLDIRS = $(DESTDIR)$(dlldir)
DLLSUBDIRS = @ALL_DLL_DIRS@
IMPLIBSUBDIRS = @ALL_IMPLIB_DIRS@
-TESTSUBDIRS = @ALL_TEST_DIRS@
-SUBDIRS = $(DLLSUBDIRS) $(IMPLIBSUBDIRS) $(TESTSUBDIRS)
-BUILDSUBDIRS = $(DLLSUBDIRS) $(TESTSUBDIRS)
+SUBDIRS = $(DLLSUBDIRS) $(IMPLIBSUBDIRS)
+BUILDSUBDIRS = $(DLLSUBDIRS)
INSTALLSUBDIRS = $(DLLSUBDIRS) $(IMPLIBSUBDIRS)
DOCSUBDIRS = $(DLLSUBDIRS)
@@ -445,8 +444,6 @@ CROSS_IMPLIBS = \
wsock32/libwsock32.a \
wtsapi32/libwtsapi32.a
-$(TESTSUBDIRS:%=%/__crosstest__): $(CROSS_IMPLIBS)
-
implib: $(IMPORT_LIBS)
.PHONY: implib
diff --git a/programs/Makefile.in b/programs/Makefile.in
index 7bd60b2..e5edef4 100644
--- a/programs/Makefile.in
+++ b/programs/Makefile.in
@@ -38,7 +38,3 @@ install install-lib:: install-progs$(DLLEXT) $(INSTALLDIRS)
uninstall::
-cd $(DESTDIR)$(bindir) && $(RM) wineapploader $(INSTALLPROGS)
-rmdir $(DESTDIR)$(dlldir)
-
-# Rules for testing
-
-check test:: $(SUBDIRS:%=%/__test__)
diff --git a/programs/winetest/Makefile.in b/programs/winetest/Makefile.in
index d153c04..3dd7bcd 100644
--- a/programs/winetest/Makefile.in
+++ b/programs/winetest/Makefile.in
@@ -21,10 +21,6 @@ SVG_SRCS = winetest.svg
@MAKE_PROG_RULES@
-ALL_TEST_DIRS = @ALL_TEST_DIRS@
-
-TESTBINS = $(ALL_TEST_DIRS:%/tests=%_test.exe)
-
@ALL_WINETEST_DEPENDS@
# Special rules
--
1.5.3.6
Тем не менее, при использовании этих патчей следует быть внимательными. Во время своей работы команда bisect не допускает модификацию дерева исходных кодов. Поэтому для того, чтобы команда bisect выполнилась надлежащим образом при пока ещё отключённых аттестационных тестах, запустите следующие команды (при этом предполагается, что патч находится в ~/wine-git/disable_test_new.diff и что регрессия появилась в промежутке между версиями 1.1.4 и 1.1.5):
- $ git bisect start
- $ git bisect bad wine-1.1.4
- $ git bisect good wine-1.1.5
- $ patch -p1 < disable_test_new.diff && CC="ccache gcc" ./configure && make && patch -p1 -R < disable_test_new.diff
Теперь протестируйте приложение, после чего укажите, присутствует ошибка или нет ("git bisect good" или "git bisect bad") для подготовки Git к следующему тесту. Затем повторите команды из 4й строки. Совершайте эти действия, пока не обнаружите набор изменений, вызвавший ошибку. Команды из 4й строки применяют патч, компилируют Wine и удаляют патч из дерева исходных кодов, таким образом, процедура bisect не обнаружит модификацию дерева исходных кодов.
Оформление отчёта об ошибке
Если у вас ещё нет учётной записи на bugs.winehq.org, зарегистрируйтесь. Войдите, использовав в качестве логина адрес электронной почты. Далее выберите создание нового отчёта (ссылка "New").
a460a2df43aa8eae10b1db028c6020829b009c54 is first bad commit commit a460a2df43aa8eae10b1db028c6020829b009c54 Author: Stefan Doesinger <stefandoesinger@gmx.at> Date: Sat Jun 9 14:27:41 2007 +0200 wined3d: Store the gl information in a per adapter structure and initialize it only once. :040000 040000 d8ae35832fcdbca8de07acae73b9e21564ced413 1720cc38fb598110071c9ee4f21f8f61b6f764c3 M dlls
Выберите на странице соответствующий компонент (здесь это wined3d), если он отсутствует в списке, тогда "-unknown".
- Version — выберите версию Wine, в которой вы впервые заметили ошибку.
- Severity — можно оставить normal.
- Hardware — аппаратная платформа, в большинстве случаев это "x86".
- OS — тип вашей операционной системы.
- CC (должна быть нажата ссылка "Show Advanced Fields") — e-mail автора набора изменений, в данном случае это stefandoesinger@gmx.at.
- URL — как правило, ссылка на страницу, с которой можно загрузить демо-версию (или полную версию, если она находится в свободном доступе) приложения или игры.
- Regression SHA1 — хеш-сумма набора изменений, в данном случае a460a2df43aa8eae10b1db028c6020829b009c54.
- Summary — название отчёта об ошибке, подробнее об этом поле ниже. Description — описание ошибки.
Заполнение полей Summary и Description
Поле Summary рекомендуется заполнять по следующему образцу: вначале идёт название приложения/игры, затем двоеточие и краткое описание проблемы. Например: Fallout 3: Configuration combobox empty (Fallout 3: Выпадающий список [в окне] конфигурации пуст). Ещё примеры:
- Fable: The game won't start (Fable: Игра не запускается)
- Commandos: The main menu is black (Commandos: Чёрный экран вместо главного меню)
- Call of Duty 4 MW: Graphical glitches when shooting (Call of Duty 4 MW: Искажения графики при стрельбе).
В поле Description подробно описываете (первый пункт обязателен, остальные желательны):
- Какие действия необходимо выполнить, что установить, чтобы воспроизвести ошибку.
- Какой у вас дистрибутив операционной системы и его версия
- Версия X сервера (в командной строке наберите: Xorg -version)
- В каком режиме вы запускали Wine — в полноэкранном режиме (fullscreen), или в режиме виртуального рабочего стола (virtual desktop mode)
- Какая у вас видеокарта (в командной строке наберите: lspci | grep VGA)
- Какой у вас драйвер видеокарты (в командной строке наберите: glxinfo | grep "OpenGL version string:")
Заполнение поля Attachment
Первое, что необходимо иметь в виду — размер вложения не должен превышать 1 Мб.
Обязательно нужно приложить журнал отладки Wine с каналами отладки tid, seh и relay. Делается это так:
- В командной строке перейдите в папку, в которой находится исполняемый файл, через который запускается приложение. Например, если приложение было установлено в папку "C:\Program Files\Program Name", то команда для перехода в эту папку будет выглядеть так:
cd ~/.wine/drive_c/Program\ Files/Program\ Name
- Запустите приложение в Wine, передав ему следующие параметры (замените program.exe на название исполняемого файла):
WINEDEBUG=+tid,+seh,+relay ~/wine-git/wine program.exe &> log.txt
- выполните сжатие полученного файла log.txt:
$ tar -cjvf log.tar.bz2 log.txt
Если размер полученного архива оказался больше 1 Мб, загрузите его на файловый хостинг без времени ожидания.
- Вложите файл, нажав кнопку Add an attachment и указав путь в поле File. Если вы загрузили архив на файловый хостинг, укажите ссылку в поле Description.
Если ваша ошибка видна визуально, желательно после создания отчёта приложить снимок экрана (скриншот), кликнув по ссылке Add an attachment на странице с отчётом. Для игр, запускаемых в виртуальном рабочем столе, на скриншоте показывается только сама область игры, декорации окна должны быть обрезаны.
