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: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 Nate how did it turn out 02:26 Nate i tried to sound neutral but he called me right after i woke up 02:26 Nate im sitting in a room full of my girlfriends friends right now 02:27 Nate my only defense mechanism is to bury my head in work in the corner and hope they ignore me 02:28 Nate ii found it 02:30 chris sorry got distracted by a toddler 02:30 chris i think you sounded fine 02:32 Nate good to hear 02:33 chris have you seen http://wiki.code4lib.org/index.php/SirsiDynix:_Integrated_Library_System_Platforms_on_Open_Source#Commentary 02:33 chris 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.sirsidynix.com/archives/2009/10/its_about_a_res.html 02:37 chris dunno when it will show up 02:37 chris but if you read that last comment, and stephen's reply to it 02:37 chris i just couldnt resist saying 02:38 chris 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 Nate 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 * chris goes to play stickers 02:49 chris_n2 :-) 04:02 chris_n2 g'night 05:20 brendan goodnight all 07:31 Ropuch Morning 09:00 Ropuch Hi nicomo 09:00 nicomo hi Ropuch 16:03 pianohackr|work hola, #koha 16:03 pianohackr|work chris: around? 16:10 Ropuch Hi pianohackr|work 16:10 pianohackr|work hi, Ropuch 18:49 |Lupin| good day all 18:51 pianohackr|work Hi, sébastien 18:52 |Lupin| hello Jesse :) 18:53 |Lupin| 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 |Lupin| 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 pianohackr|work http://fr.wikipedia.org/wiki/Attelle 18:58 |Lupin| pianohackr|work: aaaaaaah ! 18:58 |Lupin| 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 |Lupin| 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 pianohackr|work (comes out roughly to six weeks) 19:02 pianohackr|work how are you? 19:02 |Lupin| pianohackr|work: I see :) 19:02 |Lupin| 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 pianohackr|work 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 |Lupin| 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 |Lupin| 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 |Lupin| 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 pianohackr|work very similar to waiting for a package in the mail 19:11 |Lupin| pianohackr|work: how similar ? 19:11 pianohackr|work anticipating and receiving something is better than having it 19:12 |Lupin| pianohackr|work: ok :) 19:13 |Lupin| 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 |Lupin| 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 pianohackr|work *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 |Lupin| 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 pianohackr|work 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 pianohackr|work 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 |Lupin| 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 pianohackr|work 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 |Lupin| 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 pianohackr|work yup 19:31 |Lupin| pianohackr|work: np, do it when you have time 19:31 |Lupin| pianohackr|work: can you please /msg me an e-mail address where I could send the code ? 19:32 |Lupin| pianohackr|work: hmm actually... 19:32 |Lupin| 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 |Lupin| pianohackr|work: does this mean to install a specific debian package ? 19:37 |Lupin| 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 pianohackr|work |Lupin|: there's http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-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 |Lupin| pianohackr|work: ok 19:44 |Lupin| 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 pianohackr|work |Lupin|: it looks, though, like you can just make the .git directory available over http, and git can pull from it 19:47 pianohackr|work see http://git.debian.org/git/sane/sane-backends.git/ for an example 19:48 |Lupin| thanks 19:48 |Lupin| 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/bugzilla3/show_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 pianohackr|work And I'm not sure a working implementation of staffClientBaseURL would fix your problem 19:54 |Lupin| pianohackr|work: why ? 19:55 |Lupin| pianohackr|work: here it's rather OPACBaseURL which is concerned... 19:55 pianohackr|work ah, nvm, it could 19:55 pianohackr|work 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 pianohackr|work (no firm decision, just the general feeling of the developers) 20:03 pianohackr|work anyway, headed home, talk to you later 20:03 pianohackr|work good luck with koha, drupal and git 20:03 |Lupin| pianohackr|work: thanks 20:03 |Lupin| pianohackr|work: just one thing... 20:03 |Lupin| pianohackr|work: warning: remote HEAD refers to nonexistent ref, unable to checkout. 20:04 |Lupin| pianohackr|work: any idea what I should do ? 20:04 pianohackr|work |Lupin|: possibly git-update-server-info 20:04 pianohackr|work see ya 20:07 |Lupin| pianohackr|work: sokay, till soon 21:34 |Lupin| hi again pianohacker :) 21:35 |Lupin| pianohacker: still trying to make the git repo visible... 21:35 pianohacker hallo 21:35 pianohacker 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 |Lupin| pianohacker: I think the problem is almost solved 21:36 pianohacker cool 21:37 pianohacker 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 |Lupin| 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 pianohacker actually, if you put your koha-httpd.conf on pastebin, I might be able to help 21:42 pianohacker 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 |Lupin| pianohacker: http://pastebin.com/f3e37bc93 21:46 |Lupin| 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 pianohacker that should be working 21:48 |Lupin| pianohacker: well, it does not... :) 21:48 |Lupin| pianohacker: try for instance 21:48 |Lupin| lynx http://194.199.19.26/git/objects/ 21:48 |Lupin| and then 21:48 |Lupin| lynx http://194.199.19.26/git/objects/34/ 21:49 pianohacker hmm 21:49 pianohacker 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 |Lupin| pianohacker: I did a git clone and I think I got the URL from there 21:51 |Lupin| 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/objects/49/3fba56e294684518482b270cc6b2a57eaa1d0c , from a git clone error, gives a 404 21:54 pianohacker interestingly, the fetch is trying to reach nonexistent objects 21:54 |Lupin| pianohacker: yeah I have similar syndroms with other files 21:54 |Lupin| pianohacker: it's just that I don't know how to proceed with that... 21:54 |Lupin| pianohacker: interestingly, yeah... 21:54 |Lupin| 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 |Lupin| not sure how that can be interpreted... 21:56 pianohacker no useful info 21:56 pianohacker |Lupin|: some of the objects are stored as compressed packs under objects/packs 21:57 |Lupin| pianohacker: hmm... and so ? 21:57 |Lupin| pianohacker: what is strange is that I tried to fetch the debian repository you mentionned earlier, and that worked... 21:59 |Lupin| 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 pianohacker here's my theory 22:01 pianohacker 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 pianohacker so it just interprets if it had actually found the object 22:04 pianohacker yup, and that's correct 22:04 pianohacker here's what you can do 22:05 pianohacker just remove the ErrorDocument 404 line from the OPAC section of koha-httpd.conf 22:06 pianohacker it'll be a little less user-friendly for those that get broken urls, but those aren't very common 22:07 pianohacker 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 pianohacker only theory 22:09 |Lupin| pianohacker: ok. just reading the doc from the kernelyou suggested 22:10 |Lupin| 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 pianohacker 404.pl doesn't seem to do that, though it can and should 22:12 |Lupin| aaaaaaaah 22:12 |Lupin| pianohacker: that would be done in the headers, right ? 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 pianohacker I'm off to do house chores, but will be back later; please let me know if you get it working :) 23:30 |Lupin| pianohacker: stil here. 23:30 |Lupin| pianohacker: I have fixed the 404.pl script, will send a patch 23:30 |Lupin| 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 pianohacker 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 |Lupin| pianohacker: ok 23:33 pianohacker |Lupin|: http rfc 23:37 |Lupin| pianohacker: yep, thanks...