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

"freezing" koha 3.0
by Paul POULAIN 19 May '08

19 May '08

Hello, I begin to be really troubled by all those new features added in the main trunk... I think we really should stop hacking koha that much & work only on stabilizing things. And by stabilizing I mean "stop adding anything new, strictly, really strictly, just fix things that have to be fixed" just some examples of the side effects/problems with this activity : 1- the french translation was 100% done. I just updated the .po file : 192 fuzzy (chain changes) and 45 untranslated strings. And I keep the translation update really often. I'm afraid other translators will have a very bad surprise, seeing 20 or 25% of the stuff they already did has to be redone, because each change in the template will result in 2- I see some new features like patron images, tagging, serialsadditem at subscription level[1], move to yui 2.5.1 (from 2.31.), new sysprefs by dozens, important changes in the DB structure (the great new permission/sub permission, the old_issues table). Important code refactoring/cleaning. All those great. Undoubtfully. But the risk to introduce some unexpected bugs where things were working previously is really BIG. Just 2 examples : one patch of me troubled kados, because he broke something in another page : the problem was directly introduced by a change in API (C4::Dates.pm). I was not wrong with my patch, I just discovered a larger problem (that atz has fixed iirc). the patch to add a new way to introduce issuing rules resulted in the unexpected bug #2000. [1] yes, I know, this patch is mine. but with the release being so delayed, I was tired to delay this patch & have decided to send it. 3- I see some gui changes, done by owen, that are great. but such changes can be done forever, things will never be perfect (and one will find something awful when someone else will say it's great :-\ ). 4- Joshua, you've announced the alpha for jan, 4. beta for feb, 1st and stable for march, 1st. We are almost may 1st, and still no stable version released. I would be interested to know how many commits were related to true "bugfixes" and how many were related to "improvement/cleaning/new features". I would say it's 30% / 70% (numbers not calculated scientifically ;-) ) In french we says "better is sometimes enemy of good". I think we are facing this situation : "better" is now our biggest enemy. So, I request/propose the following decision to be taken : - we didn't have had an irc meeting for a long time, it's time to plan one. - no changes in the code, except true bugfixes. "imperfection" fixes will be for later. - no more changes in templates except true spelling problems (or true bugfixes, of course), to let time to i18n teams to do their job. - create a branch, as soon as possible, to have ppl doing improvements on the dev branch, and bugfixes on the 3.0 branch. That's how we did for 2.0 and 2.2. I released a version once every 3 month or something like that. I agree we didn't had a company like LibLime doing 125/130 commits every month. (http://git.koha.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ve…) but 3.0 will never be ready if we continue like that. And with git, it should be "easy" for ppl wanting to have an hacked version of 3.0, with a backported improvement from the dev branch to be done. I'm sure, because I have some patches for some of our customers, that we haven't commited to the main repo (some of them will never be, some of them will be for 3.2, probably) Joshua, you probably have a different opinion than mine, as RM. But as previous RM, I had to write my thoughts. I hope you'll understand my opinion and agree on most of it. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

10 26

RFC: 'Edit-Items' staff permission
by Mason James 15 May '08

15 May '08

Hi All, What does anyone think about changing the current 'edit-catalogue' permission into 2 separate permissions? An 'edit-catalogue' permission, and a 'edit-items' permssion. The idea behind this is to give the Koha Administrator the ability to: 1) allow some staff accounts to make changes to a catalog record at both the bib-level and item-level 2) restrict some staff accounts to make changes to a catalog record at the item-level *only* I have already made a mod for a koha3-beta2 install to do this, and its a pretty small and safe mod. I'll work on this tomorrow to get it working with Galen's newer permissions stuff in HEAD and send over the patch. Does this sound like a feature we can get included in koha3-beta3? Cheers, Mason. _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

6 5

Links authorities records with biblio records
by Salvador Zaragoza Rubio 15 May '08

15 May '08

Dear all, After installing the 3.00.00 beta version of the Koha, i've been trying to link the authorities records with the biblio records launching the link_bibs_to_authorities.pl script without success so far. I did some debugging at the koha-zebradaemon-output.log file and found out that the query looking for authorities matches didn't display any hits, because it was searching with the Match-heading Bib-1 attribute. Our authorities titles are stored in the Marc21 150$a field, that correspond with the Subject-topical-heading Bib-1 attribute, so i had to change in the Heading.pm file in the authorities method the Bib-1 attribute, suppress in the method _query_limiters the thesaurus and added terms, and add in the /etc/koha/zebradb/ccl.properties file the new Local-Use Authority Index of the Subject-topical-heading attribute. After all these changes, launching the link_bibs_to_authorities.pl script started to display results of heading changes and the zebraqueue was filled with biblio specialupdates operations. So i think this is the way how it has to be configured, at least for our authorities records. It worked for me. If anyone has a suggestion or believes that is a wrong procedure comments will be welcome. Thanks in advance and receive my best regards, Salva - ---- Salvador Zaragoza Rubio Departamento proyectos software C/ Garcilaso, 15 46003 Valencia Telf: 96 369 41 23 / 677 405 909 Fax: 96 369 34 39 www.masmedios.com

1 0

RFC on ISBN sanitisations, was: [Koha-patches] [PATCH] Bugfix ShelfBrowser using unsanitized ISBNs. Owen reported the
by Jesse 15 May '08

15 May '08

Woops, forgot to CC the list. Yes, I think this should be moved to C4. I've been noodling around > with the notion of creating a C4::Normalize or the like to centralize > these kinds of normalizations (as ISSNs, LC card numbers, OCLC > numbers, etc. could benefit from this as well), but haven't done > anything yet. > > Regards, > > Galen Do you think we could also put standard formatting of these types of numbers in there, and make a naming scheme? Example: ISBNInternalForm('0-7434-3602-4') eq '0743436024' ISBNDisplayForm('0743436024') eq '0-7434-3602-4' Also LCCNInternalForm and LCCNDisplayForm, etc. The naming scheme is a slightly awkward one, so feel free to modify. It would be nice to have this functionality for other things too, such as C4::Amazon.

6 9

Vote NOW for the Koha Community Website Theme
by Darci Hanning 14 May '08

14 May '08

Dear Koha Community, You may now vote for the Koha Community Website Theme here: http://www.surveymonkey.com/s.aspx?sm=cXmKffvDeO7c48PVcFB4BA_3d_3d Please submit your votes by May 1, 2008, 11:59pm PDT (-0800). The winner will be announced on May 2, 2008 As stated in the poll/survey, you are reviewing the visual impact and graphical elements of the theme. Overall site structure and actual content was created in order for the themes to have something to design against. You can view each of the themes at: http://contest.hanning.name/skin1 http://contest.hanning.name/skin2 http://contest.hanning.name/skin3 If you have any problems viewing the themes, please contact Darci Hanning at darci.hanning(a)gmail.com with "Koha Theme Contest" in the Subject: line. If you have problems with the voting or survey, please contact Joshua Ferraro at jmf(a)liblime.com Cheers! Darci Hanning

10 31

Re: [Koha] Koha 3.0 beta on Kubuntu gutsy - "production mode -trapped fatal
by Mason James 14 May '08

14 May '08

> > On 2008/05/8, at 8:48 PM, Mason James wrote: > >> >> On 2008/05/8, at 6:34 PM, Ken Lomax wrote: >> >>> Hi >>> >>> I see no reason why you should need to uninstall these unless you >>> have >>> different versions of the relevant files. You may need to restart >>> the >>> mysql server "service mysqld restart" on my fedora systems. >>> >>> Check that all relevant files have the same version numbers. The >>> files I >>> have installed are >>> mysql-5.0.45 >>> mysql-devel-5.0.45 >>> mysql-server-5.0.45 >>> mysql-libs-5.0.45 >>> >>> >>> On Tue, 2008-05-06 at 15:33 -0700, rmaynord wrote: >>>> Ken: >>>> >>>> I installed the development files, but no change. Should I >>>> uninstall/install mysql or perl or koha after installing the >>>> development >>>> files? >>>> >>>>>> >>>>>> I then tried to force install DBD::mysql but received the >>>>>> message ---> >>>>>> Can't exec "mysql_config": No such file or directory at >>>>>> Makefile.PL line >>>>>> 76. >>>>>> >> >> >> Hi Robert, >> >> On a debian box, try installing the package 'libmysqlclient15-dev' >> to resolve your missing 'mysql_config' file issue. >> >> $ which mysql_config >> /usr/bin/mysql_config >> >> $ dpkg -S /usr/bin/mysql_config >> libmysqlclient15-dev: /usr/bin/mysql_config >> >> Cheers, Mason. > > > > Just a little update (on a debian box) > > The previous 'dpkg -S' example only works on packages that you > *already* have installed > Try apt-file to find out which package a file belongs to - that you > *dont* have installed. > > $ sudo apt-get install apt-file > $ apt-get update > $ apt-file search 'mysql_config' > libmysqlclient15-dev: usr/bin/mysql_config > > Mason. > _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

1 0

git, mails to patches ML & commit note
by Paul POULAIN 13 May '08

13 May '08

Hello, i've just commited a small patch with long comments, and see that the comment has been wrapped by something. Did someone realize that before, and did someone find a solution not to have commit comment eaten by some hidden beast on the server ? cheers. Note : it seems the commit note is not transformed on git itself, just on the mail to the patches list -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

Re: [Koha] Changed IP - Can't connect to mysql server
by Mason James 13 May '08

13 May '08

On 2008/05/13, at 1:13 AM, Robert Linebaugh wrote: > Koha version 2.2.5 (Internal IP 10.0.254.3) > Mysql version 4.1 (Internal IP 10.0.254.4) > > I did not use the GRANT ALL ON command on the mysql server. I > assume this command has to be performed on the mysql server and the > @server should be the Koha server? (ex. GRANT ALL ON koha.* to > kohaadmin(a)10.0.254.3 ) I probably need to know the mysql root > password that I’ve been reading about? > > I’m not sure how to connect to the mysql server with the > commandline mysql client from the koha server. > > C:\Documents and Settings\rlinebaugh>telnet 10.0.250.4 3306 > Connecting To 10.0.250.4...Could not open connection to the host, > on port 3306: > Connect failed > > Rob Hi Rob, your mysql server isnt configured to allow remote connections. these are *nix examples, but you get the gist... You can google for more info. 1) edit your mysql conf file , change your bind-address value from 127.0.0.1 to your server's IP server$ vi /etc/mysql/my.cnf # bind-address = 127.0.0.1 bind-address = 10.0.254.4 ------------ 2) restart your mysqld server$ /etc/init.d/mysql restart ------------ 3) connect to server from the client.... client $ mysql -u kohaadmin -h 10.0.254.4 -p koha Your MySQL connection id is 8 Server version: 5.0.32-Debian_7etch5 Debian etch distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> Mason. > From: Mason James [mailto:mason.loves.sushi@gmail.com] > Sent: Friday, May 09, 2008 7:53 PM > To: Ryan Higgins > Cc: Robert Linebaugh; koha > Subject: Re: [Koha] Changed IP - Can't connect to mysql server > > > On 2008/05/10, at 10:02 AM, Ryan Higgins wrote: > > > > Did you > > GRANT ALL ON mykoha_db_name.* to kohaadmin(a)72.227.31.7 > > on the mysql server ? > > Can you connect to the mysql server with the commandline mysql > client on the koha server ? > > > I had to change the IP scheme of my network. I have changed the > > interfaces, hosts and koha.conf files to reflect the new IP. > When I try > > to access Koha by typing http://koha.domain.com:8050 I get a 500 > > internal server error. My opac-error_log file says: > > > > > > > > Thu May 08 21:24:58 2008] [error] [client 72.227.31.7] DBI > > connect('Koha:10.0.250.4','kohaadmin',...) failed: Can't connect to > > MySQL server on '10.0.250.4' (111) at > > /usr/local/koha/intranet/modules/C4/Context.pm line 411 > > Hi Robert, > > Try these tests too... > > To test your networking, try a telnet to the remote mysql box... > $ telnet 10.0.250.4 3306 > > If that works, hit it with the mysql client... > $ mysql -u kohaadmin –h 10.0.250.4 –p'mypassword' koha > > Cheers, Mason. _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

2 2

Problems with Fixes to 1782
by Joshua Ferraro 12 May '08

12 May '08

I've just applied and pushed Henri-Damien's recent patch to fix bug 1782. The patch adds a new syspref called AddPatronLists that allows the administrator to specify how patron types and categories should be displayed in the patron add screen. Specifically, it seems to determin whether the categories should be organized by the top-level hard-coded type codes (Adult, Child, Staff, etc.), or whether the user-specified categories are the only ones that should be displayed. NOTE: This only patches the drop-down list when adding a patron, the memberentry.pl screen still groups the list of categories by the type selected, regardless of the syspref's value. I'd consider this a bug. However, this patch causes complete failure of memberentry.pl. When adding new patrons, the following error results, regardless of the value of the PatronLists syspref: Bad index while coercing array into hash at /home/jmf/repos/koha-rm-test.git/members/memberentry.pl line 151. The relevant lines in memberentry.pl are: 150 my $tmpborrowercategory=GetBorrowercategory($check_category); 151 $check_categorytype=$tmpborrowercategory->{'category_type'}; The problem is that it assumes that GetBorrowercategory always returns a hash, which it does not. This is a problem in and of itself, but futher digging reveals that a sub called 'checkuniquemember' is completely bogus, and may be the real cause of the problem (it attempts to prevent creation of patrons with the same name!!!) WARNING: These bugs are outstanding, and it's very likely that adding and editing patrons WILL FAIL after you apply these patches until the problems are resolved. Normally, I wouldn't push up a patch that had such catastrophic consequences, but I feel the best approach in this case is to push up a fix to the problem asap. So ... any volunteers to repair the damage and clean up this problematic area? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 1

[marc.chantreux@biblibre.com: Re: XML::LIBXSLT error on Debian etch]
by Marc Chantreux 09 May '08

09 May '08

----- Forwarded message from Marc Chantreux <marc.chantreux(a)biblibre.com> ----- From: Marc Chantreux <marc.chantreux(a)biblibre.com> To: koha-devel(a)lists.koha.org Subject: Re: [Koha-devel] XML::LIBXSLT error on Debian etch On Wed, May 07, 2008 at 08:48:34AM -0600, Chadwick, John, DCA wrote: > Okay, I got the DBD::mysql issue resolved yesterday. I am down to one stubborn package, XML::LIBXSLT won't install. as this module is debian packaged, why don't you install it by this way ? koha:/# apt-cache policy libxml-libxslt-perl libxml-libxslt-perl: Installé : 1.59-1 Candidat : 1.59-1 Table de version : 1.62-1.1 0 500 http://ftp.fr.debian.org testing/main Packages *** 1.59-1 0 990 http://ftp.u-strasbg.fr etch/main Packages 100 /var/lib/dpkg/status hth -- Marc Chantreux BibLibre, expert en logiciels libres pour l'info-doc http://biblibre.com ----- End forwarded message ----- -- Marc Chantreux BibLibre, expert en logiciels libres pour l'info-doc http://biblibre.com

1 0