Created attachment 7062 [details]
gpg публичный ключ

(In reply to comment #0)
> Created an attachment (id=7061)

Ok.

(In reply to comment #1)
> Created an attachment (id=7062)

Ok.

(В ответ на комментарий №0)
> имя ментора: Михаил Шигорин
Подтверждаю.

> Внезапно понял, что это моё. Хочу собирать пакеты для учебных направлений.
Ура :-)

ssh ключ на gitery.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 3.0.

(В ответ на комментарий №4)
> ssh ключ на gitery.alt зарегистрирован.
> Адрес для пересылки создан.
> 
> T/J/S -> 3.0.

Подключился. Создал папку. Полазил по другим папкам, посмотрел разные команды и возможности. Закачал проект. Прав на сборку пока нет?

(In reply to comment #5)
> Прав на сборку пока нет?

Да, на этой стадии ещё нет прав на сборку.  Момент выдачи таких прав определяет ментор по мере готовности пакетов (см. Team/Join/Secretary п. 3).

Если идёт работа на пакетом ruleuser, то в файл ChangeLog.ru не надо ничего дописывать: это — наследие, список изменений сделанных до того, как пакет был сымпорчен в Сизиф. Писать об изменениях нужно в секцию %changelog в spec-файле.

Файла ruleuser.tar не должно быть в репозитории; тарболл автоматически сгенерится на основе правил, написанных в файле .gear/rules, который как раз-таки почему-то отсутствует в репозитории :)

Добавил .gear/rules
убрал changelog файл

Я всё правильно сделал?
Я должен сейчас что-то ещё сделать? Или просто ждать проверку?

Да, сейчас надо добраться и проверить (с чем у меня традиционные затыки); рекомендую прислушаться к советам vseleznv@.

На какой стадии процедуры мы находимся?

(В ответ на комментарий №11)
> На какой стадии процедуры мы находимся?
mentor timeout по моей стороне был :-/

Если кто может подстраховать отсмотром пакета, буду сильно благодарен.

Я готов заменить Мишу

(В ответ на комментарий №9)
> Я всё правильно сделал?
> Я должен сейчас что-то ещё сделать? Или просто ждать проверку?
Артём, Вы ещё не разуверились в нас?..

(В ответ на комментарий №13)
> Я готов заменить Мишу
Спасибо!!  Посмотри этот репозиторий:
http://git.altlinux.org/people/tema/packages/?p=ruleuser.git;a=summary

Верните мне, пожалуйста, адрес tema@altlinux.org
Он мне сейчас очень нужен.

У меня сложилось ощущение, что кандидат фактически прекратил процедуру вступления ещё в 2017 году.

Артём, Вы ещё собираетесь вступать в тим?

Я сменил форму трудоустройства в школе. Сейчас я учитель по совместительству и могу снова работать над пакетами. Хочу продолжить вступление, по возможности.

Имя ментора:
Антон Мидюков (https://bugzilla.altlinux.org/show_bug.cgi?id=33388#c13)

Пакеты, которые хочу собрать в репозиторий для начала (в основном образовательные для школы):
https://github.com/temaps/qtSimpleGraph
https://github.com/temaps/qtSimpleGraphPy
https://github.com/temaps/staj
https://github.com/temaps/Vesi
https://github.com/temaps/Xerox-6515
https://clonezilla.org/

С 2017 года много воды утекло, поэтому, в соответствии с действующим регламентом, просьба названного ментора подтвердить или опровергнуть, что он действительно является активным ментором для кандидата.

(Ответ для Dmitry V. Levin на комментарий #19)
> С 2017 года много воды утекло, поэтому, в соответствии с действующим
> регламентом, просьба названного ментора подтвердить или опровергнуть, что он
> действительно является активным ментором для кандидата.

Немного подумав, решили, что Артёму удобнее, чтобы его ментором был Михаил Новосёлов mikhailnov@
Я его подписал на багу. Ждём от него подтверждение.

Подтверждаю

(In reply to Артём from comment #18)
> Хочу продолжить вступление, по возможности.

Приложенные к багу ssh- и gpg- ключи актуальны?

(Ответ для Gleb F-Malinovskiy на комментарий #22)
> (In reply to Артём from comment #18)
> > Хочу продолжить вступление, по возможности.
> 
> Приложенные к багу ssh- и gpg- ключи актуальны?

ssh актуален, а gpg привязывался к tema@altlinux.org сейчас, наверное, я его не найду в архивах
Я сейчас переделаю gpg

Created attachment 10071 [details]
Новый публичный ключ gpg

$ ssh git.alt find-package ruleuser
ssh: git_tema@gitery.altlinux.org: Permission denied (publickey).

Мой ssh ключ заблокирован? Давно? Полгода назад я даже push в git делал :-(

(In reply to Артём from comment #24)
> Created attachment 10071 [details]
> Новый публичный ключ gpg

Ok.

Кандидат готов к переходу на следующий этап. Т.к. ходить по ssh он умеет, пора учиться собирать пакеты.

Доступ к gitery.alt и адрес пересылки почты восстановлены.

T/J/S -> 2.3.

Есть какой-то прогресс?

(Ответ для Gleb F-Malinovskiy на комментарий #29)
> Есть какой-то прогресс?

Конечно!
Я собрал уже очень много пакетов. Ментору большое спасибо, отвечает на все возникающие вопросы. Подсоберу всё, чему научился в ближайшее время и запушу в гит альта.

https://git.altlinux.org/people/tema/packages/?p=qt5-base.git;a=commit;h=c8b1bcfcf0817eee940230ba22255523b346b55c
Важное исправление. Починили в школах тачскрин. Баг был прямо критический.
Тестируем и будем раскидывать по панелям. В пакеты собрал с помощью rpmbs и hsh

https://git.altlinux.org/people/tema/packages/?p=podiff.git;a=summary
Полезная утилита :-)

Кандидат готов к переходу на следующий этап — тренировке собирать пакеты в сборочнице.

https://git.altlinux.org/people/tema/packages/?p=qt5-base.git;a=commitdiff;h=5db5d63afe96b0d2492af7b0d8d76a33c41de018

Вот тут очень хорошо, что есть подробное описание, что и зачем делает патч, но искать описание в сообщении коммита не самый очевидный путь, его нагляднее вставить в патч, но тогда редиффать патч будет сложнее (если его вообще придется редиффать в заброшенном Qt5). Лучше согласовать с zerg-ом.

И еще надо бы обязательно указать ссылки на баг в Qt и источник патча в их gerrit.

(In reply to mikhailnov from comment #34)
> https://git.altlinux.org/people/tema/packages/?p=qt5-base.git;a=commitdiff;
> h=5db5d63afe96b0d2492af7b0d8d76a33c41de018
> 
> Вот тут очень хорошо, что есть подробное описание, что и зачем делает патч,
> но искать описание в сообщении коммита не самый очевидный путь, его
> нагляднее вставить в патч, но тогда редиффать патч будет сложнее (если его
> вообще придется редиффать в заброшенном Qt5). Лучше согласовать с zerg-ом.

Извините, если в патч вставить его описание, то в чём сложность редиффать патч?

(Ответ для Vladimir D. Seleznev на комментарий #36)
> Извините, если в патч вставить его описание, то в чём сложность редиффать
> патч?

git diff > file или diff <...> > file затрет описание, неоднократно наблюдал такое

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.

T/J/S -> 3.5.

https://git.altlinux.org/tasks/300971/
Вроде всё сделал по канонам :-)

(In reply to Артём from comment #39)
> https://git.altlinux.org/tasks/300971/
> Вроде всё сделал по канонам :-)

37 %changelog
38 * Wed Apr 20 2022 Artem Proskurnev <tema@altlinux.org> 1.3-alt1
39 - new version (1.3) with rpmgs script

Вот тут же не new version, а initial build for Sisyphus.

Апстримный код смешан со спеком, своим readme зачем-то (зачем?), непонятно, может, ты черте откуда код взял.

Я бы отдельным коммитом загрузил код (желательно указав хеш-сумму тарболла и ссылку на него в сообщении коммита, пропустив одну строку после заголовка, но тут скрипт rpmgs качает его, не знаю, удобно ли будет считать хеш), потом .gear и спек отдельным коммитом.

Свой readme никто читать не будет. В спеке %description вместо него.

https://git.altlinux.org/tasks/301015/
Учёл замечания в другом пакете.

(Ответ для Артём на комментарий #41)
> https://git.altlinux.org/tasks/301015/
> Учёл замечания в другом пакете.

Тут тоже есть, к чему придраться))

> # Source-url:   https://github.com/migashko/faslib/archive/refs/tags/0.9.4.tar.gz

Тут, наверное, имелось в виду %version вместо конкретной версии

> %setup -q -n %name-%version
Это эквивалентно "%setup -q" без -n (но -n не мешает, может, так нагляднее)

> Summary: Aspect-oriented programming on native C++
грамматически правильнее in, а не on.

Пакет из только заголовочных файлов - это плохо, т.к. при изменениях в нем не поймаются пакеты, которые нужно пересобрать из-за слома API/ABI, но что поделать.

В целом все нормально, когда будешь упаковывать не только лишь заголовочные файлы, а нормальную библиотеку, вот там порезвимся.

И история коммитов не очень чистая.

https://git.altlinux.org/tasks/301015/gears/100/git?p=git;a=commitdiff;h=f48d13d577c57491c22fec463b375995fb9eba65

Этот коммит не про добавление Russian summary.

Исправил:
https://git.altlinux.org/tasks/301022/

(Ответ для mikhailnov на комментарий #40)
> (In reply to Артём from comment #39)
> > https://git.altlinux.org/tasks/300971/
> > Вроде всё сделал по канонам :-)
> 
> 37 %changelog
> 38 * Wed Apr 20 2022 Artem Proskurnev <tema@altlinux.org> 1.3-alt1
> 39 - new version (1.3) with rpmgs script
> 
> Вот тут же не new version, а initial build for Sisyphus.
> 
> Апстримный код смешан со спеком, своим readme зачем-то (зачем?), непонятно,
> может, ты черте откуда код взял.
> 
> Я бы отдельным коммитом загрузил код (желательно указав хеш-сумму тарболла и
> ссылку на него в сообщении коммита, пропустив одну строку после заголовка,
> но тут скрипт rpmgs качает его, не знаю, удобно ли будет считать хеш), потом
> .gear и спек отдельным коммитом.
> 
> Свой readme никто читать не будет. В спеке %description вместо него.

Переделал
https://git.altlinux.org/tasks/301070/
Про хешсумму: тут же rpmgs. Можно, конечно, и ещё вручную скачать и сумму посчитать, но это лишнее действие получается и мы отбираем работу у скрипта.

Учёл все-все-все требования своего мучителя (ментора+учителя :-) ), всё исправил, отправил на сборку:
https://git.altlinux.org/tasks/302534/

(Ответ для Артём на комментарий #46)
> Учёл все-все-все требования своего мучителя (ментора+учителя :-) ), всё
> исправил, отправил на сборку:
> https://git.altlinux.org/tasks/302534/
Поправочка:
https://git.altlinux.org/tasks/302538/

И этот тоже:
https://git.altlinux.org/tasks/302540/

(Ответ для Артём на комментарий #47)
> (Ответ для Артём на комментарий #46)
> > Учёл все-все-все требования своего мучителя (ментора+учителя :-) ), всё
> > исправил, отправил на сборку:
> > https://git.altlinux.org/tasks/302534/
> Поправочка:
> https://git.altlinux.org/tasks/302538/

Это задание со smartcar и задание https://git.altlinux.org/tasks/302540/ с podiff собраны кандидатом, одобрены мною и ушли в сизиф.
Кандидату пока еще приходится напоминать, что нужно делать качественно и читаемо, но он успешно делает историю git читаемой, а сборки пакетов качественными.
В целом считаю его готовым к переходу в самостоятельное плавание. При необходимости обратится за помощью.

У кандидата два пакета были отправлены в репозиторий в ужасном состоянии.
https://packages.altlinux.org/ru/tasks/313797/
и 
https://packages.altlinux.org/ru/tasks/313797/

Пакетам в таком состоянии и с такой реализацией не место в репозитории и соответственно у меня возникает вопрос к тому, кто делал их review.

Второе задание, к содержимому которого и к необходимости его наличия в репозитории есть вопросы:
https://packages.altlinux.org/ru/tasks/313729/

(Ответ для Anton Farygin на комментарий #50)
> У кандидата два пакета были отправлены в репозиторий в ужасном состоянии.
> https://packages.altlinux.org/ru/tasks/313797/
> и 
> https://packages.altlinux.org/ru/tasks/313797/
> 
> Пакетам в таком состоянии и с такой реализацией не место в репозитории и
> соответственно у меня возникает вопрос к тому, кто делал их review.

В целом в глубине души не могу не согласиться, что написанные на коленке скрипты без даже правильных кодов возврата и должных проверок хорошая идея отправлять в репозиторий, но во время ревью этот скрипт был избавлен от хотя бы самых критичных недостатков (это видно по истории git, все коммиты после первого были сделаны кандидатом после ревью ментора).
Вопрос целесообразности наличия такой утилиты считаю вне компетенции ментора, да и вообще кого-либо, кроме ее автора, до тех пор, пока она не мешает кому-либо (мешать может при конфликте с другими пакетами, если это кривой патч в ранее существовавший пакет и т.д.).
Задачей ментора вижу помочь и/или заставить привести подобные творения в хотя бы минимально работоспособный вид, например, чтобы скрипт не писал, что якобы поставил пакет на hold, когда как не поставил, т.к. был запущен не от root, что было сделано в ходе ревью.
Такие вопросы, как писать или не писать ман, делать или не делать тщательные проверки входных данных, выдавать ли ненулевые коды возврата в ряде случаев и т.д., на мой взгляд не имеют четкой методологии поиска ответа, а значит разные варианты ответа на них имеют право на жизнь в репозитории.

Что касается cups-usb-lp-symlink (https://packages.altlinux.org/ru/tasks/313729/), то в нем честно написано, что это костыль, который успешно обходит конкретную проблему. Костыль не нарушает работосопосбность других пакетов и ОС, куда он установлен, далее возникает аналогичная выше приведенной цепочка рассуждений.

А если не хочется, чтобы в репозитории были пакеты сомнительного качества, то такое желание понятно и правильно, но в репозитории много сомнительных пакетов, которые могут выйти боком, возникает вопрос о критериях для включения пакета в репозиторий.

(Ответ для mikhailnov на комментарий #53)
> , но в репозитории много сомнительных
> пакетов

Пожалуйста, повесьте баги на пакеты аналогичного качества. Для таких замечаний нужна конкретика.

К необходимости скрипта вообще вопросов нет, но его содержимое до сих пор ужасно и конечно надо его переписать.

Т.е. - по хорошему ментор должен объяснить кандидату в чём проблема в его коде и добиться высокого качества, а не пропускать просто потому что работа по скрипту уже была проделана.

Что касается симплинка - исправление ошибки в пакете костылём в другом пакете недопустимо, это приводит к необоснованному раздвуванию пакетной базы как в репозитории так и на машинах пользователей. К тому же в данном случае фикс ошибки выглядит простым и доступным для исправления даже кандидату такого уровня, как Тёма.

(Ответ для AEN на комментарий #54)
> (Ответ для mikhailnov на комментарий #53)
> > , но в репозитории много сомнительных
> > пакетов
> 
> Пожалуйста, повесьте баги на пакеты аналогичного качества. Для таких
> замечаний нужна конкретика.
opera-dev, например.

(Ответ для Anton Farygin на комментарий #55)
> Т.е. - по хорошему ментор должен объяснить кандидату в чём проблема в его
> коде и добиться высокого качества, а не пропускать просто потому что работа
> по скрипту уже была проделана.
Это сложный вопрос. Непонятно, где грань между замечаниями по существу и самодурством — ориентированием на свои субъективные представления. Например, по моим представлениям такой скрипт должен лежать в /usr/sbin, но автор поразмышлял над этим и решил, что все-таки в /usr/bin ему будет лучше. Нужно ли ментору добиваться перемещения в /usr/sbin? Сомневаюсь.

О кодах возврата кандидат, кажется, в курсе; мне тут вообще вся логика работы скрипта кажется странной и ненадежной (например, автоматическое подставление здезды *), поэтому, если попытаюсь добиться доведения скрипта до почти идеала, он переродится в нечто иное, чем первоначальная задумка. Но т.к. странность логики не отменяет работоспособности скрипта и не вводит критичных рисков, не пропускать пакет на основании этого субъективного ощущения будет близко к самодурству на мой взгляд.

vitlav@ сделал более предсказуемо работающую реализацию в eepm mark hold/unhold (https://github.com/Etersoft/eepm/blob/master/bin/epm-mark), можно просто удалить apt-hold-utility из сизифа за ненадобностью, попрошу кандидата подумать над этим.

> Что касается симплинка - исправление ошибки в пакете костылём в другом
> пакете недопустимо
Ну, это не "исправление", а временный объезд, который не предлагается использовать там, где в нем нет необходимости.
> это приводит к необоснованному раздвуванию пакетной базы
> как в репозитории так и на машинах пользователей. К тому же в данном случае
> фикс ошибки выглядит простым и доступным для исправления даже кандидату
> такого уровня, как Тёма.
Наверняка проблема исправляется просто, а основной задачей будет поиск места ее возникновения.

Я так и написал изначально - этот скрипт целиком крив и его надо полностью переписать, именно это нужно было донести кандидату до попадания скрипта в репозиторий.
К тому же действительно есть и другие инструменты для Hold'а (я уже не говорю про текстовый редактор).

(Ответ для mikhailnov на комментарий #52)
> Что касается cups-usb-lp-symlink
> (https://packages.altlinux.org/ru/tasks/313729/), то в нем честно написано,
> что это костыль, который успешно обходит конкретную проблему. Костыль не
> нарушает работосопосбность других пакетов и ОС, куда он установлен, далее
> возникает аналогичная выше приведенной цепочка рассуждений.

Для обхода проблемы udev-правило надо было написать.

проблемы нет, нечего обходить.

Ну как нет, один компонент создает /dev/lp0 (ядро?), другой (cups?) ищет /dev/usb/lp0. Правило udev будет тоже костылем.

Ошибки нет, т.к. не описан тестовый стенд, нет методики воспроизведения.
У нас огромное количество пользователей системы не замечают этой проблемы, да и на наших стендах она не воспроизводится, давно бы уже заметили.

И да, ядро не создаёт /dev/lp0 и не создаёт /dev/usb/lp0
Жаль что вы не разобрались и бросились делать костыли.

(Ответ для Anton Farygin на комментарий #50)
> У кандидата два пакета были отправлены в репозиторий в ужасном состоянии.
> https://packages.altlinux.org/ru/tasks/313797/
> и 
> https://packages.altlinux.org/ru/tasks/313797/
> 
> Пакетам в таком состоянии и с такой реализацией не место в репозитории и
> соответственно у меня возникает вопрос к тому, кто делал их review.

Я сначала предложил это в epm mark и даже отправил решение.
Но пока делали в epm mark hold, я написал эти скрипты, чтобы быстрее появилась такая возможность. Конечно нельзя сказать, что скрипт идеальный, но я собираюсь его поддерживать и улучшать, а это является жизненным циклом всех скриптов и программ. Я так понимаю, что первая претензия к русскому языку в сообщениях? Ничего такого сверхужасного, кроме того, что он написан быстро для решения конкретной задачи и решает её, я не вижу.

Артём, к скрипту так много замечаний, что я не вижу никакого смысла в их ревью, к сожалению.
можете поработать со своим ментором над их переписыванием.

(Ответ для Anton Farygin на комментарий #55)
> К необходимости скрипта вообще вопросов нет, но его содержимое до сих пор
> ужасно и конечно надо его переписать.
> 
> Т.е. - по хорошему ментор должен объяснить кандидату в чём проблема в его
> коде и добиться высокого качества, а не пропускать просто потому что работа
> по скрипту уже была проделана.
> 


Ментор мне дал полезные советы, как только я сделал скрипт. Я даже учёл советы и это видно по гиту. Есть и то с чем я не согласился. Я, когда писал, размышлял разместить в sbin или в bin и всё-таки остановился на bin. На это мне тоже указал ментор, но я объяснил, что уже сделал выбор осознанно, а не случайно.
Скрипт не может быть написан идеально прямо сразу. Но так, как мне нравится именно такой подход к холду пакетов, я его буду переписывать, чтобы он хоть как-то соответствовал твоим ожиданиям

> Что касается симплинка - исправление ошибки в пакете костылём в другом
> пакете недопустимо, это приводит к необоснованному раздвуванию пакетной базы
> как в репозитории так и на машинах пользователей. К тому же в данном случае
Мы уже проходили это и когда я предлагал исправление в пакет для тача в Qt и когда возвращал в KDE вызов консоли по Ctrl+Alt+T. По тачу пришлось несколько месяцев уговаривать принять исправление, например. Так что я стараюсь в чужие пакеты не лезть, по возможности, как минимум, пока меня не принимают. Хотя я в прошлый четверг и скачал и исследовал cups и, кажется, нашёл где можно вставить этот костыль.

> фикс ошибки выглядит простым и доступным для исправления даже кандидату
> такого уровня, как Тёма.
Хорошо подколол :-))))

(Ответ для mikhailnov на комментарий #60)
> Ну как нет, один компонент создает /dev/lp0 (ядро?), другой (cups?) ищет
> /dev/usb/lp0. Правило udev будет тоже костылем.

Наоборот

(Ответ для Anton Farygin на комментарий #61)
> Ошибки нет, т.к. не описан тестовый стенд, нет методики воспроизведения.
> У нас огромное количество пользователей системы не замечают этой проблемы,
> да и на наших стендах она не воспроизводится, давно бы уже заметили.

Ну раньше я эту проблему тоже не замечал.
Например с 2016 года вот с этим аппаратом http://solvpro.ru/213-panasonic-kx-mb1500-%d0%b2-linux/ проблемы не было.
А сейчас (не знаю как давно, может и в прошлом году) она появилась. Мне этот принтер не попадался года два, наверное. И вот он попался мне на прошлой неделе и у него описанная в баге проблема.

(Ответ для Артём на комментарий #64)
> Хотя я в прошлый четверг и скачал и исследовал cups и, кажется,
> нашёл где можно вставить этот костыль.
Это будет затрагивающий работу других установок костыль, когда как костыль в виде пакета их не затрагивает.
В текущей ситуации можно просто удалить пакет-костыль из сизифа, кому-нибудь полегачает?
Нормальное исправление проблемы, прошедшее обсуждение с апстримами, вряд ли получится сделать быстро и прям просто.

(Ответ для Артём на комментарий #64)
> Скрипт не может быть написан идеально прямо сразу. Но так, как мне нравится
> именно такой подход к холду пакетов, я его буду переписывать, чтобы он хоть
> как-то соответствовал твоим ожиданиям
Ожидания должны формироваться заявленным функционалом, лучше пропиши в нем --help и/или man с описанием, что скрипт делает.

(Ответ для Антон Мидюков на комментарий #58)
> (Ответ для mikhailnov на комментарий #52)
> > Что касается cups-usb-lp-symlink
> > (https://packages.altlinux.org/ru/tasks/313729/), то в нем честно написано,
> > что это костыль, который успешно обходит конкретную проблему. Костыль не
> > нарушает работосопосбность других пакетов и ОС, куда он установлен, далее
> > возникает аналогичная выше приведенной цепочка рассуждений.
> 
> Для обхода проблемы udev-правило надо было написать.

Подумал, посмотрел. Не могу осознать, чем костыль udev будет лучше, чем костыль через .patch

(Ответ для mikhailnov на комментарий #68)
> (Ответ для Артём на комментарий #64)
> > Скрипт не может быть написан идеально прямо сразу. Но так, как мне нравится
> > именно такой подход к холду пакетов, я его буду переписывать, чтобы он хоть
> > как-то соответствовал твоим ожиданиям
> Ожидания должны формироваться заявленным функционалом, лучше пропиши в нем
> --help и/или man с описанием, что скрипт делает.

Хорошо. Сделаю

(Ответ для Anton Farygin на комментарий #61)
> Ошибки нет, т.к. не описан тестовый стенд, нет методики воспроизведения.

Нарочно чтоли? Я специально сходил в багу и посмотрел, т.к. помнил, что там это есть.
Вот:
Актуально для:
Epson M200
Samsung ProXpress M3870FD

Проверил на образе
5010bef12654ec7802a7bbc7719c85e8  alt-kworkstation-10.1-beta1-install-x86_64.iso

Да не, если на стендах Базальта нет проблемы, значит ее и у всех нет, а все остальные дураки, придумывают какие-то костыли и делятся ими, пока не нашли правильное решение.

(Ответ для mikhailnov на комментарий #72)
> Да не, если на стендах Базальта нет проблемы, значит ее и у всех нет, а все
> остальные дураки, придумывают какие-то костыли и делятся ими, пока не нашли
> правильное решение.

В баге ничего не сообщено толком. Ну элементарно сообщить о том, что права на устройство такие-то, у пользователя на устройство права есть, делаю такие-то действия, ничего не выходит, можно было?

логов нет, опять же никаких.

(Ответ для Антон Мидюков на комментарий #73)
> (Ответ для mikhailnov на комментарий #72)
> > Да не, если на стендах Базальта нет проблемы, значит ее и у всех нет, а все
> > остальные дураки, придумывают какие-то костыли и делятся ими, пока не нашли
> > правильное решение.
> 
> В баге ничего не сообщено толком. Ну элементарно сообщить о том, что права
> на устройство такие-то, у пользователя на устройство права есть, делаю
> такие-то действия, ничего не выходит, можно было?

Никто не мешал и не мешает это спросить в баге, если есть интерес к участию в ее исправлении, в данном случае претензии пост-фактум неуместны.
Я бы понял накал страстей, если бы костыль был закоммичен в установленный на всех системах пакет, но он сделан отдельным пакетом, максимум, чего опасаться — это что кто-нибудь поставит этот пакет и при обновлении с правильным решением проблемы этот пакет сломает работу принтера, если его автор не позаботится об его обновлении вместе с правильным решением проблемы.

Если не нравится такой подход — делать временный пакет-костыль, не ломающий работу существущих установок — кто-то считает неправильным, то такое мнение уважаю, но, как ментор, считаю правильным проконтролировать невлияние на репозиторий и существующие установки, а вопрос допустимости нахождения пакета в репозитории оставить за его автором. Сам однозначного мнения по этому вопросу не имею.
Когда будет постоянный (не временный) доступ к проблемному оборудованию, возможно, родится правильное решениею

(Ответ для mikhailnov на комментарий #75)
> (Ответ для Антон Мидюков на комментарий #73)
> > (Ответ для mikhailnov на комментарий #72)
> > > Да не, если на стендах Базальта нет проблемы, значит ее и у всех нет, а все
> > > остальные дураки, придумывают какие-то костыли и делятся ими, пока не нашли
> > > правильное решение.
> > 
> > В баге ничего не сообщено толком. Ну элементарно сообщить о том, что права
> > на устройство такие-то, у пользователя на устройство права есть, делаю
> > такие-то действия, ничего не выходит, можно было?
> 
> Никто не мешал и не мешает это спросить в баге, если есть интерес к участию
> в ее исправлении, в данном случае претензии пост-фактум неуместны.
> Я бы понял накал страстей, если бы костыль был закоммичен в установленный на
> всех системах пакет, но он сделан отдельным пакетом, максимум, чего
> опасаться — это что кто-нибудь поставит этот пакет и при обновлении с
> правильным решением проблемы этот пакет сломает работу принтера, если его
> автор не позаботится об его обновлении вместе с правильным решением проблемы.

Бага для того и открыта и для того и существует, чтобы при правильном решении проблемы, автор увидел что багу закрыли исправлением и сразу решил что делать с костылём. Кроме того, этот костыль добавлен комментарием в багу, чтобы тот, кто будет вносить исправление знал о нём и мог связаться с автором и предложить его уже, например, удалить за ненадобностью

И как вы предлагаете удалять костыли у пользователей ?

(Ответ для Anton Farygin на комментарий #78)
> И как вы предлагаете удалять костыли у пользователей ?

Например, конфликтом в спеке

В спеке какого пакета ? Сделать костыль для удаления костыля ?
А почему-бы сразу не найти настоящую причину и не исправить её ?

Почему-то ментор ещё не проверил то, что homepage пакета соответствует реальной.
в данном случае ведёт на какую-то заглушку.

(Ответ для Anton Farygin на комментарий #80)
> В спеке какого пакета ? Сделать костыль для удаления костыля ?
> А почему-бы сразу не найти настоящую причину и не исправить её ?

В спеке костыля. Require сделать, что только ниже указанной версии

(Ответ для Anton Farygin на комментарий #81)
> Почему-то ментор ещё не проверил то, что homepage пакета соответствует
> реальной.
> в данном случае ведёт на какую-то заглушку.

Дизайнеры уж очень долго делают страницу :-(

(Ответ для Anton Farygin на комментарий #81)
> Почему-то ментор ещё не проверил то, что homepage пакета соответствует
> реальной.
> в данном случае ведёт на какую-то заглушку.

Так лучше?

(Ответ для Артём на комментарий #82)
> (Ответ для Anton Farygin на комментарий #80)
> > В спеке какого пакета ? Сделать костыль для удаления костыля ?
> > А почему-бы сразу не найти настоящую причину и не исправить её ?
> 
> В спеке костыля. Require сделать, что только ниже указанной версии

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

Conflicts непредсказуемое поведение даст, в сам текущий пакет не будет проблемой добавить необходимые проверки, останется просто мёртвым грузом, где был установлен.

(In reply to Anton Farygin from comment #80)
> В спеке какого пакета ? Сделать костыль для удаления костыля ?
> А почему-бы сразу не найти настоящую причину и не исправить её ?

В пакете, в котором сделано исправление (из-за которого больше не нужен костыль) можно сделать Obsoletes (и даже Provides) на пакет-костыль.  Но, конечно же, пакет-костыль нужен *в репозитории* только если никакого больше технического решения не нашлось.

Коллеги, мне хотелось бы чтобы в этой баге речь шла преимущественно о процедуре join, а о конкретных изменениях и пакетах лучше переписываться в списках рассылки или багах про эти пакеты. Спасибо.

Халтура это, коллеги. 
Обсуждайте где хотите, но такие пакеты собирать, на мой взгляд, стыдно.

Это сложный организационный вопрос - по сути я начал ревью пакетов кандидата вместо текущего ментора. Я вижу, что текущий ментор предвзято относится к пакетам кандидата и пропускает их в репозиторий в явно сыром и недоделанном виде.

Собственно поэтому данное обсуждение возникло в этой задаче.

(Ответ для Артём на комментарий #84)
> (Ответ для Anton Farygin на комментарий #81)
> > Почему-то ментор ещё не проверил то, что homepage пакета соответствует
> > реальной.
> > в данном случае ведёт на какую-то заглушку.
> 
> Так лучше?

Если вы разместили на том сайте редирект на altlinux.org, тогда не жульничайте и укажите настоящую homepage для пакетов, как делают другие ментейнеры - git.altlinux.org

(Ответ для Anton Farygin на комментарий #89)
> Это сложный организационный вопрос - по сути я начал ревью пакетов кандидата
> вместо текущего ментора. Я вижу, что текущий ментор предвзято относится к
> пакетам кандидата и пропускает их в репозиторий в явно сыром и недоделанном
> виде.

Это ещё большой вопрос кто предвзято относится.
А ментора у меня можно обвинить в предвзятости только за то, что он меня за каждую неправильную запятую мучает и заставляет по стопицот раз переписывать.

(Ответ для Anton Farygin на комментарий #90)
> (Ответ для Артём на комментарий #84)
> > (Ответ для Anton Farygin на комментарий #81)
> > > Почему-то ментор ещё не проверил то, что homepage пакета соответствует
> > > реальной.
> > > в данном случае ведёт на какую-то заглушку.
> > 
> > Так лучше?
> 
> Если вы разместили на том сайте редирект на altlinux.org, тогда не
> жульничайте и укажите настоящую homepage для пакетов, как делают другие
> ментейнеры - git.altlinux.org

Я не делал никакой редирект.
Так и сделаю. Исправлю. Просто не подумал, что можно указать git.altlinux.org и сидел ломал голову что туда написать, а решение оказалось на поверхности :-)

(In reply to Anton Farygin from comment #89)
> Это сложный организационный вопрос - по сути я начал ревью пакетов кандидата
> вместо текущего ментора.
Не вместо, а в дополнении к.
За что спасибо.

(Ответ для Артём на комментарий #91)
> (Ответ для Anton Farygin на комментарий #89)
> > Это сложный организационный вопрос - по сути я начал ревью пакетов кандидата
> > вместо текущего ментора. Я вижу, что текущий ментор предвзято относится к
> > пакетам кандидата и пропускает их в репозиторий в явно сыром и недоделанном
> > виде.
> 
> Это ещё большой вопрос кто предвзято относится.

Спасибо за уделённое время не дождатьcя, я так понимаю ?

> А ментора у меня можно обвинить в предвзятости только за то, что он меня за
> каждую неправильную запятую мучает и заставляет по стопицот раз переписывать.

Если это так, то почему тогда такой результат ?

Дело не "обвинениях", а в доверии. 
И для тим это беда. 
Сделайте нормально, не надо нам такого.

С одной стороны понимаю возмущение и низость качества, но с другой, если в apt-hold-utility (https://packages.altlinux.org/ru/tasks/313797/) избавить скрипт от нахождения всего кода в if-else, сделать вывод сообщений на английском без требования UTF-8, брать перевод через gettext, обеспечить правильность кодов возврата, добавить проверки на существование пакета, на наличие недопустимых символов в имени пакета, то не изменится, по-моему, почти ничего с точки зрения пользователей этого скрипта. То, что действительно важно — например, не вывод ложных сообщений об успехе, когда как возникла ошибка — было замечено и исправлено в ходе ревью.

Что касается cups-usb-lp-symlink, этот пакет не мешает другим пакетам и является малокровным функционально приемлемым временным решением проблемы.

Однако, раз нахождение таких пакетов в сизифе считаете неприемлемых, удаляю их.
https://packages.altlinux.org/ru/tasks/314305/
Простите, что заставил понервничать.

Не надо считать что репозиторий - свалка никому не мешающих пакетов.

Часто бывает так, что пакеты влияют на репозиторий самим фактом своего наличия.
Например, в данном случае с cups-usb-lp-symlink - кривым образом маскируется настоящая проблема, решается костылём и подпоркой. И мы просто в принципе не узнаем с вами, нужно ли что-то делать в других местах, т.к. пользователи вместо того, что бы описыаать проблему и фиксировать ошибки будут просто ставить "всё решающий пакет", да к тому же ещё и кривой архитектурно и не работающий в 100% проблемных случаев.

В общем я считаю что я уже окончательно потратил всё доступное время на эту историю и предлагаю перестать пытаться пропихнуть кривульку вместо того, что бы внести исправления.

Думаю что если так будет продолжаться дальше, то надо отклонять этот JOIN и больше не доверять текущему ментору менторить других кандидатов, в связи с явным отутствием ( или нежеланием) понимания того, каким качеством должны обладать пакеты в репозитории.

А зачем пользователям описывать ошибку, которая не воспроизводится на стендах Базальта, а значит её просто нет.

Антон, я понял позицию по критериям и удалил пакеты.

Эта позиция наверняка приведёт к тому, что в cups без наличия оборудовани под руками будет на глаз вставлено что-то типа пробовать /dev/usb/lp0 вместо /dev/lp0, что заткнет проблему еще более кривым образом вместо её фундаментального решения, но все останутся довольны. Посмотрим, пока что больше нечего обсуждать.

Стенды Базальта расширяемы, да и на самом деле имея живого пользователя, готового помогать в решении проблемы, проблему можно попробовать решить и без стенда.

Но это уже совсем не имеет отношения к JOIN и давай не будем засорять эту тему.
Спасибо.

Мы удалили пакеты с некачественным решением ("костылями"). Я добавлю решение конкретной проблемы другим пакетом способом, к которому я пришёл после беседы с Андреем Черепановым. А по cups мы договорились с Георгием, что я пришлю ему патч, когда заберу проблемное устройство для исследования и попробую исправить проблему, которую я вроде локализовал с parallel: в самом пакете, а не отдельным пакетом.

GJ

(Ответ для Артём на комментарий #100)
> Мы удалили пакеты с некачественным решением ("костылями"). Я добавлю решение
> конкретной проблемы другим пакетом способом, к которому я пришёл после
> беседы с Андреем Черепановым. А по cups мы договорились с Георгием, что я
> пришлю ему патч, когда заберу проблемное устройство для исследования и
> попробую исправить проблему, которую я вроде локализовал с parallel: в самом
> пакете, а не отдельным пакетом.

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

Но и собирать пакет ради сборки пакета, если не собираешься им пользоваться, тоже сомнительно.

(Ответ для mikhailnov на комментарий #103)
> Но и собирать пакет ради сборки пакета, если не собираешься им пользоваться,
> тоже сомнительно.

Неужели в репозитории есть все нужные Артёму пакеты? И не один из пакетов в репозитории нет желания исправить? Всё устраивает? А если всё устраивает, то зачем вступать в Тим? В Тим идут, когда чего-то не хватает или не устраивает и есть желание собрать или исправить, а потом в будущем это поддерживать.

(Ответ для mikhailnov на комментарий #103)
> Но и собирать пакет ради сборки пакета, если не собираешься им пользоваться,
> тоже сомнительно.

Нет, не сомнительно. Это практика. Отработка навыка, если угодно. "Тренировка на кошках".

(Ответ для Антон Мидюков на комментарий #104)
> Неужели в репозитории есть все нужные Артёму пакеты? И не один из пакетов в
> репозитории нет желания исправить? Всё устраивает?

Да. В сизифе есть 18 тысяч пакетов. И из этого безумного количества большинство людей пользуются только базовыми пакетами типа ДЕ, ИДЕ, браузеры и текстовые редакторы. У большинства ПОПУЛЯРНЫХ пакетов есть мейнтейнеры со своими представлениями о прекрасном и их изменить не получится, пакеты кстати тоже.

На кошках Артем тренировался, вот, например: https://packages.altlinux.org/ru/sisyphus/srpms/podiff/
Простая программа на си, написана, работает, не развивается, минимум зависимостей, проблемы вряд ли вызовет ещё долго (разве что при переходе на gcc 13, если там есть соответствующий код).
А вот ненужные кандидату и потенциально проблемные в будущем пакеты собирать чисто для тренировки нормально, а вот отправлять их в репозиторий спорно.

(Ответ для mikhailnov на комментарий #106)
> А вот ненужные кандидату и потенциально проблемные в будущем пакеты собирать
> чисто для тренировки нормально, а вот отправлять их в репозиторий спорно.

Можно вообще ничего не отправлять в репозиторий. Задания сейчас не ограничены во времени. Как посчитаете, что кандидат готов, ревьювер пакеты посмотрит, если всё хорошо, подтвердит, что кандидат готов. Кандидата примут в Тим, и он сам решит, что отправить в репозиторий.

Товарищи, я, как ментор, обычно предлагаю кандидатам либо собрать что-то из Proposed Packages либо обновить пакет с acl @nodody. Это и тренировка и полезно для сообщества.

Еще можно починить какой-нибудь несобирающийся пакет. Это даже в дополнение, а не вместо всего остального будет очень полезно для кандидата.

(Ответ для Антон Мидюков на комментарий #107)
> Кандидата примут в Тим, и он сам решит, что отправить в репозиторий.
Это будет безответственно со стороны ментора. Новички обычно не имеют достаточного опыта, чтобы осознавать все последствия отправки собранного ими пакета в репозиторий.
Человеческая природа такова, что большинству людей очень сложно принять бесполезность проделанной ими работы. Если кандидат для тренировки собрал какой-нибудь там калькулятор ПМС на wxGTK, то при таком подходе он наверняка примет решение отправить его в репозиторий, однако он им сам не будет пользоваться (в силу отсутствия функциональной необходимости), а у его жены айфон. В результате в репозитории окажется пакет, который придется либо чинить, либо выкидывать при обновлении wxGTK (или любой другой часто ломающей API библиотеки). Лучше бы вообще избегать работы в стол.

Всё это уже превратилось в какое-то не имеющее отношение к tema обсуждение. не пора ли перебраться в devel@

(Ответ для Grigory Ustinov на комментарий #108)
> Товарищи, я, как ментор, обычно предлагаю кандидатам либо собрать что-то из
> Proposed Packages либо обновить пакет с acl @nodody. Это и тренировка и
> полезно для сообщества.

  Вот хороший кандидат: python3-module-numpy "FTBFS since Nov. 16, 2022".

(Ответ для Andrew Vasilyev на комментарий #112)
> (Ответ для Grigory Ustinov на комментарий #108)
> > Товарищи, я, как ментор, обычно предлагаю кандидатам либо собрать что-то из
> > Proposed Packages либо обновить пакет с acl @nodody. Это и тренировка и
> > полезно для сообщества.
> 
>   Вот хороший кандидат: python3-module-numpy "FTBFS since Nov. 16, 2022".

Это плохой кандидат. На этом пакете очень много чего завязано и этот пакет должен обновляться и поправляться лицом, представляющем что к чему.

У меня в питоньем таске он собирается.

Согласен, не надо трогать numpy неопытными руками.

(Ответ для Антон Мидюков на комментарий #107)
> (Ответ для mikhailnov на комментарий #106)
> > А вот ненужные кандидату и потенциально проблемные в будущем пакеты собирать
> > чисто для тренировки нормально, а вот отправлять их в репозиторий спорно.
> 
> Можно вообще ничего не отправлять в репозиторий. Задания сейчас не
> ограничены во времени. Как посчитаете, что кандидат готов, ревьювер пакеты
> посмотрит, если всё хорошо, подтвердит, что кандидат готов. Кандидата примут
> в Тим, и он сам решит, что отправить в репозиторий.

Ну вообще-то я жду ещё с вот этого комментария:
https://bugzilla.altlinux.org/show_bug.cgi?id=33388#c49
Чтобы ревьюверы посмотрели и я мог пройти дальше.

По поводу обсуждения сборки только нужных пакетов я придерживаюсь мнения, что даже для вступления собирать надо те пакеты, которые я буду использовать и поддерживать в дальнейшем. Сейчас, например, в школе понадобился kdevelop5-plugin-python3.
Можно ли ждать ревьювера теперь? Или нужны другого вида пакеты, которые я должен собрать для галочки, а не для использования?
https://git.altlinux.org/people/tema/packages/?p=kdevelop5-plugin-python3.git;a=summary

Вот сейчас мне ещё один пакет будет нужен в ближайшее время и я его тоже соберу и буду поддерживать. Тоже скину сюда ссылку, когда закончу

(Ответ для Артём на комментарий #115)
> Можно ли ждать ревьювера теперь? Или нужны другого вида пакеты, которые я
> должен собрать для галочки, а не для использования?
> https://git.altlinux.org/people/tema/packages/?p=kdevelop5-plugin-python3.
> git;a=summary
От ментора можно, в текущем виде по состоянию на коммит dd82a03 ментор не пропустит :-)

(Ответ для Артём на комментарий #115)
> (Ответ для Антон Мидюков на комментарий #107)
> > (Ответ для mikhailnov на комментарий #106)
> > > А вот ненужные кандидату и потенциально проблемные в будущем пакеты собирать
> > > чисто для тренировки нормально, а вот отправлять их в репозиторий спорно.
> > 
> > Можно вообще ничего не отправлять в репозиторий. Задания сейчас не
> > ограничены во времени. Как посчитаете, что кандидат готов, ревьювер пакеты
> > посмотрит, если всё хорошо, подтвердит, что кандидат готов. Кандидата примут
> > в Тим, и он сам решит, что отправить в репозиторий.
> 
> Ну вообще-то я жду ещё с вот этого комментария:
> https://bugzilla.altlinux.org/show_bug.cgi?id=33388#c49
> Чтобы ревьюверы посмотрели и я мог пройти дальше.
> 

https://www.altlinux.org/Team/Join/Secretary

Сейчас находитесь на шаге 3.5
По решению ментора будет осуществлён переход к 4.0
Тогда и будет ревью.

> Можно ли ждать ревьювера теперь? Или нужны другого вида пакеты, которые я
> должен собрать для галочки, а не для использования?

Решение о переходе на следующий шаг принимает ментор.

В комментарии 49 имел в виду, что кандидат по моему мнению готов к п.4

(Ответ для mikhailnov на комментарий #116)
> (Ответ для Артём на комментарий #115)
> > Можно ли ждать ревьювера теперь? Или нужны другого вида пакеты, которые я
> > должен собрать для галочки, а не для использования?
> > https://git.altlinux.org/people/tema/packages/?p=kdevelop5-plugin-python3.
> > git;a=summary
> От ментора можно, в текущем виде по состоянию на коммит dd82a03 ментор не
> пропустит :-)

Я догадываюсь :-)
Я просто комментировал насчёт нужности пакетов и показал какой пакет мне нужен сейчас и над чем я сейчас работаю.

https://git.altlinux.org/tasks/317202/
Очень нужная в школе штука. Рекомендую включить в Альтобразование

(In reply to Артём from comment #120)
> https://git.altlinux.org/tasks/317202/
> Очень нужная в школе штука. Рекомендую включить в Альтобразование

avogadro2-libs - неправильное название пакета.
Если там библиотека, то пакеты должны называться libavogadro*.

(Ответ для Dmitry V. Levin на комментарий #121)
> (In reply to Артём from comment #120)
> > https://git.altlinux.org/tasks/317202/
> > Очень нужная в школе штука. Рекомендую включить в Альтобразование
> 
> avogadro2-libs - неправильное название пакета.
> Если там библиотека, то пакеты должны называться libavogadro*.

Спасибо за комментарий.
Там не только библиотеки lib. Там ещё библиотека компонентов
/usr/share/avogadro2/crystals/
Set of over 500 common crystal structures.
https://github.com/openchemistry/crystals
А так же скрипты и плагины

(In reply to Артём from comment #122)
> (Ответ для Dmitry V. Levin на комментарий #121)
> > (In reply to Артём from comment #120)
> > > https://git.altlinux.org/tasks/317202/
> > > Очень нужная в школе штука. Рекомендую включить в Альтобразование
> > 
> > avogadro2-libs - неправильное название пакета.
> > Если там библиотека, то пакеты должны называться libavogadro*.
> 
> Спасибо за комментарий.
> Там не только библиотеки lib. Там ещё библиотека компонентов
> /usr/share/avogadro2/crystals/
> Set of over 500 common crystal structures.
> https://github.com/openchemistry/crystals
> А так же скрипты и плагины

Значит, это хороший тест на упаковку чего-то менее тривиального. :)

(Ответ для Dmitry V. Levin на комментарий #123)
> (In reply to Артём from comment #122)
> > (Ответ для Dmitry V. Levin на комментарий #121)
> > > (In reply to Артём from comment #120)
> > > > https://git.altlinux.org/tasks/317202/
> > > > Очень нужная в школе штука. Рекомендую включить в Альтобразование
> > > 
> > > avogadro2-libs - неправильное название пакета.
> > > Если там библиотека, то пакеты должны называться libavogadro*.
> > 
> > Спасибо за комментарий.
> > Там не только библиотеки lib. Там ещё библиотека компонентов
> > /usr/share/avogadro2/crystals/
> > Set of over 500 common crystal structures.
> > https://github.com/openchemistry/crystals
> > А так же скрипты и плагины
> 
> Значит, это хороший тест на упаковку чего-то менее тривиального. :)

Тест отличный!
Мне кажется, что получилось неплохо. :-)

Могу только повторить, что avogadro2-libs - это неправильное название пакета, что бы там не находилось.  Пакеты с библиотеками обычно называются lib*, пакеты с другим содержимым называются как-то ещё.  Исторически сложилось, что Сизифе есть несколько пакетов, которые называются *-libs, но не надо увеличивать их число.

предлагаю дождаться review от ментора с оценкой результата.

(Ответ для Dmitry V. Levin на комментарий #125)
> Могу только повторить, что avogadro2-libs - это неправильное название пакета,
> что бы там не находилось.
Лучше не смотреть, что там. ;-)

(Ответ для Артём на комментарий #122)
> > avogadro2-libs - неправильное название пакета.
> > Если там библиотека, то пакеты должны называться libavogadro*.
> Там не только библиотеки lib. Там ещё библиотека компонентов
> /usr/share/avogadro2/crystals/
Если это всё апстримом поставляется как тарбол с именем avogadro2-libs -- возможно, обсуждаемо (хотя согласен с крайне неудачным выбором названия,
я бы с апстримом потолковал тогда насчёт более внятного).

Если же это при упаковке в один исходный пакет свалены код и данные --
так лучше не делать, но собрать libavogadro* и отдельно avogadro2-data какие:
при этом изменения кода (библиотеки) и изменения данных (особенно если их много) будут приводить к минимально необходимым изменениям в пакетной базе.

Из показательных примеров -- например, SimGear, FlightGear и FlightGear-data:
семь метров, полтора метра и полтора гига.

(Ответ для Michael Shigorin на комментарий #128)
> Если же это при упаковке в один исходный пакет свалены код и данные --
> так лучше не делать, но собрать libavogadro* и отдельно avogadro2-data какие:
> при этом изменения кода (библиотеки) и изменения данных (особенно если их
> много) будут приводить к минимально необходимым изменениям в пакетной базе.
> 
> Из показательных примеров -- например, SimGear, FlightGear и FlightGear-data:
> семь метров, полтора метра и полтора гига.

Миш, большое спасибо за комментарии. Дима и тебе тоже спасибо!
Я, конечно, последую советам и пересоберу обязательно пакет, учитывая то, что вы написали.
Как только у меня опять появится возможность, я сразу соберу и выложу тут ссылку. Пока пользуемся как есть тем что получилось из-за катастрофической нехватки времени :-(

NOTABUG ?

(Ответ для Sergey V Turchin на комментарий #130)
> NOTABUG ?

Закрывай. Я разочаровался. Интерес потерян.