Re: Status of sqlalchemy

2024-04-15 Thread 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



Re: Status of sqlalchemy

2024-04-15 Thread 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

2024-04-15 Thread 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

2024-04-15 Thread 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 = 

Re: Status of sqlalchemy

2024-04-15 Thread 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

2024-04-15 Thread 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

2024-04-15 Thread 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=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)



Bug#1069016: ITP: python-btsocket -- Python interface for BlueZ Bluetooth Management API

2024-04-15 Thread Edward Betts
Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: python-btsocket
  Version : 0.2.0
  Upstream Author : Barry Byford 
* URL : https://github.com/ukBaz/python-btsocket
* License : MIT
  Programming Lang: Python
  Description : Python interface for BlueZ Bluetooth Management API

  This package provides a Python interface to the BlueZ Bluetooth Management
  API, which is the official Linux Bluetooth protocol stack. This library is
  particularly useful for developers needing to interact with Bluetooth
  hardware at a low level using Python. It offers functionalities to control
  and monitor Bluetooth devices directly from a Linux system.
  .
  The library is in the early stages of development and currently requires root
  privileges for most operations. It supports different programming models to
  handle Bluetooth commands and responses, making it adaptable to various
  development needs. This package is ideal for developers involved in embedded
  systems, home automation, or educational projects requiring direct control
  over Bluetooth hardware.

I plan to maintain this package as part of the Python team.