Re: Убрать /etc/mtab -> /proc/mounts [was: количество смонтированных устройств]

31.01.2012 19:58, Dubrovskiy Viacheslav пишет:
> 31.01.2012 04:38, Dmitry V. Levin пишет:
>>>>>> В mtab должны отображаться все смонтированные FS. snmp пытается
>>>>>> показать даже те FS, к которым не имеет доступа и
из-за этого 
>>>>>> глючит. 
>>>>>>
>>>>>> Очевидно надо править кривой софт, а не ломать систему.
>>>>>  
>>>>> Давайте тогда править всё, начиная с df. 
>>>>>
>>>>> $ df
>>>>> df: `/var/lib/vz/root/03164': Permission denied
>>>>> df: `/var/lib/vz/root/03164/sys': Permission denied
>>>>> df: `/var/lib/vz/root/03165': Permission denied
>>>>> df: `/var/lib/vz/root/03165/sys': Permission denied
>>>> А что из вышеприведенного нуждается в исправлении?
>>> Исходя из логики "править кривой софт", то
исправлять нужно df, чтобы он
>>> не пытался лезть туда куда нет прав и не сыпал ошибками.
>> Это ведь настоящие, а не надуманные какие-то ошибки. 
Почему df должен их
>> скрывать?
> Потому что предполагалось что туда он не должен
ходить. И он исправно
> ориентировался на /etc/mtab.
> А его обманули, подсунув ссылку где все без разбора,
вот он тоже
> оказался не готов и сыпет ошибками.
> И согласитесь, что ошибки это плохо и сознательно

Re: Q: personal package repositories: user PoV

On Sat, Jan 28, 2012 at 04:19:39AM +0400, Dmitry V. Levin wrote:
> 3. Добавление к NSVR пакета еще одной характеристики B.  Автоматическое
> увеличение этой характеристики самой сборочной
системой при каждой
> пересборке пакета.  Сквозная адаптация всех
инструментальных средств на
> стороне пользователя (в первую очередь apt и rpm) для
учета этой
> характеристики B при обработке пакетов.  Тут
возможны различные варианты.
> Можно включать эту характеристику в имя файла
собранного пакета, а можно
> этого не делать.  Можно включать эту характеристику в пользовательские
> интерфейсы выбора пакета (например, чтобы можно
было указать ее для
> уточнения пакета при вызове apt-get и rpm), а можно этого не делать.
> Наконец, можно придумать для этой характеристики B
какой-то новый тэг rpm,
> а можно попробовать адаптировать какой-нибудь из
уже существующих.
> Чем больше будет таких мест, где сможет/будет
фигурировать B, тем больше
> рычагов управления будет у пользователя, с одной
стороны, и тем сложнее
> будет реализация и хуже обратная совместимость, с
другой стороны.
> 
> 4. На самом деле в rpm уже есть один тэг, который годится
на роль такой
> характеристики B.  Более того, значение этого тэга уже сейчас

Re: Q: personal package repositories: user PoV

On Wed, Feb 01, 2012 at 09:47:47PM +0400, Alexey Tourbin wrote:
> On Sat, Jan 28, 2012 at 04:19:39AM +0400, Dmitry V. Levin wrote:
> > 3. Добавление к NSVR пакета еще одной характеристики B.  Автоматическое
> > увеличение этой характеристики самой сборочной
системой при каждой
> > пересборке пакета.  Сквозная адаптация всех
инструментальных средств на
> > стороне пользователя (в первую очередь apt и rpm) для
учета этой
> > характеристики B при обработке пакетов.  Тут
возможны различные варианты.
> > Можно включать эту характеристику в имя файла
собранного пакета, а можно
> > этого не делать.  Можно включать эту характеристику
в пользовательские
> > интерфейсы выбора пакета (например, чтобы можно
было указать ее для
> > уточнения пакета при вызове apt-get и rpm), а можно этого не делать.
> > Наконец, можно придумать для этой характеристики B
какой-то новый тэг rpm,
> > а можно попробовать адаптировать какой-нибудь из
уже существующих.
> > Чем больше будет таких мест, где сможет/будет
фигурировать B, тем больше
> > рычагов управления будет у пользователя, с одной
стороны, и тем сложнее
> > будет реализация и хуже обратная совместимость, с
другой стороны.
> > 
> > 4. На самом деле в rpm уже есть один тэг, который годится

Re: Q: personal package repositories: user PoV

On Wed, Feb 01, 2012 at 10:57:58PM +0400, Dmitry V. Levin wrote:
> > Результат сборки пакетов не должен зависеть от
модельного времени t,
> > а должен зависеть только от ингредиентов, которые
напрямую влияют на
> > результат сборки.  Таких ингредиентов два: B(S,C)->P, где
S - исходный
> > код пакета, C - содержимое сборочного чрута.
> 
> Время t тоже напрямую (через такие интерфейсы как
gettimeofday(2)) может
> влиять на результат сборки.  Но суть не в этом.
> 
> > Представление о времени в зависимостях вообще
нерелевантно, и должно быть
> > исключено.  Например, если где-то требуется
библиотечная функция foo(),
> > то должен быть способ представить зависимость на
функцию foo() - и такой
> > способ сейчас существует.  А если кому-то нужна
библиотека не хуже 17 мартобря,
> > освященная духом святым - это другое дело.
> > 
> > Смысла характеристики B никакой нету, кроме
привязки к модельному времени.
> 
> Речь идет вообще не о зависимостях, а об обновлении
собранных пакетах
> как таковых.
> Если один и тот же исходный пакет был собран

I: Sisyphus-20120202 packages: +5! -7 +155 (12888)

День добрый!

	7 REMOVED packages
...
plasma-applet-icontasks	0.9.2-alt1
...

You have been engaged in ACL change(s) initiated by Girar Administrator:
plasma-applet-icontasks: "ogion @everybody" -> DELETED

Что это было и по какому поводу?

--

-- 
Всего доброго,

Денис.
_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel

Re: I: Sisyphus-20120202 packages: +5! -7 +155 (12888)

День добрый!

>        7 REMOVED packages
> ...
> plasma-applet-icontasks 0.9.2-alt1
> ...
>
> You have been engaged in ACL change(s) initiated by Girar Administrator:
> plasma-applet-icontasks: "ogion @everybody" -> DELETED
>
>
> Что это было и по какому поводу?

Всё, разобрался. Но хоть бы написали перед тем, как
удалять, что для
KDE-4.8 этот пакет больше не требуется. А то получаю
сообщение, что
пакет удалён, и никаких комментариев. Потратил час
рабочего времени
пытаясь собрать ещё раз и в конце обнаружил, что пакет
с таким именем
уже есть, и получается он из kde4plasma-addons.

--

-- 
Всего доброго,

Денис.
_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org

I: apache2-2.2.22-alt1

Приветствую.

  apache2-2.2.22-alt1 добрался таки до Сизифа (см.
<http://git.altlinux.org/tasks/archive/done/_62/63724/logs/events.3.3.log>).
Если до понедельника не будет к нему замечаний -- его
аналоги уйдут в
бранчи.

--

-- 

С уважением. Алексей.

_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel

I: local pocket rebuild scripts

Господа,

Заскриптовал у себя тестирование пакетов перед
отправкой в Сизиф
пересборкой в локальном кармане.

Принцип работы следующий.
Набрались в ~/hasher пакеты, которые хотим
протестировать 
перед отправкой в Сизиф - переносим каждый пакет с его бинарниками
в папочку rebuild. для каждого пакета форкаем Сизиф,
вытестняем из форка старую версию пакета и
генерируем индексы apt -- 
получаем local pocket c этим пакетом.
В полученном local pocket пересобираем с новым пакетом
все пакеты, в сборочное окружение которых
вытягивался тестируемый 
пакет и сохраняем логи пересборки.
Пересборка идет с другим hasher subconfig identifier,
чтобы не мешать работе.
По итогам пересборок принимаем решение об отправке в Сизиф.

Мне это нужно для java, где каждое обновление - русская рулетка.
Если кому-то еще будет интересно, буду причесывать,
чтобы выложить в общее пользование.

--
Dr. Igor Vlasenko
--------------------
Topology Department

java: куда идем мы с Пятачком

Коллеги,

С начала года я плотно занялся java репозиторием.
За январь залил более 200 пакетов обновлений и починки; 
это как бы и много, но по сравнению с 1000-пакетным 
java репозиторием это только шаг.

Какие наиболее важные задачи для java репозитория
видятся в 2012 году.

1) переезд с java5/java6 сборки на java6/java7 сборку.

2) переезд на maven3.

Для 1) надо окончательно избавиться от java5-only пакетов,
наиболее сложная задача здесь обновить jboss до 5-й версии.
после чего можно будет выложить в репозиторий java7 
и собирать java7 c -source/-target 6.

2-е - переезд на maven3 -- более сложная задача.
Чистый maven -- online-сборщик, чтобы он работал offline,
есть патчи от JPackage для maven2 и от Fedora для maven3.
При этом они не совместимы по синтаксису.
В Fedora при переезде на maven3 просто переписали свои спеки;
народу там побольше, а пакетов поменьше.

У нас же около 400 пакетов собираются maven2. Переписывать их
спеки - работа египетская. Поэтому буду искать способ допилить
maven3 до совместимости с maven2 от JPackage.

Re: java: куда идем мы с Пятачком

02.02.2012 20:47, Igor Vlasenko пишет:
> Коллеги,
> 
> С начала года я плотно занялся java репозиторием.
> За январь залил более 200 пакетов обновлений и
починки; 
> это как бы и много, но по сравнению с 1000-пакетным 
> java репозиторием это только шаг.
> 
> Какие наиболее важные задачи для java репозитория
видятся в 2012 году.
> 
> 1) переезд с java5/java6 сборки на java6/java7 сборку.
> 
> 2) переезд на maven3.
> 
> Для 1) надо окончательно избавиться от java5-only пакетов,
> наиболее сложная задача здесь обновить jboss до 5-й версии.
> после чего можно будет выложить в репозиторий java7 
> и собирать java7 c -source/-target 6.
> 
> 2-е - переезд на maven3 -- более сложная задача.
> Чистый maven -- online-сборщик, чтобы он работал offline,
> есть патчи от JPackage для maven2 и от Fedora для maven3.

  А не проще/лучше ли обмануть сборщик, чтобы он думал,
что он online, а
по факту, вместо сети файлы брались бы из пакетов?

> При этом они не совместимы по синтаксису.