[devel] mgetty x86_64

[devel] mgetty x86_64

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

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

А mgetty на x86_64 когда-нибудь у нас будет? Без него какого-то censored
hylafax не собирается.

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

http://freesource.info
----------------------------------------------------------------------------
 * Vitls сегодня отмечает 3-х ление участия в проекте Linux Ru Net 

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

Re: [devel] mgetty x86_64

[Anton Gorlov]

Денис Смирнов пишет:
> А mgetty на x86_64 когда-нибудь у нас будет? Без него какого-то censored
> hylafax не собирается.

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

-- 
   np: silence

Re: [devel] mgetty x86_64

[Hihin Ruslan]

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

Здравствуйте Anton Gorlov
  В сообщении от Saturday 13 January 2007 20:27 Anton Gorlov написал(a):
 > Денис Смирнов пишет:
 > > А mgetty на x86_64 когда-нибудь у нас будет? Без него какого-то
 > > censored
 > >
 > > hylafax не собирается.
 >
 > былб под руками 64 битная среда..посомтрел бы. Новый комп будет
 > через
 > неджелю.а вот с 64 битным сизифом дела очень плохо. Нету его у меня.
Всвязи со своим переездом на Athlon64 и соответственно переездом на 
x86_64 архитектуру попытался собрать несколько пакетов.
Заметил, что основная причина несборки построении пакетов - это то, что 
в x86_64 %_libdir, это /usr/lib64, а в i586 - /usr/lib, несмотря на это 
при сборке пакетов (makefele и т.п.) файлы попадают в /usr/lib, а 
не /usr/lib64. В частности по mgetty :

rpm -bE выдаёт :

%build
make
make -C voice

pushd frontends/X11/viewfax-2.5
xmkmf
make HELPDIR=/usr/lib64/mgetty+sendfax CONFDIR=/etc/mgetty+sendfax 
depend
make CDEBUGFLAGS="$RPM_OPT_FLAGS" HELPDIR=/usr/lib64/mgetty+sendfax 
CONFDIR=/etc/mgetty+sendfax
popd
.....
и в файлах :
...
%files sendfax
%dir /usr/lib64/mgetty+sendfax
/usr/lib64/mgetty+sendfax/faxq-helper
/usr/lib64/mgetty+sendfax/*.pbm
....

А реально получается :
find . | grep lib
./lib
./lib/mgetty+sendfax
./lib/mgetty+sendfax/faxq-helper
./lib/mgetty+sendfax/cour25n.pbm
./lib/mgetty+sendfax/cour25.pbm

То-же самое и у cdrecord (утром для себя собрал).

Тут надо что-то делать на уровне rpm и полиси сборки 
Например :
%_libdir -назначать независимо от архитектуры  (/usr/lib), 
а какой-нибудь %_libdir_arch - в зависимости от архитектуры: 
или /usr/lib, или /usr/lib64 
 Другой варинт - обратный %_libdir - зависим от архитектуры, 
а %_comm_libdir - независимо от архитектуры.
PS первый вариант менее трудоёмкий для пересборки.

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

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

Re: [devel] mgetty x86_64

[Dmitry V. Levin]

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

On Sat, Jan 13, 2007 at 10:00:37PM +0300, Hihin Ruslan wrote:
[...]
> Тут надо что-то делать на уровне rpm и полиси сборки 
> Например :
> %_libdir -назначать независимо от архитектуры  (/usr/lib), 
> а какой-нибудь %_libdir_arch - в зависимости от архитектуры: 
> или /usr/lib, или /usr/lib64 

Вы либо шутите либо празднуете.

>  Другой варинт - обратный %_libdir - зависим от архитектуры, 
> а %_comm_libdir - независимо от архитектуры.

Если вам нужно использовать /usr/lib - используйте /usr/lib.
Не надо злоупотреблять макросами.

> PS первый вариант менее трудоёмкий для пересборки.

:-))


-- 
ldv

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

Re: [devel] mgetty x86_64

[Hihin Ruslan]

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

Здравствуйте Dmitry V. Levin
  В сообщении от Saturday 13 January 2007 22:27 Dmitry V. Levin 

>нужно использовать /usr/lib - используйте /usr/lib.
 > Не надо злоупотреблять макросами.
 > > PS первый вариант менее трудоёмкий для пересборки.
 > >
 > :-))
Вопрос - кому нужен :)

Я ещё раз объясняю - если в %files прописано 
%_libdir/что-то, то на архитектуре x86_64 это выглядит так :
/usr/lib64
а на ix86 
/usr/lib
А реально файлы лежат независимо от прхитектуры в /usr/lib 
и таких пакетов .... :)

Я и спрашиваю - кому это нужно ?
-- 
С уважением Xихин Руслан

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

Re: [devel] mgetty x86_64

[Dmitry V. Levin]

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

On Sat, Jan 13, 2007 at 10:56:02PM +0300, Hihin Ruslan wrote:
>   В сообщении от Saturday 13 January 2007 22:27 Dmitry V. Levin 
> 
> >нужно использовать /usr/lib - используйте /usr/lib.
>  > Не надо злоупотреблять макросами.
>  > > PS первый вариант менее трудоёмкий для пересборки.
>  > >
>  > :-))
> Вопрос - кому нужен :)
> 
> Я ещё раз объясняю - если в %files прописано 
> %_libdir/что-то, то на архитектуре x86_64 это выглядит так :
> /usr/lib64
> а на ix86 
> /usr/lib

Значит, празднуете. :)

> А реально файлы лежат независимо от прхитектуры в /usr/lib 
> и таких пакетов .... :)
> 
> Я и спрашиваю - кому это нужно ?

Мантейнер по ошибке вместо /usr/lib написал %_libdir, надо повесить багу
или сделать NMU, обсуждать тут нечего.


-- 
ldv

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

Re: [devel] mgetty x86_64

[Sergey Y. Afonin]

On Sunday 14 January 2007 00:00, Dmitry V. Levin wrote:

> > Я и спрашиваю - кому это нужно ?
> 
> Мантейнер по ошибке вместо /usr/lib написал %_libdir, надо повесить багу
> или сделать NMU, обсуждать тут нечего.

Что-то теперь и я торможу. А зачем тогда lib64 ? Собирается-то пакет под 
x86_64, и библиотеки, соответственно, 64-разрядные получаться должны ?

-- 
С уважением, Сергей Афонин

Re: [devel] mgetty x86_64

[Dmitry V. Levin]

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

On Sun, Jan 14, 2007 at 01:05:42AM +0400, Sergey Y. Afonin wrote:
> On Sunday 14 January 2007 00:00, Dmitry V. Levin wrote:
> 
> > > Я и спрашиваю - кому это нужно ?
> > 
> > Мантейнер по ошибке вместо /usr/lib написал %_libdir, надо повесить багу
> > или сделать NMU, обсуждать тут нечего.
> 
> Что-то теперь и я торможу. А зачем тогда lib64 ? Собирается-то пакет под 
> x86_64, и библиотеки, соответственно, 64-разрядные получаться должны ?

А разве речь идёт о библиотеках?
/usr/lib/mgetty+sendfax/faxq-helper больше похоже на helper чем на
библиотеку.


-- 
ldv

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

Re: [devel] mgetty x86_64

[Sergey Y. Afonin]

On Sunday 14 January 2007 01:21, Dmitry V. Levin wrote:

> А разве речь идёт о библиотеках?
> /usr/lib/mgetty+sendfax/faxq-helper больше похоже на helper чем на
> библиотеку.

А, в таком виде понятно.

-- 
С уважением, Сергей Афонин

Re: [devel] mgetty x86_64

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [070114 00:30]:
> А разве речь идёт о библиотеках?
> /usr/lib/mgetty+sendfax/faxq-helper больше похоже на helper чем на
> библиотеку.
И место ему в %_libexecdir (который у нас по умолчанию везде
равен /usr/lib).

-- 
Regards,
Sir Raorn.

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

[devel] /lib(64)?/mkinitrd

[Sergey Vlasov]

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

On Sun, Jan 14, 2007 at 01:26:34AM +0300, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [070114 00:30]:
> > А разве речь идёт о библиотеках?
> > /usr/lib/mgetty+sendfax/faxq-helper больше похоже на helper чем на
> > библиотеку.
> И место ему в %_libexecdir (который у нас по умолчанию везде
> равен /usr/lib).

Кстати, в свете этих рассуждений - стоит ли /%_lib/mkinitrd держать
именно в /%_lib, или же положить раз и навсегда в /lib/mkinitrd (как,
например, /lib/udev)?  В текущей ситуации туда неудобно класть куски
скриптов для initramfs.

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

Re: [devel] /lib(64)?/mkinitrd

[Dmitry V. Levin]

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

On Sun, Jan 21, 2007 at 02:02:44PM +0300, Sergey Vlasov wrote:
> On Sun, Jan 14, 2007 at 01:26:34AM +0300, Alexey I. Froloff wrote:
> > * Dmitry V. Levin <ldv@> [070114 00:30]:
> > > А разве речь идёт о библиотеках?
> > > /usr/lib/mgetty+sendfax/faxq-helper больше похоже на helper чем на
> > > библиотеку.
> > И место ему в %_libexecdir (который у нас по умолчанию везде
> > равен /usr/lib).
> 
> Кстати, в свете этих рассуждений - стоит ли /%_lib/mkinitrd держать
> именно в /%_lib, или же положить раз и навсегда в /lib/mkinitrd (как,
> например, /lib/udev)?  В текущей ситуации туда неудобно класть куски
> скриптов для initramfs.

Лучше пусть будет /lib/mkinitrd, это более правильно.
На самом деле это не так важно, сама по себе поддержка initramfs сейчас
важнее.


-- 
ldv

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

Re: [devel] mgetty x86_64

[Hihin Ruslan]

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

Здравствуйте Sergey Y. Afonin
  В сообщении от Sunday 14 January 2007 00:05 Sergey Y. Afonin 
написал(a):
 > On Sunday 14 January 2007 00:00, Dmitry V. Levin wrote:
 > > > Я и спрашиваю - кому это нужно ?
 > >
 > > Мантейнер по ошибке вместо /usr/lib написал %_libdir, надо
 > > повесить багу
 > >
 > > или сделать NMU, обсуждать тут нечего.
 >
 > Что-то теперь и я торможу. А зачем тогда lib64 ? Собирается-то пакет
 > под
 >
 > x86_64, и библиотеки, соответственно, 64-разрядные получаться должны
 > ?
Так они и получаются 64-разрядными, только при сборке они оказываются 
в /usr/lib, а не в /usr/lib64, если они должны лежать в /usr/lib64, то 
для 64-разрядной архитектуры нужно или
- их в спеке "вручную" переносить в /usr/lib64 
- или в %files указывать не %_libdir, а /usr/lib

PS %_libexecdir то-же указывает на /usr/lib64

user>rpm --eval %_libexecdir
/usr/lib64
user>rpm --eval %_libdir
/usr/lib64

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

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

Re: [devel] mgetty x86_64

[Anton Gorlov]

Hihin Ruslan пишет:

>  > > или сделать NMU, обсуждать тут нечего.
>  > Что-то теперь и я торможу. А зачем тогда lib64 ? Собирается-то пакет
>  > под
>  > x86_64, и библиотеки, соответственно, 64-разрядные получаться должны
>  > ?
> Так они и получаются 64-разрядными, только при сборке они оказываются 
> в /usr/lib, а не в /usr/lib64, если они должны лежать в /usr/lib64, то 
> для 64-разрядной архитектуры нужно или
> - их в спеке "вручную" переносить в /usr/lib64 
> - или в %files указывать не %_libdir, а /usr/lib

1) Вы уверены то это именно либа? Что говорит file на то что оказывается 
в  /usr/lib?
Если это таки либа -то патчить сырцы.

-- 
   np: silence

Re: [devel] mgetty x86_64

[Alexey I. Froloff]

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

* Hihin Ruslan <ruslandh@> [070114 00:40]:
> PS %_libexecdir то-же указывает на /usr/lib64
У вас что-то в сборочной среде поломано...

> user>rpm --eval %_libexecdir
> /usr/lib64
> user>rpm --eval %_libdir
> /usr/lib64
raorn@vraorn64:pts/0 ~ $ rpm --eval %_libexecdir
/usr/lib
raorn@vraorn64:pts/0 ~ $ rpm --eval %_libdir
/usr/lib64

-- 
Regards,
Sir Raorn.

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

Re: [devel] mgetty x86_64

[Eugene Ostapets]

14.01.07, Alexey I. Froloff<raorn immo.ru> написал(а):
> raorn@vraorn64:pts/0 ~ $ rpm --eval %_libexecdir
> /usr/lib
> raorn@vraorn64:pts/0 ~ $ rpm --eval %_libdir
> /usr/lib64
За что я любил старый "глячный" etersoft-build-utils, так это за
%_libexecdir == /usr/lib/libexec на любой платформе, что позволяло
отлаживать сборку пакетов под x86_64, будучи на i386...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] mgetty x86_64

[Pavlov Konstantin]

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

On Sunday 14 January 2007 01:28, Alexey I. Froloff wrote:
> * Hihin Ruslan <ruslandh@> [070114 00:40]:
> > PS %_libexecdir то-же указывает на /usr/lib64
>
> У вас что-то в сборочной среде поломано...
>
> > user>rpm --eval %_libexecdir
> > /usr/lib64
> > user>rpm --eval %_libdir
> > /usr/lib64

Знамо что:
thresh@snowflake ~ $ rpm --lastchange rpm-build-compat | sed 's,@,.,g'
* Чтв Ноя 02 2006 Vitaly Lipatov <lav.altlinux.ru> 0.8-alt3

- fix _libexecdir
thresh@snowflake /etc/rpm/macros.d $ grep libexec compat
#%_libexecdir %_prefix/lib
%_libexecdir %_libdir


-- 
Pavlov Konstantin,
ALT Linux Team,
VideoLAN Team,
jid: thresh@altlinux.org

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

Re: [devel] rpm-build-compat

[Dmitry V. Levin]

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

On Sun, Jan 14, 2007 at 01:54:07AM +0300, Pavlov Konstantin wrote:
> On Sunday 14 January 2007 01:28, Alexey I. Froloff wrote:
> > * Hihin Ruslan <ruslandh@> [070114 00:40]:
> > > PS %_libexecdir то-же указывает на /usr/lib64
> >
> > У вас что-то в сборочной среде поломано...
> >
> > > user>rpm --eval %_libexecdir
> > > /usr/lib64
> > > user>rpm --eval %_libdir
> > > /usr/lib64
> 
> Знамо что:
> thresh@snowflake ~ $ rpm --lastchange rpm-build-compat | sed 's,@,.,g'
> * Чтв Ноя 02 2006 Vitaly Lipatov <lav.altlinux.ru> 0.8-alt3
> 
> - fix _libexecdir
> thresh@snowflake /etc/rpm/macros.d $ grep libexec compat
> #%_libexecdir %_prefix/lib
> %_libexecdir %_libdir

Второй раз на те же грабли.

Так, давайте договоримся не переопределять системные rpm-макросы файлами
из /etc/rpm/macros.d/ без письменного согласия мантейнера файла
/usr/lib/rpm/macros.


-- 
ldv

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

Re: [devel] rpm-build-compat

[Eugene Ostapets]

14.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> Второй раз на те же грабли.
>
> Так, давайте договоримся не переопределять системные rpm-макросы файлами
> из /etc/rpm/macros.d/ без письменного согласия мантейнера файла
> /usr/lib/rpm/macros.
Давайте договоримся о "preinstalled" конфигурациях hasher!!! Я
вынужден использовать собственный пакет rpm-build, который Required:
x86_64-compat, содержащий один-единственный файл
/etc/tpm/zzz_fake64build с уже озвученым содержимым....
Есть два варианта:
1) Мы делает libexecdir == libdir
2) Мы реализуем в hasher возможность задания "predefined"
add_packagelist, куда любой майнтейнер включает x86_64-compat и решает
для себя проблему (i386) %_libdir==%_libexecdir, но (x86_64)
%_libexecdir != %_libdir

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] rpm-build-compat

[Dmitry V. Levin]

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

On Sun, Jan 14, 2007 at 01:32:57AM +0200, Eugene Ostapets wrote:
> 14.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> > Второй раз на те же грабли.
> >
> > Так, давайте договоримся не переопределять системные rpm-макросы файлами
> > из /etc/rpm/macros.d/ без письменного согласия мантейнера файла
> > /usr/lib/rpm/macros.
> Давайте договоримся о "preinstalled" конфигурациях hasher!!!

Простите, а при чём тут hasher?

> Я вынужден использовать собственный пакет rpm-build, который Required:
> x86_64-compat, содержащий один-единственный файл
> /etc/tpm/zzz_fake64build с уже озвученым содержимым....
> Есть два варианта:
> 1) Мы делает libexecdir == libdir

Один уже сделал.
Вы будете учиться на чужих ошибках или предпочитаете на своих?

> 2) Мы реализуем в hasher возможность задания "predefined"
> add_packagelist, куда любой майнтейнер включает x86_64-compat и решает
> для себя проблему (i386) %_libdir==%_libexecdir, но (x86_64)
> %_libexecdir != %_libdir

Вы действительно полагаете, что проблему i386 != x86-64 можно решать таким
способом?

Мантейнер, который использует макрос %_libexecdir, полагается на то, что
его значение одинаково на всех платформах, на которых одинаково значение
макроса %_bindir.

На что рассчитываете вы, я просто не могу понять.
Тоже, наверное, шутите или празднуете.


-- 
ldv

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

Re: [devel] rpm-build-compat

[Eugene Ostapets]

14.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> On Sun, Jan 14, 2007 at 01:32:57AM +0200, Eugene Ostapets wrote:
> > 14.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> > > Второй раз на те же грабли.
> > >
> > > Так, давайте договоримся не переопределять системные rpm-макросы файлами
> > > из /etc/rpm/macros.d/ без письменного согласия мантейнера файла
> > > /usr/lib/rpm/macros.
> > Давайте договоримся о "preinstalled" конфигурациях hasher!!!
> Простите, а при чём тут hasher?
А у нас есть другой механизм рекомендованой сборки пакетов???
>
> > Я вынужден использовать собственный пакет rpm-build, который Required:
> > x86_64-compat, содержащий один-единственный файл
> > /etc/tpm/zzz_fake64build с уже озвученым содержимым....
> > Есть два варианта:
> > 1) Мы делает libexecdir == libdir
>
> Один уже сделал.
> Вы будете учиться на чужих ошибках или предпочитаете на своих?
Все, (для не умеющих читать - ВСЕ мои пакеты вылечились для платформы
x86_64 с использованием ошибочной версии etersoft-build-utils). Я знаю
что бывают пакеты, для которых требуется интелект, подхватих парочку
таких из orphaned я это оценил на своей шкуре, но... Возможность на
автомет проверить пакеты на САМУЮ ТИПИЧНУЮ ошибку облегчит жизнь
майнтейнерам... Эта ошибка НЕ зависит от майнтейнера... Она диктуется
autotools-howto и политикой самого распространеного дистрибутива
линукс - RedHat(Fedora), который плюет на FHS и поддерживает
существование LIBEXECDIR
>
> > 2) Мы реализуем в hasher возможность задания "predefined"
> > add_packagelist, куда любой майнтейнер включает x86_64-compat и решает
> > для себя проблему (i386) %_libdir==%_libexecdir, но (x86_64)
> > %_libexecdir != %_libdir
>
> Вы действительно полагаете, что проблему i386 != x86-64 можно решать таким
> способом?
99% проблем именно так решается, у меня более сотни пакетов, из
которых почти 40 не собирались на 64 бит платформе из-за этого бага...
>
> Мантейнер, который использует макрос %_libexecdir, полагается на то, что
> его значение одинаково на всех платформах, на которых одинаково значение
> макроса %_bindir.
При чем тут майнтейнер??? Использование %_libexecdir прописывается
авторами пакета в секции install... А вот идеологи дистрибутива решают
чему равняется libexecdir... В некоторых итрибутивах она всегда
равняется %_libdir, где-то она равна /usr/libexecdir, а вот у нас она
зависит от платформы... У нас вообще странная поддержка платформ не
равных i586... Точнее этой поддержки нет... ВООБЩЕ нет!!!(Пусть
кто-нибудь попробует собрать bootstrap-alt под qemu-arm или что-то
подобное - он сразу поймет что лучше свалить на другой дистрибутив,
чем трахаться с альтом...). И поддержка wine в будущем Мастер 3.1
x86_64 тоже под странным вопросом... Во всех "ведущих" (по карйней мре
известных мне) дистрибутивах есть поддержка biarch и только ALT
заявляет что "biarch -  это миф"...
>
> На что рассчитываете вы, я просто не могу понять.
Я рассчитываю на помощь со стороны вендора... Есть уникальный (я не
знаю аналогов, только SuSE пытается создать что-то подбное) - hasher,
есть типичная ошибка mainstream (связанная в первую очередь с
несогласованностью вендоров), и есть идея - создать механиз
(необязательный, но рекомендуемый для майнтейнеров), который позволит
на этап сборки определить потенциальную ошибку...
> Тоже, наверное, шутите или празднуете.
Мне жаль что Вы уже празднуете и так относитесь к вполне вменяемым
идеям. Наличие Hasher - единственное что позволяет мне использовать
Альт в реальной жизни, "глючный" etersoft-build-utils - то, что
позволяло мне собирать пакеты для Альт во время "перекуров" на
"типичном" железе, но с Вашей позицией у меня возникает желание
последовать за Булавой  и Зубковым - зачем тратить время и силы, если
это никому ненужно и вызывает только поток критики...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] rpm-build-compat

[Dmitry V. Levin]

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

On Sun, Jan 14, 2007 at 02:09:48AM +0200, Eugene Ostapets wrote:
> 14.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> > On Sun, Jan 14, 2007 at 01:32:57AM +0200, Eugene Ostapets wrote:
> > > 14.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> > > > Второй раз на те же грабли.
> > > >
> > > > Так, давайте договоримся не переопределять системные rpm-макросы файлами
> > > > из /etc/rpm/macros.d/ без письменного согласия мантейнера файла
> > > > /usr/lib/rpm/macros.
> > > Давайте договоримся о "preinstalled" конфигурациях hasher!!!
> > Простите, а при чём тут hasher?
> А у нас есть другой механизм рекомендованой сборки пакетов???

hasher это технология сборки, а не rpm-build-*.

> > > Я вынужден использовать собственный пакет rpm-build, который Required:
> > > x86_64-compat, содержащий один-единственный файл
> > > /etc/tpm/zzz_fake64build с уже озвученым содержимым....
> > > Есть два варианта:
> > > 1) Мы делает libexecdir == libdir
> >
> > Один уже сделал.
> > Вы будете учиться на чужих ошибках или предпочитаете на своих?
> Все, (для не умеющих читать - ВСЕ мои пакеты вылечились для платформы
> x86_64 с использованием ошибочной версии etersoft-build-utils). Я знаю
> что бывают пакеты, для которых требуется интелект, подхватих парочку
> таких из orphaned я это оценил на своей шкуре, но... Возможность на
> автомет проверить пакеты на САМУЮ ТИПИЧНУЮ ошибку облегчит жизнь
> майнтейнерам... Эта ошибка НЕ зависит от майнтейнера... Она диктуется
> autotools-howto и политикой самого распространеного дистрибутива
> линукс - RedHat(Fedora), который плюет на FHS и поддерживает
> существование LIBEXECDIR

Нет, вы не понимаете.  Хуже того, вы не читаете того что я вам уже
написал.  Повторяю ещё раз:
Те, кто используют макрос %_libexecdir, полагаются на то, что его значение
одинаково на всех платформах, на которых одинаково значение макроса %_bindir.

> > > 2) Мы реализуем в hasher возможность задания "predefined"
> > > add_packagelist, куда любой майнтейнер включает x86_64-compat и решает
> > > для себя проблему (i386) %_libdir==%_libexecdir, но (x86_64)
> > > %_libexecdir != %_libdir
> >
> > Вы действительно полагаете, что проблему i386 != x86-64 можно решать таким
> > способом?
> 99% проблем именно так решается, у меня более сотни пакетов, из
> которых почти 40 не собирались на 64 бит платформе из-за этого бага...

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

> > Мантейнер, который использует макрос %_libexecdir, полагается на то, что
> > его значение одинаково на всех платформах, на которых одинаково значение
> > макроса %_bindir.
> При чем тут майнтейнер??? Использование %_libexecdir прописывается
> авторами пакета в секции install... А вот идеологи дистрибутива решают
> чему равняется libexecdir... В некоторых итрибутивах она всегда
> равняется %_libdir, где-то она равна /usr/libexecdir, а вот у нас она
> зависит от платформы...

СТОП.  У нас libexecdir НЕ зависит от платформы.
Ваши рассуждения строятся неверном предположении.

> У нас вообще странная поддержка платформ не равных i586

Какая есть.  Я никому не мешаю сделать фиктивный biarch более реальным.

> > На что рассчитываете вы, я просто не могу понять.
> Я рассчитываю на помощь со стороны вендора... Есть уникальный (я не
> знаю аналогов, только SuSE пытается создать что-то подбное) - hasher,
> есть типичная ошибка mainstream (связанная в первую очередь с
> несогласованностью вендоров), и есть идея - создать механиз
> (необязательный, но рекомендуемый для майнтейнеров), который позволит
> на этап сборки определить потенциальную ошибку...

Я не вижу проблемы, помимо ошибки в rpm-build-compat, из-за которой у
некоторых возникло искажённое представление о платформе.

2lav: Виталий, я надеюсь на скорейшее исправление пакета rpm-build-compat,
а то уже как минимум два человека введены в заблуждение.

> > Тоже, наверное, шутите или празднуете.
> Мне жаль что Вы уже празднуете и так относитесь к вполне вменяемым
> идеям.

Я не уловил у вас никакой идеи кроме как поменять системный %_libexecdir
с нынешнего платформонезависимого значения /usr/lib на платформозависимое
значение %_libdir.
Единственное чем я могу вам помочь - это терпеливо разъяснять почему
этого ни в коем случае делать нельзя.


-- 
ldv

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

Re: [devel] rpm-build-compat

[Vitaly Lipatov]

On Sunday 14 January 2007 03:34, Dmitry V. Levin wrote:
...
> Я не вижу проблемы, помимо ошибки в rpm-build-compat, из-за
> которой у некоторых возникло искажённое представление о
> платформе.
>
> 2lav: Виталий, я надеюсь на скорейшее исправление пакета
> rpm-build-compat, а то уже как минимум два человека введены в
> заблуждение.
Поскольку я 
а) уже один раз исправил:
thresh@snowflake ~ $ rpm --lastchange rpm-build-compat | 
sed 's,@,.,g'
* Чтв Ноя 02 2006 Vitaly Lipatov <lav.altlinux.ru> 0.8-alt3

- fix _libexecdir

thresh@snowflake /etc/rpm/macros.d $ grep libexec compat
#%_libexecdir %_prefix/lib
%_libexecdir %_libdir

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

в) так и не понял, почему оба варианта
%_libexecdir %_prefix/lib
%_libexecdir %_libdir
оказались неправильными.

г) не помню, почему _libexecdir оказался в rpm-build-compat

я удаляю определение этого макроса из rpm-build-compact
(alt4) 

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


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

Re: [devel] rpm-build-compat

[Dmitry V. Levin]

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

On Sun, Jan 14, 2007 at 04:05:44AM +0300, Vitaly Lipatov wrote:
> On Sunday 14 January 2007 03:34, Dmitry V. Levin wrote:
> ...
> > Я не вижу проблемы, помимо ошибки в rpm-build-compat, из-за
> > которой у некоторых возникло искажённое представление о
> > платформе.
> >
> > 2lav: Виталий, я надеюсь на скорейшее исправление пакета
> > rpm-build-compat, а то уже как минимум два человека введены в
> > заблуждение.
> Поскольку я 
> а) уже один раз исправил:
> thresh@snowflake ~ $ rpm --lastchange rpm-build-compat | 
> sed 's,@,.,g'
> * Чтв Ноя 02 2006 Vitaly Lipatov <lav.altlinux.ru> 0.8-alt3
> 
> - fix _libexecdir
> 
> thresh@snowflake /etc/rpm/macros.d $ grep libexec compat
> #%_libexecdir %_prefix/lib
> %_libexecdir %_libdir

Предыдущее значение, насколько я помню, было не %_prefix/lib а
%_prefix/libexec.

> б) до сих пор не умею определять макросы только в случае
> если они ещё не определены

В .rpmmacros это не так просто сделать.

> в) так и не понял, почему оба варианта
> %_libexecdir %_prefix/lib
> %_libexecdir %_libdir
> оказались неправильными.

Насколько я помню, вместо первого варианта был %_prefix/libexec.

> г) не помню, почему _libexecdir оказался в rpm-build-compat

Зачем-то понадобилось переопределить.

> я удаляю определение этого макроса из rpm-build-compact
> (alt4) 

OK

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

Мне тоже интересно, существует ли способ сделать такое в .rpmmacros.


-- 
ldv

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

Re: [devel] rpm-build-compat

[Vitaly Lipatov]

On Sunday 14 January 2007 04:29, Dmitry V. Levin wrote:
> On Sun, Jan 14, 2007 at 04:05:44AM +0300, Vitaly Lipatov wrote:
> > On Sunday 14 January 2007 03:34, Dmitry V. Levin wrote:
> > ...
> >
> > > Я не вижу проблемы, помимо ошибки в rpm-build-compat,
> > > из-за которой у некоторых возникло искажённое
> > > представление о платформе.
> > >
> > > 2lav: Виталий, я надеюсь на скорейшее исправление пакета
> > > rpm-build-compat, а то уже как минимум два человека
> > > введены в заблуждение.
> >
> > Поскольку я
> > а) уже один раз исправил:
> > thresh@snowflake ~ $ rpm --lastchange rpm-build-compat |
> > sed 's,@,.,g'
> > * Чтв Ноя 02 2006 Vitaly Lipatov <lav.altlinux.ru> 0.8-alt3
> >
> > - fix _libexecdir
> >
> > thresh@snowflake /etc/rpm/macros.d $ grep libexec compat
> > #%_libexecdir %_prefix/lib
> > %_libexecdir %_libdir
>
> Предыдущее значение, насколько я помню, было не %_prefix/lib а
> %_prefix/libexec.
Я посмотрел в CVS, там был libexec, потом %_prefix/lib, 
потом %_libdir...


> > б) до сих пор не умею определять макросы только в случае
> > если они ещё не определены
>
> В .rpmmacros это не так просто сделать.
в /etc/rpm/macros.d/* аналогично?

> > г) не помню, почему _libexecdir оказался в rpm-build-compat
>
> Зачем-то понадобилось переопределить.
Это было одновременно с соответствующей кампанией (обсуждали 
значение этого макроса) и как я посчитал пришли к решению, 
которое я и зафиксировал.

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


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

Re: [devel] rpm-build-compat

[Dmitry V. Levin]

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

On Sun, Jan 14, 2007 at 05:43:52PM +0300, Vitaly Lipatov wrote:
[...]
> > Предыдущее значение, насколько я помню, было не %_prefix/lib а
> > %_prefix/libexec.
> Я посмотрел в CVS, там был libexec, потом %_prefix/lib, 
> потом %_libdir...

Все мыслимые значения были испробованы. :)

> > > б) до сих пор не умею определять макросы только в случае
> > > если они ещё не определены
> >
> > В .rpmmacros это не так просто сделать.
> в /etc/rpm/macros.d/* аналогично?

Да, у них одинаковый синтаксис.

> > > г) не помню, почему _libexecdir оказался в rpm-build-compat
> >
> > Зачем-то понадобилось переопределить.
> Это было одновременно с соответствующей кампанией (обсуждали 
> значение этого макроса) и как я посчитал пришли к решению, 
> которое я и зафиксировал.

Мы действительно тогда долго обсуждали, менять ли _libexecdir с /usr/lib
на /usr/libexec, но к окончательному мнению не пришли.
Мне кажется, что от такого глобального изменения сломается больше чем
починится.

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

Про rpm сложно утверждать что-либо наверняка...


-- 
ldv

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

Re: [devel] rpm-build-compat

[Sergey Y. Afonin]

On Sunday 14 January 2007 19:03, Dmitry V. Levin wrote:

> Мы действительно тогда долго обсуждали, менять ли _libexecdir с /usr/lib
> на /usr/libexec, но к окончательному мнению не пришли.
> Мне кажется, что от такого глобального изменения сломается больше чем
> починится.

А если оставить, как есть, не вызовет ли это дальнейший рост граблей ?
Чем дальше, тем сложнее менять, наверное... _libexecdir в каком количестве 
спеков используется сейчас ?

-- 
С уважением, Сергей Афонин

Re: [devel] rpm-build-compat

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [070114 18:12]:
> Мы действительно тогда долго обсуждали, менять ли _libexecdir с /usr/lib
> на /usr/libexec, но к окончательному мнению не пришли.
Некоторые пакеты сами переопределяют _libexecdir на
%_prefix/libexec...

> Мне кажется, что от такого глобального изменения сломается больше чем
> починится.
Сложный вопрос.  То что это поможет определить неправильное
использование libdir/libexecdir я пости уверен.  Другой вопрос,
кто добровольно согласится проделать эту работу.

-- 
Regards,
Sir Raorn.

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

Re: [devel] rpm-build-compat

[Dmitry V. Levin]

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

On Sun, Jan 14, 2007 at 08:36:03PM +0300, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [070114 18:12]:
> > Мы действительно тогда долго обсуждали, менять ли _libexecdir с /usr/lib
> > на /usr/libexec, но к окончательному мнению не пришли.
> Некоторые пакеты сами переопределяют _libexecdir на
> %_prefix/libexec...

И у меня есть несколько таких пакетов.

> > Мне кажется, что от такого глобального изменения сломается больше чем
> > починится.
> Сложный вопрос.  То что это поможет определить неправильное
> использование libdir/libexecdir я пости уверен.  Другой вопрос,
> кто добровольно согласится проделать эту работу.

Я сомневаюсь что это на практике приведёт к исправлению.
А вот к поломке -- легко.


-- 
ldv

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

[devel] [wiki] условное определение макросов

[Michael Shigorin]

On Sun, Jan 14, 2007 at 04:05:44AM +0300, Vitaly Lipatov wrote:
> б) до сих пор не умею определять макросы только в случае
> если они ещё не определены

e.g.

%{?!_desktopdir:%define _desktopdir %_datadir/applications}

Не придумав ничего лучше, добавил в
http://wiki.sisyphus.ru/devel/SampleSpecs

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

Re: [devel] [wiki] условное определение макросов

[Dmitry V. Levin]

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

On Sun, Feb 04, 2007 at 11:28:56PM +0200, Michael Shigorin wrote:
> On Sun, Jan 14, 2007 at 04:05:44AM +0300, Vitaly Lipatov wrote:
> > б) до сих пор не умею определять макросы только в случае
> > если они ещё не определены
> 
> e.g.
> 
> %{?!_desktopdir:%define _desktopdir %_datadir/applications}

Только Виталий спрашивал про синтаксис rpmmacros, а не про синтаксис
spec-файлов.


-- 
ldv

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

Re: [devel] rpm-build-compat

[Sergey Y. Afonin]

On Sunday 14 January 2007 04:34, Dmitry V. Levin wrote:

> > При чем тут майнтейнер??? Использование %_libexecdir прописывается
> > авторами пакета в секции install... А вот идеологи дистрибутива решают
> > чему равняется libexecdir... В некоторых итрибутивах она всегда
> > равняется %_libdir, где-то она равна /usr/libexecdir, а вот у нас она
> > зависит от платформы...
> 
> СТОП.  У нас libexecdir НЕ зависит от платформы.
> Ваши рассуждения строятся неверном предположении.

Такой вопрос. А, может, всё-таки, стоит нарушить FHS ? Чем плохо существование
отдельного libexecdir ? Сложно избавиться от желания утащить libexecdir вслед
за libdir, если есть привычка, что они равны... А так всё будет достаточно 
логично.

И это, а почему это нарушение ?

/lib<qual> : Alternate format essential shared libraries (optional)
Purpose

There may be one or more variants of the /lib directory on systems which support 
more than one binary format requiring separate libraries. [14]

Почему "qual" обязательно цифра ?

-- 
С уважением, Сергей Афонин

Re: [devel] rpm-build-compat

[Dmitry V. Levin]

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

On Sun, Jan 14, 2007 at 02:28:07PM +0400, Sergey Y. Afonin wrote:
> On Sunday 14 January 2007 04:34, Dmitry V. Levin wrote:
> 
> > > При чем тут майнтейнер??? Использование %_libexecdir прописывается
> > > авторами пакета в секции install... А вот идеологи дистрибутива решают
> > > чему равняется libexecdir... В некоторых итрибутивах она всегда
> > > равняется %_libdir, где-то она равна /usr/libexecdir, а вот у нас она
> > > зависит от платформы...
> > 
> > СТОП.  У нас libexecdir НЕ зависит от платформы.
> > Ваши рассуждения строятся неверном предположении.
> 
> Такой вопрос. А, может, всё-таки, стоит нарушить FHS ? Чем плохо существование
> отдельного libexecdir ?

Иногда удобно, я сам использую /usr/libexec в некоторых своих пакетах.

> Сложно избавиться от желания утащить libexecdir вслед
> за libdir, если есть привычка, что они равны...

А разве есть такая привычка?

> А так всё будет достаточно логично.
> 
> И это, а почему это нарушение ?
> 
> /lib<qual> : Alternate format essential shared libraries (optional)
> Purpose
> 
> There may be one or more variants of the /lib directory on systems which support 
> more than one binary format requiring separate libraries. [14]
> 
> Почему "qual" обязательно цифра ?

Дело не в том что цифра, а в том что "shared libraries".


-- 
ldv

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

Re: [devel] rpm-build-compat

[Sergey Y. Afonin]

On Sunday 14 January 2007 15:45, Dmitry V. Levin wrote:

> > Сложно избавиться от желания утащить libexecdir вслед
> > за libdir, если есть привычка, что они равны...
> 
> А разве есть такая привычка?

Судя по всему, да. :-)

> > Почему "qual" обязательно цифра ?
> 
> Дело не в том что цифра, а в том что "shared libraries".

Так, стоп. Это я ошибся. Для /usr/lib<qual> :

/usr/lib<qual> performs the same role as /usr/lib for an alternate binary format, 
except that the symbolic links /usr/lib<qual>/sendmail and /usr/lib<qual>/X11 are 
not required.

-- 
С уважением, Сергей Афонин

Re: [devel] rpm-build-compat

[Alexey I. Froloff]

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

* Eugene Ostapets <eostapets@> [070114 03:11]:
> Все, (для не умеющих читать - ВСЕ мои пакеты вылечились для платформы
> x86_64 с использованием ошибочной версии etersoft-build-utils).
А мои пакеты не ломались и без использования левых "utils".

-- 
Regards,
Sir Raorn.

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

Re: [devel] mgetty x86_64

[Eugene Ostapets]

13.01.07, Hihin Ruslan<ruslandh altlinux.ru> написал(а):
> Здравствуйте Dmitry V. Levin
>   В сообщении от Saturday 13 January 2007 22:27 Dmitry V. Levin
>
> >нужно использовать /usr/lib - используйте /usr/lib.
>  > Не надо злоупотреблять макросами.
>  > > PS первый вариант менее трудоёмкий для пересборки.
>  > >
>  > :-))
> Вопрос - кому нужен :)
>
> Я ещё раз объясняю - если в %files прописано
> %_libdir/что-то, то на архитектуре x86_64 это выглядит так :
> /usr/lib64
> а на ix86
> /usr/lib
> А реально файлы лежат независимо от прхитектуры в /usr/lib
> и таких пакетов .... :)
Хм... Есть еще libexecdir (старый etersoft-build-utils, пока в нем не
исправили багу, здорово помогола собирать пакеты на x86, которые
нормально потом собирались и работали на x86_64)
>
> Я и спрашиваю - кому это нужно ?
Авторам, которые плевать хотели на FHS и пытаются ставить пакеты или
их части в libexecdir...

На самом деле пакет, предоставляющий:
echo '%_libexecdir /usr/lib' >> /etc/rpm/zzz_fake64build
и опционально подключающийся к хешеру решил бы 99% проблем сборки
пакетов под x86_64

PS: to ldv@ как на счет такого расширения функционала хешера?
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] mgetty x86_64

[Dmitry V. Levin]

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

On Sat, Jan 13, 2007 at 10:03:36PM +0200, Eugene Ostapets wrote:
> 13.01.07, Hihin Ruslan<ruslandh altlinux.ru> написал(а):
> > Здравствуйте Dmitry V. Levin
> >   В сообщении от Saturday 13 January 2007 22:27 Dmitry V. Levin
> >
> > >нужно использовать /usr/lib - используйте /usr/lib.
> >  > Не надо злоупотреблять макросами.
> >  > > PS первый вариант менее трудоёмкий для пересборки.
> >  > >
> >  > :-))
> > Вопрос - кому нужен :)
> >
> > Я ещё раз объясняю - если в %files прописано
> > %_libdir/что-то, то на архитектуре x86_64 это выглядит так :
> > /usr/lib64
> > а на ix86
> > /usr/lib
> > А реально файлы лежат независимо от прхитектуры в /usr/lib
> > и таких пакетов .... :)
> Хм... Есть еще libexecdir (старый etersoft-build-utils, пока в нем не
> исправили багу, здорово помогола собирать пакеты на x86, которые
> нормально потом собирались и работали на x86_64)
> >
> > Я и спрашиваю - кому это нужно ?
> Авторам, которые плевать хотели на FHS и пытаются ставить пакеты или
> их части в libexecdir...
> 
> На самом деле пакет, предоставляющий:
> echo '%_libexecdir /usr/lib' >> /etc/rpm/zzz_fake64build
> и опционально подключающийся к хешеру решил бы 99% проблем сборки
> пакетов под x86_64
> 
> PS: to ldv@ как на счет такого расширения функционала хешера?

Если вам нужен /usr/lib - используйте /usr/lib, зачем вам макросы?


-- 
ldv

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

Re: [devel] mgetty x86_64

[Eugene Ostapets]

13.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> > Хм... Есть еще libexecdir (старый etersoft-build-utils, пока в нем не
> > исправили багу, здорово помогола собирать пакеты на x86, которые
> > нормально потом собирались и работали на x86_64)
> > >
> > > Я и спрашиваю - кому это нужно ?
> > Авторам, которые плевать хотели на FHS и пытаются ставить пакеты или
> > их части в libexecdir...
> >
> > На самом деле пакет, предоставляющий:
> > echo '%_libexecdir /usr/lib' >> /etc/rpm/zzz_fake64build
> > и опционально подключающийся к хешеру решил бы 99% проблем сборки
> > пакетов под x86_64
> >
> > PS: to ldv@ как на счет такого расширения функционала хешера?
>
> Если вам нужен /usr/lib - используйте /usr/lib, зачем вам макросы?
Мне??? Мне не нужно!!! А вот пакет ставится в libexecdir... Как
майнтейнера меня это напрягает в свете отсутсвия понятия libexecdir в
FHS, но я не Дон Кихот и я не собираюсь положить жизнь на борьбу с
ветряными мельницами...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] mgetty x86_64

[Konstantin A. Lepikhov]

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

Hi Hihin!

Saturday 13, at 10:00:37 PM you wrote:

> То-же самое и у cdrecord (утром для себя собрал).
> 
А не обязаны они про lib64 знать. И уж тем более, cdrecord, который вообще
плюет на все гнутые тулзы и LSB.

-- 
WBR et al.

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

Re: [devel] cdrecord

[Dmitry V. Levin]

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

On Sat, Jan 13, 2007 at 10:29:15PM +0300, Konstantin A. Lepikhov wrote:
> Saturday 13, at 10:00:37 PM you wrote:
> 
> > То-же самое и у cdrecord (утром для себя собрал).
> > 
> А не обязаны они про lib64 знать. И уж тем более, cdrecord, который вообще
> плюет на все гнутые тулзы и LSB.

Между прочим, существует cdrkit, который упраздняет cdrecord.


-- 
ldv

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

Re: [devel] cdrecord

[Hihin Ruslan]

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

Здравствуйте Dmitry V. Levin
  В сообщении от Saturday 13 January 2007 22:32 Dmitry V. Levin 
написал(a):
 > Между прочим, существует cdrkit, который упраздняет cdrecord.
Да при чём тут это :)

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

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

Re: [devel] cdrecord

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Saturday 13, at 10:32:16 PM you wrote:

> On Sat, Jan 13, 2007 at 10:29:15PM +0300, Konstantin A. Lepikhov wrote:
> > Saturday 13, at 10:00:37 PM you wrote:
> > 
> > > То-же самое и у cdrecord (утром для себя собрал).
> > > 
> > А не обязаны они про lib64 знать. И уж тем более, cdrecord, который вообще
> > плюет на все гнутые тулзы и LSB.
> 
> Между прочим, существует cdrkit, который упраздняет cdrecord.
это проверено кем-нибудь? :)

-- 
WBR et al.

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

Re: [devel] mgetty x86_64

[Anton Gorlov]

Hihin Ruslan пишет:
> Заметил, что основная причина несборки построении пакетов - это то, что 
> в x86_64 %_libdir, это /usr/lib64, а в i586 - /usr/lib, несмотря на это 
> при сборке пакетов (makefele и т.п.) файлы попадают в /usr/lib, а 
> не /usr/lib64. В частности по mgetty :

Дайте мне рычаг и я..
В общем мне mgetty нужен..но пока не получу сиизф 64 битный - чтото 
сделать не смогу. тут вроде 1 вариант наклюнулся -но  наша почта очень 
быстрая и всё такое. На работе к несчастью слить не могу.. хотя инет атм 
есть..но лимиты не от меня зависят

-- 
   np: silence