Re: [Koha] Commentary on Paul's Koha 3.8 Release Manager proposal
Hi Ian, Great Idea. But I fear that what you propose would then lead to having Koha 4.0 be a new Perl 6, i.e. it will never come out (emmm.. no, Perl 6 will be released... some day). You will never be able to provide users with a schedule. And if all the new features are to be integrated step by step in the process. When 4.0 will be released, all its features will already be in 3.xxx. If ppl are to work on plumbings, rebasing the work and making its integration smooth needs to be quick unless you have to manage a de facto fork which leads to more overhead, less effective work. * arbitrary metadata formats (beyond MARC) * arbitrary biblio relationships * full support for authority records, including uploading through the GUI, automatic linking, explode searching and more * improvements to the borrower data structure (fewer pre-defined data fields, more flexibility) * separation of receiving and payment in acquisitions * serials import and export (MFHD, prediction patterns, etc) * many, many more things Are those things asked by users ? I think you are mixing developers and user features. When looking at the General meetings, very few USERS are coming. Why ? From a french point of view, the language frontier is really hard and the way to work is really different from the american way. Making KUDOS meet Kohala and have tight contacts should be a priority in order to make a list of features. I think our system should be user centric. But we should also entice users to sit at a table and get a list of feature in a schedule. Otherwise, you will just have wishfull thinking, and make idle promises. (It was not to come to that that I came into Free Softwares.) You could have added federated search, Full text search in documents and so on. My 2 cents. -- Henri-Damien LAURENT Le 07/09/2011 23:58, Ian Walls a écrit : Everyone, Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release Manager. The details of his document can be found here: http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38 I thoroughly agree that the time has come to start thinking beyond the next stable release, and on to Koha 4.0. Those of you who have seen either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know I'm very excited about the possibilities of where we can take Koha in it's next major iteration. However, I disagree with a couple of the details of Paul's proposal. The major disagreement is with the timeline. The proposal as it stands is to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8 releasing April 2012, and Koha 4.0 releasing Oct. 2012. I feel that going from Koha 3.8 directly to 4.0 is unwarranted. To my mind, there are many possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14 and so forth. This is supported by the actual database version numbers in Koha: the current release is actually 3.04.04; the zeros are squashed out for convenience. I would counter that, while we should continue releasing new features every 6 months on the 3.X line, Koha 4.0 should be defined by it's features. Paul's proposal calls several features to be key, including Solr integration, database abstraction, updated online help, improved authentication stack and automated tests. I agree that all these things are important and should be worked towards, but I'm not convinced they should be the sum total of the changes that define Koha 4.0 I would like to see the following in Koha 4.0: * arbitrary metadata formats (beyond MARC) * arbitrary biblio relationships * full support for authority records, including uploading through the GUI, automatic linking, explode searching and more * improvements to the borrower data structure (fewer pre-defined data fields, more flexibility) * separation of receiving and payment in acquisitions * serials import and export (MFHD, prediction patterns, etc) * many, many more things I think that the community should meet and discuss what features are both desirable and reasonably likely to be completed in the next few years (is there interest by libraries to sponsor these developments, or from developers to code it for fun?). Once a feature set is agreed on to define Koha 4.0, the developers of these features would meet to hash out what underlying structural changes would be required to make them happen. Hopefully commonalities could be found, so that the underlying structure could be developed in a way that accommodates multiple developments at once. Identifying these prerequisite changes early on would reduce the difficulties of rebasing developments, since we'd all be working off a similar set of base assumptions. It would also provide a reasonable basis for excluding or delaying developments that don't fit into the overall plan. Once the features were chosen and a framework for their development
Re: [Koha] 403 error with Koha 3.4.4
I got 403 error fixed by commenting out the following two lines from httpd.conf: Directory / Options FollowSymLinks AllowOverride None #Order deny,allow #Deny from all /Directory They seem to be the ones causing virtual hosts not to work. There's another problem now, but I'll post a new thread about it :D -- View this message in context: http://koha.1045719.n5.nabble.com/403-error-with-Koha-3-4-4-tp4778142p4781858.html Sent from the Koha - Discuss mailing list archive at Nabble.com. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] 3.4.4. woes continue... :(
This is what 3.4.4 throws on me when I try to access the Koha intranet: Software error: syntax error at /usr/share/koha/lib/C4/Search.pm line 497, near $data ~ syntax error at /usr/share/koha/lib/C4/Search.pm line 498, near }- syntax error at /usr/share/koha/lib/C4/Search.pm line 498, near ++; syntax error at /usr/share/koha/lib/C4/Search.pm line 511, near } Compilation failed in require at /usr/share/koha/lib/C4/Heading.pm line 26. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Heading.pm line 26. Compilation failed in require at /usr/share/koha/lib/C4/Biblio.pm line 38. Compilation failed in require at /usr/share/koha/lib/C4/Reserves.pm line 26. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Reserves.pm line 26. Compilation failed in require at /usr/share/koha/lib/C4/Circulation.pm line 26. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Circulation.pm line 26. Compilation failed in require at /usr/share/koha/lib/C4/Overdues.pm line 26. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Overdues.pm line 26. Compilation failed in require at /usr/share/koha/lib/C4/Members.pm line 29. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Members.pm line 29. Compilation failed in require at /usr/share/koha/lib/C4/Auth.pm line 30. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Auth.pm line 30. Compilation failed in require at /usr/share/koha/intranet/cgi-bin/mainpage.pl line 23. BEGIN failed--compilation aborted at /usr/share/koha/intranet/cgi-bin/mainpage.pl line 23. For help, please send mail to the webmaster (webmaster@koha), giving this error message and the time and date of the error. What? Why? -- View this message in context: http://koha.1045719.n5.nabble.com/3-4-4-woes-continue-tp4781863p4781863.html Sent from the Koha - Discuss mailing list archive at Nabble.com. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] 3.4.4. woes continue... :(
On 8 September 2011 21:38, Perch j...@pk.dy.fi wrote:
This is what 3.4.4 throws on me when I try to access the Koha intranet:
Software error:
syntax error at /usr/share/koha/lib/C4/Search.pm line 497, near $data ~
syntax error at /usr/share/koha/lib/C4/Search.pm line 498, near }-
syntax error at /usr/share/koha/lib/C4/Search.pm line 498, near ++;
syntax error at /usr/share/koha/lib/C4/Search.pm line 511, near }
Compilation failed in require at /usr/share/koha/lib/C4/Heading.pm line 26.
BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Heading.pm line
Looks to me like your upgrade/install didn't complete right.
rorohiko:[git/v3.04.04-]:~/git/koha% git checkout v3.04.04
HEAD is now at de9926a... Updating Version Number to 3.04.04.000
rorohiko:[git/v3.04.04-]:~/git/koha% perl -c C4/Search.pm
C4/Search.pm syntax OK
So I checked the tarball also
rorohiko:/tmp% wget http://download.koha-community.org/koha-3.04.04.tar.gz
rorohiko:/tmp% tar xzvf koha-3.04.04.tar.gz
rorohiko:/tmp% cd koha-3.04.04
rorohiko:/tmp/koha-3.04.04% perl -c C4/Search.pm
C4/Search.pm syntax OK
Hmmm, I think I might know the problem
What version of perl are you using?
Line 497 is unless ( $data ~~ @used_datas ) {
The ~~ is a binary smart matching operator, which doesn't exist in 5.8.8.
Chris
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] 3.4.4. woes continue... :(
My Perl version is 5.8.8 -- View this message in context: http://koha.1045719.n5.nabble.com/3-4-4-woes-continue-tp4781863p4781935.html Sent from the Koha - Discuss mailing list archive at Nabble.com. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] 3.4.4. woes continue... :(
So that will mean a complete system upgrade for me.. Oh bugger... -- View this message in context: http://koha.1045719.n5.nabble.com/3-4-4-woes-continue-tp4781863p4781951.html Sent from the Koha - Discuss mailing list archive at Nabble.com. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] FW: Commentary on Paul's Koha 3.8 Release Manager proposal
I think both proposals (from Paul and Ian) contain very good points, are ambitious and motivating for the community. With people like Ian and Paul in the release team, we will definitely reach a Koha 4.0! I would however not favor working in parallel on Koha 3.8 and 4.0 as well as maintaining 3.6.X (and possible even 3.4.X for a while). I think that three or four versions together with lowering quality standards will not result in a better product, but could imply more bugs, rebasing problems and time lost on synchronizing between versions, testing in multiple versions, etc. Why not keep it simpler? Develop in master (heading to 4.0 and solR), and keep 3.6.X stable (as soon as 3.6.X is there, declare 3.4.X end-of-life too). Just focus on those two versions. A long feature list for 4.0 is very nice and Ian's development plan may theoretically be the best way to go, but probably hard to realize in practice. A simpler approach would be: as soon as solR and searching is ready and stable, we reach 4.0. This could be after 3.8, 3.10, .. (Stick to the 6m cycle.) We have been growing into a higher QA standard when we came from 3.2. I think it would be a pity if we already lower that standard too quickly. A problem is obviously the longer time between submission and pushing. Probably, we could improve in that area by adding some persons at the QA level (Ian may have two assistants in 3.8?), asking the bug wranglers to test older patches first and let them communicate more about these patches, and doing QA first on these older signed patches. Currently, time does not really rule selection of a patch in signoff or QA, but other factors like author, size, attractive title, etc. At the same time we could allow people perhaps to sign the more easy, trivial patches themselves (especially if they have them running in production already somewhere). If QA would disagree, they could lower the patch status back to Needs signoff for getting another external test. We could make a proposal how to change current procedures for this without compromizing quality. What we should avoid, is large, very large patches without test plan. These patches did not come through now too. Which is quite understandable. Such patches should be broken up into manageable units with a test plan. Hope this helps, Marcel Everyone, Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release Manager. The details of his document can be found here: http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38 I thoroughly agree that the time has come to start thinking beyond the next stable release, and on to Koha 4.0. Those of you who have seen either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know I'm very excited about the possibilities of where we can take Koha in it's next major iteration. However, I disagree with a couple of the details of Paul's proposal. The major disagreement is with the timeline. The proposal as it stands is to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8 releasing April 2012, and Koha 4.0 releasing Oct. 2012. I feel that going from Koha 3.8 directly to 4.0 is unwarranted. To my mind, there are many possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14 and so forth. This is supported by the actual database version numbers in Koha: the current release is actually 3.04.04; the zeros are squashed out for convenience. I would counter that, while we should continue releasing new features every 6 months on the 3.X line, Koha 4.0 should be defined by it's features. Paul's proposal calls several features to be key, including Solr integration, database abstraction, updated online help, improved authentication stack and automated tests. I agree that all these things are important and should be worked towards, but I'm not convinced they should be the sum total of the changes that define Koha 4.0 I would like to see the following in Koha 4.0: * arbitrary metadata formats (beyond MARC) * arbitrary biblio relationships * full support for authority records, including uploading through the GUI, automatic linking, explode searching and more * improvements to the borrower data structure (fewer pre-defined data fields, more flexibility) * separation of receiving and payment in acquisitions * serials import and export (MFHD, prediction patterns, etc) * many, many more things I think that the community should meet and discuss what features are both desirable and reasonably likely to be completed in the next few years (is there interest by libraries to sponsor these developments, or from developers to code it for fun?). Once a feature set is agreed on to define Koha 4.0, the developers of these features would meet to hash out what underlying structural changes would be required to make them happen. Hopefully commonalities could be found, so that the
[Koha] 3.4.4 Perl upgrade/rebuilding perl-modules
I upgraded my Perl (compiled a new version from source) from 5.8.8 to 5.14.1,
because evidently Koha 3.4.4 needs a newer version of Perl than 5.8.8. Now
I'm having problems getting some of the required CPAN modules to install.
First of all:
HTTP::OAI wants a newer version of XML::SAX::Base. I have version 1.02,
while HTTP::OAI wants 1.04. However, when I try to upgrade it using CPAN,
all I get is a message saying: XML::SAX::Base is up to date (1.02). So, no
newer version available on CPAN?
Secondly: PDF::Reuse::Barcode wants Barcode::Code128, which it tries to
automatically install. However the installation fails (it fails if I try the
install Barcode::Code128 manually too):
Going to read '/root/.cpan/Metadata'
Database was generated on Thu, 08 Sep 2011 09:28:48 GMT
Running install for module 'Barcode::Code128'
Running make for W/WR/WRW/Barcode-Code128-2.01.tar.gz
Checksum for
/root/.cpan/sources/authors/id/W/WR/WRW/Barcode-Code128-2.01.tar.gz ok
CPAN.pm: Going to build W/WR/WRW/Barcode-Code128-2.01.tar.gz
Checking if your kit is complete...
Looks good
Writing Makefile for Barcode::Code128
Writing MYMETA.yml
cp lib/Barcode/Code128.pm blib/lib/Barcode/Code128.pm
Manifying blib/man3/Barcode::Code128.3
WRW/Barcode-Code128-2.01.tar.gz
/usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /usr/lib/perl5/perl-5.14.1/bin/perl
-MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch')
t/*.t
t/barcode.t .. ok
t/gif.t .. skipped: (no reason given)
t/png.t .. skipped: (no reason given)
Test Summary Report
---
t/gif.t(Wstat: 0 Tests: 1 Failed: 1)
Failed test: 1
Parse errors: Bad plan. You planned 0 tests but ran 1.
t/png.t(Wstat: 0 Tests: 1 Failed: 1)
Failed test: 1
Parse errors: Bad plan. You planned 0 tests but ran 1.
Files=3, Tests=4, 0 wallclock secs ( 0.05 usr 0.00 sys + 0.04 cusr 0.01
csys = 0.10 CPU)
Result: FAIL
Failed 2/3 test programs. 2/4 subtests failed.
make: *** [test_dynamic] Error 255
WRW/Barcode-Code128-2.01.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports WRW/Barcode-Code128-2.01.tar.gz
Running make install
make test had returned bad status, won't install without force
Thirdly, the installtion of Schedule::At fails:
Going to read '/root/.cpan/Metadata'
Database was generated on Thu, 08 Sep 2011 09:28:48 GMT
Running install for module 'Schedule::At'
Running make for J/JO/JOSERODR/Schedule-At-1.13.tar.gz
Checksum for
/root/.cpan/sources/authors/id/J/JO/JOSERODR/Schedule-At-1.13.tar.gz ok
CPAN.pm: Going to build J/JO/JOSERODR/Schedule-At-1.13.tar.gz
Checking if your kit is complete...
Looks good
Writing Makefile for Schedule::At
Writing MYMETA.yml and MYMETA.json
cp At.pm blib/lib/Schedule/At.pm
Manifying blib/man3/Schedule::At.3
JOSERODR/Schedule-At-1.13.tar.gz
/usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /usr/lib/perl5/perl-5.14.1/bin/perl
-MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch')
t/*.t
t/t1.t .. 1/9 # Failed test 2 in t/t1.t at line 45
# t/t1.t line 45 is: ok(!$rv ((scalar(keys %beforeJobs)+1) ==
scalar(keys %afterJobs)));
# Failed test 3 in t/t1.t at line 48
# t/t1.t line 48 is: ok(%atJobs);
# Test 4 got: UNDEF (t/t1.t at line 51)
# Expected: /thisIsACommand/
# t/t1.t line 51 is: ok($content, '/thisIsACommand/');
# Test 6 got: (t/t1.t at line 73)
# Expected: /^(_TEST_tag1)+$/
# t/t1.t line 73 is: ok(join('', map { $_-{TAG} } values %tag1Jobs),
'/^(_TEST_tag1)+$/');
# Test 7 got: UNDEF (t/t1.t at line 76)
# Expected: /testCMD2/
# t/t1.t line 76 is: ok($content2, '/testCMD2/');
# Test 8 got: UNDEF (t/t1.t at line 77)
# Expected: /testCMD3/
# t/t1.t line 77 is: ok($content2, '/testCMD3/');
t/t1.t .. Failed 6/9 subtests
Test Summary Report
---
t/t1.t (Wstat: 0 Tests: 9 Failed: 6)
Failed tests: 2-4, 6-8
Files=1, Tests=9, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.04 cusr 0.07
csys = 0.15 CPU)
Result: FAIL
Failed 1/1 test programs. 6/9 subtests failed.
make: *** [test_dynamic] Error 255
JOSERODR/Schedule-At-1.13.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports JOSERODR/Schedule-At-1.13.tar.gz
Running make install
make test had returned bad status, won't install without force
I tried installing ExtUtils::Command::MM, which went ok, but didn't help
any.
--
View this message in context:
http://koha.1045719.n5.nabble.com/3-4-4-Perl-upgrade-rebuilding-perl-modules-tp4782778p4782778.html
Sent from the Koha - Discuss mailing list archive at Nabble.com.
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha suppression of records
Margo, Thanks for the reply. We were discussing that possibility and I was wondering if having anything in the 942 subfield n suppressed it or does it have to be a 1? So is it unsuppressed if it's a 0? I really appreciate your help. Linda On 9/8/2011 11:26 AM, Margo Duncan wrote: Linda, I would change the default for 942$n to 0. Your staff will then use the correct framework, but add changing 942$n to 1 as part of their workflow. Margo Margo Duncan, MLS Systems Librarian Robert R. Muntz Library The University of Texas at Tyler 903.566.7174 | mdun...@uttyler.edu -Original Message- From: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Linda Culberson Sent: Thursday, September 08, 2011 10:46 AM To: koha Subject: [Koha] Koha suppression of records All, We are having a problem with suppression of newly created records in Koha and wonder how others are handling the work flow with newly created records and items. We have/had some of our frameworks set up where the default for the 942 subfield n was 1 so that a record when created would be automatically suppressed. But that record can't be unsuppressed, apparently and stay in that framework because when saved, the default setting puts it back to 1 - suppressed. So we were going to then leave the default framework to be unsuppressed, meaning that if a record is finished it has be be changed to default. The problem is the the 952 fields are set according to framework - because we have so many different types of materials and collections that adding new items goes much faster when you are in the right framework. But if you change a records framework to add items, then you must remember to change it back every time to get it unsuppressed again. So, our system isn't work ing. I'm having a hard time convincing the staff this isn't a bug in Koha, that it just is the way it works. So my question is, what does work? Any suggestions would be greatly appreciated. -- Linda Culberson lcul...@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha suppression of records
Margo, You're a life saver, and since the life you probably saved is my own, I am very grateful. Thanks! Linda On 9/8/2011 1:04 PM, Margo Duncan wrote: Linda, Yes, that's right. You should be able to see that in your Authorized Values. I've attached a screenshot of ours. Margo -Original Message- From: Linda Culberson [mailto:lcul...@mdah.state.ms.us] Sent: Thursday, September 08, 2011 11:57 AM To: Margo Duncan Cc: koha Subject: Re: [Koha] Koha suppression of records Margo, Thanks for the reply. We were discussing that possibility and I was wondering if having anything in the 942 subfield n suppressed it or does it have to be a 1? So is it unsuppressed if it's a 0? I really appreciate your help. Linda On 9/8/2011 11:26 AM, Margo Duncan wrote: Linda, I would change the default for 942$n to 0. Your staff will then use the correct framework, but add changing 942$n to 1 as part of their workflow. Margo Margo Duncan, MLS Systems Librarian Robert R. Muntz Library The University of Texas at Tyler 903.566.7174 | mdun...@uttyler.edu -Original Message- From: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Linda Culberson Sent: Thursday, September 08, 2011 10:46 AM To: koha Subject: [Koha] Koha suppression of records All, We are having a problem with suppression of newly created records in Koha and wonder how others are handling the work flow with newly created records and items. We have/had some of our frameworks set up where the default for the 942 subfield n was 1 so that a record when created would be automatically suppressed. But that record can't be unsuppressed, apparently and stay in that framework because when saved, the default setting puts it back to 1 - suppressed. So we were going to then leave the default framework to be unsuppressed, meaning that if a record is finished it has be be changed to default. The problem is the the 952 fields are set according to framework - because we have so many different types of materials and collections that adding new items goes much faster when you are in the right framework. But if you change a records framework to add items, then you must remember to change it back every time to get it unsuppressed again. So, our system isn't work ing. I'm having a hard time convincing the staff this isn't a bug in Koha, that it just is the way it works. So my question is, what does work? Any suggestions would be greatly appreciated. -- Linda Culberson lcul...@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Problems after upgrade to 3.4.3
Hi!
We still have the problem. check in and check out works as it
should, but after each check in or check out, we get this error
message:
"Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2835."
Our installation of Koha 3.00.03 (which worked perfet) is on another
physical server, so we can compare directly. The Marc to Koha
mapping is the same on the two servers. On the new server the file
record.abs had an extra line:
melm 952$i stocknumber
First we tried to comment that out. Then we even took record.abs
from the old server and copied it to the new one. After this we
reindexed zebra. But the problem is still the same.
Any ideas what to do
Den 07-09-2011 14:26, Lars J. Helbo skrev:
Den 05-08-2011 14:24, Olugbenga Adara skrev:
Also circulating books give the error - "Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2835." even though checking the patron's record later shows the book has been successfully checked out.
We have the exact same problem here now. Did you find a solution?
Koha version:
3.04.04.000
OS version ('uname -a'):
Linux Web 2.6.38-11-generic-pae #48-Ubuntu SMP Fri Jul
29 20:51:21 UTC 2011 i686 i686 i386 GNU/Linux
Perl interpreter:
/usr/bin/perl
Perl version:
5.010001
Perl @INC:
/usr/share/koha/lib
/etc/perl
/usr/local/lib/perl/5.10.1
/usr/local/share/perl/5.10.1
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.10
/usr/share/perl/5.10
/usr/local/lib/site_perl
.
MySQL version:
mysql Ver 14.14 Distrib 5.1.54, for debian-linux-gnu
(i686) using readline 6.2
Apache version:
Server version: Apache/2.2.17 (Ubuntu)
Zebraversion:
Zebra 2.0.44 (C) 1994-2010, Index Data ApS Zebra is free
software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of
it under certain conditions. SHA1 ID:
419ad759807269fdfa379799a051ed3a551c6541 Using ICU
SingleBranchMode is ON
--
Venlig hilsen
Lars J. Helbo
Borgergade 44
DK-8450 Hammel
Tlf.: +45 8696 9315
Mobil: +45 6133 9315
www.helbo.org
www.frijsendal.dk
www.sallnet.dk
www.salldata.dk
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Problems after upgrade to 3.4.3
By the way, I am a bit confused about this. Line 2835 in Biblio.pm
is in the middle of this procedure:
sub _AddBiblioNoZebra {
my ( $biblionumber, $record, $server, %result ) = @_;
my $dbh = C4::Context-dbh;
From the name of it, I would guess that this procedure is used for
adding new biblios on a system, which does not use zebra?
But we do use zebra and the error-message comes at check in and
check out.
Den 08-09-2011 21:51, Lars J. Helbo skrev:
Hi!
We still have the problem. check in and check out works as it
should, but after each check in or check out, we get this error
message:
"Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2835."
Our installation of Koha 3.00.03 (which worked perfet) is on
another physical server, so we can compare directly. The Marc to
Koha mapping is the same on the two servers. On the new server the
file record.abs had an extra line:
melm 952$i stocknumber
First we tried to comment that out. Then we even took record.abs
from the old server and copied it to the new one. After this we
reindexed zebra. But the problem is still the same.
Any ideas what to do
Den 07-09-2011 14:26, Lars J. Helbo skrev:
Den 05-08-2011 14:24, Olugbenga Adara skrev:
Also circulating books give the error - "Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2835." even though checking the patron's record later shows the book has been successfully checked out.
We have the exact same problem here now. Did you find a
solution?
Koha version:
3.04.04.000
OS version ('uname -a'):
Linux Web 2.6.38-11-generic-pae #48-Ubuntu SMP Fri Jul
29 20:51:21 UTC 2011 i686 i686 i386 GNU/Linux
Perl interpreter:
/usr/bin/perl
Perl version:
5.010001
Perl @INC:
/usr/share/koha/lib
/etc/perl
/usr/local/lib/perl/5.10.1
/usr/local/share/perl/5.10.1
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.10
/usr/share/perl/5.10
/usr/local/lib/site_perl
.
MySQL version:
mysql Ver 14.14 Distrib 5.1.54, for debian-linux-gnu
(i686) using readline 6.2
Apache version:
Server version: Apache/2.2.17 (Ubuntu)
Zebraversion:
Zebra 2.0.44 (C) 1994-2010, Index Data ApS Zebra is
free software, covered by the GNU General Public
License, and you are welcome to change it and/or
distribute copies of it under certain conditions. SHA1
ID: 419ad759807269fdfa379799a051ed3a551c6541 Using ICU
SingleBranchMode is ON
--
Venlig hilsen
Lars J. Helbo
Borgergade 44
DK-8450 Hammel
Tlf.: +45 8696 9315
Mobil: +45 6133 9315
www.helbo.org
www.frijsendal.dk
www.sallnet.dk
www.salldata.dk
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha suppression of records
Linda, Yes, that's right. You should be able to see that in your Authorized Values. I've attached a screenshot of ours. Margo -Original Message- From: Linda Culberson [mailto:lcul...@mdah.state.ms.us] Sent: Thursday, September 08, 2011 11:57 AM To: Margo Duncan Cc: koha Subject: Re: [Koha] Koha suppression of records Margo, Thanks for the reply. We were discussing that possibility and I was wondering if having anything in the 942 subfield n suppressed it or does it have to be a 1? So is it unsuppressed if it's a 0? I really appreciate your help. Linda On 9/8/2011 11:26 AM, Margo Duncan wrote: Linda, I would change the default for 942$n to 0. Your staff will then use the correct framework, but add changing 942$n to 1 as part of their workflow. Margo Margo Duncan, MLS Systems Librarian Robert R. Muntz Library The University of Texas at Tyler 903.566.7174 | mdun...@uttyler.edu -Original Message- From: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of Linda Culberson Sent: Thursday, September 08, 2011 10:46 AM To: koha Subject: [Koha] Koha suppression of records All, We are having a problem with suppression of newly created records in Koha and wonder how others are handling the work flow with newly created records and items. We have/had some of our frameworks set up where the default for the 942 subfield n was 1 so that a record when created would be automatically suppressed. But that record can't be unsuppressed, apparently and stay in that framework because when saved, the default setting puts it back to 1 - suppressed. So we were going to then leave the default framework to be unsuppressed, meaning that if a record is finished it has be be changed to default. The problem is the the 952 fields are set according to framework - because we have so many different types of materials and collections that adding new items goes much faster when you are in the right framework. But if you change a records framework to add items, then you must remember to change it back every time to get it unsuppressed again. So, our system isn't work ing. I'm having a hard time convincing the staff this isn't a bug in Koha, that it just is the way it works. So my question is, what does work? Any suggestions would be greatly appreciated. -- Linda Culberson lcul...@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824 attachment: suppression.PNG___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] OPAC error
Op vrijdag 9 september 2011 03:44:10 schreef u: My problem did turn out to be a database problem. I was able to track this down. Question: Does some amount of template information get stored in the database? I'm trying to understand what might have gotten corrupted within the database to result in these errors. You should post to the list for the benefit of everyone else. You don't say exactly what you tracked down about it being in the database. Templates are not stored there, but language settings are. If some of those went a bit haywire, then it could cause this kind of thing. For example, specifying a language that isn't available (this shouldn't cause problems, it should fall back to en, but maybe it doesn't work perfectly.) If you can tell us what it is you did to the database that made it work again, then maybe we can fix the problem at its source. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 signature.asc Description: This is a digitally signed message part. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] OPAC error
My situation is rather specific in that I have a backup of data from a PTFS 3.2 database which I'm trying to use with the 3.4.4 Community Koha. Our goal is to migrate away from a PTFS hosted solution to one more local, so I'm testing getting things set up here. In general, this has been working reasonably well. After getting 3.4.4 installed, I clear the database and replace the data with the PTFS version. I've done it a couple of times now and the Koha database upgrade process does a nice job of upgrading the database without too many errors. But, at least once now, I ran into the template problems which I sent to the list. I was never able to track this down, and so there could still be something lurking out there. What I did to finally clear it was to clear out the database and overlay and then upgrade once more. That cleared things for me, at least for now. If I determine anything more, I'll send to the list. Thanks, Tom On 09/08/2011 04:37 PM, Robin Sheat wrote: Op vrijdag 9 september 2011 03:44:10 schreef u: My problem did turn out to be a database problem. I was able to track this down. Question: Does some amount of template information get stored in the database? I'm trying to understand what might have gotten corrupted within the database to result in these errors. You should post to the list for the benefit of everyone else. You don't say exactly what you tracked down about it being in the database. Templates are not stored there, but language settings are. If some of those went a bit haywire, then it could cause this kind of thing. For example, specifying a language that isn't available (this shouldn't cause problems, it should fall back to en, but maybe it doesn't work perfectly.) If you can tell us what it is you did to the database that made it work again, then maybe we can fix the problem at its source. -- - Tom Hanstra Systems Administrator Hesburgh Libraries of Notre Dame Phone: (574)631-4686 213 Hesburgh Library Email: t...@nd.edu Notre Dame, IN 46556 Every day, from here to there, funny things are everywhere. Dr. Seuss - ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] open bibliographic principles
Kia ora! I took it as Oi, guys, this is neat! Go look. It seems like something kind of neat to bear in mind as we programme and design away. Philosophy, yeah, that's the ticket. :) Cheers, Brooke At 07:35 PM 9/8/2011 +0200, Thomas Krichel wrote: On behalf of the Open Bibilographic Working Group of the Open Knowledge Foundation, I would like to bring your attention to the Principles on Open Bibliographic data at http://openbiblio.net/principles/ The group continues to offer the opportunity, for both individuals and groups, to sign up to the principles. With respect, what is this? I have asked our biblio specialists, and they've not [yet] heard of your project. One of them took a quick look and told me that apart from it being a CC0 creative commons zero (i.e. disregard copyright) project, it's orientated towards URLs -- not MARC except incidentally. You want to bring [our] attention to your project, my librarians ask Does this break what we're doing? Paul Tired old sys-admin ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] barcode problem plz help
Op vrijdag 9 september 2011 04:30:42 schreef prasenjit ghosh: I installed Koha and its working. Cant generate barcodes. Using on Winxp. You're running Koha on Win XP? What version? Odds are it's very old. Unless you mean you're running your browser on Win XP, which is quite a different story. Internal server error showing whenever trying to generate barcode. barcodesgenerator.pl is as follows. Whenever running the perl module you have an error in your sql syntax.. message displaying. plz help. thanx in advance The important thing is the error message and the line number that it's on. Without that, there's probably little that can be done to help. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 signature.asc Description: This is a digitally signed message part. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
