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

What Debian is supposed to be used?
by Mark Tompsett 12 Dec '14

12 Dec '14

Greetings, I just started a fresh Debian Wheezy git install. I grabbed the latest Wheezy ISO from the Debian site. And after a "$ sudo apt-get install koha-perldeps koha-deps make", when I run "$ ./koha_perl_deps.pl –m –u" I get this: Installed Required Module is Module Name Version Version Required -------------------------------------------------------------------------------------------- HTTPD::Bench::ApacheBench 0 * 0.73 No Test::DBIx::Class 0 * 0.42 No Archive::Extract 0.48 * 0.60 No DBIx::Class::Schema::Loader 0.07025 * 0.07039 Yes Test::WWW::Mechanize 1.42 * 1.44 No -------------------------------------------------------------------------------------------- Total modules reported: 5 * Module is missing or requires an upgrade. DBIx::Class::Schema::Loader is a core function, and well, that's a mess to update. I've got perl 5.14.2 as far as I can tell. Are we really trying to force people to use Jessie? Is the version number required wrong? GPML, Mark Tompsett

2 1

Bug 10480 Framework plugins
by Marcel de Rooy 11 Dec '14

11 Dec '14

Hi all, Bug 10480 is about framework plugins in cataloguing and item editor. It became larger than planned. I included an advertorial in the first commit message :) Any help, feedback, test/signoff to get this further now is greatly appreciated. Thanks, Marcel

1 0

About greek support
by Fridolin SOMERS 11 Dec '14

11 Dec '14

Hie, I'd like to present the work done on Bug 11927 : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11927 We started this work during last HackFest with goal to propose a support of Greek characters in Zebra CHR indexing mode. One will say that ICU mode is recommended for non-latin languages, but the problem is that in the case of a mixed Greek+Latin catalogue, the transliteration of greek into latin is unwanted. In fact, a greek user wants to search greek records using greek characters. With ICU those characters will be transliterated and they may match latin records. Any people interested in testing is welcomed. I already apologize if something is obviously wrong. I do not speak greek but I've learned it a bit at school and it's a pleasure to use this fantastic language again. Best regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

2 1

Hackfest in Marseille = book your flights !
by Paul Poulain 10 Dec '14

10 Dec '14

Hello everybody, It's a pleasure to announce/confirm that the 2015 hackfest in Marseille will take place in March, 2nd-6th. It should be a great hackfest, with our RM Tomas, our QA Manager Katrin, 2 or 3 ppl from ByWater, 2 from PTFS-Europe, the BibLibre team, and hopefully a lot of others. ( including you ? ) If you want to join us, just send me an email (I'll add you to a gdoc that gives details about location, hotel, public transportation,...) -- Paul Poulain, Associé-gérant / co-owner BibLibre, expert du logiciel libre pour les bibliothèques BibLibre, Open Source software for libraries expert

1 0

Proposal for fund raising for Koha - to discuss/vote at December General Meeting.
by Brendan Gallagher 09 Dec '14

09 Dec '14

Hello All - After discussing with many of you within the Koha project for many years and countless times, I'd like to bring forth the idea of having a fund-raising organization for Koha. It's about time the project raised money to help meet the needs and goals of the community. This idea and concept can only be a strong option with the support and help of many of us in the community. We believe that we have great organization to stand behind this great proposal in Horowhenua Library Trust (HLT) as a non-profit-organization (NPO) to help manage the funds for the Koha community in the most responsible way (For the good of the community). Please read below for some of the ideas and thoughts - and I would like to bring to this to a vote at the next General Meeting on if we should all as a community move forward with creating a Koha-Fund to use towards and only towards Koha. These are just thoughts and ideas and we can all move forward and work on the details and rules and laws etc after we get a "YES LET'S RAISE MONEY HOWEVER WE CAN TO SPEND ON KOHA". http://blog.bigballofwax.co.nz/2014/10/09/kohacon-14-day-3-funding-the-koha… *Organization for Fund raising:* Currently the Koha project generates more patches for enhancements and bugs than the collective community has time to work on. There is a need to raise funds so that more resources can be purchased to accelerate development. All funds that are raised via the project are to be used for improvement in the project. Koha has become a large international free software and open source software project. There are many projects and needs for a project this large. Many of the responsibilities that are needed for the future need to be funded and can not rely on the volunteer hours of the many participants of the project. For example, the current number of patches to be tested far outnumbers the amount of volunteer hours that we as a project are able to put towards that. Also in the future there are many software fixes that need to be completed that need funding, which can not be expected to be led by the users of the project. The current method of development and fixes of the software are led by the funding from the users, I propose that we fundraise from within the community and external to the community for being able to solve many of these large un-met needs. The fund raisin entity should be a non-profit organization so that all donations are not taxed and if possible the donors can have tax-deductions (if that is applicable for your local tax laws). The goal of this fund organization is to gather many many small donations to lead to an effective pool of funds available to support Koha development. Some thoughts so far towards identifying the appropriate fund raising entity is using the Horowhenua Library Trust (HLT) (Which we now have the full support of and Joanne can fill us in more about that). *Governing board:* This new fund should be governed by a board. That board should be made up of volunteers, that are interested to continue/champion fund raising efforts for the Koha project. The most important aspect of any board member would be to introduce new avenues for pursuing donations. Ideally the board would be representatives from all around the world so that board members could lead fund raising efforts in their local regions. This board will also be responsible with managing the funds that are donated, and will look for recommendations from the general meetings in Koha. The board will also be responsible for reporting the status, funds available, and goals of the Fund during each general meeting. *Grants Committee:* The Board will establish a Grants Committee, with the purpose of making decisions about the allocation of funds to advance the work of the Koha project. Members of the Grants Committee may be members of the Board or other persons with suitable qualifications and experience as determined by the Board. The Board will determine a Charter for the Grants Committee that will describe the procedures to be followed to promote efficacy, efficiency, equity and transparency in the allocation of funds. The Board will publish at least annually the details of grants allocated with sufficient detail to ensure transparency. *Goals:* (These can all be adjusted based on recommendations from Koha Community) First goal should be to hire a person to complete sign-offs and only sign-offs for the community development process. Further goals will be decided in time and as funds increase. Board members will decide on future improvements with recommendations from the Koha community general meetings. Another longer term possibility - is that the fund can sponsor some community members for attendance at international conferences/hackfests, students for attending local KohaCons, and sponsoring schools/universities with leading 2 week Koha academy sessions for getting more people interested/involved in the Koha project. *Avenues for Fund Raising:* Donate money now button on the homepage of Koha - and code for that button will be made available for anyone to put that on their own home pages, etc. Reach out to all support companies that are listed on the Koha community website for donations to help seed the fund. Board members from around the world will be responsible for leading local/regional fund raising campaigns Board members will pursue and write grant proposals for alternative fund generation. Think Mellon grants here. This paper is presented to the community for endorsement of the idea, so that we can move forward promptly toward this goal. Let's definitely discuss during the December General Meeting and we can vote then or if the community decides - vote in January. This will only be a vote on YES move forward, NO do not do this (nothing about structure etc.). Regards, Brendan Gallagher, Bob Birchall and Paul Poulain

1 0

PDF::Reuse TTF glyph identifier bug?
by Christopher Nighswonger 09 Dec '14

09 Dec '14

Has anyone noticed or had reports of symptoms in their labels/patron cards like those described in this PDF::Reuse bug? I am wondering if the problem may be limited to the set of fonts the reporter was using. With Koha's variety of languages, I suspect the problem would have cropped up if it were rooted in P::R. https://rt.cpan.org/Ticket/Display.html?id=18691 Kind Regards, Chris

1 0

Re: [Koha-devel] Pending PDF::Reuse Release And Koha
by Chris Nighswonger 09 Dec '14

09 Dec '14

That's great! Thanks Mark. Kind Regards, Chris On Wed, Dec 3, 2014 at 5:41 PM, Mark Tompsett <mtompset(a)hotmail.com> wrote: > Greetings, > > With Robin’s DEB, I’ve successfully done steps 1 through 5. > > GPML, > Mark Tompsett > > *From:* Chris Nighswonger <cnighswonger(a)foundations.edu> > *Sent:* Wednesday, December 03, 2014 12:53 PM > *To:* koha-devel(a)lists.koha-community.org > *Subject:* [Koha-devel] Pending PDF::Reuse Release And Koha > > I have rolled a pending PDF::Reuse release which incorporates > several methods which I wrote to accommodate the label and patroncard tools > in Koha back in 2009. I had hoped these would be included in PDF::Reuse > before now; however, they were not. The module appears to have been > abandoned by the original author, and I was able to be listed as a > co-maintainer. > > I have tested these changes on Koha's current head, and they appear to > work fine. This is an official call for testing these changes prior to my > releasing the new version of PDF::Reuse. > > Since these changes directly affect Koha, they have the potential to > affect current and future stable installs. Below is a link to a dev release > of PDF::Reuse which contains the proposed changes. Attached is a patch > formatted against the head current at the time of this email. Please do the > following: > > 1. Upgrade PDF::Reuse to 0.35_01. > 2. Run Koha's non-DB dependent test suite. You should notice some > non-fatal warnings about the redefinition of one or two subs in PDF::Reuse. > This should not affect the functionality of the tools for the end user. > 3. Verify the functionality of the related tools. > 4. Apply the attached patch. > 5. Re-run Koha's non-DB dependent test suite. You should note no warnings > related to PDF::Reuse. > 6. Re-verify the functionality of the related tools. > 7. Reply to the list with any issue which arise. > > After we're happy with the changes, I will submit the attached patch to > Koha via normal channels for QA, etc. > > This conversation will serve as QA for the proposed PDF::Reuse release. > There are many things which could be different about the code in > PDF::Reuse. This release is not the time to deal with these, so please keep > it to show-stopping problems. There will be plenty of time to "fix" other > things later. (That said, feel free to send along any thoughts directly to > me.) > > Kind Regards, > Chris > > > http://backpan.perl.org/authors/id/C/CN/CNIGHS/PDF-Reuse-0.35_01.tar.gz > > > ------------------------------ > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > >

6 8

yaz-client malfunction?
by Waylon Robertson 09 Dec '14

09 Dec '14

ive indexed using the rebuild script, using a zebra config copied from koha 3 pre 2. indexing of 100 items went fine. using yaz-client, ive done a scan, to identify that records are in there... oddly i get numbers. f 1 gives me two hit, show 1 results in: Specified element set name not valid for specified database -- v2 addinfo 'marc'.. show 2, the same, show 3, says: Present request out of range whats wrong? Waylon

4 5

Fwd: Questionaire regarding Patron Privacy and Security
by Chris Cormack 07 Dec '14

07 Dec '14

Forwarded with Marshall's permission Would you be able to help me fill this out? Galen has already made a good start which I have pasted at https://etherpad.mozilla.org/YiC0J8efmw Also the Evergreen community are working on their response at https://docs.google.com/document/d/1RgTnQOITvm3B_yzBOTfAuPZgDZig7xQ3N7Euib8… Thanks Chris ---------- Forwarded message ---------- From: Marshall Breeding <marshall.breeding(a)librarytechnology.org> Date: 11 November 2014 02:55 Subject: Questionaire regarding Patron Privacy and Security To: Chris Cormack <chris(a)bigballofwax.co.nz> As you know, libraries are increasingly concerned with protecting the privacy of their patrons and in strong security. For an upcoming panel for CNI I have been charged with gathering data regarding how library management systems handle patron privacy and security. It would be great if I could have responses by November 21, 2014. Could you provide responses for the Koha? You are the one that comes to mind among those in the Koha community, but if there is someone else that you think should respond, please let me know. I really appreciate your help. I am interested in gathering some information regarding the current capabilities or options that systems offer today, looking forward to further progress in this arena toward more secure treatment of patron-related transactions. Given increasing concerns, I would expect that each company is working on providing a more secure environment. This data initially will be used for a briefing at the upcoming CNI Fall 2014 Membership Meeting, December 8-9, 2014: http://www.cni.org/events/membership-meetings/upcoming-meeting/fall-2014/pr… I also anticipate that this information would be helpful for other discussions, presentations, or reports. In addition to information provided by the developers of systems, I may also work with systems administrators of the various products for their perspectives on these security-related capabilities and options. I would greatly appreciate it if you could have your technical or product managers provide responses to these specific questions. It would also be helpful to have any additional comments or perspective whether these seem to be the best areas of concern regarding patron privacy, if there are alternative strategies that you are pursuing. I would also be interested to hear whether this topic has been raised also by your customers or users through enhancement requests or other product roadmap priorities. Does your online catalog or discovery interface: · Enforce encryption through SSL for all transactions involving patron activity · Offer the library an option to enable SSL for all transactions involving patron activity · Enforce encryption for specific pages or transactions involving patron details or login credentials · Offer the library an option to enable SSL for specific pages or transactions involving patron details or login details Does your client or interface for delivering functionality to library personnel: · Enforce encryption through SSL or other encryption mechanisms for all transactions · Offer the library an option to enable SSL or other encryption mechanisms for all transactions · Enforce encryption for specific pages or transactions involving patron details · Enforce Encryption for specific pages involving authentication of library personnel accounts · Offer the library an option to enable SSL for specific pages involving patron details · Offer the library an option to enable SSL or other encryption mechanisms for specific pages involving authentication of library personnel · Enforce encryption for transactions involving institutional financial data (acquisitions, patron fines, etc) · Offer the library an option to enable SSL or other encryption mechanisms for financial transactions How does your platform or system deal with the security of the storage of specific types of data: · Does your system store patron passwords or PINs as unencrypted text · Does your system store patron passwords or PINs as salted hash or similar mechanisms · Does your system encrypt patron details as they are recorded and stored? Are logs or other system files that include patron search or reading behaviors encrypted? Describe any other security measures in place that protect patron privacy as it is transmitted over local networks or the Internet from interception by any third party. One specific scenario that has been a topic of concern involves the presentation of e-book discovery and lending transactions via library catalogs or discovery interfaces. Describe any integration with third party organizations that could potential expose patron details, search, or reading patterns and measures that you have provided to strengthen privacy and security. Do the APIs allow or require encryption in requests or responses that include patron-related data? What limitations to security impact your system imposed by the APIs or protocols managed by external or third-part products? Would your company be interested in a standardized specification for the treatment of patron or financial data, similar to the way that PCI provides a compliance framework for e-commerce transactions? I really appreciate your help with this project. Please confirm that you will be able to respond and let me know if you have any questions or concerns. -marshall Marshall Breeding http://www.librarytechnology.org marshall.breeding(a)librarytechnology.org http://twitter.com/mbreeding http://www.linkedin.com/in/breeding http://scholar.google.com/citations?user=NnvfJ5cAAAAJ

5 5

Re: [Koha-devel] C4::Installer::PerlModules::version_info
by Chris Nighswonger 07 Dec '14

07 Dec '14

Forwarding to the Dev list. On Dec 7, 2014 4:02 AM, "Nigel Gourlay" <ngourlay(a)gmail.com> wrote: > > passing all=>1 into version_info returns undef > > would it be more sensible to return an arrayref of modules? > > --ngourlay

1 0