- Koha-devel - lists.koha-community.org

Re: [Koha-devel] items.wthdrawn
by Thomas Dukleth 28 Nov '07

28 Nov '07

Repeating spelling errors only complicates coding and requires excessive attention to past mistakes. Joshua Ferraro had agreed with me when we discussed that point two or three months ago. The arrangement which I made with Joshua over spelling errors in column names which were used in the MARC frameworks was that I would correct spelling errors in the frameworks and he would ensure that the spelling errors were corrected in the rest of the code. Fixing the spelling errors throughout the code should require only a simple script. Leaving spelling errors is only likely to promote future errors in coding as uncorrected spelling errors accumulate. Eventually, a special dictionary of Koha would be required if errors go uncorrected. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Tue, November 27, 2007 4:19 pm, Galen Charlton wrote: > Hi, > > Alas, the withdrawn status column in the items table is called > 'wthdrawn', not 'withdrawn'. This is observed in most places in the > code except for (as I discovered) some of the MARC 21 framework > initialization SQL. > > I'm going to replace references to 'items.withdrawn' with > 'items.wthdrawn'. While I would prefer to spell the column correctly, > sticking with 'wthdrawn' for now affects rather fewer files. I'll > wait for 3.2 to rename the column. > > Regards, > > Galen > -- > Galen Charlton > Koha Application Developer > LibLime > galen.charlton(a)liblime.com > p: 1-888-564-2457 x709 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)nongnu.org > http://lists.nongnu.org/mailman/listinfo/koha-devel >

3 2

#koha meeting for installer
by Galen Charlton 28 Nov '07

28 Nov '07

Hi, As was mentioned yesterday, I will be on #koha tomorrow (i.e., Wednesday, 28 November 2007) at 11 a.m. Central / 12 p.m. Eastern if anybody wishes to discuss the installer. I'm looking for information about the various problems that people have discovered and ways of resolving them, and am hoping to get us all towards a consensus. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709

3 3

Re: [Koha-devel] items.wthdrawn
by Thomas Dukleth 28 Nov '07

28 Nov '07

I favour fixing all spelling errors in the code now. I suspect any instances of unusual construction of misspelt names which may be missed by a good correction script are almost none to none. The code for 3.0 needs to be tested in any case. This particular spelling error is not the only such spelling error in the code but I do not have the definitive list and anyone could easily break things by assuming correct spelling or misreading the misspelling. Let us try to avoid accumulating such errors in the future. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Tue, November 27, 2007 10:18 pm, Galen Charlton wrote: > Hi, > > On 11/27/07, Thomas Dukleth <kohadevel(a)agogme.com> wrote: >> The arrangement which I made with Joshua over spelling errors in column >> names which were used in the MARC frameworks was that I would correct >> spelling errors in the frameworks and he would ensure that the spelling >> errors were corrected in the rest of the code. > > The issue is that having the discrepancy breaks the functionality of > editing the items withdrawn status field. > >> Fixing the spelling errors throughout the code should require only a >> simple script. Leaving spelling errors is only likely to promote future >> errors in coding as uncorrected spelling errors accumulate. Eventually, >> a >> special dictionary of Koha would be required if errors go uncorrected. > > I would be more than happy to submit a patch to change 'wthdrawn' to > 'withdrawn' once and for all. However, even as mechanical a change as > that requires testing to ensure that no functionality is broken and > that there are no instances in the code where a column name is being > constructed in an unusual fashion. > > My question is this: do we do such a change now in 3.0 pre-beta, or > push it to the next unstable version (i.e., 3.1/3.2)? > > Regards, > > Galen > -- > Galen Charlton > Koha Application Developer > LibLime > galen.charlton(a)liblime.com > p: 1-888-564-2457 x709 >

1 0

makefiling sources from git repository (version 3.00.00.031)
by Ignacio Javier 27 Nov '07

27 Nov '07

Hi all: I'm having some problems of the kind I'm on the nearbies of knowing why but on the outside boundaries of knowing why I should bet on my own certainness. When we installed Koha previously (3.00.00.005), we made some forced assumptions that resulted in a bad installation than now shows as problematic to make function Koha as a whole, that precisely led to a nozebra flawed table. Now, to take the certainness we are doing the things on the right, clean and "pathologically orthodoxial" way, we have the following doubt to be solved: Our debian etch comes with a default perl 5.8.8 installation that produced some errors where trying to solve the dependencies from cpan. In fact we are having severe problems with Date::Calc module, which evidences impossibility of install due to a Calc.c error. Which is probably the result of a problem with system libraries conflict due to another CPAN updates that come from any dependency that is needed by koha... Is this correct?, that is get the way doing it from CPAN or may we branch to dkpg installations to solve dependencies? Do you use for developing default debian etch perl installation or are you using another (vanilla, strawberry or maybe a version of perl compiled from sources?) That's all, hope being helped! Ignacio

2 2

items.wthdrawn
by Galen Charlton 27 Nov '07

27 Nov '07

Hi, Alas, the withdrawn status column in the items table is called 'wthdrawn', not 'withdrawn'. This is observed in most places in the code except for (as I discovered) some of the MARC 21 framework initialization SQL. I'm going to replace references to 'items.withdrawn' with 'items.wthdrawn'. While I would prefer to spell the column correctly, sticking with 'wthdrawn' for now affects rather fewer files. I'll wait for 3.2 to rename the column. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709

1 0

Fix for NPL intranet template bug
by Nicholas van Rheede van Oudtshoorn 27 Nov '07

27 Nov '07

Hello, There's a rather irritating CSS bug with the NPL acqui.simple/addbiblio.tmpl template. When you click on the tab numbers, the selected tab is made visible, and all other tabs made invisible. Unfortunately, (at least in the latest Firefox!), the invisible tabs still occupy the same space they would if they were visible. I'm not sure if it's the right fix, but the following version of the active() javascript function (inside the template file) seems to fix it (Added lines are bolded). Apologies that this isn't a patch - I never got around to figuring out how to use the *patch* command properly! Nicholas van Oudtshoorn function active(numlayer) { for (i=0; i <= 9 ; i++ ) { ong = i+"XX"; link = "link"+i; if (numlayer==i) { with(document){ if (document.getElementById(ong)){ document.getElementById (ong).style.visibility="visible"; * document.getElementById (ong).style.height="auto";* } if(document.getElementById(link)){ document.getElementById (link).style.color="#000066"; document.getElementById (link).style.backgroundColor="#FFFFCC"; } } } else { with(document){ if (document.getElementById(ong)){ document.getElementById (ong).style.visibility="hidden"; * document.getElementById (ong).style.height="0";* } if (document.getElementById(link)) { document.getElementById (link).style.color="#669999"; document.getElementById (link).style.backgroundColor="#D8DEB8"; } } } } }

1 0

Issues for README.txt and Makefile.PL
by Thomas Dukleth 26 Nov '07

26 Nov '07

README.txt and Makefile.PL for Koha 3.0 needs a number of significant fixes and corrections. As I was preparing some proposed fixes, Joshua Ferraro informed me that there are various pending fixes from a few people. Some of the pending fixes will not be pushed up to the Koha git repository because they conflict with other more complete fixes. Galen Charlton has committed some fixes which have yet to be pushed up to the main repository. Galen's fixes may resolve at least some of the issues which I have had. Galen is actively working on these issues so I raise the issues that I had originally proposed to commit so that they may be considered for non-conflicting incorporation if they have not already been fully considered. Some issues follow. Please comment and add any additional issues. 1. README.TXT PROBLEMS. 1.1. LACK OF OPERATING SYSTEM DISTRIBUTION SPECIFIC INSTRUCTIONS. Ideally, the installation would work seamlessly on every operating system distribution which Koha supports. However, we know that seamless installation is not going to happen until the time is available for building a complete set of Koha packages for various operating system distributions. README.txt lacks direction to operating system distribution specific information and otherwise undistributed packages. I have had to rely upon one and perhaps now two supplementary binary packages for Debian to allow me to install Perl modules, which may not be critical to using Koha but are certainly good to have. Vincent Danjean has some supplementary Debian packages at http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/deb.html and MJ Ray has some at http://serene.ttllp.co.uk/~mjr/ . At some point, these should be placed in repository for apt to use. There seem to be problems building Barcode::Code12 8 on many platforms which is a dependency of the needed PDF::Reuse::Barcode which the binary Debian package from Vincent solved for me. There have been problems building Barcode::Code128 on many operating systems and platforms throughout its release history. See reports from CPAN testers such as this one for the current version, http://www.nntp.perl.org/group/perl.cpan.testers/2007/07/msg544810.html . I also have a dependency issue which I have not yet completely investigated for building XML::LibXSLT 1.6.3. Maybe keeping version 1.6.2 for now will not be a problem. 1.2. CORRECT PATHNAMES IN COMMANDS. Any pathnames in commands should at least match the default pathnames created by Makefile.PL. Perhaps Makefile.PL should build the necessary commands to run with the correct pathnames during make install or make install should also create a script to run the commands after make install. 1.3. ENVIRONMENT VARIABLES. Possibly conflicting Koha release 2.2 environment variables should be unset or reset if that may be a potential problem for some. 1.4. SPECIFYING THE XML CONFIGURATION FILE OPTION FOR ZEBRA. The -c option is still given for zebrasrv which should long ago have been changed to -f for using an XML configuration file. 2. MAKEFILE.PL PROBLEMS. 2.1. PROBLEMS PREVENTING SUCCESSFUL MAKE. File globbing which captures directories builds a makefile which aborts with the following error when running make. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ERROR: Cannot copy 'installer/data/mysql/fr/mandatory' to '/usr/local/lib/cgi-bin/koha/installer/data/mysql/fr/mandatory': Is a directory !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! at -e line 1 make: *** [pm_to_blib] Error 21 Changing general file globbing from * to *.* for using the '.' in filenames can fix that problem. However, that solution is not robust if files are not in *.* form and at least needs a specific correction for .htaccess as the only file which does not match the pattern. 2.2. INSTALLATION DIRECTORY PROBLEMS. Default installation directories are not what they should be. If the task of resolving these issues has been left to Galen, I am not going to take the full time to make a detailed list, however, some special attention should be given to general principles. The defaults do not put directories where they should be in multiple cases. 2.2.1. CONFLICT BETWEEN PL_FILES AND MAP_TREE. I believe that Galen has a fix for the problem where map_tree values had been overwriting PL_FILES values. 2.2.2. ZEBRA DIRECTORY LOCATIONS. The case of Zebra is especially problematic. The treatment of the Zebra directories does not follow important principles. Currently, configuration and data directories for Zebra are in the same location. 2.2.2.1. SEGREGATION OF CONFIGURATION AND DATA. Configuration files should be segregated from data files for easy and distinct management. Configuration files are traditionally stored in /etc or some equivalent such as /usr/local/etc. Data files are usually stored in /var or some equivalent such as /var/local. Configuration information in some form of /etc can be reasonably compact for storage and backup. Data in some form of /var may be quite large and require its own disc storage for all of what it needs to contain and as use develops it may grow significantly over time. 2.2.2.2. MISSING DIRECTORY. One additional issue is of special importance. The main Zebra temporary directory is not created on installation. 2.3. INSTALLATION FILE OWNERSHIP. The webserver user should be read and ownership of the necessary files should be changed to the webserver user when running make install. 2.4. CONFIGURATION FILES CONTENT. 2.4.1. GENERAL CONFIGURATION FILE PROBLEMS. Configuration file pathnames do not match either the default pathnames or the actually installed pathnames. 2.4.2. KOHA-HTTPD.CONF. Using the ScriptAlias directives is considered a security vulnerability. Alias directives, rewrite rules or some other more secure method should be substituted for ScriptAlias directives. Directory options should be specified in advance 2.4.3. KOHA-CONF.XML. The Koha administrator username and password should be written to the file according to what is specified. 2.4.4. LANGUAGE SPECIFIC CONFIGURATION FILES. Language specific Zebra configuration files are missing from the Zebra configuration directories. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783

4 5

Digital Signature Implementation
by arnab 26 Nov '07

26 Nov '07

Dear All, I'm using Koha227 on windows platform. I'm working on a customization module of patron authentication using Digital Signature. Patron could search books and send requisition to the librarian. At the time of the issue, the patron has to give his/her password. The information regarding the book, patron id etc will be converted into a message digest and using a Digital Signature algorithm, would be stored in the database. In future if the patron denies accepting the book, this will be used to very the patron authentication. So, far I'm not able to install the module required for the implementation of digital signature. Should I go for implementing the Crypt::DSA module?? if so how should this module be installed. thanx Arnab -- View this message in context: http://www.nabble.com/Digital-Signature-Implementation-tf4872852.html#a1394… Sent from the Koha - Dev mailing list archive at Nabble.com.

1 0

Internationalising Koha frameworks
by Thomas Dukleth 26 Nov '07

26 Nov '07

Do you use MARC 21 in a language other than English? Do you use UNIMARC in a language other than French or English? Do you use a MARC variant other than MARC 21 or UNIMARC? If you have any language specific or MARC variant specific Koha frameworks for sharing, please contact me on or off the list. LibLime has asked me to prepare whatever MARC frameworks I can obtain for use in the forthcoming version of Koha 3.0. Share yours so that others do not need to do redundant work. [MARC frameworks are either bibliographic or authorities frameworks and go by various names in Koha depending upon how you access them. In the system administration intranet interface, they are identified as Biblio framework (MARC structure) for bibliographic frameworks or Thesaurus structure for authorities. In the installation directories, they have names such as structure_def.sql for bibliographic frameworks or authorities_normal_marc.sql for authorities.] I will supply very simple instructions for exporting your frameworks from your SQL database if you need such assistance. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783

1 0

How to start play with pre-Koha 3.0?
by Serhij Dubyk Сергі й Дубик 23 Nov '07

23 Nov '07

I am interested to install Koha 3.0 CVS to start translate it into native language (large work), test it and look about possibility to apply my patches 2.2.9 Think that necessary to begin with getting from CVS. How to do it correctly? Through a search I found such 3 variants: 1) cvs -d:pserver:anonymous@cvs.sv.gnu.org:/sources/koha login cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/koha co . 2) cvs -d:pserver:anonymous@cvs.sv.gnu.org:/sources/koha login cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/koha co . 3) git clone git://git.koha.org/pub/scm/koha.git kohaclone Also please tell shortly about depositarys of Koha (CVS, git ...) With kind regards Serhij Dubyk (Ukraine) -- View this message in context: http://www.nabble.com/How-to-start-play-with-pre-Koha-3.0--tf4857763.html#a… Sent from the Koha - Dev mailing list archive at Nabble.com.

2 2