[devel] *-gdb пакеты

[devel] *-gdb пакеты

[Max Ivanov]

Есть ли у нас возможность делать *-gdb пакеты, как, например, в федоре?
Т.е. ставишь обычный qutIM , работаешь, нашел место падения, ставишь
qutIM-gdb и вуаля, красивые бектрейсы, запуск из под gdb и прочие
радости.

Re: [devel] *-gdb пакеты

[Pavlov Konstantin]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

On Thu, Apr 16, 2009 at 04:27:21PM +0400, Max Ivanov wrote:
> Есть ли у нас возможность делать *-gdb пакеты, как, например, в федоре?
> Т.е. ставишь обычный qutIM , работаешь, нашел место падения, ставишь
> qutIM-gdb и вуаля, красивые бектрейсы, запуск из под gdb и прочие
> радости.

Мне это тоже интересно. Попробую реализовать.

-- 
> В последнем wks26, как написано ниже, зависание при выходе из иксов.
> В остальных (два непоследних wks26 и непоследний std226) почему-то
> исчезли виртуальные консоли.
вы сами не запутались? "непоследний один" и "непоследний другой"
- это сильное высказывание.
		-- lakostis in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Pavlov Konstantin]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Tue, Apr 21, 2009 at 05:37:55PM +0400, Pavlov Konstantin wrote:
> On Thu, Apr 16, 2009 at 04:27:21PM +0400, Max Ivanov wrote:
> > Есть ли у нас возможность делать *-gdb пакеты, как, например, в федоре?
> > Т.е. ставишь обычный qutIM , работаешь, нашел место падения, ставишь
> > qutIM-gdb и вуаля, красивые бектрейсы, запуск из под gdb и прочие
> > радости.
> 
> Мне это тоже интересно. Попробую реализовать.

В Fedora это реализовано следующим образом:

в конце секции %install запускается макрос

%{?__debug_package:%{__debug_install_post}}, который генерит
%дополнительный пакет debug и вызывает для формирования файлов в нем
 скрипт find-debuginfo.sh.

Что скажут ув. мантейнеры rpm?

https://bugzilla.altlinux.org/show_bug.cgi?id=19707

-- 
> Грабли - оно штука занятная: не узнаешь, пока не наступишь. :-)
Пользуйтесь граблеискателем. :)
		-- ldv in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
> On Tue, Apr 21, 2009 at 05:37:55PM +0400, Pavlov Konstantin wrote:
> > On Thu, Apr 16, 2009 at 04:27:21PM +0400, Max Ivanov wrote:
> > > Есть ли у нас возможность делать *-gdb пакеты, как, например, в федоре?
> > > Т.е. ставишь обычный qutIM , работаешь, нашел место падения, ставишь
> > > qutIM-gdb и вуаля, красивые бектрейсы, запуск из под gdb и прочие
> > > радости.
> > 
> > Мне это тоже интересно. Попробую реализовать.
> 
> В Fedora это реализовано следующим образом:
> 
> в конце секции %install запускается макрос
> 
> %{?__debug_package:%{__debug_install_post}}, который генерит
> %дополнительный пакет debug и вызывает для формирования файлов в нем
>  скрипт find-debuginfo.sh.
> 
> Что скажут ув. мантейнеры rpm?

Не знаю стоит это делать или нет.

Там сделано как.  Автоматически генерируется левый пакет %name-debuginfo.
То есть прямо как бо вставляется в спекфайлу.

#       Template for debug information sub-package.
%debug_package \
%ifnarch noarch\
%global __debug_package 1\
%package debug\
Summary: Debug information for package %{name}\
Group: Development/Debug\
AutoReqProv: 0\
%description debug\
This package provides debug information for package %{name}.\
Debug information is useful when developing applications that use this\
package or when debugging this package.\
%files debug -f debugfiles.list\
%defattr(-,root,root)\
%endif\
%{nil}

А далее этот скрипт find-debuginfo.sh вызывает strip который специальным
образом складывает обрезки ельфов в файлы с дополнительным суффиком .debug.

Получается вот такие тонны генерата.  Его конечно хранят отдельно.
http://download.opensuse.org/factory/repo/debug/suse/x86_64/

Интересно как этот debuginfo потом будет загружать gdb.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

* Alexey Tourbin <at@> [090421 22:19]:
> Интересно как этот debuginfo потом будет загружать gdb.
Примерно так (strip(1)):

Run "objcopy --add-gnu-debuglink=foo.dbg foo" to add a link to
the debugging info into the stripped executable.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Pavlov Konstantin]

[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]

On Tue, Apr 21, 2009 at 10:18:18PM +0400, Alexey Tourbin wrote:
> > Что скажут ув. мантейнеры rpm?
> 
> Не знаю стоит это делать или нет.
> 
> Там сделано как.  Автоматически генерируется левый пакет %name-debuginfo.
> То есть прямо как бо вставляется в спекфайлу.
> 
> #       Template for debug information sub-package.
> %debug_package \
> %ifnarch noarch\
> %global __debug_package 1\
> %package debug\
> Summary: Debug information for package %{name}\
> Group: Development/Debug\
> AutoReqProv: 0\
> %description debug\
> This package provides debug information for package %{name}.\
> Debug information is useful when developing applications that use this\
> package or when debugging this package.\
> %files debug -f debugfiles.list\
> %defattr(-,root,root)\
> %endif\
> %{nil}

Да, это было ясно. Не вижу большой проблемы в этом.

> А далее этот скрипт find-debuginfo.sh вызывает strip который специальным
> образом складывает обрезки ельфов в файлы с дополнительным суффиком .debug.
> 
> Получается вот такие тонны генерата.  Его конечно хранят отдельно.
> http://download.opensuse.org/factory/repo/debug/suse/x86_64/

Не везде. Например в debian оно лежит в основном репозитории.

> Интересно как этот debuginfo потом будет загружать gdb.

info gdb, секция 15.2. Т.е. gdb автомагически будет смотреть в указанное:
--with-separate-debug-dir=%_libdir/debug в gdb.spec

-- 
<AMorozov> hiddenman: у меня знакомые (другие уже), находясь на конференции в
           Германии, решили съездить в Голландию в музей Ван Гога.
<AMorozov> Девушки они правильные (даже чересчур), поэтому ехали они в
           Голландию исключительно на Ван Гога посмотреть, никаких нехороших
           увеселений не планировалось.
<AMorozov> приехали туда, пошли устраиваться в /хостел подешевле/.  Пришли,
           мужик на ресепшне им меланхолически выдал ключи и указал комнату.
           Они туда зашли, включили свет.
<henker> и? :)
<klalafuda> а там бородатый мужик ставит Linux

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Tue, Apr 21, 2009 at 10:32:35PM +0400, Pavlov Konstantin wrote:
> On Tue, Apr 21, 2009 at 10:18:18PM +0400, Alexey Tourbin wrote:
> > > Что скажут ув. мантейнеры rpm?
> > 
> > Не знаю стоит это делать или нет.
> > 
> > Там сделано как.  Автоматически генерируется левый пакет %name-debuginfo.
> > То есть прямо как бо вставляется в спекфайлу.
> > 
> > #       Template for debug information sub-package.
> > %debug_package \
> > %ifnarch noarch\
> > %global __debug_package 1\
> > %package debug\
> > Summary: Debug information for package %{name}\
> > Group: Development/Debug\
> > AutoReqProv: 0\
> > %description debug\
> > This package provides debug information for package %{name}.\
> > Debug information is useful when developing applications that use this\
> > package or when debugging this package.\
> > %files debug -f debugfiles.list\
> > %defattr(-,root,root)\
> > %endif\
> > %{nil}
> 
> Да, это было ясно. Не вижу большой проблемы в этом.

Okay, let's talk about global *-debuginfo support.  First off,
we need to pass -g to the compiler.  Assuming that -g does not
alter optimization, there are two ways to plug -g:

1) in %optflags; the problem is that %optflags are not always used,
and for this reason there is a second option:

2) in gcc spec, implicitly, like __chk_printf/--as-needed etc.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]


Twas brillig at 22:18:18 21.04.2009 UTC+04 when at@altlinux.ru did gyre and gimble:

 AT> Там сделано как.  Автоматически генерируется левый пакет %name-debuginfo.
 AT> То есть прямо как бо вставляется в спекфайлу.

 AT> #       Template for debug information sub-package.
...
 AT> %{nil}

Не хватает простановки зависимостей между дебаг-инфой и бинарниками, их
которых она сгенерирована, ибо дебаг-инфа от другой сборки менее, чем
полезна.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:

Для отладки этой возможности очень не хватает сейчас. Пересборка с
--with-debug приводит к невоспроизводимости некоторых баг, которые есть в
обычной ситуации. Вот mutt1.5 у меня, например, тот что из репо -- падает,
а пересобранный самостоятельно с --with-debug не падает.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

Здравствуйте Денис Смирнов
  В сообщении от 27 апреля 2009 Денис Смирнов написал(a):
> Вот mutt1.5 у меня, например, тот что из репо -- падает,
> а пересобранный самостоятельно с --with-debug не падает.

По личному опыту - обычно так выражается ошибки инициализации, в 
частности ошибка инициализации массивов и структур.  

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Slava Semushin]

27 апреля 2009 г. 15:58 пользователь Денис Смирнов <mithraen@altlinux> написал:
> On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
>
> Для отладки этой возможности очень не хватает сейчас. Пересборка с
> --with-debug приводит к невоспроизводимости некоторых баг, которые есть в
> обычной ситуации. Вот mutt1.5 у меня, например, тот что из репо -- падает,
> а пересобранный самостоятельно с --with-debug не падает.

Запуск под valgrind-ом часто помогает быстрее локализовать причину
падения программы. :)


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Wed, Apr 22, 2009 at 12:28:30AM +0400, Alexey Tourbin wrote:
> Assuming that -g does not alter optimization, there are two ways to plug
> -g:
> 
> 1) in %optflags; 
Так сделано в Debian, SUSE, Fedora и Mandriva.

> the problem is that %optflags are not always used,
"If not, suboptimal debuginfo packages are not the only problem; the
package is probably also compiled without the security enhancing options
of recent compiler versions."
Это, во-1-х, проблема конкретных пакетов, и если майнтейнер хочет -dbg, он
эту проблему исправит. Во-2-х, это в любом случае если не бага, то
неприятность, стоящая её исправления.

> and for this reason there is a second option:
> 
> 2) in gcc spec, implicitly, like __chk_printf/--as-needed etc.
Я против. Это не то, ради чего надо патчить gcc, тем более что на мой
взгляд это достигается более простым способом.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

"я тебя открыл, я тебя и closed"
		-- mike in #4235

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
> В Fedora это реализовано следующим образом:
> 
> в конце секции %install запускается макрос
> 
> %{?__debug_package:%{__debug_install_post}}, который генерит
> %дополнительный пакет debug и вызывает для формирования файлов в нем
>  скрипт find-debuginfo.sh.
Proof of concept тут:
http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo
Основано на rpm 5.1.9. debugedit падает на hashFunctionContextDigest, т.к.
в нашем почти прошловековом beecrypt у него другая сигнатура.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> Похоже, обновление rpm не проходит.
Похоже, что у вас apt слишком старый, раз он rpm запускает.
Похоже, что у вас /bin/rpm статически собранный, раз он падает.
Похоже, что у вас rpm слишком старый, поскольку /bin/rpm собран
статически.

Вывод: похоже, что вам не стоит обновлять такую систему без промежуточного
репозитария.
		-- ldv in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[devel] base2 <-> base62

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

Ломал голову несколько часов.  Кто знает тому пряник.

Есть слово в алфавите {0,1} - т.е. последовательность нулей и единиц.
Хочется представить это слово в алфавите {0..9,a..z,A..Z} (base62)
для экономии битов.  То есть получить более короткое представление
этой последовательности в виде букв и цифр.  И нужно уметь
конвертировать назад.

Понятно, что если из последовательности сделать просто число, то задача
сводится к представлению числа в различных системах счисления.  Но
последовательность слишком длинная, в машинное число она не поместится,
а связываться с GPM неохота.

В связи с чем вопрос, нет ли какого-нибудь более простого способа.
Мне казалось как-то с остатками можно сделать.  Но раскодировать остатки
пока не получилось.-)

    // Далее последовательность нулей и единиц хранится в { bitc, bitv[] }.

    // base62
    void put_digit(int c)
    {
	if (c < 10)
	    putchar(c + '0');
	else if (c < 36)
	    putchar(c - 10 + 'a');
	else if (c < 62)
	    putchar(c - 36 + 'A');
    }

    v = 0;
    for (i = 0; i < bitc; i++) {
	v = (v << 1) | bitv[i];
	while (v >= 62) {
	    int q = v / 62;
	    int r = v % 62;
	    put_digit(r);
	    v = q;
	}
    }
    if (v)
	put_digit(v);
    putchar('\n');


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Thu, Aug 05, 2010 at 01:18:18AM +0400, Alexey Tourbin wrote:
> Ломал голову несколько часов.  Кто знает тому пряник.
> 
> Есть слово в алфавите {0,1} - т.е. последовательность нулей и единиц.
> Хочется представить это слово в алфавите {0..9,a..z,A..Z} (base62)
> для экономии битов.

Почему 62, там ведь есть ещё пара разрешённых символов: '_' и '/'.
Итого 64, т.е. ровно 6 бит.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Thu, Aug 05, 2010 at 01:26:20AM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 05, 2010 at 01:18:18AM +0400, Alexey Tourbin wrote:
> > Ломал голову несколько часов.  Кто знает тому пряник.
> > 
> > Есть слово в алфавите {0,1} - т.е. последовательность нулей и единиц.
> > Хочется представить это слово в алфавите {0..9,a..z,A..Z} (base62)
> > для экономии битов.
> 
> Почему 62, там ведь есть ещё пара разрешённых символов: '_' и '/'.
> Итого 64, т.е. ровно 6 бит.

Это нужно для зависимостей, которые будут выглядеть как
libfoo.so.1 = set:0123456789abcdefg...

После "set:" не хотелось бы ставить ничего, кроме букв и цифр.
Подчеркивание ещё пойдет, хотя два подчеркивания подряд или
подчеркивание в начале или в конце уже будут плохо смотреться.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

On Thu, Aug 05, 2010 at 01:38:12AM +0400, Alexey Tourbin wrote:
> On Thu, Aug 05, 2010 at 01:26:20AM +0400, Dmitry V. Levin wrote:
> > On Thu, Aug 05, 2010 at 01:18:18AM +0400, Alexey Tourbin wrote:
> > > Ломал голову несколько часов.  Кто знает тому пряник.
> > > 
> > > Есть слово в алфавите {0,1} - т.е. последовательность нулей и единиц.
> > > Хочется представить это слово в алфавите {0..9,a..z,A..Z} (base62)
> > > для экономии битов.
> > 
> > Почему 62, там ведь есть ещё пара разрешённых символов: '_' и '/'.
> > Итого 64, т.е. ровно 6 бит.
> 
> Это нужно для зависимостей, которые будут выглядеть как
> libfoo.so.1 = set:0123456789abcdefg...
> 
> После "set:" не хотелось бы ставить ничего, кроме букв и цифр.

Не надо создавать искусственные ограничения.  parseRCPOT() не требует
ограничиваться xisalnum() в "версии" зависимостей.

> Подчеркивание ещё пойдет, хотя два подчеркивания подряд или
> подчеркивание в начале или в конце уже будут плохо смотреться.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

On Thu, Aug 05, 2010 at 02:05:13AM +0400, Dmitry V. Levin wrote:
> > Это нужно для зависимостей, которые будут выглядеть как
> > libfoo.so.1 = set:0123456789abcdefg...
> > 
> > После "set:" не хотелось бы ставить ничего, кроме букв и цифр.
> 
> Не надо создавать искусственные ограничения.  parseRCPOT() не требует
> ограничиваться xisalnum() в "версии" зависимостей.

Тогда список символов ещё шире, и вопрос сохраняется.

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

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

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

Увидел в google.com/codesearch, что base62 легко сделать из base64.
А именно, например, в base64 можно заменить "i" -> "ii", "_" -> "i1",
"/" -> "i2".  Наверное так и надо сделать, если численных идей
не появится.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

On Thu, Aug 05, 2010 at 11:41:40AM +0400, Алексей Турбин wrote:

AT> Увидел в google.com/codesearch, что base62 легко сделать из base64.
AT> А именно, например, в base64 можно заменить "i" -> "ii", "_" -> "i1",
AT> "/" -> "i2".  Наверное так и надо сделать, если численных идей
AT> не появится.

Обрабатывать блоки размером 31 байт, это уже не столь страшные длинные
числа будут?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Alexander Bokovoy]

2010/8/5 Alexey Tourbin <at@altlinux.ru>:
> Ломал голову несколько часов.  Кто знает тому пряник.
>
> Есть слово в алфавите {0,1} - т.е. последовательность нулей и единиц.
> Хочется представить это слово в алфавите {0..9,a..z,A..Z} (base62)
> для экономии битов.  То есть получить более короткое представление
> этой последовательности в виде букв и цифр.  И нужно уметь
> конвертировать назад.
>
> Понятно, что если из последовательности сделать просто число, то задача
> сводится к представлению числа в различных системах счисления.  Но
> последовательность слишком длинная, в машинное число она не поместится,
> а связываться с GPM неохота.
В оригинальной задаче наличие всех первоначальных битов обязательно
или можно обойтись хэшем?
Если нельзя, то какой длины последовательность? Хорошо ли сжимается?
Может быть имеет смысл сжимать (хаффманом или еще чем), а потом
полученный результат паковать в base64 и заменять "неправильные"
символы на "правильные" с однозначным обратным восстановлением при
распаковке с последующим unbase64.

-- 
/ Alexander Bokovoy

Re: [devel] base2 <-> base62

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]

On Thu, Aug 05, 2010 at 04:07:00PM +0300, Alexander Bokovoy wrote:
> 2010/8/5 Alexey Tourbin <at@altlinux.ru>:
> > Ломал голову несколько часов.  Кто знает тому пряник.
> >
> > Есть слово в алфавите {0,1} - т.е. последовательность нулей и единиц.
> > Хочется представить это слово в алфавите {0..9,a..z,A..Z} (base62)
> > для экономии битов.  То есть получить более короткое представление
> > этой последовательности в виде букв и цифр.  И нужно уметь
> > конвертировать назад.
> >
> > Понятно, что если из последовательности сделать просто число, то задача
> > сводится к представлению числа в различных системах счисления.  Но
> > последовательность слишком длинная, в машинное число она не поместится,
> > а связываться с GPM неохота.
> В оригинальной задаче наличие всех первоначальных битов обязательно
> или можно обойтись хэшем?

Обязательно.  В двух словах, происходит следующее.
Нам надо представить набор строк в виде их хешей.
Строки хешируются и урезаются по длине хеша (e.g. 20 битов).
1) Массив хешей сортируется.
2) Идет дельта кодирование, то есть хранится разница между соседними
значениями.
2) Применяется golomb coding, на этих данных он дает оптимальный
результат (как хаффман), т.к. если хеш дает равномерное распределение,
то после сортировки и дельта кодирования получается геометрическое распределение.

Недавно вычитал в статье
http://algo2.iti.kit.edu/singler/publications/cacheefficientbloomfilters-wea2007.pdf
Куда раньше смотрел не понятно.-(

> Если нельзя, то какой длины последовательность? Хорошо ли сжимается?
> Может быть имеет смысл сжимать (хаффманом или еще чем), а потом
> полученный результат паковать в base64 и заменять "неправильные"
> символы на "правильные" с однозначным обратным восстановлением при
> распаковке с последующим unbase64.

Соответственно у меня проблема уже на последней стадии: golomb encoder
выдает поток нулей и единиц, надо их представить в окончательном виде,
пригодном для зависимостей.

Длина большая, представь себе что в библиотеке 1024 символа, и
изначально хеш 20 битов на символ.  После ужатия получается примерно
12 битов на символ.  Поэтому и есть интерес сделать эту строку как можно
короче, за счет base62.  А если бы она был не такой длинной, то сгодился
бы hex обычный.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Hi,

On Sun, May 03, 2009 at 11:55:14PM +0600, Andrey Rahmatullin wrote:
> On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
> > В Fedora это реализовано следующим образом:
> > 
> > в конце секции %install запускается макрос
> > 
> > %{?__debug_package:%{__debug_install_post}}, который генерит
> > %дополнительный пакет debug и вызывает для формирования файлов в нем
> >  скрипт find-debuginfo.sh.
> Proof of concept тут:
> http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo
> Основано на rpm 5.1.9. debugedit падает на hashFunctionContextDigest, т.к.
> в нашем почти прошловековом beecrypt у него другая сигнатура.

Может быть, лучше собрать утилиту debugedit отдельно от rpm?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

On Thu, Aug 05, 2010 at 11:41:40AM +0400, Alexey Tourbin wrote:
> Увидел в google.com/codesearch, что base62 легко сделать из base64.
> А именно, например, в base64 можно заменить "i" -> "ii", "_" -> "i1",
> "/" -> "i2".  Наверное так и надо сделать, если численных идей
> не появится.

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

Но с первого раза у меня опять не получилось написать декодирование.
Кто хочет мне помочь?  Вот полностью кодирование.  После декодирования
разрешается, чтобы массив bitv[] содержал в конце несколько лишних
нулей.

    const char *bitv_to_base62(int bitc, char bitv[])
    {
	int base62c = 0;
	char *base62v = NULL;
	void put_char(int c)
	{
	    int realloc_delta = 1024;
	    if ((base62c & (realloc_delta - 1)) == 0)
		base62v = realloc(base62v, sizeof(*base62v) * (base62c + realloc_delta));
	    base62v[base62c++] = c;
	}
	void put_digit(int c)
	{
	    if (c < 10)
		put_char(c + '0');
	    else if (c < 36)
		put_char(c - 10 + 'a');
	    else if (c < 62)
		put_char(c - 36 + 'A');
	}
	int i;
	int bits6 = 0;
	int num6b = 0;
	for (i = 0; i < bitc; i++) {
	    if (bits6 < 6)
		num6b |= bitv[i] << bits6++;
	    if (bits6 == 6) {
		switch (num6b) {
		case 61:
		    put_digit(61);
		    // extra "0" binary bit
		    bits6 = 1;
		    num6b = 0;
		    break;
		case 62:
		    put_digit(61);
		    // extra "10" binary bits
		    bits6 = 2;
		    num6b = 1;
		    break;
		case 63:
		    put_digit(61);
		    // extra "11" binary bits
		    bits6 = 2;
		    num6b = 3;
		    break;
		default:
		    assert(num6b < 61);
		    put_digit(num6b);
		    bits6 = 0;
		    num6b = 0;
		    break;
		}
	    }
	}
	if (bits6) {
	    assert(num6b < 61);
	    put_digit(num6b);
	}
	put_char(0);
	return base62v;
    }

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

On Fri, Aug 06, 2010 at 05:17:19PM +0400, Alexey Tourbin wrote:
> Но с первого раза у меня опять не получилось написать декодирование.
> Кто хочет мне помочь?  Вот полностью кодирование.  После декодирования
> разрешается, чтобы массив bitv[] содержал в конце несколько лишних
> нулей.
> 
>     const char *bitv_to_base62(int bitc, char bitv[])
>     {
> 	int base62c = 0;
> 	char *base62v = NULL;
> 	void put_char(int c)
> 	{
> 	    int realloc_delta = 1024;
> 	    if ((base62c & (realloc_delta - 1)) == 0)
> 		base62v = realloc(base62v, sizeof(*base62v) * (base62c + realloc_delta));
> 	    base62v[base62c++] = c;
> 	}
> 	void put_digit(int c)
> 	{
> 	    if (c < 10)
> 		put_char(c + '0');
> 	    else if (c < 36)
> 		put_char(c - 10 + 'a');
> 	    else if (c < 62)
> 		put_char(c - 36 + 'A');
> 	}
> 	int i;
> 	int bits6 = 0;
> 	int num6b = 0;
> 	for (i = 0; i < bitc; i++) {
> 	    if (bits6 < 6)
> 		num6b |= bitv[i] << bits6++;
> 	    if (bits6 == 6) {
> 		switch (num6b) {
> 		case 61:
> 		    put_digit(61);
> 		    // extra "0" binary bit
> 		    bits6 = 1;
> 		    num6b = 0;
> 		    break;
> 		case 62:
> 		    put_digit(61);
> 		    // extra "10" binary bits
> 		    bits6 = 2;
> 		    num6b = 1;
> 		    break;
> 		case 63:
> 		    put_digit(61);
> 		    // extra "11" binary bits
> 		    bits6 = 2;
> 		    num6b = 3;
> 		    break;
> 		default:
> 		    assert(num6b < 61);
> 		    put_digit(num6b);
> 		    bits6 = 0;
> 		    num6b = 0;
> 		    break;
> 		}
> 	    }
> 	}
> 	if (bits6) {
> 	    assert(num6b < 61);
> 	    put_digit(num6b);
> 	}
> 	put_char(0);
> 	return base62v;
>     }

Нужно учитывать, что значение 61 (Z) может идти два или более раза
подряд.  Например, следующий bitv[] кодируется в "ZZ1".  Это значит,
что мы не можем сразу же распаковать "Z", посмотрев на следующую букву.
Потому что следующая буква тоже может быть "Z" и т.д.  Тогда надо класть
Z в стек и распаковывать в обратном порядке.  Это слишком сложно.
Распаковка должна работать быстро и быть более-менее тривиальной.
Тогда можно попытаться сделать так, чтобы после первого Z никогда
не могло идти второе Z.

    char bitv[] = {
	1, 0, 1, 1, 1, 1,
	1, 1, 1, 1, 1, 0,
    };

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] base2 <-> base62

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

On Fri, Aug 06, 2010 at 06:26:38PM +0400, Alexey Tourbin wrote:
> On Fri, Aug 06, 2010 at 05:17:19PM +0400, Alexey Tourbin wrote:
> > Но с первого раза у меня опять не получилось написать декодирование.
> > Кто хочет мне помочь?  Вот полностью кодирование.  После декодирования
> > разрешается, чтобы массив bitv[] содержал в конце несколько лишних
> > нулей.
> > 
> >     const char *bitv_to_base62(int bitc, char bitv[])
> >     {
> > 	int base62c = 0;
> > 	char *base62v = NULL;
> > 	void put_char(int c)
> > 	{
> > 	    int realloc_delta = 1024;
> > 	    if ((base62c & (realloc_delta - 1)) == 0)
> > 		base62v = realloc(base62v, sizeof(*base62v) * (base62c + realloc_delta));
> > 	    base62v[base62c++] = c;
> > 	}
> > 	void put_digit(int c)
> > 	{
> > 	    if (c < 10)
> > 		put_char(c + '0');
> > 	    else if (c < 36)
> > 		put_char(c - 10 + 'a');
> > 	    else if (c < 62)
> > 		put_char(c - 36 + 'A');
> > 	}
> > 	int i;
> > 	int bits6 = 0;
> > 	int num6b = 0;
> > 	for (i = 0; i < bitc; i++) {
> > 	    if (bits6 < 6)
> > 		num6b |= bitv[i] << bits6++;
> > 	    if (bits6 == 6) {
> > 		switch (num6b) {
> > 		case 61:
> > 		    put_digit(61);
> > 		    // extra "0" binary bit
> > 		    bits6 = 1;
> > 		    num6b = 0;
> > 		    break;
> > 		case 62:
> > 		    put_digit(61);
> > 		    // extra "10" binary bits
> > 		    bits6 = 2;
> > 		    num6b = 1;
> > 		    break;
> > 		case 63:
> > 		    put_digit(61);
> > 		    // extra "11" binary bits
> > 		    bits6 = 2;
> > 		    num6b = 3;
> > 		    break;
> > 		default:
> > 		    assert(num6b < 61);
> > 		    put_digit(num6b);
> > 		    bits6 = 0;
> > 		    num6b = 0;
> > 		    break;
> > 		}
> > 	    }
> > 	}
> > 	if (bits6) {
> > 	    assert(num6b < 61);
> > 	    put_digit(num6b);
> > 	}
> > 	put_char(0);
> > 	return base62v;
> >     }
> 
> Нужно учитывать, что значение 61 (Z) может идти два или более раза
> подряд.  Например, следующий bitv[] кодируется в "ZZ1".  Это значит,
> что мы не можем сразу же распаковать "Z", посмотрев на следующую букву.

На самом деле можем, если упаковывать биты в буквы, начиная со
старшего; тогда, прочитав после "Z" ещё "Z", которое в данном случае
обозначает 1111(01|10|11), можно использовать старшие 11, не
заглядывая далее.

> Потому что следующая буква тоже может быть "Z" и т.д.  Тогда надо класть
> Z в стек и распаковывать в обратном порядке.  Это слишком сложно.
> Распаковка должна работать быстро и быть более-менее тривиальной.
> Тогда можно попытаться сделать так, чтобы после первого Z никогда
> не могло идти второе Z.
> 
>     char bitv[] = {
> 	1, 0, 1, 1, 1, 1,
> 	1, 1, 1, 1, 1, 0,
>     };

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Kirill A. Shutemov]

On Thu, Aug 05, 2010 at 09:00:00PM +0400, Dmitry V. Levin wrote:
> Hi,
> 
> On Sun, May 03, 2009 at 11:55:14PM +0600, Andrey Rahmatullin wrote:
> > On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
> > > В Fedora это реализовано следующим образом:
> > > 
> > > в конце секции %install запускается макрос
> > > 
> > > %{?__debug_package:%{__debug_install_post}}, который генерит
> > > %дополнительный пакет debug и вызывает для формирования файлов в нем
> > >  скрипт find-debuginfo.sh.
> > Proof of concept тут:
> > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo
> > Основано на rpm 5.1.9. debugedit падает на hashFunctionContextDigest, т.к.
> > в нашем почти прошловековом beecrypt у него другая сигнатура.
> 
> Может быть, лучше собрать утилиту debugedit отдельно от rpm?

Я попробовал перетащить наш rpm на более живой beecrypt.

Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
rpm притворяется, что работает. Нужно хорошенько его потестировать.
Наверняка что-нибудь сломано.

Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
Посмотрите, пожалуйста.

debuginfo теперь (с новым beecrypt) похож на рабочий. Потребовалось немного
напильника. И, конечно, ещё понадобиться, но для proof of concept сойдёт.
Смотрите ветку debuginfo у меня в git.

Всё. Спать.

P.S. Я неделю в отпуске, так что можете готовиться к новому gcc :)

-- 
 Kirill A. Shutemov

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 4420 bytes --]

On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> Я попробовал перетащить наш rpm на более живой beecrypt.
> 
> Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> rpm притворяется, что работает. Нужно хорошенько его потестировать.
> Наверняка что-нибудь сломано.
> 
> Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> Посмотрите, пожалуйста.
> 
> debuginfo теперь (с новым beecrypt) похож на рабочий. Потребовалось немного
> напильника. И, конечно, ещё понадобиться, но для proof of concept сойдёт.
> Смотрите ветку debuginfo у меня в git.
В /people/wrar/packages/hello.git в ветке debug лежит спек с добавленными
ровно двумя строчками:

%def_enable debug (чтоб собиралось с -g)
%debug_package (чтоб создавался дебаг-пакет)

Создался пакет hello-debug с таким содержимым:

drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/lib/debug/.build-id
drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/lib/debug/.build-id/36
lrwxrwxrwx    1 root    root               21 Авг  7 15:24 /usr/lib/debug/.build-id/36/515c96c9c09363cd0fbe9156e2926013a087bd -> ../../../../bin/hello
lrwxrwxrwx    1 root    root               25 Авг  7 15:24 /usr/lib/debug/.build-id/36/515c96c9c09363cd0fbe9156e2926013a087bd.debug -> ../../usr/bin/hello.debug
drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/lib/debug/usr
drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/lib/debug/usr/bin
-rwxr-xr-x    1 root    root            26780 Авг  7 15:24 /usr/lib/debug/usr/bin/hello.debug
drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/src/debug/hello-2.4
drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib
drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib
-rw-r--r--    1 root    root             3050 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/close-stream.c
-rw-r--r--    1 root    root             4522 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/closeout.c
-rw-r--r--    1 root    root              856 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/exitfail.c
-rw-r--r--    1 root    root              759 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/exitfail.h
-rw-r--r--    1 root    root            22370 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/quotearg.c
-rw-r--r--    1 root    root            11981 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/quotearg.h
-rw-r--r--    1 root    root             1322 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/xalloc-die.c
-rw-r--r--    1 root    root             8152 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/xalloc.h
-rw-r--r--    1 root    root             3327 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/xmalloc.c
drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/src/debug/hello-2.4/src
-rw-r--r--    1 root    root             5774 Авг  7 15:24 /usr/src/debug/hello-2.4/src/hello.c

У него, кстати, нет зависимостей ни на что, включая главный пакет.

В hello/src/hello.c внесено изменение специального вида, позволяющее
протестировать нужность пакета hello-debug. Сначала этот пакет не
установлен:

Reading symbols from /usr/bin/hello...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/hello 

Program received signal SIGSEGV, Segmentation fault.
0x08048bba in exit ()
(gdb) bt
#0  0x08048bba in exit ()
#1  0x0804a4f3 in ?? ()
#2  0x4ef47c66 in __libc_start_main () from /lib/libc.so.6
#3  0x08048ac1 in exit ()

Теперь установлен:

Reading symbols from /usr/bin/hello...Reading symbols from
/usr/lib/debug/usr/bin/hello.debug...done.
done.
(gdb) r
Starting program: /usr/bin/hello 

Program received signal SIGSEGV, Segmentation fault.
0x08048bba in main (argc=1, argv=0xbfffefd4) at hello.c:63
63        *((char*)0) = 0;
(gdb) bt
#0  0x08048bba in main (argc=1, argv=0xbfffefd4) at hello.c:63


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> >"Что было бы, если бы ALT Linux Team производила самолеты?" :-)
> А Вы не пользуйтесь Сизифом ;)
"Да нет, ничего, мы привыкли" (TM). Просто, гхм, слегка оторопь берет,
когда таким вот способом из биплана в полете делают дирижабль: вначале
отламывают крылья, а уж потом начинают искать баллоны с гелием :-)
		-- morozov in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Kirill A. Shutemov]

On Sat, Aug 07, 2010 at 03:36:23PM +0600, Andrey Rahmatullin wrote:
> On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > Я попробовал перетащить наш rpm на более живой beecrypt.
> > 
> > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > Наверняка что-нибудь сломано.
> > 
> > Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> > Посмотрите, пожалуйста.
> > 
> > debuginfo теперь (с новым beecrypt) похож на рабочий. Потребовалось немного
> > напильника. И, конечно, ещё понадобиться, но для proof of concept сойдёт.
> > Смотрите ветку debuginfo у меня в git.
> В /people/wrar/packages/hello.git в ветке debug лежит спек с добавленными
> ровно двумя строчками:
> 
> %def_enable debug (чтоб собиралось с -g)

Теперь -g всегда есть в %optflags_default

> %debug_package (чтоб создавался дебаг-пакет)

Теперь он всегда создаётся. --disable debug_packages что б выключить.

Всё в той же ветке

<кусь/>

> У него, кстати, нет зависимостей ни на что, включая главный пакет.
> 

at@, поможешь? Наверно нужно изобразить конфликты на пакеты собираемые из
того же спека с версией отличной от %version-%release.

-- 
 Kirill A. Shutemov

Re: [devel] автогенерация debug-пакетов в rpm

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 3507 bytes --]

On Sat, Aug 07, 2010 at 03:36:23PM +0600, Andrey Rahmatullin wrote:
> On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > Я попробовал перетащить наш rpm на более живой beecrypt.
> > 
> > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > Наверняка что-нибудь сломано.
> > 
> > Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> > Посмотрите, пожалуйста.
> > 
> > debuginfo теперь (с новым beecrypt) похож на рабочий. Потребовалось немного
> > напильника. И, конечно, ещё понадобиться, но для proof of concept сойдёт.
> > Смотрите ветку debuginfo у меня в git.
> В /people/wrar/packages/hello.git в ветке debug лежит спек с добавленными
> ровно двумя строчками:
> 
> %def_enable debug (чтоб собиралось с -g)
> %debug_package (чтоб создавался дебаг-пакет)
> 
> Создался пакет hello-debug с таким содержимым:
> 
> drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/lib/debug/.build-id
> drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/lib/debug/.build-id/36
> lrwxrwxrwx    1 root    root               21 Авг  7 15:24 /usr/lib/debug/.build-id/36/515c96c9c09363cd0fbe9156e2926013a087bd -> ../../../../bin/hello
> lrwxrwxrwx    1 root    root               25 Авг  7 15:24 /usr/lib/debug/.build-id/36/515c96c9c09363cd0fbe9156e2926013a087bd.debug -> ../../usr/bin/hello.debug
> drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/lib/debug/usr
> drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/lib/debug/usr/bin
> -rwxr-xr-x    1 root    root            26780 Авг  7 15:24 /usr/lib/debug/usr/bin/hello.debug
> drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/src/debug/hello-2.4
> drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib
> drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib
> -rw-r--r--    1 root    root             3050 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/close-stream.c
> -rw-r--r--    1 root    root             4522 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/closeout.c
> -rw-r--r--    1 root    root              856 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/exitfail.c
> -rw-r--r--    1 root    root              759 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/exitfail.h
> -rw-r--r--    1 root    root            22370 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/quotearg.c
> -rw-r--r--    1 root    root            11981 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/quotearg.h
> -rw-r--r--    1 root    root             1322 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/xalloc-die.c
> -rw-r--r--    1 root    root             8152 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/xalloc.h
> -rw-r--r--    1 root    root             3327 Авг  7 15:24 /usr/src/debug/hello-2.4/gnulib/lib/xmalloc.c
> drwxr-xr-x    2 root    root                0 Авг  7 15:24 /usr/src/debug/hello-2.4/src
> -rw-r--r--    1 root    root             5774 Авг  7 15:24 /usr/src/debug/hello-2.4/src/hello.c
> 
> У него, кстати, нет зависимостей ни на что, включая главный пакет.

Зависимость на /usr/bin/hello или содержащий этот файл пакет, наверное,
всё же есть?
Хорошо бы, конечно, поставить зависимость с %version-%release, только 
для того, чтобы узнать имя пакета(ов), потребуются специальные усилия.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

On Sat, Aug 07, 2010 at 05:57:37PM +0400, Dmitry V. Levin wrote:
> Зависимость на /usr/bin/hello или содержащий этот файл пакет, наверное,
> всё же есть?
$ rpm -qR hello-debug 
rpmlib(PayloadIsLzma)  

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<dubrsl> Народ, скажите, вот дали диски Barracuda ES.2. Там джампер есть. Типа
         если стоит, то Limit to 1.5Gb/s operation. Хочу снять. Ничего не
         сломается?
<hiddenman> dubrsl: рожа треснет

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On Sat, Aug 07, 2010 at 02:05:59PM +0300, Kirill A. Shutemov wrote:
> > %debug_package (чтоб создавался дебаг-пакет)
> Теперь он всегда создаётся. --disable debug_packages что б выключить.
Создаётся только для основного пакета, что логично, и даже с ручным
использованием теперешнего макроса по-другому не сделать.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

Не надо abisuite выкидывать. Он нормальный и я им _пользуюсь_
		-- rider in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

On Sat, Aug 07, 2010 at 08:09:58PM +0600, Andrey Rahmatullin wrote:
> On Sat, Aug 07, 2010 at 05:57:37PM +0400, Dmitry V. Levin wrote:
> > Зависимость на /usr/bin/hello или содержащий этот файл пакет, наверное,
> > всё же есть?
> $ rpm -qR hello-debug 
> rpmlib(PayloadIsLzma)  
Там в макросе для этого пакета ставится AutoReqProv: 0

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

А почему ссылка на xorg-x11-6.8.2-alt5.src.rpm находится в
SRPMS.kernel? Или у нас уже GUI в ядре? ;)
		-- mrkooll in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On Sat, Aug 07, 2010 at 02:05:59PM +0300, Kirill A. Shutemov wrote:
> at@, поможешь? Наверно нужно изобразить конфликты на пакеты собираемые из
> того же спека с версией отличной от %version-%release.

У меня сейчас о другом голова болит, хочется доделать soname
set-dependencies.  Кажется Там был какой-то build-id, как раз для
изображения конфликтов.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Michael Shigorin]

On Sat, Aug 07, 2010 at 02:05:59PM +0300, Kirill A. Shutemov wrote:
> > %def_enable debug (чтоб собиралось с -g)
> Теперь -g всегда есть в %optflags_default

Это временно?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

On Sat, Aug 07, 2010 at 09:38:32PM +0300, Michael Shigorin wrote:
> > > %def_enable debug (чтоб собиралось с -g)
> > Теперь -g всегда есть в %optflags_default
> Это временно?
Нет, это было частью изначального предложения, это так в других
дистрибутивах и это обязательно для осмысленности дебаг-пакетов.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<|Drool|> Самурай в собственном сакэ

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Michael Shigorin]

On Sun, Aug 08, 2010 at 12:41:58AM +0600, Andrey Rahmatullin wrote:
> > > > %def_enable debug (чтоб собиралось с -g)
> > > Теперь -g всегда есть в %optflags_default
> > Это временно?
> Нет, это было частью изначального предложения, это так в других
> дистрибутивах и это обязательно для осмысленности дебаг-пакетов.

А, так вот почему RHEL6 beta так тормозит...

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

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

On Sat, Aug 07, 2010 at 09:50:24PM +0300, Michael Shigorin wrote:
> А, так вот почему RHEL6 beta так тормозит...
Добавление -g не означает убирания -O2.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

Поздно, сегодня все равно будет новая версия.
		-- ldv in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Led]

On Saturday 07 August 2010 21:50:24 Michael Shigorin wrote:
> On Sun, Aug 08, 2010 at 12:41:58AM +0600, Andrey Rahmatullin wrote:
> > > > > %def_enable debug (чтоб собиралось с -g)
> > > >
> > > > Теперь -g всегда есть в %optflags_default
> > >
> > > Это временно?
> >
> > Нет, это было частью изначального предложения, это так в других
> > дистрибутивах и это обязательно для осмысленности дебаг-пакетов.
>
> А, так вот почему RHEL6 beta так тормозит...

А тебе не кажеться, что именно "beta" и должна быть с debug-info?

-- 
Led

Re: [devel] автогенерация debug-пакетов в rpm

[Kirill A. Shutemov]

On Sat, Aug 07, 2010 at 09:50:24PM +0300, Michael Shigorin wrote:
> On Sun, Aug 08, 2010 at 12:41:58AM +0600, Andrey Rahmatullin wrote:
> > > > > %def_enable debug (чтоб собиралось с -g)
> > > > Теперь -g всегда есть в %optflags_default
> > > Это временно?
> > Нет, это было частью изначального предложения, это так в других
> > дистрибутивах и это обязательно для осмысленности дебаг-пакетов.
> 
> А, так вот почему RHEL6 beta так тормозит...

Миша, у тебя есть основания полагать, что -g серьёзно сказывается на
производительности? Желательно с use-case'ом.

Можно сразу на http://gcc.gnu.org/bugzilla/

-- 
 Kirill A. Shutemov

Re: [devel] автогенерация debug-пакетов в rpm

[Michael Shigorin]

On Sat, Aug 07, 2010 at 10:35:40PM +0300, Kirill A. Shutemov wrote:
> > > > > > %def_enable debug (чтоб собиралось с -g)
> > > > > Теперь -g всегда есть в %optflags_default
> > > > Это временно?
> > > Нет, это было частью изначального предложения, это так в других
> > > дистрибутивах и это обязательно для осмысленности дебаг-пакетов.
> > А, так вот почему RHEL6 beta так тормозит...
> Миша, у тебя есть основания полагать, что -g серьёзно
> сказывается на производительности? Желательно с use-case'ом.

Насколько помнил, -g выключало оптимизацию -- погуглил после
подсказки wrar@, нашёл про текущий дефолт -g -O2 и немного
успокоился.

Но факт, по сравнению с сизифом в одинаковых условиях --
тормозит.

> Можно сразу на http://gcc.gnu.org/bugzilla/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Sat, Aug 07, 2010 at 10:44:25PM +0300, Michael Shigorin wrote:
> Но факт, по сравнению с сизифом в одинаковых условиях --
> тормозит.
Ты уверен, что даже в RHEL5 -g не был включен?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<r1d3r> hiddenman: ты вообще что мне хочешь доказать ? что у меня странные
        взгляды на диалоги открытия файлов ?
<r1d3r> hiddenman: или что Linux не дозрел до масс ?
<hiddenman> я жду, когда ты покончишь с собой. я ж какбэ Марвин. ты просто об
            этом не знаешь. а raorn вот знает, поэтому молчит

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Michael Shigorin]

On Sun, Aug 08, 2010 at 01:45:34AM +0600, Andrey Rahmatullin wrote:
> > Но факт, по сравнению с сизифом в одинаковых условиях --
> > тормозит.
> Ты уверен, что даже в RHEL5 -g не был включен?

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] автогенерация debug-пакетов в rpm

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Sat, Aug 07, 2010 at 10:29:33PM +0300, Led wrote:

L> А тебе не кажеться, что именно "beta" и должна быть с debug-info?

Это зависит от софта.

Для библиотек debug-info нужна.

Для приложений -- зависит от ситуации. Скажем для тех же warzone или
nexuiz -- не нужна. Ибо там скорость несопоставимо важнее надежности, и
надо выкручивать всю оптимизацию по максимуму.

А вот Asterisk несмотря ни на что я бы хотел видеть с debug-info. Ибо если
упадет, то нужно иметь возможность быстро отлаживать (вплоть до
автоматизации разбора корки и отправки админу на мыло backtrace).

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On Sat, Aug 07, 2010 at 08:11:43PM +0600, Andrey Rahmatullin wrote:

AR> Создаётся только для основного пакета, что логично, 

Т.е. если пакет мелко порезан на подпакеты -- то облом, и надо собирать
отдельными пакетами?

/me с грустью думает о том, как придется собирать Asterisk чтобы иметь
debug info :(

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

On Sun, Aug 08, 2010 at 08:56:46AM +0400, Денис Смирнов wrote:
> AR> Создаётся только для основного пакета, что логично, 
> Т.е. если пакет мелко порезан на подпакеты -- то облом, и надо собирать
> отдельными пакетами?
Нет, я уже догадался и проверил, что догадка верна: в один дебаг-пакет
кладутся символы для всех бинарных подпакетов.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<ab> dottedmag: между прочим, это яйцо с позапрошлого века на здании Института
     Логики красуется
<aen_> ab: "здание Института Логики" -- это круто ! :-)))
<ab> aen_: ;-))
<Lost> ab: этот институт изучает, что было раньше, курица или яйцо?
<dottedmag> ab: да хоть на входе в Сорбонну. Что из того?
<ab> dottedmag: а, ты же наверное не видел и не был там. Это место, где
     сидит(-ел) ALT Linux
<aen_> ab: сидел, сидит и будет сидеть
<aen_> Lost: Институт Логики -- это такой самый лучший институт, сидит в ин-те
       философии РАН
<aen_> Lost: а ALTLinux сидит в помещении ин-то Логики
<aen_> Lost: дружим мы :-)
 * ab горд. Он ведь работал в Институте Логики под руководством самого aen_ :-)
<Lost> они с вами делятся логикой, а вы с ними - линуксом?
<aen_> Lost: у нас все общее, и логика, и линукс

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

On Sun, Aug 08, 2010 at 01:27:53PM +0600, Andrey Rahmatullin wrote:

AR> Нет, я уже догадался и проверил, что догадка верна: в один дебаг-пакет
AR> кладутся символы для всех бинарных подпакетов.

Отлично! Спасибо.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Kirill A. Shutemov]

On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> On Thu, Aug 05, 2010 at 09:00:00PM +0400, Dmitry V. Levin wrote:
> > Hi,
> > 
> > On Sun, May 03, 2009 at 11:55:14PM +0600, Andrey Rahmatullin wrote:
> > > On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
> > > > В Fedora это реализовано следующим образом:
> > > > 
> > > > в конце секции %install запускается макрос
> > > > 
> > > > %{?__debug_package:%{__debug_install_post}}, который генерит
> > > > %дополнительный пакет debug и вызывает для формирования файлов в нем
> > > >  скрипт find-debuginfo.sh.
> > > Proof of concept тут:
> > > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo
> > > Основано на rpm 5.1.9. debugedit падает на hashFunctionContextDigest, т.к.
> > > в нашем почти прошловековом beecrypt у него другая сигнатура.
> > 
> > Может быть, лучше собрать утилиту debugedit отдельно от rpm?
> 
> Я попробовал перетащить наш rpm на более живой beecrypt.
> 
> Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> rpm притворяется, что работает. Нужно хорошенько его потестировать.
> Наверняка что-нибудь сломано.
> 
> Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> Посмотрите, пожалуйста.

Дима, Алексей, немогли бы вы посмотерть на мой патч. Хотелось бы, всё
таки, переехать на более новый beecrypt.

-- 
 Kirill A. Shutemov

[devel] base2 <-> base62

[Alexey Tourbin]

vsu:
> > Нужно учитывать, что значение 61 (Z) может идти два или более раза
> > подряд.  Например, следующий bitv[] кодируется в "ZZ1".  Это значит,
> > что мы не можем сразу же распаковать "Z", посмотрев на следующую букву.
> 																	
> На самом деле можем, если упаковывать биты в буквы, начиная со
> старшего; тогда, прочитав после "Z" ещё "Z", которое в данном случае
> обозначает 1111(01|10|11), можно использовать старшие 11, не
> заглядывая далее.

I didn't quite get your idea.  Can't you elaborate please (possibly
using the code below)?

But I've got another (possibly similar) idea.  You see, for values
61, 62, and 63 two hight bits are set (to "11").  Other high bits
combinations, which are "00", "01", and "10", can be used to amend
previous value, which is what we need.

So the code goes like this.

    #include <stdio.h>
    #include <stdlib.h>
    #include <assert.h>

    #define xrealloc realloc
    #define AUTO_REALLOC(ptr, size, delta) \
	do { \
	    if (((size) & ((delta) - 1)) == 0) \
		ptr = xrealloc((ptr), sizeof(*(ptr)) * ((size) + (delta))); \
	} while (0)


    struct uintcv {
	unsigned int c;
	unsigned int *v;
    };

    struct charcv {
	unsigned int c;
	char *v;
    };

    const char *bits_to_base62(int bitc, char bitv[])
    {
	int base62c = 0;
	char *base62v = NULL;
	void put_char(int c)
	{
	    AUTO_REALLOC(base62v, base62c, 1024);
	    base62v[base62c++] = c;
	}
	void put_digit(int c)
	{
	    if (c < 10)
		put_char(c + '0');
	    else if (c < 36)
		put_char(c - 10 + 'a');
	    else if (c < 62)
		put_char(c - 36 + 'A');
	}
	int i;
	int bits6 = 0;
	int num6b = 0;
	for (i = 0; i < bitc; i++) {
	    if (bits6 < 6)
		num6b |= bitv[i] << (5 - bits6++);
	    if (bits6 == 6) {
		switch (num6b) {
		case 61:
		    put_digit(61);
		    // extra "00" high bits
		    bits6 = 2;
		    num6b = 0;
		    break;
		case 62:
		    put_digit(61);
		    // extra "01" hight bits
		    bits6 = 2;
		    num6b = 16;
		    break;
		case 63:
		    put_digit(61);
		    // extra "10" hight bits
		    bits6 = 2;
		    num6b = 32;
		    break;
		default:
		    assert(num6b < 61);
		    put_digit(num6b);
		    bits6 = 0;
		    num6b = 0;
		    break;
		}
	    }
	}
	if (bits6) {
	    assert(num6b < 61);
	    put_digit(num6b);
	}
	put_char(0);

	return base62v;
    }

    void base62_to_bits(const char *base62, struct charcv *bits)
    {
	int c2d(int c)
	{
	    if (c >= '0' && c <= '9')
		return c - '0';
	    if (c >= 'a' && c <= 'z')
		return c - 'a' + 10;
	    if (c >= 'A' && c <= 'Z')
		return c - 'A' + 36;
	    return -1;
	}

	void put_bit(char bit)
	{
	    AUTO_REALLOC(bits->v, bits->c, 1024);
	    bits->v[bits->c++] = bit;
	}

	void put6bits(int c)
	{
	    put_bit((c >> 5) & 1);
	    put_bit((c >> 4) & 1);
	    put_bit((c >> 3) & 1);
	    put_bit((c >> 2) & 1);
	    put_bit((c >> 1) & 1);
	    put_bit((c >> 0) & 1);
	}

	void put4bits(int c)
	{
	    put_bit((c >> 3) & 1);
	    put_bit((c >> 2) & 1);
	    put_bit((c >> 1) & 1);
	    put_bit((c >> 0) & 1);
	}

	int c;
	while ((c = *base62++)) {
	    int d = c2d(c);
	    assert(d >= 0);
	    if (d == 61) {
		c = *base62++;
		assert(c);
		d = c2d(c);
		assert(d >= 0);
		switch (d & 48) {
		case 0:
		    put6bits(61);
		    break;
		case 16:
		    put6bits(62);
		    break;
		case 32:
		    put6bits(63);
		    break;
		default:
		    assert(0);
		    break;
		}
		put4bits(d);
	    }
	    else {
		put6bits(d);
	    }
	}
	return;

    }

    int main()
    {
	char bitv[] = {
	    1, 1, 1, 1, 1, 1,
	    1, 1, 1, 1, 1, 0,
	};
	int bitc = sizeof(bitv)/sizeof(*bitv);
	const char *base62 = bits_to_base62(bitc, bitv);
	fprintf(stderr, "base62=%s\n", base62);

	int i;
	struct charcv bits = {0};
	base62_to_bits(base62, &bits);
	fprintf(stderr, "bitc=%d bits.c=%d\n", bitc, bits.c);
	assert(bitc <= bits.c);
	for (i = 0; i < bitc; i++)
	    assert(bitv[i] == bits.v[i]);

	return 0;
    }

Note that there is still a possibility not to deal with high bits, e.g.
1) Let Z = 11111111; or
2) Let special value be 0 = 000000.

So, after all, what do you think?  Isn't there a better way to handle
base62 somehow?  Or shall we resort to base64?  We'll need it soon.
The main requirement is that the decoder be simple and robust (since
it is going to be executed countless times during e.g. unmets check).

Re: [devel] автогенерация debug-пакетов в rpm

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

On Tue, Aug 10, 2010 at 02:14:53AM +0300, Kirill A. Shutemov wrote:
> On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > On Thu, Aug 05, 2010 at 09:00:00PM +0400, Dmitry V. Levin wrote:
> > > On Sun, May 03, 2009 at 11:55:14PM +0600, Andrey Rahmatullin wrote:
> > > > On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
> > > > > В Fedora это реализовано следующим образом:
> > > > > 
> > > > > в конце секции %install запускается макрос
> > > > > 
> > > > > %{?__debug_package:%{__debug_install_post}}, который генерит
> > > > > %дополнительный пакет debug и вызывает для формирования файлов в нем
> > > > >  скрипт find-debuginfo.sh.
> > > > Proof of concept тут:
> > > > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo
> > > > Основано на rpm 5.1.9. debugedit падает на hashFunctionContextDigest, т.к.
> > > > в нашем почти прошловековом beecrypt у него другая сигнатура.
> > > 
> > > Может быть, лучше собрать утилиту debugedit отдельно от rpm?
> > 
> > Я попробовал перетащить наш rpm на более живой beecrypt.
> > 
> > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > Наверняка что-нибудь сломано.

Как будем тестировать?  У beecrypt тесты есть?  А у rpm?

> > Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> > Посмотрите, пожалуйста.

У старого libbeecrypt нет других клиентов.
Думаю что такой переезд пройдёт нормально.

> Дима, Алексей, немогли бы вы посмотерть на мой патч.

К сожалению, смотреть придётся не на патч, а на beecrypt.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] автогенерация debug-пакетов в rpm

[Kirill A. Shutemov]

On Wed, Aug 11, 2010 at 04:28:49AM +0400, Dmitry V. Levin wrote:
> On Tue, Aug 10, 2010 at 02:14:53AM +0300, Kirill A. Shutemov wrote:
> > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > > On Thu, Aug 05, 2010 at 09:00:00PM +0400, Dmitry V. Levin wrote:
> > > > On Sun, May 03, 2009 at 11:55:14PM +0600, Andrey Rahmatullin wrote:
> > > > > On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
> > > > > > В Fedora это реализовано следующим образом:
> > > > > > 
> > > > > > в конце секции %install запускается макрос
> > > > > > 
> > > > > > %{?__debug_package:%{__debug_install_post}}, который генерит
> > > > > > %дополнительный пакет debug и вызывает для формирования файлов в нем
> > > > > >  скрипт find-debuginfo.sh.
> > > > > Proof of concept тут:
> > > > > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo
> > > > > Основано на rpm 5.1.9. debugedit падает на hashFunctionContextDigest, т.к.
> > > > > в нашем почти прошловековом beecrypt у него другая сигнатура.
> > > > 
> > > > Может быть, лучше собрать утилиту debugedit отдельно от rpm?
> > > 
> > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > 
> > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > Наверняка что-нибудь сломано.
> 
> Как будем тестировать?  У beecrypt тесты есть?

Есть. Добавил в спеку запуск.

> А у rpm?

Я не вижу. Иммет ли смысл пересобрать Сизиф с патченым rpm'ом?

> > > Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> > > Посмотрите, пожалуйста.
> 
> У старого libbeecrypt нет других клиентов.
> Думаю что такой переезд пройдёт нормально.
> 
> > Дима, Алексей, немогли бы вы посмотерть на мой патч.
> 
> К сожалению, смотреть придётся не на патч, а на beecrypt.

А что ты смотришь в таких случаях? Неужели вычитываешь сплошняком?

-- 
 Kirill A. Shutemov

Re: [devel] автогенерация debug-пакетов в rpm

[Kirill A. Shutemov]

On Wed, Aug 11, 2010 at 04:11:37AM +0300, Kirill A. Shutemov wrote:
> On Wed, Aug 11, 2010 at 04:28:49AM +0400, Dmitry V. Levin wrote:
> > On Tue, Aug 10, 2010 at 02:14:53AM +0300, Kirill A. Shutemov wrote:
> > > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > > > On Thu, Aug 05, 2010 at 09:00:00PM +0400, Dmitry V. Levin wrote:
> > > > > On Sun, May 03, 2009 at 11:55:14PM +0600, Andrey Rahmatullin wrote:
> > > > > > On Tue, Apr 21, 2009 at 06:24:53PM +0400, Pavlov Konstantin wrote:
> > > > > > > В Fedora это реализовано следующим образом:
> > > > > > > 
> > > > > > > в конце секции %install запускается макрос
> > > > > > > 
> > > > > > > %{?__debug_package:%{__debug_install_post}}, который генерит
> > > > > > > %дополнительный пакет debug и вызывает для формирования файлов в нем
> > > > > > >  скрипт find-debuginfo.sh.
> > > > > > Proof of concept тут:
> > > > > > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo
> > > > > > Основано на rpm 5.1.9. debugedit падает на hashFunctionContextDigest, т.к.
> > > > > > в нашем почти прошловековом beecrypt у него другая сигнатура.
> > > > > 
> > > > > Может быть, лучше собрать утилиту debugedit отдельно от rpm?
> > > > 
> > > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > > 
> > > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > > Наверняка что-нибудь сломано.
> > 
> > Как будем тестировать?  У beecrypt тесты есть?
> 
> Есть. Добавил в спеку запуск.
> 
> > А у rpm?
> 
> Я не вижу. Иммет ли смысл пересобрать Сизиф с патченым rpm'ом?
> 
> > > > Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> > > > Посмотрите, пожалуйста.
> > 
> > У старого libbeecrypt нет других клиентов.
> > Думаю что такой переезд пройдёт нормально.
> > 
> > > Дима, Алексей, немогли бы вы посмотерть на мой патч.
> > 
> > К сожалению, смотреть придётся не на патч, а на beecrypt.

Кстати, есть ещё вариант: в rpm, который не rpm5 вообще отказались от
beecrypt в пользу NSS. Можно попробовать посмотреть в эту сторону, если
интересно.

> 
> А что ты смотришь в таких случаях? Неужели вычитываешь сплошняком?
> 
> -- 
>  Kirill A. Shutemov
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
 Kirill A. Shutemov

Re: [devel] автогенерация debug-пакетов в rpm

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Wed, Aug 11, 2010 at 04:11:37AM +0300, Kirill A. Shutemov wrote:
> On Wed, Aug 11, 2010 at 04:28:49AM +0400, Dmitry V. Levin wrote:
> > On Tue, Aug 10, 2010 at 02:14:53AM +0300, Kirill A. Shutemov wrote:
> > > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
[...]
> > > > > Может быть, лучше собрать утилиту debugedit отдельно от rpm?
> > > > 
> > > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > > 
> > > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > > Наверняка что-нибудь сломано.
> > 
> > Как будем тестировать?  У beecrypt тесты есть?
> 
> Есть. Добавил в спеку запуск.

А в федорном спеке этого не было?

> > А у rpm?
> 
> Я не вижу. Иммет ли смысл пересобрать Сизиф с патченым rpm'ом?

С какой целью?

> > > > Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> > > > Посмотрите, пожалуйста.
> > 
> > У старого libbeecrypt нет других клиентов.
> > Думаю что такой переезд пройдёт нормально.
> > 
> > > Дима, Алексей, немогли бы вы посмотерть на мой патч.
> > 
> > К сожалению, смотреть придётся не на патч, а на beecrypt.
> 
> А что ты смотришь в таких случаях? Неужели вычитываешь сплошняком?

Для начала надо понять, как за эти годы поменялся API.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] перевод rpm на свежий beecrypt

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> Я попробовал перетащить наш rpm на более живой beecrypt.
> 
> Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> rpm притворяется, что работает. Нужно хорошенько его потестировать.
> Наверняка что-нибудь сломано.

Можно пояснить причину выкидывания IS_LITTLE_ENDIAN в
http://git.altlinux.org/people/kas/packages/?p=rpm.git;a=commitdiff;h=4.0.4-alt98.40-1-g7b1dab3#patch2
?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] перевод rpm на свежий beecrypt

[Kirill A. Shutemov]

On Wed, Aug 11, 2010 at 07:02:15PM +0400, Dmitry V. Levin wrote:
> On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > Я попробовал перетащить наш rpm на более живой beecrypt.
> > 
> > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > Наверняка что-нибудь сломано.
> 
> Можно пояснить причину выкидывания IS_LITTLE_ENDIAN в
> http://git.altlinux.org/people/kas/packages/?p=rpm.git;a=commitdiff;h=4.0.4-alt98.40-1-g7b1dab3#patch2
> ?

После первой попытки портирования rpm начал ругяться на несоответвие
md5-суммы в устанавливаемых пакетах. Расследование вывело на этот кусок
кода.

Решение было найдено в upstream'е:

http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=d4538f2d0da92317bbfeb37b1c7513350763b0f4

Похоже, начиная с версии 3, beecrypt умеет сам разбираться с endianness.

-- 
 Kirill A. Shutemov

Re: [devel] перевод rpm на свежий beecrypt

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

On Wed, Aug 11, 2010 at 10:08:15PM +0300, Kirill A. Shutemov wrote:
> On Wed, Aug 11, 2010 at 07:02:15PM +0400, Dmitry V. Levin wrote:
> > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > 
> > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > Наверняка что-нибудь сломано.
> > 
> > Можно пояснить причину выкидывания IS_LITTLE_ENDIAN в
> > http://git.altlinux.org/people/kas/packages/?p=rpm.git;a=commitdiff;h=4.0.4-alt98.40-1-g7b1dab3#patch2
> > ?
> 
> После первой попытки портирования rpm начал ругяться на несоответвие
> md5-суммы в устанавливаемых пакетах. Расследование вывело на этот кусок
> кода.
> 
> Решение было найдено в upstream'е:
> 
> http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=d4538f2d0da92317bbfeb37b1c7513350763b0f4
> 
> Похоже, начиная с версии 3, beecrypt умеет сам разбираться с endianness.

Обрати внимание, uint32 там заменён не на uint32_t.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] перевод rpm на свежий beecrypt

[Kirill A. Shutemov]

On Wed, Aug 11, 2010 at 11:34:47PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 11, 2010 at 10:08:15PM +0300, Kirill A. Shutemov wrote:
> > On Wed, Aug 11, 2010 at 07:02:15PM +0400, Dmitry V. Levin wrote:
> > > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > > 
> > > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > > Наверняка что-нибудь сломано.
> > > 
> > > Можно пояснить причину выкидывания IS_LITTLE_ENDIAN в
> > > http://git.altlinux.org/people/kas/packages/?p=rpm.git;a=commitdiff;h=4.0.4-alt98.40-1-g7b1dab3#patch2
> > > ?
> > 
> > После первой попытки портирования rpm начал ругяться на несоответвие
> > md5-суммы в устанавливаемых пакетах. Расследование вывело на этот кусок
> > кода.
> > 
> > Решение было найдено в upstream'е:
> > 
> > http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=d4538f2d0da92317bbfeb37b1c7513350763b0f4
> > 
> > Похоже, начиная с версии 3, beecrypt умеет сам разбираться с endianness.
> 
> Обрати внимание, uint32 там заменён не на uint32_t.

Fixed ориентируясь на upstream. Обе ветки запушены с -f.

python'овские binding'и, похоже, требуют больше внимания. Я не курсе как
их тестировать, я в этом ни бум-бум. Кстати, они, как я понял, тоже сильно
отстали от upstream'а. :(

-- 
 Kirill A. Shutemov

Re: [devel] автогенерация debug-пакетов в rpm

[Kirill A. Shutemov]

On Wed, Aug 11, 2010 at 05:52:46PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 11, 2010 at 04:11:37AM +0300, Kirill A. Shutemov wrote:
> > On Wed, Aug 11, 2010 at 04:28:49AM +0400, Dmitry V. Levin wrote:
> > > On Tue, Aug 10, 2010 at 02:14:53AM +0300, Kirill A. Shutemov wrote:
> > > > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> [...]
> > > > > > Может быть, лучше собрать утилиту debugedit отдельно от rpm?
> > > > > 
> > > > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > > > 
> > > > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > > > Наверняка что-нибудь сломано.
> > > 
> > > Как будем тестировать?  У beecrypt тесты есть?
> > 
> > Есть. Добавил в спеку запуск.
> 
> А в федорном спеке этого не было?

Неа.

http://cvs.fedoraproject.org/viewvc/devel/beecrypt/beecrypt.spec?view=markup

> > > А у rpm?
> > 
> > Я не вижу. Иммет ли смысл пересобрать Сизиф с патченым rpm'ом?
> 
> С какой целью?

Думал ты придумаешь :) Так, для очистки совести. 

> > > > > Ещё я не уверен, правильно ли сделал переезд на новый soname libbeecrypt.
> > > > > Посмотрите, пожалуйста.
> > > 
> > > У старого libbeecrypt нет других клиентов.
> > > Думаю что такой переезд пройдёт нормально.
> > > 
> > > > Дима, Алексей, немогли бы вы посмотерть на мой патч.
> > > 
> > > К сожалению, смотреть придётся не на патч, а на beecrypt.
> > 
> > А что ты смотришь в таких случаях? Неужели вычитываешь сплошняком?
> 
> Для начала надо понять, как за эти годы поменялся API.

Что думаешь насчёт NSS?

-- 
 Kirill A. Shutemov

Re: [devel] автогенерация debug-пакетов в rpm

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

On Thu, Aug 12, 2010 at 03:09:31AM +0300, Kirill A. Shutemov wrote:
> Что думаешь насчёт NSS?

Переехать на NSS сложнее, чем просто обновить beecrypt.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] перевод rpm на свежий beecrypt

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

On Thu, Aug 12, 2010 at 03:06:15AM +0300, Kirill A. Shutemov wrote:
> On Wed, Aug 11, 2010 at 11:34:47PM +0400, Dmitry V. Levin wrote:
> > On Wed, Aug 11, 2010 at 10:08:15PM +0300, Kirill A. Shutemov wrote:
> > > On Wed, Aug 11, 2010 at 07:02:15PM +0400, Dmitry V. Levin wrote:
> > > > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > > > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > > > 
> > > > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > > > Наверняка что-нибудь сломано.
> > > > 
> > > > Можно пояснить причину выкидывания IS_LITTLE_ENDIAN в
> > > > http://git.altlinux.org/people/kas/packages/?p=rpm.git;a=commitdiff;h=4.0.4-alt98.40-1-g7b1dab3#patch2
> > > > ?
> > > 
> > > После первой попытки портирования rpm начал ругяться на несоответвие
> > > md5-суммы в устанавливаемых пакетах. Расследование вывело на этот кусок
> > > кода.
> > > 
> > > Решение было найдено в upstream'е:
> > > 
> > > http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=d4538f2d0da92317bbfeb37b1c7513350763b0f4
> > > 
> > > Похоже, начиная с версии 3, beecrypt умеет сам разбираться с endianness.
> > 
> > Обрати внимание, uint32 там заменён не на uint32_t.
> 
> Fixed ориентируясь на upstream. Обе ветки запушены с -f.

Успеем отправить в Сизиф перед еженедельной тестовой пересборкой?

> python'овские binding'и, похоже, требуют больше внимания. Я не курсе как
> их тестировать, я в этом ни бум-бум.

Например, запустить arepo.

> Кстати, они, как я понял, тоже сильно отстали от upstream'а. :(

Да, они ведь сильно привязаны к rpm.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] перевод rpm на свежий beecrypt

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Thu, Aug 12, 2010 at 08:22:49PM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 12, 2010 at 03:06:15AM +0300, Kirill A. Shutemov wrote:
> > On Wed, Aug 11, 2010 at 11:34:47PM +0400, Dmitry V. Levin wrote:
> > > On Wed, Aug 11, 2010 at 10:08:15PM +0300, Kirill A. Shutemov wrote:
> > > > On Wed, Aug 11, 2010 at 07:02:15PM +0400, Dmitry V. Levin wrote:
> > > > > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > > > > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > > > > 
> > > > > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > > > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > > > > Наверняка что-нибудь сломано.
> > > > > 
> > > > > Можно пояснить причину выкидывания IS_LITTLE_ENDIAN в
> > > > > http://git.altlinux.org/people/kas/packages/?p=rpm.git;a=commitdiff;h=4.0.4-alt98.40-1-g7b1dab3#patch2
> > > > > ?
> > > > 
> > > > После первой попытки портирования rpm начал ругяться на несоответвие
> > > > md5-суммы в устанавливаемых пакетах. Расследование вывело на этот кусок
> > > > кода.
> > > > 
> > > > Решение было найдено в upstream'е:
> > > > 
> > > > http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=d4538f2d0da92317bbfeb37b1c7513350763b0f4
> > > > 
> > > > Похоже, начиная с версии 3, beecrypt умеет сам разбираться с endianness.
> > > 
> > > Обрати внимание, uint32 там заменён не на uint32_t.
> > 
> > Fixed ориентируясь на upstream. Обе ветки запушены с -f.
> 
> Успеем отправить в Сизиф перед еженедельной тестовой пересборкой?

Я отправил сам.  На самом деле наш rpm использует beecrypt в очень
незначительном объёме, в основном полагаясь на gpg(1).


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] перевод rpm на свежий beecrypt

[Kirill A. Shutemov]

On Fri, Aug 13, 2010 at 01:07:16AM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 12, 2010 at 08:22:49PM +0400, Dmitry V. Levin wrote:
> > On Thu, Aug 12, 2010 at 03:06:15AM +0300, Kirill A. Shutemov wrote:
> > > On Wed, Aug 11, 2010 at 11:34:47PM +0400, Dmitry V. Levin wrote:
> > > > On Wed, Aug 11, 2010 at 10:08:15PM +0300, Kirill A. Shutemov wrote:
> > > > > On Wed, Aug 11, 2010 at 07:02:15PM +0400, Dmitry V. Levin wrote:
> > > > > > On Sat, Aug 07, 2010 at 06:29:08AM +0300, Kirill A. Shutemov wrote:
> > > > > > > Я попробовал перетащить наш rpm на более живой beecrypt.
> > > > > > > 
> > > > > > > Обновлённый beecrypt и патченый rpm (ветка beecrypt) лежит у меня в git.
> > > > > > > rpm притворяется, что работает. Нужно хорошенько его потестировать.
> > > > > > > Наверняка что-нибудь сломано.
> > > > > > 
> > > > > > Можно пояснить причину выкидывания IS_LITTLE_ENDIAN в
> > > > > > http://git.altlinux.org/people/kas/packages/?p=rpm.git;a=commitdiff;h=4.0.4-alt98.40-1-g7b1dab3#patch2
> > > > > > ?
> > > > > 
> > > > > После первой попытки портирования rpm начал ругяться на несоответвие
> > > > > md5-суммы в устанавливаемых пакетах. Расследование вывело на этот кусок
> > > > > кода.
> > > > > 
> > > > > Решение было найдено в upstream'е:
> > > > > 
> > > > > http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=d4538f2d0da92317bbfeb37b1c7513350763b0f4
> > > > > 
> > > > > Похоже, начиная с версии 3, beecrypt умеет сам разбираться с endianness.
> > > > 
> > > > Обрати внимание, uint32 там заменён не на uint32_t.
> > > 
> > > Fixed ориентируясь на upstream. Обе ветки запушены с -f.
> > 
> > Успеем отправить в Сизиф перед еженедельной тестовой пересборкой?
> 
> Я отправил сам.  На самом деле наш rpm использует beecrypt в очень
> незначительном объёме, в основном полагаясь на gpg(1).

Отлично. Спасибо.

-- 
 Kirill A. Shutemov