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

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

(no subject)
by Karen Myers 28 Nov '07

28 Nov '07

Hi all I have an interesting problem : after catalouging 1000 books on Koha, the system can no longer find books via the quick search (or advanced). I know all the data is there because I can export it and reimport it to the Reservoir but as far as searching for a book or adding a new item, no dice. Can anyone provide me any clues? Which file holds all the biblio data? Which file holds the Reservoir data? I am using Koha 2.2.8 on Windows with MySQL 4.1 any help appreciated. Karen Myers _________________________________________________________________ New music from the Rogue Traders - listen now! http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=832&refer…

2 1

Amazon webservices (legal issues)
by Paul POULAIN 28 Nov '07

28 Nov '07

Hello all, I've continued to read carefully the contract and have seen, in Amazon E-Commerce Service™ (Amazon ECS), section 5.1.3. " You are not permitted to use Amazon ECS with any Application or for any use that does not have, as its principal purpose, driving traffic to the Amazon Website and driving sales of products and services on the Amazon Website." We are clearly not "driving traffic to the amazon website as principal purpose" Isn't this a caveat for us ? does someone have ask Amazon about this specific topic ? With my subscription, i've specified it was for testing koha, that is a software for libraries, that will use amazon services to provide a better experience to their customers" (or something like that, it's not a copy/paste of what I wrote) -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

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

28 Nov '07

Reply inline: On Wed, November 28, 2007 2:22 pm, Paul POULAIN wrote: > Galen Charlton a écrit : >> 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)? > > I vote NO for doing it nowe. definetly. I doubt that anything will break with a simple script to fix the problem. Do you believe that something will break if the problem is fixed with a script or are concerned about users of yours who have already put Koha 3.0 into production? Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783

1 0

Amazon similar products
by Paul POULAIN 28 Nov '07

28 Nov '07

I've tested the new feature similar product. It's really ... how to say... wonderfull ! But it seem to slow a lot Koha, probably because Koha retrieves the results, and check what is available at the library before computing the result. Shouldn't we have this tab as a separate page, to have opac-detail.pl very fast and "opac-similar.pl" slow, but that's assumed. If you think it's a good idea, then I can file a bugzilla request. -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

1 0

Re: [Koha-devel] makefiling sources from git repository (version 3.00.00.031)
by MJ Ray 28 Nov '07

28 Nov '07

"Ignacio Javier" <ignacio.gomez(a)coremain.com> wrote: > Cannot copy 'installer/data/mysql/fr/mandatory' to > 'usr/local/lib/cgi-bin/koha/installer/data/mysql/fr/mandatory': Is a > Directory Yes, someone changed the structure of installer/data without updating the Makefile.PL function map_tree. I'll try to rustle up a patch for it - I'd like to generalise it and recursively copy files, but I'm not sure of how to do that portably without adding dependencies. [...] > Should I manually remove the > 'usr/local/lib/cgi-bin/koha/installer/data/mysql/fr/mandatory' file, and > copy -R the directory > 'installer/data/mysql/fr/mandatory' to > 'usr/local/lib/cgi-bin/koha/installer/data/mysql/fr/'? That seems like it should work, but there will be other copies left undone, so maybe it won't. Regards, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/

3 4

Re: [Koha-translate] Norwegian translation of Koha
by Thomas Dukleth 28 Nov '07

28 Nov '07

Reply inline: [Sorry for my late reply. I intended to reply earlier but a lingering cold kept me from some things last month.] On Fri, October 12, 2007 10:42 am, Axel Bojer wrote: [...] > We have good news from Norway: > NUUG ( Norwegian Unix User group, http://nuug.no/ ) have agreed to pay > two translators to translate koha into norwegian (bokmål, by the way, we > also have nynorsk :-). So now the next question is: > > How far has the translation files for Koha 3.0 come by now? As quoted > above, they ought to be in good shape now, but, well, delays seems to > happen, so: How is the status by now? Is it advisable and possible to > start translating koha 3.0 already now or will there be major changes > that will render our work (partly) useless? > > I also wonder how difficult it will be to make a local build with our > translations? The koha-translate list is not read by as many people who should read it as it ought to be. I will try to obtain an answer for you about the current status of Koha 3.0 HTML stability for translation. > My experiences with other translation project (Scribus, OOo, KDE) shows > me that it is essential to be able to look at what you have actually > committed. Often it is impossible to know exactly how to translate a > spesific phrase without knowing how this function works and/or what the > GUI looks like. > It will therefore be important for us to be able to make our own > localised builds continuously to see the changes and the results. > > And third: If all the other questions are answered with «GO FOR IT > (NOW)», then: Is it possible to put the needed files out on the net like > this: > http://translate.koha.org/use.php?lg=en > > or do you have pot- and po-files ready for us? > While setting up something like "http://translate.koha.org/use.php?lg=en" may be possible, I suspect that is not likely to happen given other development priorities. Although, you could do that yourself using a git repository clone. See the Koha git documentation at http://wiki.koha.org/doku.php?id=en:development:git_usage . I will press for the current status of po files. > And, finally, what about the mentioned «MARC frameworks», are there any > ready made translation files for them? > There has never been a proper translation model for frameworks. A diff based model at least should be created for future. At present simply adapt the most current copy of the frameworks in SQL format for your language. I recommend carefully editing the most current Koha frameworks as SQL files using a text editor designed for editing source code such as vim. Using the frameworks editor inside Koha is suitable for small changes but it is too slow and has too many bugs to be really suitable for translation work. Whether you are translating current MARC 21 into Norwegian or adapting it for the similar NORMARC, you should start with the most recent version of the Koha MARC 21 bibliographic framework, http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=installer/data/mysql… . Use the NORMARC documentation whether you are translating the current version of MARC 21 or adapting for NORMARC, http://www.nb.no/fag/kompetansesenter/kunnskapsorganisering/dnk . Use the most recent version of Koha MARC 21 authorities framework, http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=installer/data/mysql… . I would be pleased to offer any assistance I can for the frameworks. I edited the English frameworks but I do not have any facility with the language of my ancestors. Also, I would personally be interested in a formal English translation of the relatively few NORMARC elements which do not match MARC 21 elements. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 [...]

4 3