Time Nick Message 00:25 rangi oh hey another idea 00:25 rangi mtj: it's all good with xslt eh? 00:25 rangi (i dont think it would touch it at all, but just in case) 00:52 mtj rangi: it looks ok with xslt enabled 00:53 mtj afaik, the TT caching is just 'compiling?' .tt files into .ttc files 00:53 mtj .. so, doesnt touch any xslt stuff :) 01:15 rangi yeah, it shouldn't 01:29 mtj i spotted paul.p/joubu's discussion about moving the bi.marc/marcxml fields - the numbers are impressive 01:37 rangi yeah it should make a difference 01:37 rangi i tell you the single fastest way to speed up the OPAC 01:37 rangi turn off local cover images 01:38 rangi otherwise you get 20(or whatever number of results per page) hits on that script 01:38 rangi from 33secs to 6 01:39 rangi just from turning that off 01:39 rangi of course it would be better to fix it, so it isnt that slow, and we could still do local cover 01:39 rangi s 01:39 rangi but if a library isnt actually using them, making sure that is off is a big improvement 01:40 rangi (opac-images.pl) 01:40 rangi sorry opac-image.pl 01:40 rangi i wonder if there is a bug for that 01:50 mtj ah yes... ive seen that in the logs 01:51 mtj ..i thought someone was DOSing the server, at 1st 01:51 rangi exactly 01:54 mtj hmm, i guess plack would help with opac-images.pl startup? 01:54 rangi a little 01:54 rangi but not enough 02:00 rangi i think one trick is to get them to be fetched via ajax, so it doesnt slow down the whole page 02:00 rangi and then also, set headers like 304 02:01 rangi so that if youve seen that cover, you dont get it again 02:01 rangi etc 02:02 rangi and because i think it touches bibloitems, it would get faster with the changes i think 02:02 rangi part of the problem is because it has to check if a localcover exists 02:02 rangi so if you have 30 local covers 02:02 rangi and 5 million not 02:03 rangi you still have to check every record in the results 02:04 rangi so if we got it so that the results knew 02:04 rangi ie, index if there is a local image, so we know 02:04 rangi then we dont have to check again 02:05 rangi we get the records to display the results, if we know it doesnt have a local cover right then, then why dont need to check 02:05 rangi does that make sense? 02:06 wizzyrea do you mean mysql index or zebra index or some other context of index like "mark it" 02:07 wizzyrea (I'm sorry if that's a silly question) 02:07 rangi well i think we get the full record object back for the restuls page, ie we get stuff from zebra, then we grab the actual data from the db and hand that to be displayed 02:07 rangi no reason we couldnt check local image exists as part of that 02:07 rangi then it could be just a 1:0 02:08 rangi and we only put the img src if its 1 02:08 rangi it'd still be slow if you had tons of them 02:08 rangi but i think thats gonna be the exception 02:08 rangi my guess is in my result sets you have 0 or maybe 1 or 2 02:08 rangi which is better than doing 20 hits on opac-image 02:10 rangi just rubber ducking :) 02:11 wizzyrea yeah fair enough ^.^ 02:40 mtj yep, makes sense on both points 04:18 mtj i like your ajax idea for opac-images.pl rangi 04:18 mtj ... seems like a good quick/dirty solution, until a better fix happens 04:18 rangi it still is gonna dos you 04:19 rangi if a few people search at once, perhaps even faster than before 04:19 rangi so i kinda hate it as an idea now hehehe 04:19 rangi i think not fetching the image unless you know you have one is better ;) 04:20 mtj yeah 04:25 mtj ..you are making me question the idea now too :) 04:27 wizzyrea it seems sad to me that we can get covers faster from amazon and that it's our own that cause problems :( 04:28 rangi or at least getting them from amazon puts no load on our system 04:28 wizzyrea that frowny face looks frownier than usual today 04:28 rangi the annoying thing with load, it spirals fast 04:29 rangi http://www.visawoap.com/burger-wellington/ 04:29 rangi interesting 04:29 wahanui i guess interesting is sometimes good and sometimes bad 04:29 wizzyrea the GP is not on that list! Shocking! 04:29 rangi yeah 04:30 rangi most of the ones i heard buzz about being great arent 04:30 rangi it's funny how that happens 04:30 wizzyrea tbf, I forgot to rate a couple of mine :/ 04:30 rangi *nod* 04:30 wizzyrea it could be our fault :'/ 04:38 mtj wizzyrea: whats the GP? 04:38 wahanui the GP is not on that list! Shocking! 04:38 wizzyrea General Practitioner, corner of manners and willis 04:38 mtj ..also NZ pj harvey tickets on sale tmrw, doods 04:39 wizzyrea ohh 04:39 wizzyrea I wish I had funds for that >.< 04:40 rangi ditto 04:41 mtj http://www.undertheradar.co.nz/news/11568/PJ-Harvey-Announces-Two-New-Zealand-Shows.utr 04:51 * wizzyrea cries a bit 05:07 teja koha software 05:46 * magnuse waves 06:38 reiveune hello 07:08 alex_a Bonjour 07:09 morgane hi #koha 07:09 fridolin hie 07:38 magnuse @wunder boo 07:38 huginn magnuse: The current temperature in Bodo, Norway is 10.0°C (9:20 AM CEST on August 31, 2016). Conditions: Light Rain. Humidity: 94%. Dew Point: 9.0°C. Pressure: 29.62 in 1003 hPa (Steady). 09:10 LibraryClaire morning #koha 09:10 cait morning LibraryClaire 09:11 LibraryClaire hi cait :) 09:11 cait :) 09:13 eythian hi LibraryClaire & cait 09:13 LibraryClaire hey eythian :) 09:23 janPasi is it ok to change koha to marc mappings for publishercode in biblioitems table or will that break something? 09:24 janPasi we would like to use 028b here instead of the koha default 260b 09:24 cait it won't break things - but it won't apply immediately to records already in the system 09:24 Joubu should be ok 09:24 cait thhere is a job you can run to do that 09:24 janPasi cait: yeah, i know, it needs running the script to make it happen for the old records 09:25 janPasi i can't recall the name of the script, but i think i can find it again :D 09:26 janPasi thanks, we'll try that :) 09:26 cait REbuild...Bibllio sth 09:26 janPasi yeah 09:26 cait i think it's in misc or bin depending on your installation 09:26 cait i was looking at it yesterday 09:28 janPasi yeah, i think it's in misc somewere :D 09:28 Joubu misc/batchRebuildBiblioTables.pl 09:28 janPasi Joubu: cool, thanks :) 09:28 Joubu and misc/batchRebuildItemsTables.pl I guess 11:33 marcelr hi #koha 11:47 oleonard Hi #koha 11:47 marcelr hi oleopard 11:56 magnuse hi o'leopard 12:03 eythian olé, pard 12:04 eythian @wunder ams 12:04 huginn eythian: The current temperature in Schiphol, Badhoevedorp, Netherlands is 25.0°C (1:52 PM CEST on August 31, 2016). Conditions: Partly Cloudy. Humidity: 49%. Dew Point: 13.0°C. Pressure: 30.09 in 1019 hPa (Steady). 12:05 magnuse @wunder boo 12:05 huginn magnuse: The current temperature in Bodo, Norway is 13.0°C (1:50 PM CEST on August 31, 2016). Conditions: Light Rain. Humidity: 94%. Dew Point: 12.0°C. Pressure: 29.56 in 1001 hPa (Steady). 12:05 magnuse oh, it's possible to delete the AnonymousPatron? 12:05 magnuse shouldn't that be kind of easy to block? 12:05 eythian yeah, but you can't delete the HeadlessHorseman 12:06 oleonard It would be nice to be able to block deletion of any selected patron 12:06 magnuse ooh, there is a syspref for that? 12:06 magnuse ah donotdelete checkbox on each patron? sounds like a good idea, yeah 12:11 LibraryClaire @wunder LCY 12:11 huginn LibraryClaire: The current temperature in London City, United Kingdom is 22.0°C (12:50 PM BST on August 31, 2016). Conditions: Partly Cloudy. Humidity: 50%. Dew Point: 11.0°C. Pressure: 30.12 in 1020 hPa (Steady). 12:25 magnuse nengard! 12:25 wahanui somebody said nengard was fast 12:25 nengard morning magnuse 12:25 nengard how are you?? :) 12:25 magnuse good! 12:26 magnuse and yerself? missing us yet? ;-) 12:30 tcohen hola #koha 12:31 tcohen @later tell rangi I got the point on the first read. I answered that only so it is in the logs too 12:31 huginn tcohen: The operation succeeded. 12:31 nengard magnuse, I'm here every day :) nothing to miss :) hehe 12:31 nengard but I am loving my new job :) 12:32 LibraryClaire hi tcohen :) 12:32 tcohen hi LibraryClaire 12:33 magnuse nengard: that is good to hear :-) 12:34 eythian wahanui: australia is <reply>http://www.sbs.com.au/comedy/article/2016/08/31/australia-beautiful-see-hawk-literally-throw-snake-innocent-family 12:34 wahanui ...but australia is pretty great in a lot of ways, but they are woefully deficient in the pierogi department...|https://twitter.com/BR3NDA/status/410647513633284096/photo/1... 12:34 eythian wahanui: australia is also <reply>http://www.sbs.com.au/comedy/article/2016/08/31/australia-beautiful-see-hawk-literally-throw-snake-innocent-family 12:34 wahanui okay, eythian. 12:38 oleonard As opposed to the time a hawk threw a snake at a family who totally deserved it. 12:38 oleonard (which is so common in Australia as to not make the news) 12:39 jcamins oleonard: good point. 12:44 LibraryClaire terrifying 12:51 cait @later tell drojf ping! 12:51 huginn cait: The operation succeeded. 12:55 tcohen I don't think blou's comment about documentation is correct 12:59 Joubu the entry points are hard to find 12:59 tcohen probably, but we are all around to answer about those 13:00 Joubu yep yep 13:00 tcohen I accept we should think about improving documentation 13:00 * tcohen is not on denial 13:00 Joubu and patches are waiting for signoff for a while (before the ground has been pushed) 13:01 Joubu have to go, I will be afk for the next of the week. I had to get some rest or submit a very big patchset, I referred to postpone the submission :D 13:01 Joubu prefered 13:02 tcohen hehe 13:02 tcohen have a nice whatever you're gonna do 13:02 mtompset Greetings, #koha. 13:03 mtompset Sorry, tcohen, I didn't get to it yet. 13:03 mtompset I got distracted by a bigger problem! 13:03 mtompset check in 13:03 wahanui i heard check in was different though. 13:03 mtompset check out 13:03 mtompset restart mysql server 13:03 mtompset Oops... got that backwards... 13:03 magnuse have fun Joubu! 13:04 mtompset check out, check in, restart mysql server, check out, check in... old_issues bug! 13:04 mtompset InnoDb forgets its highest auto_increment after server restart! 13:05 mtompset Any ideas on the best way to solve it? 13:07 marcelr Joubu: still looking at bug 15758 13:07 huginn 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15758 enhancement, P5 - low, ---, jonathan.druart, Signed Off , Move the C4::Branch related code to Koha::Libraries - part 4 13:07 marcelr almost done 13:16 oleonard marcelr++ 13:16 marcelr oleonard++ for testing it 13:33 barton good morning #koha! 13:33 oleonard Hi barton 13:33 nengard morning barton 13:33 marcelr hi barton 13:34 barton I'm looking at bug 16581... I think there's still a number of un-answered questions there... 13:34 huginn 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16581 enhancement, P5 - low, ---, gmcharlt, RESOLVED WONTFIX, ICU tokenization bug in idzebra-2.0 2.0.59-1 13:34 marcelr mtompset: nasty problem, any chance of more issues cause of that? 13:35 mtompset anything with an old_! 13:35 marcelr barton: i did not understand why it was closed either 13:35 mtompset because if we are moving from one to the other, we'll hit overlap and lose history. 13:36 marcelr well an argument to stop with those deleted tables 13:36 mtompset A strong one. 13:36 barton so here are the things that I'm wondering about: 1) is it possible to require the use of the indexdata repo? 2) what version of idzebra-2.0 *should* we be using? 13:37 mtompset 1) why not? It's a good idea, 2) the current one -- I think something 62? 13:52 oleonard khall around? 13:55 nengard oh good he's ignoring you too :) hehehe 14:00 oleonard @later tell khall Bug 16903 says it has been pushed to master but I don't think it really has. 14:00 huginn oleonard: The operation succeeded. 14:01 mtompset Oh, and sorry for not doing it sooner. Greetings, oleonard nengard marcelr barton magnuse mario JesseM amyk :) 14:02 mtompset Apologies. Greetings, JoshB too. :) 14:02 marcelr bye 14:02 mtompset Bye. :) 14:02 JesseM Hello 14:02 JoshB hello 14:02 amyk greatings all! :-) 14:02 amyk oops 14:02 JesseM oleonard: khall is on vacation 14:02 amyk greetings! not awake yet ;-) 14:03 tcohen hi amyk JesseM 14:03 amyk hi nengard! 14:03 amyk hi tcohen 14:03 JesseM Hi tcohen 14:03 nengard yeah!! it's morning love fest :) hehe 14:03 nengard hi all! 14:03 nengard I miss this 14:03 amyk :-) 14:03 nengard at the new job we're all on so many calls that we hardly talk in IRC 14:03 oleonard calls-- 14:04 barton oleonard, nengard khall is out; he'll be back Friday. 14:04 nengard oh, okay :) 14:04 nengard and yes oleonard 14:07 mtompset OH! I'm not awake either. nengard! 14:08 mtompset How is the new job going? 14:13 nengard a-ok 14:13 nengard lovign my team and the work 14:16 oleonard And the hat, nengard? Don't foget the hat! 14:16 * oleonard assumes nengard wears it 9-5 every day now 14:17 * oleonard spends the rest of his day feverishly working on designs for a Koha hat 14:18 nengard ha 14:18 nengard that as kind of a lie ... it wasn't my hat - mine is still on the way 14:19 nengard was not as 14:19 eythian barton: requiring the use of another repository is not trivial, and not something I would expect drojf to be comfortable automating. 14:19 eythian I suspect it is wontfix because it's not feasible to fix from Koha's POV. 14:22 barton eythian: I see... so the proper avenue would probably be to file bugs with debian and indexdata to get idzebra-2.0 upgraded in jessie? 14:24 eythian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777515 <-- like this :) 14:24 eythian which unfortunately got no response. 14:24 eythian it's not something indexdata has control over 14:25 eythian My suggestion would be to have a warning in the staff client about page if a particular zebra version is in use that links to a wiki page with some resolutions, for example maybe a debian backport could be arranged. 14:26 eythian Or maybe just prodding the maintainer to see what he suggests 14:40 tcohen anyone to talk about the REST api and permissions? 14:42 * kidclamp waves 14:50 oleonard kidclamp: Are you sick of fielding questions from me about Coce yet? 14:53 kidclamp not yet 14:54 kidclamp what's the question oleonard 14:54 oleonard I'm still getting mixed http/https results from Amazon: https://search.myacpl.org/cgi-bin/koha/opac-search.pl?idx=kw&q=dogs&offset=40 14:54 oleonard Some covers from https://images-na.ssl-images-amazon.com, some from http://ecx.images-amazon.com 14:55 oleonard Do you know anything about that? 14:55 oleonard Or perhaps fredericd does? 14:55 kidclamp my guess, without looking into code, is that image links previously cached are http 14:55 kidclamp and new ones are pulled using https 14:55 kidclamp so as the links expire the issue will resolve itself 14:56 kidclamp or I can try to flush the amazon storage, but I don't know off top of my head 14:57 oleonard Out of curiosity, do you know what the lifetime of links is? 14:57 mtompset oleonard: ecx doesn't exist in git. Is it in a system preference? 14:57 oleonard mtompset: https://github.com/fredericd/coce 14:58 kidclamp 86400000 seconds 14:58 mtompset Okay... external git... :) 14:58 kidclamp 1000 days 14:59 oleonard Wow that's a long time 14:59 kidclamp I think it was to counter the fact that initial fetch doesn't load images 14:59 kidclamp when you do a new search coce gets the linkss, but doesn't display them until the next access 15:00 kidclamp so we keep them a long time to increase results displayed 15:04 kidclamp looking into how I can clear the amazon links oleonard, but not overfly familiar with redis 15:05 oleonard It's not a high priority kidclamp, but I would like to clear up those warnings. 15:06 kidclamp can you open a ticket oleonard - that will keep it on my radart 15:06 oleonard Sure, thanks. 15:23 morgane bye #koha 16:09 reiveune bye 16:52 kidclamp around oleonard? 16:52 oleonard Yes 16:53 kidclamp bug 14060 - I don't think we should warn on closing datepicker if no date is selected 16:53 huginn 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14060 normal, P5 - low, ---, jonathan.druart, Signed Off , Remove readonly on date inputs 16:56 kidclamp just wanted your thought 16:57 oleonard Agreed. I didn't notice that when I tested. 16:58 kidclamp Okay, FQA for now, but works well elsewise 18:54 CrispyBran Question for the room: How does one determine how Koha and when Koha calculates overdue and long overdue statuses? Is it on the fly, or is it done by a cron job? 18:59 eythian Pretty sure it's a cron job 19:00 CrispyBran Sorry, app issues. :/ 19:00 CrispyBran If anyone responded to my question, I missed it. :( 19:04 mtompset CrispyBran: It's a cronjob. 19:05 mtompset It's in /etc/cron*/koha-common I put *, because I don't know which one has it. :) 19:05 mtompset Have a great day (24 hour period), #koha. 19:45 * andreashm waves 19:51 * cait waves back 20:35 Mauricio_BR Hola a todos buenas tardes. alguien habla español? 20:41 Mauricio_BR please i need to know where is stored the 856 marc-tag in the koha database schema... 20:43 eythian @marc 856 20:43 huginn eythian: The information needed to locate and access an electronic resource. The field may be used in a bibliographic record for a resource when that resource or a subset of it is available electronically. In addition, it may be used to locate and access an electronic version of a non-electronic resource described in the bibliographic record or a related electronic resource. (Repeatable) (1 more message) 20:43 eythian @more 20:43 huginn eythian: [a,b,c,d,f,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,2,3,6,8] 20:45 kidclamp Mauricio_BR 856$u is likely mapped to / stored in biblioitems.uri in the DB 20:45 kidclamp make that url 20:46 Mauricio_BR thank you kodclamp, the thing is that I stored the url-cover in 856a 20:46 Mauricio_BR but i do not know where the 856a marc-tag is stored in the database schema 20:47 kidclamp if not mapped to a koha field it is stored in the full record / marcxml field in biblioitems 20:50 Mauricio_BR and can i map the 856a as a koha field after import a .mrc file? 20:57 kidclamp you can alter the mapping, but then you will need to run a script to rebuild the db from the biblios 20:58 Mauricio_BR mmm ok i see, thank you 21:06 tcohen hi kiwis 21:08 wizzyrea hi tcohen :) 21:14 tcohen hey wizzyrea 21:14 wahanui i think wizzyrea is so dumb at rewrite rules 21:14 tcohen wahanui: i don't belive you 21:14 wahanui tcohen: what? 21:15 wizzyrea still mostly true 21:15 wizzyrea ^.^ 21:15 tcohen wahanui: what you heard 21:15 wahanui tcohen: wish i knew 21:15 tcohen no one understands rewrite rules 21:15 tcohen or at least everyone has to review the docs each time 21:15 tcohen i'm sure 21:17 wizzyrea hehe 21:17 wizzyrea I"m still not sure I solved the problem that precipitated that original statement 21:18 wizzyrea this thread on developer problems is highly interesting 21:19 tcohen which one? 21:19 wahanui which one is t? 21:20 wizzyrea the one about koha-zebra-jessie 21:20 wizzyrea and "why is this so haaaard" 21:20 tcohen hahaha 21:20 wizzyrea (I was having a moan about this yesterday, independent of this) 21:22 wizzyrea it is reasonably hard to test things like elasticsearch 21:22 wizzyrea and plack. And any dev that touches lots of things 21:23 wizzyrea (the "advanced cataloguing interface" comes to mind) 21:24 tcohen yes, they are hard 21:25 tcohen and it is not the rest of the devs' fault 21:25 tcohen only for making it easy to test plack i re-did the kohadevbox 21:26 tcohen I struggle more with the fact that devs are done in environments that don't match production, than with difficult bugs 21:27 wizzyrea *nod* the lack of a really good production scale dataset is a serious problem 21:27 tcohen dataset, library versions, previous tries cruft, etc 21:27 wizzyrea thousands of borrowers, tens of thousands of records 21:28 wizzyrea hundreds of thousands of issues/old_issues 21:28 wizzyrea hundreds of reserves 21:28 wizzyrea nonlinear upgrades 21:28 wizzyrea and on and on 21:29 tcohen if we had a complete test suite 21:29 tcohen that should happen on jenkins 21:30 tcohen and is completely do-able 21:30 wizzyrea a good place to start maybe, would be to take say the members tests and build it up to not do like, one issue and return, but hundreds 21:30 wizzyrea or tens at the very least 21:31 tcohen you need to first think 'what question would you like the tests to answer' 21:32 wizzyrea I want a tool off the side that basically simulates a day at the library 21:33 wizzyrea users added, users removed, biblios/items added/removed, reserves added/filled/waiting/deleted/suspended, issues and returns 21:34 wizzyrea note I'm not asking you to write that. 21:34 wizzyrea ^.^ 21:34 tcohen hehe 21:35 tcohen you want t/db_dependent/selenium/basic_workflow.t 21:35 tcohen at least extending it 21:37 wizzyrea oh true, I didn't realise that was there. 21:37 wizzyrea Oh and that's another problem 21:37 tcohen ? 21:38 wizzyrea keeping on top of every new thing. :) 21:38 tcohen ah 21:38 tcohen he 21:38 tcohen it needs to be around, daily 21:38 tcohen otherwise you loose track 21:38 tcohen that's true 21:39 tcohen that was what I tried to reply to blou 21:39 wizzyrea even I just simply don't have enough spoons for all the things that I should be on top of. 21:40 * tcohen knows about that 22:30 rangi hey hey 22:30 wahanui niihau, rangi 22:31 rangi guess who moved into number 2 pushing liblime down in the companies list today 22:32 rangi http://git.koha-community.org/stats/koha-master/authors.html#commits_by_domains 22:33 tcohen :-D 22:33 tcohen catalyst++ 22:33 tcohen google is close too :-P 22:33 rangi hehe yeah, if you combine ? and gmail .. the unknowns are 2nd :) 22:34 rangi how cool is it that a library myacpl is 4th though 22:34 tcohen oleonard is awesome :-D 22:35 rangi but also, 2 directors now, who have let him do that 22:35 rangi thats pretty amazing 22:38 tcohen true 23:47 tcohen bye #koha 23:48 rangi cya tcohen