Time Nick Message 23:37 |Lupin| pianohacker: yep, thanks... 23:33 pianohacker |Lupin|: http rfc 23:32 |Lupin| pianohacker: ok 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 off again, be back later 23:31 pianohacker most likely 23:31 |Lupin| pianohacker: I think the other error scripts have the same problem. 23:30 pianohacker ah, cool 23:30 |Lupin| pianohacker: so that it efines the status correctly, I mean 23:30 |Lupin| pianohacker: I have fixed the 404.pl script, will send a patch 23:30 |Lupin| pianohacker: stil here. 22:14 pianohacker I'm off to do house chores, but will be back later; please let me know if you get it working :) 22:13 pianohacker that's the term, couldn't remember it 22:13 |Lupin| a status line... 22:13 pianohacker it's normally HTTP/1.1 200 OK 22:13 |Lupin| ok 22:12 pianohacker kind of; it's the first line of the response, before the headers 22:12 |Lupin| s/headers/HTTP headers/ 22:12 |Lupin| pianohacker: that would be done in the headers, right ? 22:12 |Lupin| aaaaaaaah 22:11 pianohacker 404.pl doesn't seem to do that, though it can and should 22:10 pianohacker because if Apache's serving a static file, it can set the 404 Not Found response code 22:10 |Lupin| pianohacker: and why would the trick you explained about 404.html rather than 404.pl work ? 22:09 |Lupin| pianohacker: ok. just reading the doc from the kernelyou suggested 22:09 pianohacker only theory 22:09 pianohacker I believe so 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: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:06 pianohacker it'll be a little less user-friendly for those that get broken urls, but those aren't very common 22:05 pianohacker just remove the ErrorDocument 404 line from the OPAC section of koha-httpd.conf 22:04 pianohacker here's what you can do 22:04 pianohacker yup, and that's correct 22:02 pianohacker so it just interprets if it had actually found the object 22:01 pianohacker but Koha's 404 page might not be setting the 404 response header correctly 22:01 |Lupin| pianohacker: yeah... 22:01 pianohacker git fetch over http first looks for the plain object, then looks for the pack if it encounters a 404 22:00 pianohacker here's my theory 22:00 pianohacker so it probably exists, but is in the packs 21:59 |Lupin| pianohacker: the file that was not found corresponds actually to an existing commit... 21:57 |Lupin| pianohacker: what is strange is that I tried to fetch the debian repository you mentionned earlier, and that worked... 21:57 |Lupin| pianohacker: hmm... and so ? 21:56 pianohacker |Lupin|: some of the objects are stored as compressed packs under objects/packs 21:56 pianohacker no useful info 21:56 |Lupin| not sure how that can be interpreted... 21:56 |Lupin| Total 129145 (delta 90512), reused 129078 (delta 90447) 21:55 pianohacker worth a shot 21:54 |Lupin| pianohacker: perhaps I should do a git gc ? 21:54 |Lupin| pianohacker: interestingly, yeah... 21:54 |Lupin| pianohacker: it's just that I don't know how to proceed with that... 21:54 |Lupin| pianohacker: yeah I have similar syndroms with other files 21:54 pianohacker interestingly, the fetch is trying to reach nonexistent objects 21:53 pianohacker ahh, http://194.199.19.26/git/objects/49/3fba56e294684518482b270cc6b2a57eaa1d0c , from a git clone error, gives a 404 21:51 |Lupin| pianohacker: however the repo is sane: I did a git fsck --full and this reported no problem... 21:51 |Lupin| pianohacker: I did a git clone and I think I got the URL from there 21:50 |Lupin| pianohacker: well 21:49 pianohacker those folders that exist seem to work fine 21:49 |Lupin| you'll see the second takes you to the opac... 21:49 pianohacker there isn't a 34 directory in git/objects/ 21:49 pianohacker hmm 21:48 |Lupin| lynx http://194.199.19.26/git/objects/34/ 21:48 |Lupin| and then 21:48 |Lupin| lynx http://194.199.19.26/git/objects/ 21:48 |Lupin| pianohacker: try for instance 21:48 |Lupin| pianohacker: well, it does not... :) 21:47 pianohacker that should be working 21:47 pianohacker hmm 21:46 |Lupin| pianohacker: it's almost the original koha-httpd.conf, I think the only modificiation is the addition of the Aliasline 21:45 |Lupin| pianohacker: http://pastebin.com/f3e37bc93 21:45 |Lupin| pianohacker: well so far I didn't use rewrite rules for the git part, I used Alias... 21:42 pianohacker http://paste.workbuffer.org/ 21:42 pianohacker actually, if you put your koha-httpd.conf on pastebin, I might be able to help 21:42 pianohacker |Lupin|: does the Rewrite directive end in $ ? If so, it would only match /git/objects/, not /git/objects/34/ 21:37 |Lupin| pianohacker: I suspect the Alias directive and the Rewrite one do not go together well... 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 little mozilla dev quip for the translators: http://quotes.burntelectrons.org/4798 21:36 pianohacker cool 21:36 |Lupin| pianohacker: I think the problem is almost solved 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:35 pianohacker any luck? 21:35 pianohacker hallo 21:35 |Lupin| pianohacker: still trying to make the git repo visible... 21:34 |Lupin| hi again pianohacker :) 20:07 |Lupin| pianohackr|work: sokay, till soon 20:04 pianohackr|work see ya 20:04 pianohackr|work |Lupin|: possibly git-update-server-info 20:04 |Lupin| pianohackr|work: any idea what I should do ? 20:03 |Lupin| pianohackr|work: warning: remote HEAD refers to nonexistent ref, unable to checkout. 20:03 |Lupin| pianohackr|work: just one thing... 20:03 |Lupin| pianohackr|work: thanks 20:03 pianohackr|work good luck with koha, drupal and git 20:03 pianohackr|work anyway, headed home, talk to you later 20:03 pianohackr|work (no firm decision, just the general feeling of the developers) 20:02 pianohackr|work |Lupin|: in the future, we want to use Template::Toolkit 20:02 |Lupin| pianohackr|work: indeed. You said "the current templating system" because there are some plans to change that ? 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 19:59 |Lupin| pianohackr|work: impossible !? I didn't realise the situation was sobad ! I just thought it was hard to do... why impossible ? 19:58 pianohackr|work |Lupin|: under the current templating system, it would be basically impossible 19:57 |Lupin| pianohackr|work: actually I think it represents a certain deal of work to implement it... 19:57 pianohackr|work right 19:57 |Lupin| pianohackr|work: yeah, if it was implemented I could do that... 19:55 pianohackr|work you could set it to http://opac/koha/, for example 19:55 pianohackr|work ah, nvm, it could 19:55 |Lupin| pianohackr|work: here it's rather OPACBaseURL which is concerned... 19:54 |Lupin| pianohackr|work: why ? 19:54 pianohackr|work And I'm not sure a working implementation of staffClientBaseURL would fix your problem 19:53 pianohackr|work |Lupin|: probably easier to move drupal at the moment, yes 19:53 |Lupin| pianohackr|work: so I hope drupal is easier to re-locate... 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:52 |Lupin| pianohackr|work: cf. Bug 3717 I think... 19:52 pianohackr|work |Lupin|: no, that's very very hardcoded 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: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:48 |Lupin| I'm exploring... first seeing if the git port is firewalled or not... 19:48 |Lupin| thanks 19:47 pianohackr|work see http://git.debian.org/git/sane/sane-backends.git/ for an example 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:46 pianohackr|work git-daemon is an entirely separate program 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:44 pianohackr|work shouldn't cause any conflict, as the git server will only access the .git directory 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:43 |Lupin| pianohackr|work: ok 19:43 |Lupin| pianohackr|work: ah thanks ! 19:43 pianohackr|work 9418 19:43 |Lupin| pianohackr|work: do you know which port is traditionnally used ? 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:39 pianohackr|work |Lupin|: git-daemon is easy to set up and comes by default on ubuntu, but needs its own port 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:37 |Lupin| pianohackr|work: does this mean to install a specific debian package ? 19:36 |Lupin| pianohackr|work: yeah if that's not too much work, I think I'd like to do it like this... 19:36 pianohackr|work you could do that; you don't even need git-web, just a git server 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:35 pianohackr|work depends; if you want to, you could set up a git server on one of your web-accessible servers 19:34 |Lupin| pianohackr|work: I'm just wondering whether it's the quickest and easiest way to proceed... 19:34 pianohackr|work cool 19:34 |Lupin| pianohackr|work: I think ist's okay 19:34 pianohackr|work although that would make it public, not sure if that's okay 19:34 |Lupin| pianohackr|work: k... 19:33 pianohackr|work |Lupin|: would probably be easiest to upload it to a site like github.com or gitorious.org 19:33 |Lupin| pianohackr|work: any suggestion about how that could be done ? 19:32 pianohackr|work even better 19:32 |Lupin| pianohackr|work: I could perhaps make my gi repo accessible to you somehow... 19:32 |Lupin| pianohackr|work: hmm actually... 19:31 |Lupin| pianohackr|work: can you please /msg me an e-mail address where I could send the code ? 19:31 |Lupin| pianohackr|work: np, do it when you have time 19:31 pianohackr|work yup 19:31 pianohackr|work I can definitely review it, tomorrow if not today 19:31 |Lupin| pianohackr|work: yeah minor but seems really helpful indeed :) things don't need to be very elaborated to be helpful 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:29 pianohackr|work np, minor hack that's helped me 19:28 |Lupin| pianohackr|work: yeah that's okay, I think I see what you mean, it's really elegant, thanks a lot 19:28 pianohackr|work the code to support that's pretty trivial 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:27 |Lupin| pianohackr|work: ah that would indeed be an improvement 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:25 |Lupin| pianohackr|work: right... I think I may have a look to that and perhaps follow this road... 19:25 pianohackr|work there is; it's a CGI::Session 19:25 |Lupin| pianohackr|work: I understand. 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 not usually; it's just overkill for most situations 19:24 |Lupin| pianohackr|work: is that a problem ? 19:23 pianohackr|work Because the data stored there will stay there as long as the user is logged in 19:22 |Lupin| pianohackr|work: ah yes I was thinking to something like that. Why are you saying it's usually not necessary ? 19:22 pianohackr|work other, easier ways for those with access to cause you pain 19:22 pianohackr|work right 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:21 pianohackr|work |Lupin|: you can store additional information in Koha's session store, but that's usually not necessary 19:20 |Lupin| pianohackr|work: bu actually, what are the other possible ways to deal with this problem ? 19:20 pianohackr|work very true, but is it sensitive data? 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:18 pianohackr|work esp. wizards, like the guided reports module 19:18 pianohackr|work |Lupin|: that approach isn't exceptionally clean, but a lot of koha uses it 19:18 |Lupin| pianohackr|work: I'm wondering how you would store this persistent data... 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:17 pianohackr|work *far 19:17 pianohackr|work okay, makes sense so fa 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:15 pianohackr|work k 19:15 |Lupin| pianohackr|work: our library will use a home-made cataloguing/additem.pl (+ associated templae). 19:14 |Lupin| pianohackr|work: becoming more technical... 19:13 pianohackr|work yep :) 19:13 |Lupin| pianohackr|work: although sometimes there are big expectations regarding the received thing, followed by a cetain disappointment... 19:12 |Lupin| pianohackr|work: ok :) 19:11 pianohackr|work anticipating and receiving something is better than having it 19:11 |Lupin| pianohackr|work: how similar ? 19:09 pianohackr|work very similar to waiting for a package in the mail 19:08 pianohackr|work okay, yeah 19:08 |Lupin| pianohackr|work: so basically the message is that how we appreciate things depends more on transitions than on states... 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: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:05 pianohackr|work do tell 19:05 |Lupin| pianohackr|work: I was just thinking to a storry I find funny. 19:05 |Lupin| pianohackr|work: yeah looks wise... 19:03 pianohackr|work my mother is a physical therapist, is cautioning me to not work it too hard and hurt myself again 19:02 pianohackr|work |Lupin|: very much! 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 |Lupin| pianohackr|work: I see :) 19:02 pianohackr|work how are you? 19:00 pianohackr|work (comes out roughly to six weeks) 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 18:59 |Lupin| pianohackr|work: yep, got it now, thanks. 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 np. basically just for keeping the bones immobile while they mend 18:58 |Lupin| pianohackr|work: thanks 18:58 |Lupin| pianohackr|work: aaaaaaah ! 18:57 pianohackr|work http://fr.wikipedia.org/wiki/Attelle 18:57 pianohackr|work hmm 18:57 |Lupin| pianohackr|work: I'm sorry, I don't understand the word splint and my dictionnary is not very helpful... 18:55 |Lupin| good evening Ropuch 18:53 Ropuch Hello |Lupin| 18:53 pianohackr|work very good, the splint comes off at midnight 18:53 |Lupin| pianohackr|work: how are your fingers today ? 18:52 |Lupin| hello Jesse :) 18:51 pianohackr|work Hi, sébastien 18:49 |Lupin| good day all 16:10 pianohackr|work hi, Ropuch 16:10 Ropuch Hi pianohackr|work 16:03 pianohackr|work chris: around? 16:03 pianohackr|work hola, #koha 09:00 nicomo hi Ropuch 09:00 Ropuch Hi nicomo 07:31 Ropuch Morning 05:20 brendan goodnight all 04:02 chris_n2 g'night 02:49 chris_n2 :-) 02:45 * chris goes to play stickers 02:45 chris hehe have fun 02:45 Nate Ive been discovered! until monday folks.... 02:44 chris same goes for publicly attacking release maintainers, not constructive at all 02:43 chris_n2 gmcharlt: nice observation about bugs and bashing, I agree 100% 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:40 Nate yeah its not posted yet but ill look for it tommorow 02:38 Nate Nice! 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:37 chris i just couldnt resist saying 02:37 chris but if you read that last comment, and stephen's reply to it 02:37 chris dunno when it will show up 02:37 chris http://stephenslighthouse.sirsidynix.com/archives/2009/10/its_about_a_res.html 02:37 * chris just commented on stephen abrams blog 02:33 chris its a good place to try to pull together all the stuff 02:33 chris have you seen http://wiki.code4lib.org/index.php/SirsiDynix:_Integrated_Library_System_Platforms_on_Open_Source#Commentary 02:32 Nate good to hear 02:30 chris i think you sounded fine 02:30 chris sorry got distracted by a toddler 02:28 Nate ii found it 02:27 Nate my only defense mechanism is to bury my head in work in the corner and hope they ignore me 02:26 Nate im sitting in a room full of my girlfriends friends right now 02:26 Nate i tried to sound neutral but he called me right after i woke up 02:25 Nate how did it turn out 02:25 Nate do you have a link to that article 02:25 chris i see you were quoted in library journal 02:25 Nate hey chris 02:25 chris heya Nate 00:51 chris ahh it made it to linux weekly news, he's picked as far bigger fight than he meant to