Bug 22276 - Не собирается
: Не собирается
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/python-module-kinterbasdb)
: unstable
: all Linux
: P3 critical
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2009-11-13 08:11 by
Modified: 2010-01-17 13:04 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-11-13 08:11:56
Проблему локализовал: файл kinterbasdb/_kiservices.c, строки 39-41, но до
починки не дошёл, просьба мейнтейнера починить.

x86_64-alt-linux-gcc -pthread -fno-strict-aliasing -DNDEBUG -pipe -Wall -O2
-fPIC -DPIC -D_GNU_SOU    RCE -fPIC -UNDEBUG -I/usr/include/python2.6
-I/usr/include/python2.6 -c _kiservices.c -o build/tem   
p.linux-x86_64-2.6/_kiservices.o -pedantic -g -std=c99 -fno-strict-aliasing
-pthread -O3          
In file included from /usr/include/string.h:658,                                
                 from /usr/include/python2.6/Python.h:38,                       
                 from _kinterbasdb.h:33,                                        
                 from _kiservices.h:21,                                         
                 from _kiservices.c:18:                                         
In function 'memcpy',                                                           
    inlined from 'pyob_query_base' at _kiservices.c:363:                        
/usr/include/bits/string3.h:52: error: call to __builtin___memcpy_chk will
always overflow destination buffer
------- Comment #1 From 2009-11-13 08:51:35 -------
попробую. спасибо-)
------- Comment #2 From 2009-11-13 11:35:11 -------
ужас какой-то. я думаю, если оно никому не нужно, то его можно выкинуть. мне
оно уже не нужно особо.
------- Comment #3 From 2009-11-13 11:42:20 -------
Дамир предложил решение:

>  334   char spb[6];
>  335   char *spb_walk = spb;
> 
> Размер буфера - 6 байт.
> Этого не хватает, чтобы вместить unsigned long на x86_64 (8 байт),
> который туда суется через memcpy.
> 
> Для решения можно исправить в строке 334 число 6 на число 10.

1. Могу при пересборке с python 2.6 это сделать.
2. Можете Вы это сделать раньше.
3. Пакет Ваш, решать Вам, удалять ли его. Но я бы для начала в devel@ спросил. 

Если к моменту пересборки пакет ещё будет в сизифе, я воспользуюсь тем
решением, что приведено выше (и пунктом 1).
------- Comment #4 From 2009-11-13 11:47:43 -------
(В ответ на комментарий №3)
> Дамир предложил решение:
> 
> >  334   char spb[6];
> >  335   char *spb_walk = spb;
> > 
> > Размер буфера - 6 байт.
> > Этого не хватает, чтобы вместить unsigned long на x86_64 (8 байт),
> > который туда суется через memcpy.
> > 
> > Для решения можно исправить в строке 334 число 6 на число 10.
> 
> 2. Можете Вы это сделать раньше.

спасибо, я приложу.
------- Comment #5 From 2009-11-13 12:08:43 -------
python-module-kinterbasdb-3.3.0-alt3 -> sisyphus:

* Fri Nov 13 2009 Boris Savelev <boris@altlinux> 3.3.0-alt3

- fix x86_64 build (closes: #22276)
------- Comment #6 From 2009-11-13 13:33:41 -------
Это "решение", скорее всего, приводит к сборке неработоспособного кода на
x86_64 (а на big-endian архитектурах этот код не работал и раньше).
http://lists.altlinux.org/pipermail/devel/2009-November/177234.html
------- Comment #7 From 2009-11-13 13:55:45 -------
Так если пакет никому не нужен, не проще ли его просто выкинуть?
------- Comment #8 From 2009-11-13 14:08:18 -------
(В ответ на комментарий №7)
> Так если пакет никому не нужен, не проще ли его просто выкинуть?

я не против.
------- Comment #9 From 2009-11-13 16:19:38 -------
написал баг, в апстрим.
------- Comment #10 From 2010-01-15 09:19:27 -------
Ну так что решили? Реакции в апстриме нет, пакет, насколько выясняется, никому
не нужен. Выбрасываем?
------- Comment #11 From 2010-01-15 13:47:33 -------
(В ответ на комментарий №10)
> Ну так что решили? Реакции в апстриме нет, пакет, насколько выясняется, никому
> не нужен. Выбрасываем?

я не против.
------- Comment #12 From 2010-01-15 15:52:55 -------
task #18713: added #1: delete package python-module-kinterbasdb from sisyphus
------- Comment #13 From 2010-01-17 13:04:37 -------
x c