27419 2012-06-07 20:40:30 +0400 add src.list from autoimports.altlinux.org to the lists checked 2024-06-10 11:07:29 +0300 1 1 2 Infrastructure Infrastructure girar unspecified all Linux NEW ftp://autoimports.altlinux.org/pub/ALTLinux/autoimports/Sisyphus/files/list/src.list P3 enhancement --- 1 viy placeholder arbars asy bystrov.arterm enp evg glebfm grenka ildar lav ldv legion mike neff real.altlinux.org rider zerg nobody oldest_to_newest 131699 0 viy 2012-06-07 20:40:30 +0400 в girar проверяется, (в gb-task-repo-vercheck?) чтобы поступивший пакет был не моложе уже имеющихся в бранчах пакетов. Так как autoimports.altlinux.org скоро станет публичным расширением Сизифа, прошу добавить в эту проверку и пакеты из autoimports. src.list для пакетов из autoimports доступен по адресу: http://autoimports.altlinux.org/pub/ALTLinux/autoimports/Sisyphus/files/list/src.list 131716 1 viy 2012-06-08 14:07:54 +0400 Проблема актуальна: люди уже начинают интересоваться пакетами из autoimports, а раз эти пакеты уже могут стоять у пользователей, то нужно проверять, что пакеты, заливаемые в Сизиф, вытесняют пакеты из autoimports. 131717 2 ldv 2012-06-08 14:14:54 +0400 Прежде чем пакеты из autoimports начнут влиять на правила приема пакетов в Сизиф и бранчи, надо зафиксировать правила, по которым пакеты попадают в autoimports. Иначе получается, что на пакеты в Сизиф и бранчи накладываются достаточно произвольные ограничения, вплоть до невозможности отправить пакет в бранч, поскольку, с одной стороны, он не должен быть свежее сизифного, и, с другой стороны, он должен быть свежее импортированного. 131719 3 viy 2012-06-08 14:31:01 +0400 (В ответ на комментарий №2) > надо зафиксировать правила, по которым пакеты попадают в autoimports. Сейчас бранчей в autoimports нет; таким образом, на пакеты в бранчах они не влияют. В момент форка p7 из Сизифа я хочу сделать аналогичный форк и в autoimports, получив, таким образом, autoimports/p7. Тогда и для пакетов в p7/branch необходимо будет проверять, что они старше, чем пакеты в autoimports/p7. Ограничений же, чтобы пакет в branch был моложе пакета в autoimports/Sisyphus, лучше не накладывать. С другой стороны, это не слишком сильное ограничение: раз пакет в autoimports, то его нет в настоящем сизифе и его можно смело туда залить. 131720 4 viy 2012-06-08 14:38:05 +0400 Т.е. избыточных ограничений лучше не накладывать - для этого для проверки по версиям снизу использовать смерженный список пакетов, Sisyphus/classic+Sisyphus/autoimports, а для проверки в бранчах по версиям сверху использовать чистый список пакетов Sisyphus/classic. Также, удаление пакетов из Sisyphus/autoimports будет проводиться по крону раз в сутки, поэтому нормально, что src.list для пакетов из autoimports может содержать names пакетов, которые уже залиты в сизиф. Поэтому мерж src.list из autoimports и из Sisyphus/classic надо делать аккуратно. 133886 5 viy 2012-10-12 10:34:14 +0400 Проблема по прежнему актуальна, в Сизиф заливаются пакеты с релизом меньше чем в autoimports (последний пример perl-Devel-Autoflush) что может создавать проблемы с обновлением из Сизифа. 143786 6 zerg 2013-11-14 15:23:30 +0400 (В ответ на комментарий №5) > в Сизиф заливаются пакеты с релизом меньше чем в autoimports Я бы сказал наоборот, в autoimports заливаются пакеты с заведомо большим релизом, чем нужно. 144116 7 mike 2013-12-07 05:05:41 +0400 Так меньше alt1_* не получится, т.к. alt0_* не сбэкпортится при надобности. 144141 8 zerg 2013-12-09 16:45:52 +0400 (В ответ на комментарий №7) > Так меньше alt1_* не получится, т.к. alt0_* не сбэкпортится при надобности. Нужно получать такие, чтоб сбэкпортился. 155988 9 asy 2016-04-06 13:32:28 +0300 Может, пока суть да дело, хотябы предупреждение в лог сборки выдавать ? А то, бывает, пост фактум узнаёшь, что пакет-то уже был в autoimports. 171775 10 grenka 2018-06-09 13:52:38 +0300 Проблема по-прежнему актуальна: python-module-apipkg 185805 11 bystrov.arterm 2019-11-26 15:34:47 +0300 Подтверждаю актуальность, пакет eureka: https://packages.altlinux.org/ru/sisyphus/srpms/eureka 193270 12 legion 2020-10-16 03:21:46 +0300 2viy я считаю не очень хорошим подходом рассылать спам про то, что в вашем стороннем компоненте пакет убежал вперёд из-за недоразвитости робота и призывать проголосовать за этот "баг". The RPM package perl-Search-Xapian-1.2.25.2-alt1.src.rpm you uploaded to Sisyphus is not greater than the RPM package perl-Search-Xapian-1.2.25.2-alt5_7.src.rpm Please, visit https://bugzilla.altlinux.org/show_bug.cgi?id=27419 and vote for the bug. https://src.fedoraproject.org/rpms/perl-Search-Xapian/blob/master/f/perl-Search-Xapian.spec : %changelog * Tue Jul 28 2020 Fedora Release Engineering <releng@fedoraproject.org> - 1.2.25.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Tue Jun 23 2020 Jitka Plesnikova <jplesnik@redhat.com> - 1.2.25.2-6 - Perl 5.32 rebuild * Thu Jan 30 2020 Fedora Release Engineering <releng@fedoraproject.org> - 1.2.25.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Fri Jul 26 2019 Fedora Release Engineering <releng@fedoraproject.org> - 1.2.25.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Fri May 31 2019 Jitka Plesnikova <jplesnik@redhat.com> - 1.2.25.2-3 - Perl 5.30 rebuild * Sat Feb 02 2019 Fedora Release Engineering <releng@fedoraproject.org> - 1.2.25.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sun Sep 23 2018 Emmanuel Seyman <emmanuel@seyman.fr> - 1.2.25.2-1 - Update to 1.2.25.2 Очень мило, что ваш робот сделал эту работу и упаковал столь важные изменения, но я отказываюсь учитывать циклы пересборки в fedora в своей работе в сизифе. Я вполне уверен, что эти релизы бессмысленны для сизифа. Более того, вы и сами поднимаете релиз: %changelog * Thu Oct 01 2020 Cronbuild Service <cronbuild@altlinux.org> 1.2.25.2-alt5_7 - rebuild to get rid of unmets * Thu Oct 01 2020 Igor Vlasenko <viy@altlinux.ru> 1.2.25.2-alt4_7 - rebuild with perl 5.30 * Tue Jan 29 2019 Cronbuild Service <cronbuild@altlinux.org> 1.2.25.2-alt3_1 - rebuild to get rid of unmets * Tue Jan 29 2019 Cronbuild Service <cronbuild@altlinux.org> 1.2.25.2-alt2_1 - rebuild to get rid of unmets (Кстати, предлагаю упростить запись и писать: fix. К чему делать настолько детальное описание сделанных изменений?) Если ввести предлагаемую проверку, то отправка нового пакета в сизиф превратится в рулетку или же придётся сначала сверяться с вашим репозиторием, чтобы выбрать "правильный" релиз. Я считаю, что это совершенно неправильным подходом. autoimports не может иметь приоритет над сизифом. Vote: -1 P.S. пожалуйста, добавьте меня в blacklist рассылки таких писем. 193287 13 viy 2020-10-16 13:10:36 +0300 > Если ввести предлагаемую проверку, то отправка нового пакета в сизиф > превратится в рулетку или же придётся сначала сверяться с вашим > репозиторием, чтобы выбрать "правильный" релиз. Я считаю, что это совершенно > неправильным подходом. autoimports не может иметь приоритет над сизифом. Гм. а как же больба за качество в Сизифе? Если Вы читали недавнее письмо lav@ https://lists.altlinux.org/pipermail/devel/2020-October/212112.html , там lav@ предлагает вынести нестабильную разработку в репозитории - карманы над Сизифом. И при переносе пакетов из нестабильных карманов в Сизиф естественное требование, чтобы релизы в Сизифе были БОЛЬШЕ, чем в репозиториях - карманах. autoimports это пока единственный наш нестабильный карман, только потому, что сейчас в сборочнице поддержки карманов нет. Как только появится, то должна будет появиться и поддержка проверки релизов, чтобы выкладка в Сизиф не была меньше пакетов в карманах, иначе мы быдем стрелять в ногу пользователям, ставившим пакеты из нестабильных карманов. Это общее правило, зачем делать из него исключение для autoimports? > Если ввести предлагаемую проверку, то отправка нового пакета в сизиф > превратится в рулетку или же придётся сначала сверяться с вашим репозиторием, > чтобы выбрать "правильный" релиз. Гм. при отправке "нового" perl-*.src.rpm в Сизиф рулетки нет. На 99.99% можно быть уверенным, что такой пакет уже есть в autoimports. Но вообще сборочница _уже_ проверяет релизы на сравнение с более ранними ветвями, и не принимает пакет, если такое имя уже есть. Так что элемент рулетки уже присутствует. В случае с реализацией нестабильных карманов в сборочнице, это только усугубится. Имеет смысл добавить в girar отдельную команду, которая покажет последнюю версию-релиз по всем бранчам и карманам, ассоциированную с данным имененем, что-то вроде ssh girar find-latest <name>. 193288 14 viy 2020-10-16 13:11:26 +0300 (Ответ для viy на комментарий #13) > Но вообще сборочница _уже_ проверяет релизы на сравнение с более ранними > ветвями, и не принимает пакет, если такое имя уже есть с большим релизом, естественно. 193290 15 legion 2020-10-16 14:01:35 +0300 (Ответ для viy на комментарий #13) > > Если ввести предлагаемую проверку, то отправка нового пакета в сизиф > > превратится в рулетку или же придётся сначала сверяться с вашим > > репозиторием, чтобы выбрать "правильный" релиз. Я считаю, что это совершенно > > неправильным подходом. autoimports не может иметь приоритет над сизифом. > > Гм. а как же больба за качество в Сизифе? Расскажите, как представленные выше релизы в федоре повышают качество в сизифе ? > Если Вы читали недавнее письмо lav@ > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html , > там lav@ предлагает вынести нестабильную разработку в репозитории - карманы > над Сизифом. Вы говорите так будто с его идеей все согласились, хотя это не так и были высказаны обоснованные мысли, что предложенное делать не требуется. > И при переносе пакетов из нестабильных карманов в Сизиф > естественное требование, чтобы релизы в Сизифе были БОЛЬШЕ, чем в > репозиториях - карманах. > > autoimports это пока единственный наш нестабильный карман, только потому, > что сейчас в сборочнице поддержки карманов нет. Как только появится, то > должна будет появиться и поддержка проверки релизов, чтобы выкладка в Сизиф > не была меньше пакетов в карманах, иначе мы быдем стрелять в ногу > пользователям, ставившим пакеты из нестабильных карманов. Возможно, у вас в подвале есть машина времени и вы уже живёте в будущем, где карманы уже есть. На данный момент никих карманов в сизифе нет. Я вполне уверен, что если они будут когда-нибудь реализованы, то карманы не будут похожи на autoimports. Пока же карманы это только фантазии и я не хочу их обсуждать. > Это общее правило, зачем делать из него исключение для autoimports? Не понимаю о чём вы. > > Если ввести предлагаемую проверку, то отправка нового пакета в сизиф > > превратится в рулетку или же придётся сначала сверяться с вашим репозиторием, > чтобы выбрать "правильный" релиз. > > Гм. при отправке "нового" perl-*.src.rpm в Сизиф рулетки нет. > На 99.99% можно быть уверенным, что такой пакет уже есть в autoimports. Пока эти пакеты не в сизифе их нет. Собранный в сизиф пакет может отличаться как по составу файлов, так и по включённым опциям от того, что лежит в autoimports. То что вы предлагаете делать в письмах счастья просто некорректно по отношению к пользователям вашего же autoimports. У них произойдёт подмена одного пакета другим с другим содержимым. > Но вообще сборочница _уже_ проверяет релизы на сравнение с более ранними > ветвями, и не принимает пакет, если такое имя уже есть. Так что элемент > рулетки уже присутствует. Это не рулетка а коллизия в пределах одного репозитория, которая решается в пределах git.altlinux.org/{gears,srpms}. Все версии там, все имена там. Никакой рулетки нет. А вот когда у вас N произвольных сторонних репозиториев с дупами по именам, то сборка даже нового релиза уже существующего пакета в сизиф превращается в угадайку: в каком репозитории какая версия пакета под таким же именем (и дай бог с таким же содержимым) и не собирается ли там сейчас altI+1, которая сломает ваш релиз. > ssh girar find-latest <name>. В обсуждении карманов буду принимать участие только когда будет RFC на карманы. В самой этой идее есть ряд технических проблем. P.S. Я получил уже второе письмо от ваших роботов с практически идентичным содержимым: Autoimports: the package you uploaded to incoming is not greater Fedoraimport: the package you uploaded to incoming is not greater прекратите пожалуйста. Я не подписывался на эту рассылку и на участие в autoimports. 193291 16 viy 2020-10-16 14:21:59 +0300 (Ответ для Alexey Gladkov на комментарий #15) > P.S. Я получил уже второе письмо от ваших роботов с практически идентичным > содержимым: гм. Я вмешался и руками удалил. Это, кстати, кусок работы, больший, чем если бы вам залить perl-Search-Xapian-1.2.25.2-alt6 :( 193292 17 legion 2020-10-16 14:32:06 +0300 (Ответ для viy на комментарий #16) > гм. Я вмешался и руками удалил. Это, кстати, кусок работы, больший, > чем если бы вам залить perl-Search-Xapian-1.2.25.2-alt6 :( Не нужно меня упрекать. Вы сами придумали себе проблемы. 193293 18 mcpain 2020-10-16 14:32:33 +0300 Вынужден согласиться с Алексеем и присоединиться к его требованиям не рассылать спам ментейнерам Сизифа. 193294 19 viy 2020-10-16 14:56:10 +0300 К сожалению, я часто сталкивался с ситуацией "поматросил и бросил" по отношению к пакетам в autoimports. Понадобился пакет, его быстро переложили в Сизиф и забили на обновления. Потом такой пакет мешает обновлять другие пакеты perl. 193295 20 rider 2020-10-16 15:12:15 +0300 а вот в обновлении в sisyphus уже могли бы подключиться роботы. только большая просьба при этом не ломать и не захламлять структуру спек-файла. если нужно положить служебную информацию, то это можно сделать в .gear/ 193296 21 legion 2020-10-16 15:14:43 +0300 (Ответ для viy на комментарий #19) > К сожалению, я часто сталкивался с ситуацией "поматросил и бросил" по > отношению к пакетам в autoimports. Понадобился пакет, его быстро переложили > в Сизиф и забили на обновления. Потом такой пакет мешает обновлять другие > пакеты perl. Это общая проблема любого репозитория и не специфична для autoimports. Эта проблема в равной степени относится к модулям интерпретаторов и клиентам библиотек. Вы это к чему вспомнили ? К тому, что ваш робот обновляет пакеты лучше, чем мантейнер, а мантейнеры мешают его работе ? 193297 22 legion 2020-10-16 15:17:58 +0300 (Ответ для Anton Farygin на комментарий #20) > а вот в обновлении в sisyphus уже могли бы подключиться роботы. > только большая просьба при этом не ломать и не захламлять структуру > спек-файла. > если нужно положить служебную информацию, то это можно сделать в .gear/ У нас же есть некий cronbuild. 193298 23 viy 2020-10-16 15:25:21 +0300 Добавляю Виталия в сс: так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в https://lists.altlinux.org/pipermail/devel/2020-October/212112.html, 193299 24 legion 2020-10-16 15:32:01 +0300 (Ответ для viy на комментарий #23) > Добавляю Виталия в сс: > так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html, Лично я не буду обсуждать этот оффтопик в этой баге. 193300 25 viy 2020-10-16 15:40:24 +0300 (Ответ для viy на комментарий #23) > Добавляю Виталия в сс: > так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html, эта тема пример следующих вопросов, связанных х с нестабильными карманами: 1) нестабильные карманы нужно добавлять для проверки, не ниже ли релиз в Сизифе (бранче) релиза в нестабильном кармане, чтобы обеспечить корректное обновление пользователя кармана до Сизифа. 2) не урегулированная, порождает споры и конфликты, когда майнтайнер А сопровождает пакет в нестабильном кармане, а майнтайнер В выкладывает этот пакет в Сизиф (бранч). В данном случае еще и пример странного, когда майнтайнер В, выложив пакет майнтайнера А, еще и предъявляет претензии майнтайнеру А :( 193302 26 lav 2020-10-16 18:05:12 +0300 (Ответ для viy на комментарий #25) > (Ответ для viy на комментарий #23) > > Добавляю Виталия в сс: > > так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в > > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html, > > эта тема пример следующих вопросов, связанных х с нестабильными карманами: > 1) нестабильные карманы нужно добавлять для проверки, не ниже ли релиз в > Сизифе (бранче) релиза в нестабильном кармане, чтобы обеспечить > корректное обновление пользователя кармана до Сизифа. Как я понимаю, пакет в autoimports должен иметь релиз вида alt0.x Тогда при сборке той же версии мантейнером сделанный вручную пакет будет иметь приоритет. Поскольку в autoimports далее не будет обновляться/собираться этот пакет, ситуация, когда в autoimports появится пакет с большей версией, не случится. (А это так работает сейчас?) > 2) не урегулированная, порождает споры и конфликты, когда майнтайнер А > сопровождает пакет в нестабильном кармане, а майнтайнер В выкладывает этот > пакет в Сизиф (бранч). На мой взгляд, выкладывание такого пакета в Сизиф (бранч) (т.е. выкладывание из кармана) должно приводить к автоматическому удалению кармана. Соответственно, такая операция должна быть требовать approve от всех, у кого в кармане есть такой пакет. > В данном случае еще и пример странного, когда майнтайнер В, выложив пакет > майнтайнера А, еще и предъявляет претензии майнтайнеру А :( репозиторий мантейнера A не принимается всерьёз... Всё это тема не для обсуждения в баге, конечно. 215153 27 arbars 2022-09-21 22:58:50 +0300 Очередной пакет, причём с пылу, с жару: https://packages.altlinux.org/ru/sisyphus/srpms/woof/ Причём не только с autoimports, но и с mgaimport. 241008 28 neff 2024-02-01 13:56:47 +0300 Та же история с пакетом: https://packages.altlinux.org/ru/sisyphus/srpms/dexed/ И autoimports и mgaimport. 241012 29 rider 2024-02-01 15:26:09 +0300 В автоимпортах, на мой взгляд, кривая версия пакета была. Вообще тащить к себе наследование версий автоматически-собранных пакетов - идея не очень. Предлагаю просто игнорировать пакеты из других дистрибутивов. 247457 30 mike 2024-06-10 11:07:29 +0300 (Ответ для Michael Shigorin на комментарий #7) > Так меньше alt1_* не получится, т.к. alt0_* не сбэкпортится при надобности. Это соображение в целом устарело; возможно, в autoimports стоит класть alt0_* по умолчанию.