From paul.poulain at biblibre.com Wed Jun 1 09:41:13 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 01 Jun 2011 09:41:13 +0200 Subject: [Koha-devel] Hardware requirements and cluster scalability In-Reply-To: <4DDCC563.9000501@jns.fi> References: <4DDCC563.9000501@jns.fi> Message-ID: <4DE5ED19.1090008@biblibre.com> Le 25/05/2011 11:01, Olli-Antti Kivilahti a ?crit : > Good day to everybody at the devel-list. > And greetings from Finland! Hi Finland, here is France ;-) (just FYI : there is a monestary in finland that uses Koha. Ask Monk Viktor (mviktor at valamo.fi) ) > The library of Joensuu has started a project to compare different open > source library systems, mainly Koha and Evergreen, with the goal of > moving from our current closed source system to open source. We are > planning to create a consortium of minimum of a ~20 libraries, but if > open ILS are found to be superrior, probably the consortium can easily > grow to ~250 libraries with ~5 million articles and ~150 000 > transactions/hour. Our largest customer is a little bit smaller, but not that much : 48 libraries, 1.3 millions items (and 760k biblios), something like 1 million check-out per year. The hardware is a bi-quadri-core (8 cores), 12GB RAM, RAID10 hard disks (84GB used for system/koha/zebra, and 26GB used for mySQL) The server is far from being overloaded. There is no specific hard disk, and no NAS or something like that. Just take care of what I wrote on our blog : http://www.biblibre.com/en/blog/entry/mysql-default-config-and-very-large-koha-database About the pc units, we haven't changed any computer. So some are very old (5years or more). The only requirement is to be able to run Firefox. So even a winXP should be OK. The server is centralized and host the 48 libraries catalogues, that are considered as one. I don't see how you could have every library hosting their own database if you want to have a true network (ie: with easy transfers/holds/check-in/out) between branches. The OPAC can be integrated with Drupal through SOPAC. We've made the ILS-DI connector for Koha, and the ILS-DI connector for Drupal. However, if you want to investigate deeper, you should drop me a mail, there are some problems we've solved and that are not on official SOPAC (in 2 words : the sopac guys want something working with any ILS and any portal, we think it's better to use all drupal specific features) I'm not sure though that it would work well with a 5 million records database. HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chrisc at catalyst.net.nz Wed Jun 1 09:45:58 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 1 Jun 2011 19:45:58 +1200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <976151D961E4AC4CA553EF34A9FBF609648658D9@Srv-EX02.ptsecurity.ru> References: <976151D961E4AC4CA553EF34A9FBF609648658D9@Srv-EX02.ptsecurity.ru> Message-ID: <20110601074558.GI9732@rorohiko.wgtn.cat-it.co.nz> * Yury Marishev (ymarishev at ptsecurity.ru) wrote: > Dear sirs, > > > > We have detected a vulnerabilities in Koha Library Software. Please > contact us to obtain the details. > > Our disclosure policy is available here: > http://en.securitylab.ru/lab/disclosure-policy.php > > I have responded offlist, and I hope to hear the details shortly Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From paul.poulain at biblibre.com Wed Jun 1 09:47:05 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 01 Jun 2011 09:47:05 +0200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <976151D961E4AC4CA553EF34A9FBF609648658D9@Srv-EX02.ptsecurity.ru> References: <976151D961E4AC4CA553EF34A9FBF609648658D9@Srv-EX02.ptsecurity.ru> Message-ID: <4DE5EE79.2050407@biblibre.com> Le 31/05/2011 09:33, Yury Marishev a ?crit : > > Dear sirs, > > > > We have detected a vulnerabilities in Koha Library Software. Please > contact us to obtain the details. > > Our disclosure policy is available here: > http://en.securitylab.ru/lab/disclosure-policy.php > > > Hi Yury, I propose you sent a mail to Chris Cormack . He is the Release Manager for Koha 3.6, and will make a follow-up of you mail to anyone that could help -chris, you can add me in the loop- Next question: we've spoken of a mailing list for such vulnerabilities. Should we create vulnerabilities at lists.koha-communitiy.org ? I think it could be helpfull. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From kmkale at anantcorp.com Wed Jun 1 09:48:56 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Wed, 1 Jun 2011 13:18:56 +0530 Subject: [Koha-devel] Kohacon : We would love to hear your ideas and achievements Message-ID: Hi All, We would like you to share your knowledge, expertise and experience with us at Kohacon11 at VPM, Thane, India from 31st October 2011 to 2nd November 2011. Please send in your presentations. For your information please see the call for papers reproduced below.. Call for Papers The 2011 Koha Conference committee is requesting proposals for papers and presentations. Presentations should cover topics of interest to current and future users of Koha. The conference is expected to have a wide variety of attendees, including - Library administrators - Librarians - Programmers and system administrators Presentations should be approximately 45 minutes in length and allow time for questions. Presenters can expect to have Interest access and a computer projector for slides and, if necessary, a laptop computer with standard presentation software. When submitting your proposal, please include - The name and institutional affiliation of each presenter - Contact information, particularly email address - The target audience for your presentation (e.g. introductory, technical, administrative, etc.) - The proposed title of your presentation - A brief description suitable for publishing in the conference program. Descriptions should be no longer than 250 words. Author Guidelines The process for submission is Abstract followed by proposal (2 rounds of review required; first for abstract, second for proposal) Please try to submit your papers as early as possible. *The deadline forsubmissions is 15th August 2011. * Start here to submit a paper to this conference. STEP ONE OF THE SUBMISSION PROCESS ( http://kohacon11.vpmthane.org/ocs/index.php/k/k11/author/submit?requiresAuthor=1) Please feel free to contact me for any assistance, queries, offers of help, sponsorship, comments etc. My contact information is given below. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Wed Jun 1 14:20:02 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 1 Jun 2011 12:20:02 +0000 Subject: [Koha-devel] sysprefs.sql Norway Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312D1F3B@S-MAIL-1B.rijksmuseum.intra> Magnus, I rebased a patch today for installing a pref. While adding this pref to the sysprefs.sql file in the norway directory, it seems that it has not yet been updated by a few recently pushed patches. Would you mind taking a look? Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at enger.priv.no Wed Jun 1 14:35:47 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 1 Jun 2011 14:35:47 +0200 Subject: [Koha-devel] sysprefs.sql Norway In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA312D1F3B@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA312D1F3B@S-MAIL-1B.rijksmuseum.intra> Message-ID: On 1 June 2011 14:20, Marcel de Rooy wrote: > Magnus, > > I rebased a patch today for installing a pref. > > While adding this pref to the sysprefs.sql file in the norway directory, it > seems that it has not yet been updated by a few recently pushed patches. > > Would you mind taking a look? Thanks, Marcel, I will definitely take a look! But I will also say that it might be time we started looking for a better way to store the sysprefs - having them repeated over and over in files for each language seems to be asking for trouble. I'll create a bug for it, with some of my thoughts. Best regards, Magnus Enger libriotech.no From dpavlin at rot13.org Wed Jun 1 19:58:28 2011 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Wed, 1 Jun 2011 19:58:28 +0200 Subject: [Koha-devel] EAN-13 barcode support Message-ID: <20110601175828.GA7889@rot13.org> I need to develop EAN-13 barcode support in next two weeks to migrate one university library from custom software. First step should be creation of RFC document, but I didn't receive confirmation e-mail from wiki, so I can't add it there directly. I tried with this and gmail.com e-mail address, so I would be greatful if somebody could help me with that. Basically, library now uses EAN-13[1] barcode which is zero-padded primary key in old system istead of ISBN or ISSN. Since books allready have barcodes on them, we can't change it. To make things more insteresting, at least one barcode reader reports it as UPC-A[2] without first leading zero, since EAN-13 has backwards compatibility with it. So, my first question is should I store barcodes padded with zeros in Koha? It seems that itemBarcodeInputFilter syspref and small change to barcodedecode in C4/Circulation.pm will support both solutions, and it seems to be that 13-digit EAN-13 with padded zeros is cleaner solution. Next, I would need to implement plugin which generates new barcodes in same format (with check digit). This would involve change to autoBarcode syspref in cataloguing/value_builder/barcode.pl and new C4/Barcode/EAN13.pm to support next barcode while ignoring last checksum digit. Finally, we need to print them. PDF::Reuse::Barcode allready supports EAN13, so it seems that small change to C4/Labels/Label.pm would be sufficiant. Am I missing something important other than tests? :-) 1: http://en.wikipedia.org/wiki/EAN-13 2: http://en.wikipedia.org/wiki/UPC-A -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From listy-in at zatorski.net Wed Jun 1 20:20:50 2011 From: listy-in at zatorski.net (Wojciech Zatorski) Date: Wed, 01 Jun 2011 20:20:50 +0200 Subject: [Koha-devel] EAN-13 barcode support In-Reply-To: <20110601175828.GA7889@rot13.org> References: <20110601175828.GA7889@rot13.org> Message-ID: <4DE68302.7020203@zatorski.net> W dniu 2011-06-01 19:58, Dobrica Pavlinusic pisze: > I need to develop EAN-13 barcode support in next two weeks to migrate > one university library from custom software. > > First step should be creation of RFC document, but I didn't receive > confirmation e-mail from wiki, so I can't add it there directly. I tried > with this and gmail.com e-mail address, so I would be greatful if > somebody could help me with that. > > Basically, library now uses EAN-13[1] barcode which is zero-padded primary key > in old system istead of ISBN or ISSN. Since books allready have barcodes > on them, we can't change it. > > To make things more insteresting, at least one barcode reader reports it > as UPC-A[2] without first leading zero, since EAN-13 has backwards > compatibility with it. > > So, my first question is should I store barcodes padded with zeros in > Koha? It seems that itemBarcodeInputFilter syspref and small change to > barcodedecode in C4/Circulation.pm will support both solutions, and it > seems to be that 13-digit EAN-13 with padded zeros is cleaner solution. > > Next, I would need to implement plugin which generates new barcodes in > same format (with check digit). This would involve change to autoBarcode > syspref in cataloguing/value_builder/barcode.pl and new C4/Barcode/EAN13.pm > to support next barcode while ignoring last checksum digit. > > Finally, we need to print them. PDF::Reuse::Barcode allready supports > EAN13, so it seems that small change to C4/Labels/Label.pm would be sufficiant. > > Am I missing something important other than tests? :-) > > > 1: http://en.wikipedia.org/wiki/EAN-13 > 2: http://en.wikipedia.org/wiki/UPC-A > By the way... we are using EAN13 in Koha 2.2.x without problems:) All 13-digits are saved in barcode field, to print barcodes we are using php class;) -- The Main Library of Szczecin University. Computerization Department. http://bg.szczecin.pl From magnus at enger.priv.no Wed Jun 1 22:20:55 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 1 Jun 2011 22:20:55 +0200 Subject: [Koha-devel] Trouble with email in 3.4 Message-ID: Hi all! I'm having some trouble with email in both current master and 3.4.1. * The setup - EnhancedMessagingPreferences is set to "Allow" - No circulation alerts are disabled under "Item Circulation Alerts" - Turning things off and on in the "Default messaging preferences for this patron category" does not affect the outcome - Emails for the patron I'm testing is enabled for check in/check out (and shows as enabled both in the OPAC and staff client) * The symptom When check ins and check outs are done for the patron I'm testing with, no emails show up, and no messages are ever put in the message_queue table in the database. The oldest circ message in there is dated 2011-03-18, but I'm not sure how much it has been used after that. I can see some HOLD messages from 2011-04-06 and one REJECTED purchase suggestion from today, so some things are working. The problem was reported after the upgrade from 3.2.6 to 3.4.1 this last weekend. I can reproduce it on a live system running 3.4.1 (+ the most recent batch of patches on the 3.4.x branch) and on a test system running current master. * The investigation I have tried diggin around in the code, and found that in SendCirculationAlert() in C4/Circulation.pm, $borrower_preferences is empty: sub SendCirculationAlert { my ($opts) = @_; my ($type, $item, $borrower, $branch) = ($opts->{type}, $opts->{item}, $opts->{borrower}, $opts->{branch}); my %message_name = ( CHECKIN => 'Item Check-in', CHECKOUT => 'Item Checkout', ); my $borrower_preferences = C4::Members::Messaging::GetMessagingPreferences({ borrowernumber => $borrower->{borrowernumber}, message_name => $message_name{$type}, }); ... This is in turn caused by the SQL GetMessagingPreferences() in C4/Members/Messaging.pm: SELECT borrower_message_preferences.*, borrower_message_transport_preferences.message_transport_type, message_attributes.message_name, message_attributes.takes_days, message_transports.is_digest, message_transports.letter_module, message_transports.letter_code FROM borrower_message_preferences LEFT JOIN borrower_message_transport_preferences ON borrower_message_transport_preferences.borrower_message_preference_id = borrower_message_preferences.borrower_message_preference_id LEFT JOIN message_attributes ON message_attributes.message_attribute_id = borrower_message_preferences.message_attribute_id JOIN message_transports ON message_transports.message_attribute_id = message_attributes.message_attribute_id AND message_transports.message_transport_type = borrower_message_transport_preferences.message_transport_type WHERE message_attributes.message_name = 'Item Check-in' AND borrower_message_preferences.borrowernumber = 51; not retuning anything: Empty set (0.00 sec) Now I must confess that all those JOINs are making my head spin... Here are the actual contents of the tables involved in that query: mysql> select * from borrower_message_preferences where borrowernumber = 51; +--------------------------------+----------------+--------------+----------------------+-----------------+--------------+ | borrower_message_preference_id | borrowernumber | categorycode | message_attribute_id | days_in_advance | wants_digest | +--------------------------------+----------------+--------------+----------------------+-----------------+--------------+ | 56 | 51 | NULL | 2 | 0 | 0 | | 57 | 51 | NULL | 6 | NULL | 0 | | 58 | 51 | NULL | 4 | NULL | 0 | | 59 | 51 | NULL | 1 | NULL | 0 | | 60 | 51 | NULL | 5 | NULL | 0 | +--------------------------------+----------------+--------------+----------------------+-----------------+--------------+ mysql> select * from message_attributes; +----------------------+----------------+------------+ | message_attribute_id | message_name | takes_days | +----------------------+----------------+------------+ | 1 | Item_Due | 0 | | 2 | Advance_Notice | 1 | | 4 | Hold_Filled | 0 | | 5 | Item_Check_in | 0 | | 6 | Item_Checkout | 0 | +----------------------+----------------+------------+ mysql> select * from message_transports; +----------------------+------------------------+-----------+---------------+-------------+ | message_attribute_id | message_transport_type | is_digest | letter_module | letter_code | +----------------------+------------------------+-----------+---------------+-------------+ | 5 | email | 0 | circulation | CHECKIN | | 5 | sms | 0 | circulation | CHECKIN | | 6 | email | 0 | circulation | CHECKOUT | | 6 | sms | 0 | circulation | CHECKOUT | | 1 | email | 0 | circulation | DUE | | 1 | sms | 0 | circulation | DUE | | 1 | email | 1 | circulation | DUEDGST | | 1 | sms | 1 | circulation | DUEDGST | | 2 | email | 0 | circulation | PREDUE | | 2 | sms | 0 | circulation | PREDUE | | 2 | email | 1 | circulation | PREDUEDGST | | 2 | sms | 1 | circulation | PREDUEDGST | | 4 | email | 0 | reserves | HOLD | | 4 | sms | 0 | reserves | HOLD | +----------------------+------------------------+-----------+---------------+-------------+ * The questions - Is anyone else seeing the same behaviour? - Can anyone spot what's going on? I'd be happy to create a bug for this, I just thought I'd try and figure out if it *is* a bug, or if I have done something silly (again), first... Best regards, Magnus Enger libriotech.no From dpavlin at rot13.org Thu Jun 2 11:12:34 2011 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Thu, 2 Jun 2011 11:12:34 +0200 Subject: [Koha-devel] EAN-13 barcode support In-Reply-To: <4DE68302.7020203@zatorski.net> References: <20110601175828.GA7889@rot13.org> <4DE68302.7020203@zatorski.net> Message-ID: <20110602091234.GA8929@rot13.org> On Wed, Jun 01, 2011 at 08:20:50PM +0200, Wojciech Zatorski wrote: > >So, my first question is should I store barcodes padded with zeros in > >Koha? It seems that itemBarcodeInputFilter syspref and small change to > >barcodedecode in C4/Circulation.pm will support both solutions, and it > >seems to be that 13-digit EAN-13 with padded zeros is cleaner solution. > > By the way... we are using EAN13 in Koha 2.2.x without problems:) > All 13-digits are saved in barcode field, to print barcodes we are > using php class;) Ok, so I will store all 13 digits so you can have clean upgrade path :-) -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From semarie-koha at latrappe.fr Thu Jun 2 12:14:08 2011 From: semarie-koha at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie) Date: Thu, 2 Jun 2011 12:14:08 +0200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <4DE5EE79.2050407@biblibre.com> References: <976151D961E4AC4CA553EF34A9FBF609648658D9@Srv-EX02.ptsecurity.ru> <4DE5EE79.2050407@biblibre.com> Message-ID: <20110602101408.GA460@latrappe.fr> On Wed, Jun 01, 2011 at 09:47:05AM +0200, Paul Poulain wrote: > > Next question: we've spoken of a mailing list for such vulnerabilities. > Should we create vulnerabilities at lists.koha-community.org ? I think it > could be helpfull. > I think Koha project need a communication canal for security issues: currently, the only one I know is using the release manager mail... And when I look in Koha code, there are work possible in security: but should I submerge release manager for 'small' issues (like using regex for sanitization before use user variables...) whereas he has enough work with 'release manager tasks' ? I think I would be better to have 'a team' for security issues, and a place for track these. It should be: - a list, as Paul propose. - a component in bugs.koha-community.org (like 'security' or 'vulnerabilities') - any other suggestions ? Personnally, I will choose both: have a list with moderated subscription (the team security), and a component in bugzilla (where the list is the default assignee). The list, for reporting and discussion about issues (some may need conceptual modifications), and the bugzilla component for tracking. It seems to me, that bugzilla could mark bug as confidencial. This would permit a minimum of discretion before bug correction. But it should be public after patching or releasing. -- Fr?re S?bastien Marie Abbaye Notre Dame de La Trappe 61380 Soligny-la-Trappe T?l: 02.33.84.17.00 Fax: 02.33.34.98.57 Web: http://www.latrappe.fr/ From cnighswonger at foundations.edu Thu Jun 2 19:56:02 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 2 Jun 2011 13:56:02 -0400 Subject: [Koha-devel] Koha 3.2.x String Freeze Message-ID: Hi all, The 3.2.x branch is in a string freeze for the 3.2.10 release as of the time of this email. I'm a few hours late, but needed to catch up on pushing some changes to the main repo. Keep in mind that 3.2.10 will most likely be the final release of the 3.2.x branch. Kind Regards, Chris From chris at bigballofwax.co.nz Thu Jun 2 21:10:19 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 3 Jun 2011 07:10:19 +1200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <20110602101408.GA460@latrappe.fr> References: <976151D961E4AC4CA553EF34A9FBF609648658D9@Srv-EX02.ptsecurity.ru> <4DE5EE79.2050407@biblibre.com> <20110602101408.GA460@latrappe.fr> Message-ID: 2011/6/2 Fr?re S?bastien : > On Wed, Jun 01, 2011 at 09:47:05AM +0200, Paul Poulain wrote: >> >> Next question: we've spoken of a mailing list for such vulnerabilities. >> Should we create vulnerabilities at lists.koha-community.org ? I think it >> could be helpfull. >> > > I think Koha project need a communication canal for security issues: currently, the only one I know is using the release manager mail... > > And when I look in Koha code, there are work possible in security: but should I submerge release manager for 'small' issues (like using regex for sanitization before use user variables...) whereas he has enough work with 'release manager tasks' ? > > I think I would be better to have 'a team' for security issues, and a place for track these. > > It should be: > ?- a list, as Paul propose. > ?- a component in bugs.koha-community.org (like 'security' or 'vulnerabilities') > ?- any other suggestions ? > > Personnally, I will choose both: have a list with moderated subscription (the team security), and a component in bugzilla (where the list is the default assignee). > > The list, for reporting and discussion about issues (some may need conceptual modifications), and the bugzilla component for tracking. > > It seems to me, that bugzilla could mark bug as confidencial. This would permit a minimum of discretion before bug correction. But it should be public after patching or releasing. > I like these ideas. Do we have any dissenting opinions or should we make it so? In talking to my friends who work in security, they suggest a page prominently displayed somewhere that tells people how to let us know about security issues. Also never feel like you are bothering me, I would always, always rather know of any problems than not, So for the time being, if you know of any issues, let me know. You can gpg encrypt the mail using my gpg key if you wish. But lets get a more formal and documented process set up. Chris From robin at catalyst.net.nz Thu Jun 2 23:11:17 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 03 Jun 2011 09:11:17 +1200 Subject: [Koha-devel] Koha Library Software In-Reply-To: References: <976151D961E4AC4CA553EF34A9FBF609648658D9@Srv-EX02.ptsecurity.ru> <20110602101408.GA460@latrappe.fr> Message-ID: <201106030911.27178.robin@catalyst.net.nz> Op vrijdag 3 juni 2011 07:10:19 schreef Chris Cormack: > I like these ideas. Do we have any dissenting opinions or should we make it > so? This method is pretty much the same as it's done in a number of other projects (e.g. Mozilla, Ubuntu), and it seems to work well for the most part. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mjr at phonecoop.coop Fri Jun 3 12:03:50 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 3 Jun 2011 11:03:50 +0100 (BST) Subject: [Koha-devel] Koha Library Software In-Reply-To: Message-ID: <20110603100350.B27E09F0D2@nail.towers.org.uk> Chris Cormack wrote: > 2011/6/2 Fr?re S?bastien : > > On Wed, Jun 01, 2011 at 09:47:05AM +0200, Paul Poulain wrote: > >> Next question: we've spoken of a mailing list for such > >> vulnerabilities. Should we create > >> vulnerabilities at lists.koha-community.org ? I think it could be > >> helpfull. > > > > I think Koha project need a communication canal for security > > issues: currently, the only one I know is using the release > > manager mail... [...] > > Personnally, I will choose both: have a list with moderated > > subscription (the team security), and a component in bugzilla > > (where the list is the default assignee). [...] > I like these ideas. Do we have any dissenting opinions or should we > make it so? Please, no closed list for development discussions. If someone finds a security vulnerability and has a support provider, they should tell them. If they do not, contact the project release manager - hopefully we always have release managers who value security highly. I'd encourage everyone to practice full disclosure and discuss them on the BTS or koha-devel as much as possible. Hope that explains, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From robin at catalyst.net.nz Fri Jun 3 14:29:32 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Sat, 04 Jun 2011 00:29:32 +1200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <20110603100350.B27E09F0D2@nail.towers.org.uk> References: <20110603100350.B27E09F0D2@nail.towers.org.uk> Message-ID: <201106040029.41512.robin@catalyst.net.nz> Op vrijdag 3 juni 2011 22:03:50 schreef MJ Ray: > Please, no closed list for development discussions. If someone finds > a security vulnerability and has a support provider, they should > tell them. If they do not, contact the project release manager - > hopefully we always have release managers who value security highly. That's not really possible for people outside the project to figure out easily. We want to make it as easy as possible for vulnerabilities to be reported. > I'd encourage everyone to practice full disclosure and discuss them on > the BTS or koha-devel as much as possible. That's not how responsible disclosure (which is distinct from, and an improvement upon full disclosure) works. Typically you want as few people as possible to know about the vulnerability until it's been patched and released. This keeps the users as secure as is reasonably possible. The standard approach, taken by many open source projects, is to have some really easy way of confidentially reporting vulnerabilities, these are then resolved and released, at which point an announcement is made. Ideally this announcement consists of a workaround if possible, a patch for older versions (if you can't upgrade for some reason), and a release with that patch included. This ensures that the risk of an active exploit finding it's way into the wild is reduced before people have a reasonable chance to do something about it. This is one of the few situations where I think development in private, or at least semi-private, is a good thing. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From oleonard at myacpl.org Fri Jun 3 14:38:11 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Fri, 3 Jun 2011 08:38:11 -0400 Subject: [Koha-devel] Koha Library Software In-Reply-To: <201106040029.41512.robin@catalyst.net.nz> References: <20110603100350.B27E09F0D2@nail.towers.org.uk> <201106040029.41512.robin@catalyst.net.nz> Message-ID: > Op vrijdag 3 juni 2011 22:03:50 schreef MJ Ray: >> Please, no closed list for development discussions. We're not talking about a secret cabal of self-chosen list members (anymore). Koha now has an (informally) elected list of officers who can be on the list: Release manager, release maintainer, QA manager. Let's keep it as simple as that. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From magnus at enger.priv.no Fri Jun 3 14:39:32 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Fri, 3 Jun 2011 14:39:32 +0200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <201106040029.41512.robin@catalyst.net.nz> References: <20110603100350.B27E09F0D2@nail.towers.org.uk> <201106040029.41512.robin@catalyst.net.nz> Message-ID: 2011/6/3 Robin Sheat : > This is one of the few situations where I think development in private, or at > least semi-private, is a good thing. +1 Best regards, Magnus Enger libriotech.no From ian.walls at bywatersolutions.com Fri Jun 3 15:11:33 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Fri, 3 Jun 2011 09:11:33 -0400 Subject: [Koha-devel] Koha Library Software In-Reply-To: References: <20110603100350.B27E09F0D2@nail.towers.org.uk> <201106040029.41512.robin@catalyst.net.nz> Message-ID: It would be hard for a sekrit society of developers to push through any changes that aren't documented publicly; we can all see the commit stream to Git, and if there are a sudden burst of patches being committed that violate the community's agreed-upon practices for submission and review, the community can call shenanigans on the person(s) doing the commits. In the case of any critical security fix, it would be the Release Manager's and Release Maintainers' responsibilities to justify the change set and the deviation from standard procedure; this is probably going to be as simple as "fixes this security issue" in the commit message. Once it's committed, a more robust report can be written up somewhere and linked. I don't think we're going to encounter these kinds of security issues often, so building a complex process to handle them seems counter-productive. I'd rather spend the time just finding/fixing any such issues. -Ian On Fri, Jun 3, 2011 at 8:38 AM, Owen Leonard wrote: > > Op vrijdag 3 juni 2011 22:03:50 schreef MJ Ray: > >> Please, no closed list for development discussions. > > We're not talking about a secret cabal of self-chosen list members > (anymore). Koha now has an (informally) elected list of officers who > can be on the list: Release manager, release maintainer, QA manager. > Let's keep it as simple as that. > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianjcj at gmail.com Fri Jun 3 17:53:10 2011 From: christianjcj at gmail.com (Christian Calle Jahuira) Date: Fri, 3 Jun 2011 11:53:10 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 Message-ID: It is a pleasure to find KOHA community greatly strengthened. Write to La Paz Bolivia, I have implemented KOHA version 3.0, my question is about the advantages of KOHA 4 and LibLime, which presents differences. Atte -- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: christianjcj at gmail.com Cel: 73017301 - 65151595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Fri Jun 3 18:00:18 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Fri, 3 Jun 2011 12:00:18 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: > my question is about the advantages of KOHA 4 and LibLime, > which presents differences. The advantage of using Koha (the latest version of which is 3.4.1) is that it's part of a real open source project backed by a community of developers from around the world. Koha will always be free software and its development will always be done out in the open. "Liblime Koha," which has been arbitrarily given the version number 4, is the product of a single company which is openly hostile to the Koha community. As far as I'm concerned that's all you need to know. No feature differences between the two would be enough for me to ever recommend "Liblime Koha" over the real thing. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From nengard at gmail.com Fri Jun 3 18:01:52 2011 From: nengard at gmail.com (Nicole Engard) Date: Fri, 3 Jun 2011 12:01:52 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: PS. It's Koha (as Owen wrote it) not KOHA (sorry pet peeve of mine) - it's a word and not an acronym - if you're interested in learning more about the origin of the name check this out: http://bywatersolutions.com/2010/10/15/what-is-a-koha/ Nicole On Fri, Jun 3, 2011 at 12:00 PM, Owen Leonard wrote: >> my question is about the advantages of KOHA 4 and LibLime, >> which presents differences. > > The advantage of using Koha (the latest version of which is 3.4.1) is > that it's part of a real open source project backed by a community of > developers from around the world. Koha will always be free software > and its development will always be done out in the open. > > "Liblime Koha," which has been arbitrarily given the version number 4, > is the product of a single company which is openly hostile to the Koha > community. > > As far as I'm concerned that's all you need to know. No feature > differences between the two would be enough for me to ever recommend > "Liblime Koha" over the real thing. > > ?-- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > From cfouts at liblime.com Fri Jun 3 19:07:22 2011 From: cfouts at liblime.com (Clay Fouts) Date: Fri, 3 Jun 2011 10:07:22 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: Greetings, Christian. Referring to the code bases, I don't know of a point-by-point feature comparison between the various forks. However, LibLime does provide feature notes for the recent 4.2 release, available at http://www.koha.org/library/resources/LibLimeKoha4.2ReleaseNotes.pdf. You can check out the code directly in our public Git repository at https://github.com/liblime/LibLime-Koha. Cheers, Clay 2011/6/3 Christian Calle Jahuira > It is a pleasure to find KOHA community greatly strengthened. > > Write to La Paz Bolivia, I have implemented KOHA version 3.0, > my question is about the advantages of KOHA 4 and LibLime, > which presents differences. > > Atte > > -- > Christian Jhonny Calle Jahuira > TUTOR ELEARNING - UMSA > Consultor Sistemas de Informacion de Bibliotecas de la UMSA > Email: christianjcj at gmail.com > Cel: 73017301 - 65151595 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Fri Jun 3 21:15:40 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Fri, 3 Jun 2011 15:15:40 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: 2011/6/3 Clay Fouts : > Referring to the code bases, I don't know of a point-by-point feature > comparison between the various forks. Between your fork and Koha, you mean? No, but here's a notable single comparison: "Liblime Koha:" https://github.com/liblime/LibLime-Koha/blob/4_02/koha-tmpl/intranet-tmpl/prog/en/modules/about.tmpl Koha: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=koha-tmpl/intranet-tmpl/prog/en/modules/about.tt;h=bfa17e227a4331266437562fc64284b7c918f4e2;hb=HEAD "Liblime Koha" is curiously missing the list of contributors to the "open source" software they're offering. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From ian.walls at bywatersolutions.com Fri Jun 3 21:33:16 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Fri, 3 Jun 2011 15:33:16 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: On Fri, Jun 3, 2011 at 12:00 PM, Owen Leonard wrote: > > my question is about the advantages of KOHA 4 and LibLime, > > which presents differences. > > The advantage of using Koha (the latest version of which is 3.4.1) is > that it's part of a real open source project backed by a community of > developers from around the world. Koha will always be free software > and its development will always be done out in the open. > > Owen brings up the most important point here: Koha has a community around it, while LK only has LibLime. Anyone in the world can contribute to Koha, either with patches sent to the patches mailing list [1], with bug reports filed in the Bugzilla database [2], by sharing reports/jqueries/tips/tricks on either the discussion list [3], wiki [4] or newsletter [5], or by participation in IRC discussion [6]. LK has none of those community tools (at least not anywhere where I could find them!). A statistical work up of the two codebases has been done recently, which is interesting for what it's worth [7]. One can watch Koha's codebase grow daily [8]. LK, like it's predecessor Harley, seems to be a static release rather than a living, growing organism, though I've been told that LibLime does have versions 4.4 and 4.6 in use for their clients (though not released as open source at this time). As a Koha developer and officer, I'll readily admit my bias, but hopefully the links below, as well as other posts on this thread, can help folks make their own decisions. Cheers, -Ian 1. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-patches 2. http://bugs.koha-community.org 3. http://lists.katipo.co.nz/mailman/listinfo/koha 4. http://wiki.koha-community.org 5. http://koha-community.org/category/koha-newsletter/ 6. http://stats.workbuffer.org/irclog/koha/ 7. http://blog.bigballofwax.co.nz/2011/05/24/i-love-pulling-statistics-out-of-git/ 8. http://git.koha-community.org/gitweb/?p\x3dkoha.git;a\x3drss -- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mason at kohaaloha.com Sat Jun 4 03:53:58 2011 From: mason at kohaaloha.com (James, Mason) Date: Sat, 4 Jun 2011 13:53:58 +1200 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: On 2011-06-4, at 5:07 AM, Clay Fouts wrote: > Greetings, Christian. > > Referring to the code bases, I don't know of a point-by-point feature comparison between the various forks. slightly off-topic... ohloh.com has some pretty graph comparisons (code, commits, committers, languages, etc) between Koha and the ptfs/liblime fork, https://www.ohloh.net/p/koha https://www.ohloh.net/p/Koha-PTFS-Liblime > You can check out the code directly in our public Git repository at https://github.com/liblime/LibLime-Koha. thats great, but how do people submit enhancements to the ptfs/liblime project? Mason From mason at kohaaloha.com Sat Jun 4 04:49:54 2011 From: mason at kohaaloha.com (James, Mason) Date: Sat, 4 Jun 2011 14:49:54 +1200 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: <0B34D8B0-D600-4FE5-BE03-FA2900288D18@kohaaloha.com> On 2011-06-4, at 4:00 AM, Owen Leonard wrote: >> my question is about the advantages of KOHA 4 and LibLime, >> which presents differences. as other people before have pointed out - there is *not* an official Koha 4.x release... yet ;) (Koha is currently still releasing on version 3.x) it's also very disrespectful to the Koha project (and confusing), for ptfs/liblime to claim their fork's release as 'Koha 4' https://github.com/liblime/LibLime-Koha/blob/4_02/INSTALL "Koha 4.2 - the next-generation release of the award-winning Koha open-source integrated library system." ... and then remove all Koha contributor names from the 'about' page (wtf?!?) https://github.com/liblime/LibLime-Koha/commit/80cccbd027a950152114a69e233f913e08e204a5#koha-tmpl/intranet-tmpl/prog/en/modules/about.tmpl hope that helps, Mason From cfouts at liblime.com Sat Jun 4 09:13:13 2011 From: cfouts at liblime.com (Clay Fouts) Date: Sat, 4 Jun 2011 00:13:13 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: Github makes patch submission very easy. The typical process is to fork the repository, commit your changes to your own fork (often on a topic branch), then submit a pull request to the maintainer of the forked project. The web interface provides simple buttons for forking (e.g. the LK-4.2 fork link is https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. The maintainer receives notification of the pull request and can then opt to merge the new commits back into the original repository. The service offers a nice interface to the whole code management process and provides additional features for discussing patches, providing line-by-line commentary, basic issue tracking, docs wiki, and so on. They offer public repositories for free, so there's a very low barrier to entry for open source developers. Internally we have released LK-4.4 and 4.6 into production and are now working on development branch 4.7. These are not publicly accessible, and that makes development of larger features pretty tricky if you're working on the 4.2 release as your base. Anyone interested in creating a more involved feature and ensuring it can be easily ported to future releases should consult us for pointers as there are notable architectural and schema differences. Regards, Clay On Fri, Jun 3, 2011 at 6:53 PM, James, Mason wrote: > > On 2011-06-4, at 5:07 AM, Clay Fouts wrote: > > > Greetings, Christian. > > > > Referring to the code bases, I don't know of a point-by-point feature > comparison between the various forks. > > slightly off-topic... > > ohloh.com has some pretty graph comparisons (code, commits, committers, > languages, etc) between Koha and the ptfs/liblime fork, > > https://www.ohloh.net/p/koha > https://www.ohloh.net/p/Koha-PTFS-Liblime > > > > You can check out the code directly in our public Git repository at > https://github.com/liblime/LibLime-Koha. > > thats great, but how do people submit enhancements to the ptfs/liblime > project? > > > Mason > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Sat Jun 4 09:32:09 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 4 Jun 2011 19:32:09 +1200 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: 2011/6/4 Clay Fouts : > Github makes patch submission very easy. The typical process is to fork the > repository, commit your changes to your own fork (often on a topic branch), > then submit a pull request to the maintainer of the forked project. The web > interface provides simple buttons for forking (e.g. the LK-4.2 fork link is > https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. The > maintainer receives notification of the pull request and can then opt to > merge the new commits back into the original repository. > The service offers a nice interface to the whole code management process and > provides additional features for discussing patches, providing line-by-line > commentary, basic issue tracking, docs wiki, and so on. They offer public > repositories for free, so there's a very low barrier to entry for open > source developers. > > Internally we have released LK-4.4 and 4.6 into production and are now > working on development branch 4.7. These are not publicly accessible, and > that makes development of larger features pretty tricky if you're working on > the 4.2 release as your base. Anyone interested in creating a more involved > feature and ensuring it can be easily ported to future releases should > consult us for pointers as there are notable architectural and schema > differences. Right, perhaps we should move this off the Koha lists, Liblime run their own lists for their project. This discussion about how to contribute to the Liblime project is better there. Its fairly clear from Clays message, and comments on my blog etc that what Liblime is developing is not Koha, and has diverged significantly. So I say lets just keep discussion about Koha here, and unless the discussion turns to how to reconcile the fork with the Koha project, leave discussion of Liblime's Project for their own lists. We don't discuss Koha on the Evergreen lists, and OPALS don't discuss their project on the Koha lists. Liblime have their own project with their own lists, lets leave them to it and get back to focusing on Koha. Chris From massoud at kwareict.com Sat Jun 4 15:56:48 2011 From: massoud at kwareict.com (massoud alshareef) Date: Sat, 4 Jun 2011 16:56:48 +0300 Subject: [Koha-devel] Koha-devel Digest, Vol 67, Issue 7 In-Reply-To: References: Message-ID: I second Chris's thought. There is only one community-driven OSS Koha! Thanks Massoud M. AlShareef, KnowledgeWare On Sat, Jun 4, 2011 at 1:00 PM, wrote: > Send Koha-devel mailing list submissions to > koha-devel at lists.koha-community.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > or, via email, send a message with subject or body 'help' to > koha-devel-request at lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner at lists.koha-community.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Koha-devel digest..." > > > Today's Topics: > > 1. Re: KOHA version 3.0, my question is about the advantages of > KOHA 4 (Chris Cormack) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 4 Jun 2011 19:32:09 +1200 > From: Chris Cormack > Subject: Re: [Koha-devel] KOHA version 3.0, my question is about the > advantages of KOHA 4 > To: Clay Fouts > Cc: koha-devel at lists.koha-community.org > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > 2011/6/4 Clay Fouts : > > Github makes patch submission very easy. The typical process is to fork > the > > repository, commit your changes to your own fork (often on a topic > branch), > > then submit a pull request to the maintainer of the forked project. The > web > > interface provides simple buttons for forking (e.g. the LK-4.2 fork link > is > > https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. > The > > maintainer receives notification of the pull request and can then opt to > > merge the new commits back into the original repository. > > The service offers a nice interface to the whole code management process > and > > provides additional features for discussing patches, providing > line-by-line > > commentary, basic issue tracking, docs wiki, and so on. They offer public > > repositories for free, so there's a very low barrier to entry for open > > source developers. > > > > Internally we have released LK-4.4 and 4.6 into production and are now > > working on development branch 4.7. These are not publicly accessible, and > > that makes development of larger features pretty tricky if you're working > on > > the 4.2 release as your base. Anyone interested in creating a more > involved > > feature and ensuring it can be easily ported to future releases should > > consult us for pointers as there are notable architectural and schema > > differences. > > Right, perhaps we should move this off the Koha lists, Liblime run > their own lists for their project. This discussion about how to > contribute to the Liblime project is better there. > > Its fairly clear from Clays message, and comments on my blog etc that > what Liblime is developing is not Koha, and has diverged > significantly. So I say lets just keep discussion about Koha here, and > unless the discussion turns to how to reconcile the fork with the Koha > project, leave discussion of Liblime's Project for their own lists. > We don't discuss Koha on the Evergreen lists, and OPALS don't discuss > their project on the Koha lists. Liblime have their own project with > their own lists, lets leave them to it and get back to focusing on > Koha. > > Chris > > > ------------------------------ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > End of Koha-devel Digest, Vol 67, Issue 7 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpavlin at rot13.org Sat Jun 4 17:08:22 2011 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Sat, 4 Jun 2011 17:08:22 +0200 Subject: [Koha-devel] EAN-13 barcode support In-Reply-To: <20110601175828.GA7889@rot13.org> References: <20110601175828.GA7889@rot13.org> Message-ID: <20110604150822.GA23460@rot13.org> I have made some progress this week. Changes are available at: http://git.rot13.org/?p=koha.git;a=log;h=refs/heads/koha-6448-EAN-13_barcode Curretly, they are split into several patches. Should I merge all the changes together before attaching it to related bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448 or attach them one-by-one? Should I open separate bugs for itemBarcodeInputFilter, autoBarcode and label support? On Wed, Jun 01, 2011 at 07:58:28PM +0200, Dobrica Pavlinusic wrote: > First step should be creation of RFC document, but I didn't receive > confirmation e-mail from wiki, so I can't add it there directly. I tried > with this and gmail.com e-mail address, so I would be greatful if > somebody could help me with that. I still haven't received any wiki confirmation, so I'm spamming devel list. I hope you don't mind :-) -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From mason at kohaaloha.com Mon Jun 6 04:00:36 2011 From: mason at kohaaloha.com (James, Mason) Date: Mon, 6 Jun 2011 14:00:36 +1200 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: Message-ID: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> On 2011-06-4, at 7:13 PM, Clay Fouts wrote: > Github makes patch submission very easy. The typical process is to fork the repository, commit your changes to your own fork (often on a topic branch), then submit a pull request to the maintainer of the forked project. The web interface provides simple buttons for forking (e.g. the LK-4.2 fork link is https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. The maintainer receives notification of the pull request and can then opt to merge the new commits back into the original repository. > > The service offers a nice interface to the whole code management process and provides additional features for discussing patches, providing line-by-line commentary, basic issue tracking, docs wiki, and so on. They offer public repositories for free, so there's a very low barrier to entry for open source developers. > > Internally we have released LK-4.4 and 4.6 into production and are now working on development branch 4.7. These are not publicly accessible, and that makes development of larger features pretty tricky if you're working on the 4.2 release as your base. Anyone interested in creating a more involved feature and ensuring it can be easily ported to future releases should consult us for pointers as there are notable architectural and schema differences. > > Regards, > Clay > thanks for that Clay, thats great info so, do PTFS/Liblime have any plans to submit their client-funded features/enhancements back into the Koha codebase... or not? Mason From mjr at phonecoop.coop Mon Jun 6 11:17:18 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 6 Jun 2011 10:17:18 +0100 (BST) Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: Message-ID: <20110606091718.6875FF6605@nail.towers.org.uk> Christian Calle Jahuira wrote: > Write to La Paz Bolivia, I have implemented KOHA version 3.0, > my question is about the advantages of KOHA 4 and LibLime, > which presents differences. The latest version is Koha 3.4. There is no Koha 4 yet. LibLime is trying to pass off their LMS as Koha, but it is not Koha. Do not be tricked! Koha would not delete its contibutor credits. As I understand it, LibLime 4.2 is actually a fork around Koha 3.0, which was the last version release-managed by someone from LibLime (oh the pain) and was end-of-lifed by koha-community last month, as in http://lists.koha-community.org/pipermail/koha-devel/2011-May/035542.html Also, I think that the public LibLime 4.2 is not current, with their customers using later versions. So their public version is already obsolete by its publisher and based on a now-unsupported community release, so why would anyone use it unless forced or daft? This seems like a repeat of the trick when LibLime started selling "Enterprise Koha" - and where is that now? ;-) Koha 3.4 is clearly the place to be. The big feature there is the improved template system, but since 3.0, the acquisitions module is significantly revamped, the system preferences editor is easier to use, there's bulk item editing, better reports, serials and cataloguing, more connections to other systems, more localisaton, tons of small bugs fixed and more that you can find in the release notes. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From mjr at phonecoop.coop Mon Jun 6 10:34:17 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 6 Jun 2011 09:34:17 +0100 (BST) Subject: [Koha-devel] Koha Library Software In-Reply-To: <201106040029.41512.robin@catalyst.net.nz> Message-ID: <20110606084252.022CA9F0D3@nail.towers.org.uk> Robin Sheat wrote: > Op vrijdag 3 juni 2011 22:03:50 schreef MJ Ray: > > Please, no closed list for development discussions. If someone finds > > a security vulnerability and has a support provider, they should > > tell them. If they do not, contact the project release manager - > > hopefully we always have release managers who value security highly. > > That's not really possible for people outside the project to figure out > easily. We want to make it as easy as possible for vulnerabilities to be > reported. So let's document the current practice and make it easier? Changing the process, adding more steps and special bug cases seems wrong. > > I'd encourage everyone to practice full disclosure and discuss them on > > the BTS or koha-devel as much as possible. > > That's not how responsible disclosure (which is distinct from, and an > improvement upon full disclosure) works. Typically you want as few people as > possible to know about the vulnerability until it's been patched and released. > This keeps the users as secure as is reasonably possible. Delayed disclosure (the neutral name for what you describe, because it is highly irresponsible in the eyes of full-disclosure supporters) has often gone too far and resulted in people trying to keep problems secret for far too long, like until every vulnerable system is patched. There are also the risks that someone inside the privileged group leaks information to attackers, while good people outside that privileged group don't even know that there's a problem. Basically, what type of people are we? Would we tell our neighbours that their homes are insecure when there's a burglar about? Or would we keep quiet until we figured out how to secure our own home first? As far as I know, early all of the vulnerabilities that Koha has suffered have been discoverable with fairly simple tools if you knew where to point them - most have needed some access to intranet or related websites, thankfully. > The standard approach, taken by many open source projects, is to have some > really easy way of confidentially reporting vulnerabilities, these are then > resolved and released, at which point an announcement is made. [...] I don't think there is any such standard (got a link?). Yes, many "open source" projects are really closed when it comes to security, but popularity is not a good argument for something, else Koha would almost never be adopted. The disagreement between full and delayed disclosure has been going on in general for at least 150 years, and over 20 for internet security. We're probably not going to change each others' views, but at least know that not everyone wants delayed disclosure. Hope that explains, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From mjr at phonecoop.coop Mon Jun 6 11:28:31 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 6 Jun 2011 10:28:31 +0100 (BST) Subject: [Koha-devel] EAN-13 barcode support In-Reply-To: <20110604150822.GA23460@rot13.org> Message-ID: <20110606092831.3034CF6619@nail.towers.org.uk> Dobrica Pavlinusic wrote: > Curretly, they are split into several patches. Should I merge all the > changes together before attaching it to related bug > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448 > or attach them one-by-one? I think either is fine, but maybe the RMs have an opinion? > Should I open separate bugs for itemBarcodeInputFilter, autoBarcode and label support? I don't think I would, if the fixes are related. > On Wed, Jun 01, 2011 at 07:58:28PM +0200, Dobrica Pavlinusic wrote: > > First step should be creation of RFC document, but I didn't receive > > confirmation e-mail from wiki, so I can't add it there directly. I tried > > with this and gmail.com e-mail address, so I would be greatful if > > somebody could help me with that. > > I still haven't received any wiki confirmation, so I'm spamming devel > list. I hope you don't mind :-) No, that's fine. The wiki is currently crippled by http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6326 and we're a bit limited in who can fix it. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From fridolyn.somers at gmail.com Mon Jun 6 12:29:45 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 6 Jun 2011 12:29:45 +0200 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <20110606091718.6875FF6605@nail.towers.org.uk> References: <20110606091718.6875FF6605@nail.towers.org.uk> Message-ID: Juste for information : The demo form LibLime website provides the revision number in "About" module : * Koha version: 3.01.00.039 with LibLime Enterprise Koha build: 4.0600001* On Mon, Jun 6, 2011 at 11:17 AM, MJ Ray wrote: > Christian Calle Jahuira wrote: > > Write to La Paz Bolivia, I have implemented KOHA version 3.0, > > my question is about the advantages of KOHA 4 and LibLime, > > which presents differences. > > The latest version is Koha 3.4. There is no Koha 4 yet. > LibLime is trying to pass off their LMS as Koha, but it is not Koha. > Do not be tricked! Koha would not delete its contibutor credits. > > As I understand it, LibLime 4.2 is actually a fork around Koha 3.0, > which was the last version release-managed by someone from LibLime (oh > the pain) and was end-of-lifed by koha-community last month, as in > http://lists.koha-community.org/pipermail/koha-devel/2011-May/035542.html > > Also, I think that the public LibLime 4.2 is not current, with their > customers using later versions. So their public version is already > obsolete by its publisher and based on a now-unsupported community > release, so why would anyone use it unless forced or daft? > > This seems like a repeat of the trick when LibLime started selling > "Enterprise Koha" - and where is that now? ;-) > > Koha 3.4 is clearly the place to be. The big feature there is the > improved template system, but since 3.0, the acquisitions module is > significantly revamped, the system preferences editor is easier to > use, there's bulk item editing, better reports, serials and > cataloguing, more connections to other systems, more localisaton, tons > of small bugs fixed and more that you can find in the release notes. > > Hope that informs, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for various work through http://www.software.coop/ > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From M.de.Rooy at rijksmuseum.nl Mon Jun 6 15:35:16 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 6 Jun 2011 13:35:16 +0000 Subject: [Koha-devel] Z3950 search/UNIMARC Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312D2FFA@S-MAIL-1B.rijksmuseum.intra> Hi all, I am testing some changes in z3950_search.pl and I am wondering if the default Koha z3950 script correctly functions for unimarc targets (with marcflavor to unimarc as well of course). Could anyone of you using z3950 with unimarc reply on that? Is the MARC and Card view on the results screen correct too? Did you encounter problems with encodings? MARC-8, UTF-8, etc.? I tested with carmin.sudoc.abes.fr z3950 target? Could you recommend another one? Thanks for some feedback, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Mon Jun 6 15:23:23 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Tue, 07 Jun 2011 01:23:23 +1200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <20110606084252.022CA9F0D3@nail.towers.org.uk> References: <20110606084252.022CA9F0D3@nail.towers.org.uk> Message-ID: <201106070123.24032.robin@catalyst.net.nz> Op maandag 6 juni 2011 20:34:17 schreef MJ Ray: > So let's document the current practice and make it easier? Changing > the process, adding more steps and special bug cases seems wrong. No it doesn't. (If you can claim something in that manner, so can I :) > Delayed disclosure (the neutral name for what you describe, because it That's not neutral at all. > is highly irresponsible in the eyes of full-disclosure supporters) has > often gone too far and resulted in people trying to keep problems > secret for far too long, like until every vulnerable system is > patched. Well then you establish a policy that doesn't have those issues. Problem solved. > There are also the risks that someone inside the privileged > group leaks information to attackers, while good people outside that > privileged group don't even know that there's a problem. If you release everything in a full disclosure manner, you give the attackers information without getting it (and a fix) first to the people who have something to defend and will require a bit of time to do so. I think that's a bigger, actual risk than a hypothetical risk of disclosure. If you discover it's already in use in the wild, then you release immediately, falling back to full disclosure mode. Best of both worlds. > Basically, what type of people are we? Would we tell our neighbours > that their homes are insecure when there's a burglar about? Or would > we keep quiet until we figured out how to secure our own home first? You're making a strawman argument. In particular the "there's a burglar about" bit. In this case, there isn't. > As far as I know, early all of the vulnerabilities that Koha has > suffered have been discoverable with fairly simple tools if you knew > where to point them - Yes, but (afaik) they are generally discovered long after they're implemented, which suggests that this doesn't happen a lot. > most have needed some access to intranet or > related websites, thankfully. That's more good luck than good management. > I don't think there is any such standard (got a link?). Yes, many > "open source" projects are really closed when it comes to security, > but popularity is not a good argument for something, else Koha would > almost never be adopted. They're not closed. They're just not so open their brains fall out. They (in general, and I'm sure there are pathalogical examples too) simply try to ensure that a fix is available at the same time the attack information is available. Personally, I'm something of a fan of something along the lines of the policy described here: http://web.archive.org/web/20100813161135/http://www.wiretrip.net/rfp/policy.html As an example, if you report a security issue on the Mozilla bug tracker, the bug is closed by default until a fix is released. Then it's opened. http://www.mozilla.org/projects/security/security-bugs-policy.html This is far more involved than anything I'd suggest for Koha however. My main concern is to avoid the world at large knowing how to exploit Koha before anyone can quickly work around the issue (I might know how to mitigate a SQL injection, but I go to one or two security conferences a year. Not everyone does.) > The disagreement between full and delayed disclosure has been going on > in general for at least 150 years, and over 20 for internet security. > We're probably not going to change each others' views, but at least > know that not everyone wants delayed disclosure. As someone who deploys Koha systems, I'd like to see a release of a fix with an announcement so that I know I need to update now, and the information required to do so is immediately available. If it's a difficult fix, then I'd consider something that mitigates the issue to be acceptable. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From cfouts at liblime.com Mon Jun 6 17:06:47 2011 From: cfouts at liblime.com (Clay Fouts) Date: Mon, 6 Jun 2011 08:06:47 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: We do not in general make an effort to coordinate our work with other code bases, nor attempt to port our code over to them. The source is however available for all to see. Upon release from the sponsoring customer, we publish the source code for anyone to work whichever pieces they want into whatever code base they manage. Clay On Sun, Jun 5, 2011 at 7:00 PM, James, Mason wrote: > > On 2011-06-4, at 7:13 PM, Clay Fouts wrote: > > > Github makes patch submission very easy. The typical process is to fork > the repository, commit your changes to your own fork (often on a topic > branch), then submit a pull request to the maintainer of the forked project. > The web interface provides simple buttons for forking (e.g. the LK-4.2 fork > link is https://github.com/liblime/LibLime-Koha/fork) and issuing pull > requests. The maintainer receives notification of the pull request and can > then opt to merge the new commits back into the original repository. > > > > The service offers a nice interface to the whole code management process > and provides additional features for discussing patches, providing > line-by-line commentary, basic issue tracking, docs wiki, and so on. They > offer public repositories for free, so there's a very low barrier to entry > for open source developers. > > > > Internally we have released LK-4.4 and 4.6 into production and are now > working on development branch 4.7. These are not publicly accessible, and > that makes development of larger features pretty tricky if you're working on > the 4.2 release as your base. Anyone interested in creating a more involved > feature and ensuring it can be easily ported to future releases should > consult us for pointers as there are notable architectural and schema > differences. > > > > Regards, > > Clay > > > > > thanks for that Clay, thats great info > > so, do PTFS/Liblime have any plans to submit their client-funded > features/enhancements back into the Koha codebase... or not? > > > Mason -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfouts at liblime.com Mon Jun 6 17:17:34 2011 From: cfouts at liblime.com (Clay Fouts) Date: Mon, 6 Jun 2011 08:17:34 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <20110606091718.6875FF6605@nail.towers.org.uk> References: <20110606091718.6875FF6605@nail.towers.org.uk> Message-ID: Why would anyone use it? I've given a link to the current release notes that document the features that are unique to our fork. There are release notes for previous version, as well. We don't develop features for the fun of it (usually); we develop features that libraries want and that don't yet exist. Just as a brief example, many libraries have records that hundreds or even a thousand items. Koha 3.4 can't handle those. LibLime Koha 4.2 can. LibLime Academic Koha (n?e LibLime Enterprise Koha) is still very actively developed and updated with regular time-based releases that offer new features like improved search syntax, browse searching, and real authority control. I'm not sure exactly what you're alluding to by citing it, but it continues to grow in both feature set and user base. Clay On Mon, Jun 6, 2011 at 2:17 AM, MJ Ray wrote: > Christian Calle Jahuira wrote: > > Write to La Paz Bolivia, I have implemented KOHA version 3.0, > > my question is about the advantages of KOHA 4 and LibLime, > > which presents differences. > > The latest version is Koha 3.4. There is no Koha 4 yet. > LibLime is trying to pass off their LMS as Koha, but it is not Koha. > Do not be tricked! Koha would not delete its contibutor credits. > > As I understand it, LibLime 4.2 is actually a fork around Koha 3.0, > which was the last version release-managed by someone from LibLime (oh > the pain) and was end-of-lifed by koha-community last month, as in > http://lists.koha-community.org/pipermail/koha-devel/2011-May/035542.html > > Also, I think that the public LibLime 4.2 is not current, with their > customers using later versions. So their public version is already > obsolete by its publisher and based on a now-unsupported community > release, so why would anyone use it unless forced or daft? > > This seems like a repeat of the trick when LibLime started selling > "Enterprise Koha" - and where is that now? ;-) > > Koha 3.4 is clearly the place to be. The big feature there is the > improved template system, but since 3.0, the acquisitions module is > significantly revamped, the system preferences editor is easier to > use, there's bulk item editing, better reports, serials and > cataloguing, more connections to other systems, more localisaton, tons > of small bugs fixed and more that you can find in the release notes. > > Hope that informs, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for various work through http://www.software.coop/ > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Mon Jun 6 17:17:56 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 6 Jun 2011 11:17:56 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: 2011/6/6 Clay Fouts : > We do not in general make an effort to coordinate our work with other code > bases, nor attempt to port our code over to them. The source is however > available for all to see.?Upon release from the sponsoring customer, we > publish the source code for anyone to work whichever pieces they want into > whatever code base they manage. Cutting to the chase, your wordy explanation can be reduced to a one word policy: Non-cooperation. Wording it that way wastes less of our time on parsing the verbiage. Liblime's product is simply *NOT* Koha. Period. End of discussion. And I'm not sure we really want what they have at this point anyway. Now back to more productive work. Kind Regards, Chris From fridolyn.somers at gmail.com Mon Jun 6 17:30:22 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 6 Jun 2011 17:30:22 +0200 Subject: [Koha-devel] Z3950 search/UNIMARC In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA312D2FFA@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA312D2FFA@S-MAIL-1B.rijksmuseum.intra> Message-ID: Hie, Z3950 search in Koha works well with the BFN server. See french default installation : http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=installer/data/mysql/fr-FR/2-Optionel/z3950_BNF.sql;h=cde873e1bb834ec2f1634e65d824ea483c818776;hb=HEAD Regards, 2011/6/6 Marcel de Rooy > Hi all, > > > > I am testing some changes in z3950_search.pl and I am wondering if the > default Koha z3950 script correctly functions for unimarc targets (with > marcflavor to unimarc as well of course). > > Could anyone of you using z3950 with unimarc reply on that? > > Is the MARC and Card view on the results screen correct too? > > Did you encounter problems with encodings? MARC-8, UTF-8, etc.? > > I tested with carmin.sudoc.abes.fr z3950 target? Could you recommend > another one? > > > > Thanks for some feedback, > > > > Marcel > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From cfouts at liblime.com Mon Jun 6 18:05:27 2011 From: cfouts at liblime.com (Clay Fouts) Date: Mon, 6 Jun 2011 09:05:27 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: Each vendor has their own (sometimes very large) customizations that they may or may not port back into community code. The community RM may or may not accept these back ports even if effort is made to rebase them. Please point to the line distinguishing "Koha" from "not Koha". Is BibLibre's fork Koha? They have substantial, potentially irreconcilable differences that appear not to be destined for the community base and their extremely patient efforts to point this out and seek solution are met with little more than a dismissive that "well, that's your problem." Who is or isn't cooperating this case? Is Software Coop's fork Koha? I understand there are large differences that they are not paying to port back into the community base. I even recall seeing an announcement that someone was paying ByWater to do the work of porting the coop's EDI code back to community. Does this qualify as "cooperation"? How is this different from LibLime publishing its code so that any library is welcome to pay the vendor of their choosing to back port it to community? Would we receive the same praiseful press release if ByWater was getting paid to port our large-bib functionality into community code? The community had their opportunity to fork their project from the company that owns the trademark, website, etc. and call their software something different, much like LibreOffice and Jenkins chose to do when splitting from the Oracle-run projects. But that wasn't the choice that was made, so now we all get to have endless arguments and have libraries confused about what is or is not Koha. At the very least, LibLime when asked tries to be respectful of our differences and does not say "well, that's not really Koha." Regards, Clay On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > 2011/6/6 Clay Fouts : > > We do not in general make an effort to coordinate our work with other > code > > bases, nor attempt to port our code over to them. The source is however > > available for all to see. Upon release from the sponsoring customer, we > > publish the source code for anyone to work whichever pieces they want > into > > whatever code base they manage. > > Cutting to the chase, your wordy explanation can be reduced to a one > word policy: Non-cooperation. > > Wording it that way wastes less of our time on parsing the verbiage. > > Liblime's product is simply *NOT* Koha. Period. End of discussion. And > I'm not sure we really want what they have at this point anyway. > > Now back to more productive work. > > Kind Regards, > Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at bywatersolutions.com Mon Jun 6 18:50:29 2011 From: info at bywatersolutions.com (Brendan A. Gallagher) Date: Mon, 6 Jun 2011 09:50:29 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> Clay - Please get your facts straight before you continue with this thread and us other companies names. Comment in-line. On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote: > Each vendor has their own (sometimes very large) customizations that they may or may not port back into community code. The community RM may or may not accept these back ports even if effort is made to rebase them. Please point to the line distinguishing "Koha" from "not Koha". > > Is BibLibre's fork Koha? They have substantial, potentially irreconcilable differences that appear not to be destined for the community base and their extremely patient efforts to point this out and seek solution are met with little more than a dismissive that "well, that's your problem." Who is or isn't cooperating this case? > > Is Software Coop's fork Koha? I understand there are large differences that they are not paying to port back into the community base. I even recall seeing an announcement that someone was paying ByWater to do the work of porting the coop's EDI code back to community. Does this qualify as "cooperation"? How is this different from LibLime publishing its code so that any library is welcome to pay the vendor of their choosing to back port it to community? Would we receive the same praiseful press release if ByWater was getting paid to port our large-bib functionality into community code? Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This is a project that we are pursuing and we are using our own money to fund for our time to rebase this code. As part of our company we spend the time to rebase code/ submit bugfixes, and pay for our employees to work on community code and documentation (manual) that is not directly sponsored by a customer. This is all meant for the best interests in the project as a whole. Hopefully that makes sense - if not, you are welcome to give me a phone call whenever you want. -Brendan ByWater Solutions CEO > > The community had their opportunity to fork their project from the company that owns the trademark, website, etc. and call their software something different, much like LibreOffice and Jenkins chose to do when splitting from the Oracle-run projects. But that wasn't the choice that was made, so now we all get to have endless arguments and have libraries confused about what is or is not Koha. > > At the very least, LibLime when asked tries to be respectful of our differences and does not say "well, that's not really Koha." > > Regards, > Clay > > > On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger wrote: > 2011/6/6 Clay Fouts : > > We do not in general make an effort to coordinate our work with other code > > bases, nor attempt to port our code over to them. The source is however > > available for all to see. Upon release from the sponsoring customer, we > > publish the source code for anyone to work whichever pieces they want into > > whatever code base they manage. > > Cutting to the chase, your wordy explanation can be reduced to a one > word policy: Non-cooperation. > > Wording it that way wastes less of our time on parsing the verbiage. > > Liblime's product is simply *NOT* Koha. Period. End of discussion. And > I'm not sure we really want what they have at this point anyway. > > Now back to more productive work. > > Kind Regards, > Chris > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfouts at liblime.com Mon Jun 6 18:55:40 2011 From: cfouts at liblime.com (Clay Fouts) Date: Mon, 6 Jun 2011 09:55:40 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> Message-ID: I did not say that Software Coop was paying for it. My whole point was that they were *not* paying for it. I stated that someone was paying ByWater to port it, and I now understand that that someone is ByWater itself, not a customer. I stand corrected on that point. Clay On Mon, Jun 6, 2011 at 9:50 AM, Brendan A. Gallagher < info at bywatersolutions.com> wrote: > Clay - > > Please get your facts straight before you continue with this thread and us > other companies names. Comment in-line. > > On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote: > > Each vendor has their own (sometimes very large) customizations that they > may or may not port back into community code. The community RM may or may > not accept these back ports even if effort is made to rebase them. Please > point to the line distinguishing "Koha" from "not Koha". > > Is BibLibre's fork Koha? They have substantial, potentially irreconcilable > differences that appear not to be destined for the community base and their > extremely patient efforts to point this out and seek solution are met with > little more than a dismissive that "well, that's your problem." Who is or > isn't cooperating this case? > > Is Software Coop's fork Koha? I understand there are large differences that > they are not paying to port back into the community base. I even recall > seeing an announcement that someone was paying ByWater to do the work of > porting the coop's EDI code back to community. Does this qualify as > "cooperation"? How is this different from LibLime publishing its code so > that any library is welcome to pay the vendor of their choosing to back port > it to community? Would we receive the same praiseful press release if > ByWater was getting paid to port our large-bib functionality into community > code? > > > Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This > is a project that we are pursuing and we are using our own money to fund for > our time to rebase this code. As part of our company we spend the time to > rebase code/ submit bugfixes, and pay for our employees to work on community > code and documentation (manual) that is not directly sponsored by a > customer. This is all meant for the best interests in the project as a > whole. > > Hopefully that makes sense - if not, you are welcome to give me a phone > call whenever you want. > > -Brendan > ByWater Solutions CEO > > > The community had their opportunity to fork their project from the company > that owns the trademark, website, etc. and call their software something > different, much like LibreOffice and Jenkins chose to do when splitting from > the Oracle-run projects. But that wasn't the choice that was made, so now we > all get to have endless arguments and have libraries confused about what is > or is not Koha. > > At the very least, LibLime when asked tries to be respectful of our > differences and does not say "well, that's not really Koha." > > Regards, > Clay > > > On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger < > cnighswonger at foundations.edu> wrote: > >> 2011/6/6 Clay Fouts : >> > We do not in general make an effort to coordinate our work with other >> code >> > bases, nor attempt to port our code over to them. The source is however >> > available for all to see. Upon release from the sponsoring customer, we >> > publish the source code for anyone to work whichever pieces they want >> into >> > whatever code base they manage. >> >> Cutting to the chase, your wordy explanation can be reduced to a one >> word policy: Non-cooperation. >> >> Wording it that way wastes less of our time on parsing the verbiage. >> >> Liblime's product is simply *NOT* Koha. Period. End of discussion. And >> I'm not sure we really want what they have at this point anyway. >> >> Now back to more productive work. >> >> Kind Regards, >> Chris >> > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfouts at liblime.com Mon Jun 6 18:55:40 2011 From: cfouts at liblime.com (Clay Fouts) Date: Mon, 6 Jun 2011 09:55:40 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> Message-ID: I did not say that Software Coop was paying for it. My whole point was that they were *not* paying for it. I stated that someone was paying ByWater to port it, and I now understand that that someone is ByWater itself, not a customer. I stand corrected on that point. Clay On Mon, Jun 6, 2011 at 9:50 AM, Brendan A. Gallagher < info at bywatersolutions.com> wrote: > Clay - > > Please get your facts straight before you continue with this thread and us > other companies names. Comment in-line. > > On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote: > > Each vendor has their own (sometimes very large) customizations that they > may or may not port back into community code. The community RM may or may > not accept these back ports even if effort is made to rebase them. Please > point to the line distinguishing "Koha" from "not Koha". > > Is BibLibre's fork Koha? They have substantial, potentially irreconcilable > differences that appear not to be destined for the community base and their > extremely patient efforts to point this out and seek solution are met with > little more than a dismissive that "well, that's your problem." Who is or > isn't cooperating this case? > > Is Software Coop's fork Koha? I understand there are large differences that > they are not paying to port back into the community base. I even recall > seeing an announcement that someone was paying ByWater to do the work of > porting the coop's EDI code back to community. Does this qualify as > "cooperation"? How is this different from LibLime publishing its code so > that any library is welcome to pay the vendor of their choosing to back port > it to community? Would we receive the same praiseful press release if > ByWater was getting paid to port our large-bib functionality into community > code? > > > Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This > is a project that we are pursuing and we are using our own money to fund for > our time to rebase this code. As part of our company we spend the time to > rebase code/ submit bugfixes, and pay for our employees to work on community > code and documentation (manual) that is not directly sponsored by a > customer. This is all meant for the best interests in the project as a > whole. > > Hopefully that makes sense - if not, you are welcome to give me a phone > call whenever you want. > > -Brendan > ByWater Solutions CEO > > > The community had their opportunity to fork their project from the company > that owns the trademark, website, etc. and call their software something > different, much like LibreOffice and Jenkins chose to do when splitting from > the Oracle-run projects. But that wasn't the choice that was made, so now we > all get to have endless arguments and have libraries confused about what is > or is not Koha. > > At the very least, LibLime when asked tries to be respectful of our > differences and does not say "well, that's not really Koha." > > Regards, > Clay > > > On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger < > cnighswonger at foundations.edu> wrote: > >> 2011/6/6 Clay Fouts : >> > We do not in general make an effort to coordinate our work with other >> code >> > bases, nor attempt to port our code over to them. The source is however >> > available for all to see. Upon release from the sponsoring customer, we >> > publish the source code for anyone to work whichever pieces they want >> into >> > whatever code base they manage. >> >> Cutting to the chase, your wordy explanation can be reduced to a one >> word policy: Non-cooperation. >> >> Wording it that way wastes less of our time on parsing the verbiage. >> >> Liblime's product is simply *NOT* Koha. Period. End of discussion. And >> I'm not sure we really want what they have at this point anyway. >> >> Now back to more productive work. >> >> Kind Regards, >> Chris >> > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfouts at liblime.com Mon Jun 6 18:55:40 2011 From: cfouts at liblime.com (Clay Fouts) Date: Mon, 6 Jun 2011 09:55:40 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> Message-ID: I did not say that Software Coop was paying for it. My whole point was that they were *not* paying for it. I stated that someone was paying ByWater to port it, and I now understand that that someone is ByWater itself, not a customer. I stand corrected on that point. Clay On Mon, Jun 6, 2011 at 9:50 AM, Brendan A. Gallagher < info at bywatersolutions.com> wrote: > Clay - > > Please get your facts straight before you continue with this thread and us > other companies names. Comment in-line. > > On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote: > > Each vendor has their own (sometimes very large) customizations that they > may or may not port back into community code. The community RM may or may > not accept these back ports even if effort is made to rebase them. Please > point to the line distinguishing "Koha" from "not Koha". > > Is BibLibre's fork Koha? They have substantial, potentially irreconcilable > differences that appear not to be destined for the community base and their > extremely patient efforts to point this out and seek solution are met with > little more than a dismissive that "well, that's your problem." Who is or > isn't cooperating this case? > > Is Software Coop's fork Koha? I understand there are large differences that > they are not paying to port back into the community base. I even recall > seeing an announcement that someone was paying ByWater to do the work of > porting the coop's EDI code back to community. Does this qualify as > "cooperation"? How is this different from LibLime publishing its code so > that any library is welcome to pay the vendor of their choosing to back port > it to community? Would we receive the same praiseful press release if > ByWater was getting paid to port our large-bib functionality into community > code? > > > Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This > is a project that we are pursuing and we are using our own money to fund for > our time to rebase this code. As part of our company we spend the time to > rebase code/ submit bugfixes, and pay for our employees to work on community > code and documentation (manual) that is not directly sponsored by a > customer. This is all meant for the best interests in the project as a > whole. > > Hopefully that makes sense - if not, you are welcome to give me a phone > call whenever you want. > > -Brendan > ByWater Solutions CEO > > > The community had their opportunity to fork their project from the company > that owns the trademark, website, etc. and call their software something > different, much like LibreOffice and Jenkins chose to do when splitting from > the Oracle-run projects. But that wasn't the choice that was made, so now we > all get to have endless arguments and have libraries confused about what is > or is not Koha. > > At the very least, LibLime when asked tries to be respectful of our > differences and does not say "well, that's not really Koha." > > Regards, > Clay > > > On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger < > cnighswonger at foundations.edu> wrote: > >> 2011/6/6 Clay Fouts : >> > We do not in general make an effort to coordinate our work with other >> code >> > bases, nor attempt to port our code over to them. The source is however >> > available for all to see. Upon release from the sponsoring customer, we >> > publish the source code for anyone to work whichever pieces they want >> into >> > whatever code base they manage. >> >> Cutting to the chase, your wordy explanation can be reduced to a one >> word policy: Non-cooperation. >> >> Wording it that way wastes less of our time on parsing the verbiage. >> >> Liblime's product is simply *NOT* Koha. Period. End of discussion. And >> I'm not sure we really want what they have at this point anyway. >> >> Now back to more productive work. >> >> Kind Regards, >> Chris >> > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfouts at liblime.com Mon Jun 6 18:55:40 2011 From: cfouts at liblime.com (Clay Fouts) Date: Mon, 6 Jun 2011 09:55:40 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> Message-ID: I did not say that Software Coop was paying for it. My whole point was that they were *not* paying for it. I stated that someone was paying ByWater to port it, and I now understand that that someone is ByWater itself, not a customer. I stand corrected on that point. Clay On Mon, Jun 6, 2011 at 9:50 AM, Brendan A. Gallagher < info at bywatersolutions.com> wrote: > Clay - > > Please get your facts straight before you continue with this thread and us > other companies names. Comment in-line. > > On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote: > > Each vendor has their own (sometimes very large) customizations that they > may or may not port back into community code. The community RM may or may > not accept these back ports even if effort is made to rebase them. Please > point to the line distinguishing "Koha" from "not Koha". > > Is BibLibre's fork Koha? They have substantial, potentially irreconcilable > differences that appear not to be destined for the community base and their > extremely patient efforts to point this out and seek solution are met with > little more than a dismissive that "well, that's your problem." Who is or > isn't cooperating this case? > > Is Software Coop's fork Koha? I understand there are large differences that > they are not paying to port back into the community base. I even recall > seeing an announcement that someone was paying ByWater to do the work of > porting the coop's EDI code back to community. Does this qualify as > "cooperation"? How is this different from LibLime publishing its code so > that any library is welcome to pay the vendor of their choosing to back port > it to community? Would we receive the same praiseful press release if > ByWater was getting paid to port our large-bib functionality into community > code? > > > Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This > is a project that we are pursuing and we are using our own money to fund for > our time to rebase this code. As part of our company we spend the time to > rebase code/ submit bugfixes, and pay for our employees to work on community > code and documentation (manual) that is not directly sponsored by a > customer. This is all meant for the best interests in the project as a > whole. > > Hopefully that makes sense - if not, you are welcome to give me a phone > call whenever you want. > > -Brendan > ByWater Solutions CEO > > > The community had their opportunity to fork their project from the company > that owns the trademark, website, etc. and call their software something > different, much like LibreOffice and Jenkins chose to do when splitting from > the Oracle-run projects. But that wasn't the choice that was made, so now we > all get to have endless arguments and have libraries confused about what is > or is not Koha. > > At the very least, LibLime when asked tries to be respectful of our > differences and does not say "well, that's not really Koha." > > Regards, > Clay > > > On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger < > cnighswonger at foundations.edu> wrote: > >> 2011/6/6 Clay Fouts : >> > We do not in general make an effort to coordinate our work with other >> code >> > bases, nor attempt to port our code over to them. The source is however >> > available for all to see. Upon release from the sponsoring customer, we >> > publish the source code for anyone to work whichever pieces they want >> into >> > whatever code base they manage. >> >> Cutting to the chase, your wordy explanation can be reduced to a one >> word policy: Non-cooperation. >> >> Wording it that way wastes less of our time on parsing the verbiage. >> >> Liblime's product is simply *NOT* Koha. Period. End of discussion. And >> I'm not sure we really want what they have at this point anyway. >> >> Now back to more productive work. >> >> Kind Regards, >> Chris >> > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Mon Jun 6 19:26:39 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 6 Jun 2011 13:26:39 -0400 Subject: [Koha-devel] EAN-13 barcode support In-Reply-To: <20110606170814.GA12762@rot13.org> References: <20110601175828.GA7889@rot13.org> <20110606170814.GA12762@rot13.org> Message-ID: Hi Dobrica, On Mon, Jun 6, 2011 at 1:08 PM, Dobrica Pavlinusic wrote: >> The scaling foo really follows no logic that I've be able to figure >> out yet. It is definitely not a "one size fits all" situation. Right >> now it is optimized for longer barcodes. Feel free to improve upon it >> if you are able. > > I was wondering what units are used for $bar_length, and I haven't > figured it out. IIRC all at that level are points. I'm pretty sure that I refactored the entire creator code to use points as its base unit. > > However, without scaling, barcodes are correct size (at least for > EAN-13/UPC-a which have "standard" size), so it's not a show-stoppper. I suspect this is true for the average user, which is why it has not been high on my list to work on (sorry everyone). If I can help by answering questions, please feel free to ask. My time right now is tight, so I can't do much more. Kind Regards, Chris From cnighswonger at foundations.edu Mon Jun 6 19:48:54 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 6 Jun 2011 13:48:54 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: On Mon, Jun 6, 2011 at 12:05 PM, Clay Fouts wrote: > Each vendor has their own (sometimes very large) customizations that they > may or may not port back into community code. The community RM may or may > not accept these back ports even if effort is made to rebase them. Please > point to the line distinguishing "Koha" from "not Koha". That's easy: the point at which the vendor (whomever they may be) chooses to fork from Koha. At that point, the software the vendor is servicing, maintaining, your-term-goes-here, ceases to be Koha. It may be said to be based upon Koha, but it is not Koha. > Is BibLibre's fork Koha? They have substantial, potentially irreconcilable > differences that appear not to be destined for the community base and their > extremely patient efforts to point this out and seek solution are met with > little more than a dismissive that "well, that's your problem." Who is or > isn't cooperating this case? > Is Software Coop's fork Koha? I understand there are large differences that > they are not paying to port back into the community base. I even recall > seeing an announcement that someone was paying ByWater to do the work of > porting the coop's EDI code back to community. Does this qualify as > "cooperation"? How is this different from LibLime publishing its code so > that any library is welcome to pay the vendor of their choosing to back port > it to community? Would we receive the same praiseful press release if > ByWater was getting paid to port our large-bib functionality into community > code? By definition a fork is not the same as the base from which it was forked. A given instance of code is only a true fork once there is a delta between it and the source from which it was cloned. Otherwise it is a clone rather than a fork. So, by definition any repo, installation, etc. which has a delta over the main repo is a fork. Since we live in a world where there must be some objective standard against which to make accurate comparisons, we must decide on that standard. In the Koha community that standard has long been the code base in the main repo. So every fork is by definition only as nearly "Koha" as it conforms to that standard. Thus, the larger the delta between the fork and the main repo, the less the fork can be said to be "Koha." Its an inverse relationship if that is clearer. At this point in history, LibLime's fork has a pretty large delta and so is less "Koha" than other forks. > The community had their opportunity to fork their project from the company > that owns the trademark, website, etc. and call their software something > different, much like LibreOffice and Jenkins chose to do when splitting from > the Oracle-run projects. But that wasn't the choice that was made, so now we > all get to have endless arguments and have libraries confused about what is > or is not Koha. Liblime only owns the US trademark usage of the name "Koha," and last I looked, the US does not dictate world trademark law. Koha is much bigger than LibLime (as much as LibLime might pretend otherwise). So just as you are free to have your opinion, the Koha community has their opinion: There is no confusion to those in the know. The Koha community produces and holds the standard against which all other things calling themselves Koha are judged. > At the very least, LibLime when asked tries to be respectful of our > differences and does not say "well, that's not really Koha." I'd say that LibLime is simply acceding to the facts of reality when they refrain from making such claims. They are certainly not doing the community any favors. Kind Regards, Chris From cfouts at liblime.com Mon Jun 6 20:19:44 2011 From: cfouts at liblime.com (Clay Fouts) Date: Mon, 6 Jun 2011 11:19:44 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: On Mon, Jun 6, 2011 at 10:48 AM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > standard. In the Koha community that standard has long been the code > base in the main repo. So every fork is by definition only as nearly > "Koha" as it conforms to that standard. Thus, the larger the delta > between the fork and the main repo, the less the fork can be said to > be "Koha." Its an inverse relationship if that is clearer. At this > point in history, LibLime's fork has a pretty large delta and so is > less "Koha" than other forks. > You speak like you haven't looked at the BibLibre diffs. I don't know that they're at any less of a delta than LibLime, and it's only getting larger. They are a very productive group. Where is your indignation when they call their product Koha? Software Coop, who apparently has no ambition to back port their own code, sells "Koha" support. Do you tell people that their software isn't really Koha? These folks are obviously selling work that differs remarkably from "Koha" as you've defined it, and to my knowledge they don't even differentiate it with a "BibLibre Koha" or a "Software Coop" Koha the way that LibLime has chosen to do. You can be chafed at the fact that LibLime took liberties that you don't like with the koha.org website, and I can accept and empathize with that. However, your contention that LibLime's code "isn't Koha" and somehow these other projects are is rather incoherent. > Liblime only owns the US trademark usage of the name "Koha," and last > I looked, the US does not dictate world trademark law. Koha is much > bigger than LibLime (as much as LibLime might pretend otherwise). So > just as you are free to have your opinion, the Koha community has > their opinion: There is no confusion to those in the know. The Koha > community produces and holds the standard against which all other > things calling themselves Koha are judged. > The frequency with which we hear the phrase "New Zealand Koha" at conventions suggests the confusion may be deeper and more widespread than you have led yourself to believe. Regards, Clay -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Mon Jun 6 20:49:16 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 7 Jun 2011 06:49:16 +1200 Subject: [Koha-devel] Circulation Improvements Message-ID: <20110606184916.GM8109@rorohiko.wgtn.cat-it.co.nz> Hi All Biblibre have done some good circulation improvements (bug 5872) but this is currently blocked by bug 5436 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5436 Work is being done on Hourly loans http://bugs.koha-community.org/bugzilla3/showdependencytree.cgi?id=5549&hide_resolved=1 And I want all of the changes in 5872 in with that. Would someone be able to look at 5436 and fix it up (the other 2 bugs 5872 depends on have made their way through sign off already). Thanks in advance Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nengard at gmail.com Tue Jun 7 01:22:53 2011 From: nengard at gmail.com (Nicole Engard) Date: Mon, 6 Jun 2011 19:22:53 -0400 Subject: [Koha-devel] RFCs Message-ID: Hello developers, On looking at the wiki I see that the 3.4 RFCs have some things that didn't make it in to 3.4 and the 3.6 RFCs page is empty. We should probably move the devs that didn't make it to 3.4 from this page: http://wiki.koha-community.org/wiki/Category:Koha_3.4_RFCs to a page for 3.6 Nicole From mjr at phonecoop.coop Tue Jun 7 13:26:43 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 7 Jun 2011 12:26:43 +0100 (BST) Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: Message-ID: <20110607112643.DC043F661B@nail.towers.org.uk> Clay Fouts wrote: > Why would anyone use it? I've given a link to the current release notes that > document the features that are unique to our fork. There are release notes > for previous version, as well. We don't develop features for the fun of it > (usually); we develop features that libraries want and that don't yet exist. That's not a reason in favour of Liblime 4.2. Most Koha developers develop features that libraries request - and then submit them promptly to the community, unlike Liblime. A couple of firms even develop features to provide a service to libraries as our basic missions, rather than to provide a profit to external investors in a company that bought a business that bought a business. > Just as a brief example, many libraries have records that hundreds or even a > thousand items. Koha 3.4 can't handle those. LibLime [...] 4.2 can. Actually, you're mistaken: Koha 3.4 can handle those. The underlying structural bug released by the 3.0 release manager (from Liblime) has been fixed in 3.4. There are some consequences, but there are other capacity-improvement patches and branches to cure them linked from the wiki if anyone wants them before they are included in a future Koha release. So that isn't a reason for a library to be cut off from the global community by using the already-obsolete Liblime 4.2. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From mjr at phonecoop.coop Tue Jun 7 14:28:52 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 7 Jun 2011 13:28:52 +0100 (BST) Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> Message-ID: <20110607122852.A410CF661B@nail.towers.org.uk> Brendan A. Gallagher wrote: > Please get your facts straight before you continue with this thread > and us other companies names. Comment in-line. Yes, I agree with that sentiment. Liblime workers appearing to actively fib about other community participants is a new step back. > On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote: > > Is Software Coop's fork Koha? No, and we don't market it as such. (It's software.coop, by the way.) All but one of our libraries are on Koha releases available from koha-community.org and all patches we create are sent back, but those have been fairly small and sporadic since then. The release management seems much better in 3.2 and 3.4. For anyone new to this topic, that fork is a single-library variant of Koha which I feel Liblime forced us into a few years ago. The 3.0 release manager (Josh, then owner of Liblime) refused to hold back from adopting a feature in one of the template modules that: 1. was not portable; 2. Liblime had requested; 3. was not packaged for mainstream operating systems yet; and 4. did not compile on that library's servers at that time. Remember that Josh had announced Koha 3.0 would be released at the end of 2006, then in July 2008, he presented us with the prospect that a library which had patiently helped us to develop 3.0 wouldn't be able to use it when it was released! The co-op's core mission is "to provide computer-related services" so we did what we had to do to serve that library. The main bit of the thread provoking the fork starts at http://lists.koha-community.org/pipermail/koha-patches/2008-July/007016.html tl;dr where I disclose that we've forked for the one library is http://lists.koha-community.org/pipermail/koha-patches/2008-August/007309.html > > I understand there are large differences that they are not paying > > to port back into the community base. What gave you that idea? The co-op is using our own money to fund porting them back (for various reasons rooted in government cuts IMO, the original project won't complete any time soon), so it's taking far longer than I would like. I shudder to think of the cost that this fork has incurred. > I even recall seeing an announcement that someone was paying ByWater > to do the work of porting the coop's EDI code back to > community. Does this qualify as "cooperation"? That EDI code was developed for the same one library which is why it's based on the fork. Bywater have agreed to help us with porting this back sooner and we really appreciate that, but I don't remember any announcement about someone paying them to do it. Please post links, like I did above, so anyone can see for themselves. > How is this different from LibLime publishing its code so that any > library is welcome to pay the vendor of their choosing to back port > it to community? Key differences: 1. the fork exists mainly because of Liblime's 3.0 release manager; 2. it's used at one library and we've been quite open about that; 3. we still support the community, on IRC, web, in meetings, and so on; 4. we have never tried to pass the fork off as Koha or booted the community out of resources they developed; 5. despite the massive cost, we will port the key features and not publish a tangled mess as abandonware for the community to sort out; 6. we have shared it with other Koha developers, both at Kohacon10 and otherwise; 7. we normally sell the proper Koha releases. > Software Coop is not paying ByWater Solutions to rebase EDI for > Koha. This is a project that we are pursuing and we are using our > own money to fund for our time to rebase this code. [...] Thanks to Bywater, once again. > Hopefully that makes sense - if not, you are welcome to give me a > phone call whenever you want. Similarly, anyone is welcome to call the co-op - we now have local access numbers in over 35 countries, linked on http://www.software.coop/contact/ Hope that clarifies, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From mason at kohaaloha.com Tue Jun 7 02:19:49 2011 From: mason at kohaaloha.com (James, Mason) Date: Tue, 7 Jun 2011 12:19:49 +1200 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: <4E3AE33F-7A1C-4330-94F0-E63B3AB93B5A@kohaaloha.com> On 2011-06-7, at 6:19 AM, Clay Fouts wrote: > On Mon, Jun 6, 2011 at 10:48 AM, Chris Nighswonger wrote: > standard. In the Koha community that standard has long been the code > base in the main repo. So every fork is by definition only as nearly > "Koha" as it conforms to that standard. Thus, the larger the delta > between the fork and the main repo, the less the fork can be said to > be "Koha." Its an inverse relationship if that is clearer. At this > point in history, LibLime's fork has a pretty large delta and so is > less "Koha" than other forks. > > You speak like you haven't looked at the BibLibre diffs. I don't know that they're at any less of a delta than LibLime, and it's only getting larger. They are a very productive group. Where is your indignation when they call their product Koha? Software Coop, who apparently has no ambition to back port their own code, sells "Koha" support. Do you tell people that their software isn't really Koha? > These folks are obviously selling work that differs remarkably from "Koha" as you've defined it, and to my knowledge they don't even differentiate it with a "BibLibre Koha" or a "Software Coop" Koha the way that LibLime has chosen to do. the big difference is that Biblibre, software-coop, (and all other Koha support companies) do *not* make their own Koha releases, unlike PTFS/Liblime BL and SW-COOP understand that having many company-releases of many Koha-forks is harmful to the reputation of the Koha project, so they respectfully choose not to do that... (a subtle point that only PTFS/Liblime fail to understand) ... instead they continue to invest their energy submitting their enhancements and bug-fixes into the Koha codebase PTFS/Liblime is the *only* company that continues to release its own 'Koha', and the only company to renege on it commitment to integrate its enhancements back to the Koha codebase PTFS/Liblime seem to have missed the fundamental point of participating in the Koha project. > The frequency with which we hear the phrase "New Zealand Koha" at conventions suggests the confusion may be deeper and more widespread than you have led yourself to believe. Clay, i think that confusion exists only around conversations with PTFS/Liblime staff, at those conventions ;) Mason From lculber at mdah.state.ms.us Tue Jun 7 14:49:43 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Tue, 07 Jun 2011 07:49:43 -0500 Subject: [Koha-devel] Koha More regarding local call number search/barcodes In-Reply-To: <4DEDB286.8030907@biblibre.com> References: <4DE7FD8F.2050604@mdah.state.ms.us> <4DED1FF9.2010108@mdah.state.ms.us> <4DED2240.9020000@mdah.state.ms.us> <4DEDB286.8030907@biblibre.com> Message-ID: <4DEE1E67.2040507@mdah.state.ms.us> All, At Chris's suggestion, I'm moving this to the development list. It seems to me that Henri-Damien is correct in that exact would be better for the sn and bc indexes but that the phrase might work better for call numbers. Since I am very much a newbie at this, I'd like to hear from those more experienced about the best way to proceed. Do I need to put this discussion on bugzilla or just the outcome of the discussion when we're ready to proceed? We are very interested in contributing but don't want to create any problems when trying to fix something. Thanks, Linda On 1:59 PM, LAURENT Henri-Damien wrote: > Le 06/06/2011 20:57, Chris Cormack a ??crit : >> > On 7 June 2011 06:53, Linda Culberson wrote: >>> >> The problem, at least in 3.4, does exist, but changing the query from >>> >> sn,wrdl to sn,phr and bc,wrdl to bc,phr seems to fix it. >>> >> >>> >> But I'm still wondering if there are others - besides call numbers - >>> >> for which this applies. >>> >> >>> >> I apologize for the multiple emails. I should do more research before I >>> >> email. I'll try to keep quiet now. >>> >> >> > >> > Hi Linda >> > Multiple emails are fine, but perhaps this discussion is better on the >> > koha-devel list. >> > I think its not a new problem (i think 3.0.x up did this) but that >> > doesn't mean its right. >> > >> > I think phr for barcode, sn, etc makes more sense and I would >> > encourage you to widen the scope of your bug to include them. >> > The fix is simply changes in the template so should be relatively >> > straightforward to implement and would be a welcome fix for many >> > libraries I think. >> > >> > Chris > Well, it all depends on what you search, but ext could be really what > you are looking for. > With phr you could look for : > AAAA/BB > And find > AAAA/BB C > AAAA/BB D > or even > C AAAA/BB > where ext would match the exact subfield... > But one default for that is that you cannot search both ext and * afaik > (could be quite easy to test if anyone interested. In a yaz-client : > f @attr 4=1 @attr 6=3 @attr 5=2 "your callnumber" > ) > > and that ext search requires the completeness set to 1 on the index type > you use in default.idx ... Which is commonly the case when you use p... > Moreoved, consider that using p should not replace w indexing, but be added. > Since there are places in the code or in database settings where lcn can > be searched directly without using phr modifier. And if you donot have > indexed with word... Then the search will always fail which would be > worse than the problem it fixed. > Hope that helps. > -- Henri-Damien LAURENT -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824 From paul.poulain at biblibre.com Tue Jun 7 15:38:32 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 07 Jun 2011 15:38:32 +0200 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: <4DEE29D8.6020401@biblibre.com> Le 06/06/2011 18:05, Clay Fouts a ?crit : > Each vendor has their own (sometimes very large) customizations that > they may or may not port back into community code. The community RM > may or may not accept these back ports even if effort is made to > rebase them. Please point to the line distinguishing "Koha" from "not > Koha". Well, I think we are mixing 2 things : * local & specific customizations * fork a local and specific customization: it occur very often. For example, one of our customer has very long barcodes, and the barcode length in the database is not enough for them. it's specific to the customer, and has nothing to do with a public version. Sometimes, it's not that small (even if it's local). For example, for Aix-Marseille universities, we changed the circulation (check-out) workflow to query a NFC reader& database. The NFC card & database is responsible to say if a card is valid and fill the members table in Koha database. This is OpenSource (GPL), available on our public git repo, but won't be submitted to the community, it's useless unless you've this exact technology. I agree it can be worth for a library using the same NFC technology and we could have announced what we made more widely. Our fault, nobody's perfect (announcement : if you've a 'horoquartz' NFC technology, you can drop me a mail ;-) ) a fork. Do we have a fork ? Frankly, yes, but 1- we didn't wanted this to happen, 2- we do all what we can to fix this (yes we consider it's a "bug"). Reminder about the history : Koha 3.2 has been delayed due to events we all know here (for newbies, see : http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html), thus many feature we have developed have needed too much time to reach master (and had to be splitted/merged/...) I'm on my way to write a mail on our blog to detail how it happens, why we consider it a bug (and want to fix it), and what's the strategy to avoid it to happen again. In a few word: * we deploy only community version * if you sponsor a feature 2 options : you sponsor and use it live when it's in master, you sponsor, go live immediately. BUT if it's not included in master, then you'll have either to choose to switch back to community version (and forget you stuff), wait until it's in master, sign a specific contract for support from BibLibre (or someone else) to have your nice-feature-not-in-master rebased regularly vs master. * there are only a few things in "3.2 biblibre" that are not in 3.4, and everything will be in 3.6. > Is BibLibre's fork Koha? They have substantial, potentially > irreconcilable differences that appear not to be destined for the > community base and their extremely patient efforts to point this out > and seek solution are met with little more than a dismissive that > "well, that's your problem." Who is or isn't cooperating this case? Well, you're not completely wrong. I'm sometimes quite upset by "community". And I'm sure "community" is sometimes upset by me too ;-) . But I still think it's better to have strong discussions and arguments than doing our way without "the community". Hope that explains -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From magnus at enger.priv.no Tue Jun 7 16:16:14 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Tue, 7 Jun 2011 16:16:14 +0200 Subject: [Koha-devel] Global sign off day, 2011-06-15 Message-ID: Dear all! (And sorry for cross posting... At least a little bit ;-) We had such great fun in Marseilles earlier this year, signing off patches, that I have been wondering if it would be possible to re-create some of that experience without incurring the costs of travel. I broached the subject on IRC earlier today and after the briefest and least democratic of processes, "we" decided to declare 15th June 2011 as a Global Sign Off Day: http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 The hope is that as many people as possible will be able to set aside as much other work as possible on this day, and concentrate on signing off patches, to reduce the queue of bugs that are currently waiting for sign-off (66 at this moment: http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=cf_patch_status&query_format=advanced&type0-0-0=equals&value0-0-0=needs%20signoff&order=bug_id&list_id=7042) We will try to visualise and document the progress that is made, to make it more fun and maybe even tickle the competitive instincts a little bit... ;-) And who knows, if this day is a success, maybe we could turn it into a regular tradition? * If you have not signed off on a patch before, now is the perfect time to do it! The more the merrier! The process is outlined here: http://wiki.koha-community.org/wiki/Sign_off_on_patches And there will be people on IRC that you can ask for help and guidance! Best regards, Magnus Enger * On the other hand, let's hope we can keep the queue as short as possible... From cfouts at liblime.com Tue Jun 7 21:31:53 2011 From: cfouts at liblime.com (Clay Fouts) Date: Tue, 7 Jun 2011 12:31:53 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <20110607112643.DC043F661B@nail.towers.org.uk> References: <20110607112643.DC043F661B@nail.towers.org.uk> Message-ID: On Tue, Jun 7, 2011 at 4:26 AM, MJ Ray wrote: > That's not a reason in favour of Liblime 4.2. Most Koha developers > develop features that libraries request - and then submit them > promptly to the community, unlike Liblime. This is particularly dense, MJ. The features present in LK4.2 are already paid for. A library using it would not have to pay LibLime or anyone else in order to be able to take advantage of them. > A couple of firms even > develop features to provide a service to libraries as our basic > missions, rather than to provide a profit to external investors in > a company that bought a business that bought a business. > ... and now the sermon. And who *sold* that original business? > Actually, you're mistaken: Koha 3.4 can handle those. > Glad to be mistaken, then. It's a feature that a lot of libraries need. > The underlying > structural bug released by the 3.0 release manager (from Liblime) has > been fixed in 3.4. There are some consequences, but there are other > capacity-improvement patches and branches to cure them linked from the > wiki if anyone wants them before they are included in a future Koha > release. > The resounding chorus in all of your messages seems to be "It's Josh's fault!" > So that isn't a reason for a library to be cut off from the global > community by using the already-obsolete Liblime 4.2. This is FUD, pure and simple. Is community Koha 3.2 "already-obsolete" because it's not the most current version? We've already pushed out two sets of updates since the initial 4.2 release. Regards, Clay -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfouts at liblime.com Tue Jun 7 21:32:33 2011 From: cfouts at liblime.com (Clay Fouts) Date: Tue, 7 Jun 2011 12:32:33 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <20110607122852.A410CF661B@nail.towers.org.uk> References: <542C74A2-0002-4EC1-8516-14CF87D93932@bywatersolutions.com> <20110607122852.A410CF661B@nail.towers.org.uk> Message-ID: "1. the fork exists mainly because of Liblime's 3.0 release manager;" Back to "Josh made me do it!" chorus... Five months of lead time is not exactly a last minute change. But I suppose that's as good of excuse as any. I stand corrected in regards to you passing off your fork as "Koha". So then why does so little of your work show up in the community repository? Does software.coop just not do much software development? Clay On Tue, Jun 7, 2011 at 5:28 AM, MJ Ray wrote: > Brendan A. Gallagher wrote: > > Please get your facts straight before you continue with this thread > > and us other companies names. Comment in-line. > > Yes, I agree with that sentiment. Liblime workers appearing to > actively fib about other community participants is a new step back. > > > On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote: > > > Is Software Coop's fork Koha? > > No, and we don't market it as such. (It's software.coop, by the way.) > > All but one of our libraries are on Koha releases available from > koha-community.org and all patches we create are sent back, > but those have been fairly small and sporadic since then. The > release management seems much better in 3.2 and 3.4. > > For anyone new to this topic, that fork is a single-library variant of > Koha which I feel Liblime forced us into a few years ago. The 3.0 > release manager (Josh, then owner of Liblime) refused to hold back > from adopting a feature in one of the template modules that: > > 1. was not portable; > 2. Liblime had requested; > 3. was not packaged for mainstream operating systems yet; and > 4. did not compile on that library's servers at that time. > > Remember that Josh had announced Koha 3.0 would be released at the end > of 2006, then in July 2008, he presented us with the prospect that a > library which had patiently helped us to develop 3.0 wouldn't be able > to use it when it was released! The co-op's core mission is "to > provide computer-related services" so we did what we had to do to > serve that library. > > The main bit of the thread provoking the fork starts at > > http://lists.koha-community.org/pipermail/koha-patches/2008-July/007016.html > > tl;dr where I disclose that we've forked for the one library is > > http://lists.koha-community.org/pipermail/koha-patches/2008-August/007309.html > > > > I understand there are large differences that they are not paying > > > to port back into the community base. > > What gave you that idea? The co-op is using our own money to fund > porting them back (for various reasons rooted in government cuts IMO, > the original project won't complete any time soon), so it's taking far > longer than I would like. I shudder to think of the cost that this > fork has incurred. > > > I even recall seeing an announcement that someone was paying ByWater > > to do the work of porting the coop's EDI code back to > > community. Does this qualify as "cooperation"? > > That EDI code was developed for the same one library which is why it's > based on the fork. Bywater have agreed to help us with porting this > back sooner and we really appreciate that, but I don't remember any > announcement about someone paying them to do it. Please post links, > like I did above, so anyone can see for themselves. > > > How is this different from LibLime publishing its code so that any > > library is welcome to pay the vendor of their choosing to back port > > it to community? > > Key differences: > > 1. the fork exists mainly because of Liblime's 3.0 release manager; > > 2. it's used at one library and we've been quite open about that; > > 3. we still support the community, on IRC, web, in meetings, and so on; > > 4. we have never tried to pass the fork off as Koha or booted the > community out of resources they developed; > > 5. despite the massive cost, we will port the key features and not > publish a tangled mess as abandonware for the community to sort out; > > 6. we have shared it with other Koha developers, both at Kohacon10 > and otherwise; > > 7. we normally sell the proper Koha releases. > > > Software Coop is not paying ByWater Solutions to rebase EDI for > > Koha. This is a project that we are pursuing and we are using our > > own money to fund for our time to rebase this code. [...] > > Thanks to Bywater, once again. > > > Hopefully that makes sense - if not, you are welcome to give me a > > phone call whenever you want. > > Similarly, anyone is welcome to call the co-op - we now have local > access numbers in over 35 countries, linked on > http://www.software.coop/contact/ > > Hope that clarifies, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for various work through http://www.software.coop/ > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfouts at liblime.com Tue Jun 7 22:14:03 2011 From: cfouts at liblime.com (Clay Fouts) Date: Tue, 7 Jun 2011 13:14:03 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <4E3AE33F-7A1C-4330-94F0-E63B3AB93B5A@kohaaloha.com> References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> <4E3AE33F-7A1C-4330-94F0-E63B3AB93B5A@kohaaloha.com> Message-ID: On Mon, Jun 6, 2011 at 5:19 PM, James, Mason wrote: > the big difference is that Biblibre, software-coop, (and all other Koha > support companies) do *not* make their own Koha releases, > unlike PTFS/Liblime > > BL and SW-COOP understand that having many company-releases of many > Koha-forks is harmful to the reputation of the Koha project, so they > respectfully choose not to do that... (a subtle point that only PTFS/Liblime > fail to understand) > There are a large number of successful open source software projects that defy this supposition. Forks are a vital part of the open source ecosystem that provide competitive feedback into the software development process. PTFS/Liblime is the *only* company that continues to release its own 'Koha', > and the only company to renege on it commitment to integrate its > enhancements back to the Koha codebase > > PTFS/Liblime seem to have missed the fundamental point of participating in > the Koha project. > I think it's fair to say there's disagreement on what the fundamental point of participating in the Koha project is. Regards, Clay -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfouts at liblime.com Tue Jun 7 22:34:25 2011 From: cfouts at liblime.com (Clay Fouts) Date: Tue, 7 Jun 2011 13:34:25 -0700 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <4DEE29D8.6020401@biblibre.com> References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> <4DEE29D8.6020401@biblibre.com> Message-ID: Hello, Paul. What you describe here is an insightful analysis followed up with a perfectly valid decision that embodies that priorities you've set for your business in order to benefit your customers. There is a value in seeking to keep in sync with the git.koha-community.org repo, and there is value in diverging from it. It's a matter of personal and business priorities which path to take, and I respect everyone to make that decision for themselves. Cheers, Clay On Tue, Jun 7, 2011 at 6:38 AM, Paul Poulain wrote: > Le 06/06/2011 18:05, Clay Fouts a ?crit : > > Each vendor has their own (sometimes very large) customizations that > > they may or may not port back into community code. The community RM > > may or may not accept these back ports even if effort is made to > > rebase them. Please point to the line distinguishing "Koha" from "not > > Koha". > Well, I think we are mixing 2 things : > * local & specific customizations > * fork > > a local and specific customization: it occur very often. For example, > one of our customer has very long barcodes, and the barcode length in > the database is not enough for them. it's specific to the customer, and > has nothing to do with a public version. Sometimes, it's not that small > (even if it's local). For example, for Aix-Marseille universities, we > changed the circulation (check-out) workflow to query a NFC reader& > database. The NFC card & database is responsible to say if a card is > valid and fill the members table in Koha database. This is OpenSource > (GPL), available on our public git repo, but won't be submitted to the > community, it's useless unless you've this exact technology. I agree it > can be worth for a library using the same NFC technology and we could > have announced what we made more widely. Our fault, nobody's perfect > (announcement : if you've a 'horoquartz' NFC technology, you can drop me > a mail ;-) ) > > a fork. Do we have a fork ? Frankly, yes, but 1- we didn't wanted this > to happen, 2- we do all what we can to fix this (yes we consider it's a > "bug"). Reminder about the history : Koha 3.2 has been delayed due to > events we all know here (for newbies, see : > http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html), > thus many feature we have developed have needed too much time to reach > master (and had to be splitted/merged/...) > > I'm on my way to write a mail on our blog to detail how it happens, why > we consider it a bug (and want to fix it), and what's the strategy to > avoid it to happen again. > In a few word: > * we deploy only community version > * if you sponsor a feature 2 options : you sponsor and use it live when > it's in master, you sponsor, go live immediately. BUT if it's not > included in master, then you'll have either to choose to switch back to > community version (and forget you stuff), wait until it's in master, > sign a specific contract for support from BibLibre (or someone else) to > have your nice-feature-not-in-master rebased regularly vs master. > * there are only a few things in "3.2 biblibre" that are not in 3.4, and > everything will be in 3.6. > > > Is BibLibre's fork Koha? They have substantial, potentially > > irreconcilable differences that appear not to be destined for the > > community base and their extremely patient efforts to point this out > > and seek solution are met with little more than a dismissive that > > "well, that's your problem." Who is or isn't cooperating this case? > Well, you're not completely wrong. I'm sometimes quite upset by > "community". And I'm sure "community" is sometimes upset by me too ;-) . > But I still think it's better to have strong discussions and arguments > than doing our way without "the community". > > Hope that explains > > -- > 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 at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccalle at umsa.bo Wed Jun 8 00:03:10 2011 From: ccalle at umsa.bo (ccalle) Date: Tue, 07 Jun 2011 18:03:10 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> <4DEE29D8.6020401@biblibre.com> Message-ID: <8109da8875ebcf24aae349153a134fae@umsa.bo> Estimates This is a topic which I fully understand what is happening with the versions, and what I personally favor is changing URL and the business sense behind that there Koha, Koha we adopt in our University and thanks to community and (http://koha-community.org/) achieves important objectives. I do not think there is another alternative as this community that we are the programmers who love freedom. Never fails KOHA (http://koha-community.org/) from Bolivia. Thanks. Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: ccalle at umsa.bo Cel: 73017301 On Tue, 7 Jun 2011 13:34:25 -0700, Clay Fouts wrote: > Hello, Paul. > > What you describe here is an insightful analysis followed up with a > perfectly valid decision that embodies that priorities you've set for > your business in order to benefit your customers. There is a value in > seeking to keep in sync with the git.koha-community.org [1] repo, and > there is value in diverging from it. It's a matter of personal and > business priorities which path to take, and I respect everyone to make > that decision for themselves. > > Cheers, > Clay > > On Tue, Jun 7, 2011 at 6:38 AM, Paul Poulain wrote: > Le 06/06/2011 18:05, Clay Fouts a ?crit : > >> Each vendor has their own (sometimes very large) customizations > that > > they may or may not port back into community code. The community > RM > > may or may not accept these back ports even if effort is made to > > rebase them. Please point to the line distinguishing "Koha" from > "not > > Koha". > Well, I think we are mixing 2 things : > * local & specific customizations > * fork > > a local and specific customization: it occur very often. For > example, > one of our customer has very long barcodes, and the barcode length > in > the database is not enough for them. it's specific to the customer, > and > has nothing to do with a public version. Sometimes, it's not that > small > (even if it's local). For example, for Aix-Marseille universities, > we > changed the circulation (check-out) workflow to query a NFC reader& > database. The NFC card & database is responsible to say if a card is > valid and fill the members table in Koha database. This is > OpenSource > (GPL), available on our public git repo, but won't be submitted to > the > community, it's useless unless you've this exact technology. I agree > it > can be worth for a library using the same NFC technology and we > could > have announced what we made more widely. Our fault, nobody's perfect > (announcement : if you've a 'horoquartz' NFC technology, you can > drop me > a mail ;-) ) > > a fork. Do we have a fork ? Frankly, yes, but 1- we didn't wanted > this > to happen, 2- we do all what we can to fix this (yes we consider > it's a > "bug"). Reminder about the history : Koha 3.2 has been delayed due > to > events we all know here (for newbies, see : > http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html > [3]), > thus many feature we have developed have needed too much time to > reach > master (and had to be splitted/merged/...) > > I'm on my way to write a mail on our blog to detail how it happens, > why > we consider it a bug (and want to fix it), and what's the strategy > to > avoid it to happen again. > In a few word: > * we deploy only community version > * if you sponsor a feature 2 options : you sponsor and use it live > when > it's in master, you sponsor, go live immediately. BUT if it's not > included in master, then you'll have either to choose to switch back > to > community version (and forget you stuff), wait until it's in master, > sign a specific contract for support from BibLibre (or someone else) > to > have your nice-feature-not-in-master rebased regularly vs master. > * there are only a few things in "3.2 biblibre" that are not in 3.4, > and > everything will be in 3.6. > > > Is BibLibre's fork Koha? They have substantial, potentially > > irreconcilable differences that appear not to be destined for the > > community base and their extremely patient efforts to point this > out > > and seek solution are met with little more than a dismissive that > > "well, that's your problem." Who is or isn't cooperating this > case? > Well, you're not completely wrong. I'm sometimes quite upset by > "community". And I'm sure "community" is sometimes upset by me too > ;-) . > But I still think it's better to have strong discussions and > arguments > than doing our way without "the community". > > Hope that explains > > -- > Paul POULAIN > http://www.biblibre.com [4] > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org [5] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > [6] > website : http://www.koha-community.org/ [7] > git : http://git.koha-community.org/ [8] > bugs : http://bugs.koha-community.org/ [9] > > > > Links: > ------ > [1] http://git.koha-community.org > [2] mailto:paul.poulain at biblibre.com > [3] > http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html > [4] http://www.biblibre.com > [5] mailto:Koha-devel at lists.koha-community.org > [6] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > [7] http://www.koha-community.org/ > [8] http://git.koha-community.org/ > [9] http://bugs.koha-community.org/ -- Atte -- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: ccalle at umsa.bo Cel: 73017301 From chrisc at catalyst.net.nz Wed Jun 8 00:30:47 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 8 Jun 2011 10:30:47 +1200 Subject: [Koha-devel] Koha More regarding local call number search/barcodes In-Reply-To: <4DEE1E67.2040507@mdah.state.ms.us> References: <4DE7FD8F.2050604@mdah.state.ms.us> <4DED1FF9.2010108@mdah.state.ms.us> <4DED2240.9020000@mdah.state.ms.us> <4DEDB286.8030907@biblibre.com> <4DEE1E67.2040507@mdah.state.ms.us> Message-ID: <20110607223047.GD13034@rorohiko.wgtn.cat-it.co.nz> * Linda Culberson (lculber at mdah.state.ms.us) wrote: > All, > At Chris's suggestion, I'm moving this to the development list. It > seems to me that Henri-Damien is correct in that exact would be > better for the sn and bc indexes but that the phrase might work > better for call numbers. Since I am very much a newbie at this, > I'd like to hear from those more experienced about the best way to > proceed. > I bow to Henri-Damien on this one, he has much better knowledge of it than I do. > Do I need to put this discussion on bugzilla or just the outcome of > the discussion when we're ready to proceed? > The outcome summarised is perfectly fine > We are very interested in contributing but don't want to create any > problems when trying to fix something. > I'm sure you will do fine. And there's nothing that can be done that can't be undone, so never fear ;) Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From cnighswonger at foundations.edu Wed Jun 8 00:35:00 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 7 Jun 2011 18:35:00 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: References: <489FB4A6-1B5B-48B1-A0CE-2B4A34560276@kohaaloha.com> Message-ID: On Mon, Jun 6, 2011 at 2:19 PM, Clay Fouts wrote: > On Mon, Jun 6, 2011 at 10:48 AM, Chris Nighswonger > wrote: >> >> standard. In the Koha community that standard has long been the code >> >> base in the main repo. So every fork is by definition only as nearly >> "Koha" as it conforms to that standard. Thus, the larger the delta >> between the fork and the main repo, the less the fork can be said to >> be "Koha." Its an inverse relationship if that is clearer. At this >> point in history, LibLime's fork has a pretty large delta and so is >> less "Koha" than other forks. > > You speak like you haven't looked at the BibLibre diffs. I don't know that > they're at any less of a delta than LibLime, and it's only getting larger. Rather the contrary, I am familiar with the size of the delta between BL's repo and the main repo. However, (as others have ably pointed out to you) that delta is rapidly shrinking to BL's credit. and it appears from the remainder of your statement that it is you who have not taken time to accurately access those diffs. > They are a very productive group. Where is your indignation when they call > their product Koha? Software Coop, who apparently has no ambition to back > port their own code, sells "Koha" support. Do you tell people that their > software isn't really Koha? These folks are obviously selling work that > differs remarkably from "Koha" as you've defined it, and to my knowledge > they don't even differentiate it with a "BibLibre Koha" or a "Software Coop" > Koha the way that LibLime has chosen to do. Again, as others have pointed out, no one apart from LL/PTFS attempts to "release" some "other" product which they call Koha and at a minimum imply is an "official" release, trying to best the true Koha by advancing a major version number in that "other" product. > You can be chafed at the fact that LibLime took liberties that you don't > like with the koha.org website, and I can accept and empathize with that. > However, your contention that LibLime's code "isn't Koha" and somehow these > other projects are is rather incoherent. It appears that others on the list had no problem understanding my train of thought. Perhaps the problem here is not so much with my contention being incoherent as with your corporate enforced presupposition preventing your own coherent understanding of my contention. > The frequency with which we hear the phrase "New Zealand Koha" at > conventions suggests the confusion may be deeper and more widespread than > you have led yourself to believe. Since I've never heard anyone refer to "New Zealand Koha," I would have to say that you must move in a very limited circle at these conventions. In practice, what is said at conventions usually ends up on a list or blog somewhere, so I must beg to be pointed to a source to support the assertion that this title is applied at all, much less with "frequency." And finally, at least I can speak what I believe without fear of losing my job. I think that not many have that privilege, and so their judgment tends to be clouded by pecuniary interests of some sort or at a minimum they speak with a conflict of interest. If that steps on some toes, so be it, but I believe it places those who occupy such ground at the unique advantage of a rather more objective view of the facts. If you disagree, that's certainly ok. Many a pilot has run his plane into the ground because he would not yield to the more objective view of the controller in the tower. I suppose we'll just have to sit it out and see who's plane ends up nose first in the ground won't we? Kind Regards, Chris From mjr at phonecoop.coop Wed Jun 8 01:06:04 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 8 Jun 2011 00:06:04 +0100 (BST) Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: Message-ID: <20110607230604.36AD1F6610@nail.towers.org.uk> Clay Fouts wrote: > "1. the fork exists mainly because of Liblime's 3.0 release manager;" > > Back to "Josh made me do it!" chorus... Yeah, well, truth doesn't change over time. I posted the links for all to read the actual exchange as it happened. > Five months of lead time is not > exactly a last minute change. But I suppose that's as good of excuse as any. It wasn't an simple bug to identify, as the somewhat off-beam suggestions from @liblime in that thread hopefully illustrate. Not an excuse, just an explanation. Interesting that you suggest forks need excusing: I guess PTFS knows the Liblime forks are a fankle. > I stand corrected in regards to you passing off your fork as "Koha". So then > why does so little of your work show up in the community repository? Does > software.coop just not do much software development? We're not doing as much Koha development as I'd like just now. We're doing more development on other things, some of which support our Koha deployments (like the git-bz patch I published this week, for example), plus one or two that don't. The bulk of our Koha development is in reconciling that fork, so some day soon there should be a couple of surges and we'll be basically back on track, working on new stuff for the mainline again at last. Other than that, we work on the various websites and give some support on IRC and mailing lists, as well as serve our own libraries. And how about PTFS? Why's it taking so long to reconcile the Limlibe fork? Does PTFS just not do much software development? -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From oleonard at myacpl.org Wed Jun 8 02:30:40 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 7 Jun 2011 20:30:40 -0400 Subject: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 In-Reply-To: <20110607230604.36AD1F6610@nail.towers.org.uk> References: <20110607230604.36AD1F6610@nail.towers.org.uk> Message-ID: I think it's time for this thread to end. No one is going to convince Clay that PTFS is doing it wrong, and Clay isn't going to convince the rest of us that PTFS isn't. This list is for discussing Koha, and 99% of us know what that means perfectly well. I suggest anyone still interested in this argument should take it off-list, IMO. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From M.de.Rooy at rijksmuseum.nl Wed Jun 8 16:01:58 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 8 Jun 2011 14:01:58 +0000 Subject: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312D477E@S-MAIL-1B.rijksmuseum.intra> Fridolyn [AND others as well]: Thanks for responding. I tried connecting to BNF, but it failed me again. Could this be related to the userid and password? (I also tried without user and pw.) Please note that the other target mentioned earlier functions well. But could you answer the following question please? Or someone else from the list? Would it be interesting for you to Z3950-search MARC21 targets too from your UNIMARC Koha? I made some changes in the script and am able to search both "worlds". MARC and Card view work fine. Only obstacle remains the Import, because it assumes that all records are in the system MARC flavour. It would not be so hard to convert most (important) fields vice versa when copying them to the framework in the addbiblio script. Regards, Marcel ________________________________ Van: Fridolyn SOMERS [fridolyn.somers at gmail.com] Verzonden: maandag 6 juni 2011 17:30 Aan: Marcel de Rooy CC: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Z3950 search/UNIMARC Hie, Z3950 search in Koha works well with the BFN server. See french default installation : http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=installer/data/mysql/fr-FR/2-Optionel/z3950_BNF.sql;h=cde873e1bb834ec2f1634e65d824ea483c818776;hb=HEAD Regards, 2011/6/6 Marcel de Rooy > Hi all, I am testing some changes in z3950_search.pl and I am wondering if the default Koha z3950 script correctly functions for unimarc targets (with marcflavor to unimarc as well of course). Could anyone of you using z3950 with unimarc reply on that? Is the MARC and Card view on the results screen correct too? Did you encounter problems with encodings? MARC-8, UTF-8, etc.? I tested with carmin.sudoc.abes.fr z3950 target? Could you recommend another one? Thanks for some feedback, Marcel _______________________________________________ Koha-devel mailing list Koha-devel at 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/ -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolyn.somers at gmail.com Wed Jun 8 18:33:07 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Wed, 8 Jun 2011 18:33:07 +0200 Subject: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA312D477E@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA312D477E@S-MAIL-1B.rijksmuseum.intra> Message-ID: Yes, I'm intrested. I'm working on Z3950 UNIMARC correction. On Wed, Jun 8, 2011 at 4:01 PM, Marcel de Rooy wrote: > Fridolyn [AND others as well]: > > > > Thanks for responding. I tried connecting to BNF, but it failed me again. > Could this be related to the userid and password? (I also tried without user > and pw.) Please note that the other target mentioned earlier functions well. > > > But could you answer the following question please? Or someone else from > the list? > > > > Would it be interesting for you to Z3950-search MARC21 targets too from > your UNIMARC Koha? I made some changes in the script and am able to search > both "worlds". MARC and Card view work fine. Only obstacle remains the > Import, because it assumes that all records are in the system MARC flavour. > > It would not be so hard to convert most (important) fields vice versa when > copying them to the framework in the addbiblio script. > > > > Regards, > > Marcel > ------------------------------ > *Van:* Fridolyn SOMERS [fridolyn.somers at gmail.com] > *Verzonden:* maandag 6 juni 2011 17:30 > *Aan:* Marcel de Rooy > *CC:* koha-devel at lists.koha-community.org > *Onderwerp:* Re: [Koha-devel] Z3950 search/UNIMARC > > Hie, > > Z3950 search in Koha works well with the BFN server. > See french default installation : > > http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=installer/data/mysql/fr-FR/2-Optionel/z3950_BNF.sql;h=cde873e1bb834ec2f1634e65d824ea483c818776;hb=HEAD > > Regards, > > > 2011/6/6 Marcel de Rooy > >> Hi all, >> >> >> >> I am testing some changes in z3950_search.pl and I am wondering if the >> default Koha z3950 script correctly functions for unimarc targets (with >> marcflavor to unimarc as well of course). >> >> Could anyone of you using z3950 with unimarc reply on that? >> >> Is the MARC and Card view on the results screen correct too? >> >> Did you encounter problems with encodings? MARC-8, UTF-8, etc.? >> >> I tested with carmin.sudoc.abes.fr z3950 target? Could you recommend >> another one? >> >> >> >> Thanks for some feedback, >> >> >> >> Marcel >> >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at 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/ >> > > > > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From laurenthdl at alinto.com Wed Jun 8 18:45:32 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Wed, 08 Jun 2011 18:45:32 +0200 Subject: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA312D477E@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4DEFA72C.6090805@alinto.com> Hi, Marcel, Fridolyn BibLibre did an enhancement to z3950 target so that user can choose an xslt for the results. We would be interested in seeing what was done, you can take a look there : http://git.biblibre.com/?p=koha;a=shortlog;h=refs/heads/origin/wip/limoges/MT4735 It should enable the libraries to add more sources and take advantage of xslt to import those entries into their own catalogue. I am quite curious about your developments Marcel. Hope that helps. -- Henri-Damien LAURENT Le 08/06/2011 18:33, Fridolyn SOMERS a ?crit : > Yes, I'm intrested. > I'm working on Z3950 UNIMARC correction. > > On Wed, Jun 8, 2011 at 4:01 PM, Marcel de Rooy > wrote: > > Fridolyn [AND others as well]: > > > > Thanks for responding. I tried connecting to BNF, but it failed me > again. Could this be related to the userid and password? (I also > tried without user and pw.) Please note that the other target > mentioned earlier functions well. > > But could you answer the following question please? Or someone else > from the list? > > > > Would it be interesting for you to Z3950-search MARC21 targets too > from your UNIMARC Koha? I made some changes in the script and am > able to search both "worlds". MARC and Card view work fine. Only > obstacle remains the Import, because it assumes that all records are > in the system MARC flavour. > > It would not be so hard to convert most (important) fields vice > versa when copying them to the framework in the addbiblio script. > > > > Regards, > > Marcel > > ------------------------------------------------------------------------ > *Van:* Fridolyn SOMERS [fridolyn.somers at gmail.com > ] > *Verzonden:* maandag 6 juni 2011 17:30 > *Aan:* Marcel de Rooy > *CC:* koha-devel at lists.koha-community.org > > *Onderwerp:* Re: [Koha-devel] Z3950 search/UNIMARC > > Hie, > > Z3950 search in Koha works well with the BFN server. > See french default installation : > http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=installer/data/mysql/fr-FR/2-Optionel/z3950_BNF.sql;h=cde873e1bb834ec2f1634e65d824ea483c818776;hb=HEAD > > Regards, > > > 2011/6/6 Marcel de Rooy > > > Hi all, > > > > I am testing some changes in z3950_search.pl > and I am wondering if the default Koha > z3950 script correctly functions for unimarc targets (with > marcflavor to unimarc as well of course). > > Could anyone of you using z3950 with unimarc reply on that? > > Is the MARC and Card view on the results screen correct too? > > Did you encounter problems with encodings? MARC-8, UTF-8, etc.? > > I tested with carmin.sudoc.abes.fr > z3950 target? Could you recommend another one? > > > > Thanks for some feedback, > > > > Marcel > > > From M.de.Rooy at rijksmuseum.nl Thu Jun 9 08:59:04 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 9 Jun 2011 06:59:04 +0000 Subject: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets In-Reply-To: <4DEFA72C.6090805@alinto.com> References: <809BE39CD64BFD4EB9036172EBCCFA312D477E@S-MAIL-1B.rijksmuseum.intra> <4DEFA72C.6090805@alinto.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312D4B31@S-MAIL-1B.rijksmuseum.intra> Hi Henri-Damien, Your changes look very good. I would like to incorporate them; we were thinking the same. I made some similar changes to the code in order to also include SRU targets. Could you pass me the stylesheet you use to switch the marc dialect? Will send you my code after I added the xslt and some sru query translations. Thanks! Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens LAURENT Henri-Damien Verzonden: woensdag 8 juni 2011 18:46 Aan: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets Hi, Marcel, Fridolyn BibLibre did an enhancement to z3950 target so that user can choose an xslt for the results. We would be interested in seeing what was done, you can take a look there : http://git.biblibre.com/?p=koha;a=shortlog;h=refs/heads/origin/wip/limoges/MT4735 It should enable the libraries to add more sources and take advantage of xslt to import those entries into their own catalogue. I am quite curious about your developments Marcel. Hope that helps. -- Henri-Damien LAURENT Le 08/06/2011 18:33, Fridolyn SOMERS a ?crit : > Yes, I'm intrested. > I'm working on Z3950 UNIMARC correction. > > On Wed, Jun 8, 2011 at 4:01 PM, Marcel de Rooy > wrote: > > Fridolyn [AND others as well]: > > > > Thanks for responding. I tried connecting to BNF, but it failed me > again. Could this be related to the userid and password? (I also > tried without user and pw.) Please note that the other target > mentioned earlier functions well. > > But could you answer the following question please? Or someone else > from the list? > > > > Would it be interesting for you to Z3950-search MARC21 targets too > from your UNIMARC Koha? I made some changes in the script and am > able to search both "worlds". MARC and Card view work fine. Only > obstacle remains the Import, because it assumes that all records are > in the system MARC flavour. > > It would not be so hard to convert most (important) fields vice > versa when copying them to the framework in the addbiblio script. > > > > Regards, > > Marcel > > ------------------------------------------------------------------------ > *Van:* Fridolyn SOMERS [fridolyn.somers at gmail.com > ] > *Verzonden:* maandag 6 juni 2011 17:30 > *Aan:* Marcel de Rooy > *CC:* koha-devel at lists.koha-community.org > > *Onderwerp:* Re: [Koha-devel] Z3950 search/UNIMARC > > Hie, > > Z3950 search in Koha works well with the BFN server. > See french default installation : > http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=installer/data/mysql/fr-FR/2-Optionel/z3950_BNF.sql;h=cde873e1bb834ec2f1634e65d824ea483c818776;hb=HEAD > > Regards, > > > 2011/6/6 Marcel de Rooy > > > Hi all, > > > > I am testing some changes in z3950_search.pl > and I am wondering if the default Koha > z3950 script correctly functions for unimarc targets (with > marcflavor to unimarc as well of course). > > Could anyone of you using z3950 with unimarc reply on that? > > Is the MARC and Card view on the results screen correct too? > > Did you encounter problems with encodings? MARC-8, UTF-8, etc.? > > I tested with carmin.sudoc.abes.fr > z3950 target? Could you recommend another one? > > > > Thanks for some feedback, > > > > Marcel > > > _______________________________________________ Koha-devel mailing list Koha-devel at 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/ From laurenthdl at alinto.com Thu Jun 9 09:13:23 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Thu, 09 Jun 2011 09:13:23 +0200 Subject: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA312D4B31@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA312D477E@S-MAIL-1B.rijksmuseum.intra> <4DEFA72C.6090805@alinto.com> <809BE39CD64BFD4EB9036172EBCCFA312D4B31@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4DF07293.3010801@alinto.com> Hi, it is already in the tree. look for crosswalk. Hope that helps. -- Henri-Damien LAURENT Le 09/06/2011 08:59, Marcel de Rooy a ?crit : > Hi Henri-Damien, > Your changes look very good. I would like to incorporate them; we were thinking the same. I made some similar changes to the code in order to also include SRU targets. > Could you pass me the stylesheet you use to switch the marc dialect? > Will send you my code after I added the xslt and some sru query translations. > Thanks! > > Marcel > > -----Oorspronkelijk bericht----- > Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens LAURENT Henri-Damien > Verzonden: woensdag 8 juni 2011 18:46 > Aan: koha-devel at lists.koha-community.org > Onderwerp: Re: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets > > Hi, > > Marcel, Fridolyn > BibLibre did an enhancement to z3950 target so that user can choose an > xslt for the results. > We would be interested in seeing what was done, you can take a look there : > http://git.biblibre.com/?p=koha;a=shortlog;h=refs/heads/origin/wip/limoges/MT4735 > It should enable the libraries to add more sources and take advantage of > xslt to import those entries into their own catalogue. > > I am quite curious about your developments Marcel. > Hope that helps. From weinheimer.jim.l at gmail.com Thu Jun 9 10:02:38 2011 From: weinheimer.jim.l at gmail.com (James Weinheimer) Date: Thu, 09 Jun 2011 10:02:38 +0200 Subject: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets In-Reply-To: <4DF07293.3010801@alinto.com> References: <809BE39CD64BFD4EB9036172EBCCFA312D477E@S-MAIL-1B.rijksmuseum.intra> <4DEFA72C.6090805@alinto.com> <809BE39CD64BFD4EB9036172EBCCFA312D4B31@S-MAIL-1B.rijksmuseum.intra> <4DF07293.3010801@alinto.com> Message-ID: <4DF07E1E.1010900@gmail.com> The Library of Congress made UNIMARC to MARC21 conversion charts. http://www.loc.gov/marc/unimarctomarc21.html Horrifying to behold, however... I would suggest focusing on converting the variable fields (200-802) and expecting the cataloger to just input the rest of the codes in the fixed fields manually, which is pretty simple most of the time. Converting all those codes would be a lot of work for very little savings. On 09/06/2011 09:13, LAURENT Henri-Damien wrote: > Hi, > it is already in the tree. > look for crosswalk. > Hope that helps. -- James Weinheimer weinheimer.jim.l at gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/ From salvazm at masmedios.com Thu Jun 9 12:03:37 2011 From: salvazm at masmedios.com (Salvador Zaragoza Rubio) Date: Thu, 09 Jun 2011 12:03:37 +0200 Subject: [Koha-devel] Items not added to Zebra in field 952 Message-ID: <4DF09A79.4040909@masmedios.com> Hi all, On my git master updated version when adding an item I can't see the item added in the 952 field of the Zebra database, it's only added to the MySQL items table. I've checked the Items.pm script and in the sub AddItem this is what we had before: # create MARC tag representing item and add to bib my $new_item_marc = _marc_from_item_hash($item, $frameworkcode, $unlinked_item_subfields); _add_item_field_to_biblio($new_item_marc, $item->{'biblionumber'}, $frameworkcode ); And now: ModZebra( $item->{biblionumber}, "specialUpdate", "biblioserver", undef, undef ); The sub _add_item_field_to_biblio is missing and the 952 is not added to the biblio record (field marcxml, filed marc in biblioitems) and the ModZebra doesn't update the record with the new 952 field. Am I missing something? Is that correct and is a planned modification about Items? I can't find a bug related with this issue. Regards Salva -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5527 bytes Desc: S/MIME Cryptographic Signature URL: From frederic at tamil.fr Thu Jun 9 12:29:26 2011 From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Thu, 09 Jun 2011 12:29:26 +0200 Subject: [Koha-devel] Items not added to Zebra in field 952 In-Reply-To: <4DF09A79.4040909@masmedios.com> References: <4DF09A79.4040909@masmedios.com> Message-ID: <4DF0A086.8080606@tamil.fr> > I can't find a bug related with this issue. Bug 5579 From M.de.Rooy at rijksmuseum.nl Thu Jun 9 12:21:09 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 9 Jun 2011 10:21:09 +0000 Subject: [Koha-devel] Items not added to Zebra in field 952 In-Reply-To: <4DF09A79.4040909@masmedios.com> References: <4DF09A79.4040909@masmedios.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312D4B7C@S-MAIL-1B.rijksmuseum.intra> Try: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5579 -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Salvador Zaragoza Rubio Verzonden: donderdag 9 juni 2011 12:04 Aan: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] Items not added to Zebra in field 952 Hi all, On my git master updated version when adding an item I can't see the item added in the 952 field of the Zebra database, it's only added to the MySQL items table. I've checked the Items.pm script and in the sub AddItem this is what we had before: # create MARC tag representing item and add to bib my $new_item_marc = _marc_from_item_hash($item, $frameworkcode, $unlinked_item_subfields); _add_item_field_to_biblio($new_item_marc, $item->{'biblionumber'}, $frameworkcode ); And now: ModZebra( $item->{biblionumber}, "specialUpdate", "biblioserver", undef, undef ); The sub _add_item_field_to_biblio is missing and the 952 is not added to the biblio record (field marcxml, filed marc in biblioitems) and the ModZebra doesn't update the record with the new 952 field. Am I missing something? Is that correct and is a planned modification about Items? I can't find a bug related with this issue. Regards Salva From salvazm at masmedios.com Thu Jun 9 12:33:27 2011 From: salvazm at masmedios.com (Salvador Zaragoza Rubio) Date: Thu, 09 Jun 2011 12:33:27 +0200 Subject: [Koha-devel] Items not added to Zebra in field 952 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA312D4B7C@S-MAIL-1B.rijksmuseum.intra> References: <4DF09A79.4040909@masmedios.com> <809BE39CD64BFD4EB9036172EBCCFA312D4B7C@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4DF0A177.5070809@masmedios.com> Thanks I totally missed this new change, now I understand. Regards El 09/06/2011 12:21, Marcel de Rooy escribi?: > Try: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5579 > > -----Oorspronkelijk bericht----- > Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Salvador Zaragoza Rubio > Verzonden: donderdag 9 juni 2011 12:04 > Aan: koha-devel at lists.koha-community.org > Onderwerp: [Koha-devel] Items not added to Zebra in field 952 > > Hi all, > > On my git master updated version when adding an item I can't see the item added in the 952 field of the Zebra database, it's only added to the MySQL items table. > > I've checked the Items.pm script and in the sub AddItem this is what we had before: > > # create MARC tag representing item and add to bib > my $new_item_marc = _marc_from_item_hash($item, $frameworkcode, $unlinked_item_subfields); > _add_item_field_to_biblio($new_item_marc, $item->{'biblionumber'}, $frameworkcode ); > > And now: > > ModZebra( $item->{biblionumber}, "specialUpdate", "biblioserver", undef, undef ); > > > The sub _add_item_field_to_biblio is missing and the 952 is not added to the biblio record (field marcxml, filed marc in biblioitems) and the ModZebra doesn't update the record with the new 952 field. > > Am I missing something? Is that correct and is a planned modification about Items? > I can't find a bug related with this issue. > > > Regards > > Salva > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5527 bytes Desc: S/MIME Cryptographic Signature URL: From Louise_Towers at hugoboss.com Thu Jun 9 13:32:32 2011 From: Louise_Towers at hugoboss.com (Louise_Towers at hugoboss.com) Date: Thu, 9 Jun 2011 13:32:32 +0200 Subject: [Koha-devel] Koha Version 3.4.1 Message-ID: Dear Sir/Madam, We need some answers and support based on Koha Version 3.4.1. We have installed and are using here at Hugo Boss Ticino but now we have some questions and require some support for a number of things - would it be possible to organise a conference call with one of your technicians or documentation managers? We know the time difference may be a problem as we are based in Switzerland but we can stay later to compensate for this - maybe 6pm our time, 9am your time tomorrow morning Friday 10th June or Tuesday 14th June? We are having problems like, if two people reserve the same book at the same time, there is no circulation email. Also, does the support for Koha have a cost for the service?? I look forward to hearing from you as soon as possible to help us use your product most effectively and efficiently, With Regards, Louise HUGO BOSS Ticino SA Louise Towers Project and Service Management Knitwear ------------------------------------------------------- Via Sant'Apollonia 32 6877 Coldrerio - CH Phone : +41 91 6966875 Fax : +41 91 6966816 e-mail: Louise_Towers at hugoboss.com www.hugoboss.com This e-mail (and/or attachments) is confidential and may be privileged. Use or disclosure of it by anyone other than a designated addressee is unauthorized. If you are not an intended recipient, please delete this e-mail from the computer on which you received it. We thank you for notifying us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bargioni at pusc.it Thu Jun 9 16:05:00 2011 From: bargioni at pusc.it (Stefano Bargioni) Date: Thu, 9 Jun 2011 16:05:00 +0200 Subject: [Koha-devel] Bug 3013 - 006 and 008 for non book material Message-ID: <2CF58115-8519-487E-8687-0046F95B2D2B@pusc.it> Hi, as I commented in http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3013 the latest patch seems ok to me (tested in Koha 3.2.3). I signed it off (in Bugzilla only, I'm not able to use git up to now, sorry). Hope it could be included in Koha 3.2.10. Bye. Stefano From mdhafen at tech.washk12.org Thu Jun 9 19:34:23 2011 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Thu, 9 Jun 2011 11:34:23 -0600 Subject: [Koha-devel] Koha Version 3.4.1 In-Reply-To: References: Message-ID: Dear Sir/Madam, You seem to have confused an open source community for a software vendor. There are a number of vendors who do provide support for the Koha software though. I'm sure they would be happy to be contacted by you. On the koha community web site there is a handy list of these companies. The url for this list is: http://koha-community.org/support/paid-support/ Have a nice day. 2011/6/9 > Dear Sir/Madam, > > We need some answers and support based on Koha Version 3.4.1. > > We have installed and are using here at Hugo Boss Ticino but now we have > some questions and require some support for a number of things - would it be > possible to organise a conference call with one of your technicians or > documentation managers? > > We know the time difference may be a problem as we are based in Switzerland > but we can stay later to compensate for this - maybe 6pm our time, 9am your > time tomorrow morning Friday 10th June or Tuesday 14th June? > > We are having problems like, if two people reserve the same book at the > same time, there is no circulation email. > > Also, does the support for Koha have a cost for the service?? > > I look forward to hearing from you as soon as possible to help us use your > product most effectively and efficiently, > > With Regards, > > Louise > > HUGO BOSS Ticino SA > Louise Towers > Project and Service Management Knitwear > ------------------------------------------------------- > Via Sant'Apollonia 32 > 6877 Coldrerio - CH > Phone : +41 91 6966875 > Fax : +41 91 6966816 > e-mail: Louise_Towers at hugoboss.com > www.hugoboss.com > > This e-mail (and/or attachments) is confidential and may be privileged. Use or disclosure of it by anyone other than a designated addressee is unauthorized. > If you are not an intended recipient, please delete this e-mail from the computer on which you received it. We thank you for notifying us immediately. > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Fri Jun 10 15:06:25 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 10 Jun 2011 15:06:25 +0200 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: References: <4D9039BA.6040802@biblibre.com> <20110328101032.C82A95025B@nail.towers.org.uk> <4D91C45A.3030500@biblibre.com> Message-ID: <4DF216D1.2030504@biblibre.com> Le 29/03/2011 13:56, Koustubha Kale a ?crit : > On Tue, Mar 29, 2011 at 5:06 PM, Paul Poulain wrote: >> Le 28/03/2011 12:45, Koustubha Kale a ?crit : >>> Here is what I suggest : >>> 1) We break for a day after the main conference on Thursday 3rd November. >>> 2) We start Hackfest in two separate nearby rooms one for teaching / >>> getting started sessions the other room for experienced developers to >>> hack together at peace. The experienced developers take breaks turn by >>> turn to deliver sessions / guidance in the first room. This goes on >>> for two days Friday 4th November and Saturday 5th November. >>> Experienced developers who can not be physically present but would >>> still like to participate in the hackfest, we will try to accommodate >>> through video conferencing. Frankly I don't know how thats gonna work >>> for hacking together, but atleast they can deliver some guidance / >>> tips to the newbies. End of day two of hackfest i.e. on Saturday 5th >>> November, the developers who can not stay more can leave but they >>> would still have had two days of hacking together. >>> 3) Those developers who can stay more are free to continue hacking >>> again from Monday 7th November for as long as they want. I am sure we >>> will find a place for them to work for as long as it takes. >> Hi, >>> How does that sound? >> My fear is that most of the devs will flight back during the week-end >> if 3) is not announced/organised. >> We must propose something very clearly, not just say "stay as long as >> you want". >> That's also a must-have for ppl that have a boss and must argue that >> they must stay for one more week. For example, I think Katrin will have >> some difficulties to argue & convince her boss ! > I completely agree that we need a fixed schedule, but IMHO its for you > people i.e. Koha developers to propose how many days you need. I will > try and arrange for facilities. thread back ... I spoke with kmkale about the hackfest. We have no alternative option for the hackfest: the week before the main conference is a holiday week in india, so, everything closed. The hackfest *must* be after the main conf. As the main conf ends on wed, the best option we see is: * thursday => break * friday -> tuesday (so *including sunday*) hackfest. * as for previous hackfest, any attendee is free to leave when needed. I like the idea of having 2 separate rooms dedicated to differents things (training, hacking,...) Does anyone have another idea/suggestion ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From kmkale at anantcorp.com Fri Jun 10 16:48:21 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Fri, 10 Jun 2011 20:18:21 +0530 Subject: [Koha-devel] Date and time of next Kohacon11 volunteers meeting Message-ID: Hi All, I had to miss the last scheduled volunteers meeting and since there were only two attendees they decided to postpone the meeting. Attendance at Kohacon11 volunteers meeting in the #koha irc channel has been poor. So here I am requesting the community to discuss & decide over email exchange, the date and timing of the next meeting so that as many as possible people may attend. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmkale at anantcorp.com Sat Jun 11 14:31:25 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sat, 11 Jun 2011 18:01:25 +0530 Subject: [Koha-devel] [Koha] Date and time of next Kohacon11 volunteers meeting In-Reply-To: <20110611120843.033D49F0D2@nail.towers.org.uk> References: <20110611120843.033D49F0D2@nail.towers.org.uk> Message-ID: On Sat, Jun 11, 2011 at 5:38 PM, MJ Ray wrote: > > Koustubha Kale wrote: > > I had to miss the last scheduled volunteers meeting and since there were > > only two attendees they decided to postpone the meeting. > > > > Attendance at Kohacon11 volunteers meeting in the #koha irc channel has been > > poor. So here I am requesting the community to discuss & decide over email > > exchange, the date and timing of the next meeting so that as many as > > possible people may attend. > > The key thing is to get you or others on-site to attend, so could > you please pick some times you can make and then put up a poll? > > We've sometimes used m.doodle.com for that, Ok. here we go. I have tried to cover the bases a bit here. Poll "Kohacon11 : Date and time of next volunteers meeting" http://doodle.com/28um6kk9c2d2r2qw Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From savitra.sirohi at osslabs.biz Mon Jun 13 07:33:19 2011 From: savitra.sirohi at osslabs.biz (savitra sirohi) Date: Mon, 13 Jun 2011 11:03:19 +0530 Subject: [Koha-devel] Converting .tmpl to .tt In-Reply-To: References: Message-ID: Hi Chris, We are looking to rebase some of our code (e.g. analytical records feature) on 3.4.x. Do you have any scripts to convert .tmpl files to .tt files? Thanks, Savitra From chrisc at catalyst.net.nz Mon Jun 13 09:42:46 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Mon, 13 Jun 2011 19:42:46 +1200 Subject: [Koha-devel] Converting .tmpl to .tt In-Reply-To: References: Message-ID: <20110613074246.GC13034@rorohiko.wgtn.cat-it.co.nz> * savitra sirohi (savitra.sirohi at osslabs.biz) wrote: > Hi Chris, > > We are looking to rebase some of our code (e.g. analytical records > feature) on 3.4.x. > > Do you have any scripts to convert .tmpl files to .tt files? > Sure do Take a look at http://lists.koha-community.org/pipermail/koha-devel/2011-April/035416.html Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From savitra.sirohi at osslabs.biz Mon Jun 13 09:54:57 2011 From: savitra.sirohi at osslabs.biz (savitra sirohi) Date: Mon, 13 Jun 2011 13:24:57 +0530 Subject: [Koha-devel] Converting .tmpl to .tt In-Reply-To: <20110613074246.GC13034@rorohiko.wgtn.cat-it.co.nz> References: <20110613074246.GC13034@rorohiko.wgtn.cat-it.co.nz> Message-ID: Thanks Chris. Sorry, should have googled it first. - Savitra On Mon, Jun 13, 2011 at 1:12 PM, Chris Cormack wrote: > * savitra sirohi (savitra.sirohi at osslabs.biz) wrote: >> Hi Chris, >> >> We are looking to rebase some of our code (e.g. analytical records >> feature) on 3.4.x. >> >> Do you have any scripts to convert .tmpl files to .tt files? >> > Sure do > > Take a look at > > http://lists.koha-community.org/pipermail/koha-devel/2011-April/035416.html > > Chris > > -- > Chris Cormack > Catalyst IT Ltd. > +64 4 803 2238 > PO Box 11-053, Manners St, Wellington 6142, New Zealand > From chrisc at catalyst.net.nz Mon Jun 13 10:10:52 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Mon, 13 Jun 2011 20:10:52 +1200 Subject: [Koha-devel] Converting .tmpl to .tt In-Reply-To: References: <20110613074246.GC13034@rorohiko.wgtn.cat-it.co.nz> Message-ID: <20110613081051.GD13034@rorohiko.wgtn.cat-it.co.nz> * savitra sirohi (savitra.sirohi at osslabs.biz) wrote: > Thanks Chris. Sorry, should have googled it first. > No worries, I only knew it was there because I remembered writing it :) Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From paul.poulain at biblibre.com Mon Jun 13 10:37:18 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 13 Jun 2011 10:37:18 +0200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <201106070123.24032.robin@catalyst.net.nz> References: <20110606084252.022CA9F0D3@nail.towers.org.uk> <201106070123.24032.robin@catalyst.net.nz> Message-ID: <4DF5CC3E.2070606@biblibre.com> Hi, 1- I like very much Robin proposals 2- i've added the topic to the next IRC meeting (http://wiki.koha-community.org/wiki/General_IRC_Meeting,_14_June_2011) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chrisc at catalyst.net.nz Mon Jun 13 10:43:09 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Mon, 13 Jun 2011 20:43:09 +1200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <4DF5CC3E.2070606@biblibre.com> References: <20110606084252.022CA9F0D3@nail.towers.org.uk> <201106070123.24032.robin@catalyst.net.nz> <4DF5CC3E.2070606@biblibre.com> Message-ID: <20110613084309.GE13034@rorohiko.wgtn.cat-it.co.nz> Back to the original topic. I have not heard back at all from Yury, so have no information on the security issue. I will try to email again. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From dschust1 at gmail.com Tue Jun 14 05:55:33 2011 From: dschust1 at gmail.com (David Schuster) Date: Mon, 13 Jun 2011 22:55:33 -0500 Subject: [Koha-devel] KUDOS looking for nominations for officers Message-ID: KUDOS - North American Koha users group is looking for nominations for the following positions: President Vice president Secretary Treasurer If you are interested in running for an office please contact me so we can put together a slate of officers. By-laws require that you have an instance of Koha running and that you work in a library. We hesitate to change the bylaws currently as they have been submitted as part of our 501c3 application to the US Government. Once we receive notification of the 501c3 application then bylaws could be adjusted to better match the will of the North American community of Koha users in allowing any individual to be a KUDOS member and run for office. Please let me know if you are interested. We are going to try and have a meeting or at least a virtual meeting in the next 2 weeks. -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmkale at anantcorp.com Tue Jun 14 07:11:26 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Tue, 14 Jun 2011 10:41:26 +0530 Subject: [Koha-devel] [Koha] Date and time of next Kohacon11 volunteers meeting In-Reply-To: References: <20110611120843.033D49F0D2@nail.towers.org.uk> Message-ID: There is a suggestion on the poll from Paul that any meeting must be informed at least one week in advance and I agree with him. Also we have not garnered much response on the poll. Only 5 votes apart from mine, so I am cancelling this poll and proposing new dates of two weeks from hence here http://www.doodle.com/b4gqk76xqq59ckxi. That will give us one week to decide the date and then one weeks warning to all concerned to attend the meeting. I will close the new poll on 21st June 2011 and send out a mail to the lists announcing the date and time getting highest votes. Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 On Sat, Jun 11, 2011 at 6:01 PM, Koustubha Kale wrote: > On Sat, Jun 11, 2011 at 5:38 PM, MJ Ray wrote: >> >> Koustubha Kale wrote: >> > I had to miss the last scheduled volunteers meeting and since there were >> > only two attendees they decided to postpone the meeting. >> > >> > Attendance at Kohacon11 volunteers meeting in the #koha irc channel has been >> > poor. So here I am requesting the community to discuss & decide over email >> > exchange, the date and timing of the next meeting so that as many as >> > possible people may attend. >> >> The key thing is to get you or others on-site to attend, so could >> you please pick some times you can make and then put up a poll? >> >> We've sometimes used m.doodle.com for that, > > Ok. here we go. I have tried to cover the bases a bit here. > > Poll "Kohacon11 : Date and time of next volunteers meeting" > > http://doodle.com/28um6kk9c2d2r2qw > > Regards, > Koustubha Kale > Anant Corporation > > Contact Details : > Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes > Naka, Thane (w), > ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. > TeleFax? : +91-22-21720108, +91-22-21720109 > Mobile? ?? : +919820715876 > Website? : http://www.anantcorp.com > Blog : http://www.anantcorp.com/blog/?author=2 > From magnus at enger.priv.no Tue Jun 14 09:30:15 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Tue, 14 Jun 2011 09:30:15 +0200 Subject: [Koha-devel] Reminder: Global sign off day 2011-06-15 (in your time zone of choice) Message-ID: Dear Koha friends! Just a gentle reminder that Global sign off day is just 2,5 hours away in Kiribati, and fast approaching for other time zones too... Se the message below for details. Best regards, Magnus Enger ---------- Forwarded message ---------- From: Magnus Enger Date: 7 June 2011 16:16 Subject: Global sign off day, 2011-06-15 To: Koha list , koha-devel at lists.koha-community.org Dear all! (And sorry for cross posting... At least a little bit ;-) We had such great fun in Marseilles earlier this year, signing off patches, that I have been wondering if it would be possible to re-create some of that experience without incurring the costs of travel. I broached the subject on IRC earlier today and after the briefest and least democratic of processes, "we" decided to declare 15th June 2011 as a Global Sign Off Day: http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 The hope is that as many people as possible will be able to set aside as much other work as possible on this day, and concentrate on signing off patches, to reduce the queue of bugs that are currently waiting for sign-off (66 at this moment: http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=cf_patch_status&query_format=advanced&type0-0-0=equals&value0-0-0=needs%20signoff&order=bug_id&list_id=7042) We will try to visualise and document the progress that is made, to make it more fun and maybe even tickle the competitive instincts a little bit... ;-) And who knows, if this day is a success, maybe we could turn it into a regular tradition? * If you have not signed off on a patch before, now is the perfect time to do it! The more the merrier! The process is outlined here: http://wiki.koha-community.org/wiki/Sign_off_on_patches And there will be people on IRC that you can ask for help and guidance! Best regards, Magnus Enger * On the other hand, let's hope we can keep the queue as short as possible... From M.de.Rooy at rijksmuseum.nl Wed Jun 15 13:45:38 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 15 Jun 2011 11:45:38 +0000 Subject: [Koha-devel] Z3950 searching on MARC as well as UNIMARC targets In-Reply-To: <4DF07293.3010801@alinto.com> References: <809BE39CD64BFD4EB9036172EBCCFA312D477E@S-MAIL-1B.rijksmuseum.intra> <4DEFA72C.6090805@alinto.com> <809BE39CD64BFD4EB9036172EBCCFA312D4B31@S-MAIL-1B.rijksmuseum.intra>, <4DF07293.3010801@alinto.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312D55A0@S-MAIL-1B.rijksmuseum.intra> BibLibre already spent time on converting MARC21 to UNIMARC via XSLT. Did anyone of you coincidentally already work on a conversion the other way around? Would like to incorporate these conversions with Z3950 searching. Thanks.. > Hi, it is already in the tree. look for crosswalk. Hope that helps. From ohiocore at gmail.com Thu Jun 16 20:12:40 2011 From: ohiocore at gmail.com (Joe Atzberger) Date: Thu, 16 Jun 2011 14:12:40 -0400 Subject: [Koha-devel] Koha Library Software In-Reply-To: <201106070123.24032.robin@catalyst.net.nz> References: <20110606084252.022CA9F0D3@nail.towers.org.uk> <201106070123.24032.robin@catalyst.net.nz> Message-ID: In security circles, if the reporter feels that the bug is not being recognized or dealt with adequately by the dedicated project team, then they have the option (and some responsibility) to report it to the wider community. But *starting* with public disclosure of a security issue is correctly regarded as irresponsible. It serves the ego, enables widespread casual exploits and makes the project look bad without giving them a chance to fix it first. Depending on the complexity of the bug and whether or not it is being actively exploited in the wild (and project release methodology), the acceptable duration can vary, anywhere from a couple weeks to several months. A reporting system can have a conservative revert-to-public duration built in. In no case is there grounds to just bury a security bug indefinitely. --joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Thu Jun 16 20:49:07 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 17 Jun 2011 06:49:07 +1200 Subject: [Koha-devel] Koha Library Software In-Reply-To: <20110613084309.GE13034@rorohiko.wgtn.cat-it.co.nz> References: <20110606084252.022CA9F0D3@nail.towers.org.uk> <201106070123.24032.robin@catalyst.net.nz> <4DF5CC3E.2070606@biblibre.com> <20110613084309.GE13034@rorohiko.wgtn.cat-it.co.nz> Message-ID: 2011/6/13 Chris Cormack : > Back to the original topic. > > I have not heard back at all from Yury, so have no information on the > security issue. I will try to email again. > I now have the report from Yury. Thank you Yury. It is not a major problem, but a problem nonetheless, happy to share info offlist and will have patches shortly. Chris From magnus at enger.priv.no Fri Jun 17 12:11:48 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Fri, 17 Jun 2011 12:11:48 +0200 Subject: [Koha-devel] Summary of Global Signoff Day 2011-06-15 - more to come? Message-ID: Dear Community! * GSOD #1 Our very first Global Signoff Day (GSOD) was held on 2011-06-15. During the 48 hours that make up a day in all available time zones, we reduced the number of bugs that had status "Needs signoff" from about 76 to about 45. (There were some bugs that got the "Needs Signoff" status during the day, which complicates counting somewhat...) You can see a more or less complete list of what bugs were changed here: http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 See the bottom of this page for some more numbers, and keep in mind that the dates there are relative to UTC: http://bugs.koha-community.org/cgi-bin/progress.pl As far as I can tell we were about 6 people signing off on things during GSOD #1, which is not an astronomical figure, but i still think we made some good inroads into the queue. (A number of the remaining bugs are actually ones that depend on other bugs that have failed QA, so they are not really available for signing off.) Imagine what we could have done if there were more of us... ;-) * GSOD #2 BibLibre have said all their staff will dedicate half a day every two weeks to signing off on bugs and similar tasks (woohoo!). I would like to propose another GSOD to coincide with their first such day, which is scheduled for 2011-07-08. Motto: "The more, the merrier"! Some questions spring to mind: - How can we get more people involved? - Should the name of the "event" reflect that other activities (such as closing bugs) are encouraged too? - How can we make it even more fun? -- Better/other lists and visualisations? -- Could we have the huginn bot on IRC annonunce new signoffs, the same way it does "needs signoff"s? -- Could we use some kind of VoIP/videoconferencing tools to make the social interactions seem more um... "real"? Or is GSOD a really bad idea, would it be better to channel our energy into making signoffs (and similar activities) look more like an ongoing task, and less something you only have to think about once a month? Best regards, Magnus Enger From magnus at enger.priv.no Fri Jun 17 12:24:27 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Fri, 17 Jun 2011 12:24:27 +0200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: <1306710319.2375.91.camel@zarathud> References: <1306710319.2375.91.camel@zarathud> Message-ID: 2011/5/30 Robin Sheat : > Magnus Enger schreef op vr 27-05-2011 om 14:46 [+0200]: >> Looks to me like the packaging/packages is doing some rearranging of >> the CSS files that only works for the English templates and not for >> templates translated into other languages? Are there any package gurus >> out there who are able to see what is going on? > > From the debian/rules file: > > rm -r $(TMP)/usr/share/koha/opac/htdocs/opac-tmpl/prog/en/lib/yui > ln -s /usr/share/javascript/yui $(TMP)/usr/share/koha/opac/htdocs/opac-tmpl/prog/en/lib/yui > > and then a bunch of installs of css and png files > into ...-tmp/prog/en/css. Perhaps this is what you're seeing that causes > things to lay out differently. Finally some time to look at this again... Yup, that is definitely the heart of the matter! Installing another language replicates lots of JS/CSS/image stuff from opac-tmpl/prog/en/ to e.g. opac-tmpl/prog/nb-NO/ and then the packaging process comes in and does it's magic, but only on the stuff in opac-tmpl/prog/en/ and not on the stuff that has been installed for any other languages. The weird thing is that it seems to work just fine for the Intranet, but not for the OPAC... I am not sure why yet. So far, these are the possibilities I can see: - Move the JS/CSS stuff out of the language specific directories and have all languages use this stuff from one and the same location. - Make debian/rules do it's stuff for all installed languages with some kind of foreach-loop, if that is possible - Find another way to handle translations than the process I am trying now (install the languages, commit the resulting files with git, build packages with build-git-snapshot) - Make custom versions of debian/rules to accommodate translations, I'm currently testing this: http://div.libriotech.no/kohadeb/rules - the packages are being built as we speak Best regards, Magnus Enger libriotech.no From magnus at enger.priv.no Fri Jun 17 12:38:01 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Fri, 17 Jun 2011 12:38:01 +0200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: References: <1306710319.2375.91.camel@zarathud> Message-ID: On 17 June 2011 12:24, Magnus Enger wrote: > - Make custom versions of debian/rules to accommodate translations, > I'm currently testing this: http://div.libriotech.no/kohadeb/rules - > the packages are being built as we speak PS Looks like that actually worked! ;-) Magnus From abesottedphoenix at yahoo.com Fri Jun 17 13:21:24 2011 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Fri, 17 Jun 2011 04:21:24 -0700 (PDT) Subject: [Koha-devel] [Koha] Summary of Global Signoff Day 2011-06-15 - more to come? In-Reply-To: References: Message-ID: <1308309684.71783.YahooMailNeo@web114703.mail.gq1.yahoo.com> Kia ora! > -- Better/other lists and visualisations? A notch in the belt visualisation. You know you wanna. > -- Could we use some kind of VoIP/videoconferencing tools to make the > social interactions seem more um... "real"? > Mumble, it's like Ventrilo, but bettah. http://sourceforge.net/projects/mumble/ The question would be would this leave a few folks out in the cold if they've a crap connection. Cheers, Brooke From nengard at gmail.com Fri Jun 17 15:15:18 2011 From: nengard at gmail.com (Nicole Engard) Date: Fri, 17 Jun 2011 09:15:18 -0400 Subject: [Koha-devel] Newsletter Call for Articles Message-ID: It's that time again and shockingly I already have three articles (without asking). If you have an article you want in the newsletter please get it to me before the 21st of June so that I can finish up the newsletter before I go out of town for ALA. Thanks Nicole From mjr at phonecoop.coop Sun Jun 19 16:16:57 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Sun, 19 Jun 2011 15:16:57 +0100 (BST) Subject: [Koha-devel] [Koha] Summary of Global Signoff Day 2011-06-15 - more to come? In-Reply-To: Message-ID: <20110619141657.4F3C89F0D2@nail.towers.org.uk> Magnus Enger wrote: > * GSOD #1 [...] > You can see a more or less complete list of what bugs were changed here: > http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 Thanks for the summary, Magnus! I was unaware of that page, so did not edit it when reviewing or signing off. Editing a wiki page seems a bit odd: doesn't bugzilla track status and who's working on a bug already? Commenting on the bug or hopping on IRC seems a good idea if you absolutely want to avoid the risk of "two signoffs, one bug" (I apologise for that image ;-) ). > As far as I can tell we were about 6 people signing off on things JOOI, how can you tell that? > * GSOD #2 > > BibLibre have said all their staff will dedicate half a day every two > weeks to signing off on bugs and similar tasks (woohoo!). I would like > to propose another GSOD to coincide with their first such day, which > is scheduled for 2011-07-08. Motto: "The more, the merrier"! I send my regrets. I think that's the second Friday of Co-operatives Fortnight here and I will be occupied with co-op community events. > Some questions spring to mind: > > - How can we get more people involved? > - Should the name of the "event" reflect that other activities (such > as closing bugs) are encouraged too? Yes, if they are. Bug Squashing Party is used in debian. http://wiki.debian.org/BSP > - How can we make it even more fun? > -- Better/other lists and visualisations? > -- Could we have the huginn bot on IRC annonunce new signoffs, the > same way it does "needs signoff"s? > -- Could we use some kind of VoIP/videoconferencing tools to make the > social interactions seem more um... "real"? I'm unsure about conferencing because it seems like it would need its own effort to set up (I'd go for a simple SIP party-line, but I'm sure there are others using incompatible systems which I wouldn't want to use either) and keep running. It may also suffer from the synchronisation problem worse than IRC currently does. Yes to lists and bots - maybe we could reuse some of the tools from another bugzilla-using project's bug-squash party? I'm not sure where to look for that though. > Or is GSOD a really bad idea, would it be better to channel our energy > into making signoffs (and similar activities) look more like an > ongoing task, and less something you only have to think about once a > month? I think spot events are good when we want to bring a count down. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From paivakil at gmail.com Sun Jun 19 18:10:32 2011 From: paivakil at gmail.com (Mahesh T Pai) Date: Sun, 19 Jun 2011 21:40:32 +0530 Subject: [Koha-devel] Wrong Links on Staff Client. (v. 3.4.1) Message-ID: <8762o1by4n.fsf@gmail.com> I know this ought be reported as a bug, but I am still just finding my way around the project and the community, so will first report it here. Situation:- Default install; of koha 3.4.1 on Debian. the database created by 3.000.1XX is restored, upgraded, the web installer has only asked the kohaadmin user the password and username. After doing the nitty and gritty of updating the database from 3. version to 3.4.1, the web installer has forced the kohaadmin user to relogin, and I am now looking at the staff client page. On Left hand side, I am looking at the column starting with "News". Here is the entire html source as rendered in the browser. (beginquote)
(endquote) I am not sure if the links in
  • items at top of the HTML snippet is a relic from the older backup; but surely, the installer / updater scripts should take care to fix them, right? Except the link to kohadocs.org, and koha.org (the LibLime one) site, all other links give me an error message - and I believe that this has nothing to do with dns resolution. (I use google's DNS). I suspect this snippet occurs the way it does because I have restored a backup (made using mysqldump) from 3.000.107 (will confirm later). -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From paivakil at gmail.com Sun Jun 19 18:27:02 2011 From: paivakil at gmail.com (Mahesh T Pai) Date: Sun, 19 Jun 2011 21:57:02 +0530 Subject: [Koha-devel] Koha Security best practises Message-ID: <87sjr5aisp.fsf@gmail.com> Is a best practises document available for securing a System running Koha? I mean beyond whatever documentation is available for OSes in general, is there anything Koha specific to look into? I cannot think of anything beyond filtering out incoming traffic to ports other than 80 and 8080, and long complicated passwords. -- Mahesh T. Pai || Sent from my Computer. Running Debian GNU/Linux From dpavlin at rot13.org Sun Jun 19 18:43:04 2011 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Sun, 19 Jun 2011 18:43:04 +0200 Subject: [Koha-devel] Koha Security best practises In-Reply-To: <87sjr5aisp.fsf@gmail.com> References: <87sjr5aisp.fsf@gmail.com> Message-ID: <20110619164304.GA27514@rot13.org> On Sun, Jun 19, 2011 at 09:57:02PM +0530, Mahesh T Pai wrote: > > Is a best practises document available for securing a System running > Koha? > > I mean beyond whatever documentation is available for OSes in general, > is there anything Koha specific to look into? > > I cannot think of anything beyond filtering out incoming traffic to > ports other than 80 and 8080, and long complicated passwords. We are using https for logged in users[1] and for intranet. 1: just edit login form action to https version -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From cnighswonger at foundations.edu Sun Jun 19 22:16:48 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sun, 19 Jun 2011 16:16:48 -0400 Subject: [Koha-devel] 3.4.x String Freeze and Roadmap Update Message-ID: Hi all, The monthly 3.4.x release is a few days behind schedule. As of 0000 UTC 20 June 2011, 3.4.x is in a string freeze. 27 June 2011 will be the date of the 3.4.2 release. At this point the only patches that touch strings which will be accepted are blocker and security fixes. Non-string patches will still be applied up to the date of the release. Kind Regards, Chris Nighswonger Release Maintainer Koha 3.2.x/3.4.x From chrisc at catalyst.net.nz Sun Jun 19 23:44:36 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Mon, 20 Jun 2011 09:44:36 +1200 Subject: [Koha-devel] [Koha] Summary of Global Signoff Day 2011-06-15 - more to come? In-Reply-To: <20110619141657.4F3C89F0D2@nail.towers.org.uk> References: <20110619141657.4F3C89F0D2@nail.towers.org.uk> Message-ID: <20110619214436.GH13034@rorohiko.wgtn.cat-it.co.nz> * MJ Ray (mjr at phonecoop.coop) wrote: > Magnus Enger wrote: > > * GSOD #1 > [...] > > You can see a more or less complete list of what bugs were changed here: > > http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 > > Thanks for the summary, Magnus! > > > As far as I can tell we were about 6 people signing off on things > > JOOI, how can you tell that? I use the bugs list, I counted Liz, Nicole, Katrin, Magnus, You and me, but I may have missed someone, apologies if so. I thought it was a great idea, and one worth doing again. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From chrisc at catalyst.net.nz Sun Jun 19 23:47:27 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Mon, 20 Jun 2011 09:47:27 +1200 Subject: [Koha-devel] Wrong Links on Staff Client. (v. 3.4.1) In-Reply-To: <8762o1by4n.fsf@gmail.com> References: <8762o1by4n.fsf@gmail.com> Message-ID: <20110619214727.GI13034@rorohiko.wgtn.cat-it.co.nz> * Mahesh T Pai (paivakil at gmail.com) wrote: > > I know this ought be reported as a bug, but I am still just finding my > way around the project and the community, so will first report it here. > > > I suspect this snippet occurs the way it does because I have restored a > backup (made using mysqldump) from 3.000.107 (will confirm later). > Yep, the news items are stored in the database. And because people may have edited them, or deleted and added new ones. It is not safe for the updater to try to change them. Not really a bug, just a feature of upgrading from an old version of Koha. All new ones install sample news items with the right links Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From robin at catalyst.net.nz Mon Jun 20 01:06:38 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Mon, 20 Jun 2011 11:06:38 +1200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: References: <1306710319.2375.91.camel@zarathud> Message-ID: <1308524798.10974.2.camel@zarathud> Magnus Enger schreef op vr 17-06-2011 om 12:24 [+0200]: > - Find another way to handle translations than the process I am trying > now (install the languages, commit the resulting files with git, build > packages with build-git-snapshot) I'd be inclined to have the rules process build the language, and then have a koha-translations-no.install file that puts the appropriate files in the right place, along with an entry to 'control' that creates a package called koha-translations-no. This way you get a package that can be installed to get -no translations. It also means I get to delegate the work of doing the first one of these (which will be the hard bit) to someone else ;) -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From cnighswonger at foundations.edu Mon Jun 20 03:50:58 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sun, 19 Jun 2011 21:50:58 -0400 Subject: [Koha-devel] Koha 3.2.10 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.2.10. Note: This is potentially the final release of the 3.2.x branch. Please act accordingly with new implementations and upgrades. The package can be retrieved from: http://download.koha-community.org/koha-3.02.10.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.10.tar.gz.MD5 http://download.koha-community.org/koha-3.02.10.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.10.tar.gz.sig Release notes for 3.2.10 are below. Come and get it! RELEASE NOTES FOR KOHA 3.2.10 - 19 June 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.2.10 can be downloaded from: http://download.koha-community.org/koha-3.02.09.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation IMPORTANT ANNOUNCEMENT CONCERNING 3.2.x EOL ======================================================================== With the release of 3.4.1, the 3.2.x branch is nearing its EOL. A motion will be made at the August 2011 general IRC meeting to officially announce EOL for the 3.2.x branch. Unless someone or some entity steps forward to take over 3.2.x maintenance, this date will mark the official EOL for the 3.2.x branch. Please keep this in mind when planning new deployments and upgrades to existing systems. Highlights of 3.2.10 ====================== This release marks over 700 commits since the release of 3.2.0. That represents nearly 90 commits per month since 3.2.0! Congratulations are due to the entire community for all of the hard work which has gone into improving Koha during this release cycle! Some of the higher profile bugs addressed in this release are: 2246 Label printing doesn't work with Unicode characters (Improved work-around rather than a fix.) 3072 'Heading-Main' authority-index breaks authority searching in STABLE 4993 ldap search always anonymous when using auth_by_bind 5860 Adding duplicate stocknumber will fail silently 5094 auth_by_bind authentication can fail even if given a correct password and userid Bugs fixed in 3.2.10 ====================== 3013 Value builder for 006 and 008 need choices for all format types 5653 default new label layout and sample data have broken call number placeholder 5684 Z3950 search on OCLC pulls in items (tag 952) 6061 C4::Context clearing up system preference on update 6131 (unimarc only) improper index name for personal-name 6091 Remove undeclared syspref OPACAdvSearchInputCount 6152 Authority-zebra-indexdefs.xsl should indicate it's automatically generated 6218 patron login gets an initial dot added when no first name 6315 depreciation warnings in C4::Serials in new perls 6350 Bug for tracking updates to the history file 6401 Give Ian Walls credit in the history file. 5760 Add the jquery table sorter to borrowers reading record System Requirements ====================== Changes since 3.0: * The minimum version of Perl required is now 5.8.8. * There are a number of new Perl module dependencies. Run ./koha_perl_deps.pl -u -m to get a list of any new modules to install during upgrade. Upgrades ====================== The structure of the acquisitions tables have changed significantly from 3.0.x. In particular, the budget hierarchy is quite different. During an upgrade, a new database table is created called fundmapping that contains a record of how budgets were mapped. It is strongly recommended that users of Koha 3.0.x acquisitions carefully review the results of the upgrade before resuming ordering in Koha 3.2.x. Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, several translations of the Koha manual are available: English: http://koha-community.org/documentation/3-2-manual/ Spanish: http://koha-community.org/documentation/3-2-manual-es/ French: http://koha-community.org/documentation/3-2-manual-fr/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://www.kohadocs.org/usersguide/apb.html for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.2 is Release Manager: Galen Charlton Documentation Manager: Nicole Engard Translation Manager: Chris Cormack Release Maintainer (3.0.x): Henri-Damien Laurent Release Maintainer (3.2.x): Chris Nighswonger Credits ====================== We thank the following individuals who contributed patches to Koha 3.2.10: Alex Arnaud Jared Camins-Esakov Colin Campbell Fernando Canizo Fr??d??rick Capovilla Galen Charlton Tomas Cohen Arazi Chris Cormack Jeremy Crabtree Fr??d??ric Demians Jonathan Druart Katrin Fischer Owen Leonard Chris Nighswonger Dobrica Pavlinusic Marcel de Rooy Salvador Zaragoza Rubio ruth at bywatersolutions.com Fridolyn Somers We regret any omissions. If a contributor has been inadvertantly missed, please send patch against these release notes to koha-patches at lists.koha-community.org. The 3.2.x Release Maintainer especially thanks the 3.6 Release Team and all who participated in QA for their diligent labors in testing and pushing well over 700 patches since the 3.2.0 relese. Their continued work very much makes possible the release of 3.2.10 on its announced schedule. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.2.x (i.e., this version of Koha and future bugfix releases) is 3.2.x. The next major feature release of Koha will be Koha 3.4.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Naku te rourou, nau te rourou, ka ora ai te iwi. From paivakil at gmail.com Mon Jun 20 06:47:07 2011 From: paivakil at gmail.com (Mahesh T Pai) Date: Mon, 20 Jun 2011 10:17:07 +0530 Subject: [Koha-devel] Wrong Links on Staff Client. (v. 3.4.1) References: <8762o1by4n.fsf@gmail.com> <20110619214727.GI13034@rorohiko.wgtn.cat-it.co.nz> Message-ID: <87liwx2jp0.fsf@gmail.com> Chris Cormack writes: > Not really a bug, just a feature of upgrading from an old version of > Koha. All new ones install sample news items with the right links > Thanks for that info; now how do I set this to default - default as in what a fresh 3.4.1 install will put in there?? -- Mahesh T. Pai || L'homme est libre au moment qu'il veut l'etre. * Man is free at the instant he wants to be. From paivakil at gmail.com Mon Jun 20 07:06:50 2011 From: paivakil at gmail.com (Mahesh T Pai) Date: Mon, 20 Jun 2011 10:36:50 +0530 Subject: [Koha-devel] Koha Security best practises References: <87sjr5aisp.fsf@gmail.com> <20110619164304.GA27514@rot13.org> Message-ID: <87hb7l2is5.fsf@gmail.com> Dobrica Pavlinusic writes: > We are using https for logged in users[1] and for intranet. > > 1: just edit login form action to https version Thanks. Is it possible to use IP address based access controls from within koha? Like specifying from where library staff can access / log in ? -- Mahesh T. Pai || L'homme est libre au moment qu'il veut l'etre. * Man is free at the instant he wants to be. From robin at catalyst.net.nz Mon Jun 20 07:16:03 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Mon, 20 Jun 2011 17:16:03 +1200 Subject: [Koha-devel] Koha Security best practises In-Reply-To: <87hb7l2is5.fsf@gmail.com> References: <87sjr5aisp.fsf@gmail.com> <20110619164304.GA27514@rot13.org> <87hb7l2is5.fsf@gmail.com> Message-ID: <1308546963.10974.16.camel@zarathud> Mahesh T Pai schreef op ma 20-06-2011 om 10:36 [+0530]: > Thanks. > > Is it possible to use IP address based access controls from within koha? > > Like specifying from where library staff can access / log in ? These kinds of things are best handled by Apache, as it has all sorts of controls that can be applied. For example: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 allows Apache to require that the user has a correct client SSL certificate (and if they do, it makes it possible to log them in without a password.) -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From paivakil at gmail.com Mon Jun 20 07:53:10 2011 From: paivakil at gmail.com (Mahesh T Pai) Date: Mon, 20 Jun 2011 11:23:10 +0530 Subject: [Koha-devel] Koha Security best practises References: <87sjr5aisp.fsf@gmail.com> <20110619164304.GA27514@rot13.org> <87hb7l2is5.fsf@gmail.com> <1308546963.10974.16.camel@zarathud> Message-ID: <87d3i92gmx.fsf@gmail.com> Robin Sheat writes: > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Exactly the kind of thing I was looking for. But, I am not happy with that no username / password thing required comment in that report; one library I knew (10 years back) did not restrict physical access much. -- Mahesh T. Pai || From robin at catalyst.net.nz Mon Jun 20 08:02:46 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Mon, 20 Jun 2011 18:02:46 +1200 Subject: [Koha-devel] Koha Security best practises In-Reply-To: <87d3i92gmx.fsf@gmail.com> References: <87sjr5aisp.fsf@gmail.com> <20110619164304.GA27514@rot13.org> <87hb7l2is5.fsf@gmail.com> <1308546963.10974.16.camel@zarathud> <87d3i92gmx.fsf@gmail.com> Message-ID: <1308549766.10974.20.camel@zarathud> Mahesh T Pai schreef op ma 20-06-2011 om 11:23 [+0530]: > Exactly the kind of thing I was looking for. > > But, I am not happy with that no username / password thing required > comment in that report; one library I knew (10 years back) did not > restrict physical access much. Well, if you don't turn the syspref on, then Apache will validate the certificate and you'll still require a login. However, in this case, the certificate is part of an organisations single-sign-on system, and so it would have largely defeated its purpose to still require a login (also, by the nature of the organisation, being a government department, there is a significant element of physical security.) -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From paivakil at gmail.com Mon Jun 20 08:29:49 2011 From: paivakil at gmail.com (Mahesh T Pai) Date: Mon, 20 Jun 2011 11:59:49 +0530 Subject: [Koha-devel] bug 4406 - missing LSB information Message-ID: <87y60x10de.fsf@gmail.com> I have put this in header of koha-zebra-daemon on my system. Of course, taken from soem other script in init.d/ and modified. So, it may cast a spell on other systems. Feel free to junk or accept this. ### BEGIN INIT INFO # Provides: koha-zebra-daemon # Required-Start: $syslog $remote_fs # Required-Stop: $syslog $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Koha-zebra-daemon ### END INIT INFO I do not know why $remote_fs is required - probably if syslog writes to a remote file system?? And cannot figure why this should run in any other runlevel other than 2. Of coruse, feel free to discuss and modify as required; it just works for me. -- Mahesh T. Pai || The next best thing to knowing something is to know where to find it. --Samuel Johnson From mjr at phonecoop.coop Mon Jun 20 19:12:26 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 20 Jun 2011 18:12:26 +0100 (BST) Subject: [Koha-devel] bug 4406 - missing LSB information In-Reply-To: <87y60x10de.fsf@gmail.com> Message-ID: <20110620171226.1DE189F0D2@nail.towers.org.uk> Mahesh T Pai [...] > I do not know why $remote_fs is required - probably if syslog writes to > a remote file system?? Or if zebra's data storage is on one? Not 100% sure though. > And cannot figure why this should run in any other runlevel other than > 2. Of coruse, feel free to discuss and modify as required; it just works > for me. Personally, on my desktop machine, I still use 2 for a multiuser text boot and 5 for a graphical boot, but all of 2 to 5 are runlevels we probably want to start up in by default. I've made a patch based on your suggestion and submitted it. Thank you for your help, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ From robin at catalyst.net.nz Tue Jun 21 00:50:44 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Tue, 21 Jun 2011 10:50:44 +1200 Subject: [Koha-devel] bug 4406 - missing LSB information In-Reply-To: <20110620171226.1DE189F0D2@nail.towers.org.uk> References: <20110620171226.1DE189F0D2@nail.towers.org.uk> Message-ID: <1308610244.10974.24.camel@zarathud> MJ Ray schreef op ma 20-06-2011 om 18:12 [+0100]: > > I do not know why $remote_fs is required - probably if syslog writes > to > > a remote file system?? > > Or if zebra's data storage is on one? Not 100% sure though. Yes. If you have /usr (or /var, but less common I think) mounted on an NFS partition or similar, you want that to be present before you start most things. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From lori.ayre at galecia.com Fri Jun 17 16:33:52 2011 From: lori.ayre at galecia.com (Lori Bowen Ayre) Date: Fri, 17 Jun 2011 07:33:52 -0700 Subject: [Koha-devel] [Koha] Summary of Global Signoff Day 2011-06-15 - more to come? In-Reply-To: References: Message-ID: Maybe there should be some kind of Bug Swatter Award given each month or after each GSOD session. I understand that closing out bugs is less sexy and exciting than developing something new so we need to recognize those that are willing to do that work. It is certainly equally important! Even if we don't have a cash prize or a bouquet to give the award recipient, there's nothing wrong with giving the developers some extra ++'s from the user community! Lori =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-= Lori Bowen Ayre // Library Technology Consultant The Galecia Group // www.galecia.com (707) 763-6869 // Lori.Ayre at galecia.com Specializing in open source ILS solutions, RFID, filtering, workflow optimization, and materials handling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= On Fri, Jun 17, 2011 at 3:11 AM, Magnus Enger wrote: > Dear Community! > > * GSOD #1 > > Our very first Global Signoff Day (GSOD) was held on 2011-06-15. > > During the 48 hours that make up a day in all available time zones, we > reduced the number of bugs that had status "Needs signoff" from about > 76 to about 45. (There were some bugs that got the "Needs Signoff" > status during the day, which complicates counting somewhat...) > > You can see a more or less complete list of what bugs were changed here: > http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 > > See the bottom of this page for some more numbers, and keep in mind > that the dates there are relative to UTC: > http://bugs.koha-community.org/cgi-bin/progress.pl > > As far as I can tell we were about 6 people signing off on things > during GSOD #1, which is not an astronomical figure, but i still think > we made some good inroads into the queue. (A number of the remaining > bugs are actually ones that depend on other bugs that have failed QA, > so they are not really available for signing off.) Imagine what we > could have done if there were more of us... ;-) > > * GSOD #2 > > BibLibre have said all their staff will dedicate half a day every two > weeks to signing off on bugs and similar tasks (woohoo!). I would like > to propose another GSOD to coincide with their first such day, which > is scheduled for 2011-07-08. Motto: "The more, the merrier"! > > Some questions spring to mind: > > - How can we get more people involved? > - Should the name of the "event" reflect that other activities (such > as closing bugs) are encouraged too? > - How can we make it even more fun? > -- Better/other lists and visualisations? > -- Could we have the huginn bot on IRC annonunce new signoffs, the > same way it does "needs signoff"s? > -- Could we use some kind of VoIP/videoconferencing tools to make the > social interactions seem more um... "real"? > > Or is GSOD a really bad idea, would it be better to channel our energy > into making signoffs (and similar activities) look more like an > ongoing task, and less something you only have to think about once a > month? > > Best regards, > Magnus Enger > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at enger.priv.no Wed Jun 22 10:26:12 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 22 Jun 2011 10:26:12 +0200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: <1308524798.10974.2.camel@zarathud> References: <1306710319.2375.91.camel@zarathud> <1308524798.10974.2.camel@zarathud> Message-ID: 2011/6/20 Robin Sheat : > Magnus Enger schreef op vr 17-06-2011 om 12:24 [+0200]: >> - Find another way to handle translations than the process I am trying >> now (install the languages, commit the resulting files with git, build >> packages with build-git-snapshot) > > I'd be inclined to have the rules process build the language, and then > have a koha-translations-no.install file that puts the appropriate files > in the right place, along with an entry to 'control' that creates a > package called koha-translations-no. This way you get a package that can > be installed to get -no translations. That definitely sounds like the *right* solution. > It also means I get to delegate the work of doing the first one of these > (which will be the hard bit) to someone else ;) My understanding of the steps involved is severely limited, but if there is any "manual labour" involved I'd be happy to volunteer! Best regards, Magnus Enger libriotech.no From kmkale at anantcorp.com Wed Jun 22 13:06:49 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Wed, 22 Jun 2011 16:36:49 +0530 Subject: [Koha-devel] [Koha] Date and time of next Kohacon11 volunteers meeting In-Reply-To: References: <20110611120843.033D49F0D2@nail.towers.org.uk> Message-ID: Hi All, The poll at http://doodle.com/b4gqk76xqq59ckxi received response from only six people. As per the poll there are three date + time combinations that received most ( 5 ) ticks each. These are Tuesday June 28 2011 6.00 UTC Wednesday June 29 6.00 UTC Wednesday June 29 8.00 UTC Out of these I would personally prefer Wednesday June 29 6.00 UTC so should we fix on that? Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From paul.poulain at biblibre.com Wed Jun 22 13:17:39 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 22 Jun 2011 13:17:39 +0200 Subject: [Koha-devel] [Koha] Date and time of next Kohacon11 volunteers meeting In-Reply-To: References: <20110611120843.033D49F0D2@nail.towers.org.uk> Message-ID: <4E01CF53.3030502@biblibre.com> Le 22/06/2011 13:06, Koustubha Kale a ?crit : > Hi All, > The poll at http://doodle.com/b4gqk76xqq59ckxi received response from > only six people. > As per the poll there are three date + time combinations that received > most ( 5 ) ticks each. > These are > Tuesday June 28 2011 6.00 UTC > Wednesday June 29 6.00 UTC > Wednesday June 29 8.00 UTC > > Out of these I would personally prefer Wednesday June 29 6.00 UTC so > should we fix on that? Yikes, I totally forget to file this poll... june 29, 6AM UTC will be OK for me... if we're quickly doing. I've a training starting at 7 UTC (i'll try to move to 8UTC, but not sure it will be OK) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From robin at catalyst.net.nz Wed Jun 22 14:44:42 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 23 Jun 2011 00:44:42 +1200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: References: <1308524798.10974.2.camel@zarathud> Message-ID: <201106230044.50085.robin@catalyst.net.nz> Op woensdag 22 juni 2011 20:26:12 schreef Magnus Enger: > My understanding of the steps involved is severely limited, but if > there is any "manual labour" involved I'd be happy to volunteer! Well, the guts of it is this (from memory): * The debian/rules file contains the commands that need to be run to install everything into a chroot that is needed to build all the packages (at the moment just koha and koha-common.) If the command to build the translations was added to this, along with anything needed to put them in the right place (probably alongside the en installed files), then that's the first step. * Say you've set it up to install the -no translations, then you need to add the details of that package in debian/control (or, really, debian/control.in.) This is a description and depends and so forth. Basically, it'll require a) anything that's needed to build the translations (build-depends), and b) it'll depend on koha-common to be installed. * Make sure that koha-common.install doesn't pull in the translations into the package that it makes - it should only include the default en ones (or, perhaps, they should be in their own package too. I'm not sure about that though.) * Create something like koha-translations-no.install (the name being whatever you called it in the control file) that tells it where the translated files go when the rules file is being evaluated, and where they should end up when the package is installed. All going to plan, this should work :) Once someone has worked out the tricks the first time, any other translations should just be a copy-paste of that with appropriate language codes changed. It's been on my radar for a while (I really want to get -en-nz into there for example), but I've lacked the time, and things aren't going to get quieter in the next month or three it looks like (too many libraries want Koha now apparently :) -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From magnus at enger.priv.no Wed Jun 22 14:57:25 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 22 Jun 2011 14:57:25 +0200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: <201106230044.50085.robin@catalyst.net.nz> References: <1308524798.10974.2.camel@zarathud> <201106230044.50085.robin@catalyst.net.nz> Message-ID: 2011/6/22 Robin Sheat : > All going to plan, this should work :) Once someone has worked out the tricks > the first time, any other translations should just be a copy-paste of that > with appropriate language codes changed. Thanks for that run-down Robin! This definitely goes on my "summer holiday cool projects" list! ;-) > It's been on my radar for a while (I really want to get -en-nz into there for > example), but I've lacked the time, and things aren't going to get quieter in > the next month or three it looks like (too many libraries want Koha now > apparently :) A mixed blessing? Nah, not really... ;-) Best regards, Magnus Enger libriotech.no From dschust1 at gmail.com Wed Jun 22 15:46:46 2011 From: dschust1 at gmail.com (David Schuster) Date: Wed, 22 Jun 2011 08:46:46 -0500 Subject: [Koha-devel] [Koha] Summary of Global Signoff Day 2011-06-15 - more to come? In-Reply-To: References: Message-ID: So who would get the "award" this time around...??? 2011/6/17 Lori Bowen Ayre > Maybe there should be some kind of Bug Swatter Award given each month or > after each GSOD session. > > I understand that closing out bugs is less sexy and exciting than > developing something new so we need to recognize those that are willing to > do that work. It is certainly equally important! > > Even if we don't have a cash prize or a bouquet to give the award > recipient, there's nothing wrong with giving the developers some extra ++'s > from the user community! > > Lori > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-= > Lori Bowen Ayre // Library Technology Consultant > The Galecia Group // www.galecia.com > (707) 763-6869 // Lori.Ayre at galecia.com > > Specializing in open source ILS solutions, RFID, > filtering, > workflow optimization, and materials handling > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > On Fri, Jun 17, 2011 at 3:11 AM, Magnus Enger wrote: > >> Dear Community! >> >> * GSOD #1 >> >> Our very first Global Signoff Day (GSOD) was held on 2011-06-15. >> >> During the 48 hours that make up a day in all available time zones, we >> reduced the number of bugs that had status "Needs signoff" from about >> 76 to about 45. (There were some bugs that got the "Needs Signoff" >> status during the day, which complicates counting somewhat...) >> >> You can see a more or less complete list of what bugs were changed here: >> http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 >> >> See the bottom of this page for some more numbers, and keep in mind >> that the dates there are relative to UTC: >> http://bugs.koha-community.org/cgi-bin/progress.pl >> >> As far as I can tell we were about 6 people signing off on things >> during GSOD #1, which is not an astronomical figure, but i still think >> we made some good inroads into the queue. (A number of the remaining >> bugs are actually ones that depend on other bugs that have failed QA, >> so they are not really available for signing off.) Imagine what we >> could have done if there were more of us... ;-) >> >> * GSOD #2 >> >> BibLibre have said all their staff will dedicate half a day every two >> weeks to signing off on bugs and similar tasks (woohoo!). I would like >> to propose another GSOD to coincide with their first such day, which >> is scheduled for 2011-07-08. Motto: "The more, the merrier"! >> >> Some questions spring to mind: >> >> - How can we get more people involved? >> - Should the name of the "event" reflect that other activities (such >> as closing bugs) are encouraged too? >> - How can we make it even more fun? >> -- Better/other lists and visualisations? >> -- Could we have the huginn bot on IRC annonunce new signoffs, the >> same way it does "needs signoff"s? >> -- Could we use some kind of VoIP/videoconferencing tools to make the >> social interactions seem more um... "real"? >> >> Or is GSOD a really bad idea, would it be better to channel our energy >> into making signoffs (and similar activities) look more like an >> ongoing task, and less something you only have to think about once a >> month? >> >> Best regards, >> Magnus Enger >> _______________________________________________ >> Koha mailing list http://koha-community.org >> Koha at lists.katipo.co.nz >> http://lists.katipo.co.nz/mailman/listinfo/koha >> > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: From vdanjean.ml at free.fr Wed Jun 22 16:37:31 2011 From: vdanjean.ml at free.fr (Vincent Danjean) Date: Wed, 22 Jun 2011 16:37:31 +0200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: <201106230044.50085.robin@catalyst.net.nz> References: <1308524798.10974.2.camel@zarathud> <201106230044.50085.robin@catalyst.net.nz> Message-ID: <4E01FE2B.6030100@free.fr> Hi, just a few remarks about translation packaging. On 22/06/2011 14:44, Robin Sheat wrote: > Op woensdag 22 juni 2011 20:26:12 schreef Magnus Enger: >> My understanding of the steps involved is severely limited, but if >> there is any "manual labour" involved I'd be happy to volunteer! > > Well, the guts of it is this (from memory): > > * The debian/rules file contains the commands that need to be run to install > everything into a chroot that is needed to build all the packages (at the > moment just koha and koha-common.) If the command to build the translations > was added to this, along with anything needed to put them in the right place > (probably alongside the en installed files), then that's the first step. > * Say you've set it up to install the -no translations, then you need to add > the details of that package in debian/control (or, really, debian/control.in.) > This is a description and depends and so forth. Basically, it'll require a) > anything that's needed to build the translations (build-depends), and b) it'll > depend on koha-common to be installed. If you have a control.in and if generating different package language is really similar, you can auto-generate the paragraph in control. For an example, look at http://anonscm.debian.org/gitweb/?p=collab-maint/koha.git;a=tree;f=debian;hb=wip the file control, control.LL and rules > * Make sure that koha-common.install doesn't pull in the translations into the > package that it makes - it should only include the default en ones (or, > perhaps, they should be in their own package too. I'm not sure about that > though.) > * Create something like koha-translations-no.install (the name being whatever > you called it in the control file) that tells it where the translated files go > when the rules file is being evaluated, and where they should end up when the > package is installed. A 'classical' name for such packages is 'koha-l10n-XX' (see icedove, iceweasel, kde, koffice, libreoffice, ...). The install files can probably be autogenerated if the pattern is regular enough. Note that you can have a 'special' target in debian/rules to (re)generate packaging files (control, koha-l10n-XX.install, ...) that will be triggered manually by a developer when a new language must be added. But the control file *must not* be updated during a regular build of koha (with dpkg-buildpackage for examples). That would badly break the policy (and various tools at Debian if koha ended uploaded in official repo) Regards, Vincent > All going to plan, this should work :) Once someone has worked out the tricks > the first time, any other translations should just be a copy-paste of that > with appropriate language codes changed. > > It's been on my radar for a while (I really want to get -en-nz into there for > example), but I've lacked the time, and things aren't going to get quieter in > the next month or three it looks like (too many libraries want Koha now > apparently :) > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble T?l?phone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann Email: Vincent.Danjean at imag.fr 38330 Montbonnot Saint Martin From mjr at phonecoop.coop Wed Jun 22 19:39:46 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 22 Jun 2011 18:39:46 +0100 (BST) Subject: [Koha-devel] [Koha] Date and time of next Kohacon11 volunteers meeting In-Reply-To: <4E01CF53.3030502@biblibre.com> Message-ID: <20110622173946.744109F0D2@nail.towers.org.uk> Paul Poulain wrote: > Le 22/06/2011 13:06, Koustubha Kale a ?crit : > > Out of these I would personally prefer Wednesday June 29 6.00 UTC so > > should we fix on that? > Yikes, I totally forget to file this poll... > > june 29, 6AM UTC will be OK for me... if we're quickly doing. I've a > training starting at 7 UTC (i'll try to move to 8UTC, but not sure it > will be OK) I've noted it in my calendar. I may not be fully awake though ;-) Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From robin at catalyst.net.nz Thu Jun 23 01:20:50 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 23 Jun 2011 11:20:50 +1200 Subject: [Koha-devel] Trouble with CSS files after creating package with translations In-Reply-To: <4E01FE2B.6030100@free.fr> References: <1308524798.10974.2.camel@zarathud> <201106230044.50085.robin@catalyst.net.nz> <4E01FE2B.6030100@free.fr> Message-ID: <1308784851.32039.4.camel@zarathud> Vincent Danjean schreef op wo 22-06-2011 om 16:37 [+0200]: > If you have a control.in and if generating different package language is > really similar, you can auto-generate the paragraph in control. > For an example, look at > http://anonscm.debian.org/gitweb/?p=collab-maint/koha.git;a=tree;f=debian;hb=wip > the file control, control.LL and rules The templating is done with M4, so that should be possible. I'd suggest it'd be worth getting two languages in there and then extracting the stuff in common into templates. > A 'classical' name for such packages is 'koha-l10n-XX' (see icedove, iceweasel, > kde, koffice, libreoffice, ...). The install files can probably be autogenerated > if the pattern is regular enough. Good point. I'd say go with l10n. I'm not sure where I got "translations" from :) > Note that you can have a 'special' target in debian/rules to (re)generate > packaging files (control, koha-l10n-XX.install, ...) that will be triggered > manually by a developer when a new language must be added. But the > control file *must not* be updated during a regular build of koha (with > dpkg-buildpackage for examples). That would badly break the policy (and various > tools at Debian if koha ended uploaded in official repo) Currently we have a couple of shell scripts in debian/ to do similar things. There's no reason we couldn't put them into the rules files though. Thanks for those comments, they're quite worthwhile. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kmkale at anantcorp.com Thu Jun 23 05:57:54 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Thu, 23 Jun 2011 09:27:54 +0530 Subject: [Koha-devel] [Koha] Date and time of next Kohacon11 volunteers meeting In-Reply-To: <20110622173946.744109F0D2@nail.towers.org.uk> References: <4E01CF53.3030502@biblibre.com> <20110622173946.744109F0D2@nail.towers.org.uk> Message-ID: OK. Date and time of next Kohacon11 volunteers meeting : Wednesday June 29 6.00 UTC it is. Hope to see more people that those that have voted. 1) We need to get an idea about who / how many are coming 2) We need more papers / presentations 3) Start working on conference schedule as per papers / abstracts already submitted or committed that it will be done 3 a ) If some people would like to make a remote presentation I need to know what facilities will be required on our side 4) Need to know accommodation assistance required ( if at all ) 5) Need more sponsors Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From paivakil at gmail.com Thu Jun 23 09:00:52 2011 From: paivakil at gmail.com (Mahesh T Pai) Date: Thu, 23 Jun 2011 12:30:52 +0530 Subject: [Koha-devel] Koha 3.4.1 upgarde - failed: Access denied for user 'kohaadmin'@'localhost' (using password: YES) References: <4DDE7C2C.D759.006F.0@kis.in> Message-ID: <87fwn13ucb.fsf@gmail.com> "ISM KIS" writes: > What does that mean? > ( By the way: I' m able to access mysql -ukohaadmin -pxxxxx ) > > Any ideas? Is the koha database owner's username and password in $HOME/.my.cnf? -- Mahesh T. Pai || Learn from the mistakes of others. You won't live long enough to make all of them yourself. From fridolyn.somers at gmail.com Thu Jun 23 09:46:54 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Thu, 23 Jun 2011 09:46:54 +0200 Subject: [Koha-devel] Koha 3.4.1 upgarde - failed: Access denied for user 'kohaadmin'@'localhost' (using password: YES) In-Reply-To: <87fwn13ucb.fsf@gmail.com> References: <4DDE7C2C.D759.006F.0@kis.in> <87fwn13ucb.fsf@gmail.com> Message-ID: I'd say no. They are in /etc/koha/koha-conf.xml and configured into MySQL server. On Thu, Jun 23, 2011 at 9:00 AM, Mahesh T Pai wrote: > "ISM KIS" writes: > > > > What does that mean? > > ( By the way: I' m able to access mysql -ukohaadmin -pxxxxx ) > > > > Any ideas? > > Is the koha database owner's username and password in $HOME/.my.cnf? > > -- > Mahesh T. Pai || > Learn from the mistakes of others. > You won't live long enough to make all of them yourself. > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From ruth at bywatersolutions.com Thu Jun 23 14:30:54 2011 From: ruth at bywatersolutions.com (D Ruth Bavousett) Date: Thu, 23 Jun 2011 08:30:54 -0400 Subject: [Koha-devel] Request for interviewees - qualitative study on women and open source Message-ID: <4E0331FE.3090909@bywatersolutions.com> I received this on the LinuxChix announcements list--some of the ladies here might be interested in this, in particular, though she is calling for some men, as well: >*snip!* Hello LinuxChix! My name is Sarah Riggs and I am a Master's Degree seeking candidate at the School of Information and Library Science at UNC Chapel Hill. I am conducting research which addresses the large gender gap in the open source community. In 2006, a team of researchers sought to capture an image of women contributors to open source software, as it was clear that women made up a very small minority of participants (Nafus, Leach, & Kriegar, 2006). Several proactive members of your community then implemented programs aimed at increasing the number of women in open source; however, little research has been done since this study. By conducting qualitative interviews, my intention is to collect narratives about the experiences of open source participants. I will ask questions about your experiences joining and participating in the open source community. Your answers will be used to to identify ways in which more women can feel comfortable joining the community and contributing to open source software development. I would like to hear thoughts from women as well as men who are open source contributors. Please consider participating whether you are just starting out, or have been contributing to open source for many years. It is important for this research to obtain a diverse group of respondents with varied backgrounds so this research constructs a representative narrative of experience. I will be conducting interviews through July 20th, 2011, and I will be happy to meet you at a time and date at your convenience. Those volunteers who are selected will be allowed to decide the method of participation, and phone calls, face-to-face interaction, or Internet Relay Chat are valid means of communication. Exhaustive efforts will be made to ensure that any information you give me is confidential, and you are always free to stop the interview at any time. Please don't hesitate to contact me if you have any further questions. I can be best reached by e-mail, smriggs at email dot unc dot edu** Thank you for your time, Sarah Riggs Principal Investigator Research Approved by IRB, UNC-Chapel Hill* University of North Carolina at Chapel Hill, School of Information and Library Science * Reference: Nafus, D., Leach, J. & Kriegar, B. (2006). *Gender: Integrated Report of Findings* (Deliverable -- 16).* *Retrieved from Free/Libre/Open Source Software: Policy Support,* http://www.flosspols.org/deliverables/FLOSSPOLS-D16-Gender_Integrated_Report_of_Findings.pdf * >*snip!* -- *D Ruth Bavousett* Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software VISIT US AT ALA: BOOTH 732 Headquarters: Santa Barbara, CA Office: Washington, DC Phone/Fax (888)900-8944 http://bywatersolutions.com ruth at bywatersolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nengard at gmail.com Sat Jun 25 22:46:16 2011 From: nengard at gmail.com (Nicole Engard) Date: Sat, 25 Jun 2011 15:46:16 -0500 Subject: [Koha-devel] Official Koha Newsletter : Volume 2, Issue 6: June 2011 Message-ID: Below is the text of the newsletter, for active links please visit the Koha site: http://koha-community.org/koha-newsletter-volume-2issue-6-june-2011/ Official Koha Newsletter (ISSN 2153-8328) Volume 2, Issue 6: June 2011 Table of Contents Koha Developments Koha 3.2.10 Available Koha 3.4.2 Coming Soon Koha Community Koha website: Announcing the Comments Policy What Colour Am I? Wiki Open For Contributors Again Koha Events Global Sign Off Day 15.06.2011 Symposium Koha ? Lyon (France) 2011 Koha General Meeting: 6 July 2011 Koha Developments Koha 3.2.10 Available by Chris Nighswonger Note: This is potentially the final release of the 3.2.x branch. Please act accordingly with new implementations and upgrades. The package can be retrieved from: http://download.koha-community.org/koha-3.02.10.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.10.tar.gz.MD5 http://download.koha-community.org/koha-3.02.10.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.10.tar.gz.sig Come and get it! Read More. Koha 3.4.2 Coming Soon by Chris Nighswonger The monthly 3.4.x release is a few days behind schedule. As of 0000 UTC 20 June 2011, 3.4.x is in a string freeze. 27 June 2011 will be the date of the 3.4.2 release. At this point the only patches that touch strings which will be accepted are blocker and security fixes. Non-string patches will still be applied up to the date of the release. Koha Community Koha website: Announcing the Comments Policy by MJ Ray The Koha website now has a comments policy. The policy is described at http://koha-community.org/about/comments-policy/ It basically summarises the recent practice and adds a suggestion that people should appeal to a general meeting if there is a dispute. What Colour Am I? by Brooke Johnson Chris Cormack world renowned SLS strikes again. This time, he brought us a very cool bug visualisation. http://bugs.koha-community.org/cgi-bin/bug_status.pl We know we?re well behind on signoffs if we?re in the red. As I wrote this, thanks to Global Sign Off Day, I?m looking at a glorious yellow 46. It was wonderful to watch how motivational this was. Developers threw down just to get the colour to change and the number to decrease. Wouldn?t this be neat as a widget? Wiki Open For Contributors Again by MJ Ray The Koha wiki is one of the simplest places for users to collaborate on documentation about Koha, how to use it, how it?s been used and a lot of other topics. The wiki can send out email again now, which means that new contributors can register and actually validate their email address, which means they can edit pages. If you registered during the recent problems, please visit http://wiki.koha-community.org/wiki/Special:Preferences to log in and request a new validation email. If you would like to register, please visit http://wiki.koha-community.org/w/index.php?title=Special:OpenIDLogin with your social media account from WordPress, Livejournal, Yahoo, Google or any other OpenID-enabled site, or http://wiki.koha-community.org/w/index.php?title=Special:UserLogin&type=signup to register with an email address. Please help us improve the documentation by registering with the wiki and editing some pages. Koha Events Global Sign Off Day 15.06.2011 by Brooke Johnson How great are our developers? Wonderful, of course! Magnus Enger, Katrin Fischer, and Chris Cormack proved once again that cool things happen on IRC! 07:36 magnuse maybe we should declare a global signing off day before summer? (drawn from http://stats.workbuffer.org/irclog/koha/2011-06-07) and just days later, it happened. 22 lovely bug contestants were sent on through to the next stage, including a critical and a major. Alas, 7 failed QA, but they?ll be back for our second chance round after a retool. For a blow by blow description, visit the wiki: http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 We couldn?t have done this without everyone?s help. Thank you all. This is a great example of just how quickly things can progress when folks get together and roll up their sleeves. Nau te rourou, naku te rourou, ka ora ai te tangata. Symposium Koha ? Lyon (France) 2011 by Pascale Nalon, president of KohaLa association University libraries of Lyon 2, Lyon 3 and Saint-Etienne (together representing approximately 80,000 students and 900,000 items) have switched from their proprietary software to Koha in 2010-2011. In this context of re-computerization, the third Koha symposium was organized by University Lyon 2 for May 26 and 27. During the two days, 130 participants from public or private libraries joined conferences about open source and open data, the history of Koha, the experience of Inter-Universities, cooperation for implementation of Koha in libraries, work reorganization and other workshops (Birt and JasperReports, SQL, XSLT, install party). These conferences and workshops hosted by french companies providing services around Koha and other softwares (Progilone, Tamil and Biblibre) and some librarians of different institutions. Students of ?CoLibre?, bachelor of communication and open source software, participated to the organisation. The new thing about this symposium, was the presence of open source exhibitors (free music, associations promoting Open Source and enterprises). Articles, videos and podcasts are available online. Koha General Meeting: 6 July 2011 by MJ Ray There will be a general meeting in the #koha IRC channel (IRC server irc.oftc.net) on 6 July 2011 at 10:00 UTC+0. As well as discussing the future development of the Koha software, it will also consider when to end free support for the 3.2 version (it will remain available, but no new releases will be made) and discuss the Koha Conferences. You can read the agenda and register your intentions or apologies at http://wiki.koha-community.org/wiki/General_IRC_Meeting,_6_July_2011. Newsletter edited by Nicole C. Engard, Koha Documentation Manager. From chris at bigballofwax.co.nz Sun Jun 26 00:05:00 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 25 Jun 2011 17:05:00 -0500 Subject: [Koha-devel] [Koha] Hackfest at ALA In-Reply-To: <20110620225305.GU13034@rorohiko.wgtn.cat-it.co.nz> References: <20110620225305.GU13034@rorohiko.wgtn.cat-it.co.nz> Message-ID: 2011/6/20 Chris Cormack : > > When we know the hotel room, we'll send out another invite. But please > if possible do come along. It should be a bunch of fun and who knows > we might even fix a bug or two and create some new features. > Hi All Hackfest is on tomorrow starting at 4pm (New Orleans time), at the Hampton Inn across the road from the convention centre. Room 413. Come one, come all, there will be talking, coding, testing and pizza Chris From cmurdock at ccfls.org Mon Jun 27 15:31:39 2011 From: cmurdock at ccfls.org (Cindy Murdock Ames) Date: Mon, 27 Jun 2011 09:31:39 -0400 Subject: [Koha-devel] mandatory & default value ignored when adding items Message-ID: <4E08863B.8090707@ccfls.org> Hi all, I sent the message below the the main mailing list last week, but didn't get a response, so I'm CC'ing here as well in the hopes that someone can answer my question. Thanks! Cindy -------- Original Message -------- Subject: [Koha] mandatory & default value ignored when adding items Date: Fri, 24 Jun 2011 10:11:08 -0400 From: Cindy Murdock Ames To: koha Hi all, I just noticed yesterday on an install (from git, on debian squeeze) of 3.4 that when I add an item not only does it ignore the "hidden" property (bug 6439: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6439) but it also ignores the default values that I've set for some fields as well as the "mandatory" setting. Am I missing something in the configuration, is it a bug, or is it just me? Cheers! Cindy -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org _______________________________________________ Koha mailing list http://koha-community.org Koha at lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha -------------- next part -------------- An HTML attachment was scrubbed... URL: From spalding at senylrc.org Mon Jun 27 19:52:39 2011 From: spalding at senylrc.org (Zachary Spalding) Date: Mon, 27 Jun 2011 13:52:39 -0400 Subject: [Koha-devel] Access URL from opac-results.tt Message-ID: <4E08C367.20207@senylrc.org> In koha 3.2 I used to be able to access the 856$u filed with the variable in the opac-results.tmpl file. Can someone give me a hint on how I can access it in 3.4, in the opac-results.tt file? Thanks -- Zachary Spalding Systems Manager Southeastern NY Library Resources Council 21 S. Elting Corners Rd Highland, NY 12528 Phone: 845-883-9065x11 Fax: 845-883-9483 Email: spalding at senylrc.org From fridolyn.somers at gmail.com Tue Jun 28 09:57:38 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Tue, 28 Jun 2011 09:57:38 +0200 Subject: [Koha-devel] Access URL from opac-results.tt In-Reply-To: <4E08C367.20207@senylrc.org> References: <4E08C367.20207@senylrc.org> Message-ID: Hie, I'd say : *[% url %]*. (if it is not into a loop). Regards, On Mon, Jun 27, 2011 at 7:52 PM, Zachary Spalding wrote: > In koha 3.2 I used to be able to access the 856$u filed with the > variable in the opac-results.tmpl file. > > Can someone give me a hint on how I can access it in 3.4, in the > opac-results.tt file? > > Thanks > > -- > Zachary Spalding > Systems Manager > Southeastern NY Library Resources Council > 21 S. Elting Corners Rd > Highland, NY 12528 > > Phone: 845-883-9065x11 > Fax: 845-883-9483 > Email: spalding at senylrc.org > > ______________________________**_________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From fridolyn.somers at gmail.com Tue Jun 28 12:19:38 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Tue, 28 Jun 2011 12:19:38 +0200 Subject: [Koha-devel] Debian installer Message-ID: Hie, I'm looking for documentation about the Koha's debian installer. I've looked at wiki but I can't find sripts "koha-*" description. Thanks, -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From laurenthdl at alinto.com Tue Jun 28 12:34:57 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Tue, 28 Jun 2011 12:34:57 +0200 Subject: [Koha-devel] Debian installer In-Reply-To: References: Message-ID: <4E09AE51.1060306@alinto.com> Le 28/06/2011 12:19, Fridolyn SOMERS a ?crit : > Hie, > > I'm looking for documentation about the Koha's debian installer. > I've looked at wiki but I can't find sripts "koha-*" description. > > Thanks, > You would have to install koha-common and it comes along. From robin at catalyst.net.nz Tue Jun 28 13:58:52 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Tue, 28 Jun 2011 23:58:52 +1200 Subject: [Koha-devel] Debian installer In-Reply-To: <4E09AE51.1060306@alinto.com> References: <4E09AE51.1060306@alinto.com> Message-ID: <201106282359.07598.robin@catalyst.net.nz> Op dinsdag 28 juni 2011 22:34:57 schreef LAURENT Henri-Damien: > You would have to install koha-common and it comes along. > From what I tested, unless i am mistaken, koha-* scripts are to be used > on a machine where you install koha as a package with standard install > with USMARC only. That's correct. What documentation there is is at: http://wiki.koha-community.org/wiki/Koha_3.2_on_Debian_Squeeze the rest will have to be got from reading the source at the moment. Unless someone wants to write man pages (please, anyone ;) It's aimed at USMARC at the moment because that's what I know, but if anyone who knows other MARCs wants to help out, that's great too. If all it is is that zebra needs a different configuration, then that can be an option to koha-create. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From tajoli at cilea.it Tue Jun 28 14:09:37 2011 From: tajoli at cilea.it (Zeno Tajoli) Date: Tue, 28 Jun 2011 14:09:37 +0200 Subject: [Koha-devel] To update about Message-ID: <4E09C481.2010308@cilea.it> Hi to all, I need to update the list of Italian translators in 3.4 and 3.6 From:
  • Italiano (Italian) Zeno Tajoli, Pietro Gozzetti and Paolo Pozzan
    • to:
  • Italiano (Italian) Stefano Bargioni, Paolo Bizzarri and Zeno Tajoli for 3.2 and 3.4. For 3.0 Federica Benetello and Zeno Tajoli
    • Is it enough or do I need to send a patch to koha-patches ? Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer From fridolyn.somers at gmail.com Tue Jun 28 14:09:49 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Tue, 28 Jun 2011 14:09:49 +0200 Subject: [Koha-devel] Debian installer In-Reply-To: <201106282359.07598.robin@catalyst.net.nz> References: <4E09AE51.1060306@alinto.com> <201106282359.07598.robin@catalyst.net.nz> Message-ID: Ok, thanks. This question comes from a client. Actually, I'm more focussed on DEV mode. It works well for several instances. Best regards, 2011/6/28 Robin Sheat > Op dinsdag 28 juni 2011 22:34:57 schreef LAURENT Henri-Damien: > > You would have to install koha-common and it comes along. > > From what I tested, unless i am mistaken, koha-* scripts are to be used > > on a machine where you install koha as a package with standard install > > with USMARC only. > > That's correct. What documentation there is is at: > > http://wiki.koha-community.org/wiki/Koha_3.2_on_Debian_Squeeze > > the rest will have to be got from reading the source at the moment. Unless > someone wants to write man pages (please, anyone ;) > > It's aimed at USMARC at the moment because that's what I know, but if > anyone > who knows other MARCs wants to help out, that's great too. If all it is is > that zebra needs a different configuration, then that can be an option to > koha-create. > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From laurenthdl at alinto.com Tue Jun 28 14:11:37 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Tue, 28 Jun 2011 14:11:37 +0200 Subject: [Koha-devel] Debian installer In-Reply-To: <201106282359.07598.robin@catalyst.net.nz> References: <4E09AE51.1060306@alinto.com> <201106282359.07598.robin@catalyst.net.nz> Message-ID: <4E09C4F9.4070805@alinto.com> Le 28/06/2011 13:58, Robin Sheat a ?crit : > Op dinsdag 28 juni 2011 22:34:57 schreef LAURENT Henri-Damien: >> You would have to install koha-common and it comes along. >> From what I tested, unless i am mistaken, koha-* scripts are to be used >> on a machine where you install koha as a package with standard install >> with USMARC only. > > That's correct. What documentation there is is at: > > http://wiki.koha-community.org/wiki/Koha_3.2_on_Debian_Squeeze > > the rest will have to be got from reading the source at the moment. Unless > someone wants to write man pages (please, anyone ;) > > It's aimed at USMARC at the moment because that's what I know, but if anyone > who knows other MARCs wants to help out, that's great too. If all it is is > that zebra needs a different configuration, then that can be an option to > koha-create. From robin at catalyst.net.nz Tue Jun 28 14:47:53 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 29 Jun 2011 00:47:53 +1200 Subject: [Koha-devel] Debian installer In-Reply-To: References: <201106282359.07598.robin@catalyst.net.nz> Message-ID: <201106290047.59423.robin@catalyst.net.nz> Op woensdag 29 juni 2011 00:09:49 schreef Fridolyn SOMERS: > It works well for several instances. Actually, the packages work better. koha-create --create-db library1 koha-create --create-db library2 now you have two instances :) -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From robin at catalyst.net.nz Tue Jun 28 14:49:16 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 29 Jun 2011 00:49:16 +1200 Subject: [Koha-devel] Debian installer In-Reply-To: <4E09C4F9.4070805@alinto.com> References: <201106282359.07598.robin@catalyst.net.nz> <4E09C4F9.4070805@alinto.com> Message-ID: <201106290049.17132.robin@catalyst.net.nz> Op woensdag 29 juni 2011 00:11:37 schreef LAURENT Henri-Damien: > From what I know of the Koha installer, there is an environment > parameters which allows to create the desired zebra configuration files : I'd need to to not run as part of the installer, but instead see what they produce differently and allow those different files to be swapped in when you create an instance. That way you could have USMARC and UNIMARC running from one package installation. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From serhijdubyk at gmail.com Tue Jun 28 19:19:44 2011 From: serhijdubyk at gmail.com (=?UTF-8?B?0KHQtdGA0LPRltC5INCU0YPQsdC40Lo=?=) Date: Tue, 28 Jun 2011 20:19:44 +0300 Subject: [Koha-devel] Debian installer In-Reply-To: <201106290049.17132.robin@catalyst.net.nz> References: <201106282359.07598.robin@catalyst.net.nz> <4E09C4F9.4070805@alinto.com> <201106290049.17132.robin@catalyst.net.nz> Message-ID: Hi > Op woensdag 29 juni 2011 00:11:37 schreef LAURENT Henri-Damien: >> From what I know of the Koha installer, there is an environment >> parameters which allows to create the desired zebra configuration files >> : > > I'd need to to not run as part of the installer, but instead see what they > produce differently and allow those different files to be swapped in when > you > create an instance. That way you could have USMARC and UNIMARC running > from > one package installation. I tried to use a package "koha-common" (stable 3.2.x) for library with Unimarc-records. Probably, the command "koha-create" work good only with marc21-specific. Editing record.abs and others not gave effect and I published a bug: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6172 The generation of two (or more) different instances with "koha-create" for unimarc and marc21 (and languages) would be very good. Probably could be a problem with marc21/unimarc agreement the choice Marc-standard when creating the instance (koha-create) and the web installer. With best regards, -- Serhij Dubyk -------------- next part -------------- An HTML attachment was scrubbed... URL: From dubyk at library.lviv.ua Tue Jun 28 19:18:17 2011 From: dubyk at library.lviv.ua (=?utf-8?B?U2VyaGlqIER1YnlrIC8g0KHQtdGA0LPRltC5INCU0YPQsdC40Lo=?=) Date: Tue, 28 Jun 2011 20:18:17 +0300 (EEST) Subject: [Koha-devel] Debian installer In-Reply-To: <201106290049.17132.robin@catalyst.net.nz> References: <201106282359.07598.robin@catalyst.net.nz> <4E09C4F9.4070805@alinto.com> <201106290049.17132.robin@catalyst.net.nz> Message-ID: <34885.46.211.212.236.1309281497.squirrel@www.library.lviv.ua> > Op woensdag 29 juni 2011 00:11:37 schreef LAURENT Henri-Damien: >> From what I know of the Koha installer, there is an environment >> parameters which allows to create the desired zebra configuration files >> : > > I'd need to to not run as part of the installer, but instead see what they > produce differently and allow those different files to be swapped in when > you > create an instance. That way you could have USMARC and UNIMARC running > from > one package installation. I tried to use a package "koha-common" (stable 3.2.x) for library with Unimarc-records. Probably, the command "koha-create" work good only with marc21-specific. Editing record.abs and others not gave effect and I published a bug: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6172 The generation of two (or more) different instances with "koha-create" for unimarc and marc21 (and languages) would be very good. Probably could be a problem with marc21/unimarc agreement the choice Marc-standard when creating the instance (koha-create) and the web installer. With best regards, -- Serhij Dubyk -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From irmalibraries at gmail.com Wed Jun 29 01:41:54 2011 From: irmalibraries at gmail.com (Irma Birchall) Date: Wed, 29 Jun 2011 09:41:54 +1000 Subject: [Koha-devel] mandatory & default value ignored when adding items In-Reply-To: <4E08863B.8090707@ccfls.org> References: <4E08863B.8090707@ccfls.org> Message-ID: <4E0A66C2.20604@gmail.com> Hi Cindy, Are you using the export/import function? Or manually editing your MARC frameworks? Irma CALYX On 27/06/11 23:31, Cindy Murdock Ames wrote: > Hi all, > > I sent the message below the the main mailing list last week, but > didn't get a response, so I'm CC'ing here as well in the hopes that > someone can answer my question. > > Thanks! > Cindy > > -------- Original Message -------- > Subject: [Koha] mandatory & default value ignored when adding items > Date: Fri, 24 Jun 2011 10:11:08 -0400 > From: Cindy Murdock Ames > To: koha > > > > Hi all, > > I just noticed yesterday on an install (from git, on debian squeeze) of > 3.4 that when I add an item not only does it ignore the "hidden" > property (bug 6439: > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6439) but it > also ignores the default values that I've set for some fields as well as > the "mandatory" setting. > > Am I missing something in the configuration, is it a bug, or is it just me? > > Cheers! > Cindy > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Cindy Murdock Ames > IT Services Director > Meadville Public Library | CCFLS > http://meadvillelibrary.org |http://ccfls.org > > _______________________________________________ > Koha mailing listhttp://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Wed Jun 29 01:50:06 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 28 Jun 2011 19:50:06 -0400 Subject: [Koha-devel] Koha 3.4.2 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.4.2. The package can be retrieved from: http://download.koha-community.org/koha-3.04.02.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.02.tar.gz.MD5 http://download.koha-community.org/koha-3.04.02.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.02.tar.gz.sig Release notes for 3.4.2 are below. Come and get it! RELEASE NOTES FOR KOHA 3.4.2 - 27 June 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.4.2 can be downloaded from: http://download.koha-community.org/koha-3.04.02.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.4.2 is a bugfix/maintenance release. Highlights of 3.4.2 ====================== 6518 blocker XSS vulnerabilities in the OPAC 2246 critical Label printing doesn't work with Unicode characters 4993 critical ldap search always anonymous when using auth_by_bind 5658 critical can't delete subfields in frameworks 5683 critical link_bibs_to_authorities.pl can corrupt records 5860 critical Adding duplicate stocknumber will fail silently 6343 critical Label Creator not working, Current Branch: NULL 6395 critical cannot create routing list - template error? 6472 critical HidePatronName no longer works as stated 6525 critical hold filled emails not going out 3140 major It is possible to email someone else's private list 4319 major waiting items cannot be reserved 5094 major auth_by_bind authentication can fail even if given a correct password and userid 5918 major When AddPatronLists is set to "general" and EnhancedMessagingPreferences is set, messaging prefs not copied from defaults 6258 major Guided reports wizard 'Build new' brings up empty page 6300 major can't get to other pages of marc import 6340 major Pagination bar on guided reports result page broken 6351 major Cannot delete library-specific circulation rules 6370 major news showing that it's for the opac when it's for the librarian interface 6452 major Missing SQL placeholders 6497 major MARC URLs not showing up in both OPAC and staff client Details page under non-XSLT view Bugs fixed in 3.4.2 ====================== 5509 Packaging scripts get upset when there's an LDAP configuration in the koha_conf.xml 5653 default new label layout and sample data have broken call number placeholder 5684 Z3950 search on OCLC pulls in items (tag 952) 5868 Subject indexes do not search most 6xx fields 6031 koha-rebuild-zebra doesn't allow XML and verbose indexing 6067 When Add Duplicate changing framework would lose data 6103 Many MARC21 fields not searched with CCL indexes due to misconfiguration 6131 (unimarc only) improper index name for personal-name 6170 'More options' in advanced search broken 6306 It is not possible edit news 6337 Variable scope errors in staff client cart print view 6338 Datepickers on OPAC hold form does not work 6342 Help link doesn't popup anymore contextual help page 6353 Erroneous prefixes before the singleBranchMode preference 6355 Late orders report shows cancelled orders 6363 The "Item Location" selectbox in inventory.pl doesn't appear when the default MARC framework is the only one avaiable. 6364 Display of item availability broken on OPAC detail screen 6365 Missing information about tab number when mandatory fields unfilled 6402 Lists sorted by year appear to be empty 6408 column alignment off on the patron categories admin 6409 pagination bar for guided report output does not work if report has parameters 6417 Template variable errors in Guided Reports 6436 Don't allow deletion of an itemtype used in items.itype 6444 Encoding problems with vendor names in subscription-add.pl 6446 batch item deletion interface problems 6463 Authorities browsing error when using auth. plugins 6487 No error explanation if patron expiration date is missing 6510 "Sort by" in intranet search alters search and number of hits 6512 Time missing from Item circulation history table 6521 Editing a patron fails with blank cardnumber 5268 Language Issue: Debarred 5714 Unescaped ampersands in OPAC facets 6091 Remove undeclared syspref OPACAdvSearchInputCount 6357 Items (un)availability not displayed correctly (OPAC) 6367 'Preview MARC' hover button does not show correct MARC record 6375 Markup and style corrections for overdue report 6377 fines should be red on patron search 6378 Misaligned columns on tags approval page 6388 Broken pager images in branch_transfer_limits.tt 6389 Administration menu like Tools menu 6397 Mis-named variable in .TT causes table cell shift 6442 opacnav pref explained wrong 6453 The "Compare barcodes list to results" functionnality of inventory.pl can't find barcodes 6462 Authority type is not displayed in OPAC 5020 on patron record sex should be gender 6332 missing 'clear date' link 6350 Bug for tracking updates to the history file 6401 Give Ian Walls credit in the history file. 6459 Needless call to C4::Context->dbh in C4::Templates::themelanguage() 5929 Use branch admin email for advance_notice.pl emails 6050 GetItemsInfo ignores second parameter 6294 Add {BIBLIONUMBER} parsing support to SearchForTitleIn syspref 6347 Bug in opac-reserve.pl stopping item level holds 6362 Fix MARC display in OPAC 6415 Can't make a patron card batch 6429 Updating development team in about 6433 rebuild_zebra.pl does not handle MARC::Record exceptions gracefully 6464 Add inconsistence check for '%s' count in tmpl_process3.pl 6491 Add Div in privacy page System requirements ====================== Changes since 3.2: * Template::Toolkit Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the english version of the Koha manual is available: http://koha-community.org/documentation/3-4-manual/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.4 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr??d??ric Demians Release Maintainer (3.2.x): Chris Nighswonger Release Maintainer (3.4.x): Chris Nighswonger QA Manager: Colin Campbell Credits ====================== We thank the following individuals who contributed patches to Koha 3.4.2. Tomas Cohen Arazi Alex Arnaud D Ruth Bavousett Jared Camins-Esakov Colin Campbell Fr??d??rick Capovilla Galen Charlton Chris Cormack Jeremy Crabtree Elliott Davis Fr??d??ric Demians Nicole C. Engard Magnus Enger Katrin Fischer Srdjan Jankovi?? Janusz Kaczmarek Owen Leonard Fr??re S??bastien Marie Ricardo Dias Marques Chris Nighswonger Dobrica Pavlinusic Ian Walls MJ Ray Liz Rea Marcel de Rooy Robin Sheat Fridolyn Somers We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix releases) is 3.4.x. The next major feature release of Koha will be Koha 3.6.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini From kmkale at anantcorp.com Wed Jun 29 09:38:22 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Wed, 29 Jun 2011 13:08:22 +0530 Subject: [Koha-devel] POLL : Kohacon11 volunteers followup meeting dates Message-ID: In the last Kohacon11 volunteers meeting on 29th June 2011, we asked people to drive participation, paper submission and review of papers during the next Koha general IRC meeting on 6th July. We decided to hold a followup meeting of Kohacon11 volunteers one week thereafter to review what was discussed during the general meeting. So I am proposing a few dates and times here please make your choice. http://www.doodle.com/bqg2wkifrkvu6gk2 Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From fridolyn.somers at gmail.com Wed Jun 29 10:00:12 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Wed, 29 Jun 2011 10:00:12 +0200 Subject: [Koha-devel] Debian installer In-Reply-To: <201106290049.17132.robin@catalyst.net.nz> References: <201106282359.07598.robin@catalyst.net.nz> <4E09C4F9.4070805@alinto.com> <201106290049.17132.robin@catalyst.net.nz> Message-ID: +1 for me This could be a little step for the package, a great step for Koha 2011/6/28 Robin Sheat > Op woensdag 29 juni 2011 00:11:37 schreef LAURENT Henri-Damien: > > From what I know of the Koha installer, there is an environment > > parameters which allows to create the desired zebra configuration files : > > I'd need to to not run as part of the installer, but instead see what they > produce differently and allow those different files to be swapped in when > you > create an instance. That way you could have USMARC and UNIMARC running from > one package installation. > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From cmurdock at ccfls.org Wed Jun 29 17:36:52 2011 From: cmurdock at ccfls.org (Cindy Murdock Ames) Date: Wed, 29 Jun 2011 11:36:52 -0400 Subject: [Koha-devel] mandatory & default value ignored when adding items In-Reply-To: <4E0A66C2.20604@gmail.com> References: <4E08863B.8090707@ccfls.org> <4E0A66C2.20604@gmail.com> Message-ID: <4E0B4694.3020406@ccfls.org> Hi Irma, I just went to have another look at it to answer your questions, and now I feel crazy because it's showing the default values I set and the fields marked as mandatory. Wish I knew why! Still having issues with subfields that are supposed to be hidden, though. c. On 06/28/2011 07:41 PM, Irma Birchall wrote: > Hi Cindy, > > Are you using the export/import function? > Or manually editing your MARC frameworks? > > > Irma > CALYX > > On 27/06/11 23:31, Cindy Murdock Ames wrote: >> Hi all, >> >> I sent the message below the the main mailing list last week, but >> didn't get a response, so I'm CC'ing here as well in the hopes that >> someone can answer my question. >> >> Thanks! >> Cindy >> >> -------- Original Message -------- >> Subject: [Koha] mandatory & default value ignored when adding items >> Date: Fri, 24 Jun 2011 10:11:08 -0400 >> From: Cindy Murdock Ames >> To: koha >> >> >> >> Hi all, >> >> I just noticed yesterday on an install (from git, on debian squeeze) of >> 3.4 that when I add an item not only does it ignore the "hidden" >> property (bug 6439: >> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6439) but it >> also ignores the default values that I've set for some fields as well as >> the "mandatory" setting. >> >> Am I missing something in the configuration, is it a bug, or is it just me? >> >> Cheers! >> Cindy >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Cindy Murdock Ames >> IT Services Director >> Meadville Public Library | CCFLS >> http://meadvillelibrary.org |http://ccfls.org >> >> _______________________________________________ >> Koha mailing listhttp://koha-community.org >> Koha at lists.katipo.co.nz >> http://lists.katipo.co.nz/mailman/listinfo/koha >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at 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/ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From semarie-koha at latrappe.fr Thu Jun 30 06:47:35 2011 From: semarie-koha at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie) Date: Thu, 30 Jun 2011 06:47:35 +0200 Subject: [Koha-devel] [Koha-patches] [PATCH] When searching the catalogue, if I get no results then hit the Z39.50 search the title field in the pop up window is populated with what I searched for. In-Reply-To: <1309365861-25399-1-git-send-email-peter@oslo.ie> References: <1309365861-25399-1-git-send-email-peter@oslo.ie> Message-ID: <20110630044735.GA20559@latrappe.fr> Hi, Please use placeholders in SQL statement. Your patch could result SQL injection if user may change C4::Branch::mybranch return value or result SQL error if branchname contains "'" (quote) character. The 'safe' way should be: $bsth =$dbh->prepare("SELECT branchcode,branchname FROM branches WHERE branchcode = ?"); $bsth->execute(C4::Branch::mybranch()); As here the 'prepare' is in if-clause, the 'execute' should be too (as parameters are dependant of placeholders), resulting something like: my $bsth; if ( C4::Context->preference("searchMyLibraryOnly") ) { $bsth = $dbh->prepare("SELECT branchcode,branchname FROM branches WHERE branchcode = ?"); # FIXME : use C4::Branch::GetBranches $bsth->execute(C4::Branch::mybranch()); } else { $bsth = $dbh->prepare("SELECT branchcode,branchname FROM branches"); $bsth->execute(); } Thanks. -- Fr?re S?bastien Marie Abbaye Notre Dame de La Trappe 61380 Soligny-la-Trappe T?l: 02.33.84.17.00 Fax: 02.33.34.98.57 Web: http://www.latrappe.fr/ On Wed, Jun 29, 2011 at 05:44:21PM +0100, Peter Lorimer wrote: > If I search for a valid ISBN number and hit the Z39.50 search, the title field > is populated with the ISBN number I searched for. This number should populate > the ISBN field and not the title field. > --- > C4/Search.pm | 34 +++++++++++++++++++++++++++++----- > 1 files changed, 29 insertions(+), 5 deletions(-) [...] >+ my $bsth; >+ if ( C4::Context->preference("searchMyLibraryOnly") ) >+ { >+ $bsth =$dbh->prepare("SELECT branchcode,branchname FROM branches WHERE branchcode = '". C4::Branch::mybranch() ."' >+"); # FIXME : use C4::Branch::GetBranches >+ } >+ else >+ { >+ $bsth =$dbh->prepare("SELECT branchcode,branchname FROM branches "); >+ } > $bsth->execute(); [...] From M.de.Rooy at rijksmuseum.nl Thu Jun 30 15:21:42 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 30 Jun 2011 13:21:42 +0000 Subject: [Koha-devel] FW: [Koha-bugs] [Bug 6536] Z3950 Enhancements: SRU targets, MARC conversion, additional XSLT processing Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312E9C81@S-MAIL-1B.rijksmuseum.intra> This patch also needs some testing at the UNIMARC side. Anyone of BibLibre perhaps? With thanks for your conversion to UNIMARC again! -----Oorspronkelijk bericht----- Van: koha-bugs-bounces at lists.koha-community.org [mailto:koha-bugs-bounces at lists.koha-community.org] Namens bugzilla-daemon at bugs.koha-community.org Verzonden: donderdag 30 juni 2011 15:09 Aan: koha-bugs at lists.koha-community.org Onderwerp: [Koha-bugs] [Bug 6536] Z3950 Enhancements: SRU targets, MARC conversion, additional XSLT processing http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6536 M. de Rooy changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 |PATCH-Sent Patch Status|--- |Needs Signoff --- Comment #3 from M. de Rooy 2011-06-30 13:09:07 UTC --- Z3950 Enhancements include SRU search targets, MARC conversion, additional XSLT processing and some code refactoring. The MARC21 to UNIMARC conversion and additional XSLT processing has actually been created by BibLibre and is incorporated into these two patches. A testplan with 12 steps is included: see http://wiki.koha-community.org/wiki/Z3950_RFC This patch needs a signoff for MARC21 and another one for UNIMARC. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. _______________________________________________ Koha-bugs mailing list Koha-bugs at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From sebastien.marie at latrappe.fr Thu Jun 30 19:53:07 2011 From: sebastien.marie at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie) Date: Thu, 30 Jun 2011 19:53:07 +0200 Subject: [Koha-devel] security question about injection in Zebra In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA312E9C36@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA312E9C36@S-MAIL-1B.rijksmuseum.intra> Message-ID: <20110630175307.GA14960@latrappe.fr> Hi, Seeing the patch proposed by Marcel de Rooy for bug 6536, a question arrived in my mind about injection of code in Zebra. Does someone is aware about something like that ? Next an extract of patch (and after my comments): On Thu, Jun 30, 2011 at 01:01:01PM +0000, Marcel de Rooy wrote: > Z3950 Enhancements: SRU search targets, MARC conversion and additional XSLT processing > > diff --git a/C4/Breeding.pm b/C4/Breeding.pm > index 9003f9a..cb04e14 100644 > --- a/C4/Breeding.pm > +++ b/C4/Breeding.pm [...] > +sub build_query { > + my $nterms=0; > + my $title = $input->param('title')||''; > + my $author = $input->param('author')||''; > + my $isbn = $input->param('isbn')||''; > + my $lccall = $input->param('lccall')||''; > + my $subject = $input->param('subject')||''; > + my $dewey = $input->param('dewey')||''; > + my $controlnumber = $input->param('controlnumber')||''; > + my $stdid = $input->param('stdid')||''; > + my $srchany = $input->param('srchany')||''; > + > + if ($isbn) { > + $zquery = "\@or \@attr 1=8 \"$isbn\" \@attr 1=7 \"$isbn\" "; > + $squery = "([isbn]=\"$isbn\" or [issn]=\"$isbn\") and "; > + $nterms++; > + } > + if ($title) { > + utf8::decode($title); > + $zquery .= "\@attr 1=4 \"$title\" "; > + $squery .= "[title]=\"$title\" and "; > + $nterms++; > + } [...] First, some notes about code: - alls variables seems to come from userdata (input query), so are user controlled. - if one contains a double-quote escape in done (and could result invalid query) About zebra possible exploits (untested): - yaz-client (Z39.50 client) permit bang pattern for shell invocation, does the library too ? - does zebra permit anonymous index write ? (resulting index corruption, possible affection of koha for places where data are read from zebra, and use 'as-it') - or connection to another server ? (could expose local network area) - ... If someone have other ideas... If zebra library permit use of placeholders, we should use them. Else perhaps develop a small function for variable escapment before inclusion in zebra query. Thanks. -- Fr?re S?bastien Marie Abbaye Notre Dame de La Trappe 61380 Soligny-la-Trappe T?l: 02.33.84.17.00 Fax: 02.33.34.98.57 Web: http://www.latrappe.fr/ From spalding at senylrc.org Mon Jun 27 18:44:54 2011 From: spalding at senylrc.org (Zachary Spalding) Date: Mon, 27 Jun 2011 16:44:54 -0000 Subject: [Koha-devel] Access URL from opac-results.tt Message-ID: <4E08B37F.5050200@senylrc.org> In koha 3.2 I used to be able to access the 856$u filed with the variable in the opac-results.tmpl file. Can someone give me a hint on how I can access it in 3.4, in the opac-results.tt file? Thanks -- Zachary Spalding Systems Manager Southeastern NY Library Resources Council 21 S. Elting Corners Rd Highland, NY 12528 Phone: 845-883-9065x11 Fax: 845-883-9483 Email: spalding at senylrc.org