Time  Nick          Message
23:41 gmcharlt      thanks, everybody!
23:41 huginn        Log:            http://meetings.koha-community.org/2014/development_irc_meeting__9_september_2014__part_2_.2014-09-09-22.03.log.html
23:41 huginn        Minutes (text): http://meetings.koha-community.org/2014/development_irc_meeting__9_september_2014__part_2_.2014-09-09-22.03.txt
23:41 huginn        Minutes:        http://meetings.koha-community.org/2014/development_irc_meeting__9_september_2014__part_2_.2014-09-09-22.03.html
23:41 huginn        Meeting ended Tue Sep  9 23:41:20 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
23:41 gmcharlt      #endmeeting
23:41 gmcharlt      and... that's a wrap
23:41 gmcharlt      #agreed We'll meet same time next week
23:41 gmcharlt      ok
23:40 rangi         none from me
23:39 gmcharlt      any objections?
23:39 gmcharlt      the first meeting has agreed on holding the next meeting the same time next week
23:39 gmcharlt      #topic Next meeting
23:38 gmcharlt      #info gmcharlt and tcohen set deadline of 9/19 forwriting some unit tests for the utf8 bug
23:38 gmcharlt      #info ashimema has started qa for UTF8 bug.. minimal comments left already
23:38 gmcharlt      #info ashimema added a note to the wiki to encourage use of columns stuff for datatables
23:37 gmcharlt      #topic Action items from previous meeting
23:35 gmcharlt      great
23:35 eythian       they can go upstream separately.
23:35 eythian       Elasticsearch is mosying along. I really ought to break out the bits I've had to build to support it, like Koha::Biblio and such.
23:35 dcook         Actually, bbiab
23:34 dcook         I don't think I'm up to anything with Koha at the moment. Non-Koha projects and local stuff at the moment.
23:34 * pianohacker has to head out. Bye all!
23:34 pianohacker   Rancor patches coming soon, with new macro languages, bugfixes and optional chrome running boards
23:33 gmcharlt      #info Feedback still being sought on the VAT/GST rewrite
23:33 gmcharlt      also
23:33 gmcharlt      anything else?
23:31 rangi         but its always going to be a separate project, not merged with koha (like the SIP was) so it doesnt end up like the sip did
23:31 rangi         ncip stuff is in uat testing with masscat, in the meantime its being refactored by dyrcona
23:30 gmcharlt      OK, watcha all doing?
23:30 * dcook       perks up
23:30 dcook         I heard my name
23:30 gmcharlt      #topic Big stuff we are working on
23:30 gmcharlt      moving on
23:29 gmcharlt      in that case, perhaps it might be as easy as changing a few variable, column, and syspref names
23:29 rangi         ah yeah, i have nothing else to add
23:27 eythian       it needed a better explanation, it wasn't until I got to dcook's comment that I figured it out.
23:27 gmcharlt      any other comments on this before we move on?
23:27 * gmcharlt    has now left some feedback
23:24 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10860 enhancement, P5 - low, ---, jonathan.druart, Needs Signoff , In-House Use
23:24 gmcharlt      #info Joubu is requesting feedback on bug 10860, which adds a "reading room"/"in house use" feature
23:23 gmcharlt      #topic Call for feedback
23:22 gmcharlt      #action eythian will start a discussion on koha-devel about --dryrun behavior for CLI scripts
23:22 eythian       sure
23:22 gmcharlt      who wants to start a thread on koha-devel about --dryrun? eythian?
23:21 huginn        Yes (5): rangi, gmcharlt, tcohen, pianohacker, eythian
23:21 huginn        Voted on "Shall we adopt the pod* & Getopt::Long sections of the propose CLI script guidelines?" Results are
23:21 gmcharlt      #endvote
23:21 gmcharlt      kk
23:21 rangi         #vote yes
23:21 eythian       #vote yes
23:20 tcohen        #vote yes
23:20 pianohacker   #vote yes
23:20 gmcharlt      #vote yes
23:20 huginn        Vote using '#vote OPTION'. Only your last vote counts.
23:20 huginn        Begin voting on: Shall we adopt the pod* & Getopt::Long sections of the propose CLI script guidelines? Valid vote options are Yes, No, Abstain.
23:20 gmcharlt      #startvote Shall we adopt the pod* & Getopt::Long sections of the propose CLI script guidelines? Yes, No, Abstain
23:19 gmcharlt      ok, I'll take up pianohacker's suggest
23:19 huginn        Current chairs: gmcharlt tcohen
23:19 tcohen        #chair gmcharlt
23:19 tcohen        thanks
23:19 gmcharlt      I'll grab it
23:19 tcohen        guys, need to leave, can anyone chair?
23:18 pianohacker   I think we all agree on everything but dryrun; should we vote on the guidelines besides that portion?
23:16 eythian       almost everything has options anyway
23:16 gmcharlt      at least in this case, there are a small enough number of such scripts that we can reasonably expect to ahve the tuits to bend them all to our will, whichever convention we decide on
23:16 eythian       yeah
23:15 pianohacker   I like do-nothing-with-no-params regardless of dryrun being default or not
23:15 eythian       (in a way that you can't tell if it was going to do the right hting or not.)
23:15 eythian       the linkbibstoauthorities is one offender, its output is actually different when it's in dryrun mode.
23:15 rangi         i like the do nothing without at least one param option
23:15 gmcharlt      at least for the ones that would be destructive if (passively) misused
23:14 eythian       however, if it's dry run by default, it needs to make it _really_clear_, as there are some scripts that don't and it's very confusing.
23:14 rangi         yeah
23:14 gmcharlt      an alternative might be adopting --dryrun, but also ensuring that just running the script without any parameters doesn't do anything except show the help
23:14 pianohacker   true, but it makes for angrier mailing list posts ;)
23:14 eythian       if you use it without understanding, you've got bigger problems anyway.
23:13 pianohacker   eythian: a lot of the scripts where this might apply can be massive data shotguns if fat-fingered or used without understanding, I vote for keeping dry-run as the default
23:12 eythian       i.e. reversing the sense so that you're putting it into a test mode.
23:12 eythian       or something like that
23:12 eythian       why not --dryrun
23:12 pianohacker   rangi: isn't there a strong trend to use -f for that outside of coreutils?
23:12 gmcharlt      --run ?
23:12 rangi         i think that might get confusing
23:11 tcohen        you're right
23:11 rangi         in the posix world
23:11 rangi         thats pretty much universally used for config
23:11 rangi         is -c
23:11 rangi         the only one
23:11 pianohacker   all of these are close enough to a de facto standard that I think enshrining them is an excellent idea
23:11 tcohen        RM
23:11 tcohen        JOubu mentioned gmcharlt asked CLI scripts to have a dry run mode too when he was MR
23:10 tcohen        - the -c parameter to confirm the changes
23:10 tcohen        - add the POD at the end of the file
23:09 tcohen        - call pod2usage if something wrong with the parameters
23:09 tcohen        - GetOpt::Long
23:09 tcohen        - Pod::Usage
23:09 tcohen        he proposes:
23:09 tcohen        Jonathan proposed some coding guidelines for CLI scripts
23:09 tcohen        #topic Requirements for CLI scripts
23:08 tcohen        #info there is a partial agreement on having coding guidelines that match DBIc ones, concerns raise about how to migrate existing tables/column names and research is needed
23:08 pianohacker   +1
23:08 bag           sure +1
23:07 tcohen        ?
23:07 tcohen        ok we agree we could have a coding guideline, and some research is needed to figure how a migration path would develop
23:05 pianohacker   no opinion on the changing existing tables, but I am in favor of new ones following guidelines
23:05 eythian       I also don't have a strong opinion on it :)
23:05 bag           I vote 0 cause I'd like some research first
23:04 gmcharlt      0 for me
23:04 gmcharlt      I LOVE XML (... followed by cavets)
23:04 rangi         0 for me
23:04 rangi         hmm yeah no opinion yet
23:04 eythian       I think so, yeah
23:04 bag           HA
23:04 tcohen        heh
23:04 wahanui       I HATE XML
23:04 tcohen        pianohacker?
23:04 tcohen        gmcharlt, eythian, rangi?
23:03 bag           0 - no vote
23:02 tcohen        can we say we agree new tables/columns should follow DBIc naming convention, and it should be written in the coding guidelines?
23:01 * bag         sent a note to khall
23:01 gmcharlt      eythian: yeah, I think such aliasing would be doable
23:01 tcohen        night
23:01 wahanui       If you feel like someone is looking through wahanui's window, it's OK, it's just me.
23:01 cait          good night
23:01 cait          sorry much too late here, need to go
23:00 tcohen        (as part of the thread)
23:00 tcohen        eythian: i like your idea, maybe we could ask khall to do some research on that
22:59 tcohen        gmcharlt: people like Yohann worked on moving from DBI to using DBIc, maybe we should encourage people doing that, to revisit the current table/column names
22:59 rangi         yeah, new ones seems ok, changing old ones seems like a way to make a mess
22:58 cait          just changing to meet guidelines is difficult, we tend to introduce bugs, even with careful rewrites all the time
22:58 eythian       I wonder if we can make dbic pretend like existing things have the properly styled names, to make renaming the actual existing tables/columns easier in the future.
22:58 bag           either way - it's still a pain in the a..  and you really have to have an idea of what you are looking for
22:58 cait          i am not sure about the gain
22:58 bag           I could agree with new tables and columns
22:56 cait          hm good point
22:56 gmcharlt      if not, then I think it would need to be very clear that any such convention applies only to new tables and columns
22:56 gmcharlt      well, one question is whether anybody cares to make a committment to revise the schema to match
22:55 cait          tcohen: now you want to make me use google translate?
22:55 tcohen        no harm on having *any* naming convention
22:55 tcohen        as eythian said, that horse has already bolted
22:54 cait          not sure what it implies, it does sound ok so far
22:53 tcohen        maybe we should just vote/agree on following DBIC conventions and next meeting vote the wording
22:53 tcohen        khall will propose the wording
22:53 * tcohen      is reading the logs
22:52 tcohen        and 'id' for primary key
22:52 tcohen        OO style
22:51 cait          and plurals on table names i think
22:49 tcohen        yes
22:49 eythian       so the dbic convention is to use underscore_style?
22:49 tcohen        ?
22:49 tcohen        any objections
22:48 tcohen        "To add a rule to the coding guidelines that mimicks that of the dbic conventions for column_names pending this evening meeting"
22:48 tcohen        part one voted to add to the coding guidelines
22:47 tcohen        :-P
22:47 eythian       (that's not really a reason to not start having a standard though.)
22:47 tcohen        eythian: stop making me use google translate
22:47 eythian       naming is already a bit of a mishmash
22:46 tcohen        eythian: meaning?
22:46 tcohen        essentialy, that we follow standard dbic naming convention
22:45 * eythian     feels that horse may have bolted :)
22:45 tcohen        a naming cenvention for table/column names
22:45 tcohen        in line with the preivous one (not a coincidence) khall proposed that we adopt
22:44 tcohen        #topic Naming of database columns
22:44 cait          :)
22:44 tcohen        don't leave khall aloooone
22:44 tcohen        ok, we are all encouraged to post our opinions once that email is posted
22:43 rangi         cool
22:43 tcohen        so he offered to post that on the list
22:43 rangi         i think we shouldnt do either yeah, no dbi and dbic at the pl
22:43 tcohen        khall thought he had a point on what we could be doing with dbic that we dont
22:43 eythian       yep
22:42 tcohen        my opinion is, in principle, that using dbic is similar to using dbi at the .pl level, and i tend not to agree
22:42 rangi         im leaning that way, but dont have enough thoughts to write up an email yet
22:41 eythian       depending on a database at the .pl level doesn't mesh with that.
22:41 eythian       our modules should present a data-storage-independent API
22:41 eythian       I don't think I like it.
22:41 tcohen        anyone wants to write his/her opinion on the subject here?
22:41 rangi         havent really thought about it enough to know if i like it or not
22:40 tcohen        and using DBIC ResultSet for crud operations is not different from using our own crafted packages
22:39 tcohen        the key point being that sooner than later we should start using DBIc more extensively
22:38 tcohen        and khall was forced to volunteer to post an email to the dev list on the subject
22:38 tcohen        during part 1 we decided to move the discussion to the list
22:38 tcohen        #topic should we use DBIC on .pl scripts?
22:37 tcohen        #agreed adding Koha.Preference use to coding guidelines
22:37 rangi         +1
22:36 gmcharlt      +1
22:36 pianohacker   +1
22:36 tcohen        +1
22:36 cait          +1
22:35 tcohen        should we vote?
22:35 tcohen        it could be done as training on the hackfest, dunno
22:34 tcohen        if anyone has the time to do it, we'll see what happens
22:34 pianohacker   I like the guideline for new code, yes
22:34 cait          i think rewriting old code will only introduce bugs
22:34 tcohen        part 1 agreed to add that to the coding guidelines, it is for new code
22:34 cait          ok for me for new code
22:33 tcohen        #link coding guidelines foe using Koha.Preference https://trello.com/c/8d7pELLj/28-coding-guidelines-koha-preference
22:33 tcohen        there is a proposal from dcook to add the use of Koha.Preference on TT instead of passing syspref values from .pl scripts
22:32 tcohen        #topic Additions to Coding Guidelines
22:32 tcohen        will skip some items, and put them on the "bgs" topic
22:31 tcohen        ok, moving on then
22:30 cait          not closely
22:29 tcohen        has anyone read the TestBuilder code yet?
22:28 tcohen        i'm trying to read questions raised on part 1, so we have more opinions
22:26 * tcohen      tends to be non-idiomatic
22:26 cait          not sure about the terms/differences, sorry
22:25 tcohen        and also, should we spend time writing mocked tests or complete multiple-pieces integrated tests?
22:25 cait          if i got the question correctly
22:25 cait          without needing special data or leaving traces
22:25 cait          yes, i think it would be nice to get the tests to be able to run on any database
22:25 tcohen        do you guys agree each test should build its own data?
22:24 cait          but I think by adding more 'koha ways' of doing things, we might make things harder in the end
22:23 tcohen        maybe *someone* can run a tutorial
22:23 cait          :)
22:23 cait          maybe hackfest?
22:23 tcohen        we can spend some time on that during hackfest cait
22:22 cait          i'd like if there was a tutorial or something for beginners with mock
22:22 tcohen        hi gmcharlt
22:22 tcohen        my experience with Test::MockObject is positive
22:22 * gmcharlt_   feels much the same way as rangi; I don't think it that's hard to more directly create required rows in dependent tables
22:22 rangi         and something that other perl developers would have seen before
22:22 tcohen        and it is simpler to write tests
22:21 tcohen        it is methodologically cleaner
22:21 tcohen        I personally prefer to mock
22:21 rangi         then i can ignore it
22:20 rangi         but as long as its not mandatory
22:20 cait          i tend to agree
22:20 rangi         its 1/ another tool for people to learn 2/ something that needs its own tests 3/ something we have to maintain 4/ makes people not understand how the db actually works
22:19 tcohen        certaintly
22:19 rangi         i think everyone knows that im against the idea
22:19 tcohen        you need to create the patron category, the branches, etc
22:18 tcohen        because if you cannot depend on DB's content (ideally)
22:18 cait          hm
22:18 cait          why not create it with koha's methods?
22:18 tcohen        no need to create all stuff needed to create a patron before creating it
22:18 tcohen        the main idea is that if your test needs a patron, you create it with testbuilder
22:17 cait          it#s also another tool to learn - would it be mandatory?
22:16 cait          I am a little worried about people forgetting what actualyl happens in the background with a tool like testbuilder
22:15 wahanui       opinions are slightly divded :)
22:15 tcohen        opinions?
22:15 tcohen        I proposed they should be able to run randomly (no side effect between unit tests)
22:14 tcohen        and there was some agreement they shouldn't have side effects, create its own semi-randomized data
22:14 tcohen        they are more like integration tests
22:14 tcohen        TestBuilder appears as a way to write more tests in an easier way
22:13 tcohen        *and* also have a means to have proper integration tests
22:13 tcohen        my position was that ideally we should have complete unit tests for out methods, with all their dependencies mocked, to prevent side effects upon testing
22:12 tcohen        the pros and cons
22:12 tcohen        trying to speak about the whole testing stuff we've collected on the project
22:12 tcohen        on part 1, it was discussed in a broader way
22:10 tcohen        https://trello.com/c/vsrkdpvv/27-tests-mocking-when-to-and-when-not-to-that-is-the-question
22:10 tcohen        there's been a discussion on the subject
22:09 tcohen        #subtopic To mock or not to mock...?
22:09 cait          yep
22:09 tcohen        #topic General technical discussion
22:09 bag           yup
22:09 tcohen        moving on?
22:09 tcohen        heh
22:09 bag           heh my favorite - (sorry to interrupt the meeting)
22:09 wahanui       I LIKE SPACE AND MY WIFE
22:09 bag           NateC?
22:08 tcohen        https://github.com/tomascohen/koha/commit/281808cce6cc94e26beb6281ec44daada0a85595
22:07 tcohen        to define facets
22:07 tcohen        i focused on XSLT's and defining almost-good syntax for the XML file
22:07 cait          which is ok, just for testing
22:07 tcohen        good question: yes
22:06 cait          tcohen: just a quick question - it#s dom only now?
22:06 tcohen        thanks to jcamins and indexdata for their support
22:06 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232 new feature, P5 - low, ---, gmcharlt, Needs Signoff , Retrieve facets from Zebra
22:06 wahanui       i already had it that way, tcohen.
22:06 tcohen        #info facets from zebra is needs sign off, bug 11232
22:05 wizzyrea      \o/
22:05 tcohen        that is to say I'll try to focus on UTF-8 regression tests
22:05 cait          tcohen++
22:05 tcohen        as i mentioned earlier, my work on facets is pretty complete
22:05 tcohen        #topic RM 3.18 comments
22:04 tcohen        which bug rangi?
22:04 JasonBurds    #info Jason Burds I.T. Supervisor Carnegie-Stout Public Library
22:03 bag           #info Brendan Gallagher ByWater
22:03 wizzyrea      #info Liz Rea, Catalyst IT
22:03 tcohen        #info Tomas Cohen Arazi, Universidad Nacional de Cordoba
22:03 cait          #info Katrin Fischer
22:03 wahanui       #info wahanui, a bot that has become sentient
22:03 tcohen        #topic Introductions
22:03 huginn        The meeting name has been set to 'development_irc_meeting__9_september_2014__part_2_'
22:03 huginn        Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:03 huginn        Meeting started Tue Sep  9 22:03:04 2014 UTC.  The chair is tcohen. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03 tcohen        #startmeeting Development IRC meeting, 9 September 2014 (part 2)
22:02 cait          we got midnight now
22:02 cait          it's really late here oto, that's the problem
22:01 tcohen        i can pay some attention
22:01 tcohen        i cannot, unfortunately
22:01 cait          tcohen: are you around and can chair?
22:01 wahanui       privet, tcohen
22:01 tcohen        hi
22:01 cait          ah
22:01 bag           I think tcohen just joined us
22:01 bag           that works no?
22:01 bag           I'm here, JasonBurds is here, rangi and cait
22:00 cait          anyone around for the meeting?
22:00 cait          hm ok
21:58 rangi         theres a bug
21:57 bag           I know we've gone this before
21:56 JasonBurds    we have a vendor that wants weekly dumps so I wanted to automate it
21:56 bag           there are some cronjobs iirc
21:55 JasonBurds    I am manually running it from the tools menu atm
21:55 JasonBurds    I haven't check yet
21:55 cait          then you could use cron maybe
21:55 cait          i am not sure, but did you check if there is a command line tool for doing tha tin koha?
21:54 cait          hm
21:53 JasonBurds    Does anyone know a good way of scheduling bibs with items export to mrc files?
21:24 cait          sleep well :)
21:24 cait          thought so
21:24 ashimema      so not I ;)
21:24 ashimema      lol.. I'm heading to bed miss..
21:24 ashimema      made a fair few decisions though.. obviosly pending any objections later.
21:24 cait          someone around willing to chair a meeting in 30 mins? :)
21:23 cait          i might fall asleep in the midst of it
21:23 ashimema      wonder if they'll talk much in the second meeting.. looking at the logs for the last few seems they're always quieter then ;)
21:23 ashimema      it certianly was a long agenda..
21:22 wizzyrea      also: smoked butter.
21:21 wizzyrea      http://www.whitestonecheese.com/ < awesome cheese.
21:21 wizzyrea      cheese is good
21:21 wizzyrea      not cheese. :P
21:21 cait          ashimema: long agenda :)
21:20 wizzyrea      ashimema: ohh, that stinks.
21:20 wizzyrea      yeah.
21:20 cait          wizzyrea: cheese? ;)
21:20 ashimema      it was a long one cait
21:20 wizzyrea      man I always miss the good conversations
21:19 cait          still reading logs from first meeting :)
21:19 cait          good night ashimema :)
21:16 ashimema      g'night #koha
21:12 mtompset      Bye, pianohacker magnuse jcamins cait. :)
21:12 mtompset      Have a great day, #koha. Thanks for the email thd-away.
20:45 * magnuse     wanders off to dream of cheese
20:45 magnuse       weird and wonderful!
20:43 mtompset      And that demonstrates cheese is a source of weirdness too. ;)
20:42 mtompset      Why do people call it cutting the cheese when they fart?
20:41 magnuse       it is!
20:41 cait          cheese is complicated stuff
20:40 magnuse       some of them can be really um, dunno what to call it... astringent?
20:40 magnuse       but as the wikipedia article says, brunost can also be used as a name for a cheese that is made with the same methods, but from goats milk
20:39 magnuse       pianohacker: prim does, and some brunost.
20:39 magnuse       and then there is https://en.wikipedia.org/wiki/Gomme_%28food%29, which i think of as sort of related to brunost and prim, probably about 5 varieties of that too
20:38 pianohacker   so it mostly just tastes milky and caramelized and sweet?
20:38 magnuse       my local store probably has 5 kinds of "prim" too
20:37 magnuse       "If boiled for a shorter time, the soft, spreadable version called prim in Norwegian (or messmör in Swedish and mysingur in Icelandic), similar to dulce de leche, is produced."
20:37 magnuse       lol, i guess we do :-)
20:36 jcamins       magnuse: you Norwegians have a lot of dairy-related disasters, don't you? The butter crisis, the brunost fire...
20:35 pianohacker   oh yum
20:35 magnuse       there are lots of different varieties. my local store probably has at least 10 types
20:34 magnuse       i don't think i know dulce de leche
20:34 pianohacker   magnuse: that sounds fantastic. is the hard version like a hard dulce de leche?
20:33 cait          wow
20:33 magnuse       "In January 2013, the Bratli Tunnel at Tysfjord was damaged when a lorry load of caramelised brunost caught fire. The high concentration of fat and sugar in the cheese caused it to burn fiercely at sufficiently high temperatures that the fire was still burning five days later."
20:32 magnuse       maybe some https://en.wikipedia.org/wiki/Brunost (which is strictly speaking not a cheese)
20:31 * magnuse     consider bringing some norwegian cheese next year
20:31 magnuse       for eating with my hands, i would prefer cheese, yes
20:30 bag           cheese is better!
20:30 magnuse       yes, butter is nice too
20:30 cait          rofl
20:30 magnuse       lol
20:30 wahanui       well, cheese is delicious, but cait just had butter.
20:30 magnuse       cheese!
20:29 bag           magnuse yes please
20:29 * magnuse     must make it to marseille, at least
20:29 cait          we should split off another for the dev talk
20:29 cait          this is really a food channel
20:28 cait          :)
20:28 bag           I love cheese day - can't wait for next years :D
20:06 cait          aah good luck then :)
20:06 * magnuse     crosses fingers some more
20:06 paul_p        cait (it was a private message: the 1st contact for this RFP came from magnus, and I promized french cheese if we win)
20:05 cait          ok this lomito looks delicious
20:05 cait          cheese in an rfp?
20:05 * magnuse     crosses fingers
20:04 cait          thx
20:04 cait          oh missed the link the first time
20:04 paul_p        s/come/could/
20:04 paul_p        magnuse (keep fingers crossed, cheese come be in this RFP ;-) )
20:03 magnuse       have fun paul_p
20:03 paul_p        I have to go. On international RFP to end before sleeping...
20:02 paul_p        cait seems that = http://www.saveur.com/article/Recipes/Lomito-Completo
20:01 cait          lomito?
20:00 paul_p        bye
20:00 tcohen        bye paul_p
20:00 tcohen        bye!
20:00 tcohen        so, must-try
19:59 tcohen        there aren't 'lomitos' like that in buenos aires or any other place
19:59 bag           oh yeah tcohen I'm going to try that place
19:58 cait          bag: yah, we were talking about food :P
19:58 bag           rangi++
19:58 bag           talking about asado's and such
19:58 bag           HA figures rangi would show up now
19:58 paul_p        kia ora rangi
19:58 magnuse       not /me ;-)
19:58 bag           cool I'll cook you all some food one night if there is a bbq on the balcony
19:58 rangi         :)
19:57 magnuse       kia ora rangi
19:57 cait          we are being excited about argentina and asados :)
19:57 cait          morning rangi
19:57 rangi         morning
19:57 cait          bag: in our apartment description it says something about bbq on the balcony i think
19:57 tcohen        you need to try this at least once http://www.betos.com.ar/?lang=en
19:56 bag           heh
19:56 bag           let's have one everyday!!!
19:56 bag           tcohen++
19:56 tcohen        that's impossible
19:56 tcohen        we won't be having *one* asado
19:56 cait          bag: clever:)
19:56 magnuse       yeah, finding them so close to home is a mixed blessing...
19:56 cait          heavenly
19:56 cait          i found ben and jerry's with peanut butter cups in a store recently
19:55 cait          they are sooo good
19:55 bag           magnuse++
19:55 bag           ah magnuse
19:55 bag           woot
19:55 * magnuse     just found REESE'S Peanut Butter Cups in a local store - will have to do some comfort eating...
19:55 bag           oh cait we are having one!  I'm going to sponsor one for everyone :D
19:55 cait          i am sure tcohen won't let you go before you had one
19:54 cait          lol
19:54 bag           ever since I learned of what it is
19:54 bag           but I've been dreaming of an asado for years now
19:54 cait          koha people!
19:54 bag           well amongst other cool things too :)
19:54 cait          lol
19:53 bag           ASADO!!!
19:53 * magnuse     sighs
19:53 tcohen        we are really excited here too
19:53 cait          super super super excited heh
19:53 bag           me too :D
19:52 cait          i am super excited :)
19:52 wahanui       niihau, bag
19:52 bag           magnuse: HI THERE
19:52 paul_p        bag I can't believe it's in less than 1 month now...
19:52 magnuse       bag: HI
19:49 cait          :)
19:46 bag           cya soon in argentina :)
19:46 bag           heya paul_p
19:43 tcohen        hi paul
19:43 paul_p        tcohen are you around ?
19:36 mtompset      Thanks. looking now.
19:35 thd           mtompset: I have sent the code archive now.
18:30 mtompset      I won't be running for anyone else... I'll be running it to figure out how it works, and then get the data out of it, and then delete it. :)
18:29 thd           mtompset:  The license as I received it is AGPL 3 which would require modification to link to the source of your modified version if you run it for someone else over the network.
18:27 thd           Consequently, a GPL compatible license could not be GPL 2 which Koha was using at the time.
18:27 mtompset      Mixed licenses are a pain. Even Koha has a bit of this problem with some of the pieces it integrates. :)
18:26 thd           mtompset: There is an Apache 2 License code from Amazon as part of it.
18:26 mtompset      So could you email it to me then?
18:24 thd           mtompset: The author did not use any actual license for the users of Chopac which are few.
18:24 thd           mtompset: That is easy enough.  I think the code needs modification to conform to its own license as given to me.
18:20 mtompset      Ah, well, I don't need to integrate it. I just need to understand it, so I can get data out of it. :)
18:19 thd           mtompset: Very small.  If I had any time it would be in Koha but the issue had been a license upgrade for the project.
18:18 mtompset      how big is it?
18:18 thd           mtompset: I can make a copy of the source code for you.
18:13 tgoat         hey look .. Im back!
18:10 mtompset      Mmmm.... no, that's just an interface.
18:06 thd           mtompset: The source code is in Chopac, http://chopac.org .
18:05 mtompset      How does one install it?
18:05 thd           mtompset: The biggest difficulty with the implementation is that some organisation's use may not conform to the terms of service for the APIs which it uses.
18:05 mtompset      So, I wonder what my colleagues in Africa are using and calling LibCat.
18:03 thd           mtompset: LibCat is an automated cataloguing aid which creates some basic MARC 21 information from some common information sources.
18:01 thd           http://www.libcat.org
18:00 mtompset      Can you point me at a URL or something? I'm new to what LibCat supposedly even is.
18:00 thd           mtompset: I worked with the author to obtain the source code with a proper license attached.
17:59 thd           mtompset: Some of it would be in Koha already if I had more time.
17:59 mtompset      thd: Any idea on how to export from LibCat to Koha?
17:59 thd           mtompset: Yes, very familiar.
17:56 thd           hello mtompset.
17:56 mtompset      Any one here familiar with LibCat?
17:56 thd           oleonard: However, most of my time is often already taken by things which might have been relatively easy but actually are found not to be.
17:56 mtompset      Greetings, thd.
17:55 mtompset      Greetings, indradg. :)
17:55 indradg       mtompset: hiya
17:53 thd           oleonard: A better answer would be if I thought it might be relatively easy to fix even if was actually not easy.
17:46 mtompset      Greetings, #koha.
17:39 thd           oleonard: If I thought that it would be the greatest collaboration system ever then yes.
17:38 thd           oleonard: no ;)
17:38 oleonard      Is that something you were likely to do?
17:37 thd           s/fix/fixing/
17:37 thd           oleonard:  However, the source code of Trello is not available for the possibility of fix the problem.
17:35 thd           oleonard: It may be the version on the old system from which I have not yet migrated my IRC infrastructure.
17:28 thd           Joubu: Unnecessary use of JavaScript grrr.
17:28 oleonard      Chromium doesn't complain to me.
17:27 Joubu         I am starving too! Have a good day/night everyone
17:26 thd           It may work despite the warning that it would not.
17:26 Joubu         thd: but if it works, don't care :)
17:26 wahanui       the version is always noted in a comment on top
17:26 Joubu         thd: what's the version?
17:25 thd           Joubu: Actually, I was using chromium just now when I saw the complaint.
17:25 ashimema      dinner time..
17:25 barton        lynx on an amiga was my primary web browser through most of the 90s.
17:24 barton        old school!
17:24 thd           Joubu: I prefer lynx ;)
17:24 barton        Joubu++
17:24 Joubu         are you using w3m or links? :)
17:24 oleonard      thd: What is your web browser?
17:23 ashimema      a bit rushed at the end there.. but I could sense we were loosing everyone ;)
17:23 Joubu         thd: hum, I don't know
17:23 huginn        Log:            http://meetings.koha-community.org/2014/koha_developer_irc_meeting__9_september_2014___part_1.2014-09-09-15.07.log.html
17:23 huginn        Minutes (text): http://meetings.koha-community.org/2014/koha_developer_irc_meeting__9_september_2014___part_1.2014-09-09-15.07.txt
17:23 huginn        Minutes:        http://meetings.koha-community.org/2014/koha_developer_irc_meeting__9_september_2014___part_1.2014-09-09-15.07.html
17:23 huginn        Meeting ended Tue Sep  9 17:23:39 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:23 ashimema      #endmeeting
17:23 thd           Joubu why does the trello board complain about my web browser?
17:23 ashimema      #info more chat on the trello board before the meeting.. try to limit the meeting to agreements and assignments of work.
17:22 Joubu         (trello or alternative)
17:22 ashimema      yeah.. I agree. we should make more sue of trello and use the meeting to bascially vote and assign tasks.
17:22 Joubu         in order no to debate from the beginning.
17:22 ashimema      #agreed meeting needs to be kept shorter
17:22 Joubu         It would be great to have some discussion on the trello board, before the meeting
17:22 ashimema      #agreed Same time next week.. assuming that's ok with the guys this evening
17:21 ashimema      done
17:21 ztajoli       Ok for me
17:21 atheia        next tuesday is fine with me.
17:21 ashimema      what he said..
17:21 ashimema      hopefully these meets will get shorter soon.
17:21 Joubu         next tuesday? (maybe a little bit shorter :))
17:21 ashimema      Worth keeping the momentum and having another same time next week.. or should we have a bigger gap..
17:20 ashimema      #topic Next Meeting?
17:19 ashimema      any more for any more?
17:19 ashimema      that's all the actions in the minutes..
17:19 ashimema      #info Waiting to hear from gmcharlt, tcohen regarding utf8 tests
17:18 ashimema      #info ashimema has started qa for UTF8 bug.. minimal comments left already
17:18 ashimema      #info ashimema added a note to the wiki to encourage use of columns stuff for datatables
17:17 ashimema      #topic Actions from last meeting
17:17 ashimema      this actually moves us on nicely to
17:17 Joubu         ashimema: no new stuff (except vat rewrite:)) from BibLibre planned
17:17 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11944 major, P5 - low, ---, jonathan.druart, Signed Off , Cleanup Koha UTF-8
17:17 ashimema      #info bug 11944 is working it's way through QA
17:16 Joubu         I don't know, I hope :)
17:16 ashimema      he was working on tests for it was he not?
17:16 * Joubu       does not know why he told that
17:16 ashimema      shame tcohen has gone..
17:16 ashimema      deffo.
17:15 Joubu         ashimema: it could be good not to squash the patches. I think we need to keep the history, if something wrong happened
17:15 ashimema      it's a biggen ;)
17:15 ashimema      ztajoli, i'm still working on it..
17:14 ztajoli       UTF-8 QA ?
17:14 ashimema      any mroe for any more?
17:14 ashimema      :)
17:14 Joubu         you can upload your data (test installation only!, the data will be deleted)
17:13 ashimema      #info hea is bug 11926
17:13 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11926 new feature, P5 - low, ---, jonathan.druart, ASSIGNED , Render community koha statistic usages
17:13 Joubu         see bug 11926
17:13 ashimema      I'm about to add it to our customer repository Joubu.. then i just need to talk customers into turning it on ;)
17:12 atheia        hea is looking nice!
17:12 ashimema      #info account rewrite is getting there.. wohoo
17:12 khall         neat!
17:12 Joubu         but
17:12 Joubu         (Bug I don't find guinea pigs to test it)
17:12 ashimema      it works today.
17:12 ashimema      ooh.. that link didn't work for me last night..
17:12 khall         Accounts Rewrite. It's been pretty much bullet proofed. I expect qa issues will involve internationalization
17:12 ashimema      #info hea.koha-community.org is coming :)
17:11 Joubu         hea is coming (see hea.koha-community.org)
17:11 ashimema      any more for any more?
17:11 ashimema      #topic Big Stuff we're working on?!
17:10 wahanui       next topic is a tricky one...
17:10 ashimema      next topic
17:10 Joubu         khall: yes, more or less :)
17:10 ashimema      :)
17:10 ashimema      #info Agreed that 'on-site' was a better wording than 'in-house'
17:09 khall         %s/In-House/On-Site/g
17:09 Joubu         I just don't want to do this massive change twice
17:09 Joubu         I am happy with what you want :)
17:09 ashimema      if so.. we'll move on :)
17:09 ashimema      you happy with 'on-site' Joubu?
17:09 ashimema      I felt 'local use' wasn't descriptive enough for some reason.. can't rmember why though
17:09 khall         my vote goes to 'on-site'
17:09 jcamins       ashimema: sorry!
17:08 ashimema      hehe.. jcamins don't stir ! ;)
17:08 nengard       that's another way people refer to it
17:08 nengard       local use?
17:08 jcamins       I'd vote for "in-house" except we're already using that for statistical purposes.
17:08 Joubu         ok thanks everybody :)
17:07 ashimema      We've got normal lending (off site), we've got statistical lending (were the librarian performs a check in to signify an anonymous has of I item on site) and finally there monitored reference only use (on site, but not anonymous).
17:07 atheia        +1 on-site
17:07 jcamins       This is a very common scenario in rare book libraries.
17:07 atheia        yeah, from what I understand on-site is better
17:07 khall         thd: I could see that happening. However, Koha no longer functions on Windows, so it should be a non-issue.
17:07 thd           khall: I think the issue I had with long parameters was forcing the same behaviour for shell scripts between bash MSDOS and Perl for parameters.
17:07 khall         this connects the use of the item to a patron, correct?
17:07 ashimema      that's about ti right, joubu
17:07 jcamins       +1 for on-site use
17:06 ashimema      Joubu's feature adds the ability to track specifc uses by patrons for say a monitored material that's not alloud to leave the library..
17:06 khall         I'm assuming it gives the ability to track the use of an item that can't be removed from the library
17:06 ashimema      We've already go statistical users for tracking when an item has been 'used' withn the library (i.e left out on a desk at the end of the day)..
17:06 Joubu         Why "inhouse use" is for anonymous use only?
17:05 barton        I'm still not clear what this feature does.
17:05 ashimema      haha.. funnily enough. that's what I ended up suggesting.
17:05 ashimema      The feature is for statistical tracking basically..
17:04 khall         how about "on-site only"
17:04 ashimema      So..
17:04 ashimema      did anyone come up with any alternatives ti 'In house use'
17:04 Joubu         ashimema: could you explain for me please? :)
17:04 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10860 enhancement, P5 - low, ---, jonathan.druart, Needs Signoff , In-House Use
17:04 ashimema      #topic Wording of bug 10860
17:03 thd           Recommended with the explanation of please avoid thrashing the user's system by surprise.
17:03 atheia        agreed.
17:03 khall         agreed.
17:03 ashimema      but.. shall we move onto the next topic ;)
17:03 ashimema      ok by me..
17:02 khall         we can just say it's a strong recommendation and best practice
17:02 ashimema      I don't think --test should be mandatory..
17:02 thd           khall:  I may have solved it the past but you will show me if I do not see that in my old code ;)
17:02 khall         what about —test ? are we not making a decision on that?
17:02 ashimema      anyone facny havig a punt at wording that for the guidlines and adding it?
17:02 indradg       +1 khall
17:02 khall         please add examples with the rules when possible to help new developers
17:02 ashimema      is that info comprehensive enough without blocking too much?
17:02 atheia        barton: indeed, subtle difference between thrash and drash :-)
17:01 khall         thd: it can be done
17:01 ashimema      #info Pod::Usage, GetOpt::Long, pod2usage, POD at end of file and --confirm (where lack of display help test)
17:01 khall         —test shouldn't be mandatory, as some scripts can't do dry runs
17:01 atheia        +1 for khall's statement.
17:01 thd           When I tried to write --something parameters in the past using GetOpt::Long I found that -s would have the same function.
17:01 barton        I'm with khall.
17:00 ashimema      #agreed To add requirement for new CLI scripts to guidlines
17:00 Joubu         yep
17:00 khall         not sure we've reached consensus, but I can accept —confirm and —test with the default being the help
17:00 ztajoli       also for me
17:00 atheia        fine by me.
16:59 ashimema      ok..  can i go for an agreed on.. we need guidlines for it.. and we agree on --confirm for all scripts.. and lack therof displays help
16:59 Joubu         (;))
16:59 Joubu         so we need to confirm the dry-run?
16:59 thd           khall: What about a script which reads your entire database and manipulates it without writing anything as thrashing dry run behaviour?
16:59 barton        atheia: I think that was thrash, not trash
16:59 atheia        makes sense.
16:59 atheia        :-)
16:59 atheia        ah interesting :)-
16:59 khall         lol
16:59 ashimema      jinx
16:58 ashimema      heavy db reading
16:58 khall         heavy db reading
16:58 atheia        What dry-run would trash a system? that's a crazy dry-run? or am I naive here?
16:58 ashimema      agreed khall
16:58 khall         they should be mutually exclusive
16:58 khall         ashimema: dry run should definitely not require confirm.
16:58 oleonard      atheia: You can also think of it as making scripts user-friendly, since the user doesn't have to be afraid to try running them
16:58 ashimema      I also agree to that thd.
16:57 thd           All of the scripts which I write do nothing but display usage information when invoked without parameters.
16:57 ashimema      i'm sort of edging toward.. no confirm always give help test.. and a dry run requires a -t (but not nessarily a --confirm)?
16:57 ashimema      very true.. hadn't thought of that case thd
16:57 atheia        But what we're saying here is that scripts are always dangerous, and that we don't trust the user by default.
16:56 thd           Dry runs of some possible scripts could thrash your system.
16:56 khall         are we just saying that we can't trust sysadmin's to use Koha's scripts correctly with this idea?
16:56 ashimema      how about.. if possible to dry run.. then without confirm we get dry run.. if not possible to dry run.. we return help
16:56 thd           I favour requiring a parameter even for dry runs.
16:56 atheia        Generally one might require confirmation for dangerous behaviour so there is some precedent in unixy tools.
16:56 atheia        I would like the behaviour to be dryrun but I think requiring it for cli scripts would be pretty difficult, just in terms of providing a 'dryrun mode' for existing and even new scripts.
16:55 thd           Does GetOpt::Long prevent a short form from doing something.  It had not in my past testing.
16:54 Joubu         ashimema: actually if the output is explicit, we don't care...
16:54 ashimema      but I don' think allo of our current scripts do dry runs at all ;)
16:54 barton        ... if '--confirm' (or perhaps --commit) were missing.
16:54 khall         is there any precedent for this behavior with other unix utils?
16:54 indradg       +1 for dry run
16:54 ashimema      I'm thinking without confirm it should dry run preferably..
16:54 barton        I would expect a dry-run without action.
16:53 khall         I do agree with barton's point
16:53 ashimema      i.e if missing.. dry run.. or if missing.. help
16:53 thd           Joubu: I merely identify a potential problem for bringing some new script into Koha adapted from another community.
16:53 ashimema      but not yet to it's action
16:53 Joubu         atheia: yes
16:53 ashimema      so we're now agreeing to a --confirm..
16:53 barton        I'm not so hot on the behavior -- it feels distinctly un-unixy.
16:53 ashimema      I see..
16:52 * oleonard    doesn't really care about the letter, just the behavior
16:52 Joubu         thd: it's like that for a lot of Koha scripts...
16:52 thd           I perfectly agree with requiring some confirmation
16:52 khall         how about —confirm
16:52 thd           Yes
16:52 oleonard      thd: So all you object to is the letter choice?
16:51 thd           Many scripts in the world use -c for other purposes.  FSF recommends -c for displaying copyright information.
16:51 atheia        So we are targetting this at someone who normally does not use cli commands, and who would simply expect information when running a command, rather than behaviour?
16:51 oleonard      thd: Do you have an example?
16:51 Joubu         thd: are you asking for scripts you are going to submit on bugzilla?
16:50 atheia        If we require -c to do something to the db we're saying it's a fail-safe against accidental use.
16:50 thd           It may be a good default but a strong requirement may complicate adapting and maintaining some existing script from outside Koha to Koha.
16:50 ashimema      go on
16:49 atheia        OK, so just running this through:
16:48 khall         thd: why?
16:48 thd           I object to requiring confirmation parameter to be -c.
16:48 Joubu         atheia: yes, I agree
16:48 khall         atheia: I think the tangible benefit is getting the help and not altering the db by accident
16:48 barton        I'm with atheia...
16:48 ashimema      hmm..
16:48 atheia        If you see what I'm saying?
16:48 atheia        But just showing help does not…
16:47 atheia        like running in dry-run makes sense
16:47 atheia        So I think there should be a tangible benefit in forcing the user to pass -c
16:47 khall         agreed, we should require -c, display help if no -c, and have -t for dry runs
16:47 thd           If default displays usage information you do not need to read the source code to determine the help parameter.
16:47 atheia        but surely if you invoke a script you expect it to do something - why else would you invoke it?
16:47 ashimema      but can't agree yet on the -c
16:47 ashimema      so we agree to needing some guidlines..
16:47 ztajoli       also I  would expect the script to show help information if the -c was not passed
16:46 oleonard      I would expect the script to show help information if the -c was not passed
16:46 thd           I like even requiring a parameter for test mode.
16:46 Joubu         khall: I set the verbose flag when -c is not given
16:46 khall         just a warning if lazy? ; )
16:46 Joubu         khall: yes
16:46 khall         dry run if possbile?
16:46 atheia        indeed :-)
16:46 atheia        What would happen if no -c parameter is passed?
16:46 khall         question: what will the standard behavior for not passing -c be?
16:45 thd           All the scripts which I write merely display usage information if run without parameters.
16:45 ztajoli       for me +1 on must have a confirmation parameter
16:45 barton        do we have any scripts that don't alter data?
16:44 khall         splitting everything out to a module is the best way to go, I can totally agree.
16:44 oleonard      Are there objections to requiring that new cli scripts must have a confirmation parameter?
16:44 khall         but now it has alot of duplicate code
16:43 ashimema      (it doesn't work with patron attrbiutes btw; ;) )
16:43 khall         I was told this is frowned upon, so I made it cli only
16:43 thd           I favour requiring a confirmation switch if running the script without parameters otherwise might do something bad or unexpected.
16:43 khall         it's good to go. I would like to just have the tools patron importer work from the command line, which is what my first addition of the patch did
16:43 ashimema      I felt your bringing the liblime patch up to date was more of a stop gap, whilst a proper refactoring of the imports stuff was done.. (i.e splitting out import into a module)
16:42 ashimema      are you doing much on the patron importer khall?
16:42 thd           I can see the advantage of consistency but adopting some script existing in the world may be a problem.
16:42 Joubu         ashimema: not all, but gmcharlt_ asked that when he was RM
16:42 ashimema      and if they do.. should they all have a 'dry run' mode
16:41 khall         I agree in general, but these rules will mean I probably will not continue development of my cli patron importer.
16:41 ashimema      do 'all' scripts need a confirmation?
16:41 ashimema      I also wonder about the -c..
16:41 ashimema      most seems sensible to me (and is how I've been writing recent scripts too).
16:41 thd           I am not certain about forcing -c as the confirmation parameter.
16:40 Joubu         - add the POD at the end of the file
16:40 Joubu         - call pod2usage if something wrong with the parameters
16:40 Joubu         - the -c parameter to confirm the changes
16:40 Joubu         - GetOpt::Long
16:40 Joubu         It uses: - Pod::Usage
16:40 Joubu         I propose misc/cronjobs/delete_patrons.pl as an example of the best pratices (I don't tell that because I am the author...).
16:40 Joubu         I thought some guidelines existed for Koha scripts, but actually they don't (or I don't find them, I did not search for a lot).
16:40 ashimema      yes please :)
16:40 ashimema      First:Are we happy with Joubu's suggestions?
16:40 Joubu         I can c/c the note I put on the trello:
16:39 ashimema      #topic Requirements for CLI scripts
16:39 thd           yes
16:38 * ashimema    wonders if he's started talking to himself?
16:37 ashimema      we ok to move on?
16:37 ashimema      #info exact wording of guidline to be decided (after looking up dbic specifics)
16:37 ashimema      #agreed To add a rule to the coding guidelines that mimicks that of the dbic conventions for column_names pending this evening meeting
16:37 khall         that would include the primary key being 'id' and any foreign keys being the table name, rather than the primary key name
16:36 khall         I think the rule should just be 'follow dbic conventions' and list the important parts ( underscores, plurality, etc )
16:35 khall         yes
16:35 Joubu         an url could be useful
16:35 ashimema      khall you ok to add a rule to the guidlines?
16:34 ashimema      either way.. I think the dbic convenstions are sensible and it would be nice to tie it down to them..
16:34 oleonard      +1
16:34 ashimema      plural form is a dbic convention too is it not?
16:34 Joubu         But +1 to follow DBIC conventions
16:34 Joubu         not sure about the plural form.
16:34 khall         koha_widgets rather than koha_widget
16:33 ztajoli       +1
16:33 ztajoli       aslo for me makes sense to go forward being dbic compliant
16:33 atheia        +1
16:33 ashimema      +1
16:33 ashimema      makes sense to go forward being dbic compliant
16:33 barton        +1
16:33 khall         and should be plural
16:33 ashimema      I'm happy to go with that.. does everyone agree?
16:32 ashimema      #info column_names made up of multiple words should be joined with underscore to maintain dbic standards
16:31 khall         I'll try to locate a document that specifies them, if there is one
16:31 ashimema      or, whilst you come up with some wording.. can we agree to column_name as convenstions?
16:31 khall         we should follow standard dbic naming conventions
16:31 khall         tables should be named as plurals with each word separated by underscores
16:30 ashimema      did you do some wording for a new guidline?
16:30 khall         yep
16:30 Joubu         It's a request from khall
16:30 ashimema      khall.. I think this one was one of your suggestions.
16:29 ashimema      sorry, had to catch up in the agenda
16:29 ashimema      #topic Naming of database columns
16:29 wahanui       next topic is a tricky one...
16:29 barton        next topic?
16:28 tcohen        bbl, thanks everyone
16:28 ashimema      ok.. so moving on.
16:28 huginn        Current chairs: ashimema tcohen
16:28 tcohen        #chair ashimema
16:28 tcohen        need to run, ashimema will continue to chair
16:27 tcohen        #cochair ashimema
16:26 tcohen        of course :-d
16:26 ashimema      and a coding guideline for it ;)
16:26 tcohen        #action Kyle will start a discussion on the koha-dev list on taking advantage of DBIc in our code base. We will discuss where to use DBIc, and how to properly test our ResultSet classes
16:25 tcohen        including how to properly test our ResultSet classes?
16:24 khall         tcohen: sure!
16:24 khall         module subs should only be needed when evaluation across tables is required
16:24 tcohen        khall: can you post an email to the list with your POV
16:24 khall         we don't need a sub in a perl module, we can have a method in the ResultSet, which would be unit testable
16:24 tcohen        khall: we will soon :-D
16:24 khall         we really aren't taking advantage of the power of dbic at the moment
16:23 ztajoli       also for me ok for a discussion on the list
16:23 Joubu         tcohen: ok for a discussion on the list
16:23 khall         anything complicated we can have as a canned method for the resultset
16:23 Joubu         khall: if you need the same result somewhere else, you will have to c/c your code
16:22 khall         anything where the search criteria isn't determined at run-time
16:21 Joubu         khall: how to you defined "simple" searches?
16:21 tcohen        can we discuss this on the list? so we have broader opinions and maybe reach some consensus?
16:21 Joubu         yes, read too fast, sorry
16:21 Joubu         khall: ok last link is not relevant :)
16:20 khall         I don't think that is a good and applicable example Joubu
16:20 tcohen        thd: :-D
16:20 huginn        04Bug 12891: critical, P5 - low, ---, koha-bugs, Signed Off , NewOrder does not return ordernumber
16:19 thd           tcohen: You might exercise your authority as RM during your term, however, further discussion towards some consensus would be helpful.
16:19 Joubu         We have to have an unit test for this regression
16:19 Joubu         critical bug found yesterday
16:19 Joubu         khall: simple example: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12891
16:19 tcohen        khall: I think CRUD operations are ok
16:18 Joubu         khall: why it's equivalent? If you call create something in the pl script, you want to test it
16:18 khall         otherwise we are just jumping through hoops that don't need to be there
16:18 khall         tcohen: I think there is a line to walk here. I think using find and simple searches should be allowable in pl files
16:18 ashimema      khall.. where do you see the line being drawn?
16:17 Joubu         tcohen: not really fair to vote. :)
16:17 khall         using DBIC in pl scripts should be equivilent to using pm subs in pl scripts
16:17 tcohen        ah, we don't yet agree heh
16:17 tcohen        or do we all agree (at least) that no db call should be done on the .pl scripts? (it includes DBIC)
16:17 ashimema      so assuming we went to allowing dbic in scripts.. would we impose limits upon what it can be used for?
16:17 tcohen        ok, should we vote?
16:16 khall         tcohen: agreed, the logic should not be in pl scripts
16:16 khall         that would still apply, the code would only move to Koha/Schema/Result and Koha/Schema/ResultSet
16:16 tcohen        business logic should be removed from the .pl scripts
16:16 ashimema      the line between what belongs in a module and what belongs in a script becomes rather fuzzy if we allow this?
16:15 ashimema      but we currently only demand unit tests on modules.. not scripts..
16:15 khall         agreed, it can still be unit tested
16:15 Joubu         the logic should be tested :)
16:14 khall         Joubu: I would disagree. I think we should move in the long run to reducing the number of modules and moving logic into DBIC
16:14 ashimema      I kinda agree with Joubu.. I feel the need for database lookups in pl scripts highlights a flaw in the .pm
16:14 Joubu         tcohen: in pm script... In pm module
16:14 Joubu         I think DBIC should only be used in pm script. For the maintainability, for UT and for reusability
16:14 tcohen        meaning? there is no agreement on either?
16:13 Joubu         And nobody agrees
16:13 Joubu         I think this has already been discussed :)
16:13 wahanui       opinions are slightly divded :)
16:13 tcohen        opinions?
16:12 tcohen        next one: should we use DBIC on .pl scripts?
16:11 tcohen        #agreed (subject to votes from part 2) https://trello.com/c/8d7pELLj/28-coding-guidelines-koha-preference will be added to Coding guidelines
16:10 atheia        OK. I think I'm fine either way then :-)
16:10 ashimema      atheia.. basically yes ;)
16:10 atheia        is it purely conciseness?
16:10 thd           When is HTML 7 coming :) ?
16:10 atheia        ?
16:10 atheia        out of curiosity, what is the reason for not passing in the variable in pl
16:10 tcohen        ?
16:10 tcohen        Koha.Preference usage mandatory then
16:09 tcohen        ok, objections?
16:09 ashimema      agree
16:09 khall         yep and agreed
16:08 pastebot      "tcohen" at 172.16.248.212 pasted "Proposed text fro Koha.Preference usage on TT" (3 lines) at http://paste.koha-community.org/197
16:08 Joubu         tcohen: yes I think so, the board is public
16:07 tcohen        can everyone view that link?
16:07 tcohen        so TT plugins are used for fetching preferences instead of passing them from .pl
16:07 Joubu         https://trello.com/c/8d7pELLj/28-coding-guidelines-koha-preference
16:07 tcohen        there is a proposal from dcook to amend the coding guidelines
16:06 tcohen        #topic Additions to Coding Guidelines
16:06 tcohen        we need to move ahead
16:05 tcohen        he will (hopefully) be on part 2
16:05 ashimema      worth poking rangi too for Class::Accessor advice ;)
16:04 tcohen        #info Jonathan needs feedback on bugs 12830 and 12896. Specifically his approach to Class::Accessor and DBIc
16:04 Joubu         khall: maybe? :)
16:03 Joubu         I would like to base the code on these 2 new modules for the rest of the rewrite.
16:03 Joubu         12830 and 12896 (submited today). A (new) try with Class:Accessor and DbIC
16:02 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12830 enhancement, P5 - low, ---, jonathan.druart, Patch doesn't apply , Move the order-related code into its own module
16:02 tcohen        another one that needs feedback Bug 12830
16:02 tcohen        moving on then
16:02 tcohen        thanks thd
16:02 thd           tcohen: I will try to add appropriate comment and link to some discussions of the issue in free software accountancy programs.
16:01 tcohen        heh
16:01 ashimema      Joubu.. I'll take a look at those bugs.. but I'm currently working through qa on the UTF8 bug and QA on an emails bug.. they're tkaing allot of me qa time at the minute.
16:01 Joubu         thd: yes, please
16:01 Joubu         I am not aware of these rules.
16:01 tcohen        thd, Joubu: please include those aspects of the problem on the RFC
15:59 thd           Joubu: That is the problem that correct might even vary by the accountancy rules in a particular jurisdiction and defies programmer centric rules about significant figures etc.
15:59 tcohen        ztajoli: we will be discussing that on the next topics
15:58 ztajoli       For name of DB coloums we prefer the "long_name" policy
15:58 tcohen        can everyone interested give Joubu feedback on the RFC?
15:58 Joubu         thd: You can share on the wiki page what is a correct rounding management, if you like.
15:57 ztajoli       for us the refactory line on Joubu is OK.
15:57 thd           Joubu: The same issues have been raised with free software accounting software without resolving the issue.
15:56 tcohen        #info feedback is needed urgently
15:56 thd           Joubu: I know that the issue has been raised in the RFC.
15:56 tcohen        #link GST rewrite http://wiki.koha-community.org/wiki/GST_Rewrite_RFC
15:56 ztajoli       As Cineca we have many attention on ACQ. We are starting to test the present patch as are on 'Need Sign off' status
15:56 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12826 enhancement, P5 - low, ---, jonathan.druart, ASSIGNED , GST / VAT rewrite - plumbing
15:56 Joubu         then bug 12826
15:56 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12825 enhancement, P5 - low, ---, jonathan.druart, ASSIGNED , GST / VAT rewrite
15:56 Joubu         then bug 12825
15:55 Joubu         ashimema: the entry point is the wiki page :)
15:55 Joubu         thd: you can give feedback on the RFC if you want. Some of these questions have already been discuted
15:55 ashimema      what he said
15:55 ashimema      whats the bug number again?
15:54 tcohen        can u add links to those small-step patches/bugs?
15:54 thd           Refactoring may be essential to resolving the problem that every free software accounting program does rounding incorrectly from an accounting perspective.
15:54 Joubu         But I cannot continue without getting a consensus on the patches I already submited.
15:54 Joubu         I am trying to add as many UT as I can
15:54 ashimema      so far so good Joubu..
15:53 ashimema      agreed.. refactoring is certainly super sensible.
15:53 oleonard      Native speakers who understand acquisitions :P
15:53 tcohen        i think refactoring that code is a valuable task, we need to support Joubu's effort
15:53 thd           Joubu: Do you know if the code supports tax rates which are more granular than the smallest unit of the currency?
15:53 Joubu         need native speakers here
15:53 Joubu         Some wording should be decide too. How the DB columns should be named? What about the rrp term? Is there a better appropriated term?
15:52 Joubu         I still plan to add the column configuration stuff to the acquisition tables (invoices, basket, etc.). But this will be one of the  last steps.
15:52 Joubu         When the code will be refactored, it will be easy to change the way prices are calculated.
15:52 Joubu         How I see the next steps: I will try to provide as many small changes as I can without any behavior changes.
15:51 Joubu         That's why I am a little bit stuck, I cannot continue to develop other parts if the method I used is not validated by the developer team.
15:51 Joubu         I really think this plumbing part is inevitable for the future of the  Acquisition module and to add a correct vat management.
15:51 Joubu         I propose to explode the Acquisition module into small module under the  Koha namespace. I will add missing unit tests and use DBIC when  possible.
15:50 Joubu         I started to submit some patches last week (and today), I would like to get feedback on patches I already submitted.
15:50 Joubu         ok, so the entry point is the wiki page (http://wiki.koha-community.org/wiki/GST_Rewrite_RFC).
15:50 tcohen        please, explain
15:50 Joubu         tcohen: Can I explain a liittle or you just list them?
15:49 tcohen        :/
15:49 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10273 normal, P5 - low, ---, jonathan.druart, ASSIGNED , Unit tests should not be dependent on the Jenkins database
15:49 tcohen        - Bug 10273 GST/VAT/Tax rewrite - Needs more feedback!
15:49 tcohen        #subtopic bugs that need feedback
15:49 tcohen        ok
15:49 tcohen        #info we are voting the inclusion of TestBuilder next meeting
15:48 tcohen        ok, moving on for now
15:48 tcohen        and also hear the folks from part 2
15:47 tcohen        i pretended that we discussed the basis for the decision today
15:47 ashimema      next topic then :)
15:47 tcohen        not sure how to deal with that
15:47 ashimema      I missed that.. sos
15:47 tcohen        ashimema: i moved Testbuilder specific discussion to next meeting yesterday
15:46 barton        +1
15:46 ashimema      anywho.. lets either move on or vote ;)
15:46 barton        yeah, that's where I was going with that.
15:46 ashimema      see.. I would like TestBuilder at some point to morph into a 'got db, test agianst it, not got db.. mock it' module
15:45 tcohen        that's what i was saying about infinite time
15:45 tcohen        yeah
15:45 ashimema      but that measn writing both ;)
15:45 tcohen        barton: we need both, I agree
15:45 ashimema      indeed..
15:45 barton        if you have a db_dependant test that passes, and a db_independant that doesn't, that could be useful information...
15:44 tcohen        i think we could push TestBuilder, butI'm confident I'll continue to write mocked tests
15:44 Joubu         quite empty...
15:44 ashimema      and in fact.. there's a lib for it too t/lib/Mocks
15:44 tcohen        :-D
15:44 tcohen        ashimema: mocking is pretty straightforward
15:44 ashimema      mocking context is actually pretty straight forward..
15:43 tcohen        i think it was gmcharlt_that said we could separate context-dependent vs. non-context-dependent
15:43 ashimema      My last questions regarding testbuilder can go on off meeting.. (there are to do with that dbic followup)
15:42 ashimema      we aught to more clearly define when you should write a 'db_dependant unit test', a 'db_independant unit test', a 'integration test'
15:42 Joubu         but easily to write, so more unit tests :)
15:42 Joubu         I don't think so
15:42 tcohen        my only concern is technical debt
15:42 tcohen        so, in the short term, I'd agree we can have *better* tests using testBuilder
15:41 tcohen        at the same time
15:41 tcohen        and also have some integration tests
15:41 Joubu         tcohen: some tests are unit tests, others are integration tests
15:41 ashimema      we're certainly mixing unit tests with integration tests..
15:41 tcohen        but I see TestBuilder as a shortcut to something "closer" to unit testing
15:41 tcohen        i don't think we are doing unit testing either
15:40 tcohen        i'm not sure about the approach to unit testing
15:40 tcohen        sorry, i was called by te boss
15:40 wahanui       tcohen is, like, obsessed with automated testing :)
15:40 ashimema      tcohen?
15:40 ztajoli       In my opinion yes
15:39 Joubu         great, moving on?
15:38 ashimema      it's bascially passed qa now.. I just felt this discussion was needed
15:38 ashimema      either way.. can we agree on TestBuilder being pushed or not?
15:38 ztajoli       attention on use modules from CPAN, only if mandatry for same feature/fix
15:38 Joubu         ashimema: not sure, because we will certainly introduce some Koha specific stuff (the db structure is sometime not good, fk cannot be follow to create data).
15:37 ztajoli       as is in debian stable better
15:37 clrh          (ok thanks)
15:37 ashimema      clrh.. any other comments outside Joubu and My ramblings (conversation)
15:37 ashimema      but I tihnk for speeds sake we're probably best pushing TestBuilder as is?
15:36 clrh          what does mean chip back in ashimema ?
15:36 ashimema      Long term.. i'de prefer we added the functionality to the cpan module mentioned as an alternative in the bug..
15:36 ashimema      anyone else care to chip back in?
15:35 Joubu         they are created automatically with random data
15:35 ashimema      exactly..
15:35 Joubu         no need to create biblio, budget, etc.
15:35 Joubu         oops
15:35 Joubu         +my $order1 = $builder->build({ +    source  => 'Aqorder', +    value   => { +        datecancellationprinted => undef, +    }, +    only_fk => 1, +}); +C4::Acquisition::NewOrder($order1);
15:35 ashimema      not s/fake/random in that last case.. you should still be able to add some specific data to a specific field.. so you can test for fringe case that are only caught with such data..
15:35 Joubu         example: http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30090
15:34 Joubu         yes
15:34 Joubu         s/fake/random
15:34 ashimema      is that all correct Joubu?
15:34 ashimema      it's just about ensuring you meet all foreign key constraints when attempting to add fake data for testing..
15:33 ashimema      so it's not about randomising everything..
15:33 ashimema      So.. the point of testbuilder from my understanding is so you can put some specifics in your database to check against (and test builder will take care to add all random foreign keys for you)..
15:33 Joubu         I think we should give TestBuilder a try. We can remove it later if we find a better solution.
15:33 ashimema      They fail due to the test assuming stuff about the data already in said database.. like default category codes for example..
15:32 ashimema      We have a bunch of tests that will fail if run against a database other than the one that resides on the jenkins server.. I think that wrong personally.
15:31 ashimema      It's not random data so much, as adding foreign keys for you.
15:31 tcohen        thd: TestBuilder is supposed to (for example) create a branch (taking care of all needs to be set for that) and then you use the created branch
15:30 thd           s/past/patch/
15:30 thd           ashimema: What do you do with random data which does not trigger the behaviour against which the past needs to be tested?
15:29 ashimema      and we come round to TestBuilder..
15:29 bag           heya tcohen
15:29 tcohen        hi bag
15:29 Joubu         ashimema: so, the next question: "how?" :)
15:29 bag           #info Brendan Gallagher ByWater
15:29 bag           morning (sorry to be late
15:29 ashimema      so we agree that instead of 'To mock or not to Mock' the question is 'Should be be data agnostic' and the answer to that is obviosly yes.
15:29 tcohen        thd: patch testing
15:28 clrh          me ;)
15:28 Joubu         Who has already took a look??
15:28 thd           tcohen: Is this question concerning building or patch testing?
15:28 ashimema      So.. I'm happy to say that db_dependant have their place..
15:28 Joubu         Yohann proposed a way to generate random data, to be data agnostic, (see TestBuilder).
15:27 ashimema      Joubu++
15:27 tcohen        ashimema: algorithmically mocking a package's API is harder than checking foreign key constrains, i guess
15:27 thd           s/Refreshing/Dropping and starting again/
15:27 Joubu         Maybe the question is "what is the next step?", not "what could be the ideal situation?"
15:27 thd           tcohen: Refreshing would be required then but that would add to the overhead.
15:26 * ashimema    is playing devils advocate..
15:26 tcohen        thd: a test might be writing data that is making the next test to pass, just because the data is there
15:25 thd           tcohen: What side effects would you have in a Db which would be missed there but caught by mocking?
15:25 ashimema      In which case.. do we need a TestBuilder like module that mocks instead of pushing random data to the database?
15:25 tcohen        and probably leave db-dependent tests to jenkins or smth like that
15:25 ztajoli       I think that our standard db_dependant test could be: 1)insert data in sql server 2)test 3)drop data
15:24 tcohen        and mocked
15:24 tcohen        our tests should be organized in a way they could be run randomly
15:24 tcohen        the thing is using the DB might prevent us from detecting side effects
15:24 thd           Is this question concerning building or patch testing?
15:24 ashimema      that's my point of question
15:24 ashimema      so.. in the packages case.. it needs to be completely mocked.. not just data agnostic if we want it to get tested..
15:23 tcohen        ashimema: during packages build, we run non db-dependent tests
15:22 jcamins       ashimema: because when building a package there's no database available.
15:22 ztajoli       clearly you need an sql working
15:22 ashimema      (that's a question for the package builders out there.. currently I know packages build without running ANY db_dependant tests.. the question is why?)
15:22 ztajoli       all data to test inside the test
15:22 thd           Testing some behaviour requires data which will elicit the behaviour.
15:22 atheia        So I'd rather go with mock than not to mock for unit tests :-)
15:22 ashimema      do we ever need to test without a sql server on the system at all?
15:22 atheia        Definitely being data agnostic would be good. The tests that I wrote using mock were a little painful, but I'm not sure how else I would have tested.
15:21 ztajoli       data agnostic is good goal
15:21 thd           You cannot always have a good test which is really data agnostic.
15:21 ashimema      data agnostic is fine.. so long as you have a sql server running to push randomised data to..
15:21 ztajoli       I have the same opinion of tcohen.
15:20 ashimema      I suppose they're two questions then..
15:20 tcohen        yes
15:20 Joubu         It's not a problem not to mock. I think the main problem is to be data agnostic, isn't it?
15:19 tcohen        the problem is we don't have infinite time to do it
15:19 ashimema      What are people thoughts generally.. I'm with tcohen and beleive if possible we should mock.. using db is as a last resort in my mind.
15:19 tcohen        and integration tests should be written for using the DB
15:19 tcohen        as i wrote on trello, I think unit tests should be fully mocked
15:18 * ashimema    couldn't resist
15:18 Joubu         discussion already started on trello: https://trello.com/c/vsrkdpvv/27-tests-mocking-when-to-and-when-not-to-that-is-the-question
15:18 ashimema      that is the question...
15:17 tcohen        heh
15:17 tcohen        #subtopic To mock or not to mock...?
15:17 tcohen        This discussion might as well take place on the list
15:17 tcohen        #topic General technical discussion
15:17 tcohen        but here we go
15:17 ashimema      Certainly there are enhancements to come.. but this is certainly an awesome start!
15:17 tcohen        we didn't know how to call it
15:16 wahanui       next topic is a tricky one...
15:16 tcohen        ok, next topic
15:16 tcohen        people that tested it already proposed future enhancements
15:16 atheia        #info Alex Sassmannshausen, PTFS Europe, UK
15:15 barton        #info Barton Chittenden, ByWater Solutions, Louisville, KY, USA
15:15 tcohen        UNIMARC is better as an example
15:15 thd           Great tcohen++
15:15 tcohen        thd: https://github.com/tomascohen/koha/commit/281808cce6cc94e26beb6281ec44daada0a85595
15:15 thd           yes I just saw the good part of the code
15:15 Joubu         tcohen: it's worth some beers, definitely ;)
15:15 thd           ah no
15:15 tcohen        thd: no
15:14 thd           tcohen: Is this still bound to subfield a?
15:14 ashimema      deffo
15:14 tcohen        ok, next
15:14 tcohen        :-P
15:14 tcohen        then drink some beers
15:14 tcohen        ashimema: we need to first see how it develops
15:13 ashimema      fantastic work there tcohen
15:13 tcohen        ^^^^^ there you can see the syntax
15:13 tcohen        https://github.com/tomascohen/koha/commit/5b0b36895bad75052e8a0e362e561a8631f103f2
15:13 nengard       #info Nicole Engard, ByWater Solutions
15:13 tcohen        i have added a new syntax for facets specification
15:12 tcohen        #info facets from zebra is needs sign off, bug 11232
15:12 ashimema      #info Martin Renvoize, PTFS Europe
15:12 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232 new feature, P5 - low, ---, gmcharlt, Needs Signoff , Retrieve facets from Zebra
15:12 wahanui       i heard bug 11232 was relevant in the medium term, as one of the side effects of using Zebra to calculate facets will be to make library facets both more correct as well as easier to tweak
15:12 Joubu         bug 11232
15:12 khall         #info Kyle M Hall, ByWater Solutions
15:12 tcohen        thd, was looking for it
15:12 thd           ?
15:12 thd           tcohen: what is the bug number for that
15:11 ztajoli       #info Zeno Tajoli, Cineca (Italy)ù
15:11 Joubu         good job tcohen :)
15:10 tcohen        #info facet retrieval from Zebra is complete, feedback is needed
15:10 tcohen        #topic RM 3.18 comments
15:10 tcohen        ok, moving on
15:09 Joubu         #info Jonathan Druart, BibLibre
15:08 thd           #info Thomas Dukleth, Agogme, New York City
15:08 clrh          #info Claire Hernandez, developments manager at BibLibre
15:08 tcohen        #info Tomas Cohen Arazi, Universidad Nacional de Cordoba
15:08 tcohen        please introduce yourselves using #info name
15:08 oleonard      #info Owen Leonard, Athens County Public Libraries
15:08 wahanui       #info wahanui, a bot that has become sentient
15:08 tcohen        #topic Introductions
15:07 huginn        The meeting name has been set to 'koha_developer_irc_meeting__9_september_2014___part_1'
15:07 huginn        Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:07 huginn        Meeting started Tue Sep  9 15:07:58 2014 UTC.  The chair is tcohen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07 tcohen        #startmeeting Koha Developer IRC meeting, 9 September 2014 - part 1
15:03 tcohen        will grab a coffee and will be back in a couple minutes
15:03 tcohen        ztajoli: yes
15:03 ztajoli       http://wiki.koha-community.org/wiki/Development_IRC_meeting,_9_September_2014
15:02 ztajoli       dev meeting ?
15:02 reiveune      bye
15:01 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12891 critical, P5 - low, ---, koha-bugs, Signed Off , NewOrder does not return ordernumber
15:01 Joubu         new critical bug in the qa queue, see bug 12891
15:01 ztajoli       hi
14:26 mveron        bye #koha
14:26 * mveron      has to head away
14:16 cait          bye all
14:00 tcohen        hi francharb
14:00 francharb     Hello all!
13:54 huginn        New commit(s) kohagit: Bug 12587: (qa followup) report name consistency <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=8af38d518fe4d3ef9a467b8db15a066c8ef48f9d> / Bug 12587 - Improve output of filter information on patrons with the most checkouts... <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=bfb20c9a7e6cfae9fd841a2be5d63d3337b8ddd8> / Bug 12849 - fix URLs in sent lists <http://git.koha-community.org/gitweb/
13:16 mveron        hi drojf :-)
13:15 cait          hey! how was your exam drojf?
13:14 tcohen        (which I have preserved to make it easier to transition)
13:14 tcohen        i've just changed the code that feeds the data structure
13:14 cait          i had a library asking how it worked now and didn'T want to tell them somethig wrong :)
13:14 cait          cool
13:14 cait          ok, so alphabetically, up to 5, then the more link
13:14 tcohen        the code that does the sorting, i havent touched it yet
13:14 tcohen        i'd say that should be an enh, after the patch is pushed
13:14 cait          i think with a bigger result set being looked at, the list could get quite long and the first alphabetic rsults might not be so helpful
13:13 cait          is that something that is going to change with the new facets? or just something we can think about later?
13:13 cait          so not sorted by number of occurences... should have seen that the first time i looked at it
13:13 cait          it seems they appear alphabetically?
13:12 tcohen        yes
13:12 cait          for some of the facets
13:12 cait          i think we show the more link after x facets
13:12 cait          ok, i will try to be fast
13:12 cait          oh
13:12 tcohen        (meeting)
13:12 tcohen        have 4 spare minutes
13:11 tcohen        i can
13:11 cait          tcohen: can you answer a few questions about facetting maybe?
13:10 mveron        :-)
13:10 cait          mveron: crossing fingers... i don't like it either
13:09 * mveron      does not like to go to the dentist
13:09 mveron        On even days we indentation is prohibited...
13:08 cait          aaaah right.
13:08 oleonard      cait: That's only on odd-numbered days
13:07 cait          oleonard: i thought it was tab space tab space tab?
13:06 oleonard      Oh sorry, yes you missed it ashimema we agreed on using 5 tabs for indentation from now on.
13:05 cait          druthb: :)
13:05 ashimema      i didn't miss it then ;)
13:05 ashimema      cool.
13:05 oleonard      Just under two hours from now isn't it?
13:04 ashimema      remind me.. what time is the meeting again?
13:03 nengard       that's fine with me
13:03 oleonard      nengard: Any opinion on the idea of replacing "Checked" with "Verified" in suggestions management?
13:02 oleonard      ...and it doesn't look to me at first glance like we are doing that in the staff client template anyway
13:01 druthb        A nice comfy wingback, the best place in the house to snuggle up and read a book.
13:01 oleonard      Regarding the potential difficulty of replacing "checked" in suggestions: Any place where we are displaying the value "checked" directly from the database should be replaced for i18n purposes anyway.
13:01 * druthb      thinks
13:00 druthb        Hm.
13:00 cait          druthb: what about me?
13:00 talljoy       hiya magnuse
12:58 NateC         hiya magnuse!
12:58 * magnuse     waves at talljoy and NateC, before wandering off
12:55 magnuse       :-)
12:55 * druthb      would be that strange overstuffed love seat with a bizarre floral print, that no one sits on because it's got lumpy stuffing, and is obscenely uncomfortable.
12:53 druthb        magnuse would be a great big chair, tall and big like the Iron Throne, but more comfy.
12:53 cait          oh
12:53 magnuse       oh noes
12:53 * magnuse     will miss every meeting on the current schedule - it's either kiddotime or sleeptime
12:52 cait          you will be the first! :)
12:52 cait          hmpf
12:52 magnuse       oops, cait has found the secret spell that turns people into chairs!
12:51 cait          i will see who is there and make someone chair maybe :)
12:51 cait          part 2 is really really late here, but i can try
12:51 * druthb      hugs cait, since she took the blame.
12:50 tcohen        cait: i'll probably miss part 2
12:50 cait          what why me?
12:50 cait          oh preselect is also nice
12:50 * druthb      blames cait
12:50 mveron        Preselect for z39.50 admin?
12:50 cait          verified sounds nice
12:49 mveron        :-)
12:49 wahanui       agree is not the best approach
12:49 mveron        Agree...
12:48 wahanui       mveron?
12:48 mveron        wahanui?
12:48 * mveron      agrees again...
12:48 oleonard      "verified" would work well in that context.
12:48 oleonard      The Decider!
12:47 nengard       big libraries have multiple people in the acq department. So first someone 'checks' the suggestion and edits it to make it right (isbn, title, author) and then passes is to the official decider and then that person marks it accepted or rejected
12:47 cait          :)
12:46 nengard       I know what it's for!!
12:46 cait          all the other status have a meaning in the workflow or generate an email, but checked not i think
12:46 cait          oleonard: i always train it as 'use it as you want, it has no feature i know of linked to it'
12:46 oleonard      I don't even know what the suggestions "checked" status is for.
12:45 cait          so it doesn't appear at all on the form
12:45 wahanui       i heard agree was not the best approach
12:45 mveron        cait: agree...
12:45 cait          i wonder if people will think it's to turn on/off the search option totally
12:45 oleonard      Enabled is good, for Z39.50 admin.
12:44 gerundio      cait, oleonard: enabled?
12:44 oleonard      I'm also inclined to change the suggestions terminology because "checked" is not very clear in English.
12:44 mveron        oleonard: I had a look at the suggestions, it is much more complicated to change it there. Authorized values involved.
12:44 cait          oleonard: and it appears in a lot of places
12:43 tcohen        hi
12:43 cait          morning tcohen
12:43 cait          oleonard: checked is one of the database status for suggestions, not sure if it wuld be confusing to change it
12:43 tcohen        morning
12:42 oleonard      I'll ask the same question as I asked yesterday about another ambiguity bug: Isn't it necessary to change only one of the two instances? Can't we resolve this by changing the suggestions template and leaving the Z39.50 one alone?
12:42 cait          and while we are talking... could we differentiate term too? we ran into this a few days ago - term (like a search term) and term (like a time span in course reserves) - it's pretty confusing
12:39 cait          select all / unselect
12:39 cait          maybe selected? we use that for the checkboxes in tables
12:39 cait          oleonard: not sure about active - might appear in other context.... wonderng if there can be different translations, although i can't think of one right now
12:38 oleonard      I could also see using "Active" as the table header and "Active (searched by default)" in the add/edit form
12:34 oleonard      I think "Searched by default" is good for the label on the add/edit form. I'm not sure about the table column header.
12:33 druthb        Whut y'all need, now?
12:32 oleonard      We could ask druthb but she only speaks Texan now.
12:31 * oleonard    investigates
12:30 * magnuse     looks at oleonard too
12:30 cait          oleonard: we are looking in your direction... well I am :)
12:28 mveron        speakers
12:28 mveron        Hi cait :-)
12:27 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12882 trivial, P5 - low, ---, veron, Signed Off , Translations: Resolve ambiguity for word "checked" in Z39.50 server administration
12:27 * mveron      would like to have a comment of native and non-nativespekers on Bug 12882  (Wording)
12:27 * cait        waves
12:27 mveron        Hi oleonard and everyone :-)
12:26 oleonard      Hi mveron and everyone
12:25 mveron        Hi #koha
10:57 Joubu         gerundio: I agree with your answer, my solution is not the right one.
10:39 gerundio      have you given any thought about my reply to the solution you proposed?
10:19 Joubu         no
10:18 gerundio      Joubu, have you discussed any alternative solutions?
10:15 Joubu         gerundio: it could worth to provide unit tests too.
10:13 Joubu         I would like to get another QA pov, I am not sure the patch you submited is the best way to fix the issue.
10:13 Joubu         gerundio: Katrin and me told about this patch this morning.
10:13 gerundio      that might explain it
10:12 gerundio      its a minor bug with a trivial patch
10:12 huginn        04Bug 12669: major, P5 - low, ---, rolando.isidoro, Signed Off , "Template process failed: undef error - Invalid local time for date in time zone"
10:12 gerundio      http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12669
10:11 Joubu         gerundio: What bugs are you waiting for?
10:04 cait          also something lots of people are interested inmight go faster a feature that not many people are aware how to use
10:03 cait          a easy bug fix will make it faster than a big rewrite
10:03 cait          it depends on a lot of factors
10:03 cait          there is no rule there really
09:59 gerundio      any idea on what's the expected time between bug sign off and QA testing?
09:58 gerundio      hi, good morning
08:51 magnuse       hiya ztajoli
08:32 cait          I won't make it :(
08:32 cait          maybe if there is time left at today's meeting you coudl mention it?
08:31 Joubu         cait: yes, I need more time to know exactly how to fix that. But it's worth someone else has a look.
08:26 cait          Joubu: maybe there exists a best practice or something? I cannot say i fully understand it, although I looked at the page linked
08:24 atheia        (prbly not dbic stuff though)
08:24 Joubu         cait: I'm not sure it's the right way to fix the issue. And the issue is not fixed everywhere (but could be a first step)
08:24 atheia        Thanks for your comments on the previous issue patch cait++. I will hopefully get some time soon to finish off those changes.
08:23 atheia        oh — belated hello, magnuse, cait.
08:23 cait          it's a bit confusing
08:22 cait          makes sense
08:22 Joubu         cait: I would like to get another qa pov for this one
08:20 cait          Joubu: I did a bit of QA yesterday and was looking at the major bugs in the list - do you think 12669 could be QA'd with the explanation from Rolando?
08:16 huginn        magnuse: The current temperature in Realtor, CABRIES, France is 24.2°C (10:11 AM CEST on September 09, 2014). Conditions: Partly Cloudy. Humidity: 71%. Dew Point: 18.0°C. Pressure: 30.03 in 1017 hPa (Rising).
08:16 magnuse       @wunder marseille
08:16 huginn        magnuse: The current temperature in Bodo, Norway is 14.0°C (9:50 AM CEST on September 09, 2014). Conditions: Mostly Cloudy. Humidity: 88%. Dew Point: 12.0°C. Pressure: 29.80 in 1009 hPa (Steady).
08:16 magnuse       @wunder boo
08:16 magnuse       bonjour Joubu
08:14 cait          hi Joubu
08:12 Joubu         hi #koha
07:56 * cait        waves at atheia
07:54 magnuse       hiya atheia
07:46 dcook         cheers :)
07:31 cait          bye dcook
07:27 magnuse       have fun dcook
07:26 ashimema      have a nice evening dcook
07:25 dcook         Ok, dcook, leave work
07:25 dcook         Handy in some cases of course, but dang
07:25 dcook         Another reason why hierarchies suck
07:24 dcook         Or yeah... if elements cross reference each other as parents
07:24 ashimema      yup
07:24 dcook         If there are no elements without a parent
07:24 dcook         I suppose you could accidentally wind up in an infinite loop
07:24 dcook         foreach element without a parent - find the elements with this element as its parent, foreach of these elements - find the element with this element as its parent, foreach of these elements...
07:23 ashimema      They do.. thouhg I can't find the code for that anywhere either
07:22 dcook         Do they ever see the full hierarchy?
07:22 ashimema      maybe I should just arbitrarily cap the number of downward hops a user can make.
07:22 dcook         Then iterate downward from there?
07:22 dcook         Couldn't you do a select on all elements without a parent
07:21 dcook         Hmm
07:21 ashimema      I can see i'm going to end up with loops inside of loops to an arbitrary depth.. that scares me
07:21 dcook         It's not the best
07:20 ashimema      I hate php
07:20 ashimema      best go did out my php manual..
07:20 ashimema      so I think your right.. I need to loop
07:20 dcook         yeah, I forgot about the multiple levels..
07:20 ashimema      but I don't tihnk there's any way to tell how many levels without already executing a massive loop..
07:20 ashimema      if you can work out how many level you need to traverse first.. then you can left join on self level number of times..
07:19 dcook         Actually, I guess you could do it with SQL
07:19 cait          yeah i think you probably need some programming
07:18 dcook         I don't even know if you could do that with SQL...
07:18 cait          could you do... a select... and when it returns results... do another on the ids found... and repeat that until no results come back?
07:18 dcook         hehe
07:18 cait          .. there there?
07:18 ashimema      that will lead to all sorts of sql pain.. both in writing the sql and in executing it :'(
07:17 ashimema      yeah.. It's a properly nasty problem..
07:17 ashimema      understand now cait?
07:17 dcook         Wow...
07:17 ashimema      I need to walk from the top of the heirachy down to get all possible children, grandchildren and grand grand children to an abitrary level of any said parent.
07:17 magnuse       that sounds like fun!
07:16 ashimema      so you only have child to parent relationships..
07:16 ashimema      one table contains elements.. each element has an ID and a Parent column.. the Parent column contains the ID of the Parent in the Heirachy.
07:15 cait          i don't even understand what you are trying to do
07:15 cait          ?
07:15 * ashimema    hates php
07:15 ashimema      or sql
07:15 ashimema      in php
07:15 ashimema      any idea how I can walk down an 'Adjacency List' in mysql to get all nodes from any arbitrary node given that the heirachy can be any arbitrary depth.
07:14 ashimema      I've decided I really hate this guys programming..
07:13 dcook         always fun times, ashimema
07:09 ashimema      my head hurts.
07:09 ashimema      ack.. I'm grappling with a poorly designed database schema again..
07:08 cait          only a short walk
07:06 ashimema      you got to work quick cait
07:05 dcook         Nah, need to go to the vet, I think.
07:05 cait          dcook: go home!
07:05 cait          heh
07:05 dcook         hehe. Thanks, magnuse.
07:05 dcook         wb cait
07:05 dcook         Hmm, didn't quite leave on time
07:00 magnuse       dcook: good plan :-)
06:57 ashimema      haha..
06:57 dcook         Trying to get my silliness out of the way before I have a kid and just look like a hypocrite? :p
06:57 dcook         ...
06:57 dcook         double chocolate actually
06:56 * dcook       had chocolate cookies for breakfast
06:55 ashimema      s/ceral/cereal
06:55 * ashimema    just has ceral
06:54 * ashimema    jealous
06:53 * magnuse     just finished breakfast, with homemade plum jam
06:52 dcook         Mmm, I could go for breakfast
06:50 ashimema      breakfast time me thinks.
06:46 reiveune      \o_ dcook
06:45 dcook         heya reiveune, magnuse
06:44 magnuse       oops, now i scared cait away...
06:43 magnuse       bonjour reiveune
06:39 reiveune      bonjour cait magnuse
06:39 * magnuse     waves
06:38 cait          hi reiveune
06:38 reiveune      hello
06:38 cait          :)
06:38 dcook         Might actually leave work on time to take care of some errands though ;)
06:37 dcook         Well, I'll be around for a little bit
06:37 cait          but yeah :) leaving to go to work in a few moments
06:37 cait          ah i misread
06:37 dcook         leaving, cait?
06:35 cait          bye eythian and dcook
06:35 dcook         Thanks for the OSDC advice
06:34 dcook         laterz eythian
06:31 eythian       alright, time for me to go. Later all.
06:29 eythian       we should get one
06:29 ashimema      k
06:29 eythian       nope
06:29 ashimema      you guys donw have an Overdrive account for demo purposes do you?
06:28 wahanui       i think random question.. is there anywhere in koha that uses editable datatables?
06:28 ashimema      oh.. random question..
06:28 * dcook       likes this idea of end-user modificable XSLT
06:28 ashimema      k
06:28 eythian       I think they're just referenced by file path. I'm not totally sure, wizzyrea is doing that bit.
06:26 ashimema      rather.. how do you use the xslt's in /var/www/files?
06:26 eythian       I don't think so
06:26 ashimema      do you run into any issues with https and custom xslt's?
06:25 eythian       /usr is fine for the code.
06:25 ashimema      probably /var/www/files is probably the more sensible place
06:25 eythian       if we got it into upstream koha, /var would be the right place.
06:25 eythian       it's also where their theming and such goes.
06:25 ashimema      likewise
06:25 ashimema      seems sensible enough
06:25 eythian       it's part of our plan to allow end-user-modifiable XSLT.
06:24 eythian       all our sites have a publicly accessible /var/www/files/site, we've started putting XSLT in there.
06:24 ashimema      should we not ;)
06:23 ashimema      we should also probably stick most of the koha runtime code in opt instead of usr ;)
06:23 ashimema      haha..
06:23 ashimema      does that make sense to you?
06:22 ashimema      then added a 'custom' alias to the instance vhost
06:22 ashimema      for this I've gone the route of adding a /www/opac/en/xslt dir within /var/lib/koha/instance
06:22 ashimema      We also add custom xslt sheets allot..
06:22 eythian       I just can't be bothered writing the migration code to fix it :)
06:21 ashimema      I agree..
06:21 ashimema      I hadn't noticed that before.. but yeah..
06:21 eythian       really, the email enabled/disabled flag should be in /etc/koha/sites/*/ rather than in /var/koha/...
06:20 ashimema      that certainly helps
06:20 ashimema      cheers
06:18 eythian       "for being"
06:18 eythian       "for be"...
06:18 eythian       rc.d-esque
06:18 eythian       I tend to think of /var/ for be where the application can make day-to-day changes of its own data, but /etc/ where configuration specifically goes, even if that config is a small shell script.
06:17 ashimema      oh.. hadn't thought to look at ifup/ifdown.. that's a good idea ;)
06:16 eythian       I'm not 100% sure what that is.
06:16 eythian       I'd have a look to whatever the good practice for ifup/ifdown scripts is.
06:15 eythian       (or something along those lines)
06:15 ashimema      you'd go for /etc/koha/sites would you?  I was thinking /var/lib/koha/instance/scripts
06:15 eythian       in that case I'd have /etc/koha/sites/*/borrower_import.conf that contains "filename=/chroot/home/.../file.csv", the processing script uses that, and then some standard rename to rename it or whatever.
06:14 ashimema      but yeah.. I imagine the 'wrapper script' will always need to be slighlty custom
06:14 eythian       oh, OK
06:14 eythian       I'd do that by having a "pre-process" shell script in /etc/koha/sites/*/something.sh that fetches the file, puts it somewhere, and returns the filename with path.
06:14 ashimema      actually.. I lied.. in this case.. the customer is sftping to the server in chroot/home/customername ;)
06:13 eythian       ashimema: OK, so the sftp thing will have to be custom configuration.
06:13 dcook         To insert them directly, to put them in import_records, or have another table..
06:13 ashimema      there's not really any clear consensus on how to deal with the 'extra bits' using packages.
06:13 dcook         Whether to store the harvested records as temp files or in the db
06:13 dcook         I keep thinking about reviving the oai harvester code, but not sure the best way to do it
06:13 dcook         Mmm, I know about you mean about best practices, ashimema
06:12 ashimema      yup.. exactly ;)
06:12 ashimema      the wrapper script basically grabs the file via sftp, stuffs it somewhere for the import to run upon it, then after the import has run, it renames the file, keeps it for a week so you can go back to it if you need to... and after a week cleans up after itself.
06:12 eythian       *each instance
06:12 eythian       and the config will be similar but slightly different for each one?
06:11 eythian       hmm. So, you're writing something that'll look somewhere for a file each day, process it, and then do something with the file that it processed to get it out of the way?
06:11 ashimema      but I imagine it'll be usefull for community once I've narrowed it down a bit ;)
06:10 ashimema      it is for now..
06:10 eythian       this is custom to your environment?
06:10 ashimema      any thoughts eythian?
06:10 ashimema      where to call said script.. (as crontab within koha-shell for instance.. or in cron.daily/koha-instance)
06:09 ashimema      like.. where to put said script..
06:09 ashimema      but it's the wrapper script that moves the files round and creates logs etc that I'm struggling to come up with a best practice for..
06:09 ashimema      Well, i've been working on a re-write of the staff client patron import tools to add a nice cli version (but that's not ready yet), so we're using the not especially nice script from liblime that khall recently refactored..
06:08 ashimema      it's the 'extra bits' i'm now working on..
06:07 dcook         Background loading of patrons sounds interesting
06:07 ashimema      I took notes.. i fact.. I stole a copy of the slides ;)
06:07 dcook         true true
06:07 ashimema      Yeah.. his best practices talk was pretty good.. but it only touched the basics.. not going into further detail
06:07 dcook         ashimema must not have taken notes :P
06:07 * dcook       seems to recall rangi doing a best practice talk at kohacon13
06:06 eythian       I planned a talk on best practices for a kohacon, but didn't end up going. Though I think rangi gave it in my stead.
06:06 ashimema      for instance.. adding per instance cronjobs.. (like background loading of patrons on a regular basis)
06:06 eythian       heh
06:05 ashimema      collegue keep throwing 'best practice' questions at me.. problem is I haven't worked out th best practice yet ;)
06:05 ashimema      been battling with packages the last few hours..
06:05 ashimema      Yeah, not bad..
06:05 eythian       pretty good, yourself?
06:04 ashimema      Hey eythian, hows it hangin'
06:04 eythian       hi ashimema
06:04 ashimema      morning all
06:04 huginn        ashimema: The operation succeeded.
06:04 ashimema      @later tell wizzyrea fraid not, we haven't got our overdrive problem sorted.  Basically we want to be able to demo koha's support for it tomorrow, but can't get any reply from Overdrive regarding a demo account.
05:54 dcook         Ahh, figured it out...
05:52 huginn        dcook: The operation succeeded.
05:52 dcook         @later tell marcelr have time to answer a few questions about XSLTs and Z39.50?
05:38 cait          wish i could .)
05:38 ivan          I will certainly consider it.  At least a bug report. I failed on the wiki update with my last issue but maybe this time.
05:38 eythian       hi cait, go back to bed.
05:38 * cait        waves
05:38 eythian       or even just report a bug describing anything. Maybe someone with free time who uses SIP will see it and fix it.
05:37 eythian       if you want to turn your diagnosis time into good, make a patch :)
05:37 ivan          eythian, oh yes that would have been blessed indeed.
05:36 eythian       oh, interesting indeed
05:35 eythian       ivan: the real solution will be to have SIP say something obvious, like "user xyz doesn't exist as specified in the config"
05:31 dcook         I suppose that's one way of keeping data that doesn't convert easily
05:30 huginn        dcook: Contains data from non-MARC records for which there are no corresponding MARC 21 fields. Used when converting non-MARC records into the MARC 21 format. (Repeatable) [a,2]
05:30 dcook         @marc 887
05:30 dcook         Well, this is interesting. Sort of. http://www.loc.gov/marc/bibliographic/bd887.html
05:18 ivan          Well I guess the only useful bit out of this for others is that if you get an error complaining about ils being undefined you are likely getting a 940 error. Which means you are not logging in, which (in Ubuntu) is logged in syslog not sip*.log.
05:16 ivan          Yeah.. that's pretty close to the new name
05:16 rangi         sometimes they still do :)
05:16 rangi         DO NOT DELETE ME
05:16 rangi         i usually make them be something like
05:16 ivan          Well login is working now, imagine that?!
05:15 rangi         that'd do it
05:15 * ivan        cries
05:15 ivan          Ughh... One of the staff at my library had deleted my API user.
05:10 rangi         and does it exist in koha?
05:10 rangi         does that user and pass and library exist in teh config
05:09 ivan          https://dpaste.de/AxRE
05:09 ivan          rangi, eythian, wizzyrea: I found some more logs for it in syslog. I think something is wrong with my user.?
04:43 dcook         hehe
04:43 huginn        dcook: Quote #190: "<jcamins> Hehe. Guillotine: the revolutionary card game you win by getting a head <asaurat> lol <asaurat> I mean mdr" (added by slef at 03:46 PM, February 28, 2012)
04:43 dcook         @quote random
04:41 huginn        gmcharlt: Quote #272: "jcamins: THIS IS A SECURITY RISK -- no kidding. It's Windows." (added by wizzyrea at 02:18 AM, August 29, 2013)
04:41 gmcharlt      @quote random
04:33 rangi         might be testable
04:33 huginn        04Bug 12729: normal, P5 - low, ---, koha-bugs, Needs Signoff , Overdue items won't show as overdue in red in circulation
04:33 rangi         aleisha: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12729
04:28 dcook         Sweet as
04:28 huginn        04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6536 new feature, P3, ---, m.de.rooy, Pushed to Master , Z3950 Search Enhancements: SRU targets and additional XSLT processing
04:28 wahanui       somebody said bug 6536 was ready for takeoff
04:28 dcook         bug 6536
04:26 dcook         That would actually do exactly what I need..
04:26 dcook         Applying a XSLT to incoming records could be pretty cool..
04:26 dcook         Hmm, I wonder how far along marcelr's XSLT stuff is going...
04:08 ivan          Hmm... I will keep poking around
04:07 rangi         something is causing the modules not to load, it could be a syntax error, it could be the config file, etc
04:07 ivan          Everything seems to be checking out
04:07 rangi         yep
04:06 ivan          Is that right?
04:06 ivan          I am compiling these by going into each folder and typing perl -c *.pm
04:01 ivan          doing that now
04:01 rangi         i suspect there is a syntax error, that is causing the files to not load
04:01 rangi         id try doing those perl -c then
04:01 ivan          rangi: The only thing in the logs is an output of the config (on startup) and then the error I posted earlier
03:54 rangi         aleisha: then 12882
03:53 ivan          Ah, yeah I see that in the spec now. Under 94<ok>, 0 meaning fail I guess
03:53 rangi         aleisha: 12890 is a good one to start with
03:52 rangi         also try doing a perl -c on the files in SIP/ILS
03:52 rangi         whats in the sip.err or sip.log  files?
03:51 rangi         so the user is not succesfully logging in, probably because the ILS module is not being instatiated
03:51 rangi         41 means successful terminal login. 940 or getting dropped means failure.
03:50 ivan          Oh and yeah, after that last command is when I get the error in the logs
03:50 ivan          http://multimedia.3m.com/mws/mediawebserver?mwsId=SSSSSu7zK1fslxtUm8_9m82Uev7qe1%207zHvTSevTSeSSSSSS--
03:50 ivan          Looking at the spec though I don't know if that matters or not.
03:49 ivan          I have noticed that the Koha wiki shows a 941 response and I am getting 940.
03:48 ivan          6300020060329    201700          AOsomelibrary|AAbad_barcode|
03:47 ivan          [No output in log at this point]
03:46 ivan          940                          <--- The response
03:46 ivan          9300CNsomeuser|COsomepass|somelibrary|
03:45 ivan          telnet localhost 6000
03:45 ivan          This may help. Here is my telnet session I am testing with (for patron info).
03:30 ivan          I wonder if ILS is something that is set on succesfull login and not in server setup
03:29 eythian       ah right
03:29 dcook         eythian: I think the only web-based one. Think the draft is on another hard drive.
03:27 ivan          *borrower
03:27 ivan          We have borrow categories and the institution is the same as the branch code
03:26 ivan          https://dpaste.de/drCn
03:26 ivan          Here is the trace for the find_patron error
03:24 wizzyrea      and a branch created that matches your institution ID
03:24 wizzyrea      this may sound daft, but you do have borrower categories and a borrower or two defined?
03:21 wizzyrea      I've seen this before... I know I have...
03:21 ivan          No but I can get you a trace by running it in debug. One moment.
03:20 eythian       is there anything before that?
03:20 eythian       hmm
03:20 ivan          This is from an item info request. "Can't call method "check_inst_id" on an undefined value at /usr/share/koha/lib/C4/SIP/Sip/MsgType.pm line 1099."
03:20 ivan          Can't call method "find_patron" on an undefined value at /usr/share/koha/lib/C4/SIP/Sip/MsgType.pm line 935.
03:20 ivan          Yep, this is from a patron info request.
03:16 eythian       does anything get logged?
03:15 ivan          Here is my config: https://dpaste.de/Kva7
03:07 ivan          wizzyrea: I am guessing you are referring to the <server-params tag in the config?
03:06 eythian       dcook: it's your only copy, eh?
03:05 * dcook       is glad that the website saved his proposal
03:05 ivan          Heh, yeah I am sure I have defined something wrong there. It just all looks right to me so I am trying to figure out what I missed.
03:04 wizzyrea      ivan: you may want to check that you have defined your server correctly in the config file.
03:02 eythian       heh
03:01 dcook         Looks like I'll have to come up with something to say
03:01 dcook         I guess, haha
03:01 wahanui       good news is it looks like it's running properly.
03:01 eythian       good news?
03:01 dcook         eythian: Just heard back from OSDC :)
03:01 ivan          self is then passed to my failing function where it is renamed to server
03:00 ivan          my $self = shift;
03:00 ivan          sub process_request {
03:00 ivan          I think netserver builds the server within the main file in a process_request method
02:44 ivan          Ok checking...
02:44 eythian       not of the top of my head, but you should be able to see where it comes from in the code.
02:44 ivan          Ah, I see. Any idea what files to check for server?
02:43 eythian       so that means that $server->{ils} isn't being set up by whatever sets up $server
02:43 eythian       it's looking in the $server hashref for 'ils'
02:42 ivan          The $ils var is what seems to be undefined
02:42 ivan          Ah, that wasn't my guess. Heh. Here is a line I was looking at in 'handle_patron_status': my $ils = $server->{ils};
02:41 eythian       instanting is generally something like Class::Name->new(...data..)
02:41 eythian       it's probably that it's failing to instantiate for some reason, e.g. not having data it needs or something
02:40 ivan          I am trying to figure out how that object get's instantiated to begin with. A little tricky as I am new to perl
02:37 ivan          Whenever I invoke a command that causes the ils object within MsgType.pm to be referenced I get: Can't call method "blah" on an undefined value...
02:36 wizzyrea      oh?
02:36 ivan          Having some SIP trouble on Ubuntu 14.04.