20451 2009-06-15 09:38:15 +0400 incompatible change in version script handling 2009-09-14 13:05:46 +0400 1 1 4 Development Sisyphus binutils unstable all Linux CLOSED FIXED P3 critical --- 20450 20496 21187 1 bikr glebfm Andrey.Chichak algor boris dk evg glebfm grizlik78 ktirf swi vsu vvk qa-sisyphus oldest_to_newest 93061 0 bikr 2009-06-15 09:38:15 +0400 > Судя по всему в C++ части бибилиотеки поменялся API, но ни в soname, ни > в vesrioning script это не отражено. (c) ns@ codeblocks-8.02-alt10 с библиотекой wxGTK-2.8.9-alt1 запускается нормально, при запуске же его с wxGTK-2.8.9-alt2 выдаётся следующая ошибка: codeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference 93070 1 algor 2009-06-15 11:55:06 +0400 это NOTABUG, собственно. пересоберите codeblocks. поскольку версия wxGTK не изменилась, SONAME и все прочие пироги не изменились тоже. 93072 2 ktirf 2009-06-15 12:19:44 +0400 API мог и не измениться, а вот ABI явно изменился. 93077 3 algor 2009-06-15 12:32:38 +0400 тогда вопрос в том, что вызвало смену ABI в данном случае. 93090 4 vsu 2009-06-15 14:44:13 +0400 Поздравляю, у нас сломан binutils. В wxGTK используется version-script.in следующего вида: @WX_VERSION_TAG@.2 { global: # wxFileHistory::Set/GetBaseId() *wxFileHistory*etBaseId*; *wxSafeConvert*; *wxSearchCtrl*SetDescriptiveText*; *wxSearchCtrl*GetDescriptiveText*; *wxSizerFlags*Bottom*; *wxSizerFlags*FixedMinSize*; *wxSizerFlags*Shaped*; *wxSizerFlags*Top*; *wxToolBar*SetToolNormalBitmap; *wxToolBar*SetToolDisabledBitmap; }; ... @WX_VERSION_TAG@ { global: *; }; Т.е., части символов присваиваются версии вида WXU_2.8.2 (но при этом эти символы указываются через glob, чтобы не писать C++ mangled name), а для всех остальных через global: * указывается версия WXU_2.8. Однако где-то между binutils-2.18.50.0.9-alt5 и 2.19.51.0.2-alt2 этот механизм сломался - теперь все символы получают версию WXU_2.8 (хотя в таблицу версий WXU_2.8.2 всё-таки попадает, поэтому provides у пакета не отвалились). Testcase: $ cat libtest.c int test(void) { return 1; } int test_new(void) { return 2; } $ cat libtest.version TEST_1.0.1 { *new*; }; TEST_1.0 { global: *; }; $ gcc -c -fPIC libtest.c $ ld -shared -o libtest.so -version-script libtest.version libtest.o Со старой версией binutils получается: $ objdump -T libtest.so |grep '\<test' 00000230 g DF .text 0000000a TEST_1.0 test 0000023a g DF .text 0000000a TEST_1.0.1 test_new С новой версией: $ LD_LIBRARY_PATH=./lib ./bin/ld -shared -o libtest.so -version-script libtest.version libtest.o vsu@center4 ~/tmp/11 $ objdump -T libtest.so |grep '\<test' 00000230 g DF .text 0000000a TEST_1.0 test 0000023a g DF .text 0000000a TEST_1.0 test_new 93092 5 vsu 2009-06-15 15:40:26 +0400 Похоже, это побочный эффект исправления http://sourceware.org/bugzilla/show_bug.cgi?id=7047 Теперь логика обработки glob pattern в version script изменилась - если имя символа соответствует нескольким шаблонам, раньше, похоже, брался первый из них, а теперь берётся последний (однако соответствия global более приоритетны, чем local, а точное соответствие имени (без glob) в любом случае имеет максимальный приоритет). В документации точное поведение ld в этом случае вновь обошли молчанием, добавив рекомендацию не использовать шаблоны в подобном случае: | When the linker finds a symbol defined in a library which is not | specifically bound to a version node, it will effectively bind it to an | unspecified base version of the library. You can bind all otherwise | unspecified symbols to a given version node by using @samp{global: *;} | somewhere in the version script. Note that it's slightly crazy to use | wildcards in a global spec except on the last version node. Global | wildcards elsewhere run the risk of accidentally adding symbols to the | set exported for an old version. That's wrong since older versions | ought to have a fixed set of symbols. 93173 6 ldv 2009-06-17 01:16:50 +0400 (In reply to comment #5) > Похоже, это побочный эффект исправления > http://sourceware.org/bugzilla/show_bug.cgi?id=7047 Да, это именно он и есть. > Теперь логика обработки glob pattern в version script изменилась - если имя > символа соответствует нескольким шаблонам, раньше, похоже, брался первый из > них, а теперь берётся последний (однако соответствия global более приоритетны, > чем local, а точное соответствие имени (без glob) в любом случае имеет > максимальный приоритет). В документации точное поведение ld в этом случае вновь > обошли молчанием, Alan Modra написал про это изменение следующее: I don't try to provide any ordering between two matching wildcards, except that a match in a global specification has higher precedence than a local spec. Otherwise, the last matching wildcard in the script wins. Оборот речи "I don't try to provide any ordering" говорит о том, что поведение зависит от реализации и может измениться, если кто-нибудь ещё что-нибудь там исправит. > добавив рекомендацию не использовать шаблоны в подобном > случае: > > | When the linker finds a symbol defined in a library which is not > | specifically bound to a version node, it will effectively bind it to an > | unspecified base version of the library. You can bind all otherwise > | unspecified symbols to a given version node by using @samp{global: *;} > | somewhere in the version script. Note that it's slightly crazy to use > | wildcards in a global spec except on the last version node. Global > | wildcards elsewhere run the risk of accidentally adding symbols to the > | set exported for an old version. That's wrong since older versions > | ought to have a fixed set of symbols. Ну что, будем жаловаться "наверх" на incompatible change, или будем фиксить скрипты? 93187 7 vsu 2009-06-17 12:40:30 +0400 (В ответ на комментарий №6) > Ну что, будем жаловаться "наверх" на incompatible change, или будем фиксить > скрипты? И как в данном случае это фиксить, чтобы результат работал и со старыми, и с новыми версиями binutils, и при этом не приходилось прибивать в скрипте все имена гвоздями (что в данном случае проблемно из-за C++ - насколько надёжно работает extern "C++" в version script с учётом возможности использования разных версий gcc?)? 96600 8 algor 2009-08-17 09:16:30 +0400 отцы, так есть уже официально рекомендованный способ решения данной проблемы ? wxGTK и то, что от него зависит висит в разваленном состоянии. 96602 9 ldv 2009-08-17 10:32:03 +0400 (In reply to comment #7) > (В ответ на комментарий №6) > > Ну что, будем жаловаться "наверх" на incompatible change, или будем фиксить > > скрипты? > > И как в данном случае это фиксить, чтобы результат работал и со старыми, и с > новыми версиями binutils, и при этом не приходилось прибивать в скрипте все > имена гвоздями (что в данном случае проблемно из-за C++ - насколько надёжно > работает extern "C++" в version script с учётом возможности использования > разных версий gcc?)? Похоже что такой результат недостижим. Либо со старыми версиями binutils, либо с новыми, либо поддерживать две версии скрипта и проверять binutils во время сборки. 96614 10 3743 vsu 2009-08-17 12:50:07 +0400 Created attachment 3743 ld_shared_wrapper.pl Раз в binutils ничего не делается, видимо, придётся делать объезд со стороны wxGTK - например, подстановкой при сборке библиотек вместо g++ приложенного скрипта, который делает следующее: 1) Собирает библиотеку обычным образом во временный файл. 2) Извлекает из полученного временного файла список глобальных символов. 3) Используя этот список, заменяет шаблоны в version script на точный список символов, которые им соответствуют (остаётся в виде шаблона только "*", а также те шаблоны, для которых не найдено соответствий - иначе для некоторых версий могут получиться пустые секции, что ld считает ошибкой). 4) Собирает окончательный вариант библиотеки, используя модифицированный version script (кладётся в файл *.versions рядом с собранной библиотекой для проверки результатов работы). 96615 11 3744 vsu 2009-08-17 12:51:23 +0400 Created attachment 3744 wxGTK-2.8.9-alt3.src.rpm.diff Изменения в wxGTK.spec для использования приложенного скрипта. 97163 12 repository-robot 2009-08-24 12:44:35 +0400 wxGTK-2:2.8.10-alt2 -> sisyphus: * Mon Aug 24 2009 Boris Savelev <boris@altlinux> 2:2.8.10-alt2 - Add workaround for new version script handling in binutils: expand symbol patterns in version scripts manually instead of relying on unstable binutins behavior (Sergey Vlasov) (closes #20451). 97164 13 dk 2009-08-24 12:49:34 +0400 А можно получить пояснения, нуждается ли теперь в пересборке софт, слинкованный с wxGTK, который а) перестал работать в результате этого бага? б) перестал работать, но был пересобран с новой wxGTK, с тех пор работает? 97172 14 algor 2009-08-24 13:33:37 +0400 (In reply to comment #13) > А можно получить пояснения, нуждается ли теперь в пересборке софт, слинкованный > с wxGTK, который нуждается. весь. 97174 15 vsu 2009-08-24 13:39:12 +0400 (В ответ на комментарий №12) > unstable binutins behavior (Sergey Vlasov) (closes #20451). Эх, опечатка пролезла :( (В ответ на комментарий №13) > А можно получить пояснения, нуждается ли теперь в пересборке софт, > слинкованный с wxGTK, который > > а) перестал работать в результате этого бага? Не нуждается - теперь версии символов вернулись в первоначальное состояние. Я сравнивал символы wxGTK-2.8.9-alt1 и сборки со своим патчем - GLOBAL совпадают полностью, WEAK совпадают по версиям, но набор их поменялся (однако копии этих функций в любом случае будут и в бинарниках, реально их использующих, так что проблем из-за этого быть не должно). > б) перестал работать, но был пересобран с новой wxGTK, с тех пор работает? Вот это придётся опять пересобирать. 97175 16 dk 2009-08-24 13:41:15 +0400 Гм. Значит я все прошедшие выходные копаюсь с переводом codeblocks, поскольку в понедельник предполагают сделать RC школьного дистрибутива, а тут в Сизиф въезжает бомба, ломающая весь wxGTK-софт, да? Тогда либо нужно собирать RC сейчас, пока wxGTK не доехало до Сизифа, либо пересобирать сразу же все пакеты... В общем, прошу обратить внимание на проблему пересборки в свете предполагаемого выхода RC. 97222 17 ldv 2009-08-24 22:19:10 +0400 (In reply to comment #16) > Гм. Значит я все прошедшие выходные копаюсь с переводом codeblocks, поскольку в > понедельник предполагают сделать RC школьного дистрибутива, а тут в Сизиф > въезжает бомба, ломающая весь wxGTK-софт, да? Не ломающая, а исправляющая. Сломано было немного раньше. > Тогда либо нужно собирать RC сейчас, пока wxGTK не доехало до Сизифа, либо > пересобирать сразу же все пакеты... RC лучше выпускать после изменения ABI, иначе релиз будет бинарно несовместим с RC по этим пакетам. > В общем, прошу обратить внимание на проблему пересборки в свете предполагаемого > выхода RC. Давайте составим список пакетов, которые нужно пересобрать как можно быстрее. 97223 18 dk 2009-08-24 22:26:40 +0400 > Не ломающая, а исправляющая. Сломано было немного раньше. Не суть - главное, что тот софт, который успели за последние 2,5 месяца пересобрать со сломанной wxGTK больше не работает. > Давайте составим список пакетов, которые нужно пересобрать как можно быстрее. codeblocks poedit Это из числа того, что отражено в зависимостях от этого бага. 97224 19 ldv 2009-08-24 22:31:08 +0400 (In reply to comment #18) > > Не ломающая, а исправляющая. Сломано было немного раньше. > > Не суть - главное, что тот софт, который успели за последние 2,5 месяца > пересобрать со сломанной wxGTK больше не работает. Поскольку 2.5+ месяца назад софт тоже существовал, разнца всё же есть. > > Давайте составим список пакетов, которые нужно пересобрать как можно быстрее. > > codeblocks > poedit > > Это из числа того, что отражено в зависимостях от этого бага. Можно попросить мантейнеров этих пакетов просто отправить пакеты на сборку? 97225 20 dk 2009-08-24 22:39:08 +0400 codeblocks я могу отправить на пересборку прямо сейчас, наверное, надо выставить requires на wxGTK >= 2.8.10-alt2 Нужно ли дожидаться, пока wxGTK доедет до сизифа, или можно отправить пакет прямо сейчас вот с таким вот requires? 97226 21 ldv 2009-08-24 22:43:48 +0400 (In reply to comment #20) > codeblocks я могу отправить на пересборку прямо сейчас, наверное, надо > выставить requires на wxGTK >= 2.8.10-alt2 Да, пожалуй. > Нужно ли дожидаться, пока wxGTK доедет до сизифа, или можно отправить пакет > прямо сейчас вот с таким вот requires? Уже доехал: http://git.altlinux.org/tasks/11283/task/log 97227 22 dk 2009-08-24 22:53:10 +0400 > Да, пожалуй. codeblocks-8.02-alt17 ушел в incoming > Уже доехал: > http://git.altlinux.org/tasks/11283/task/log Это до вас может быть доехал, а до меня, т.е. до публичных серверов - еще не доехал. Вот я сейчас src.rpm собирал с ключом --nodeps, у меня то нового wxGTK пока нет. 97241 23 boris 2009-08-25 09:23:24 +0400 вот эта проблема http://lists.altlinux.org/pipermail/devel/2009-July/173326.html возможно тоже из-за binutils? 97299 24 ldv 2009-08-25 18:02:11 +0400 (In reply to comment #17) > Давайте составим список пакетов, которые нужно пересобрать как можно быстрее. Вот список всех пострадавших пакетов: Aug 22 14:27 poedit-1.4.2-alt3.src.rpm Aug 18 03:26 dvdstyler-1.7.3-alt2.src.rpm Aug 11 23:48 wxMaxima-0.8.3-alt1.src.rpm Jul 29 07:46 hugin-0.8.0-alt2.1.src.rpm Jul 22 01:31 bacula-3.0.2-alt1.src.rpm Jul 5 16:31 python-module-wx-2.8.9-alt1.src.rpm Jul 1 21:31 scalasca-1.1-alt5.src.rpm Jun 25 06:47 scummvm-tools-0.13.0-alt2.src.rpm Jun 18 16:58 xchm-1.17-alt1.src.rpm May 25 11:22 flamerobin-0.9.0-alt2.src.rpm May 18 01:35 aMule-2.2.5-alt1.src.rpm May 13 18:11 tintii-2.1.0-alt1.src.rpm 97352 25 Andrey.Chichak 2009-08-26 15:42:04 +0400 (В ответ на комментарий №24) > (In reply to comment #17) > > Давайте составим список пакетов, которые нужно пересобрать как можно быстрее. > > Вот список всех пострадавших пакетов: я бы добавил pgadmin3 97355 26 algor 2009-08-26 16:17:02 +0400 > я бы добавил pgadmin3 Его уже нет в репозитории, по причине несобираемости. Правда, вроде как есть люди, желающие реанимировать. 3743 2009-08-17 12:50:07 +0400 2009-08-17 12:50:07 +0400 ld_shared_wrapper.pl ld_shared_wrapper.pl text/plain 2966 vsu IyEvdXNyL2Jpbi9wZXJsCiMKIyAkKExEX1NIQVJFRF9DWFgpIHdyYXBwZXIgZm9yIHd4R1RLIHRv IGhhbmRsZSBzeW1ib2wgdmVyc2lvbmluZwojCgp1c2UgRmlsZTo6VGVtcDsKdXNlIHN0cmljdDsK dXNlIHdhcm5pbmdzOwoKc2NhbGFyKEBBUkdWKSA+IDAgb3IgZGllICJubyBhcmd1bWVudHMiOwoK bXkgQGxkX2FyZ3NfMTsKbXkgQGxkX2FyZ3NfMiA9IEBBUkdWOwp3aGlsZSAoc2NhbGFyKEBsZF9h cmdzXzIpIGFuZCAkbGRfYXJnc18yWzBdIG5lICctbycpIHsKCXB1c2ggQGxkX2FyZ3NfMSwgc2hp ZnQoQGxkX2FyZ3NfMik7Cn0Kc2NhbGFyKEBsZF9hcmdzXzIpID49IDIgb3IgZGllICJtaXNzaW5n ICctbyA8ZmlsZT4nIG9wdGlvbiI7CnB1c2ggQGxkX2FyZ3NfMSwgc2hpZnQoQGxkX2FyZ3NfMik7 CSMgJy1vJwpteSAkb3JpZ19vdXRwdXRfZmlsZSA9IHNoaWZ0KEBsZF9hcmdzXzIpOwoKbXkgJHRt cGRpciA9IEZpbGU6OlRlbXAtPm5ld2RpcigpOwoKbXkgJG9yaWdfdmVyc2lvbl9zY3JpcHQ7Cm15 ICR0bXBfdmVyc2lvbl9zY3JpcHQgPSAiJG9yaWdfb3V0cHV0X2ZpbGUudmVyc2lvbnMiOwpteSBA ZmluYWxfbGRfYXJnc18yID0gQGxkX2FyZ3NfMjsKZm9yIChAZmluYWxfbGRfYXJnc18yKSB7Cgkv Xi1XbCwtLXZlcnNpb24tc2NyaXB0LCguKikkLyAmJiBkbyB7CgkJJG9yaWdfdmVyc2lvbl9zY3Jp cHQgPSAkMTsKCQkkXyA9ICItV2wsLS12ZXJzaW9uLXNjcmlwdCwkdG1wX3ZlcnNpb25fc2NyaXB0 IjsKCQlsYXN0OwoJfQp9CgppZiAobm90IGRlZmluZWQgJG9yaWdfdmVyc2lvbl9zY3JpcHQpIHsK CWV4aXQodmVyYm9zZV9zeXN0ZW0oQGxkX2FyZ3NfMSwgJG9yaWdfb3V0cHV0X2ZpbGUsIEBsZF9h cmdzXzIpKTsKfQoKIyBGaXJzdCBsaW5rIGF0dGVtcHQsIHdyaXRpbmcgdG8gYSB0ZW1wb3Jhcnkg ZmlsZQpteSAkdG1wX2xpYiA9ICIkdG1wZGlyL3RtcC5zbyI7Cm15ICRyYyA9IHZlcmJvc2Vfc3lz dGVtKEBsZF9hcmdzXzEsICR0bXBfbGliLCBAbGRfYXJnc18yKTsKZXhpdCgkcmMpIGlmICRyYyAh PSAwOwoKIyBSZWFkIGdsb2JhbCBzeW1ib2xzIGZyb20gdGhlIGxpbmsgcmVzdWx0Cm15ICVzeW1i b2xzOwpvcGVuKG15ICRubV9vdXRwdXQsICctfCcsICdubScsICctRCcsICctLWRlZmluZWQtb25s eScsICR0bXBfbGliKQoJb3IgZGllICJnZXQgbm0gb3V0cHV0OiAkISI7CndoaWxlICg8JG5tX291 dHB1dD4pIHsKCWNob21wOwoJL15bWzp4ZGlnaXQ6XV0qXHMrW1s6dXBwZXI6XV1ccysoXFMrKSQv ICYmIGRvIHsKCQkkc3ltYm9sc3skMX0gPSAxOwoJfQp9CmNsb3NlKCRubV9vdXRwdXQpCglvciBk aWUgJCEgPyAiZXJyb3IgY2xvc2luZyBubSBvdXRwdXQ6ICQhIgoJCTogIm5tOiBleGl0ZWQgd2l0 aCBzdGF0dXMgJD8iOwoKIyBVc2luZyBnbG9iYWwgc3ltYm9sIGxpc3QsIGV4cGFuZCBzeW1ib2wg cGF0dGVybnMgaW4gdmVyc2lvbiBzY3JpcHQKb3BlbihteSAkdnNfaW4sICc8JywgJG9yaWdfdmVy c2lvbl9zY3JpcHQpCglvciBkaWUgIm9wZW4gJyRvcmlnX3ZlcnNpb25fc2NyaXB0JzogJCEiOwpv cGVuKG15ICR2c19vdXQsICc+JywgJHRtcF92ZXJzaW9uX3NjcmlwdCkKCW9yIGRpZSAib3BlbiAn JHRtcF92ZXJzaW9uX3NjcmlwdCc6ICQhIjsKd2hpbGUgKDwkdnNfaW4+KSB7CgljaG9tcDsKCS9e XHMqKFteWzpzcGFjZTpdI3t9O10rKTtccyokLyAmJiBkbyB7CgkJZXhwYW5kX3N5bWJvbCgkdnNf b3V0LCAkXywgJDEpOwoJCW5leHQ7Cgl9OwoJcHJpbnQgJHZzX291dCAiJF9cbiI7Cn0KY2xvc2Uo JHZzX291dCkgb3IgZGllICJlcnJvciBjbG9zaW5nICckdG1wX3ZlcnNpb25fc2NyaXB0JzogJCEi OwpjbG9zZSgkdnNfaW4pIG9yIGRpZSAiZXJyb3IgY2xvc2luZyAnJG9yaWdfdmVyc2lvbl9zY3Jp cHQnOiAkISI7CgojIEZpbmFsIGxpbmssIHVzaW5nIHRoZSBtb2RpZmllZCB2ZXJzaW9uIHNjcmlw dApleGl0KHZlcmJvc2Vfc3lzdGVtKEBsZF9hcmdzXzEsICRvcmlnX291dHB1dF9maWxlLCBAZmlu YWxfbGRfYXJnc18yKSk7CgoKCnN1YiBleHBhbmRfc3ltYm9sCnsKCW15ICgkdnNfb3V0LCAkbGlu ZSwgJGdsb2IpID0gQF87CgoJIyBLZWVwICcqJyBhcyBpcwoJaWYgKCRnbG9iIGVxICcqJykgewoJ CXByaW50ICR2c19vdXQgIiRsaW5lXG4iOwoJCXJldHVybjsKCX0KCgkjIENvbnZlcnQgc2hlbGwg cGF0dGVybiB0byByZWdleHAgKGN1cnJlbnRseSBvbmx5ICcqJyBpcyBoYW5kbGVkKS4KCWlmICgk Z2xvYiA9fiAvW15bOmFsbnVtOl1fKl0vKSB7CgkJZGllICJ1bmFibGUgdG8gaGFuZGxlIHN5bWJv bCBwYXR0ZXJuICckZ2xvYiciOwoJfQoJbXkgJHJlID0gJGdsb2I7CgkkcmUgPX4gcy9cKi8uKi9n OwoJaWYgKCRyZSBlcSAkZ2xvYikgewoJCSMgZXhhY3QgbWF0Y2ggLSBrZWVwIGFzIGlzCgkJcHJp bnQgJHZzX291dCAiJGxpbmVcbiI7CgkJcmV0dXJuOwoJfQoJJHJlID0gcXIvXiRyZSQvOwoKCW15 ICRmaXJzdCA9IDE7Cglmb3IgbXkgJHN5bSAoZ3JlcCB7IG0vJHJlLyB9IGtleXMgJXN5bWJvbHMp IHsKCQlpZiAoJGZpcnN0KSB7CgkJCSRmaXJzdCA9IDA7CgkJCXByaW50ICR2c19vdXQgIiMjJGxp bmVcbiI7CgkJfQoJCXByaW50ICR2c19vdXQgIlx0JHN5bTtcbiI7CgkJZGVsZXRlICRzeW1ib2xz eyRzeW19OwoJfQoJaWYgKCRmaXJzdCkgewoJCSMgS2VlcCB1bm1hdGNoZWQgcGF0dGVybnMgdG8g YXZvaWQgZW1wdHkgc2VjdGlvbnMKCQlwcmludCAkdnNfb3V0ICIkbGluZVxuIjsKCX0gZWxzZSB7 CgkJcHJpbnQgJHZzX291dCAiXG4iOwoJfQp9CgpzdWIgdmVyYm9zZV9zeXN0ZW0KewoJcHJpbnQg IisgIiAuIGpvaW4oJyAnLCBAXykgLiAiXG4iOwoJbXkgJHJjID0gc3lzdGVtIHsgJF9bMF0gfSBA XzsKCWlmICgkcmMgPT0gLTEpIHsKCQlkaWUgInN5c3RlbTogJCEiOwoJfQoJZWxzaWYgKCRyYyAm IDEyNykgewoJCXJldHVybiAoJHJjICYgMTI3KSB8IDEyODsKCX0KCXJldHVybiAkcmMgPj4gODsK fQo= 3744 2009-08-17 12:51:23 +0400 2009-08-17 12:51:23 +0400 wxGTK-2.8.9-alt3.src.rpm.diff wxGTK-2.8.9-alt3.src.rpm.diff text/plain 1287 vsu LS0tIHd4R1RLLTIuOC45LWFsdDIvd3hHVEsuc3BlYwkyMDA5LTA2LTExIDA3OjQzOjA3ICswMDAw CisrKyB3eEdUSy0yLjguOS1hbHQzL3d4R1RLLnNwZWMJMjAwOS0wOC0xNyAwODowMzozNyArMDAw MApAQCAtOCw3ICs4LDcgQEAKIAogTmFtZTogd3hHVEsKIFZlcnNpb246ICV3eGJyYW5jaC45Ci1S ZWxlYXNlOiBhbHQyCitSZWxlYXNlOiBhbHQzCiBTZXJpYWw6CTIKIAogU3VtbWFyeTogVGhlIEdU SysgcG9ydCBvZiB0aGUgd3hXaWRnZXRzIGxpYnJhcnkKQEAgLTE3LDYgKzE3LDcgQEAgR3JvdXA6 IFN5c3RlbS9MaWJyYXJpZXMKIFVybDogaHR0cDovL3d4d2lkZ2V0cy5vcmcKIAogU291cmNlOiAl bmFtZS0ldmVyc2lvbi50YXIuZ3oKK1NvdXJjZTI6IGxkX3NoYXJlZF93cmFwcGVyLnBsCiBQYXRj aDoJY2hhbmdlc2V0X3I2MDg3NS5kaWZmCiBQYXRjaDE6CWNoYW5nZXNldF9yNjA4NzYuZGlmZgog I1NvdXJjZTogJW5hbWUtMjAwNy0wMS0zMS50YXIuYnoyCkBAIC0xMjUsOSArMTI2LDkgQEAgSGVh ZGVyIGZpbGVzIGZvciB3eFdpZGdldHMgb2JqZWN0IGdyYXBoaQogCSAgIC0td2l0aC1zZGwgXAog CSAgIC0td2l0aC1yZWdleD1zeXMKIAotJW1ha2VfYnVpbGQKKyVtYWtlX2J1aWxkIFNIQVJFRF9M RF9DWFg9J3BlcmwgJVNPVVJDRTIgJChDWFgpIC1zaGFyZWQgLWZQSUMgLW8nCiBjZCBjb250cmli L3NyYwotJW1ha2VfYnVpbGQKKyVtYWtlX2J1aWxkIFNIQVJFRF9MRF9DWFg9J3BlcmwgJVNPVVJD RTIgJChDWFgpIC1zaGFyZWQgLWZQSUMgLW8nCiAKICVpbnN0YWxsCiAlbWFrZWluc3RhbGwKQEAg LTI0Myw2ICsyNDQsMTEgQEAgY2QgY29udHJpYi9zcmMKICVfZGF0YWRpci93eC9leGFtcGxlcwog CiAlY2hhbmdlbG9nCisqIE1vbiBBdWcgMTcgMjAwOSBTZXJnZXkgVmxhc292IDx2c3VAYWx0bGlu dXgucnU+IDI6Mi44LjktYWx0MworLSBBZGQgd29ya2Fyb3VuZCBmb3IgbmV3IHZlcnNpb24gc2Ny aXB0IGhhbmRsaW5nIGluIGJpbnV0aWxzICgjMjA0NTEpOgorICBleHBhbmQgc3ltYm9sIHBhdHRl cm5zIGluIHZlcnNpb24gc2NyaXB0cyBtYW51YWxseSBpbnN0ZWFkIG9mIHJlbHlpbmcgb24KKyAg dW5zdGFibGUgYmludXRpbnMgYmVoYXZpb3IuCisKICogVGh1IEp1biAxMSAyMDA5IEFsZXggR29y YmFjaGVua28gKGFnZW50XzAwNykgPGFsZ29yQGFsdGxpbnV4LnJ1PiAyOjIuOC45LWFsdDIKIC0g IGZpeCAjMjAzMjguCiAKRW5kIG9mIGRpZmYKCkZpbGVzIG5vdCBjb21wYXJlZCBpbiB3eEdUSy0y LjguOS1hbHQzOgpsZF9zaGFyZWRfd3JhcHBlci5wbAoK