IRC log for #koha, 2009-10-31

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
00:51 chris ahh it made it to linux weekly news, he's picked as far bigger fight than he meant to
02:01 Nate joined #koha
02:25 chris heya Nate
02:25 Nate hey chris
02:25 chris i see you were quoted in library journal
02:25 Nate do you have a link to that article
02:25 how did it turn out
02:26 i tried to sound neutral but he called me right after i woke up
02:26 im sitting in a room full of my girlfriends friends right now
02:27 my only defense mechanism is to bury my head in work in the corner and hope they ignore me
02:28 ii found it
02:30 chris sorry got distracted by a toddler
02:30 i think you sounded fine
02:32 Nate good to hear
02:33 chris have you seen http://wiki.code4lib.org/index[…]Source#Commentary
02:33 its a good place to try to pull together all the stuff
02:37 * chris just commented on stephen abrams blog
02:37 chris http://stephenslighthouse.sirs[…]_about_a_res.html
02:37 dunno when it will show up
02:37 but if you read that last comment, and stephen's reply to it
02:37 i just couldnt resist saying
02:38 Stephen If you read back, you will notice that David says he is using your software. So he is reserving his criticism for a proprietary ILS that restricts his freedoms. Your company's proprietary ILS.
02:38 Nate Nice!
02:40 yeah its not posted yet but ill look for it tommorow
02:41 chris yeah it usually takes a while to come through, i think he has to take time to formulate his response and post that at the same time :-)
02:43 chris_n2 gmcharlt: nice observation about bugs and bashing, I agree 100%
02:44 chris same goes for publicly attacking release maintainers, not constructive at all
02:45 Nate Ive been discovered! until monday folks....
02:45 chris hehe have fun
02:45 Nate left #koha
02:45 * chris goes to play stickers
02:49 chris_n2 :-)
04:02 g'night
05:20 brendan goodnight all
06:45 indradg joined #koha
07:31 Ropuch Morning
08:02 nicomo joined #koha
09:00 Ropuch Hi nicomo
09:00 nicomo hi Ropuch
09:02 nicomo left #koha
09:20 greenmang0 joined #koha
10:41 cait_laptop joined #koha
10:52 CGI622 joined #koha
10:55 cait_laptop left #koha
10:55 CGI622 left #koha
12:28 bad_trip joined #koha
12:28 bad_trip left #koha
13:04 greenmang0 left #koha
14:06 francharb joined #koha
15:15 pianohackr|work joined #koha
15:29 francharb left #koha
16:03 pianohackr|work hola, #koha
16:03 chris: around?
16:10 Ropuch Hi pianohackr|work
16:10 pianohackr|work hi, Ropuch
17:25 nengard joined #koha
17:44 nengard left #koha
18:48 |Lupin| joined #koha
18:49 |Lupin| good day all
18:51 pianohackr|work Hi, sébastien
18:52 |Lupin| hello Jesse :)
18:53 pianohackr|work: how are your fingers today ?
18:53 pianohackr|work very good, the splint comes off at midnight
18:53 Ropuch Hello |Lupin|
18:55 |Lupin| good evening Ropuch
18:57 pianohackr|work: I'm sorry, I don't understand the word splint and my dictionnary is not very helpful...
18:57 pianohackr|work hmm
18:57 http://fr.wikipedia.org/wiki/Attelle
18:58 |Lupin| pianohackr|work: aaaaaaah !
18:58 pianohackr|work: thanks
18:59 pianohackr|work np. basically just for keeping the bones immobile while they mend
18:59 |Lupin| pianohackr|work: so wht does it mean that it comes off ? that you are allowed to get rid of it at midnight ?
18:59 pianohackr|work: yep, got it now, thanks.
19:00 pianohackr|work I've been taking it off to shower. Technically, it's six weeks of healing, midnight on halloween just sounded like a fun time to take it off for good
19:00 (comes out roughly to six weeks)
19:02 how are you?
19:02 |Lupin| pianohackr|work: I see :)
19:02 pianohackr|work: I am sure you are going to be really happy in the coming days to take advantage of all the functionalities of your body...
19:02 pianohackr|work |Lupin|: very much!
19:03 my mother is a physical therapist, is cautioning me to not work it too hard and hurt myself again
19:05 |Lupin| pianohackr|work: yeah looks wise...
19:05 pianohackr|work: I was just thinking to a storry I find funny.
19:05 pianohackr|work do tell
19:06 |Lupin| pianohackr|work: basically it's a man who is not happy and an old wise man suggests that the man adopts a goat. HIs life becomes worse, then the wise man suggests he adopts a chicken. HIs life becomes even worse.
19:07 pianohackr|work: then the wise man tells him to get rid of the chicken, so the man finds his life really great, and then to get rid of the goat, and then the man finds his life even greater.
19:08 pianohackr|work: so basically the message is that how we appreciate things depends more on transitions than on states...
19:08 pianohackr|work okay, yeah
19:09 very similar to waiting for a package in the mail
19:11 |Lupin| pianohackr|work: how similar ?
19:11 davi left #koha
19:11 davi joined #koha
19:11 pianohackr|work anticipating and receiving something is better than having it
19:12 |Lupin| pianohackr|work: ok :)
19:13 pianohackr|work: although sometimes there are big expectations regarding the received thing, followed by a cetain disappointment...
19:13 pianohackr|work yep :)
19:14 |Lupin| pianohackr|work: becoming more technical...
19:15 pianohackr|work: our library will use a home-made cataloguing/additem.pl (+ associated templae).
19:15 pianohackr|work k
19:16 |Lupin| pianohackr|work: the scrip is called three times. First it's clled with just a biblionumber. The user chooses a file format to add, says how many files are to be uploaded, and gives a few other informations. Second time the script is called with all this info and the user is asked to give the file names plus a few metadata for each file. Third time the files specified by the user are uploaded to a file server and the metadata saved.
19:17 pianohackr|work okay, makes sense so fa
19:17 *far
19:17 |Lupin| pianohackr|work: for the moment, to store the daa that have to be persistent from step 1 to step 3, I use hidden controls in the form, which I find not very clean
19:18 pianohackr|work: I'm wondering how you would store this persistent data...
19:18 pianohackr|work |Lupin|: that approach isn't exceptionally clean, but a lot of koha uses it
19:18 esp. wizards, like the guided reports module
19:20 |Lupin| pianohackr|work: yeah actually I find it rather ugly, e.g. because a malicious user could modify the data in the hidden fields... they are not checked again and again at each step.
19:20 pianohackr|work very true, but is it sensitive data?
19:20 |Lupin| pianohackr|work: bu actually, what are the other possible ways to deal with this problem ?
19:21 pianohackr|work |Lupin|: you can store additional information in Koha's session store, but that's usually not necessary
19:21 |Lupin| pianohackr|work: hmm.. I don't know how sensitive it is... not much but it could perhaps be used to spoil the DB or I don't know what. The good thing is that it's in the staf client, so accessible to only a few users...
19:22 pianohackr|work right
19:22 other, easier ways for those with access to cause you pain
19:22 |Lupin| pianohackr|work: ah yes I was thinking to something like that. Why are you saying it's usually not necessary ?
19:23 pianohackr|work Because the data stored there will stay there as long as the user is logged in
19:24 |Lupin| pianohackr|work: is that a problem ?
19:25 pianohackr|work not usually; it's just overkill for most situations
19:25 |Lupin| pianohackr|work: or isn't there a way to explicitly remove it form the session once it has been used ?
19:25 pianohackr|work: I understand.
19:25 pianohackr|work there is; it's a CGI::Session
19:25 |Lupin| pianohackr|work: right... I think I may have a look to that and perhaps follow this road...
19:26 pianohackr|work If you want to make dealing with the hidden variables easier, you can store them inside a hash inside your script, then expose them to the template inside a loop
19:27 |Lupin| pianohackr|work: ah that would indeed be an improvement
19:28 pianohackr|work In the template: <!-- TMPL_LOOP NAME="vars" --><input type="hidden" name="<!-- TMPL_VAR NAME="name" -->" value="<!-- TMPL_VAR NAME="value -->"><!-- /TMPL_LOOP -->
19:28 the code to support that's pretty trivial
19:28 |Lupin| pianohackr|work: yeah that's okay, I think I see what you mean, it's really elegant, thanks a lot
19:29 pianohackr|work np, minor hack that's helped me
19:30 |Lupin| pianohackr|work: actually, I'd be happy to get some feedback on the code I wrote, since it's my first piece of code in Koha and almost my first one in Prl. would you accept to have a look to it ? The script is 376 lines long...
19:31 pianohackr|work: yeah minor but seems really helpful indeed :) things don't need to be very elaborated to be helpful
19:31 pianohackr|work I can definitely review it, tomorrow if not today
19:31 yup
19:31 |Lupin| pianohackr|work: np, do it when you have time
19:31 pianohackr|work: can you please /msg me an e-mail address where I could send the code ?
19:32 pianohackr|work: hmm actually...
19:32 pianohackr|work: I could perhaps make my gi repo accessible to you somehow...
19:32 pianohackr|work even better
19:33 |Lupin| pianohackr|work: any suggestion about how that could be done ?
19:33 pianohackr|work |Lupin|: would probably be easiest to upload it to a site like github.com or gitorious.org
19:34 |Lupin| pianohackr|work: k...
19:34 pianohackr|work although that would make it public, not sure if that's okay
19:34 |Lupin| pianohackr|work: I think ist's okay
19:34 pianohackr|work cool
19:34 |Lupin| pianohackr|work: I'm just wondering whether it's the quickest and easiest way to proceed...
19:35 pianohackr|work depends; if you want to, you could set up a git server on one of your web-accessible servers
19:35 |Lupin| pianohackr|work: actually our production system is visible on the web and KOha runs from git there, so perhaps I could install some git-web tool there ? would that be a good idea ?
19:36 pianohackr|work you could do that; you don't even need git-web, just a git server
19:36 |Lupin| pianohackr|work: yeah if that's not too much work, I think I'd like to do it like this...
19:37 pianohackr|work: does this mean to install a specific debian package ?
19:37 pianohackr|work: and can that work over http ? cause I'm not sure the git port (if there is one at all) is already open on the machine I'm thinking about...
19:39 pianohackr|work |Lupin|: git-daemon is easy to set up and comes by default on ubuntu, but needs its own port
19:42 |Lupin|: there's http://www.kernel.org/pub/soft[…]ver-over-http.txt, but might be more than you need
19:43 |Lupin| pianohackr|work: do you know which port is traditionnally used ?
19:43 pianohackr|work 9418
19:43 |Lupin| pianohackr|work: ah thanks !
19:43 pianohackr|work: ok
19:44 pianohackr|work: the thing is, I'm not sre how well it would work to have both a git server and Koha working simultaneously...
19:44 pianohackr|work shouldn't cause any conflict, as the git server will only access the .git directory
19:46 |Lupin| pianohackr|work: but if there is already apache listening... or would apache all the git server for some well-defined URLs ?
19:46 pianohackr|work git-daemon is an entirely separate program
19:47 |Lupin|: it looks, though, like you can just make the .git directory available over http, and git can pull from it
19:47 see http://git.debian.org/git/sane/sane-backends.git/ for an example
19:48 |Lupin| thanks
19:48 I'm exploring... first seeing if the git port is firewalled or not...
19:50 pianohackr|work |Lupin|: also, re your drupal question: you could easily have koha and drupal in the same virtual host, though you'd want drupal to have its own area (if your staff side was at http://staff/cgi-bin/..., then drupal would have to be at something like http://staff/pages/)
19:52 |Lupin| pianohackr|work: right... but KOha really has to be at cgi-bin/something, it's not possible to change that easily, is it ?
19:52 pianohackr|work |Lupin|: no, that's very very hardcoded
19:52 |Lupin| pianohackr|work: cf. Bug 3717 I think...
19:52 munin 04Bug http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=3717 minor, P5, ---, paul.poulain@biblibre.com, NEW, staffClientBaseURL and OPACBaseURL should be used
19:53 |Lupin| pianohackr|work: so I hope drupal is easier to re-locate...
19:53 pianohackr|work |Lupin|: probably easier to move drupal at the moment, yes
19:54 And I'm not sure a working implementation of staffClientBaseURL would fix your problem
19:54 |Lupin| pianohackr|work: why ?
19:55 pianohackr|work: here it's rather OPACBaseURL which is concerned...
19:55 pianohackr|work ah, nvm, it could
19:55 you could set it to http://opac/koha/, for example
19:57 |Lupin| pianohackr|work: yeah, if it was implemented I could do that...
19:57 pianohackr|work right
19:57 |Lupin| pianohackr|work: actually I think it represents a certain deal of work to implement it...
19:58 pianohackr|work |Lupin|: under the current templating system, it would be basically impossible
19:59 |Lupin| pianohackr|work: impossible !? I didn't realise the situation was sobad ! I just thought it was hard to do... why impossible ?
20:00 pianohackr|work perhaps not impossible, but every link would have to be prepended with a TMPL_VAR; it would make reading and writing templates much more difficult
20:02 |Lupin| pianohackr|work: indeed. You said "the current templating system" because there are some plans to change that ?
20:02 pianohackr|work |Lupin|: in the future, we want to use Template::Toolkit
20:03 (no firm decision, just the general feeling of the developers)
20:03 anyway, headed home, talk to you later
20:03 good luck with koha, drupal and git
20:03 |Lupin| pianohackr|work: thanks
20:03 pianohackr|work: just one thing...
20:03 pianohackr|work: warning: remote HEAD refers to nonexistent ref, unable to checkout.
20:04 pianohackr|work: any idea what I should do ?
20:04 pianohackr|work |Lupin|: possibly git-update-server-info
20:04 see ya
20:07 |Lupin| pianohackr|work: sokay, till soon
20:08 pianohackr|work left #koha
21:30 pianohacker joined #koha
21:34 |Lupin| hi again pianohacker :)
21:35 pianohacker: still trying to make the git repo visible...
21:35 pianohacker hallo
21:35 any luck?
21:35 |Lupin| pianohacker: it's funny, I had to modify koha-httpd.conf so that the URL or the git directory is mapped to the right plae
21:36 pianohacker: I think the problem is almost solved
21:36 pianohacker cool
21:37 little mozilla dev quip for the translators: http://quotes.burntelectrons.org/4798
21:37 |Lupin| pianohacker: it's just I don't understand why http://194.199.19.26/git/objects/ is rewritten correctly, whereas http://194.199.19.26/git/objects/34/ brings up a Koha page...
21:37 pianohacker: I suspect the Alias directive and the Rewrite one do not go together well...
21:42 pianohacker |Lupin|: does the Rewrite directive end in $ ? If so, it would only match /git/objects/, not /git/objects/34/
21:42 actually, if you put your koha-httpd.conf on pastebin, I might be able to help
21:42 http://paste.workbuffer.org/
21:45 |Lupin| pianohacker: well so far I didn't use rewrite rules for the git part, I used Alias...
21:45 pianohacker: http://pastebin.com/f3e37bc93
21:46 pianohacker: it's almost the original koha-httpd.conf, I think the only modificiation is the addition of the Aliasline
21:47 pianohacker hmm
21:47 that should be working
21:48 |Lupin| pianohacker: well, it does not... :)
21:48 pianohacker: try for instance
21:48 lynx http://194.199.19.26/git/objects/
21:48 and then
21:48 lynx http://194.199.19.26/git/objects/34/
21:49 pianohacker hmm
21:49 there isn't a 34 directory in git/objects/
21:49 |Lupin| you'll see the second takes you to the opac...
21:49 pianohacker those folders that exist seem to work fine
21:50 |Lupin| pianohacker: well
21:51 pianohacker: I did a git clone and I think I got the URL from there
21:51 pianohacker: however the repo is sane: I did a git fsck --full and this reported no problem...
21:53 pianohacker ahh, http://194.199.19.26/git/objec[…]70cc6b2a57eaa1d0c , from a git clone error, gives a 404
21:54 interestingly, the fetch is trying to reach nonexistent objects
21:54 |Lupin| pianohacker: yeah I have similar syndroms with other files
21:54 pianohacker: it's just that I don't know how to proceed with that...
21:54 pianohacker: interestingly, yeah...
21:54 pianohacker: perhaps I should do a git gc ?
21:55 pianohacker worth a shot
21:56 |Lupin| Total 129145 (delta 90512), reused 129078 (delta 90447)
21:56 not sure how that can be interpreted...
21:56 pianohacker no useful info
21:56 |Lupin|: some of the objects are stored as compressed packs under objects/packs
21:57 |Lupin| pianohacker: hmm... and so ?
21:57 pianohacker: what is strange is that I tried to fetch the debian repository you mentionned earlier, and that worked...
21:59 pianohacker: the file that was not found corresponds actually to an existing commit...
22:00 pianohacker so it probably exists, but is in the packs
22:00 here's my theory
22:01 git fetch over http first looks for the plain object, then looks for the pack if it encounters a 404
22:01 |Lupin| pianohacker: yeah...
22:01 pianohacker but Koha's 404 page might not be setting the 404 response header correctly
22:02 so it just interprets if it had actually found the object
22:03 mahesh left #koha
22:04 pianohacker yup, and that's correct
22:04 here's what you can do
22:05 just remove the ErrorDocument 404 line from the OPAC section of koha-httpd.conf
22:06 it'll be a little less user-friendly for those that get broken urls, but those aren't very common
22:07 If you want to keep Koha's error page, you could save the html to a file and point ErrorDocument 404 at that instead of 404.pl
22:09 |Lupin| pianohacker: and git would know what to do with the 404 ? t would know that the object is packed and would consequently require the right thing ?
22:09 pianohacker I believe so
22:09 only theory
22:09 |Lupin| pianohacker: ok. just reading the doc from the kernelyou suggested
22:10 pianohacker: and why would the trick you explained about 404.html rather than 404.pl work ?
22:10 pianohacker because if Apache's serving a static file, it can set the 404 Not Found response code
22:11 404.pl doesn't seem to do that, though it can and should
22:12 |Lupin| aaaaaaaah
22:12 pianohacker: that would be done in the headers, right ?
22:12 mahesh joined #koha
22:12 |Lupin| s/headers/HTTP headers/
22:12 pianohacker kind of; it's the first line of the response, before the headers
22:13 |Lupin| ok
22:13 pianohacker it's normally HTTP/1.1 200 OK
22:13 |Lupin| a status line...
22:13 pianohacker that's the term, couldn't remember it
22:14 I'm off to do house chores, but will be back later; please let me know if you get it working :)
22:14 pianohacker is now known as pianohackr-away
23:10 pianohackr-away is now known as pianohacker
23:30 |Lupin| pianohacker: stil here.
23:30 pianohacker: I have fixed the 404.pl script, will send a patch
23:30 pianohacker: so that it efines the status correctly, I mean
23:30 pianohacker ah, cool
23:31 |Lupin| pianohacker: I think the other error scripts have the same problem.
23:31 pianohacker most likely
23:32 off again, be back later
23:32 |Lupin| pianohacker: any idea where the status and the corresponding messages can be found ? that would avoid me to have to reproduce each error to see how apache handles it
23:32 pianohacker: ok
23:33 pianohacker |Lupin|: http rfc
23:37 |Lupin| pianohacker: yep, thanks...

← Previous day | Today | Next day → | Search | Index

koha1