https://www.altlinux.org/api.php?action=feedcontributions&user=Ender&feedformat=atomALT Linux Wiki - Вклад [ru]2024-03-28T21:26:48ZВкладMediaWiki 1.38.2https://www.altlinux.org/index.php?title=Xdg&diff=17927Xdg2011-02-16T05:51:23Z<p>Ender: </p>
<hr />
<div>{{Улучшение}}<br />
=Следование стандартам FreeDesktop=<br />
В данном документе будут описаны рамки, в которых сообщество разработчиков ALTLinux следует стандартам [http://www.freedesktop.org/wiki/ freedesktop.org].<br />
<br />
==xdg-user-dirs==<br />
Стандарт [http://www.freedesktop.org/wiki/Software/xdg-user-dirs xdg-user-dirs] определяет каталоги, которые создаются по-умолчанию у пользователя. Каталоги создаются на национальном языке.<br />
<br />
radik@ реализовал следующее расположение каталогов для пользователя:<br />
<br />
В домашнем каталоге остаются следующие каталоги:<br />
DESKTOP=Desktop <br />
DOCUMENTS=Documents <br />
DOWNLOAD=Downloads <br />
PUBLICSHARE=Public <br />
<br />
Убраны в подкаталог:<br />
TEMPLATES=Documents/Templates<br />
MUSIC=Documents/Music<br />
PICTURES=Documents/Pictures<br />
VIDEOS=Documents/Videos<br />
PHOTOS=Documents/Photos<br />
MOVIES=Documents/Movies<br />
<br />
Для тех, кому данные новвоведения неудобны, был создан [[Control|control]].<br />
По умолчанию он '''выключен'''.<br />
Для того, чтобы его включить, достаточно ввести команду от root:<br />
control xdg-user-dirs enabled<br />
<br />
Обсуждение ведется [http://lists.altlinux.org/pipermail/devel/2011-February/188360.html здесь].<br />
<br />
[[Категория:ALT Linux Desktop]]<br />
[[Категория:Sisyphus]]</div>Enderhttps://www.altlinux.org/index.php?title=Xdg&diff=17919Xdg2011-02-15T14:39:24Z<p>Ender: </p>
<hr />
<div>{{Улучшение}}<br />
=Следование стандартам FreeDesktop=<br />
В данном документе будут описаны рамки, в которых сообщество разработчиков ALTLinux следует стандартам [http://www.freedesktop.org/wiki/ freedesktop.org].<br />
<br />
==xdg-user-dirs==<br />
Стандарт [http://www.freedesktop.org/wiki/Software/xdg-user-dirs xdg-user-dirs] определяет каталоги, которые создаются по-умолчанию у пользователя. Каталоги создаются на национальном языке.<br />
<br />
radik@ реализовал следующее расположение каталогов для пользователя:<br />
<br />
В домашнем каталоге остаются следующие каталоги:<br />
DESKTOP=Desktop <br />
DOCUMENTS=Documents <br />
DOWNLOAD=Downloads <br />
PUBLICSHARE=Public <br />
<br />
Убраны в подкаталог:<br />
TEMPLATES=Documents/Templates<br />
MUSIC=Documents/Music<br />
PICTURES=Documents/Pictures<br />
VIDEOS=Documents/Videos<br />
PHOTOS=Documents/Photos<br />
MOVIES=Documents/Movies<br />
<br />
Для тех, кому данные новвоведения неудобны, был создан [[Control|control]].<br />
По умолчанию он '''выключен'''.<br />
Для того, чтобы его включить, достаточно ввести команду от root:<br />
control user-dirs enabled<br />
<br />
Обсуждение ведется [http://lists.altlinux.org/pipermail/devel/2011-February/188360.html здесь].<br />
<br />
[[Категория:ALT Linux Desktop]]<br />
[[Категория:Sisyphus]]</div>Enderhttps://www.altlinux.org/index.php?title=Girar/Internals&diff=11209Girar/Internals2009-05-18T08:30:06Z<p>Ender: </p>
<hr />
<div>{{stub}}<br />
Есть два главных компонента системы: <tt>girar</tt> и <tt>girar-builder</tt>.<br />
<br />
=== Girar ===<br />
;girar:это то что обслуживает ssh доступ к git.altlinux.org.<br />
Обрабатывает команды, описанные в [[Git.alt/Справочник]] и формирует [[Git.alt/Справочник#Сборка пакетов|задания]] для сборки.<br />
<br />
=== Girar Builder ===<br />
;girar-builder:забирает [[Git.alt/Справочник#Сборка пакетов|задания]] на сборку.<br />
<br />
;Задание:это каталог со специальной структурой (ближайшая аналогия -- каталог /proc/$pid).<br>Структура каталога описана в файле girar-builder/TASK. Описание может быть неполным или неточным, но оно дает правильное первоначальное представление.<br />
<br />
Команды на формирование задания описаны в [[Git.alt/Справочник#Сборка пакетов|задания]] (команда <tt>task</tt>).<br />
<br />
[[Git.alt/Справочник#Сборка пакетов|Задание]] состоит из нескольких стадий, которые выполняются в режиме<br />
<tt>sh -e</tt> (то есть, когда одна из стадий завершается с ошибкой, остальные<br />
стадии не выполняются). Последние стадии задания -- это копирование<br />
собранных пакетов в репозитарий и перегенерация репозитария.<br />
<br />
Процедура сборки задания находится в <tt>girar-builder/gb-run-task</tt>.<br />
<br />
==== Процедура сборки задания ====<br />
Сейчас усилиями ldv реализована архитектура <tt>girar-builder</tt> + <tt>nodes</tt>.<br />
<tt>girar-builder</tt> находится на одной машине и выполняет всякие<br />
централизованные действия.<br />
<br />
В каталоге <tt>girar-builder/remote/</tt> лежат программы, которые выполняются на ''remote nodes''. В частности, для сборки<br />
пакетов на ноде выполняется программа <tt>girar-builder/remote/gb-remote-build</tt>.<br />
<br />
Характерной особенностью <tt>girar-builder</tt> является то, что у него нету своего [[Hasher|хешера]].<br />
[[Hasher|Хешер]] находятся на ''remote nodes''. Когда нужно что-то от хешера, например сборка или проверка<br />
установки, то <tt>girar-builder</tt> стучится на ''remote nodes'' и там всё делает.<br />
<br />
Зато <tt>girar-builder</tt> умеет генерировать репозитарии, а ''remote nodes'' могут<br />
работать только с готовыми репозитарями. Существует строго ограниченное<br />
количество ''remote nodes'', по имени репозитария и по архитектуре.<br />
<br />
То есть существуют ноды типа:<br />
* build_sisyphus_i586<br />
* build_sisyphus_x86_64<br />
* build_50_i586<br />
* build_50_x86_64<br />
<br />
Как распределены ноды между физическим железом это никто не знает.<br />
Предполагается что они каким-то образом балансируют нагрузку.<br />
<br />
Есть ещё одна проблема: на ноды приходится целиком копировать временный<br />
репозитарий. Сейчас этот репозитарий делается симлинками. Это<br />
накладывает дополнительное условие: репозитарий на <tt>girar-builder</tt> и<br />
репозитарий на нодах должен иметь одинаковый путь. Потому что симлинки<br />
туда смотрят.<br />
<br />
==== Сборка из source rpm ====<br />
Недавно была добавлена из source rpm через <tt>girar</tt> (команда [[Git.alt/Справочник#build|build srpm]], анонс: http://lists.altlinux.org/pipermail/devel/2009-May/170472.html).<br />
<br />
При сборке из source rpm происходят проверки, запрещающие сборку, если предыдущая версия была собрана из [[gear]]. <br />
<br />
Обоснование данной проверки:<br />
Изначально предполагалось, что переход на сборку из [[git]] позволит проверять<br />
наследование сборки (от предыдущей сборки) естественноым путём, что<br />
упрощает совместную разработку и [[NMU]].<br />
<br />
К сожалению, <tt>srpm</tt> не позволяют реализовать такую проверку (точнее говоря,<br />
можно реализовать приблизительную проверку, например, путём сравнения<br />
<tt>%changelog</tt>'ов).<br />
<br />
По этой причине сборка пакета из <tt>srpm</tt> после сборки этого пакета из [[git]]<br />
не допускается.<br />
<br />
<br />
=== Источники ===<br />
Описание скомпилировано из:<br />
* http://lists.altlinux.org/pipermail/devel/2009-May/170534.html<br />
* http://lists.altlinux.org/pipermail/devel/2009-May/170726.html<br />
* http://lists.altlinux.org/pipermail/devel/2009-May/170478.html</div>Enderhttps://www.altlinux.org/index.php?title=Girar/Internals&diff=11208Girar/Internals2009-05-18T07:32:41Z<p>Ender: </p>
<hr />
<div>{{stub}}<br />
<br />
Есть два главных компонента системы: <tt>girar</tt> и <tt>girar-builder</tt>.<br />
<br />
;girar:это то что обслуживает ssh доступ к git.altlinux.org. <tt>girar</tt> формирует ''задания'' для сборки.<br />
;girar-builder:забирает ''задания'' на сборку.<br />
;Задание:это каталог со специальной структурой (ближайшая аналогия -- каталог /proc/$pid).<br>Структура каталога описана в файле girar-builder/TASK. Описание может быть неполным или неточным, но оно дает правильное первоначальное представление.<br />
<br />
''Задание'' состоит из нескольких стадий, которые выполняются в режиме<br />
<tt>sh -e</tt> (то есть, когда одна из стадий завершается с ошибкой, остальные<br />
стадии не выполняются). Последние стадии задания -- это копирование<br />
собранных пакетов в репозитарий и перегенерация репозитария.<br />
<br />
Процедура сборки задания находится в <tt>girar-builder/gb-run-task</tt>.<br />
<br />
У <tt>girar-builder</tt> нету своего хешера. Хешер существует на ноде, которая<br />
называется $remote_host. В каталоге <tt>girar-builder/remote/</tt> лежат<br />
программы, которые выполняются на $remote_host. В частности, для сборки<br />
пакетов на ноде выполняется программа <tt>girar-builder/remote/gb-remote-build</tt>.</div>Enderhttps://www.altlinux.org/index.php?title=Girar/Internals&diff=11207Girar/Internals2009-05-18T07:32:11Z<p>Ender: Создана новая страница размером Есть два главных компонента системы: <tt>girar</tt> и <tt>girar-builder</tt>. ;girar:это то что ...</p>
<hr />
<div>Есть два главных компонента системы: <tt>girar</tt> и <tt>girar-builder</tt>.<br />
<br />
;girar:это то что обслуживает ssh доступ к git.altlinux.org. <tt>girar</tt> формирует ''задания'' для сборки.<br />
;girar-builder:забирает ''задания'' на сборку.<br />
;Задание:это каталог со специальной структурой (ближайшая аналогия -- каталог /proc/$pid).<br>Структура каталога описана в файле girar-builder/TASK. Описание может быть неполным или неточным, но оно дает правильное первоначальное представление.<br />
<br />
''Задание'' состоит из нескольких стадий, которые выполняются в режиме<br />
<tt>sh -e</tt> (то есть, когда одна из стадий завершается с ошибкой, остальные<br />
стадии не выполняются). Последние стадии задания -- это копирование<br />
собранных пакетов в репозитарий и перегенерация репозитария.<br />
<br />
Процедура сборки задания находится в <tt>girar-builder/gb-run-task</tt>.<br />
<br />
У <tt>girar-builder</tt> нету своего хешера. Хешер существует на ноде, которая<br />
называется $remote_host. В каталоге <tt>girar-builder/remote/</tt> лежат<br />
программы, которые выполняются на $remote_host. В частности, для сборки<br />
пакетов на ноде выполняется программа <tt>girar-builder/remote/gb-remote-build</tt>.<br />
<br />
{{stub}}</div>Enderhttps://www.altlinux.org/index.php?title=Gear/changelog&diff=10732Gear/changelog2009-04-15T08:54:32Z<p>Ender: Создана новая страница размером ===gear-changelog=== ====gear-changelog vs git-shortlog==== Эта утилита формирует <tt>changelog</tt>, но делает...</p>
<hr />
<div>===gear-changelog===<br />
====gear-changelog vs git-shortlog====<br />
Эта утилита формирует <tt>changelog</tt>, но делает это несколько иначе чем <tt>git-shortlog</tt>. Вот, например, вывод последнего:<br />
<pre>Alexey Gladkov (11):<br />
Add license<br />
shell-var: Add new source<br />
shell-args: parse_common_option(): Option --quiet cancels option --verbose<br />
shell-var: shell_var_unquote(): Returns the value through eval<br />
shell-var: Rename shell_var_{no,yes} -> shell_var_is_{no,yes}<br />
Merge branch 'shell-var'<br />
shell-lists: Add new source<br />
shell-quote: Add quote_shell_args()<br />
shell-quote: Fix Usage for quote_shell_args<br />
shell_var_unquote(), string_quote_remove(): Fix "'" unquote for bash<br />
shell-quote: Rewrite quote_shell_args() from scratch, to avoid the dangerous shell constructions</pre><br />
<br />
Из 11 коммитов как тут сделать <tt>changelog</tt> можно, но если коммитов значительно больше и изменения ещё более дифференцированы, то радости никакой при этом не испытываешь. Я сломался на втором большом релизе.<br />
<br />
Утилита <tt>gear-changelog</tt> выводит коммиты от последнего тега, если не указано другое.<br />
<br />
Вот вывод тех же изменений, но полученные через <tt>gear-changelog</tt>:<br />
<pre>$ gear-changelog<br />
* Tue Apr 14 2009 Alexey Gladkov <legion@altlinux.org> 0.0.9-alt2<br />
- shell-quote changes:<br />
+ Rewrite quote_shell_args() from scratch, to avoid the dangerous<br />
shell constructions.<br />
+ Fix Usage for quote_shell_args.<br />
+ Add quote_shell_args().<br />
- shell-var changes:<br />
+ Rename shell_var_{no,yes} -> shell_var_is_{no,yes}.<br />
+ shell_var_unquote(): Returns the value through eval.<br />
+ Add new source.<br />
- Other changes:<br />
+ Update .gear/changelog.<br />
+ shell_var_unquote(), string_quote_remove(): Fix "'" unquote<br />
for bash.<br />
+ shell-lists: Add new source.<br />
+ shell-args: parse_common_option(): Option --quiet cancels<br />
option --verbose.<br />
+ Add license.</pre><br />
Они сгруппированы и из них выброшены некоторые лишние коммиты.<br />
<br />
====Как это сделано====<br />
<br />
<tt>gear-changelog</tt> использует набор со своими правилами. правила находят в файле <tt>.gear/changelog</tt>. Формат правил таков:<br />
<br />
* <code>width: <NUM></code><br>Это глобальная директива в правилах, указывающая ширину строки.<br />
<br />
* <code>group: <TITLE></code><br>Заголовок группы<br />
*<code>regexp: <PATTERN></code><br>grep-паттерн для того, чтобы отнести коммит к этой группе<br />
*<code>filter: <SED-S-COMMAND></code><br>sed'овкий s/// для возможных исправлений.<br />
<br />
'''Пример:'''<br />
<pre>group: shell*-config changes<br />
regexp: ^shell(-ini)?-config:<br />
filter: s/^shell(-ini)?-config: //<br />
<br />
group: Documentation changes<br />
regexp: ^[^:]+\.man:<br />
<br />
group: Other changes<br />
regexp: .*</pre><br />
<br />
Можно не заниматься группировками и вызвать утилиту без правил вообще (<tt>--no-rules</tt>) и/или не применять группировку (<tt>--no-groups</tt>). В этом случае вывод будет прост. Но мне кажется что группировать по префиксу коммита очень удобно... особенно если с терминологией определишься. Это помогает и коммиты более понятные делать и <tt>changelog</tt> формировать.<br />
<br />
У самой утилиты <tt>gear-changelog</tt> очень мало опций, единственная которая ещё достоена внимания это <tt>--format</tt>. Эта утилита генерирует <tt>changelog</tt> не только в rpm формате, формально она поддерживает ещё и <tt>deb</tt> и <tt>gnu</tt>.<br />
<br />
За два последних прошу не пинать. Я добавлял их из соображений не прибивания одного какого-то формата вывода. Они сделаны just-for-fun,<br />
но похожи на настоящие :)<br />
<br />
====Замечание====<br />
Приведённый тут вывод был получен на репозитории:<br />
<br />
http://git.altlinux.org/people/legion/packages/libshell.git<br />
<br />
Вот как выглядbт его gear/changelog:<br />
<br />
http://git.altlinux.org/people/legion/packages/libshell.git?p=libshell.git;a=blob;f=.gear/changelog;hb=HEAD<br />
<br />
[[Категория:Gear]]</div>Enderhttps://www.altlinux.org/index.php?title=Shared_Library_Symbol_Versioning_HOWTO&diff=5664Shared Library Symbol Versioning HOWTO2008-11-07T16:17:06Z<p>Ender: /* Поведение апстрима */</p>
<hr />
<div>[[Категория:HOWTO]]<br />
{{Stub}}<br />
<br />
''рассказать что такое symbol versioning и зачем он нужен''<br />
<br />
<br />
=== Поведение апстрима ===<br />
# '''Апстрим не отвечает за бинарную совместимость.''' Это особенно плохо вот в каком отношении: бинарная совместимость может обеспечивается не только названиями функций и переменных, но ещё и доступом к полям структур (например, структура может целиком создаваться на стеке). В Си доступ к полям структуры заменяется на доступ по смещению относительно начального адреса размещения структуры (то есть поля структуры на самом деле «пронумерованы» примерно как в массиве). Это означает, что (если API подразумевает доступ к полям структур) если просто переставить местами два поля в структуре, то вся бинарная совместимость накрывается медным тазом. При таком раскладе следить за бинарной совместимостью очень сложно. Version script может не помочь, нужно дополнительно изучать хедеры на предмет прототипов и структур. И тогда либо самому менять сонейм, если он вообще есть, либо, другой вариант — просто собирать библиотеку статически и линковаться с ней статически.<br />
# '''Апстрим понимает, что такое бинарная совместимость, и не делает глупостей''' (по крайней мере, не меняет базовых определений и прототипов). К счастью, такой расклад имеет место быть с большей частью системных библиотек. Тогда достаточно убедиться, что:<br />
## В новой версии библиотеки не исчезли никакие старые переменные, и, по крайней мере, функции. Если исчезли, тогда нужно проверить, что их никто не использует. Если их кто-то использует, тогда придётся восстанавливать.<br />
## Если добавились новые переменные или функции, сделать version script (добавить новую секцию в version script, в которой перечислены все новые переменные и, по крайней мере, функции).<br />
<br />
=== Как проверить, что убавившиеся функции никто не использует ===<br />
<br />
Нужно иметь копию Сизифа. Нужно установить пакет <tt>qa-robot</tt> и запустить '<tt>qa-robot bad_elf_symbols /ALT/Sisyphus/files/i586/RPMS</tt>'. Далее грепать файл <tt>~/.qa-robot/bad_elf_symbols/ref</tt> на предмет убавившихся символов.<br />
<br />
<br />
=== Как узнать, убавились ли или добавились новые символы и как сделать version script ===<br />
<br />
Нужно собрать новую версию пакета в тестовом режиме (со старым version script или без него). Далее установить пакет <tt>qa-robot</tt> и запустить '<tt>rpmsodiff libстарый.rpm libновый.rpm</tt>'. Он покажет, какие символы убавились, а какие добавились, а также выдаст заготовку для version script’а. Эту заготовку нужно поместить в файл с названием <tt>lib%name.map</tt> (альтернативно <tt>lib%name.ver</tt>, <tt>lib%name.sym</tt> или <tt>lib%name.def</tt>), возможно, немножко поправив название секции (<tt>LIBNAME_1.2.3</tt> vs <tt>NAME_1.2.3</tt>). Этот файл далее нужно скормить в <tt>gcc</tt> или <tt>libtool</tt> с помощью <tt>-Wl,--version-script=lib%name.def</tt>. Убедиться, что у пакета появился provides вида <tt>lib%name*.so*(LIBNAME_1.2.3)</tt>.</div>Enderhttps://www.altlinux.org/index.php?title=Shared_Libs_Policy&diff=5663Shared Libs Policy2008-11-07T16:11:18Z<p>Ender: /* Переезд со старого именования */</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=PavlovKonstantin, MikhailGusarov<br />
}}<br />
<br />
Библиотеки могут потенциально использоваться многими программами, из-за чего несовместимое изменение интерфейса любой библиотеки требует большого объёма работы по адаптации её клиентов. Для упрощения процесса обновления и уменьшения количества сломанных в каждый момент времени пакетов библиотеки различных несовместимых версий должны уметь сосуществовать в установленной системе.<br />
<br />
В дальнейшем несовместимое изменение ABI библиотеки будет называться «ломкой».<br />
<br />
=== Упаковка библиотек ===<br />
<br />
Библиотека должна быть упакована в пакет, имя которого меняется при каждой ломке ABI.<br />
<br />
Пакет должен иметь название lib%name%abiversion, где %abiversion является изменяемой частью (если название библиотеки заканчивается на цифру, то во всех именах пакетов перед %abiversion нужно добавить '-': lib%name-%abiversion, lib%name-%abiversion-devel etc).<br />
<br />
Пакеты с development-частями библиотек должны иметь название lib%name-devel. Если планируется поддерживать несколько development-версий для разных версий библиотек (что далеко не всегда оправданно, см. ниже) то lib%name%abiversion-devel.<br />
<br />
Статические библиотеки, собираемые в дополнение к динамическим, должны быть выделены в отдельный пакет lib%name-devel-static или lib%name%abiversion-devel-static (сооветственно стилю -devel-пакета). Если же собирается только статическая библиотека, без динамической, то пакет должен называться -devel.<br />
<br />
Таким образом, именование пакетов вида lib%name%abiversion и lib%name-devel позволит избавиться от проблем с обновлениями пакетов, когда они не пересобраны с новой библиотекой.<br />
<br />
Если же библиотеки с разным ABI сосуществовать в системе не могут по каким-то причинам (будь то файловые конфликты или что-то другое), то данное полиси неприменимо, поскольку содержание двух пакетов в репозитории не будет иметь смысла и майнтайнер при обновлении библиотеки вместо изменения названия пакета должен пересобрать все зависимые пакеты.<br />
<br />
=== Выбор правильного %abiversion в имени пакета ===<br />
<br />
Если авторы библиотеки явно используют soversion для указания моментов ломки, то в качестве %abiversion нужно использовать использовать именно его. Если авторы библиотеки soversion не используют, или используют нестандартно (скажем, изменяя его вне зависимости от реальной смены ABI), то можно использовать любую другую удобную в данном конкретном случае схему именования (рекомендуется использовать последовательно возрастающие числа, начинающиеся с 0 и увеличивающиеся на 1 при каждой ломке).<br />
<br />
В случае, если существует несколько поддерживаемых веток одной библиотеки, %soversion может соответствовать major-версии библиотеки (libqt3, libqt4) или иметь вид major.minor (libdb4.0, libdb4.1). Можно также использовать часть soname’а библиотеки (напр., libcurl4, libflac8).<br />
<br />
=== Переезд со старого именования ===<br />
<br />
Не секрет, что сейчас в Сизифе подобным образом запакованы очень немногие библиотеки. Предположим, что библиотека libfoo обновилась и в ней сменился soname с N на M.<br />
<br />
При сборке новой версии пакета libfoo предлагается сделать следующее:<br />
#Переименовать бинарный пакет libfoo в libfooM<br />
#Добавить в пакет libfooM Provides: libfoo = %version-%release<br />
<br />
=== Политика адаптации клиентов разделяемых библиотек к новым версиям ===<br />
<br />
За исключением особых случаев (например, qt3 и qt4, которые по сути являются различными библиотеками, а не разными версиями одной), настоятельно рекомендуется поддерживать наличие ровно одного -devel пакета (соответствующего самой новой версии библиотеки) для любой библиотеки, сколько бы старых версий этой библиотеки не присутствовало в Сизифе. При выполнении этого правила новые собираемые версии клиентов библиотек будут автоматически собираться с новой версией библиотеки (см. тж. [http://lists.altlinux.org/pipermail/devel/2006-December/039664.html письмо в devel@]). В виде исключения, если новая версия библиотеки приводит к несобираемости большого количества пакетов, допустимо поддерживать две версии пакетов -devel, с проставлением тегов Conflicts в этих пакетах -devel друг на друга и соответствующим разделением зависимых пакетов на собирающиеся с новой и со старой версией библиотеки.<br />
<br />
Старые библиотеки должны быть перемещены в группу 'System/Legacy libraries' при появлении в Сизифе новой версии [<div style="display: inline; color: red;">FIXME: группа прибита внутри RPM-ки. Пересобирать их? Есть ли другой вариант? Можно ли узнать, что библиотека уже никем не собирается?</div>]. Аналогично пакетам -devel, в исключительных случаях разрешается иметь более одной версии библиотеки не в Legacy.<br />
<br />
Когда библиотека из группы 'System/Legacy libraries' не требуется ни одним пакетом из Сизифа, она должна быть удалена из него. Пакеты из группы 'System/Legacy Libraries' (и, соответственно, пакеты, зависящие от них) объявляются непригодными к выпуску в [[Branches|стабильной ветке]].<br />
<br />
=== Бэкпорты ===<br />
<br />
Поскольку предлагаемое изменение именования библиотек жёстко прикрепляет soname к имени пакета, а также позволяет сосуществовать разным версиям библиотек, становится возможным бэкпортить новые версии библиотек и программы, зависящие от новых версий библиотек, что значительно ослабляет условие 5 в [http://backports.altlinux.ru/policy/ backports policy].<br />
<br />
== Ссылки ==<br />
<br />
* [http://www.us.debian.org/doc/debian-policy/ch-sharedlibs.html http://www.us.debian.org/doc/debian-policy/ch-sharedlibs.html]</div>Enderhttps://www.altlinux.org/index.php?title=Dual_Screen_with_radeon&diff=5510Dual Screen with radeon2008-11-05T16:01:46Z<p>Ender: Новая: == Xrandr == a-la XINERAMA: один Screen, экран имеет ширину в два монитора === xrog.conf === Section "ServerLayout" Identifier "radeon" Screen ...</p>
<hr />
<div>== Xrandr ==<br />
a-la XINERAMA: один Screen, экран имеет ширину в два монитора<br />
<br />
=== xrog.conf ===<br />
Section "ServerLayout"<br />
Identifier "radeon"<br />
Screen ''"radeon|0"''<br />
...<br />
EndSection<br />
<br />
# остался от fglrx.<br />
Section "Monitor"<br />
Identifier ''"aticonfig-Monitor[0]"''<br />
Option "VendorName" "ATI Proprietary Driver"<br />
Option "ModelName" "Generic Autodetecting Monitor"<br />
Option "DPMS" "true"<br />
DisplaySize 375 302<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier ''"radeon|0"''<br />
Driver "radeon"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier ''"radeon|0"''<br />
Device ''"radeon|0"''<br />
Monitor ''"aticonfig-Monitor[0]"''<br />
DefaultDepth 24<br />
Option "Backingstore" "true"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1280x1024"<br />
'''Virtual 2560 1024'''<br />
EndSubSection<br />
EndSection<br />
<br />
Обращаю внимание на выделенный жирным ''Virtual''. не будет его, <tt>xrandr</tt> может начать ругаться (в моем случае)<br />
xrandr: screen cannot be larger than 1280x1280 (desired size 2560x1024)<br />
как я понял, причина, что <tt>xrandr</tt> работает в пределах ''Virtual'' и за них не вылезает.<br />
<br />
в принципе это вся конфигурация <tt>xorg</tt>. остальное делается динамически.<br />
<br />
=== xrandr invocation ===<br />
==== получение списка выводов ====<br />
перво-наперво смотрим, какие выводы мы имеем:<br />
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum '''1280 x 1280'''<br />
<font color=red>DVI-0</font> connected 1280x1024+0+0 (normal left inverted right x axis y axis) 0mm x 0mm<br />
1280x1024 59.9*+ 60.0 <br />
1280x960 60.0 <br />
1024x768 60.0 <br />
800x600 60.3 <br />
640x480 59.9 <br />
<font color=red>DVI-1</font> connected 1280x1024+0+0 (normal left inverted right x axis y axis) 0mm x 0mm<br />
1280x1024 59.9*+ 60.0 <br />
1280x960 60.0 <br />
1024x768 60.0 <br />
800x600 60.3 <br />
640x480 59.9 <br />
<br />
<font color=red>DVI-0</font> и <font color=red>DVI-1</font> - выводы для <tt>xrandr</tt> ( подставляется в <tt>--output</tt>).<br />
''обращаю внимание на выделенное 1280x1280: это тот самый region, на котором рабоатает xrandr. меняется через Virtual, как сказано выше.''<br />
<br />
==== запуск dual-head режима ====<br />
xrandr --output DVI-0 --left-of DVI-1<br />
в большинстве случаев после этой команды ничего делать тне нужно.<br />
<br />
==== привязка выхода к монтору ====<br />
так случилось, что после запуска <tt>xrandr</tt> с <tt>--left-of</tt>, второй монитор начал показывать один в один то, что показывает первый. но по taskbar'у fluxbox'а заметно, что двойной режим-то включен. исправило ситуацию следующие команды:<br />
xrandr --output DVI-0 --crtc 0 --auto<br />
xrandr --output DVI-1 --crtc 1 --auto<br />
здесь устанавливается привязка монтора (crtc) и вывода (output). <tt>--auto</tt> указан для того, чтобы после этих команда мониторы не выключались.<br />
<br />
==== уменщились/увеличились шрифты ====<br />
второй проблемой, с которой я столкнулся, были шрифты. после запуска <tt>xrandr</tt> с <tt>--left-of</tt> dpi шрифтов изменились, как и размеры монитора в выводе <tt>xdpyinfo</tt>:<br />
...<br />
screen #0:<br />
print screen: no<br />
'''dimensions: 1280x1024 pixels (360x270 millimeters)<br />
resolution: 96x96 dots per inch<br />
depths (7): 24, 1, 4, 8, 15, 16, 32<br />
root window id: 0xa1<br />
depth of root window: 24 planes<br />
...<br />
мне же нужно было: <br />
screen #0:<br />
...<br />
print screen: no<br />
'''dimensions: 1280x1024 pixels (375x302 millimeters)'''<br />
resolution: 87x86 dots per inch<br />
depths (7): 24, 1, 4, 8, 15, 16, 32<br />
root window id: 0xa1<br />
depth of root window: 24 planes<br />
...<br />
для чего я и указывал ''DisplaySize 375 302'' в xorg.conf, но после <tt>xrandr</tt> ''DisplaySIze'' к сожалению сбросился.<br />
установка вручную происходит следующим образом:<br />
xrandr --output DVI-0 --fbmm 375x302<br />
xrandr --output DVI-1 --fbmm 375x302<br />
после перезапуска программ (<tt>fluxbox</tt> restart, <tt>opera</tt>, etc) шрифты вернулись на место.<br />
<br />
==== сброс dual-head ====<br />
чисто случайно испробовал я следующую команду:<br />
xrandr --output DVI-1 --same-as DVI-0<br />
после неё X сервер вернулся к clone режиму.<br />
<br />
=== Помещение в автозапуск ===<br />
в <tt>/etc/X11/xinit</tt> есть файл <tt>xrandrrc</tt>. он считывает <tt>/etc/sysconfig/xrandr</tt> и <tt>$HOME/.Xrandr</tt> записи вида:<br />
:[0-9]* <xrandr options><br />
поэтому для атвтоматического запуска <tt>xrandr</tt> достаточно поместить в один из этих файлов команды. мне хватило следующих:<br />
:0 --output DVI-0 --fbmm 375x302<br />
:0 --output DVI-1 --fbmm 375x302<br />
:0 --output DVI-0 --crtc 0 --auto<br />
:0 --output DVI-1 --crtc 1 --auto<br />
:0 --output DVI-0 --left-of DVI-1<br />
<br />
== Dual Screen режим ==<br />
как в <tt>XINERAMA</tt>, так и в <tt>xrandr</tt> мне не понравилось, что после их запуска программы экраном считают не один монитор, а оба сразу. например программа установки обев растягивала картинку на оба монитора. <br />
с другой <tt>xrandr</tt> для этого и предназначен, потому нужен был иной подход: радзделение мониторов по разным Screen'ам.<br />
я нашел только, как это сделать статически:<br />
Section "ServerLayout"<br />
Identifier "radeon"<br />
<font color=red>Screen "radeon|0"</font><br />
<font color=red>Screen "radeon|1" RightOf "radeon|0"</font><br />
...<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "aticonfig-Monitor[0]"<br />
Option "VendorName" "ATI Proprietary Driver"<br />
Option "ModelName" "Generic Autodetecting Monitor"<br />
Option "DPMS" "true"<br />
DisplaySize 375 302<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "aticonfig-Monitor[1]"<br />
Option "VendorName" "ATI Proprietary Driver"<br />
Option "ModelName" "Generic Autodetecting Monitor"<br />
Option "DPMS" "true"<br />
DisplaySize 375 302<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "radeon|0"<br />
Driver "radeon"<br />
Option "DRI" "off"<br />
<font color=red>Screen 0</font><br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "radeon|1"<br />
Driver "radeon"<br />
Option "DRI" "off"<br />
<font color=red>Screen 1</font><br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "radeon|0"<br />
Device "radeon|0"<br />
Monitor "aticonfig-Monitor[0]"<br />
DefaultDepth 24<br />
Option "Backingstore" "true"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1280x1024"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "radeon|1"<br />
Device "radeon|1"<br />
Monitor "aticonfig-Monitor[1]"<br />
DefaultDepth 24<br />
Option "Backingstore" "true"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1280x1024"<br />
EndSubSection<br />
EndSection<br />
красным выделены критичные строчки.<br />
в <tt>ServerLayout</tt> строка <br />
Screen "radeon|0"<br />
важна! в противном случае X сервер матерится, что не может найти подходящий screen для работы.</div>Enderhttps://www.altlinux.org/index.php?title=TypicalPackagingErrors/LinkingError&diff=3387TypicalPackagingErrors/LinkingError2008-09-04T20:13:57Z<p>Ender: </p>
<hr />
<div>[[Category:Devel]]<br />
{{MovedFromFreesourceInfo|AltLinux/Sisyphus/devel/TypicalPackagingErrors/LinkingError}}<br />
<br />
== --as-needed ==<br />
<br />
На этой странице планируется собирать полезную для майнтейнеров информацию, связанную с ошибками сборки из-за --as-needed.<br />
<br />
=== Из архива почтовой рассылки devel@: ===<br />
<br />
---- Original Message ----<br />
Subject: Re: [devel] --as-needed<br />
Date: Mon, 6 Mar 2006 16:22:03 +0300<br />
From: Dmitry V. Levin <ldv@altlinux><br />
To: ALT Devel discussion list <devel@lists.altlinux><br><br />
Вот несколько искусственный пример, полученный<br />
путём усушки реального случая:<br><br />
$ cat zv.c<br />
#include <zlib.h><br />
int main(void) { return !zlibVersion(); }<br />
$ gcc -c zv.c<br />
$ ld --as-needed --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o zv /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i586-alt-linux/3.4.4/ crtbegin.o -[[TypicalPackagingErrors/L/usr/lib/gcc/i586|i586]]-alt-linux/3.4.4 -L/usr/lib zv.o -lz -lc /usr/lib/gcc/i586-alt-linux/3.4.4/crtend.o /usr/lib/crtn.o<br />
$ ld --as-needed --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o zv /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i586-alt-linux/3.4.4/crtbegin.o -[[TypicalPackagingErrors/L/usr/lib/gcc/i586|i586]]-alt-linux/3.4.4 -L/usr/lib -lz zv.o -lc /usr/lib/gcc/i586-alt-linux/3.4.4/crtend.o /usr/lib/crtn.o<br />
zv.o: In function `main':zv.c:(.text+0x23): undefined reference to `zlibVersion'<br><br />
Первый ld отличается от второго порядком файлов:<br />
в первом "zv.o -lz", во втором "-lz zv.o".<br><br />
Такое поведение ld не является ошибкой, в режиме --as-needed порядок может<br />
повлиять на значение: если библиотека (здесь -lz) следует до первого<br />
пользователя (здесь zv.o), то в режиме --as-needed оно будет убрано как<br />
ненужное.<br />
<br />
---- Original Message ----<br />
Subject: Re: [devel] --as-needed<br />
Date: Mon, 6 Mar 2006 18:56:11 +0300<br />
From: Dmitry V. Levin <ldv@altlinux><br />
To: ALT Devel discussion list <devel@lists.altlinux><br><br />
&gt;&gt;&gt;&gt;Первый ld отличается от второго порядком файлов:<br />
&gt;&gt;&gt; > в первом "zv.o -lz", во втором "-lz zv.o".<br />
&gt;&gt;&gt; ><br />
&gt;&gt;&gt; > Такое поведение ld не является ошибкой, в режиме --as-needed порядок может<br />
&gt;&gt;&gt; > повлиять на значение: если библиотека (здесь -lz) следует до первого<br />
&gt;&gt;&gt; > пользователя (здесь zv.o), то в режиме --as-needed оно будет убрано как<br />
&gt;&gt;&gt; > ненужное.<br />
&gt;&gt;&gt;<br />
&gt;&gt; Собственно, со статическими библиотеками так всегда и было (только ещё<br />
&gt;&gt; хуже - могла вытащиться часть, которой потом не хватало для остального).<br><br />
В том то и дело: --as-needed просто делает работу со динамическими<br />
библиотеками аналогичной работе со статическими библиотеками.<br />
<br />
---- Original Message ----<br />
Subject: Re: [devel] --as-needed<br />
Date: Tue, 7 Mar 2006 08:06:38 +0300<br />
From: Andrey Rahmatullin <wrar-alt@mail><br />
To: devel@lists.altlinux<br />
&gt;&gt; Меньше всех, разумеется, пострадали KDEшные пакеты, и то с редкими &gt;&gt; именами. :)<br><br />
Если бы во всех около-КДЕшных пакетах был нормальный (новый) admin/, давно<br />
можно было бы всем им (попробовать) сделать --enable-new-ldflags,<br />
добавляющий --as-needed ;) <br />
См. konversation.<br />
<br />
---- Original Message ----<br />
Subject: Re: [devel] --as-needed<br />
Date: Tue, 7 Mar 2006 12:30:53 +0300<br />
From: Dmitry V. Levin <ldv@altlinux.><br />
To: ALT Devel discussion list <devel@lists.altlinux><br><br />
&gt;&gt;&gt; > Первый ld отличается от второго порядком файлов:<br />
&gt;&gt;&gt; > в первом "zv.o -lz", во втором "-lz zv.o".<br />
&gt; &gt;&gt; Ага. И такое может сгенерить и automake. И генерит.<br />
&gt;&gt; <br />
&gt;&gt; Вход:<br />
&gt;&gt; bin_PROGRAMS = mpdscribble<br />
&gt;&gt; mpdscribble_SOURCES = mpdscribble.c as.c conn.c escape.c file.c lmc.c \<br />
&gt;&gt; md5.c misc.c as.h conn.h escape.h file.h lmc.h md5.h misc.h &gt;&gt; AM_CFLAGS="-I./libmpdclient"<br />
&gt;&gt; AM_LDFLAGS="./libmpdclient/libmpdclient.o"<br><br />
Не надо имена библиотек указывать в LDFLAGS.<br />
Для этого в automake предусмотрены другие средства (LDADD).<br />
<br />
---- Original Message ----<br />
Subject: Re: [devel] --as-needed<br />
Date: Tue, 14 Mar 2006 13:31:24 +0300<br />
From: Dmitry V. Levin <ldv@altlinux><br />
To: ALT Devel discussion list <devel@lists.altlinux><br><br />
&gt; Кстати, а это нововведение в апстриме ? В смысле можно этим агументировать<br />
&gt; необходимость пересмотра порядка библиотек при подготовке багрепортов для<br />
&gt; апстримов других пакетов ?<br><br />
Да, ld --as-needed руализован больше года назад и есть в последнем<br />
стабильном выпуске ld (не только для linux).<br><br />
Повторюсь, изменение порядка библиотек, которое приходится делать<br />
дляисправления линковки с --as-needed, автоматически исправляет линковку<br />
со статическими библиотеками. Для некоторых upstream'ов это тоже может<br />
быть аргументом.<br />
<br />
---- Original Message ----<br />
Subject: Re: [devel] --as-needed<br />
Date: Sat, 18 Mar 2006 22:06:45 +0300<br />
From: Dmitry V. Levin <ldv@altlinux><br />
To: ALT Devel discussion list <devel@lists.altlinux><br><br />
Обнаружилась ещё одна типичная проблема, которую легко понять на<br />
приведённом ниже простом примере:<br><br />
$ cat libfoo1.c <br />
int foo1(void) { return 0; }<br />
$ cat libfoo2.c<br />
extern int foo1(void);<br />
int foo2(void) { return foo1(); }<br />
$ cat foo3.c <br />
extern int foo2(void);<br />
int main(void) { return foo2(); }<br><br />
$ gcc -Wall -fpic -shared libfoo1.c -o libfoo1.so<br />
$ gcc -Wall -fpic -shared libfoo2.c -o libfoo2.so -L. -lfoo1<br />
$ gcc -Wall foo3.c -o foo3 -L. -lfoo2<br />
/usr/bin/ld: warning: libfoo1.so, needed by ./libfoo2.so, not found (try using -rpath or -rpath-link)<br />
./libfoo2.so: undefined reference to `foo1'<br />
collect2: ld returned 1 exit status<br />
$ gcc -Wall foo3.c -o foo3 -L. -lfoo2 -Wl,-rpath-link,.<br><br />
Тонкость в том, что раньше ещё и так работало (хоть и ругалось):<br />
$ gcc -Wall foo3.c -o foo3 -L. -lfoo2 -lfoo1<br />
/usr/bin/ld: warning: libfoo1.so, needed by ./libfoo2.so, not found (try using -rpath or -rpath-link)<br><br />
А теперь так не работает:<br />
$ gcc -Wall foo3.c -o foo3 -L. -lfoo2 -lfoo1<br />
/usr/bin/ld: warning: libfoo1.so, needed by ./libfoo2.so, not found (try using -rpath or -rpath-link)<br />
./libfoo2.so: undefined reference to `foo1'<br />
collect2: ld returned 1 exit status<br><br />
Это bugfix, см. [http://sourceware.org/ml/binutils/2006-03/msg00259.html http://sourceware.org/ml/binutils/2006-03/msg00259.html]<br />
Так что надо будет постепенно всё это зафиксить и за'upstream'ить.<br />
<br />
=== Ссылки ===<br />
* [[UpStream/AsNeeded|AsNeeded]]</div>Ender