Created attachment 3300 [details] Разница в отбражении В версии 2.1.4 наблюдается регрес в отображении системных шрифтов по сравнению с 2.0.4. Результат скриншотом во вложении Воспроизводилось на ALTLinux/p7
Решил исследовать с помощью git-bisect, а заодно и изучить этот инструмент. Но выяснил что после git checkout и git bisect возникают ошибки вида: parser.y: In function ‘rsrcid_to_token’: parser.y:2841:15: error: ‘YYLEX’ undeclared (first use in this function) Решине проблемы нашлось здесь https://forum.winehq.org/viewtopic.php?f=8&t=19959#p88521 Это скрипт который нужно запускать после выполнения checkout или bisect. Пока в раздумиях каким образом лучше отловить возникнвение проблемы
Хотел сравнить ветки wine-pure, public, eterhack Разбирался нюансах ветвления наших репозиториев wine. Основная страница http://winehq.org.ru/Repos Примечания : 1)репозитории по адресу git.eter:/projects/wine/wine-pure.git и /srv/wine/Projects/wine-origin не синхронизированы 2)Последняя собранная версия public 1.7.53, а в репозитории git.eter:/projects/wine/wine.git 1.7.47. Как так и что делать я не понял В репозитории public есть ветка pure, но она старая - wine 1.3.*. Значит изменения тянуться прямо из репозитория wine-pure На основе каких веток базируется eterhack я не понял. Есть подозрения что это wine-pure. Но какие тогда отличия от eterwine по открытой части?
C помощью скрипта ww полусилось найти " хороший коммит " на которм не воспроизводиться проблема, он помечен тегом 2.1.0-alt3. Итого имеем : Хорошие шрифты - 2.1.0-alt3 Плохие шрифты - 2.1.4-alt2 Вот тут уже можно попробовать git biset
Диапазон сократился до good - 2.1.3-alt1 bad - 2.1.4-al2
Результат исследования: $ git bisect good 8c154be5487a10e7d69d825325cdf3dcd5a01f14 is the first bad commit commit 8c154be5487a10e7d69d825325cdf3dcd5a01f14 Author: Vitaly Lipatov <lav@etersoft.ru> Date: Sat Apr 4 00:55:40 2015 +0300 port freetype detection from newest wine :100644 100644 ed27013ad78b4f6fb936f07c555b5f2d4258a27a 90c35e0e213b2f4c172c638199f456022a9503f4 M aclocal.m4 :100755 100755 b6d264f6fca54c8b0e578ad93f7df6b3523ff6a1 78786dde739394c2ceb5e6547280d206183f585e M configure :100644 100644 0f6f207b3ce5cd1f1464b8a43a5609ae6c74ae19 72c7d36ab5d460e9d1a1e38a692e6071d22bb155 M configure.ac :040000 040000 1d252d1bb2ac464a43c4e318b5f7c31c217ac183 c38c9a29c79df58b1f7086821da32db80aada6a4 M dlls Последний рабочий коммит помечен тэгом 2.1.3-alt13
eterhack/eter-2.1 коммиты : Good: fa0639e721aff4001211e00c54f1c1c384809272 new build 2.1.3-alt13 (with rpmlog script) Bad: 8c154be5487a10e7d69d825325cdf3dcd5a01f14 port freetype detection from newest wine
Дмитрий, вы не могли бы посмотреть на этот коммит, может быть что-то там очевидно?
Костя, на мой взгляд, бага была в 2.0.4, где шрифты сглаживались, когда не надо. Сейчас она исправлена, и шрифт не сглаживается. А то, что он такой некрасивый при этом, это уже другой вопрос.
(Ответ Konstantin Artyushkin на комментарий5) > Результат исследования: > > $ git bisect good > > 8c154be5487a10e7d69d825325cdf3dcd5a01f14 is the first bad commit > commit 8c154be5487a10e7d69d825325cdf3dcd5a01f14 > Author: Vitaly Lipatov <lav@etersoft.ru> > Date: Sat Apr 4 00:55:40 2015 +0300 > > port freetype detection from newest wine По результатам теста на регрессию, проведенного Константином, проделал следующие шаги для проверки правильности теста: 1. git reset --hard 8c154be5487a10e7d69d825325cdf3dcd5a01f14 После компиляции сделал скриншот и сгенерировал +font лог. 2. git show 8c154be5487a10e7d69d825325cdf3dcd5a01f14 | patch -p1 -R После компиляции сделал скриншот и сгенерировал +font лог. На моем компьютере скриншоты и логи, созданные на шагах #1 и #2 - полностью идентичные. (Ответ Vitaly Lipatov на комментарий7) > Дмитрий, вы не могли бы посмотреть на этот коммит, может быть что-то там > очевидно? На первый взгляд в коммите 8c154be5487a10e7d69d825325cdf3dcd5a01f14 не видно чего-то такого, что могло бы сломать отображение шрифтов, ведь он "просто" меняет макросы для определения присутствующих при компиляции заголовков freetype. Однако, с другой стороны, при более внимательнос анализе файла freetype.c целиком (а не только крошечного фрагмента из коммита) я обнаружил, что этот коммит не полностью заменяет все макросы HAVE_xxxx, используемые для детектирования функциональности freetype, например HAVE_FREETYPE_FTLCDFIL_H продолжает использоваться при условной компиляции LCD фильтрации, в то время как по идее должен использоваться новый макрос FT_LCD_FILTER_H. Я отправил патч, заменяющий старый макрос на новый для включения в ветку eter-2.1, исправляет ли он ситуацию с отображением шрифтов?
Ура товарищи, Бинго! wine-etersoft-sql-2.1.4-alt2 wine-etersoft-2.1.4-alt4 Шрифты выглядят гораздо лучше, см. скриншот. Почему задание как решённое
Created attachment 3306 [details] Исправленный вариант
Закрываю.