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

Status of Debian and Koha
by Vincent Danjean 05 Aug '08

05 Aug '08

Hi, I'm pleased to announce that most of Koha dependencies (as listed in Makefile.PL) are present and up-to-date in Debian. The only exceptions are: * XML::RSS: the package libxml-rss-perl is outdated but its maintainer has just accepted that the package will be maintained by the Debian Perl Group. So it should be ok very soon. * Zebra [and Koha itself]: they will need more work According to a recent post on this list, zebra seems to require a more recent version of ZOOM (or at least of libyaz) than the one currently in Debian: Makefile.PL (from Koha) requires ZOOM >= 1.16 that works with libyaz2 2.1.48. Both ZOOM 1.16 and libyaz2 2.1.48 are on my webpage and in Debian experimental. But newer versions seem to be required. There is good hope here again that we will be able to upload an up-to-date yaz package in a few weeks. Next step: packaging zebra and Koha... Best regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanjean(a)debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main

6 9

new sysprefs
by Paul POULAIN 20 Feb '08

20 Feb '08

Hello, i'm translating the syspref added this week, and have found some that are only defined, and not used in the code : - WebBasedSelfCheck - staffClientBaseURL - minPasswordLength - noItemTypeImages - noOPACHolds (+ kados said, and he was right, that setting "no" to a "noXXXX" parameter means "XXXX", so we should probably rename this syspref to something "positive") - emailLibrarianWhenHoldIsPlaced - holdCancelLength - libraryAddress - finesMode (this one is used, but only in C4/SIP/Patron.pm, which is, afaik, specific & not production ready - globalDueDate - itemBarcodeInputFilter - singleBranchMode - URLLinkText - noOPACUserLogin (which would be a duplicate of opacuserlogin iiuc + kados said, and he was right, that setting "no" to a "noXXXX" parameter means "XXXX", so we should probably rename this syspref to something "positive") - OPACDisplayExtendedSubInfo - OPACViewOthersSuggestions - OPACURLOpenInNewWindow - OPACUserCSS (what does this one mean ? We already have opacstylesheet, opaccolorstylesheet) - emailPurchaseSuggestions There are so many missing that I just checked my repo was uptodate !!! so, were they here by mistake ? it is some planned features ? something i've missed ? cheers -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

4 4

Koha 3.0 Staff Client Ready for Translation
by Joshua Ferraro 08 Jan '08

08 Jan '08

Hi all, Just a quick announcement for those of you interested in translating Koha 3.0 into your respective languages, the Staff Client POT file is ready for download and translation. I've created a generic POT that can be used, simply re-name the file to match your locale using RFC4646 conventions. Here's the link: http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=tree;f=misc/translator/po;h… (note that there is already a French translation written) The generic PO is called 'xx-XX-i-staff-prog-v-30000.pot'. You'll want to rename that file to match the language-script-region that you're translating. Starting with Koha 3.0, I'd like to propose a new naming convention for the PO/POT files in Koha that follows RFC4646 (have a look at http://www.w3.org/International/articles/language-tags/ for an intro). We can utilize RFC4646's concept of 'extensions' to tag for the 'theme' (t) and 'interface' (i) and 'version' (v). For example, if you're creating a French translation in France, the filename would be: fr-FR-i-staff-t-prog-v-30000.po Note that FR is a 'region' subtag ... but in some languages, such as Chinese, it's also useful to be able to distinguish between 'script's, such as 'Hans' (Simplified Han) or 'Hant' (Traditional Han). So you might, if you are translating Koha into Chinese, end up with a filename like: zh-Hans-i-staff-t-prog-v-30000.po RFC4646 gives us a lot of flexibility in how we distinguish between various translations. There are two excellent programs for doing your translation, depending on which platform you're running: LocFactory Editor (for OSX) POEdit (for Windows) Of course, you're free to simply use a text editor if that suites you, but please make sure you're in UTF-8 mode. Once you've got your PO file into a state where you're happy with it, you have a number of choies: 1. you can email it to the koha-translate list 2. you can email it to me 3. you can add it to Git yourself In the coming weeks I'll be updating translate.koha.org in preparation for the 3.0 cycle of releases, and improving the documentation on how to internationalize your Koha system, but if you prefer to work with local PO files, I wanted to make sure you had that opportunity. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

2 1

Any interest in adding MP3 ID3v2 read/write capability to Koha?
by Chris Nighswonger 05 Dec '07

05 Dec '07

Hi, We have a good sized collection (and growing) of MP3 encoded audio that we plan to use Koha to catalog. Most of our MP3's have to have tags created and added to them. A few have tags already. The job of creating them could be made a lot easier by adding the ability to write ID3v2 tags to the MP3's based on the corresponding marc record for the audio archive. (Our in-house software does this currently, but is coded in VB rather than Perl.) We have been looking at using MP3::Tag to incorporate this read/write capability into Koha. To do this right, I think some discussion is in order prior to beginning. I'd like to hear feedback on two points: 1. From the user prospective: Is there any interest/demand for this type of feature? 2. From the developer prospective: What is the best mapping plan for marc fields to ID3v2 frames and vise-versa? If you are not familiar with the ID3v2 standard, take a look at http://www.id3.org/id3v2.4.0-frames which is probably the relevant part for this discussion. Regards, Chris -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org

4 8

UTF-8
by Dorian Meid 03 Dec '07

03 Dec '07

Gentlemen, I have a problem using UTF-8 with Koha. If I import MARC-Data via z3950 special characters are treated differently ÄÜÖäüö works at some pages but not in all. ß dosn't work at any page. This is the ü I get from z3950 and this is the ü which is generated when I type it. These are two different characters. I'm using Koha 2.2.8, MySQL5 and Apache 1.3 on Mac OSX 10.4 with Firefox. I've read the notes on the Wiki and my server, Database and the tables are set to UTF-8. I also set the templates encoding variable and added the encoding to httpd.conf The z3950 server sends data UTF-8 encoded Did I miss something? Dorian Meid

3 5

PERL5LIB question
by Ignacio Javier 30 Nov '07

30 Nov '07

Hi all: Just a doubt: where is supposed to point PERL5LIB, perl libraries directory, that is: /usr/(local/)?share/perl/5.8.8 Or /usr/(local/)?share/perl/5.8.8/koha Or Koha directory (in this case where is located?) My question comes because I'm not sure if there is any difference between perl standard path for perl libraries and koha perl one, seems in my debian perl installation all koha .pm files are installed below /usr/local/share/perl/5.8.8 The indications that led me to confusion are at: http://wiki.koha.org/doku.php?id=22_to_30&s=perl5lib Hope being helped!, Greetings, Ignacio

5 6

Installer - temporary git tree set up
by Galen Charlton 30 Nov '07

30 Nov '07

Hi, I have created a temporary git repository for work on the Koha 3.0 installer. My intention is to integrate patches from myself and others and by the end of next week compile a stable set of changes to push to the main HEAD. GitWeb is at http://manage-gmc.dev.kohalibrary.com/cgi-bin/gitweb.cgi The repository can be cloned from http://manage-gmc.dev.kohalibrary.com/koha-installer.git as well -- note that the protocol is http, not git. Thus far I've integrated patches mostly concerned with allowing the Zebra language and MARC flavor to be set during installation. Over the next few days, I will be applying more patches and working on: [1] separate target directories for Zebra configuration files and index data. [2] general bug fixes Tomorrow I will also post a summary of the #koha discussion regarding the installer. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709

1 0

Re: [Koha-devel] Issues for README.txt and Makefile.PL
by Thomas Dukleth 29 Nov '07

29 Nov '07

Reply inline: On Mon, November 26, 2007 11:42 am, MJ Ray wrote: > "Thomas Dukleth" <kohadevel(a)agogme.com> wrote: [...] >> 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. [...] > > That seems like the wrong solution to me. If people aren't creating > and pushing unannounced fixes to the main repo fast enough, the > conflicts are their lookout IMO. For example, I didn't know Galen > Charlton was also working on the PL_FILES problems until your email. 1. SHARING OF COMMITS. There is an issue that there is no efficient mechanism for seeing what others have committed until the commits have been approved and pushed to the main repository. A mechanism needs to be provided at some point for sharing people's local git repositories and allowing anyone to see commits pending for the main repository. I do not suggest that this needs attention now but should be well considered when there is time to do so. This might be nothing more than just a listing of links to various contributors public local Koha git repositories, which would have a little extra value if gitweb has been applied to them. Cloning them on koha.org is another possibility. The absence of such a system has not yet been a serious issue for me personally, but I see the prospect that collaborative work may be slowed at some future point without some system for sharing work which may not even be ready to be pushed up to the main repository. 2. THIS CASE. The presumption for this particular case was that conflicts would be likely, therefore, not everyone's fixes would be pushed up to the main repository. More significantly for this case, the suggestion to me was that with so many people working on the installer I could better use my time by working on something else and merely sharing my thoughts with those taking the lead on the installer. 3. DEBIAN PACKAGES. > > A few comments on the other aspects: > >> [...] 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. > > They will be placed in the main repositories. Vincent Danjean has > pushed some packages to pkg-perl just this weekend. > I assume that they will be in Debian testing at this point. Will they also be provided for apt in a manner tied to Debian Etch via backports or an independent Etch based repository? 4. FILE GLOBBING. >> 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. > > A better fix might be to check that glob returns are files with -f or > at least ! -d. Thanks for that correction. Unusually for me, I did not persist until I found the correct documentation for glob. I only spent a few seconds in a couple of Perl references which did not list any options other than simple pattern matching expressions. I believe that glob derives it function externally to Perl but I still did not take the time to look. 5. 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. > > Why? That seems like a serious security risk, leaving the web > application able to change the file-based configuration if exploited. > > I think that is one thing which should be left to defaults, with the > sysadmin tightening things if needed. > I did not put that correctly. I should have said group ownership. The group owner should not have permission to change files which the group owner does not need to change. The installation process should be able to produce a working Koha installation with the least manual configuration necessary. The more obstacles required to see a test installation of Koha running well, however minor, the less widespread interest in using Koha is likely to be. [I do not mean that Koha should have a silly installation which presumes that the person installing does not need to know anything. That would not happen with Koha, although, I suspect such simple installations help the adoption of some MS Window ILS systems.] 6. HTTPD CONFIGURATION. 6.1. PERMISSIONS. >> Using the ScriptAlias directives is considered a security vulnerability. > > By whom? It's not mentioned in > http://httpd.apache.org/docs/2.2/howto/cgi.html > - in fact, it seems to suggest the reverse. > I do not have any obvious authority to identify readily available. I believe that the problem as I have seen it described is that ScriptAlias is too permissive in what it allows. I realised just after I sent this message that I had forgotten to include strictly limited directory based permissions. I believe that AddHandler cgi-script .pl or something similar which only provides for executing explicitly provided file extensions is at least a little safer than ScriptAlias. >> Alias directives, rewrite rules or some other more secure method should >> be >> substituted for ScriptAlias directives. > 6.2. EXTRA REQUIREMENTS. > Rewrite rules would add extra requirements for Koha hosting. Not sure > whether that's a problem or not. Rewrite rules would add an extra requirement so they should perhaps be an included option even if many may prefer them. Some rewrite rules are currently provided by default. The most flexible solution may be to have the user select preferences in Makefile.PL for how to have the default koha-httpd.conf configured. Other options should still be available as comments if the user wants to change something. Minimal options should be possible but more powerful options should be available. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783

3 2

Re: [Koha-devel] PERL5LIB question
by mourik jan heupink 29 Nov '07

29 Nov '07

> That seems to be written by people who install koha into a non-FHS > location, as well as using the CPAN shell instead of debian packages. > Maybe heupink and tipaul can explain why they do that and/or edit the > page to mention those oddities. Hi, I'm 'heupink' who edited the page, but the only change I made was that I corrected the url for zebra (as it was: http://www.indexdata/dk/zebra) So I'm sorry, but really can't explain anything. :-) regards, mourik jan

1 0

RE: [Koha-devel] koha 3 installation, some battles won, but warseems lost still...
by Michael Hafen 29 Nov '07

29 Nov '07

This gets ugly. When I install to a location other than default most config stuff for zebra and koha, especially paths, are wrong. I have to fix them. Mostly it's just the paths, the only exception is the database stuff at the bottom of koha-conf.xml. The user, pass, and database I have to set to the right value. The other problem I find is the SQL scripts don't get installed by `make install` so I have to copy them into the right place for install.pl to find them. I suspect that most of this is because I have installed to a location other than the default. The rest will probably be fixed with the work that is being done on the install scripts. On Thu, 2007-11-29 at 19:17 +0100, Ignacio Javier wrote: > Two additional doubts then: > > 1) install.pl (which seems to import SQL scripts for koha dependencies > outside zebra) is not invoked from the installer interface? > > 2) what is the right configuration for zebra (koha_conf.xml) then, other > different from the default one? > > -----Mensaje original----- > De: koha-devel-bounces+ignacio.gomez=coremain.com(a)nongnu.org > [mailto:koha-devel-bounces+ignacio.gomez=coremain.com@nongnu.org] En nombre > de Michael Hafen > Enviado el: jueves, 29 de noviembre de 2007 18:53 > Para: koha-devel(a)nongnu.org > Asunto: Re: [Koha-devel] koha 3 installation, some battles won, but warseems > lost still... > > > I've installed Koha 3 to a location other than default. As I recall > this error was caused by the database config in koha_conf.xml not being > right. I suggest checking that. > > > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)nongnu.org > http://lists.nongnu.org/mailman/listinfo/koha-devel >

1 0