[SRM] Stable update for perdition (1.17.1-2+lenny2)
Hi,
I would like the upload of 1.17.1-2+lenny2 considered.
My proposed upload resolves the following problems.
* mysql: Don't store MYSQL * return values in a long
- This seems problematic on architectures such as amd64 where
pointers are 8 bytes wide but long is only 4 bytes wide.
- As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/db00825e370f
* Resolve 4/8 byte problems raised in bug #595432)
- odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol()
+ This seems problematic on architectures such as amd64 where
size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only
4 bytes wide.
+ As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
- core: the return value of callbacks to vanessa_socket_pipe_func()
should be a ssize_t not an int.
+ This seems problematic on architectures such as amd64 where
ssize_t is 8 bytes wide but int is only 4 bytes wide.
+ As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
- (closes: #595432)
The diff of the proposed changes is as follows:
diff -u perdition-1.17.1/debian/changelog perdition-1.17.1/debian/changelog
--- perdition-1.17.1/debian/changelog
+++ perdition-1.17.1/debian/changelog
@@ -1,3 +1,27 @@
+perdition (1.17.1-2+lenny2) stable; urgency=low
+
+ * mysql: Don't store MYSQL * return values in a long
+ - This seems problematic on architectures such as amd64 where
+ pointers are 8 bytes wide but long is only 4 bytes wide.
+ - As per upstream patch
+ http://hg.vergenet.net/perdition/perdition/rev/db00825e370f
+ * Resolve 4/8 byte problems raised in bug #595432)
+ - odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol()
+ + This seems problematic on architectures such as amd64 where
+ size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only
+ 4 bytes wide.
+ + As per upstream patch
+ http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
+ - core: the return value of callbacks to vanessa_socket_pipe_func()
+ should be a ssize_t not an int.
+ + This seems problematic on architectures such as amd64 where
+ ssize_t is 8 bytes wide but int is only 4 bytes wide.
+ + As per upstream patch
+ http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
+ - (closes: #595432)
+
+ -- Simon Horman <horms@debian.org> Tue, 28 Sep 2010 00:35:13 +0900
+
perdition (1.17.1-2+lenny1) stable; urgency=low
* Don't call make from perdition prerm script
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/io.c
+++ perdition-1.17.1/perdition/io.c
@@ -517,7 +517,9 @@
*
**********************************************************************/
-static int __io_pipe_read(int fd, void *buf, size_t count, void *data){
+static ssize_t
+__io_pipe_read(int fd, void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
ssize_t bytes;
@@ -550,7 +552,9 @@
}
-static int __io_pipe_write(int fd, const void *buf, size_t count, void *data){
+static ssize_t
+__io_pipe_write(int fd, const void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/db/mysql/perditiondb_mysql.c
+++ perdition-1.17.1/perdition/db/mysql/perditiondb_mysql.c
@@ -206,21 +206,18 @@
size_t *len_return
){
MYSQL db;
- long rc;
MYSQL_RES *res;
MYSQL_ROW row;
char sqlstr[PERDITIONDB_MYSQL_QUERY_LENGTH];
size_t servername_len;
- rc = mysql_init(&db);
- if(!rc){
+ if (!mysql_init(&db)) {
perditiondb_mysql_log("mysql_init", &db);
vanessa_dynamic_array_destroy(a);
return(-1);
}
- rc = mysql_real_connect(&db,dbhost,dbuser,dbpwd,dbname,dbport,NULL,0);
- if(!rc){
+ if (!mysql_real_connect(&db,dbhost,dbuser,dbpwd,dbname,dbport,NULL,0)) {
perditiondb_mysql_log("mysql_connect", &db);
mysql_close(&db);
return(-1);
@@ -256,8 +253,7 @@
}
}
- rc = mysql_query(&db, sqlstr);
- if(rc){
+ if (mysql_query(&db, sqlstr)) {
perditiondb_mysql_log("mysql_query", &db);
mysql_close(&db);
return(-1);
Reply to: