Re: [fossil-users] Version 1.28 release?
On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp d...@sqlite.org wrote: It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? i'm a bit late to the party (been off with a back injury since New Year's Eve), and don't really want to wade through the near-30 responses because sitting up on the PC is still very uncomfortable, so i'll just ask: is there still a need to run the current trunk through valgrind (or similar testing) for the release? i have x64 Mint Linux here i could run it through, but won't do so if the release is already on its way out the door. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Sat, Jan 11, 2014 at 6:21 AM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp d...@sqlite.org wrote: It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? i'm a bit late to the party (been off with a back injury since New Year's Eve), and don't really want to wade through the near-30 responses because sitting up on the PC is still very uncomfortable, so i'll just ask: is there still a need to run the current trunk through valgrind (or similar testing) for the release? i have x64 Mint Linux here i could run it through, but won't do so if the release is already on its way out the door. I just now ran the valgrind test script, and there are issues. There is a performance issue in timeline which seems to be related to Unhide. And there is a valgrind error (jump based on uninitialized memory) in the /tar page. Those of the problems I've seen so far. Continuing to investigate -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Sat, Jan 11, 2014 at 9:31 AM, Richard Hipp d...@sqlite.org wrote: I just now ran the valgrind test script, and there are issues. There is a performance issue in timeline which seems to be related to Unhide. The performance problem only comes up with WITHOUT ROWID tables are used (which happens only if you run fossil test-without-rowid on the repository to modify the schema.) It appears to be some problem in the SQLite query planner related to WITHOUT ROWID. Since nobody (besides me) uses WITHOUT ROWID repositories, I don't think this should hinder the release. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem with compilation under MINGW
2014/1/4 James Turner ja...@calminferno.net: I won't begin to tell you how to develop fossil but I do want to throw out there that OpenBSD has been providing fossil with --disable-internal-sqlite via it's ports tree and packages fairly successfully (and with 'fossil sqlite3' support) for the last year+. I re-enabled fossil sqlite3 again in the branch-1.28 branch: My guess is that most package maintainers will re-enable it anyway. It's easy enough, but I want to make your work easier, not more difficult. For trunk, there's still more than enough time to think how this should be fixed the 'correct' way, which satisfies everyone (I hope). Thanks! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem with compilation under MINGW
On Sat, Jan 11, 2014 at 1:24 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/4 James Turner ja...@calminferno.net: I won't begin to tell you how to develop fossil but I do want to throw out there that OpenBSD has been providing fossil with --disable-internal-sqlite via it's ports tree and packages fairly successfully (and with 'fossil sqlite3' support) for the last year+. I re-enabled fossil sqlite3 again in the branch-1.28 branch: My guess is that most package maintainers will re-enable it anyway. It's easy enough, but I want to make your work easier, not more difficult. For trunk, there's still more than enough time to think how this should be fixed the 'correct' way, which satisfies everyone (I hope). I *still* haven't sent out that message / warning yet, but I'm getting closer. Have info now for: CentOS (and Scientific Linux), Cygwin, Debian (and Ubuntu), Fedora, FreeBSD, Gentoo (and Sabayon), NetBSD, OpenBSD (can be skipped however), openSUSE, Slackware. I haven't looked up the Solaris variants yet, nor the other Linux and BSD distros (Linux: Arch, Mageia, Manjaro, Puppy; BSD: Dragonfly, Ghost, PC-BSD). The message will take into account that a 1.28 release will (apparently) permit --disable-internal-sqlite, but that it is still subject to disabling (and/or may already be disabled?) for development versions / trunk and therefore for a future 1.29 release. (I have to lookit the sources online to verify this before I say it, however.) Just a heads up that no, I haven't forgotten or given up. I'm just slow. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small issue with ticket hook script
2014/1/9 Mark Janssen mpc.jans...@gmail.com:
When I use the following script as a ticket hook:
set project simpletask
tclInvoke package require http
query {SELECT title, status
FROM ticket
WHERE tkt_uuid=$uuid} {
set title [tclInvoke http::formatQuery $title]
http -asynchronous --
http://127.0.0.1/cgi-bin/tkt-hook?uuid=$uuidtitle=$titlestatus=$statusproject=$project
}
Looking at this again, fossil could benefit from a
TH1 encodeURIComponent() function, which does
the same as the Javascript function with the same
name. Doing this through Tcl's http::formatQuery
command is a lot more expensive.
Anyone interested in writing a TH1
encodeURIComponent() function? I guess
more parts in fossil could benefit from that.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
2014/1/11 Richard Hipp d...@sqlite.org: I don't think this should hinder the release. That's great news. So the valgrind error in the /tar page and the two failing test-cases (which simply could be disabled) are the only things which should be handled? I wouldn't know anything else. Thanks! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
I have a request. Can you guys do the official builds SSL-enabled? On Sat, Jan 11, 2014 at 2:22 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/11 Richard Hipp d...@sqlite.org: I don't think this should hinder the release. That's great news. So the valgrind error in the /tar page and the two failing test-cases (which simply could be disabled) are the only things which should be handled? I wouldn't know anything else. Thanks! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Sat, Jan 11, 2014 at 2:22 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/11 Richard Hipp d...@sqlite.org: I don't think this should hinder the release. That's great news. So the valgrind error in the /tar page and the two failing test-cases (which simply could be disabled) are the only things which should be handled? I wouldn't know anything else. Thanks! The valgrind error in /tar has now been fixed on trunk. (It was utterly harmless and so it is not necessary to merge the fix into the 1.28 branch.) I'm currently chasing another valgrind error in the diff-er. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem with compilation under MINGW
On 11.01.2014 20:44, Joseph R. Justice wrote: On Sat, Jan 11, 2014 at 1:24 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/4 James Turner ja...@calminferno.net: I *still* haven't sent out that message / warning yet, but I'm getting closer. Have info now for: CentOS (and Scientific Linux), Cygwin, Debian (and Ubuntu), Fedora, FreeBSD, Gentoo (and Sabayon), NetBSD, OpenBSD (can be skipped however), openSUSE, Slackware. I haven't looked up the Solaris variants yet, nor the other Linux and BSD distros (Linux: Arch, Mageia, Manjaro, Puppy; BSD: Dragonfly, Ghost, PC-BSD). Once you have collected the leading packagers contacts already, what about new, low-traffic list *packag...@lists.sqlite.org* intended for: * coordinating packaging of SQLite and Fossil * help potential new packagers working for non yet covered distributions My rationale is that the packagers often are busy with supporting few dozen packages and for some could turn out difficult to follow the whole users@l.f.o. IMHO in general, some form of packagers forum should be beneficial for any wide adopted project. Kind Regards, Alek P.S. I am trying to follow the Fedora development. As Josef pointed in a previous mail, Fedora is the main upstream of the whole family (RHEL, CentOS, etc) so most packaging decisions happen there. The Fedora Packaging Guidelines explicitly _prohibit_ bundling practices. Every single bundling exception should be proved inevitable/temporary and specifically granted by FPC (Fedora Packaging Committee). There are zero exceptions for SQLite bundling at the moment, and it would be hard to impossible one to be granted for such important system library (yum: The Fedora family (CentOS, RHEL, etc) package manager is SQLite based). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small issue with ticket hook script
On 11 Jan 2014 20:09, Jan Nijtmans jan.nijtm...@gmail.com wrote:
2014/1/9 Mark Janssen mpc.jans...@gmail.com:
When I use the following script as a ticket hook:
set project simpletask
tclInvoke package require http
query {SELECT title, status
FROM ticket
WHERE tkt_uuid=$uuid} {
set title [tclInvoke http::formatQuery $title]
http -asynchronous --
http://127.0.0.1/cgi-bin/tkt-hook?uuid=$uuidtitle=$titlestatus=$statusproject=$project
}
Looking at this again, fossil could benefit from a
TH1 encodeURIComponent() function, which does
the same as the Javascript function with the same
name. Doing this through Tcl's http::formatQuery
command is a lot more expensive.
Anyone interested in writing a TH1
encodeURIComponent() function? I guess
more parts in fossil could benefit from that.
Of course it would be easier if th1 had a command like this, but
considering the TCL bridge is there and the fact that tickets are not in
high volume, for me the current solution is good enough.
Mark
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
