[devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Michael Shigorin]

On Sun, Dec 13, 2009 at 05:13:56AM +0300, repocop@ wrote:
> 	1 NEW repocop-report added to the list
> httrack-3.43.7-alt1.1.x86_64	experimental	arch-dep-package-has-big-usr-share

Там пакету-то метр с сошкой, данные распаковываются в 2.4M -- надо?
(IMHO смысл теста в том, чтобы экономить _пакетные_ место/трафик
-- если /usr/share хорошо жмётся, смысла может просто не быть)

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

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Igor Vlasenko]

On Sun, Dec 13, 2009 at 04:43:27PM +0200, Michael Shigorin wrote:
> On Sun, Dec 13, 2009 at 05:13:56AM +0300, repocop@ wrote:
> > 	1 NEW repocop-report added to the list
> > httrack-3.43.7-alt1.1.x86_64	experimental	arch-dep-package-has-big-usr-share
> 
> Там пакету-то метр с сошкой, данные распаковываются в 2.4M -- надо?
> (IMHO смысл теста в том, чтобы экономить _пакетные_ место/трафик
> -- если /usr/share хорошо жмётся, смысла может просто не быть)

Торг уместен :)
цифры в этом тесте взяты с Debian (Lintian).
текущее условие таково (в байтах).
WHERE usrshare > 2097152 OR (usrshare > 1048576 AND usrshare/total > 0.5);

Тест экспериментального уровня.

Как насчет поднять цифры в 2-3 раза и заодно повысить уровень теста до 
info?

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Michael Shigorin]

On Sun, Dec 13, 2009 at 06:45:04PM +0200, Igor Vlasenko wrote:
> > > 	1 NEW repocop-report added to the list
> > > httrack-3.43.7-alt1.1.x86_64	experimental	arch-dep-package-has-big-usr-share
> > Там пакету-то метр с сошкой, данные распаковываются в 2.4M -- надо?
> > (IMHO смысл теста в том, чтобы экономить _пакетные_ место/трафик
> > -- если /usr/share хорошо жмётся, смысла может просто не быть)
> Торг уместен :)

Собственно, тут не торг, а предлагается дополнительный фактор.

> цифры в этом тесте взяты с Debian (Lintian).
> текущее условие таково (в байтах).
> WHERE usrshare > 2097152 OR (usrshare > 1048576 AND usrshare/total > 0.5);

Предлагаю добавить размер пакета, о котором речь -- если он менее
мегабайта (или двух при поднятии вдвое лимита), не волноваться.

Обоснование: файловой системе конкретного хоста решительно всё
равно, развернулись ли мегабайты из $arch или noarch; это имеет
значение только для репозитория, а там объектом являются пакеты
(а не их содержимое).

> Тест экспериментального уровня.  Как насчет поднять цифры в 2-3
> раза и заодно повысить уровень теста до info?

Думаю, пока можно поднять вдвое -- опустить всегда успеется.

С отчётами repocop пока плохо то, что их очень много и глаз
замыливается -- возможно, выделение _самого_ важного (причём
необязательно на всех, а "top10 репокоповых претензий к моим
пакетам") помогло бы менее обречённо смотреть на то, что не
окучить патчгенами.

Хотя при желании и это уже есть:
http://sisyphus.ru/packager/mike/srpms?sort=status&order=desc

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

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Igor Vlasenko]

On Sun, Dec 13, 2009 at 07:42:06PM +0200, Michael Shigorin wrote:
> Предлагаю добавить размер пакета, о котором речь -- если он менее
> мегабайта (или двух при поднятии вдвое лимита), не волноваться.

Это выполнится, если поднять лимит вдвое.

> > Тест экспериментального уровня.  Как насчет поднять цифры в 2-3
> > раза и заодно повысить уровень теста до info?
> 
> Думаю, пока можно поднять вдвое -- опустить всегда успеется.

ok, сделаю, только немного попозже, так как
там еще просится выделить подтест для чистого /usr/share -
к нему патчгенератор написать можно.

> С отчётами repocop пока плохо то, что их очень много и глаз
> замыливается -- возможно, выделение _самого_ важного (причём
> необязательно на всех, а "top10 репокоповых претензий к моим
> пакетам") помогло бы менее обречённо смотреть на то, что не
> окучить патчгенами.
> 
> Хотя при желании и это уже есть:
> http://sisyphus.ru/packager/mike/srpms?sort=status&order=desc

Я тоже этим пользуюсь.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] big-and-nicely-compressible-usr-share

[Michael Shigorin]

On Sun, Dec 13, 2009 at 08:07:25PM +0200, Igor Vlasenko wrote:
> > Предлагаю добавить размер пакета, о котором речь -- если он менее
> > мегабайта (или двух при поднятии вдвое лимита), не волноваться.
> Это выполнится, если поднять лимит вдвое.

Нет, в смысле "добавить проверку размера пакета".  Или сложно?

> ok, сделаю, только немного попозже

Спасибо :)

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

Re: [devel] big-and-nicely-compressible-usr-share

[Igor Vlasenko]

On Sun, Dec 13, 2009 at 08:31:16PM +0200, Michael Shigorin wrote:
> On Sun, Dec 13, 2009 at 08:07:25PM +0200, Igor Vlasenko wrote:
> > > Предлагаю добавить размер пакета, о котором речь -- если он менее
> > > мегабайта (или двух при поднятии вдвое лимита), не волноваться.
> > Это выполнится, если поднять лимит вдвое.
> 
> Нет, в смысле "добавить проверку размера пакета".  Или сложно?
> 
> > ok, сделаю, только немного попозже
> 
> Спасибо :)

Сделал, повысил порог вдвое.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Igor Zubkov]

13 декабря 2009 г. 19:42 пользователь Michael Shigorin написал:
> Хотя при желании и это уже есть:
> http://sisyphus.ru/packager/mike/srpms?sort=status&order=desc

http://prometheus.altlinux.org/en/packager/mike/repocop

И покликай на package, status и test. Там сортировка работает. На js
прям в браузере. Я всё никак не придумаю как выделить это, что бы было
понятно что тут можно кликнуть и оно отсортирует табличку в браузере.

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] big-and-nicely-compressible-usr-share

[Michael Shigorin]

On Sun, Dec 13, 2009 at 08:45:25PM +0200, Igor Zubkov wrote:
> > Хотя при желании и это уже есть:
> > http://sisyphus.ru/packager/mike/srpms?sort=status&order=desc
> http://prometheus.altlinux.org/en/packager/mike/repocop
> И покликай на package, status и test. Там сортировка работает.

О!  А сделай <pre> для message, или оно одной строкой долетает?

Насчёт теста -- это в любом разе не fail, и если кому интересно,
то моё предложение действительно и для lintian.

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

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Igor Vlasenko]

On Sun, Dec 13, 2009 at 08:45:25PM +0200, Igor Zubkov wrote:
> 13 декабря 2009 г. 19:42 пользователь Michael Shigorin написал:
> > Хотя при желании и это уже есть:
> > http://sisyphus.ru/packager/mike/srpms?sort=status&order=desc
> 
> http://prometheus.altlinux.org/en/packager/mike/repocop
> 
> И покликай на package, status и test. Там сортировка работает. На js
> прям в браузере. Я всё никак не придумаю как выделить это, что бы было
> понятно что тут можно кликнуть и оно отсортирует табличку в браузере.

<pacкатываю губу>
Мне бы для полноты счастья чтобы на
http://prometheus.altlinux.org/en/packager/mike/srpms
клик по колонке repocop тоже сортировал
<закатываю губу>

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Igor Zubkov]

13 декабря 2009 г. 18:45 пользователь Igor Vlasenko написал:
> On Sun, Dec 13, 2009 at 04:43:27PM +0200, Michael Shigorin wrote:
>> On Sun, Dec 13, 2009 at 05:13:56AM +0300, repocop@ wrote:
>> >     1 NEW repocop-report added to the list
>> > httrack-3.43.7-alt1.1.x86_64        experimental    arch-dep-package-has-big-usr-share
>>
>> Там пакету-то метр с сошкой, данные распаковываются в 2.4M -- надо?
>> (IMHO смысл теста в том, чтобы экономить _пакетные_ место/трафик
>> -- если /usr/share хорошо жмётся, смысла может просто не быть)
>
> Торг уместен :)
> цифры в этом тесте взяты с Debian (Lintian).
> текущее условие таково (в байтах).
> WHERE usrshare > 2097152 OR (usrshare > 1048576 AND usrshare/total > 0.5);
>
> Тест экспериментального уровня.
>
> Как насчет поднять цифры в 2-3 раза и заодно повысить уровень теста до
> info?

Предлагаю для начала просто отключить тест.

И написать новый. С только одним правилом. Если данных в /usr/share/
больше 10 мегабайт, fail. И для такого надо пакета делать -common (или
-data или как-то ещё) noarch. Просто и сердито.

Тест могу и я написать если что. :)

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Igor Vlasenko]

On Sun, Dec 13, 2009 at 08:39:08PM +0200, Igor Zubkov wrote:
> > цифры в этом тесте взяты с Debian (Lintian).
> > текущее условие таково (в байтах).
> > WHERE usrshare > 2097152 OR (usrshare > 1048576 AND usrshare/total > 0.5);
> >
> > Тест экспериментального уровня.
> >
> > Как насчет поднять цифры в 2-3 раза и заодно повысить уровень теста до
> > info?
> 
> Предлагаю для начала просто отключить тест.
> 
> И написать новый. С только одним правилом. Если данных в /usr/share/
> больше 10 мегабайт, fail. И для такого надо пакета делать -common (или
> -data или как-то ещё) noarch. Просто и сердито.
> 
> Тест могу и я написать если что. :)

А почему бы им не сосуществовать на
разных уровнях? твой на fail, lintianовский на info.

Только для fail надо оформить --
написать обсудить и принять полиси.

Для experimantal/info такого не нужно.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Led]

On Wednesday 16 December 2009 17:32:41 Victor Forsyuk wrote:
> 2009/12/13 Igor Vlasenko <vlasenko@imath.kiev.ua>
>
> > On Sun, Dec 13, 2009 at 04:43:27PM +0200, Michael Shigorin wrote:
> > > On Sun, Dec 13, 2009 at 05:13:56AM +0300, repocop@ wrote:
> > > >     1 NEW repocop-report added to the list
> > > > httrack-3.43.7-alt1.1.x86_64        experimental
> >
> >  arch-dep-package-has-big-usr-share
> >
> > > Там пакету-то метр с сошкой, данные распаковываются в 2.4M -- надо?
> > > (IMHO смысл теста в том, чтобы экономить _пакетные_ место/трафик
> > > -- если /usr/share хорошо жмётся, смысла может просто не быть)
> >
> > Торг уместен :)
> > цифры в этом тесте взяты с Debian (Lintian).
> > текущее условие таково (в байтах).
> > WHERE usrshare > 2097152 OR (usrshare > 1048576 AND usrshare/total >
> > 0.5);
> >
> > Тест экспериментального уровня.
> >
> > Как насчет поднять цифры в 2-3 раза и заодно повысить уровень теста до
> > info?
>
> Если уж речь пошла об усовершенствовании этого теста, то я снова повторю
> (высказывал в личной переписке) свою просьбу - не учитывать в объеме
> usrshare тот объем, который занимают файлы из /usr/share/locale.

Почему? Содержимое /usr/share/locale/ перестало быть noarch?

-- 
Led

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Igor Vlasenko]

On Wed, Dec 16, 2009 at 05:32:41PM +0200, Victor Forsyuk wrote:
> Если уж речь пошла об усовершенствовании этого теста, то я снова повторю
> (высказывал в личной переписке) свою просьбу - не учитывать в объеме
> usrshare тот объем, который занимают файлы из /usr/share/locale.

Я так понимаю, что выделять файлы из /usr/share/locale в 
подпакет -- не вредно, а полезно.

Например.
пусть есть arch пакет foo, который
состоит из 
/usr/bin/foo 20Mb
и 20-ти 
/usr/share/locale/*/LC_MESSAGES/foo.mo по 500K каждый.

Если выделить /usr/share/locale/*/LC_MESSAGES/foo.mo
в отдельный пакет foo-i18n,
то репозитарий похудееет на 10Mb.
Это и есть польза.

Если что-то не понимаю, поправьте пожалуйста.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] big-and-nicely-compressible-usr-share (was: [cyber] repocop-reports +1! -2 +13 (3652))

[Igor Vlasenko]

On Mon, Dec 21, 2009 at 06:06:01PM +0200, Victor Forsyuk wrote:
> > On Wed, Dec 16, 2009 at 05:32:41PM +0200, Victor Forsyuk wrote:
> > > Если уж речь пошла об усовершенствовании этого теста, то я снова повторю
> > > (высказывал в личной переписке) свою просьбу - не учитывать в объеме
> > > usrshare тот объем, который занимают файлы из /usr/share/locale.
> Например, пусть есть пакет warzone2100, в котором есть /usr/bin/warzone2100
> занимающий на диске 2МБ с чем-то
> и /usr/share/locale/*/LC_MESSAGES/warzone2100.mo занимающие вместе
> приблизительно такой же объем.
> Если выделить все локализации для одной программы, то они (как текстовые
> файлы, да еще и регулярной структуры, да еще и с повторениями) ужмутся очень
> сильно. Намного сильнее бинарника программы. В два раза.
> польза Мизерная. На фоне сотен мегабайт данных игрушек - слёзы. Если взять
> конкретно warzone2100, то 42 МБ(!) его игровых данных я отрезал в отдельный
> пакет. А вот полмега локалей - извините, не буду.

Виктор, вы, как майнтайнер, вправе решать,
что и как делать с пакетом.
И в данном конкретном случае вы правы - это экономия на спичках.

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

Конечно, минус в том, что сообщение останется висеть.

Чтобы оно не висело, вы просили переписать тест.

Но в том, что вы просили, есть своя тонкость: 
кроме того, что мне не понятен смысл, зачем переписывать тест, 
у меня на переотладку теста пойдут те же 
усилия, если когда я просто попрошу у вас NMU (добавить @qa)
и сам отрежу у warzone2100 эти полмега локалей.

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

В результате репозитарий на спичку станет лучше.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine