[devel] Gtk+ и DirectFB

[devel] Gtk+ и DirectFB

[Alexey Rusakov]

Доброго времени суток.

За это лето я узнал о по крайней мере двух людях (lav@ и legion@, 
возможно, есть кто-то ещё), заинтересованных в появлении в Сизифе сборки 
Gtk+ с DirectFB вместо Xlib. Апстрим Gtk+ относится к этому 
благосклонно, и версия 2.10.2 не просто собирается с DirectFB, а даже 
пытается работать. На данный момент есть несколько вопросов скорее 
организационного плана:
1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым 
местом, всё же хочется понять, насколько нынешний мейнтейнер в нём 
заинтересован.
2. Требуется собрать Cairo с поддержкой DirectFB. Принципиальных 
сложностей здесь никаких, Cairo можно собрать с одновременной поддержкой 
обоих библиотек (Xlib и DirectFB), но для пакета, разумеется, это будет 
ещё одна зависимость (от libdirectfb). Выслушиваются мнения о том, 
насколько это будет мешать, кроме того, есть вопрос мейнтейнерства 
(поддержку DirectFB проверять, видимо, буду в основном я, а не at@). 
Возможно, стоит создать тим.
3. В отличие от Cairo, Gtk+ поддерживать одновременно и Xlib, и DirectFB 
- не умеет. Сборки с разными backends пересекаются друг с другом по 
файлам. Посему вопрос к заинтересованным в сборке людям: может ли 
потребоваться одновременное присутствие в системе libgtk+2 и 
libgtk+2_dfb? Судя по обсуждению с lav@, в основном это может 
потребоваться мне, поскольку я работаю в иксах, и каждый раз подменять 
библиотеку для тестирования неохота, а сетапить виртуальную машину под 
это, честно говоря, лень, да и неясно, насколько будет работать. В любом 
случае, вопрос: стоит ли заниматься распиливанием libgtk+2 так, чтобы 
можно было держать на машине оба пакета одновременно?

Засим пока всё, жду ответов от всех, кому это интересно.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Alexey Rusakov пишет:
> Доброго времени суток.
> 
> За это лето я узнал о по крайней мере двух людях (lav@ и legion@, 
> возможно, есть кто-то ещё), заинтересованных в появлении в Сизифе сборки 
> Gtk+ с DirectFB вместо Xlib. Апстрим Gtk+ относится к этому 
> благосклонно, и версия 2.10.2 не просто собирается с DirectFB, а даже 
> пытается работать. На данный момент есть несколько вопросов скорее 
> организационного плана:

А можете куда-нибудь это выложить? ... очень хочется протестировать :)

> 1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым 
> местом, всё же хочется понять, насколько нынешний мейнтейнер в нём 
> заинтересован.

Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
libdirectfb ... мне он будет нужен.

> 2. Требуется собрать Cairo с поддержкой DirectFB. Принципиальных 
> сложностей здесь никаких, Cairo можно собрать с одновременной поддержкой 
> обоих библиотек (Xlib и DirectFB), но для пакета, разумеется, это будет 

В этом случае будут зависимости не нужные для DirectFB

$ ldd /usr/lib/libcairo.so.2.9.1 |grep X
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xa7e17000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xa7d36000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xa7be1000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xa7bdc000)

А для сборки с Xlib будет лишняя зависимость на libdirectfb ... это не
желательно для обоих бэкендов ... не лучше ли сделать две разные
сборки с разными бэкендами ?

> ещё одна зависимость (от libdirectfb). Выслушиваются мнения о том, 
> насколько это будет мешать, кроме того, есть вопрос мейнтейнерства 
> (поддержку DirectFB проверять, видимо, буду в основном я, а не at@). 
> Возможно, стоит создать тим.
> 3. В отличие от Cairo, Gtk+ поддерживать одновременно и Xlib, и DirectFB 
> - не умеет. Сборки с разными backends пересекаются друг с другом по 
> файлам. Посему вопрос к заинтересованным в сборке людям: может ли 
> потребоваться одновременное присутствие в системе libgtk+2 и 
> libgtk+2_dfb? Судя по обсуждению с lav@, в основном это может 
> потребоваться мне, поскольку я работаю в иксах, и каждый раз подменять 
> библиотеку для тестирования неохота, а сетапить виртуальную машину под 
> это, честно говоря, лень, да и неясно, насколько будет работать. В любом 
> случае, вопрос: стоит ли заниматься распиливанием libgtk+2 так, чтобы 
> можно было держать на машине оба пакета одновременно?

Если такое будет, то будет замечательно.

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Valery V. Inozemtsev]

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

> > 1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым
> > местом, всё же хочется понять, насколько нынешний мейнтейнер в нём
> > заинтересован.
>
> Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
> libdirectfb ... мне он будет нужен.

мне он уже давно без надобности. отдам хоть щас

-- 
Valery V. Inozemtsev

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

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Valery V. Inozemtsev пишет:
>>> 1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым
>>> местом, всё же хочется понять, насколько нынешний мейнтейнер в нём
>>> заинтересован.
>> Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
>> libdirectfb ... мне он будет нужен.
> 
> мне он уже давно без надобности. отдам хоть щас

Как только по пробую Gtk2 с DirectFB :)

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Alexey Rusakov]

Alexey Gladkov пишет:
> Valery V. Inozemtsev пишет:
>   
>>>> 1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым
>>>> местом, всё же хочется понять, насколько нынешний мейнтейнер в нём
>>>> заинтересован.
>>>>         
>>> Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
>>> libdirectfb ... мне он будет нужен.
>>>       
>> мне он уже давно без надобности. отдам хоть щас
>>     
>
> Как только по пробую Gtk2 с DirectFB :)
>
>   
http://ktirf.nale.ru/RPMS/libcairo-1.2.4-alt1.1.src.rpm
http://ktirf.nale.ru/RPMS/libcairo-1.2.4-alt1.1.i586.rpm
http://ktirf.nale.ru/RPMS/libcairo-devel-1.2.4-alt1.1.i586.rpm
http://ktirf.nale.ru/RPMS/libgtk+2_dfb-2.10.2-alt1.src.rpm
http://ktirf.nale.ru/RPMS/libgtk+2_dfb-2.10.2-alt1.i586.rpm
http://ktirf.nale.ru/RPMS/libgtk+2_dfb-devel-2.10.2-alt1.i586.rpm
http://ktirf.nale.ru/RPMS/libgtk+2_dfb-devel-doc-2.10.2-alt1.i586.rpm

Играйтесь :)

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Gtk+ и DirectFB

[Valery V. Inozemtsev]

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

В сообщении от 28 августа 2006 23:04 Alexey Rusakov написал(a):
> Alexey Gladkov пишет:
> > Valery V. Inozemtsev пишет:
> >>>> 1. DirectFB в Сизифе старый. Хотя на данном этапе не это является
> >>>> слабым местом, всё же хочется понять, насколько нынешний мейнтейнер в
> >>>> нём заинтересован.
> >>>
> >>> Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
> >>> libdirectfb ... мне он будет нужен.
> >>
> >> мне он уже давно без надобности. отдам хоть щас
> >
> > Как только по пробую Gtk2 с DirectFB :)
>
> http://ktirf.nale.ru/RPMS/libcairo-1.2.4-alt1.1.src.rpm
> http://ktirf.nale.ru/RPMS/libcairo-1.2.4-alt1.1.i586.rpm
> http://ktirf.nale.ru/RPMS/libcairo-devel-1.2.4-alt1.1.i586.rpm
> http://ktirf.nale.ru/RPMS/libgtk+2_dfb-2.10.2-alt1.src.rpm
> http://ktirf.nale.ru/RPMS/libgtk+2_dfb-2.10.2-alt1.i586.rpm
> http://ktirf.nale.ru/RPMS/libgtk+2_dfb-devel-2.10.2-alt1.i586.rpm
> http://ktirf.nale.ru/RPMS/libgtk+2_dfb-devel-doc-2.10.2-alt1.i586.rpm
>
> Играйтесь :)

велосипед вы изобретаете. проще собрать kdrive и будут вам embedded X с 
directfb, с tslib и xcalibrate

-- 
Valery V. Inozemtsev

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

Re: [devel] Gtk+ и DirectFB

[Alexey Tourbin]

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

On Mon, Aug 28, 2006 at 11:05:51AM +0400, Alexey Gladkov wrote:
> Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
> libdirectfb ... мне он будет нужен.

Я тоже хотел поковырять directfb, но я не умею его тестировать.
Сходу претензии к нему такие: soname привязн к версии; если бинарная
совместимость сохраняется, то можно вписать в Provides старый soname.
В пакете libdirectfb самый большой файл -- ChangeLog; при том, что также
имеется файл NEWS, паковать ChangeLog точно не стоит.  Low-level ChangeLog
в пакете нужен не больше, чем исходники.  Кстати это касается всех пакетов.

> > 2. Требуется собрать Cairo с поддержкой DirectFB. Принципиальных 
> > сложностей здесь никаких, Cairo можно собрать с одновременной поддержкой 
> > обоих библиотек (Xlib и DirectFB), но для пакета, разумеется, это будет 
> 
> В этом случае будут зависимости не нужные для DirectFB
> 
> $ ldd /usr/lib/libcairo.so.2.9.1 |grep X
>         libXrender.so.1 => /usr/lib/libXrender.so.1 (0xa7e17000)
>         libX11.so.6 => /usr/lib/libX11.so.6 (0xa7d36000)
>         libXau.so.6 => /usr/lib/libXau.so.6 (0xa7be1000)
>         libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xa7bdc000)
> 
> А для сборки с Xlib будет лишняя зависимость на libdirectfb ... это не
> желательно для обоих бэкендов ... не лучше ли сделать две разные
> сборки с разными бэкендами ?

Делать две сборки libcairo?  Да ну!  Уж лучше пусть будет зависимость на
libdirectfb.  Это довольно маленькая библиотека (300K), если ChangeLog
выкинуть.

Но если собирать libcairo+libdirectfb без libX11 вообще -- тогда другое дело.
Только не знаю есть в этом смысл или нет.  И soname'ами что делать.  Они
ведь провайдятся.

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

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Alexey Tourbin пишет:
> Я тоже хотел поковырять directfb, но я не умею его тестировать.
> Сходу претензии к нему такие: soname привязн к версии; если бинарная
> совместимость сохраняется, то можно вписать в Provides старый soname.
> В пакете libdirectfb самый большой файл -- ChangeLog; при том, что также
> имеется файл NEWS, паковать ChangeLog точно не стоит.  Low-level ChangeLog
> в пакете нужен не больше, чем исходники.  Кстати это касается всех пакетов.

Думаю, это можно пофиксить.

> Делать две сборки libcairo?  Да ну!  Уж лучше пусть будет зависимость на
> libdirectfb.  Это довольно маленькая библиотека (300K), если ChangeLog
> выкинуть.

Обратная ситуация хуже.

> Но если собирать libcairo+libdirectfb без libX11 вообще -- тогда другое дело.
> Только не знаю есть в этом смысл или нет.  И soname'ами что делать.  Они
> ведь провайдятся.

Думаю смысл есть. Это нужно для встроенных систем. Тянуть libX*
библиотеки в этом случае не имеет смысла ... более того это накладно.

По сути в этом случае библиотеки будут замещать друг друга так как API
и ABI у них не должен меняться.

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Led]

В сообщении от 28 августа 2006 11:29 Alexey Gladkov написал(a):
> Alexey Tourbin пишет:
> > Я тоже хотел поковырять directfb, но я не умею его тестировать.
> > Сходу претензии к нему такие: soname привязн к версии; если бинарная
> > совместимость сохраняется, то можно вписать в Provides старый soname.
> > В пакете libdirectfb самый большой файл -- ChangeLog; при том, что также
> > имеется файл NEWS, паковать ChangeLog точно не стоит.  Low-level
> > ChangeLog в пакете нужен не больше, чем исходники.  Кстати это касается
> > всех пакетов.
>
> Думаю, это можно пофиксить.
>
> > Делать две сборки libcairo?  Да ну!  Уж лучше пусть будет зависимость на
> > libdirectfb.  Это довольно маленькая библиотека (300K), если ChangeLog
> > выкинуть.
>
> Обратная ситуация хуже.
>
> > Но если собирать libcairo+libdirectfb без libX11 вообще -- тогда другое
> > дело. Только не знаю есть в этом смысл или нет.  И soname'ами что делать.
> >  Они ведь провайдятся.
>
> Думаю смысл есть. Это нужно для встроенных систем. Тянуть libX*
> библиотеки в этом случае не имеет смысла ... более того это накладно.

Это тянет чуть ли не на новый Arch (embeded или как его там...)

>
> По сути в этом случае библиотеки будут замещать друг друга так как API
> и ABI у них не должен меняться.

-- 
Led.

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Led пишет:
> Это тянет чуть ли не на новый Arch (embeded или как его там...)

А есть ещё что-нибудь кроме Gtk, Pango, Cairo что нужно собирать в так
называемый embeded ?

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Led]

В сообщении от 28 августа 2006 13:17 Alexey Gladkov написал(a):
> Led пишет:
> > Это тянет чуть ли не на новый Arch (embeded или как его там...)
>
> А есть ещё что-нибудь кроме Gtk, Pango, Cairo что нужно собирать в так
> называемый embeded ?

QT-Embeded?

-- 
Led.

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Led пишет:
> QT-Embeded?
> 

Это понятно. :)
А ещё что-нибудь ?

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Led]

В сообщении от 28 августа 2006 14:39 Alexey Gladkov написал(a):
> Led пишет:
> > QT-Embeded?
>
> Это понятно. :)
> А ещё что-нибудь ?

Ну, наверное, весь прикладной софт, собранный с соответствующими Qt и GTK+ и с 
libdirectfb вместо libX*. По крайней мере, скриншоты GIMP в FB видел ещё года 
3 назад:)

-- 
Led.

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Led пишет:
> В сообщении от 28 августа 2006 14:39 Alexey Gladkov написал(a):
>> Led пишет:
>>> QT-Embeded?
>> Это понятно. :)
>> А ещё что-нибудь ?
> 
> Ну, наверное, весь прикладной софт, собранный с соответствующими Qt и GTK+ и с 
> libdirectfb вместо libX*. По крайней мере, скриншоты GIMP в FB видел ещё года 
> 3 назад:)
> 

Как раз этого и не требуется. Изменяется только бэкенд у библиотек, а
API, ABI не меняется... или я заблуждаюсь ?

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Alexey Rusakov]

Alexey Gladkov пишет:
> Led пишет:
>   
>> В сообщении от 28 августа 2006 14:39 Alexey Gladkov написал(a):
>>     
>>> Led пишет:
>>>       
>>>> QT-Embeded?
>>>>         
>>> Это понятно. :)
>>> А ещё что-нибудь ?
>>>       
>> Ну, наверное, весь прикладной софт, собранный с соответствующими Qt и GTK+ и с 
>> libdirectfb вместо libX*. По крайней мере, скриншоты GIMP в FB видел ещё года 
>> 3 назад:)
>>
>>     
>
> Как раз этого и не требуется. Изменяется только бэкенд у библиотек, а
> API, ABI не меняется... или я заблуждаюсь ?
>   
Хотелось бы. На деле бэкенд DIrectFB попросту ещё не дописан, и 
полноценный API, как следствие, предоставить не может. Это как минимум, 
боюсь, что этим не ограничится.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Gtk+ и DirectFB

[Vitaly Lipatov]

On Monday 28 August 2006 16:47, Alexey Gladkov wrote:
...
> > Ну, наверное, весь прикладной софт, собранный с
> > соответствующими Qt и GTK+ и с libdirectfb вместо libX*. По
> > крайней мере, скриншоты GIMP в FB видел ещё года 3 назад:)
>
> Как раз этого и не требуется. Изменяется только бэкенд у
> библиотек, а API, ABI не меняется... или я заблуждаюсь ?
Я уверен что пересборка не требуется. Есть небольшая проблема с 
тем что программы слинкованы с libgtk-x11.so, а потребуется их 
запускать с libgtk-directfb.so. 

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Gtk+ и DirectFB

[Alexey Tourbin]

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

On Tue, Aug 29, 2006 at 12:56:16AM +0400, Vitaly Lipatov wrote:
> On Monday 28 August 2006 16:47, Alexey Gladkov wrote:
> ...
> > > Ну, наверное, весь прикладной софт, собранный с
> > > соответствующими Qt и GTK+ и с libdirectfb вместо libX*. По
> > > крайней мере, скриншоты GIMP в FB видел ещё года 3 назад:)
> >
> > Как раз этого и не требуется. Изменяется только бэкенд у
> > библиотек, а API, ABI не меняется... или я заблуждаюсь ?
> Я уверен что пересборка не требуется. Есть небольшая проблема с 

Откуда уверенность?

> тем что программы слинкованы с libgtk-x11.so, а потребуется их 
> запускать с libgtk-directfb.so. 

Можно LD_LIBRARY_PATH+симлинками отбиться.
Только мне пока не понятно зачем это нужно.
Вы собрались что-то писать на gtk для ембедовщины?

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

Re: [devel] Gtk+ и DirectFB

[Vitaly Lipatov]

On Tuesday 29 August 2006 01:04, Alexey Tourbin wrote:
> On Tue, Aug 29, 2006 at 12:56:16AM +0400, Vitaly Lipatov wrote:
> > On Monday 28 August 2006 16:47, Alexey Gladkov wrote:
> > ...
> >
> > > > Ну, наверное, весь прикладной софт, собранный с
> > > > соответствующими Qt и GTK+ и с libdirectfb вместо libX*.
> > > > По крайней мере, скриншоты GIMP в FB видел ещё года 3
> > > > назад:)
> > >
> > > Как раз этого и не требуется. Изменяется только бэкенд у
> > > библиотек, а API, ABI не меняется... или я заблуждаюсь ?
> >
> > Я уверен что пересборка не требуется. Есть небольшая
> > проблема с
>
> Откуда уверенность?
1. пробовали
2. несовместимость ABI в этом случае ясно бы показало кривость 
проектирования библиотеки
3. было бы смешно, если бы в этом случае API совпадало, а ABI 
нет.
4. небольшой опыт с WINE

> > тем что программы слинкованы с libgtk-x11.so, а потребуется
> > их запускать с libgtk-directfb.so.
>
> Можно LD_LIBRARY_PATH+симлинками отбиться.
> Только мне пока не понятно зачем это нужно.
> Вы собрались что-то писать на gtk для ембедовщины?
Да. А что? Я не люблю qt.
Более того, на pygtk.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Gtk+ и DirectFB

[Alexey Tourbin]

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

On Tue, Aug 29, 2006 at 01:33:59AM +0400, Vitaly Lipatov wrote:
> > Можно LD_LIBRARY_PATH+симлинками отбиться.
> > Только мне пока не понятно зачем это нужно.
> > Вы собрались что-то писать на gtk для ембедовщины?
> Да. А что? Я не люблю qt.
> Более того, на pygtk.

Всё понятно. :)  Питон на микро-ембедовщину явно не тянет.
Короче прделагаю пока не отрывать иксовые библиотеки и не делать
конфликтующих пакетов.  Это преждевременная оптимизация.  Насколько
эта оптимизация нужна станет ясно позже.

Именно, предлагаю сделать следующее:

1) дожадться в сизифе нового directfb (legion?);
2) собрать cairo одновременно с X11 и directfb;
3) собрать неконфликтующие версии libgtk+2 и libgtk+2_fb,
у которых должны отличаться soname'ы.

Далее, писать на питоне под нормальный libgtk+2, а тестировать в режиме
ембедовщины так:

ln -s ../libgtk-fb-2.0.so.0 /usr/lib/directfb/libgtk-x11-2.0.so.0
LD_LIBRARY_PATH=/usr/lib/directfb myprog.py

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

Re: [devel] Gtk+ и DirectFB

[Vitaly Lipatov]

On Tuesday 29 August 2006 02:23, Alexey Tourbin wrote:
...
> Именно, предлагаю сделать следующее:
>
> 1) дожадться в сизифе нового directfb (legion?);
> 2) собрать cairo одновременно с X11 и directfb;
> 3) собрать неконфликтующие версии libgtk+2 и libgtk+2_fb,
> у которых должны отличаться soname'ы.
>
> Далее, писать на питоне под нормальный libgtk+2, а тестировать
> в режиме ембедовщины так:
>
> ln -s ../libgtk-fb-2.0.so.0
> /usr/lib/directfb/libgtk-x11-2.0.so.0
> LD_LIBRARY_PATH=/usr/lib/directfb myprog.py
Я рад что думал также ;)

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Gtk+ и DirectFB

[Alexey Rusakov]

Vitaly Lipatov пишет:
> On Tuesday 29 August 2006 02:23, Alexey Tourbin wrote:
> ...
>   
>> Именно, предлагаю сделать следующее:
>>
>> 1) дожадться в сизифе нового directfb (legion?);
>>     
Жду в Сизифе нового DirectFB, потихоньку распиливаю libgtk+2.

>> 2) собрать cairo одновременно с X11 и directfb;
>> 3) собрать неконфликтующие версии libgtk+2 и libgtk+2_fb,
>> у которых должны отличаться soname'ы.
>>
>> Далее, писать на питоне под нормальный libgtk+2, а тестировать
>> в режиме ембедовщины так:
>>
>> ln -s ../libgtk-fb-2.0.so.0
>> /usr/lib/directfb/libgtk-x11-2.0.so.0
>> LD_LIBRARY_PATH=/usr/lib/directfb myprog.py
>>     
> Я рад что думал также ;)
>   
Да, мне тоже нравится.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Embedded Sisyphus

[Alex V. Myltsev]

Alexey Gladkov wrote:
> Led пишет:
>> QT-Embeded?
> Это понятно. :)
> А ещё что-нибудь ?

uСlibc, и всё с ним собирать?
Если уж embedded.

busybox вместо *utils (или вместе, но чтобы зависимости позволяли одно
на другое поменять).

dropbear туда утащить ("created _only_ for embedded systems").

Возможно, init-ng или другой параллельный init, если с ним грузиться
будет быстрее.

Мог бы получиться репозиторий для сборки appliances. Со своими
особенностями: не важна обновляемость пакетов (потому что appliance
обновляется целиком), не важна совместимость со взрослым Сизифом (потому
что на разных машинах они работают). Маленький хакерский репозиторий :).

Re: [devel] Embedded Sisyphus

[Anton Farygin]

Alex V. Myltsev wrote:
> Alexey Gladkov wrote:
>> Led пишет:
>>> QT-Embeded?
>> Это понятно. :)
>> А ещё что-нибудь ?
> 
> uСlibc, и всё с ним собирать?
> Если уж embedded.
> 
> busybox вместо *utils (или вместе, но чтобы зависимости позволяли одно
> на другое поменять).
> 
> dropbear туда утащить ("created _only_ for embedded systems").
> 
> Возможно, init-ng или другой параллельный init, если с ним грузиться
> будет быстрее.
> 
> Мог бы получиться репозиторий для сборки appliances. Со своими
> особенностями: не важна обновляемость пакетов (потому что appliance
> обновляется целиком), не важна совместимость со взрослым Сизифом (потому
> что на разных машинах они работают). Маленький хакерский репозиторий :).

Идея весьма интересна.

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

Вообще на самом деле мне становится интересно видеть Sisyphus на X-Scale 
;) и для X-Scale. имеется в виду всё, что нужно для разработки на 
обычном PC под arm. Весь сизиф на arm, это конечно перебор, но хотя бы 
базовую часть я бы не отказался ;)

там правда возникает вопрос, на который уже есть ответ..

что делать с RPM ? выкинуть!

Rgds,
Rider

Re: [devel] Embedded Sisyphus

[Led]

В сообщении от 28 августа 2006 16:13 Anton Farygin написал(a):
> Alex V. Myltsev wrote:
> > Alexey Gladkov wrote:
> >> Led пишет:
> >>> QT-Embeded?
> >>
> >> Это понятно. :)
> >> А ещё что-нибудь ?
> >
> > uСlibc, и всё с ним собирать?
> > Если уж embedded.
> >
> > busybox вместо *utils (или вместе, но чтобы зависимости позволяли одно
> > на другое поменять).
> >
> > dropbear туда утащить ("created _only_ for embedded systems").
> >
> > Возможно, init-ng или другой параллельный init, если с ним грузиться
> > будет быстрее.
> >
> > Мог бы получиться репозиторий для сборки appliances. Со своими
> > особенностями: не важна обновляемость пакетов (потому что appliance
> > обновляется целиком), не важна совместимость со взрослым Сизифом (потому
> > что на разных машинах они работают). Маленький хакерский репозиторий :).
>
> Идея весьма интересна.
>
> Только с рядом дополнений. busybox я бы выкинул, ибо всё равно его если
> и собирать, то под конкретную задачу.. uClibc.. сложно сказать.
>
> Вообще на самом деле мне становится интересно видеть Sisyphus на X-Scale
> ;) и для X-Scale. имеется в виду всё, что нужно для разработки на
> обычном PC под arm. Весь сизиф на arm, это конечно перебор, но хотя бы
> базовую часть я бы не отказался ;)
>
> там правда возникает вопрос, на который уже есть ответ..
>
> что делать с RPM ? выкинуть!

Зачем выкидывать? rpmi оставить можно.

Оно может и интересно, но зачем тогда "безиксовость", если практика показывает 
успешность использования нативной X Window на КПК по сравнению с "чистыми" 
FB-системами:)

-- 
Led.

Re: [devel] Embedded Sisyphus

[Anton Farygin]

Led wrote:
> В сообщении от 28 августа 2006 16:13 Anton Farygin написал(a):
>> Alex V. Myltsev wrote:
>>> Alexey Gladkov wrote:
>>>> Led пишет:
>>>>> QT-Embeded?
>>>> Это понятно. :)
>>>> А ещё что-нибудь ?
>>> uСlibc, и всё с ним собирать?
>>> Если уж embedded.
>>>
>>> busybox вместо *utils (или вместе, но чтобы зависимости позволяли одно
>>> на другое поменять).
>>>
>>> dropbear туда утащить ("created _only_ for embedded systems").
>>>
>>> Возможно, init-ng или другой параллельный init, если с ним грузиться
>>> будет быстрее.
>>>
>>> Мог бы получиться репозиторий для сборки appliances. Со своими
>>> особенностями: не важна обновляемость пакетов (потому что appliance
>>> обновляется целиком), не важна совместимость со взрослым Сизифом (потому
>>> что на разных машинах они работают). Маленький хакерский репозиторий :).
>> Идея весьма интересна.
>>
>> Только с рядом дополнений. busybox я бы выкинул, ибо всё равно его если
>> и собирать, то под конкретную задачу.. uClibc.. сложно сказать.
>>
>> Вообще на самом деле мне становится интересно видеть Sisyphus на X-Scale
>> ;) и для X-Scale. имеется в виду всё, что нужно для разработки на
>> обычном PC под arm. Весь сизиф на arm, это конечно перебор, но хотя бы
>> базовую часть я бы не отказался ;)
>>
>> там правда возникает вопрос, на который уже есть ответ..
>>
>> что делать с RPM ? выкинуть!
> 
> Зачем выкидывать? rpmi оставить можно.
> 
> Оно может и интересно, но зачем тогда "безиксовость", если практика показывает 
> успешность использования нативной X Window на КПК по сравнению с "чистыми" 
> FB-системами:)
> 

Кому как.. мне FB на КПК нравится больше, чем X.

Re: [devel] Выкинуть RPM

[Alex V. Myltsev]

Anton Farygin wrote:
> что делать с RPM ? выкинуть!
Зачем? И что вместо? И удобно ли будет перетаскивать пакеты? И будет ли
неRPM собираться в hasher'е?

Re: [devel] Embedded Sisyphus

[Damir Shayhutdinov]

> Вообще на самом деле мне становится интересно видеть Sisyphus на X-Scale ;) и для X-Scale. имеется в виду всё, что нужно для разработки на
> обычном PC под arm. Весь сизиф на arm, это конечно перебор, но хотя бы
> базовую часть я бы не отказался ;)
Тулчейн для xscale есть у меня на работе, правда gcc 3.4.5 и glibc.
Впрочем все патчи довольно тривиальны и валяются в сети. С всякими
dietlibc и uClibc были проблемы со сборкой C++.

> там правда возникает вопрос, на который уже есть ответ..
>
> что делать с RPM ? выкинуть!
Я заменил на ipkg, правда глючный он и сегфолтается иногда.
А вообще простой rpm, умеющий ставить пакеты входит в busybox.

Re: [devel] Embedded Sisyphus

[Vitaly Ostanin]

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

Damir Shayhutdinov пишет:
>> Вообще на самом деле мне становится интересно видеть Sisyphus на X-Scale ;) и для X-Scale. имеется в виду всё, что нужно для разработки на
>> обычном PC под arm. Весь сизиф на arm, это конечно перебор, но хотя бы
>> базовую часть я бы не отказался ;)
> Тулчейн для xscale есть у меня на работе, правда gcc 3.4.5 и glibc.
> Впрочем все патчи довольно тривиальны и валяются в сети. С всякими
> dietlibc и uClibc были проблемы со сборкой C++.

Есть такой
http://www.openembedded.org/
там есть всё нужное для сборки под arm и оно даже работает.

В embedded системах проблема больше не в конкретном репозитории,
а в драйверах и отладке.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [devel] Embedded Sisyphus

[Ildar Mulyukov]

On 28.08.2006 19:13:44, Anton Farygin wrote:
> Идея весьма интересна.
> 
> Только с рядом дополнений. busybox я бы выкинул, ибо всё равно его
> если и собирать, то под конкретную задачу.. uClibc.. сложно сказать.
> 
> Вообще на самом деле мне становится интересно видеть Sisyphus на
> X-Scale ;) и для X-Scale. имеется в виду всё, что нужно для  
> разработки на обычном PC под arm. Весь сизиф на arm, это конечно  
> перебор, но хотя бы базовую часть я бы не отказался ;)
Подпишусь тестировать и даже помогать. У меня есть iPaq H3970 под  
Familiar Linux. Предлагаю открыть страничку на wiki для координации.

> там правда возникает вопрос, на который уже есть ответ..
> что делать с RPM ? выкинуть!
Конечно. Думаю, можно сделать несложный конвертор RPM->ipkg с  
сохранением зависимостей. То есть собирать кросс-arm.rpm и конвертить в  
pkg-ver.ipk Можно делать плавный попакетный переход с Familiar на ALT.  
Короче, есть и мысли и желания. Нужны соратники.

Ильдар.
--
Ildar  Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Embedded Sisyphus

[Alexey Rusakov]

Ildar Mulyukov пишет:
> On 28.08.2006 19:13:44, Anton Farygin wrote:
>   
>> Вообще на самом деле мне становится интересно видеть Sisyphus на
>> X-Scale ;) и для X-Scale. имеется в виду всё, что нужно для  
>> разработки на обычном PC под arm. Весь сизиф на arm, это конечно  
>> перебор, но хотя бы базовую часть я бы не отказался ;)
>>     
> Подпишусь тестировать и даже помогать. У меня есть iPaq H3970 под  
> Familiar Linux. Предлагаю открыть страничку на wiki для координации.
>   
>> там правда возникает вопрос, на который уже есть ответ..
>> что делать с RPM ? выкинуть!
>>     
> Конечно. Думаю, можно сделать несложный конвертор RPM->ipkg с  
> сохранением зависимостей. То есть собирать кросс-arm.rpm и конвертить в  
> pkg-ver.ipk Можно делать плавный попакетный переход с Familiar на ALT.  
> Короче, есть и мысли и желания. Нужны соратники.
>   
Эх, с соратниками всегда был самый большой напряг...

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Embedded Sisyphus

[Vitaly Ostanin]

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

Alexey Rusakov пишет:

<skipped/>

>> Конечно. Думаю, можно сделать несложный конвертор RPM->ipkg с  
>> сохранением зависимостей. То есть собирать кросс-arm.rpm и конвертить в  
>> pkg-ver.ipk Можно делать плавный попакетный переход с Familiar на ALT.  
>> Короче, есть и мысли и желания. Нужны соратники.
>>   
> Эх, с соратниками всегда был самый большой напряг...

Я готов участвовать (не организовывать :)).

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [devel] Embedded Sisyphus

[Michael Shigorin]

On Thu, Aug 31, 2006 at 03:08:41PM +0600, Ildar Mulyukov wrote:
> Короче, есть и мысли и желания. Нужны соратники.

А смысл есть, действительно?

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

Re: [devel] Embedded Sisyphus

[Ildar Mulyukov]

On 02.09.2006 19:19:16, Michael Shigorin wrote:
> On Thu, Aug 31, 2006 at 03:08:41PM +0600, Ildar Mulyukov wrote:
> > Короче, есть и мысли и желания. Нужны соратники.
> А смысл есть, действительно?
За всех не скажу, изложу только свою мотивацию.
Хочется довести свой iPaq до "удобного" состояния. Для этого надо хоть  
немного включаться в процесс разработки. Однако, облазив handhelds.org,  
нашёл только разочарование:
1. Этот убогий open embedded - н-дцать мегабайт готовых бинарников. Мне  
бы, например, было бы стыдно на каком-нибудь вики писать: скачайте и  
_распакуйте_ "это". Брр.
Я бы предпочёл arm-cross-compiler из Альта и, если надо, какие-то  
полезные скрипты взять из этого open embedded, в существовании которых  
я, вообще, сильно сомневаюсь.
2. Программировать там вообще не умеют. Qt-based я так подробно не  
смотрел, но GPE- это что-то убогое. Никакой культуры. Люди лабают  
что-то на коленке. Никакого понятия об autotools там нет. И т.п. А  
насаждать культуру хорошо, когда есть какая-то наработанная  
инфраструктура. Тогда можно им показать так: Смотрите, ребята, как это  
делается у нас двумя командами из bash! (Я вообще, где это приемлемо,  
часто хвастаюсь тем, что наработано в Альт. Может, кто прислушается? ;)
3. Всё, что я пишу или даже просто дорабатываю чужое, хочу запаковать,  
чтобы можно было пользоваться на моём десктопе (что есть важное  
преимущество Linux-based наладонников)

В родной среде и программировать приятнее, особенно, когда знаешь, что  
всё, чем пользуешься, откликается на rpm -qf!

Вот такая у меня паранойя! Будущим поколениям урок: не становитесь, как  
я, фанатиками :)
Преданный Альту, Ильдар
--
Ildar  Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Embedded Sisyphus

[Sergey Bolshakov]

>>>>> "Ildar" == Ildar Mulyukov <ildar@altlinux.ru> writes:
[skipped]
 > 1. Этот убогий open embedded - н-дцать мегабайт готовых бинарников. Мне  
 > бы, например, было бы стыдно на каком-нибудь вики писать: скачайте и  
 > _распакуйте_ "это". Брр.
 > Я бы предпочёл arm-cross-compiler из Альта и, если надо, какие-то  
 > полезные скрипты взять из этого open embedded, в существовании которых  
 > я, вообще, сильно сомневаюсь.
 > 2. Программировать там вообще не умеют. Qt-based я так подробно не  
 > смотрел, но GPE- это что-то убогое. Никакой культуры. Люди лабают  
 > что-то на коленке. Никакого понятия об autotools там нет. И т.п.

Истратив некоторое время на порт alt на xscale, пришел к выводу,
что иначе с кроссом не бывает. Бишь, если хочется autotools
и всякой прочей культур-мультур -- нужно быть готовым собирать
нативно. Разумеется, на наладоннике это _очень_ медленно,
но кто мешает заинтересованным лицам завести сборочный
кластер (distcc какой-нить) из двух десятков таковых ? :)

-- 

Re: [devel] Embedded Sisyphus

[Ildar Mulyukov]

On 04.09.2006 15:23:16, Sergey Bolshakov wrote:
> >>>>> "Ildar" == Ildar Mulyukov <ildar@altlinux.ru> writes:
> [skipped]
>  > 2. Программировать там вообще не умеют. Qt-based я так подробно не
>  > смотрел, но GPE- это что-то убогое. Никакой культуры. Люди лабают
>  > что-то на коленке. Никакого понятия об autotools там нет. И т.п.
> 
> Истратив некоторое время на порт alt на xscale, пришел к выводу,
> что иначе с кроссом не бывает. Бишь, если хочется autotools
> и всякой прочей культур-мультур -- нужно быть готовым собирать
> нативно. Разумеется, на наладоннике это _очень_ медленно,
> но кто мешает заинтересованным лицам завести сборочный
> кластер (distcc какой-нить) из двух десятков таковых ? :)
Сергей,
спасибо за ответ. Но хотелось бы подробностей - хотя бы схематично. В  
личку. С перспективой быть размещённым на wiki, если таковая назреет,  
таки.

С уважением, Ильдар
--
Ildar  Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Embedded Sisyphus

[Vitaly Ostanin]

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

Sergey Bolshakov пишет:
>>>>>> "Ildar" == Ildar Mulyukov <ildar@altlinux.ru> writes:
> [skipped]
>  > 1. Этот убогий open embedded - н-дцать мегабайт готовых бинарников. Мне  
>  > бы, например, было бы стыдно на каком-нибудь вики писать: скачайте и  
>  > _распакуйте_ "это". Брр.
>  > Я бы предпочёл arm-cross-compiler из Альта и, если надо, какие-то  
>  > полезные скрипты взять из этого open embedded, в существовании которых  
>  > я, вообще, сильно сомневаюсь.
>  > 2. Программировать там вообще не умеют. Qt-based я так подробно не  
>  > смотрел, но GPE- это что-то убогое. Никакой культуры. Люди лабают  
>  > что-то на коленке. Никакого понятия об autotools там нет. И т.п.

Программировать там умеют не все, но kernel hackers там больше
одного. Просто они отдают приоритет драйверам, а не сборочной среде.

> Истратив некоторое время на порт alt на xscale, пришел к выводу,
> что иначе с кроссом не бывает. Бишь, если хочется autotools
> и всякой прочей культур-мультур -- нужно быть готовым собирать
> нативно. Разумеется, на наладоннике это _очень_ медленно,
> но кто мешает заинтересованным лицам завести сборочный
> кластер (distcc какой-нить) из двух десятков таковых ? :)

Я готов предоставить ipaq hx2790 в такой кластер (по будням в
рабочее время по msk), как только в нём заработает usbnet
(кто-нибудь допишет драйвер для usb gadget в pxa270) или bluetooth.

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [devel] Embedded Sisyphus

[Kirill A. Shutemov]

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

On 12:46 Tue 05 Sep, Vitaly Ostanin wrote:
> Sergey Bolshakov пишет:
> >>>>>> "Ildar" == Ildar Mulyukov <ildar@altlinux.ru> writes:
> > [skipped]
> >  > 1. Этот убогий open embedded - н-дцать мегабайт готовых бинарников. Мне  
> >  > бы, например, было бы стыдно на каком-нибудь вики писать: скачайте и  
> >  > _распакуйте_ "это". Брр.
> >  > Я бы предпочёл arm-cross-compiler из Альта и, если надо, какие-то  
> >  > полезные скрипты взять из этого open embedded, в существовании которых  
> >  > я, вообще, сильно сомневаюсь.
> >  > 2. Программировать там вообще не умеют. Qt-based я так подробно не  
> >  > смотрел, но GPE- это что-то убогое. Никакой культуры. Люди лабают  
> >  > что-то на коленке. Никакого понятия об autotools там нет. И т.п.
> 
> Программировать там умеют не все, но kernel hackers там больше
> одного. Просто они отдают приоритет драйверам, а не сборочной среде.
> 
> > Истратив некоторое время на порт alt на xscale, пришел к выводу,
> > что иначе с кроссом не бывает. Бишь, если хочется autotools
> > и всякой прочей культур-мультур -- нужно быть готовым собирать
> > нативно. Разумеется, на наладоннике это _очень_ медленно,
> > но кто мешает заинтересованным лицам завести сборочный
> > кластер (distcc какой-нить) из двух десятков таковых ? :)
> 
> Я готов предоставить ipaq hx2790 в такой кластер (по будням в
> рабочее время по msk), как только в нём заработает usbnet
> (кто-нибудь допишет драйвер для usb gadget в pxa270) или bluetooth.
У нас компиляция идёт на xscale + distcc на кросс-компилятор на x86.


-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

> А еще я изящным движением мыши утащил верхнюю панель налево -
> как без перезапуска гнома ее вернуть на место?
Подцепить мышкой и перетащить обратно
		-- avp in sisyphus@

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

Re: [devel] Embedded Sisyphus

[Ildar Mulyukov]

On 06.09.2006 18:58:16, Віталь Хілько wrote:
> On 9/6/06, Kirill A. Shutemov <kas@altlinux.ru> wrote:
>> У нас компиляция идёт на xscale + distcc на кросс-компилятор на x86.
> Скорее всего нативной сборки больше не будет, разом с БТЕ2 и всем  
> рпмным гемором. Шаги в эту сторону уже сделаны. Кросс, только кросс  
> ;-)
Можно подкрепить эти слова конкретным примером или даже рецептом - как?

Спасибо. С уважением, Ильдар.
--
Ildar  Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Embedded Sisyphus

[Andrei Bulava]

Alex V. Myltsev wrote:
> Alexey Gladkov wrote:
>> Led пишет:
>>> QT-Embeded?
>> Это понятно. :)
>> А ещё что-нибудь ?
> 
> uСlibc, и всё с ним собирать?
> Если уж embedded.
> 
> busybox вместо *utils (или вместе, но чтобы зависимости позволяли одно
> на другое поменять).
> 
> dropbear туда утащить ("created _only_ for embedded systems").
> 
> Возможно, init-ng или другой параллельный init, если с ним грузиться
> будет быстрее.
> 
> Мог бы получиться репозиторий для сборки appliances. Со своими
> особенностями: не важна обновляемость пакетов (потому что appliance
> обновляется целиком), не важна совместимость со взрослым Сизифом (потому
> что на разных машинах они работают). Маленький хакерский репозиторий :).

Нечто подобное существует на Gentoo, называется GNAP, хорошо гуглится:
http://www.gentoo.org/proj/en/base/embedded/gnap-userguide.xml

Так ли велика необходимость велика? :-)

Насчёт "не важна обновляемость пакетов" и "не важна совместимость со
взрослым Сизифом" - две типичных ошибки велосипедистов, в изобилии и
самозабвенно клепающих мертворожденные embedded linux'ы. См.
http://www.pcengines.ch/wrap.htm как хороший пример кладбища.

Конечно, GNAP не ставит "важна совместимость со взрослым Gentoo" в
абсолют, но совместимость с portage на уровне возможности пересборки
декларирована. Что касается "важна обновляемость пакетов", то у GNAP
вполне здравый подход к обновлениям благодаря "оверлеям" конфигурации
относительно "ядра" GNAP.

Сейчас всё более популярной становится x86 как платформа для appliances
(и http://www.pcengines.ch/ - это далеко не первый пример вслед за
soekris и пачкой вполне pc-подобных (по наличию vga+keyboard, а не
только serial-интерфейса) mini-ITX решений). И, таким образом,
необходимость извращаться с кросс-компиляцией под экзотические не-x86
архитектуры всё менее востребована.

Что же касается популярных не-x86 appliances, более известных как PDA...
 неужто чуть живых http://familiar.handhelds.org/ и прочих
http://intimate.handhelds.org/ мало, что нужно рожать ещё более мёртвое?

P.S. На современных mini-ITX стоят по 512 RAM и 533 MHz VIA Nehemiah +
2,5" HDD. На одном таком у меня крутится OpenVPN-сервер под обычным
CentOS 4.3 без всяких извращений. И будет крутиться столько, сколько
будет поддерживаться RHEL 4, в отличие от большинства поделок,
перечисленных на http://www.pcengines.ch/wrap.htm

-- 
// AB1002-UANIC

Re: [devel] Gtk+ и DirectFB

[Alexey Rusakov]

Alexey Gladkov пишет:
> Led пишет:
>   
>> Это тянет чуть ли не на новый Arch (embeded или как его там...)
>>     
>
> А есть ещё что-нибудь кроме Gtk, Pango, Cairo что нужно собирать в так
> называемый embeded ?
>   
Pango, к слову, собирать в embed не нужно, он замечательно работает без 
пересборки с чем угодно.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Alexey Rusakov пишет:
> Pango, к слову, собирать в embed не нужно, он замечательно работает без 
> пересборки с чем угодно.
> 

Зато у него есть зависимость на X. Я его пересобирал с without-x ...
кажется так ... давно дело было. Поправьте если не прав.

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Alexey Rusakov]

Alexey Gladkov пишет:
> Alexey Rusakov пишет:
>   
>> Pango, к слову, собирать в embed не нужно, он замечательно работает без 
>> пересборки с чем угодно.
>>
>>     
>
> Зато у него есть зависимость на X. Я его пересобирал с without-x ...
> кажется так ... давно дело было. Поправьте если не прав.
Хм-м, да, действительно зависит от libX11, libXft и libXrender. 
Интересно, будет ли оно жить (и как) под иксами, если его собрать 
--without-x :)

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Alexey Rusakov пишет:
> Хм-м, да, действительно зависит от libX11, libXft и libXrender. 
> Интересно, будет ли оно жить (и как) под иксами, если его собрать 
> --without-x :)

Нужно смотреть зачем pango нужны эти либы.

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Alexey Tourbin]

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

On Mon, Aug 28, 2006 at 12:29:02PM +0400, Alexey Gladkov wrote:
> > Но если собирать libcairo+libdirectfb без libX11 вообще -- тогда другое дело.
> > Только не знаю есть в этом смысл или нет.  И soname'ами что делать.  Они
> > ведь провайдятся.
> 
> Думаю смысл есть. Это нужно для встроенных систем. Тянуть libX*
> библиотеки в этом случае не имеет смысла ... более того это накладно.
> 
> По сути в этом случае библиотеки будут замещать друг друга так как API
> и ABI у них не должен меняться.

Я посмотрел наугад несколько гетэкакашных приложений, они все с иксами
слинкованы.  То есть просто так подменить библиотеки и запускать то что
уже собрано под directfb без зависимости на иксовые библиотеки слабо.

$ rpm -qR gimp2 |grep libX
libX11.so.6  
libXmu.so.6  
libXpm.so.4  
libXt.so.6  
$ rpm -qR mozilla |grep libX
libX11.so.6  
libXft.so.2  
libXrender.so.1  
libXt.so.6  
$ 

Есть в сизифе хоть одно гетэкакашное приложение умеренной сложности
которыму иксовые библиотеки ни на йоту не нужны?

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

Re: [devel] Gtk+ и DirectFB

[Dmitry V. Levin]

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

On Tue, Aug 29, 2006 at 12:22:16AM +0400, Alexey Tourbin wrote:
> On Mon, Aug 28, 2006 at 12:29:02PM +0400, Alexey Gladkov wrote:
> > > Но если собирать libcairo+libdirectfb без libX11 вообще -- тогда другое дело.
> > > Только не знаю есть в этом смысл или нет.  И soname'ами что делать.  Они
> > > ведь провайдятся.
> > 
> > Думаю смысл есть. Это нужно для встроенных систем. Тянуть libX*
> > библиотеки в этом случае не имеет смысла ... более того это накладно.
> > 
> > По сути в этом случае библиотеки будут замещать друг друга так как API
> > и ABI у них не должен меняться.
> 
> Я посмотрел наугад несколько гетэкакашных приложений, они все с иксами
> слинкованы.

Они все были в режиме --as-needed слинкованы?


-- 
ldv

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

Re: [devel] Gtk+ и DirectFB

[Alexey Tourbin]

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

On Tue, Aug 29, 2006 at 12:28:10AM +0400, Dmitry V. Levin wrote:
> > On Mon, Aug 28, 2006 at 12:29:02PM +0400, Alexey Gladkov wrote:
> > > Думаю смысл есть. Это нужно для встроенных систем. Тянуть libX*
> > > библиотеки в этом случае не имеет смысла ... более того это накладно.

Кстати нет постановки задачи, поэтому не ясно, что накладно а что не
накладно.  Несколько иксовых библиотек не более накладно, чем glibc.
libX11.so.6 занимает места меньше, чем libc.so.6.  Если экономия нужна
до такой степени, то ембедовщину нужно делать на uClibc.

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

> > > По сути в этом случае библиотеки будут замещать друг друга так как API
> > > и ABI у них не должен меняться.
> > 
> > Я посмотрел наугад несколько гетэкакашных приложений, они все с иксами
> > слинкованы.
> 
> Они все были в режиме --as-needed слинкованы?

Может и нет.  Но вот vim я совсем недавно обновлял.

$ rpm -q --lastchange vim-X11-gtk2 |head -c 33
* Sun Aug 13 2006 Sir Raorn <raor%
$ rpm -qR vim-X11-gtk2 |grep libX             
libX11.so.6  
libXt.so.6  
$

А вот в perl-Gtk2 теперь всё по-честному; но в одной из предыдущих
версий завязки на иксы там были.

$ rpm -qR perl-Gtk2 |grep libX
$

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

Re: [devel] Gtk+ и DirectFB

[Vitaly Lipatov]

On Tuesday 29 August 2006 00:42, Alexey Tourbin wrote:
...
> Короче непонятно зачем предлагается всё переделать, причем в
> первую очередь системные библиотеки -- при том, что наработки,
> которые могли бы оправдать такие изменения, отсутствуют
> (насколько я понимаю).
Собственно я как раз за то, чтобы ничего не переделывать. 
Возможно, добавить несколько пакетов в Сизиф, позволяющих 
использовать gtk-directfb.
А наработки возникнуть не могли по причине отсутствия 
gtk-directfb в природе ;)

Кроме того, эксперименты с другим backend для gtk должно выявить 
разные замаскированные недоделки в программах (как мне кажется, 
требование иксов в gtk-программе это либо ошибка, либо хак, 
потому что вполне можно обойтись самой gtk).

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Vitaly Lipatov пишет:
> On Tuesday 29 August 2006 00:42, Alexey Tourbin wrote:
> ...
>> Короче непонятно зачем предлагается всё переделать, причем в
>> первую очередь системные библиотеки -- при том, что наработки,
>> которые могли бы оправдать такие изменения, отсутствуют
>> (насколько я понимаю).
> Собственно я как раз за то, чтобы ничего не переделывать. 
> Возможно, добавить несколько пакетов в Сизиф, позволяющих 
> использовать gtk-directfb.

+1

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [060829 00:45]:
> Может и нет.  Но вот vim я совсем недавно обновлял.
> $ rpm -q --lastchange vim-X11-gtk2 |head -c 33
> * Sun Aug 13 2006 Sir Raorn <raor%
> $ rpm -qR vim-X11-gtk2 |grep libX             
> libX11.so.6  
> libXt.so.6  
> $
Да, vim их хочет.  Для client-server через эвенты.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] Gtk+ и DirectFB

[Dmitry V. Levin]

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

On Mon, Aug 28, 2006 at 12:29:02PM +0400, Alexey Gladkov wrote:
> Alexey Tourbin пишет:
> > Я тоже хотел поковырять directfb, но я не умею его тестировать.
> > Сходу претензии к нему такие: soname привязн к версии; если бинарная
> > совместимость сохраняется, то можно вписать в Provides старый soname.
> > В пакете libdirectfb самый большой файл -- ChangeLog; при том, что также
> > имеется файл NEWS, паковать ChangeLog точно не стоит.  Low-level ChangeLog
> > в пакете нужен не больше, чем исходники.  Кстати это касается всех пакетов.
> 
> Думаю, это можно пофиксить.

Что касается ChangeLog'ов, то они бывают разные.  Иногда стоит пожать и
упаковать, иногда достаточно файла NEWS.

Что касается soname, то если ABI не меняется, то можно, конечно, отвязать
его от версии.  Важно понять, почему upstream этого не делает.  Если по
незнанию, то можно и проинформировать.  В любом случае придётся
самостоятельно отслеживать изменения в ABI.


-- 
ldv

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

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Dmitry V. Levin пишет:
> Что касается soname, то если ABI не меняется, то можно, конечно, отвязать
> его от версии.  Важно понять, почему upstream этого не делает.  Если по
> незнанию, то можно и проинформировать.  В любом случае придётся
> самостоятельно отслеживать изменения в ABI.

Вот их логика:
#
# Making releases:
#   DIRECTFB_MICRO_VERSION += 1;
#   DIRECTFB_INTERFACE_AGE += 1;
#   DIRECTFB_BINARY_AGE += 1;
# if any functions have been added, set DIRECTFB_INTERFACE_AGE to 0.
# if backwards compatibility has been broken,
# set DIRECTFB_BINARY_AGE and DIRECTFB_INTERFACE_AGE to 0.
#
#
DIRECTFB_MAJOR_VERSION=0
DIRECTFB_MINOR_VERSION=9
DIRECTFB_MICRO_VERSION=25
DIRECTFB_INTERFACE_AGE=0
DIRECTFB_BINARY_AGE=0

Новая версия будет libdirectfb-0.9.so.25.0.0 .

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Dmitry V. Levin]

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

On Sat, Sep 02, 2006 at 03:33:59AM +0400, Alexey Gladkov wrote:
> Dmitry V. Levin пишет:
> > Что касается soname, то если ABI не меняется, то можно, конечно, отвязать
> > его от версии.  Важно понять, почему upstream этого не делает.  Если по
> > незнанию, то можно и проинформировать.  В любом случае придётся
> > самостоятельно отслеживать изменения в ABI.
> 
> Вот их логика:
> #
> # Making releases:
> #   DIRECTFB_MICRO_VERSION += 1;
> #   DIRECTFB_INTERFACE_AGE += 1;
> #   DIRECTFB_BINARY_AGE += 1;
> # if any functions have been added, set DIRECTFB_INTERFACE_AGE to 0.
> # if backwards compatibility has been broken,
> # set DIRECTFB_BINARY_AGE and DIRECTFB_INTERFACE_AGE to 0.

Где-то я это уже видел, только более правильно и подробно:
$ info libtool 'Updating version info'

> DIRECTFB_MAJOR_VERSION=0
> DIRECTFB_MINOR_VERSION=9
> DIRECTFB_MICRO_VERSION=25
> DIRECTFB_INTERFACE_AGE=0
> DIRECTFB_BINARY_AGE=0
> 
> Новая версия будет libdirectfb-0.9.so.25.0.0 .

Поскольку directfb для сборки использует libtool, мне очевидно что
upstream недочитал вышеупомянутое info.  Кто-то должен сделать это
вместо них.


-- 
ldv

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