A new version of the Koha 2.2 Users Guide is now available on www.kohadocs.org (in the General Information section). While still not complete, this version brings the Guide up to date for Koha 2.2.4 and adds some new user comments and information about Acquisitions. -- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com From my mail list lurking first questions include: How do I setup the database? (I think this means both the Koha part of it, and the software in general) How do I install Koha? Is it necessary for Koha to be config'd in the root HTML directory structure? Does Koha work with <webserver/database>? Does Koha do/will it eventually do <MARC/this/that/other>? Thoughts, anyone, on other common questions? NSR From then on, inside the folder you can just run cvs update and cvs commit commands without all the other stuff. Hope this makes sense Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz From command line: mysqladmin -uroot -ppassword create Koha There is a databse installation shell script included with the Koha tarball. 2. Set up a koha user and password in mysql Log in to mysql: mysql -uroot -ppassword To create a user called "koha" who has full administrative rights to the "Koha" database when autheicting from "localhost", enter the following on mysql command line: grant all privileges on Koha.* to koha@localhost identified by 'kohapassword'; Press ENTER, and if you see no errors then enter \q to quit mysql. 3. Use the mysql script to create the tables mysql -uusername -ppassword Koha < koha.mysql 3.1 Update your database tables perl updatedatabase -I /pathtoC4 4. Edit koha.conf Set the database name to what you have called your database, hostname willprobably stay as localhost (unless you are installing the database on a different machine to the webserver) User and password should be changed to reflect the username and password you have chosen above. You can include a line called "includes= " with path to your includes folder instead of entering the path in Output.pm - see example in KohaHints. 5. Copy koha.conf to /etc/ The permissions on this config file should also be strict, since they contain the database password. At a minimum, the apache user needs to be able to read it, as well as any other user that runs circ. I would suggest ownership of www-data.libadmins with no access to others.libadmins contain all users that use koha (If you set the owner as www-data u will need to make sure apache is running as www-data) 6. Create directories for scripts and html documents. Here you need to decide where your scripts and html are going to live. And edit C4/Output.pm to reflect that. Set $path= where your includes live, for example: $path="/usr/local/www/koha/htdocs/includes"; You do not need to do that if you have already entered the includes path in koha.conf (see example above) Next copy the C4 directory (in scripts/) to somewhere in your perl path eg /usr/local/lib/site_perl/i386-linux/ If you do not have sufficient access to copy the files to the default perl folder (maybe you are using your ISPs hosting server) then you can copy the modules to any other location and add a line to apache.conf like: SetEnv? PERL5LIB "/usr/local/www/koha/modules" Copy the C4 directory into the modules folder (see detailed example in KohaHints) 7. Set up your Online Public Access Catalogue (OPAC) Set up a webspace for the OPAC: For example: You might make /usr/local/www/opac ... and set a virtual host in apache to use that dir In your opac dir make a dir called htdocs, and copy everything in opac-html/ to it. Again in ur opac dir make a dir called cgi-bin and copy all the files in scripts/ that have a .pl extension to it, eg copy scripts/*.pl /usr/local/www/opac/cgi-bin/koha/ Your virtual host should be set up to use these dirs, some thing like this: <VirtualHost opac.your.site> ServerAdmin webmaster@your.site DocumentRoot /usr/local/www/opac/htdocs ServerName opac.your.site ErrorLog logs/opac-error_log TransferLog logs/opac-access_log </VirtualHost> When finished, restart apache and point your browser at opac.your.site and it should be all go (of course - if you dont have any data in the database there wont be much to see!) Find supplementary information and config examples in KohaHints 8. Set up the intranet/librarian interface Create new directories and additional httpd.conf changes to Set up another webspace. Lets call it koha. For example: In the dir you have just created make an htdocs dir and a cgi-bin dir Copy everything in intranet-html/ to the htdocs dir Copy all the .pl files in scripts/ to the cgi-bin/koha dir Make sure ur virtual host is set up to use these dirs Restart apache point your browser at koha.your.site and it should work 9. Configure SECURITY for the Librarians/Intranet Interface If you are using AuthenDBI to do your authentication, you will need to add some users to the users table in the koha database. And edit your apache conf file to use AuthenDBI on the intranet site. Otherwise, set up htaccess files in both koha/htdocs/ and koha/cgi-bin You can use general .htaccess based security. It is important though to password protect the librarians interface because from it you can delete and add items, remove borrowers fines and generally case havoc. 10. Set up Issues, Returns and Telnet interface. Since we have already copied the files in scripts/C4 into somewhere in our perl source tree We just need to now copy the scripts from scripts/telnet/ into somewhere in the executable path, eg /usr/local/bin Then its done: type circ and your away, ready to issue and return. In release 1.1.0 on there is now a webbased circulation module, So issues and returns can be done from there, or from circ. You will find some Koha config examples in KohaHints Check out KohaMiniFAQ for general, supplementary information. --- NEW FILE --- Example /etc/koha.conf file entries database=Koha hostname=localhost user=Koha pass=xxxxxx includes=/usr/local/www/koha/htdocs/includes Please note the final line (includes=path) - The path entry can be used as an alternative to manually editing the path in Output.pm file (see INSTALL manual). -------------------------------------------------------------------------------- Example apache httpd.conf entries: Koha makes extensive use of Server Side Includes (SSI): http://httpd.apache.org/docs/mod/mod_include.html If your page headers and footers do not show, then you may need to re-configure your web server. Here is an example of entries suitable for Apache httpd.conf: <VirtualHost 111.222.333.1> ServerName koha.example.com ServerPath /var/www/library DocumentRoot /var/www/library/koha/html Alias /images/ "/var/www/library/koha/html/images/" ScriptAlias /cgi-bin/koha/ "/var/www/library/koha/cgi-bin/" SetEnv PERL5LIB "/var/www/library/modules" ErrorLog /var/log/httpd/koha-error_log # # ======== koha uses Server Side Includes ========= # Normally here, use the same path as "DocRoot" above <Directory "/var/www/library/koha/html"> # AllowOverride None # # First, you MUST enable +Includes or +IncludesNoExec # Options +Includes -FollowSymlinks -Indexes # # Second, you must also configure one of following: # # 1. server-parsed content (SSI) for files ending in ".html" # AddHandler server-parsed .html # # ...OR... (not "AND" !!!!)... # # 2. Allow SSI if executable bit set using "XBitHack" # XBitHack on|off|full # # XBitHack on - any file that has the user-execute bit # - set will be treated as a server-parsed html doc. # - The "full" = "on" but, in addition, will test the # - group-execute bit. If the group execute bit is set # - then the Last-modified date of the returned file # - is sent. If group-execute bit is not set, then no # - last-modified date is sent. # - Setting this bit allows clients and proxies to # - cache the result of the request! # # For example, enable XBitHack (on) if you want to # - include non-executable content in documents like: # <!--#include virtual="/includes/footer.inc" --> # <!--#include virtual="/cgi-bin/counter.pl" --> # # XBitHack on # # Remember - do not use XBitHack if using AddHandler! </Directory> </VirtualHost> <VirtualHost 111.222.333.1> ServerName opac.example.com ServerPath /var/www/library DocumentRoot /var/www/library/opac/html Alias /images/ "/var/www/library/opac/html/images/" ScriptAlias /cgi-bin/opac/ "/var/www/library/opac/cgi-bin/" SetEnv PERL5LIB "/var/www/library/modules" ErrorLog /var/log/httpd/opac-error_log # <Directory "/var/www/library/opac/html"> AllowOverride None Options +Includes -FollowSymLinks -Indexes AddHandler server-parsed .html </Directory> </VirtualHost> Read your web server docs for more information about how Server Side Includes work. From our end, we'd want to help (a) peruvian group(s) to: a) build one or more viable regional support company (if they so desire) b) add functionality, make adding functionality easier c) become part of a larger (international) koha foundation which is tasked with guiding the growth of koha and the larger koha community. Thank you for your time and efforts. I'll look forward to hearing from you soon. Mucho gusto, -pate@gnu.org Pat Eyler [1] koha is licensed under the GPL, you can find more information (in English) at www.koha.org From the librarian's point of view, this change would just require a different template. The small library librarian doesn't need to know that her data is being stored in a MARC-compatible format. It always shows up in a simple bibliographic format on her screens. In other words, having a MARC compatible back end means we allow large libraries to use Koha, without impacting the small libraries which can already use Koha. From the developer's standpoint, things are considerably different. I would have to agree that switching to a marc database is going to raise the bar for new developers to work on the Koha code. Many new developers will come to Koha with no knowledge of MARC, and MARC can be daunting. I'm hopeful that we can develop a cataloguing API that will alleviate some of these problems. It should be possible for us to develop some routines that "hide" the marc format of the data from the developers to a certain extent. As an overly simplistic example, we could have a routine like: getinfo(1563,'author') returns Herman Melville from the 100 a subfield getinfo(1563,'title') returns Moby Dick from the 245 a subfield setinfo(1563,'author', 'Melville, Herman') updates author info Here the number 1563 would be the bibid of the item in question. Steve Tonnesen Here are some direct responses to your comments. The numbered items represent your comments (paraphrased by me in some cases, hopefully I didn't mess them up) followed by my comments: 1. acqui.simple and marcimport.pl == MARC compatible acqui.simple and marcimport.pl will import marc records and "squash" the data into the standard Koha database. There can be considerable loss of information in this process. In my mind, MARC compatible means that we can import, export, view, and edit bibliographic records in MARC format. Note that it doesn't mean that we _have_ to view and edit in MARC format, just that we _can_. 2. Use Marc tables only for data that is not already represented by the koha databases. I think this is a bad idea. It'd be too confusing about what information was stored where. 3. Storing Koha-specific data in local Marc tags, just for the sake of saying it is all Marc, seems to me to be arbitrary and inefficient. My reason for storing koha-specific tags in the marc data is just so that existing libraries can switch to the new database without losing the functionality that they expect Koha to have. Primarily this means tying individual marc records together based on their "copyright" information as it is stored in the current biblio table. Currently, Romeo and Juliet by Shakespeare could be in the library in seven different formats (different publications, video, audio, etc.) each of which has a separate biblioitems entry, but all of which share one biblio entry. I proposed added a local marc field that would tie the separate MARC entries for all 7 formats of this work together as well. 4. You give some examples of what you think a search query would look like with the new MARC data and state, "As a programmer, I cannot see this being practical for my skill set to work on. I really just want to be able to select columns from tables in a reasonable manner." First off, searches will never be done directly on the MARC data storage tables. That would be too slow. I envision separate indexes being generated to facilitate searching. It would be easy, for example, to create an index that contained the following information: bibid, title, author, dewey, isbn Then a search for bibid would be identical to the search that you gave in your example using the koha database. Not that you could potentially lose information stored in the marc record if there is more than one author, for example. These "seach indexes" are still vaporware. Paul and I are trying to work out the specifics of what the new backend database will look like. 5. You mention MARC-XML and suggest that we not tie ourselves to the MARC format. We are not proposing that bibliographic data be stored in MARC format, only that the back end database be capable of storing any and all information that a MARC record can store (whether it is a conventional MARC record or the as-yet-unspecified MARC-XML format record). The existing MARC format is just a flat file that uses control character separators and a directory index for the tags. The MARC-XML specification will be the same format, but will use XML tags for separating the data instead of control characters. We would not want to use either of these formats internally, although we would probably want to be capable of importing/exporting those formats.
I don't want to sound harsh, but frankly, if this is the goal, I'd like to know now so I can wish you good luck on it and look elsewhere for something that fits me better. Thanks for taking the time to discuss it.
Switching to MARC is a big undertaking and it should be well thought out. I appreciate your comments. Steve. From my POV these projects have probably gone past the "negotiation" stage unless whatevers wanted isn't going to cost any additional hours. I'd like to see these features go into the general release as soon as possible after they are installed and verified as working on the client sites, so that they get the satisfaction of seeing them released on the list etc (good feel good factor), and nice for the list to see development. I perceive that our work is somewhat at odds with the current versioning system on the Road Map, because we will have things ready before the rest of the release is probably even scheduled to be ready. I'm afraid I've already been acting the benevolent dictator to some extent, and for example have had my designers working on a new koha.org site over the last few months. It has been a project for my designer to practice her HTML on. Cheers Rachel _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org From the main Koha mailing list:
From: "Rachel Hamilton-Williams" <rachel@katipo.co.nz>
4) printing out bibliographies of holdings, such as a list of books we have on science experiments
I would say at the moment there isn't a specific report written to do this. The Horowhenua Library use a product called UrbanSQL which they use to run a variety of reports - I couldn't say wether this is one that they run.
Here's one to keep in mind for MARC-ification. We're really going to need to keep simple, normal database tables which a "power user" can use with simple SQL reporting tools other than Perl. There's no way any mere mortal will be able to navigate the new proposed MARC biblio structure with a report writer. I know Steve already mentioned planning for simplified search tables from the Marc data; let's just make sure they aren't an after-thought later :-) - Alan From our Government guidelines (keeping in mind that many Libraries here and in other countries are run by local or central Government) It is acceptable to use cookies only where absolutely necessary for the function performed (e.g. personalisation or e-commerce). Cookies should not be required for random searching or browsing. Agencies should understand (and document in detail) the purpose of any cookies used on their site. Agencies should not require the use of cookies for access to the base functionality of the site. Many users tend to have cookies turned off to avoid privacy invasion by commercial sites. If agencies are relying on cookies to provide visitor statistics, these users will not show and the statistics will be inaccurate. The site should contain a clear statement of policy on the use of cookies including why they are being used and what information is being recorded or relayed. Sites should not collect user information unless it is required for the business of government that the user wishes to undertake. Agencies should also undertake to advise users explicitly if information collected is to be shared with other agencies.
Here's my proposal for authentication. I hope this will help with the anti-cookie people in the crowd.
Note, after writing all this out, I found a module called mod_auth_tkt which apparently does most of the cookie part of this. Might be better to implement it ourselves, as it makes one less apache configuration problem on installation.
1. Every script calls a checkauth($query) routine before doing anything else.
2. checkauth() checks for a $ENV{'REMOTE_USERNAME'} environment variable. a. If one is set, assume that basic authentication of some sort is being used b. check that this user is allowed to be running this script. If not, print a warning page and exit (possibly redirect to library home page or somesuch?). c. return a zero value and the userid logged in and the script carries on.
3. checkauth() looks for the value of a sessionID cookie in the $query hash. a. If it doesn't find one: * present a log in screen where the user can enter a username and password. * The name of the original script and any query parameters are stored as hidden query params. * authentication script checks the entered username and password against a configurable authentication source (eg local mysql table, passwd file, ldap, pop server, you name it) and stores the sessionID, userid, remote ip address and lastcontact (current time) in the sessions database table. b. If it finds one: * look up the userid, ip address and lastcontact values from a database table (sessions) for this sessionID. If ip address is the same, and lastcontact is recent enough for this category of user (eg librarians might time out after 30 minutes, patrons after 5 minutes) then return a zero value, the userid logged in, and a cookie to be added to the HTML header and the script carries on. * If ip address is different, display a warning page and exit. (Note that this doesn't prevent the same user from logging in from two different ips simultaneously, as they would normally have different sessionIDs. It just protects (somewhat) against somebody hijacking the cookie and the session. * If lastcontact time has expired, remove the session from the sessions table and display a login screen (as in 3a above).
Modifications to existing scripts consist of calling:
my ($userid,$cookie)=checkauth()
at the top of every script and changing:
print $input->header;
to
if ($config->{'usecookieauth'}) { print $input->header(-cookie->$cookie); } else { print $input->header; }
Steve.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
_____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org From an admins point of view, the ideal would be to have the list of servers stored as a flat text file in /etc/koha/ so that commandline Junkies, like myself can edit the list with vim and cat the list to mail and all sorts of other mundane admin tasks. But this more of an enhancement than a bug. Thanks. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From koha-error_log: attempt to revoke directory as script: /var/www/html/koha/intarnet/cgi-bin (same for opac-error_log) Ville Huhtala From the Sky" ? I've never heard of this ???<br> <br> <blockquote type="cite" cite="midPine.LNX.4.44.0208280748350.5195-100000@petrol.whirlycott.com"> <pre wrap="">-pate </pre> </blockquote> --<br> Paul<br> </body> </html> --------------010201050300090903020608-- From apache opac-*_log I get: --------------67C033FA5068E2C56A07001A Content-Type: text/plain; charset=us-ascii; name="opac-access_log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="opac-access_log" 192.168.0.38 - - [07/Sep/2002:20:16:12 +1000] "POST /cgi-bin/koha/userpage.pl HTTP/1.0" 302 0 --------------67C033FA5068E2C56A07001A Content-Type: text/plain; charset=us-ascii; name="opac-error_log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="opac-error_log" DBD::mysql::st execute failed: Table 'Koha.sessions' doesn't exist at /usr/local/koha/intranet/modules/C4/Auth.pm line 74, <KC> line 20. DBD::mysql::st fetchrow failed: fetch() without execute() at /usr/local/koha/intranet/modules/C4/Auth.pm line 76, <KC> line 20. DBD::mysql::st execute failed: Table 'Koha.sessions' doesn't exist at /usr/local/koha/intranet/modules/C4/Auth.pm line 81, <KC> line 20. DBD::mysql::st execute failed: Table 'Koha.sessionqueries' doesn't exist at /usr/local/koha/intranet/modules/C4/Auth.pm line 85, <KC> line 20. DBD::mysql::st execute failed: Unknown column 'password' in 'field list' at /usr/local/koha/intranet/modules/C4/Auth.pm line 255, <KC> line 20. DBD::mysql::st fetchrow failed: fetch() without execute() at /usr/local/koha/intranet/modules/C4/Auth.pm line 257, <KC> line 20. DBD::mysql::st execute failed: Unknown column 'password' in 'field list' at /usr/local/koha/intranet/modules/C4/Auth.pm line 263, <KC> line 20. DBD::mysql::st fetchrow failed: fetch() without execute() at /usr/local/koha/intranet/modules/C4/Auth.pm line 265, <KC> line 20. DBD::mysql::st execute failed: Table 'Koha.sessions' doesn't exist at /usr/local/koha/intranet/modules/C4/Auth.pm line 141, <KC> line 30. DBD::mysql::st execute failed: Table 'Koha.sessions' doesn't exist at /usr/local/koha/intranet/modules/C4/Auth.pm line 143, <KC> line 30. DBD::mysql::st execute failed: Table 'Koha.sessionqueries' doesn't exist at /usr/local/koha/intranet/modules/C4/Auth.pm line 145, <KC> line 30. DBD::mysql::st fetchrow failed: fetch() without execute() at /usr/local/koha/intranet/modules/C4/Auth.pm line 147, <KC> line 30. DBD::mysql::st execute failed: Table 'Koha.sessionqueries' doesn't exist at /usr/local/koha/intranet/modules/C4/Auth.pm line 149, <KC> line 30. --------------67C033FA5068E2C56A07001A-- From link: http://syy059.oulu.fi:8080/cgi-bin/koha/search.pl?startfrom=10&title= --> You did not specify any seach criteria 0 results found --> arrow back [<-] http://syy059.oulu.fi:8080/cgi-bin/koha/search.pl?startfrom=0&type=intra goes nowhere Manual correction gives expected results http://syy059.oulu.fi:8080/cgi-bin/koha/search.pl?startfrom=10&title= http://syy059.oulu.fi:8080/cgi-bin/koha/search.pl?startfrom=10&title=%20 * catalog author search 'the' Directly from icon (page [2]): see above Next Records from link and arrow [->] works. Ville Huhtala From the Kaitiaki: Welcome to the new and improved newsletter. 'he panui koha' means (roughly) 'the news of Koha'. I've found that it's becoming harder to track all of the things that have been going on in the world of Koha. To ensure that you get all the news you want, I'm going to be trying something new starting next week. I've asked several people to take on the responsibility of writing a short section for the newsletter. Each week, I'll collate their sections into a single newsletter and send it out. 1.4: The 1.3.0 has been released a few weeks ago. The 1.3.1 will come very soon. bugfixes, and it will add management tools for MARC parameters, and a first draft of MARCdetail. Then, we will continue toward 1.3.2 which will add MARC add and modify of biblios. The french UNIMARC parameters tables should be avaible a few days after the 1.3.1 release, but won't be integrated during installation process (maybe in 1.3.2). Docs: The developer level documentation (POD) written by Andrew Arensburger and others (Thanks guys!), is now being auto posted to http://www.kohalabs.com/resources/pod/ -- the documentation is rebuit from source every night to ensure the most up-to-date information is available. Koha in the news: Koha made the news again this week. Marshall Breeding wrote a somewhat negative piece about Open Source in libraries for Information Today (http://www.infotoday.com/it/oct02/breeding.htm) which was also picked up by LinuxToday (http://linuxtoday.com/news_story.php3?ltsn=2002-10-09-014-26-RV-SW-PB). The feedback at LinuxToday was mixed. It seems we have a long road ahead of us to convince people that open source can make as big a dent in the ILS market as it has in the webserver and operating systems markets. Community: As more libraries have begun looking into Koha, we've started testing it with bigger data sets. One library is testing Koha themselves with over 450,000 items in their database. A developer is also testing Koha against a collection of just over 2,000,000 items. Another development aimed at overcoming the obstacles to wider koha adoption is the Koha2010 project, which gets its name from the Oregon Library Association's 'Vision 2010' strategic plan. This project is aimed at building a dialog between koha developers, librarians, and library associations to guide the development of Koha. My intent is to ensure that Koha can fulfill all the requirements of these groups strategic plans for the next 5-10 years. If you'd like to join the conversation, please send an email to koha2010-subscribe@kohalabs.com and follow the directions you get in return mail. You can also see http://www.kohalabs.com/projects/koha2010/ for more information. From the Kaitiaki: Wow! Thigs are continuing to move quickly. More libraries seem to be looking at Koha, and a couple of vendors are starting to show it to libraries as well. This week's edition of the news came together pretty easily, and I think it covers the scope of the project and community much better than I could on my own. Thanks to all those who ptiched in. 1.4: The 1.3.x team is proud to announce the birth of the breeding farm. The breeding farm is a place where you can place (lot of) MARC records in 2 clicks. they stay in the breeding farm as long as you have no items for this record. When you want to add an item in koha, you enter ISBN/ISSN of the book. If the book is in the breeding farm, it's immedialty called, and entering a biblio is very quick (you just have to modify what you want). This functionnality is avaible only in CVS currently, but will be ready for 1.3.2 in around 2 weeks. Note: This functionnality is not intended for migrating a library to Koha - to do this (migrating biblios AND items, you need to use bulkmarcimport, avaible in 1.2 and that will be completed/rewritten in 1.3) Docs: Thanks to some thoughts and work from Steve and Finlay, in short order The SGML version(s) of the full manual will be uploaded via a nifty form to Sourceforge, where the files will live in their own CVS tree (to keep them a little away from the code). Steve has thrown together something already: http://www.haz.cmsd.bc.ca/cgi-bin/kohadoc/upload This will let us run the SGML->HTML and HTMLtidy routine as part of the buildrelease scipt, since the "most recent" manual will be in CVS. ThemeHowTo/ThemeNotes will be marked up into SGML format, and will join the manual (developer section) soon. Ditto info on the POD stuff (http://www.kohalabs.com/resources/pod/). Transitions will most likely be getting a contribution re: how to move out of the "Winnebago" package. How to do a language template is not as far along, but as there is existing stuff from Katipo on how to use Kea, I don't anticipate huge problems doing the same for that material. I'm hoping to have the above done/proofed/final for the next stable release (1.3.something I guess). Developers: Especially NEW developers, please check the *current "released" manual* if you haven't do so already. We *want* to credit you, and spell your names correctly. Thanks. That goes especially for our new language contributors. Community: There were three big items from the community this week. One of the Win32 developers has not only gotten Koha running on several versions of windows, but he has put together a Win32 installer. If you're interested in helping work on this, please join the koha-win32 mailing list at: http://www.sourceforge.net/projects/koha/ Please take some time and fill out the survey that was posted to the mailing list recently. Getting the word out about Koha is one of the most important steps in keeping the development and user community flourishing. It's also a very easy way to contribute. Marshall Breeding's request earlier this week was another, similar, way to contribute to the long term success of Koha. In some ways it might be more visible. Marshall's site gets a lot of eyes. If Koha looks good there, it will be a big plus. French Koha: Thanks to several worthy librarians, we now have a CSV file of the whole UNIMARC tables : UNIMARC compliance will really help to make Koha a viable alternative to commercial ILS in France. UNIMARC is the standard used in libraries, from the Fench National Library to the smallest public libraries. This is a major step forward for the project in France. Another, smaller step forward that occured this week is the translation of the koha web site in French : it will soon go live at http://fr.koha.org. It will help us publicize all Koha related business in France, and provide a resource center for French libraries interested in Koha. All in all, it's been another great week. thanks, the Koha team From the Kaitiaki: Sorry that it's been so long since I've put one of these out. It always seems like something else gets in the way, doesn't it? Hopefully the breadth and importance of the news below is engaging enought for you to forgive my lapse in sending things out lately. Development: Paul is closing in on the next 1.3 release and Steve is plugging away at the next 1.2 release, but the biggest development news this time around is administrative. We've decided that the 1.3 series is such a radical departure from the existing 1.2 stuff, that it will become Koha 2.0 instead of 1.4. This release marks a watershed for us, and deserves the recognition that 2.0 will give it. Congratulations to Paul and everyone else who has been involved in the 1.3 work. Community: Chris Cormack (the release manager for the 1.2 series) recently attended two conferences in Ohio, here's what he had to say: Well I think the trip went really well, Stephen and the rest of the NPL are feeling even more positive now. The OLC conference was good lots of interesting topics and tho we were the last session on the last day. We still had about 20-30 people stay to listen about koha. Got to the think linux show the next day and got my pass and stuff. Listened to the Linux terminal server project and other thin clients. Interesting stuff for libraries, specially coupled with the cool serial over ip hubs they were showing off as well. Then came the presentation, I didnt end up using my slides because they were aimed at a more libraryish audience. So I talked about koha, explaining what a library system is to start :-) Then did the history of koha, were we are at now, how they can help, how to get it etc. About 25 people listening. People drove in from Michigan and from Grandview Heights (near Columbus, Ohio), three to four hour drives for both groups, just to talk about Koha and how it might fit into their libraries. (One of the libraies is a consortium that has a circulation of about 1.5 million a year! They'll both be in touch with NPL and Koha. All in all a very positive trip it was heartening how many people had heard of the project. And the guy from debian was keen to get koha into the distro. Koha also had a stall (manned by Katipo and HLT) at the 2002 Lianza conference http://www.confer.co.nz/lianza2002/ -- way to go! On a different tack, I'd like to welcome The Linux Box (http://www.linuxbox.nu/) of Ann Arbor, Michigan as the newest vendor offering commercial support for Koha. If you are interested in supporting Koha, please let me know. We'd be happy to add you to our support vendors page at http://koha.org/installation/support.html French Koha: Paul Poulain has announced that demo.koha-fr.org and fr.koha.org are now live. The first is a demo site where you can play with the emerging 1.3 series (it's especially nice to see that Koha is becoming bilingual). The second site is the french language home for Koha. These efforts are both huge wins for Koha in terms of visibility. Nicolas Morin wrote: And the other day I went to a formation session on library web sites: it turned out every single librarian attending (a group of about 20 people from different libraries) knew that Koha existed : "isn't it that open source library system that's talked about?" So I think librarians awareness about Koha is good here in France : but to really take off we would need one first library to use it. I think what worked well in France so far is that, so to speak, we played a duet : one programmer who can answer questions about the software, the install, etc; and one librarian that can publicize Koha and get colleagues interested. Couldn't we try to set up such "duets" elsewhere? This does look like a good model to follow within our other language translation groups. The french community Koha mailing list is up to 51 subscribers, and there seems to be a great deal of work and excitement on it. Two last bits of news from the french koha community: * the templating of the OPAC now being over, translation of the OPAC will begin very soon : to start working on the translation of the software itself is obviously a major step towards implementing Koha in France. * This week also, Koha-France contributed a list of report features we would love to see implemented in Koha : see http://www.saas.nsw.edu.au/wiki/index.php?page=ReportFeatures for this list. Any contribution to this list is welcome. If you want to get involved, the Koha wiki is a good place to look at : http://www.saas.nsw.edu.au/wiki/index.php?page=KohaProject thanks, the Koha team From a cursory glance of Auth.pm and Security.pm, it seems that user names are stored in uppercase and passwords are MD5-hashed, but I can't seem to be able create a valid user to log on to the librarian interface. Thanks very much! --=20 Ambrose Li <a.c.li@ieee.org> http://ada.dhs.org/~acli/cmcc/ http://www.cccgt.org/ DRM is theft - We are the stakeholders From the mysql documentation When you distribute a non-GPL application that only works with the MySQL software and ship it with the MySQL software. This type of solution is actually considered to be linking even if it's done over a network. Since we neither ship Koha with MySQL, nor is Koha non-GPL. The license is not an issue. And Koha and MySQL being GPLd prevents it from ever becoming one. The technical constraint is the actual issue, and im not against binding koha to specific db in principle. If the benefits gained are such to warrant the disadvantages. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz From the Kaitiaki: Another week, and another bunch of work getting done. Two items that've come up a bit recently are a need for more and better administration tools and a reorganization of the Koha source code. The first should help make Koha much easier for a library to manage, allowing changes to be made without having to dive into the database itself. The second should help the developers by cleaning up the structure they have to work with every time they fix a bug or add a feature. I'm anxious to see the fruits of both efforts. Community: Paul has started a french language complement to the koha-translate mailing list. His comments are pertinent: when a developper modifies a template (which happends yesterday from me), i think translators should be informed. As translators are not necessary following the koha-cvs ml, i think we should create a koha-translate ml, for translators. note : i'm happy to announce creation of traduction@koha-fr.org for french translators and technique@koha-fr.org for french developpers. The main translation list can be subscribed to from: http://lists.sourceforge.net/lists/listinfo/koha-translate France: Nicolas Morin has talked to two libraries in New Caladonia who are starting to work with Koha. He'll be releasing a longer article about it shortly, but here are some of the highlights: * the first library has two branches 12 kms apart, amounting to 600 meters square (1800 meters square in 2005), 35000 documents, with a yearly increase of 5000 ocuments. It's run by a team of 10 people. A small library, but growing steadily. * the second library is run by a 38 people strong team, has 74000 documents, did 260.000 transactions in 2001. Both libraries are jointly considering the switch to Koha. Among their motives, they listed: * the GPL license that would allow them to install Koha in rural and often poor areas that could not pay for a proprietary system, and thus increasing the value of their network * the openness of the source code, that would allow local businesses or the university computer people to support the system Both libraries will evaluate Koha and test it in the coming months. Meanwhile Christophe Augias, head of the second library, couldn't wait and got involved in the french translation team... Documentation: I need technical proofing volunteers (particularly people who have just done installs) for comment on the next version of the manual. Another attempt to make sure I've got every contributor in the CREDITS will occur after the tech proofread. The next edition of the manual is going to try to sit a little on the fence so as to cover the versions out there (the 1.3/devel-test and 1.2/stable). thanks to everyone involved in the project, -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha From the Members page for a particular member (e.g., http://intranet.example.org/cgi-bin/koha/moremember.pl?bornum=1), if we press Cancel Requests, bornum is reset to the null string, resulting in Koha losing track of which member is being currently viewed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From marcmanip.pl I got absolutely no results, and from MARC::Lint I only got a few minor warnings (see attached). I'm wondering why this was so: I believe that each record has an 001 field, and that its value in each case is the character string "ocm" followed by the OCLC record number. Since we would somehow need to get our MARC records from OCLC CatME into Koha, I'm wondering about several things: 1. Can anyone detect what is wrong with this set of 15 MARC records? The marcmanip.pl script seems to be bypassing the 001 fields for some reason. 2. Koha presently seems to require a number value for the key field biblionumber in the biblio table, and it seems like this should correspond to the 001 field of the MARC record. Has anyone devised a method of taking a single exported OCLC record or a batch of exported OCLC records, changing the OCLC record number-based 001 field to a value acceptable to Koha, and then loading these MARC records into Koha? Larry Currie -- Lawrence W. Currie User Services Librarian California Academy of Sciences Golden Gate Park San Francisco, CA 94118 lcurrie@calacademy.org (415) 750-7108 (415) 750-7106 fax http://www.calacademy.org/research/library/ --------------D05F0D0C273D511FA9BB9D75 Content-Type: application/x-unknown-content-type-dat_auto_file; name="mar142003.dat" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mar142003.dat" MDEyMThjYW0gIDIyMDAyODlJYSA0NXgwMDAxMDAxMzAwMDAwMDAzMDAwNjAwMDEzMDA1MDAx NzAwMDE5MDA4MDA0MTAwMDM2MDQwMDAyMzAwMDc3MDQzMDAxMjAwMTAwMDkwMDAyMTAwMTEy MDQ5MDAyMzAwMTMzMTAwMDA0MTAwMTU2MjQ1MDE4NzAwMTk3MjQ2MDA1MzAwMzg0MjYwMDA1 ODAwNDM3MzAwMDA3ODAwNDk1NTAwMDAyMjAwNTczNTkwMDAyODAwNTk1NjUwMDAzNzAwNjIz NjUwMDAzNTAwNjYwNjUwMDAyOTAwNjk1NjUwMDAyODAwNzI0NzAwMDA4NTAwNzUyNzAwMDA3 OTAwODM3OTk0MDAxMjAwOTE2Hm9jbTEwOTM5MDI2IB5PQ29MQx4yMDAzMDMxNDEyMjAwNC4w Hjg0MDcxMXMxNzkwICAgIG5lIGFmICAgICAgICAgMDAxIDAgZHV0IGQeICAfYVRYQR9jVFhB H2RPQ0wfZENBVx4gIB9hZW4tLS0tLR4gIB9hU0IzNjAfYi5LNjYgMTc5MB4gIB9hW2ZvbGlv XUNBV0MfbDI3NjQ1HjEgH2FLbm9vcCwgSm9oYW5uIEhlcm1hbm4sH2RiLiBjYS4gMTcwMC4e MTAfYUJlc2NocmlqdmluZyBlbiBhZmJlZWxkaW5nZW4gdmFuIGRlIGJlc3RlIHNvb3J0ZW4g dmFuIGFwcGVsZW4gZW4gcGVlcmVuIDsgQmVzY2hyaWp2aW5nIHZhbiB2cnVjaHRib29tZW4g ZW4gdnJ1Y2hlbiA7IEJlc2NocmlqdmluZyB2YW4gcGxhbnRhZ2llLWdld2Fzc2VuIC8fY2Rv b3IgSm9oYW5uIEhlcm1hbm4gS25vb3AuHjEgH2lCaW5kZXIncyBzcGluZSB0aXRsZTofYU92 ZXIgdnJ1Y2h0ZW4gZW4gZ2V3YXNzZW4eICAfYUFtc3RlcmRhbSA6H2JBbGxhcnQsIEhvbHRy b3AsIERlTGVldXcgZW4gS3JhcCwfYzE3OTAuHiAgH2ExIHYuICh2YXJpb3VzIHBhZ2luZ3Mp LCAzOSBmb2xkZWQgbGVhdmVzIG9mIHBsYXRlcyA6H2Jjb2wuIGlsbC4gOx9jMzQgY20uHiAg H2FJbmNsdWRlcyBpbmRleGVzLh4gIB9hUmVjbGFzc2VkIGZyb20gNjM0IEs3NTYeIDAfYUZy dWl0LWN1bHR1cmUfekV1cm9wZSwgTm9ydGhlcm4uHiAwH2FGcnVpdCB0cmVlcx96RXVyb3Bl LCBOb3J0aGVybi4eIDAfYUFwcGxlH3pFdXJvcGUsIE5vcnRoZXJuLh4gMB9hUGVhch96RXVy b3BlLCBOb3J0aGVybi4eMTIfYUtub29wLCBKb2hhbm4gSGVybWFubiwfZGIuIGNhLiAxNzAw Lh90QmVzY2hyaWp2aW5nIHZhbiB2cnVjaHRib29tZW4gZW4gdnJ1Y2h0ZW4uHjEyH2FLbm9v cCwgSm9oYW5uIEhlcm1hbm4sH2RiLiBjYS4gMTcwMC4fdEJlc2NocmlqdmluZyB2YW4gcGxh bnRhZ2llLWdld2Fzc2VuLh4gIB9hWDAfYkNBVx4dMDA5NThjYW0gIDIyMDAyNzcgYSA0NXgw MDAxMDAxMzAwMDAwMDAzMDAwNjAwMDEzMDA1MDAxNzAwMDE5MDA4MDA0MTAwMDM2MDEwMDAx NzAwMDc3MDQwMDAxODAwMDk0MDE5MDAxMzAwMTEyMDQzMDAxMjAwMTI1MDkyMDAyNjAwMTM3 MDQ5MDAyNTAwMTYzMTAwMDAyNjAwMTg4MjQ1MDA3MzAwMjE0MjYwMDA2MjAwMjg3MzAwMDAy OTAwMzQ5NDkwMDA2MjAwMzc4NTAwMDAxOTAwNDQwNTA0MDA1NDAwNDU5NjUwMDA1MTAwNTEz NjUwMDA1MTAwNTY0ODMwMDA1MzAwNjE1OTk0MDAxMjAwNjY4Hm9jbTA0NDkyMjY1IB5PQ29M Qx4yMDAzMDMxNDEyNDY0MC4wHjc4MTAwNnMxOTc0ICAgIHBvIGEgICAgIGIgICBsMDAwIDAg ZW5nICAeICAfYSAgIDc4MTAwOTkzIB4gIB9hRExDH2NETEMfZENBVx4gIB9hMTg3Mjc4OTke ICAfYWxubWEtLS0eICAfYTUwNh9iRjk2Mk02IG5vLjI4OjEyNR4gIB9hW1NlcmlhbHNdQ0FX Qh9sZXhjaC4eMSAfYUxldnJpbmcsIFRvcmUsH2QxOTEzLR4xNB9hVGhlIG1hcmluZSBhbGdh ZSBvZiB0aGUgQXJjaGlwZWxhZ28gb2YgTWFkZWlyYSAvH2NbYnkgVG9yZSBMZXZyaW5nXS4e ICAfYUZ1bmNoYWwsIE1hZGVpcmEgOh9iQ+NhbWFyYSBNdW5pY2lwYWwgZG8gRnVuY2hhbCwf Y1sxOTc0XR4gIB9hMTExIHAuIDofYmlsbC4gOx9jMjQgY20uHjEgH2FCb2xldGltIGRvIE11 c2V1IE11bmljaXBhbCBkbyBGdW5jaGFsIDsfdm5vLiAyOCwgYXJ0LiAxMjUeICAfYSJBZ29z dG8gMTk3NC4iHiAgH2FJbmNsdWRlcyBiaWJsaW9ncmFwaGljYWwgcmVmZXJlbmNlcyAocC4g MTA3LTExMSkuHiAwH2FNYXJpbmUgYWxnYWUfek1hZGVpcmEgSXNsYW5kcx92SWRlbnRpZmlj YXRpb24uHiAwH2FNYXJpbmUgYWxnYWUfek1hZGVpcmEgSXNsYW5kcx92Q2xhc3NpZmljYXRp b24uHiAwH2FCb2xldGltIGRvIE11c2V1IE11bmljaXBhbCBkbyBGdW5jaGFsIDsfdm5vLiAy OC4eICAfYVgwH2JDQVceHTAyMzg5Y2FzICAyMjAwNTI5ICAgNDV4MDAwMTAwMTMwMDAwMDAw MzAwMDYwMDAxMzAwNTAwMTcwMDAxOTAwODAwNDEwMDAzNjAxMDAwMTcwMDA3NzA0MDAwODgw MDA5NDAxNjAwMTgwMDE4MjAxNjAwMjAwMDIwMDAxOTAwMjEwMDIyMDAyMjAwMTQwMDI0MTAz MDAwMTEwMDI1NTAzNzAwNzIwMDI2NjA0MTAwMTMwMDMzODA0MjAwMTMwMDM1MTA5MDAwMTYw MDM2NDA0OTAwNDAwMDM4MDIxMDAwMTYwMDQyMDIyMjAwMTgwMDQzNjI0NTAwMTkwMDQ1NDI2 MDAwOTEwMDQ3MzMwMDAwMjUwMDU2NDMxMDAwMTQwMDU4OTM2MjAwMjMwMDYwMzUwMDAwNDcw MDYyNjUxMDAwNTUwMDY3MzUxMDAwMzYwMDcyODUxMDAwMjkwMDc2NDUzMDAxMzAwMDc5MzY1 MDAwMjYwMDkyMzY1MDAwMjYwMDk0OTcxMDAwMjAwMDk3NTc3NjAwNDQwMDk5NTc3NjAwNzIw MTAzOTc4MDAwMzAwMTExMTg1MDAwMTUwMTE0MTg1NjAyNDEwMTE1Njg1NjAyNjcwMTM5Nzg1 NjAwNjMwMTY2NDg5MTAwMzQwMTcyNzg5MTAwMzkwMTc2MTkzNjAwNDcwMTgwMDk5NDAwMTIw MTg0Nx5vY20wMTc4NTkyNSAeT0NvTEMeMjAwMzAzMTQxMjQ2NDAuMB43MzA3MjRjMTk3MDk5 OTllbmtxcnpwICAgICAgIDAgICBhMGVuZyAgHiAgH2EgICA3MzY0MjQzMiAeICAfYURMQx9j RExDH2RPQ0wfZE5TRB9kUkNTH2RBSVAfZE9DTB9kTlNEH2RETEMfZE5TVB9kT0NMH2RNWUcf ZFNZUx9kT0NMH2ROU0QfZE5MTR9kQ0FXHjcgH2E3NTA1NjU4HzJETkxNHjcgH2FNMDMyNjAw MDAfMkROTE0eICAfYTE3NzA4MzUfYTEzNTk3OTgeMCAfYTAzMDUtMTgzOB4gIB9hTU1MUkFJ HiAgH2JCbGFja3dlbGwgU2NpZW50aWZpYyBQdWJsaWNhdGlvbnMsIEx0ZC4sIE9zbmV5IE1l YWQsIE94Zm9yZCBPWDIgT0VMHjAgH2FlbmcfYmVuZx4gIB9hbGMfYW5zZHAeICAfYVFMNzAw H2IuTTMxHiAgH2FbU2VyaWFsc11DQVdLH3YxLR9sU0hFTFZFRCBCWSBUSVRMRR4wIB9hTWFt bWFsIHJldi4eIDAfYU1hbW1hbCByZXZpZXceMDAfYU1hbW1hbCByZXZpZXcuHiAgH2FPeGZv cmQgW2V0Yy5dH2JQdWJsaXNoZWQgZm9yIHRoZSBNYW1tYWwgU29jaWV0eSBieSBCbGFja3dl bGwgU2NpZSBudGlmaWMgUHVibGljYXRpb25zLh4gIB9hdi4gOh9iaWxsLiA7H2MyNCBjbS4e ICAfYVF1YXJ0ZXJseR4wIB9hdi4gMS0gICBGZWIuIDE5NzAtHiAgH2FQdWJsaXNoZWQgMTk3 MC0xOSAgIGJ5IHRoZSBNYW1tYWwgU29jaWV0eS4eMiAfYUFydCBhbmQgYXJjaGFlb2xvZ3kg dGVjaG5pY2FsIGFic3RyYWN0cx94MDAwNC0yOTk0HjIgH2FCaW9sb2dpY2FsIGFic3RyYWN0 cx94MDAwNi0zMTY5HjIgH2FMaWZlIHNjaWVuY2VzIGNvbGxlY3Rpb24eICAfYUFsc28gYXZh aWxhYmxlIGJ5IHN1YnNjcmlwdGlvbiB2aWEgV29ybGQgV2lkZSBXZWIgdGhyb3VnaCBPQ0xD IEZpcnN0U2VhcmNoIEVsZWN0cm9uaWMgQ29sbGVjdGlvbnMgT25saW5lIGFuZCB0aHJvdWdo IFN5bmVyZ3kuHiAwH2FNYW1tYWxzH3ZQZXJpb2RpY2Fscy4eIDIfYU1hbW1hbHMfdlBlcmlv ZGljYWxzLh4yIB9hTWFtbWFsIFNvY2lldHkuHjEgH3RNYW1tYWwgcmV2aWV3IChPbmxpbmUp H3coT0NvTEMpNDIyMDE3MjEeMSAfdE1hbW1hbCByZXZpZXcgKE9ubGluZSA6IFN5bmVyZ3kp H3coRExDKSAgIDAwMjQyMjg4H3coT0NvTEMpNDUyMzEyNjIeMDMfYU1hbW1hbCBTb2NpZXR5 Lh90QnVsbGV0aW4eICAfYURMQx9hS3lMb1UeNDEfdWh0dHA6Ly9maXJzdHNlYXJjaC5vY2xj Lm9yZx96QWRkcmVzcyBmb3IgYWNjZXNzaW5nIHRoZSBqb3VybmFsIHVzaW5nIGF1dGhvcml6 YXRpb24gbnVtYmVyIGFuZCBwYXNzd29yZCB0aHJvdWdoIE9DTEMgRmlyc3RTZWFyY2ggRWxl Y3Ryb25pYyBDb2xsZWN0aW9ucyBPbmxpbmUuIFN1YnNjcmlwdGlvbiB0byBvbmxpbmUgam91 cm5hbCByZXF1aXJlZCBmb3IgYWNjZXNzIHRvIGFic3RyYWN0cyBhbmQgZnVsbCB0ZXh0HjQx H3VodHRwOi8vZmlyc3RzZWFyY2gub2NsYy5vcmcvam91cm5hbD0wMzA1LTE4Mzg7c2NyZWVu PWluZm87RUNPSVAfekFkZHJlc3MgZm9yIGFjY2Vzc2luZyB0aGUgam91cm5hbCBmcm9tIGFu IGF1dGhvcml6ZWQgSVAgYWRkcmVzcyB0aHJvdWdoIE9DTEMgRmlyc3RTZWFyY2ggRWxlY3Ry b25pYyBDb2xsZWN0aW9ucyBPbmxpbmUuIFN1YnNjcmlwdGlvbiB0byBvbmxpbmUgam91cm5h bCByZXF1aXJlZCBmb3IgYWNjZXNzIHRvIGFic3RyYWN0cyBhbmQgZnVsbCB0ZXh0HjQxH3Vo dHRwOi8vd3d3LmJsYWNrd2VsbC1zeW5lcmd5LmNvbS9pc3N1ZWxpc3QuYXNwP2pvdXJuYWw9 bWFtHjEzHzk4NTMfODEfYXYuH2Juby4fdTQfdnIfaSh5ZWFyKR40MB85ODYzHzgxH2E8MT4t H2k8MTk3MD4tH3hwcm92aXNpb25hbB4gIB9hVm9sLiAzMiwgbm8uIDEgKE1hci4gMjAwMikg KHN1cnJvZ2F0ZSkgTElDHiAgH2FYMB9iQ0FXHh0wMTA5MW5hbSAgMjIwMDI1M0lhIDQ1eDAw MDEwMDEzMDAwMDAwMDMwMDA2MDAwMTMwMDUwMDE3MDAwMTkwMDgwMDQxMDAwMzYwNDAwMDEz MDAwNzcwOTAwMDIxMDAwOTAwNDkwMDIyMDAxMTExMDAwMDUwMDAxMzMyNDUwMjA5MDAxODMy NjAwMDMyMDAzOTIzMDAwMDY3MDA0MjQ1MDAwMDM2MDA0OTE1MDAwMDg5MDA1Mjc1MDQwMDQx MDA2MTY1OTAwMDM5MDA2NTc2NTAwMDI3MDA2OTY3MDAwMDM1MDA3MjM3MDAwMDY3MDA3NTg5 OTQwMDEyMDA4MjUeb2NtNTE3MjU0NjcgHk9Db0xDHjIwMDMwMzE0MTI0NjQwLjAeMDMwMjIx czE4MzYgICAgZ3cgYWYgICAgYiAgICAwMDAgMCBnZXIgZB4gIB9hQ0FXH2NDQVceICAfYVFM NjczH2IuUzM0IDE4NTYeICAfYVtmb2xpb11DQVdDH2w2OTYwHjEgH2FTY2hpbnosIEguIFIu H3EoSGVpbnJpY2ggUnVkb2xmKSwfZDE3NzctMTg2MS4eMTAfYU5hdHVyZ2VzY2hpY2h0ZSB1 bmQgQWJiaWxkdW5nZW4gZGVyIFbob2dlbCA6H2JuYWNoIGRlbiBuZXVlc3RlbiBTeXN0ZW1l biAvH2NiZWFyYmVpdGV0IHZvbiBILlIuIFNjaGlueiA7IG5hY2ggZGVyIE5hdHVyIHVuZCBk ZW4gdm9yeuh1Z2xpY2hzdGVuIE9yaWdpbmFsaWVuIGdlemVpY2huZXQgdW5kIGxpdGhvZ3Jh cGhpcnQgdm9uIEsuSi4gQnJvZHRtYW5uLh4gIB9hTGVpcHppZyA6H2JXZWlkbWFubiwfYzE4 MzYuHiAgH2F4eHh2aSwgNDMwLCB4aSBwLiwgMTQ0IGxlYXZlcyBvZiBwbGF0ZXMgOh9iY29s LiBpbGwuIDsfYzM1IGNtLh4gIB9hT3JpZ2luYWxseSBpc3N1ZWQgaW4gZmFzY2ljbGVzLh4g IB9hQmFzZWQgb24gdGhlIG9ybml0aG9sb2dpY2FsIHBhcnQgb2YgR2VvcmdlcyBDdXZpZXIn cyBMZSBy4WVnbmUgYW5pbWFsIChQYXJpcywgMTgxNykuHiAgH2FJbmNsdWRlcyBiaWJsaW9n cmFwaGljYWwgcmVmZXJlbmNlcy4eICAfYVJlY2xhc3NlZCBmcm9tIDU5OC4yMDg0IFNjaDM0 IDE4MzYeIDAfYUJpcmRzH3ZJZGVudGlmaWNhdGlvbi4eMSAfYUJyb2R0bWFubiwgSm9zZXBo LB9kMTc4Ny0xODYyLh4xIB9hQ3V2aWVyLCBHZW9yZ2VzLB9jYmFyb24sH2QxNzY5LTE4MzIu H3RS4WVnbmUgYW5pbWFsLh9wT2lzZWF1eC4eICAfYVgwH2JDQVceHTAwOTk1Y2FtICAyMjAw MjY1SWEgNDV4MDAwMTAwMTMwMDAwMDAwMzAwMDYwMDAxMzAwNTAwMTcwMDAxOTAwODAwNDEw MDAzNjAxMDAwMTcwMDA3NzA0MDAwNjEwMDA5NDA0MzAwMTIwMDE1NTA5MDAwMjYwMDE2NzA0 OTAwNDEwMDE5MzEwMDAwMzMwMDIzNDI0NTAwNzEwMDI2NzI0NjAwNDMwMDMzODI0NjAwNDgw MDM4MTI2MDAwNDEwMDQyOTMwMDAwNzIwMDQ3MDUwNDAwNDEwMDU0MjU5MDAwMzIwMDU4MzY1 MTAwNjUwMDYxNTY1MDAwMzcwMDY4MDk5NDAwMTIwMDcxNx5vY20wNjQ5ODI5MCAeT0NvTEMe MjAwMzAzMTQxMjQ2NDAuMB44MDA3MDlzMTg5MyAgICBlbmthYmYgICBiICAgIDAwMCAwIGVu ZyBkHiAgH2FhZ3IwNDAwMDQ5OCAeICAfYUxpYnJhcnksIFUuUy4gRGVwdC4gb2YgQWdyaWN1 bHR1cmUfY0NMRR9kT0NMH2RPQ0xDUR9kQ0FXHiAgH2FhLW15LS0tHiAgH2FEUzU5Ny4zNC5L NR9iVzU0IDE4OTMeICAfYVtmb2xpb11DQVdDH2xnaWZ0OiBFLiBMZWFjaCAoNTktMDY4KR4x IB9hV2hpdGVoZWFkLCBKb2huLB9kMTg2MC0xODk5Lh4xMB9hRXhwbG9yYXRpb24gb2YgTW91 bnQgS2luYSBCYWx1LCBOb3J0aCBCb3JuZW8gLx9jYnkgSm9obiBXaGl0ZWhlYWQuHjE0H2FF eHBsb3JhdGlvbiBvZiBLaW5hIEJhbHUsIE5vcnRoIEJvcm5lbx4zIB9hRXhwbG9yYXRpb24g b2YgTW91bnQgS2luYWJhbHUsIE5vcnRoIEJvcm5lbx4gIB9hTG9uZG9uIDofYkd1cm5leSBh bmQgSmFja3NvbiwfYzE4OTMuHiAgH2F4LCAzMTcgcC4sIFszMl0gbGVhdmVzIG9mIHBsYXRl cyA6H2JpbGwuIChzb21lIGNvbC4pLCBtYXAgOx9jMzggY20uHiAgH2FJbmNsdWRlcyBiaWJs aW9ncmFwaGljYWwgcmVmZXJlbmNlcy4eICAfYVJlY2xhc3NlZCBmcm9tIDkxOS4xMTUgVzU4 Nx4gMB9hS2luYWJhbHUsIE1vdW50IChTYWJhaCkfeERpc2NvdmVyeSBhbmQgZXhwbG9yYXRp b24feEJyaXRpc2guHiAwH2Fab29sb2d5H3pTYWJhaB96S2luYWJhbHUsIE1vdW50Lh4gIB9h WDAfYkNBVx4dMDExMzRjYW0gIDIyMDAzMTNJYSA0NXgwMDAxMDAxMzAwMDAwMDAzMDAwNjAw MDEzMDA1MDAxNzAwMDE5MDA4MDA0MTAwMDM2MDQwMDAxMzAwMDc3MDIwMDAyNTAwMDkwMDIw MDAyNTAwMTE1MDQzMDAxMjAwMTQwMDkwMDAyNTAwMTUyMDQ5MDAxNzAwMTc3MjQ1MDE1MjAw MTk0MjQ2MDAzNTAwMzQ2MjQ2MDAxMTAwMzgxMjYwMDAzNjAwMzkyMzAwMDAzMzAwNDI4NTAw MDA2NDAwNDYxNTA0MDA1MzAwNTI1NjUwMDA0MjAwNTc4NjUwMDA0MjAwNjIwNzAwMDAyNjAw NjYyNzAwMDAzMzAwNjg4NzAwMDA2NzAwNzIxNzEwMDAyMDAwNzg4OTk0MDAxMjAwODA4Hm9j bTQyNjM0NDIzIB5PQ29MQx4yMDAzMDMxNDEyNDY0MC4wHjk5MTAxM20xOTk5MjAwM25lIGFi ICAgIGIgICAgMDAxIDAgZW5nIGQeICAfYUNBVx9jQ0FXHiAgH2E5MDU3ODIwNDIwIChbcHQu XSAxKR4gIB9hOTA1NzgyMTI1NyAoW3B0Ll0gMykeICAfYWFzLS0tLS0eICAfYVNCMTA4LkE3 ODUfYlA1MiB2LjEyHiAgH2FDQVdGH3Y8MSwgMz4eMDAfYVBsYW50IHJlc291cmNlcyBvZiBT b3V0aC1FYXN0IEFzaWEuH25Oby4gMTIsH3BNZWRpY2luYWwgYW5kIHBvaXNvbm91cyBwbGFu dHMgLx9jTC5TLiBkZSBQYWR1YSwgTi4gQnVueWFwcmFwaGF0c2FyYSwgYW5kIFIuSC5NLkou IExlbW1lbnMgKGVkaXRvcnMpLh4zMB9hTWVkaWNpbmFsIGFuZCBwb2lzb25vdXMgcGxhbnRz HjE0H2FQcm9zZWEeICAfYUxlaWRlbiA6H2JCYWNraHV5cywfYzE5OTktMjAwMy4eICAfYTMg di4gOh9iaWxsLiwgbWFwcyA7H2MyNiBjbS4eICAfYVtQdC5dIDMgZWRpdGVkIGJ5IFIuSC5N LkouIExlbW1lbnMgYW5kIE4uIEJ1bnlhcHJhcGhhdHNhcmEuHiAgH2FJbmNsdWRlcyBiaWJs aW9ncmFwaGljYWwgcmVmZXJlbmNlcyBhbmQgaW5kZXhlcy4eIDAfYU1lZGljaW5hbCBwbGFu dHMfekFzaWEsIFNvdXRoZWFzdGVybi4eIDAfYVBvaXNvbm91cyBwbGFudHMfekFzaWEsIFNv dXRoZWFzdGVybi4eMSAfYURlIFBhZHVhLCBMdWRpdmluYSBTLh4wIB9hTmFudGhhd2FuIEJ1 bnlhcHJhcGhhdHP45W9uLh4xIB9hTGVtbWVucywgUi4gSC4gTS4gSi4fcShSb2VsYW5kIEhl bmRyaWt1cyBNYXJpYSBKdWxpZW4pLB9kMTk1NC0eMiAfYVByb3NlYSBQcm9qZWN0Lh4gIB9h WDAfYkNBVx4dMDEyMzljYW0gIDIyMDAzMDFJYSA0NXgwMDAxMDAxMzAwMDAwMDAzMDAwNjAw MDEzMDA1MDAxNzAwMDE5MDA4MDA0MTAwMDM2MDQwMDAzODAwMDc3MDk5MDAzNDAwMTE1MDQ5 MDAxODAwMTQ5MTAwMDAxOTAwMTY3MjQ1MDE5NjAwMTg2MjQ2MDAzNTAwMzgyMjYwMDA2NzAw NDE3MzAwMDAzNDAwNDg0NDkwMDA3NzAwNTE4NDkwMDAxNjAwNTk1NTAwMDA1NDAwNjExNTAw MDAyODAwNjY1NjUwMDAzNTAwNjkzNjUwMDAzMDAwNzI4NjUwMDAyODAwNzU4NzAwMDAyMjAw Nzg2ODMwMDA2MzAwODA4ODMwMDA1NDAwODcxOTk0MDAxMjAwOTI1Hm9jbTIzOTUwMTIwIB5P Q29MQx4yMDAzMDMxNDEyNDY0MC4wHjkxMDYxOHMxOTkxICAgIG5idWEgICAgIGIgICAgMDAw IDAgZW5nIGQeICAfYUdJUx9jR0lTH2RPU1UfZFVJVR9kQ0FXH2RPQ0wfZENBVx4gIB9hUUU4 NDEfYS5KNjcfYXYuH2ExMToxH2FzdXBwbC4eICAfYVtTZXJpYWxzXUNBV0EeMSAfYUdyYW5k ZSwgTGFuY2UuHjEwH2FPc3Rlb2xvZ3kgYW5kIHBoeWxvZ2VuZXRpYyByZWxhdGlvbnNoaXBz IG9mIGZvc3NpbCBhbmQgUmVjZW50IHBhZGRsZWZpc2hlcyAoUG9seW9kb250aWRhZSkgOh9i d2l0aCBjb21tZW50cyBvbiB0aGUgaW50ZXJyZWxhdGlvbnNoaXBzIG9mIEFjaXBlbnNlcmlm b3JtZXMgLx9jTGFuY2UgR3JhbmRlIGFuZCBXaWxsaWFtIEUuIEJlbWlzLh4xNx9hTGl2aW5n IGFuZCBmb3NzaWwgcGFkZGxlZmlzaGVzHiAgH2FbTGluY29sbiwgTmViLl0gOh9iU29jaWV0 eSBvZiBWZXJ0ZWJyYXRlIFBhbGVvbnRvbG9neSwfY2MxOTkxLh4gIB9hdmlpLCAxMjEgcC4g Oh9iaWxsLiA7H2MyOCBjbS4eMSAfYUpvdXJuYWwgb2YgdmVydGVicmF0ZSBwYWxlb250b2xv Z3ksH3gwMjcyLTQ2MzQgOx92di4gMTEsIHN1cHBsLiB0byBuby4gMR4xIB9hTWVtb2lyIDsf djEeICAfYUluY2x1ZGVzIGJpYmxpb2dyYXBoaWNhbCByZWZlcmVuY2VzIChwLiAxMTYtMTIx KS4eICAfYSIyOCBNYXJjaCAxOTkxIi0tQ292ZXIuHiAwH2FQb2x5b2RvbnRpZGFlH3hDbGFz c2lmaWNhdGlvbi4eIDAfYVBvbHlvZG9udGlkYWUfeFBoeWxvZ2VueS4eIDAfYVBvbHlvZG9u dGlkYWUfeEFuYXRvbXkuHjEgH2FCZW1pcywgV2lsbGlhbSBFLh4gMB9hSm91cm5hbCBvZiB2 ZXJ0ZWJyYXRlIHBhbGVvbnRvbG9neSA7H3Z2LiAxMSwgbm8uIDEsIHN1cHBsLh4gMB9hTWVt b2lyIChTb2NpZXR5IG9mIFZlcnRlYnJhdGUgUGFsZW9udG9sb2d5KSA7H3YxLh4gIB9hWDAf YkNBVx4dMDA4NDhjYW0gIDIyMDAyNTNJYSA0NXgwMDAxMDAxMzAwMDAwMDAzMDAwNjAwMDEz MDA1MDAxNzAwMDE5MDA4MDA0MTAwMDM2MDQwMDAyMzAwMDc3MDk5MDAyNjAwMTAwMDQ5MDAx ODAwMTI2MjQ1MDEwMzAwMTQ0MjYwMDA0NDAwMjQ3MzAwMDAyODAwMjkxNDQwMDA0NjAwMzE5 NTAwMDAyMjAwMzY1NTAwMDAxODAwMzg3NTA0MDA0MTAwNDA1NjUwMDAyNTAwNDQ2NjUwMDAy NDAwNDcxNjUwMDA0OTAwNDk1NzAwMDAzODAwNTQ0OTk0MDAxMjAwNTgyHm9jbTI3MjU3Mzg0 IB5PQ29MQx4yMDAzMDMxNDEyNDY0MC4wHjkzMDExNXMxOTkwICAgIGVua2EgICAgIGIgICAg MTAwIDAgZW5nIGQeICAfYUZITh9iZnJlH2NGSE4fZENBVx4gIB9hUUw3MDAfYS5NMzEfYXYu H2EyMDoxHiAgH2FbU2VyaWFsc11DQVdLHjAwH2FXaGFsZXMgaW4gYSBtb2Rlcm4gd29ybGQg Oh9iYSBzeW1wb3NpdW0gaGVsZCBpbiBMb25kb24sIE5vdmVtYmVyIDE5ODggLx9jW2VkaXRl ZCBieSBOaWdlbCBCb25uZXJdLh4gIB9hT3hmb3JkIDofYkJsYWNrd2VsbCBTY2llbnRpZmlj LB9jYzE5OTAuHiAgH2E3MyBwLiA6H2JpbGwuIDsfYzI1IGNtLh4gMB9hTWFtbWFsIHJldmll dywfeDAzMDUtMTgzOCA7H3Z2LiAyMCwgbm8uIDEeICAfYVRpdGxlIGZyb20gY292ZXIuHiAg H2EiTWFyY2ggMTk5MC4iHiAgH2FJbmNsdWRlcyBiaWJsaW9ncmFwaGljYWwgcmVmZXJlbmNl cy4eIDAfYVdoYWxpbmcfdkNvbmdyZXNzZXMuHiAwH2FXaGFsZXMfdkNvbmdyZXNzZXMuHiA3 H2FCYWxlaW5lcx94QXNwZWN0IOJlY29ub21pcXVlH3hDb25ncuFlcy4fMnJhbR4xIB9hQm9u bmVyLCBXLiBOaWdlbB9xKFdpbGxpYW0gTmlnZWwpHiAgH2FYMB9iQ0FXHh0wMDc5N2NhbSAg MjIwMDI0MUlhIDQ1eDAwMDEwMDEzMDAwMDAwMDMwMDA2MDAwMTMwMDUwMDE3MDAwMTkwMDgw MDQxMDAwMzYwNDAwMDIzMDAwNzcwOTkwMDI3MDAxMDAwNDkwMDE4MDAxMjcxMDAwMDI0MDAx NDUyNDUwMDgwMDAxNjkyNjAwMDc2MDAyNDkzMDAwMDQ2MDAzMjU0NDAwMDM1MDAzNzE1MDAw MDIyMDA0MDY1MDAwMDIzMDA0Mjg1MDQwMDUyMDA0NTE2NTAwMDE1MDA1MDM2NTAwMDI1MDA1 MTg5OTQwMDEyMDA1NDMeb2NtMzA2OTA0OTAgHk9Db0xDHjIwMDMwMzE0MTI0NjQwLjAeOTQw NjMwczE5NzQgICAgZW5rYWYgICAgYiAgICAwMDAgMCBlbmcgZB4gIB9hWlc5H2JmcmUfY1pX OR9kQ0FXHiAgH2FRTDcwMB9hLk0zMR9hdi4fYTQ6MS8yHiAgH2FbU2VyaWFsc11DQVdLHjEg H2FSdXNzZWxsLCBFbGVhbm9yIE0uHjE0H2FUaGUgYmlvbG9neSBvZiBrYW5nYXJvb3MgKE1h cnN1cGlhbGlhLCBNYWNyb3BvZGlkYWUpIC8fY0VsZWFub3IgTS4gUnVzc2VsbC4eICAfYU94 Zm9yZCA6H2JQdWJsaXNoZWQgZm9yIE1hbW1hbCBTb2NpZXR5IGJ5IEJsYWNrd2VsbCBTY2ll bnRpZmljLB9jWzE5NzRdHiAgH2E1OSBwLiwgWzRdIHAuIG9mIHBsYXRlcyA6H2JpbGwuIDsf YzI1IGNtLh4gMB9hTWFtbWFsIHJldmlldyA7H3Z2LiA0LCBuby4gMS8yHiAgH2FUaXRsZSBm cm9tIGNvdmVyLh4gIB9hIk1hcmNoL0p1bmUgMTk3NC4iHiAgH2FJbmNsdWRlcyBiaWJsaW9n cmFwaGljYWwgcmVmZXJlbmNlcyAocC4gNTItNTkpLh4gMB9hS2FuZ2Fyb29zLh4gMB9hS2Fu Z2Fyb29zH3hCZWhhdmlvci4eICAfYVgwH2JDQVceHTAwOTc1Y2FtICAyMjAwMjY1SWEgNDV4 MDAwMTAwMTMwMDAwMDAwMzAwMDYwMDAxMzAwNTAwMTcwMDAxOTAwODAwNDEwMDAzNjA0MDAw MTgwMDA3NzA3MDAwMjUwMDA5NTA5OTAwMjMwMDEyMDA0OTAwMTgwMDE0MzExMDAwNzgwMDE2 MTI0NTAwNTQwMDIzOTI2MDAwNzYwMDI5MzMwMDAwMjgwMDM2OTQ0MDAwNDUwMDM5NzUwMDAw MjIwMDQ0MjUwMDAxMjUwMDQ2NDUwMDAwMTgwMDU4OTUwNDAwNDEwMDYwNzY1MDAwMjQwMDY0 ODY1MDAwMjUwMDY3Mjk5NDAwMTIwMDY5Nx5vY20wMjM3MDQ4NiAeT0NvTEMeMjAwMzAzMTQx MjQ2NDAuMB43NjA4MTNzMTk3NiAgICBlbmthICAgICBiICAgIDEwMCAwIGVuZyAgHiAgH2FB R0wfY0FHTB9kQ0FXHiAgH2FRTDcwMC5NMjQfYnYuNiwgTm8uMR4gIB9hUUw3MDAfYS5NMzEf YXYuNjoxHiAgH2FbU2VyaWFsc11DQVdLHjIgH2FNYW1tYWwgU29jaWV0eS4fYkF1dHVtbiBT eW1wb3NpdW0fZCgxOTc0IDofY1pvb2xvZ2ljYWwgU29jaWV0eSBvZiBMb25kb24pHjEwH2FQ cm9jZWVkaW5ncyBvZiBhIHN5bXBvc2l1bSBvbiB3aGFsZXMgYW5kIHdoYWxpbmcuHiAgH2FP eGZvcmQgOh9iUHVibGlzaGVkIGZvciBNYW1tYWwgU29jaWV0eSBieSBCbGFja3dlbGwgU2Np ZW50aWZpYywfY1sxOTc2XR4gIB9hNjIgcC4gOh9iaWxsLiA7H2MyNSBjbS4eIDAfYU1hbW1h bCByZXZpZXcsH3gwMzA2LTE4MzggOx92di4gNiwgbm8uIDEeICAfYVRpdGxlIGZyb20gY292 ZXIuHiAgH2EiVGhlIDE5NzQgQXV0dW1uIFN5bXBvc2l1bSBvZiB0aGUgTWFtbWFsIFNvY2ll dHkgd2FzIGhlbGQgb24gMjMgTm92ZW1iZXIgYXQgdGhlIC4uLiBab29sb2dpY2FsIFNvY2ll dHkgb2YgTG9uZG9uIi0tUC4gMS4eICAfYSJNYXJjaCAxOTc2LiIeICAfYUluY2x1ZGVzIGJp Ymxpb2dyYXBoaWNhbCByZWZlcmVuY2VzLh4gMB9hV2hhbGVzH3ZDb25ncmVzc2VzLh4gMB9h V2hhbGluZx92Q29uZ3Jlc3Nlcy4eICAfYVgwH2JDQVceHTAxMDE2Y2FtICAyMjAwMjUzSWEg NDV4MDAwMTAwMTMwMDAwMDAwMzAwMDYwMDAxMzAwNTAwMTcwMDAxOTAwODAwNDEwMDAzNjA0 MDAwMjUwMDA3NzA5OTAwMjcwMDEwMjA0OTAwMTgwMDEyOTExMDAwNzgwMDE0NzI0NTAwOTUw MDIyNTI0NjAwMjgwMDMyMDI0NjAwMTcwMDM0ODI2MDAwNzYwMDM2NTMwMDAwNTEwMDQ0MTQ0 MDAwNDcwMDQ5MjUwMDAxMjcwMDUzOTUwMDAwMjMwMDY2NjUwNDAwNDEwMDY4OTY1MDAwMjAw MDczMDk5NDAwMTIwMDc1MB5vY20zNTM0NTY5MiAeT0NvTEMeMjAwMzAzMTQxMjQ2NDAuMB43 ODEwMThzMTk3OCAgICBlbmthYmYgICBiICAgIDEwMCAwIGVuZyBkHiAgH2FDQUkfY0NBSR9k T0NMQ1EfZENBVx4gIB9hUUw3MDAfYS5NMzEfYXYuH2E4OjEvMh4gIB9hW1NlcmlhbHNdQ0FX Sx4yIB9hTWFtbWFsIFNvY2lldHkuH2JBdXR1bW4gU3ltcG9zaXVtH2QoMTk3NiA6H2Nab29s b2dpY2FsIFNvY2lldHkgb2YgTG9uZG9uKR4xMB9hUHJvY2VlZGluZ3Mgb2YgdGhlIDE5NzYg QXV0dW1uIFN5bXBvc2l1bSBvZiB0aGUgTWFtbWFsIFNvY2lldHkgb24gYXNwZWN0cyBvZiBz ZWFsIGJpb2xvZ3kuHjMwH2FBc3BlY3RzIG9mIHNlYWwgYmlvbG9neR4zMB9hU2VhbCBiaW9s b2d5HiAgH2FPeGZvcmQgOh9iUHVibGlzaGVkIGZvciBNYW1tYWwgU29jaWV0eSBieSBCbGFj a3dlbGwgU2NpZW50aWZpYywfY1sxOTc4XR4gIB9hNzYgcC4sIFs2XSBwLiBvZiBwbGF0ZXMg Oh9iaWxsLiwgbWFwIDsfYzI1IGNtLh4gMB9hTWFtbWFsIHJldmlldywfeDAzMDUtMTgzOCA7 H3Z2LiA4LCBuby4gMS8yHiAgH2EiVGhlIDE5NzYgQXV0dW1uIFN5bXBvc2l1bSBvZiB0aGUg TWFtbWFsIFNvY2lldHkgd2FzIGhlbGQgb24gMjAgTm92ZW1iZXIgYXQgdGhlIC4uLiBab29s b2dpY2FsIFNvY2lldHkgb2YgTG9uZG9uIi0tUC4gWzFdLh4gIB9hIk1hcmNoL0p1bmUgMTk3 OC4iHiAgH2FJbmNsdWRlcyBiaWJsaW9ncmFwaGljYWwgcmVmZXJlbmNlcy4eIDAfYVNlYWxz IChBbmltYWxzKR4gIB9hWDAfYkNBVx4dMDEwNTJjYW0gIDIyMDAyNjVJYSA0NXgwMDAxMDAx MzAwMDAwMDAzMDAwNjAwMDEzMDA1MDAxNzAwMDE5MDA4MDA0MTAwMDM2MDQwMDAyMzAwMDc3 MDk5MDAyODAwMTAwMDQ5MDAxODAwMTI4MjQ1MDI0NjAwMTQ2MjYwMDA3NjAwMzkyMzAwMDAz NDAwNDY4NDQwMDA0ODAwNTAyNTAwMDAyMjAwNTUwNTAwMDAyNzAwNTcyNTA0MDA0MTAwNTk5 NjUwMDAzNjAwNjQwNzAwMDAxNzAwNjc2NzAwMDAyMzAwNjkzNzEwMDAyMDAwNzE2NzEwMDAz ODAwNzM2OTk0MDAxMjAwNzc0Hm9jbTM1NDcyODI3IB5PQ29MQx4yMDAzMDMxNDEyNDY0MC4w Hjg3MDkxOHMxOTg3ICAgIGVua2EgICAgIGIgICAgMTAwIDAgZW5nIGQeICAfYUNBSR9jQ0FJ H2RZU00fZENBVx4gIB9hUUw3MDAfYS5NMzEfYXYuH2ExNzoyLzMeICAfYVtTZXJpYWxzXUNB V0seMDAfYVByb2NlZWRpbmdzIG9mIGEgam9pbnQgbWVldGluZyBiZXR3ZWVuIHRoZSBNYW1t YWwgU29jaWV0eSBhbmQgdGhlIEJyaXRpc2ggU29jaWV0eSBmb3IgUGFyYXNpdG9sb2d5LCBb aGVsZCBhdF0gUm95YWwgSG9sbG93YXkgJiBCZWRmb3JkIE5ldyBDb2xsZWdlLCBVbml2ZXJz aXR5IG9mIExvbmRvbiwgRWdoYW0sIFN1cnJleSwgMTYgRGVjZW1iZXIgMTk4NSAvH2NlZGl0 ZWQgYnkgSi5XLiBMZXdpcyBhbmQgRi5FLkcuIENveC4eICAfYU94Zm9yZCA6H2JQdWJsaXNo ZWQgZm9yIE1hbW1hbCBTb2NpZXR5IGJ5IEJsYWNrd2VsbCBTY2llbnRpZmljLB9jWzE5ODdd HiAgH2FwLiBbNTldLTE1NCA6H2JpbGwuIDsfYzI1IGNtLh4gMB9hTWFtbWFsIHJldmlldywf eDAzMDUtMTgzOCA7H3Z2LiAxNywgbm8uIDIvMx4gIB9hVGl0bGUgZnJvbSBjb3Zlci4eICAf YSJKdW5lL1NlcHRlbWJlciAxOTg3LiIeICAfYUluY2x1ZGVzIGJpYmxpb2dyYXBoaWNhbCBy ZWZlcmVuY2VzLh4gMB9hTWFtbWFscx94UGFyYXNpdGVzH3ZDb25ncmVzc2VzLh4xIB9hTGV3 aXMsIEouIFcuHjEgH2FDb3gsIEZyYW5jaXMgRS4gRy4eMiAfYU1hbW1hbCBTb2NpZXR5Lh4y IB9hQnJpdGlzaCBTb2NpZXR5IGZvciBQYXJhc2l0b2xvZ3kuHiAgH2FYMB9iQ0FXHh0wMTA5 NmNhbSAgMjIwMDI2NUlhIDQ1eDAwMDEwMDEzMDAwMDAwMDMwMDA2MDAwMTMwMDUwMDE3MDAw MTkwMDgwMDQxMDAwMzYwNDAwMDEzMDAwNzcwNDMwMDEyMDAwOTAwOTkwMDI3MDAxMDIwNDkw MDI5MDAxMjkxMDAwMDIyMDAxNTgyNDUwMTI1MDAxODAyNDYwMDczMDAzMDUyNjAwMTY2MDAz NzgzMDAwMDM0MDA1NDQ0NDAwMDM3MDA1Nzg1MDAwMDIxMDA2MTU1MDAwMDIwMDA2MzY2NTAw MDQ4MDA2NTY2NTAwMDQ5MDA3MDQ2NTAwMDY1MDA3NTM5OTQwMDEyMDA4MTgeb2NtNTE3MjU4 MjggHk9Db0xDHjIwMDMwMzE0MTI0NjQwLjAeMDMwMjIxczIwMDIgICAgd2F1YiAgICAgdCAg IGYwMDAgMCBlbmcgZB4gIB9hQ0FXH2NDQVceICAfYW4tdXMtYWseICAfYVNIMTEfYS5BMTgf YW5vLh9hMDItMDceICAfYVtTZXJpYWxzXUNBV0EfbHB1Yi4gZ2lmdB4xIB9hWmVuZ2VyLCBI YXJvbGQgSC4eMTAfYVJlcG9ydCB0byBpbmR1c3RyeSA6H2JmaXNoaW5nIGxvZyBmb3IgdGhl IDIwMDIgYm90dG9tIHRyYXdsIHN1cnZleSBvZiB0aGUgQWxldXRpYW4gSXNsYW5kcyAvH2Nw cmVwYXJlZCBieSBIYXJvbGQgWmVuZ2VyLh4zMB9hRmlzaGluZyBsb2cgZm9yIHRoZSAyMDAy IGJvdHRvbSB0cmF3bCBzdXJ2ZXkgb2YgdGhlIEFsZXV0aWFuIElzbGFuZHMeICAfYVtTZWF0 dGxlXSA6H2JOYXRpb25hbCBPY2VhbmljIGFuZCBBdG1vc3BoZXJpYyBBZG1pbmlzdHJhdGlv biwgQWxhc2thIEZpc2hlcmllcyBTY2llbmNlIENlbnRlciwgTmF0aW9uYWwgTWFyaW5lIEZp c2hlcmllcyBTZXJ2aWNlLCBVLlMuIERlcHQuIG9mIENvbW1lcmNlLB9jWzIwMDJdHiAgH2Fp aWksIDEyOCBwLiA6H2JtYXBzIDsfYzI4IGNtLh4gMB9hQUZTQyBwcm9jZXNzZWQgcmVwb3J0 IDsfdjIwMDItMDceICAfYSJEZWNlbWJlciAyMDAyLiIeICAfYUNoaWVmbHkgdGFibGVzLh4g MB9hRmlzaCBwb3B1bGF0aW9ucx96QWxhc2thH3pBbGV1dGlhbiBJc2xhbmRzLh4gMB9hRmlz aGVyeSByZXNvdXJjZXMfekFsYXNrYR96QWxldXRpYW4gSXNsYW5kcy4eIDAfYVRyYXdscyBh bmQgdHJhd2xpbmcfeENhdGNoIGVmZm9ydB96QWxhc2thH3pBbGV1dGlhbiBJc2xhbmRzLh4g IB9hWDAfYkNBVx4dMDA4NDduYW0gIDIyMDAyNDFJYSA0NXgwMDAxMDAxMzAwMDAwMDAzMDAw NjAwMDEzMDA1MDAxNzAwMDE5MDA4MDA0MTAwMDM2MDQwMDAxMzAwMDc3MDkwMDAyMjAwMDkw MDQ5MDAyNTAwMTEyMTAwMDAyNTAwMTM3MjQ1MDEwNTAwMTYyMjQ2MDAxOTAwMjY3MjYwMDA2 NDAwMjg2MzAwMDAyODAwMzUwNDQwMDA3ODAwMzc4NTAwMDAzMTAwNDU2NTA0MDA1MjAwNDg3 NjUwMDAzMDAwNTM5NjUwMDAyNDAwNTY5OTk0MDAxMjAwNTkzHm9jbTUxNjE5OTE1IB5PQ29M Qx4yMDAzMDMxNDEyNDY0MC4wHjAzMDIxMHMyMDAzICAgIG55dWEgICAgIGIgICAgMDAwIDAg ZW5nIGQeICAfYVlBTR9jWUFNHiAgH2FRSDEfYi5BNDUgbm8uIDI3NB4gIB9hW1NlcmlhbHNd Q0FXQR9sZXhjaC4eMSAfYURhdmlsYSwgRGlhbmEgU2lsdmEuHjEwH2FIaWdoZXItbGV2ZWwg cmVsYXRpb25zaGlwcyBvZiB0aGUgc3BpZGVyIGZhbWlseSBDdGVuaWRhZSAoQXJhbmVhZSwg Q3Rlbm9pZGVhKSAvH2NEaWFuYSBTaWx2YSBEYXZpbGEuHjE3H2FDdGVuaWQgc3BpZGVycx4g IB9hTmV3IFlvcmssIE5ZIDofYkFtZXJpY2FuIE11c2V1bSBvZiBOYXR1cmFsIEhpc3Rvcnks H2NjMjAwMy4eICAfYTg2IHAuIDofYmlsbC4gOx9jMjYgY20uHiAwH2FCdWxsZXRpbiBvZiB0 aGUgQW1lcmljYW4gTXVzZXVtIG9mIE5hdHVyYWwgSGlzdG9yeSwfeDAwMDMtMDA5MCA7H3Zu by4gMjc0HiAgH2EiSXNzdWVkIEZlYnJ1YXJ5IDYsIDIwMDMuIh4gIB9hSW5jbHVkZXMgYmli bGlvZ3JhcGhpY2FsIHJlZmVyZW5jZXMgKHAuIDMzLTM5KS4eIDAfYUN0ZW5pZGFlH3ZDbGFz c2lmaWNhdGlvbi4eIDAfYVNwaWRlcnMfeFBoeWxvZ2VueS4eICAfYVgwH2JDQVceHTAxMDA4 Y2FtICAyMjAwMjUzSWEgNDV4MDAwMTAwMTMwMDAwMDAwMzAwMDYwMDAxMzAwNTAwMTcwMDAx OTAwODAwNDEwMDAzNjA0MDAwMTgwMDA3NzA0MzAwMTIwMDA5NTA4NjAwMjIwMDEwNzA5OTAw MzIwMDEyOTA0OTAwMjUwMDE2MTI0NTAxMjkwMDE4NjI2MDAwODUwMDMxNTMwMDAwNDkwMDQw MDQ0MDAwNTMwMDQ0OTUwMDAwNDkwMDUwMjUwNDAwNTIwMDU1MTY1MDAwNjUwMDYwMzcwMDAw MjEwMDY2ODcxMDAwNTMwMDY4OTk5NDAwMTIwMDc0Mh5vY201MTY3MDA4MyAeT0NvTEMeMjAw MzAzMTQxMjQ2NDAuMB4wMzAyMThzMjAwMiAgICBjYXVhYiAgICBiICAgZjAwMCAwIGVuZyBk HiAgH2FVT1AfY1VPUB9kQ0ZJHiAgH2FuLXVzLWNhHiAwH2FJIDE5LjQyLzQ6MDItNDI0Mx4g IB9hR0I3MDEfYS5XMzcfYW5vLh9hMDItH2E0MjQzHiAgH2FbU2VyaWFsc11DQVdBH2xleGNo Lh4wMB9hR3JvdW5kLXdhdGVyIHF1YWxpdHkgaW4gdGhlIFNhbnRhIEFuYSBXYXRlcnNoZWQs IENhbGlmb3JuaWEgOh9ib3ZlcnZpZXcgYW5kIGRhdGEgc3VtbWFyeSAvH2NieSBTY290dCBO LiBIYW1saW4gLi4uIFtldCBhbC5dLh4gIB9hU2FjcmFtZW50bywgQ2FsaWYuIDofYlUuUy4g RGVwdC4gb2YgdGhlIEludGVyaW9yLCBVLlMuIEdlb2xvZ2ljYWwgU3VydmV5LB9jMjAwMi4e ICAfYXhpLCAxMzcgcC4gOh9iY29sLiBpbGwuLCBjb2wuIG1hcHMgOx9jMjggY20uHiAwH2FX YXRlci1yZXNvdXJjZXMgaW52ZXN0aWdhdGlvbnMgcmVwb3J0IDsfdjAyLTQyNDMeICAfYSJO YXRpb25hbCBXYXRlci1RdWFsaXR5IEFzc2Vzc21lbnQgUHJvZ3JhbS4iHiAgH2FJbmNsdWRl cyBiaWJsaW9ncmFwaGljYWwgcmVmZXJlbmNlcyAocC4gNTEtNTQpLh4gMB9hR3JvdW5kd2F0 ZXIfekNhbGlmb3JuaWEfelNhbnRhIEFuYSBSaXZlciBXYXRlcnNoZWQfeFF1YWxpdHkuHjEg H2FIYW1saW4sIFNjb3R0IE4uHjIgH2FOYXRpb25hbCBXYXRlci1RdWFsaXR5IEFzc2Vzc21l bnQgUHJvZ3JhbSAoVS5TLikeICAfYVgwH2JDQVceHQ== --------------D05F0D0C273D511FA9BB9D75 Content-Type: text/plain; charset=us-ascii; name="mar14lintreport.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mar14lintreport.txt" RECORD 1 246: Indicator 2 must be 0, 1, 2, 3, 4, 5, 6, 7 or 8 but it's " " RECORD 3 022: Indicator 1 must be blank but it's "0" 260: Must have a subfield _c. RECORD 4 700: Subfield _p is not allowed. RECORD 5 246: Field is not repeatable. 246: Indicator 2 must be 0, 1, 2, 3, 4, 5, 6, 7 or 8 but it's " " RECORD 6 246: Field is not repeatable. RECORD 7 490: Subfield _x is not allowed. RECORD 8 040: Subfield _b is not allowed. 440: Subfield _x is not allowed. RECORD 9 040: Subfield _b is not allowed. RECORD 10 110: Subfield _d is not allowed. 110: Subfield _c is not allowed. 440: Subfield _x is not allowed. RECORD 11 110: Subfield _d is not allowed. 110: Subfield _c is not allowed. 246: Field is not repeatable. 440: Subfield _x is not allowed. RECORD 12 440: Subfield _x is not allowed. RECORD 14 440: Subfield _x is not allowed. --------------D05F0D0C273D511FA9BB9D75 Content-Type: application/x-perl; name="marcmanip.pl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="marcmanip.pl" #!/usr/bin/perl use strict; use MARC::Batch; use Getopt::Long; #!/usr/bin/perl use strict; use MARC::Batch; use Getopt::Long; ## get options my ( $file ); GetOptions( 'file:s' => \$file ); print "\nusage: report --file=file.dat\n\n" and exit(0) if !$file; die "no such file: $file" if ! -f $file; ## create batch object, and read each record my $batch = MARC::Batch->new( 'USMARC', $file ); $batch->warnings_off(); $batch->strict_off(); while ( my $record = $batch->next() ) { my $status = undef; my $f001 = $record->field( '001' ); my $f100 = $record->field( '100' ); my $f245 = $record->field( '245' ); my $f240 = $record->field( '240' ); my $f504 = $record->field( '504' ); my $f440 = $record->field( '440' ); ## skip if we don't have 001 ##next if !$f001; ## get the control number from the 001 ##my $id = $f001->data(); ## get the 100$a data if ( my $f100a ) { my $f100a = $f100->subfield( 'a' ); print "$id: $f100a in 100\$a\n"; } ## get the 245a data if ( my $f245a ) { my $f245a = $f245->subfield( 'a' ); print "$id: $f245a in 245\$a\n"; } ## get the 240$a data if ( my $f240a ) { my $f240a = $f240->subfield( 'a' ); print "$id: $f240a in 240\$a\n"; } ## get the 504a data if ( my $f504a ) { my $f504a = $f504->subfield( 'a' ); print "$id: $f504a in 504\$a\n"; } ## get the 440$a data if ( my $f440a ) { my $f440a = $f440->subfield( 'a' ); print "$id: $f440a in 440\$a\n"; } ## get the 240f data if ( my $f240f ) { my $f240f = $f240->subfield( 'f' ); print "$id: $f240f in 240\$f\n"; } } --------------D05F0D0C273D511FA9BB9D75-- From the ethnicity table .. or at least it is at HLT. Im guessing that the table is either non existent, or is empty in a new install. The table is structured like this. ----------+-----------------+ | code | name | +----------+-----------------+ | european | European/Pakeha | | maori | Maori | So what we need is in the add/modify and display members screen is a check to see if want to collect and/or display ethnicity data. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From 271: Title search related MARC21 tags (2XX) are missing. Unimarc seems to be ok. How to fix: Koha admin page MARC tag structure 245 TITLE STATEMENT a Title biblio.title No No 1 (or some other number 0-9) but yes, it should be predefined ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From search.pl if (C4::Context->preference('acquisitions') eq 'simple') { $template->param(script => "MARCdetail.pl"); } else { $template->param(script => "detail.pl"); } Changed this to use the marc setting in system preferences if (C4::Context->preference('marc') eq 'on') { $template->param(script => "MARCdetail.pl"); } else { $template->param(script => "detail.pl"); } ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From the release notes * koha does NOT work with MARC::Record 1.12. It works fine with MARC::Record 0.93, and maybe with other versions. Could you try MARC::Record version 0.93 and see if you still get this error? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From a more inward looking stance, I don't believe that losing Ingrid will be a disastrous blow to Koha. Development and bug fixing are both moving forward, and the community seems to be quite healthy. There are also good signs in the larger oss4lib community around us, members of different development groups are talking together and there seems to be some interest in cooperating where it makes sense. Where do we go from here? Well, it's important to find a new QA/Testing manager. It's also important for us to get a rock-solid 2.0.0 release out the door. I'm confident that we'll accomplish both, and in the fairly near future. thanks, -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org From a topic mentioned in there: is requiring JavaScript a bug? A nice thing about koha is that most aspects of accessibility are there and it shouldn't be too hard to complete. Requiring JS will make it difficult. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult." From this post I'm wondering what version of Koha I should be using on Apache 2.x, Is 1.2.3 the right one? regards Steven -----Original Message----- From: MJ Ray [mailto:markj@cloaked.freeserve.co.uk] Sent: Thursday, 19 June 2003 11:43 AM To: koha-devel@lists.sourceforge.net Subject: Re: [Koha] Re: [Koha-devel] Re: Koha Setup Question Christopher Hicks <chicks@chicks.net> wrote:
One of the things I found in moving to Apache 2.0 [...]
When mentioning Apache 2.0, it's probably quite useful to know what process/forking model you're using. I've not noticed many problems yet, but I've not seriously hammered koha 1.9.x yet. Right now, I keep installing and reinstalling... -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult." ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel From MARC documentation online at Library of Congress (URL <http://lcweb.loc.gov/marc/>) the description of what the Leader is, is under the rubric of the Concise MARC 21 Bibliographic data at URL <http://www.loc.gov/marc/bibliographic/ecbdldrd.html>, to wit, LEADER A fixed field that comprises the first 24 character positions (00-23) of each record and provides information for the processing of the record. The leader is followed immediately by the Directory, which provides a computer-generated index to the location of the variable control and data fields within a record. [i.e. what we think of as the bibliographic data, what we enter] The Directory immediately follows the Leader at character position 24 and consists of a series of fixed-length (12 character positions) entries that give the tag, length, and starting character position of each variable field. In casual usage, the Directory is often thought to be part of the Leader and both are referred to together as the Leader. As for 'setting' it, you can't. That is, the computer has to be able to generate certain data elements (lengths, positionals). You may already know how to do that; I have no clue how it's done. In terms of coding the Leader, that must be done individually for each record based on the actual data of the record. The Directory, following from the definition, is directly depended on the actual data and size of the record; any changes/updates to the record automatically change the data coded into the Directory. You might be able to use a provisional, kind of rudimentary coding for the Leader, setting, by default, position 5 to n for New position 6 to a for Language Material (most common) position 7 to m for Monograph (most common) position 8 as blank position 9 as blank position 17 as 2 for less-than-full level, material not examined position 18 to a for AACR2 (or otherwise as accurate) I have no idea at all how to code the other required positions. Like most end-users, I guess just having worked with the systems we've had, the systems always did all the other bits which are equally crucial. I hope some of this helps you figure out a script. You might also want to take a look at the Understanding MARC Bibliographic, especially the end part at URL <http://www.loc.gov/marc/umb/um11to12.html> and check through the MARC Tools and Services section to see if one of the tools there that is noted as working with/for Perl scripts might help. Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB CANADA From the manual: "MySQL can use indexes on columns more efficiently if they are declared the same. (For ISAM tables, indexes may not be used at all unless the columns are declared the same.)" does this apply here? Do we need to eliminate column length and type=20 mismatches? Is 'range' the proper type for m2? Would things speed up if we eliminated resolving the diffs between bibid and biblionumber and saved that for Perl to do after the result set has been returned (or would this just create another query and take longer). In general, could we trim down the complexity of the query and eliminate one or two of the joins (I realize that my example has three terms and so is not the most efficient, however, it's a very popular search type for us)? Perhaps our real solution will be new hardware and a replicated database on a seperate server for searching ...=20 Thanks, Joshua