[devel] I: x86_64 update

[devel] I: x86_64 update

[Anton D. Kachalov]

Hi all!
Итак, на ftp://ftp.altlinux.ru/pub/people/mouse/Sisyphus/files/ доступен
небольшой Сизифчик под сабжевую архитектуру. В себя включает новый(!)
rpm-4.4-0.9 и хэшер, способный юзать этим rpm'ом ;)
Здесь ftp://ftp.altlinux.ru/pub/people/mouse/smp-alt10/ и up-alt10.
UP-ядро лучше для использования вместе с fglrx (иксовые либы тащим
отдельно), т.к. в smp был глюк в конфиге ядра с компиляцией agpgart'а вовнутрь.
Некоторые базовые пакеты имеют неудовлетворённые зависимости на модули pam.
А так же пакеты, завязанные на X11, т.к. Добавление в requires и provides
'(64bit)' появилось позже. Часть пакетов было собрано ручками с --nodeps.
Многие пакеты требовали напильника. На стружки смотрим здесь:
ftp://ftp.altlinux.ru/pub/people/mouse/patches/
Там же лежит файлик list, в котором живёт список багов на эту тему
(правда, его пора уже немного обновлять).
Отличие old от new только в том, что в old - патчи, которые были засланы в
багзиллу, а в new - либо ещё нет, либо обновлённые патчи.

Прошу обратить внимание на %_lib (многие используют /lib за что ссылаются
в багзиллу), %_libdir и...%_x11libdir, про который я писал раньше, но так
ничего в ответ и не услышал. Последний держит пересборку xorg-x11 и всё
остальное.

PS. Некое подобие README:
ftp://ftp.altlinux.ru/pub/people/mouse/Sisyphus/files/x86_64/README

PPS. Также встаёт остро вопрос с multilib'ом. Многие библиотечные пакеты
содержат не только библиотеки и их одновременное присутствие в системе
становится невозможным, например, glibc-core, в котором есть ldconfig,
etc...

2мантейнеры: Господа, используйте libdir по назначению!

Rgds,
Anton

Re: [devel] I: x86_64 update

[Kirill A. Shutemov]

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

On Thu, Jan 27, 2005 at 09:18:59PM +0300, Anton D. Kachalov wrote:
> Hi all!
> небольшой Сизифчик под сабжевую архитектуру. В себя включает новый(!)
> rpm-4.4-0.9 и хэшер, способный юзать этим rpm'ом ;)
А когда этот армагедец ждать в Сизифе?

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

Если у кого-то есть работающий ftp-сервер, это не значит, что именно этот
ftp-сервер должен быть в Сизифе.
		-- ldv in devel@

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

Re: [devel] I: x86_64 update

[Mikhail Zabaluev]

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

В Чтв, 27/01/2005 в 21:18 +0300, Anton D. Kachalov пишет:
> PPS. Также встаёт остро вопрос с multilib'ом. Многие библиотечные пакеты
> содержат не только библиотеки и их одновременное присутствие в системе
> становится невозможным, например, glibc-core, в котором есть ldconfig,
> etc...
> 
> 2мантейнеры: Господа, используйте libdir по назначению!

Проблема только с библиотечными пакетами?
А что мешает ставить библиотеки в /usr/lib, раз уж пакет собран под
конкретную архитектуру и rpm не попустит использования его в
несовместимых архитектурах?

Кстати, какой это %_arch? Спрашиваю к тому, что когда-нибудь в swt и
eclipse придется поддержать вариант сборки с архитектурой amd64 (по их
терминологии).


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: x86_64 update

[Anton Farygin]

Kirill A. Shutemov wrote:

>On Thu, Jan 27, 2005 at 09:18:59PM +0300, Anton D. Kachalov wrote:
>  
>
>>Hi all!
>>небольшой Сизифчик под сабжевую архитектуру. В себя включает новый(!)
>>rpm-4.4-0.9 и хэшер, способный юзать этим rpm'ом ;)
>>    
>>
>А когда этот армагедец ждать в Сизифе?
>
>  
>
Давайте для начала чуть чуть переживем последствия нового gcc ;-)

Rgds,
Rider

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Fri, Jan 28, 2005 at 12:36:29PM +0300, Anton Farygin wrote:
> Kirill A. Shutemov wrote:
> 
> >On Thu, Jan 27, 2005 at 09:18:59PM +0300, Anton D. Kachalov wrote:
> > 
> >
> >>Hi all!
> >>небольшой Сизифчик под сабжевую архитектуру. В себя включает новый(!)
> >>rpm-4.4-0.9 и хэшер, способный юзать этим rpm'ом ;)
> >>   
> >>
> >А когда этот армагедец ждать в Сизифе?
> >
> > 
> >
> Давайте для начала чуть чуть переживем последствия нового gcc ;-)

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

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Fri, Jan 28, 2005 at 12:12:05PM +0300, Mikhail Zabaluev wrote:
> В Чтв, 27/01/2005 в 21:18 +0300, Anton D. Kachalov пишет:
> > PPS. Также встаёт остро вопрос с multilib'ом. Многие библиотечные пакеты
> > содержат не только библиотеки и их одновременное присутствие в системе
> > становится невозможным, например, glibc-core, в котором есть ldconfig,
> > etc...
> > 
> > 2мантейнеры: Господа, используйте libdir по назначению!
> 
> Проблема только с библиотечными пакетами?
> А что мешает ставить библиотеки в /usr/lib, раз уж пакет собран под
> конкретную архитектуру и rpm не попустит использования его в
> несовместимых архитектурах?
Есть ещё пакеты, которые кладут noarch в %_libdir,а не в %_datadir
В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
системе могут присутствовать одни и те же пакеты, только разных
архитектур. Но некоторые такие пакеты содержат ещё и исполняемые файлы
вместе с либами. Т.ч. пора вешать баги на пакеты, в которых есть
библиотеки и не библиотеки.

> 
> Кстати, какой это %_arch? Спрашиваю к тому, что когда-нибудь в swt и
> eclipse придется поддержать вариант сборки с архитектурой amd64 (по их
> терминологии).
x86_64

Rgds,
Anton

Re: [devel] I: x86_64 update

[Mikhail Zabaluev]

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

В Птн, 28/01/2005 в 14:23 +0300, Anton D. Kachalov пишет:
> Есть ещё пакеты, которые кладут noarch в %_libdir,а не в %_datadir
> В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
> системе могут присутствовать одни и те же пакеты, только разных
> архитектур.

Это зачем?

> Но некоторые такие пакеты содержат ещё и исполняемые файлы
> вместе с либами. Т.ч. пора вешать баги на пакеты, в которых есть
> библиотеки и не библиотеки.

Ага. Значит, в libification появился дополнительный резон.


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Fri, Jan 28, 2005 at 02:36:30PM +0300, Mikhail Zabaluev wrote:
> В Птн, 28/01/2005 в 14:23 +0300, Anton D. Kachalov пишет:
> > Есть ещё пакеты, которые кладут noarch в %_libdir,а не в %_datadir
> > В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
> > системе могут присутствовать одни и те же пакеты, только разных
> > архитектур.
> 
> Это зачем?
что зачем? зачем в системе пакеты разных архитектур? берём тот же amd64,
который в нативном умеет эмулировать ia32. Продолжать? :)

Rgds,
Anton

Re: [devel] I: x86_64 update

[Denis Smirnov]

On Thu, Jan 27, 2005 at 09:18:59PM +0300, Anton D. Kachalov wrote:

ADK> Итак, на ftp://ftp.altlinux.ru/pub/people/mouse/Sisyphus/files/ доступен
ADK> небольшой Сизифчик под сабжевую архитектуру. В себя включает новый(!)
ADK> rpm-4.4-0.9 и хэшер, способный юзать этим rpm'ом ;)

Ур-р-р-р-ра! 

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

http://freesource.info

Re: [devel] I: x86_64 update

[Mikhail Zabaluev]

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

В Птн, 28/01/2005 в 17:22 +0300, Anton D. Kachalov пишет:
> > > В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
> > > системе могут присутствовать одни и те же пакеты, только разных
> > > архитектур.
> > 
> > Это зачем?
> что зачем? зачем в системе пакеты разных архитектур? берём тот же amd64,
> который в нативном умеет эмулировать ia32. Продолжать? :)

Берем и заменяем пакеты архитектуры ia32 на x86_64, лежащие там же. Или
наоборот. Какой смысл в наличии двух вариантов библиотеки, если одна из
них гарантированно не используется без специальных ухищрений с ld.so?
Точно так же, как пересобирать для себя пакеты под pentium4: никто не
даст гарантии, что они будут работать на i586, однако отдельных папок
под это дело не заводится.


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sat, Jan 29, 2005 at 03:18:25AM +0300, Mikhail Zabaluev wrote:
> В Птн, 28/01/2005 в 17:22 +0300, Anton D. Kachalov пишет:
> > > > В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
> > > > системе могут присутствовать одни и те же пакеты, только разных
> > > > архитектур.
> > > 
> > > Это зачем?
> > что зачем? зачем в системе пакеты разных архитектур? берём тот же amd64,
> > который в нативном умеет эмулировать ia32. Продолжать? :)
> 
> Берем и заменяем пакеты архитектуры ia32 на x86_64, лежащие там же. Или
> наоборот. Какой смысл в наличии двух вариантов библиотеки, если одна из
> них гарантированно не используется без специальных ухищрений с ld.so?
> Точно так же, как пересобирать для себя пакеты под pentium4: никто не
> даст гарантии, что они будут работать на i586, однако отдельных папок
> под это дело не заводится.

а если я хочу запускать проприетарный софт, который только под ia32? а
этот софт тянет gtk, например. И что? Одно дело оптимизация под конкретный
камень, как например pentium4 и i586, а другое дело разные архитектуры
ia32 и x86_64. И ia32 / x86_64 - не единственное multilib-сочетание.
Тогда, спрашивается, зачем в gcc есть поддержка multilib, зачем SuSE, RH
создают lib64, почему тогда та же ATI держит модули именно в
/usr/X11R6/lib64 ? FHS? Там вроде бы /usr/libexec'а уже нет...да и как там
дела с /media, /sys, /swap?
Да и директории уже заведены (обращаем внимание на пакет filesystem, который давно в Сизифе).

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Fri, Jan 28, 2005 at 07:22:44PM +0300, Denis Smirnov wrote:
> On Thu, Jan 27, 2005 at 09:18:59PM +0300, Anton D. Kachalov wrote:
> 
> ADK> Итак, на ftp://ftp.altlinux.ru/pub/people/mouse/Sisyphus/files/ доступен
> ADK> небольшой Сизифчик под сабжевую архитектуру. В себя включает новый(!)
> ADK> rpm-4.4-0.9 и хэшер, способный юзать этим rpm'ом ;)
> 
> Ур-р-р-р-ра! 

Сегодня-завтра туда уедет пересобранный tcl,tk,bind...а дальше видно
будет. Сейчас начну перелапачивать xorg на предмет %_x11libdir с
развешиванием багов на пакеты.

Rgds,
Anton

Re: [devel] I: x86_64 update

[Denis Smirnov]

On Sat, Jan 29, 2005 at 07:15:15PM +0300, Anton D. Kachalov wrote:

> ADK>> Итак, на ftp://ftp.altlinux.ru/pub/people/mouse/Sisyphus/files/ доступен
> ADK>> небольшой Сизифчик под сабжевую архитектуру. В себя включает новый(!)
> ADK>> rpm-4.4-0.9 и хэшер, способный юзать этим rpm'ом ;)
>> Ур-р-р-р-ра! 
ADK> Сегодня-завтра туда уедет пересобранный tcl,tk,bind...а дальше видно
ADK> будет. Сейчас начну перелапачивать xorg на предмет %_x11libdir с
ADK> развешиванием багов на пакеты.

После этого я, наверное, опять в гости приеду. Дабы поставить сие счастье
уже на ноутбук и играться более серьёзно (ту машину на которой я раньше
игрался сейчас использовть для игр с x86_64 не могу).

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

http://freesource.info

Re: [devel] I: x86_64 update

[Andrey Rahmatullin]

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

On Sat, Jan 29, 2005 at 07:13:39PM +0300, Anton D. Kachalov wrote:
> дела с /media,
Оно как раз из FHS2.3 к нам и пришло.

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

Вы забыли в sources.list указать компоненту "nonfree".
Это типовые грабли, по ним уже в офисе прошлись.
		-- ldv in community@

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

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sat, Jan 29, 2005 at 09:43:12PM +0500, Andrey Rahmatullin wrote:
> On Sat, Jan 29, 2005 at 07:13:39PM +0300, Anton D. Kachalov wrote:
> > дела с /media,
> Оно как раз из FHS2.3 к нам и пришло.
да, оно есть, но /sys нет. А насчёт lib64:
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
Т.ч.я не вижу основания для возмущений на тему lib64.

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sat, Jan 29, 2005 at 07:22:44PM +0300, Denis Smirnov wrote:
> On Sat, Jan 29, 2005 at 07:15:15PM +0300, Anton D. Kachalov wrote:
> 
> > ADK>> Итак, на ftp://ftp.altlinux.ru/pub/people/mouse/Sisyphus/files/ доступен
> > ADK>> небольшой Сизифчик под сабжевую архитектуру. В себя включает новый(!)
> > ADK>> rpm-4.4-0.9 и хэшер, способный юзать этим rpm'ом ;)
> >> Ур-р-р-р-ра! 
> ADK> Сегодня-завтра туда уедет пересобранный tcl,tk,bind...а дальше видно
> ADK> будет. Сейчас начну перелапачивать xorg на предмет %_x11libdir с
> ADK> развешиванием багов на пакеты.
> 
> После этого я, наверное, опять в гости приеду. Дабы поставить сие счастье
> уже на ноутбук и играться более серьёзно (ту машину на которой я раньше
> игрался сейчас использовть для игр с x86_64 не могу).
оки :)
ut2004 весьма неплохо себя ведёт. Тока памяти уж очень много хочет :(

Rgds,
Anton

Re: [devel] I: x86_64 update

[Denis Smirnov]

On Sat, Jan 29, 2005 at 07:54:49PM +0300, Anton D. Kachalov wrote:

>> После этого я, наверное, опять в гости приеду. Дабы поставить сие счастье
>> уже на ноутбук и играться более серьёзно (ту машину на которой я раньше
>> игрался сейчас использовть для игр с x86_64 не могу).
ADK> оки :)
ADK> ut2004 весьма неплохо себя ведёт. Тока памяти уж очень много хочет :(

ut2004 на _x86-64_ ?

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

http://freesource.info

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sat, Jan 29, 2005 at 08:54:04PM +0300, Denis Smirnov wrote:
> On Sat, Jan 29, 2005 at 07:54:49PM +0300, Anton D. Kachalov wrote:
> 
> >> После этого я, наверное, опять в гости приеду. Дабы поставить сие счастье
> >> уже на ноутбук и играться более серьёзно (ту машину на которой я раньше
> >> игрался сейчас использовть для игр с x86_64 не могу).
> ADK> оки :)
> ADK> ut2004 весьма неплохо себя ведёт. Тока памяти уж очень много хочет :(
> 
> ut2004 на _x86-64_ ?

да

Rgds,
Anton

Re: [devel] I: x86_64 update

[Denis Smirnov]

On Sat, Jan 29, 2005 at 09:06:46PM +0300, Anton D. Kachalov wrote:
> >>> После этого я, наверное, опять в гости приеду. Дабы поставить сие счастье
> >>> уже на ноутбук и играться более серьёзно (ту машину на которой я раньше
> >>> игрался сейчас использовть для игр с x86_64 не могу).
> ADK>> оки :)
> ADK>> ut2004 весьма неплохо себя ведёт. Тока памяти уж очень много хочет :(
>> ut2004 на _x86-64_ ?
ADK> да

Вау! Она есть в смысле родная под x86_64-linux?

Тогда я точно скоро приеду в гости :)

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

http://freesource.info

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sat, Jan 29, 2005 at 03:18:25AM +0300, Mikhail Zabaluev wrote:
> В Птн, 28/01/2005 в 17:22 +0300, Anton D. Kachalov пишет:
> > > > В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
> > > > системе могут присутствовать одни и те же пакеты, только разных
> > > > архитектур.
> > > 
> > > Это зачем?
> > что зачем? зачем в системе пакеты разных архитектур? берём тот же amd64,
> > который в нативном умеет эмулировать ia32. Продолжать? :)
> 
> Берем и заменяем пакеты архитектуры ia32 на x86_64, лежащие там же. Или
> наоборот. Какой смысл в наличии двух вариантов библиотеки, если одна из
> них гарантированно не используется без специальных ухищрений с ld.so?
> Точно так же, как пересобирать для себя пакеты под pentium4: никто не
> даст гарантии, что они будут работать на i586, однако отдельных папок
> под это дело не заводится.

Кстати, что подразумевается под "специальными ухищрениями с ld.so"? :)
Ничего специального там нет. ldconfig (из 64bit'ой glibc) прекрасно рулит
и теми и другими либами.

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton Farygin]

Mikhail Zabaluev wrote:

>В Птн, 28/01/2005 в 14:23 +0300, Anton D. Kachalov пишет:
>  
>
>>Есть ещё пакеты, которые кладут noarch в %_libdir,а не в %_datadir
>>В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
>>системе могут присутствовать одни и те же пакеты, только разных
>>архитектур.
>>    
>>
>
>Это зачем?
>  
>
Для одновременной работы 64-х и 32-х bit приложений.

>  
>
>>Но некоторые такие пакеты содержат ещё и исполняемые файлы
>>вместе с либами. Т.ч. пора вешать баги на пакеты, в которых есть
>>библиотеки и не библиотеки.
>>    
>>
>
>Ага. Значит, в libification появился дополнительный резон.
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Devel mailing list
>Devel@altlinux.ru
>https://lists.altlinux.ru/mailman/listinfo/devel
>

Re: [devel] I: x86_64 update

[Anton Farygin]

Mikhail Zabaluev wrote:

>В Птн, 28/01/2005 в 17:22 +0300, Anton D. Kachalov пишет:
>  
>
>>>>В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
>>>>системе могут присутствовать одни и те же пакеты, только разных
>>>>архитектур.
>>>>        
>>>>
>>>Это зачем?
>>>      
>>>
>>что зачем? зачем в системе пакеты разных архитектур? берём тот же amd64,
>>который в нативном умеет эмулировать ia32. Продолжать? :)
>>    
>>
>
>Берем и заменяем пакеты архитектуры ia32 на x86_64, лежащие там же. Или
>наоборот. Какой смысл в наличии двух вариантов библиотеки, если одна из
>них гарантированно не используется без специальных ухищрений с ld.so?
>Точно так же, как пересобирать для себя пакеты под pentium4: никто не
>даст гарантии, что они будут работать на i586, однако отдельных папок
>под это дело не заводится.
>  
>
А как заменять runtime ?

Rgds,
Rider

Re: [devel] I: x86_64 update

[Mikhail Zabaluev]

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

В Вск, 30/01/2005 в 11:20 +0300, Anton Farygin пишет:
> Mikhail Zabaluev wrote:
> 
> >В Птн, 28/01/2005 в 14:23 +0300, Anton D. Kachalov пишет:
> >  
> >
> >>Есть ещё пакеты, которые кладут noarch в %_libdir,а не в %_datadir
> >>В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
> >>системе могут присутствовать одни и те же пакеты, только разных
> >>архитектур.
> >>    
> >>
> >
> >Это зачем?
> >  
> >
> Для одновременной работы 64-х и 32-х bit приложений.

Я не совсем понимаю, как ld.so в 64bit приложениях будет искать
библиотеки в lib64, а в 32bit -- не будет. Но, видимо, ответ на этот
вопрос есть. Иначе в _одновременном_ присутствии библиотек все равно нет
практического смысла.
Ну хорошо, с библиотеками понятно. Но небиблиотечные бинарные пакеты все
равно не удастся развести по архитектурам.


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sun, Jan 30, 2005 at 02:37:17PM +0300, Mikhail Zabaluev wrote:
> В Вск, 30/01/2005 в 11:20 +0300, Anton Farygin пишет:
> > Mikhail Zabaluev wrote:
> > 
> > >В Птн, 28/01/2005 в 14:23 +0300, Anton D. Kachalov пишет:
> > >  
> > >
> > >>Есть ещё пакеты, которые кладут noarch в %_libdir,а не в %_datadir
> > >>В случае multilib, класть 64bit нужно в lib64, а 32 в lib. При этом в
> > >>системе могут присутствовать одни и те же пакеты, только разных
> > >>архитектур.
> > >>    
> > >>
> > >
> > >Это зачем?
> > >  
> > >
> > Для одновременной работы 64-х и 32-х bit приложений.
> 
> Я не совсем понимаю, как ld.so в 64bit приложениях будет искать
> библиотеки в lib64, а в 32bit -- не будет. Но, видимо, ответ на этот
> вопрос есть. Иначе в _одновременном_ присутствии библиотек все равно нет
> практического смысла.
> Ну хорошо, с библиотеками понятно. Но небиблиотечные бинарные пакеты все
> равно не удастся развести по архитектурам.
> 
$ uname -m
x86_64
$ /sbin/ldconfig -p|grep libbeecrypt
        libbeecrypt.so.6 (libc6,x86-64) => /usr/lib64/libbeecrypt.so.6
        libbeecrypt.so.2 (libc6) => /usr/lib/libbeecrypt.so.2
        libbeecrypt.so (libc6,x86-64) => /usr/lib64/libbeecrypt.so
но это умеет только 64bit ldconfig
А зачем библиотечные бинарные пакеты разводить по архитектурам? И что
вообще подразумевается под "библиотечными бинарными пакетами"? В чём
отличие от обычных бинарных пакетов?

Rgds,
Anton


> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> https://lists.altlinux.ru/mailman/listinfo/devel

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

Итак, очередное небольшое обновление.
Обновил tcl. Tk так и осталось старым из-за непересобираемости Xorg (для
библиотек пропадает PIC при компиляции). А ещё обновил freetype &
fontconfig.
Ядро теперь собрано штатными средствами. Есть up и smp 2.6.10.
Из /people/mouse/ я убрал директории smp-alt10 и up-alt10.

2devel-kernel: как собирать модулю в хэшере (или ещё как) под определённую
версию ядра без модификации src.rpm?

PS. следующая итерация будет с новым Xorg и всеми вытекающими.
PPS. прошу заметить, что Сизифчик тож перешёл на gcc3.4 =)

Rgds,
Anton

[devel] Re: I: x86_64 update

[Konstantin A. Lepikhov]

Hi Anton!

Monday 31, at 10:42:19 PM you wrote:

<skip>
> Итак, очередное небольшое обновление.
> Обновил tcl. Tk так и осталось старым из-за непересобираемости Xorg (для
> библиотек пропадает PIC при компиляции). А ещё обновил freetype &
> fontconfig.
а там как раз не тот ли патчик нужен, что gentoo взяла из debian (который
062_make_libGL_PIC_compliant)?

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

Re: [devel] Re: I: x86_64 update

[Anton D. Kachalov]

On Mon, Jan 31, 2005 at 11:10:46PM +0300, Konstantin A. Lepikhov wrote:
> Hi Anton!
> 
> Monday 31, at 10:42:19 PM you wrote:
> 
> <skip>
> > Итак, очередное небольшое обновление.
> > Обновил tcl. Tk так и осталось старым из-за непересобираемости Xorg (для
> > библиотек пропадает PIC при компиляции). А ещё обновил freetype &
> > fontconfig.
> а там как раз не тот ли патчик нужен, что gentoo взяла из debian (который
> 062_make_libGL_PIC_compliant)?

libGL вроде нормально собирается. Раньше с ней были проблемы. Сейчас
сборка падает на libXfont и ещё какой-то либе.

Rgds,
Anton

Re: [devel] Re: I: x86_64 update

[Anton D. Kachalov]

On Mon, Jan 31, 2005 at 11:14:13PM +0300, Anton D. Kachalov wrote:
> On Mon, Jan 31, 2005 at 11:10:46PM +0300, Konstantin A. Lepikhov wrote:
> > Hi Anton!
> > 
> > Monday 31, at 10:42:19 PM you wrote:
> > 
> > <skip>
> > > Итак, очередное небольшое обновление.
> > > Обновил tcl. Tk так и осталось старым из-за непересобираемости Xorg (для
> > > библиотек пропадает PIC при компиляции). А ещё обновил freetype &
> > > fontconfig.
> > а там как раз не тот ли патчик нужен, что gentoo взяла из debian (который
> > 062_make_libGL_PIC_compliant)?
> 
> libGL вроде нормально собирается. Раньше с ней были проблемы. Сейчас
> сборка падает на libXfont и ещё какой-то либе.
я могу даже точно сказать:
#define SharedXfontReqs  stubs/libfntstubs.a -L%_libdir -lfreetype -lm
вот эта строчка в спеке всё и ломает. Точнее, линковка c libfntstubs.a

Rgds,
Anton

Re: [devel] I: x86_64 update

[Mikhail Zabaluev]

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

В Пнд, 31/01/2005 в 00:37 +0300, Anton D. Kachalov пишет:
> > Я не совсем понимаю, как ld.so в 64bit приложениях будет искать
> > библиотеки в lib64, а в 32bit -- не будет. Но, видимо, ответ на этот
> > вопрос есть. Иначе в _одновременном_ присутствии библиотек все равно нет
> > практического смысла.
> > Ну хорошо, с библиотеками понятно. Но небиблиотечные бинарные пакеты все
> > равно не удастся развести по архитектурам.
> > 
> $ uname -m
> x86_64
> $ /sbin/ldconfig -p|grep libbeecrypt
>         libbeecrypt.so.6 (libc6,x86-64) => /usr/lib64/libbeecrypt.so.6
>         libbeecrypt.so.2 (libc6) => /usr/lib/libbeecrypt.so.2
>         libbeecrypt.so (libc6,x86-64) => /usr/lib64/libbeecrypt.so
> но это умеет только 64bit ldconfig
> А зачем библиотечные бинарные пакеты разводить по архитектурам? И что
> вообще подразумевается под "библиотечными бинарными пакетами"? В чём
> отличие от обычных бинарных пакетов?

НЕбиблиотечными.
То есть libfoo.so.1 я еще смогу установить для x86_64 одновременно с
вариантом для i586, а с /usr/bin/foo придется выбирать. Оно, конечно,
вещь стоящий код в наше время вынесен в библиотеки, ан все равно обидно.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Tue, Feb 01, 2005 at 02:33:58AM +0300, Mikhail Zabaluev wrote:
> В Пнд, 31/01/2005 в 00:37 +0300, Anton D. Kachalov пишет:
> > > Я не совсем понимаю, как ld.so в 64bit приложениях будет искать
> > > библиотеки в lib64, а в 32bit -- не будет. Но, видимо, ответ на этот
> > > вопрос есть. Иначе в _одновременном_ присутствии библиотек все равно нет
> > > практического смысла.
> > > Ну хорошо, с библиотеками понятно. Но небиблиотечные бинарные пакеты все
> > > равно не удастся развести по архитектурам.
> > > 
> > $ uname -m
> > x86_64
> > $ /sbin/ldconfig -p|grep libbeecrypt
> >         libbeecrypt.so.6 (libc6,x86-64) => /usr/lib64/libbeecrypt.so.6
> >         libbeecrypt.so.2 (libc6) => /usr/lib/libbeecrypt.so.2
> >         libbeecrypt.so (libc6,x86-64) => /usr/lib64/libbeecrypt.so
> > но это умеет только 64bit ldconfig
> > А зачем библиотечные бинарные пакеты разводить по архитектурам? И что
> > вообще подразумевается под "библиотечными бинарными пакетами"? В чём
> > отличие от обычных бинарных пакетов?
> 
> НЕбиблиотечными.
> То есть libfoo.so.1 я еще смогу установить для x86_64 одновременно с
> вариантом для i586, а с /usr/bin/foo придется выбирать. Оно, конечно,
> вещь стоящий код в наше время вынесен в библиотеки, ан все равно обидно.
для бинарей всё однозначно =)
поэтому и выносить нужно из библиотек как бинари, так и дата-файлы.

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Mon, Jan 31, 2005 at 10:42:19PM +0300, Anton D. Kachalov wrote:
> 2devel-kernel: как собирать модулю в хэшере (или ещё как) под определённую
> версию ядра без модификации src.rpm?
с этим я разобрался %)

Rgds,
Anton

[devel] I: x86_64 update

[Anton D. Kachalov]

Очередное обновление поступит сегодня ночью :)
Xorg 6.8.2.RC3
tk
tetex-*
и ещё небольшая кучка всякого.
На данный момент, Сизифчик занимает почти 500 Мб и содержит чуть более 700
пакетов.
Растём-с :)

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton Farygin]

Anton D. Kachalov wrote:

>Очередное обновление поступит сегодня ночью :)
>Xorg 6.8.2.RC3
>tk
>tetex-*
>и ещё небольшая кучка всякого.
>На данный момент, Сизифчик занимает почти 500 Мб и содержит чуть более 700
>пакетов.
>Растём-с :)
>
>  
>
IMHO надо не там расти, а делать полноценный репозитарий с другой 
архитектурой в текущем Sisyphus.

Rgds,
Rider

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Wed, Feb 02, 2005 at 01:01:31PM +0300, Anton Farygin wrote:
> Anton D. Kachalov wrote:
> 
> >Очередное обновление поступит сегодня ночью :)
> >Xorg 6.8.2.RC3
> >tk
> >tetex-*
> >и ещё небольшая кучка всякого.
> >На данный момент, Сизифчик занимает почти 500 Мб и содержит чуть более 700
> >пакетов.
> >Растём-с :)
> >
> > 
> >
> IMHO надо не там расти, а делать полноценный репозитарий с другой 
> архитектурой в текущем Sisyphus.

тогда мантейнеры должны лучше пинаться.
или баги делать block :)

Плюс ко всему, нужно переводить сборку прог на kernel-headers от 2.6.
Сейчас с этим беда.

И собирать такой Сизиф нужно на полноценной машинkе, а не на ноуте :)

Rgds,
Anton

Re: [devel] I: x86_64 update

[Vital Khilko]

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

On Срд, 2005-02-02 at 14:16 +0300, Anton D. Kachalov wrote:

> тогда мантейнеры должны лучше пинаться.
> или баги делать block :)
при наличии полноценного репозитария в Сизифе для x86_64 готов лучше
отвечать на пинки =)

[-- Attachment #2: Гэтая частка паведамленьня падпісана электроным подпісам --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: x86_64 update

[Vitaly Lipatov]

On Wednesday 02 February 2005 14:16, Anton D. Kachalov wrote:

> И собирать такой Сизиф нужно на полноценной машинkе, а не на
> ноуте :)
Только не говорите, что собирать такой Сизиф надо именно на 
x86_64-машине.
А когда это будет полноценный репозиторий, в том плане, что 
пакеты будут пересобираться и под эту архитектуру, баги о 
непересобираемости должны сами потечь к мантейнерам. См. Debian, 
разве нет?

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

Re: [devel] I: x86_64 update

[Vital Khilko]

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

On Чцв, 2005-02-03 at 01:01 +0300, Vitaly Lipatov wrote:
> On Wednesday 02 February 2005 14:16, Anton D. Kachalov wrote:
> 
> > И собирать такой Сизиф нужно на полноценной машинkе, а не на
> > ноуте :)
> Только не говорите, что собирать такой Сизиф надо именно на 
> x86_64-машине.
именно только на x86_64 , кросскомпилинг страшная и невсегда работающая
штука

[-- Attachment #2: Гэтая частка паведамленьня падпісана электроным подпісам --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: x86_64 update

[Vitaly Lipatov]

On Thursday 03 February 2005 10:21, Vital Khilko wrote:
> On Чцв, 2005-02-03 at 01:01 +0300, Vitaly Lipatov wrote:
> > On Wednesday 02 February 2005 14:16, Anton D. Kachalov wrote:
> > > И собирать такой Сизиф нужно на полноценной машинkе, а не
> > > на ноуте :)
> >
> > Только не говорите, что собирать такой Сизиф надо именно на
> > x86_64-машине.
>
> именно только на x86_64 , кросскомпилинг страшная и невсегда
> работающая штука
Не вижу объективных причин. Мне кажется, как к нему относишься, 
так он и работает. А основная причина может в том, что мысли о 
том, что в Сизифе должен быть кросскомпилятор (кроме mingw) - 
нет.

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

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Thu, Feb 03, 2005 at 01:01:29AM +0300, Vitaly Lipatov wrote:
> On Wednesday 02 February 2005 14:16, Anton D. Kachalov wrote:
> 
> > И собирать такой Сизиф нужно на полноценной машинkе, а не на
> > ноуте :)
> Только не говорите, что собирать такой Сизиф надо именно на 
> x86_64-машине.
а вот возьму и скажу!
да, именно так :) не кроссом же?

> А когда это будет полноценный репозиторий, в том плане, что 
> пакеты будут пересобираться и под эту архитектуру, баги о 
> непересобираемости должны сами потечь к мантейнерам. См. Debian, 
> разве нет?
а пакеты и так многие пересобираются под эту архитектуру. Проблемы обычно
возникают с системными пакетами и теми, что используют kernel-headers от
2.4...
А логи и так сыпятся...только пока о i386-архитектуре :)
А пока все проблемы пишутся в багзиллу.

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Thu, Feb 03, 2005 at 11:44:45AM +0300, Vitaly Lipatov wrote:
> > именно только на x86_64 , кросскомпилинг страшная и невсегда
> > работающая штука
> Не вижу объективных причин. Мне кажется, как к нему относишься, 
> так он и работает. А основная причина может в том, что мысли о 
> том, что в Сизифе должен быть кросскомпилятор (кроме mingw) - 
> нет.
кросс x86_64 (gcc3.3, а 3.4 я не пробовал) оооочень крив. Там нужно было
жуткое кол-во костылей вставлять, чтобы что-то собирать.
С ARM и MIPS такого секса я не ощущал, как с кроссом x86_64.
Нативная сборка всегда лучше, тем более, когда есть вычислительное
мощности. Одна из причин - это то, что хост среда отличается от таргета.
Представляем себе некую прогу, которая говорит uname -m и
ориентируется на это. А ещё есть проги (кривые), которые любят сначала
собрать прогу, а потом этой прогой заюзать для дальнейшей сборки. Опять
же, кроссовые либы живут не в /usr/lib/, а в /usr/arch/usr/lib.И опять
вспоминаем какие-нить проги, которые тож жёстко к этому привязываются. А
ещё...
И самое главное - как вы себе представляете сборку пакетов под другу
архитектуру кроссом из того же спека? (С учётом устанавливаемых пакетов в
собираемую среду). И ещё, тот же rpm не позволит поставить пакет другой
архитектуры, если ему не написать, что i586 совместим с x86_64 - бред же.

Т.ч.наличие кросса avr и mingw - всего-лишь необходимость в сборке под
девайсы (avr), на которых просто нереально что-либо собирать :))
а mingw я тож пользуюсь, но пакеты ж не собираю...и вроде пока никто не
устраивает (и не собирался вроде) отдельного cygwin-репозитария.

Rgds,
Anton

Re: [devel] I: x86_64 update

[Denis Smirnov]

On Thu, Feb 03, 2005 at 12:27:33PM +0300, Anton D. Kachalov wrote:

ADK> Представляем себе некую прогу, которая говорит uname -m и
ADK> ориентируется на это.

Выискивать и отрывать головы. Подобная сборка очень этому способствует.
У меня рабочая машина в офисе -- Athlon. Собираю я всё в hasher'е.

Так вот моя сборка Asterisk просто падала, когда я её попытался запустить
на VIA. Помедитировав чуток я обнаружил кучу этих самых uname -m, кои были
очень шустро зарезаны subst'ом.

Это мерзкие подводные грабли, которые чем раньше будут выловлены, тем
лучше.

Про остальное не говорю -- остальное реально сложные проблемы.

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

http://freesource.info

[devel] Re: I: x86_64 update

[Konstantin A. Lepikhov]

Hi Anton!

Thursday 03, at 12:27:33 PM you wrote:

<skip>
> Т.ч.наличие кросса avr и mingw - всего-лишь необходимость в сборке под
> девайсы (avr), на которых просто нереально что-либо собирать :))
> а mingw я тож пользуюсь, но пакеты ж не собираю...и вроде пока никто не
> устраивает (и не собирался вроде) отдельного cygwin-репозитария.
хм. на выходных буду пробовать повторный подход к снаряду - сборку win32
xulrunner через mingw cross. Первый подход был неудачен не по-причине
кривости компилятора и объекта сборки (хотя в configure много чего
пришлость отрывать с мясом), просто не хватило времени. Но народ в
bugzilla сообщал о том, что собирали mozilla suite без проблем.

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

[devel] A: perl-HTML-* perl-libwww #@$#!

[Anton D. Kachalov]

Сейчас буду ругаться благим матом!
Очень нравится такой расклад: для сборки perl-libwww нужен этот самый
perl-libwww (неявно, а черезе perl-HTML-Parser).
Хорошо, ставлю пакеты --nodeps и собираю perl-libwww в живой системе,
минуя хэшер. Засовываю всё это в хэшер и...опять ничего не работает:
Следующие пакеты имеют неудовлетворенные зависимости:
  perl-HTML-Parser: Требует: perl(HTTP/Headers.pm)
E: Извините, `битые' пакеты
perl(HTTP/Headers.pm) провайдится perl-libwww.
Иду разбираться: rpm -qpR perl-libwww-5.803-alt1.noarch.rpm:
...
perl(HTML/FormatPS.pm)  
perl(HTML/FormatText.pm)
...
Для сборки perl-HTML-Format нужен, в свою очередь perl-libwww, но для
того, чтобы его поставить нужен perl-HTML-Format.
И как всё это в Сизифе живёт?

Rgds,
Anton

Re: [devel] I: x86_64 update

[Vitaly Lipatov]

On Thursday 03 February 2005 12:27, Anton D. Kachalov wrote:
> И самое главное - как вы себе представляете сборку пакетов под
> другу архитектуру кроссом из того же спека? (С учётом
Спасибо за разъяснение. Теперь осознал. Свойство кругозора быть 
ограниченным вело к тому, что некоторые проблемы казались 
несущественными, или их вообще не было видно.

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

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Fri, Feb 04, 2005 at 12:03:51AM +0300, Vitaly Lipatov wrote:
> On Thursday 03 February 2005 12:27, Anton D. Kachalov wrote:
> > И самое главное - как вы себе представляете сборку пакетов под
> > другу архитектуру кроссом из того же спека? (С учётом
> Спасибо за разъяснение. Теперь осознал. Свойство кругозора быть 
> ограниченным вело к тому, что некоторые проблемы казались 
> несущественными, или их вообще не было видно.
=)
ещё как небольшой пример можно привести сборку кроссом под ARM и
нативно на ARM'e - в первом случае мне так и не удалось избавиться от
TEXTREL, а во втором всё прошло гладко.

Rgds,
Anton

[devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Alexey Tourbin]

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

On Thu, Feb 03, 2005 at 10:29:17PM +0300, Anton D. Kachalov wrote:
> Сейчас буду ругаться благим матом!
> Очень нравится такой расклад: для сборки perl-libwww нужен этот самый
> perl-libwww (неявно, а черезе perl-HTML-Parser).
> Хорошо, ставлю пакеты --nodeps и собираю perl-libwww в живой системе,
> минуя хэшер. Засовываю всё это в хэшер и...опять ничего не работает:
> Следующие пакеты имеют неудовлетворенные зависимости:
>   perl-HTML-Parser: Требует: perl(HTTP/Headers.pm)
> E: Извините, `битые' пакеты
> perl(HTTP/Headers.pm) провайдится perl-libwww.
> Иду разбираться: rpm -qpR perl-libwww-5.803-alt1.noarch.rpm:
> ...
> perl(HTML/FormatPS.pm)  
> perl(HTML/FormatText.pm)
> ...
> Для сборки perl-HTML-Format нужен, в свою очередь perl-libwww, но для
> того, чтобы его поставить нужен perl-HTML-Format.

Угу, пакеты друг от друга зависят.

> И как всё это в Сизифе живёт?

Дык можно забутстрапить.  Примерно так, как ты и описываешь: --nodeps,
--without test, --define '_perl_req_method relaxed', потом по второму
кругу, а потом уже в hasher'е.  Просто пока этого ни разу не
потребовалось.

> Rgds,
> Anton

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

[devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Alexey Tourbin]

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

On Thu, Feb 03, 2005 at 10:29:17PM +0300, Anton D. Kachalov wrote:
> Сейчас буду ругаться благим матом!
> Очень нравится такой расклад: для сборки perl-libwww нужен этот самый
> perl-libwww (неявно, а черезе perl-HTML-Parser).
> Хорошо, ставлю пакеты --nodeps и собираю perl-libwww в живой системе,
> минуя хэшер. Засовываю всё это в хэшер и...опять ничего не работает:
> Следующие пакеты имеют неудовлетворенные зависимости:
>   perl-HTML-Parser: Требует: perl(HTTP/Headers.pm)
> E: Извините, `битые' пакеты
> perl(HTTP/Headers.pm) провайдится perl-libwww.
> Иду разбираться: rpm -qpR perl-libwww-5.803-alt1.noarch.rpm:
> ...
> perl(HTML/FormatPS.pm)  
> perl(HTML/FormatText.pm)
> ...
> Для сборки perl-HTML-Format нужен, в свою очередь perl-libwww, но для
> того, чтобы его поставить нужен perl-HTML-Format.
> И как всё это в Сизифе живёт?

И вообще, из трех перечисленных пакетов бинарным является только
perl-HTML-Parser, а perl-libwww и perl-HTML-Format -- это noarch пакеты,
их по идее и пересобирать не нужно.

Проблема у тебя, как я догадываюсь, в том, что в перле сейчас
используется вот какой расклад модулей по каталогам:

%_libdir/perl5/vendor_perl -- для noarch пакетов;
%_libdir/perl5/vendor_perl/i386-linux -- для бинарных пакетов.

Расклад этот очевидно не вписывается в x86_64, т.к. noarch пакеты
оказываются чувствительными к различию между lib и lib64.
Но это расклад придумал не я, он всегда таким был и на протяжении
perl-5.8.x я решил его не менять.  perl-5.10.0 ожидается этим летом. :)

Правильный расклад должен быть таким:
%_datadir/perl5/vendor_perl -- для noarch пакетов;
%_libdir/perl5/venodr_perl -- для бинарных пакетов.

Тогда для x86_64 нужно будет отдельно пересобирать только
perl-HTML-Parser.

> Rgds,
> Anton

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

[devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Alexey Tourbin]

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

On Fri, Feb 04, 2005 at 01:29:16AM +0300, Alexey Tourbin wrote:
> Проблема у тебя, как я догадываюсь, в том, что в перле сейчас
> используется вот какой расклад модулей по каталогам:
> 
> %_libdir/perl5/vendor_perl -- для noarch пакетов;
> %_libdir/perl5/vendor_perl/i386-linux -- для бинарных пакетов.
> 
> Расклад этот очевидно не вписывается в x86_64, т.к. noarch пакеты
> оказываются чувствительными к различию между lib и lib64.
> Но это расклад придумал не я, он всегда таким был и на протяжении
> perl-5.8.x я решил его не менять.  perl-5.10.0 ожидается этим летом. :)

Можно придумать промежуточный вариант, который всех устроит до выхода
perl-5.10.0.  Например, такой:

%_prefix/lib/perl5/vendor_perl -- для noarch пакетов;
%_libdir/perl5/vendor_perl/i386-linux -- для i586 пакетов;
%_libdir/perl5/vendor_perl/x86_64 -- для x86_64 пакетов.

Тогда
- каталог для noarch пакетов останется таким же, как сейчас, но он не
  будет зависеть от различия lib vs lib64, т.е. noarch пакеты не
  придется пересобирать для x86_64;
- для i586 останется всё по-старому;
- для x86_64 макрос %_libdir раскроется в /usr/lib/lib64.

Предлагай, как лучше сделать.

> Правильный расклад должен быть таким:
> %_datadir/perl5/vendor_perl -- для noarch пакетов;
> %_libdir/perl5/venodr_perl -- для бинарных пакетов.
> 
> Тогда для x86_64 нужно будет отдельно пересобирать только
> perl-HTML-Parser.

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

Re: [devel] Re: I: x86_64 update

[Alexey I. Froloff]

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

* Konstantin A. Lepikhov <lakostis@> [050203 22:02]:
> хм. на выходных буду пробовать повторный подход к снаряду -
> сборку win32 xulrunner через mingw cross.
Er...  Кость, не хочу тебя расстраивать, но я вчера залил
3.4.3...  Надо некоторое время подумать, как победить
%_archdatadir/aclocal и наверно пересобрать некоторые пакеты...

> Первый подход был неудачен не по-причине кривости компилятора и
> объекта сборки
Оно случайно не через gcj собирается?  А то я чуть не выкинул со
злости поддержку java...

-- 
Regards, Sir Raorn.
-------------------
> > netatalk
> Не смотри на меня так, сейчас маков под рукой не водится. :(
Одна штука мака есть у меня. Могу подобрать.
		-- nikon in devel@

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

Re: [devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Anton D. Kachalov]

On Fri, Feb 04, 2005 at 01:53:55AM +0300, Alexey Tourbin wrote:
> - для x86_64 макрос %_libdir раскроется в /usr/lib/lib64.
а это что за... ? может, /usr/lib64? :)

> 
> Предлагай, как лучше сделать.
сейчас как минимум нужно решить проблему с h2ph.

> > Правильный расклад должен быть таким:
> > %_datadir/perl5/vendor_perl -- для noarch пакетов;
> > %_libdir/perl5/venodr_perl -- для бинарных пакетов.
> > 
> > Тогда для x86_64 нужно будет отдельно пересобирать только
> > perl-HTML-Parser.
это-то понятно, но пока можно оставить всё как есть и дождаться выхода
нового перла, если в нём это зафиксят. В любом случае, в x86_64 системе
два перла (64 & 32 bit) жить не могут - будут конфликтовать по perl-base (/usr/bin/*).

А ещё есть проблема с perl-Tk. Проблема с компиляцией pTk/mTk/imgXPM.c с опцией
-Werror. Там, например, в строках 405 и 406:
hPtr = Tcl_CreateHashEntry(&colorTable, (char *) color1, &found);
Tcl_SetHashValue(hPtr, (char *) data);

imgXPM.c:405: warning: cast to pointer from integer of different size
imgXPM.c:406: warning: cast to pointer from integer of different size
imgXPM.c:454: warning: cast to pointer from integer of different size
imgXPM.c:461: warning: cast from pointer to integer of different size
imgXPM.c:483: warning: cast to pointer from integer of different size
imgXPM.c:485: warning: cast from pointer to integer of different size

там есть ещё как минимум один такой же ущербный файл.

Rgds,
Anton

[devel] Re: I: x86_64 update

[Konstantin A. Lepikhov]

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

Hi Alexey!

Friday 04, at 09:49:49 AM you wrote:

> * Konstantin A. Lepikhov <lakostis@> [050203 22:02]:
> > хм. на выходных буду пробовать повторный подход к снаряду -
> > сборку win32 xulrunner через mingw cross.
> Er...  Кость, не хочу тебя расстраивать, но я вчера залил
> 3.4.3...  Надо некоторое время подумать, как победить
> %_archdatadir/aclocal и наверно пересобрать некоторые пакеты...
Посмотрим. У меня вообще сборочная среда - ALM2.4, так что за версиями
гнаться особо смысла нет. Если не пойдет - попробую откатиться на более
старые.

> 
> > Первый подход был неудачен не по-причине кривости компилятора и
> > объекта сборки
> Оно случайно не через gcj собирается?  А то я чуть не выкинул со
> злости поддержку java...
нет, пока такого там не накрутили.

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1377 bytes --]

[devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Alexey Tourbin]

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

On Fri, Feb 04, 2005 at 10:37:48AM +0300, Anton D. Kachalov wrote:
> On Fri, Feb 04, 2005 at 01:53:55AM +0300, Alexey Tourbin wrote:
> > - для x86_64 макрос %_libdir раскроется в /usr/lib/lib64.
> а это что за... ? может, /usr/lib64? :)

Да. :)  

Кстати, вот есть каталог для компилируемых перловых модулей, сейчас это
%_libdir/perl5/{что-то там}.  Каким он должен быть на x86_64:
/usr/lib/perl5 или /usr/lib64/perl5?

Другими словами, я не понимаю, какой смысл придается каталогам /usr/lib
и /usr/lib64 в новом раскладе.

Например, в новом раскладе остается каталог /usr/lib/rpm.
Какая здесь логика?  Почему не в lib64, и не лучше ли переместить его
содержимое в /usr/share/rpm?

> > > Тогда для x86_64 нужно будет отдельно пересобирать только
> > > perl-HTML-Parser.
> это-то понятно, но пока можно оставить всё как есть и дождаться выхода
> нового перла, если в нём это зафиксят. В любом случае, в x86_64 системе
> два перла (64 & 32 bit) жить не могут - будут конфликтовать по perl-base (/usr/bin/*).

Зафиксят не в самом перле, а зафиксит maintainer перла. :)
Просто до последнего времени все перловые пакеты были более-менее
совместимы сверху вниз и снизу вверх вплоть до M22.  Если изменить
расклад по каталогам, то, как минимум, придется пересобрать всё перловое
хозяйство, и, кроме того, придумать, как "задним числом" нарушить
совместимость, чтобы обновилось "всё сразу", а не частично.

Короче, perl-5.10 -- просто хороший повод для этой миграции, т.к. в
любом случае придется пересобирать все бинарные модули, заодно можно
будет изменить расклад по каталогам и для noarch модулей.

Сейчас можно сделать так: в perl58.spec при конструировании каталогов
для модулей использовать не %_libdir, а %_prefix/lib.  Тогда noarch
пакеты будут полностью переносимы, а бинарные пакеты будут лежать в
разных каталогах, типа /usr/lib/perl5/i386-linux и
/usr/lib/perl5/x86_64-linux.

Попробуй вот этот патч (по сравнению со вчерашней сборкой перла).
Если пойдёт, я в следующей сборке так и сделаю.

--- RPM/SPECS/perl58.spec-	2005-02-02 09:09:22 +0000
+++ RPM/SPECS/perl58.spec	2005-02-04 14:03:55 +0000
@@ -4,7 +4,7 @@
 
 Name: perl
 Version: %major.%minor.%micro
-Release: alt3
+Release: alt3.1
 Epoch: 1
 
 %define sover %major.%minor
@@ -34,7 +34,7 @@ BuildRequires: libdb4.2-devel libgdbm-de
 %define perl_arch_os %perl_arch-%_os
 
 # skeleton
-%define privlib %_libdir/%name%major
+%define privlib %_prefix/lib/%name%major
 %define archlib %privlib/%perl_arch_os
 %define autolib %archlib/auto
 %define vendor_privlib %privlib/vendor_perl
@@ -44,7 +44,7 @@ BuildRequires: libdb4.2-devel libgdbm-de
 
 # site stuff is now used for local installations
 %define site_prefix /usr/local
-%define site_privlib %site_prefix/%_lib/perl%major/site_perl/%version
+%define site_privlib %site_prefix/lib/perl%major/site_perl/%version
 %define site_archlib %site_privlib/%perl_arch_os
 %define site_autolib %site_archlib/auto
 %define site_man1dir %site_prefix/man/man1
@@ -878,6 +878,9 @@ __EOF__
 # }}}
 
 %changelog
+* Fri Feb 04 2005 Alexey Tourbin <at@altlinux.ru> 1:5.8.6-alt3.1
+- fixed directory layout for x86_64
+
 * Wed Feb 02 2005 Alexey Tourbin <at@altlinux.ru> 1:5.8.6-alt3
 - applied upstream change #23565: MakeMaker's default MANIFEST.SKIP was broken
 - applied fix for suidperl/perlio exploit and buffer overflow (perlbug #33990)


> А ещё есть проблема с perl-Tk. Проблема с компиляцией pTk/mTk/imgXPM.c с опцией
> -Werror. Там, например, в строках 405 и 406:
> hPtr = Tcl_CreateHashEntry(&colorTable, (char *) color1, &found);
> Tcl_SetHashValue(hPtr, (char *) data);
> 
> imgXPM.c:405: warning: cast to pointer from integer of different size
> imgXPM.c:406: warning: cast to pointer from integer of different size
> imgXPM.c:454: warning: cast to pointer from integer of different size
> imgXPM.c:461: warning: cast from pointer to integer of different size
> imgXPM.c:483: warning: cast to pointer from integer of different size
> imgXPM.c:485: warning: cast from pointer to integer of different size
> 
> там есть ещё как минимум один такой же ущербный файл.

Значит хорошо, что -Werror включил.  По идее, некоторые warning'и нужно
приравнивать к ошибкам, тогда как другие -- совсем не обязательно.

Он и на i586 сейчас не собирается, из-за gcc3.4.  Буду чинить.

> Rgds,
> Anton

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

Re: [devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Dmitry V. Levin]

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

On Fri, Feb 04, 2005 at 05:11:20PM +0300, Alexey Tourbin wrote:
> On Fri, Feb 04, 2005 at 10:37:48AM +0300, Anton D. Kachalov wrote:
> > On Fri, Feb 04, 2005 at 01:53:55AM +0300, Alexey Tourbin wrote:
> > > - для x86_64 макрос %_libdir раскроется в /usr/lib/lib64.
> > а это что за... ? может, /usr/lib64? :)
> 
> Да. :)  
> 
> Кстати, вот есть каталог для компилируемых перловых модулей, сейчас это
> %_libdir/perl5/{что-то там}.  Каким он должен быть на x86_64:
> /usr/lib/perl5 или /usr/lib64/perl5?
> 
> Другими словами, я не понимаю, какой смысл придается каталогам /usr/lib
> и /usr/lib64 в новом раскладе.

Это, конечно, ересь, но я до сих пор не вижу смысла в /usr/lib64 на
нормальной (полноценной) 64-битной платформе.

> Например, в новом раскладе остается каталог /usr/lib/rpm.
> Какая здесь логика?  Почему не в lib64, и не лучше ли переместить его
> содержимое в /usr/share/rpm?

Тогда уж в /usr/libexec/rpm (из-за бинарных утилит).


-- 
ldv

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

[devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Alexey Tourbin]

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

On Fri, Feb 04, 2005 at 07:46:57PM +0300, Dmitry V. Levin wrote:
> > Кстати, вот есть каталог для компилируемых перловых модулей, сейчас это
> > %_libdir/perl5/{что-то там}.  Каким он должен быть на x86_64:
> > /usr/lib/perl5 или /usr/lib64/perl5?
> > 
> > Другими словами, я не понимаю, какой смысл придается каталогам /usr/lib
> > и /usr/lib64 в новом раскладе.
> 
> Это, конечно, ересь, но я до сих пор не вижу смысла в /usr/lib64 на
> нормальной (полноценной) 64-битной платформе.

Первая ересь, которая мне приходит в голову: если на полноценной
64-битной платформе хочется запускать 32-битный 3d-party бинарный код,
то нужно делать каталог со специальным названием именно для 32-битных
библиотек, а не для "нормальных" 64-битных.  То бишь должно иметь место
скорее нечто вроде /usr/lib32.

> > Например, в новом раскладе остается каталог /usr/lib/rpm.
> > Какая здесь логика?  Почему не в lib64, и не лучше ли переместить его
> > содержимое в /usr/share/rpm?
> 
> Тогда уж в /usr/libexec/rpm (из-за бинарных утилит).

Ах да.  Там, с одной стороны, лежат rpmb, rpmk и т.д., а с другой -- все
эти скрипты для сборки и поиска зависимостей...

Вот какой патч мне предлагается применить к rpm-build-perl.spec для
поддержки rpm на платформе x86_64:
ftp://ftp.altlinux.ru/pub/people/mouse/patches/new/rpm-build-perl.spec.diff

Во-первых, патч большой, гораздо проще было бы записать
%define _libdir %_prefix/lib

Во-вторых, не понятно тогда, в каких ещё случаях нужно будет
заменить %_libdir на %_prefix/lib и почему.

(В третьих, лучше использовать не %prefix, а %_prefix, т.к., если я
правильно ошибаюсь, %prefix связан с тэгом Prefix и т.н. relocations.)

> -- 
> ldv

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

Re: [devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Anton D. Kachalov]

On Fri, Feb 04, 2005 at 07:46:57PM +0300, Dmitry V. Levin wrote:
> On Fri, Feb 04, 2005 at 05:11:20PM +0300, Alexey Tourbin wrote:
> > On Fri, Feb 04, 2005 at 10:37:48AM +0300, Anton D. Kachalov wrote:
> > > On Fri, Feb 04, 2005 at 01:53:55AM +0300, Alexey Tourbin wrote:
> > > > - для x86_64 макрос %_libdir раскроется в /usr/lib/lib64.
> > > а это что за... ? может, /usr/lib64? :)
> > 
> > Да. :)  
> > 
> > Кстати, вот есть каталог для компилируемых перловых модулей, сейчас это
> > %_libdir/perl5/{что-то там}.  Каким он должен быть на x86_64:
> > /usr/lib/perl5 или /usr/lib64/perl5?
> > 
> > Другими словами, я не понимаю, какой смысл придается каталогам /usr/lib
> > и /usr/lib64 в новом раскладе.
> 
> Это, конечно, ересь, но я до сих пор не вижу смысла в /usr/lib64 на
> нормальной (полноценной) 64-битной платформе.
да уж, куда удобней было б распихивать все 32-bit приложения по
/usr/lib32... но вопрос в том, _как_ их собрать, чтобы они туда ложились?
Собирать-то нужно всё-таки не кроссом, а нативно во избежании
side-эффектов, да и куча софта, который не пересоберёшь, лезет в
/usr/lib...
а главное - мы получим те же яйца, только в профиль. Только проблем больше
- lib64 уже во многих местах есть, а lib32 нужно везде делать при этом
отрывая везде lib64 -> lib. Как минимум, двойная работа. Единственную
платформу, замеченную с lib32 - это не то AIX, не то IRIX, которые сами по
себе 64bit.

> 
> > Например, в новом раскладе остается каталог /usr/lib/rpm.
> > Какая здесь логика?  Почему не в lib64, и не лучше ли переместить его
> > содержимое в /usr/share/rpm?
мня...может тогда и /usr/X11R6/lib/X11 -> /usr/X11R6/share? :) и огрести
много приятных ночей с этим делом.

> 
> Тогда уж в /usr/libexec/rpm (из-за бинарных утилит).
вот-вот. Но это проще, чем с иксами :)

Rgds,
Anton

Re: [devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Anton D. Kachalov]

On Fri, Feb 04, 2005 at 05:11:20PM +0300, Alexey Tourbin wrote:
> On Fri, Feb 04, 2005 at 10:37:48AM +0300, Anton D. Kachalov wrote:
> > On Fri, Feb 04, 2005 at 01:53:55AM +0300, Alexey Tourbin wrote:
> > > - для x86_64 макрос %_libdir раскроется в /usr/lib/lib64.
> > а это что за... ? может, /usr/lib64? :)
> 
> Да. :)  
> 
> Кстати, вот есть каталог для компилируемых перловых модулей, сейчас это
> %_libdir/perl5/{что-то там}.  Каким он должен быть на x86_64:
> /usr/lib/perl5 или /usr/lib64/perl5?
/usr/lib64/perl5, как он и есть сейчас.

> 
> Другими словами, я не понимаю, какой смысл придается каталогам /usr/lib
> и /usr/lib64 в новом раскладе.
для перла /usr/lib/ нафиг не въелся.

> Сейчас можно сделать так: в perl58.spec при конструировании каталогов
> для модулей использовать не %_libdir, а %_prefix/lib.  Тогда noarch
> пакеты будут полностью переносимы, а бинарные пакеты будут лежать в
> разных каталогах, типа /usr/lib/perl5/i386-linux и
> /usr/lib/perl5/x86_64-linux.
это лучшее решение, т.к.32bit perl стоять точно не будет.

> 
> Попробуй вот этот патч (по сравнению со вчерашней сборкой перла).
> Если пойдёт, я в следующей сборке так и сделаю.

т.е.ты мне предлагаешь ещё убить какое-то время на пересборку perl-* с
новыми путями? :) правда, это будет значительно проще со старыми
noarch-пакетами, которые для пересборки по зависимостям хотели сами себя.

Rgds,
Anton

Re: [devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Anton D. Kachalov]

On Fri, Feb 04, 2005 at 08:40:23PM +0300, Alexey Tourbin wrote:
> Вот какой патч мне предлагается применить к rpm-build-perl.spec для
> поддержки rpm на платформе x86_64:
> ftp://ftp.altlinux.ru/pub/people/mouse/patches/new/rpm-build-perl.spec.diff
> 
> Во-первых, патч большой, гораздо проще было бы записать
> %define _libdir %_prefix/lib
> 
> Во-вторых, не понятно тогда, в каких ещё случаях нужно будет
> заменить %_libdir на %_prefix/lib и почему.
> 
> (В третьих, лучше использовать не %prefix, а %_prefix, т.к., если я
> правильно ошибаюсь, %prefix связан с тэгом Prefix и т.н. relocations.)
это очень древни патч. Времён, когда я только начинал возню с lib64.

Rgds,
Anton

Re: [devel] lib32/lib64

[Dmitry V. Levin]

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

On Fri, Feb 04, 2005 at 11:34:15PM +0300, Anton D. Kachalov wrote:
> On Fri, Feb 04, 2005 at 07:46:57PM +0300, Dmitry V. Levin wrote:
> > On Fri, Feb 04, 2005 at 05:11:20PM +0300, Alexey Tourbin wrote:
> > > On Fri, Feb 04, 2005 at 10:37:48AM +0300, Anton D. Kachalov wrote:
> > > > On Fri, Feb 04, 2005 at 01:53:55AM +0300, Alexey Tourbin wrote:
> > > > > - для x86_64 макрос %_libdir раскроется в /usr/lib/lib64.
> > > > а это что за... ? может, /usr/lib64? :)
> > > 
> > > Да. :)  
> > > 
> > > Кстати, вот есть каталог для компилируемых перловых модулей, сейчас это
> > > %_libdir/perl5/{что-то там}.  Каким он должен быть на x86_64:
> > > /usr/lib/perl5 или /usr/lib64/perl5?
> > > 
> > > Другими словами, я не понимаю, какой смысл придается каталогам /usr/lib
> > > и /usr/lib64 в новом раскладе.
> > 
> > Это, конечно, ересь, но я до сих пор не вижу смысла в /usr/lib64 на
> > нормальной (полноценной) 64-битной платформе.
> да уж, куда удобней было б распихивать все 32-bit приложения по
> /usr/lib32... но вопрос в том, _как_ их собрать, чтобы они туда ложились?
> Собирать-то нужно всё-таки не кроссом, а нативно во избежании
> side-эффектов, да и куча софта, который не пересоберёшь, лезет в
> /usr/lib...
> а главное - мы получим те же яйца, только в профиль. Только проблем больше
> - lib64 уже во многих местах есть, а lib32 нужно везде делать при этом
> отрывая везде lib64 -> lib. Как минимум, двойная работа. Единственную

Я так понимаю, что lib64 не прошит в программах, поскольку есть куча
64-битных архитектур, где нет 32-битной эмуляции.

Короче говоря, потребность в поддержке этой мультибитности вызвана тем
обстоятельством, что x86_64 (пока ещё) не является полноценной 64-битной
платформой.

В завершение позволю себе процитировать соответствующий отрывок из FHS-2.3:

"/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)

The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit
libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.

The 64-bit architecture IA64 must place 64-bit libraries in /lib.

    Rationale: This is a refinement of the general rules for /lib<qual> and /
    usr/lib<qual>. The architectures PPC64, s390x, sparc64 and AMD64 support
    support both 32-bit (for s390 more precise 31-bit) and 64-bit programs.
    Using lib for 32-bit binaries allows existing binaries from the 32-bit
    systems to work without any changes: such binaries are expected to be
    numerous. IA-64 uses a different scheme, reflecting the deprecation of
    32-bit binaries (and hence libraries) on that architecture."


-- 
ldv

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

Re: [devel] lib32/lib64

[Anton D. Kachalov]

On Sat, Feb 05, 2005 at 12:33:41AM +0300, Dmitry V. Levin wrote:
> On Fri, Feb 04, 2005 at 11:34:15PM +0300, Anton D. Kachalov wrote:
> > On Fri, Feb 04, 2005 at 07:46:57PM +0300, Dmitry V. Levin wrote:
> > > On Fri, Feb 04, 2005 at 05:11:20PM +0300, Alexey Tourbin wrote:
> > > > On Fri, Feb 04, 2005 at 10:37:48AM +0300, Anton D. Kachalov wrote:
> 
> Я так понимаю, что lib64 не прошит в программах, поскольку есть куча
> 64-битных архитектур, где нет 32-битной эмуляции.
вот именно, зато мест, где прибито гвоздями lib ооочень много. Чаще это
решается subst'ами или ещё какими методами.

> 
> Короче говоря, потребность в поддержке этой мультибитности вызвана тем
> обстоятельством, что x86_64 (пока ещё) не является полноценной 64-битной
> платформой.
и не будет.

> В завершение позволю себе процитировать соответствующий отрывок из FHS-2.3:
> 
> "/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
> 
> The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit
> libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
> 
> The 64-bit architecture IA64 must place 64-bit libraries in /lib.
> 
>     Rationale: This is a refinement of the general rules for /lib<qual> and /
>     usr/lib<qual>. The architectures PPC64, s390x, sparc64 and AMD64 support
>     support both 32-bit (for s390 more precise 31-bit) and 64-bit programs.
>     Using lib for 32-bit binaries allows existing binaries from the 32-bit
>     systems to work without any changes: such binaries are expected to be
>     numerous. IA-64 uses a different scheme, reflecting the deprecation of
>     32-bit binaries (and hence libraries) on that architecture."
стоит отметить тот факт, что Intel свернула все разработки в области
IA-64. Т.ч.всё стало немного проще.

Rgds,
Anton

[devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Alexey Tourbin]

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

On Fri, Feb 04, 2005 at 11:38:41PM +0300, Anton D. Kachalov wrote:
> > Кстати, вот есть каталог для компилируемых перловых модулей, сейчас это
> > %_libdir/perl5/{что-то там}.  Каким он должен быть на x86_64:
> > /usr/lib/perl5 или /usr/lib64/perl5?
> /usr/lib64/perl5, как он и есть сейчас.
> 
> > Другими словами, я не понимаю, какой смысл придается каталогам /usr/lib
> > и /usr/lib64 в новом раскладе.
> для перла /usr/lib/ нафиг не въелся.

(До появления /usr/share/perl5.)
((Но всё равно не понимаю.))

> > Сейчас можно сделать так: в perl58.spec при конструировании каталогов
> > для модулей использовать не %_libdir, а %_prefix/lib.  Тогда noarch
> > пакеты будут полностью переносимы, а бинарные пакеты будут лежать в
> > разных каталогах, типа /usr/lib/perl5/i386-linux и
> > /usr/lib/perl5/x86_64-linux.
> это лучшее решение, т.к.32bit perl стоять точно не будет.

То есть здесь таки речь идет о /usr/lib/perl5/x86_64-linux, а не
/usr/lib64/perl5/x86_64-linux.  Сделать равномерное "расслоение"
на /usr/lib/perl5 (noarch) и /usr/lib64/perl5 (x86_64) в принципе
не намного сложнее.

> > Попробуй вот этот патч (по сравнению со вчерашней сборкой перла).
> > Если пойдёт, я в следующей сборке так и сделаю.
> т.е.ты мне предлагаешь ещё убить какое-то время на пересборку perl-* с
> новыми путями? :) правда, это будет значительно проще со старыми
> noarch-пакетами, которые для пересборки по зависимостям хотели сами себя.

Если noarch пакеты просто переложить в $BUILD/repo, то проблем с
бутстрапом не будет.  Бинарных перловых пакетов примерно вдвое меньше,
чем noarch, просто скармливай их в мясорубку по мере необходимости.

> Rgds,
> Anton

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

[devel] Re: lib32/lib64

[Alexey Tourbin]

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

On Sat, Feb 05, 2005 at 12:42:18AM +0300, Anton D. Kachalov wrote:
> > Короче говоря, потребность в поддержке этой мультибитности вызвана тем
> > обстоятельством, что x86_64 (пока ещё) не является полноценной 64-битной
> > платформой.
> и не будет.

А почему не будет?  Почему x86_64 нельзя считать полноценной 64-битной
платформой, на манер IA-64?  Только потому, что велико искушение
запускать всякий левый софт типа acroread.exe? :)

> > "/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
> > 
> > The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit
> > libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
> > 
> > The 64-bit architecture IA64 must place 64-bit libraries in /lib.
> > 
> >     Rationale: This is a refinement of the general rules for /lib<qual> and /
> >     usr/lib<qual>. The architectures PPC64, s390x, sparc64 and AMD64 support
> >     support both 32-bit (for s390 more precise 31-bit) and 64-bit programs.
> >     Using lib for 32-bit binaries allows existing binaries from the 32-bit
> >     systems to work without any changes: such binaries are expected to be
> >     numerous. IA-64 uses a different scheme, reflecting the deprecation of
> >     32-bit binaries (and hence libraries) on that architecture."

Deprecation как бы в любом случае имеет место быть.
Интересно, через сколько лет 64-битные боксы начнут доминировать?

Кстати, кажется, архитектуре i586 как основной для сборки уже больше
5 лет, она ещё со времен iplabs, когда альтлинукса не было.

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

[devel] -mcpu? (was: lib32/lib64)

[Michael Shigorin]

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

On Sat, Feb 05, 2005 at 01:54:46AM +0300, Alexey Tourbin wrote:
> Кстати, кажется, архитектуре i586 как основной для сборки уже
> больше 5 лет, она ещё со времен iplabs, когда альтлинукса не
> было.

Эээ... ну раз пошла такая пьянка...

--- http://lwn.net/Articles/121843/
 The Fedora developers keep being asked this, and their answer is
 the same (although I've yet to check the compile flags on the
 Extras packages).

 Fedora packages are compiled optimising for i686 (earlier
 releases) or the Pentium 4 (today). But they normally use the
 i386 instruction set.

 For most packages, there is no performance benefit to using the
 later instructions. And modern processors other than the Pentium
 4 seem to benefit as much from Pentium 4 optimisations (Athlons,
 in particular, do so much reordering that they can optimise for
 themselves).

 If you can identify a package that is compiled with 386
 instructions but would benefit from more recent instructions,
 and if you can provide benchmarks ("Distribution X is faster"
 doesn't count since there are too many variables), then
 fedora-devel@redhat.com would love to hear from you.

 Incidentally, AMD K6-based computers count as i586 as far as gcc
 is concerned.
---

Может, и нам как-нить на досуге(tm) поиграться с тестами по части
-mcpu?  Под рукой есть Pentium I/II/III{,Xeon}/4, Athlon,
AthlonMP, AthlonXP.

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

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

Re: [devel] Re: A: perl-HTML-* perl-libwww #@$#!

[Anton Farygin]

Dmitry V. Levin wrote:

>On Fri, Feb 04, 2005 at 05:11:20PM +0300, Alexey Tourbin wrote:
>  
>
>>On Fri, Feb 04, 2005 at 10:37:48AM +0300, Anton D. Kachalov wrote:
>>    
>>
>>>On Fri, Feb 04, 2005 at 01:53:55AM +0300, Alexey Tourbin wrote:
>>>      
>>>
>>>>- для x86_64 макрос %_libdir раскроется в /usr/lib/lib64.
>>>>        
>>>>
>>>а это что за... ? может, /usr/lib64? :)
>>>      
>>>
>>Да. :)  
>>
>>Кстати, вот есть каталог для компилируемых перловых модулей, сейчас это
>>%_libdir/perl5/{что-то там}.  Каким он должен быть на x86_64:
>>/usr/lib/perl5 или /usr/lib64/perl5?
>>
>>Другими словами, я не понимаю, какой смысл придается каталогам /usr/lib
>>и /usr/lib64 в новом раскладе.
>>    
>>
>
>Это, конечно, ересь, но я до сих пор не вижу смысла в /usr/lib64 на
>нормальной (полноценной) 64-битной платформе.
>  
>
На полноценной - смысла нет. А на такой, как x86_64 - вполне осмысленно.

Rgds,
Rider

Re: [devel] Re: lib32/lib64

[Anton Farygin]

Alexey Tourbin wrote:

>On Sat, Feb 05, 2005 at 12:42:18AM +0300, Anton D. Kachalov wrote:
>  
>
>>>Короче говоря, потребность в поддержке этой мультибитности вызвана тем
>>>обстоятельством, что x86_64 (пока ещё) не является полноценной 64-битной
>>>платформой.
>>>      
>>>
>>и не будет.
>>    
>>
>
>А почему не будет?  Почему x86_64 нельзя считать полноценной 64-битной
>платформой, на манер IA-64?  Только потому, что велико искушение
>запускать всякий левый софт типа acroread.exe? :)
>  
>
Нет. Потому что такие вот процессоры выпускают - недо64бит.

Точнее говоря - взят стандартный камень и к нему прикручено некоторое 
количество 64-битных инструкций.

>  
>
>>>"/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
>>>
>>>The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit
>>>libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
>>>
>>>The 64-bit architecture IA64 must place 64-bit libraries in /lib.
>>>
>>>    Rationale: This is a refinement of the general rules for /lib<qual> and /
>>>    usr/lib<qual>. The architectures PPC64, s390x, sparc64 and AMD64 support
>>>    support both 32-bit (for s390 more precise 31-bit) and 64-bit programs.
>>>    Using lib for 32-bit binaries allows existing binaries from the 32-bit
>>>    systems to work without any changes: such binaries are expected to be
>>>    numerous. IA-64 uses a different scheme, reflecting the deprecation of
>>>    32-bit binaries (and hence libraries) on that architecture."
>>>      
>>>
>
>Deprecation как бы в любом случае имеет место быть.
>Интересно, через сколько лет 64-битные боксы начнут доминировать?
>  
>
Можно считать так:
- момент выпуска Celeron/Sempron 64bit + 2-3 года.

Насколько я знаю - x86_64 дешевые процессоры пока не стоят в планах 
Intel и AMD.

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

>Кстати, кажется, архитектуре i586 как основной для сборки уже больше
>5 лет, она ещё со времен iplabs, когда альтлинукса не было.
>  
>
ALT linux'у в этом году (кстати, в феврале-марте) будет исполняться 5 лет.

:-)

Rgds,
Rider

Re: [devel] Re: lib32/lib64

[Anton D. Kachalov]

On Sat, Feb 05, 2005 at 03:18:50PM +0300, Anton Farygin wrote:
> ALT linux'у в этом году (кстати, в феврале-марте) будет исполняться 5 лет.

Пьянка? :)

Rgds,
Anton

Re: [devel] Re: lib32/lib64

[Genix]

Anton D. Kachalov wrote:

>>ALT linux'у в этом году (кстати, в феврале-марте) будет исполняться 5 лет.
> 
> 
> Пьянка? :)

т.е. в феврале-марте до сизифа лучше не обновляться?

P.$.: с такой неопределенной датой (февраль-март) и спиться можно

-- 
У каждого в башке свои тараканы...

Re: [devel] -mcpu? (was: lib32/lib64)

[Dmitry V. Levin]

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

On Sat, Feb 05, 2005 at 12:00:09PM +0200, Michael Shigorin wrote:
> Может, и нам как-нить на досуге(tm) поиграться с тестами по части
> -mcpu?  Под рукой есть Pentium I/II/III{,Xeon}/4, Athlon,
> AthlonMP, AthlonXP.

Я не против, но тогда все старые компиляторы придётся отправить на свалку,
поскольку параметры компиляции для них просто не годятся.


-- 
ldv

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

[devel] Re: -mcpu? (was: lib32/lib64)

[Michael Shigorin]

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

On Sat, Feb 05, 2005 at 06:55:05PM +0300, Dmitry V. Levin wrote:
> > Может, и нам как-нить на досуге(tm) поиграться с тестами по
> > части -mcpu?  Под рукой есть Pentium I/II/III{,Xeon}/4,
> > Athlon, AthlonMP, AthlonXP.
> Я не против, но тогда все старые компиляторы придётся отправить
> на свалку, поскольку параметры компиляции для них просто не
> годятся.

Гм, а что у нас сейчас собирается 2.9x?..  11 пакетов:

RPM/SPECS/classic> grep '^Build.*gcc.*2\.9' * | cut -f1 -d:
abuse_sdl.spec
billardgl.spec
dx.spec
etherboot.spec
foobillard.spec
logjam.spec
memtest86.spec
MPlayer.spec
qt1.spec
qt2.spec
XFree86-compat.spec

Из них минимум два (abuse и memtest86) взорвались то ли с 3.0.4,
то ли с 3.2, в общем -- порядком давно и с тех пор должны были
полечиться.

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

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

Re: [devel] -mcpu? (was: lib32/lib64)

[Sergey Vlasov]

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

On Sat, Feb 05, 2005 at 06:55:05PM +0300, Dmitry V. Levin wrote:
> On Sat, Feb 05, 2005 at 12:00:09PM +0200, Michael Shigorin wrote:
> > Может, и нам как-нить на досуге(tm) поиграться с тестами по части
> > -mcpu?  Под рукой есть Pentium I/II/III{,Xeon}/4, Athlon,
> > AthlonMP, AthlonXP.
> 
> Я не против, но тогда все старые компиляторы придётся отправить на свалку,
> поскольку параметры компиляции для них просто не годятся.

А если сделать проверку поддерживаемых опций для выбранной версии компилятора
(аналогично тому, что сделано в Makefile ядра)?  Например, вот так:

optflags: i586 %optflags_default -march=i586 %optflags_mcpu

%optflags_mcpu		%(%{?_gcc_version:GCC_VERSION=\"%_gcc_version\"} /usr/lib/rpm/gcc-option -mcpu=pentium4 -mcpu=i686)

И к этому /usr/lib/rpm/gcc-option:

#!/bin/sh -e
for options in "$@"; do
	if gcc $options -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then
		echo "$options"
		exit 0
	fi
done

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

[devel] I: x86_64 update

[Anton D. Kachalov]

Итак, очередное обновление.
Наконец-таки был собран ghostscript со всеми вытекающими.
Из свеженького samba, mysql, postgresql, libgnome
Проблемы со сборкой gimp-print и graphviz: не удаётся обновить
configure,etc... (autoreconf -fisv не отрабатывает). Желающие могут помочь
разобраться :)
Сейчас собирается qt3 и если всё будет пучком, то он тоже уедет в
Сизифчик.

ЗЫ. Чуть не забыл - обновил std26-up - сделал патч на skbuff
(kernel-fix-core-skbuff),
увеличивающий размер control buffer'a для того, чтобы можно было заюзать
драйверами amedyn под x86_64 (модем великолепно работает и здесь :)) Вот
только появилась такая фигня в логах (наверн,из-за usb в 2.6.10):
Feb  5 12:44:06 test8 kernel: usbcore: registered new driver xdslusb
Feb  5 12:44:06 test8 kernel: kobject_register failed for xdslusb (-17)
Feb  5 12:44:06 test8 kernel: 
Feb  5 12:44:06 test8 kernel: Call
Trace:<ffffffff801d1956>{kobject_register+70}
<ffffffff8023d49b>{bus_add_driver+107} 
Feb  5 12:44:06 test8 kernel:
<ffffffff8023da22>{driver_register+50}
<ffffffffa00ef30a>{:usbcore:usb_register+90} 
Feb  5 12:44:06 test8 kernel:
<ffffffff8014aa2d>{sys_init_module+317} <ffffffff8011ea31>{ia32_sysret+0} 
Feb  5 12:44:06 test8 kernel:        
Feb  5 12:44:06 test8 kernel: usbcore: error -17 registering driver
xdslusb
но при этом драйвер всё равно грузится и работает :)
примерно такая же ругань при выгрузке.

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

ах да, ещё openldap и gcc :) в последнем добавил сборку жабы.

Rgds,
Anton

Re: [devel] I: x86_64 update

[Vitaly Lipatov]

On Sunday 06 February 2005 15:13, Anton D. Kachalov wrote:

> ЗЫ. Чуть не забыл - обновил std26-up - сделал патч на skbuff
> (kernel-fix-core-skbuff),
> увеличивающий размер control buffer'a для того, чтобы можно
> было заюзать драйверами amedyn под x86_64 (модем великолепно
> работает и здесь :)) Вот только появилась такая фигня в логах
Ух ты...
> (наверн,из-за usb в 2.6.10): Feb  5 12:44:06 test8 kernel:
Не, у меня на 2.6.10 другое пишет...
> но при этом драйвер всё равно грузится и работает :)

P.S. Чуть позже пересмотрю драйвер, постараюсь привести его в 
чувство и согласованность с последними ядрами.

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

[devel] Re: lib32/lib64

[Ilya]

Anton Farygin wrote:
> Alexey Tourbin wrote:

>> Кстати, кажется, архитектуре i586 как основной для сборки уже больше
>> 5 лет, она ещё со времен iplabs, когда альтлинукса не было.
>>  
>>
> ALT linux'у в этом году (кстати, в феврале-марте) будет исполняться 5 лет.
> :-)

Антон, пока только четыре года :)

Первые новости от 25 Марта 2001

-- 
Илья Машкин

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sun, Feb 06, 2005 at 07:06:26PM +0300, Vitaly Lipatov wrote:
> On Sunday 06 February 2005 15:13, Anton D. Kachalov wrote:
> 
> > ЗЫ. Чуть не забыл - обновил std26-up - сделал патч на skbuff
> > (kernel-fix-core-skbuff),
> > увеличивающий размер control buffer'a для того, чтобы можно
> > было заюзать драйверами amedyn под x86_64 (модем великолепно
> > работает и здесь :)) Вот только появилась такая фигня в логах
> Ух ты...
> > (наверн,из-за usb в 2.6.10): Feb  5 12:44:06 test8 kernel:
> Не, у меня на 2.6.10 другое пишет...
> > но при этом драйвер всё равно грузится и работает :)
> 
> P.S. Чуть позже пересмотрю драйвер, постараюсь привести его в 
> чувство и согласованность с последними ядрами.

могу дать маленький патч на amedyn, который всё-таки даёт возможность
собирать br2684ctl - там нужно ставить хидеры от ядра и сделать замены
$(KERNEL_PATH) на /usr:
ftp://ftp.altlinux.ru/pub/people/mouse/patches/newest/amedyn.spec.diff

а всё остальное работает :)

Rgds,
Anton

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

До кучи, doxygen и firefox с evms'ом :)
Вот тока багу нужно на firefox вешать - не проверяет для какой архитектуры
качает плагин :(

Rgds,
Anton

Re: [devel] -mcpu?

[Anton Farygin]

Dmitry V. Levin wrote:

>On Sat, Feb 05, 2005 at 12:00:09PM +0200, Michael Shigorin wrote:
>  
>
>>Может, и нам как-нить на досуге(tm) поиграться с тестами по части
>>-mcpu?  Под рукой есть Pentium I/II/III{,Xeon}/4, Athlon,
>>AthlonMP, AthlonXP.
>>    
>>
>
>Я не против, но тогда все старые компиляторы придётся отправить на свалку,
>поскольку параметры компиляции для них просто не годятся.
>
>
>  
>
А какие старые компиляторы у нас сейчас реально используются ?

а вообще есть статистика по использованию компиляторов ? Может быть 
какие-то уже пора действительно отправлять на свалку ?

Rgds,
Rider

Re: [devel] Re: lib32/lib64

[Anton Farygin]

Ilya wrote:

> Anton Farygin wrote:
>
>> Alexey Tourbin wrote:
>
>
>>> Кстати, кажется, архитектуре i586 как основной для сборки уже больше
>>> 5 лет, она ещё со времен iplabs, когда альтлинукса не было.
>>>  
>>>
>> ALT linux'у в этом году (кстати, в феврале-марте) будет исполняться 5 
>> лет.
>> :-)
>
>
> Антон, пока только четыре года :)
>
> Первые новости от 25 Марта 2001
>
О блин.. действительно..

Как медленно идет время ;-)

Rgds,
Rider

[devel] Re: -mcpu?

[Michael Shigorin]

On Mon, Feb 07, 2005 at 10:31:13AM +0300, Anton Farygin wrote:
> >>Может, и нам как-нить на досуге(tm) поиграться с тестами по
> >>части -mcpu?  Под рукой есть Pentium I/II/III{,Xeon}/4,
> >>Athlon, AthlonMP, AthlonXP.
> >Я не против, но тогда все старые компиляторы придётся
> >отправить на свалку, поскольку параметры компиляции для них
> >просто не годятся.
> А какие старые компиляторы у нас сейчас реально используются ?
> а вообще есть статистика по использованию компиляторов ? Может
> быть какие-то уже пора действительно отправлять на свалку ?

Ну, отправлять "просто так" -- тоже, наверное, не лучший вариант.
Всегда найдётся кто-то, прижатый к стенке старой софтиной.

Другое дело, что пакетную базу 2.x уже практически не собирают.

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

Re: [devel] I: x86_64 update

[Dmitry V. Levin]

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

On Thu, Feb 03, 2005 at 12:13:07PM +0300, Anton D. Kachalov wrote:
> On Thu, Feb 03, 2005 at 01:01:29AM +0300, Vitaly Lipatov wrote:
> > On Wednesday 02 February 2005 14:16, Anton D. Kachalov wrote:
[...]
> > А когда это будет полноценный репозиторий, в том плане, что 
> > пакеты будут пересобираться и под эту архитектуру, баги о 
> > непересобираемости должны сами потечь к мантейнерам. См. Debian, 
> > разве нет?
> а пакеты и так многие пересобираются под эту архитектуру. Проблемы обычно
> возникают с системными пакетами и теми, что используют kernel-headers от
> 2.4...
> А логи и так сыпятся...только пока о i386-архитектуре :)
> А пока все проблемы пишутся в багзиллу.

Антон, предлагаю тебе сделать NMU на тему поддержки x86_64 для тех
пакетов, мантейнеры которых до сих пор не отозвались на соответствующие
баги в багзилле.


-- 
ldv

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

Re: [devel] I: x86_64 update

[Anton Farygin]

Dmitry V. Levin wrote:

>On Thu, Feb 03, 2005 at 12:13:07PM +0300, Anton D. Kachalov wrote:
>  
>
>>On Thu, Feb 03, 2005 at 01:01:29AM +0300, Vitaly Lipatov wrote:
>>    
>>
>>>On Wednesday 02 February 2005 14:16, Anton D. Kachalov wrote:
>>>      
>>>
>[...]
>  
>
>>>А когда это будет полноценный репозиторий, в том плане, что 
>>>пакеты будут пересобираться и под эту архитектуру, баги о 
>>>непересобираемости должны сами потечь к мантейнерам. См. Debian, 
>>>разве нет?
>>>      
>>>
>>а пакеты и так многие пересобираются под эту архитектуру. Проблемы обычно
>>возникают с системными пакетами и теми, что используют kernel-headers от
>>2.4...
>>А логи и так сыпятся...только пока о i386-архитектуре :)
>>А пока все проблемы пишутся в багзиллу.
>>    
>>
>
>Антон, предлагаю тебе сделать NMU на тему поддержки x86_64 для тех
>пакетов, мантейнеры которых до сих пор не отозвались на соответствующие
>баги в багзилле.
>
>  
>
Да, присоединяюсь к предложению.

Rgds,
Rider

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Tue, Feb 08, 2005 at 09:44:27AM +0300, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> 
> >On Thu, Feb 03, 2005 at 12:13:07PM +0300, Anton D. Kachalov wrote:
> > 
> >
> >>On Thu, Feb 03, 2005 at 01:01:29AM +0300, Vitaly Lipatov wrote:
> >>   
> >>
> >>>On Wednesday 02 February 2005 14:16, Anton D. Kachalov wrote:
> >>>     
> >>>
> >[...]
> > 
> >
> >>>А когда это будет полноценный репозиторий, в том плане, что 
> >>>пакеты будут пересобираться и под эту архитектуру, баги о 
> >>>непересобираемости должны сами потечь к мантейнерам. См. Debian, 
> >>>разве нет?
> >>>     
> >>>
> >>а пакеты и так многие пересобираются под эту архитектуру. Проблемы обычно
> >>возникают с системными пакетами и теми, что используют kernel-headers от
> >>2.4...
> >>А логи и так сыпятся...только пока о i386-архитектуре :)
> >>А пока все проблемы пишутся в багзиллу.
> >>   
> >>
> >
> >Антон, предлагаю тебе сделать NMU на тему поддержки x86_64 для тех
> >пакетов, мантейнеры которых до сих пор не отозвались на соответствующие
> >баги в багзилле.
> >
> > 
> >
> Да, присоединяюсь к предложению.

сегодня будет день пересборок :)

Rgds,
Anton

Re: [devel] I: x86_64 update

[Sergey Vlasov]

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

On Tue, Feb 08, 2005 at 11:49:50AM +0300, Anton D. Kachalov wrote:
> > >Антон, предлагаю тебе сделать NMU на тему поддержки x86_64 для тех
> > >пакетов, мантейнеры которых до сих пор не отозвались на соответствующие
> > >баги в багзилле.
> > Да, присоединяюсь к предложению.
> 
> сегодня будет день пересборок :)

Только не надо делать пересборку так, как это было сделано в своё время
для mkinitrd-busybox (в результате чего, помимо всего прочего, там
образовалась версия 1.00.pre8).

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

[devel] [JT] Re: I: x86_64 update

[Michael Shigorin]

On Tue, Feb 08, 2005 at 11:49:50AM +0300, Anton D. Kachalov wrote:
> сегодня будет день пересборок :)

Пересборник или билдат? :)

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

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

Добренького!
Итак, очередные обновки. Из приятного, многие патчи синхронизированы с
основным Сизифом. Осталось буквально полтора десятка пакетов.
Из нового: ppp, emacs/xemacs, postfix, gettext(наконец-таки собранный в
хэшере), licq :)

Пересборка i синхронизация to be continued...

Rgds,
Anton

Re: [devel] I: x86_64 update

[Valery V. Inozemtsev]

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

В сообщении от 12 Февраль 2005 11:45 Anton D. Kachalov написал(a):
> Добренького!
> Итак, очередные обновки. Из приятного, многие патчи синхронизированы с
> основным Сизифом. Осталось буквально полтора десятка пакетов.
> Из нового: ppp, emacs/xemacs, postfix, gettext(наконец-таки собранный в

прикрути к ppp вот это, раз уж мы на 2.6 считай переехали

http://www.polbox.com/h/hs001/ppp-2.4.2-stdopt-mppe-mppc-1.1.patch.gz

> хэшере), licq :)
>
> Пересборка i синхронизация to be continued...

-- 
Valery V. Inozemtsev

Powered by ALT Linux Sisyphus (20050209) on kernel 2.6.10-std26-up-alt3
ftp://ftp.altlinux.ru/pub/people/shrek/

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

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sat, Feb 12, 2005 at 12:00:37PM +0300, Valery V. Inozemtsev wrote:
> В сообщении от 12 Февраль 2005 11:45 Anton D. Kachalov написал(a):
> > Добренького!
> > Итак, очередные обновки. Из приятного, многие патчи синхронизированы с
> > основным Сизифом. Осталось буквально полтора десятка пакетов.
> > Из нового: ppp, emacs/xemacs, postfix, gettext(наконец-таки собранный в
> 
> прикрути к ppp вот это, раз уж мы на 2.6 считай переехали
> 
> http://www.polbox.com/h/hs001/ppp-2.4.2-stdopt-mppe-mppc-1.1.patch.gz
попробую :)

Rgds,
Anton

Re: [devel] I: x86_64 update

[Alexey Shabalin]

Anton D. Kachalov пишет:

>Добренького!
>Итак, очередные обновки. Из приятного, многие патчи синхронизированы с
>основным Сизифом. Осталось буквально полтора десятка пакетов.
>Из нового: ppp, emacs/xemacs, postfix, gettext(наконец-таки собранный в
>хэшере), licq :)
>
>Пересборка i синхронизация to be continued...
>
>  
>
Глупый вопрос можно :) ?
apt-get на него натравливается или нет?
После установки M24 указал на него - apt не хочет видеть этих пакетов.
Наверно rpm надо вручную обновить?

Алексей.

Re: [devel] I: x86_64 update

[Anton D. Kachalov]

On Sun, Feb 13, 2005 at 09:35:25PM +0300, Alexey Shabalin wrote:
> Anton D. Kachalov пишет:
> 
> >Добренького!
> >Итак, очередные обновки. Из приятного, многие патчи синхронизированы с
> >основным Сизифом. Осталось буквально полтора десятка пакетов.
> >Из нового: ppp, emacs/xemacs, postfix, gettext(наконец-таки собранный в
> >хэшере), licq :)
> >
> >Пересборка i синхронизация to be continued...
> >
> > 
> >
> Глупый вопрос можно :) ?
> apt-get на него натравливается или нет?
> После установки M24 указал на него - apt не хочет видеть этих пакетов.
> Наверно rpm надо вручную обновить?

А хост система какая? Во-первых, в старом rpm эта архитектура не прописана
как дружественная к i586 (точнее, наоборот - i586 дружествен к x86_64).
Т.ч. установка только ручками (пока). Сейчас планируется допилить кое-что
из корковых пакетов так, чтобы можно было собрать тот же live cd...
И обновлять нужно, начиная с kernel + mkinitrd-busybox, а потом, из
нативного ядра можно остальное, но лучше не обновлять, а ставить рядом. Но
это весьма рискованное мероприятие ;)

Rgds,
Anton