Re: [Koha-devel] Coverity - creating OS software maps - (automated defect detection)
It's a static analysis tool which works on projects in C, C++ and Java. It was originally developed to analyse the linux kernel codebase. As such the Koha code is not a candidate, but many of the projects Koha relies on (Perl, Apache) are already using it Cheers Colin ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] Authority Linking
On a fresh marc21/zebra/dom install. I found that after linking bibs to authorities the link appeared bib->authority but all authorities showed 0 biblios linked. Zebra was not recognising 'Koha-Auth-Number' Changing ccl.properties entry Authority-Number 1=Koha-Auth-Number an Authority-Number Koha-Auth-Number Authority-Number to Authority-Number 1=8910 an Authority-Number Koha-Auth-Number Authority-Number fixed this (8910 being the value of Koha-Auth_Number in biblios/etc/bib1.att. My question is this cause or a symptom of a larger problem in the attribute definitions. Cheers Colin ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Authority Linking
On Tue, Mar 24, 2009 at 03:17:54PM +0100, Henri-Damien LAURENT wrote: > Can you precise your zebra server version and yaz-client ? > zebra server 2.0.36 yaz-client 3.0.34 Cheers Colin ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] Searching Authorities
On the authority searching screen there are three tabs, Search Authorities/Search Main Heading/Search All Headings. At present the first two appear to generate the same zebra search while the third generates a search with the unrecognized attribute 'Any'. 'search Main Heading' sounds more like a Bib search than an authority search. Has anyone any pointers on what we think these should be doing? If there is some agreement I'll try and get theory and practice to correspond a bit more closely Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] Sip2 and Sip.pm
Hi, there's an underlying assumption in Koha's Sip implementation that messages from sip units will be terminated by carriage return line feed. This works with many sip clients (including 3M). However the sip2 standard mandates that sip messages are terminated by carriage return (hex 0d). That means any client that implements the standard as specified (and I know of at least 2 such vendors) can't connect to Koha's implementation (which sits waiting for the CR). It also means that those units that send hex 0a in the body of text can cause grief. I'm wondering if anyone has any thoughts on improving the server side. Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Sip2 and Sip.pm
On 07/06/2009 03:00 PM, Joe Atzberger wrote: > Colin -- > > Koha SIP can handle dossy ^M line endings just fine. The detection of > line endings is essentially delegated to the IO::Socket::INET and Socket > modules with local $/ = "\012". The problem is that the protocol states that all messages end in a carrage return (hex 0d). There is no requirement to set linefeed as a terminator as it is not a message separator. > > I don't see any reason for a client to send hex 0a or any other control > character in any message field. It's allowed so they will. I've seen it on a number of occasions. > I'm really talking about raw sockets implementations here. Although in my experience a "strictly conforming" implementation can handle communication over a telnet connection because basic telnet handles the extra overhead (the clients typically script the connection set up). > It may be possible to make the line-ending an > attribute of the SIPconfig account, such that you could have a different > one for a given SIP terminal. Or more likely, you can get the clients > to send a different line ending. > This would be the way to go for flexibility. At the moment the assumption is interwoven with the protocol handling. I don't think expecting the clients to send different line endings is likely as these are usually closed (often windows) binaries. Its a lot easier to handle the vagaries of the clients in the perl code. Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Sip2 and Sip.pm
On 07/06/2009 05:00 PM, Joe Atzberger wrote: > I agree with you on what the spec says, but at the time of > implementation, ZERO clients available to Koha developers actually > behaved that way, including the reference implementation from 3M. At > this time, the number of such clients available to us is still zero. We > would need more information about the clients in question: I'm talking from the experience of supporting a number of clients (including 3M) on sockets connections. As to telnet, I've only used that to debug connections, in practical terms it seems approprate only for the older clients. > When do you imagine it would be appropriate for a SIP client to send, > for example, a BELL character or BACKSPACE character? I don't but the robustness principle appliers, 'be liberal in what you accept, be conservative in what you transmit' > You could still run a middle layer on localhost. But if it can be > handled cleanly via SIPconfig, I would support that. > Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] Letters.pm
I've been looking at C4/Letters.pm as the templating fails to generate useful output for claimissues. I can certainly get it to work with some code changes but I started wondering if a better use of long term effort might be to replace the home grown templating with a tried and tested perl module. It could use Template Toolkit for instance without changing the user interface, but resulting in more maintainable code. Thought I'd float that suggestion for comments. Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] To mantain documentation on Mysql tables, indexess and relation
On 10/12/2009 12:08 PM, Zeno Tajoli wrote: > Hi to all, > My preference is the first option, someone are agree, someone are not agree. > The real and big obstacles again first option is: >-- Not all RDBMS support it o similar syntax > It works only on MySQL, Postgresql, Oracle. But not in compatible syntaxes. We are talking about adding another mysqlism into the database structure. (Admitted localised to kohastructure.sql) > -- We want to use Class::DBI. Class::DBI doesn't support it Actually Chris was talking, I believe, about using DBIx::Class not Class::DBI. Using DBIx::Class does offer us more options in having a better defined schema. We probably need to review what our options are in the future for db compatibility. Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] Perl Org
The new look http://www.perl.org is now up and running. C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] koha with better support for postgresql
On 02/12/09 21:13, Rick Welykochy wrote: > Joe Atzberger wrote: > >> Chris' work is encouraging. ORM classes are definitely a different way >> of thinking about data though. The mapping is its own little ecosystem, >> and will require the structure to be maintained and updated (much like >> kohastructure.sql and updatedatabase). One great thing though, is that >> it combines with caching very naturally (caching an object, not just a >> DB row). > > Perhaps a move towards Koha objects in perl could accompany this change, i.e. > data model objects that present Koha constructs like Patron, Catalogue, Item, > etc. I think this is a way we need to go, and hopefully it will make it easier for people to contribute new features in future. At the moment some of the routines in the libraries are huge and full of side effects for the unwary. > > Having used an ORM before, I think it is important to monitor the performance > of the auto generated SQL, keep some metrics and optimise once the concepts > are functioning. It's very important, I've been down that road as well. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] Graphics::Magick on Fedora
FYI The Graphics::Magick perl module is now required for install in the community 3.2 branch hosted by biblibre. Anyone wanting to install that on Fedora will probably need the work around listed in > https://bugzilla.redhat.com/show_bug.cgi?id=527143 to get it to work. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] updatedatabase errors
I've just been taking a database from 3.01.00.61 to 3.01.00.107. (That's HEAD prior to Galen's last big pile of patches to the current biblibre community 3.2. Enroute updatedatebase throws a lot of errors due to duplication, incorrect sequencing of updates etc. As the may be of interest elsewhere (I'm sure someone said they were looking at these problems) I've uploaded a branch to my github: g...@github.com:colinsc/koha.git called dbupgrade3.2 which contains the changes I needed to make to get updatedatabase run error-free. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] updatedatabase errors
On 25/01/10 16:18, Chris Nighswonger wrote: > Hi Colin, > > On Mon, Jan 25, 2010 at 10:35 AM, Colin Campbell > wrote: >> I've just been taking a database from 3.01.00.61 to 3.01.00.107. (That's >> HEAD prior to Galen's last big pile of patches to the current biblibre >> community 3.2. Enroute updatedatebase throws a lot of errors due to >> duplication, incorrect sequencing of updates etc. As the may be of >> interest elsewhere (I'm sure someone said they were looking at these >> problems) I've uploaded a branch to my github: >> g...@github.com:colinsc/koha.git >> called dbupgrade3.2 which contains the changes I needed to make to get >> updatedatabase run error-free. > > > Checkout Bug 4046... > http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4046 > > I'm not sure if this addresses all of the issues you found or not. > Thanks Chris. Actually the issues I found were in a system with this patch already applied and were less syntax errors than operations carried out in an invalid sequence or twice. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Koha and Subversion
On 26/01/10 22:33, Richard Forristall wrote: > Has anyone setup subversion to manage their Koha modifications? > I'm trying to create a subversion repository and get this error: > Adding var/run/zebradb > svn: Unknown or unversionable type for 'var/run/zebradb/authoritysocket' authoritysocket is a socket not a source file, its not part of the codebase and you wouldn't want to keep it under authority control. That said, you really want to look at using git. The time spent learning it will repay you no end. It also makes it easier to track changes by others while maintaining your own working version and to contribute your own changes back to the project. I worked on a project that used subversion and moved to git and after the initial learning curve for everyone we never looked back. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Koha and Subversion
On 27/01/10 14:07, Richard Forristall wrote: > > Thanks for the 'heads up' on git. > > 1. I'm not using git out of pure ignorance. Are you referring to > http://git.koha.org or using git vice svn for version control? > git.koha.org is the repository but we were talking about git in general, > http://wiki.koha.org/doku.php?id=en:development:git_usage is informative about the process in general > 2. Colin, in your message you talk about contributing my own changes back to > the project. I'm new at koha (started supporting our librarian about 4 weeks > ago) so this is all new to me. I really like the community model of making > the koha software more robust, but what happens when my changes don't apply > across all koha users? Branding for example. I certainly don't want to > force irrelevant changes onto the entire community. > git makes it very easy to maintain local branches, for things specific to your site or for development, It also makes it easy to merge updates into them. So you could have in your local repository a branch holding the local changes, as well as branches tracking the git.koha.org version > 3. We use Subversion for all our other version control processes You can use git-svn to create a git repository tracking a subversion repository giving you the ability to use gits local branches for development but pull from and commit to the subversion repository. It's also a good way to familiarize yourself with git if migrating in a subversion environment. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] IRC connection problems?
On 28/01/10 14:25, David Schuster wrote: > > Anyone else having problems getting into IRC? I was wondering since it was a > Katipo server if it has been taken down? > > Or maybe our tech people figured out a way to block me! Chris tweeted that the NZ folks could get on but the international link was down. Try #koha on irc.freenode.net for us disadvantaged by being in the wrong hemisphere C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] Gource
Having had my interest sparked by someone else's comments, I took a look at Gsource an SVC visualization tool. Interestingly on the screenshots page there is a screenshot generated from the koha source. > http://code.google.com/p/gource/wiki/Screenshots Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Bug assignees - call for volunteers
On 09/02/10 15:47, Paul Poulain wrote: > Galen Charlton a écrit : >> Hi, >> >> The current list of default assignees for bug categories is here: >> >> http://wiki.koha.org/doku.php?id=en:development:bug_default_assignees >> > Note to all : i've nothing against "loosing" default assignment: I don't > have time anymore to be a good bug wrangler. So you won't upset me if > you candidate for one of my default assign ;-) > If you want to shed some and no one else steps up to the plate, I'm quite willing to take up the serials bugs. As I'm scheduled to do a fair bit of work in that area I'll probably be generating a proportion of those bugs. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] perltidy
There was a little bit of discussion on irc a few days back about perltidy and using it to get a bit of consistency in the formatting of the codebase. (consistency is good it means the surproses are more likely to be good than unpleasant). For those of you unfamiliar with perltidy its the program in the perl module Perl::Tidy which if you run it on a perl script produces a version consistently formatted according to irs rules. For more info see the docs at http://perltidy.sourceforge.net also man perltidy and perldoc Perl::Tidy The default rules in perltidy are an expansion of those in the perl style guide (perldoc perlstyle). Koha has its own set of recommendations, for the most part these are the defaults with perltidy. The uncommented lines in xt/perltidyrc show where we've overridden the defaults, they are: cuddled_else opening-brace-always-on-tight (a logical extension of cuddling your else) paren-tightness=1 (uncommented as if a non-default but is the perltidy default) vertical-tightness ( see the examples in Perl Best Practices for a reason for this) maximum-line-length=178 I would suggest that the maximum-line-length be reduced ( The default value is 80), my reasoning is this: although we all have editors and terminals that handle long lines, we actually like to use that screen estate to see more than one file, so that letting the code wander off to the right makes it easier to miss important clues when reading it. Especially when using tools like vimdiff, git diff, git blame etc. I feel if you have a line like: ($lots, $of, $returns) = call_subroutine( $with, $more, $arguments, $than, $it $should @have) if ($i_want_to_hide_my_conditional && $x == $y); a few judiciously placed new lines make it more readable and more maintainable, and with a long line length they disappear. Also a quick unscientific scan through the existing codebase a few days back revealed 96.96% of existing lines are 80 characters or less ( 99.7% are less than 100) so that perltidying with a long line length may have a detrimental effect in some cases. Also it seems we are by default using shorter lines. I think we should resolve this before considering any cleanup operations. Finally a tip. I found this in the book Perl Hacks with these two vim mappings: map ,pt :%! perltidy map ,ptv : '<,'>! perltidy I can use the commands ,pt and ,ptv in vim tp perltidy the file, or a region of the file within the editor. The latter is esprcially handy if I've added a few lines to a file and I want them formatted consistently but I don't want to obscure the files revision history by cleaning up code I've not touched. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Koha sessions table is ridiculously huge
On 18/02/10 11:47, Chris Nighswonger wrote: > On Thu, Feb 18, 2010 at 5:05 AM, Paul Poulain > wrote: >> Le 17/02/2010 21:10, Chris Cormack a écrit : >>> 2010/2/18 Clay Fouts: >>> >>>> It depends, actually. For tables without FK constraints (like Koha's >>>> "sessions"), truncation is instantaneous in MySQL. >>>> >>>> >>> Not when they tried it yesterday :-) >>> >>> It does depend, InnoDB can do some strange things. >>> >> including not freeing space in the file system even if you truncate the >> table :( > > Ouch! this would seem to be a mysql bug. Is there no way to ensure the > drive space is freed up? mysql says no http://bugs.mysql.com/bug.php?id=1287 If you have everything in one ibdata file it can be difficult to recover space. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Koha sessions table is ridiculously huge
On 18/02/10 12:42, Galen Charlton wrote: > However, reclaiming space is easy enough, since by default a separate > InnoDB file is created for each table: just drop and recreate the > sessions table. You can also use MyISAM instead of InnoDB for that > table. I'm not sure it is the default. It requires innodb_file_per_table to be set in your config (some distributions may do that for you). Colin (who has cursed this feature when freeing up space in the early hours of the morning in the past) -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
[Koha-devel] Date::Manip - a Warning
Just a warning that if you install Date::Manip from CPAN you get version 6. It is a major overhaul and will not build on perls earlier than 5.10. Anyone writing code that depends on it should probably be circumspect and check Date::Manip::Changes5to6. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] FSF address in copyright notices
On 16/03/10 10:39, Galen Charlton wrote: >> My preference is to update installation documentation, not remove it. >> Any Fedora users about who could run through an installation with the >> current version of Fedora? Certainly the current one needs a health warning. I'll try and run an install on a fresh Fedora 12 and see what should be in the doc. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Developer Documentation
On 18/03/10 14:47, Nicole Engard wrote: > Hi all, > > I know that we're all busy, but this idea is for the best of the > future of Koha - with better documentation for developers we can > attract more skilled developers - and improve the work of those trying > to help with development now ... so is anyone interested in being on a > committee? > Yes I'll lend a hand. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Possible IRC tutorial nginx and FastCGI
I heard that PSGI on nginx is very fast. I was impressed by a presentation on PSGI/Plack by its author, but haven't really played with it since. Has anyone any experience of it? Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Minimum version of Perl
On 14/05/10 14:17, Galen Charlton wrote: > Hi, > > At present, the minimum version of Perl required by Koha is 5.6.1. > Since MARC::Record requires 5.8.2, at the very least Koha's > requirement should be 5.8.2, and 5.8.8 (the current stable release in > the 5.8.x series) would be better. Are there any common platforms > where this would be an issue? What about going further and bumping up > to 5.10.0? 5.8.8 has been around for a few years and most platforms (even the more conservative enterprise ones) are on at least that. It might be a good base to recommend as it resolved some long standing oddities if I remember right. What ever people feel, I definitely thing we should say 3.4 will be at least 5.10. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] Minimum version of Perl
On 14/05/10 16:24, Chris Nighswonger wrote: > On Fri, May 14, 2010 at 9:17 AM, Galen Charlton wrote: > In any case, we should determine for sure which version is required to > run all Koha code successfully and go with that OR determine what code > requires 5.10 and make it compatible with 5.8 prior to 3.2 stable. Bug 4269 refers to DBD::SQLite2 which is a problem (but most folk can run koha happily without) Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Re: [Koha-devel] git.koha-community.org
On 14/05/10 16:47, Galen Charlton wrote: > # for the Koha repository > git remote set-url origin git://git.koha-community.org/koha.git I think set-url is new in git 1.7ish if you don't have it change the url for origin in .git/config (or upgrade git!!!) Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
