Re: Status of sqlalchemy

[Thomas Goirand]

On 4/14/24 23:23, Martin wrote:

Hi,

are there any news regarding the status of sqlalchemy?
I'm curious, because the next version of gajim will depend on
sqlalchemy >= 2, which is only in experimental right now.

Cheers


Hi,

As much as I know, Piotr has been nicely putting this on old until the 
OpenStack packages could be fixed. Thanks for the patience. OpenStack 
2024.1 (aka: Caracal) was released 2 weeks ago, and I uploaded all of it 
in Unstable. It's nice much better.


Let me give you a quick comment on the situation.

I'm still waiting on Manila support which is the most annoying one. I've 
been told that upstream Manila will backport all the SQLA 2.x fixes when 
they land in Master.


As per this:
https://qa.debian.org/excuses.php?experimental=1&package=sqlalchemy

SQLA 2.x will also break Trove and Zaqar, but we can probably live with 
them broken until the next release of OpenStack. I care more about Trove 
(OpenStack DB as a service) than Zaqar (Messaging as a Service). I hope 
Trove upstream contributors will fix the situation, but at this point I 
don't know the status. I don't really use gertty, and I'm unsure why 
it's doing unit tests against SQLA. These could probably be ignored.


The rest of:
- pymodbus
- sqlalchemy-utc
- wtforms-alchemy

I don't even know what they do.

All that to say: I'm ok at this point if SQLA 2.x is uploaded to Sid and 
we move on...


Cheers,

Thomas Goirand (zigo)

Re: Status of sqlalchemy

[Alexandre Detiste]

Le lun. 15 avr. 2024 à 11:20, Thomas Goirand  a écrit :
> The rest of:
> - pymodbus
>
> I don't even know what they do.

Life is better when one does not have to deal with modbus :-)
This package is outdated and need a refresh.

> All that to say: I'm ok at this point if SQLA 2.x is uploaded to Sid and
> we move on...

Agreed, please move on

Re: Status of sqlalchemy

[Martin]

Quoting Thomas Goirand :

The rest of:
- pymodbus
- sqlalchemy-utc
- wtforms-alchemy

I don't even know what they do.

All that to say: I'm ok at this point if SQLA 2.x is uploaded to Sid  
and we move on...


I'll check, if I can update pymodbus, which is some versions behind
upstream. Maybe that already fixes things.

I don't know about the other two: I feel uneasy to break them, but we
need SQLAlchemy 2.x anyway, looks like 1.x is not supported anymore.

If nobody objects (or is faster than me), I'll upload SQLAlchemy 2.x
to unstable in a couple of days or weeks. No hurry from my side.

Cheers

Re: Status of sqlalchemy

[Piotr Ożarowski]

sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and
3.12) somewhere in pysqlite:

[…]
test/orm/inheritance/test_assorted_poly.py::MultiOfTypeContainsEagerTest_joined::test_big_query[not_use_criteria-contains_eager]
 PASSED 
 [  1%]
test/orm/inheritance/test_assorted_poly.py::MultiOfTypeContainsEagerTest_joined::test_big_query[not_use_criteria-joinedload]
Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
#1  0x75e7d84b in sqlite3DbStrDup () from 
/lib/x86_64-linux-gnu/libsqlite3.so.0
#2  0x75eb3dde in ?? () from /lib/x86_64-linux-gnu/libsqlite3.so.0
#3  0x75edef9c in sqlite3WalkSelect () from 
/lib/x86_64-linux-gnu/libsqlite3.so.0
#4  0x75eb2bb5 in ?? () from /lib/x86_64-linux-gnu/libsqlite3.so.0
#5  0x75edef9c in sqlite3WalkSelect () from 
/lib/x86_64-linux-gnu/libsqlite3.so.0
#6  0x75eb42fd in sqlite3SelectPrep () from 
/lib/x86_64-linux-gnu/libsqlite3.so.0
#7  0x75eb4558 in sqlite3Select () from 
/lib/x86_64-linux-gnu/libsqlite3.so.0
#8  0x75e8c24e in sqlite3Parser () from 
/lib/x86_64-linux-gnu/libsqlite3.so.0
#9  0x75ebb345 in sqlite3RunParser () from 
/lib/x86_64-linux-gnu/libsqlite3.so.0
#10 0x75e93d39 in ?? () from /lib/x86_64-linux-gnu/libsqlite3.so.0
#11 0x75e94aa1 in ?? () from /lib/x86_64-linux-gnu/libsqlite3.so.0
#12 0x75e94eea in sqlite3_prepare_v2 () from 
/lib/x86_64-linux-gnu/libsqlite3.so.0
#13 0x767ea3bb in pysqlite_statement_create 
(connection=connection@entry=0x7fffef167880, sql=) at 
../Modules/_sqlite/statement.c:59
#14 0x767ea111 in pysqlite_connection_call (self=0x7fffef167880,
args=('SELECT unithead.id, employee.id AS id_1, employee.name, 
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS 
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id 
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS 
employee_1 JOIN manager AS manager_1 ON employee_1.id = manager_1.id) ON 
employee_1.id = employee_m2m_1."right" AND employee_1.type = ?) ON employee.id 
= employee_m2m_1."left"',), kwargs=0x0)
at ../Modules/_sqlite/connection.c:1786
#15 0x00582bb2 in _PyObject_Call (tstate=0xbb04a8 <_PyRuntime+459656>, 
callable=,
args=('SELECT unithead.id, employee.id AS id_1, employee.name, 
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS 
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id 
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS 
employee_1 JOIN manager AS manager_1 ON employee_1.id = manager_1.id) ON 
employee_1.id = employee_m2m_1."right" AND employee_1.type = ?) ON employee.id 
= employee_m2m_1."left"',), kwargs=)
at ../Objects/call.c:367
#16 0x00698320 in bounded_lru_cache_wrapper (self=0x7fffeea89170,
args=('SELECT unithead.id, employee.id AS id_1, employee.name, 
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS 
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id 
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS 
employee_1 JOIN manager AS manager_1 ON employee_1.id = manager_1.id) ON 
employee_1.id = employee_m2m_1."right" AND employee_1.type = ?) ON employee.id 
= employee_m2m_1."left"',), kwds=0x0)
at ../Modules/_functoolsmodule.c:1020
#17 0x0052ccc3 in _PyObject_MakeTpCall (tstate=0xbb04a8 
<_PyRuntime+459656>,
callable=, __module__='sqlite3', __doc__='SQLite database connection 
object.', __wrapped__=) at remote 
0x7fffeea89170>,
args=, nargs=1, keywords=0x0) at ../Objects/call.c:240
#18 0x767e8e90 in get_statement_from_cache (
operation='SELECT unithead.id, employee.id AS id_1, employee.name, 
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS 
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id 
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS 
employee_1 JOIN manager AS manager_1 ON employee_1.id = manager_1.id) ON 
employee_1.id = employee_m2m_1."right" AND employee_1.type = ?) ON employee.id 
= employee_m2m_1."left"', self=0x7fffec6989c0)
at ../Modules/_sqlite/cursor.c:510
#19 _pysqlite_query_execute (self=, multiple=0,
operation='SELECT unithead.id, employee.id AS id_1, employee.name, 
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS 
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id 
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS 
employee_1 JOIN manager AS manager_1 ON employee_1.id = manage

Re: Status of sqlalchemy

[Thomas Goirand]

On 4/15/24 12:04, Martin wrote:

If nobody objects (or is faster than me), I'll upload SQLAlchemy 2.x
to unstable in a couple of days or weeks. No hurry from my side.

Cheers


Please don't do this alone. Ask Piotr, as he's been the usual maintainer 
of the package.


Cheers,

Thomas Goirand (zigo)

Re: Status of sqlalchemy

[Martin]

Quoting Piotr Ożarowski :

sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and
3.12) somewhere in pysqlite:

...

I will upload to unstable once I figure that one out


Perfect! I prefer not to mess with the package, if I don't have to ;-)
Thanks, Piotr!

Re: Status of sqlalchemy

[Carsten Schoenert]

Hi,

Am 15.04.24 um 11:20 schrieb Thomas Goirand:


The rest of:
...
- wtforms-alchemy


I'll try to have a look at this library.

--
Regards
Carsten