<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.altlinux.devel">
    <title>gmane.linux.altlinux.devel</title>
    <link>http://blog.gmane.org/gmane.linux.altlinux.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84181"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84175"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84161"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84153"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84084"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84064"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84042"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84030"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84029"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84001"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/84000"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83984"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83983"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83974"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83973"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83972"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83967"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83951"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83948"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.altlinux.devel/83934"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84181">
    <title>Получение списка пакетов по зависимостям rpm</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84181</link>
    <description>&lt;pre&gt;
Возникла необходимость по списку зависимостей бинарного пакета 
(получаемого через rpm --requires) получить
список названий пакетов, удовлетворяющих эти зависимости.
В сущности, это происходит при установке пакета с помощью hsh-install: 
там вызывается rpmi для установки пакетов по перечню.

Ну то есть надо в ответ на rpm-зависимость 'perl(Text/ParseWords.pm)' 
получить perl-base.

Как получить такой список снаружи, есть ли доступный способ?


&lt;/pre&gt;</description>
    <dc:creator>Vitaly Lipatov</dc:creator>
    <dc:date>2012-05-26T11:02:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84175">
    <title>выход из сборщика в сеть</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84175</link>
    <description>&lt;pre&gt;Приветствую всех,

Для сборки некоего пакета сборщику оказалось нужно вылезать в
интернет. Делает он это так, вызывает xsltproc, который за таблицей
преобразования xslt лезет на сайт docbook:
$ xsltproc --stringparam man.copyright.section.enable 0 --stringparam
man.authors.section.enabled 0
http://docbook.sourceforge.net/release/xsl-ns/current/manpages/docbook.xsl
unpaper.1.xml

Если собирать на машине, у которой выход сеть присутствует, то всё
хорошо, но в hasher-е оно валится. И, на жалость, попытка вытянуть
этот docbook.xsl руками с очевидным успехам не привела, т.к. оный
имеет большое количество нассылаемых файлов, счёт которых идёт на
десятки.

Вообщем я тут вижу 2 подхода: либо как-то дать hasher-у выход в сеть,
либо где-то (я не знаю где) найти этот большой пакет преобразований
xslt.

Какие будет ещё мысли и советы?

&lt;/pre&gt;</description>
    <dc:creator>Мал Скрылёв</dc:creator>
    <dc:date>2012-05-26T09:21:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84161">
    <title>I: buildreq-src now supports perl</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84161</link>
    <description>&lt;pre&gt;Господа, 

в утилиту buildreq-src добавлен автопоиск сборочных perl-зависимостей. 
По умолчанию зависимости прописываются как perl(Some/Module.pm). 
C опцией --sourcedep-perl-resolve зависимости прописываются как
имена соответствующих пакетов.

Требуется perl-RPM-Source-Editor &amp;gt;= 0.782.

&lt;/pre&gt;</description>
    <dc:creator>Igor Vlasenko</dc:creator>
    <dc:date>2012-05-24T16:06:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84153">
    <title>IA: kernel vs udev &gt; 175</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84153</link>
    <description>&lt;pre&gt;Привет!

Я сегодня нарвался сам и хотел бы предостеречь вас:

udev 176
========
The 'devtmpfs' filesystem is required now, udev will not create or
delete device nodes anymore, it only adjusts permissions and ownership
of device nodes and maintains additional symlinks.

Таким образом, если у вас ядро не поддерживает devtmpfs, то udev будет
для вас совершенно не рабочим как в системе, так и в initrd.

&lt;/pre&gt;</description>
    <dc:creator>Alexey Gladkov</dc:creator>
    <dc:date>2012-05-24T13:26:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84084">
    <title>repocop complain</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84084</link>
    <description>&lt;pre&gt;Други!

Не очень понимаю, на что именно ругается Репокоп - http://sisyphus.ru/ru/srpm/Sisyphus/i3/repocop :

Main Categories consist of those categories that every conforming desktop environment MUST support.(http://standards.freedesktop.org/menu-spec/latest/apa.html). None found in /usr/share/applications/i3.desktop. please, fix. Menu-related Additional Categories (http://standards.freedesktop.org/menu-spec/latest/apa.html) not found in /usr/share/applications/i3.desktop. Please add it or report a bug against this test if you already have registered one (not including menu unrelated ones as Core or Qt). 

Вот содержимое файла /usr/share/applications/i3.desktop:

[Desktop Entry]
Name=i3
Comment=improved dynamic tiling window manager
Exec=i3
Type=Application

Может быть его нужно вообще убрать? Или, хотя бы, где посмотреть, как подобный файл должен выглядеть (Оконный менеджер)?

Заранее спасибо,
    Андрей.
_______________________________________________
Devel mailing list
Devel&amp;lt; at &amp;gt;lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel&lt;/pre&gt;</description>
    <dc:creator>Bergman Andrey</dc:creator>
    <dc:date>2012-05-19T09:01:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84064">
    <title>atime-based "no need to rebuild"</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84064</link>
    <description>&lt;pre&gt;Мужчины, у вас медленно задания собираются.  Потому что при повторном
запуске выполняется пересборка всех пакетов, а оптимизация "no need to
rebuild" срабатывает только при очень строгом условии: список пакетов
в чруте должен быть полностью идентичным, с точностью до конкретной сборки
каждого пакета (пересобранный пакет уже не идентичен).  Далее я обсуждаю
другие критерии для повторной пересборки и как их можно использовать для
дальнейшей оптимизации.

Есть два основных аспекта этой проблемы.

1) После повторной пересборки в пакете появляются новые значения st_mtime,
основанные на текущем времени; это в свою очередь запускает каскад
пересборок, даже если содержимое файлов в пакете не меняется.
Следовательно, чтобы остановить этот каскад, в качестве критерия
пересборки нужно учитывать только содержимое файлов (md5 суммы).

2) Некоторые пакеты во время сборки просто не используются.  Например,
пакет cpio редко используется при сборке, но он входит в базовую сборочную
среду; его обновление запустит лишнюю пересборку какого бы то ни было
пакета.  Такие ситуации возникают и за пределами базовой сборочной среды.
Следовательно, в качестве критерия пересборки нужно учитывать только
фактически используемые пакеты.

Исходя из этих соображений я реализовал альтернативный/дополнительный
критерий, который учитывает использование файлов в чруте.  В двух словах,
он работает так: при первой сборке отслеживаются фактически используемые
файлы (на основе разницы между st_mtime/st_ctime и st_atime).  Перед
началом повторной сборки используемые файлы проверяются: если они
совпадают (с точностью до md5 сумм), то пересборка не требуется.

http://git.altlinux.org/people/at/packages/girar-builder.git

Несколько точнее, перед самым началом сборки, когда все пакеты
BuildRequires уже установлены, запускается специальная программа, которая
"сбрасывает" st_atime у всех файлов в чруте.  Эту программу пришлось
написать на Си, потому что там есть тонкости.  Сбрасывать st_atime
требуется, чтобы он обновлялся на файловых системах, смонтированных с
опцией relatime (которая используется по умолчанию).  Затем запускается
сборка, и после ее завершения запускается другая программа, которая ищет
в чруте все "использованные" файлы (у которых st_atime &amp;gt; st_mtime/ctime).
Эта схема отслеживания достаточно надежна, поскольку псевдопользователь
builder не может изменить атрибуты запакованных файлов, принадлежащих
псевдопользователю rooter.

Некоторые файлы отслеживать не нужно.  Например, в базе /var/lib/rpm/
содержатся значения st_mtime всех файлов, которые как бы дублируют
значения st_mtime в реальной файловой системе (от которых мы как раз
пытаемся избавиться).  В /var/cache/ldconfig/ содержатся значения st_ctime
библиотек.  В /etc/passwd содержатся численные идентификаторы
псевдопользователей rooter и builder, которые отличаются на сборочных
нодах.  Самое спорное решение - не отслеживать файлы в /usr/share/doc/.
Я обосную его чуть ниже.

Список использованных файлов не может быть исчерпывающим критерием.
Например, при первой сборке в чруте может отсутствовать библиотека foo.
Скрипт configure скажет "checking for libfoo... no", т.е. программа
соберется в конфигурации без libfoo.  Если для повторной сборки установить
в чрут libfoo-devel, то ранее использованные файлы могут быть полностью
идентичны, но результат сборки изменится, поскольку в чруте появились
новые файлы.  Следовательно, полный критерий должен учитывать все файлы
в чруте, но для неиспользуемых файлов нужно учитывать только имя (без md5
суммы).  Теперь становится понятно, почему я предлагаю не отслеживать
содержимое /usr/share/doc/: каталоги в /usr/share/doc/ традиционно
включают в себя версию пакета, т.е. при сборке новой версии какого-либо
пакета будет срабатывать критерий изменения списка неиспользуемых файлов.
Если вернуться к примеру с cpio, это выглядит нежелательно.

Наконец, остается вопрос: нужно ли учитывать симлинки?  С одной стороны,
симлинки не содержат самостоятельных данных.  С другой стороны, легко
придумать контрпример: если симлинк 'gcc -&amp;gt; gcc4.5' заменить на 'gcc -&amp;gt;
gcc4.6', то результат сборки может серьезно измениться.  Короче, симлинки
"перекраивают" файловую систему, и их можно рассматривать как миниатюрные
конфигурационные файлы.  Пути симлинков учитываются наравне с md5 суммами
файлов.

Эти изменения привносит несколько новых файлов в задание: кроме
chroot_base и chroot_BR (списки пакетов), в каждом каталоге появятся
файлы chroot_fused и chroot_funused (списки использованных и
неиспользованных файлов).  Кроме того, если выполняется повторная сборка,
то добавляются файлы chroot_pdiff и chroot_fdiff, из которых можно понять
причину пересборки.

Насколько было возможно, я протестировал эти изменения.
_______________________________________________
Devel mailing list
Devel&amp;lt; at &amp;gt;lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel&lt;/pre&gt;</description>
    <dc:creator>Alexey Tourbin</dc:creator>
    <dc:date>2012-05-17T04:19:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84042">
    <title>squid и kde4</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84042</link>
    <description>&lt;pre&gt;Вот уже два дня ругаюсь всякими нехорошими словами.

Во-первых, в нашем squid обнаружилась очень неприятная проблема с 
использованием external_acl_type, описанная мною в #27329. Эта бага рушит 
работу squid. Однако на неё нет никакой реакции. Даже непонятно, что делать 
дальше. Вешать блокер? Есть ли живой мантейнер?

Во-вторых, позавчерашнее обновление KDE4 до 4.8.3 (вместе со всей системой) 
снесло голову KMail: любая попытка сменить папку или выбрать письмо приводило 
к краху KMail. Сегодня наконец-то программа заработала, но после нудной чистки 
всяких кешей в /var/tmp и конфигов в ~/.kde4. Уж не знаю, что сработало. 
Простой перезапуск оболочки и даже компьютера ничего не давал. Причины я так и 
не нашёл. Может, пора при обновлении kde4 стоит сразу чистить времянки?

Зато обнаружил бонус: заработало автодополнение в строке ввода адресата в 
KMail. :) Хоть какой-то бальзам на душу.

&lt;/pre&gt;</description>
    <dc:creator>Sergei Epiphanov</dc:creator>
    <dc:date>2012-05-16T06:09:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84030">
    <title>libldap2.4 -&gt; libldap</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84030</link>
    <description>&lt;pre&gt;Хотел узнать, почему вопреки
http://www.altlinux.org/SharedLibsPolicy
libldap2.4 вдруг переименовали?

Эти метания с нумерацией так всегда меня задевают...
Приходится бегать по конфигам и спекам и менять названия пакетов.

&lt;/pre&gt;</description>
    <dc:creator>Vitaly Lipatov</dc:creator>
    <dc:date>2012-05-15T19:19:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84029">
    <title>debuginfo, x86_64-i586 и Dynamic MMap ran out of room</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84029</link>
    <description>&lt;pre&gt;
Большая радость по поводу появления полного x86_64-i586
омрачается тем, что пользоваться этим невозможно.
Без ручного увеличения лимита apt не справляется:
Чтение списков пакетов... Ошибка!
E: Dynamic MMap ran out of room
E: При обработке python-module-django (NewVersion1) возникла ошибка
...
E: Невозможно прочитать список пакетов или файл статуса.

Хотелось бы понять политику: нельзя ли вставить в apt новый лимит, 
подходящий под увеличенное количество пакетов?

Или каждый должен для себя сам настраивать?

&lt;/pre&gt;</description>
    <dc:creator>Vitaly Lipatov</dc:creator>
    <dc:date>2012-05-15T19:12:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84001">
    <title>I: make-initrd guess-modules</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84001</link>
    <description>&lt;pre&gt;Приветствую!

В версии make-initrd-0.7.8 появилась возможность узнать какие модули
(с точки зрения make-initrd) понадобятся для монтирования указанного
блочного устройства или точки монитрования:

# make-initrd guess-modules /mnt/scm
/lib/modules/3.3.0/kernel/drivers/block/ub.ko
/lib/modules/3.3.0/kernel/drivers/scsi/scsi_mod.ko
/lib/modules/3.3.0/kernel/drivers/scsi/sd_mod.ko
/lib/modules/3.3.0/kernel/drivers/usb/core/usbcore.ko
/lib/modules/3.3.0/kernel/drivers/usb/host/ehci-hcd.ko
/lib/modules/3.3.0/kernel/drivers/usb/storage/uas.ko
/lib/modules/3.3.0/kernel/drivers/usb/storage/usb-libusual.ko
/lib/modules/3.3.0/kernel/drivers/usb/storage/usb-storage.ko
/lib/modules/3.3.0/kernel/drivers/usb/usb-common.ko
/lib/modules/3.3.0/kernel/fs/ext4/ext4.ko
/lib/modules/3.3.0/kernel/fs/jbd2/jbd2.ko
/lib/modules/3.3.0/kernel/fs/mbcache.ko
/lib/modules/3.3.0/kernel/lib/crc16.ko
/lib/modules/3.3.0/kernel/lib/crc-t10dif.ko

# make-initrd guess-modules /dev/sda1
/lib/modules/3.3.0/kernel/drivers/ata/ata_generic.ko
/lib/modules/3.3.0/kernel/drivers/ata/ata_piix.ko
/lib/modules/3.3.0/kernel/drivers/ata/libata.ko
/lib/modules/3.3.0/kernel/drivers/ata/pata_acpi.ko
/lib/modules/3.3.0/kernel/drivers/scsi/scsi_mod.ko
/lib/modules/3.3.0/kernel/drivers/scsi/sd_mod.ko
/lib/modules/3.3.0/kernel/fs/fat/fat.ko
/lib/modules/3.3.0/kernel/fs/fat/vfat.ko
/lib/modules/3.3.0/kernel/lib/crc-t10dif.ko

Также чтобы сократить время выполнения и уменьшить количество ненужных
операций появился дополнительный ключ --no-depmod (-D).

Надеюсь это будет кому-нибудь полезно.

&lt;/pre&gt;</description>
    <dc:creator>Alexey Gladkov</dc:creator>
    <dc:date>2012-05-14T15:31:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/84000">
    <title>systemd status or let's officially start pottering sisyphus</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/84000</link>
    <description>&lt;pre&gt;Hi,

в связи с обеспечением полноценной поддержки systemd в Sisyphus в свете 
подготовки p7 (http://bit.ly/ITVckO) хотелось бы сформулировать текущие 
ориентиры:
1) Как минимум все desktop-дистрибутивы на p7 будут выпускаться на 
systemd. Это означает, что требуется упаковка unit-файлов для всех 
сервисов. Просьба при сборке новых версий пакетов паковать unit-файлы, 
которые в большинстве своём можно брать в Fedora 
(http://pkgs.fedoraproject.org/gitweb/) и добавлять поддержку systemd. В 
случае проблем, как тут уже объявлялось, поддержку брались оказывать 
shaba&amp;lt; at &amp;gt; и amike&amp;lt; at &amp;gt;, можете обращаться и ко мне. В ближайшее время, как мне 
кажется, требуется добавить warning при сборке пакетов, содержащих 
init-скрипт и не содержащих одноимённый unit-файл. В будущем его стоит 
сделать error.

2) Поддержка sysvinit для серверных применений пока сохраняется, 
желательно сохранять работоспособность подобных систем без systemd. Т.е. 
не стоит выбрасывать init-скрипты и специально создавать сложности. 
Иногда, однако, эти сложности неизбежны как, к примеру, в случае с 
polkit. В таких случаях, видимо, предпочтение следует отдавать systemd.

3) Полноценные десктопные системы без systemd, видимо, работать уже не 
будут.

4) В настоящее время systemd уже не работает нормально на ядрах 2.6.32 
(как минимум, на el-smp). el-smp, видимо, останется в p6, в p7 
выпускаться дистрибутивы на нём не будут.

Все пожелания/предложения приветствуются.

_______________________________________________
Devel mailing list
Devel&amp;lt; at &amp;gt;lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel&lt;/pre&gt;</description>
    <dc:creator>Vitaly Kuznetsov</dc:creator>
    <dc:date>2012-05-14T15:17:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83984">
    <title>exclusive acl &amp; bugs</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83984</link>
    <description>&lt;pre&gt;Hi,

у нас есть пакеты с эксклюзивным acl. Также у на есть баги на такие 
пакеты и на них зачастую отсутствует какая бы то ни была реакция в 
bugzilla в течение длительного времени. Не стоит ли считать подобное 
стечение обстоятельств поводом к добавлению в acl пакета &amp;lt; at &amp;gt;qa/&amp;lt; at &amp;gt;everybody? 
Вполне возможно, что существуют готовые зафиксить соответствующий баг 
люди, но эксклюзивный acl их останавливает.

_______________________________________________
Devel mailing list
Devel&amp;lt; at &amp;gt;lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel&lt;/pre&gt;</description>
    <dc:creator>Vitaly Kuznetsov</dc:creator>
    <dc:date>2012-05-12T07:43:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83983">
    <title>I: linux/ext2_fs.h is no more</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83983</link>
    <description>&lt;pre&gt;Hi,

После обновления glibc-kernheaders пакеты, использующие linux/ext2_fs.h,
перестали собираться, потому что linux/ext2_fs.h перестал
компилироваться.

Я не буду исправлять linux/ext2_fs.h, поскольку апстрим решил со
следующей версии ядра (&amp;gt;= 3.4) не экспортировать этот файл:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=v3.3-9234-g4a165d2

Немногочисленным пакетам, еще использующим linux/ext2_fs.h (socat,
syslinux, syslinux4), рекомендуется перейти на ext2fs/ext2_fs.h из
пакета libe2fs-devel.


&lt;/pre&gt;</description>
    <dc:creator>Dmitry V. Levin</dc:creator>
    <dc:date>2012-05-11T22:19:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83974">
    <title>I: kernel-headers-alsa is no more</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83974</link>
    <description>&lt;pre&gt;Hi,

Пакет kernel-headers-alsa давно устарел, и с обновлением пакета
kernel-headers-common прекратил свое существование.

Два пакета (kdemultimedia-3.5.13-alt2 и sox-14.3.2-alt1) из-за этого
перестанут собираться, просьба обновить в этих пакетах сборочные
зависимости.


&lt;/pre&gt;</description>
    <dc:creator>Dmitry V. Levin</dc:creator>
    <dc:date>2012-05-11T11:59:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83973">
    <title>I: linux/videodev.h is no more</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83973</link>
    <description>&lt;pre&gt;Hi,

Файла /usr/include/linux/videodev.h уже давно нет:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=v2.6.37-rc8-178-g88ae762

С обновлением пакета glibc-kernheaders #include &amp;lt;linux/videodev.h&amp;gt;
перестанет работать, и примерно два десятка пакетов из-за этого
перестанут собираться:

asterisk1.11-1.11-alt0.337970
fmio-2.0.8-alt2.1
hal-0.5.14-alt8
kdenetwork-3.5.13-alt1
libdc1394-2.1.3-alt1.1
libpw1.11-1.11.2-alt0.9cvs20061011.1
libunicap-0.9.8-alt3
linuxtv-dvb-apps-1.1.1-alt2
mjpegtools-1.9.0-alt4
motion-3.2.12-alt2.3
mpfc-radio-0.1-alt2
python-module-pygame-1.9.1-alt1.1.1
qutecom-2.2.1-alt3.1
spcaview-20071224-alt1
tvtime-1.0.2-alt12
v4l2ucp-2.0.2-alt1
webcam-tools-0.2.1-alt1.svn2011021201
xmms-fmradio-1.5-alt1.qa1
zbar-0.10-alt4.1


&lt;/pre&gt;</description>
    <dc:creator>Dmitry V. Levin</dc:creator>
    <dc:date>2012-05-11T11:56:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83972">
    <title>systemd policy - different names for systemd and sysV.</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83972</link>
    <description>&lt;pre&gt;Господа,
когда имя systemd сервиса отличается от имени sysV init скрипта,
возникает вопрос, что писать в %post/un_service &amp;lt;name&amp;gt;.

Естественно, хочется писать в %post/un_service 
имя sysV init скрипта.

Если сделать симлинк systemd сервиса с sysV init именем,
например, bluetoothd.service -&amp;gt; bluetooth.service
service &amp;lt;sysV init имя&amp;gt; start/stop работать будет.

Проблема в том, что chkconfig &amp;lt;sysV init имя&amp;gt; on / off
не работает, даже если есть симлинк, поскольку эта функциональность
считается неправильной в systemctl.

Это плохо, так как не позволяет писать скрипты, одинаково
работающие хоть под sysV init, хоть под systemd.

Однако нам ничто не мешает пропатчить chkconfig,
чтобы он разрешал симлинк в настоящее имя systemd сервиса.

Пример такого достаточно тривиального патча к chkconfig
приложен в аттачменте (chkconfig-2.patch).

Предлагаю патчить chkconfig (не обязательно предложенным патчем)
так как иначе придется переименовывать sysV init скрипты,
а это 
1) будут замусорены сотни спеков
2) сотни спеков будут замусорены как правило некорректным
кодом, который еще надо тщательно тестировать, чтобы он не
сломал обновление.

Ведь при переименовании, если не проследить,
может поменяться имя pid файла, и вообще у нас при переименовании 
нет condrestart, а есть только &amp;lt;старое имя&amp;gt; stop
и &amp;lt;новое имя&amp;gt; start, и универсальный триггер для condrestart при
переименовании, использование которого можно было бы рекомендовать
в полиси, вряд ли получится написать. Нужно будет смотреть 
в каждый sysV init скрипт индивидуально.
И все ли смогут сделать это корректно?

&lt;/pre&gt;</description>
    <dc:creator>Igor Vlasenko</dc:creator>
    <dc:date>2012-05-11T11:16:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83967">
    <title>[alterator] синхронность activity</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83967</link>
    <description>&lt;pre&gt;Здравствуйте.
Помогите сняться с ручника:

(extra-button (when clicked
                (begin
                  (format #t "HERE1\n")
                  (extra-button activity #f)
                  (form-update-activity '("extra-button") #f)
                  (format #t "HERE2\n")
                  (commit-interface)
                  (format #t "HERE3\n")
                  )))

Кнопка деактивируется уже после возврата commit-interface,
которое представляет из себя ходока в бэкенд:

(define (commit-interface)
  (catch/message
    (lambda()
      (woo-write "/backend" 'var (form-value "var")))))

Т.е. в выводе наблюдаю:

HERE1
HERE2
[выполнение команд бэкендом]
HERE3

...и при этом на HERE2 extra-button нажимабельная,
а после HERE3 -- уже нет.

&lt;/pre&gt;</description>
    <dc:creator>Michael Shigorin</dc:creator>
    <dc:date>2012-05-11T04:38:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83951">
    <title>Упаковка django приложений</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83951</link>
    <description>&lt;pre&gt;Здравствуйте.

Есть django приложение www.cdr-stats.org
Дело в том, что это питоновские модули и естественно они должны
располагаться в /usr/lib/python2.7/site-packages/. Но после установки
нужно запустить серию команд:

    python manage.py syncdb --noinput
    python manage.py migrate
    python manage.py createsuperuser
    python manage.py collectstatic -l --noinput

Которые прямо в этой директории создают базу, статические ссылки и т.д.
Хочется чтобы модули были отдельно, а все данные и т.д. отдельно где-то
в районе /var/lib или /var/www
Подскажите, как правильно упаковывать django приложения?
Это зависит от настроек самого приложения или может есть типичный пример?

&lt;/pre&gt;</description>
    <dc:creator>Dubrovskiy Viacheslav</dc:creator>
    <dc:date>2012-05-10T04:58:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83948">
    <title>srpmbackport in perl-RPM-Source-Editor</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83948</link>
    <description>&lt;pre&gt;5 мая 2012 г., 21:46 пользователь Igor Vlasenko
&amp;lt;vlasenko&amp;lt; at &amp;gt;imath.kiev.ua&amp;gt; написал:


Кажется, в этом пакете когда-то еще имелась утилита srpmbackport -
куда она подевалась?

&lt;/pre&gt;</description>
    <dc:creator>Eugene Prokopiev</dc:creator>
    <dc:date>2012-05-10T03:21:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83934">
    <title>python-module-matplotlib</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83934</link>
    <description>&lt;pre&gt;День добрый. С праздником!

Скажите, это нормально, что из коробки не получается ничего толком импортировать из matplotlib:

16:17&amp;gt;&amp;gt;&amp;gt; from matplotlib.figure import Figure
Traceback (most recent call last):
  File "&amp;lt;stdin&amp;gt;", line 1, in &amp;lt;module&amp;gt;
  File "/usr/lib64/python2.7/site-packages/matplotlib/__init__.py", line 135, in &amp;lt;module&amp;gt;
    from matplotlib.rcsetup import (defaultParams,
  File "/usr/lib64/python2.7/site-packages/matplotlib/rcsetup.py", line 19, in &amp;lt;module&amp;gt;
    from matplotlib.colors import is_color_like
  File "/usr/lib64/python2.7/site-packages/matplotlib/colors.py", line 52, in &amp;lt;module&amp;gt;
    import numpy as np
  File "/usr/lib64/python2.7/site-packages/numpy/__init__.py", line 137, in &amp;lt;module&amp;gt;
    import add_newdocs
  File "/usr/lib64/python2.7/site-packages/numpy/add_newdocs.py", line 9, in &amp;lt;module&amp;gt;
    from numpy.lib import add_newdoc
  File "/usr/lib64/python2.7/site-packages/numpy/lib/__init__.py", line 13, in &amp;lt;module&amp;gt;
    from polynomial import *
ImportError: No module named polynomial
16:17&amp;gt;&amp;gt;&amp;gt; from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg
Traceback (most recent call last):
  File "&amp;lt;stdin&amp;gt;", line 1, in &amp;lt;module&amp;gt;
  File "/usr/lib64/python2.7/site-packages/matplotlib/__init__.py", line 135, in &amp;lt;module&amp;gt;
    from matplotlib.rcsetup import (defaultParams,
  File "/usr/lib64/python2.7/site-packages/matplotlib/rcsetup.py", line 19, in &amp;lt;module&amp;gt;
    from matplotlib.colors import is_color_like
  File "/usr/lib64/python2.7/site-packages/matplotlib/colors.py", line 52, in &amp;lt;module&amp;gt;
    import numpy as np
  File "/usr/lib64/python2.7/site-packages/numpy/__init__.py", line 137, in &amp;lt;module&amp;gt;
    import add_newdocs
  File "/usr/lib64/python2.7/site-packages/numpy/add_newdocs.py", line 9, in &amp;lt;module&amp;gt;
    from numpy.lib import add_newdoc
  File "/usr/lib64/python2.7/site-packages/numpy/lib/__init__.py", line 13, in &amp;lt;module&amp;gt;
    from polynomial import *
ImportError: No module named polynomial
16:18&amp;gt;&amp;gt;&amp;gt; from matplotlib import rc
Traceback (most recent call last):
  File "&amp;lt;stdin&amp;gt;", line 1, in &amp;lt;module&amp;gt;
  File "/usr/lib64/python2.7/site-packages/matplotlib/__init__.py", line 135, in &amp;lt;module&amp;gt;
    from matplotlib.rcsetup import (defaultParams,
  File "/usr/lib64/python2.7/site-packages/matplotlib/rcsetup.py", line 19, in &amp;lt;module&amp;gt;
    from matplotlib.colors import is_color_like
  File "/usr/lib64/python2.7/site-packages/matplotlib/colors.py", line 52, in &amp;lt;module&amp;gt;
    import numpy as np
  File "/usr/lib64/python2.7/site-packages/numpy/__init__.py", line 137, in &amp;lt;module&amp;gt;
    import add_newdocs
  File "/usr/lib64/python2.7/site-packages/numpy/add_newdocs.py", line 9, in &amp;lt;module&amp;gt;
    from numpy.lib import add_newdoc
  File "/usr/lib64/python2.7/site-packages/numpy/lib/__init__.py", line 13, in &amp;lt;module&amp;gt;
    from polynomial import *
ImportError: No module named polynomial
16:18&amp;gt;&amp;gt;&amp;gt; import matplotlib
Traceback (most recent call last):
  File "&amp;lt;stdin&amp;gt;", line 1, in &amp;lt;module&amp;gt;
  File "/usr/lib64/python2.7/site-packages/matplotlib/__init__.py", line 135, in &amp;lt;module&amp;gt;
    from matplotlib.rcsetup import (defaultParams,
  File "/usr/lib64/python2.7/site-packages/matplotlib/rcsetup.py", line 19, in &amp;lt;module&amp;gt;
    from matplotlib.colors import is_color_like
  File "/usr/lib64/python2.7/site-packages/matplotlib/colors.py", line 52, in &amp;lt;module&amp;gt;
    import numpy as np
  File "/usr/lib64/python2.7/site-packages/numpy/__init__.py", line 137, in &amp;lt;module&amp;gt;
    import add_newdocs
  File "/usr/lib64/python2.7/site-packages/numpy/add_newdocs.py", line 9, in &amp;lt;module&amp;gt;
    from numpy.lib import add_newdoc
  File "/usr/lib64/python2.7/site-packages/numpy/lib/__init__.py", line 13, in &amp;lt;module&amp;gt;
    from polynomial import *
ImportError: No module named polynomial

доустановка python-module-numpy-addons нормализует ситуацию.

&lt;/pre&gt;</description>
    <dc:creator>Terechkov Evgenii</dc:creator>
    <dc:date>2012-05-09T08:37:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.altlinux.devel/83922">
    <title>сборка только для i586 и x86_64</title>
    <link>http://comments.gmane.org/gmane.linux.altlinux.devel/83922</link>
    <description>&lt;pre&gt;Hi!

Я тут заметил что мой пакет pommed собирает и для arm архитектуры, но
это не имеет смысла. Так как это утилиты для руления всякими фичами
Apple техники. А они никогда не выпускали ничего на арме.

В общем вопрос: что добавить в спек что бы собиралось только для x86/x86_64?

Заранее спасибо!

&lt;/pre&gt;</description>
    <dc:creator>Igor Zubkov</dc:creator>
    <dc:date>2012-05-07T16:13:55</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.altlinux.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.altlinux.devel</link>
  </textinput>
</rdf:RDF>

