ALT Linux Bugzilla – #38797

Created attachment 8904 [details]
gpg pubkey

Подтверждаю менторство.

Подтверждаю.

(Ответ для Anna на комментарий #0)
> Создано вложение 8903 [details] [подробности]
> ssh pubkey
Ok.

(Ответ для Anna на комментарий #1)
> Создано вложение 8904 [details] [подробности]
> gpg pubkey
Ok.

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

T/J/S -> 3.0.

Кандидат готов к сборке. Можем переходить на следующий этап.

Подтверждаю, что кандидат готов к переходу на следующий этап.

Глеб, ping! Можешь дать Анне права на build.alt?

Пакет alt-gpgkeys обновлён.

T/J/S -> 4.0.

(Ответ для Gleb F-Malinovskiy на комментарий #9)
> Пакет alt-gpgkeys обновлён.
> 
> T/J/S -> 4.0.

Кандидат показал, что справился со сборкой. Прошу перейти на следующий этап.

(In reply to Andrey Cherepanov from comment #10)
> (Ответ для Gleb F-Malinovskiy на комментарий #9)
> > Пакет alt-gpgkeys обновлён.
> > 
> > T/J/S -> 4.0.
> 
> Кандидат показал, что справился со сборкой. Прошу перейти на следующий этап.

Справился со сборкой - это хорошо.
Но в пакете нет ни одного патча, хотя напрашивается.

Например, в bpytop.spec написано:
%py3_requires psutil

В то же время в bpytop.py написано:
try: import fcntl, termios, tty, pwd
except Exception as e: errors.append(f'{e}')
try: import psutil # type: ignore
except Exception as e: errors.append(f'{e}')

Логично же заменить этот try на обычный import и убрать %py3_requires?

Заодно можно будет попрактиковаться в упаковывании патчей.

Дима, к собранному пакету у нас есть и другие замечания, мы никуда не торопимся. Анна постепенно совершенствует технику, а данный пакет никто без одобрения не пропустит. Переход на текущий этап дал нам возможность, наконец, работать с кандидатом удалённо, видеть результаты. Но реакция была больше месяца. Так что, возможно, нынешний запрос сделан чуточку заранее, но с учётом занятости Глеба.

(Ответ для Andrey Cherepanov на комментарий #10)
> Кандидат показал, что справился со сборкой. Прошу перейти на следующий этап.

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

(Ответ для Leonid Krivoshein на комментарий #12)
> возможно, нынешний запрос сделан чуточку заранее, но

Если это верно, то пожалуйста больше не делайте так.

> Справился со сборкой - это хорошо.
> Но в пакете нет ни одного патча, хотя напрашивается.
> 
> Например, в bpytop.spec написано:
> %py3_requires psutil
> 
> В то же время в bpytop.py написано:
> try: import fcntl, termios, tty, pwd
> except Exception as e: errors.append(f'{e}')
> try: import psutil # type: ignore
> except Exception as e: errors.append(f'{e}')
> 
> Логично же заменить этот try на обычный import и убрать %py3_requires?
> 
> Заодно можно будет попрактиковаться в упаковывании патчей.

Сделала патч - task #262703

>(Ответ для Gleb F-Malinovskiy на комментарий #13)

> Мне кажется, что одного маленького пакета мало чтобы в этом убедиться.

Планирую взяться за второй пакет.

(In reply to Anna from comment #14)
> > Справился со сборкой - это хорошо.
> > Но в пакете нет ни одного патча, хотя напрашивается.
> > 
> > Например, в bpytop.spec написано:
> > %py3_requires psutil
> > 
> > В то же время в bpytop.py написано:
> > try: import fcntl, termios, tty, pwd
> > except Exception as e: errors.append(f'{e}')
> > try: import psutil # type: ignore
> > except Exception as e: errors.append(f'{e}')
> > 
> > Логично же заменить этот try на обычный import и убрать %py3_requires?
> > 
> > Заодно можно будет попрактиковаться в упаковывании патчей.
> 
> Сделала патч - task #262703

Спасибо.

Мне кажется, что строчка
BuildRequires: python3-devel
в этом спек-файле лишняя, как вы думаете?

Да и строчку
BuildRequires(pre): rpm-build-python3
в этом спек-файле, если я не ошибаюсь, можно было бы упростить до
BuildPreReq: pm-build-python3

(Ответ для Dmitry V. Levin на комментарий #15)
> Да и строчку
> BuildRequires(pre): rpm-build-python3
> в этом спек-файле, если я не ошибаюсь, можно было бы упростить до
> BuildPreReq: pm-build-python3
Интересно, вралась ли бы сюда опечатка без "если я не ошибаюсь"... :)

(In reply to Dmitry V. Levin from comment #15)
> BuildPreReq: pm-build-python3

Кто-то съел букву, имелось в виду
BuildPreReq: rpm-build-python3

(In reply to Michael Shigorin from comment #16)
> Интересно, вралась ли бы

Сложно сказать! :)

(Ответ для Dmitry V. Levin на комментарий #15)
> BuildRequires(pre): rpm-build-python3

Вот это моё влияние.  Я считаю, что spec должен вычисляться без ошибок сразу после установки пакетов из (pre), но со мной, кажется, не все согласны. :)

(Ответ для Gleb F-Malinovskiy на комментарий #19)
> (Ответ для Dmitry V. Levin на комментарий #15)
> > BuildRequires(pre): rpm-build-python3
> 
> Вот это моё влияние.  Я считаю, что spec должен вычисляться без ошибок сразу
> после установки пакетов из (pre), но со мной, кажется, не все согласны. :)

А, но на данный момент макросы для вычисления spec-файла вообще не нужны, т.е. можно зависимость только на python3-devel оставить.

(In reply to Gleb F-Malinovskiy from comment #20)
> (Ответ для Gleb F-Malinovskiy на комментарий #19)
> > (Ответ для Dmitry V. Levin на комментарий #15)
> > > BuildRequires(pre): rpm-build-python3
> > 
> > Вот это моё влияние.  Я считаю, что spec должен вычисляться без ошибок сразу
> > после установки пакетов из (pre), но со мной, кажется, не все согласны. :)
> 
> А, но на данный момент макросы для вычисления spec-файла вообще не нужны,
> т.е. можно зависимость только на python3-devel оставить.

А почему python3-devel, а не rpm-build-python3, в пакете же просто скрипт на python3?

(Ответ для Dmitry V. Levin на комментарий #21)
> (In reply to Gleb F-Malinovskiy from comment #20)
> > т.е. можно зависимость только на python3-devel оставить.
> 
> А почему python3-devel, а не rpm-build-python3, в пакете же просто скрипт на
> python3?

Да, наверное так понятнее будет, согласен.

(Ответ для Dmitry V. Levin на комментарий #15)
> Да и строчку
> BuildRequires(pre): rpm-build-python3
> в этом спек-файле, если я не ошибаюсь, можно было бы упростить до
> BuildPreReq: rpm-build-python3

Разве BuildPreReq у нас не считается "дурным тоном"? Я всегда старался писать BuildRequires(pre) и даже менял в некоторых пакетах BuildPreReq на BuildRequires(pre).

(In reply to Grigory Ustinov from comment #23)
> (Ответ для Dmitry V. Levin на комментарий #15)
> > Да и строчку
> > BuildRequires(pre): rpm-build-python3
> > в этом спек-файле, если я не ошибаюсь, можно было бы упростить до
> > BuildPreReq: rpm-build-python3
> 
> Разве BuildPreReq у нас не считается "дурным тоном"?

Нет, BuildPreReq - это фактически синоним BuildRequires, некоторые используют BuildPreReq для того, чтобы ещё сильнее отличать зависимости, указанные вручную, от зависимостей, которые вычислил buildreq.

> Я всегда старался
> писать BuildRequires(pre) и даже менял в некоторых пакетах BuildPreReq на
> BuildRequires(pre).

У BuildRequires(pre) всё-таки немного другой смысл.

(Ответ для Dmitry V. Levin на комментарий #24)
> Нет, BuildPreReq - это фактически синоним BuildRequires, некоторые
> используют BuildPreReq для того, чтобы ещё сильнее отличать зависимости,
> указанные вручную, от зависимостей, которые вычислил buildreq.

Перед автоматически вычисленными зависимостями _некоторые_ используют комментарий, который недвусмысленно даёт понять, как они были получены. Так что я не вижу в этом синониме иного смысла, как запутать и без того запутанных мейнтейнеров=) Я скорее согласен с Глебом и если вижу rpm-build-* или rpm-macros-* то ставлю их в BuildRequires(pre):

(Ответ для Dmitry V. Levin на комментарий #15)
> BuildRequires(pre): rpm-build-python3
> в этом спек-файле, если я не ошибаюсь, можно было бы упростить до
> BuildPreReq: pm-build-python3

Такой хороший вопрос :) Если я правильно поняла, то BuildRequires(pre) следует использовать для тех пакетов, которые будут установлены в cборочную среду до того как hasher начинает сборку пакета с помощью rpm-build. Т.е. если бы у меня был прежний макрос %python3_build, то было бы правильно, но так как патч уже сделан, то дальше rpm-build-python3 можно перенести в BuildRequires.
Переделала task #263031

(In reply to Dmitry V. Levin from comment #11)
> Логично же заменить этот try на обычный import и убрать %py3_requires?
Как в Дебиане, но не как в Федоре... как дилетант в этом вопросе я бы выбрал второй вариант, чтобы не таскать патч, не проходимый в апстрим. Конечно, можно переложить интелект разруливания зависимостей на нашу сборочницу, но стоит ли так делать для такого небольшого скрипта, если сам питон справляется с задачей успешно?

> Заодно можно будет попрактиковаться в упаковывании патчей.
Разве что полезно попрактиковаться, это да. :-)

(In reply to Leonid Krivoshein from comment #27)
> (In reply to Dmitry V. Levin from comment #11)
> > Логично же заменить этот try на обычный import и убрать %py3_requires?
> Как в Дебиане, но не как в Федоре... как дилетант в этом вопросе я бы выбрал
> второй вариант, чтобы не таскать патч, не проходимый в апстрим. Конечно,
> можно переложить интелект разруливания зависимостей на нашу сборочницу, но
> стоит ли так делать для такого небольшого скрипта, если сам питон
> справляется с задачей успешно?

Так точно стоит делать, чтобы не отслеживать зависимости вручную.

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

> > Заодно можно будет попрактиковаться в упаковывании патчей.
> Разве что полезно попрактиковаться, это да. :-)

Полезно во всех отношениях, на мой вгляд. :)

(In reply to Anna from comment #26)
> Переделала task #263031

У меня замечаний нет. Если Андрей заапрувит, надо перезапустить таск на сборку и на следующих итерациях ждём самостоятельно собранного пакета "с нуля" и одного исправления в Сизифе. Хотя, на мой взгляд, пользоваться инструментарием Вы уже научились, а опыт сборки приходит с годами.

(Ответ для Leonid Krivoshein на комментарий #29)
> (In reply to Anna from comment #26)
> > Переделала task #263031
> 
> У меня замечаний нет. Если Андрей заапрувит, надо перезапустить таск на
> сборку и на следующих итерациях ждём самостоятельно собранного пакета "с
> нуля" и одного исправления в Сизифе. Хотя, на мой взгляд, пользоваться
> инструментарием Вы уже научились, а опыт сборки приходит с годами.

Посмотрел, одобрил. Но из-за test_only=yes запускать надо самой Анне.

(In reply to Andrey Cherepanov from comment #30)
> Посмотрел, одобрил.
Анна собрала ещё один пакет в #264340 -- у меня замечаний нет. Он может быть полезен нашим ядерщикам и партнёрам типа Касперского/DrWeb.

(Ответ для Leonid Krivoshein на комментарий #31)
> (In reply to Andrey Cherepanov from comment #30)
> > Посмотрел, одобрил.
> Анна собрала ещё один пакет в #264340 -- у меня замечаний нет. Он может быть
> полезен нашим ядерщикам и партнёрам типа Касперского/DrWeb.

  А нужен ли
BuildRequires: gcc
  ?
  gcc разве не всегда устанавливается?

(Ответ для Andrew Vasilyev на комментарий #32)
> (Ответ для Leonid Krivoshein на комментарий #31)
> > (In reply to Andrey Cherepanov from comment #30)
> > > Посмотрел, одобрил.
> > Анна собрала ещё один пакет в #264340 -- у меня замечаний нет. Он может быть
> > полезен нашим ядерщикам и партнёрам типа Касперского/DrWeb.
> 
>   А нужен ли
> BuildRequires: gcc
>   ?
>   gcc разве не всегда устанавливается?

Спасибо, изменила.

(In reply to Andrew Vasilyev from comment #32)
> А нужен ли BuildRequires: gcc?
Сборочная зависимость (gcc) у программы есть, так что её прямое указание в спеке полиси не нарушает и ошибкой не является.

> gcc разве не всегда устанавливается?
Полагаю, вместе с зависимостями rpm-build, т.е. можно это считать текущими особенностями сборочницы. Можно ли полагаться на эту особенность в дальнейшем?

Есть ли у коллег замечания к task #264340?

Есть ли комментарии у основного и добавленного менторов? На мой взгляд Анна показала готовность использовать наш инструментарий. В ближайшее время на сборку должны отправиться ещё несколько пакетов по линии совместимости.

Ещё собрала пакет kesl10-preinstall task #265441
Обновила  librtpkcs11ecp task #265108

Планирую дальше собирать пакеты для списка-0

(In reply to Anna from comment #36)
> Ещё собрала пакет kesl10-preinstall task #265441
> Обновила  librtpkcs11ecp task #265108

Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9.

> Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9.

Отправила.
Что от меня ещё требуется для join?

(In reply to Anna from comment #38)
> > Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9.
> 
> Отправила.
> Что от меня ещё требуется для join?

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

(Ответ для Dmitry V. Levin на комментарий #39)
> (In reply to Anna from comment #38)
> > > Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9.
> > 
> > Отправила.
> > Что от меня ещё требуется для join?
> 
> Убедить всех менторов в том, что ваши сборки больше не нуждаются в ревью.
> Я думаю, что спешить не стоит - чем больше вы практикуетесь, тем больше у
> вас опыта.

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

(In reply to Andrey Cherepanov from comment #40)
> (Ответ для Dmitry V. Levin на комментарий #39)
> > (In reply to Anna from comment #38)
> > > > Если вдруг ещё не отправили, эту же сборку можно отправлять сразу в p9.
> > > 
> > > Отправила.
> > > Что от меня ещё требуется для join?
> > 
> > Убедить всех менторов в том, что ваши сборки больше не нуждаются в ревью.
> > Я думаю, что спешить не стоит - чем больше вы практикуетесь, тем больше у
> > вас опыта.
> 
> Меня лично Анна убедила, что может собирать пакеты.

Вопрос в том, может ли она это делать полностью самостоятельно.

> А совершенствоваться
> можно и параллельно сборке пакетов с одобренной учётной записи. Можно,
> конечно, и одобрять все задания, но какой в этом будет смысл. Зачем
> затягивать?

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

(In reply to Dmitry V. Levin from comment #41)
> Вопрос в том, может ли она это делать полностью самостоятельно.
Анна убедила, что может и вообще-то должна. Хотя спрашивать совета коллег на хитрых задачках вполне нормально, как мне кажется. Дело в том, что её "рабочая задача" не просто:

(In reply to Anna from comment #0)
> Цель: Научиться собирать пакеты.
а, на самом деле, собирать вполне определённые пакеты, так что здесь нужды проходить все тонкости просвещения нет. То, что требуется для работы, Анна уже знает и умеет, подтвердила это неоднократно. Теперь для работы необходимость апрува ментора при нашей загрузке создаёт лишь дополнительные сложности.

Давайте сделаем так: Анна самостоятельно внесёт улучшения в свой последний пакет и полностью с нуля сделает ещё один похожий пакет. Будет ли этого достаточно для джойна?

(In reply to Leonid Krivoshein from comment #42)
> Давайте сделаем так: Анна самостоятельно внесёт улучшения в свой последний
> пакет и полностью с нуля сделает ещё один похожий пакет.

Давайте.

> Будет ли этого достаточно для джойна?

Посмотрим. :)

Доброй ночи!

Добавила улучшение в пакет kesl10-preinstall task #268312

(In reply to Anna from comment #44)
> Добавила улучшение в пакет kesl10-preinstall task #268312
Я бы одобрил. Ждём остальных...

Собрала еще пару пакетов: 
vipnetcsp4-preinstall task #268849
fsprot-control task #268850
drweb11-preinstall task #268850

(In reply to Anna from comment #46)
> vipnetcsp4-preinstall task #268849
> fsprot-control task #268850
> drweb11-preinstall task #268850
К этим сборкам у меня замечаний нет, можно пропускать.
Соберите хотя бы ещё парочку таких же полностью без замечаний.

(Ответ для Anna на комментарий #46)
> Собрала еще пару пакетов: 
> drweb11-preinstall task #268850

  К самой процедуре сборки отношения не имеет, но:

"This is needded for" -> needed или necessary
(аналогично в kesl10-preinstall).

"Don't forget remove" -> "to remove"
"Don't forget disable" -> "to disable"

(Ответ для Andrew Vasilyev на комментарий #48)
> (Ответ для Anna на комментарий #46)
> > Собрала еще пару пакетов: 
> > drweb11-preinstall task #268850
> 
>   К самой процедуре сборки отношения не имеет, но:
> 
> "This is needded for" -> needed или necessary
> (аналогично в kesl10-preinstall).
> 
> "Don't forget remove" -> "to remove"
> "Don't forget disable" -> "to disable"

Андрей, спасибо большое. Обязательно исправлю, если больше замечаний не будет.

Исправила замечания по прошлым пакетам.
Обновила пакет librtpkcs11ecp до новой версии 2.1.1.0.
librtpkcs11ecp #269872
vipnetcsp4-preinstall #269293
kesl10-preinstall #269256
fsprot-control #268850
drweb11-preinstall #268850

(In reply to Anna from comment #50)
> Исправила замечания по прошлым пакетам.
> Обновила пакет librtpkcs11ecp до новой версии 2.1.1.0.
> librtpkcs11ecp #269872
> vipnetcsp4-preinstall #269293
> fsprot-control #268850
Вот это безупречно, я бы заапрувил сходу, если нет других возражений.

> kesl10-preinstall #269256
> drweb11-preinstall #268850
Здесь тоже всё неплохо, но над тестом %description можно было бы и получше поработать (на мой взгляд). В крайнем случае можно подправить в следующих сборках.

Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и самостоятельности.

(In reply to Leonid Krivoshein from comment #52)
> Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и
> самостоятельности.

Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата".
Кто у нас ментор? :)

(Ответ для Dmitry V. Levin на комментарий #53)
> (In reply to Leonid Krivoshein from comment #52)
> > Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и
> > самостоятельности.
> 
> Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата".
> Кто у нас ментор? :)

Прошу перечитать https://bugzilla.altlinux.org/show_bug.cgi?id=38797#c7
Или нужно каждое действие повторно подтверждать? Укажите место в регламенте, где это написано.

(In reply to Andrey Cherepanov from comment #54)
> (Ответ для Dmitry V. Levin на комментарий #53)
> > (In reply to Leonid Krivoshein from comment #52)
> > > Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и
> > > самостоятельности.
> > 
> > Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата".
> > Кто у нас ментор? :)
> 
> Прошу перечитать https://bugzilla.altlinux.org/show_bug.cgi?id=38797#c7
> Или нужно каждое действие повторно подтверждать? Укажите место в регламенте,
> где это написано.

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

(Ответ для Dmitry V. Levin на комментарий #55)
> (In reply to Andrey Cherepanov from comment #54)
> > (Ответ для Dmitry V. Levin на комментарий #53)
> > > (In reply to Leonid Krivoshein from comment #52)
> > > > Дима, я прошу посмотреть выложенные задания и дать оценку о готовности и
> > > > самостоятельности.
> > > 
> > > Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата".
> > > Кто у нас ментор? :)
> > 
> > Прошу перечитать https://bugzilla.altlinux.org/show_bug.cgi?id=38797#c7
> > Или нужно каждое действие повторно подтверждать? Укажите место в регламенте,
> > где это написано.
> 
> Со времён того подтверждения регламент успел поменяться, так что для
> перехода на следующую стадию нужно подтвердить.

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

(In reply to Dmitry V. Levin from comment #53)
> Мы находимся на стадии 3.4 "Ожидать решения ментора о готовности кандидата".
> Кто у нас ментор? :)
Дима, я уже давно в комментарии 42 высказал мнение как бывший ментор. И моя позиция не изменится, сколько бы изменений в регламент не вносилось. Я смотрел каждый последующий пакет и твёрдо убеждён, что Анна научилась собирать пакеты, которые требовалось.

Принимающая сторона в комментарии 43 хотела что-то ещё посмотреть. Не знаю, зачем затягивать процесс и почему не дать финальную оценку о готовности либо неготовности кандидата. У нас ещё есть немного времени, чтобы этот баг не ляг очередным пятном на наш джойн. Призываю дать оценку на своё усмотрение, положительную ли, отрицательную, но не динамить с этим. Или сказать, что ещё не сделано или сделано не так.

Попробую позвать ещё одного человека (darktemplar@) для независимой оценки готовности кандидата.

Рекомендации:

http://git.altlinux.org/people/khab/packages/?p=bpytop.git;a=commitdiff;h=32c1dcf4084eb73fb6c6f85270c2733e04dcb991

1) copy: *.patch

Думаю, лучше будет написать "copy?: *.patch" - в таком случае если патчи будут не нужны, их можно будет удалить без изменения файла .gear/rules.

2) Рекомендую при сборке пакетов выставлять:

%define _unpackaged_files_terminate_build 1

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

По крайней мере это может быть полезно для пакетов, содержащих файлы.

3) Packager: Anna Khrustova <khab@altlinux.org>

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

4) %makeinstall_std PREFIX=/usr

Вместо /usr скорее всего стоит использовать макрос %_prefix.
На следующей странице содержится большое количество макросов с их значениями:
https://www.altlinux.org/Spec/Предопределенные_макросы
Но данный список не является полным.

http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4

5) Не сразу очевидно почему указана данная лицензия, поскольку не взят коммит из апстрима, добавляющий лицензию, а в исходниках она не указана. Хорошо бы взять соответствующий коммит из апстрима.

Вопросы:
http://git.altlinux.org/people/khab/packages/?p=drweb11-preinstall.git;a=commitdiff;h=8bd720a7d0fdf89b7cc515700611fc77cde92353

1) Где и при каких условиях создаётся или удаляется файл /_NEW_SYSTEM_ ?

http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4

2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не удалось найти указание версии в апстриме.


К имеющимся пакетам претензий нет. Есть только пара вопросов и несколько небольших рекомендаций.

К сожалению, все собранные пакеты - простые, либо не содержат сборки, либо эта сборка простая.

Вот два самых сложных пакета для сборки:
http://git.altlinux.org/people/khab/packages/?p=bpytop.git;a=commitdiff;h=32c1dcf4084eb73fb6c6f85270c2733e04dcb991
http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4

Пакеты *-preinstall по сборке ещё проще двух указанных выше пакетов. Там сборка отсутствует.

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

Спасибо за комментарии, учту.

> Вопросы:
> http://git.altlinux.org/people/khab/packages/?p=drweb11-preinstall.git;
> a=commitdiff;h=8bd720a7d0fdf89b7cc515700611fc77cde92353
> 
> 1) Где и при каких условиях создаётся или удаляется файл /_NEW_SYSTEM_ ?
> 
> http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;
> h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4

На этапе инсталляции системы нельзя менять свойств безопасности определенные выпускающим дистрибутива. Наш инсталлятор создаёт флаг /_NEW_SYSTEM_ в начале инсталяции и удаляет его после завершения. Например, когда в каталоге /tmp стоит опция 'noexec' и идет процесс установки системы, то нам это позваляет понять, что в данный момент установка программы в данный каталог будет невозможна, а если пакет устанавливает уже администартор, то данную опцию возможно поменять.

http://git.altlinux.org/gears/a/alterator-pkg.git?p=alterator-pkg.git;a=blob;f=alterator-pkg/backend3/pkg-init;h=9e76ca686d4d6744d50027d884f51615c7271ac3;hb=cf4cdff3f3212cdb7c4c671d6df9d0c994022152#l53

> 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не
> удалось найти указание версии в апстриме.
> 

Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE
> 
> К имеющимся пакетам претензий нет. Есть только пара вопросов и несколько
> небольших рекомендаций.
> 
> К сожалению, все собранные пакеты - простые, либо не содержат сборки, либо
> эта сборка простая.
> 
 Изначально такая цель ставилась, научиться собирать простые пакеты такие как preinstall.
> Вот два самых сложных пакета для сборки:
> http://git.altlinux.org/people/khab/packages/?p=bpytop.git;a=commitdiff;
> h=32c1dcf4084eb73fb6c6f85270c2733e04dcb991
> http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;
> h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4
> 
> Пакеты *-preinstall по сборке ещё проще двух указанных выше пакетов. Там
> сборка отсутствует.
> 
> Только по таким простым пакетам сложно оценить насколько хорошо кандидат
> умеет собирать пакеты. Возможно было бы лучше, если бы кандидат
> продемонстрировал свои навыки на сборке с нуля какого-либо более сложного
> пакета.

Ещё несколько пакетов было собрано:
#282420 1c-preinstall.git=8.3-alt13
#279956 sputnik-browser-preinstall.git=5.3.5672.0-alt1
#270114 mate-panel.git=1.22.2-alt2

Дима, Алексей, большое спасибо!

В комментарии 39 говорилось, что осталось сделать для джойна: "Убедить всех менторов в том, что ваши сборки больше не нуждаются в ревью.", после чего мы с Андреем эту готовность подтвердили. Изначально действительно ставилась задача научиться собирать вполне определённые пакеты, обеспечивающие слой совместимости продуктовых решений со сторонним коммерческим ПО. Лично для меня было важно иметь возможность поручать Анне такие задачи, а также простое бэкпортирование. Пропущенных нами с Андреем заданий от Анны очевидно больше, чем упомянуто в баге. Нас она давно убедила в том, что этот навык освоила. Теперь и независимый ментор, как я понял, подтвердил, что такие пакеты Анна может собирать без ошибок и самостоятельно.

Достаточно ли этого для закрытия бага или требуется что-то ещё?

(Ответ для Anna на комментарий #60)
> Спасибо за комментарии, учту.
> 
> > Вопросы:
> > http://git.altlinux.org/people/khab/packages/?p=drweb11-preinstall.git;
> > a=commitdiff;h=8bd720a7d0fdf89b7cc515700611fc77cde92353
> > 
> > 1) Где и при каких условиях создаётся или удаляется файл /_NEW_SYSTEM_ ?
> > 
> > http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;
> > h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4
> 
> На этапе инсталляции системы нельзя менять свойств безопасности определенные
> выпускающим дистрибутива. Наш инсталлятор создаёт флаг /_NEW_SYSTEM_ в
> начале инсталяции и удаляет его после завершения. Например, когда в каталоге
> /tmp стоит опция 'noexec' и идет процесс установки системы, то нам это
> позваляет понять, что в данный момент установка программы в данный каталог
> будет невозможна, а если пакет устанавливает уже администартор, то данную
> опцию возможно поменять.
> 
> http://git.altlinux.org/gears/a/alterator-pkg.git?p=alterator-pkg.git;a=blob;
> f=alterator-pkg/backend3/pkg-init;h=9e76ca686d4d6744d50027d884f51615c7271ac3;
> hb=cf4cdff3f3212cdb7c4c671d6df9d0c994022152#l53
> 

Спасибо за объяснение.

> > 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не
> > удалось найти указание версии в апстриме.
> > 
> 
> Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE

Извините, если я не точно выразился. Я имел ввиду версию пакета, указанную вот так:

Version: 0.0.0.2.507ad

> > 
> > К имеющимся пакетам претензий нет. Есть только пара вопросов и несколько
> > небольших рекомендаций.
> > 
> > К сожалению, все собранные пакеты - простые, либо не содержат сборки, либо
> > эта сборка простая.
> > 
>  Изначально такая цель ставилась, научиться собирать простые пакеты такие
> как preinstall.

Эта цель была достигнута, я согласен.

(Ответ для Leonid Krivoshein на комментарий #61)
> Достаточно ли этого для закрытия бага или требуется что-то ещё?

С учётом всего вышенаписанного это решать Дмитрию.

> > > http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;
> > > h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4
> > > 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не
> > > удалось найти указание версии в апстриме.
> > > 
> > 
> > Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE
> 
> Извините, если я не точно выразился. Я имел ввиду версию пакета, указанную
> вот так:
> 
> Version: 0.0.0.2.507ad

Прошу прощения, идея была написать commit id в релиз, где 2 количество комитов от апстрима.

(In reply to Anna from comment #63)
> > > > http://git.altlinux.org/people/khab/packages/?p=kcore_dump.git;a=commitdiff;
> > > > h=508de01d06aa7ee06f7f7f000e5bfd021b9527d4
> > > > 2) Почему указана именно такая версия для пакета kcore_dump? Мне нигде не
> > > > удалось найти указание версии в апстриме.
> > > > 
> > > 
> > > Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE
> > 
> > Извините, если я не точно выразился. Я имел ввиду версию пакета, указанную
> > вот так:
> > 
> > Version: 0.0.0.2.507ad
> 
> Прошу прощения, идея была написать commit id в релиз, где 2 количество
> комитов от апстрима.

В качестве апстримного релиза был взят 0.0, поскольку у апстрима не было ни одного релиза?

> > > > Вот тут https://github.com/schlafwandler/kcore_dump/blob/master/LICENSE
> > > 
> > > Извините, если я не точно выразился. Я имел ввиду версию пакета, указанную
> > > вот так:
> > > 
> > > Version: 0.0.0.2.507ad
> > 
> > Прошу прощения, идея была написать commit id в релиз, где 2 количество
> > комитов от апстрима.
> 
> В качестве апстримного релиза был взят 0.0, поскольку у апстрима не было ни
> одного релиза?

Да

(In reply to Aleksei Nikiforov from comment #62)
> > > К имеющимся пакетам претензий нет. Есть только пара вопросов и несколько
> > > небольших рекомендаций.
> > > 
> > > К сожалению, все собранные пакеты - простые, либо не содержат сборки, либо
> > > эта сборка простая.
> > > 
> >  Изначально такая цель ставилась, научиться собирать простые пакеты такие
> > как preinstall.
> 
> Эта цель была достигнута, я согласен.
> 
> (Ответ для Leonid Krivoshein на комментарий #61)
> > Достаточно ли этого для закрытия бага или требуется что-то ещё?
> 
> С учётом всего вышенаписанного это решать Дмитрию.

С одной стороны, изначально была поставлена очень низкая планка, с другой стороны, эта планка была взята.  Кандидат способен самостоятельно собирать простые пакеты, и совершенно не претендует на сборку сложных.  Достаточно ли этого для вступления в ALT?  Это очень необычный расклад, не припоминаю ничего подобного с тех пор, как была введена формальная процедура вступления.

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

(In reply to Dmitry V. Levin from comment #66)
> Кандидат способен самостоятельно собирать
> простые пакеты, и совершенно не претендует на сборку сложных.
Сложность решаемых задач бывает и за пределами пакетной сборки. То, что оседает в спеке, может быть квинтэссенцией очень непростой работы, но зачастую полезной для ALT.

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

> Достаточно ли этого для вступления в ALT? Это очень необычный расклад,
> не припоминаю ничего подобного с тех пор, как была введена формальная
> процедура вступления.
Анна овладела тремя навыками -- сборкой с нуля простых пакетов, простые изменения пакетов, включая прикладывание патчей и простейшее бэкпорирование путём копирования. Кандидат показал способность освоить навык. Он может освоить и другой навык, если это потребуется. Ведь нигде не говорится, какой сборочной сложности должен быть пакет. Говорят, в 2007 все кандидаты собирали один и тот же пакет, он никогда не доезжал до Сизифа. К слову, нынешнюю планку я бы точно не взял, и сложность моих пакетов почти всегда не в хитросплетениях пакетной сборки.

> Оставляю этот комментарий здесь, чтобы дать на него ссылку коллегам и
> спросить их мнение.
Спасибо! Я начал было писать письмо, чтобы помочь систематизировать ряд вопросов, но так и не нашёл подходящих коротких формулировок.

Однако вспомнился случай, когда мы (еле собирающие пакеты) быстро и просто помогли маинтейнеру, собирающему такие пакеты, как LibreOffice и Chromium-gost. Просто, у всех в тиме должна быть своя специализация, сборка пакетов -- ещё не вся разработка, другие сильные стороны тоже могут быть полезны ALT.

Джойн нужен не только для того, чтобы научились собирать, главная цель -- понимать друг друга, учиться друг у друга и пользоваться единым инструментом, едиными стандартами. Злоупотреблять только полученными возможностями никогда не надо. Т.е. можно это всё отрегулировать по уму, вопрос организационный.

(Ответ для Dmitry V. Levin на комментарий #66)
> С одной стороны, изначально была поставлена очень низкая планка, с другой
> стороны, эта планка была взята.  Кандидат способен самостоятельно собирать
> простые пакеты, и совершенно не претендует на сборку сложных.  Достаточно ли
> этого для вступления в ALT?
Брр, а тебя точно не смущает, что моя первая сборка в альте была по сути чем-то вроде замены /usr/local/apache/log/access_log на /var/log/httpd/access_log в пакетном webalizer.conf? :-)

Мне кажется, пора уже RESOLVED FIXED здесь увидеть.

(In reply to Michael Shigorin from comment #68)
> (Ответ для Dmitry V. Levin на комментарий #66)
> > С одной стороны, изначально была поставлена очень низкая планка, с другой
> > стороны, эта планка была взята.  Кандидат способен самостоятельно собирать
> > простые пакеты, и совершенно не претендует на сборку сложных.  Достаточно ли
> > этого для вступления в ALT?
> Брр, а тебя точно не смущает, что моя первая сборка в альте была по сути
> чем-то вроде замены /usr/local/apache/log/access_log на
> /var/log/httpd/access_log в пакетном webalizer.conf? :-)

Нынешний порядкок вступления был принят вследствие снижения уровня готовности кандидатов к самостоятельной сборке пакетов.

(In reply to Anna from comment #0)
> Created attachment 8903 [details]
> ssh pubkey
> 
> Псевдоним: Khab
> Email: anna.khrustova@gmail.com
> Ментор: cas@ , klark@
> Цель: Научиться собирать пакеты.

У меня остался один вопрос:
теперь, когда над вами больше не довлеет то, что довлело раньше,
вы всё ещё хотите завершить процедуру вступления в ALT?

(Ответ для Dmitry V. Levin на комментарий #70)
> (In reply to Anna from comment #0)
> > Created attachment 8903 [details] [подробности] [details]
> > ssh pubkey
> > 
> > Псевдоним: Khab
> > Email: anna.khrustova@gmail.com
> > Ментор: cas@ , klark@
> > Цель: Научиться собирать пакеты.
> 
> У меня остался один вопрос:
> теперь, когда над вами больше не довлеет то, что довлело раньше,
> вы всё ещё хотите завершить процедуру вступления в ALT?

Да.

Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!

(Ответ для Gleb F-Malinovskiy на комментарий #72)
> Адрес подписан на devel@.
> Пользователь добавлен в группу мейнтейнеров.
> 
> Желаю удачного мейнтейнерства!

Анна, добро пожаловать в тим! :)

(In reply to Anna from comment #71)
> (Ответ для Dmitry V. Levin на комментарий #70)
> > вы всё ещё хотите завершить процедуру вступления в ALT?
> Да.
Анна, мои поздравления! Успешных ALT-build'ов! :-)