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

How to get CAS based Single Sign On working?
by Koustubha Kale 25 May '15

25 May '15

Hi All, I have a situation where we have a main website based on Joomla. This Joomla site uses CAS to authenticate users. We would like users ( who have already logged in to the Joomla site via CAS) to be able to follow a link to Koha site and be logged in automatically ( e.g. Single Sign On ). I have got simple CAS ( not proxy CAS ) working with Koha ( version 3.2.6 ) using the same CAS server as used by Joomla site. Still when I login to Joomla site with CAS, and then go to Koha and click on login and follow the CAS login link, I am asked to fill up CAS login information again. How can this be avoided by using CAS SSO? I have read through http://wiki.koha-community.org/wiki/SSO_CAS_improvements and am confused by the statement "Note: simple sso cas support (no proxy) has been done already by biblibre, is in testing and should be released in Koha 3.2" in there. Does this statement mean that SSO is possible with simple CAS? If yes how to set it up? If not, I have also read through bugs 6012, 5630 and the CAS Proxy examples. Frankly I haven't been able to figure out how I can achieve the above required functionality based on all the reading. Any help is much appreciated.. Another related query is, Is it possible to automatically create users in Koha once they have authenticated with CAS? Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

3 3

koha-3.00.00 make fails
by Rick Welykochy 28 Dec '13

28 Dec '13

Hi all, I have downloaded http://download.koha.org/koha-3.00.00.tar.gz and began installing it on Debian/etch (in a Linux vserver environment). 0. FINE: cd koha-3.00.00 1. FINE: perl Makefile.PL 2. FAIL: make : : : Manifying blib/man3/C4::UploadedFile.3pm Manifying blib/man3/C4::BackgroundJob.3pm Manifying blib/man3/opac::opac-dictionary.3pm Manifying blib/man3/serials::member-search.3pm /usr/bin/perl "-Iblib/arch" "-Iblib/lib" fix-perl-path.PL blib /usr/bin/perl "-Iblib/arch" "-Iblib/lib" rewrite-config.PL blib/KOHA_CONF_DIR/koha-conf.xml Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at rewrite-config.PL line 67. make: *** [blib/KOHA_CONF_DIR/koha-conf.xml] Error 255 Any ideas what went wrong and how to fix? Aside: there were a couple of other problems with this "out of the box" debian based install of Koha 3.0 which had to be fixed along the way, e.g. seven missing perl modules and libgd not found. I'll report on the entire process from unpacking to a running Koha/3.00.00 once I get to the end. cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor The manual said Windows XP/SP2 or better so I installed Linux.

4 5

tt style point
by Colin Campbell 26 Oct '11

26 Oct '11

Hi I noticed that in QA someone is changing tt constructs from [% IF variable %] to [% IF (variable) %] as style issues I think this is very bad style for the following reasons: You'll not see it in any of the documentation for tt either the perldoc, on the tt site or in the badger book. (and I've never seen it on any tt using project). It adds nothing (we hope) syntactically. My initial response is that as we are not using normal tt syntax, something "clever" or magic is going on here rather than a usual [% IF %] It detracts from readability. (ok slightly subjective but the environment already makes full use of the top row of the keyboard.) Whats its relation with the legitimate use of brackets e.g. to call vmethods in regexps [% IF variable1( variable2 ) %] The authors didn't require brackets around more complex boolean expressions [% IF variable == 0 %] why bring em back in for simple variables. Could it have unforeseen side effects (don't know but I don't want to spend time researching it) It confuses the reader of the code and the writer of subsequent code - 'should I use () no? when? why? It strikes me as weird (!!) In short I'm arguing for clarity... I realise that Chris bracketed things in the great template conversion but I think that was defensive programming when he couldn't rely on variable always being one. And we shouldn't be encouraging or enforcing others to use a peculiar idiolect rather than standard practice. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

11 24

Commentary on Paul's Koha 3.8 Release Manager proposal
by Ian Walls 05 Oct '11

05 Oct '11

Everyone, Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release Manager. The details of his document can be found here: http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38 I thoroughly agree that the time has come to start thinking beyond the next stable release, and on to Koha 4.0. Those of you who have seen either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know I'm very excited about the possibilities of where we can take Koha in it's next major iteration. However, I disagree with a couple of the details of Paul's proposal. The major disagreement is with the timeline. The proposal as it stands is to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8 releasing April 2012, and Koha 4.0 releasing Oct. 2012. I feel that going from Koha 3.8 directly to 4.0 is unwarranted. To my mind, there are many possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14 and so forth. This is supported by the actual database version numbers in Koha: the current release is actually 3.04.04; the zeros are squashed out for convenience. I would counter that, while we should continue releasing new features every 6 months on the 3.X line, Koha 4.0 should be defined by it's features. Paul's proposal calls several features to be key, including Solr integration, database abstraction, updated online help, improved authentication stack and automated tests. I agree that all these things are important and should be worked towards, but I'm not convinced they should be the sum total of the changes that define Koha 4.0 I would like to see the following in Koha 4.0: - arbitrary metadata formats (beyond MARC) - arbitrary biblio relationships - full support for authority records, including uploading through the GUI, automatic linking, "explode" searching and more - improvements to the borrower data structure (fewer pre-defined data fields, more flexibility) - separation of "receiving" and "payment" in acquisitions - serials import and export (MFHD, prediction patterns, etc) - many, many more things I think that the community should meet and discuss what features are both desirable and reasonably likely to be completed in the next few years (is there interest by libraries to sponsor these developments, or from developers to code it "for fun"?). Once a feature set is agreed on to "define" Koha 4.0, the developers of these features would meet to hash out what underlying structural changes would be required to make them happen. Hopefully commonalities could be found, so that the underlying structure could be developed in a way that accommodates multiple developments at once. Identifying these prerequisite changes early on would reduce the difficulties of rebasing developments, since we'd all be working off a similar set of base assumptions. It would also provide a reasonable basis for excluding or delaying developments that don't fit into the overall plan. Once the features were chosen and a framework for their development agreed upon, it would be time to code. The development and submission process would be the same as it is now (basing patches off master and submitting to the patches listserv and Bugzilla). As new features become ready, they would be incorporated into the time-based 3.X releases by the release manager for that particular cycle. This way, what works is made available, and what needs more time continues to be tested until it's stable for production use. Once all the agreed upon features were ready, it would be time to release Koha 4.0. Hopefully, that would be with 1-2 years, but there would be flexibility here. One of my other issues with the proposal was the "lightening" of Quality Assurance standards for the first 3 months of the 3.8 release cycle. If operating under the 1 year time frame for Koha 4.0 as outlined in Paul's proposal, this would seem necessary in order to get everything included in time. Unfortunately, while the next 3 months would be dedicated to clean up of features rolled in, there is never any guarantee of bug fixes being generated in a timely fashion. You cannot force people to write or sign off on bug fixes; we're all free agents here. So code that has not been rigourously tested could get in and stay in for a long time, long after 4.0 would release, because no one knows how to test it or fix it. However, if we operate under my proposed model, all code could continue to operate under the same quality assurance standards, and nothing that is broken or otherwise incomplete would make it in until it was ready. Releases would still come out every 6 months, even if a major development was inoperable, until that development could be completed. This has been a long email, so let me sum up. I think: - we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month cycles using the current community practices for feature inclusion - we should, as a community, meet and decide what features we want to define Koha 4.0 - the developers of those features should get together and come up with a unified plan for accomplishing them all, in a way that requires minimal rebasing - as new features become stable and tested, they should be folded into the 3.X line until all the features defined as "Koha 4.0" are ready - Once all the agreed upon features are complete, Koha 4.0 is then released. I've already gotten some feedback on this in today's Koha IRC meeting, but I'd very much like to hear what the rest of the community thinks about this, particular in relation to Paul's proposal for 3.8 Release Manager. Our time is limited for discussion, as the election time draws near, but hopefully I've made my thoughts clear enough for a dialogue to get started. Please let me know if I've been at all unclear. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

3 6

Re: [Koha-devel] tt style point
by Mason James 02 Oct '11

02 Oct '11

reply inline On 2011-09-20, at 8:17 PM, LAURENT Henri-Damien wrote: > Le 20/09/2011 04:33, Mason James a écrit : >> >> i'm not suggesting existing code will be rejected if its not formatted to the new perltidy style, thats too painful!! >> >> i simply suggest we start the process by agreeing on a standard, and go from there... >> > it is always the same question : who will decide we can decide now the koha-devel mailing-list, or as a topic for the next Koha IRC meeting > and who will process > the files ? not sure on that bit yet :p , lets agree on a Perl style standard first, then decide who/how/when later >> the current perltidyrc file *is* just an idle file, because it was never agreed upon... >> >> lets agree on a formatting style, and make the spec official. then it wont be just an idle file :) > When ? some things has already been committed. And things donot get > improved. when should we agree on a formatting style,? how about now... >> >> >> i'm strongly against having old code 'perltidy-fied' in huge commits, because i know the problems that causes with tools like 'git-blame', etc > I am not. > git blame may be useful, but code readability is a much serious issue. > I think that some decision should be not only discussed but also taken, > announced and applied. ah, ok that would be the next thing to discuss, after we all voted on a Perl formatting style :) >> >> so i suggest we slowly and gently correct small blocks of existing code - as we work on it >> and the formatting in new Koha releases will start to become more consistent > How can you enforce PBP or any formatting on part of a file ? its easy using vim!, and surely possible for all other respectable editors > If previous file indentation is broken, you will just add broken things. nope, perltidy corrects the indentation perfectly, without any syntax errors > If there is some magic I don't know please tell me. yes, there is some magic :) i added this to my .vimrc file, now F4 tidys a selected block of text :) fyi: i use this method many times a day ---------------------------------------- map <F4> <Esc>:%! perltidy<CR> ---------------------------------------- described here... http://www.modernperlbooks.com/mt/2009/10/from-novice-to-adept-cleaning-up-… i very rarely run perltidy on a whole Koha file, instead i run it *carefully* on small blocks of messy historical Koha code as i see them >> i personally don't mind *what* that standard is... i just want an agreed upon standard >> but hey... --PBP get my vote by a mile! >> > I don't know what ranty mean. "To speak agressivly about somthing. or to take your own tangent about a subject and talk for a long time in a passionate manner" :) http://www.urbandictionary.com/define.php?term=rant > But don't be mistaken, all I want is a change for better. The fact is > that ppl are working on the same code ignoring what other ppl are doing. > And with the need to revamp more and more things for security, > sustainability and performance issues. I think that it should be shared, > discussed, stated, worked in groups and done. yes... but thats a separate issue to what Perl formatting style to use for Koha so remember, there's a few who/when/how issues to discuss here... but can we at least agree on a Perl formatting style, for a start -PBP++ ;) cheers, Mason

3 3

Adding rel_3_8 to bugzilla ?
by Paul Poulain 27 Sep '11

27 Sep '11

Hello, As we've now feature frozen, shouldn't we add rel_3_8 for new features submitted on bugzilla ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 2

Koha 3.4.5 is now available
by Chris Nighswonger 27 Sep '11

27 Sep '11

It is with pleasure that I announce the release of Koha 3.4.5. The package can be retrieved from: http://download.koha-community.org/koha-3.04.05.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.05.tar.gz.MD5 http://download.koha-community.org/koha-3.04.05.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.05.tar.gz.sig Release notes for 3.4.5 are below. Come and get it! RELEASE NOTES FOR KOHA 3.4.5 - 26 September 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.4.5 can be downloaded from: http://download.koha-community.org/koha-3.04.05.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.4.5 is a bugfix/maintenance release. Highlights of 3.4.5 ====================== 4122 blocker WebBasedSelfCheck doesn't control anything 6704 critical merging records cuts off fields at quotation marks 6727 critical can't import frameworks 6750 critical Guarantor search broken on translated templates 4419 major Cannot change module for notice templates 4966 major no way to finish receiving 6318 major fields missing when editing a layout 6351 major Cannot delete library-specific circulation rules 6620 major Sip Server Output may be buffered 6651 major koha-upgrade-to-3.4 fails when multiple instances are present 6665 major advancedMARCeditor preference not functioning 6765 major Enable correct checksums for UTF-8 encoded data 6834 major $template->{param_map} is deprecated with the introduction of Template::Toolkit 6841 major A member with cataloging permissions cannot change branches (when independent branches is set on) Bugs fixed in 3.4.5 ====================== 520 Displaying ALL records 1016 Crashed mySql tables 1220 validation problems and usability in lynx 1664 Installer not picking up missing perl modules 2539 kohaspsuggest is deprecated, notes outmoded 2775 Test suite failing after change to cache sysprefs 2891 Cannot manually enter dates in some report forms 4866 Optionally enable Change event for item plugins 4868 Improve controls for cloning and deleting MARC subfields 4877 Create and update the manual pages for the koha-* scripts. 5028 Remove references to catmaintain.pl 5252 Emails & Phones On Patron Add/Edit form 5498 Standardize markup and style of pagination menus 5524 Can't delete list from second page of results 5602 Improve configurability of package building scripts 5866 At larger hold volume, waitingreserves.pl for all libraries times out, can cause generalized slowness 6121 waitingreserves: branchname instead of branch code 6129 ISSN url param for serialssolutions.com 6256 Many bib1 attributes missing 6275 Automated backups of data and config 6368 unimarc_field_4XX plugin does not work with new templates 6431 New Circulation modules for Hourly Circulation 6458 incorrect parsing result in translation processing 6479 Encoding problem in "recievedlist" when the numbering formula contains utf-8 characters 6516 koha-create makes assumptions about borrowernumber of staff user 6517 koha-create wants "use database" in DEFAULTSQL 6528 Cataloging search issues - Holdings not displayed in location column 6538 help on letter.pl is incorrect 6540 Add more options to koha-create 6555 only 10 lists in pull down when adding from a bib record 6562 Reserve request generates unnecessary runtime errors 6595 Add German translation for purchase suggestion mails 6602 Reports dictionary doesn't properly recognize text columns 6640 Template errors in defining default variable values causes information not to be displayed 6652 Zip showing in funny place on libraries admin 6656 Default sort preferences ignored on advanced search 6662 sort options in opac are dewey specific 6677 patron stats still refers to debarred 6695 Layout of patron category add/edit form slightly broken 6696 New category button broken when no categories defined 6712 Remove memberofinstitution markup from templates until it can be completed 6715 xmlControlField.js always fetches the value_builder xml files in the "en" directory. 6723 allow framework import with CRLF 6724 Holds Ratio does not allow decimals 6726 When SMS is enabled the messaging table is misaligned 6728 Table sorter for receiving acquisitions 6732 Missing Title for Manual Invoice 6733 printing routing list sends you to main serials page 6744 Acknowledge the actual es-ES translators 6747 Additional check in opac-export 6753 Markup corrections and improvements for label export window 6754 Improve breadcrumbs on lists pages 6768 Two unused include files can be removed: error-top.inc and error-bottom.inc 6791 editing list with apostrophe loses text 6794 Broken toggle in member-flags in ie 6822 RIS export problem in opac-export.pl with parsing the MARC 6829 Remove two warnings for opac-MARCdetail 6860 syndetics covers not showing on search results or shelf browse 6863 covers missing from shelf browse for various services System requirements ====================== Changes since 3.2: * Template::Toolkit Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the english version of the Koha manual is available: http://koha-community.org/documentation/3-4-manual/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.4 is Release Manager: Chris Cormack <chrisc(a)catalyst.net.nz> Documentation Manager: Nicole C Engard <nengard(a)gmail.com> Translation Manager: FrÃ©dÃ©ric Demians <frederic(a)tamil.fr> Release Maintainer (3.2.x): Chris Nighswonger <cnighswonger(a)foundations.edu> Release Maintainer (3.4.x): Chris Nighswonger <cnighswonger(a)foundations.edu> QA Manager: Colin Campbell Credits ====================== We thank the following individuals who contributed patches to Koha 3.4.5 Tomas Cohen Arazi Alex Arnaud Steven Callender Colin Campbell FrÃ©dÃ©rick Capovilla Chris Cormack Christophe Croullebois FrÃ©dÃ©ric Demians Nicole C. Engard Magnus Enger Katrin Fischer Srdjan Jankovic Janusz Kaczmarek Ulrich Kleiber Henri-Damien LAURENT Owen Leonard Chris Nighswonger Maxime Pelletier Paul Poulain Liz Rea Marcel de Rooy Salvador Zaragoza Rubio Robin Sheat Ian Walls Ward van Wanrooij Brett Wilkins We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches(a)lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix releases) is 3.4.x. The next major feature release of Koha will be Koha 3.6.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini

1 0

Official Koha Newsletter : Volume 2, Issue 9: September 2011
by Daniel Grobani 26 Sep '11

26 Sep '11

[Below is the text of the newsletter. For active links and a more readable format, please visit http://koha-community.org/koha-newsletter-volume-2issue-9-september-2011] Official Koha Newsletter (ISSN 2153-8328) Volume 2, Issue 9: September 2011 Edited by Daniel Grobani, Koha Community Newsletter Editor. Please submit news items to danielg.koha(a)gmail.com. Table of Contents Koha Developments Koha 3.4.5 Release Delayed Koha 3.6 Feature Freeze Koha 3.8 Roles New Database Schema Site Koha Community New Koha Libraries Community Gossip Past Koha Events Global Bug Squashing Day #4 September General IRC Meeting Upcoming Koha Events Global Bug Squashing Day October General IRC Meeting KohaCon11 KohaCon12: Voting on Proposals Koha Developments Koha 3.4.5 Release Delayed Chris Nighswonger, Koha 3.4.x release maintainer, reports that the release of Koha 3.4.5, originally scheduled for 22 October, has been delayed a few days. Koha 3.6 Feature Freeze by Chris Cormack Why is it so cold in here? We are in feature freeze leading up to next month’s release of 3.6.0. No new features submitted will be considered for that release. Anything that is already in the needs-signoff queue is still OK, though. But get testing, signing off, etc. The next deadline is string freeze, coming up on 8 October, and the more we get signed off by then, the better. Koha 3.8 Roles by Paul Poulain A reminder: Everyone who plans to volunteer for a position in Koha version 3.8 is welcome to file his/her name on the wiki page: http://wiki.koha-community.org/wiki/Roles_for_3.8. The specific module maintainers and release maintainer positions are (desperately) empty. Elections will be held in October. New Database Schema Site by Chris Cormack For everyone who writes reports, or develops on Koha, we have a new site available to help: http://schema.koha-community.org. This, combined with the work Nicole has been doing to add comments, allows for nice information like this: http://schema.koha-community.org/tables/biblio.html. It is up to date with master (what will be 3.6.0 on October 22), and will continue to track master thereafter. Thanks to Robin for rediscovering SchemaSpy and to Nicole for adding comments. Koha Community New Koha Libraries Arcadia University (via ByWater Solutions) College of the Redwoods (via ByWater Solutions) Ducks Unlimited Canada (via Equinox Software) Mississippi Department of Archives and History (via ByWater Solutions) New Zealand State Services Commission (via Catalyst IT) New Zealand Treasury Department (via Catalyst IT) Community Gossip Thatcher Rea joined ByWater Solutions as their Lead Support Specialist. Paul Poulain of BibLibre is convening a working group to address integrating solR and a re-implementation of Zebra into Koha 4.0. Vandana Singh of University of Tennessee Knoxville is seeking people to interview for a study comparing technical support of open source ILSs and proprietary ILSs. For more info, or to participate, see http://www.facebook.com/pages/OSS-Lib-Tech/111245305579507. Bones 1: Nicole Engard is recovering from hip replacement surgery. Bones 2: Koustubha Kale is recovering from a broken arm and wrist. Six Koha libraries are jointly sponsoring development of customizable print slips. Past Koha Events Global Bug Squashing Day #4 Global Bug Squashing Day #4 occured on 2 September. For more info, see http://wiki.koha-community.org/wiki/2011-09-02_Global_bug_squashing_day. September General IRC Meeting The September general IRC meeting was held on 7 September 2011. For more info, including links to the minutes, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_September_2011. Upcoming Koha Events Global Bug Squashing Day by Magnus Enger String freeze for 3.6 has been set to 8 October 23:59 UTC. I’d like to propose a Global bug squashing day for October 7th, as a last, concerted effort to get as much as possible from the “needs signoff” queue into 3.6. Details are here: http://wiki.koha-community.org/wiki/2011-10-07_Global_bug_squashing_day. Happy squashing! October General IRC Meeting The next general IRC meeting is 5 October 2011 1000 UTC. Here’s the agenda as of publication time: Introductions Update on Roadmap to 3.4 Update on Roadmap to 3.6 Vote for Roles for 3.8 KohaCon2011 Results of the Vote for KohaCon2012 Global bug squashing days Actions from General IRC Meeting, 7 September 2011 Miscellaneous Follow-up on koha-devel thread “bugzilla & default assignee”. suggestion made : add koha-devel(a)lists.koha-community.org as a possible assignee for bugs the default assignee don’t want to handle. Adopt this proposition? any other proposition? Gamification and Open Badges Set time of next meeting For more info, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_5_October_2011. KohaCon11 KohaCon11 will be held 31 October 2011 to 6 November 2011 in Thane, India. For more info, see http://wiki.koha-community.org/wiki/Category:KohaCon11 or http://kohacon11.vpmthane.org/ocs/index.php/k/k11. KohaCon12: Voting on Proposals by Magnus Enger The deadline for proposals for KohaCon12 ended on 1 September, and we have two proposals: software.coop and other tbc: Edinburgh, Scotland, UK Washoe County Library System: Reno, NV USA Details on the proposals are at http://wiki.koha-community.org/wiki/Proposals_for_KohaCon12. Nicole Engard has created a survey where folks can vote on their preference: http://survey.web2learning.net/limesurvey/index.php?sid=63529. The deadline for voting is 1 October.

1 0

re-introducing myself
by Greg Barniskis 26 Sep '11

26 Sep '11

Hello all, Some of you may recognize my name from the context of my long-time employment at a leading Wisconsin public library system. My employer has a contract with LibLime to develop LibLime Koha in ways specific to their business needs as a very large public library consortium. That's not really central to my job description there; I am a technology integrator, a generalist for a pretty wide and deep tech stack that happens to include LibLime Koha. I mainly get to watch, and sometimes assist in integrating the outcomes of that contractual development process. I only bring up that subject so that I may acknowledge it as loosely relevant in an environmental way (I know some of what I know because of where I work), but then to really emphasize how little my employer or its vendor relationship has to do with my reasons for writing this today, or for that matter anything else that I may write in the future. Just to be clear, when I'm writing things or contributing code from my personal gmail address, I'm doing it on my own time, on my own equipment, for my own reasons in my own context as an informed private citizen. Anyway, I have decided that, all forkiness aside, I would like to contribute code and other content to the Koha community via the community's selected tools for bugs, wiki, git, etc. To that end I have registered for accounts on k-c bugs and wiki, and have for a long time now been subscribed to the devel and patches email lists (I sometimes even grok what passes on them =). I've been using Perl as an all-purpose utility glue for quite a few years, doing mostly smallish scripts for unix and windows systems management. My most celebrated Perl achievement: low-jacking my employer's old Sun server print spool in order to digitally shred its venerable but verbose Dynix Classic ILS greenbar paper reports directly into Excel spreadsheets on no paper. The customers seemed to really like that trick. In more recent years, I've also been using Perl a lot with HTML::Template and with DBI for lots of different Access, MySQL and Postgres contexts, all on relatively small scales. I don't really know any Template::Toolkit yet, but I have the ora book for it and expect the transition won't be too traumatic. I'm new to Git, but have read enough of the relevant Koha wiki pages to think that I have now correctly checked out the current development HEAD to play with, formatted my first patch file, and eventually even got that first patch emailed to the patches list (I think). I expect I'll be limiting my contributions to low hanging fruit in the short term, until I get a bit more comfortable with Git and Koha internals. For now, I just wanted to say hi, and that I plan to begin submitting small bug fixes soon and various enhancements someday, and that I'm doing so from a context strictly unrelated to my employment. Thanks to those who helped me get started on irc today (and to those who will undoubtedly have to clean up my Git newbie mistakes tomorrow =).

2 2

2011-10-07 Global bug squashing day - 3.6 String Freeze Sprint
by Magnus Enger 26 Sep '11

26 Sep '11

Dear Community! String freeze for 3.6 has been set to 8 October 23:59 UTC. I'd like to propose a Global bug squashing day for October 7th, as a last, concerted effort to get as much as possible from the "needs signoff" queue into 3.6. Details are here: http://wiki.koha-community.org/wiki/2011-10-07_Global_bug_squashing_day Happy squashing! Magnus Enger

1 0