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

Re: [Koha-devel] [Koha] Koha Virtual Appliance 3.6 Now Available For Download
by Muhammad Abdullah 02 Dec '11

02 Dec '11

Thanks alot for this. Been using it for awhile now, very useful appliance. This upgrade should make it more robust, now that it is running on Debian 6. On Thu, Dec 1, 2011 at 10:48 PM, Kyle Hall <kyle.m.hall(a)gmail.com> wrote: > Hey All, > I just wanted to let everyone know that I've updated my virtual > appliances to 3.6. This is a complete rebuild using Debian 6.0 ( > Squeeze ) instead of Lenny. I also added a bit more to the Koha > Console program for automatically fixing the networking issue that > crops up on virtual machines from time to time. Enjoy! > > http://millruntech.com/koha/koha-virtual-appliances > > Kyle > > http://www.kylehall.info > Mill Run Technology Solutions ( http://millruntech.com ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > _______________________________________________ > Koha mailing list http://koha-community.org > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha

2 1

[Bug 7310] Improving permissions on lists (virtual shelves)
by Marcel de Rooy 02 Dec '11

02 Dec '11

Hi, If you have a suggestion on report 7310 about lists management, please respond. Following up on report 7281 (hide lists from OPAC) I am sending the following question to the ml in order to improve lists management: 1 Who should be allowed to delete a public [closed] list (category 2 only!) or add/remove items from that list? (Note that removing all items from a list is more or less the same as removing the list at once.) My answer would be: the owner should only be allowed to do that in the OPAC. A user in the staff client may do it too. [Currently, any opac login can delete the list. This is a bug!] 2 Who should be allowed to delete an public open list (category 3 only!) or add/remove items from that list? My answer would be: any login from OPAC or staff. It should be made clear that creating such a list is really at your own risk ;) Currently, a user in the opac cannot create an open list. (Is that a bug?) 3 Proposed revisions to lists management: If we solve points 1 and 2, management of lists comes down to all or nothing. You can do everything with an open list, but if you are not owning a closed list, you can't do anything. Would it be useful to have something in between? Like deleting your own added items from a closed list (we could save borrowernumber in virtualshelfcontents)?? Or give the owner of an open list the choice between full access for other logins, adding items only or deleting own added items? What do you think? Marcel

1 0

Code4Lib Scholarships available
by Galen Charlton 01 Dec '11

01 Dec '11

Please excuse the cross-posting. Equinox Software is offering 2 scholarships to the code4lib conference in February. The scholarships will reimburse travel and accommodation expenses up to $750.00 USD for a full-time employee from public libraries using either Evergreen or Koha to attend the Code4Lib Conference in Seattle, Washington, USA, from February 6-9, 2012. The awardees will also receive free registration to Code4Lib. ELIGIBILITY The applicants must be presently working in a public library that is currently using or is actively committed to moving to either Evergreen or Koha as their ILS. The applicants must indicate any amount and source of additional funding which, combined with the Scholarship, will permit them to cover their expenses to attend the Conference. (This will not reduce the amount of the award.) Preference will be given to underfunded libraries or libraries in budget crisis. DEADLINE FOR APPLICATION December 31, 2011 The email application should include a current resume, including all contact information, education, and experience, along with an essay as described below. The applicants will write up to 750 words of narrative in English to address the following: • Description of the library’s mission and commitment to open source solutions • How attendance may benefit the applicant • How the applicant intends to share the benefit of the experience with colleagues • Description of funding constraints, budgetary limitations, or travel/hiring freezes pertinent to the applicant’s situation APPLICATION ADDRESS: Please send resumes and essays to Grace Dunbar before December 31, 2011 by email attachment to c4lgrant(a)esilibrary.com NOTIFICATION: The successful applicants will be notified by January 5, 2012. Feel free to re-post this announcement and/or our press release (http://esilibrary.com/esi/newsitem.php?id=2182) Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

1 1

Koha Virtual Appliance 3.6 Now Available For Download
by Kyle Hall 01 Dec '11

01 Dec '11

Hey All, I just wanted to let everyone know that I've updated my virtual appliances to 3.6. This is a complete rebuild using Debian 6.0 ( Squeeze ) instead of Lenny. I also added a bit more to the Koha Console program for automatically fixing the networking issue that crops up on virtual machines from time to time. Enjoy! http://millruntech.com/koha/koha-virtual-appliances Kyle http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org )

1 0

Version numbering, starting a discussion
by Paul Poulain 01 Dec '11

01 Dec '11

Hello, There are 2 questions in this mail: === DB update numbering === The bug 7167 will probably pushed in a few days, and it's a new way to handle updatedatabase. They will be non-linear, meaning update 1 can be applied after update 2, and before update 3. The previous numbering pattern, made from 4 parts (3.06.00.001 for example) was made to handle release version + DB version. The 1st update for version 3.8.3 would be called 3.08.03.001 for example. With the new scheme, there's no need to have a so complex numbering system. We could just number our databases update 1, 2, 3, ... What do you think of this idea ? Why should we keep the previous numbering scheme ? Any other suggestion ? === Koha version numbering === This second topic is a harder one. So please, don't jump on this and forget the 1st one. I was wondering why/if we should continue with our 3.6 / 3.8 / 4.0 / ... numbering. This question arise because some of our libraries have problem understanding what will be the next version number. It will be 3.8. And the next one ? 3.10 or 4.0, depending on Solr or any other major change being applied. And maybe, in april, Solr will be pushed, in this case it would be called 4.0 (I don't think it will, but it's just for the example) That's quite unclear for external people. That's why I was wondering : why not use another, totally new numbering schema. The "koha april 2012" could be called 2012.A, or 12.A, or 12.1. The "Koha October 2012" could be called 2012.B, or 12.B, or 12.2 (or any other scheme, I'm open to any proposal, including not changing, I just want to share the idea. - we should just avoid Ubuntu numbering patter: 12.4 / 12.10 would be a bad idea, as Ubuntu is released in april and october, like Koha. So it may be confusing -) What we need is a number for each monthly maintainance release. But for the rest, what about changing everything in our numbering method ? There's also another interest with this idea: if we change completly our numbering, we would not seem to be "late" against another software that is currently numbered 4.8 (i've been in Greece recently, for a talk in academic libraries. I saw that there is a big confusion here, and changing the numbering would also help I think). Let's start the discussion, but please, on both topics, that are related but different: we could change #1 and not #2 ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Fresh install 3.6.1
by Paul 30 Nov '11

30 Nov '11

Just built a new server (Ubuntu 11.10) and preparing it for a fresh install of Koha 3.6.1 -- we're trying to take all precautions ahead of time, so ran the Perl dependencies script: paul@nelson:~/koha/koha-3.06.01$ perl koha_perl_deps.pl -m -u [Wed Nov 30 09:07:17 2011] koha_perl_deps.pl: could not find ParserDetails.ini in /usr/local/share/perl/5.10.1/XML/SAX Installed Required Module is Module Name Version Version Required -------------------------------------------------------------------------------------------- Business::ISBN 0 * 2.05 Yes CGI::Session::Driver::memcached 0 * 0.04 No Gravatar::URL 0 * 1.03 No -------------------------------------------------------------------------------------------- Total modules reported: 3 * Module is missing or requires an upgrade. I would appreciate help on two points: 1) I don't know if that is the definitive list of "missing" dependencies, as koha_perl_deps.pl seems to be looking for ParserDetails.ini in a spot where it isn't: paul@nelson:~/koha/koha-3.06.01$ locate ParserDetails.ini /etc/perl/XML/SAX/ParserDetails.ini /usr/share/perl5/XML/SAX/ParserDetails.ini /var/lib/ucf/cache/:etc:perl:XML:SAX:ParserDetails.ini 2) memcached 1.4.6 *is* installed (haven't yet looked into the other two) Thanks in advance - Paul Paul Tired old sys-admin

2 1

Re: [Koha-devel] Bug 6328 (fine in days) and updatedatabase
by Paul Poulain 30 Nov '11

30 Nov '11

Hi chris_n, The 6328 patch has been QAed by Ian, and can now be pushed. BUT there is a problem that i'll try to explain: * as i've announced in my Koha 3.8 release notes and we've worked during KohaCon11 Hackfest, we're working on a new method to update database on a non linear way. Jonathan has written code for that. It works pretty well, i'm testing and there is only (I think) a remaining problem for fresh installs I plan to work on today. Then i'll submit the patch (see bug 7167). * my plan, until this is ready, is to queue all patches that have a database update. Thus, 3.8 will only have the new method for update. * The problem is for bugfixes that have a DB update and must be in 3.6. There should be only a few of them, but here is the 1st, so, we must deal with it. My proposition: * you apply this patch on the 3.6.x * when the new method is ready, we rewritte the patch for 3.8 updatedb At the end: * fresh 3.8 will have directly the correct DB * 3.6.2+ will be updated to have the correct DB. When upgrading to 3.8, the new updater will have to check for this and not try to update the DB once again * 3.6.0 upgraded to 3.8 will be upgraded through the new DB update, that will handle this case. Is there something i'm missing ? Are you OK with this proposition ? -------- Message original -------- Sujet: Re: Bug 6328 (fine in days) and QA Date : Sat, 19 Nov 2011 10:08:36 -0500 De : Ian Walls <ian.walls(a)bywatersolutions.com> Pour : Paul Poulain <paul.poulain(a)biblibre.com> Passed, with a note about a small template change still required on circ/circulation.tt <http://circulation.tt> around line 390. Not worth holding up QA for this, though, as a followup patch could be very easily generated. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

6 18

New dates for GBSD: 2011-12-07 and 2012-01-06
by Magnus Enger 30 Nov '11

30 Nov '11

Yes, that's right, after some consultation on IRC I'm proposing two dates, to avoid the short notices that have been creeping up on us lately: http://wiki.koha-community.org/wiki/2011-12-07_Global_bug_squashing_day http://wiki.koha-community.org/wiki/2012-01-06_Global_bug_squashing_day And yes, 2011-12-07 is a Wednesday (some of us have been talking about trying another dey than Friday) and yes it does fall on the same date as the next general IRC meeting. The devious plan of the bug wranglers is to cajole people into squashing bugs after the meeting! ;-) See you there! Magnus

2 1

Testing patches with a lot of comments
by Paul Poulain 30 Nov '11

30 Nov '11

Hello koha-devel, I sometimes face patches that have a lot of comments, more than one patch, and it's not always easy to understand how to test the proposed patches. We need the following things to be very clearly explained: * test case / step to reproduce * which patch(es) to apply (* anything else ?) Does anyone see a way to have those points clearly displayed/described in the bug ? For example, look at bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5549, about hourly loans = 33 comments, it has only 2 small patches, it's clear more things are needed, maybe the git repo in comment 1. Or is it the one in comment 3? which repo does comment 6 use ? Maybe it's comment 25 in fact. Anyway, it's quite unclear, and, even with all my willingness, I don't know how/what to test. I took this example just because Eliott rises this bug a few hours ago on this ML. But it's not a single case. If anyone has a suggestion, it's welcomed !!! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Hourly Loans
by Elliott Davis 30 Nov '11

30 Nov '11

Hi Koha Devels, I am running the hourly loans branch in my production system and am merging it daily with master. It seems like this gets harder with each merge because of increasing code conflicts. Recently I have set up a branch to keep hourly up to date with master that is on github<https://github.com/libsysguy/koha-hourly>. As I'm sure most of you know I have been actively pushing to get the hourly branch merged into master. I am sending this message to the devel list in an attempt to possibly expedite this process. The issue that I believe we have is this branch is fairly untested which we all know can cause issues when pushed into prod. I am running this branch with no issues in production but I would like to see some other libraries pick up this branch and test. As a side note I think to really generate serious academic library interest in Koha the hourly loans module is a must. I know it was for us when we implemented Koha and not having it in master is really hurting us in regards to time solving merge conflicts. Let me know if anyone is interested. Best, Elliott Davis Robert R. Muntz Library University of Texas at Tyler

2 2