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

Koha Release Manager newsletter published
by Paul Poulain 03 Aug '12

03 Aug '12

Hello, I just published my monthly newsletter on koha-community.org website : http://koha-community.org/koha-release-manager-newsletter-9-2012-07/ And now, I leave for 3 weeks of vacation. See you on Aug, 26th ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

About Release process
by Paul Poulain 03 Aug '12

03 Aug '12

Hello koha-devel, I have some points to rise about our release process. Koha 3.8 has been released 2.5 months ago, and some libraries have reported major problems with 3.8.0. The main origin of those problems came from the fact that a large feature (hourly loans) has been pushed close to the release. It works well, but introduced many side effect: changing the issuing date field to a datetime field broke many other features because some comparison became wrong. When Koha 3.4 has been released, we faced a similar problem, with the switch to T::T that caused many problems too (badly scoped variables in loops, translations problems) Those problems are solved quickly, but libraries that installed Koha 3.X.0 in production faced troubles. So I think we must refine our workflow. There are 2 options here: * stop pushing enhancements that are potentially harmful sooner (2 months before the release ?). What could be harmful is the RM decision. That would make 4 months for pushing ENH, and 2 months for testing. * Release the 3.X.0 saying it's a beta, could have some bugs not detected. The 3.X.1 being a RC, and the 3.X.2 being the 1st really stable version. I must say that I prefer, the 2nd option: contributors are concentrated on stabilizing 3.8, and, on the previous release, a lot of ENH have been signed off close to the release. It look like we had 2 periods: the 1st one where our strength are dedicated to stable, the 2nd one being dedicated to the next release. What is also good with the 2nd option is that it does not change a lot the current timeline and workflow. It's just a matter of announcing things. Your opinion ? PS: I must also add that, independently from this community decision, BibLibre plan to deploy most customers in 3.X.2, and I've been told by Brendan that bywatersolutions will probably wait for .3 or .4. Both of our companies having a few libraries accepting to heavily test releases early. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

15 25

Sanbox n.2 and bug 8357
by tajoli＠cilea.it 01 Aug '12

01 Aug '12

Hi to all, Yesterday I have tested bug 8357 with the Biblibre sanbox n.2. I also use the second form in the web page http://pro.test2.biblibre.com/cgi-bin/koha/sandbox.pl to sign-off the patch. I wait 12 hours but the sign-off is not done. Is there any problem ? Bye Zeno Tajoli

2 2

Cautionary warnings in longoverdue.pl
by Owen Leonard 01 Aug '12

01 Aug '12

misc/longoverdue.pl contains this warning; WARNING: This script is known to be faulty. It is NOT recommended to use multiple --lost options. See http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2883 The bug in question has been closed ("RESOLVED - WORKSFORME"). Can we now remove that warning from the script? What about these FIXMEs? Are they still valid, and should that affect the help text? # FIXME: We need three pieces of data to operate: # ~ lower bound (number of days), # ~ upper bound (number of days), # ~ new lost value. # Right now we get only two, causing the endrange hack. This is a design-level failure. # FIXME: do checks on --lost ranges to make sure they are exclusive. # FIXME: do checks on --lost ranges to make sure the authorized values exist. # FIXME: do checks on --lost ranges to make sure don't go past endrange. # FIXME: convert to using pod2usage # FIXME: allow --help or -h -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 0

Re: [Koha-devel] QohA
by Mason James 31 Jul '12

31 Jul '12

On 2012-07-31, at 3:54 AM, Jonathan Druart wrote: > Hi Mason (and QA team), > > I made some refactoring of your code. > > Several things are still not good, but I hope I helped to improve your code and to make it more maintainable. > > Please have a look a the TODO file I created at the root of the project. > > I hope these modification are going the same way that you planed. yes, thank you - you have done much of what i planned to do :) my next improvement is to re-use the existing ./koha/t/*.t tests, rather than cut/pasting them into the qa-repo > > Regards, > Jonathan > > > https://github.com/joubu/koha-qa-tools/tree/qoha cheers, Mason -- KohaAloha, NZ

1 0

Re: [Koha-devel] Koha on Ubuntu LTS
by Paul 30 Jul '12

30 Jul '12

At 03:58 PM 7/30/2012 -0400, Jared Camins-Esakov wrote: [snip] >However, using a normal sudo account for crontab -e, use vi, add: > >KOHA_CONF=/etc/koha/koha-conf.xml >KOHAPATH=/usr/share/koha >PERL5LIB=$KOHAPATH/lib >* * * * * Â koha Â >$KOHAPATH/bin/migration_tools/<http://rebuild_zebra.pl>rebuild_zebra.pl -a >-b -z 2>&1 > /dev/null > >makes a fully functional cron for incrementing Zebra, albeit in >/var/spool/cron/crontab/ with root:root ownership. All that remains to be >done is to rename the koha file in /etc/cron.d to koha.old (or plain >remove it.) [N.B. the job is quasi-instantaneous, so running every minute >is imperceptible as overhead.] > > >The ownership of the file doesn't matter. What matters is that you >shouldn't have this configured in two different crontabs, which you >currently do. This may cause problems. Very minor point: I wrote "All that remains to be done is to rename the koha file in /etc/cron.d to koha.old (or plain remove it.)" I should have said that I already did it: paul@server2:/var/log$ sudo cat syslog | grep CRON Jul 30 16:09:01 server2 CRON[3345]: (root) CMD (koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z 2>&1 > /dev/null) Jul 30 16:10:01 server2 CRON[3351]: (root) CMD (koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z 2>&1 > /dev/null) Jul 30 16:11:01 server2 CRON[3354]: (root) CMD (koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z 2>&1 > /dev/null) Also thanks for correcting the Wiki, but there was something strange going on (char set glitch?) Copy/paste from Firefox to Putty screen gives: perl .I /usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl .b .w Not the "." rather than "-" for I, b and w I did an edit, which worked in the "show preview" so I saved it. Best - Paul

2 1

Re: [Koha-devel] Koha on Ubuntu LTS
by Archives and Collections Society 30 Jul '12

30 Jul '12

Over the last few days, I've looked into the cron "problem" that I raised the other day and just to be sure, I've just reformatted and installed the whole server+Koha again, using 3.6.7's INSTALL.ubuntu, Tomas' Wiki page and my own notes. I created the user koha by: $ sudo adduser koha but did not use either of the following: $ sudo adduser koha sudo [to give sudo rights] $ sudo adduser koha adm [to give full admin rights] This gives rise to user=koha not being able to use crontab -e, as can be seen: paul@server2:/$ su koha Password: koha@server2:/$ crontab -e crontabs/koha/: fdopen: Permission denied koha@server2:/$ sudo crontab -e [sudo] password for koha: koha is not in the sudoers file. This incident will be reported. koha@server2:/$ However, using a normal sudo account for crontab -e, use vi, add: KOHA_CONF=/etc/koha/koha-conf.xml KOHAPATH=/usr/share/koha PERL5LIB=$KOHAPATH/lib * * * * * koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z 2>&1 > /dev/null makes a fully functional cron for incrementing Zebra, albeit in /var/spool/cron/crontab/ with root:root ownership. All that remains to be done is to rename the koha file in /etc/cron.d to koha.old (or plain remove it.) [N.B. the job is quasi-instantaneous, so running every minute is imperceptible as overhead.] ALSO, I've had to relook at how to do a complete Zebra re-index, given the permissions to user=koha. The following is fully functional: $ su koha $ cd usr/share/koha $ KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -a -r -v $ KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x [N.B. This differs from the Wiki Appendix C., which relies on user=koha having sudo rights.] All of this could possibly be avoided by giving user=koha sudo rights [$ sudo adduser koha sudo], but I am for various reasons loath to do so. The solution outlined above works, and I have not yet found a specific user=koha task that fails. So my question is 'have I missed something else that requires user=koha to have sudo rights?' If not, I would suggest that a revamp of the Ubuntu installation should be written -- I'll be happy to do so. Best - Paul

2 1

Re: [Koha-devel] Koha on Ubuntu LTS
by Paul 30 Jul '12

30 Jul '12

Over the last few days, I've looked into the cron "problem" that I raised the other day and just to be sure, I've just reformatted and installed the whole server+Koha again, using 3.6.7's INSTALL.ubuntu, Tomas' Wiki page and my own notes. I created the user koha by: $ sudo adduser koha but did not use either of the following: $ sudo adduser koha sudo [to give sudo rights] $ sudo adduser koha adm [to give full admin rights] This gives rise to user=koha not being able to use crontab -e, as can be seen: paul@server2:/$ su koha Password: koha@server2:/$ crontab -e crontabs/koha/: fdopen: Permission denied koha@server2:/$ sudo crontab -e [sudo] password for koha: koha is not in the sudoers file. This incident will be reported. koha@server2:/$ However, using a normal sudo account for crontab -e, use vi, add: KOHA_CONF=/etc/koha/koha-conf.xml KOHAPATH=/usr/share/koha PERL5LIB=$KOHAPATH/lib * * * * * koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z 2>&1 > /dev/null makes a fully functional cron for incrementing Zebra, albeit in /var/spool/cron/crontab/ with root:root ownership. All that remains to be done is to rename the koha file in /etc/cron.d to koha.old (or plain remove it.) [N.B. the job is quasi-instantaneous, so running every minute is imperceptible as overhead.] ALSO, I've had to relook at how to do a complete Zebra re-index, given the permissions to user=koha. The following is fully functional: $ su koha $ cd usr/share/koha $ KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -a -r -v $ KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x [N.B. This differs from the Wiki Appendix C., which relies on user=koha having sudo rights.] All of this could possibly be avoided by giving user=koha sudo rights [$ sudo adduser koha sudo], but I am for various reasons loath to do so. The solution outlined above works, and I have not yet found a specific user=koha task that fails. So my question is 'have I missed something else that requires user=koha to have sudo rights?' If not, I would suggest that a revamp of the Ubuntu installation should be written -- I'll be happy to do so. Best - Paul --- 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

XSLT output method
by Fridolyn SOMERS 30 Jul '12

30 Jul '12

Hie, I've worked on Bug 8513 : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8513 The source of this bug is that an anchor tag (<a>) is build without content. With actual version, the generated code is : <a href="..." /> That is what causes a really odd broken page (see bug details). Now, I notices that in XSLTs, the output method is XML. If I use XHTML method, the anchor is generated like this : <a href="..." ></a> And in this case, page is not broken. The anchor is just not visible. I corrected bug in XSLT without changing method but I wonder, why using XML method ? XHTML method corresponds to the usage, and can avoid a lot of bugs like n°8513. I even prefer HTML method. It is not good to break if generated code is not XHTML but just HTML. Best regards, -- Fridolyn SOMERS Biblibre - Pôle Support fridolyn.somers(a)biblibre.com <mailto:fridolyn.somers@biblibre.com>

1 0

Re: [Koha-devel] Koha on Ubuntu LTS
by Paul 29 Jul '12

29 Jul '12

At 06:30 PM 7/28/2012 -0400, Jared Camins-Esakov wrote: >[snip] >Did you try rerunning updatedatabase? Many thanks for the reply. Yes, but I ran paul@server2:/usr/share/koha/intranet/cgi-bin/installer/data/mysql$ perl -I updatedatabase.pl overnight - it only took a few minutes when initiated by Koha after the install. If I've made an error, could you please assist with the syntax? Also, Chris N. suggested "Also double check to be sure that OpacMaintenance did not get set somehow" -- it was set (not sure how - I didn't even realize that this preference existed) and now the OPAC is up and running. Thanks Chris. >The instructions all assume a user crontab. If you are using >/etc/cron.d/koha, you should not be using the user crontab (as all the >instructions assume), or you could do things vice versa. Hidden in a corner under the name 'root' I finally found it, and the cron is now working perfectly (except 'mail', see below). For the archives: $ cd /var/spool/cron $ sudo chmod 755 crontabs $ sudo vi root [change 5 mins to 1 min] :x $ cd .. $ sudo chmod 1770 crontabs >So, remove nullmailer. nullmailer needs to be configured appropriately if >you are using it. Done, and get (once a minute) syslog entries: Jul 29 13:38:01 server2 CRON[1854]: (CRON) info (No MTA installed, discarding output) which was why I was asking if there was an easy way of "turning it off" in Koha (I've looked unsuccessfully for a global O/S method to turn off "warnings) - I don't need an email every minute, 24/7 :-} -- and I'd like to reinstall nullmailer to verify all the "wanted" patron emails (no intention of installing sendmail on this sandbox; on the production server I've got sendmail to selectively dev/null unwanted messages.) Many thanks all around. I'll continue comparing this to our production box, and get some of our cataloguers to have a look over the next few days. As and when we come up with more bits and pieces, I'll have a look at helping with the Wiki page -- Tomas, I see that you have done all the editing, but have a blank "talk" page. Would you prefer to email (either on- or off-list) or use the "talk page"? Regards -- Paul

3 3