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

Next general IRC meeting: 3 March 2010 at 19:00 UTC+0
by Galen Charlton 09 Feb '10

09 Feb '10

Hi, The next general IRC meeting will be held on Wednesday, 3 March 2010 at 19:00 UTC+0 in the #koha IRC channel (server irc.katipo.co.nz). The agenda is currently" 1. Update on Roadmap to 3.2. 2. Update on Koha 3.0 Roadmap. 3. Follow-up on actions from General IRC Meeting, 9 February 2010. 4. Discuss module maintainer proposals 5. Bug Category Roles: update default assignees - for more background, see http://lists.koha.org/pipermail/koha-devel/2010-February/010920.html 6. Agree times of next meetings. To add items to the agenda, please edit the wiki page for this meeting: http://wiki.koha.org/doku.php?id=en:events:meetings:irc_meetings:meetingnot… [1] Time converter: http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=03&day… Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

1 0

Make borrowers.userid a unique key
by Chris Nighswonger 05 Feb '10

05 Feb '10

Hi all, As things stand in the current HEAD, borrowers.userid is constrained by memberentry.pl code to be unique preventing duplicate userids. The import_borrowers.pl script does *not* enforce this restraint thus introducing the possibility of duplicate userids. Most AAA systems with which I am familiar prohibit the use of duplicate userids. I believe that this constraint should be enforced at the database level in Koha. Making this change will also ensure that the constraint is honored by custom patron import utilities/interfaces. The only fallout I can see from this change would occur if an existing database was already populated with duplicate userids. This would, of course, have to be addressed with some sort of custom foo in order to enable the change to be applied to the db schema. What are your thoughts on this? Kind Regards, Chris

2 1

Zebra and OpenSuse
by Oscar Gaona 05 Feb '10

05 Feb '10

Hi all I am working Koha 9.00.05, Zebra and OpenSuse 11.2 and the ./rebuild_zebra.pl -a -b -z process is not automatic. When I try /etc/init.d/koha-zebra-daemon, it shows: koha@linux:/> /etc/init.d/koha-zebra-daemon start koha@linux:/> /etc/init.d/koha-zebraqueue-daemon start Starting Zebraqueue Daemon /etc/init.d/koha-zebraqueue-daemon: line 26: daemon: no se encontro la orden koha@linux:/> Also for innserv /etc/init.d/koha-zebra-daemon, it shows: insserv: warning: script 'koha-zebraqueue-daemon' missing LSB tags and overrides insserv: warning: script 'koha-zebra-daemon' missing LSB tags and overrides Neither the cronjob "* * * * * /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -a -b -z" is working. I previously installed idzebra, idzebra-devel and idzebra-doc. What could be happening? Thanks in advance. Regards, Oscar

3 5

Koha Ubuntu server on an Apple server network
by Joe Ellis 05 Feb '10

05 Feb '10

I need someone knowledgeable about networks to check my thinking on a problem I am having. I installed Koha using a Live CD on a Macintosh Mini running Ubuntu 9.1 server for a small private school library. The school uses an Apple server for their school network, I believe it's running Apple's OS 10.4 server software. When I connected the Mini into the school's ethernet network it obtained a dhcp address (192.168.1.60). I entered this address into the Librarian's browser at her disk and got the KOHA login page. But after entering the user name and password the browser couldn't load subsequent pages. I think it's because koha refers back to "localhost" to call scripts. To test this, I brought the Mini home and installed it on my network where I have OS 10.6 server running on another Mini and in fact saw the same result. I then entered the Ubuntu servers name and ethernet address into the DNS server as a sub-zone of my network and like magic, I can log on and run Koha fine. What I need to know is: Is the cure to my problem a simple matter of adding a sub-zone record in the school's DNS server record; or will doing that cause other problems. Any advice would be appreciated. Joe Ellis Canterbury, CT

2 1

Gource
by Colin Campbell 04 Feb '10

04 Feb '10

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.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

2 1

Future branch
by Galen Charlton 03 Feb '10

03 Feb '10

HI, I've started a 'future' branch in my librarypolice.com RM Git repository (gitweb http://git.librarypolice.com/?p=koha-rm.git;a=summary, git://git.librarypolice.com/git/koha-rm.git) where I will be sticking patches sent to patches(a)koha.org that are candidates for 3.4 and that pass my initial sniff test. This is a temporary thing to hopefully help Chris out as he gears up for 3.4, but if anybody is desperately curious to look at very new and shiny post-3.2 stuff, that branch will be one place to look. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

1 0

Bug squashing session 2/10
by Galen Charlton 03 Feb '10

03 Feb '10

Hi, I'm calling a general bug squashing session all day on Wednesday, 10 February for us to hack on Koha 3.2 and fix bugs. Please join us on #koha (server irc.katipo.co.nz) for the festivities. Virtual pizza is on offer - don't miss it! Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

1 0

Koha 3.2 alpha tarballs available for download
by Galen Charlton 03 Feb '10

03 Feb '10

Hi, Tarballs of Koha 3.2 alpha are now available for download. Two versions are available; the first is a compact version that includes the PO files for translations but doesn't expand them into koha-tmpl, while the second version is the traditional full package that includes every language. Because the full package is ten times larger than the compact one, please download the compact one unless you absolutely require the full version with the translations already expanded. Compact, preferred distribution: http://download.koha.org/koha-3.02.00-alpha.tar.gz (the package itself) http://download.koha.org/koha-3.02.00-alpha.tar.gz.MD5 (checksum) http://download.koha.org/koha-3.02.00-alpha.tar.gz.MD5.asc (signed checksum) http://download.koha.org/koha-3.02.00-alpha.tar.gz.sig (signature of tarball) Version with all translations expanded: http://download.koha.org/koha-3.02.00-alpha-all-translations.tar.gz (the package itself) http://download.koha.org/koha-3.02.00-alpha-all-translations.tar.gz.MD5 (checksum) http://download.koha.org/koha-3.02.00-alpha-all-translations.tar.gz.MD5.asc (signed checksum) http://download.koha.org/koha-3.02.00-alpha-all-translations.tar.gz.sig (signature of tarball) In order to expand all translations from the compact package, after expanding the tarfile, do cd koha-3.02.00-alpha/misc/translator ./install.pll Then run the normal installation process. To expand a particular language, e.g., fr-FR, do cd koha-3.02.00-alpha/misc/translator ./install-code.pl fr-FR As a reminder, as with any alpha release, this is not recommend for use in a production setting. To report bugs in the alpha, please visit http://bugs.koha.org/. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

1 1

3.2 alpha tagged in Git
by Galen Charlton 03 Feb '10

03 Feb '10

Hi, I have tagged v3.02.00-alpha in Git, thereby kicking off the alpha period for 3.2. The corresponding DB revision is 3.01.00.111; I'll switch the DBrev to 3.02.00.000 for the beta. I will prepare a tarball tomorrow. At this point, 3.2 is feature complete and development should now be in pure bugfixing mode. Only the following types of patches will be accepted for inclusion in 3.2, starting now: * bugfixes * translations, including a mechanism to translate the new system preference editor * documentation improvements * necessary forward ports to preserve enhancements that were added to 3.0.x but which were not submitted to HEAD. I reserve the release manager's prerogative to bring in a few more minor enhancement patches that have already been submitted, and also reserve the right to add in one more enhancement I promised a library - permitting bibs to be cataloged without requiring any use or generation of authority records. However, if that should prove too unstable, I will not consider that last enhancement a blocker for the general release of 3.2. At this point, my criteria for moving to beta are as follows: * all HEAD and 3.2 blocker bugs are resolved, recategorized, or intentionally targeted for 3.4. * we have proof of a clean upgrade path from 3.0.0 to 3.2.0. * we have proof of a clean upgrade path from 3.0.5/6 to 3.2.0 - because of the numerous functionality enhancements in the 3.0.x series, this upgrade path is definitely distinct from the path originating in 3.0.0. * we have a completely clean pass of all test cases on (at least) Debian Lenny. Regarding management of branches in git.koha.org repository, I intend to start a 3.2.x branch and have bugfixes patches flow from HEAD to 3.2.x. I recommend that patches meant for inclusion in 3.4 be applied to a new 3.4-future topic branch, but leave final word on that up to Chris. Translators can consider a soft string freeze to be in effect - string changes to fix en-US typos will be accepted, but by and large strings should now be stable. I'm working on full release notes, but notable improvements in 3.2 include but are not limited to: * A revamped acquisitions module * An improved system preference editor * Improved patron card and item label creator * email checkout slips * branch transfer limits * support for Syndetics, LibraryThing, and Babeltheque enhanced content * improvements in Koha's ability to express circulation policies As with any alpha release, 3.2-alpha is *not* recommend for use in a production environment. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

2 1

Receiving serials item: customize item subfield population
by Christopher Curry 02 Feb '10

02 Feb '10

Hello everyone. A few questions about serials: I'm working on getting the serials module working correctly (or at least limping along). When receiving a new item from within a subscription record, some data is automatically generated in the item record. The call number is applied (as defined in system preferences "itemcallnumber") and "serialseq" ( from serialitems table) is inserted into $v - Cost, replacement price. The latter is obviously a mistake, and is easy enough to fix by editing line 73 of /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/serials/serials-edit.tmpl, replacing "v" with "h" to populate $h - Serial Enumeration / chronology with "serialseq" instead. <http://pastebin.com/m4e03ad68>function unHideItems(index,labelindex, serialId) { subfield = document.getElementById(index); subfield.style.display = 'block'; label = document.getElementById(labelindex); label.style.display='none'; // Prefilling 995$v with issue number // Getting item id itemid = $("fieldset#" + index + " div.cataloguing_additem_itemlist div.items").attr("id"); // Getting subfield id subfieldid = "subfield" + itemid.substr(4) + "v"; // Setting text field $("#" + subfieldid + " input[type='text']").val($("#serialseq" + serialId).val()); } I was pointed to the following bug that deals with this issue: Bug http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3899 normal, PATCH-Sent, ---, nengard(a)gmail.com, NEW, Receive Serial Item Has Copy Info in Wrong Field However, I'm trying to do a more involved customization to populate $h with "publisheddate" from the serialitems table and append "serialseq" to the call number in $o. Any tips on how I can achieve this? I tried copying the js from above and changing the subfield to o and replacing serialseq with publisheddate, but this doesn't output the publisheddate field; it also overwrites the call number generated by system preferences, rather than appending to the end of it, so I guess something more sophisticated is necessary? In addition, $c, shelving location is missing from this form...I checked the MARC Bibliographic Framework and the code for the hidden field of 952$c is correct & it displays correctly when creating a non-serial item. Thanks for your time. -- Cheers, Christopher Curry Assistant Technical Librarian / Assistant IT Officer American Philosophical Society 105 South Fifth Street Philadelphia, PA 19106-3386 Tel. (215) 599-4299 ccurry(a)amphilsoc.org <mailto:ccurry@amphilsoc.org> *For technical support, please use helpdesk(a)amphilsoc.org <mailto:helpdesk@amphilsoc.org>* Main Library number: (215)440-3400 APS website: http://www.amphilsoc.org

1 1