[SRM] Stable update for perdition (1.17.1-2+lenny2)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[SRM] Stable update for perdition (1.17.1-2+lenny2)

Simon Horman
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 <[hidden email]>  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);


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100927154208.GA7819@...

Reply | Threaded
Open this post in threaded view
|

Re: [SRM] Stable update for perdition (1.17.1-2+lenny2)

Simon Horman
On Tue, Sep 28, 2010 at 12:42:08AM +0900, Simon Horman wrote:

> 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)

        Sorry, this should read

      - (closes: #597914)

      I will fix my proposed package accordingly.

>
> 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 <[hidden email]>  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);


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100927154403.GB7819@...

Reply | Threaded
Open this post in threaded view
|

Re: [SRM] Stable update for perdition (1.17.1-2+lenny2)

Julien Cristau-6
In reply to this post by Simon Horman
On Tue, Sep 28, 2010 at 00:42:08 +0900, Simon Horman wrote:

> 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
long and void * are the same size on all Debian architectures (amd64 has
8-byte longs), so the proposed change is effectively a nop.

>   * 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

That doesn't seem to be included in your proposed diff.

>     - 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

That one looks reasonable.

Cheers,
Julien

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#597914: [SRM] Stable update for perdition (1.17.1-2+lenny2)

Simon Horman
On Mon, Sep 27, 2010 at 06:35:57PM +0200, Julien Cristau wrote:

> On Tue, Sep 28, 2010 at 00:42:08 +0900, Simon Horman wrote:
>
> > 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
>
> long and void * are the same size on all Debian architectures (amd64 has
> 8-byte longs), so the proposed change is effectively a nop.

My bad, I'll drop that portion.

> >   * 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
>
> That doesn't seem to be included in your proposed diff.

Sorry, I'll send a revised version that includes that portion.

> >     - 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
>
> That one looks reasonable.

Thanks


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100928003434.GB1871@...

Reply | Threaded
Open this post in threaded view
|

Re: Bug#597914: [SRM] Stable update for perdition (1.17.1-2+lenny2)

Simon Horman
Hi Julien,

I have addressed your two concerns and the
change now looks the same as the one between 1.19~rc4-1 and 1.19~rc4-2.

The new changelog is:

  * Resolve 4/8 byte problems raised in bug #597914)
    - 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: #597914)

And the new diff is:

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,22 @@
+perdition (1.17.1-2+lenny2) stable; urgency=low
+
+  * Resolve 4/8 byte problems raised in bug #597914)
+    - 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: #597914)
+
+ -- Simon Horman <[hidden email]>  Tue, 28 Sep 2010 09:44:37 +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/odbc/perditiondb_odbc.c
+++ perdition-1.17.1/perdition/db/odbc/perditiondb_odbc.c
@@ -214,7 +214,7 @@
  char **str_return, size_t * len_return)
 {
  SQLINTEGER rc;
- SQLINTEGER rc2;
+ SQLLEN rc2;
  int status = -1;
  SQLHENV env;
  SQLHDBC hdbc;


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100928004909.GG1871@...

Reply | Threaded
Open this post in threaded view
|

Re: Bug#597914: [SRM] Stable update for perdition (1.17.1-2+lenny2)

Adam D Barratt
On Tue, 2010-09-28 at 09:49 +0900, Simon Horman wrote:

>   * Resolve 4/8 byte problems raised in bug #597914)
>     - 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: #597914)

Please go ahead.

Regards,

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/1285706352.16049.105.camel@...