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

Hackfest update #2
by Galen Charlton 22 Oct '13

22 Oct '13

Hi, Here are some notes from the second day of hackfest: * The total number of kittens now gamboling in the fields is 102. [1] * Two tutorial sessions were done. Chris Cormack conducted one on Class::Accessor and Object::Tiny, while I conducted one on DBIx::Class. Some discussion of moving forward now that DBIx::Class is in master took place, which I'll be writing up later this week. * Petter Goksøyr Åse gave a presentation on plans by the Oslo Public Library to use Koha as a library transaction manager while the discovery system will be based on an RDF triple-store. The metadata layer would generate MARC records for ingest into Koha. * Chris Cormack helped a librarian set up a Koha development environment. * Several librarians attending the LIANZA conference in New Zealand submitted first-time patches to Koha under the guidance of Liz Rea. * Several of us visited one of the branches of the Washoe County Library to inspect the self-check stations that they've been building using open source software and inexpensive computer hardware and cabinetry. [1] http://scoreboard.koha-community.org/ -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

1 0

odd tag
by Fridolyn SOMERS 21 Oct '13

21 Oct '13

Hie all, After a git remote update on koha git sources, I noticed an odd tag : * [new tag] 3772f30a0c50db7b993ce68b10b27aeeb09f1f4b -> 3772f30a0c50db7b993ce68b10b27aeeb09f1f4b This is an error I bet. Also, clone over HTTP seems to never respond. Regards, -- Fridolyn SOMERS Biblibre - Pôle support fridolyn.somers(a)biblibre.com

1 0

Hackfest update #1
by Galen Charlton 21 Oct '13

21 Oct '13

Hi, Here are some notes from the first day of hackfest: * A total of 34 kittens were saved [1]. In other words, a number of bugs were worked on, tested, QAed, and pushed. * Several tutorial sessions took place, including a session on Koha bug reporting and patch testing fundamentals led by Bob Birchall and a tutorial on Git and navigating the Koha source tree lead by myself. * Several folks had a lengthy discussion about various issues regarding search and indexing. A couple short-term projects initiated today include dealing with a bug concerning retrieving oversize ISO 2709 records from Zebra and a project to switch facet calculation over to using Zebra's built-in faceting. There was also discussion of the idea of using Elasticsearch as a complement to Zebra and Solr. * Chris Cormack helped a library upgrade their Koha database from (I think) 3.6 all the way to 3.12 ... in 27 minutes. Tomorrow tutorial sessions on DBIx::Class and Class::Accessor are planned as well as a roundtable on digging into Zebra's internals. For folks wanting to play along at home, lists of wishlist items [2] and notes from the conference roundtables [3] are available on the wiki. I'm sure this summary is incomplete, and I encourage other hackfest attendees to supplement it. [1] http://scoreboard.koha-community.org/ [2] http://wiki.koha-community.org/wiki/KohaCon13/Hackfest/Wishlist [3] http://wiki.koha-community.org/wiki/KohaCon13/Roundtable_Notes Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

4 4

Error circulation
by Carlos Rodrigo Cordova Sandoval 16 Oct '13

16 Oct '13

Hello, I am using koha 3.8.10.2 and I have problems when I return a book gives the following message: screenshot: http://snag.gy/Rio25.jpg and the apache log is: [Mon Oct 14 21:17:27 2013] [error] [client 186.105.227.88] [Mon Oct 14 21:17:27 2013] returns.pl: Invalid local time for date in time zone: America/Santiago, referer: http://catalogo.ipciisa.cl:8080/cgi-bin/koha/mainpage.pl thank you very much. -Carlos

2 1

Optimisation and DBI::ping
by Robin Sheat 16 Oct '13

16 Oct '13

I've been doing a bit of profiling, focussing on opac-search, as it's terribly slow at times. See: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11051 for what I've looked at so far. There's one thing I'd like some comments on. http://debian.koha-community.org/~robin/opac-search-cached/nytprof/usr-shar… All the pings take 1.36 seconds, which is a huge amount. It's not helped that Context::dbh is called 1423 times, I'm working on that too (many things that are called inside a tight loop, rather than grabbing all the data you might need in one go and putting it into a hash or something.) Is there a situation where the ping is likely to be required? It'd be easy to strip it out, but are there likely to be bad effects that can't be worked around? For context, I'm profiling this on a system with a remote database so that latency shows up a bit more than it would in a typical dev environment. As that's what many production systems are using, this is not atypical. The DBI docs: http://search.cpan.org/~timb/DBI-1.623/DBI.pm#ping say "Few applications would have direct use for this method. See the specialized Apache::DBI module for one example usage" so it might be reasonable to just pull it out. Any thoughts? Also have a look at the two other patches: one illustrating that caching actually slows things down some times, and the other just changing a query repeated once per branch, to just run once. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF

2 2

First alpha of Koha 3.14 released
by Galen Charlton 15 Oct '13

15 Oct '13

Hi, I have tagged and cut the first alpha of Koha 3.14. The tarball can be retrieved from: http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz The following files can be used to check the integrity of the tarball: http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.sig http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.MD5 http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.MD5.asc The script-generated release notes can be read at: http://git.koha-community.org/gitweb/?p=koha.git;a=blob_plain;f=misc/releas… This first alpha should be considered a preliminary smoke testing version, as I have some more large merges to get through this week. I expect to cut a second alpha during KohaCon's hackfest, with a beta to follow shortly thereafter as the condition of master warrants. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

1 0

Call for news for the October newsletter (especially re KohaCon13!)
by Daniel Grobani 14 Oct '13

14 Oct '13

Dear Koha kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 27th anything you think your fellow community members might like to know about. And all you lucky #kohacon13 attendees, here's your chance to share your experience with the community in more than 140-character chunks! "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani

1 0

vm for koha
by Samuel Desseaux 14 Oct '13

14 Oct '13

Hi, I'm preparing vm for koha, as i've said a few weeks ago. I've 2 vm *one, in french, for unimarc users *the other, in english, for marc21 users the size is nearly 1 Go. Is it ok for upload it to one of the koha servers ? Best regards Samuel

2 1

find old bugs to sign off
by Mathieu Saby 13 Oct '13

13 Oct '13

Hi The bot on bugzilla is really a great great idea :-) But now, we can't find really old bugs to sign off, because if the bot can sign off, the date of "last change" of the bug is updated. So for ex, this patch that I submitted in april 2013 is marked "modified 2013-09-24" http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10138 and the "10 oldest bugs to sign off" on Koha dashboard are not the oldest at all. http://dashboard.koha-community.org/ Do you think it would be possible to keep the advantage of having bot running on BZ and to restore the ability to see the oldest bugs waiting for sign off (maybe there is a way to find the date when the "Need sign off" status was given to a bug?) ? By the way, is someone in community, or within some vendor staff, dedicated to the signing off of oldest bugs? M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

1 0

Re: [Koha-devel] Crashes on new Opac Recent Searches cookie in older Koha versions
by Paul 12 Oct '13

12 Oct '13

At 12:54 PM 10/12/2013 +1300, Chris Cormack wrote: >On 12 October 2013 11:16, Paul <paul.a(a)aandc.org> wrote: > > At 12:26 PM 10/11/2013 -0700, Galen Charlton wrote: > > > > "Name based" v. "port based", "Nasty side effects" and "negative data" > raise > > flags with me. I've just looked up bug 10657 which either blind-sides me > > with science or baffles me with bull. "Storable" and references to " > >I totally would not have gone there with the inference that Galen was >talking bull, but hey if that's how you want to go, each to their own. Please... I was only saying that *I* was confused (blind-sided or baffled) by the Subject: of the email "Crashes..." in the context of Bug 10657. The Perl references to "crashing" were (I believed, perhaps incorrectly) taken care of when I disabled EnableOpacSearchHistory. The phrases that I quoted (maybe out of context?) did not reassure me. I still haven't had time to fully sandbox test the changes <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=eeedee8c987…> to C4/Auth.pm, opac/opac-search-history.pl and opac/opac-search.pl for use within our stable production 3.8.5 -- nor to consider a full system upgrade from 3.8.5. As you well know, I'm a believer in system stability over a two year period, à la LTS, with only security upgrades. In 2014, we'll look into whatever the latest Koha release might be. In the meanwhile, I believed (again perhaps incorrectly) that by disabling some functionality (OPAC search history) we had the well-publicized security concern under control. Until I saw "crashing" in the context of Bug 10657 and the mention by Marcel de Rooy of two commits not referencing bug numbers .... I was asking for clarification -- and certainly had no intention whatsoever of questioning Galen's integrity. If Galen read it that way, I apologize unreservedly to him. Without wanting to excuse myself, please remember that I am generally much more comfortable writing in French rather than in English. Regards - Paul > > > > checked for JSON-correctness and is ignored" are > > meaningless without context. > > > > If there really is a security aspect would someone please explain it? > > >Or the implication that he was lying. > >Of course there was a security aspect, and that's why we did security >releases for 3.12.x, 3.10.x and 3.8.x. >If you read the release notes > http://koha-community.org/security-release-july-2013/ > >And you snipped some lines out of context, and complain for them being >out of context. > >Here is the whole thing, for context. > >"When EnableOpacSearchHistory system preference is enabled, Koha >stores recent search history for anonymous OPAC sessions in a cookie >called KohaOpacRecentSearches. In particular, it used to use the >Storable Perl module to serialize the array of hashrefs representing >the recent searches. > >However, the documentation for Storable strongly recommends [1] that >data to be deserialized *not* come from untrusted sources -- and >cookies cannot be considered trustworthy, as most web browsers (to say >nothing of curl) allow the user to modify them. There is a >theoretical possibility that a modification to the >KohaOpacRecentSearches cookie could result in the execution of >unauthorized code with the privileges of the Apache backend process. > >The 29 July 2013 security update resolves the security issuing by >replacing use of the Storable module with the JSON, which doesn't by >default serialize blessed references and does not attempt to >deserialize and execute coderefs. The payload of the cookie is >checked for JSON-correctness and is ignored if it doesn't contain a >valid (double-URI-encoded) JSON object. In particularly, any old >Storable-based cookies are silently ignored. > >[1] http://perldoc.perl.org/Storable.html#SECURITY-WARNING " > >If you read the link that is provided there it says > >"Do not accept Storable documents from untrusted sources! >Some features of Storable can lead to security vulnerabilities if you >accept Storable documents from untrusted sources. Most obviously, the >optional (off by default) CODE reference serialization feature allows >transfer of code to the deserializing process. Furthermore, any >serialized object will cause Storable to helpfully load the module >corresponding to the class of the object in the deserializing module. >For manipulated module names, this can load almost arbitrary code. >Finally, the deserialized object's destructors will be invoked when >the objects get destroyed in the deserializing process. Maliciously >crafted Storable documents may put such objects in the value of a hash >key that is overridden by another key/value pair in the same hash, >thus causing immediate destructor execution. >In a future version of Storable, we intend to provide options to >disable loading modules for classes and to disable deserializing >objects altogether. Nonetheless, Storable deserializing documents from >untrusted sources is expected to have other, yet undiscovered, >security concerns such as allowing an attacker to cause the >deserializer to crash hard. >Therefore, let me repeat: Do not accept Storable documents from >untrusted sources! >If your application requires accepting data from untrusted sources, >you are best off with a less powerful and more-likely safe >serialization format and implementation. If your data is sufficently >simple, JSON is a good choice and offers maximum interoperability." > >So we were accepting Storable documents from untrusted sources (the >entire internet) and this bug stops that happening. > >I respectfully request you think about the way you phrase your >questions in the future, so they sound like questions not insults. > >Chris --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0