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

Convincing City IT Dept.
by Ed Veal 11 Aug '08

11 Aug '08

I have an interesting situation here. We had LibLime come and give us a presentation last week and I thought it would be best to invite the city IT staff to take a look so that they could be onboard with any decision that we make. However, what has happened is that they seem to think that they have the expertise to do this on their own. I shudder at the thought. They have already set up a server and are wanting my advice and guidance in migrating data. My advice is to contract it out, we don't have the resources or the expertise to accomplish this. So my question is how do I convince the IT department of this? I can't seem to get it through to them that this is not just any old SQL database. **************************************************************** Edward Veal (eveal(a)mail.ci.lubbock.tx.us) System Administrator Lubbock Public Library http://www.lubbocklibrary.com Mahon Library 1306 9th St. Lubbock, TX 79401 voice: 806-775-2849 fax: 806-775-2827 *******************************************************************

8 7

Application to get the KOHA cd package.
by itiwm Jonny 11 Aug '08

11 Aug '08

Hi, I am a librarian in kenya.I would like to get the cd installation package for the KOHA library software.We have a slow internet connection and we cannot download the program online.Any assistance in that aspect would help in the automation of our small library. Thank you. Tonny Mwiti My address is Tonny Mwiti, P.o.Box 11136-001100, Nairobi, Kenya.

2 1

Proposed schedule for 3.2
by Galen Charlton 11 Aug '08

11 Aug '08

Hi, For your consideration, an outline of a schedule for Koha 3.2. This is organized by weeks, with this week being Week 1. My main scheduling goals are to have more frequent intermediate releases, to explicitly schedule several periods of bugfixing between the feature pushes, and to release Koha 3.2 no later than the second quarter of 2009 (and preferably, by the end the first quarter). [1] Plotting and planning (weeks 1 to 5) During this period, we'll finishing submitting RFCs for 3.2 and review them. Patches to 3.1 will be accepted, but I may stick anything particularly controversial onto a topic branch until the community has had time to digest the relevant RFCs. At the end of this period, I hope to have: * A list of features that contributors are committed to delivering for 3.2, as well as those that may be pushed off to 3.4 and 3.6. * A list of any architectural and major technology changes for 3.2. * Final coding standards for 3.2. At the end of this period, I tentatively plan to do an initial release of 3.1 (to be called 3.1-dev-release-0), mostly to verify that I can put the package together correctly. This may coincide with release of 3.0.1 (first bugfixes for 3.0-stable). [2] Coding phase 1 (weeks 6 to 9) Period of intensive hacking. [3] Stabilization 1 (weeks 10 and 11) Freeze on major developments; during this time we focus on bugfixing. At the end of this period I will release 3.1-dev-release-1. [4] Coding phase 2 (weeks 12 to 15) More hacking. [5] Stabilization 2 (weeks 16 and 17) At the end of this period I will release 3.1-dev-release-2. [6] Coding phase 3 (weeks 18-21) More hacking. [6] Stabilization 3 (weeks 22 and 23). At the end of this period I will release 3.2-alpha. [7] Catchup feature developement (weeks 24 and 25). Last chance to put in small and medium-sized features. If we can swing it, after this period ends new feature work will go on a branch for inclusion in 3.4. [8] Stabilization 4 (weeks 26 and 27) At the end of this period I will release 3.2-beta. [9] General non-coder review and bugfixing (weeks 28 to 31). At the end of this period I will release 3.2-rc1. [10] Final release (weeks 32 and 33) At the end of this, 3.2-stable. If I'm counting the weeks correctly, that corresponds to the end of March, 2009. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 skype: gmcharlt

1 0

Adding to or Editing the Koha Wiki
by Owen Leonard 10 Aug '08

10 Aug '08

For those of you who may be new to Koha, please note that the Koha Wiki is not editable by default. Because of wiki-spam problems in the past, users are required to register and log in to make changes. This is indcated on the Wiki home page by a message at the top, "Login from the link at the bottom of the page and contribute to the content." The wiki is a great place to get discussions and ideas down in a central place that might be easier to refer to than list messages and IRC chats. Please register and contribute where you can! http://wiki.koha.org Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

3 2

Some thoughts about bulkediting Biblios testing merge_authority.pl .
by henridamien.laurent 09 Aug '08

09 Aug '08

Hi I tested yesterday some authorities modification on the fly. I see two bottlenecks : a) commits in the database are done on each record processed. they should be delayed until all the records are processed. At the moment there is no way using ModBiblio to take control over commits in the database, unless I am mistaken. Could be added quite fast. Someone wanting to test that solution ? b) having to act record by record rather than on the whole bunch of records. Indeed, NoZebra uses GetMarcbiblio and zebra returns USMARC or marcxml but record by record. When it comes to editing 200 biblios, it takes several seconds. maybe if we could have a file containing all the biblios and apply one s///g it could be lightning fast. The problem would be then that there is no batch update into the database designed. But maybe I am dreaming. Nonetheless, if we can't make batch update faster, then we should make it a scheduled process (and have a good API for that which would support regular scheduling). Comments welcome. -- Henri-Damien LAURENT BibLibre SARL http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc tel : +33 4 67 65 75 50 _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

1 0

FW: Welcome to the "Koha-devel" mailing list (Digest mode)
by Jeaux White 05 Aug '08

05 Aug '08

My E-mail address is jwhite(a)ector.lib.tx.us ________________________________ From: koha-devel-bounces(a)lists.koha.org on behalf of koha-devel-request(a)lists.koha.org Sent: Tue 8/5/2008 1:01 PM To: Jeaux White Subject: Welcome to the "Koha-devel" mailing list (Digest mode) Welcome to the Koha-devel(a)lists.koha.org mailing list! To post to this list, send your email to: koha-devel(a)lists.koha.org General information about the mailing list is at: http://lists.koha.org/mailman/listinfo/koha-devel If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://lists.koha.org/mailman/options/koha-devel/jwhite%40ector.lib.tx.us You can also make such adjustments via email by sending a message to: Koha-devel-request(a)lists.koha.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: jeauxite Normally, Mailman will remind you of your lists.koha.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you.

1 0

cat search result list in OPAC & staff
by Paul POULAIN 05 Aug '08

05 Aug '08

Hi, One of our libraries bugs me to have exactly the same look the the biblio summary in the list result. atm, the differences I can see are : - in staff, title/author are on 2 lines, in OPAC, they are on 1 line, separated by 'by' - in staff, publisher is after author, in OPAC it's on line 2, before pubyer Is there an explanation for those 2 diffs, or can I modify the staff to have exactly the same look as OPAC ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

5 5

opac logo image resize
by Paul POULAIN 05 Aug '08

05 Aug '08

Hi, on OPAC, the library can put it's own image for logo, on top/left. If the image is large, it's cropped, not resized : http://o11.bureau.paulpoulain.com/cgi-bin/koha/opac-main.pl where the image is : http://koha.mom.fr/images/LogoFrantiqJPG-CL.jpg (owen) is there some style property to resize automatically the image ? I've tried : <h1 id="libraryname" style="background-image: url('');height:50px;"> without success :( -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

4 5

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

Re: [Koha-devel] [RFC 3.2] Adding some options to item display in OPAC
by Michael Hafen 04 Aug '08

04 Aug '08

Sorry Paul, I forgot to CC the list on this. On Mon, 2008-08-04 at 15:48 +0200, Paul POULAIN wrote: > (http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:display_item) > > On large networks, a given biblio can have multiple items. For a given > patron, it's sometimes hard to see at 1st glance if a book is available > at his own branch. > This RFP want to improve the display of items. > [snip] > * hiding : some libraries may also want to hide completly items that > are not in the branch of the patron (or branchip). A syspref could be > added to activate this feature. If activated : in the result list, only > the patron branch (or branchip) would be displayed. In the biblio detail > same thing, but a click let the user see other items. > I have submitted a patch, and maintain it on my local git branch, that mostly does that, only without the syspref. I use the IndependantBranches syspref as the trigger since this is the way my librarians think this syspref should work. Having it controlled by a syspref would be good for the case where IndependantBranches isn't on. However there are already so many syspref's. It would be nice if we could somehow sub-group them, or have an option to hide syspref's considered 'advanced'. I think in most cases the default setting is right, so this may work. Any other idea's / comment's along this line? Thanks.

1 1