Time  Nick       Message
11:19 nahuel     does someone can say me why in http://wiki.koha.org/doku.php?id=en:development:dbrevs:start there is two version "v3.01.00.011" ? and which version I can add? .012 ou .015?
12:23 gmcharlt   nahuel: please use .015
13:08 hdl_laptop hi gmcharlt
13:09 hdl_laptop have you had time to take a look at the patches I sent you ?
13:09 hdl_laptop (just For My Information)
13:10 nahuel     ok gmcharlt thanks
13:10 nahuel     gmcharlt, did you see my new zotero patch ?
13:11 mc         hell all
13:11 mc         hello all
13:11 mc         better
13:11 hdl_laptop yes
13:42 paul_p     ;-)
13:42 paul_p     hi owen.
13:42 owen       Hi paul_p
13:43 owen       Today we've got new snow, although not too much
13:43 paul_p     last time there was so many snow in Marseille : 22 years ago !
13:43 paul_p     I said "once every 10 years", I was under ;-)
13:43 owen       Now everyone in Marseille is saying "There is no global warming!"
13:44 paul_p     not sure : Marseille ppl are well known to be the most crying ppl in France !
13:44 paul_p     we are famous for that and for soccer
13:45 owen       :)
13:50 kf         it was in german news yesterday - snow in marseille and a short film
13:51 kf          :)
13:52 owen       kf, you're in Germany?
13:55 kf         yes
14:00 kf         some snow here, cold but sunny ;)
14:02 owen       I don't think we've met before kf, I'm from the Nelsonville Public Library in Ohio, U.S.A.
14:04 kf         i know, you are responsible for koha looking so nice
14:07 kf         i did some work on german translation and getting deeper in koha everyday now
14:12 owen       I'm a little behind on Koha work these days because my library is preparing for its own upgrade to 3.0 (with Liblime's help)
14:14 hdl_laptop hi kf :
14:15 hdl_laptop I am working on 3.0.1
14:18 kf         hi hdl
15:29 teelmo     hello
15:29 gmcharlt   hi teelmo
15:39 teelmo     i was trying to install koha earlier today :) didn't quite manage
15:50 nahuel     gmcharlt, you have 2 mins ?
15:50 gmcharlt   nahuel: for you, yes :)
15:51 nahuel     hehe :)
15:51 gmcharlt   haven't had a chance to test your COinS patches yet, but later today
15:51 nahuel     ok great, but I wanted to talked you about the mail I just send to koha-devel about innodb
15:51 nahuel     and the growing disk space used by innodb
15:51 nahuel     did someone in liblime had the same problem ?
15:52 gmcharlt   I assume we do
15:52 nahuel     how did you do ?
15:52 gmcharlt   a couple things I can think of right away - enable innodb_file_per_table_feature.
15:52 nahuel     to decrease ?
15:52 nahuel     hmmm, ok, but it do not delete the data
15:54 gmcharlt   right, but with care, would be able to selectively shrink certain tables
15:54 gmcharlt   still means production downtime
15:54 gmcharlt   another trick is during your production data migration
15:54 gmcharlt   after you finish the load, either drop the database and load it from a dump
15:54 gmcharlt   or transfer the dump for a temp database used for the migration to the production one
15:55 nahuel     yes, but I'm thinking in a client that have a 10 years old installation...
15:55 gmcharlt   that way you don't start off with unnecessary space for any temporary stuff created during the migration
15:55 gmcharlt   ah
15:55 nahuel     or like an university use
15:55 gmcharlt   thinking aloud, one possibility might be setting up replication
15:56 nahuel     that delete/create thousands of "patrons" each years
15:56 nahuel     and all the loans
15:56 gmcharlt   then swtich over from master to replica
15:56 nahuel     yes it could be a solution, but it's a big problem of innodb...
15:56 gmcharlt   minimizes downtime, but I haven't actually tried anything like that
15:57 nahuel     Well, another solution for us is to dump/restore the database each upgrade time
15:58 gmcharlt   that's no unreasonable for major upgrades
15:58 gmcharlt   since you'll have some downtime anyway
15:58 gmcharlt   (or if you're doing something clever to not have downtime, it would likely involve having a copy of the database anyway)
16:00 gmcharlt   nahuel: cfouts will undoubtedly have better insight
16:01 nahuel     it should be a solution for long time support
16:01 nahuel     but i imagine someone who install koha and do not do this for 10 years
16:01 nahuel     ans have 10k users
16:01 nahuel     s/s/d
16:03 cfouts     what's up?
16:04 gmcharlt   cfouts: nahuel has some questions about shrinking innodb datafiles for tables and databases that do lots of inserts and deletes
16:05 cfouts     not much to be done about it, unfortunately.
16:05 nahuel     :s
16:05 nahuel     you let the databases growing ?
16:06 cfouts     well, they don't grow without bounds, generally.
16:06 cfouts     it grows to accommodate however much data you put into it.
16:06 cfouts     and then never shrinks if you delete some data.
16:07 nahuel     yes of course, but i'm thinking to some libraries that received/delete lot of datas each months
16:07 nahuel     the database is permanently growing
16:07 nahuel     and I think you can count the size in GB each years
16:07 cfouts     lots of that is often the sessions table. have you looked at that?
16:08 nahuel     yes
16:08 nahuel     too big ;)
16:08 nahuel     but what do you do to decrease it ?
16:08 cfouts     it also contributes in terms of table fragmentation, which gives very sparse and inefficient data storage.
16:08 cfouts     'truncate sessions'
16:08 cfouts     at night when not many people are using it.
16:08 nahuel     but innodb do not delete datas from disk
16:09 cfouts     no, it will never shrink, but periodically truncating the sessions table will keep it from growing further.
16:09 hdl_laptop cfouts: having decent expiry session time would be also a solution
16:09 cfouts     I've got a bug in for that.
16:10 nahuel     mc should look to fix this
16:10 cfouts     that's the ideal solution, but truncate works for now
16:10 nahuel     but as i understand do not decrease the disk space used?
16:11 cfouts     no, you have to dump and rebuild to shrink the database file size.
16:12 nahuel     dump/rebuild is bad in production databases amha
16:12 cfouts     yes, it's not an ideal solution, that's for sure.
16:12 mc         nahuel, i'm reading
16:13 nahuel     mc, :)
16:13 nahuel     but this innodb problem is amha a big problem...
16:13 cfouts     you can do other things, like connect a replication slave to create a new copy of the data
16:13 cfouts     disk space is pretty cheap. I don't know how big of a problem this is.
16:14 nahuel     The problem is you do not control the disk space grow
16:14 nahuel     it do not more depend of the data in the database
16:14 nahuel     but the USE of the database
16:15 mc         nahuel, what do you expect from me ... i'm just a rookie with mysql
16:15 gmcharlt   but that's always the case
16:15 nahuel     mc, we talked about sessions expiry
16:15 mc         almost rookie in database in generam
16:15 mc         ooh
16:15 mc         yes:
16:15 nahuel     gmcharlt, hmm no :)
16:15 gmcharlt   a library could start out small, get a big grant, and increase its collection ten-fold
16:15 mc         i'm aware
16:15 nahuel     use myisam, the disk space used, is the data disk space...
16:15 nahuel     (and indexes)
16:15 gmcharlt   like anything else, disk space usage has to be monitored
16:16 cfouts     isam doesn't support foreign key constraints
16:16 nahuel     cfouts, yes i know :)
16:16 nahuel     postgre yes :)
16:19 nahuel     well at the beggining the question is : does liblime have a solution ?
16:22 gmcharlt   well, at moment best idea is probably to dump/recreate database during scheduled downtime for an upgrade
16:22 gmcharlt   or do something with a replica
16:23 paul_p     gmcharlt: that was exactly the idea of nahuel : clean when upgrading !!!
16:25 nahuel     :)
16:29 owen       I'm surprised to realize that you can't search tags in Koha 3. Also surprised that I never thought of it until one of my staff asked about it.
16:57 nengard    owen i was under the impression that since tagging was still experimental more cool features would be coming - eventually
16:57 nengard    i think atz is the one to ask about that
16:58 owen       Yeah, I'm sure. I was just surprised at myself for never noticing.
16:59 atz        owen: the correct fix would be to index tags in zebra
16:59 hdl_laptop owen: fwiw, imho, tags should be considered as metadata.
16:59 hdl_laptop atz: same idea
16:59 atz        but i don't have time/skillz/sponsorship for that
16:59 owen       Yeah, my library is full of ideas but empty of cash.
16:59 atz        it's not really experimental though.  it's pretty stable at this point.
17:00 hdl_laptop atm, multiple MARC flavour support is quite time consuming for all of us.
17:01 atz        hdl_laptop: I imagine that would be very difficult
17:04 hdl_laptop mmm... not that much....
17:05 hdl_laptop if we add a new link to a subfield.
17:05 hdl_laptop But that would double the data.
17:05 gmcharlt   conceptually, adding a marcflavour column to biblio and replacing preference lookups would go a long way
17:05 gmcharlt   but there are lots of details to attend to
17:06 gmcharlt   - indexing : would requires DOM mode to have enough flexibility
17:06 hdl_laptop And we should then add user information.
17:06 hdl_laptop gmcharlt: ++
17:06 gmcharlt   - UI changes for user to know/set which MARC format is in use at a given point in time
17:07 gmcharlt   - the obvious thought that if you make Koha support multiple MARC formats, you may as well go all the way and support native DC and other metadata formats
17:07 hdl_laptop Sure.... long way.
17:08 gmcharlt   - finding a large rock to hide under as traditional catalogers and metadata librarians start fighting over the ILS ;)
17:09 hdl_laptop provided that traditional catalog is working fine, i think it would be OK for traditional catalogers.
17:10 gmcharlt   of course, I was just joking
17:20 trepador   hi i finally got install koha
17:20 trepador   but when i try to conect with the navigator shows me this fatal error
17:21 trepador   Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'
17:21 trepador   someone knows what's the problem
17:21 trepador   thanks
17:34 hdl_laptop trepador: yes.
17:34 hdl_laptop mysql seems not running
17:37 trepador   sorry but i'am a newbie jejeje
17:37 trepador   i don't have mysql-server installed
17:37 trepador   now i'm installing with the web installer
17:37 trepador   thanks
17:41 hdl_laptop trepador: I think that MANY things are told in INSTALL documents.
17:41 atz        you can't do web install w/o mysql.
17:48 trepador   thank you hdl laptop, but i have no idea of apache and mysql , i start to learn it, two days ago
17:49 trepador   i read many times the installation page on kubuntu hardy heron
17:49 trepador   and one thing more i apologize for my poor english
18:10 rhcl       I don't really know anything about rima-tde.net, but just as a side note it has some interesting google hits.
19:23 atz        owen: what mechanism do we use for keyboard hotkeys, if any, in the staff interface?
19:24 owen       It's not used extensively (or consistently, probably), but there is a jquery plugin being used in some places--the resident search form, for instance
19:25 atz        i see jquery.hotkeys.js
19:25 owen       Look in staff-global.js for where it is put to use
19:25 atz        cool, thx
19:28 atz        looks like alt+r, alt+u, and alt+q
19:28 owen       Right, for checkins, checkouts, and searches
19:28 owen       See this bug for complications: http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2639
19:29 owen       I haven't looked into the bug report because I always forget when I'm on my Mac :|
19:29 atz        i'd say that's a minor bug unless it affects win32 FF or IE
19:34 atz        hmm.... option r gives me ®
19:34 atz        q => œ
19:35 atz        u => opens some kind of dead-key extra-keyboard entry
19:36 atz        maybe i don't even know how to get to "alt" on my keyboard
19:37 atz        it's the same key as option on this small MacBook keyboard... but as a secondary
19:37 atz        so maybe i need shift or fn or some other magic
19:39 chris      morning
19:46 atz        maybe alt's not working b/c i installed "Witch"
19:46 atz        hi chris
19:47 atz        same results w/ Witch disabled...
19:47 atz        Œ‰¨
19:48 owen       Is there a preference for controlling how transfers are handled by default in returns?
19:48 owen       For instance: whether or not to automatically transfer items which belong at other branches
19:48 atz        for shift + alt/option + q|r|u
19:48 chris      i think so owen
19:48 chris      but i may be misremembering
19:49 chris      ill go look
19:49 owen       Hmm... AutomaticItemReturn maybe?
19:49 chris      hmm, my staff site is in greek
19:49 owen       "This Variable allow or not to return automaticly to his homebranch"
19:49 chris      this is gonna be tricky
19:49 owen       :)
19:49 atz        owen: i think there is a SomethingNeedsSomething syspref?
19:49 atz        (search for need)
19:50 cait       AutomaticItemReturn should be right, i remember i tested it wednesday
19:50 chris      yep
19:50 chris      If ON, Koha will automatically set up a transfer of this item to its homebranch
19:51 owen       Yeah, looks like what we were looking for.
19:52 owen       Too bad there isn't a "do not transfer" button offered like there is a "do transfer" button when it's switched off.
19:53 cait       HomeOrHoldingBranch might also be interesting
19:54 chris      thats more for if you can issue an item
19:55 cait       or if it has to go back first, yes
20:10 cait       its greek g
20:10 cait       ah meant for chris
20:11 chris      heh, yeah you can change it
20:11 cait       need login first :)
20:13 chris      done :)
20:14 cait       i did it too - parallel? g
21:35 danny      i have a patch that will make a couple of files obsolete, what is the general procedure for that? Is a separate patch for removing old files best or including that in the main patch?
21:36 gmcharlt   put in the main patch if removing the files is logically part of the change
21:36 gmcharlt   if it's just something you noticed along the way, put it in a separate patch
21:36 danny      ok
22:34 SelfishMan mwalling: That's funny
22:34 SelfishMan oops, wrong window
23:14 atz        chris: besides the "encoding" field not being populated, what else might cause working z3950 targets in 2.2 to break after upgrade to 3.0?
23:15 atz        it seems odd that the 2.2 implementation works better out of the box than the 3.0 one
23:53 chris      the 2.2 worked totally different
23:53 chris      you had to have a daemon type thing running on your box
23:53 chris      that actually did the z3950 searches
23:54 chris      and it didnt use ZOOM
23:54 chris      so theres a few things different
00:08 atz        chris: any recommendations for getting busted ones working in 3.0?  Clients can't be persuaded that the sources they were using last week are unnecessary in the fancy new version of the software.....
00:09 atz        i suppose i'll just try recreating broken ones from scratch.  it is probably a default value (in addition to encoding) that doesn't get applied by migration scripts...
00:10 chris      could well be it
00:10 chris      give that a whirl then see if you can spot the diff
00:12 atz        interesting
00:12 atz        was it an indexdata daemon also?
00:12 chris      nope, totally custom written
00:12 atz        wow... had no idea
00:12 chris      lemme find it
00:13 chris      http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=tree;f=z3950;h=59a4ebff8ea83f2c908e8d5e3faefc42f570b1b4;hb=4cde30f3a56670e1302798bccd56706dfbf49df8
00:13 chris      the z3950-daemon-shell.sh and z3950-daemon-launch.sh
00:13 chris      in there
00:15 atz        chris: http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=z3950/processz3950queue;h=a87b84d14bc64c76f781194c266169ae8f207a5a;hb=4cde30f3a56670e1302798bccd56706dfbf49df8
00:15 atz        uses ZOOM ?
00:16 chris      oh maybe it was changed
00:16 chris      it used to use plain old Net::Z3950
00:16 atz        ah, interesting
00:16 chris      must have changed whent that changed to ZOOM
00:17 atz        alright.... now here's an interesting part:
00:17 atz        use Encode::Guess;
00:18 atz        my $decoder = guess_encoding($marcdata, qw/utf8 latin1/);
00:19 atz        might have to look at that again later
01:08 mason      atz: i wonder if you are hitting a similar encoding bug to me?
01:09 mason      "besides the "encoding" field not being populated,"
01:10 mason      tho, my encoding bug is a bit more obvious than yours , it seems..
06:52 mc         hello world
07:25 chris      hi mc