- Koha-devel - lists.koha-community.org

FW: Koha 1.3.0 released (with message this time)
by Eyler, Patrick 24 Sep '02

24 Sep '02

Koha 1.3.0 has been released. This release marks the beginning of public development and testing of the MARC compliant Koha we've been Looking forward to. As the 1.3 releases stabilize and reach feature completion, they will become Koha 1.4. This is an alpha quality release only. *DO NOT ATTEMPT TO USE IT IN PRODUCTION SYSTEMS* It may cause data corruption or loss, it may confuse patrons, it may cause books to refile themselves in strange places. *IT SHOULD BE USED FOR TESTING ONLY*. (I hope that's clear enough.) If you are want to use Koha in a production setting, please stick with the stable 1.2 release until the 1.3 series stabilizes enough for us to create Koha 1.4.0. Significant new features in this release include: * Data is stored natively in a MARC based format. * Multiple flavors of MARC are supported. * Enhanced API supports both the new MARC format and the older Koha specific format. Please note though, that from a users perspective, this release should look just like a 1.2 series release. All of the work so far has been in redesigning the data format and extending the API. User visible changes will be included once the infrastructure has stabilized. It is also important to note that the simple acquisition system is currently broken. *DO NOT EVEN THINK ABOUT USING IT* The full acquisition system works correctly. Paul Poulain Pat Eyler 1.4 Release manager Kaitiaki/manager the Koha project the Koha project

1 0

Koha 1.3.0 released
by Eyler, Patrick 24 Sep '02

24 Sep '02

1 0

RE: building a community
by Eyler, Patrick 23 Sep '02

23 Sep '02

> -----Original Message----- > From: Rhyno Art [mailto:arhyno@server.uwindsor.ca] > Sent: Monday, September 23, 2002 6:57 AM > To: discuss(a)callimachus.org > Subject: Re: building a community > > Wow, very impressive, Koha is doing great and is a much needed > success > story for OSS in libraries. Thanks, it's always nice to hear kudos. > I am involved in two library-related > open > source projects, one called PYTHEAS > <http://www.uwindsor.ca/library/leddy/people/art/pytheas> and > another > called WIBS <http://wibs.sourceforge.net>. PYTHEAS started out > somewhat > similar to Koha, it had some PHP instead of Perl, but used MySQL on > the > backend, and even had a middle layer written in C. I managed to get > a 6 > month study leave to work on OSS, about half of which I used to > study the > current trends in how to put enterprise systems together. Thanks to > initiatives like Koha and Avanti, my feeling was that the options > for small > to medium sized libraries were becoming much better defined, but 15 > years > of working in a university environment had made me yearn for an > option for > large academic libraries, and one that plugged into other > environments. It > has always bothered me from a systems viewpoint that universities > constantly replicate systems between departments and that mainstream > software, such as LDAP servers, were very rare for university > administrative systems. I agree, it would be nice to see more emphasis on getting LDAP and similar tools into libraries. Perhaps turnkey system approaches built from OSS are the key to proving that this kind of tech not only works, but is a good fit for libraries. > > Anyway, my study leave led me to look closely at Enterprise Java > Beans > (EJB), which latter lead to Web Services and SOAP. I was also trying > to > maximize the use of XML since one of my first tasks as a systems > librarian > was working on a MARC editor for Stanford's SPIRES database and > rather than > repeating the experience, I felt that XML was the key to freeing > MARC from > quirky editing applications. None of this is an attempt to convince > anyone > of the benefits of Java, XML, or middleware infrastructures like > EJB, but > one area where I think we could share some of our efforts is in how > we map > our data structures. For example, I think Koha's MARC work, at one > time at > least, used an early version of the table layout defined for > PYTHEAS. Lots > of work and mistakes since then have led to numerous changes in the > layout > and I would be very interested in seeing if some of this learning > process > would be of use to anyone else. For that matter, any of the projects > that > use an RDBMS on the backend could probably benefit from sharing > ideas on > mapping and information retrieval with relational systems. > I agree, this might be an excellent place for callimachus to shine. > WIBS was based on the MRBS (Meeting Room Booking System) and was a > much > simpler endeavor. In fact, it was mainly put together to avoid > coming up > with the outrageous amounts that the commercial options for > workstation > booking seemed to require. Like MRBS, WIBS is a PHP/MySql > application but I > am currently reworking it to use the University of Washington > Calendar > Server. Is this an ICal (and related tech) thing? Do you have an URL for it? > Again, this ventures into Java territory, but my switch is > motivated by similar concerns. We would like to pass booking > information > between the university's main calendar systems (Lotus Notes) and > personal > calendar systems, and a true calendar server provides the plumbing > to > easily support iCalendar and other standard data formats for > calendar > information. This could all be built by hand in PHP but my minimal > amount > of time for OSS activities is already shrinking and it didn't make > sense > for me to rebuilt what others have done. I am also keen to keep in > line > with the Java in Administration Special Interest Group (JA-SIG) > <http://www.ja-sig.org/> and Java is a key part of this (though as I > have > told Pat, if I had my druthers, I would be working in nothing but > Python!). > > I have found that in a university environment, Java tends to open a > lot of > doors, not because of anything intrinsic to the language, but > because it > has such a rich and evolving set of APIs. Still, I have been through > more > grief trying to help people set up Java-based applications like > Tomcat than > anything I have seen with PHP, Perl, or other common types of OSS > solutions, so I am glad to see a variety of options available for > libraries > installing systems. Unlike Koha, my sharing of code has largely been > directly with other universities, and most of the projects I have > seen from > this have been very low profile. I am blown away by how well keeping > the > project in the public eye has served Koha and my hat is off to Pat > and all > the folks who have made this happen. Remember, I am still hoping at > least > one spokesperson for Koha might be at the upcoming Access conference > <http://www.access.uwindsor.ca> and could give an update at the > software > rodeo we are trying to put together. I'd like to get us there. Any volunteers from the devel list? Thanks, -pate > > art > --- > Art Rhyno, Systems Librarian > Leddy Library, University of Windsor > Internet: arhyno(a)uwindsor.ca > Tel: (519) 253-4232, EXT. 3163 > FAX: (519) 973-7076 > WWW: <http://www.uwindsor.ca/library/leddy/people/art>

1 0

buildrelease
by Andrew Arensburger 21 Sep '02

21 Sep '02

I've been looking at the 'buildrelease' script, and have a few comments and questions about it. For one thing, it looks for ".kohaautobuild.conf" and "docs/" in root's home directory, rather than in the current user's home directory or the CVS build directory. I assume these are considered bugs. Also, it uses "cp -a", which isn't portable (neither FreeBSD's nor Solaris's 'cp' take a "-a" option). The way it builds the distribution directory (which will be tarred up as the distribution tarball) is to copy everything from the CVS build directory into /tmp/koha-1.2.3/intranet-cgi, and then move things around, or delete unwanted files. The problem with this is that it can leave an awful lot of cruft in the intranet-cgi directory, which might therefore wind up in the end-user's internal/cgi-bin directory. I don't know about y'all, but I tend to generate a fair number of temporary files that shouldn't wind up in the release. For instance, if I find a security hole in "somescript.pl", I might make a backup copy "somescript.pl.buggy" for reference before fixing the bug. The way 'buildrelease' and the installation instructions are currently written, "somescript.pl.buggy" will wind up in a number of end-users' internal/cgi-bin directories. And since the source and revision history are there for all to see, it'll be fairly easy for a black-hat to write an exploit. A better approach, IMO, would be to have a file that specifies which files are to be included in the distribution, and where: ChangeLog* . search.pl intranet-cgi search.pl opac-cgi koha-html/intranet-html/index.html intranet-html ... So that all of the ChangeLog* files will be copied to /tmp/koha-1.2.3, "search.pl" will be copied to both /tmp/koha-1.2.3/intranet-cgi and /tmp/koha-1.2.3/opac-cgi, koha-html/intranet-html/index.html will be copied to /tmp/koha-1.2.3/intranet-html, and so forth. If people tell me, "you found the bug, you fix it", I will. Oh, and a general comment about Koha: none of these CGI scripts perform taint checks, even though they take user input. IMO this is a Bad Thing. -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com Reality? But there are DIRTY DISHES in Reality!

2 1

RE: FW: [Koha-devel] buildrelease for 1.3.0 => steve ?
by Eyler, Patrick 20 Sep '02

20 Sep '02

> -----Original Message----- > From: Tonnesen Steve [mailto:tonnesen@cmsd.bc.ca] > Sent: Friday, September 20, 2002 8:41 AM > To: Eyler, Patrick > Cc: koha-devel(a)lists.sourceforge.net > Subject: RE: FW: [Koha-devel] buildrelease for 1.3.0 => steve ? > > > On Fri, 20 Sep 2002, Eyler, Patrick wrote: > > > Let's build a 1.4-unstable package to put it in. I think the 1.2 > series > > will likely continue to get some love until (at least) next summer > > (people will take a while to upgrade), and I'd like us to be able > to > > support both trees in the interim. v> > 1.4-unstable should maybe be used for 1.4 release candidates? We > should > have a koha_1.3 package for the 1.3.x releases. > I wanted to reinforce the idea that the whole 1.3 series is the unstable/development cycle for 1.4 .... my thought is that it will go something like this: 1.3.0, ... 1.3.X, 1.4.0RC1, 1.4.0RC2, 1.4.0, 1.4.1RC1, ... 1.4.0, 1.4.1, etc would be in the koha_1.4 package and everything else would go into koha_1.4_unstable I'm open to discussion, and I think the final call belongs to Paul (he's the release manager after all). -pate > Steve. >

1 0

RE: FW: [Koha-devel] buildrelease for 1.3.0 => steve ?
by Eyler, Patrick 20 Sep '02

20 Sep '02

Steve wrote: > On Fri, 20 Sep 2002, Eyler, Patrick wrote: > > Paul asked: > > > Then, should I tag the version ? I think yes. Please confirm. > Yes, tag the release if you are going to release it publicly. This will > allow us to see what has changed in CVS since it was released for bug > confirmation, etc. We can also delete old tags after a certain time so > they don't clutter up the CVS too much. For example, I deleted all of the > release candidates for the 1.2.2 release after 1.2.2 went out. > > > where should I put my tar.gz when builded ? we planned not to release > > > officialy it on sf, so where should I put it after testing install ? > > > > Do we want to put it on sourceforge? I think that might be a good idea. > > We can also make release announcements on Freshmeat. I think that > > active, visible development of the 1.4 tree will draw even more > > developers into the fold. > I'd recommend putting it up on sourceforge. Put it under the > koha-unstable package, I guess. Or do we want a new package for 1.3.x > releases to separate them from the release candidates for the stable > branch? Only the most recent file in a package will show up on the main > sf.net/projects/koha/ page. Let's build a 1.4-unstable package to put it in. I think the 1.2 series will likely continue to get some love until (at least) next summer (people will take a while to upgrade), and I'd like us to be able to support both trees in the interim. > Steve. -pate

2 1

FW: [Koha-devel] buildrelease for 1.3.0 => steve ?
by Eyler, Patrick 20 Sep '02

20 Sep '02

Oops, this should have gone to the list as well... bad outlook, no cookie for you! -pate -----Original Message----- From: Eyler, Patrick Sent: Friday, September 20, 2002 7:59 AM To: 'paul POULAIN' Subject: RE: [Koha-devel] buildrelease for 1.3.0 => steve ? -----Original Message----- From: paul POULAIN [mailto:paul.poulain@free.fr] Sent: Friday, September 20, 2002 7:39 AM To: koha-devel(a)lists.sourceforge.net Subject: [Koha-devel] buildrelease for 1.3.0 => steve ? > Hi, > I try to build a 1.3.0 tarball (wooow !) with the buildrelease script. Wow! This is awesome! > I don't understand well how it manages versions. > I'im in my koha.dev (main trunk) directory. > the script says : > Current release tag is 1.2.3RC14. > Would you like to bump that up to 1.2.3RC15 (or manually enter > version)? [Y]/N: > Should I answer N or Y ? > I found that N build a new 1.2.3RC15 and a Y enables a new version. In > this case, what shall I enter ? 1.3.0RC1 or 1.3.0 ? I think that we can just use 1.3.0, with the development releases, everyone knows that they are potentially broken anyway. Once we go into a 1.4.0 release cycle we can go back to doing RC releases. > Then, should I tag the version ? I think yes. Please confirm. > where should I put my tar.gz when builded ? we planned not to release > officialy it on sf, so where should I put it after testing install ? Do we want to put it on sourceforge? I think that might be a good idea. We can also make release announcements on Freshmeat. I think that active, visible development of the 1.4 tree will draw even more developers into the fold. > thanks for your answers and good week end to everybody thanks for all the work. Enjoy your weekend. Happy hacking, -pate > -- > Paul ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel

2 1

buildrelease for 1.3.0 => steve ?
by paul POULAIN 20 Sep '02

20 Sep '02

Hi, I try to build a 1.3.0 tarball (wooow !) with the buildrelease script. I don't understand well how it manages versions. I'im in my koha.dev (main trunk) directory. the script says : Current release tag is 1.2.3RC14. Would you like to bump that up to 1.2.3RC15 (or manually enter version)? [Y]/N: Should I answer N or Y ? I found that N build a new 1.2.3RC15 and a Y enables a new version. In this case, what shall I enter ? 1.3.0RC1 or 1.3.0 ? Then, should I tag the version ? I think yes. Please confirm. where should I put my tar.gz when builded ? we planned not to release officialy it on sf, so where should I put it after testing install ? thanks for your answers and good week end to everybody -- Paul

1 0

support for Koha in France
by nicolas morin 20 Sep '02

20 Sep '02

Hello, I am working along with Paul Poulain to get support for Koha in France. I recently tried to lobby the French national school for librarianship into supporting Koha. One of their department sounds interested : the Research department conducts researches in librarianship and information sciences. But the thing is : they might be willing to put money into the development of features that clearly are not what most common ILS provide, but not to put money on, say, MARC development. That makes sense for them, since they are a research department. But what Koha needs most, I think, is money to help develop the "usual" features : MARC, Z3950, etc... So : could we come up with something we might be interested in, that would also interest them, a feature at the cutting edge of library systems that would also make sense for Koha to develop? For instance, I thought they might be interested in a system that is truly multilingual, were you can store data in arabic, english, french, chinese, whatever; an Opac you can search in all these languages... It's the only example I could come up with. Any other idea? Any input welcome... Nicolas

1 0

Re: [Koha] Database Structure and Full Features
by Pat Eyler 19 Sep '02

19 Sep '02

Domingo, This question may get more responses from the developers' list. (I'm CC:ing it there.) If you have further technical questions, please feel free to subscribe to the list (see http://www.sourceforge.net/projects/koha for directions) and post them there. I'm sure that you'll find the answers that your looking for. (Maybe whoever answers them would like to do so publicly, and we'll turn your answer into docs on the website <hint>). 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 On Thu, 19 Sep 2002, Domingo Genaro P. Tamayo wrote: > Good day folks! > > We're currently evaluating KOHA as a solution for the Union Catalog > project of the SciNET (Science Network) here in the Philippines. I'm > interested with the database structure and the detailed features of KOHA. > I tried searching koha's site but I can't find those information. > I believe KOHA is an excellent system. I just hope anyone can help me find > the data that I need. > Regards, > > Domingo Genaro P. Tamayo > STII-DOST > > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0