Hi Jake,
When you installed OpenSRF, did you also enable all the parts to run
websockets? For the Evergreen web staff client, this parts are required.
And also it could be that even if you did enable, depending on whether
there was firewall, etc. it might be affecting your browser connection to
Hi Jane,
Thanks for the questions!
Just a comment about Pootle... during the last Hack-A-Way, we did
setup a Pootle test instance and it was unable to distinguish and was
actively stripping out the code elements needed for angular from the
generated xliff files. Because of this, we started to
surprised or bug fixes change something).
This separates my i18n concerns from the primary XUL retention question.
I still vote "yes" though.
-- Ben
On Wed, Aug 29, 2018 at 12:21 PM Ben Shum wrote:
>
> I vote "yes" to getting rid of XUL now.
>
> From i18n si
I vote "yes" to getting rid of XUL now.
>From i18n side of things, we've been working around the problems with
running the translation process with our old XUL code by using the
older template toolkit set from Ubuntu 14.04. That Ubuntu version is
EOL next year April 2019, and I'd rather not have
translations that we already have due to major
structural changes in how the code/strings work.
-- Ben
On Thu, Aug 16, 2018 at 8:37 AM, Ben Shum wrote:
> Hi Bill,
>
> Spinning up a Pootle instance has been on our community to-do list for
> awhile as part of our ongoing discussions abou
Hi Bill,
Spinning up a Pootle instance has been on our community to-do list for
awhile as part of our ongoing discussions about the desire/plans to
switch off Launchpad. I started playing with this during the last
couple conferences locally in a VM on my laptop, but we still have yet
to agree on
Hey Yamil,
Take a look at this wiki page:
https://wiki.evergreen-ils.org/doku.php?id=server_installation:semi_automated
It has a listing of various "semi" automated installation scripts
folks have put together.
I've been using berick's ansible script for Ubuntu 16.04 as my primary
test platform
Those sound like the right places (by default). Maybe also the apache
log, which I think goes towards /var/log/apache/*.log
You did restart apache service after you ran autogen, right? And exit
out of the client and try over.
-- Ben
On Sun, Apr 10, 2016 at 12:39 PM, Chris Rafferty
d be interested in knowing some more about what you changed within
> eg.conf, Ben.
>
> Thanks,
> Kelsey
>
> On Sun, Mar 6, 2016 at 7:58 PM, Ben Shum <b...@evergreener.net> wrote:
>>
>> Hi Kelsey,
>>
>> I've been using Let's Encrypt on my personal Ev
Hi Kelsey,
I've been using Let's Encrypt on my personal Evergreen test server
(https://demo.evergreener.net) for this past month or so. Prior to
that, I used Let's Encrypt for some other test systems at my previous
place of work.
The biggest issue I encountered initially was that my system
So, the AFOK was removed from Evergreen during 2.7 series' development.
This is the Launchpad number for the change:
https://bugs.launchpad.net/evergreen/+bug/1246745
This is a link to the change in git:
Hi Jesse,
Surprisingly enough, I just went back through the upgrade scripts so
far from 2.6 to 2.7, and I cannot find anything that explicitly
requires a reingest action. Which is probably why there's no mention
of it in the existing upgrade scripts or instructions.
That said, I usually
Actually, I take it back. There appears to have been a missed
reingest needed to combat an ingest function that was repaired during
2.6.3's time.
We're going to coordinate some new maintenance releases shortly, and
this will be reflected then.
-- Ben
On Tue, Feb 3, 2015 at 3:31 PM, Ben Shum bs
Hi Bill,
Dates look reasonable to me. Having gone through the alpha cutting
stage myself now, I may agree with you that very few people tend to
test them and provide feedback with the majority often waiting for the
beta when more features have been added of note or substance. Or you
know...
Hi Tim,
When we upgraded to Evergreen 2.6, we also changed a lot of our
infrastructure in terms of moving to better database server equipment
(faster CPU, memory, using SSDs, etc.) so at first, we felt things
were nice and speedy. Things became slow for us due to unforeseen
performance issues
Agreed, I really like the potential dates suggested for end of September.
Hopefully we will be done with 2.7.0 release and free to start fresh on
the next round of development work too!
-- Ben
On Mon, Jul 21, 2014 at 2:51 PM, Sharp, Chris csh...@georgialibraries.org
wrote:
Sounds good to me!
Hi Terran,
Bill can probably answer the rest, but just to get a quick reply out there
on the four digits as password for new accounts in patron registration...
yes, that is a library setting that must be configured on the server. By
default, that is not enabled and you will get a randomly
Hi folks,
We will be fast approaching the intended deadline for our first alpha cut
for Evergreen 2.7, which is due this Thursday, July 10, 2014.
This is a link to launchpad bugs which are targeted for work during 2.7:
https://launchpad.net/evergreen/+milestone/2.next
The same target list, but
As is, Evergreen staff client development stopped with xulrunner 14 around
Evergreen 2.2. Beyond that version of xulrunner, there are more issues with
parts of the staff client, like MARC editing (I think) and others.
For myself, I just use the Linux 64 bit tarball that's generated with my
staff
Since the dates are fast approaching, I'm making an executive decision and
setting the next developer meeting date and time as Thursday, June 12, at
2:00 pm ET.
A draft agenda has started at
http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-06-12
Please feel free to add items for
Hi Tim,
So, there's different ways that the Evergreen Community has applied
milestones for tracking over the years and some of the concepts have
changed over time depending on the nature of the release process and the
specific bugs involved. For some additional history, in the past, we used
to
I'd be curious also how the system was setup. This may not be a
related problem, but if the IP or hostname were changed on the machine
between restarts, it's possible ejabberd is not starting back up
properly or trying to listen for things that no longer exist.
This has happened in other email
For whatever it's worth, the IRC logs are generally updated instantly.
You can view http://irc.evergreen-ils.org/evergreen/today as a link
to the logs for a given day, and as folks type in channel, it should
get logged immediately and displayed on refresh of that page.
-- Ben
On Mon, Mar 24,
+1 from me to the lunch time meeting. That would be fine for me.
-- Ben
On Thu, Mar 20, 2014 at 10:01 PM, Galen Charlton g...@esilibrary.com wrote:
Hi,
On Thu, Mar 20, 2014 at 8:33 PM, Galen Charlton g...@esilibrary.com wrote:
I suggest that we meet in the hotel lobby at 11:45 a.m. and find
For whatever it's worth, I've always really appreciated how simple TT2
was to learn once it became such a huge part of our lives with the
current Evergreen catalog code. So perhaps I'm far less wary of
having TT2 use extended and applied where it makes sense to do so in
other places. While we
+1 from me, fearless leader.
-- Ben
On Dec 19, 2013 10:44 AM, Dan Wells d...@calvin.edu wrote:
Hello all,
Back at the dev meeting on Nov. 12, I made an offer to continue as RM for
an abbreviated 2.6 release. In the meeting, the discussion concluded with
Galen suggesting that “voting the
Actually, we tend to make use of that Assigned to field in
development to indicate that a particular bug is intended to be worked
on by the assigned person. This is especially tied to use of the
status In Progress with a particular person assigned to that bug.
Additionally, sometimes reviewers
Hi Carl,
Yes, unfortunately we noted similar reaction times when using xulrunner
1.9 with older Evergreen versions. The most I ever learned about this
was that xulrunner 1.9 was just darned slow on Macs. Since it wasn't
being supported by Mozilla anymore, we never got to the bottom of it.
The
Hi all,
From one of the late Saturday night conversations post-conference, I
mentioned a recent post shared by Anoop Atre in G+ and IRC about the
near git disaster suffered by the KDE project earlier this year. See
full article here: http://jefferai.org/2013/03/24/too-perfect-a-mirror/
For fun
Hi all,
As noted in http://www.google-melange.com/gsoc/homepage/google/gsoc2013,
the organization applications open March 18 and end on March 29
(today). At the March developer meeting, I'd volunteered to be the lead
administrator for Evergreen's application and coordinate activities
related to
Hi Galen,
Backporting both of those fixes to rel_2_1 sounds reasonable to me. The
Wheezy part only makes sense though if we're intending that OpenSRF 2.1
(and by extension Evergreen 2.3 and 2.2) will be usable on Wheezy.
Otherwise, we could also just leave that Wheezy support for OpenSRF 2.2
I was not around much yesterday, so I'm still playing catch up with
everything that's happened. But I feel that I need to say something in
this area as well.
First of all, I'd like to emphasize that I am very grateful and
appreciative of efforts made by *all* developers in this community to
Just noting some minor issues as I was worked through upgrading a copy
of our production DB with the new upgrade scripts:
0752: evergreen.is_json might be public.is_json on older upgraded
databases; creating that as a new function or changing the script to
allow for the old naming worked for
Well, in our consortium, we also do not use any SSN identifiers for
similar reasons to the others listed thus far. We actually use the
ident_value field to store student ID numbers for our school library
patrons as an alternate means of identifying students separate from
barcodes, etc. The
to test in the future.
-- Ben
On 07/30/2012 01:17 PM, Mike Rylander wrote:
On Mon, Jul 30, 2012 at 12:32 PM, Ben Shum bs...@biblio.org wrote:
Hi folks,
So here's a situation. A library system has multiple branches, and each
owns their own copies/patrons. Library A owns a copy of an item
Hi folks,
So here's a situation. A library system has multiple branches, and each
owns their own copies/patrons. Library A owns a copy of an item and
Library B does not. But patrons from both A and B place holds against
the material. Because of how holds target / opportunistically
Hi Bill,
I've updated the website's downloads page to reflect the alpha2 release.
Cheers,
-- Ben
On 7/18/12 4:35 PM, Bill Erickson wrote:
Hi,
Evergreen 2.3.0 Alpha2 files are uploaded. The usual suspects should
all be there.
Server:
Hi Robert,
In anticipation of this request, I had already written a git commit to
change the page to the new link once you informed us that the docs end
of things was squared away.
Website updated!
Thanks,
-- Ben
On 7/11/12 9:49 AM, Soulliere, Robert wrote:
Hi,
I wonder if it would be
I'm not sure, but it seems like it may not be possible to use
marc_export script to extract only a single library's holdings as
associated to bib records.
Using an option for --library SHORTNAME definitely gives me the bib
records with that library attached, but using the option for --items
For 2.2, the goal was to replace the original slimpac (simple OPAC) with
Tpac and it is there now as the simple catalog. However, there is still
ongoing work to further enhance and refine various aspects and add
features to Tpac before it will fully replace the JSPac. The projected
time
Hi folks,
So I've been trying to figure out how best to hide prefix/suffix from
being seen in the volume editor since we're not planning to implement
these at this time.
We've tried using the CSS example to hide both prefix and suffix from
view, and it results in errors when trying to
It seemed to be going well till I hit this and the rest of the script
died out:
psql:Evergreen/Open-ILS/src/sql/Pg/version-upgrade/2.1-2.2-upgrade-db.sql:15328:
ERROR: cannot drop language plperl because other objects depend on it
DETAIL: function migration_tools.add_codabar_checkdigit(text)
So I skipped over the drop language command and now hit my next snag:
psql:Evergreen/Open-ILS/src/sql/Pg/version-upgrade/2.1-2.2-upgrade-db.sql:15516:
ERROR: malformed JSON string, neither array, object, number, string or
atom, at character offset 0 (before (end of string)) at line 20.
Website updated with the provided patch. Thanks Dan!
-- Ben
On 04/03/2012 10:05 AM, Dan Scott wrote:
Not that I think there is an OpenSRF release team, but if there was you
might be interested in knowing that I've uploaded OpenSRF 2.1.0 RC1 to
Downloads page updated to include links to Evergreen 2.2 alpha3.
Includes links to OpenSRF 2.1 alpha1 too.
Question, should we generate the README and RELEASE_NOTES text files to
give folks some stuff to look at? Maybe more stuff to store in various
/preview subdirectories...
-- Ben
On
Hi all,
Should we consider moving our developer meeting time to a different hour
of the day in order to accommodate folks? It seems that the 12 pm EST
on Tuesdays tends to be difficult for several since it conflicts with
lunchtime. berick had suggested later in the afternoon so that we can
Hi Rob,
If memory serves, all the "ue" files are legacy patron registration
elements from earlier versions of Evergreen (1.6 and earlier). The
current 2.0/2.1 stable series utilize other files for patron
registration / edits, which is probably why they're all
I'm not sure yet, still thinking on this, but curious, when you deleted
entries, did you remove any extra outputs from action_trigger.event_output?
Perhaps you have remnant entries in there that are still trying to be pushed,
but since you deleted the associated acq.* contents, it doesn't
Greetings! This is an announcement that our next Evergreen Community IRC
Meeting will be held at:
* 11:00:00 a.m. Friday Dec 2, 2011 in America/Los_Angeles
* 02:00:00 p.m. Friday Dec 2, 2011 in Canada/Eastern
* 07:00:00 Friday Dec 2, 2011 in UTC
This is a public meeting for the Evergreen
Some thoughts below based on what I know so far with my very limited
poking around...
On 11/15/2011 7:01 PM, Scott Prater wrote:
I'm working on the patron statistical category enhancements. I made
the changes to the database, adding a few columns and a new table, and
I updated the install
Hi Lori,
Overall read pretty well to me. One tidbit I saw was that the list of
core committers on page 2 did not include Thomas Berenzansky from
Merrimac Valley Library Consortium. His name is on the wiki page
equivalent:
http://open-ils.org/dokuwiki/doku.php?id=contributing:contributors
Greetings! This is an announcement that our next Evergreen Community
IRC Meeting will be held at:
* 11:00:00 a.m. Friday Nov 4, 2011 in America/Los_Angeles
* 02:00:00 p.m. Friday Nov 4, 2011 in Canada/Eastern
* 07:00:00 Friday Nov 4, 2011 in UTC
This is a public meeting for the Evergreen
Hi Jason,
It's funny you should ask on dev, one of my colleagues is seeking
similar assistance in the general list I think.
I suggest taking a peek at the following two places:
http://markmail.org/message/nodjs2m7e247dqw2
http://markmail.org/message/nodjs2m7e247dqw2 - is a link to a screenshot
Comparing differences between various installation wiki pages, it looks
like the exit command in the Evergreen install steps was changed to .
~/.bashrc # inherit the new environment at some point between Evergreen
1.4 and 1.6.0. The OpenSRF wiki pages weren't as scrutinized
apparently, but the
Greetings! This is an announcement that our next Evergreen Community
IRC Meeting will be held at:
* 11:00:00 a.m. Friday Sept 23, 2011 in America/Los_Angeles
* 02:00:00 p.m. Friday Sept 23, 2011 in Canada/Eastern
* 07:00:00 Friday Sept 23, 2011 in UTC
This is a public meeting for the
Pushed minor tweaks for hold_matrix_matchpoint similar to what I observed for
the circ_matrix_matchpoint table to this working branch:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/2.0-2.1-hold_matrix_fix
Trying another test with those modifications in
Hi Mike,
I think this approach will work great, unless the site in question
doesn't have the correct ID values appropriate to the code. In our
case, since we had identified some missing permissions didn't exist yet
in 2.0, but required it before the community had added them, something
like
Continuing along the lines of what Robert has, these were the results from our
attempts to use the existing 2.0-2.1 upgrade script. Our test system is based
on 2.0.6, but contains database patches up through 2.0.8 release.
Line 13 - CREATE SCHEMA evergreen
This fails and subsequently kills
Short follow-up, just tested our script on a freshly restored test copy
of our DB and hit this error twice now:
psql:Evergreen-ILS-2.1-RC2/Open-ILS/src/sql/Pg/2.0-2.1-upgrade-db.sql:6003:
ERROR: function force_unicode_normal_form(text, unknown) does not exist
LINE 1: SELECT
Hi everyone,
We have our regularly scheduled IRC meeting in the #evergreen channel on
Freenode at 12:00 noon EST tomorrow, August 16, 2011.
The agenda has begun at
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-08-16
See you there!
-- Ben
Evergreen 2.1-RC2 staff client has been built and uploaded to web server.
I had to manually bump the xulrunner version to 1.9.2.19 for the win client to
build properly. Noted this in the steps taken for RC2 on the wiki.
Pushing changes to website git repo for the downloads page, but won't
, 2011 at 2:16 AM, Ben Shum bs...@biblio.org wrote:
Evergreen 2.1-RC2 staff client has been built and uploaded to web server.
I had to manually bump the xulrunner version to 1.9.2.19 for the win client
to build properly. Noted this in the steps taken for RC2 on the wiki.
Pushing changes
2.0.8 staff client built and uploaded to downloads folder.
-- Ben
On 08/09/2011 12:11 AM, Mike Rylander wrote:
... finally. Please have at the Staff Client and web bits.
Updated downloads page on website, and wiki instructions.
-- Ben
On 08/09/2011 07:51 AM, Ben Shum wrote:
2.0.8 staff client built and uploaded to downloads folder.
-- Ben
On 08/09/2011 12:11 AM, Mike Rylander wrote:
... finally. Please have at the Staff Client and web bits.
Hi Elliot,
Looks like Chris nailed an important part of the database restore process.
I'd like to point you also to this wiki page:
http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-admin:maintenance:backups
The section entitled Backing up the Evergreen database includes some
generic
Hi Liam,
I believe every organization deals with bug reporting differently. At
our site, I manage most all of the Launchpad bug reporting for
Bibliomation's libraries, and help to provide more detailed explanations
of issues to the community. We end up resolving most things in-house
first
Hi everyone,
We've received reports of problems using the latest release of Evergreen
2.0.7 with locales other than en-US and have traced it back to a
problem with one of the locale files being empty (circ.properties).
This also affected the Evergreen 2.1-RC1 as well.
Mike Rylander is
Staff client has been built and uploaded to server.
Downloads page set as well.
-- Ben
On 06/28/2011 03:50 PM, Mike Rylander wrote:
http://evergreen-ils.org/downloads/Evergreen-ILS-2.0.7.tar.gz
http://evergreen-ils.org/downloads/Evergreen-ILS-2.0.7.tar.gz.md5
The staff client was built and has been copied over to
/downloads/previews. I ended up having to make a minor tweak to the rc1
windowssetup.nsi file in order for the build to complete without errors.
The downloads page has been updated. It's ready to go as soon as we do
a git refresh on the web
Hi June,
I think it depends on which labels are being altered. Most of the pieces in
lang.dtd related to staff client pieces for patron registration are legacy
editor pieces from the pre-2.0 patron registration, I think.
Checking our local customizations, it looks like to change staff client
One minor edit:
The agenda link should be
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-05-24
2012 is going to be an awesome year though :)
-- Ben
On May 23, 2011, at 11:01 PM, Dan Scott wrote:
If you work on Evergreen or OpenSRF code, then you should join the
Evergreen
Hi Dan,
I've copied the pertinent files from legacy over to live and also copied the
ChangeLog file to the server as well.
Web pages have been updated so that links and names are correct. I've also
changed the wiki install instructions for opensrf-2.0 to reflect this official
release
Awesome job with this Anoop! I really enjoy the new design elements and how
much community input has gone into this work.
I made a couple of changes to the repo's after Dan committed your changes.
One major thing of note that I would like to seek feedback on: use of short
tag ? instead of
Greetings! This is a reminder that our next Evergreen community IRC
meeting will be held at:
* 11:00:00 a.m. Friday April 1, 2011 in America/Los_Angeles
* 02:00:00 p.m. Friday April 1, 2011 in Canada/Eastern
* 07:00:00 p.m. Friday April 1, 2011 in UTC
This is a public meeting for the
Patch for downloads.php attached. I included links to older 2.0 staff
clients on the page again temporarily for now while we work to shift
contents around the old code museum page. Also made some tab to
whitespace changes.
Will update the wiki install pages accordingly with the newest
Staff client done, wiki has been updated. See attached file for update
to downloads.php page.
-- Ben
On 03/09/2011 02:59 PM, Mike Rylander wrote:
... and uploaded to the usual spot. ChangeLog is next to it. Next
up: Staff Client, downloads page, wiki, blog and email announcements
... in
For fun I tried those steps outlined with a test box running Squeeze and
Evergreen 2.0.1 and pointing at a copy of our 2.0 database. Overall the
steps worked quite flawlessly, though I did have to use a slightly
different path directory for the OpenILS/WWW contents than what was
given on the
I noticed that the local unix.log files being generated on each of our
servers keep repeating the same messages over and over. Safely
ignorable or indication of big problems elsewhere? What are the unix
log messages supposed to be telling us?
In open-ils.storage_unix.log, this message repeats
Greetings! This is a reminder that our next Evergreen community IRC
meeting will be held at:
* 11:00:00 a.m. Tuesday March 1, 2011 in America/Los_Angeles
* 02:00:00 p.m. Tuesday March 1, 2011 in Canada/Eastern
* 07:00:00 p.m. Tuesday March 1, 2011 in UTC
This is a public meeting for the
2.0.2 staff client uploaded by Mike via IRC conversation. Huzzah!
On 02/21/2011 02:48 PM, Mike Rylander wrote:
It's up at the usual spot, just waiting for a Staff Client, the
download page update, upgrade instruction adjustment (safer 1.6.1-2.0,
thanks to testing by George Duimovich, BTW) and
Hi all,
Mike asked me to post this to the -dev list, so here we go:
Earlier this weekend, we began the upgrade process from Evergreen 1.6.1
to 2.0. Specifically our production environment is 1.6.1.3 and we're
going to 2.0.1. We used the upgrade scripts included in the
2.0.1.tar.gz file and
Hi Robert,
Looks like a great start to me. I think it would be good to include
some caveats in an introductory paragraph. Some things to include might
be that there may be an upgrade required to get to PostgreSQL 8.4 (which
is the minimum required version). Also, I'm unsure about 2.0
Greetings! This is a reminder that our next Evergreen community IRC
meeting will be held at:
* 11:00:00 a.m. Tuesday January 25, 2011 in America/Los_Angeles
* 02:00:00 p.m. Tuesday January 25, 2011 in Canada/Eastern
* 07:00:00 p.m. Tuesday January 25, 2011 in UTC
This is a public meeting
These questions are aimed mostly for Jason, our head bug wrangler, but I
would appreciate any other suggestions for best practices when helping
with bug management on Launchpad.
How do we decide which bugs we target to different milestones? Is that
action designed to put a face on bugs that
The next developer meeting will be held in the #evergreen IRC channel on
the Freenode network tomorrow at:
09:00:00 a.m. Tuesday January 4, 2011 in America/Los_Angeles
12:00:00 p.m. Tuesday January 4, 2011 in Canada/Eastern
04:00:00 p.m. Tuesday January 4, 2011 in UTC
The evolving agenda for the
I'm not sure what canonical composed form quite means, but I believe
that the marc field in biblio.record_entry uses a marcxml format. See
http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd for some more
information.
Maybe someone else can comment on the more technical parts of that.
--
Greetings! This is a reminder that our next Evergreen community IRC
meeting will be held at:
* 11:00:00 a.m. Tuesday December 21, 2010 in America/Los_Angeles
* 02:00:00 p.m. Tuesday December 21, 2010 in Canada/Eastern
* 07:00:00 p.m. Tuesday December 21, 2010 in UTC
This is a public
AM, Dan Scott wrote:
On 28 November 2010 06:23, Ben Shum bs...@biblio.org wrote:
I was poking around with the 1.6.1-2.0 upgrade script that comes with
Evergreen 2.0 Beta3. Two issues came up during our upgrade process
using a copy of our live production data (based on a 1.6.1.4 system
Anoop Atre and I were working through 1.6.1.3 issues on IRC
(http://www.open-ils.org/irc_logs/evergreen/2010-11/%23evergreen.12-Fri-2010.log)
and noticed that our reports were malfunctioning. After a few twists
and turns we found that there was an issue with this changeset that was
applied for
Hi all,
The official meeting time for the Developer IRC Meeting has been
decided! We will meet earlier at:
* 08:00:00 a.m. Tuesday November 2, 2010 in America/Los_Angeles
* 11:00:00 a.m. Tuesday November 2, 2010 in Canada/Eastern
* 03:00:00 p.m. Tuesday November 2, 2010 in UTC
This is
Hi all!
At the conclusion of the last IRC meeting it was decided to discuss on
the mailing list the exact time we wished for this meeting. While
tentatively scheduled for 2 p.m. Eastern, there was also the suggestion
to start earlier in the morning instead and aim for 11 a.m. Eastern.
Please
Hi Thomas,
Wow, very cool stuff. I applied it by hand to one of my Linux staff
client folders for EG 1.6.0.2 and it seemed to work quite well.
From the patch though, the setting in prefs.js was shown to be:
pref(open-ils.toolbar.defaultnewtab, false);
I had to set this to true in order to
going to give the upgrade from 1.6.x
a whirl once we get our test database in order.
Cheers,
Ben Shum
On 10/14/2010 11:04 AM, Soulliere, Robert wrote:
Thanks Mike,
I got them to reingest after cleaning up the marc field in the
biblio.record_entry table.
For other who venture into this:
One
Hi Robert,
I'm not sure about the source of the yaz-client problem, but I
replicated your test for the SRU connection using yaz-client version
3.0.52 (using a Ubuntu 10.04 desktop) and it returned similar failures.
I tried the same test using a yaz-client on one of our test servers,
version
94 matches
Mail list logo
