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

Tipo fix (unimarc templates).
by Zeno Tajoli 31 Jul '08

31 Jul '08

Hi to all, I write here same tipo fix about english template for Unimarc. The dir is /koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/ --file unimarc_field_116.tmpl rows 955, 1152, 1345: Litographie/option>, to fix in: Litographie</option> --file unimarc_field_140.tmpl row 644: Plans/, to fix in : Plans Cheers Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

2 1

Good Bye
by Dorian Meid 30 Jul '08

30 Jul '08

After long time silence from me I finally have to cease my comittment for Koha. Our small library has been taken over and also did I quit my honorary position as a librarian and sysadmin there. The new leadership has declared that they are not willing to continue using Koha which makes me sad and angry. My real Job didn't left me much room for additional efforts anyway and so I now want to say good bye to all of you and whish you all the best and good luck developing Koha to the best free ILS ever. Dorian Meid

2 1

Re: [Koha-devel] [Koha-patches] [PATCH] BUG-2393: ENHANCEMENT: SearchMember() uses "cardnumber%" wildcard - if other search-types fail
by Andrew Moore 30 Jul '08

30 Jul '08

(Note: moved to koha-devel from patches) Hi Paul - On Fri, Jul 25, 2008 at 1:57 AM, paul POULAIN <paul.poulain(a)biblibre.com> wrote: > Please note that the SQL "LIMIT" pragma is mySQL specific. So it must be > avoided. Is this a guideline we should be currently following? I'm not asking because i disagree with it, in fact I think it's an admirable goal. I just hadn't seen it documented anywhere like the developers' wiki, and I fear that I've probably been failing to abide by it. I think there are plenty of uses of "LIMIT" in the code, and if this is something we're working towards, I'll start eliminating them in any code I work on. Thanks! -Andy

3 2

About macles.pl
by Zeno Tajoli 30 Jul '08

30 Jul '08

Hi to all, checking the staff translation I have found a connection to the script ../cataloguing/value_builder/macles.pl. For me is not clea the use of the plugin for cataloguing. Is 'MACLES' a name for a specif type of keywords ? Or is it samething else ? Can you explain me the use of this plugin ? Thank you very much Cheers Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

3 2

Is aqorderdelivery table of any use?
by Chris Nighswonger 30 Jul '08

30 Jul '08

Hi all, I cannot see where the aqorderdelivery table is used except in some queries in a acquisitions_stats.pl. However, the table never appears to be populated. I'm wondering if it has any present or future purpose? If not, is there any objection to removing it? Kind Regards, -- Chris Nighswonger LibLime www.liblime.com chris.nighswonger(a)liblime.com

3 2

RFC 3.2 : Item status bulk change
by Paul POULAIN 30 Jul '08

30 Jul '08

(http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:item_statuses_bulk_…) We will add a page to bulk change the status or location of an item. The page will let you : * choose the kind of info to change * the value to set Then, the librarian with scan barcodes and all scanned items will have the data updated. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

7 10

Image-Magick replaced with GD
by Joshua Ferraro 30 Jul '08

30 Jul '08

Hi all, Just a quick heads up to developers that in line with the proposed solution to bug 2404, Image-Magick has been removed as a dependency and replaced by GD. Please bear this in mind if you're running off of a 3.0 Git repo as you may need to install these dependencies prior to upgrading to avoid any missing dependencies. 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 0

Prepackaged perl distro
by Rick Welykochy 25 Jul '08

25 Jul '08

Hi Developers, I worked in an environment where a specific set of Perl packages known to work together well with everything else, i.e. database and web services, were required to create a virtual machine. We cobbled together perl + all perl modules required. The virtual builder then simply installed perl and all the perl modules we required. No CPAN. No failed makes. No mismatches. Can't the same be done for Koha? cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor A lifetime of listening to disco music is a high price to pay for one's sexual preference. -- Quentin Crisp _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

6 17

Re: [Koha-devel] [Koha] ImageMagick
by MJ Ray 25 Jul '08

25 Jul '08

[thread moved to koha-devel] Marcel de Rooy <M.de.Rooy(a)rijksmuseum.nl> wrote: > While doing that, I had a problem installing a newer version of > ImageMagick (and PerlMagick). Koha needs 6.2. While installing one system recently, installing perlmagick pulled 109 other packages onto the system. Nearly all of the other koha dependencies were already installed, so didn't contribute to the 109. That's far too large a dependency tree for one perl module - 109 more bits we'd need to make sure work and have compatible versions. As Marcel de Rooy's message on the main koha list suggests, there may be also ongoing version-compatibility problems in ImageMagick itself. Is there any problem in principle in moving to something lighter, like a libgd-based solution? I suggest that this is a big enough bugfix to be introduced during 3.0 Comments? -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237

2 1

3.0 stable & improvements (for comments)
by Paul POULAIN 25 Jul '08

25 Jul '08

Hi folks, Look at commit : http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=64ba3ffe8309da1e10… The commit notes write : > Refine "Patrons statistics" report, fix highlight, remove CGI::scrolling_lists. > > At client request, I added code for a rowtitle_display and coltitle_display. This > allows the script to substitute human-readable lables into the table instead of just > the literal hashkeys. For this client with dozens of numerical patron categorycodes > having a row titled "29" was not very useful. I wanted to point the "at client request I added code..." 1st thought : it's an improvement, so it should not be here, as we are supposed to have only bugfixes 2nd thought : it's really minor, harmless & usefull, so it's good to have it anyway. So... once 3.0 is released, how will we deal with those cases ? Will our Release Maintainer (Joshua) decide which patches to cherry pick from head to have minor improvements ? Do we accept some improvements (I think we will have to do that : when a client request something, it's a problem to say "ok, it's minor, it's done, but it will be only available in 3.2, that will be released in X months" + if it's a sponsored feature, we (BibLibre or LibLime or anyone else probably won't be paid until the feature is available for the client) Another solution would be to have an official trunk & local versions for local clients. if I don't mind, LL don't want to do this, and BibLibre either. ideas / thought / welcomed... experience feedback : when I was RM for 2.x, I used to add minor features. What guided me : - is the improvement changing something in the DB ? if yes and very minor (like the add of a timestamp in virtualshelves table for example ;-) ), then continue investigating. If yes and not minor (adding contraints, foreign keys, indexes, "core fields", some tables...) , don't do it now. - if the improvement is changing nothing in the DB (or yes & very minor), does it change something in the API ? If yes => delay the improvement. I prefered to add some silly code to circumvent an API limit than change the API. That's the price for stability I think. If no API change => continue investigating. - will the improvement change the user experience (I don't mean improve something, but change the way Koha works). if Yes => delay the improvement. If no => continue investigating. - is the improvement correctly coded & do I feel it's OK ? Yes => OK, add it. To summarize, there can be 3 filters : DB change, API change, user experience change. Maybe not perfect + the # of devs was from far not as much as what we have now, but, at least, that was the way I tried to handle that problem. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 7