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

Introducing Marc::Loader
by Paul Poulain 08 Feb '11

08 Feb '11

Hello, We are happy (and proud) to announce the release of MARC::Loader 0.001001 It's a small lirary that transforms a hash into a MARC record. http://search.cpan.org/~reiveune/MARC-Loader-0.001001/lib/MARC/Loader.pm Feedback is welcomed either here or directly at perl(a)biblibre.com We plan to release some/many other tools around MARC in the next months. They are tools we use internally for our migrations. Hoping that will be usefull for many ppl ! (you can send congratulations to Stephane D: That's its first cpan contribution ;-) ) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Save user visits in Opac
by Edisnel Carrazana Castro 03 Feb '11

03 Feb '11

I want to register in a table the user visits to the site after logged in. In wich place of the source code of Koha can I do that? I push the function to insert the visit in a page [in opac-user.pl] , but several insertions occur whenever this page is accessed. What can I do? Thanks

2 1

Vote for KohaCon 2011
by Nicole Engard 03 Feb '11

03 Feb '11

Hello all, I have published the official vote for the location of KohaCon 2011. The vote will remain open until the 17th of February (EST). Please enter one vote per person and rank your options with your most favorite as 1 and your least favorite as 4. If you won't go somewhere no matter what then don't vote for that location. Read the proposals before you vote: http://wiki.koha-community.org/wiki/KohaCon2011_Proposals Vote here: http://survey.web2learning.net/limesurvey/index.php?sid=15529&lang=en Thanks Nicole C. Engard Documentation Manager

4 4

trying to maintain our control numbers as biblionumber
by Linda Culberson 01 Feb '11

01 Feb '11

Our local perl guru has managed to load our control numbers into the biblio.biblionumber, biblioitems.biblionumber, and items.biblionumber, However, it isn't matching the biblioitems.marcxml field for the 999 subfield c. I'm assuming it needs to match. Right? -- Linda Culberson lculber(a)mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824

2 2

irc down ?
by Paul Poulain 31 Jan '11

31 Jan '11

Hi, It's probably already known, but IRC seems down. Side question: shouldn't we move to a wider irc server (like freenode) ? Wouldn't require katipo help to deal with problems. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

4 5

Using Unicode in Koha
by Prawesh Shrestha 31 Jan '11

31 Jan '11

Hi, I am from Nepal and using Koha Library Management System and very new to it. I want to use Nepali unicode to enter records in the system. Till now I know that its possible while researching on the net. However, eluded with details to make it work. How can I get the details to make it happen? With Regards, -- Prawesh Shrestha Project Engineer --------------------------------------------- Young Innovations Pvt. Ltd. GPO 8976 EPC 241 Pulchowk, Lalitpur, Nepal Tel: +977-01 2291892 http://yipl.com.np info[at]yipl[dot]com[dot]np ----------------------------------------------------

3 2

Development workflow
by Paul Poulain 31 Jan '11

31 Jan '11

Hello koha-devel, The more time passes, the more I think we have a workflow for Koha development that does not work correctly/efficiently/fluently. The rule we have is: * create a branch for the feature * file a bug for it * submit your branch to koha-patches ML * the RM checks that everything apply smoothly on master & ask for QA * someone signs-off the branch/patch * the RM merge the branch. For the maintenance branch, this workflow is perfect and must be secured more and more to avoid any regression. As I see it, there is always someone that can find time to sign-off a patch or 2. As ppl have system live with it i'm sure it's cricital for many ppl to check & double check ! But for the next release/unstable branch this workflow does not work well. Here is a single line of something owen said on the chat today: <owen> paul_p: I would much prefer to be testing your stuff today, but other stuff is taking precedence. God knows i'll be forever thankfull to owen for the work he does. But this sentence reveals something: for most of us, there is always "other stuff taking precedence" :\ BibLibre has submitted many new features 3 months ago. I tried to motivate ppl to get feedback & sign-off. I even have organised an IRC meeting ... where no one came. Those patches includes new features, and requires a lot of work to be tested. 2 weeks ago, I did the same for a bunch of small improvements (and I have many many more pending). Once again, no feedback, except for one very easy-to-test (new images) : signed-off by Nicole & pushed by chris in less than 24H! Those 2 minor events (with owen & nicole) made me realize that it's technically and functionnaly hard & long to test: rebase, drop database, install, file test cases, check the new features,... At KohaCon, liz tested some of those features and said "wow, great, I want this feature for my library !" (I don't remember what it was exactly). The problem is that liz is not a techie woman, and can't test patches by her own. For our images, it was easy for Nicole to test, no need to updatedatabase or anything complex, just reach the itemtypes.pl page check the images are here. Easy for a librarian ! Other point: dependancies between new features. Let me take an example: Templates on those devs relies on html::template. Chris is working on moving everything to Template::Toolkit. Once he consider it's ready, he should submit for QA, as for every new features. Suppose no-one sign-off. And suppose someone sign-off, there are 2 options: * move master to T::T when it's signed-off. What happends with other branches not merged ? they can't be merged anymore, they have to be rewritten. wow, I can't imagine that something we've submitted for QA 3 months ago has to be rewritten because no-one took care of it ! * wait until those branches are merged. Two major problems here: the release date won't be respected, and we have switched again to feature based release. Or 3.4 will be released on time, but won't contain many things all those great features that are live in all our libraries since months. The second problem is that other devs are on the way. They still rely on H::T as master is based on that. Switching to T::T will cause problems for those branches later. well, I think that none of those solutions is a correct one. I can take an other example: the analytics record feature may/will probably overlap functionnaly with the new features we have submitted for cataloguing (not sure, but i think so). Suppose our cataloguing branch is integrated in 2 weeks. it has been submitted 3 months ago. It means our indian colleagues will have to rebase & face problems to get their analytical record branch working. If our branch had been merged quickly, they would have had 3 more months to deal with it. Our actual workflow, causes a lot of overhead ! And -worst- I don't think it improves the stability & security: there are merge problems that are difficults to detect. It means that any test done on analytical records would have to be done again if our cataloguing branch is merged : more work, more pain. And the later a branch is merged, the smaller the time to find a problem. My main conclusion is that we are not a large enough community to deal with testing/validating/merging new features in a short timeline. So I think we must change the way we integrate new features. The general idea being: remove the sign-off lock on the workflow. Here is a proposal: Let's go back to the timeline: we plan to release a version every 6 months. We could have a window of, say 4 months. During those 4 months a feature can be included if : 1- the submitter provides something that applies on master (ie: it's technically valid) 2- no-one object in 2 weeks (or 3, or 4, or defined by the RM when the branch is submitted) It put more pressure on others to test quickly, and don't put pain on parallels/parallelizing developments. Once a branch is merged if there is a problem, then everybody should see it, and it will be fixed ! Then, for 1 month, any new feature can be applied only if a newly submitted branch is approved/signed-off (less than 2 months to detect a problem in a new feature is a must-have) Then, feature freeze, 1 month debugging and translating. I know it is a big change in the workflow, but the actual one is not working well, so, we have to find another one. I humbly request to have this question being put on the next irc agenda (which does not mean you should not also start a thread here, of course) PS: pls don't say i'm wrong and the workflow works well. Having branches submitted 3 months ago, getting no feedback, and planning to have a release in less than 3 months, can't be considered as something working well. Friendly. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

8 20

Zebra issues
by Tiago Murakami 30 Jan '11

30 Jan '11

Hi, I Installed Koha 3.2.2 by koha-common debian package and it works very well. But, when I restart the server, the zebra stop works. I try koha-start-zebra (instance) but don´t work Anybody can help me? -- Tiago Murakami Librarian Brazil

2 2

utf8 in labels pdf -- kernel of a solution
by Reed Wade 30 Jan '11

30 Jan '11

I was poking around at bug 2246 for some reason and thought it might be more fun to step back a bit. The result is a perl fragment that does the basic work of creating a pdf which has a barcode and text in Greek, Cyrillic, all the latins, Japanese, Thai, Hindi and Gujarati (I'm not conversant in most of those languages so I might have some silly mistakes there) all on one page. It uses PDF::API2 instead of PDF::Reuse. If you're curious, have a look at http://reedwade.net/koha/labels/ for the perl script and the pdf output. The enabling feature of interest is the ability in PDF::API2 to build a font from a set of ttf fonts and assigning different unicode code pages (or ranges) for each. It might be possible to rejigger C4/Creators/PDF.pm to use PDF::API2 instead of PDF::Reuse. This is something I predict I will not have time to pursue further anytime soon -- I'm hoping someone else might enjoy that? -reed

2 1

make test fails on BackgroundJob.t
by Koustubha Kale 28 Jan '11

28 Jan '11

Hi All, I am doing a dev install with a fresh git clone on a new machine. make test fails with following.. Test Summary Report ------------------- t/BackgroundJob.t (Wstat: 65280 Tests: 1 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 8 tests but ran 1. Files=99, Tests=6821, 53 wallclock secs ( 1.57 usr 0.24 sys + 26.95 cusr 2.46 csys = 31.22 CPU) Result: FAIL Failed 1/99 test programs. 0/6821 subtests failed. make: *** [test_dynamic] Error 255 Looking back on the make test output I see t/BackgroundJob.t ................... DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. t/BackgroundJob.t ................... 1/8 DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. Use of uninitialized value $timeout in pattern match (m//) at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Auth.pm line 606. DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480. OPAC Install required, redirecting to maintenance at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Auth.pm line 560. # Looks like you planned 8 tests but ran 1. t/BackgroundJob.t ................... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 7/8 subtests Can someone please tell me whats going on here? PS : And I also see a bunch of " DBD::mysql::db selectrow_array failed: Table 'kohadev.systempreferences' doesn't exist at /home/kk/kohaclone/blib/PERL_MODULE_DIR/C4/Context.pm line 480." lines in the make test output. I can login to the kohadev database with the credentials I am supplying perl Makefile.PL 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

2 2