Thread: psqlODBC 09.05.0200 Released
Hi, all. We are release of psqlODBC 09.05.0200. this is a some bugfix release. please see the notes at: psqlODBC may be downloaded from in source, Windows Installer, merge module, and basic zip file formats. New Windows installer installs both 32-bit and 64-bit driver at once on 64-bit OS. Both drivers may be needed on 64-bit OS because 32-bit applications require 32-bit driver and 64-bit applications require 64-bit driver. Please post any bug reports to the mailing list. I'd like to take this opportunity to thank all those involved with the development, testing and bug fixing of the updated driver. We are grateful to the help of many peoples. Thanks! -- psqlODBC team. email: pgsql-odbc@postgresql.org website: https://odbc.postgresql.org/
On 04/09/2016 07:36 AM, Hiroshi Saito wrote: > Hi, all. Thanks. > > We are release of psqlODBC 09.05.0200. this is a some bugfix release. > please see the notes at: https://odbc.postgresql.org/docs/release.html > > psqlODBC may be downloaded from in source, Windows Installer, > merge module, and basic zip file formats. > > New Windows installer installs both 32-bit and 64-bit driver at once > on 64-bit OS. Both drivers may be needed on 64-bit OS because 32-bit > applications require 32-bit driver and 64-bit applications require > 64-bit driver. > > Please post any bug reports to the mailing list. > > I'd like to take this opportunity to thank all those involved with the > development, testing and bug fixing of the updated driver. > > We are grateful to the help of many peoples. Thanks! > -- Adrian Klaver adrian.klaver@aklaver.com
Hi, fyi, I keep getting... + cat ./regression.diffs *** ./expected/param-conversions.out Sat Apr 9 14:19:08 2016 --- results/param-conversions.out Thu Apr 14 15:44:56 2016 *************** *** 72,83 **** Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"... SQLExecDirect failed ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1"; Error while executing the query Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"... SQLExecDirect failed ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1"; Error while executing the query Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"... --- 72,83 ---- Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"... SQLExecDirect failed ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1"; Error while executing the query Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"... SQLExecDirect failed ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1"; Error while executing the query Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"... + read line ... on Fedora 23. I'll try to look more carefuly next week unless there is somebody quicker than me. Thanks, Pavel
On Thursday 14 of April 2016 15:47:06 Pavel Raiskup wrote: > Hi, fyi, I keep getting... > > + cat ./regression.diffs > *** ./expected/param-conversions.out Sat Apr 9 14:19:08 2016 > --- results/param-conversions.out Thu Apr 14 15:44:56 2016 > *************** > *** 72,83 **** > > Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"... > SQLExecDirect failed > ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1"; > Error while executing the query > > Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"... > SQLExecDirect failed > ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1"; > Error while executing the query > > Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"... > --- 72,83 ---- > > Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"... > SQLExecDirect failed > ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1"; > Error while executing the query > > Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"... > SQLExecDirect failed > ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1"; > Error while executing the query > > Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"... > + read line > > ... on Fedora 23. I'll try to look more carefuly next week unless there > is somebody quicker than me. > > Thanks, Pavel Full log: https://kojipkgs.fedoraproject.org//work/tasks/9375/13659375/build.log Pavel
Weird, this should be reproducible almost everywhere, can somebody confirm? Seems like the attached patch should help, though it is a clear revert for commit d5374bcc4d58556eb5cc70241c44dcad4d9b441e. As there is no pointer from the original fix to any discussion or bug report, I believe this is regression and I'm proposing "as is". Can you point me somewhere so we can try to find a real fix for the original issue? Thanks! Pavel On Thursday 14 of April 2016 15:48:16 Pavel Raiskup wrote: > On Thursday 14 of April 2016 15:47:06 Pavel Raiskup wrote: > > Hi, fyi, I keep getting... > > > > + cat ./regression.diffs > > *** ./expected/param-conversions.out Sat Apr 9 14:19:08 2016 > > --- results/param-conversions.out Thu Apr 14 15:44:56 2016 > > *************** > > *** 72,83 **** > > > > Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"... > > SQLExecDirect failed > > ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1"; > > Error while executing the query > > > > Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"... > > SQLExecDirect failed > > ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1"; > > Error while executing the query > > > > Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"... > > --- 72,83 ---- > > > > Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"... > > SQLExecDirect failed > > ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1"; > > Error while executing the query > > > > Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"... > > SQLExecDirect failed > > ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1"; > > Error while executing the query > > > > Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"... > > + read line > > > > ... on Fedora 23. I'll try to look more carefuly next week unless there > > is somebody quicker than me. > > > > Thanks, Pavel > > Full log: > https://kojipkgs.fedoraproject.org//work/tasks/9375/13659375/build.log > > Pavel
Attachment
Hi Pavel, On 2016/04/18 22:02, Pavel Raiskup wrote: > Weird, this should be reproducible almost everywhere, can somebody > confirm? > > Seems like the attached patch should help, though it is a clear revert for > commit d5374bcc4d58556eb5cc70241c44dcad4d9b441e. As there is no pointer > from the original fix to any discussion or bug report, I believe this is > regression and I'm proposing "as is". Can you point me somewhere so we > can try to find a real fix for the original issue? The commit handles the bug report [ODBC] Issue with Money field using ODBC to Access database posted by John Van De Giessen on Febrary 14. The bug was introduced in 9.5.0100 and the regression test result maybe modified. regards, Hiroshi Inoue >>> Hi, fyi, I keep getting... >>> >>> + cat ./regression.diffs >>> *** ./expected/param-conversions.out Sat Apr 9 14:19:08 2016 >>> --- results/param-conversions.out Thu Apr 14 15:44:56 2016 >>> *************** >>> *** 72,83 **** >>> >>> Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"... >>> SQLExecDirect failed >>> ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1"; >>> Error while executing the query >>> >>> Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"... >>> SQLExecDirect failed >>> ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1"; >>> Error while executing the query >>> >>> Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"... >>> --- 72,83 ---- >>> >>> Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"... >>> SQLExecDirect failed >>> ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1"; >>> Error while executing the query >>> >>> Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"... >>> SQLExecDirect failed >>> ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1"; >>> Error while executing the query >>> >>> Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"... >>> + read line >>> >>> ... on Fedora 23. I'll try to look more carefuly next week unless there >>> is somebody quicker than me. >>> >>> Thanks, Pavel
[dropping the announce list, sorry for not doing it before] On Tuesday 19 of April 2016 07:50:30 Inoue, Hiroshi wrote: > The commit handles the bug report > [ODBC] Issue with Money field using ODBC to Access database > posted by John Van De Giessen on Febrary 14. Thanks for the reference. I have to look at the thread once more, as I don't fully understand how that patch is relevant to MONEY type. > The bug was introduced in 9.5.0100 and the regression test result maybe > modified. The test case shows that psqlodbc uses 'numeric' type for SQL_FLOAT/SQL_DOUBLE id (instead of 'double precision' used before, or 'float8'). This sounds like a bug, or is this really expected? If yes, I can submit a patch fixing the test-case -- but it does not feel right. Pavel
Yet another testsuite issue, FYI: + cat ./regression.diffs *** ./expected/declare-fetch-block.out Fri Apr 15 13:11:35 2016 --- results/declare-fetch-block.out Wed Apr 20 07:57:57 2016 *************** *** 2,10 **** fetchIdx=1, fetched rows=84, total rows=84 fetchIdx=2, fetched rows=36, total rows=120 next total rows=120 ! prior total rows=120 ! next total rows=120 ! prior total rows=120 FetchScroll beyond the end failed 100 ! encountered EOF at 120 ! disconnecting --- 2,10 ---- fetchIdx=1, fetched rows=84, total rows=84 fetchIdx=2, fetched rows=36, total rows=120 next total rows=120 ! prior total rows=20 ! next total rows=0 ! prior total rows=0 FetchScroll beyond the end failed 100 ! FetchScroll the 1st row failed ! No error informatio The architecture is armv7hl. Pavel
On Thursday 21 of April 2016 12:28:23 Pavel Raiskup wrote: > Yet another testsuite issue, FYI: > > + cat ./regression.diffs > *** ./expected/declare-fetch-block.out Fri Apr 15 13:11:35 2016 > --- results/declare-fetch-block.out Wed Apr 20 07:57:57 2016 > *************** > *** 2,10 **** > fetchIdx=1, fetched rows=84, total rows=84 > fetchIdx=2, fetched rows=36, total rows=120 > next total rows=120 > ! prior total rows=120 > ! next total rows=120 > ! prior total rows=120 > FetchScroll beyond the end failed 100 > ! encountered EOF at 120 > ! disconnecting > --- 2,10 ---- > fetchIdx=1, fetched rows=84, total rows=84 > fetchIdx=2, fetched rows=36, total rows=120 > next total rows=120 > ! prior total rows=20 > ! next total rows=0 > ! prior total rows=0 > FetchScroll beyond the end failed 100 > ! FetchScroll the 1st row failed > ! No error informatio > > The architecture is armv7hl. I forgot to mention the full build log: http://koji.fedoraproject.org/koji/taskinfo?taskID=13729322 Pavel
Re: Pavel Raiskup 2016-04-14 <2358560.7dzo2vKd9I@nb.usersys.redhat.com>
> Hi, fyi, I keep getting...
Hi,
I'm getting exactly the same diff on Debian unstable.
Do we simply have to update expected/param-conversions{,_1}.out or is
there a bug in the (testing?) code?
> + cat ./regression.diffs
> *** ./expected/param-conversions.out Sat Apr 9 14:19:08 2016
> --- results/param-conversions.out Thu Apr 14 15:44:56 2016
> ***************
> *** 72,83 ****
>
> Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
> SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1";
> Error while executing the query
>
> Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
> SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1";
> Error while executing the query
>
> Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
> --- 72,83 ----
>
> Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
> SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1";
> Error while executing the query
>
> Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
> SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1";
> Error while executing the query
>
> Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
> + read line
>
> ... on Fedora 23. I'll try to look more carefuly next week unless there
> is somebody quicker than me.
Christoph
On Friday 22 of April 2016 12:19:28 Christoph Berg wrote:
> Re: Pavel Raiskup 2016-04-14 <2358560.7dzo2vKd9I@nb.usersys.redhat.com>
> > Hi, fyi, I keep getting...
>
> Hi,
>
> I'm getting exactly the same diff on Debian unstable.
It is not suprising, it is probably reproducible everywhere?
> Do we simply have to update expected/param-conversions{,_1}.out or is
> there a bug in the (testing?) code?
I suspect that is a bug in non-testing code, as SQL_FLOAT is now mapped to
'numeric' type, while it used to be mapped to 'double precission'.
Pavel
On Thursday, April 21, 2016 12:32:16 PM CEST Pavel Raiskup wrote: > On Thursday 21 of April 2016 12:28:23 Pavel Raiskup wrote: > > Yet another testsuite issue, FYI: > > > > + cat ./regression.diffs > > *** ./expected/declare-fetch-block.out Fri Apr 15 13:11:35 2016 > > --- results/declare-fetch-block.out Wed Apr 20 07:57:57 2016 > > *************** > > *** 2,10 **** > > fetchIdx=1, fetched rows=84, total rows=84 > > fetchIdx=2, fetched rows=36, total rows=120 > > next total rows=120 > > ! prior total rows=120 > > ! next total rows=120 > > ! prior total rows=120 > > FetchScroll beyond the end failed 100 > > ! encountered EOF at 120 > > ! disconnecting > > --- 2,10 ---- > > fetchIdx=1, fetched rows=84, total rows=84 > > fetchIdx=2, fetched rows=36, total rows=120 > > next total rows=120 > > ! prior total rows=20 > > ! next total rows=0 > > ! prior total rows=0 > > FetchScroll beyond the end failed 100 > > ! FetchScroll the 1st row failed > > ! No error informatio > > > > The architecture is armv7hl. > > I forgot to mention the full build log: > http://koji.fedoraproject.org/koji/taskinfo?taskID=13729322 I had to disable yet another test with 09.05.0300 on armv7hl, full build log https://kojipkgs.fedoraproject.org//packages/postgresql-odbc/09.05.0300/1.fc25/data/logs/armv7hl/build.log Pavel
On Monday, June 20, 2016 6:45:51 AM CEST Pavel Raiskup wrote: > On Thursday, April 21, 2016 12:32:16 PM CEST Pavel Raiskup wrote: > > On Thursday 21 of April 2016 12:28:23 Pavel Raiskup wrote: > > > Yet another testsuite issue, FYI: > > > > > > + cat ./regression.diffs > > > *** ./expected/declare-fetch-block.out Fri Apr 15 13:11:35 2016 > > > --- results/declare-fetch-block.out Wed Apr 20 07:57:57 2016 > > > *************** > > > *** 2,10 **** > > > fetchIdx=1, fetched rows=84, total rows=84 > > > fetchIdx=2, fetched rows=36, total rows=120 > > > next total rows=120 > > > ! prior total rows=120 > > > ! next total rows=120 > > > ! prior total rows=120 > > > FetchScroll beyond the end failed 100 > > > ! encountered EOF at 120 > > > ! disconnecting > > > --- 2,10 ---- > > > fetchIdx=1, fetched rows=84, total rows=84 > > > fetchIdx=2, fetched rows=36, total rows=120 > > > next total rows=120 > > > ! prior total rows=20 > > > ! next total rows=0 > > > ! prior total rows=0 > > > FetchScroll beyond the end failed 100 > > > ! FetchScroll the 1st row failed > > > ! No error informatio > > > > > > The architecture is armv7hl. > > > > I forgot to mention the full build log: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=13729322 > > I had to disable yet another test with 09.05.0300 on armv7hl, full build log > https://kojipkgs.fedoraproject.org//packages/postgresql-odbc/09.05.0300/1.fc25/data/logs/armv7hl/build.log The testsuite fails for s390x too, have a look at the results here: http://s390.koji.fedoraproject.org/kojifiles/work/tasks/400/2270400/build.log Pavel
> From: pgsql-odbc-owner@postgresql.org > The testsuite fails for s390x too, have a look at the results here: > http://s390.koji.fedoraproject.org/kojifiles/work/tasks/400/2270400/bu > ild.log Did any platform succeed (e.g. Intel64)? Is there anything common among failed platforms (armv7hl, s390x), such as endian? Regards Takayuki Tsunakawa
On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote: > Did any platform succeed (e.g. Intel64)? No. Looks like x86_64/i686 is in the best condition, we apply only one downstream patch in Fedora (revert of the MONEY [1] fix which I believe should be reverted upstream) and then the testsuite succeeds. To build on armv7hl, we apply [2]. > Is there anything common among failed platforms (armv7hl, s390x), such as > endian? I haven't analyzed properly the common patterns yet. FYI, there is also downstream tracker [3] (seems like aarch64, s390* and ppc* fails too). [1] http://pkgs.fedoraproject.org/cgit/rpms/postgresql-odbc.git/tree/postgresql-odbc-09.05.0210-revert-money-fix.patch [2] http://pkgs.fedoraproject.org/cgit/rpms/postgresql-odbc.git/tree/postgresql-odbc-09.05.0210-tests-arm.patch [3] https://bugzilla.redhat.com/show_bug.cgi?id=1350486 Pavel
Hi Pavel, On 2016/06/28 17:52, Pavel Raiskup wrote: > On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote: >> Did any platform succeed (e.g. Intel64)? > No. Looks like x86_64/i686 is in the best condition, we apply only one > downstream patch in Fedora (revert of the MONEY [1] fix which I believe should > be reverted upstream) and then the testsuite succeeds. > > To build on armv7hl, we apply [2]. Could you try the attached patch on armv7hl? regards, Hiroshi Inoue
Attachment
Hi Hiroshi, On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote: > On 2016/06/28 17:52, Pavel Raiskup wrote: > > On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote: > >> Did any platform succeed (e.g. Intel64)? > > > > No. Looks like x86_64/i686 is in the best condition, we apply only one > > downstream patch in Fedora (revert of the MONEY [1] fix which I believe should > > be reverted upstream) and then the testsuite succeeds. > > > > To build on armv7hl, we apply [2]. > > Could you try the attached patch on armv7hl? of course. Submitted build (for i686, x86_64 and armv7hl): http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892 .. and all arches passed testsuite, thanks! There is just the remaining MONEY [1] revert patch. Pavel
On Sunday, July 24, 2016 10:09:18 AM CEST Pavel Raiskup wrote: > Hi Hiroshi, > > On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote: > > On 2016/06/28 17:52, Pavel Raiskup wrote: > > > On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote: > > >> Did any platform succeed (e.g. Intel64)? > > > > > > No. Looks like x86_64/i686 is in the best condition, we apply only one > > > downstream patch in Fedora (revert of the MONEY [1] fix which I believe should > > > be reverted upstream) and then the testsuite succeeds. > > > > > > To build on armv7hl, we apply [2]. > > > > Could you try the attached patch on armv7hl? > > of course. Submitted build (for i686, x86_64 and armv7hl): > http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892 > .. and all arches passed testsuite, thanks! > > There is just the remaining MONEY [1] revert patch. FYI: aarch64 passes too: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3639510 s390 still fails: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2297311 Pavel
On Sunday, July 24, 2016 10:19:42 AM CEST Pavel Raiskup wrote: > On Sunday, July 24, 2016 10:09:18 AM CEST Pavel Raiskup wrote: > > Hi Hiroshi, > > > > On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote: > > > On 2016/06/28 17:52, Pavel Raiskup wrote: > > > > On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote: > > > >> Did any platform succeed (e.g. Intel64)? > > > > > > > > No. Looks like x86_64/i686 is in the best condition, we apply only one > > > > downstream patch in Fedora (revert of the MONEY [1] fix which I believe should > > > > be reverted upstream) and then the testsuite succeeds. > > > > > > > > To build on armv7hl, we apply [2]. > > > > > > Could you try the attached patch on armv7hl? > > > > of course. Submitted build (for i686, x86_64 and armv7hl): > > http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892 > > .. and all arches passed testsuite, thanks! > > > > There is just the remaining MONEY [1] revert patch. > > FYI: > > aarch64 passes too: > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3639510 > > s390 still fails: > http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2297311 ppc64 fails, ppc64le (little endian) succeeds. http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3549998 Looks like remaining failure is big-endian related? Pavel
On 2016/07/24 18:28, Pavel Raiskup wrote: > On Sunday, July 24, 2016 10:19:42 AM CEST Pavel Raiskup wrote: >> On Sunday, July 24, 2016 10:09:18 AM CEST Pavel Raiskup wrote: >>> Hi Hiroshi, >>> >>> On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote: >>>> On 2016/06/28 17:52, Pavel Raiskup wrote: >>>>> On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote: >>>>>> Did any platform succeed (e.g. Intel64)? >>>>> No. Looks like x86_64/i686 is in the best condition, we apply only one >>>>> downstream patch in Fedora (revert of the MONEY [1] fix which I believe should >>>>> be reverted upstream) and then the testsuite succeeds. >>>>> >>>>> To build on armv7hl, we apply [2]. >>>> Could you try the attached patch on armv7hl? >>> of course. Submitted build (for i686, x86_64 and armv7hl): >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892 >>> .. and all arches passed testsuite, thanks! >>> >>> There is just the remaining MONEY [1] revert patch. >> FYI: >> >> aarch64 passes too: >> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3639510 >> >> s390 still fails: >> http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2297311 > ppc64 fails, ppc64le (little endian) succeeds. > http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3549998 > > Looks like remaining failure is big-endian related? Possibly the attached patch fixes the failure. regards, Hiroshi Inoue
Attachment
On Sunday, July 24, 2016 7:05:46 PM CEST Inoue, Hiroshi wrote: > > On 2016/07/24 18:28, Pavel Raiskup wrote: > > On Sunday, July 24, 2016 10:19:42 AM CEST Pavel Raiskup wrote: > >> On Sunday, July 24, 2016 10:09:18 AM CEST Pavel Raiskup wrote: > >>> Hi Hiroshi, > >>> > >>> On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote: > >>>> On 2016/06/28 17:52, Pavel Raiskup wrote: > >>>>> On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote: > >>>>>> Did any platform succeed (e.g. Intel64)? > >>>>> No. Looks like x86_64/i686 is in the best condition, we apply only one > >>>>> downstream patch in Fedora (revert of the MONEY [1] fix which I believe should > >>>>> be reverted upstream) and then the testsuite succeeds. > >>>>> > >>>>> To build on armv7hl, we apply [2]. > >>>> Could you try the attached patch on armv7hl? > >>> of course. Submitted build (for i686, x86_64 and armv7hl): > >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892 > >>> .. and all arches passed testsuite, thanks! > >>> > >>> There is just the remaining MONEY [1] revert patch. > >> FYI: > >> > >> aarch64 passes too: > >> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3639510 > >> > >> s390 still fails: > >> http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2297311 > > ppc64 fails, ppc64le (little endian) succeeds. > > http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3549998 > > > > Looks like remaining failure is big-endian related? > > Possibly the attached patch fixes the failure. Right. Ater that the testsuite is OK on Fedora architectures where I'm able to test (still need to revert MONEY fix [1]). Can you please push the fixes into repository? Thanks, Pavel
On 2016/07/24 17:09, Pavel Raiskup wrote: > Hi Hiroshi, > > On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote: >> On 2016/06/28 17:52, Pavel Raiskup wrote: >>> On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote: >>>> Did any platform succeed (e.g. Intel64)? >>> No. Looks like x86_64/i686 is in the best condition, we apply only one >>> downstream patch in Fedora (revert of the MONEY [1] fix which I believe should >>> be reverted upstream) and then the testsuite succeeds. >>> >>> To build on armv7hl, we apply [2]. >> Could you try the attached patch on armv7hl? > of course. Submitted build (for i686, x86_64 and armv7hl): > http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892 > .. and all arches passed testsuite, thanks! > > There is just the remaining MONEY [1] revert patch. It's difficult to revert the commit because the functionality exists before 9.5. I'm inclined to omit 2 cases in trouble from param-conversions-test for the time being. Is it OK? regards, Hiroshi Inoue
On Monday, July 25, 2016 7:12:11 AM CEST Inoue, Hiroshi wrote: > It's difficult to revert the commit because the functionality exists > before 9.5. > I'm inclined to omit 2 cases in trouble from param-conversions-test for > the time being. > Is it OK? As I understand the problem, the regression test caught real issue ... i.e. there is (a) bug fixed but (b) new regression added. I'm not able to measure what issue is more serious, but the fixed bug 'a' is looks like related to very small subset of users, while 'b' is related to everybody ... ... so (when the revert is no-go) rather than removing the tests completely, I would suggest you to mark them as "expected failure" and wait for the fix in future. I'm fine to keep that patch reverted downstream for the time being. I'm glad have fixes for the portability issues, I can't wait for having it committed! Pavel
On 2016/07/25 16:34, Pavel Raiskup wrote: > On Monday, July 25, 2016 7:12:11 AM CEST Inoue, Hiroshi wrote: >> It's difficult to revert the commit because the functionality exists >> before 9.5. >> I'm inclined to omit 2 cases in trouble from param-conversions-test for >> the time being. >> Is it OK? > As I understand the problem, the regression test caught real issue ... > i.e. there is (a) bug fixed but (b) new regression added. > > I'm not able to measure what issue is more serious, but the fixed bug 'a' > is looks like related to very small subset of users, while 'b' is related to > everybody ... > > ... so (when the revert is no-go) rather than removing the tests completely, > I would suggest you to mark them as "expected failure" and wait for the fix in > future. I'm fine to keep that patch reverted downstream for the time being. > > I'm glad have fixes for the portability issues, I can't wait for having it > committed! I changed expected/param-converions(_1).out as-is and pushd to git. Now all regression tests passes. regards, Hiroshi Inoue