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

Re: [Koha-devel] frameworks and Bug 7432
by Paul 16 Jul '12

16 Jul '12

At 02:37 PM 7/15/2012 -0400, Jared Camins-Esakov wrote: >Using 3.6.1 in production (no longer on sandbox, we're looking at 3.8) >modifying frameworks never gave "instant gratification" due to memcached, >so I use netcat: >echo -e "flush_all\nquit\n" | nc localhost 11211 >(and even have a temp 1 min cron job if I need more than a very simple >change.) > >If the only thing using memcached is Koha, you might find it easier to >simply have a cron job that runs `service memcached restart` every hour. Koha is only about 10% of our memcached load, but I do cron "flush-all", "sleep 10" then "restart" every 24 hrs (at 3am, low/no use, gets around the time delay "gotcha".) Also, as far as I know "restart" might not totally *flush* memcached (there's a lot of debate about it, particularly in the php world where memcached's garbage collection seems to be a dirty word) but I haven't done any serious testing. At least "flush-all" is virtually instantaneous, and meets the needs of Koha frameworks. >Do not mix and match files from different versions. My recommendation >would be to upgrade to a recent version of 3.6.x. Thanks for the confirmation. That was my gut feeling. But ... I really am trying to avoid trashing the work I've done on 3.8 on the sandbox (which is too old to successfully run two versions of Koha.) I'm nowhere near ready at this time to put 3.8 into production, so I guess my $64,000 question is "what is the most stable version of 3.6 that I can upgrade the production server to, with the least chance of running into problems?" There's probably a lot of other bug fixes and enhancements that could be useful. Maybe wait for your 3.6.7? :=) >[snip] (WARNING: the following is irrelevant to your question) I would >argue this is a bug (reported it as one, in fact), but that's the way it >is, so -- for the moment -- no need to mark both the tag and subfield >mandatory. Based on the way the MARC standard is written, marking a >subfield mandatory should make it so that if any subfield in that tag is >populated, that subfield must be populated, but not require that the tag >be populated at all. However, that's not the way it works, so it's kind of >a moot point. Sorry, but I can't find the bug you reported (number?) From my perspective, it was a [probaly very rare] combination of circumstances and as you say "a moot point", hence my calling it an "oddity" rather than a bug. We're back on track, the cataloguers see a red asterix, and the help file (ours, not LoC) pops up when requested. Thanks again and regards, Paul _______________________________________________ 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/ --- 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

Re: [Koha-devel] "The Plack effect" benchmarked
by Waylon Robertson 16 Jul '12

16 Jul '12

This is for Staff interface, what about OPAC interface? On Thu, Jul 12, 2012 at 2:34 AM, Waylon Robertson <wrobertson1981(a)yahoo.co.nz> wrote: just some of the speed improvement we look forward to in koha 3.8.2 > > >----- Forwarded Message ----- >From: Paul Poulain <paul.poulain(a)biblibre.com> >To: Koha-devel(a)lists.koha-community.org >Sent: Wednesday, 6 June 2012 4:02 AM >Subject: [Koha-devel] "The Plack effect" benchmarked > >Hi, > >Just in case some of you have doubts about the interest of having Plack >for staff interface, here is a result of >misc/load_testing/benchmark_staff.pl made with and without Plack: > >benchmarking WITH Plack: >Step 1: staff client main page 4178ms 4.786 pages/sec >Step 2: catalog detail page 9991ms 2.001 biblios/sec >Step 3: catalogue search 5631ms 3.551 biblios/sec >Step 5: patron detail page 7037ms 2.842 borrowers/sec >Step 5: patron search page 11800ms 3.389 borrowers/sec >Step 6a circulation (checkouts) 8967ms 2.23 checkouts/sec >Step 6b circulation (checkins) 13880ms 1.44 checkins/sec >all transactions at once 55433ms 3.247 operations/sec >(note = tests run with plackup, not with starman, the all transaction at >once results would probably be better with starman) > >benchmarking WITHOUT Plack: >Step 1: staff client main page 28576ms 0.699 pages/sec >Step 2: catalog detail page 39106ms 0.511 biblios/sec >Step 3: catalogue search 55524ms 0.36 biblios/sec >Step 5: patron detail page 34610ms 0.577 borrowers/sec >Step 5: patron search page 64964ms 0.615 borrowers/sec >Step 6a circulation (checkouts) 37907ms 0.527 checkouts/sec >Step 6b circulation (checkins) 39129ms 0.511 checkins/sec >all transactions at once 138298ms 1.301 operations/sec > >It appears that the speed improvement is more x3 or x4 than x1.5 as I >usually say >-- >Paul POULAIN >http://www.biblibre.com >Expert en Logiciels Libres pour l'info-doc >Tel : (33) 4 91 81 35 08 >_______________________________________________ >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/ > > >

1 0

Translation of KOCT (Koha Offline Circulation Tool)
by Paul Poulain 16 Jul '12

16 Jul '12

Hi, BibLibre is working on a new version of KOCT (http://wiki.koha-community.org/wiki/Offline_circulation_firefox_plugin) that enable translation of the plugin. We are currently testing the translation to french. Once we're sure things are OK, I'll send here some explanations and example file for those who want to translate the plugin in their own language. There are only a few strings (less than a dozen) Stay tuned. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Re: [Koha-devel] frameworks and Bug 7432
by Archives and Collections Society 16 Jul '12

16 Jul '12

At 02:37 PM 7/15/2012 -0400, Jared Camins-Esakov wrote: >Using 3.6.1 in production (no longer on sandbox, we're looking at 3.8) >modifying frameworks never gave "instant gratification" due to memcached, >so I use netcat: >echo -e "flush_all\nquit\n" | nc localhost 11211 >(and even have a temp 1 min cron job if I need more than a very simple >change.) > >If the only thing using memcached is Koha, you might find it easier to >simply have a cron job that runs `service memcached restart` every hour. Koha is only about 10% of our memcached load, but I do cron "flush-all", "sleep 10" then "restart" every 24 hrs (at 3am, low/no use, gets around the time delay "gotcha".) Also, as far as I know "restart" might not totally *flush* memcached (there's a lot of debate about it, particularly in the php world where memcached's garbage collection seems to be a dirty word) but I haven't done any serious testing. At least "flush-all" is virtually instantaneous, and meets the needs of Koha frameworks. >Do not mix and match files from different versions. My recommendation >would be to upgrade to a recent version of 3.6.x. Thanks for the confirmation. That was my gut feeling. But ... I really am trying to avoid trashing the work I've done on 3.8 on the sandbox (which is too old to successfully run two versions of Koha.) I'm nowhere near ready at this time to put 3.8 into production, so I guess my $64,000 question is "what is the most stable version of 3.6 that I can upgrade the production server to, with the least chance of running into problems?" There's probably a lot of other bug fixes and enhancements that could be useful. Maybe wait for your 3.6.7? :=) >[snip] (WARNING: the following is irrelevant to your question) I would >argue this is a bug (reported it as one, in fact), but that's the way it >is, so -- for the moment -- no need to mark both the tag and subfield >mandatory. Based on the way the MARC standard is written, marking a >subfield mandatory should make it so that if any subfield in that tag is >populated, that subfield must be populated, but not require that the tag >be populated at all. However, that's not the way it works, so it's kind of >a moot point. Sorry, but I can't find the bug you reported (number?) From my perspective, it was a [probaly very rare] combination of circumstances and as you say "a moot point", hence my calling it an "oddity" rather than a bug. We're back on track, the cataloguers see a red asterix, and the help file (ours, not LoC) pops up when requested. Thanks again and regards, Paul

1 0

frameworks and Bug 7432
by Paul 15 Jul '12

15 Jul '12

Using 3.6.1 in production (no longer on sandbox, we're looking at 3.8) modifying frameworks never gave "instant gratification" due to memcached, so I use netcat: echo -e "flush_all\nquit\n" | nc localhost 11211 (and even have a temp 1 min cron job if I need more than a very simple change.) However, I've just come across bug 7432, and while 10 minutes might be a bit painful, I would appreciate advice for updating in a production environment (I normally work on the principle that "if it ain't broke, don't fix it", but...) Is it better for me to attempt to modify our existing biblio.pm (4 minuses, five plusses as far as I can see) or find a more recent biblio.pm, in which case "which one and where"? (maybe from a complete tar of 3.6.5?) How do I find release details at component level? How do I check for side effects? (None are apparently visible from the bug page.) By the way, I've found a possible "oddity"; making a subfield mandatory so that the "manadatoryness" is not just functional but also appears in the fourth column of marctagstructure.pl, I have to use both: marctagstructure.pl?op=add_form AND marc_subfields_structure.pl?op=add_form -- am I doing something wrong? Many thanks, Paul

2 1

About test suite & jenkins
by Paul Poulain 13 Jul '12

13 Jul '12

Hello, Jenkins is still unstable. This happens from time to time. chris_c take care of fixing what is related to the test database or installing new dependencies, or things like that. I try to take care of fixing patches that cause failure, -but I must admit I don't understand easily what jenkins is usually saying- So I had 2 ideas: Idea 1 = I was wondering if we should not have a new elected position of "jenkins guardian". Idea 2 = And if we could not have the test suite in a repository different than Koha itself (or as a submodule), or if the jenkins guardian should not be able to push into $KOHA/t and $KOHA/xt The idea with a separate repository, would be that it could also have all jenkins parameters, databases, hooks, whatever,... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 2

RM holidays
by Paul Poulain 13 Jul '12

13 Jul '12

Hello koha-devel, Just to let you know: I'll be in holiday (and AFK) from Aug 4th to Aug 26th, included. I think I'll read my mails from time to time, but won't probably push patches, except if something is going really wrong. This period is usually very quiet, many ppl are in holiday too (northen hemisphere, at least ;-) ). If you leave today: happy holiday. If you stay for some more weeks like me, go sign-offing some patches, it's a good activity to do during summer ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Re: [Koha-devel] Authority indexing
by Stefano Bargioni 13 Jul '12

13 Jul '12

In my opinion, they can be the same. However, I'd like to have a way to search for authority number in the staff client, and obtain the authority record, not the biblio records linked to the heading. Bye. Stefano > Hello. > > Triggered by bug 8206 (add additional search options to authority browser > on OPAC: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8206) > Marcel, Katrin, and I have been discussing the inconsistent indexes used > for searching authorities in the staff client an OPAC. Somewhere in git > history (I can't remember exactly where I saw it) there was a note that the > OPAC "had" to use different authority indexes than the staff client, so > when I re-added the search options for bug 8206, I used the same indexes > that the OPAC had used previously. Marcel pointed out quite correctly that > if no one can explain *why* the OPAC should have to use different indexes, > it would be better to make the staff client and OPAC consistent. So, I turn > to the community: at this point could I just use the same indexes in the > OPAC as are used in the staff client? > > Regards, > Jared __________________________________________________ Il tuo 5x1000 al Patronato di San Girolamo della Carita' e' un gesto semplice ma di grande valore. Una tua firma aiutera' i sacerdoti ad essere piu' vicini alle esigenze di tutti noi. Aiutaci a formare sacerdoti e seminaristi provenienti dai 5 continenti indicando nella dichiarazione dei redditi il codice fiscale 97023980580.

2 1

Koha::Calendar broken since C4::Calendar split
by Dobrica Pavlinusic 13 Jul '12

13 Jul '12

With end of academic year near, I was forced to take a look why our due-dates aren't calculated correctly. Result is Bug 8418 - Koha::Calendar is_holiday ignores all user data http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8418 This is pure bug-fix patches to Koha::Calendar to restore functionality which used to work in C4::Calendar. I'm aware there are quite a few patches which touch this code, but some of them are wrong and others are stuck in sign-off because they also modify another parts of Koha. This is my attempt to provide simple bug fix only which should also be applicable for stable Koha versions. It makes useDaysMode work and remove one redundant SQL query so I hope that you will forgive me for making duplicate changes in separate bug. At least, I tried to block all bugs which also provide same fixes, but unblocking them is just removing relevant patches from them, making other bugs just functionality change. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

2 1

Authority indexing
by Jared Camins-Esakov 12 Jul '12

12 Jul '12

Hello. Triggered by bug 8206 (add additional search options to authority browser on OPAC: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8206) Marcel, Katrin, and I have been discussing the inconsistent indexes used for searching authorities in the staff client an OPAC. Somewhere in git history (I can't remember exactly where I saw it) there was a note that the OPAC "had" to use different authority indexes than the staff client, so when I re-added the search options for bug 8206, I used the same indexes that the OPAC had used previously. Marcel pointed out quite correctly that if no one can explain *why* the OPAC should have to use different indexes, it would be better to make the staff client and OPAC consistent. So, I turn to the community: at this point could I just use the same indexes in the OPAC as are used in the staff client? Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

2 1