Вот тут:
http://sisyphus.ru/ru/srpm/Sisyphus/atlas/changelog
сказано, что последнее изменение было сделано роботом. Попытка обновления с таким изменением вылетает с руганью на прикладываемый патч, который был создан роботом. Надеюсь, этот робот знает, что делать дальше...

Евгений,
вы совысем совсем не подумавши баг повесили (ночью спать надо)
робот там не при чем, он пока патчи писать не умеет. 
Это старинный патч, его делал Алексей Турбин. 
то, что название atlas-3.7.11-alt6.qa1.patch,
это потому что в git rules и в спеке так написано.
а не прикладывается, потому что к старой версии написан...

я тоже, кстати. Это же не мой баг, почему я его открываю...

Извиняюсь, коли так.

И я не весил баг, я на него отвечал. Предварительно попробовав обновить...

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

А пакет висит на @nobody :(
А это очень плохо для такого важного пакета...

Похоже, желающих помочь не найдётся.

Попробую на выходных поковырять.

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

У меня он пока застопорился на этапе make (т.е. патч я уже поправил и добавил вызов configure). В общем, пока дело двигается, но со скрипом, так что возиться буду наскоками, ибо полностью сесть и начать его ковырять непрерывно нет времени.

atlas-3.9.25-alt1 -> sisyphus:

* Thu Oct 21 2010 Eugeny A. Rostovtsev (REAL) <real at altlinux> 3.9.25-alt1
- Version 3.9.25 (ALT #24252)

(In reply to comment #8)
> atlas-3.9.25-alt1 -> sisyphus:
> 
> * Thu Oct 21 2010 Eugeny A. Rostovtsev (REAL) <real at altlinux> 3.9.25-alt1
> - Version 3.9.25 (ALT #24252)

видимо надо и numpy с ней пересобрать, а то
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from numpy.linalg import *

In [2]: from numpy.random import *

In [3]: m=randn(2000,2000)

In [4]: %time U,s,V=svd(m)
Ошибка сегментирования
[vv@tao-vp ~]$

Не воспроизводится. Приаттачте какой-нибудь скрипт, попробую.

(In reply to comment #10)
> Не воспроизводится. Приаттачте какой-нибудь скрипт, попробую.

На 64bit не воспроизводится?
Возможно я не все библиотеки обновил, полный дист-апргрэйд у меня удаляет
некоторые важные пакеты из x86_32. Может что то не дошло
Я обновил
libatlas+devel, liblapack+devel,liblaspack

"На 64bit не воспроизводится?"

Угу.

"Возможно я не все библиотеки обновил, полный дист-апргрэйд у меня удаляет
некоторые важные пакеты из x86_32"

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

segmentation fault,
видимо из-за того что у меня  еще интел фортран.Я отключил переменные ifort в bash_profile. Так что с этой стороны все должно быть чисто. 
Вы бы не могли показать
результаты
from numpy.random import *
from numpy.linalg import *
m=randn(1000,1000)
%time U,s,V=svd(m)

у меня выдал LinAlgError: SVD did not converge. Сейчас попробую пересобрать libatlas под себя

> "На 64bit не воспроизводится?"
> 
> Угу.
> 
> "Возможно я не все библиотеки обновил, полный дист-апргрэйд у меня удаляет
> некоторые важные пакеты из x86_32"
> 
> А это уже другой вопрос. Сейчас идёт процесс массовой пересборки гигантского
> количества пакетов, поэтому лучше переджать, пока всё устаканится. А точечные
> апгрейды, вероятно, ещё больше всё усложняют.

> "На 64bit не воспроизводится?"
> 
> Угу.
> 
Видимо системы разные:-)
Сейчас поставил обратно старую версию  и все работает.
А новый пакет у меня даже не собрался. Ладно подождем пока кто-нибудь из юзеров нарвется

In [1]: from numpy.random import *

In [2]: from numpy.linalg import *

In [3]: m=randn(1000,1000)

In [4]: %time U,s,V=svd(m)
CPU times: user 4.43 s, sys: 0.09 s, total: 4.52 s
Wall time: 4.52 s


"Видимо системы разные:-)"

Я ежедневно обновляюсь до сизифа.

(In reply to comment #15)
> In [1]: from numpy.random import *
> 
> In [2]: from numpy.linalg import *
> 
> In [3]: m=randn(1000,1000)
> 
> In [4]: %time U,s,V=svd(m)
> CPU times: user 4.43 s, sys: 0.09 s, total: 4.52 s
> Wall time: 4.52 s
> 
> 
> "Видимо системы разные:-)"
> 
> Я ежедневно обновляюсь до сизифа.

Сегодня специально не пожалел времени и протестировал
на виртуальной машине sisyphus на i586, и x86_64
на первой ваш libatlas работает и показывает прекрасный результат
в виде 2.29 на этом тесте, на 64bit не работает, svd выдает диагностику что процесс не сходится, самое печальное для меня что eig не рабочий тоже.
Ну да ладно хорошо, что хоть у кого то работает.
Удачи!

Может быть, я всё же позволю дать совет (Вам необязательно ему следовать, но обычно он помогает): сделайте dist-upgrade. Если часть пакетов при этом вынесет, их всегда можно установить позже (одним днём весь сизиф не пересобрать).

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

(In reply to comment #17)
> Может быть, я всё же позволю дать совет (Вам необязательно ему следовать, но
> обычно он помогает): сделайте dist-upgrade. Если часть пакетов при этом
> вынесет, их всегда можно установить позже (одним днём весь сизиф не
> пересобрать).
> 
> В любом случае, точечные обновления, как не раз показывала практика, с
> лёгкостью ломают то, что до этого прекрасно работало.
Я так и сделал. У меня стоит интел фортран локально. Для того чтобы исключить проблему интерференции, я использовал виртуальную машину на которой был сделан dist-upgrade. Я пробовал i586 и 64бит. В первом случае работает а во втором нет.
Процессор, интел core2 duo p8700. Кроме того, гарантированно работает старая версия пакета. Таким образом, врядли проблема состоит в моих локальных настройках. Предположения два: либо у вас локальные настройки, позволяющие держать две версии библиотек (это легко увидеть если посмотреть что использует нумпиевский lapack_lite.so), либо эта сборка не работает на моем процессоре,

Я на всякий случай пересоберу NumPy, SciPy, да и matplotlib заодно. Всё равно все пакеты, использующие ATLAS и/или LAPACK, пересобирать придётся.

Кстати, насчёт виртуальных машин, Вроде бы Вы ранее сообщали о нехватке памяти при работе с NumPy. Есть вероятность, что причины идентичны или каким-либо образом связаны.

(In reply to comment #20)
> Кстати, насчёт виртуальных машин, Вроде бы Вы ранее сообщали о нехватке памяти
> при работе с NumPy. Есть вероятность, что причины идентичны или каким-либо
> образом связаны.
Было дело с виртуальной машиной на для i586. Тогда я памяти добавил и проблема ушла. Наверно я сумбурно объясняюсь, но чтобы небыло непоняток я подитожу мой опыт.
1)есть ноутбук - macbook pro5.5, cpu p8700 2.53Gz, 4G ram. На нем сизиф 64 бит, последний полный дистапгрэйд. Линейная алгебра не пашет, не сходятся ни eig ни svd. Я подозревал интерференцию с интел MKL. Однако, приэтом нет проблем со старой библиотекой (3.7)
2) Для исключения подозрений попробовал поставить сизиф с беты на виртуальной машине. Памяти ей дал > 2G. Имеем, на i586 все работает на 64 бит - нет.

Для полной проверки нужен чистый пример без питона, просто фортран и слинковать с atlas

"Для полной проверки нужен чистый пример без питона, просто фортран и слинковать
с atlas"

Жду :)

Created attachment 4625 [details]
лог ошибок

автоматически создался при компиляции atlas

Лог неудачной сборки приложен выше. Лог сборки rpm обрывается на
execstack -fPIC -m64 -fPIC -DDCPLX -DFindingJITCPCE -I./ /home/vv/RPM/BUILD/ATLAS/BUILD/..//src/blas/gemm/ATL_gemm.c
make[5]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/src/blas/gemm'
gcc -DL2SIZE=4194304 -I/home/vv/RPM/BUILD/ATLAS/BUILD/include -I/home/vv/RPM/BUILD/ATLAS/BUILD/..//include -I/home/vv/RPM/BUILD/ATLAS/BUILD/..//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_Core2 -DATL_CPUMHZ=2520  -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664 -DWALL -DATL_DYLIBS -DATL_NCPU=2 -DATL_TRUST_OMP -fomit-frame-pointer -mfpmath=sse -msse2 -O2 -g -Wa,--noexecstack -fPIC -m64 -fPIC -o xzdfindCE zdfindCE.o \
                   /home/vv/RPM/BUILD/ATLAS/BUILD/src/blas/gemm/ATL_zdFindCE_mm.o /home/vv/RPM/BUILD/ATLAS/BUILD/lib/libatlas.a -lpthread -lm
/home/vv/RPM/BUILD/ATLAS/BUILD/bin/ATLrun.sh /home/vv/RPM/BUILD/ATLAS/BUILD/tune/blas/gemm xzdfindCE -f res/atlas_zdNKB.h
/home/vv/RPM/BUILD/ATLAS/BUILD/bin/ATLrun.sh: line 4:  2033 Segmentation fault      $atldir/$*
make[4]: *** [zdRunFindCE] Error 139
make[4]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/tune/blas/gemm'
make[3]: *** [res/atlas_zdNKB.h] Error 2
make[3]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/tune/blas/gemm'
make[2]: *** [/home/vv/RPM/BUILD/ATLAS/BUILD/tune/blas/gemm/res/atlas_zdNKB.h] Error 2
make[2]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/bin'
ERROR 843 DURING CACHE EDGE DETECTION!!.
make[2]: Entering directory `/home/vv/RPM/BUILD/ATLAS/BUILD/bin'
cd /home/vv/RPM/BUILD/ATLAS/BUILD ; make error_report
make[3]: Entering directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
make -f Make.top error_report
make[4]: Entering directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
uname -a 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
gcc -v 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
Using built-in specs.
Target: x86_64-alt-linux
Configured with: ../configure --host=x86_64-alt-linux --build=x86_64-alt-linux --target=x86_64-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --program-suffix=-4.4 --with-slibdir=/lib64 --with-bugurl=http://bugzilla.altlinux.org --enable-bootstrap --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-checking=release --with-system-zlib --without-included-gettext --enable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,java,ada --enable-java-awt=gtk --disable-plugin --with-native-libdir=/usr/lib64/gcj-4.4 --with-ecj-jar=/usr/share/java/ecj.jar --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.4-1.5.0.0/jre --enable-libgcj-multifile --disable-libjava-multilib --enable-java-maintainer-mode --with-arch_32=i586 --with-tune_32=generic
Thread model: posix
gcc version 4.4.5 20101001 (ALT Linux 4.4.5-alt1) (GCC) 
gcc -V 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
x86_64-alt-linux-gcc: '-V' option must have argument
make[4]: [error_report] Error 1 (ignored)
gcc --version 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
tar cf error_HAMMER64SSE2.tar Make.inc bin/INSTALL_LOG/*
gzip --best error_HAMMER64SSE2.tar
mv error_HAMMER64SSE2.tar.gz error_HAMMER64SSE2.tgz
make[4]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
make[3]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
make[2]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/bin'
Error report error_<ARCH>.tgz has been created in your top-level ATLAS
directory.  Be sure to include this file in any help request.
cat: ../../CONFIG/error.txt: No such file or directory
cat: ../../CONFIG/error.txt: No such file or directory
make[1]: *** [build] Error 255
make[1]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
make: *** [build] Error 2
make: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
ошибка: Неверный код возврата из /home/vv/tmp/rpm-tmp.70936 (%build)


Ошибки сборки пакетов:
    Неверный код возврата из /home/vv/tmp/rpm-tmp.70936 (%build)


Зачем на 64 бит --with-arch_32=i586 --with-tune_32=generic??

Ошибка похоже исправлена (выделил ___) в версии 3.9.27:

ATLAS 3.9.27 released 10/20/10, changes from 3.9.26:
   * Fixed several bugs to allow L2 BLAS to install using a low-res timer
   * Fixed bug in x8664 kernel description causing seg faults for _____CGER_____
   * Fixed bug in r1hgen and r2hgen where first kernel's minM was ignored
   * Fixed bug in ATL_her/her2 where j-loop max was N rather than NN
   * Fixed bug so that h2gen.c generates ATL_GENGERK as a function that
     can handle all operations, not just least restricted kernel.
   * Fixed bug in ATL_syr & syr2 where nr computed incorrectly
   * Fixed cblas_[nrm2,asum,iamax,scal] so that they return with no
     operations if incX < 1 (this matches f77 behavior)
   * Fixed bug with extra spaces in configure's OSX libtool finding script
ATLAS 3.9.26 released 10/18/10, changes from 3.9.25:
   * Much improved GEMV & GER performance for x86-64:
     + Addition of SSE/x86-64 GER/GEMV generators
     + Complete rewrite of GEMV tuning infrastructure
     + Change to GER kernel API to minimize parameter passing
     + Arch defaults for Core264SSE3 & AMD64K10h64SSE3 updated
   * ANSI C code generators for MVT, MVN, R1 and R2.
     + should improve non-x86/x86-64 performance
   * Started rewrite of all L2BLAS:
     + GEMVT, GEMVN, GER, SYR, SYR2, HER, HER2 built from optimized kernels
     - TRMV, TRSV, SYMV, HEMV just call reference implementation
   * Bug fixes:
     + Fixed kernel testers & timers to correctly handle alignments,
       particularly ALIGNX2A.
   * Basic support for POWER7
     + VSX detection
     + VSX GEMM, GEMVN & GEMVT kernels provided by Mike Kistler of IBM
     + Arch defs
   * Fixed it so GEMM kernel files use $(GOODGCC) instead of flat gcc
     if 'gcc' is specified (so they inherit flags like -pg, -m64, etc).

Пока не поздно...
Может быть для 6.0 лучше остаться на последней стабильной версии 3.8.3.
Нет гарантии, что выбранный релиз будет работать на новых процессорах

Последние сообщения - это Вы с кем говорили? Не со мной - явно :)

Я всё ещё жду ответа на #22.

PS. Нынешняя версия ATLAS в сизифе вполне стабильна (проверено как на сборках клиентских пакетов, так и людьми, которые с ним работают), обновлять его раньше появления бранча 6 не планирую (тут наоборот, нужно всё оставить по возможности предельно стабильным...).

У меня этот атлас не собирается, зачем тратить время на пример?
Эта сборка не рабочая со всех сторон на моем ноутбуке. Может проблема в процессоре или в памяти. Мне сейчас некогда с этим разбираться. Поставил на hold старую версию.
(In reply to comment #26)
> Последние сообщения - это Вы с кем говорили? Не со мной - явно :)
> 
> Я всё ещё жду ответа на #22.
> 
> PS. Нынешняя версия ATLAS в сизифе вполне стабильна (проверено как на сборках
> клиентских пакетов, так и людьми, которые с ним работают),
назовите пожалуйста архитектуру на которой тестировалась.
3.9.25 не везде может  работать. Смотрите чэнждлог от 3.9.27.
 
> обновлять его раньше
> появления бранча 6 не планирую (тут наоборот, нужно всё оставить по возможности
> предельно стабильным...).

(In reply to comment #26)
> Последние сообщения - это Вы с кем говорили? Не со мной - явно :)
> 
> Я всё ещё жду ответа на #22.
> 
> PS. Нынешняя версия ATLAS в сизифе вполне стабильна (проверено как на сборках
> клиентских пакетов, так и людьми, которые с ним работают), обновлять его раньше
> появления бранча 6 не планирую (тут наоборот, нужно всё оставить по возможности
> предельно стабильным...).

"У меня этот атлас не собирается, зачем тратить время на пример?"

Этот - который в сизифе? Если да, зачем Вы его собираете?

"Эта сборка не рабочая со всех сторон на моем ноутбуке."

Этот - который в сизифе?

"назовите пожалуйста архитектуру на которой тестировалась. 3.9.25 не везде может  работать"

На i586 (точнее - Pentium4 c HT) и на x86_64. "Не везде" - это где?

"Зачем на 64 бит --with-arch_32=i586 --with-tune_32=generic??"

Это вообще откуда? В сизифной сборке нет ничего подобного.

"Смотрите чэнждлог от 3.9.27."

Предлагаете обновить? ;) Если нет, зачем эта версия вообще упоминалась?

И всё же я жду результаты (см. комментарий #22) с atlas из сизифа. Всё остальное здесь написанное не имеет к теме никакого отношения.

PS. Кстати, уже доступна версия 3.9.28. Можно будет на днях ещё раз обновить.

(In reply to comment #29)
> И всё же я жду результаты (см. комментарий #22) с atlas из сизифа. Всё
> остальное здесь написанное не имеет к теме никакого отношения.
Это не просто. Потому как нужно тестировать для матриц большого размера.
Где-то больше 50x50. Пока ничего кроме диффузионного оператора с собственными занчениями в нулях функций Бесселя в голову не приходит. Для меньших матриц типа 2х2 и 3х3 вроде работает. Если у вас есть простой и доказательный пример, тогда я готов.
> 
> PS. Кстати, уже доступна версия 3.9.28. Можно будет на днях ещё раз обновить.

Мне честно говоря уже все равно, я считаю что в таких вещах лучше стабильность 
Зупустил пересборку через rpm --rebuild  и вроде этих странных макросов --with-arch_32=i586 --with-tune_32=generic нет. Раньше собирал rpm -ba atlas.spec

"Это не просто. Потому как нужно тестировать для матриц большого размера.
Где-то больше 50x50. Пока ничего кроме диффузионного оператора с собственными
занчениями в нулях функций Бесселя в голову не приходит."

Так за чем же дело встало?

"Если у вас есть простой и доказательный пример, тогда я готов."

Я не занимаюсь высшей математикой, я программист. А трясти своих коллег-кандидатов - это как-то неконструктивно, у них своя работа, и пока им обновление atlas никак не помешало. Поэтому я и жду примеров от заинтересованных людей (в данном случае - от Вас), раз Вы говорите, что что-то не работает, Вам и демонстрировать это неработу ;)

"Зупустил пересборку через rpm --rebuild  и вроде этих странных макросов
--with-arch_32=i586 --with-tune_32=generic нет. Раньше собирал rpm -ba
atlas.spec"

А в хэшере не пробовали?

(In reply to comment #32)
> "Зупустил пересборку через rpm --rebuild  и вроде этих странных макросов
> --with-arch_32=i586 --with-tune_32=generic нет. Раньше собирал rpm -ba
> atlas.spec"
> 
> А в хэшере не пробовали?
Сейчас попробую,
rpm --rebuild закончился неудачей после где-то часовой компиляции
+ lib=libatlas
+ shift
+ gcc -shared -Wl,--whole-archive libatlas.a -Wl,--no-whole-archive -o libatlas.so.3 -Wl,-soname=libatlas.so.3 -lm -Wl,-z,defs
libatlas.a(ATL_thread_start.o): In function `ATL_thread_start':
/home/vv/RPM/BUILD/ATLAS/BUILD/..//src/threads/ATL_thread_start.c:44: undefined reference to `pthread_attr_setaffinity_np'
и т.д. до
libatlas.a(ATL_thread_tree.o): In function `ATL_thread_tree':
/home/vv/RPM/BUILD/ATLAS/BUILD/..//src/pthreads/misc/ATL_thread_tree.c:84: undefined reference to `pthread_create'
collect2: ld returned 1 exit status
..
Меня еще мучают смутные сомнения насчет библиотек из x86_32? Это может влиять как то? На работу с  libatlas?

"+ gcc -shared -Wl,--whole-archive libatlas.a -Wl,--no-whole-archive -o
libatlas.so.3 -Wl,-soname=libatlas.so.3 -lm -Wl,-z,defs
libatlas.a(ATL_thread_start.o): In function `ATL_thread_start':
/home/vv/RPM/BUILD/ATLAS/BUILD/..//src/threads/ATL_thread_start.c:44: undefined
reference to `pthread_attr_setaffinity_np'"

Похоже на то, что в новых версиях появилась зависимость от libpthread. Достаточно в команду линковки добавить -lpthread перед -lm, видимо. Хотя это только предположения, у меня сейчас как раз идёт процесс сборки 3.9.28.

"Меня еще мучают смутные сомнения насчет библиотек из x86_32? Это может влиять
как то? На работу с  libatlas?"

Не знаю. Я про biarch ничего не знаю и не использую (нет необходимости).

(In reply to comment #34)
> "+ gcc -shared -Wl,--whole-archive libatlas.a -Wl,--no-whole-archive -o
> libatlas.so.3 -Wl,-soname=libatlas.so.3 -lm -Wl,-z,defs
> libatlas.a(ATL_thread_start.o): In function `ATL_thread_start':
> /home/vv/RPM/BUILD/ATLAS/BUILD/..//src/threads/ATL_thread_start.c:44: undefined
> reference to `pthread_attr_setaffinity_np'"
> 
> Похоже на то, что в новых версиях появилась зависимость от libpthread.
Я бьюсь над 3.9.25, src пакет взят из сизифа

"Я бьюсь над 3.9.25, src пакет взят из сизифа"

Зачем?

Вам лучше взять репозиторий с git.alt:/people/real/packages/atlas.git и пробовать собирать оттуда.

(In reply to comment #37)
> Вам лучше взять репозиторий с git.alt:/people/real/packages/atlas.git и
> пробовать собирать оттуда.
Долгая история, я уже забыл свой username. :-)
В хашере сборка прошла чисто и быстро. Я собирал 3.9.25. после установки  тест с svd работает. Однако время исполнения теста больше чем в 3.7, а я ожидал прироста производительности где-то в 1.5-2 раза, кроме того результаты  eig на моих кодах не являются правильными. Что ж, придется сделать тестовый пример.