* [devel] pkgconfiglib.req @ 2007-08-28 17:11 Alexey M. Tourbin 2007-08-28 19:55 ` Alexey Tourbin ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Alexey M. Tourbin @ 2007-08-28 17:11 UTC (permalink / raw) To: devel Иногда бывает так, что с новым devel-пакетом перестает что-то собираться из-за добавившихся библиотек для линковки в *.pc файле. Здесь есть два подхода. Первый подход -- это, если добавленные библиотеки на самом деле излишни, то мы получаем ценную информацию, чтобы дать кому-то подзатыльник (точнее, чтобы убрать ненужные библиотеки из Libs в новом пакете). С другой стороны, раздача подзатыльников методом поломки репозитария не кажется мне вполне технологичным развлечением. Второй подход -- это, если добавленные библиотеки на самом деле не лишние, добить новых *-devel зависимостей на соответствующие пакеты. Кроме всего прочего, этот подход относительно легко перепоручить автоматике. Поэтому предлагаю замыкать зависимости между *-devel пакетами по содержимому поля Libs в *.pc файлах. Алгоритм, который реализован ниже, не слишком точно мимикрирует перебор путей в ld (в частности, *.a библиотеки не просматриваются). Тем не мене, мне пока не приходит в голову конфигурация, даже, допустим, патологическая, при которой может получиться неправильный результат. ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ В СТАТУС "ДЛЯ *-devel ПАКЕТОВ". Уважаемые товарищи maintaner'ы! Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще, до тех пор, пока он кому-нибудь не понадобится. В своей хост-системе я обнаружил 2 *.pc файла из не-devel пакетов, которые имеют некоторые проблемы при попытке их обработки: $ rpm -qf /usr/lib/pkgconfig/libgdiplus.pc libgdiplus-1.2.4-alt1 $ rpm -qf /usr/lib/pkgconfig/avahi-qt3.pc libavahi-qt3-0.6.20-alt2 $ Некоторые подробности на этот счет приведены ниже. Changelog since `4.0.4-alt77-67-g63ac11f' follows: commit 0e085c0a8388be44d06afe1a1f4b88aa8895ad2e Author: Alexey Tourbin <at@altlinux> Date: Tue Aug 28 20:10:35 2007 +0400 pkgconfiglib.req: new pkgconfig.req mode (makes dependencies on Libs) This will grab libraries from ^Libs: clause and map each library to rpm dependency, which is typically lib*-devel package. $ grep ^Libs: /usr/lib/pkgconfig/directfb.pc Libs: -ldirectfb -lpthread -ldl -lz $ It works like this: $ ln -s pkgconfig.req.in scripts/pkgconfiglib.req.in $ scripts/pkgconfiglib.req.in -v /usr/lib/pkgconfig/directfb.pc pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libdirectfb.so -> libdirectfb-devel libdirectfb-devel pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libz.so -> zlib-devel zlib-devel pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libfusion.so -> libdirectfb-devel libdirectfb-devel pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libdirect.so -> libdirectfb-devel libdirectfb-devel pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libpthread.so -> glibc-devel (skip) pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libdl.so -> glibc-devel (skip) $ Some minor problems: $ scripts/pkgconfiglib.req.in /usr/lib/pkgconfig/*.pc >/dev/null pkgconfiglib.req.in: /usr/lib/pkgconfig/avahi-qt3.pc: cannot find libavahi-qt3.so library path (skip) pkgconfiglib.req.in: /usr/lib/pkgconfig/libgdiplus.pc: cannot find libexif.so library path (skip) pkgconfiglib.req.in: /usr/lib/pkgconfig/valgrind.pc: cannot find libcoregrind.so library path (skip) pkgconfiglib.req.in: /usr/lib/pkgconfig/valgrind.pc: cannot find libvex.so library path (skip) pkgconfiglib.req.in: /usr/lib/pkgconfig/valgrind.pc: cannot find libgcc.so library path (skip) $ Full diff since `4.0.4-alt77-67-g63ac11f' follows: diff --git a/rpm-4_0.spec b/rpm-4_0.spec index a7ace2a..c167300 100644 --- a/rpm-4_0.spec +++ b/rpm-4_0.spec @@ -474,6 +474,7 @@ fi %rpmattr %_rpmlibdir/lib.* %rpmattr %_rpmlibdir/pam.* %rpmattr %_rpmlibdir/pkgconfig.* +%rpmattr %_rpmlibdir/pkgconfiglib.* %rpmattr %_rpmlibdir/shell.* %rpmattr %_rpmlibdir/shebang.* %rpmattr %_rpmlibdir/static.* diff --git a/scripts/Makefile.am b/scripts/Makefile.am index d93d477..e58108a 100644 --- a/scripts/Makefile.am +++ b/scripts/Makefile.am @@ -51,4 +51,6 @@ config_SCRIPTS = \ install-data-local: @LN_S@ pkgconfig.req $(DESTDIR)$(configdir)/pkgconfig.prov + @LN_S@ pkgconfig.req $(DESTDIR)$(configdir)/pkgconfiglib.req @LN_S@ pkgconfig.req.files $(DESTDIR)$(configdir)/pkgconfig.prov.files + @LN_S@ pkgconfig.req.files $(DESTDIR)$(configdir)/pkgconfiglib.req.files diff --git a/scripts/pkgconfig.req.in b/scripts/pkgconfig.req.in index 37391d4..95d0210 100755 --- a/scripts/pkgconfig.req.in +++ b/scripts/pkgconfig.req.in @@ -58,8 +58,55 @@ PkgconfigProv() done } +PkgconfigLibReq() +{ + local f="$1" l L; shift + l=$(pkg-config --print-errors --libs-only-l "$f") || Fatal "failed to process $f" + L=$(pkg-config --print-errors --libs-only-L "$f") || Fatal "failed to process $f" + l=$(echo '' $l |sed -e 's/ -l/ /g') + L=$(echo '' $L |sed -e 's/ -L/ /g') + local lib libdir + for lib in $l; do + lib=lib$lib.so + if [ -n "${RPM_BUILD_ROOT-}" ]; then + for libdir in $L "$RPM_LIBDIR"; do + libdir=${libdir%/} + [ -f "$RPM_BUILD_ROOT$libdir/$lib" ] || continue + # The library is under RPM_BUILD_ROOT. + # Nothing is required. Do next lib. + Verbose "$f: $lib -> \$RPM_BUILD_ROOT$libdir/$lib (skip)" + continue 2 + done + fi + for libdir in $L "$RPM_LIBDIR"; do + libdir=${libdir%/} + [ -f "$libdir/$lib" ] || continue + # The library is found in the host system. + # Generate rpm dependency and do next lib. + local pkg n + pkg=$(rpmquery --whatprovides --queryformat='%{NAME}\n' "$libdir/$lib" |sort -u) + n=$(set -- $pkg; echo $#) + if [ "$pkg" = glibc-devel ]; then + Verbose "$f: $lib -> $pkg (skip)" + elif [ $n -eq 1 ]; then + Verbose "$f: $lib -> $pkg" + printf '%s\n' "$pkg" + elif [ $n -gt 1 ]; then + Info "$f: $libdir/$lib provided by:$(echo '' $pkg)" + Info "$f: $lib -> $libdir/$lib (raw, ambiguous)" + printf '%s\n' "$libdir/$lib" + else + Info "$f: cannot map $lib to rpm dependency (skip)" + fi + continue 2 + done + Info "$f: cannot find $lib library path (skip)" + done +} + case "${0##*/}" in pkgconfig.req*) ArgvFileAction PkgconfigReq "$@" ;; pkgconfig.prov*) ArgvFileAction PkgconfigProv "$@" ;; + pkgconfiglib.req*) ArgvFileAction PkgconfigLibReq "$@" ;; *) Fatal "req/prov method not recognized" ;; esac ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-08-28 17:11 [devel] pkgconfiglib.req Alexey M. Tourbin @ 2007-08-28 19:55 ` Alexey Tourbin 2007-08-28 20:12 ` [devel] /usr/lib/pkgconfig vs noarch Dmitry V. Levin ` (2 more replies) 2007-08-29 13:51 ` Igor Zubkov 2007-09-16 21:17 ` Michael Shigorin 2 siblings, 3 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-08-28 19:55 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 9751 bytes --] On Tue, Aug 28, 2007 at 09:11:00PM +0400, Alexey M. Tourbin wrote: > Иногда бывает так, что с новым devel-пакетом перестает что-то собираться > из-за добавившихся библиотек для линковки в *.pc файле. Здесь есть два > подхода. Первый подход -- это, если добавленные библиотеки на самом > деле излишни, то мы получаем ценную информацию, чтобы дать кому-то > подзатыльник (точнее, чтобы убрать ненужные библиотеки из Libs в новом > пакете). С другой стороны, раздача подзатыльников методом поломки > репозитария не кажется мне вполне технологичным развлечением. > > Второй подход -- это, если добавленные библиотеки на самом деле не > лишние, добить новых *-devel зависимостей на соответствующие пакеты. > Кроме всего прочего, этот подход относительно легко перепоручить > автоматике. > > Поэтому предлагаю замыкать зависимости между *-devel пакетами по > содержимому поля Libs в *.pc файлах. Взялся проанализировать содержимое noarch пакетов. $ pwd /ALT/Sisyphus/files/noarch/RPMS $ rpmfile . |grep $'\\.pc\t' gnome-doc-utils-0.10.3-alt2.noarch.rpm /usr/share/pkgconfig/gnome-doc-utils.pc 100644 ASCII text gnome-doc-utils-0.10.3-alt2.noarch.rpm /usr/share/pkgconfig/xml2po.pc 100644 ASCII text gnome-icon-theme-2.18.0-alt1.noarch.rpm /usr/share/pkgconfig/gnome-icon-theme.pc 100644 ASCII English text gnome-mime-data-2.18.0-alt1.noarch.rpm /usr/share/pkgconfig/gnome-mime-data-2.0.pc 100644 ASCII text gtk-doc-1.8-alt1.noarch.rpm /usr/share/pkgconfig/gtk-doc.pc 100644 ASCII text i386-mingw32msvc-SDL-devel-1.2.11-alt1.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/sdl.pc 100644 ASCII text i386-mingw32msvc-libogg-devel-1.1.2-alt3.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/ogg.pc 100644 ASCII text i386-mingw32msvc-libpng-devel-1.2.8-alt2.noarch.rpm /usr/lib/pkgconfig/i386-mingw32msvc-libpng.pc 120777 symbolic link to `i386-mingw32msvc-libpng12.pc' i386-mingw32msvc-libpng-devel-1.2.8-alt2.noarch.rpm /usr/lib/pkgconfig/i386-mingw32msvc-libpng12.pc 100644 ASCII text i386-mingw32msvc-libssl-devel-0.9.8a-alt1.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/libcrypto.pc 100644 ASCII text i386-mingw32msvc-libssl-devel-0.9.8a-alt1.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/libssl.pc 100644 ASCII text i386-mingw32msvc-libssl-devel-0.9.8a-alt1.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/openssl.pc 100644 ASCII text i386-mingw32msvc-libvorbis-devel-1.1.0-alt2.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/vorbis.pc 100644 ASCII English text i386-mingw32msvc-libvorbis-devel-1.1.0-alt2.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/vorbisenc.pc 100644 ASCII text i386-mingw32msvc-libvorbis-devel-1.1.0-alt2.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/vorbisfile.pc 100644 ASCII text i386-mingw32msvc-libxml2-devel-2.6.20-alt1.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/libxml-2.0.pc 100644 ASCII text i386-mingw32msvc-libxslt-devel-1.1.14-alt1.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/libexslt.pc 100644 ASCII text i386-mingw32msvc-libxslt-devel-1.1.14-alt1.noarch.rpm /usr/i386-mingw32msvc/lib/pkgconfig/libxslt.pc 100644 ASCII text icon-naming-utils-0.8.2-alt1.noarch.rpm /usr/share/pkgconfig/icon-naming-utils.pc 100644 ASCII English text iso-codes-devel-0.58-alt1.noarch.rpm /usr/share/pkgconfig/iso-codes.pc 100644 ASCII text libice-sharp-devel-3.2.0-alt1.noarch.rpm /usr/lib/pkgconfig/glacier2cs.pc 100644 ASCII text libice-sharp-devel-3.2.0-alt1.noarch.rpm /usr/lib/pkgconfig/iceboxcs.pc 100644 ASCII text libice-sharp-devel-3.2.0-alt1.noarch.rpm /usr/lib/pkgconfig/icecs.pc 100644 ASCII text libice-sharp-devel-3.2.0-alt1.noarch.rpm /usr/lib/pkgconfig/icegridcs.pc 100644 ASCII text libice-sharp-devel-3.2.0-alt1.noarch.rpm /usr/lib/pkgconfig/icepatch2cs.pc 100644 ASCII text libice-sharp-devel-3.2.0-alt1.noarch.rpm /usr/lib/pkgconfig/icestormcs.pc 100644 ASCII text xorg-x11-bitmaps-1.0.1-alt2.1.noarch.rpm /usr/share/pkgconfig/xbitmaps.pc 100644 ASCII text $ Хочу заметить, что в pkgconfig.req.files отбираются только файлы в %_libdir/pkgconfig и /usr/share/pkgconfig, так что /usr/i386-mingw32msvc/**/*.pc не создаст ложных зависимостей, эти файлы просто не будут обрабатываться. ОБРАТИМ ВНИМАНИЕ НА ИСПОЛЬЗОВАНИЕ /usr/lib/pkgconfig/ в noarch пакетах. БУДЕТ ЛИ ЭТО РАБОТАТЬ НА x86_64? [at@hint1 ~]$ hsh --init [at@hint1 ~]$ hsh-install libice-sharp-devel ... [at@hint1 ~]$ hsh-shell --rooter [root@hint1 .in]# grep -i ^name /usr/lib/pkgconfig/icestormcs.pc name = icestormcs Name: ${name} [root@hint1 .in]# pkg-config --print-errors --modversion icestormcs Package icestormcs was not found in the pkg-config search path. Perhaps you should add the directory containing `icestormcs.pc' to the PKG_CONFIG_PATH environment variable No package 'icestormcs' found [root@hint1 .in]# mv /usr/lib/pkgconfig/*.pc /usr/lib64/pkgconfig/ [root@hint1 .in]# pkg-config --print-errors --modversion icestormcs 3.2.0 [root@hint1 .in]# ВОТ ТАК ТАК! В noarch ПАКЕТАХ НЕ ДОЛЖНО БЫТЬ /usr/lib/pkgconfig! Прошу maintainer'а pkg-config прокомментировать эту ситуацию. Теперь делаю такой финт ушами чтобы посмотреть что лежит внутри этих *.pc файлов: $ rpmfile . |grep $'\\.pc\t' |cut -f1 |sort -u |xargs -n1 -I RPM rpmpeek RPM find ./usr -name '*.pc' -exec egrep -iH '^(req|libs)' {} \; ./usr/share/pkgconfig/xml2po.pc:Requires: libxml-2.0 ./usr/share/pkgconfig/gnome-icon-theme.pc:Requires: ./usr/share/pkgconfig/gnome-icon-theme.pc:Libs: ./usr/share/pkgconfig/gnome-mime-data-2.0.pc:Requires: ./usr/share/pkgconfig/gnome-mime-data-2.0.pc:Libs: ./usr/i386-mingw32msvc/lib/pkgconfig/sdl.pc:Requires: ./usr/i386-mingw32msvc/lib/pkgconfig/sdl.pc:Libs: -L${libdir} -lmingw32 -lSDLmain -lSDL -mwindows ./usr/i386-mingw32msvc/lib/pkgconfig/ogg.pc:Requires: ./usr/i386-mingw32msvc/lib/pkgconfig/ogg.pc:Libs: -L${libdir} -logg ./usr/lib/pkgconfig/i386-mingw32msvc-libpng12.pc:Libs: -lpng12 ./usr/lib/pkgconfig/i386-mingw32msvc-libpng.pc:Libs: -lpng12 ./usr/i386-mingw32msvc/lib/pkgconfig/openssl.pc:Requires: ./usr/i386-mingw32msvc/lib/pkgconfig/openssl.pc:Libs: -L${libdir} -lssl -lcrypto -lwsock32 -lgdi32 -lz ./usr/i386-mingw32msvc/lib/pkgconfig/libssl.pc:Requires: ./usr/i386-mingw32msvc/lib/pkgconfig/libssl.pc:Libs: -L${libdir} -lssl -lcrypto -lwsock32 -lgdi32 -lz ./usr/i386-mingw32msvc/lib/pkgconfig/libcrypto.pc:Requires: ./usr/i386-mingw32msvc/lib/pkgconfig/libcrypto.pc:Libs: -L${libdir} -lcrypto -lwsock32 -lgdi32 -lz ./usr/i386-mingw32msvc/lib/pkgconfig/vorbisfile.pc:Requires: vorbis ogg ./usr/i386-mingw32msvc/lib/pkgconfig/vorbisfile.pc:Libs: -L${libdir} -lvorbisfile ./usr/i386-mingw32msvc/lib/pkgconfig/vorbisenc.pc:Requires: vorbis ./usr/i386-mingw32msvc/lib/pkgconfig/vorbisenc.pc:Libs: -L${libdir} -lvorbisenc ./usr/i386-mingw32msvc/lib/pkgconfig/vorbis.pc:Requires: ogg ./usr/i386-mingw32msvc/lib/pkgconfig/vorbis.pc:Libs: -L${libdir} -lvorbis ./usr/i386-mingw32msvc/lib/pkgconfig/libxml-2.0.pc:Requires: ./usr/i386-mingw32msvc/lib/pkgconfig/libxml-2.0.pc:Libs: -L${libdir} -lxml2 -lz -liconv ./usr/i386-mingw32msvc/lib/pkgconfig/libxslt.pc:Requires: libxml-2.0 ./usr/i386-mingw32msvc/lib/pkgconfig/libxslt.pc:Libs: -L${libdir} -lxslt -L/usr/i386-mingw32msvc/lib -lxml2 -lz -liconv ./usr/i386-mingw32msvc/lib/pkgconfig/libexslt.pc:Requires: libxml-2.0 ./usr/i386-mingw32msvc/lib/pkgconfig/libexslt.pc:Libs: -L${libdir} -lexslt -lxslt -L/usr/i386-mingw32msvc/lib -lxml2 -lz -liconv ./usr/share/pkgconfig/icon-naming-utils.pc:Requires: ./usr/share/pkgconfig/icon-naming-utils.pc:Libs: ./usr/lib/pkgconfig/icestormcs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll ./usr/lib/pkgconfig/icestormcs.pc:Requires: icecs = ${version} ./usr/lib/pkgconfig/icepatch2cs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll ./usr/lib/pkgconfig/icepatch2cs.pc:Requires: icecs = ${version} ./usr/lib/pkgconfig/icegridcs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll ./usr/lib/pkgconfig/icegridcs.pc:Requires: icecs = ${version} ./usr/lib/pkgconfig/icecs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll ./usr/lib/pkgconfig/iceboxcs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll ./usr/lib/pkgconfig/iceboxcs.pc:Requires: icecs = ${version} ./usr/lib/pkgconfig/glacier2cs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll ./usr/lib/pkgconfig/glacier2cs.pc:Requires: icecs = ${version} ./usr/share/pkgconfig/xbitmaps.pc:Libs: $ К счастью, библиотек нигде нет (кроме i386-mingw32msvc и mono). Однако интересно, что xml2po.pc (gnome-doc-utils) требует libxml-2.0. Это как раз та проблема семантики pkg-config зависимостей, которую я недвано упоминал. По видимому, смысл в том, что gnome-doc-utils требует пакет xml-utils (который собирается из libxml2). Но, таким образом, ЗАВИСИМОСТИ pkg-config НЕ ЯВЛЯЕТСЯ чисто devel ЗАВИСИМОСТЯМИ для сборки других пакетов. То есть это плохая, допотопная система зависимостей, в которой BuildRequires, Requires: lib%name.so.0 и Requires: lib%name-devel свалено всё в одну кучу. Единственный приемлемый способ отражать эту систему зависимостей в rpm, это переместить все *.pc файлы в *-devel пакеты. Но и в *-devel пакетах в Libs находятся левые библиотеки, которые использовались только для сборки самого этого пакта. Такие библиотеки нужно переносить в Libs.private. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] /usr/lib/pkgconfig vs noarch 2007-08-28 19:55 ` Alexey Tourbin @ 2007-08-28 20:12 ` Dmitry V. Levin 2007-08-28 20:47 ` Alexey Tourbin 2007-08-28 20:29 ` [devel] pkgconfiglib.req Alexey I. Froloff 2007-08-28 20:46 ` Alexey Rusakov 2 siblings, 1 reply; 39+ messages in thread From: Dmitry V. Levin @ 2007-08-28 20:12 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 577 bytes --] On Tue, Aug 28, 2007 at 11:55:29PM +0400, Alexey Tourbin wrote: [...] > ОБРАТИМ ВНИМАНИЕ НА ИСПОЛЬЗОВАНИЕ /usr/lib/pkgconfig/ в noarch пакетах. > БУДЕТ ЛИ ЭТО РАБОТАТЬ НА x86_64? Нет, не будет, поскольку /usr/lib/pkgconfig не входит в список поиска на x86_64, см. pkg-config(1) на тему PKG_CONFIG_PATH. [...] > ВОТ ТАК ТАК! В noarch ПАКЕТАХ НЕ ДОЛЖНО БЫТЬ /usr/lib/pkgconfig! +1 > Прошу maintainer'а pkg-config прокомментировать эту ситуацию. Можно смело добавлять соответствующую проверку в sisyphus_check/rpm-build. Патчи приветствуются. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] /usr/lib/pkgconfig vs noarch 2007-08-28 20:12 ` [devel] /usr/lib/pkgconfig vs noarch Dmitry V. Levin @ 2007-08-28 20:47 ` Alexey Tourbin 2007-08-28 21:07 ` Alexey Tourbin 2007-08-29 15:56 ` Dmitry V. Levin 0 siblings, 2 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-08-28 20:47 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1275 bytes --] On Wed, Aug 29, 2007 at 12:12:18AM +0400, Dmitry V. Levin wrote: > > ВОТ ТАК ТАК! В noarch ПАКЕТАХ НЕ ДОЛЖНО БЫТЬ /usr/lib/pkgconfig! > > +1 > > > Прошу maintainer'а pkg-config прокомментировать эту ситуацию. > > Можно смело добавлять соответствующую проверку в sisyphus_check/rpm-build. > Патчи приветствуются. А вот смотри-ка. Я пересобрал libice-sharp на x86_64 и у него это дело поставилось в /usr/lib64/pkgconfig/. Из этого простого обстоятельства вытекает условие: если noarch пакет на i586 и x86_64 в результате собрался с отличающимся списком файлов (в данном случае с /usr/lib на i586 и /usr/lib64 на x86_64), то он должен получить reject от incoming'а. Эта нехитрая техника решает ЦЕЛЫЙ КЛАСС ПРОБЛЕМ c noarch-пакетам. МЫ НЕ МОЖЕМ ДОБАВИТЬ в sisyphus_check ВСЁ ЗНАНИЕ о том, какие именно (недопустимые) отличия могут появиться при сборке noarch пакетов на разных архитектурах. Мы не можем ждать милостей от природы, так проще взять и сравнить! А природа проста и не роскошествует излишними причинами вещей. :) Раз отличаются значит reject. Я посмотрел документацию legion'а к giter-factory, что-то меня это нисколько не обнадёжило насчет возможности внедрения первичного тестирования перед публикацией. Скорее разочаровало. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] /usr/lib/pkgconfig vs noarch 2007-08-28 20:47 ` Alexey Tourbin @ 2007-08-28 21:07 ` Alexey Tourbin 2007-08-28 21:32 ` [devel] sisyphus_check noarch Alexey Tourbin 2007-09-01 13:12 ` [devel] /usr/lib/pkgconfig vs noarch Денис Смирнов 2007-08-29 15:56 ` Dmitry V. Levin 1 sibling, 2 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-08-28 21:07 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 852 bytes --] On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote: > А вот смотри-ка. Я пересобрал libice-sharp на x86_64 и у него > это дело поставилось в /usr/lib64/pkgconfig/. Из этого простого > обстоятельства вытекает условие: если noarch пакет на i586 и x86_64 > в результате собрался с отличающимся списком файлов (в данном случае > с /usr/lib на i586 и /usr/lib64 на x86_64), то он должен получить > reject от incoming'а. Эта нехитрая техника решает ЦЕЛЫЙ КЛАСС ПРОБЛЕМ > c noarch-пакетам. Кстати, если сравнивать ещё и зависимости, то это решает также проблему, когда в noarch пакетах что-то компилируется, а noarch стоит по недосмотру. Псокольку бинарные зависимости отличаются на '(64bit)'. Собрался сделать новую проверку в sisyphus_check и теперь даже не знаю делать или нет. На другом уровне всё решается гораздо проще. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* [devel] sisyphus_check noarch 2007-08-28 21:07 ` Alexey Tourbin @ 2007-08-28 21:32 ` Alexey Tourbin 2007-09-01 13:12 ` [devel] /usr/lib/pkgconfig vs noarch Денис Смирнов 1 sibling, 0 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-08-28 21:32 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 939 bytes --] On Wed, Aug 29, 2007 at 01:07:23AM +0400, Alexey Tourbin wrote: > Собрался сделать новую проверку в sisyphus_check и теперь даже не знаю > делать или нет. На другом уровне всё решается гораздо проще. Предлагаю сделать две проверки: check_arch_paths -- на non-64 архитектуре не может быть /usr/lib64/*. check_arch_deps -- на noarch архитектуре в Requires не может быть rtld(GNU_HASH). Это минималистичные по сути проверки (философия "мы не можем знать всего") которые однако пытаются "накрыть" чем можно больше. Теперь посмотрим, что произойдёт с noarch пакетом у которого там это дело pkg-config. Если incominger собирает noarch пакеты как на i586, так и на x86_64, то на x86_64 проверка check_arch_paths обломится, потому что arch=noarch. Значит, "накрытие" есть. Теперь, однако, опять всё упирается в логику работы incoming'а. Пропустит ли он noarch пакет, который собрался на i586 и не собрался на x86_64? [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] /usr/lib/pkgconfig vs noarch 2007-08-28 21:07 ` Alexey Tourbin 2007-08-28 21:32 ` [devel] sisyphus_check noarch Alexey Tourbin @ 2007-09-01 13:12 ` Денис Смирнов 1 sibling, 0 replies; 39+ messages in thread From: Денис Смирнов @ 2007-09-01 13:12 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 826 bytes --] On Wed, Aug 29, 2007 at 01:07:23AM +0400, Алексей Турбин wrote: AT> Кстати, если сравнивать ещё и зависимости, то это решает также проблему, AT> когда в noarch пакетах что-то компилируется, а noarch стоит по недосмотру. AT> Псокольку бинарные зависимости отличаются на '(64bit)'. Я правильно понимаю что у noarch пакета в принципе не должно быть зависимости на что-либо (64bit), ибо он должен ставиться хоть на arm, хоть на микрокалькулятор? В этом случае можно обойтись без сравнения -- если noarch пакет при сборке на x86_64 имеет такую зависимость, он неправильный. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- >subversion-1.1.2-alt2 постараюсь в ближайшее время найти это самое время и залить 1.1.3 -- svd in devel@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] /usr/lib/pkgconfig vs noarch 2007-08-28 20:47 ` Alexey Tourbin 2007-08-28 21:07 ` Alexey Tourbin @ 2007-08-29 15:56 ` Dmitry V. Levin 2007-08-29 17:05 ` [devel] giter-factory Alexey Tourbin 1 sibling, 1 reply; 39+ messages in thread From: Dmitry V. Levin @ 2007-08-29 15:56 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 308 bytes --] On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote: [...] > Я посмотрел документацию legion'а к giter-factory, что-то меня это > нисколько не обнадёжило насчет возможности внедрения первичного > тестирования перед публикацией. Скорее разочаровало. Что именно разочаровало? -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* [devel] giter-factory 2007-08-29 15:56 ` Dmitry V. Levin @ 2007-08-29 17:05 ` Alexey Tourbin 2007-08-29 19:29 ` Dmitry V. Levin 2007-09-16 21:13 ` Michael Shigorin 0 siblings, 2 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-08-29 17:05 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 3254 bytes --] On Wed, Aug 29, 2007 at 07:56:32PM +0400, Dmitry V. Levin wrote: > On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote: > [...] > > Я посмотрел документацию legion'а к giter-factory, что-то меня это > > нисколько не обнадёжило насчет возможности внедрения первичного > > тестирования перед публикацией. Скорее разочаровало. > > Что именно разочаровало? Цитата из giter-factory/doc/info.tex: Как только указание получено, репозиторий встаёт в очередь на сборку. Все запросы от разных пользователей сериализуются по времени. Процесс пересборки параллелится по архитектурам, но не по положению в очереди. Такой подход позволяет просто сформировать порядок сборки зависимых пакетов. После удачной пересборки пакет сразу же публикуется. Следующие пакеты из очереди пересобираются уже на новом публичном репозитории. Это я называю "наивная сериализация". Прошёл "очень плохой пакет" и сразу же опубликовался, полсизифа перестало собираться; отозвать сборку задним числом уже нельзя. Преимущество тут только в том, что пересборка/публикация происходит очень быстро, но это просто сопособ очень быстро всё пустить под откос. Даже сейчас "ответственный товарищ, формирующий сизиф", играет созидательную роль, не пропуская (hopefully) вручную "очень плохие пакеты". Просто исключить эту роль, не дав ничего взамен, нельзя. Мое альтернативное видение такое: прошёл пакет и пересобрался. Формируется новый временный сизиф с этим пакетом, и на этом временном сизифе выполняется ряд проверок. Если все проверки прошли успешно, то временный сизиф становится текущим ("коммит"), и очередь продвигается. Если же некоторые проверки не прошли, то пакт ставится на подтверждение вручную. Подтвердить или отменить может а) maintainer б) ответственный товарищ в) чьи пакеты сломались. В детали полтики подтверждения и отмены пока вдаваться не буду. Если предусмотрена схема с подтверждением вручную, тогда вся идея "наивной сериализаци" летит в тартарары. Подтверждение может поступить через час, через два или три, через день, а может и не поступить вовсе (имплицитная отмена). Скорость продвижения очереди не должна зависеть от человеческого фактора, которым является продвижение вручную. Если пакет ставится не подтверждение, то создается "временный бранч" с "временным сизифом". Очередь продвигается с предыдущего состояния, то есть "коммита" в мэйнлайн не происходит. Если приходит подтверждение вручную, то нужно сделать "мёрж" между временным сизифом с проблемным пакетом и текущим хедом мэйнлайна. Получается прозрачная аналогия с гитовскими коммитами: /M merged pkg2 with pkg4 * | confirmed pkg2 | * pkg4 success * | pkg3 problems: please confirm `* pkg2 success * pkg1 success В чем состоит мёрж я сейчас объяснять не буду. Если прошло достаточно много времени, то мёрж уже может стать невозможным. В таком случае pkg2 "ребейсится" на pkg4 (текущий хед мэйнлайна) и его сборка/тестирование проходит заново. Если характеристики после ребейса репозитария получаются не хуже, чем характеристики репозитария до ребейса, то подтверждение считатется действительным. В противном случае генерируется новый запрос на подтверждение. Такие пироги. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 17:05 ` [devel] giter-factory Alexey Tourbin @ 2007-08-29 19:29 ` Dmitry V. Levin 2007-08-29 19:37 ` Alexey Tourbin 2007-09-16 21:13 ` Michael Shigorin 1 sibling, 1 reply; 39+ messages in thread From: Dmitry V. Levin @ 2007-08-29 19:29 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 3533 bytes --] On Wed, Aug 29, 2007 at 09:05:12PM +0400, Alexey Tourbin wrote: > On Wed, Aug 29, 2007 at 07:56:32PM +0400, Dmitry V. Levin wrote: > > On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote: > > [...] > > > Я посмотрел документацию legion'а к giter-factory, что-то меня это > > > нисколько не обнадёжило насчет возможности внедрения первичного > > > тестирования перед публикацией. Скорее разочаровало. > > > > Что именно разочаровало? > > Цитата из giter-factory/doc/info.tex: > > Как только указание получено, репозиторий встаёт в очередь на > сборку. Все запросы от разных пользователей сериализуются по > времени. > > Процесс пересборки параллелится по архитектурам, но не по > положению в очереди. Такой подход позволяет просто сформировать > порядок сборки зависимых пакетов. > > После удачной пересборки пакет сразу же публикуется. Следующие > пакеты из очереди пересобираются уже на новом публичном > репозитории. > > Это я называю "наивная сериализация". Прошёл "очень плохой пакет" > и сразу же опубликовался, полсизифа перестало собираться; отозвать > сборку задним числом уже нельзя. > > Преимущество тут только в том, что пересборка/публикация происходит > очень быстро, но это просто сопособ очень быстро всё пустить под откос. > Даже сейчас "ответственный товарищ, формирующий сизиф", играет > созидательную роль, не пропуская (hopefully) вручную "очень плохие > пакеты". Просто исключить эту роль, не дав ничего взамен, нельзя. > > Мое альтернативное видение такое: прошёл пакет и пересобрался. > Формируется новый временный сизиф с этим пакетом, и на этом временном > сизифе выполняется ряд проверок. Если все проверки прошли успешно, > то временный сизиф становится текущим ("коммит"), и очередь > продвигается. Если же некоторые проверки не прошли, то пакт ставится > на подтверждение вручную. Подтвердить или отменить может а) maintainer > б) ответственный товарищ в) чьи пакеты сломались. В детали полтики > подтверждения и отмены пока вдаваться не буду. > > Если предусмотрена схема с подтверждением вручную, тогда вся идея > "наивной сериализаци" летит в тартарары. Подтверждение может поступить > через час, через два или три, через день, а может и не поступить вовсе > (имплицитная отмена). Скорость продвижения очереди не должна > зависеть от человеческого фактора, которым является продвижение вручную. > Если пакет ставится не подтверждение, то создается "временный бранч" > с "временным сизифом". Очередь продвигается с предыдущего состояния, > то есть "коммита" в мэйнлайн не происходит. Если приходит подтверждение > вручную, то нужно сделать "мёрж" между временным сизифом с проблемным > пакетом и текущим хедом мэйнлайна. Получается прозрачная аналогия > с гитовскими коммитами: > > /M merged pkg2 with pkg4 > * | confirmed pkg2 > | * pkg4 success > * | pkg3 problems: please confirm > `* pkg2 success > * pkg1 success > > В чем состоит мёрж я сейчас объяснять не буду. Если прошло достаточно > много времени, то мёрж уже может стать невозможным. В таком случае pkg2 > "ребейсится" на pkg4 (текущий хед мэйнлайна) и его сборка/тестирование > проходит заново. Если характеристики после ребейса репозитария получаются > не хуже, чем характеристики репозитария до ребейса, то подтверждение > считатется действительным. В противном случае генерируется новый запрос > на подтверждение. > > Такие пироги. Сколько у тебя уйдёт времени, чтобы всё это реализовать? -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 19:29 ` Dmitry V. Levin @ 2007-08-29 19:37 ` Alexey Tourbin 2007-08-29 21:02 ` Alexey Tourbin 0 siblings, 1 reply; 39+ messages in thread From: Alexey Tourbin @ 2007-08-29 19:37 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 210 bytes --] On Wed, Aug 29, 2007 at 11:29:42PM +0400, Dmitry V. Levin wrote: > > Такие пироги. > Сколько у тебя уйдёт времени, чтобы всё это реализовать? Это ещё не продумано до конца. Не знаю. Буду дальше думать. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 19:37 ` Alexey Tourbin @ 2007-08-29 21:02 ` Alexey Tourbin 2007-08-29 21:11 ` Dmitry V. Levin 2007-08-30 8:53 ` Kirill A. Shutemov 0 siblings, 2 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-08-29 21:02 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 2127 bytes --] On Wed, Aug 29, 2007 at 11:37:07PM +0400, Alexey Tourbin wrote: > On Wed, Aug 29, 2007 at 11:29:42PM +0400, Dmitry V. Levin wrote: > > > Такие пироги. > > Сколько у тебя уйдёт времени, чтобы всё это реализовать? > > Это ещё не продумано до конца. > Не знаю. Буду дальше думать. У меня сейчас есть большая неопределенность во многих отношениях, что да как делать, и она тянет меня на дно. Иногда даже всё сводится к каким-то мутным соображениям, "а вот хорошо бы..." С другой стороны, я слишком забиваю себе голову возможностью реализации, при том, что плохо представляю себе сборочную инфраструктуру в офисе и как вообще сейчас всё это работает и как ещё оно может работать. Предлагаю начать обмен мнениями с того, чтобы уточнить, чего мы хотим, и детализировать это достаточно четко, но не доходя до особенностей реализации, т.е. не доходя до анатомии шелл-кода в виде грепов и т.д. Я мыслю в следующих категориях. На вход пришел src.rpm пакет. На выходе мы получаем либо новое состояние сизифа, либо отлуп maintainer'у (при некоем запоминании состояния для последующего подтверждения). Соответственно, задачу girar я представляю себе так: проверить репозитарий и сформировать trusted src.rpm с валидным полем Packager; либо дать отлуп прямо здесь. Итого, на входе есть src.rpm пакет. У меня нарисовался следующий фрагментарный "псевдо-шелл" код, который отчасти проясняет, "чего мы хотим". Его нужно читать снизу вверх. #!/bin/sh exit_hander() { sisyphus_unlock } srpm_check_version() { srpm_find_sisyphus_version if srpm_found_sisyphus_version; then srpm_ensure_newer_version fi } srpm_build() { parallel srpm_build_arch `all_arches` srpm_built_ok `primary_arches` srpm_check_if_noarch } srpm_test_arch_unmets() { dump_sisyphus_unmets dump_my_sisyphus_unmets check_new_unmets } srpm_test_arch() { make_my_arch_sisyphus srpm_test_arch_unmets } srpm_test() { parallel srpm_test_arch `primary_arches` } srpm_init sisyphus_lock_r srpm_check_acl srpm_check_verison srpm_build srpm_test sisypuhs_lock_w srpm_commit [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 21:02 ` Alexey Tourbin @ 2007-08-29 21:11 ` Dmitry V. Levin 2007-08-29 21:47 ` Alexey Tourbin 2007-08-30 8:53 ` Kirill A. Shutemov 1 sibling, 1 reply; 39+ messages in thread From: Dmitry V. Levin @ 2007-08-29 21:11 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 380 bytes --] On Thu, Aug 30, 2007 at 01:02:39AM +0400, Alexey Tourbin wrote: [...] > Соответственно, задачу girar я представляю себе так: проверить > репозитарий и сформировать trusted src.rpm с валидным полем Packager; > либо дать отлуп прямо здесь. > > Итого, на входе есть src.rpm пакет. А зачем нужен этот trusted src.rpm? Я полагал, что без него можно обойтись. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 21:11 ` Dmitry V. Levin @ 2007-08-29 21:47 ` Alexey Tourbin 2007-08-29 21:55 ` Dmitry V. Levin 0 siblings, 1 reply; 39+ messages in thread From: Alexey Tourbin @ 2007-08-29 21:47 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1511 bytes --] On Thu, Aug 30, 2007 at 01:11:32AM +0400, Dmitry V. Levin wrote: > On Thu, Aug 30, 2007 at 01:02:39AM +0400, Alexey Tourbin wrote: > [...] > > Соответственно, задачу girar я представляю себе так: проверить > > репозитарий и сформировать trusted src.rpm с валидным полем Packager; > > либо дать отлуп прямо здесь. > > > > Итого, на входе есть src.rpm пакет. > > А зачем нужен этот trusted src.rpm? > Я полагал, что без него можно обойтись. Тестирование пересборкой полагается на то, что можно очень быстро узнать BuildRequires зависимости всех src.rpm пакетов в текущем сизифе. То есть вопрос такой: есть один или несколько новых *-%version-%release.%arch.rpm пакетов. Что нужно пересобрать? Если есть готовые src.rpm пакеты, то мы делаем сначала rpm -qpR (в оптимизированном цикле) и извлекаем BuildRequires; а потом делаем --print-uris (в оптимизированном цикле) и получаем для каких src.rpm пакетов в билдрут встает один из новых пакетов *-%version-%release.%arch.rpm. Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет и дальше уже можно узнать его BuildRequires зависимости, как раньше. Здесь есть неявная пресуппозиция, что BuildRequires зависимости src.rpm пакета не слишком сильно меняются в зависимости от среды, в которой был выполнен rpm -bs. То есть, не на столько сильно, чтобы кардинально менять список пакетов в билдруте при "незначительном" изменении репозитария. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 21:47 ` Alexey Tourbin @ 2007-08-29 21:55 ` Dmitry V. Levin 2007-08-29 22:26 ` Alexey Tourbin 2007-09-01 23:47 ` Alexey Tourbin 0 siblings, 2 replies; 39+ messages in thread From: Dmitry V. Levin @ 2007-08-29 21:55 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1892 bytes --] On Thu, Aug 30, 2007 at 01:47:01AM +0400, Alexey Tourbin wrote: > On Thu, Aug 30, 2007 at 01:11:32AM +0400, Dmitry V. Levin wrote: > > On Thu, Aug 30, 2007 at 01:02:39AM +0400, Alexey Tourbin wrote: > > [...] > > > Соответственно, задачу girar я представляю себе так: проверить > > > репозитарий и сформировать trusted src.rpm с валидным полем Packager; > > > либо дать отлуп прямо здесь. > > > > > > Итого, на входе есть src.rpm пакет. > > > > А зачем нужен этот trusted src.rpm? > > Я полагал, что без него можно обойтись. > > Тестирование пересборкой полагается на то, что можно очень быстро узнать > BuildRequires зависимости всех src.rpm пакетов в текущем сизифе. > > То есть вопрос такой: есть один или несколько новых > *-%version-%release.%arch.rpm пакетов. Что нужно пересобрать? > Если есть готовые src.rpm пакеты, то мы делаем сначала rpm -qpR > (в оптимизированном цикле) и извлекаем BuildRequires; а потом > делаем --print-uris (в оптимизированном цикле) и получаем > для каких src.rpm пакетов в билдрут встает один из новых пакетов > *-%version-%release.%arch.rpm. > > Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую > процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет > и дальше уже можно узнать его BuildRequires зависимости, как раньше. Если пакет попал в Сизиф, то был собран и хранится его srpm-пакет. Т.е. в данном случае srpm-пакет есть. Но у собираемого пакета srpm-пакета нет до тех пор, пока он не соберётся. > Здесь есть неявная пресуппозиция, что BuildRequires зависимости src.rpm > пакета не слишком сильно меняются в зависимости от среды, в которой был > выполнен rpm -bs. То есть, не на столько сильно, чтобы кардинально > менять список пакетов в билдруте при "незначительном" изменении > репозитария. Как правило, мы можем на это рассчитывать, не так ли? -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 21:55 ` Dmitry V. Levin @ 2007-08-29 22:26 ` Alexey Tourbin 2007-08-30 8:40 ` Kirill A. Shutemov 2007-09-01 23:47 ` Alexey Tourbin 1 sibling, 1 reply; 39+ messages in thread From: Alexey Tourbin @ 2007-08-29 22:26 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 2372 bytes --] On Thu, Aug 30, 2007 at 01:55:53AM +0400, Dmitry V. Levin wrote: > > Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую > > процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет > > и дальше уже можно узнать его BuildRequires зависимости, как раньше. > > Если пакет попал в Сизиф, то был собран и хранится его srpm-пакет. > Т.е. в данном случае srpm-пакет есть. > Но у собираемого пакета srpm-пакета нет до тех пор, пока он не соберётся. Мне так неудобно думать. :) "Собрался src.rpm пакет в самом конце" это слишком нетрадиционно. Нужно либо целиком отказываться от src.rpm пакетов как класса, либо (с точностью до 1-1 соответствия) допускать, что src.rpm есть на входе. > > Здесь есть неявная пресуппозиция, что BuildRequires зависимости src.rpm > > пакета не слишком сильно меняются в зависимости от среды, в которой был > > выполнен rpm -bs. То есть, не на столько сильно, чтобы кардинально > > менять список пакетов в билдруте при "незначительном" изменении > > репозитария. > Как правило, мы можем на это рассчитывать, не так ли? Мы должны рассчитывать, что BuildRequires зависимости src.rpm пакета фиксированы с точностью до версий в пределах архитектуры. К примеру, зависимость BuildRequires: apache2 >= %apache2_version является в этом отношении допустимой. То есть при прохождении новой версии пакета apache2 билдрут изменится в части подпакетов apache2, то есть мы обнаруживаем что пакет с таким BuildRequires подлежит пересборке. BuildRequires зависимости в пределах архитектуры означают что напр. можно писать %ifarch arm %def_without not_yet_package %else %def_with not_yet_package BuildRequires: not_yet_package %endif Это уже означает отказ от src.rpm пакетов, потому что их зависимости отличаются на разных архитектурах; но констрейнты о которых я говорю сохраняются. Недопустимыми BuildRequiers зависимостями являются зависимости типа BuildRequires: %(rpm -qR libxml2) BuildRequires: %([ $RANDOM -lt 32 ] && echo foo || echo libbar-devel) С ними ничего нельзя сделать, и вся идея оказывается фальсифицированной. Тем не менее, нет другого способа достаточно быстро узнать, что нужно тестировать пересборкой в связи с поступлением очередных пакетов. Короче, при полном отказе от src.rpm пакетов можно per-arch кешировать некоторую часть его хедера. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 22:26 ` Alexey Tourbin @ 2007-08-30 8:40 ` Kirill A. Shutemov 0 siblings, 0 replies; 39+ messages in thread From: Kirill A. Shutemov @ 2007-08-30 8:40 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 550 bytes --] On [Thu, 30.08.2007 02:26], Alexey Tourbin wrote: [...] > %ifarch arm %ifarch %arm > %def_without not_yet_package > %else > %def_with not_yet_package > BuildRequires: not_yet_package > %endif [...] > Короче, при полном отказе от src.rpm пакетов можно per-arch кешировать > некоторую часть его хедера. nosrc.rpm ? -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys LLC, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 21:55 ` Dmitry V. Levin 2007-08-29 22:26 ` Alexey Tourbin @ 2007-09-01 23:47 ` Alexey Tourbin 1 sibling, 0 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-09-01 23:47 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1403 bytes --] On Thu, Aug 30, 2007 at 01:55:53AM +0400, Dmitry V. Levin wrote: > > Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую > > процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет > > и дальше уже можно узнать его BuildRequires зависимости, как раньше. > > Если пакет попал в Сизиф, то был собран и хранится его srpm-пакет. > Т.е. в данном случае srpm-пакет есть. > Но у собираемого пакета srpm-пакета нет до тех пор, пока он не соберётся. А если у src.rpm пакета получаются разные BuildRequires в зависимости от архитектуры? Или в зависимости от флагов --with/--without? Насколько я понимаю, это один из факторов в пользу отказа от src.rpm как первичной формы публикации исходников. А в случае с gear получается более сложное преобразование gear -> pkg.tar -> src.rpm, где последний является уже продуктом нетривиальных вычислений. Не знаю, стоит ли закладываться на окончательный отказ от src.rpm, скажем, в ближайший год. То есть заведомо раньше, чем кончится поддержка продуктов на основе branch 4.0, который сделан, грубо говоря, по старой технологии. В любом случае, если src.rpm существенно отличается при сборке на разных платформах или в зависимости от ещё каких-то обстоятельств, то результат является по сути непубликуемым. Какой из них публиковать? Природа проста: "плавающий" результат ненадёжен публикации не подлежит. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 21:02 ` Alexey Tourbin 2007-08-29 21:11 ` Dmitry V. Levin @ 2007-08-30 8:53 ` Kirill A. Shutemov 1 sibling, 0 replies; 39+ messages in thread From: Kirill A. Shutemov @ 2007-08-30 8:53 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 951 bytes --] On [Thu, 30.08.2007 01:02], Alexey Tourbin wrote: > Предлагаю начать обмен мнениями с того, чтобы уточнить, чего мы хотим, и > детализировать это достаточно четко, но не доходя до особенностей > реализации, т.е. не доходя до анатомии шелл-кода в виде грепов и т.д. Лично мне хотелось бы децентрализации сборки. Хотя бы per arch. Это помогло бы мне поддерживать репозиторий под ARM до того как он будет включён в Сизиф. Я вижу это как получение команд на сборку через почту. -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys LLC, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-08-29 17:05 ` [devel] giter-factory Alexey Tourbin 2007-08-29 19:29 ` Dmitry V. Levin @ 2007-09-16 21:13 ` Michael Shigorin 2007-09-16 21:36 ` Alexey Tourbin 1 sibling, 1 reply; 39+ messages in thread From: Michael Shigorin @ 2007-09-16 21:13 UTC (permalink / raw) To: ALT Devel discussion list On Wed, Aug 29, 2007 at 09:05:12PM +0400, Alexey Tourbin wrote: > После удачной пересборки пакет сразу же публикуется. Следующие > пакеты из очереди пересобираются уже на новом публичном > репозитории. > > Это я называю "наивная сериализация". Прошёл "очень плохой пакет" > и сразу же опубликовался, полсизифа перестало собираться; отозвать > сборку задним числом уже нельзя. И ведь сколько переливается про "карманы", и ведь автор sandman вполне досягаем... > Преимущество тут только в том, что пересборка/публикация происходит > очень быстро, но это просто сопособ очень быстро всё пустить под откос. > Даже сейчас "ответственный товарищ, формирующий сизиф", играет > созидательную роль, не пропуская (hopefully) вручную "очень плохие > пакеты". Просто исключить эту роль, не дав ничего взамен, нельзя. 2 legion: примерно об этом и на конференции пытался сказать, да и при обсуждении _осмысленности_ сверхзвуковой _публикации_. > Мое альтернативное видение такое: прошёл пакет и пересобрался. > Формируется новый временный сизиф с этим пакетом, и на этом > временном сизифе выполняется ряд проверок. Если все проверки > прошли успешно, то временный сизиф становится текущим > ("коммит"), и очередь продвигается. Кластеры изменений так тоже возможно делать становится. Например, недавнее со шрифтами или любой soname change. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-09-16 21:13 ` Michael Shigorin @ 2007-09-16 21:36 ` Alexey Tourbin 2007-09-16 21:32 ` Aleksey Avdeev 2007-09-18 9:32 ` [devel] giter-factory Michael Shigorin 0 siblings, 2 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-09-16 21:36 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 2251 bytes --] On Mon, Sep 17, 2007 at 12:13:53AM +0300, Michael Shigorin wrote: > > Преимущество тут только в том, что пересборка/публикация происходит > > очень быстро, но это просто сопособ очень быстро всё пустить под откос. > > Даже сейчас "ответственный товарищ, формирующий сизиф", играет > > созидательную роль, не пропуская (hopefully) вручную "очень плохие > > пакеты". Просто исключить эту роль, не дав ничего взамен, нельзя. > > 2 legion: примерно об этом и на конференции пытался сказать, > да и при обсуждении _осмысленности_ сверхзвуковой _публикации_. > > > Мое альтернативное видение такое: прошёл пакет и пересобрался. > > Формируется новый временный сизиф с этим пакетом, и на этом > > временном сизифе выполняется ряд проверок. Если все проверки > > прошли успешно, то временный сизиф становится текущим > > ("коммит"), и очередь продвигается. > > Кластеры изменений так тоже возможно делать становится. > Например, недавнее со шрифтами или любой soname change. Миша. Кластеры пакетов как идея это скорее глупость. В частной переписке at <-> ldv,legion я сформулировал более общую и красивую идею "мёржа" веток репозитария. Ветки это задания (один или более пакетов в "кармане"), которые не прошли подтверждение на автомате. Мёрж это некая операция применения изменений относительно других изменений. Мёрж *отлично* соответствует критерию фальсификационизма: он либо возможен, либо не возможен. Ещё бы тебе понимать, что такое критерий фальсификационизма. В общем, у меня есть некоторый набор "правильных идей", он касается первичного тестирования пакетов при сборке из gear. Большая часть этих идей была озвучена здесь (в списке devel@), некоторые принципиально важные пояснения были в частной переписке. Я могу продублировать пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень хорошо понимать, о чем идет речь. В целом всё описанное более чем возможно. Нужно просто браться за дело, но у меня в ближайшее время не будет на это много времени. А у кого будет? Здесь есть конфликт амбиций, так что это не решается с "полпинка". Думаю однако что не раньше чем через год всё это будет сделано, просто потому что будет стыдно, если через год всё это не будет сделано. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-09-16 21:36 ` Alexey Tourbin @ 2007-09-16 21:32 ` Aleksey Avdeev 2007-09-16 22:15 ` [devel] giter-factory idea Alexey Tourbin 2007-09-18 9:32 ` [devel] giter-factory Michael Shigorin 1 sibling, 1 reply; 39+ messages in thread From: Aleksey Avdeev @ 2007-09-16 21:32 UTC (permalink / raw) To: ALT Linux Team development discussions Alexey Tourbin пишет: ... > > В общем, у меня есть некоторый набор "правильных идей", он касается > первичного тестирования пакетов при сборке из gear. Большая часть этих > идей была озвучена здесь (в списке devel@), некоторые принципиально > важные пояснения были в частной переписке. Я могу продублировать > пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень > хорошо понимать, о чем идет речь. Хотелось бы услышать. (Для возможности подумать идею в фоновом режиме.) -- С уважением. Алексей. ^ permalink raw reply [flat|nested] 39+ messages in thread
* [devel] giter-factory idea 2007-09-16 21:32 ` Aleksey Avdeev @ 2007-09-16 22:15 ` Alexey Tourbin 2007-09-16 23:01 ` Aleksey Avdeev 0 siblings, 1 reply; 39+ messages in thread From: Alexey Tourbin @ 2007-09-16 22:15 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 6071 bytes --] On Mon, Sep 17, 2007 at 01:32:46AM +0400, Aleksey Avdeev wrote: > > В общем, у меня есть некоторый набор "правильных идей", он касается > > первичного тестирования пакетов при сборке из gear. Большая часть этих > > идей была озвучена здесь (в списке devel@), некоторые принципиально > > важные пояснения были в частной переписке. Я могу продублировать > > пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень > > хорошо понимать, о чем идет речь. > > Хотелось бы услышать. (Для возможности подумать идею в фоновом режиме.) Ваш стиль коммитов в git.alt не слишком обнадеживает насчет продуктивности обдумывания. Тем не менее. Есть прямая аналогия между коммитами в git и прохождением пакетов в репозитарий. Существует "хед" репозитария. Хед сдвигается, когда пакет проходит в сизиф. Перед сдвигом хеда выполняется ряд проверок. Если проверки отваливают, то "сдвиг хеда" невозможен, а формируется отдельный "бранч репозитария" (который замораживается на некоторое время, пока не станет ясно, насколько там серьезные ошибки). В дальнейшем этот бранч либо удаляется (если ошибки серьезные), либо происходит мёрж этого бранча в хед (если все специфические ошибки удалось разрулить). Короче, начать с самого примитива и закончить самым заумным мне сейчас будет сложно. Я приведу несколько кусков текста, которые я написал в частной переписке. Типа кому надо тот поймёт. -- > > В схеме с подтверждением вручную очень желательно иметь идентификатор [задания] > Что это "подтверждение вручную" ? Это моя идея внедрения первичного тестирования в giter-factory. Сразу публиковать пакеты на автомате нельзя. Сейчас вроде как подразумевается квалифицированная проверка перед подписью и публикацией, а если пакет автоматически опубликовался, то "отозвать" его задним числом уже нельзя. Значит, в автоматической системе перед публикацией будет выполняться ряд проверок. Минимально что должно проверяться -- это целостность репозитария при внедрении в него новых пакетов. В частности это unmet'ы и возможность инициализации нового билдрута. Представляешь что будет если пакет опубликовался и --initroot перестал работать?! Дальше надо будет внедрять "полную пересборку сизифа", чтобы выяснить ломают новые пакеты что-нибудь по возможности сборки или нет. Соответственно, если обнаружена "подозрительная ситуация", то пакет (точнее, весь task) ставится "на подтверждение вручную". Думаю что можно будет обнаруживать разные классы атак на целостность репозитария. В зависимости от классификации атаки подтверждения со стороны самого maintainer'а может быть достаточно или не достаточно (во втором случае требуется подтверждение со стороны "авторитета", т.е. грубо говоря ldv|legion). Подтверждение вручную ломает всю идею сериализации. Если task встал на подтверждение вручную, то этот task не должен задерживать продвижение очереди. Соответственно, могут возникать очень нетривиальные ситуации: что делать с подтверждением вручную, если оно пришло слишком поздно, и фигурально выражаясь, погода изменилась и ветер дует теперь дует в другую сторону? Но и тут можно кое-что придумать. В простейшем случае можно просто перекладывать "старые" пакеты в "новый" репозитарий, но на самом деле это никуда не годится. Здесь помогает аналогия мёржа. Нужно "смёржить" старые пакеты из "бранча" (таска), который встал на подтверждение вручную, в текущий бранч master (новый репозитарий). Стратегии мёржа могут быть разные. Простейшая стратегия это как раз нормальная формализация "перекладывания пакетов". В бранче сидит "операция мёржа", которая активизируется при подтверждении вручную: rm pkg1-subpkg1-v1.i586.rpm rm pkg1-subpkg2-v1.i586.rpm rm pkg1-v1.src.rpm add pkg1-subpkg1-v2.i586.rpm add pkg1-subpkg2-v2.i586.rpm add pkg1-v2.src.rpm Если все команды rm могут быть выполнены на master'е, то данный мёрж всё ещё возможен. Если же мёрж невозможен, то таск отменяется. Можно будет делать что-то типа авто-ребейса. Потом можно будет сделать более продвинутые стратегии мёржа, в части уточнение возможности пересборки пакетов и т.д. -- На самом деле rm и add должны выполняться с большей гранулярностью. rm name SVR filename add name SVR filename Гранулярность в rm страхует от удаления новой сборки в которой добавился serial. А гранулярность add страхует от того, что пакет с именем name но другим SVR/filename был уже добавлен. Но это детали. Суть в том, что в принципе "аналогия операции мёржа" позволяет справляться с нарушением сериализации. Очень живительная аналогия, я когда её понял то прямо обрадовался. То есть можно точно определить, изменилась погода или нет. По крайней мере на уровне возможности "перекладывания пакетов". -- > Я хочу сократить вмешательство человека до минимума. > [...] Я попытался раскрыть идею в соседнем письме. Смысл как раз в том, чтобы формализовать весь набор действий, который выполняет квалифицированный специалист при проверке и подписи репозитария. То есть работы на самом деле должно сократиться. То что <...делается...> вручную или полу-автоматически при помощи каких-то скриптов, будет преподнесено на блюдечке с голубой каёмочкой. Более того, большую часть "подтверждений вручную" можно будет отдать на откуп самим maintainer'ам. Пускай сами подтверждают или отменяют, чево они там насобирали. Подтверждение со стороны авторитета явно требуется только при "конфликтах". Например я добавил в пакет perl подпакет coreutils. То есть может быть конфликт между двумя maintainer'ами. Проверка acl по src.rpm проходит, а при попытке преложить пакеты в репозитарий ничего не получается. Тут-то и может потребоваться "авторитетное" подтверждение. Если же я запаковал в perl подпакет perl-libwww, который в свою очередь тоже висит на мне, то авторитетам вмешиваться ни к чему. Плюс аналогичная проверка, конечно же, нужна на provides/obsolets, чтобы не было конфликта претензий. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory idea 2007-09-16 22:15 ` [devel] giter-factory idea Alexey Tourbin @ 2007-09-16 23:01 ` Aleksey Avdeev 2007-09-17 5:42 ` Alexey Tourbin 0 siblings, 1 reply; 39+ messages in thread From: Aleksey Avdeev @ 2007-09-16 23:01 UTC (permalink / raw) To: ALT Linux Team development discussions Alexey Tourbin пишет: > On Mon, Sep 17, 2007 at 01:32:46AM +0400, Aleksey Avdeev wrote: >>> В общем, у меня есть некоторый набор "правильных идей", он касается >>> первичного тестирования пакетов при сборке из gear. Большая часть этих >>> идей была озвучена здесь (в списке devel@), некоторые принципиально >>> важные пояснения были в частной переписке. Я могу продублировать >>> пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень >>> хорошо понимать, о чем идет речь. >> Хотелось бы услышать. (Для возможности подумать идею в фоновом режиме.) > > Ваш стиль коммитов в git.alt не слишком обнадеживает насчет > продуктивности обдумывания. А что с ними не так, если не секрет? > Тем не менее. Спасибо. -- С уважением. Алексей. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory idea 2007-09-16 23:01 ` Aleksey Avdeev @ 2007-09-17 5:42 ` Alexey Tourbin 2007-09-17 10:41 ` Aleksey Avdeev 0 siblings, 1 reply; 39+ messages in thread From: Alexey Tourbin @ 2007-09-17 5:42 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 588 bytes --] On Mon, Sep 17, 2007 at 03:01:52AM +0400, Aleksey Avdeev wrote: > > Ваш стиль коммитов в git.alt не слишком обнадеживает насчет > > продуктивности обдумывания. > > А что с ними не так, если не секрет? У Вас слишком много бранчей. Так что когда винт начинает трещать а postfix напрягаться -- я точно знаю: Алексей Авдеев прислал пачку ценных писем про apache2. Что с ним не так Вам виднее. Но в принципе такие прецеденты нагрузки на postfix у меня были раньше только при очень неудачных пересборках сизифа (из-за того, что я получаю все письма от робота на "CC: qa@"). [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory idea 2007-09-17 5:42 ` Alexey Tourbin @ 2007-09-17 10:41 ` Aleksey Avdeev 0 siblings, 0 replies; 39+ messages in thread From: Aleksey Avdeev @ 2007-09-17 10:41 UTC (permalink / raw) To: ALT Linux Team development discussions Alexey Tourbin пишет: > On Mon, Sep 17, 2007 at 03:01:52AM +0400, Aleksey Avdeev wrote: >>> Ваш стиль коммитов в git.alt не слишком обнадеживает насчет >>> продуктивности обдумывания. >> А что с ними не так, если не секрет? > > У Вас слишком много бранчей. Так что когда винт начинает трещать > а postfix напрягаться -- я точно знаю: Алексей Авдеев прислал пачку > ценных писем про apache2. > > Что с ним не так Вам виднее. Но в принципе такие прецеденты нагрузки > на postfix у меня были раньше только при очень неудачных пересборках > сизифа (из-за того, что я получаю все письма от робота на "CC: qa@"). Такое количество бранчей вестма удобно, т. к. позволяет отделять мух от котлет явным образом. :-) Основных причины 2: 1. Упрощается выдирание самомтоятельных кусков для использования где-то ещё (spec`и, gettext`овские переводы и пр.). 2. Способ дисциплинировать себя явным образом: если работа над неким логически куском идёт в отдельном бранче, то для включения её в основной код, мердж я должен выполнить явно. От _случайной_ сборки с недоделанным куском чего-то такой подход страхует весьма неплохо. (Как показала практика -- для меня оно актуально.) И, похоже, 1 обусловлена моим незнанием правельных путей: 3. Неразобрался как правельно делать межфайловые мержы (смержить файлы с разными названием). Сейчас делаю это через временные бранчи (с пачкой переименований). Но гложит ощущение что делаю это косо... PS: Вашему postfix -- моё сочувствие. :-) -- С уважением. Алексей. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] giter-factory 2007-09-16 21:36 ` Alexey Tourbin 2007-09-16 21:32 ` Aleksey Avdeev @ 2007-09-18 9:32 ` Michael Shigorin 1 sibling, 0 replies; 39+ messages in thread From: Michael Shigorin @ 2007-09-18 9:32 UTC (permalink / raw) To: ALT Devel discussion list On Mon, Sep 17, 2007 at 01:36:55AM +0400, Alexey Tourbin wrote: > > Кластеры изменений так тоже возможно делать становится. > > Например, недавнее со шрифтами или любой soname change. > Миша. Кластеры пакетов как идея это скорее глупость. Возможно, я-то сказал "кластеры изменений". > В частной переписке at <-> ldv,legion я сформулировал более > общую и красивую идею "мёржа" веток репозитария. Ветки это > задания (один или более пакетов в "кармане"), которые не прошли > подтверждение на автомате. Ещё бы тебе понимать Layne's Law of Debate... :) Если вдруг сталкивался с использованием sandman, то примерно о том и речь, только без слова "ветки". > В общем, у меня есть некоторый набор "правильных идей", он > касается первичного тестирования пакетов при сборке из gear. > Большая часть этих идей была озвучена здесь (в списке devel@), > некоторые принципиально важные пояснения были в частной > переписке. Я могу продублировать пояснения здесь, хотя вряд ли > это что-то даст, потому что нужно очень хорошо понимать, о чем > идет речь. Буду благодарен, если продублируешь -- по крайней мере заархивируется/прогуглится, даже если сразу средним умишком не грокнуть. PS: :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-08-28 19:55 ` Alexey Tourbin 2007-08-28 20:12 ` [devel] /usr/lib/pkgconfig vs noarch Dmitry V. Levin @ 2007-08-28 20:29 ` Alexey I. Froloff 2007-08-28 20:46 ` Alexey Rusakov 2 siblings, 0 replies; 39+ messages in thread From: Alexey I. Froloff @ 2007-08-28 20:29 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 416 bytes --] * Alexey Tourbin <at@> [070828 23:57]: > i386-mingw32msvc-libpng-devel-1.2.8-alt2.noarch.rpm /usr/lib/pkgconfig/i386-mingw32msvc-libpng.pc 120777 symbolic link to `i386-mingw32msvc-libpng12.pc' > i386-mingw32msvc-libpng-devel-1.2.8-alt2.noarch.rpm /usr/lib/pkgconfig/i386-mingw32msvc-libpng12.pc 100644 ASCII text Это бага. Не должно оно лежать в /usr/lib/pkgconfig/... -- Regards, Sir Raorn. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-08-28 19:55 ` Alexey Tourbin 2007-08-28 20:12 ` [devel] /usr/lib/pkgconfig vs noarch Dmitry V. Levin 2007-08-28 20:29 ` [devel] pkgconfiglib.req Alexey I. Froloff @ 2007-08-28 20:46 ` Alexey Rusakov 2 siblings, 0 replies; 39+ messages in thread From: Alexey Rusakov @ 2007-08-28 20:46 UTC (permalink / raw) To: devel On Tue, 28 Aug 2007 23:55:29 +0400 Alexey Tourbin wrote: > ВОТ ТАК ТАК! В noarch ПАКЕТАХ НЕ ДОЛЖНО БЫТЬ /usr/lib/pkgconfig! Совершенно справедливо. *.pc файлы для noarch пакетов кладутся в /usr/share/pkgconfig как архитектурно-независимое место. -- Alexey "Ktirf" Rusakov GNOME Project ALT Linux Team ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-08-28 17:11 [devel] pkgconfiglib.req Alexey M. Tourbin 2007-08-28 19:55 ` Alexey Tourbin @ 2007-08-29 13:51 ` Igor Zubkov 2007-09-16 21:17 ` Michael Shigorin 2 siblings, 0 replies; 39+ messages in thread From: Igor Zubkov @ 2007-08-29 13:51 UTC (permalink / raw) To: ALT Devel discussion list 2007/8/28, Alexey M. Tourbin: > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ". Уважаемые товарищи maintaner'ы! > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще, > до тех пор, пока он кому-нибудь не понадобится. А кроме того, *.pc файл в пакете приводит к излишним зависимостям в этом пакете. Как пример, python-module-dbus и python-module-gst. Оба уже пофикшены. -- icesik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-08-28 17:11 [devel] pkgconfiglib.req Alexey M. Tourbin 2007-08-28 19:55 ` Alexey Tourbin 2007-08-29 13:51 ` Igor Zubkov @ 2007-09-16 21:17 ` Michael Shigorin 2007-09-16 22:50 ` Alexey Rusakov 2 siblings, 1 reply; 39+ messages in thread From: Michael Shigorin @ 2007-09-16 21:17 UTC (permalink / raw) To: devel On Tue, Aug 28, 2007 at 09:11:00PM +0400, Alexey M. Tourbin wrote: > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ". Уважаемые товарищи maintaner'ы! > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще, > до тех пор, пока он кому-нибудь не понадобится. Вот это бы хорошо в sisyphus_check, для начала как warning. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-09-16 21:17 ` Michael Shigorin @ 2007-09-16 22:50 ` Alexey Rusakov 2007-09-17 5:36 ` Alexey Tourbin 0 siblings, 1 reply; 39+ messages in thread From: Alexey Rusakov @ 2007-09-16 22:50 UTC (permalink / raw) To: devel On Mon, 17 Sep 2007 00:17:01 +0300 Michael Shigorin wrote: > On Tue, Aug 28, 2007 at 09:11:00PM +0400, Alexey M. Tourbin wrote: > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ". Уважаемые товарищи maintaner'ы! > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще, > > до тех пор, пока он кому-нибудь не понадобится. > > Вот это бы хорошо в sisyphus_check, для начала как warning. +1 -- Alexey "Ktirf" Rusakov GNOME Project ALT Linux Team ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-09-16 22:50 ` Alexey Rusakov @ 2007-09-17 5:36 ` Alexey Tourbin 2007-09-18 10:09 ` [devel] UQ: git-clone git.alt: unable to chdir or not a git archive Michael Shigorin 2007-09-18 11:44 ` [devel] pkgconfiglib.req Michael Shigorin 0 siblings, 2 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-09-17 5:36 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 644 bytes --] On Mon, Sep 17, 2007 at 02:50:25AM +0400, Alexey Rusakov wrote: > > On Tue, Aug 28, 2007 at 09:11:00PM +0400, Alexey M. Tourbin wrote: > > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ > > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ". Уважаемые товарищи maintaner'ы! > > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще, > > > до тех пор, пока он кому-нибудь не понадобится. > > > > Вот это бы хорошо в sisyphus_check, для начала как warning. > +1 Чево плюс один, берите и делайте. Но учтите что в sisyphus_check ворнингов на данный момент нету, это формальный инструмент который дает ответ да/нет. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* [devel] UQ: git-clone git.alt: unable to chdir or not a git archive 2007-09-17 5:36 ` Alexey Tourbin @ 2007-09-18 10:09 ` Michael Shigorin 2007-09-18 10:09 ` Pavlov Konstantin 2007-09-18 11:44 ` [devel] pkgconfiglib.req Michael Shigorin 1 sibling, 1 reply; 39+ messages in thread From: Michael Shigorin @ 2007-09-18 10:09 UTC (permalink / raw) To: devel On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote: > > > Вот это бы хорошо в sisyphus_check, для начала как warning. > > +1 > Чево плюс один, берите и делайте. По ходу дела: http://git.altlinux.org/people/sbolshakov/packages/sisyphus_check.git -- есть, а вот clone не едет: hasher32:~/git> git-clone git.alt:people/sbolshakov/packages/sisyphus_check.git Initialized empty Git repository in /home/mike/git/sisyphus_check/.git/ RSA host key for IP address '194.107.17.12' not in list of known hosts. fatal: 'people/sbolshakov/packages/sisyphus_check.git': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly fetch-pack from 'git.alt:people/sbolshakov/packages/sisyphus_check.git' failed. Мало того, склонировать ldv тоже не получается: hasher32:~/git> git-clone git.alt:people/ldv/packages/sisyphus_check.git Initialized empty Git repository in /home/mike/git/sisyphus_check/.git/ RSA host key for IP address '194.107.17.12' not in list of known hosts. fatal: 'people/ldv/packages/sisyphus_check.git': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly fetch-pack from 'git.alt:people/ldv/packages/sisyphus_check.git' failed. ???!? > Но учтите что в sisyphus_check ворнингов на данный момент нету, > это формальный инструмент который дает ответ да/нет. stderr ему тоже оторвали? Типа, "да, но". -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] UQ: git-clone git.alt: unable to chdir or not a git archive 2007-09-18 10:09 ` [devel] UQ: git-clone git.alt: unable to chdir or not a git archive Michael Shigorin @ 2007-09-18 10:09 ` Pavlov Konstantin 2007-09-18 10:15 ` [devel] отбой, спасибо, сам дурак Michael Shigorin 0 siblings, 1 reply; 39+ messages in thread From: Pavlov Konstantin @ 2007-09-18 10:09 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 1529 bytes --] On Tue, Sep 18, 2007 at 01:09:50PM +0300, Michael Shigorin wrote: > On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote: > > > > Вот это бы хорошо в sisyphus_check, для начала как warning. > > > +1 > > Чево плюс один, берите и делайте. > > По ходу дела: > > http://git.altlinux.org/people/sbolshakov/packages/sisyphus_check.git > -- есть, а вот clone не едет: > > hasher32:~/git> git-clone git.alt:people/sbolshakov/packages/sisyphus_check.git > Initialized empty Git repository in /home/mike/git/sisyphus_check/.git/ > RSA host key for IP address '194.107.17.12' not in list of known hosts. > fatal: 'people/sbolshakov/packages/sisyphus_check.git': unable to chdir or not a git archive > fatal: The remote end hung up unexpectedly > fetch-pack from 'git.alt:people/sbolshakov/packages/sisyphus_check.git' failed. > > Мало того, склонировать ldv тоже не получается: > > hasher32:~/git> git-clone git.alt:people/ldv/packages/sisyphus_check.git > Initialized empty Git repository in /home/mike/git/sisyphus_check/.git/ > RSA host key for IP address '194.107.17.12' not in list of known hosts. > fatal: 'people/ldv/packages/sisyphus_check.git': unable to chdir or not a git archive > fatal: The remote end hung up unexpectedly > fetch-pack from 'git.alt:people/ldv/packages/sisyphus_check.git' failed. > > ???!? Ты слэш перед people забыл. -- А вот ZODB3.3 это, конечно, большой шаг вперед. Прощай ExtensionClass ;). Я уже начал перепирать свои коды туда. -- cray in devel@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* [devel] отбой, спасибо, сам дурак 2007-09-18 10:09 ` Pavlov Konstantin @ 2007-09-18 10:15 ` Michael Shigorin 0 siblings, 0 replies; 39+ messages in thread From: Michael Shigorin @ 2007-09-18 10:15 UTC (permalink / raw) To: devel On Tue, Sep 18, 2007 at 02:09:22PM +0400, Pavlov Konstantin wrote: > > ???!? > Ты слэш перед people забыл. Спасибо, пошёл заваривать зелёный чай... -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-09-17 5:36 ` Alexey Tourbin 2007-09-18 10:09 ` [devel] UQ: git-clone git.alt: unable to chdir or not a git archive Michael Shigorin @ 2007-09-18 11:44 ` Michael Shigorin 2007-09-18 11:49 ` Alexey Rusakov 2007-09-19 22:22 ` [devel] *.pc -devel Alexey Tourbin 1 sibling, 2 replies; 39+ messages in thread From: Michael Shigorin @ 2007-09-18 11:44 UTC (permalink / raw) To: devel On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote: > > > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ > > > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ". Уважаемые товарищи maintaner'ы! > > > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще, > > > > до тех пор, пока он кому-нибудь не понадобится. > > > Вот это бы хорошо в sisyphus_check, для начала как warning. > > +1 > Чево плюс один, берите и делайте. Тоже мне бином Ньютона. Заодно добавил tests/: http://git.altlinux.org/people/mike/packages/?p=sisyphus_check.git;a=commitdiff;h=560f46b205749c2963231330a32eb20c895f12f1 PS: спасибо led@ за возвратное снимание меня с ручника по части теста на -devel. :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [devel] pkgconfiglib.req 2007-09-18 11:44 ` [devel] pkgconfiglib.req Michael Shigorin @ 2007-09-18 11:49 ` Alexey Rusakov 2007-09-19 22:22 ` [devel] *.pc -devel Alexey Tourbin 1 sibling, 0 replies; 39+ messages in thread From: Alexey Rusakov @ 2007-09-18 11:49 UTC (permalink / raw) To: devel On Tue, 18 Sep 2007 14:44:39 +0300 Michael Shigorin wrote: > On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote: > > > > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ > > > > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ". Уважаемые товарищи maintaner'ы! > > > > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще, > > > > > до тех пор, пока он кому-нибудь не понадобится. > > > > Вот это бы хорошо в sisyphus_check, для начала как warning. > > > +1 > > Чево плюс один, берите и делайте. > > Тоже мне бином Ньютона. Заодно добавил tests/: > http://git.altlinux.org/people/mike/packages/?p=sisyphus_check.git;a=commitdiff;h=560f46b205749c2963231330a32eb20c895f12f1 Вай, Миша, огромное спасибо. Люблю порядок :) -- Alexey "Ktirf" Rusakov GNOME Project ALT Linux Team ^ permalink raw reply [flat|nested] 39+ messages in thread
* [devel] *.pc -devel 2007-09-18 11:44 ` [devel] pkgconfiglib.req Michael Shigorin 2007-09-18 11:49 ` Alexey Rusakov @ 2007-09-19 22:22 ` Alexey Tourbin 1 sibling, 0 replies; 39+ messages in thread From: Alexey Tourbin @ 2007-09-19 22:22 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 2156 bytes --] On Tue, Sep 18, 2007 at 02:44:39PM +0300, Michael Shigorin wrote: > On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote: > > > > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ > > > > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ". Уважаемые товарищи maintaner'ы! > > > > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще, > > > > > до тех пор, пока он кому-нибудь не понадобится. > > > > Вот это бы хорошо в sisyphus_check, для начала как warning. > > > +1 > > Чево плюс один, берите и делайте. > > Тоже мне бином Ньютона. Заодно добавил tests/: > http://git.altlinux.org/people/mike/packages/?p=sisyphus_check.git;a=commitdiff;h=560f46b205749c2963231330a32eb20c895f12f1 > > PS: спасибо led@ за возвратное снимание меня с ручника > по части теста на -devel. :) Ох. Я наверное всё-таки поспешил сделать вывод, что все *.pc файлы нужно вынести в -devel пакеты. Это не всегда решает проблему. А проблема в неопределенной семантике pkgconfig зависимостей. То есть там нет расслоения на BuildRequires, Requires: lib%name.so.0 и Requires: lib%name-devel. Я об этом писал. То есть сейчас появляется искушение решить некоторый класс псевдо-проблем, не до конца поняв суть дела. Так что мне пока остается только, противореча самому себе, предостерегать от псевдо-решений псевдо-проблем. Сначала нужно хорошо подумать, если есть такая возможность. Переформулирую критерий включений *.pc файлов в пакеты. Файлы *.pc, как правило, должны входить в -devel пакеты. Это соответствует превалирующей семантике lib%name-devel. С другой стороны, pkgconfig зависимости иногда "снижаются" вниз по топологии пакетов до уровня /usr/bin. Если *.pc файл находится в таком не-devel пакете, то ТРЕБУЕТСЯ, чтобы зависимости этого *.pc файла, в том числе транзитивные, не содержали каких-либо -devel пакетов. *.pc файл без зависимостей заведомо удовлетворяет этому требованию. Зависимости *.pc файлов можно подчистить вручную, если они альтернативным образом хорошо обнаруживаются (при помощи find-requires). Зависимости же с семантикой BuildRequires нужно вычищать в безусловном порядке. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2007-09-19 22:22 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-08-28 17:11 [devel] pkgconfiglib.req Alexey M. Tourbin 2007-08-28 19:55 ` Alexey Tourbin 2007-08-28 20:12 ` [devel] /usr/lib/pkgconfig vs noarch Dmitry V. Levin 2007-08-28 20:47 ` Alexey Tourbin 2007-08-28 21:07 ` Alexey Tourbin 2007-08-28 21:32 ` [devel] sisyphus_check noarch Alexey Tourbin 2007-09-01 13:12 ` [devel] /usr/lib/pkgconfig vs noarch Денис Смирнов 2007-08-29 15:56 ` Dmitry V. Levin 2007-08-29 17:05 ` [devel] giter-factory Alexey Tourbin 2007-08-29 19:29 ` Dmitry V. Levin 2007-08-29 19:37 ` Alexey Tourbin 2007-08-29 21:02 ` Alexey Tourbin 2007-08-29 21:11 ` Dmitry V. Levin 2007-08-29 21:47 ` Alexey Tourbin 2007-08-29 21:55 ` Dmitry V. Levin 2007-08-29 22:26 ` Alexey Tourbin 2007-08-30 8:40 ` Kirill A. Shutemov 2007-09-01 23:47 ` Alexey Tourbin 2007-08-30 8:53 ` Kirill A. Shutemov 2007-09-16 21:13 ` Michael Shigorin 2007-09-16 21:36 ` Alexey Tourbin 2007-09-16 21:32 ` Aleksey Avdeev 2007-09-16 22:15 ` [devel] giter-factory idea Alexey Tourbin 2007-09-16 23:01 ` Aleksey Avdeev 2007-09-17 5:42 ` Alexey Tourbin 2007-09-17 10:41 ` Aleksey Avdeev 2007-09-18 9:32 ` [devel] giter-factory Michael Shigorin 2007-08-28 20:29 ` [devel] pkgconfiglib.req Alexey I. Froloff 2007-08-28 20:46 ` Alexey Rusakov 2007-08-29 13:51 ` Igor Zubkov 2007-09-16 21:17 ` Michael Shigorin 2007-09-16 22:50 ` Alexey Rusakov 2007-09-17 5:36 ` Alexey Tourbin 2007-09-18 10:09 ` [devel] UQ: git-clone git.alt: unable to chdir or not a git archive Michael Shigorin 2007-09-18 10:09 ` Pavlov Konstantin 2007-09-18 10:15 ` [devel] отбой, спасибо, сам дурак Michael Shigorin 2007-09-18 11:44 ` [devel] pkgconfiglib.req Michael Shigorin 2007-09-18 11:49 ` Alexey Rusakov 2007-09-19 22:22 ` [devel] *.pc -devel Alexey Tourbin
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git