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

Call for News for the September Newsletter
by Daniel Grobani 11 Sep '12

11 Sep '12

Dear Koha Kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 20th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani

1 0

Re: [Koha-devel] cron, env, etc
by Paul 07 Sep '12

07 Sep '12

At 11:13 AM 9/6/2012 -0300, Tomas Cohen Arazi wrote: Tomas - I'm taking the liberty of Cc:ing the devel list (you suggested that you had spoken with some of them) but would thank you for the 'off-list' exchange of emails. I have spent quite a bit of time checking various possibilities/combinations to ensure that a user cron, re-indexing zebra, functions as expected on various combinations of Koha 3.6.x and 3.8.4 on Ubuntu 10.04 and 12.04 (the two current Ubuntu LTS servers) on both 32- and 64-bit boxes. I have come to the conclusion that the use of crontab as outlined in RESULT [B] "rewritten" (see below) is fully functional, is a single "edit" at the time of installation, and could be included with total clarity in INSTALL.ubuntu and on the Wiki. The use of cron.d/koha RESULT [C] "second scenario" is also functional, but requires two edits at install time (and I've included a couple of minor caveats.) I have not looked at the "package", only at various tarballs, so do not know under what conditions either crontab or cron.d may be used. ISTR reading that package and tarball directory structure differs, so am not at all certain how close the two "installs" should or could be maintained. HTH - regards - Paul NOTES: [A] From $ man cron : "cron also reads /etc/crontab, which is in a slightly different format (see crontab(5)). Additionally, cron reads the files in /etc/cron.d: it treats the files in /etc/cron.d as in the same way as the /etc/crontab file (they follow the special format of that file, i.e. they include the user field). However, they are independent of /etc/crontab: they do not, for example, inherit environment variable settings from it." [B] From 3.8.4 INSTALL.ubuntu : 5.2.2 Zebra Indexer Add an entry in Koha user crontab to scheduled added/updated/deleted records indexing by Zebra with this command: <path/to/koha>/misc/migration_tools/rebuild_zebra -z -b -a [C] From <http://wiki.koha-community.org/wiki/Koha_on_Ubuntu> [abbreviated] 3 - Setup the environment variables used by Koha scripts $ sudo gedit /etc/cron.d/koha Add KOHA_CONF=/etc/koha/koha-conf.xml KOHAPATH=/usr/share/koha PERL5LIB=$KOHAPATH/lib (Alternatively ... same result.) $ sudo gedit /etc/bash.bashrc.local Add export KOHA_CONF=/etc/koha/koha-conf.xml export PERL5LIB=/usr/share/koha/lib 5b - Reindexing Choices Option #1: See http://wiki.koha-community.org/wiki/Background_indexing_with_Zebra Option #2: Add a cronjob to index your zebra database. $ sudo gedit /etc/cron.d/koha Add # The cronjobs */5 * * * * koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null RESULTS: [B] above does not funtion. It does function if rewritten as: 5.2.2 Zebra Indexer Add a Koha user cron job to schedule added/updated/deleted record indexing by Zebra with this command: $ sudo vi /etc/crontab Append the following lines: KOHA_CONF=/etc/koha/koha-conf.xml KOHAPATH=/usr/share/koha PERL5LIB=$KOHAPATH/lib */1 * * * * koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null :x [C] {5b Option 1 - respectfully for Frédéric - not explored "This solution is completly outside Koha"} First scenario: para 3 "cron.d" plus para 5.b Option 2 does not function (probably due to [A]) Second Scenario: para 3 "Alernatively" plus para 5.b Option 2 does function, with two possible caveats: (a) Comparing my notes from various "new installs" versus "sandbox testing edits", I suggest adding 'export KOHAPATH=/usr/share/koha' to .bashrc between the other two en vars (b) For a [user] cron, I prefer to 'export' from /home/[user]/.bashrc rather than /etc/bash.bashrc.local --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0

Unit tests and mock module
by Paul Poulain 07 Sep '12

07 Sep '12

Hi Koha-devel, I just pushed t/Members_AttributeTypes.t unit tests that fake the database. The test here could be redundant with t/db_dependent tests I feel we should be aware of that, and : * decide Mock is the way to go, and promote using of Mock, removing db_dependent tests (that fail if you don't have a database) * decide we should prefer db_dependent tests and limit the use of Mock to specific cases I feel that deciding nothing will result in a poor readability of what tests what, and some difficulties to know which test is to update when you update a sub. So, as Mock is introduced, we must speak of it. Your opinion ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

7 6

RFC on sysprefs deprecation workflow
by Tomas Cohen Arazi 07 Sep '12

07 Sep '12

We have fully documented the process of adding a syspref to Koha[1]. It remains unclear which workflow syspref deprecation should follow. I've been told on IRC that, traditionally, deprecated sysprefs are set to a 'good default' value, and then hidden. If you take a look at bug 8724 [2] you'll notice that i followed that path. But as NoZebra is to be fully removed from Koha tree I ask: what do u think the workflow for syspref removal be? It should be added to the sysprefs wiki too. I can do it if needed. Regards To+ [1] http://wiki.koha-community.org/wiki/System_Preferences [2] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8724

6 6

Monthly RM newsletter
by Paul Poulain 07 Sep '12

07 Sep '12

Hello Koha users and developers, You'll find my monthly newsletter on the website: http://koha-community.org/koha-release-manager-newsletter-10-2012-08/ The biggest part of this newsletter is dedicated to the upcoming release & release process. Happy reading ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Bugs which are assigned but abandoned
by Owen Leonard 06 Sep '12

06 Sep '12

I have created a saved search in Bugzilla for bugs which are assigned but which haven't been changed in over a year: http://bugs.koha-community.org/bugzilla3/buglist.cgi?cmdtype=dorem&remactio… If you're one of the assignees on this list and you're not really working on it anymore I think the bug should be returned to "NEW." -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

2 2

Re: [Koha-devel] RFC on sysprefs deprecation workflow
by Paul 05 Sep '12

05 Sep '12

Apologies - please disregard, didn't put #4 below in context. P. At 11:41 AM 9/5/2012 -0400, Galen Charlton wrote: >On 09/05/2012 10:50 AM, Tomas Cohen Arazi wrote: >>If you take a look at bug 8724 [2] you'll notice that i followed that >>path. But as NoZebra is to be fully removed from Koha tree I ask: what >>do u think the workflow for syspref removal be? It should be added to >>the sysprefs wiki too. I can do it if needed. > >I would think it should be something like this: > >[1] Remove all code that uses the syspref. >[2] Remove all references to the syspref from preferences/*.pref. >[3] Remove all references to the syspref from the installer SQL for all >localizations. >[4] Add an update to updatedatabase.pl deleting the preference from the >systempreferences table. +1 but from an excess of caution, is there any possibility that this could complicate a MySQL {dump form earlier version} ==> {restore to a brand new install}? Best - Paul

1 0

broken tests for smsoverdues.pl and rss.pl
by matted-34813＠mypacks.net 05 Sep '12

05 Sep '12

While running some tests. When running: prove t/db_dependent tests, the 00-strict.t the tests complain about misc/cronjobs/smsoverdues.pl and misc/cronjobs/rss.pl referring to HTML::Template:Pro which has been gone for some time. It probably esists on the jenkins server, but not on my fresh dev environment. I am wondering which way to go: a) submit a bug and recode the tests with Template::Toolkit OR b) we should remove/deprecate the functionality. (I hate removing things) Can anyone determine how long they have been broken (the release). If we don't remove them now, when in the future(release) would it be appropriate? Hopefully this can be discussed during the Sept 5th 2012 general IRC meeting (on the agenda). I can't make it to the meeting. Please chime in if you've worked on these components. wajasu

1 0

IRC Meeting Reminder: 5 September 18 UTC
by Owen Leonard 04 Sep '12

04 Sep '12

The next general IRC meeting is coming up soon: 5 September at 18 UTC http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+M… The agenda is here: http://wiki.koha-community.org/wiki/General_IRC_meeting,_5_September_2012 I hope to see you there, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 0

Volunteers for the 3.12 release
by Chris Cormack 03 Sep '12

03 Sep '12

It's that time again, we are sorting out volunteers to work on the 3.12 release http://wiki.koha-community.org/wiki/Roles_for_3.12 If there is a role you think you would be good at, please sign up Chris

1 0