[sqlite] SQLite build dependency on tclsh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, with the recent replacement of awk build scripts with tclsh ones, a problem has risen. The tcl is not commonly available when building the environment/distribution from ground up (bootstrap), and as a consequence, SQLite can no longer be built in these early stages. Would it be possible to bring back the awk-based build scripts? Best regards, Jan - -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlYvJKEACgkQXbaA6cD3QD0oegCdGaBI87ukVuc4K3KZMsxJm3gw HmUAn0Fn0Dntrr9uriN5t5JK+62Lsrtq =feNv -END PGP SIGNATURE-
[sqlite] Bug: Cannot compile the new sqlite-src-3081001: preprocessor and testuite errors
Hello, I'm trying to build sqlite from source (sqlite-src) for Fedora. In the latest version (3.8.10.1), I encountered two issues that prevents me from building it: 1) The compilation fails on file sqlite3_analyzer.c, with error sqlite3_analyzer.c:14131:30: error: #if with no expression #if SQLITE_ENABLE_DBSTAT_VTAB I found out that this is due to the way the macro is defined on the very top of the file: `#define SQLITE_ENABLE_DBSTAT_VTAB`. As the macro evaluates to nothing, the #if statement is invalid. Also, this way effectively prevents me from using the macro as compile flag, because this way overwrite any definition of this macro in compile flags. Origin of the line is in the Makefile (Makefile.in), and it is added during the sqlite3_analyzer.c creation in said Makefile. 2) When I "fix" the previous error, I'm getting assertion failure during the test suite run. The way I fixed the previous error: #ifndef SQLITE_ENABLE_DBSTAT_VTAB #define SQLITE_ENABLE_DBSTAT_VTAB 0 #endif Then I add the `-DSQLITE_ENABLE_DBSTAT_VTAB=1` flag to the CFLAGS, and the compilation sucessfully finishes. However, the testsuite run fails with the following error: shell1-5.0...testfixture: /builddir/build/BUILD/tcl8.6.3/generic/tclIO.c:5815: DoReadChars: Assertion `!((statePtr)->flags & ((1<<9))) || ((statePtr)->flags & ((1<<10))) || Tcl_InputBuffered((Tcl_Cha nnel)chanPtr) == 0' failed. The testsuite error does not occur in the 3.9.* version. Best regards, Jan -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team
Re: [sqlite] Bugreport - slowdown in sqlite after the ANALYZE statement
Thank you very much for the explanation and tips, they are appreciated. Dne 9.12.2014 v 14:30 Richard Hipp napsal(a): > Answered by adding a comment at > https://bugzilla.redhat.com/show_bug.cgi?id=1161844 > > On Tue, Dec 9, 2014 at 6:06 AM, Jan Staněk wrote: > > Hi, > some of the banshee users noticed a huge slowdown in its operation > after upgrading to version 3.8.7 from 3.8.6. Here is the related log : > > [4 Debug 13:24:27.263] Executed in 12819ms > DELETE FROM CoreCache WHERE ModelID = 9; > INSERT INTO CoreCache (ModelID, ItemID) SELECT > 9, CoreTracks.TrackID > FROM (SELECT MIN(CoreTracks.TrackID) AS TrackID, > CoreTracks.Year FROM CoreTracks GROUP BY CoreTracks.Year) AS CoreTracks > WHERE CoreTracks.Year IN > (SELECT CoreTracks.Year FROM CoreTracks, CoreCache > WHERE CoreCache.ModelID = 371 AND > CoreCache.ItemID = CoreTracks.TrackID ) > ORDER BY Year > > Reverting to 3.8.6, gives back a fast answer : > > [4 Debug 13:21:05.433] Executed in 24ms > DELETE FROM CoreCache WHERE ModelID = 9; > INSERT INTO CoreCache (ModelID, ItemID) SELECT > 9, CoreTracks.TrackID > FROM (SELECT MIN(CoreTracks.TrackID) AS TrackID, > CoreTracks.Year FROM CoreTracks GROUP BY CoreTracks.Year) AS CoreTracks > WHERE CoreTracks.Year IN > (SELECT CoreTracks.Year FROM CoreTracks, CoreCache > WHERE CoreCache.ModelID = 371 AND > CoreCache.ItemID = CoreTracks.TrackID ) > ORDER BY Year > > The original bug reporter then went on and possibly isolated the bug. > Details are at https://bugzilla.redhat.com/show_bug.cgi?id=1161844 . > > Thanks for your work, >> ___ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Bugreport - slowdown in sqlite after the ANALYZE statement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, some of the banshee users noticed a huge slowdown in its operation after upgrading to version 3.8.7 from 3.8.6. Here is the related log : [4 Debug 13:24:27.263] Executed in 12819ms DELETE FROM CoreCache WHERE ModelID = 9; INSERT INTO CoreCache (ModelID, ItemID) SELECT 9, CoreTracks.TrackID FROM (SELECT MIN(CoreTracks.TrackID) AS TrackID, CoreTracks.Year FROM CoreTracks GROUP BY CoreTracks.Year) AS CoreTracks WHERE CoreTracks.Year IN (SELECT CoreTracks.Year FROM CoreTracks, CoreCache WHERE CoreCache.ModelID = 371 AND CoreCache.ItemID = CoreTracks.TrackID ) ORDER BY Year Reverting to 3.8.6, gives back a fast answer : [4 Debug 13:21:05.433] Executed in 24ms DELETE FROM CoreCache WHERE ModelID = 9; INSERT INTO CoreCache (ModelID, ItemID) SELECT 9, CoreTracks.TrackID FROM (SELECT MIN(CoreTracks.TrackID) AS TrackID, CoreTracks.Year FROM CoreTracks GROUP BY CoreTracks.Year) AS CoreTracks WHERE CoreTracks.Year IN (SELECT CoreTracks.Year FROM CoreTracks, CoreCache WHERE CoreCache.ModelID = 371 AND CoreCache.ItemID = CoreTracks.TrackID ) ORDER BY Year The original bug reporter then went on and possibly isolated the bug. Details are at https://bugzilla.redhat.com/show_bug.cgi?id=1161844 . Thanks for your work, - -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlSG16wACgkQXbaA6cD3QD38pwCcDiofiIh5jo+E8P5B/DhxLzGF fGsAn1RJ8SjjEANSjUm4I1j+zReQfj0G =2QtO -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3_value_type dereferencing NULL pointer
During the running of the fail2ban daemon, which uses python2.7 bindings for sqlite, the function sqlite3_value_type dereferenced a NULL pointer, thus causing Segmentation fault error. Bellow are attached links to stacktraces leading to this segfault ([1] and more detailed in [2]). [1] https://retrace.fedoraproject.org/faf/reports/445794/ [2] https://bugzilla.redhat.com/attachment.cgi?id=942560 -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Failed test on aarch64
Hello, I'm trying to build sqlite for aarch64 (ARMv8) and one of the expression tests is failing (specifically e_expr-31.2.4) with: > Expected: [integer -9223372036854775808] > Got: [integer 9223372036854775807] >From the comment, I gather that this should test correct CASTing from REAL to INT, and that somehow it returns the wrong extreme (largest positive integer instead of largest negative). Can someone point me where in the source is that implemented? I would like to try to fix it, but I'm unable to find the actual execution of the CAST. Thanks in advance. -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite 3.8.0 percentile test failure
Hello, I have trouble building the sqlite for i686 architecture. One of the percentile tests (percentile-2.1.50) fails, because it expects result of exactly 274.5 and got 274.50004681, which is very near, but not exact. I've built previous versions without problem, so I guess something has changed - either the implementation or the test. I'm currently trying to package the SQLite 3.8.0.2 for Fedora and the only way I was able to find to build it successfully is to drop that test from the test suite. However, this really does not seem as long-term solution. Can anyone give me a hint what I should do with it? Thanks in advance, Jan [1] http://koji.fedoraproject.org/koji/getfile?taskID=5899018&name=build.log - log for the failed build -- Jan Stanek - Red Hat INTERN Developer Engineer - Databases Team ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Documentation license
Dne 28.5.2013 15:25, Richard Hipp napsal(a): On Tue, May 28, 2013 at 9:04 AM, Jan Staněk wrote: . May I suggest update of the webpage http://www.sqlite.org/copyright.htmlto reflect current state? It would help preventing similar "bug reports". Is the revised language on http://www.sqlite.org/copyright.html adequate? I'm no lawyer, but I believe it is. Thank you very much for cooperation. -- Jan Stanek ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Documentation license
Dne 28.5.2013 14:53, Richard Hipp napsal(a): On Tue, May 28, 2013 at 8:37 AM, Jan Staněk wrote: Hello, as a maintainer of sqlite in Fedora, I recently found out that the license of the sqlite documentation is not specified - the web page only states that documentation or its parts may be licensed under various licenses, and that the details are unclear. Recently a bug was opened (see [1]), claiming that in reporter's opinion the sqlite documentation is non-free and not distributable, thus unsuitable for packaging in Fedora. Could someone please clarify this issue? Many years ago, there were pieces of documentation of unknown provenance. But all of that has been removed now. The SQLite documentation, as with the SQLite source code, is public domain. We have in our firesafe signed affidavits from all documentation authors releasing their work into the public domain. Thank you very much for clarifying. May I suggest update of the webpage http://www.sqlite.org/copyright.html to reflect current state? It would help preventing similar "bug reports". In any case, thanks for fast reply. -- Jan Stanek ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Documentation license
Hello, as a maintainer of sqlite in Fedora, I recently found out that the license of the sqlite documentation is not specified - the web page only states that documentation or its parts may be licensed under various licenses, and that the details are unclear. Recently a bug was opened (see [1]), claiming that in reporter's opinion the sqlite documentation is non-free and not distributable, thus unsuitable for packaging in Fedora. Could someone please clarify this issue? Regards, Jan Stanek [1] https://bugzilla.redhat.com/show_bug.cgi?id=967280 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Feature request: Support for aarch64
Hello, support for the ARM 64 bit CPU architecture (aarch64) was introduced in autoconf 2.69. sqlite appears to use an earlier version of autoconf, preventing its being built. Would it be possible to migrate sqlite to new version of autoconf? Thanks for answer, Jan Stanek ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
