Здравствуйте! Как можно удалить репозитарий с git.alt? $ ssh git.alt ls packages total 12 drwxr-sr-x 5 4096 Apr 2 17:32 dbmail.git drwxr-sr-x 5 4096 Feb 24 01:36 docs-linux_ha_openvz-enp.git drwxr-sr-x 4 4096 Mar 12 14:37 heartbeat.git $ ssh git.alt rm -rf packages/dbmail.git/ girar-sh: rm -rf packages/dbmail.git/: Invalid argument Просто довел его до неприличного состояния, хочу пересоздать -- С уважением, Прокопьев Евгений
[-- Attachment #1: Type: text/plain, Size: 513 bytes --] On Mon, Apr 09, 2007 at 09:00:25AM +0400, Eugene Prokopiev wrote: EP> $ ssh git.alt rm -rf packages/dbmail.git/ ssh git.alt git-rm dbmail EP> girar-sh: rm -rf packages/dbmail.git/: Invalid argument EP> Просто довел его до неприличного состояния, хочу пересоздать ssh git.alt help будешь приятно удивлен -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- Всё слишком сложное когда-нибудь загибается. -- inger in devel@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 279 bytes --] Eugene Prokopiev пишет: > Здравствуйте! > ... > > Другой вопрос: что нужно написать в Push: в .git/remotes/origin (сейчас > он не используется), чтобы отправлять все содержимое репозитария? git-push --all (или git-push -f --all)? -- С уважением. Алексей. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 548 bytes --]
Здравствуйте! Перед отправкой: $ git-branch dbmail_2_2 * srpms $ git-show-ref 30f7175ef6fc270c42024820455e59c9b5866c1c refs/heads/dbmail_2_2 350fb9d63f4e90636eca217bb1c8f75922009319 refs/heads/srpms 5c6384de1eee3de9e74be9f2d6f4df214b7a0c78 refs/tags/2.2.4-alt1 f670fe9e78fc328349ed5f6d118930eee6394410 refs/tags/dbmail/2.2.4.200704090940 Оправка: git-push --repo=all git.alt:packages/dbmail.git Затем делаю git-clone git.alt:packages/dbmail, перехожу в каталог dbmail и в нем вижу: $ git-branch $ git-show-ref 30f7175ef6fc270c42024820455e59c9b5866c1c refs/remotes/origin/dbmail_2_2 350fb9d63f4e90636eca217bb1c8f75922009319 refs/remotes/origin/srpms 5c6384de1eee3de9e74be9f2d6f4df214b7a0c78 refs/tags/2.2.4-alt1 f670fe9e78fc328349ed5f6d118930eee6394410 refs/tags/dbmail/2.2.4.200704090940 Куда делись мои бранчи? Другой вопрос: что нужно написать в Push: в .git/remotes/origin (сейчас он не используется), чтобы отправлять все содержимое репозитария? -- С уважением, Прокопьев Евгений
Aleksey Avdeev пишет:
> Eugene Prokopiev пишет:
>
>>Здравствуйте!
>>
>
> ...
>
>>Другой вопрос: что нужно написать в Push: в .git/remotes/origin (сейчас
>>он не используется), чтобы отправлять все содержимое репозитария?
>
>
> git-push --all (или git-push -f --all)?
Все варианты приводят к: Everything up-to-date, вот только результат
git-clone удручает :(
--
С уважением, Прокопьев Евгений
[-- Attachment #1: Type: text/plain, Size: 2626 bytes --] On Mon, Apr 09, 2007 at 11:39:56AM +0400, Eugene Prokopiev wrote: > Перед отправкой: > > $ git-branch > dbmail_2_2 > * srpms > > $ git-show-ref > 30f7175ef6fc270c42024820455e59c9b5866c1c refs/heads/dbmail_2_2 > 350fb9d63f4e90636eca217bb1c8f75922009319 refs/heads/srpms > 5c6384de1eee3de9e74be9f2d6f4df214b7a0c78 refs/tags/2.2.4-alt1 > f670fe9e78fc328349ed5f6d118930eee6394410 refs/tags/dbmail/2.2.4.200704090940 > > Оправка: > > git-push --repo=all git.alt:packages/dbmail.git > > Затем делаю git-clone git.alt:packages/dbmail, перехожу в каталог dbmail > и в нем вижу: > > $ git-branch > > $ git-show-ref > 30f7175ef6fc270c42024820455e59c9b5866c1c refs/remotes/origin/dbmail_2_2 > 350fb9d63f4e90636eca217bb1c8f75922009319 refs/remotes/origin/srpms > 5c6384de1eee3de9e74be9f2d6f4df214b7a0c78 refs/tags/2.2.4-alt1 > f670fe9e78fc328349ed5f6d118930eee6394410 refs/tags/dbmail/2.2.4.200704090940 > > Куда делись мои бранчи? По умолчанию git-clone помещает все бранчи (refs/heads/*) исходного репозитория в refs/remotes/origin/* в локальном репозитории. Имя origin можно сменить опцией --origin=<name>. Обычный бранч после git-clone создаётся только один - это тот бранч, на который в исходном репозитории указывала ссылка HEAD. В данном случае HEAD указывает в refs/heads/master (способа изменить ссылку через git-push вроде бы не существует), при этом бранча master нет, поэтому git-clone не создаёт ни одного бранча. После выполнения git-clone можно создать нужные бранчи для работы: git branch dbmail_2_2 origin/dbmail_2_2 или с одновременным выполнением checkout: git checkout -b dbmail_2_2 origin/dbmail_2_2 Можно ещё добавить опцию --track, или сконфигурировать репозиторий таким образом, чтобы --track использовалось по умолчанию: git config branch.autosetupmerge true Тогда при выполнении git-pull, когда бранч, созданный с опцией --track, является текущим, в этот бранч будут смержены изменения из того репозитория и бранча, который был указан вторым параметром git-branch. > Другой вопрос: что нужно написать в Push: в .git/remotes/origin (сейчас > он не используется), чтобы отправлять все содержимое репозитария? По умолчанию git-push отправляет все бранчи, присутствующие как в локальном, так и в удалённом репозитории, поэтому дополнительные действия требуются только при необходимости выложить новый бранч, которого ещё нет на другом конце. Можно использовать git push --all, но указать эту опцию в конфигурации нельзя (кроме того, в этом случае будут отправлены и ссылки из refs/remotes/, что обычно нежелательно). [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Eugene Prokopiev пишет: > Здравствуйте! > > Перед отправкой: > > $ git-branch > dbmail_2_2 > * srpms > > $ git-show-ref > 30f7175ef6fc270c42024820455e59c9b5866c1c refs/heads/dbmail_2_2 > 350fb9d63f4e90636eca217bb1c8f75922009319 refs/heads/srpms > 5c6384de1eee3de9e74be9f2d6f4df214b7a0c78 refs/tags/2.2.4-alt1 > f670fe9e78fc328349ed5f6d118930eee6394410 refs/tags/dbmail/2.2.4.200704090940 > > Оправка: > > git-push --repo=all git.alt:packages/dbmail.git еще интересно вот что: $ git-ls-remote http://git.altlinux.org/people/enp/packages/dbmail.git 30f7175ef6fc270c42024820455e59c9b5866c1c refs/heads/dbmail_2_2 350fb9d63f4e90636eca217bb1c8f75922009319 refs/heads/srpms 5c6384de1eee3de9e74be9f2d6f4df214b7a0c78 refs/tags/2.2.4-alt1 e628d2995f6f774af07d30ecd4626588d38ae703 refs/tags/2.2.4-alt1^{} f670fe9e78fc328349ed5f6d118930eee6394410 refs/tags/dbmail/2.2.4.200704090940 30f7175ef6fc270c42024820455e59c9b5866c1c refs/tags/dbmail/2.2.4.200704090940^{} откуда взялись еще 2 ref и что они из себя представляют? -- С уважением, Прокопьев Евгений
[-- Attachment #1: Type: text/plain, Size: 993 bytes --] On Mon, Apr 09, 2007 at 02:03:19PM +0400, Eugene Prokopiev wrote: > еще интересно вот что: > > $ git-ls-remote http://git.altlinux.org/people/enp/packages/dbmail.git > 30f7175ef6fc270c42024820455e59c9b5866c1c refs/heads/dbmail_2_2 > 350fb9d63f4e90636eca217bb1c8f75922009319 refs/heads/srpms > 5c6384de1eee3de9e74be9f2d6f4df214b7a0c78 refs/tags/2.2.4-alt1 > e628d2995f6f774af07d30ecd4626588d38ae703 refs/tags/2.2.4-alt1^{} > f670fe9e78fc328349ed5f6d118930eee6394410 refs/tags/dbmail/2.2.4.200704090940 > 30f7175ef6fc270c42024820455e59c9b5866c1c refs/tags/dbmail/2.2.4.200704090940^{} > > откуда взялись еще 2 ref и что они из себя представляют? Для каждого полноценного тега git-ls-remote выводит 2 строки; в одной из них указывается идентификатор tag object, а во второй (с "^{}") - идентификатор того объекта, на который указывает тег. Это используется, в частности, для автоматического получения тегов при выполнении git-fetch. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Приветствую всех, Разбираясь с внутренним устройством "производства пакетов", я пытаюсь вникнуть в "политику партии" и решил тщательно разобраться с текущей технологией GIT. Сразу скажу следующее: - я не программист (языки программирования знаю на уровне вузовской программы прошлого тысячелетия :) паскаль, фортран); - не работал с cvs и svn; - сейчас если программирую, то только на asm для DSP. Для себя вижу много нового и пока не совсем понятного, как и для части мейнтейнеров моего уровня. Есть желание и немного времени с этим разобраться. Вытянул архивы этой рассылки и просмотрел, что может мне помочь в сборке пакетов (запланировано прежде всего Moodle и Koha для образовательного дистрибутива). Вижу обрывки знаний команды (не люблю иноязычные термины, в данном случае - team) сопровождающих свои или сторонние программы или пакеты пронрамм. Не вижу целостности знаний. Для таких как я вижу необходимость в создании "пути джедая" - т.е. документации от "истока" до пакета на основе git (это в данной рассылке уже мелькало). Начнем с самого начала: 1. На git.altlinux.org доступны для использования только (на сегодня) следующие команды [builder@hedin]$ ssh git.alt help Enter passphrase for key '/home/builder/.ssh/svyt': Available commands: help git-receive-pack <directory> git-upload-pack <directory> git-clone <git-repository> [<directory>] git-init-db <directory> git-mv-db <source-directory> <dest-directory> git-rm-db <git-repository> build <git-repository> <tag> <binary-package-repository> [<project-name>] find-package <pattern> ls [<directory>] quota Все остальные команды git-* или gear-* можно делать только на локальной машине, а затем экспортировать на git.alt/pmimport 2. Далее следует один из возможных путей для переноса программы или пакета прграмм в git: - из внешнего или внутреннеого при помощи git-clone; - из внешнего или внутрннего cvs/svn на локальную манину в git при помощи git-cvs/svn import, а затем в git.alt; - из src.rpm при помощи gear-srpmimport на локальную, а затем в git-alt. - или git пакет формируется вручную. Каждый из эти подходов требует своего инструментария. О чем хотелось бы и написать на wiki.sisyphus.ru/devel. По мере отработки самостоятельно или при помощи команды буду стааться публиковать статью на вики для последующихпоколений. PS: для седя уже собрал часть необходимых пакетов как src.rpm теперь необходимо их правильно перенести на git.alt (пакеты собираются в hasher с текущим Сизифом).
15.06.07, Vladimir A. Svyatoshenko<svyt22 / gmail.com> написал(а): [...] > 2. Далее следует один из возможных путей для переноса программы или > пакета прграмм в git: [...] > - из src.rpm при помощи gear-srpmimport на локальную, а > затем в git-alt. [...] > Каждый из эти подходов требует своего инструментария. О чем хотелось бы > и написать на wiki.sisyphus.ru/devel. Об этом способе уже написано, и IMHO достаточно понятно/подробно: http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/gear/kis (Спасибо icesik@'у! Держу эту страницу в закладках) Ещё есть http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/git тоже хорошая дока. -- + Slava Semushin | slava.semushin @ gmail.com + ALT Linux Team | php-coder @ altlinux.ru
On Fri, 15 Jun 2007 19:54:45 +0700
Slava Semushin wrote:
> 15.06.07, Vladimir A. Svyatoshenko<svyt22 / gmail.com> написал(а):
> [...]
> > 2. Далее следует один из возможных путей для переноса программы или
> > пакета прграмм в git:
> [...]
> > - из src.rpm при помощи gear-srpmimport на локальную, а
> > затем в git-alt.
> [...]
> > Каждый из эти подходов требует своего инструментария. О чем
> > хотелось бы и написать на wiki.sisyphus.ru/devel.
>
> Об этом способе уже написано, и IMHO достаточно понятно/подробно:
> http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/gear/kis
>
Спасибо, как то пропустил
но вопросы по git-cvsimport остались, что то там не все ладно, или
руки :)
hi all А как удаляется бранч на git.alt? Я вот случайно в один из своих репо при git-push --all отправил бранч save. Как его стереть, чтоб глаза не мозолил? -- Артём Золочевский
[-- Attachment #1: Type: text/plain, Size: 961 bytes --] On [Mon, 13.08.2007 17:08], Slava Semushin wrote: > 2007/8/11, Artem Zolochevskiy <artem.zolochevskiy / gmail.com>: > [...] > > А как удаляется бранч на git.alt? > > Я вот случайно в один из своих репо при git-push --all отправил бранч save. > > Как его стереть, чтоб глаза не мозолил? > > Присоединяюсь к вопросу, а то у меня для wmbday висит бранч autotools.. On Sat, Feb 24, 2007 at 08:58:46PM +0300, Dmitry V. Levin wrote: DVL> После перехода git.alt на новый git можно удалять ненужные бранчи. DVL> Например, этот refs/head/up был убран командой DVL> $ git push git.alt :refs/heads/up -- 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 --]
[-- Attachment #1: Type: text/plain, Size: 270 bytes --] On Sat, Aug 11, 2007 at 06:30:50PM +0300, Artem Zolochevskiy wrote: > hi all > > А как удаляется бранч на git.alt? > Я вот случайно в один из своих репо при git-push --all отправил бранч save. > Как его стереть, чтоб глаза не мозолил? git-push git.alt :save [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
2007/8/11, Artem Zolochevskiy <artem.zolochevskiy / gmail.com>:
[...]
> А как удаляется бранч на git.alt?
> Я вот случайно в один из своих репо при git-push --all отправил бранч save.
> Как его стереть, чтоб глаза не мозолил?
Присоединяюсь к вопросу, а то у меня для wmbday висит бранч autotools..
P.S. И надо бы этот вопрос с ответом в FAQ или в tutorial на вики.
--
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru
>>>>> On 11 Aug 2007 at 21:30 "AZ" == Artem Zolochevskiy writes:
AZ> А как удаляется бранч на git.alt?
git push git.alt:packages/package.git :branch
--
vvk
[-- Attachment #1: Type: text/plain, Size: 498 bytes --] On Sat, Aug 11, 2007 at 06:30:50PM +0300, Artem Zolochevskiy wrote: > hi all > > А как удаляется бранч на git.alt? > Я вот случайно в один из своих репо при git-push --all отправил бранч save. > Как его стереть, чтоб глаза не мозолил? git push куда :save -- > 2All: кто нить подскажет когда соберут нормальный fidogate? Есть подозрение, что FIDO и "нормально" -- это всё-таки действительно несовместимо... кто ценит своё время -- давным-давно имеет IP. -- mike in community@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
2007/8/13, Vladimir V. Kamarzin <vvk@altlinux.ru>:
> >>>>> On 11 Aug 2007 at 21:30 "AZ" == Artem Zolochevskiy writes:
>
> AZ> А как удаляется бранч на git.alt?
>
> git push git.alt:packages/package.git :branch
У меня не получилось:
[c0der@rock ~/git/wmbday/wmbday.git]$ git-push git:packages/katrin :autotools
RSA host key for IP address '194.107.17.12' not in list of known hosts.
Enter passphrase for key '/home/coder/.ssh/id_dsa':
error: dst refspec autotools does not match any existing ref on the
remote and d oes not start with refs/.
fatal: The remote end hung up unexpectedly
error: failed to push to 'git:packages/katrin'
[c1der@rock ~/git/wmbday/wmbday.git]$ git-push git:packages/katrin
refs/autotools
RSA host key for IP address '194.107.17.12' not in list of known hosts.
Enter passphrase for key '/home/coder/.ssh/id_dsa':
Enter passphrase for key '/home/coder/.ssh/id_dsa':
error: src refspec refs/autotools does not match any.
fatal: The remote end hung up unexpectedly
error: failed to push to 'git:packages/katrin'
[c1der@rock ~/git/wmbday/wmbday.git]$
--
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --] On Tue, Aug 14, 2007 at 08:32:21PM +0700, Slava Semushin wrote: > 2007/8/13, Vladimir V. Kamarzin <vvk@altlinux.ru>: > > >>>>> On 11 Aug 2007 at 21:30 "AZ" == Artem Zolochevskiy writes: > > > > AZ> А как удаляется бранч на git.alt? > > > > git push git.alt:packages/package.git :branch > > У меня не получилось: > > [c0der@rock ~/git/wmbday/wmbday.git]$ git-push git:packages/katrin :autotools > RSA host key for IP address '194.107.17.12' not in list of known hosts. > Enter passphrase for key '/home/coder/.ssh/id_dsa': > error: dst refspec autotools does not match any existing ref on the > remote and d oes not start with refs/. > fatal: The remote end hung up unexpectedly > error: failed to push to 'git:packages/katrin' > > [c1der@rock ~/git/wmbday/wmbday.git]$ git-push git:packages/katrin > refs/autotools > RSA host key for IP address '194.107.17.12' not in list of known hosts. > Enter passphrase for key '/home/coder/.ssh/id_dsa': > Enter passphrase for key '/home/coder/.ssh/id_dsa': > error: src refspec refs/autotools does not match any. > fatal: The remote end hung up unexpectedly > error: failed to push to 'git:packages/katrin' > [c1der@rock ~/git/wmbday/wmbday.git]$ rpm -q git оно вроде появилось только в >= 1.5 -- > Starting python.... > 'import site' filed use -v for trace back Попробуйте сделать то что просят... вдруг поможет... -- ns in community@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
2007/8/15, Pavlov Konstantin <thresh / altlinux.ru>: [...] > > [c1der@rock ~/git/wmbday/wmbday.git]$ git-push git:packages/katrin > > refs/autotools > > RSA host key for IP address '194.107.17.12' not in list of known hosts. > > Enter passphrase for key '/home/coder/.ssh/id_dsa': > > Enter passphrase for key '/home/coder/.ssh/id_dsa': > > error: src refspec refs/autotools does not match any. > > fatal: The remote end hung up unexpectedly > > error: failed to push to 'git:packages/katrin' > > [c1der@rock ~/git/wmbday/wmbday.git]$ > > rpm -q git [c0der@rock ~]$ rpm -q git 18:19 предупреждение: пакет git не установлен [c1der@rock ~]$ rpm -q git-core 18:19 git-core-1.5.2.4-alt1 > оно вроде появилось только в >= 1.5 Вроде версия достаточная. -- + Slava Semushin | slava.semushin @ gmail.com + ALT Linux Team | php-coder @ altlinux.ru
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --] On Wed, Aug 15, 2007 at 06:23:47PM +0700, Slava Semushin wrote: > 2007/8/15, Pavlov Konstantin <thresh / altlinux.ru>: > [...] > > > [c1der@rock ~/git/wmbday/wmbday.git]$ git-push git:packages/katrin > > > refs/autotools > > > RSA host key for IP address '194.107.17.12' not in list of known hosts. > > > Enter passphrase for key '/home/coder/.ssh/id_dsa': > > > Enter passphrase for key '/home/coder/.ssh/id_dsa': > > > error: src refspec refs/autotools does not match any. > > > fatal: The remote end hung up unexpectedly > > > error: failed to push to 'git:packages/katrin' > > > [c1der@rock ~/git/wmbday/wmbday.git]$ > > > > rpm -q git > > [c0der@rock ~]$ rpm -q git 18:19 > предупреждение: пакет git не установлен > [c1der@rock ~]$ rpm -q git-core 18:19 > git-core-1.5.2.4-alt1 > > > оно вроде появилось только в >= 1.5 > > Вроде версия достаточная. А если попробовать из ~/git/katrin/katrin.git ? :) -- > Package: kernel-modules-drm-wks-up-6.8.1-alt1.3 > Cannot build this package for 3 week(s) (since Wed Nov 10 2004). > Please investigate. блин, мне этот drm уже по ночам сниться начнет... -- lakostis in devel@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
2007/8/15, Pavlov Konstantin <thresh / altlinux.ru>:
[...]
> А если попробовать из ~/git/katrin/katrin.git ? :)
[...]
Свою ошибку понял -- спасибо.
--
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru
[-- Attachment #1: Type: text/plain, Size: 128 bytes --] On Sat, Aug 11, 2007 at 06:30:50PM +0300, Artem Zolochevskiy wrote: > А как удаляется бранч на git.alt? А как удалить ТАГ? [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 224 bytes --] Alexey Tourbin пишет: > On Sat, Aug 11, 2007 at 06:30:50PM +0300, Artem Zolochevskiy wrote: > >>А как удаляется бранч на git.alt? > > > А как удалить ТАГ? Как refs/tags/<ТАГ> -- С уважением. Алексей. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 548 bytes --]
[-- Attachment #1: Type: text/plain, Size: 178 bytes --] On Fri, Aug 17, 2007 at 11:48:11PM +0400, Aleksey Avdeev wrote: > > А как удалить ТАГ? > Как refs/tags/<ТАГ> Так не удаляется. Кажется в girar-обвязке не предусмотрено. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Привет, я первый раз залил репозиторий на git.alt и в ужасом обнаружил что commit-message у меня на русском языке в utf-8. Насколько это страшно? -- Gennady Kovalev, BIGUR, ALT Linux Team.
В сообщении от Thursday 13 December 2007 00:16:37 Gennady Kovalev написал(а):
> Привет, я первый раз залил репозиторий на git.alt и в ужасом обнаружил что
> commit-message у меня на русском языке в utf-8.
>
> Насколько это страшно?
А вот теперь вопрос как переделать commit-log. Коммит собственно первый, никто
не мешает сделать пустой репозиторий и заново закоммитить. Но вдруг есть
штатные средства переделать commit log первого коммита?
--
Gennady Kovalev,
BIGUR, ALT Linux Team.
On Dec 14, 2007 1:41 AM, Gennady Kovalev <gik@bigur.ru> wrote:
> А вот теперь вопрос как переделать commit-log. Коммит собственно первый, никто
> не мешает сделать пустой репозиторий и заново закоммитить. Но вдруг есть
> штатные средства переделать commit log первого коммита?
Штатные средства переделать commit log — это git-commit --amend.
Ну и если речь идёт об sqlalchemy, то можно сделать
git clone git://git.altlinux.org/archive/p/python-module-SQLAlchemy.git
и коммит будет не первым.
В сообщении от Friday 14 December 2007 01:41:25 Gennady Kovalev написал(а): > А вот теперь вопрос как переделать commit-log. Коммит собственно первый, > никто не мешает сделать пустой репозиторий и заново закоммитить. Но вдруг > есть штатные средства переделать commit log первого коммита? http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/git/recommit -- Regards, Sergey Alembekov ALTLinux Team xmpp: rt at jabber.ru
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --] On Sun, Feb 17, 2008 at 07:42:21PM +0200, Michael Shigorin wrote: [...] > Хуже: сейчас кто как хочет/умеет, тот так и развлекается. > Чтобы помочь, сначала надо въехать, какой именно стиль применён > в заданном пакете. Думаешь, слишком много свободы? Инструмент должен давать свободу действий. > Мне кажется, это действительно серьёзная проблема: для помощи > требуется не просто владеть хотя бы основами git на уровне > пользователя, а иметь сопоставимую с $MAINTAINER квалификацию > _именно_ в использовании этого инструмента. Что практически > убивает саму идею. Это преувеличение. Для того, чтобы помочь, чтобы сделать pull/commit/pull, не обязательно разбираться в технике ведения репозитория. > Например, для изменений в nginx мы с mithraen@ договорились, > что он втягивает мои изменения -- а вот обновления версии делает > сам, поскольку там заморочки. Твой комментарий подтверждает мою мысль. > Если в таком неопределённом и разобщённом (за пределами > gear-srpmimport) виде выкатываться, может получиться плохо. Ты думаешь, можно сделать такой репозиторий, в который будет слишком сложно вносить изменения? > Или общее -- как раз srpmimport, а дальше я сгущаю краски? > Просто его результат нечасто встречаю, обычно рукоделие... Почти все мои gear-репозитории выросли из результата работы gear-srpmimport'а. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
On Sun, Feb 17, 2008 at 08:55:22PM +0300, Dmitry V. Levin wrote: > > Хуже: сейчас кто как хочет/умеет, тот так и развлекается. > > Чтобы помочь, сначала надо въехать, какой именно стиль > > применён в заданном пакете. > Думаешь, слишком много свободы? > Инструмент должен давать свободу действий. Я не против свободы действий, я о недостатке принятых путей. Асфальт -- это хорошо, но с определением сторонности движения. > > Мне кажется, это действительно серьёзная проблема: для помощи > > требуется не просто владеть хотя бы основами git на уровне > > пользователя, а иметь сопоставимую с $MAINTAINER квалификацию > > _именно_ в использовании этого инструмента. Что практически > > убивает саму идею. > Это преувеличение. > Для того, чтобы помочь, чтобы сделать pull/commit/pull, > не обязательно разбираться в технике ведения репозитория. OK, попробуй обновить тарбол в /people/mithraen/packages/nginx.git и объяснить нам с Денисом, где он меня зря пугал, а я зря пугался. :) > > Например, для изменений в nginx мы с mithraen@ договорились, > > что он втягивает мои изменения -- а вот обновления версии > > делает сам, поскольку там заморочки. > Твой комментарий подтверждает мою мысль. Ну при этом _сейчас_ мне приходится дёргать лишний раз его для rebuild. Наверное, можно и сейчас попросить acl, поскольку коммуникации хорошо налажены -- но вот мотивации поправить багу, об которую случайно спотыкаешься, обычно недостаточно. Надо вытащить репозиторий (например, для проверки того, что в 24-ovz фактически никак не приложен патчик, упомянутый в bugzilla.openvz.org, пришлось вытащить полгига git repo -- ждём shallow clones?); понять, как он устроен; понять, каков стиль внесения изменений в него... Я не говорю, что идея плоха или реализация никуда не годится -- но пытаюсь понять, в чём текущие проблемы (они отчасти обусловлены incoming+acl+srpms) и какие из них всё равно не решаются -- или усугубляются -- переездом incoming на git. (для архива: рядом упомянутый гипотетический contrib предлагалось гарантировать как возможный к пополнению именно srpms вне зависимости от) > > Если в таком неопределённом и разобщённом (за пределами > > gear-srpmimport) виде выкатываться, может получиться плохо. > Ты думаешь, можно сделать такой репозиторий, в который будет > слишком сложно вносить изменения? Вносить-то их может оказаться несложно, а вот понять, как это делать... Почитав описание raorn@ насчёт mutt, понял, что очень рад тому, что туда не надо лазить :) > > Или общее -- как раз srpmimport, а дальше я сгущаю краски? > > Просто его результат нечасто встречаю, обычно рукоделие... > Почти все мои gear-репозитории выросли из результата работы > gear-srpmimport'а. Твои едва ли не наименее интересны среднему начинающему контрибутору git.alt (вроде меня) как раз. :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #1: Type: text/plain, Size: 484 bytes --] On Sun, Feb 17, 2008 at 08:55:22PM +0300, Dmitry V. Levin wrote: > Для того, чтобы помочь, чтобы сделать pull/commit/pull, > не обязательно разбираться в технике ведения репозитория. Но при этом нужно знать, куда и как именно в данном репозитории принято делать commit - где-то до сих пор нужно добавлять файлы с патчами, где-то принято коммитить прямо в master, где-то есть куча бранчей, и нужно понять, коммитить эти изменения в какой-то существующий, или заводить новый. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 713 bytes --] On Sun, Feb 17, 2008 at 09:14:39PM +0300, Sergey Vlasov wrote: > On Sun, Feb 17, 2008 at 08:55:22PM +0300, Dmitry V. Levin wrote: > > Для того, чтобы помочь, чтобы сделать pull/commit/pull, > > не обязательно разбираться в технике ведения репозитория. > > Но при этом нужно знать, куда и как именно в данном репозитории > принято делать commit - где-то до сих пор нужно добавлять файлы с > патчами, где-то принято коммитить прямо в master, где-то есть куча > бранчей, и нужно понять, коммитить эти изменения в какой-то > существующий, или заводить новый. Это же видно сразу. Или нет? Если нет, то давайте опишем, как определить по внешнему виду репозитория, какой стиль там принят. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
> Это же видно сразу. Или нет? Если нет, то давайте опишем, как
> определить по внешнему виду репозитория, какой стиль там принят.
Как правило, файл .gear-rules описывает стиль практически полностью.
On Sun, Feb 17, 2008 at 09:39:27PM +0300, Damir Shayhutdinov wrote: > > Это же видно сразу. Или нет? Если нет, то давайте опишем, как > > определить по внешнему виду репозитория, какой стиль там принят. > Как правило, файл .gear-rules описывает стиль практически полностью. Гм. А возможно ли как-то формализовать и выдёргивать для sisyphus.ru сводки? "[g-s]" "[kthu]" "[...]" :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #1: Type: text/plain, Size: 1702 bytes --] Twas brillig at 20:55:22 17.02.2008 UTC+03 when Dmitry V. Levin did gyre and gimble: >> Хуже: сейчас кто как хочет/умеет, тот так и развлекается. >> Чтобы помочь, сначала надо въехать, какой именно стиль применён >> в заданном пакете. DVL> Инструмент должен давать свободу действий. Можно не решить декларированную задачу "не терять NMU": NMU просто не будет из-за того, что будет непонятно, как из данном конкретного репозитория сделать NMU. Совместной работы в стиле "я тут сделал классный патч, pull пожалуйста", которой хорош в git тоже может не получиться. DVL> Это преувеличение. Для того, чтобы помочь, чтобы сделать DVL> pull/commit/pull, не обязательно разбираться в технике ведения DVL> репозитория. Нужно хотя бы понимать, что патчить. А то я взял тут какой-то репозиторий и вертел его, пока raorn не пришёл и не посоветовал половину бранчей убить, а остальные переименовать. Этот ненулевой порог деланья патча сильно мешает - нужно постоянно советоваться с майнтайнером. -- [-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1564 bytes --] On Mon, Feb 18, 2008 at 04:15:50AM +0600, Mikhail Gusarov wrote: > Twas brillig at 20:55:22 17.02.2008 UTC+03 when Dmitry V. Levin did gyre and gimble: > > >> Хуже: сейчас кто как хочет/умеет, тот так и развлекается. > >> Чтобы помочь, сначала надо въехать, какой именно стиль применён > >> в заданном пакете. > > DVL> Инструмент должен давать свободу действий. > > Можно не решить декларированную задачу "не терять NMU": NMU просто не > будет из-за того, что будет непонятно, как из данном конкретного > репозитория сделать NMU. > > Совместной работы в стиле "я тут сделал классный патч, pull пожалуйста", > которой хорош в git тоже может не получиться. Я думаю что вы преувеличиваете сложности, которые обычно возникают. Обычно процент нетривиальных применений инструмента бывает невелик. > DVL> Это преувеличение. Для того, чтобы помочь, чтобы сделать > DVL> pull/commit/pull, не обязательно разбираться в технике ведения > DVL> репозитория. > > Нужно хотя бы понимать, что патчить. А то я взял тут какой-то > репозиторий и вертел его, пока raorn не пришёл и не посоветовал половину > бранчей убить, а остальные переименовать. > > Этот ненулевой порог деланья патча сильно мешает - нужно постоянно > советоваться с майнтайнером. Я думаю что это исключение: большинство gear-репозиториев простые как табуретки. Можно произвести простой эксперимент: взять из файла http://git.altlinux.org/people-packages-list случайные 10 репозиториев и проверить, сколько из них не сразу понятно как патчить. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 316 bytes --] * Dmitry V. Levin <ldv@> [080218 01:33]: > Можно произвести простой эксперимент: взять из файла > http://git.altlinux.org/people-packages-list > случайные 10 репозиториев и проверить, сколько из них не сразу понятно > как патчить. А по оси Икс у нас будет дата первого коммита ;-) -- Regards, Sir Raorn. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
On Sun, Feb 17, 2008 at 08:55:22PM +0300, Dmitry V. Levin wrote:
> On Sun, Feb 17, 2008 at 07:42:21PM +0200, Michael Shigorin wrote:
> [...]
> > Хуже: сейчас кто как хочет/умеет, тот так и развлекается.
> > Чтобы помочь, сначала надо въехать, какой именно стиль применён
> > в заданном пакете.
>
> Думаешь, слишком много свободы?
> Инструмент должен давать свободу действий.
>
> > Мне кажется, это действительно серьёзная проблема: для помощи
> > требуется не просто владеть хотя бы основами git на уровне
> > пользователя, а иметь сопоставимую с $MAINTAINER квалификацию
> > _именно_ в использовании этого инструмента. Что практически
> > убивает саму идею.
>
> Это преувеличение.
> Для того, чтобы помочь, чтобы сделать pull/commit/pull,
> не обязательно разбираться в технике ведения репозитория.
>
> > Например, для изменений в nginx мы с mithraen@ договорились,
> > что он втягивает мои изменения -- а вот обновления версии делает
> > сам, поскольку там заморочки.
>
> Твой комментарий подтверждает мою мысль.
>
> > Если в таком неопределённом и разобщённом (за пределами
> > gear-srpmimport) виде выкатываться, может получиться плохо.
>
> Ты думаешь, можно сделать такой репозиторий, в который будет
> слишком сложно вносить изменения?
Запросто, достаточно поглядеть на kernel и темы gfxboot с их
многочисленными бранчами и пустым репозитарием после первого checkout ;)
Damir Shayhutdinov пишет:
>> Это же видно сразу. Или нет? Если нет, то давайте опишем, как
>> определить по внешнему виду репозитория, какой стиль там принят.
>
> Как правило, файл .gear-rules описывает стиль практически полностью.
Не факт. Для kernel-image и kernel-modules это утверждение ошибочно.
[-- Attachment #1: Type: text/plain, Size: 562 bytes --] Twas brillig at 10:18:45 18.02.2008 UTC+03 when Anton Farygin did gyre and gimble: >> Как правило, файл .gear-rules описывает стиль практически полностью. AF> Не факт. Для kernel-image и kernel-modules это утверждение ошибочно. Ядро, всё-таки, отдельный случай. Для него можно и отдельную краткую доку по патченью/бранченью. vsu, ау :) Общественность жаждет. -- [-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Attachment #1: Type: text/plain, Size: 386 bytes --] On Mon, Feb 18, 2008 at 10:16:56AM +0300, Stanislav Ievlev wrote: SI> Запросто, достаточно поглядеть на kernel и темы gfxboot с их SI> многочисленными бранчами и пустым репозитарием после первого checkout ;) apt-get install seiros-build-utils Co -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 937 bytes --] On Sun, Feb 17, 2008 at 09:14:39PM +0300, Sergey Vlasov wrote: >> Для того, чтобы помочь, чтобы сделать pull/commit/pull, >> не обязательно разбираться в технике ведения репозитория. SV> Но при этом нужно знать, куда и как именно в данном репозитории SV> принято делать commit - где-то до сих пор нужно добавлять файлы с SV> патчами, где-то принято коммитить прямо в master, где-то есть куча SV> бранчей, и нужно понять, коммитить эти изменения в какой-то SV> существующий, или заводить новый. Если это патч на spec -- в тот бранч где лежит spec. Если в .gear/rules патчи генерируются из бранчей -- либо в один из этих бранчей, либо в новый бранч. Обновление для .gear/rules мантейнер может и сам сделать. Если патчи лежат в виде файликов -- всем и так все ясно. Три простых правила. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2390 bytes --] On Sun, Feb 17, 2008 at 08:11:52PM +0200, Michael Shigorin wrote: >> Это преувеличение. >> Для того, чтобы помочь, чтобы сделать pull/commit/pull, >> не обязательно разбираться в технике ведения репозитория. MS> OK, попробуй обновить тарбол в /people/mithraen/packages/nginx.git MS> и объяснить нам с Денисом, где он меня зря пугал, а я зря пугался. MS> :) А! Обновление версии это действительно отдельная песня. А уж если используется импорт из какого-нибудь svn, то проще застрелиться чем другому человеку что-нибудь обновить. Хотя человек хорошо разбирающийся в git быстро поймет что там сделано. (оригинал лежит в upstream, а в master пропатченый оригинал, .gear/rules и спек). > >> Например, для изменений в nginx мы с mithraen@ договорились, > >> что он втягивает мои изменения -- а вот обновления версии > >> делает сам, поскольку там заморочки. >> Твой комментарий подтверждает мою мысль. MS> Ну при этом _сейчас_ мне приходится дёргать лишний раз его для MS> rebuild. Наверное, можно и сейчас попросить acl, поскольку MS> коммуникации хорошо налажены -- но вот мотивации поправить багу, MS> об которую случайно спотыкаешься, обычно недостаточно. Тут, кстати, действительно есть проблема. С одной стороны я не имею ничего против того, чтобы после появления сборки из git ты самостоятельно мог залить пропатченый nginx. С другой стороны, я уверен что будут люди, которым я могу доверить залить пропатченую сборку, но которые могут попытаться обновить версию -- и действительно не въедут сразу в ту простую схему, что я использую. >>> Или общее -- как раз srpmimport, а дальше я сгущаю краски? >>> Просто его результат нечасто встречаю, обычно рукоделие... >> Почти все мои gear-репозитории выросли из результата работы >> gear-srpmimport'а. MS> Твои едва ли не наименее интересны среднему начинающему MS> контрибутору git.alt (вроде меня) как раз. :) Да ладно, я вот боюсь скоро буду локально использовать форк от ssh (с теми самыми высокоскоростными патчами), а также у меня уже давно патченая libtiff :) Самые проблемные репозитории -- те, где используется импорт из внешних репозиториев, и будут оставаться такими до тех пор, пока этот импорт не будет производится на стороне git.altlinux.ru. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
On Mon, Feb 18, 2008 at 05:57:11PM +0300, Денис Смирнов wrote: > MS> Например, для изменений в nginx мы с mithraen@ договорились, > MS> что он втягивает мои изменения -- а вот обновления версии делает > MS> сам, поскольку там заморочки. > Вот это и есть правильный workflow. Нет, конечно. Смысл от таких rebuild? И если мне припрёт новая версия, а ты будешь завален по самую маковку на ближайшую неделю? > Единственное что было бы еще нужно -- сделать привычку > "добавлять запись в changelog и вообще трогать spec" и > собственно изменение делать разными commit'ами (на случай если > мантейнер держит патчи в разных бранчах). Спасибо, не знал. > Помнишь нашу разборку с поддержкой large files в apache? Если > бы апач и все модули лежали в git _и_ собирались прямо из git > (по схеме, которой пока не существует) -- я бы прямо тогда пару > раз выругался бы, а потом сел и за час эту проблему решил бы > раз и навсегда. Я тогда отказался от этой затеи по другой причине -- собранные руками, в своих пакетах или (худшее) 3rd party modules поломаются, причём неочевидным образом... -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #1: Type: text/plain, Size: 1785 bytes --] On Mon, Feb 18, 2008 at 06:20:56PM +0200, Michael Shigorin wrote: > MS>> Например, для изменений в nginx мы с mithraen@ договорились, > MS>> что он втягивает мои изменения -- а вот обновления версии делает > MS>> сам, поскольку там заморочки. >> Вот это и есть правильный workflow. MS> Нет, конечно. Смысл от таких rebuild? И если мне припрёт новая MS> версия, а ты будешь завален по самую маковку на ближайшую неделю? Вот в этом случае -- да, тебе нужно будет знать уже несколько больше. А то, что твои изменения не связаные с обновлением версии проводятся через такой rebuild -- это только потому что не работает сборка прямо из git. Если бы работала -- я бы выдал тебе соответствующие права и не заморачивался бы. >> Единственное что было бы еще нужно -- сделать привычку >> "добавлять запись в changelog и вообще трогать spec" и >> собственно изменение делать разными commit'ами (на случай если >> мантейнер держит патчи в разных бранчах). MS> Спасибо, не знал. Это полезно если патчи и метаинформация лежат в разных бранчах. >> Помнишь нашу разборку с поддержкой large files в apache? Если >> бы апач и все модули лежали в git _и_ собирались прямо из git >> (по схеме, которой пока не существует) -- я бы прямо тогда пару >> раз выругался бы, а потом сел и за час эту проблему решил бы >> раз и навсегда. MS> Я тогда отказался от этой затеи по другой причине -- собранные MS> руками, в своих пакетах или (худшее) 3rd party modules MS> поломаются, причём неочевидным образом... Гм. Насчет собранных руками -- для Сизифа и нового дистрибутива это не так существенно. А вот насчет 3rd party... А что например? -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 650 bytes --] On Mon, Feb 18, 2008 at 10:18:45AM +0300, Anton Farygin wrote: >>> Это же видно сразу. Или нет? Если нет, то давайте опишем, как >>> определить по внешнему виду репозитория, какой стиль там принят. >> Как правило, файл .gear-rules описывает стиль практически полностью. AF> Не факт. Для kernel-image и kernel-modules это утверждение ошибочно. kernel-* сейчас доступны лишь для Истинных Великих Мастеров. Мне до сих пор не удалось столько выпить, чтобы въехать в это. Хотя оно, судя по всему тривиально. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
On Tue, Feb 19, 2008 at 12:37:28AM +0300, Денис Смирнов wrote: > Если бы работала -- я бы выдал тебе соответствующие права и не > заморачивался бы. Ну так выдай ACL пока, или это я глюпый, что сразу не попросил? :) > >> Помнишь нашу разборку с поддержкой large files в apache? > >> Если бы апач и все модули лежали в git _и_ собирались прямо > >> из git (по схеме, которой пока не существует) -- я бы прямо > >> тогда пару раз выругался бы, а потом сел и за час эту > >> проблему решил бы раз и навсегда. > MS> Я тогда отказался от этой затеи по другой причине -- собранные > MS> руками, в своих пакетах или (худшее) 3rd party modules > MS> поломаются, причём неочевидным образом... > Гм. Насчет собранных руками -- для Сизифа и нового дистрибутива > это не так существенно. А вот насчет 3rd party... А что > например? Zend'овские поделия, если правильно помню обсуждение в тех багах (на apache или apache-common, в комментариях было O_LARGEFILE). -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #1: Type: text/plain, Size: 753 bytes --] On Wed, Feb 20, 2008 at 01:29:38PM +0200, Michael Shigorin wrote: >> Если бы работала -- я бы выдал тебе соответствующие права и не >> заморачивался бы. MS> Ну так выдай ACL пока, или это я глюпый, что сразу не попросил? MS> :) Если я выдам, у нас потенциально полный дурдом может оказаться (если сборка в сизифе не будет соответствовать репо). Как ты заметил я обычно максимум в 24 часа твои изменения все-таки импортирую и отправляю в incoming :) MS> Zend'овские поделия, если правильно помню обсуждение в тех багах MS> (на apache или apache-common, в комментариях было O_LARGEFILE). (вздыхая) о ужас! -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 986 bytes --] On Fri, Aug 01, 2008 at 12:55:32AM +0300, Igor Zubkov wrote: > 1 августа 2008 г. 0:24 пользователь Dmitry V. Levin написал: > >> На collaboration он не хочет идти с Aug 22 2007. Ах да, это ведь не > >> git.alt! А мне вот не охота связыватся с git.alt для пакета в котором > >> вообще не должно быть патчей. > > > > Однако с git.alt придётся связаться, причём чем раньше, тем лучше. > > Иначе collaboration, скорее всего, не выйдет. > > Зачем? Тут плюсов от git получить не получится. Я понимаю что git.alt > рулит, но только для части пакетов. Ядро пилить без git это просто > изврат. Дерево моего ice-wks у меня на винте лежит, но вот публиковать > его мне просто не получается. Слишком много трафика это для моего > тарифа у провайдера что у меня дома. Обычно пересылка srpm-пакетов создаёт больше трафика, чем git fetch и git pull, за исключением первичной закачки git-репозитория. Кроме того, возможно, имеет смысл поменять тариф и/или провайдера. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
1 августа 2008 г. 1:03 пользователь Dmitry V. Levin написал: >> Зачем? Тут плюсов от git получить не получится. Я понимаю что git.alt >> рулит, но только для части пакетов. Ядро пилить без git это просто >> изврат. Дерево моего ice-wks у меня на винте лежит, но вот публиковать >> его мне просто не получается. Слишком много трафика это для моего >> тарифа у провайдера что у меня дома. > > Обычно пересылка srpm-пакетов создаёт больше трафика, чем git fetch и > git pull, за исключением первичной закачки git-репозитория. Это понятно. Но src.rpm'ы проще. Когда я в первый раз увидел hasher я был счастлив как ребёнок. Я тогда собирал свой дистрибутив и как раз писал свой hasher. Это было похоже на mach, но только на C. А вот сейчас эти движения с git мне катострафически не нравятся. git уменьшает круг людей которые будут заниматся именно такой разработкой (скажем так, завышает планку там где этого не надо делать). Какой кайф делать git clone для репки которая пять мешков и там нет ничего чего не было у апстрима (пять шеков это для примера, никакой аналогии с мегабайтами тут нет)? Так это ещё надо читать документацию на git. А она не такая простая и не такая уж и маленькая. Да ещё и на английском. Иного, новички которые хотели бы что-то сделать уйдут сразу. Я не новичёк, но мне уже изрядно всё надоело. > Кроме того, возможно, имеет смысл поменять тариф и/или провайдера. Это у меня в планах уже более полугода. К тому же, сейчас уже есть альтернативы. Но это уже другой разговор... -- icesik
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --] On Fri, Aug 01, 2008 at 01:20:07AM +0300, Igor Zubkov wrote: > 1 августа 2008 г. 1:03 пользователь Dmitry V. Levin написал: > >> Зачем? Тут плюсов от git получить не получится. Я понимаю что git.alt > >> рулит, но только для части пакетов. Ядро пилить без git это просто > >> изврат. Дерево моего ice-wks у меня на винте лежит, но вот публиковать > >> его мне просто не получается. Слишком много трафика это для моего > >> тарифа у провайдера что у меня дома. > > > > Обычно пересылка srpm-пакетов создаёт больше трафика, чем git fetch и > > git pull, за исключением первичной закачки git-репозитория. > > Это понятно. Но src.rpm'ы проще. Когда я в первый раз увидел hasher я > был счастлив как ребёнок. Я тогда собирал свой дистрибутив и как раз > писал свой hasher. Это было похоже на mach, но только на C. А вот > сейчас эти движения с git мне катострафически не нравятся. git > уменьшает круг людей которые будут заниматся именно такой разработкой Я думаю, что уже сейчас git более широко известен чем hasher, и в дальнейшем распространённость git как инструмента будет только расти. > (скажем так, завышает планку там где этого не надо делать). Какой кайф > делать git clone для репки которая пять мешков и там нет ничего чего > не было у апстрима (пять шеков это для примера, никакой аналогии с > мегабайтами тут нет)? Имея удалённый shell с быстрым каналом до разных git-репозиториев, делать git clone можно не задумываясь. Я думаю что скоро мы сможем предоставлять такую возможность каждому мантейнеру. > Так это ещё надо читать документацию на git. А > она не такая простая и не такая уж и маленькая. Достаточно простая и вполне обозримая. > Да ещё и на английском. Не вижу в этом никакой сложности. При желании можно перевести. > Иного, новички которые хотели бы что-то сделать уйдут > сразу. Я не новичёк, но мне уже изрядно всё надоело. Очевидно, это произошло по другой причине. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --] On Fri, Aug 01, 2008 at 01:20:07AM +0300, Igor Zubkov wrote: > 1 августа 2008 г. 1:03 пользователь Dmitry V. Levin написал: > >> Зачем? Тут плюсов от git получить не получится. Я понимаю что git.alt > >> рулит, но только для части пакетов. Ядро пилить без git это просто > >> изврат. Дерево моего ice-wks у меня на винте лежит, но вот публиковать > >> его мне просто не получается. Слишком много трафика это для моего > >> тарифа у провайдера что у меня дома. > > > > Обычно пересылка srpm-пакетов создаёт больше трафика, чем git fetch и > > git pull, за исключением первичной закачки git-репозитория. > > Это понятно. Но src.rpm'ы проще. Когда я в первый раз увидел hasher я > был счастлив как ребёнок. Я тогда собирал свой дистрибутив и как раз > писал свой hasher. Это было похоже на mach, но только на C. А вот > сейчас эти движения с git мне катострафически не нравятся. git > уменьшает круг людей которые будут заниматся именно такой разработкой По-моему, есть два подхода к работе над rpm пакетами. 1) Условно "запаковка". Люди заворачивают апстримовские тарболлы в rpm пакеты с минимальными изменениями. Это занятие довольно экстенсивное, хотя временами и неизбежное. Как следствие, люди зачастую не смотрят в исходники, а например, увлекаются спорами, какая форма записи в спеке предпочтительнее: autoreconf, %__autoreconf или %autoreconf, и т.д. 2) Разработка. Люди втягиваются и начинают хачить, или, по крайней мере, смотрят в исходники и начинают понимать, в чем там дело. В перспективе разработка может войти в интенсивную фазу. Для разработки тарболлы вредны -- если количество патчей растёт быстрее, чем их забирает апстрим, то для поддержки изменений лучше использовать не патчи, а полноценный SCM. Теперь представь, что хачить начитают два или три человека. Здесь git даёт все удобства для совместной разработки. Так что надо задать себе вопрос: кто я? Запаковщик тарболлов в rpm'ы или разработчик? Запаковка тарболлов не котруется. Ни с точки зрения индивидуального роста, ни с точки зрения выигрыша для ALT Linux Team. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
1 августа 2008 г. 1:32 пользователь Dmitry V. Levin написал: >> Это понятно. Но src.rpm'ы проще. Когда я в первый раз увидел hasher я >> был счастлив как ребёнок. Я тогда собирал свой дистрибутив и как раз >> писал свой hasher. Это было похоже на mach, но только на C. А вот >> сейчас эти движения с git мне катострафически не нравятся. git >> уменьшает круг людей которые будут заниматся именно такой разработкой > > Я думаю, что уже сейчас git более широко известен чем hasher, и в > дальнейшем распространённость git как инструмента будет только расти. hasher как раз хорош тем что он работает почти из коробки. Это просто средство проверки пакетов на сборо-прочность в текущем репозитории, а не в том что называется Сизиф который стоит на машине. Конечно же, после buildreq. Это две из самых главных фич альта. К списку, конечно же, надо добавить ещё rpm-build-*. >> (скажем так, завышает планку там где этого не надо делать). Какой кайф >> делать git clone для репки которая пять мешков и там нет ничего чего >> не было у апстрима (пять шеков это для примера, никакой аналогии с >> мегабайтами тут нет)? > > Имея удалённый shell с быстрым каналом до разных git-репозиториев, У меня есть не один удалёный шелл с жирными каналами. А если не хватит, ещё добавят. Проблема в том что у меня дома нет анлимного канала. Заниматся Сизифом на работе просто некогда. А вот дома, в таком случае, не позволяют тех. возможности. > делать git clone можно не задумываясь. Я думаю что скоро мы сможем > предоставлять такую возможность каждому мантейнеру. А толку? Аналогию с ядром я не просто так привёл. Даже если я соберу ядро, для тестирования мне придётся его затянуть обратно и проверить. И не раз. И толку от такого шелла? >> Так это ещё надо читать документацию на git. А >> она не такая простая и не такая уж и маленькая. > > Достаточно простая и вполне обозримая. > >> Да ещё и на английском. > > Не вижу в этом никакой сложности. При желании можно перевести. Вот только ещё никто не перевёл. Моего Elementary для восприятия этой документации на английском явно не достаточно. >> Иного, новички которые хотели бы что-то сделать уйдут >> сразу. Я не новичёк, но мне уже изрядно всё надоело. > > Очевидно, это произошло по другой причине. Это не ответ. Что очевидно? Что новички уйдуит или что мне всё изрядно надоело? -- icesik
Friday, 01 August 2008 01:53:48 Alexey Tourbin написав:
> On Fri, Aug 01, 2008 at 01:20:07AM +0300, Igor Zubkov wrote:
> > 1 августа 2008 г. 1:03 пользователь Dmitry V. Levin написал:
> > >> Зачем? Тут плюсов от git получить не получится. Я понимаю что git.alt
> > >> рулит, но только для части пакетов. Ядро пилить без git это просто
> > >> изврат. Дерево моего ice-wks у меня на винте лежит, но вот публиковать
> > >> его мне просто не получается. Слишком много трафика это для моего
> > >> тарифа у провайдера что у меня дома.
> > >
> > > Обычно пересылка srpm-пакетов создаёт больше трафика, чем git fetch и
> > > git pull, за исключением первичной закачки git-репозитория.
> >
> > Это понятно. Но src.rpm'ы проще. Когда я в первый раз увидел hasher я
> > был счастлив как ребёнок. Я тогда собирал свой дистрибутив и как раз
> > писал свой hasher. Это было похоже на mach, но только на C. А вот
> > сейчас эти движения с git мне катострафически не нравятся. git
> > уменьшает круг людей которые будут заниматся именно такой разработкой
>
> По-моему, есть два подхода к работе над rpm пакетами.
>
> 1) Условно "запаковка". Люди заворачивают апстримовские тарболлы в rpm
> пакеты с минимальными изменениями. Это занятие довольно экстенсивное,
> хотя временами и неизбежное. Как следствие, люди зачастую не смотрят в
> исходники, а например, увлекаются спорами, какая форма записи в спеке
> предпочтительнее: autoreconf, %__autoreconf или %autoreconf, и т.д.
>
> 2) Разработка. Люди втягиваются и начинают хачить, или, по крайней
> мере, смотрят в исходники и начинают понимать, в чем там дело. В
> перспективе разработка может войти в интенсивную фазу. Для разработки
> тарболлы вредны -- если количество патчей растёт быстрее, чем их
> забирает апстрим, то для поддержки изменений лучше использовать не
> патчи, а полноценный SCM.
>
> Теперь представь, что хачить начитают два или три человека. Здесь git
> даёт все удобства для совместной разработки.
>
> Так что надо задать себе вопрос: кто я? Запаковщик тарболлов в rpm'ы
> или разработчик? Запаковка тарболлов не котруется. Ни с точки зрения
> индивидуального роста, ни с точки зрения выигрыша для ALT Linux Team.
Судя по пакетам - очень даже котируется, к сожалению. Более того: "котируется"
запаковка с левым, кривым, откуда-то утянутым спеком, с секциями %clean,
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot и другими
несуразностями :(
--
Led
1 августа 2008 г. 2:12 пользователь Led написал:
>> Так что надо задать себе вопрос: кто я? Запаковщик тарболлов в rpm'ы
>> или разработчик? Запаковка тарболлов не котруется. Ни с точки зрения
>> индивидуального роста, ни с точки зрения выигрыша для ALT Linux Team.
>
> Судя по пакетам - очень даже котируется, к сожалению. Более того: "котируется"
> запаковка с левым, кривым, откуда-то утянутым спеком, с секциями %clean,
> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot и другими
> несуразностями :(
Мне опубликовать статистику пакетов в которых прописаны теги
Distribution: и Vendor: которые вообще-то уже определены в нашем rpm?
--
icesik
1 августа 2008 г. 1:53 пользователь Alexey Tourbin написал:
>> Это понятно. Но src.rpm'ы проще. Когда я в первый раз увидел hasher я
>> был счастлив как ребёнок. Я тогда собирал свой дистрибутив и как раз
>> писал свой hasher. Это было похоже на mach, но только на C. А вот
>> сейчас эти движения с git мне катострафически не нравятся. git
>> уменьшает круг людей которые будут заниматся именно такой разработкой
>
> По-моему, есть два подхода к работе над rpm пакетами.
>
> 1) Условно "запаковка". Люди заворачивают апстримовские тарболлы в rpm
> пакеты с минимальными изменениями. Это занятие довольно экстенсивное,
> хотя временами и неизбежное. Как следствие, люди зачастую не смотрят в
> исходники, а например, увлекаются спорами, какая форма записи в спеке
> предпочтительнее: autoreconf, %__autoreconf или %autoreconf, и т.д.
>
> 2) Разработка. Люди втягиваются и начинают хачить, или, по крайней
> мере, смотрят в исходники и начинают понимать, в чем там дело. В
> перспективе разработка может войти в интенсивную фазу. Для разработки
> тарболлы вредны -- если количество патчей растёт быстрее, чем их
> забирает апстрим, то для поддержки изменений лучше использовать не
> патчи, а полноценный SCM.
>
> Теперь представь, что хачить начитают два или три человека. Здесь git
> даёт все удобства для совместной разработки.
>
> Так что надо задать себе вопрос: кто я? Запаковщик тарболлов в rpm'ы
> или разработчик? Запаковка тарболлов не котруется. Ни с точки зрения
> индивидуального роста, ни с точки зрения выигрыша для ALT Linux Team.
Вот это уже интересный ответ. Конечно же у нас не один подход к тому
что лежит в Сизифе (скорее даже, к тому что положить в Сизиф и как).
Спорить об этом бесполезно. Будем считать что это догмат. У меня есть
пара пакетов у которых либо мёртвый апстрим либо полуживой и не
принимающий мои патчи. Я думаю что тут не стоит показывать не чужие
пакета, так что я начну со своих. catpkt, o3read, pmount, nx, plib и
mdbtools. У catpkt умер апстрим. Патчи там слать уже некуда. o3read
апстрим делает вид что живой, но судя по дате посленнего релиза, патчи
им слать уже поздно. С plib тоже самое что и с o3read. С pmount
ситуация более веселее, апстрим живой, а вот на мои патчи в багзилла
не реагирует. NX просто проприетащики и патчи им отсылать просто
бесполезно. А в mdbtools просто мелкий патч для облегчения создания
sql кода который легко модно вставить в sql базу. Заводить для этого
по git репозиторию я не будаю что будет целесообразно. В остальных
пакетах у меня патчей практически нет. Зачем мне git?
--
icesik
[-- Attachment #1: Type: text/plain, Size: 677 bytes --] On Fri, Aug 01, 2008 at 02:12:38AM +0300, Led wrote: > > Так что надо задать себе вопрос: кто я? Запаковщик тарболлов в rpm'ы > > или разработчик? Запаковка тарболлов не котруется. Ни с точки зрения > > индивидуального роста, ни с точки зрения выигрыша для ALT Linux Team. > > Судя по пакетам - очень даже котируется, к сожалению. Более того: "котируется" > запаковка с левым, кривым, откуда-то утянутым спеком, с секциями %clean, > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot и другими > несуразностями :( Эти несуразности как раз не особенно страшны. Хуже, например, -- не сделать version script для новой версии системной библиотеки. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Friday, 01 August 2008 02:22:57 Alexey Tourbin написав: > On Fri, Aug 01, 2008 at 02:12:38AM +0300, Led wrote: > > > Так что надо задать себе вопрос: кто я? Запаковщик тарболлов в rpm'ы > > > или разработчик? Запаковка тарболлов не котруется. Ни с точки зрения > > > индивидуального роста, ни с точки зрения выигрыша для ALT Linux Team. > > > > Судя по пакетам - очень даже котируется, к сожалению. Более того: > > "котируется" запаковка с левым, кривым, откуда-то утянутым спеком, с > > секциями %clean, BuildRoot: > > %{_tmppath}/%{name}-%{version}-%{release}-buildroot и другими > > несуразностями :( > > Эти несуразности как раз не особенно страшны. 4.2 > Хуже, например, -- > не сделать version script для новой версии системной библиотеки. Эти "несуразности" задокументированы. В некоторых случаях они действительно не страшны, но они показывают отношение мейнтейнера к упаковке. А вот как "сделать version script для новой версии системной библиотеки" - документацию ещё поискать надо. Я, например, не нашёл, а перелопачивать архив рассылок за последние 10 лет - сорри, но на это времени как раз жалко. -- Led
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --] On Fri, Aug 01, 2008 at 02:15:44AM +0300, Igor Zubkov wrote: > > Так что надо задать себе вопрос: кто я? Запаковщик тарболлов в rpm'ы > > или разработчик? Запаковка тарболлов не котруется. Ни с точки зрения > > индивидуального роста, ни с точки зрения выигрыша для ALT Linux Team. > > Вот это уже интересный ответ. Конечно же у нас не один подход к тому > что лежит в Сизифе (скорее даже, к тому что положить в Сизиф и как). > Спорить об этом бесполезно. Будем считать что это догмат. У меня есть > пара пакетов у которых либо мёртвый апстрим либо полуживой и не > принимающий мои патчи. Я думаю что тут не стоит показывать не чужие > пакета, так что я начну со своих. catpkt, o3read, pmount, nx, plib и > mdbtools. У catpkt умер апстрим. Патчи там слать уже некуда. o3read > апстрим делает вид что живой, но судя по дате посленнего релиза, патчи > им слать уже поздно. С plib тоже самое что и с o3read. С pmount > ситуация более веселее, апстрим живой, а вот на мои патчи в багзилла > не реагирует. NX просто проприетащики и патчи им отсылать просто > бесполезно. А в mdbtools просто мелкий патч для облегчения создания > sql кода который легко модно вставить в sql базу. Заводить для этого > по git репозиторию я не будаю что будет целесообразно. В остальных > пакетах у меня патчей практически нет. Зачем мне git? А раз так, то и не обязательно знать человеческий язык. Это какая-то бравада невежеством. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1111 bytes --] On Fri, Aug 01, 2008 at 01:54:29AM +0300, Igor Zubkov wrote: IZ> У меня есть не один удалёный шелл с жирными каналами. А если не IZ> хватит, ещё добавят. Проблема в том что у меня дома нет анлимного IZ> канала. Заниматся Сизифом на работе просто некогда. А вот дома, в IZ> таком случае, не позволяют тех. возможности. В примере с ядром, достаточно сделать git clone ядра у кого-нибудь к себе на git.alt, а уже потом туда push'ить свою работу. Которая наверняка базировалась на чьем-то уже имеющемся, или хотя бы на git-репо линуса. Уйдут только diff'ы, трафика сэкономится море. >> Не вижу в этом никакой сложности. При желании можно перевести. IZ> Вот только ещё никто не перевёл. Моего Elementary для восприятия этой IZ> документации на английском явно не достаточно. Думаю ты не пробовал. Посмотри everyday git. Вся документация на git нужна только Великим Хакерам. Я пользуюсь несколькими процентами возможностей git, и мне их -- вполне достаточно. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
1 августа 2008 г. 5:54 пользователь Igor Zubkov <igor.zubkov / gmail.com> написал: [...] >>> Так это ещё надо читать документацию на git. А >>> она не такая простая и не такая уж и маленькая. >> >> Достаточно простая и вполне обозримая. >> >>> Да ещё и на английском. >> >> Не вижу в этом никакой сложности. При желании можно перевести. > > Вот только ещё никто не перевёл. Моего Elementary для восприятия этой > документации на английском явно не достаточно. http://freesource.info/wiki/RuslanHihin/GitUserManual http://freesource.info/wiki/RuslanHihin/20povsedevnyxkomandgit -- + Slava Semushin | slava.semushin @ gmail.com + ALT Linux Team | php-coder @ altlinux.ru
[-- Attachment #1: Type: text/plain, Size: 401 bytes --] On Fri, Aug 01, 2008 at 02:15:02AM +0300, Igor Zubkov wrote: > Мне опубликовать статистику пакетов в которых прописаны теги > Distribution: и Vendor: которые вообще-то уже определены в нашем rpm? Опубликуй. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): > Не знаю майнтейнера e2fsprogs. Знаю майнтейнера startup. Един в двух и более лицах. :) -- ldv in sisyphus@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
On Fri, Aug 01, 2008 at 02:32:50AM +0400, Dmitry V. Levin wrote: > > Это понятно. Но src.rpm'ы проще. Когда я в первый раз увидел > > hasher я был счастлив как ребёнок. [...] git уменьшает круг > > людей которые будут заниматся именно такой разработкой Мне всё-таки кажется, что нам с тобой src.rpm просто /привычны/. И осилить git в достаточной степени мы с тобой вполне можем. > Я думаю, что уже сейчас git более широко известен чем hasher, > и в дальнейшем распространённость git как инструмента будет > только расти. Ну это всё-таки сильно разные вещи. Сейчас gear явно менее широко известен, чем hasher. > > Так это ещё надо читать документацию на git. А > > она не такая простая и не такая уж и маленькая. > Достаточно простая и вполне обозримая. URL? (http://altlinux.org/Git -- свалка наспех) > > Иного, новички которые хотели бы что-то сделать уйдут > > сразу. Я не новичёк, но мне уже изрядно всё надоело. > Очевидно, это произошло по другой причине. Ага, мне вот тоже "изрядно всё надоело". Просто в отпуск пора -- и бук с собой не брать. :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
On Fri, Aug 01, 2008 at 02:15:44AM +0300, Igor Zubkov wrote: > Зачем мне git? Правишь спек, делаешь git diff. Удобно, однако. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #1: Type: text/plain, Size: 349 bytes --] Привет. Я собрал справочную информацию по git.alt в одном месте: http://www.altlinux.org/Git.alt Просьба при исправлении помнить, что это именно справочник: HOWTO и учебник будут отдельными документами. -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
14.08.08, Mikhail Gusarov<dottedmag@altlinux.org> написал(а): > Привет. > > Я собрал справочную информацию по git.alt в одном месте: > http://www.altlinux.org/Git.alt > > Просьба при исправлении помнить, что это именно справочник: HOWTO и > учебник будут отдельными документами. Михаил, спасибо! Вопрос для обсуждения. Мне представляется, что возможность как можно простого создания решений (дистрибутивов) на основе разных веток Сизифа, есть одна из наших важнейших целей. Если это так, если нет возражений, то HOWTO и учебник по этой теме, вкупе с профилями для разных решений, представленных как фирмами, так и независимыми разработчиками, были бы весьма важны. В идеале, конечно, хорошо бы и модуль ALTerator, но это не в ближнем TODO. Некоторые материалы есть, но хорошо бы больше, лучше и доступнее. Rgrds, Алексей > > > -- > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel > >
On Thu, Aug 14, 2008 at 01:54:35PM +0400, Aleksey Novodvorsky wrote: > > Я собрал справочную информацию по git.alt в одном месте: > > http://www.altlinux.org/Git.alt > Михаил, спасибо! +1 > Вопрос для обсуждения. Мне представляется, что возможность как > можно простого создания решений (дистрибутивов) на основе > разных веток Сизифа, есть одна из наших важнейших целей. Ну... хорошая цель. Ещё ей можно помочь быстроразворачиваемым сервером разработческой инфраструктуры и success stories интеграции своих разработок в дистрибутивы на базе ALT Linux. > то HOWTO и учебник по этой теме, вкупе с профилями для разных > решений, представленных как фирмами, так и независимыми > разработчиками, были бы весьма важны. Причём некоторые материалы стоит делать попросту пошаговыми и так же их и проверять. В своё время так делал http://fly.osdn.org.ua/~mike/docs/livecd/sandman_mini-howto.html -- но на год примерно запоздало. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #1: Type: text/plain, Size: 1964 bytes --] Что-то сломалось на git.alt. $ ssh git.alt ssh: PTY allocation request failed on channel 0 -girar-sh: Invalid number of arguments Available commands: help git-receive-pack <directory> git-upload-pack <directory> charset <path to git repository> [<charset>] clone <path to git repository> [<path to directory>] find-package <pattern> init-db <path to directory> ls [<path to directory>] mv-db <path to source directory> <path to destination directory> quota rm-db <path to git repository> task {list|new|show|drop|add|run} ... build <path to gear repository> <tag name> [<binary package repository name>] [<project name>] acl {--help|<binary package repository name> ...} Connection to git.altlinux.org closed. -- Regards, Kirill A. Shutemov + Belarus, Minsk + ALT Linux Team, http://www.altlinux.org/ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 250 bytes --] On Thu, Dec 11, 2008 at 03:41:39PM +0200, Kirill A. Shutemov wrote: > Что-то сломалось на git.alt. > > $ ssh git.alt > ssh: PTY allocation request failed on channel 0 Я выключил pty allocation. Используйте $ ssh git.alt help -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 326 bytes --] Twas brillig at 17:16:40 11.12.2008 UTC+03 when ldv@altlinux.org did gyre and gimble: DVL> Я выключил pty allocation. Используйте $ ssh git.alt help Предлагаю это так и написать, вместо вываливания сломанного usage. Патч в аттаче. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Fixed-girar-sh-output-with-PTY-allocation-disabled.patch --] [-- Type: text/x-diff, Size: 669 bytes --] >From 504997c7bea2324678856a586737fecfb3f95090 Mon Sep 17 00:00:00 2001 From: Mikhail Gusarov <dottedmag@dottedmag.net> Date: Thu, 11 Dec 2008 20:24:35 +0600 Subject: [PATCH] Fixed girar-sh output with PTY allocation disabled. --- bin/girar-sh.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/bin/girar-sh.c b/bin/girar-sh.c index 211c70e..d73fa9b 100644 --- a/bin/girar-sh.c +++ b/bin/girar-sh.c @@ -194,6 +194,6 @@ main (int ac, char *av[]) shell(av); } - error(0, 0, "Invalid number of arguments"); - show_help(EXIT_FAILURE); + error(0, 0, "Not enough arguments. Try the 'help' command."); + exit(EXIT_FAILURE); } -- 1.6.0.3 [-- Attachment #3: Type: text/plain, Size: 6 bytes --] --
Здравствуйте, хочу поставить важный, как мне кажется, вопрос о сборке модулей ядра в git.alt. Есть ли идеи, соображения и, возможно, наработки по переезду на сборку модулей ядра из git? Текущий workflow (http://www.altlinux.org/Сборка_модулей_ядра) как не укладывается, для модулей, в новую схему (aka git.alt build). Или я что-то пропустил? -- Sin (Sinelnikov Evgeny)
[-- Attachment #1: Type: text/plain, Size: 542 bytes --] Hi, On Wed, Feb 11, 2009 at 01:42:52AM +0300, Evgeny Sinelnikov wrote: > хочу поставить важный, как мне кажется, вопрос о сборке модулей ядра в > git.alt. Есть ли идеи, соображения и, возможно, наработки по переезду > на сборку модулей ядра из git? Текущий workflow > (http://www.altlinux.org/Сборка_модулей_ядра) как не укладывается, для > модулей, в новую схему (aka git.alt build). Или я что-то пропустил? Укладывается, мы об этом думали заранее. Я надеюсь, что наши ядерщики найдут свободную минутку и напишут. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Dmitry V. Levin wrote:
> Hi,
>
> On Wed, Feb 11, 2009 at 01:42:52AM +0300, Evgeny Sinelnikov wrote:
>> хочу поставить важный, как мне кажется, вопрос о сборке модулей ядра в
>> git.alt. Есть ли идеи, соображения и, возможно, наработки по переезду
>> на сборку модулей ядра из git? Текущий workflow
>> (http://www.altlinux.org/Сборка_модулей_ядра) как не укладывается, для
>> модулей, в новую схему (aka git.alt build). Или я что-то пропустил?
>
> Укладывается, мы об этом думали заранее.
> Я надеюсь, что наши ядерщики найдут свободную минутку и напишут.
В приципе я даже представляю как это должно выгладить, может быть
сегодня прямо напишу.
Здравствуйте! $ ssh git.alt task new 5.0 new task #1095: owner=enp repo=5.0 1095 $ ssh git.alt task add 1095 copy libspandsp6 girar-check-perms: access to libspandsp6 DENIED for enp: does not belong to approved builders list: mithraen Помнится, через incoming это было возможно. Подозреваю, что через git.alt я и собрать в libspandsp6 в 5.0, 4.1 и 4.0 не смогу. Если это так, то просьба к mithraen@ сделать это самому либо дать мне соответствующие ACL. -- С уважением, Прокопьев Евгений
Здравствуйте,
11 февраля 2009 г. 8:21 пользователь Michail Yakushin
<silicium@altlinux.ru> написал:
> Dmitry V. Levin wrote:
>> On Wed, Feb 11, 2009 at 01:42:52AM +0300, Evgeny Sinelnikov wrote:
>>> хочу поставить важный, как мне кажется, вопрос о сборке модулей ядра в
>>> git.alt. Есть ли идеи, соображения и, возможно, наработки по переезду
>>> на сборку модулей ядра из git? Текущий workflow
>>> (http://www.altlinux.org/Сборка_модулей_ядра) как не укладывается, для
>>> модулей, в новую схему (aka git.alt build). Или я что-то пропустил?
>>
>> Укладывается, мы об этом думали заранее.
>> Я надеюсь, что наши ядерщики найдут свободную минутку и напишут.
> В приципе я даже представляю как это должно выгладить, может быть
> сегодня прямо напишу.
Я вот думаю, мне модули для virtualbox удастся собрать через git.alt
или ручками пересобрать с помощью ./buildmodules и бросить в инкаминг?
Если я правильно понимаю, то поддержка сборки модулей из шаблонов
должна быть реализована где-то в недрах girar. Или всё не так и уже
даже придумано по-другому, но не раскрыто?
--
Sin (Sinelnikov Evgeny)
Evgeny Sinelnikov wrote: > > Я вот думаю, мне модули для virtualbox удастся собрать через git.alt > или ручками пересобрать с помощью ./buildmodules и бросить в инкаминг? > > Если я правильно понимаю, то поддержка сборки модулей из шаблонов > должна быть реализована где-то в недрах girar. Или всё не так и уже > даже придумано по-другому, но не раскрыто? > Придумано по другому. Вобщем идея простая. Есть скрипт который берет темплейты и обновляет с их помощью бранчи, по бранчу на сборку модуля под каждое ядро. Набросок этого скрипта вот http://git.altlinux.org/people/silicium/public/?p=kernel-scripts.git;a=blob;f=mod-spec-update;h=e3a280e9805cc934e6bb4f97ca59fe0954f2b673;hb=652548066ae1de9f25c0c29cb66de41a9b72ac2e Можете попробовать воспользоваться им. Он требует чтобы modules лежали в директории с kernel-image, тогда он сам определяет версию ядра и subflavours в данном случае его надо запускать mod-spec-update -n virtualbox -n virtualbox-vfs -n virtualbox-addition и обязательно перед этим kernel-modules утащить у меня, потому что там уже есть такие бранчи, и видимо обновление надо делать на основе тех. Кстати скоро будет обновления ядра, если не получиться я по вашему темплейту сам обновлю.
[-- Attachment #1: Type: text/plain, Size: 924 bytes --] On Wed, Feb 25, 2009 at 02:30:54PM +0300, Michail Yakushin wrote: > Evgeny Sinelnikov wrote: > > > > Я вот думаю, мне модули для virtualbox удастся собрать через git.alt > > или ручками пересобрать с помощью ./buildmodules и бросить в инкаминг? > > > > Если я правильно понимаю, то поддержка сборки модулей из шаблонов > > должна быть реализована где-то в недрах girar. Или всё не так и уже > > даже придумано по-другому, но не раскрыто? > > > > Придумано по другому. Вобщем идея простая. Есть скрипт который берет > темплейты и обновляет с их помощью бранчи, по бранчу на сборку модуля > под каждое ядро. > Набросок этого скрипта вот > http://git.altlinux.org/people/silicium/public/?p=kernel-scripts.git;a=blob;f=mod-spec-update;h=e3a280e9805cc934e6bb4f97ca59fe0954f2b673;hb=652548066ae1de9f25c0c29cb66de41a9b72ac2e А чем он отличается от уже имеющегося buildmodules --commit --tag --no-build ? [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Sergey Vlasov wrote:
> А чем он отличается от уже имеющегося
> buildmodules --commit --tag --no-build
> ?
Тем что берёт версию из спека kernel-image а не из rpm который был собран.
Честно говоря я не осилил полностью въехать в твой скрипт, поэтому
утащил наиболее нужную и понятную мне логику.
А вообще твоим можно сгенерировать теги не собирая ядро?
[-- Attachment #1: Type: text/plain, Size: 569 bytes --] On Wed, Feb 25, 2009 at 03:03:25PM +0300, Michail Yakushin wrote: > Sergey Vlasov wrote: > > А чем он отличается от уже имеющегося > > buildmodules --commit --tag --no-build > > ? > > Тем что берёт версию из спека kernel-image а не из rpm который был собран. > Честно говоря я не осилил полностью въехать в твой скрипт, поэтому > утащил наиболее нужную и понятную мне логику. > > А вообще твоим можно сгенерировать теги не собирая ядро? Можно указать -k FLAVOUR=VERSION-RELEASE, тогда пакет с ядром не ищется, а просто используется указанная версия. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 548 bytes --] On Wed, Feb 25, 2009 at 03:03:25PM +0300, Michail Yakushin wrote: > Sergey Vlasov wrote: > > А чем он отличается от уже имеющегося > > buildmodules --commit --tag --no-build > > ? > > Тем что берёт версию из спека kernel-image а не из rpm который был собран. И это правильно. На то и шаблон, чтобы готовить из него спек. > Честно говоря я не осилил полностью въехать в твой скрипт, поэтому > утащил наиболее нужную и понятную мне логику. Жаль. > А вообще твоим можно сгенерировать теги не собирая ядро? Да. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Как лучше вести пакет двумя людьми? К примеру, я веду пакет foo и на git.alt он выложен в /people/serpiph/packages/foo.git. Я даю разрешение ещё одному человеку на заброску пакета на сборку в Сизиф через acl. Как тот человек должен будет производить обновление и отсылку в incoming? Путём заливания изменений в мой вариант на git.alt, подписыванием тега и заданием на сборку в incoming или ему потребуется скопировать foo.git в свой список пакетов и уже оттуда всё делать? -- С уважением, Епифанов Сергей
[-- Attachment #1: Type: text/plain, Size: 342 bytes --] Twas brillig at 13:18:19 27.02.2009 UTC+03 when serpiph@nikiet.ru did gyre and gimble: ES> потребуется скопировать foo.git в свой список пакетов и уже оттуда ES> всё делать? Да. И почитай что-нибудь про git. Git User's Guide, что ли? -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
27 февраля 2009 г. 13:20 пользователь Mikhail Gusarov <dottedmag@altlinux.org> написал: > > Twas brillig at 13:18:19 27.02.2009 UTC+03 when serpiph@nikiet.ru did gyre and gimble: > > ES> потребуется скопировать foo.git в свой список пакетов и уже оттуда > ES> всё делать? > Лучше не копировать, а склонировать их на сервере ssh git.alt clone /people/serpiph/packages/foo.git > Да. > > И почитай что-нибудь про git. Git User's Guide, что ли? > Есть даже перевод, но я не знаю насколько он актуален: http://freesource.info/wiki/RuslanHihin/GitUserManual -- Sin (Sinelnikov Evgeny)
On Fri, Feb 27, 2009 at 01:18:19PM +0300, Epiphanov Sergei wrote: > Как лучше вести пакет двумя людьми? К примеру, я веду пакет foo и на git.alt > он выложен в /people/serpiph/packages/foo.git. Я даю разрешение ещё одному > человеку на заброску пакета на сборку в Сизиф через acl. Как тот человек > должен будет производить обновление и отсылку в incoming? У него будет такой же foo.git в его каталоге. > Путём заливания изменений в мой вариант на git.alt, > подписыванием тега и заданием на сборку в incoming Мне интересные коммиты приходят по почте. Касающиеся моих пакетов я могу смержить в свой git и дать задание на сборку. > или ему потребуется скопировать foo.git в свой список пакетов и > уже оттуда всё делать? Да, если ему разрешено выкладывать пакет foo, так будет даже удобнее.
On Friday 27 February 2009 13:31:58 Evgeny Sinelnikov wrote:
> 27 февраля 2009 г. 13:20 пользователь Mikhail Gusarov
>
> <dottedmag@altlinux.org> написал:
> > Twas brillig at 13:18:19 27.02.2009 UTC+03 when serpiph@nikiet.ru did
> > gyre and gimble:
> >
> > ES> потребуется скопировать foo.git в свой список пакетов и уже оттуда
> > ES> всё делать?
>
> Лучше не копировать, а склонировать их на сервере
> ssh git.alt clone /people/serpiph/packages/foo.git
>
> > Да.
> >
> > И почитай что-нибудь про git. Git User's Guide, что ли?
>
> Есть даже перевод, но я не знаю насколько он актуален:
> http://freesource.info/wiki/RuslanHihin/GitUserManual
Спасибо, погляжу!
--
С уважением, Епифанов Сергей
[-- Attachment #1: Type: text/plain, Size: 545 bytes --] Twas brillig at 13:31:58 27.02.2009 UTC+03 when sin@altlinux.ru did gyre and gimble: ES> Есть даже перевод, но я не знаю насколько он актуален: ES> http://freesource.info/wiki/RuslanHihin/GitUserManual Только первые три главы. Кроме того, на первой же странице ляп "Git is a fast distributed revision control system." -> "Git это быстро переносимая система управления версиями." -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
On Friday 27 February 2009 14:31:01 Grigory Batalov wrote:
> > или ему потребуется скопировать foo.git в свой список пакетов и
> > уже оттуда всё делать?
>
> Да, если ему разрешено выкладывать пакет foo, так будет даже удобнее.
А не будет ли рваться канва? git.alt нормально пропустит это всё через себя?
Я к тому, что вот я сделал очерезной коммит. Тогда коллеге надо будет забрать
из моего foo.git текущее состояние, смержить у себя, внести свои изменения,
отправить в свой foo.git и отправить полученное на сборку. Так?
--
С уважением, Епифанов Сергей
[-- Attachment #1: Type: text/plain, Size: 814 bytes --] Twas brillig at 16:03:14 27.02.2009 UTC+03 when serpiph@nikiet.ru did gyre and gimble: ES> А не будет ли рваться канва? git.alt нормально пропустит это всё ES> через себя? Если канва (наследование по коммитам) не будет рваться - пропустит. ES> Я к тому, что вот я сделал очерезной коммит. Тогда коллеге надо ES> будет забрать из моего foo.git текущее состояние, смержить у себя, ES> внести свои изменения, отправить в свой foo.git и отправить ES> полученное на сборку. Да. И в обратную сторону. -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
[-- Attachment #1: Type: text/plain, Size: 341 bytes --] Здравствуйте Mikhail Gusarov В сообщении от 27 февраля 2009 Mikhail Gusarov написал(a): > Кроме того, на первой же странице ляп > > "Git is a fast distributed revision control system." > -> > "Git это быстро переносимая система управления версиями." Да я в школе немецкий изучал - ляп, - поправьте :) -- С уважением Хихин Руслан [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --]
hi all Господа, а что предполагается делать с отработавшими заданиями на git.alt (теми, что DONE)? а то листинг task ls уже длинноват. - делать на них самому rm? - будут самоуничтожаться со временем? -- Артём Золочевский
[-- Attachment #1: Type: text/plain, Size: 346 bytes --] On Thu, Mar 05, 2009 at 01:30:57PM +0200, Artem Zolochevskiy wrote: > hi all > > Господа, а что предполагается делать с отработавшими заданиями на > git.alt (теми, что DONE)? а то листинг task ls уже длинноват. > > - делать на них самому rm? > - будут самоуничтожаться со временем? Будут самоуничтожаться со временем. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
On Sun, Feb 17, 2008 at 09:35:47PM +0300, Dmitry V. Levin wrote: > On Sun, Feb 17, 2008 at 09:14:39PM +0300, Sergey Vlasov wrote: > > On Sun, Feb 17, 2008 at 08:55:22PM +0300, Dmitry V. Levin wrote: > > > Для того, чтобы помочь, чтобы сделать pull/commit/pull, > > > не обязательно разбираться в технике ведения репозитория. > > > > Но при этом нужно знать, куда и как именно в данном репозитории > > принято делать commit - где-то до сих пор нужно добавлять файлы с > > патчами, где-то принято коммитить прямо в master, где-то есть куча > > бранчей, и нужно понять, коммитить эти изменения в какой-то > > существующий, или заводить новый. > > Это же видно сразу. Или нет? Если нет, то давайте опишем, как > определить по внешнему виду репозитория, какой стиль там принят. А ведь хорошая была мысль, но заглохла. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
On Saturday, 30 May 2009 19:36:19 Michael Shigorin wrote:
> On Sun, Feb 17, 2008 at 09:35:47PM +0300, Dmitry V. Levin wrote:
> > On Sun, Feb 17, 2008 at 09:14:39PM +0300, Sergey Vlasov wrote:
> > > On Sun, Feb 17, 2008 at 08:55:22PM +0300, Dmitry V. Levin wrote:
> > > > Для того, чтобы помочь, чтобы сделать pull/commit/pull,
> > > > не обязательно разбираться в технике ведения репозитория.
> > >
> > > Но при этом нужно знать, куда и как именно в данном репозитории
> > > принято делать commit - где-то до сих пор нужно добавлять файлы с
> > > патчами, где-то принято коммитить прямо в master, где-то есть куча
> > > бранчей, и нужно понять, коммитить эти изменения в какой-то
> > > существующий, или заводить новый.
> >
> > Это же видно сразу. Или нет? Если нет, то давайте опишем, как
> > определить по внешнему виду репозитория, какой стиль там принят.
>
> А ведь хорошая была мысль, но заглохла.
Я могу в несколько строк описать, как организованы мои репозитарии (тем более,
что пакеты, которые я поддрживал, сейчас почти все бесхозные), если кого-то
интересует.
--
Led
Led пишет:
> On Saturday, 30 May 2009 19:36:19 Michael Shigorin wrote:
>> On Sun, Feb 17, 2008 at 09:35:47PM +0300, Dmitry V. Levin wrote:
>>> On Sun, Feb 17, 2008 at 09:14:39PM +0300, Sergey Vlasov wrote:
>>>> On Sun, Feb 17, 2008 at 08:55:22PM +0300, Dmitry V. Levin wrote:
>>>>> Для того, чтобы помочь, чтобы сделать pull/commit/pull,
>>>>> не обязательно разбираться в технике ведения репозитория.
>>>> Но при этом нужно знать, куда и как именно в данном репозитории
>>>> принято делать commit - где-то до сих пор нужно добавлять файлы с
>>>> патчами, где-то принято коммитить прямо в master, где-то есть куча
>>>> бранчей, и нужно понять, коммитить эти изменения в какой-то
>>>> существующий, или заводить новый.
>>> Это же видно сразу. Или нет? Если нет, то давайте опишем, как
>>> определить по внешнему виду репозитория, какой стиль там принят.
>> А ведь хорошая была мысль, но заглохла.
>
> Я могу в несколько строк описать, как организованы мои репозитарии (тем более,
> что пакеты, которые я поддрживал, сейчас почти все бесхозные), если кого-то
> интересует.
Конечно описывай.
Но вообще, эти несколько строк всегда содержатся в .gear/rules для
тегов, из которых пакет был собран.
Правда, в случае с subversion - в git'е не хватает некой важной
информации, что бы не тянуть git-svn с нуля.
Представьте себе эту операцию, например, для KDE... даже на быстром
канале она занимает много гигабайт трафика кучу времени.
[-- Attachment #1: Type: text/plain, Size: 444 bytes --] Anton Farygin пишет: ... > > Правда, в случае с subversion - в git'е не хватает некой важной > информации, что бы не тянуть git-svn с нуля. > > Представьте себе эту операцию, например, для KDE... даже на быстром > канале она занимает много гигабайт трафика кучу времени. И не все репозитарии нормально такую нагрузку выдерживают. Некоторые, если их перегрузить -- блокируют ip качающего. -- С уважением. Алексей. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 552 bytes --]
On Sat, May 30, 2009 at 08:05:30PM +0300, Led wrote:
> Я могу в несколько строк описать, как организованы мои репозитарии (тем более,
> что пакеты, которые я поддрживал, сейчас почти все бесхозные), если кого-то
> интересует.
Разумеется!
--
George V. Kouryachy (aka Fr. Br. George)
mailto:george at altlinux_org
[-- Attachment #1: Type: text/plain, Size: 354 bytes --] George V. Kouryachy пишет: > On Sat, May 30, 2009 at 08:05:30PM +0300, Led wrote: >> Я могу в несколько строк описать, как организованы мои репозитарии (тем более, >> что пакеты, которые я поддрживал, сейчас почти все бесхозные), если кого-то >> интересует. > Разумеется! В каком месте сайта это делать? -- С уважением. Алексей. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 552 bytes --]
[-- Attachment #1: Type: text/plain, Size: 628 bytes --] On Mon, Jun 01, 2009 at 09:21:14PM +0400, George V. Kouryachy wrote: > On Sat, May 30, 2009 at 08:05:30PM +0300, Led wrote: > > Я могу в несколько строк описать, как организованы мои репозитарии (тем более, > > что пакеты, которые я поддрживал, сейчас почти все бесхозные), если кого-то > > интересует. > Разумеется! Детальное описание может пригодится мне (или ещё кому-нибудь) для того, чтобы наполнить testsuite для gear. Типовые репозитории, о которых идёт речь в gear-rules(5), описывать детально не нужно, достаточно сослаться на пример в http://docs.altlinux.org/manpages/gear-rules.5.html -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Умер? -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
REAL пишет:
> Умер?
Вроде уже попустило.
[-- Attachment #1: Type: text/plain, Size: 952 bytes --] On Fri, Dec 18, 2009 at 04:56:54PM +0700, REAL wrote: > Умер? ----- Forwarded message from support@hoster.ru ----- Date: Fri, 18 Dec 2009 19:03:07 +0300 From: support@hoster.ru Subject: Технический сбой с 18.12.2009 года, с 11-50 до 13-08 Здравствуйте. Сегодня, 18.12.2009 года, с 11-50 до 13-08 по московскому времени, произошел перебой предоставления услуг ООО "Филанко", связанный с аппаратными проблемами на магистральном корневом маршрутизаторе. Запрос о причинах возникшего сбоя отправлен производителю оборудования. Приносим свои извинения за те неудобства, которые вам доставила эта проблема. Несмотря ни на что, поздравляем всех с Наступающим Новым Годом! Будем рады услышать Ваши пожелания и предложения. -- С уважением, Павел Карпенко Техническая поддержка Группа компаний Филанко (Hoster.ru, Domenus.ru, Datahouse.ru, Citytelecom.ru) www.filanco.ru ----- End forwarded message ----- -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
Подскажите. В чем может быть проблема? $ ssh git.alt task new Enter passphrase for key '/home/lnkvisitor/.ssh/id_rsa': girar-task new: Permission denied Раньше не работал с git.alt.
23.12.2009 18:47, Dmitriy Kulik пишет:
> girar-task new: Permission denied
git.alt на ручном управлении в плане прав доступа. Ждем ldv@.
23.12.2009 19:47, Dmitriy Kulik пишет:
> Подскажите. В чем может быть проблема?
> $ ssh git.alt task new
> Enter passphrase for key '/home/lnkvisitor/.ssh/id_rsa':
> girar-task new: Permission denied
>
> Раньше не работал с git.alt.
ssh-add
[-- Attachment #1: Type: text/plain, Size: 549 bytes --] On Wed, Dec 23, 2009 at 10:29:01PM +0300, Anton Farygin wrote: > 23.12.2009 19:47, Dmitriy Kulik пишет: > > Подскажите. В чем может быть проблема? > > $ ssh git.alt task new > > Enter passphrase for key '/home/lnkvisitor/.ssh/id_rsa': > > girar-task new: Permission denied > > > > Раньше не работал с git.alt. > > ssh-add Какое отношение ssh-add имеет к добавлению пользователя в группу girar-builder на хосте git.alt? :) -- <gns> во франции праздник, мы тут сидим и стараемся ничего не сломать <gns> лучший способ - читать лор [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
24.12.2009 01:02, Konstantin Pavlov пишет:
> On Wed, Dec 23, 2009 at 10:29:01PM +0300, Anton Farygin wrote:
>> 23.12.2009 19:47, Dmitriy Kulik пишет:
>>> Подскажите. В чем может быть проблема?
>>> $ ssh git.alt task new
>>> Enter passphrase for key '/home/lnkvisitor/.ssh/id_rsa':
>>> girar-task new: Permission denied
>>>
>>> Раньше не работал с git.alt.
>>
>> ssh-add
>
> Какое отношение ssh-add имеет к добавлению пользователя в группу
> girar-builder на хосте git.alt? :)
Никакого. Ошибочно отправил.
$ ssh git.alt init-db flvtool++ girar-init-db: packages/flvtool++: invalid directory name Товарищи, у нас совсем нельзя в названии пакета/репозитория плюсы использовать? -- Regards, Sergey Alembekov ALTLinux Team xmpp: rt@jabber.ru
При сборке freeradius обнаружил, что на git.alt устанавливается иной набор (и порядок) пакетов в сборочный чрут: -libltdl3-devel-3:1.5.26-alt9 +libltdl7-2.2.10-alt2 +libltdl7-devel-2.2.10-alt2 Т.е. выбирается libltdl7-devel вместо libltdl3-devel, но при этом libltdl3 всё же также устанавливается. В спеке указано BuildRequires: libltdl-devel (без версии), также указано BuildPreReq: libtool_1.5 (что подразумевает использование libltdl3) Наличие libltdl7-devel вместо libltdl3-devel и использование libtool_1.5 порождает ошибку: modules.c:(.text+0x17be): undefined reference to `lt__PROGRAM__LTX_preloaded_symbols' Разработчики freeradius нарисовали костыль в своём коде для разрешения подобной ситуации https://github.com/alandekok/freeradius-server/blob/38f8025f2d413aa68de3277156edc6b4051f3385/src/main/modules.c#L1345 Интересует почему может устанавливаться иной набор пакетов (моя сборочная система - текущий сизиф) при сборке в git.alt? Сейчас в сборке я воспользовался хаком DIE_LIBTOOL_DIE в freeradius и freeradius-libs слинковался с libltdl.so.7. -- Vladimir Lettiev aka crux ✉ theCrux@gmail.com
[-- Attachment #1: Type: text/plain, Size: 679 bytes --] On Sat, Nov 27, 2010 at 09:18:42PM +0300, Vladimir Lettiev wrote: > При сборке freeradius обнаружил, что на git.alt устанавливается > иной набор (и порядок) пакетов в сборочный чрут: > > -libltdl3-devel-3:1.5.26-alt9 > +libltdl7-2.2.10-alt2 > +libltdl7-devel-2.2.10-alt2 > > Т.е. выбирается libltdl7-devel вместо libltdl3-devel, но при этом > libltdl3 всё же также устанавливается. > > В спеке указано BuildRequires: libltdl-devel (без версии), > также указано BuildPreReq: libtool_1.5 (что подразумевает использование > libltdl3) BuildPreReq: libtool_1.5 подразумевает установку libtool_1.5, однако на выбор libltdl-devel это никак не влияет. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
Приввет! > ping git.altlinux.org PING git.altlinux.org (194.107.17.12) 56(84) bytes of data. А дальше - вечная тишина ;) То же самое и с git remote update Самое смешное, что сайт git.altlinux.org работает :) -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
Привет! Оно опять в дауне? -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
[-- Attachment #1: Type: text/plain, Size: 125 bytes --] On Wed, Apr 13, 2011 at 05:31:06PM +0700, REAL wrote: > Привет! > > Оно опять в дауне? В каком смысле? -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
14.04.2011 01:10, Dmitry V. Levin пишет:
>> Оно опять в дауне?
>
> В каком смысле?
Некоторое время даже ssh git.alt task ls не работал.
--
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
Привет! Куда делся сабж? ssh: Could not resolve hostname git.altlinux.org: Name or service not known -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
On Tue, Jan 17, 2012 at 01:53:32PM +0600, REAL wrote: > Куда делся сабж? Моргает резолвингом? -- dig(1) > ssh: Could not resolve hostname git.altlinux.org: > Name or service not known git.altlinux.org has address 194.107.17.12 -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
Здравствуйте! Обновил, после долгого перерыва, сборки kdevelop & Co, однако, не могу залить их на git.alt: alex@rhyme alt/morozov/kdev-php $ git push git.alt --tags girar-sh: git-receive-pack '/people/morozov/packages/kdevelop-for-php.git': Invalid command girar-sh: Try `help' command for more information. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. alex@rhyme alt/morozov/kdev-php $ Раньше эта процедура, вроде бы, не вызывала затруднений. Подскажите, пожалуйста, что делать. С уважением, Алексей Морозов
На giter надо -- Простите за краткость, создано в K-9 Mail.
В письме от 13 ноября 2015 12:21:21 пользователь Alexey Morozov написал: > Здравствуйте! > > Обновил, после долгого перерыва, сборки kdevelop & Co, однако, не могу > залить их на git.alt: > > alex@rhyme alt/morozov/kdev-php $ git push git.alt --tags > girar-sh: git-receive-pack > '/people/morozov/packages/kdevelop-for-php.git': Invalid command > girar-sh: Try `help' command for more information. > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > alex@rhyme alt/morozov/kdev-php $ > > Раньше эта процедура, вроде бы, не вызывала затруднений. Подскажите, > пожалуйста, что делать. Теперь работы с созданием git-репозиториев идут не на git.altlinux.org, а на gitery.altlinux.org. Поэтому заливать надо соответственно на него. Т.е. создать в ~/.ssh/config: Host gitery.alt HostName gitery.altlinux.org Port 222 User git_user И соответсвенно git push gitery.alt --tags > > С уважением, > Алексей Морозов > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel
13.11.2015 12:35, Руслан Хихин пишет:
> На giter надо
Хм, означает ли это, что иначе как giter'ом на git.alt нынче больше
ничего не зальёшь (естественно, без неприемлемых трудозатрат)?
С уважением,
Алексей Морозов
On Fri, Nov 13, 2015 at 12:51:39PM +0600, Alexey Morozov wrote: > Хм, означает ли это, что иначе как giter'ом на git.alt нынче больше > ничего не зальёшь (естественно, без неприемлемых трудозатрат)? sed -i 's,git.alt:,gitery.alt:,' ~/git/*/.git/config -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
On Friday 13 November 2015 09:46:02 Nazarov Denis wrote: [...] > Теперь работы с созданием git-репозиториев идут не на git.altlinux.org, а на > gitery.altlinux.org. Поэтому заливать надо соответственно на него. Т.е. > создать в ~/.ssh/config: > > Host gitery.alt > HostName gitery.altlinux.org > Port 222 > User git_user > > И соответсвенно git push gitery.alt --tags Мне показалось более удобным переименовать сборочницу в build.alt , а в ~/.ssh/config Host git.alt HostName gitery.altlinux.org -- Regards, Sergey. ALT Linux, http://www.altlinux.ru/
Да, спасибо всем отозвавшимся. Как сделать технически - это уже вопрос
двадцать пятый, главное было узнать о существовании gitery.altlinux.org :)
13.11.2015 16:55, Sergey V Turchin пишет:
> On Friday 13 November 2015 09:46:02 Nazarov Denis wrote:
>
> [...]
>> Теперь работы с созданием git-репозиториев идут не на git.altlinux.org, а на
>> gitery.altlinux.org. Поэтому заливать надо соответственно на него. Т.е.
>> создать в ~/.ssh/config:
>>
>> Host gitery.alt
>> HostName gitery.altlinux.org
>> Port 222
>> User git_user
>>
>> И соответсвенно git push gitery.alt --tags
> Мне показалось более удобным переименовать сборочницу в build.alt , а в
> ~/.ssh/config
> Host git.alt
> HostName gitery.altlinux.org
>
On Fri, Nov 13, 2015 at 01:55:03PM +0300, Sergey V Turchin wrote: > Мне показалось более удобным переименовать сборочницу в build.alt Если бы ко времени разнесения спросили, я бы именно этот вариант (с build.altlinux.org) и предложил. Мало того, мне до сих пор кажется, что лучше исправить неудачный выбор имён, чем каждый раз спотыкаться и объяснять. -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
On Friday 13 November 2015 13:59:22 Michael Shigorin wrote: > On Fri, Nov 13, 2015 at 01:55:03PM +0300, Sergey V Turchin wrote: > > Мне показалось более удобным переименовать сборочницу в build.alt > > Если бы ко времени разнесения спросили, я бы именно этот > вариант (с build.altlinux.org) и предложил. Мало того, > мне до сих пор кажется, что лучше исправить неудачный > выбор имён, чем каждый раз спотыкаться и объяснять. На сколько я понимаю, от git.alt для возможности продолжения сборки по причине закончившегося места отделялась именно часть с репозиториями, которой и дали новое имя. -- Regards, Sergey. ALT Linux, http://www.altlinux.ru/
[-- Attachment #1: Type: text/plain, Size: 553 bytes --] Здравствуйте ! On Friday 13 November 2015 09:51:39 Alexey Morozov написал(а): > 13.11.2015 12:35, Руслан Хихин пишет: > > На giter надо > > Хм, означает ли это, что иначе как giter'ом на git.alt нынче больше > ничего не зальёшь (естественно, без неприемлемых трудозатрат)? > https://www.altlinux.org/Git.alt/Справочник "С 01.08.2015г Для работы с git репозиторием надо настроить доступ к двум серверам : gitery.altlinux.org (gitery) и git.altlinux.org (girar), поэтому дальнейшая часть статьи требует корректировки." -- C уважением, Хихин Руслан. [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --]
13.11.2015 09:21, Alexey Morozov пишет:
> Здравствуйте!
>
> Обновил, после долгого перерыва, сборки kdevelop & Co, однако, не могу
> залить их на git.alt:
Сегодня тоже решил пересобрать кое-какие свои пакеты.
Но я всегда rsync'ом заливал srpm.
rsync -va atari800-3.1.0-alt1.src.rpm gitery.alt:
ssh: Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.2]
Что можно с этим сделать?
[-- Attachment #1: Type: text/plain, Size: 651 bytes --] On Sun, Apr 17, 2016 at 04:28:57PM +0300, Evgen wrote: > 13.11.2015 09:21, Alexey Morozov пишет: > >Здравствуйте! > > > >Обновил, после долгого перерыва, сборки > >kdevelop & Co, однако, не могу > >залить их на git.alt: > > Сегодня тоже решил пересобрать кое-какие > свои пакеты. > Но я всегда rsync'ом заливал srpm. > > rsync -va atari800-3.1.0-alt1.src.rpm gitery.alt: > ssh: Permission denied (publickey). > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.2] > > Что можно с этим сделать? ~/.ssh/config поправить. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
Добрый день. При попытке запустить сборочное задание получаю ошибку "write error: Disk quota exceeded" Подскажите пожалуйста, к кому обращаться за увеличением квоты на git.alt? P.S. Прошу прощения, понял, что написал в рассылку sisyphus, поэтому пишу и сюда. Если не сложно, просьба отвечать в какой-то одной рассылке. -- Pavel Vainerman www.etersoft.ru
[-- Attachment #1: Type: text/plain, Size: 247 bytes --] On Mon, Aug 27, 2018 at 12:39:21PM +0300, Pavel Vainerman wrote: > Добрый день. > > При попытке запустить сборочное задание получаю ошибку > "write error: Disk quota exceeded" Как обычно в таких случаях, попробуйте ещё раз. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --]
28.08.2018 01:19, Dmitry V. Levin пишет:
> On Mon, Aug 27, 2018 at 12:39:21PM +0300, Pavel Vainerman wrote:
>> Добрый день.
>>
>> При попытке запустить сборочное задание получаю ошибку
>> "write error: Disk quota exceeded"
>
> Как обычно в таких случаях, попробуйте ещё раз.
Я конечно пробовал..
Но видимо когда"заклинание" произносит правильный "волшебник" всё
получается..
Спасибо. Заработало.
--
Pavel Vainerman
www.etersoft.ru
[-- Attachment #1: Type: text/plain, Size: 1596 bytes --] On Mon, Feb 18, 2019 at 05:17:53PM +0300, Andrey Savchenko wrote: > On Mon, 18 Feb 2019 16:40:00 +0300 Mikhail Efremov wrote: > > On Mon, 18 Feb 2019 16:30:27 +0300 Alexey V. Vissarionov wrote: > > > On 2019-02-18 15:11:21 +0300, Dmitry V. Levin wrote: > > > > > > > Самое актуальное описание встроено в > > > > ssh gyle.alt help > > > > ssh gyle.alt build --help > > > > ssh gyle.alt task --help > > > > ssh gyle.alt task <command> --help > > > > > > А можно для всего этого наконец-то сделать обращение по имени > > > build.alt(linux.org)? - по аналогии с git? > > > > Можно, делай. У меня это именно build.alt и называется. > > Или тебя научить использовать ~/.ssh/config? > > Как я понял, речь идёт про общедоступное DNS имя. > Согласен с тем, что нынешние gitery и gyle сбивают с толку и > приходится везде локально держать build.alt и git.alt Краткая историческая справка. Сперва был ресурс git.altlinux.org, на нём были следующие интерфейсы: ssh [1], git, http, rsync. Потом [2] гитовница со сборочницей разделились, образовались ресурсы gitery.altlinux.org и gyle.altlinux.org, на каждом из них есть следующие интерфейсы: ssh [1]. git.altlinux.org остался с интерфейсами http и rsync, раздающими ресурсы в том числе и с gitery.altlinux.org и gyle.altlinux.org. Для обратной совместимости на git.altlinux.org остался интерфейс ssh [1], который на самом деле является интерфейсом gyle.altlinux.org. [1] интерфейс ssh принимает на портах 222 и 443. [2] https://lists.altlinux.org/pipermail/devel/2015-August/199990.html -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2653 bytes --] On Wed, 20 Feb 2019 16:37:27 +0300 Dmitry V. Levin wrote: > On Mon, Feb 18, 2019 at 05:17:53PM +0300, Andrey Savchenko wrote: > > On Mon, 18 Feb 2019 16:40:00 +0300 Mikhail Efremov wrote: > > > On Mon, 18 Feb 2019 16:30:27 +0300 Alexey V. Vissarionov wrote: > > > > On 2019-02-18 15:11:21 +0300, Dmitry V. Levin wrote: > > > > > > > > > Самое актуальное описание встроено в > > > > > ssh gyle.alt help > > > > > ssh gyle.alt build --help > > > > > ssh gyle.alt task --help > > > > > ssh gyle.alt task <command> --help > > > > > > > > А можно для всего этого наконец-то сделать обращение по имени > > > > build.alt(linux.org)? - по аналогии с git? > > > > > > Можно, делай. У меня это именно build.alt и называется. > > > Или тебя научить использовать ~/.ssh/config? > > > > Как я понял, речь идёт про общедоступное DNS имя. > > Согласен с тем, что нынешние gitery и gyle сбивают с толку и > > приходится везде локально держать build.alt и git.alt > > Краткая историческая справка. > > Сперва был ресурс git.altlinux.org, > на нём были следующие интерфейсы: ssh [1], git, http, rsync. > > Потом [2] гитовница со сборочницей разделились, > образовались ресурсы gitery.altlinux.org и gyle.altlinux.org, > на каждом из них есть следующие интерфейсы: ssh [1]. > > git.altlinux.org остался с интерфейсами http и rsync, > раздающими ресурсы в том числе и с gitery.altlinux.org > и gyle.altlinux.org. > > Для обратной совместимости на git.altlinux.org остался интерфейс ssh [1], > который на самом деле является интерфейсом gyle.altlinux.org. Пришло время избавиться от исторических рудиментов и сделать для людей — особенно для новых участников сообщества — простые и понятные названия git и build. Я вспоминаю, как у меня самого взрывался мозг от этих gitery и gyle, когда я сам начинал работать в команде. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
20.02.2019 16:37, Dmitry V. Levin пишет:
> On Mon, Feb 18, 2019 at 05:17:53PM +0300, Andrey Savchenko wrote:
>> On Mon, 18 Feb 2019 16:40:00 +0300 Mikhail Efremov wrote:
>>> On Mon, 18 Feb 2019 16:30:27 +0300 Alexey V. Vissarionov wrote:
>>>> On 2019-02-18 15:11:21 +0300, Dmitry V. Levin wrote:
>>>>
>>>> > Самое актуальное описание встроено в
>>>> > ssh gyle.alt help
>>>> > ssh gyle.alt build --help
>>>> > ssh gyle.alt task --help
>>>> > ssh gyle.alt task <command> --help
>>>>
>>>> А можно для всего этого наконец-то сделать обращение по имени
>>>> build.alt(linux.org)? - по аналогии с git?
>>> Можно, делай. У меня это именно build.alt и называется.
>>> Или тебя научить использовать ~/.ssh/config?
>> Как я понял, речь идёт про общедоступное DNS имя.
>> Согласен с тем, что нынешние gitery и gyle сбивают с толку и
>> приходится везде локально держать build.alt и git.alt
> Краткая историческая справка.
>
> Сперва был ресурс git.altlinux.org,
> на нём были следующие интерфейсы: ssh [1], git, http, rsync.
>
> Потом [2] гитовница со сборочницей разделились,
> образовались ресурсы gitery.altlinux.org и gyle.altlinux.org,
> на каждом из них есть следующие интерфейсы: ssh [1].
>
> git.altlinux.org остался с интерфейсами http и rsync,
> раздающими ресурсы в том числе и с gitery.altlinux.org
> и gyle.altlinux.org.
>
> Для обратной совместимости на git.altlinux.org остался интерфейс ssh [1],
> который на самом деле является интерфейсом gyle.altlinux.org.
>
> [1] интерфейс ssh принимает на портах 222 и 443.
> [2] https://lists.altlinux.org/pipermail/devel/2015-August/199990.html
Ну вот, теперь всё понятно - осталось придумать этим интерфейсам
нормальные понятные имена и можно будет сделать алиасы.
git.altlinux.org напрашивается для gitery.altlinux.org, а
gyle.altlinux.org - build.altlinux.org
[-- Attachment #1: Type: text/plain, Size: 2063 bytes --] On 2019-02-20 16:37:27 +0300, Dmitry V. Levin wrote: >>>> А можно для всего этого наконец-то сделать обращение по имени >>>> build.alt(linux.org)? - по аналогии с git? >>> Можно, делай. У меня это именно build.alt и называется. >> Как я понял, речь идёт про общедоступное DNS имя. >> Согласен с тем, что нынешние gitery и gyle сбивают с толку и >> приходится везде локально держать build.alt и git.alt > Краткая историческая справка. > Сперва был ресурс git.altlinux.org, на нём были следующие > интерфейсы: ssh [1], git, http, rsync. > Потом [2] гитовница со сборочницей разделились, Это вполне закономерно. Более того, сборочных ферм может быть и более одной (с независимым управлением). > образовались ресурсы gitery.altlinux.org и gyle.altlinux.org, С позиции администрирования это было не самое мудрое решение. Что мешало назвать их repo и build? Или git и build? И самый главный вопрос: как объяснить стороннему человеку (клиенту), "что за дебильные имена gitery и gyle?" (прилагательное было заменено мной, в остальном цитата точная). > на каждом из них есть следующие интерфейсы: ssh [1]. > git.altlinux.org остался с интерфейсами http и rsync, > раздающими ресурсы в том числе и с gitery.altlinux.org > и gyle.altlinux.org. HTTP(S) можно держать где угодно - nginx настраивается за несколько минут. А бекендов (в том числе физических) может быть сколько угодно. > Для обратной совместимости на git.altlinux.org остался > интерфейс ssh [1], который на самом деле является > интерфейсом gyle.altlinux.org. > [1] интерфейс ssh принимает на портах 222 и 443. Второе - допустим, для обхода головожопых фраерволов. А 222 зачем? IP-адресов мало? > [2] https://lists.altlinux.org/pipermail/devel/2015-August/ > 199990.html "ssh-интерфейс к _сборочным_ командам остался на прежнем адресе _git_.altlinux.org." Феерично... -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --]
Доброе утро, коллеги! Необходимо склонировать к себе на git.alt LibreOffice для тестовой сборки, но не хватило лимитов. Огромная просьба увеличить мне дисковый лимит. $ ssh git.alt clone /srpms/L/LibreOffice.git ... Cloning into bare repository 'packages/LibreOffice.git'... error: copy-fd: write returned: Disk quota exceeded fatal: failed to copy file to 'packages/LibreOffice.git/objects/pack/pack-41fba974388a210ff12d01b1a85cfed32f25ce3f.pack': Disk quota exceeded fatal: the remote end hung up unexpectedly $ ssh git.alt quota ... Filesystem space quota limit grace files quota limit grace /dev/simfs 785M 977M 1465M 382 100k 150k P.S.: Коллеги!!! Поздравляю всех вас с наступившим Новым Годом и желаю найти под ёлочкой всё то, что вам не хватало в ушедшем году ;) -- С уважением, Евгений Кухтинов <neurofreak@altlinux.org>
Hi, On Sat, Jan 01, 2022 at 07:21:55AM +0000, Evgeniy Kukhtinov wrote: > Доброе утро, коллеги! > > Необходимо склонировать к себе на git.alt LibreOffice для тестовой сборки, но не хватило лимитов. Огромная просьба увеличить мне дисковый лимит. [...] > P.S.: Коллеги!!! Поздравляю всех вас с наступившим Новым Годом и желаю найти под ёлочкой всё то, что вам не хватало в ушедшем году ;) Сколько дискового лимита вы хотели найти под ёлочкой? :) -- ldv
1 января 2022 г. 14:27:30 UTC, "Dmitry V. Levin" <ldv@altlinux.org> пишет:
>Hi,
>
>On Sat, Jan 01, 2022 at 07:21:55AM +0000, Evgeniy Kukhtinov wrote:
>> Доброе утро, коллеги!
>>
>> Необходимо склонировать к себе на git.alt LibreOffice для тестовой сборки, но не хватило лимитов. Огромная просьба увеличить мне дисковый лимит.
>[...]
>> P.S.: Коллеги!!! Поздравляю всех вас с наступившим Новым Годом и желаю найти под ёлочкой всё то, что вам не хватало в ушедшем году ;)
>
>Сколько дискового лимита вы хотели найти под ёлочкой? :)
>
>
>--
>ldv
>_______________________________________________
>Devel mailing list
>Devel@lists.altlinux.org
>https://lists.altlinux.org/mailman/listinfo/devel
Раза в два побольше, по возможности, конечно.
Был бы благодарен :)
--
С уважением, Евгений Кухтинов
<neurofreak@altlinux.org>
Кто может, помогите пожалуйста. у меня ( pav@ ) на git.alt слишком маленькая quota: $ ssh git.alt quota Filesystem space quota limit grace files quota limit grace /dev/simfs 1594M 4096M 4608M 1159 98304 123k Не удается корректно скопировать пакет в 6,6G http://git.altlinux.org/gears/t/thunderbird.git Получаю сообщение о переполнении. Огромная просьба увеличить мне дисковый лимит до 16-20G. -- Pavel Vasenkov <pav@altlinux.org>
Что-то пошло не так?
Квота была увеличена,
$ ssh girar quota
Filesystem space quota limit grace
files quota limit grace
/dev/sdb 7655M 16384M 18432M
28951 65536 73728
а сейчас опять свернута.
$ ssh git.alt quota
Filesystem space quota limit grace files quota limit grace
/dev/simfs 3477M 4096M 4608M 1176 98304 123k
Заранее спасибо за помощь.
В Вт, 25/01/2022 в 13:47 +0300, Pavel Vasenkov пишет:
> Кто может, помогите пожалуйста.
>
> у меня ( pav@ ) на git.alt слишком маленькая quota:
>
>
> $ ssh git.alt quota
> Filesystem space quota limit grace files quota lim
> it
> grace
> /dev/simfs 1594M 4096M 4608M 1159 98304
> 123k
>
>
> Не удается корректно скопировать пакет в 6,6G
> http://git.altlinux.org/gears/t/thunderbird.git
>
> Получаю сообщение о переполнении.
>
>
>
> Огромная просьба увеличить мне дисковый лимит до 16-20G.
>
>
Pavel Vasenkov писал(а) 26.1.22 13:04: > Что-то пошло не так? > > Квота была увеличена, > > $ ssh girar quota > Filesystem space quota limit grace > files quota limit grace > /dev/sdb 7655M 16384M 18432M > 28951 65536 73728 > > а сейчас опять свернута. > > $ ssh git.alt quota Вы смотрели квоту то на girar, то на git.alt ? > Filesystem space quota limit grace files quota limit > grace > /dev/simfs 3477M 4096M 4608M 1176 98304 123k > > Заранее спасибо за помощь. > > > В Вт, 25/01/2022 в 13:47 +0300, Pavel Vasenkov пишет: >> Кто может, помогите пожалуйста. >> >> у меня ( pav@ ) на git.alt слишком маленькая quota: >> >> >> $ ssh git.alt quota >> Filesystem space quota limit grace files quota lim >> it >> grace >> /dev/simfs 1594M 4096M 4608M 1159 98304 >> 123k >> >> >> Не удается корректно скопировать пакет в 6,6G >> http://git.altlinux.org/gears/t/thunderbird.git >> >> Получаю сообщение о переполнении. >> >> >> >> Огромная просьба увеличить мне дисковый лимит до 16-20G. >> >> > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- С уважением, Виталий Липатов, ALT Linux Team
В Ср, 26/01/2022 в 18:47 +0300, Vitaly Lipatov пишет: > Pavel Vasenkov писал(а) 26.1.22 13:04: > > Что-то пошло не так? > > > > Квота была увеличена, > > > > $ ssh girar quota > > Filesystem space quota limit grace > > files quota limit grace > > /dev/sdb 7655M 16384M 18432M > > 28951 65536 73728 > > > > а сейчас опять свернута. > > > > $ ssh git.alt quota > Вы смотрели квоту то на girar, то на git.alt ? Да, точно. Нужна квота именно на на git.alt Пожалуйста увеличьте хотя-бы до 16Гб > > > Filesystem space quota limit grace files quota l > > imit > > grace > > /dev/simfs 3477M 4096M 4608M 1176 98304 > > 123k > > > > Заранее спасибо за помощь. > > > > > > В Вт, 25/01/2022 в 13:47 +0300, Pavel Vasenkov пишет: > > > Кто может, помогите пожалуйста. > > > > > > у меня ( pav@ ) на git.alt слишком маленькая quota: > > > > > > > > > $ ssh git.alt quota > > > Filesystem space quota limit grace files quota > > > lim > > > it > > > grace > > > /dev/simfs 1594M 4096M 4608M 1159 98304 > > > 123k > > > > > > > > > Не удается корректно скопировать пакет в 6,6G > > > http://git.altlinux.org/gears/t/thunderbird.git > > > > > > Получаю сообщение о переполнении. > > > > > > > > > > > > Огромная просьба увеличить мне дисковый лимит до 16-20G. > > > > > > > > _______________________________________________ > > Devel mailing list > > Devel@lists.altlinux.org > > https://lists.altlinux.org/mailman/listinfo/devel
Здравствуйте! При попытке склонировать репозиторий git clone --reference `pwd`/linux/.git git://git.altlinux.org/people/kernelbot/packages/kernel-image.git получаю следующее: Cloning into 'kernel-image'... remote: Counting objects: 1933502, done. remote: fatal: unable to create thread: Resource temporarily unavailable remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: fetch-pack: invalid index-pack output Как с этим бороться?
On Sat, Feb 26, 2022 at 09:18:27PM +0400, Alexey Sheplyakov wrote: > Здравствуйте! > > При попытке склонировать репозиторий > > git clone --reference `pwd`/linux/.git git://git.altlinux.org/people/kernelbot/packages/kernel-image.git > > получаю следующее: > > Cloning into 'kernel-image'... > remote: Counting objects: 1933502, done. > remote: fatal: unable to create thread: Resource temporarily unavailable > remote: aborting due to possible repository corruption on the remote side. > fatal: early EOF > fatal: fetch-pack: invalid index-pack output > > Как с этим бороться? JFYI, проблема этого clone решена, но если кому-то ещё понадобится, то это не хватает памяти на git.altlinux.org для работа git:// протокола. Обходится это clone/fetch по ssh с gitery.altlinux.org > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel
On Thu, Mar 10, 2022 at 07:25:45PM +0300, Vitaly Chikunov wrote: > On Sat, Feb 26, 2022 at 09:18:27PM +0400, Alexey Sheplyakov wrote: > > Здравствуйте! > > > > При попытке склонировать репозиторий > > > > git clone --reference `pwd`/linux/.git git://git.altlinux.org/people/kernelbot/packages/kernel-image.git > > > > получаю следующее: > > > > Cloning into 'kernel-image'... > > remote: Counting objects: 1933502, done. > > remote: fatal: unable to create thread: Resource temporarily unavailable > > remote: aborting due to possible repository corruption on the remote side. > > fatal: early EOF > > fatal: fetch-pack: invalid index-pack output > > > > Как с этим бороться? > > JFYI, проблема этого clone решена, но если кому-то ещё понадобится, то Я не удачно сформулировал - проблема такого git clone не решена. > это не хватает памяти на git.altlinux.org для работа git:// протокола. > Обходится это clone/fetch по ssh с gitery.altlinux.org > > > _______________________________________________ > > Devel mailing list > > Devel@lists.altlinux.org > > https://lists.altlinux.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel
Привет. Вот что мне выдаётся при попытке отправить пакет на сборку: $ ssh gitz build u-boot u-boot-sunxi-2022.07-alt1 --commit new task #303605: owner=sbolshakov repo=sisyphus task add: task #303605 is locked task rm: task #303605 is locked Что-то там неладно. (gitz = gyle.a.o) --
On Wednesday, 13 July 2022 11:59:00 MSK Sergey Bolshakov wrote: > Привет. > Вот что мне выдаётся при попытке отправить пакет на сборку: > > $ ssh gitz build u-boot u-boot-sunxi-2022.07-alt1 --commit > new task #303605: owner=sbolshakov repo=sisyphus > task add: task #303605 is locked > task rm: task #303605 is locked > > Что-то там неладно. +1 > (gitz = gyle.a.o) -- Regards, Sergey.