All,
I have gone through the installation of 2.5 RC1 on Fedora 19. I have to
say that it was less bumpy than 2.4 on Fedora 19. The prerequisites
script was much cleaner:
make -f Open-ILS/src/extras/Makefile.install fedora
installed all the rpms correctly and these are the resulting perl mods:
Business::ISSN 0.91
Net::Z3950 0.99
Net::Z3950::ZOOM 1.28
Net::Z3950::OID undef
Net::Z3950::SimpleServer 1.15
Net::Z3950::GRS1 undef
Net::Z3950::Simple2ZOOM 1.04
Template::Plugin::POSIX 0.05
SRU::Utils undef
SRU::Request undef
SRU::Response undef
SRU::Server undef
SRU::Utils::XMLTest undef
SRU::Utils::XML undef
SRU::Response::Record undef
SRU::Response::Diagnostic undef
SRU::Response::Term undef
SRU::Response::Scan undef
SRU::Response::Explain undef
SRU::Response::SearchRetrieve undef
SRU::Request::Scan undef
SRU::Request::Explain undef
SRU::Request::SearchRetrieve undef
Rose::Object 0.860
Rose::Class 0.81
Rose::URI 1.00
Rose::Class::MakeMethods::Generic 0.854
Rose::Class::MakeMethods::Set 0.81
Rose::Object::MixIn 0.856
Rose::Object::MakeMethods 0.856
Rose::Object::MakeMethods::Generic 0.859
Rose::Object::MakeMethods::DateTime 0.81
Class::DBI::Frozen::301 3.0.1
Class::DBI::Frozen::301::Column undef
Class::DBI::Frozen::301::ColumnGrouper undef
Class::DBI::Frozen::301::Query undef
Class::DBI::Frozen::301::Iterator undef
Class::DBI::Frozen::301::Relationship undef
Class::DBI::Frozen::301::Relationship::MightHave undef
Class::DBI::Frozen::301::Relationship::HasMany undef
Class::DBI::Frozen::301::Relationship::HasA undef
Business::OnlinePayment 3.02
Business::OnlinePayment::AuthorizeNet 3.22
Business::OnlinePayment::HTTPS 0.10
Business::OnlinePayment::PayPal 0.11
Business::OnlinePayment::AuthorizeNet::ARB 0.02
Business::OnlinePayment::AuthorizeNet::AIM 3.22
Business::OnlinePayment::AuthorizeNet::AIM::ErrorCodes 0.01
CPAN 1.9800
and these compiled:
libdbi-drivers-0.8.3
In contrast to 2.4 on Fedora 19, it was pretty smooth. With 2.4, I had to manually
install a bunch of the perl modules. I also had to do some things that were "off
installation script" regarding the apache configs.
With that said, I am running into an issue logging into the 2.5 RC1 server with
a windows client. ( I never got 2.4 working correctly with Fedora 19 -
encountered an error during registration of the workstation)
This is the error with 2.5 RC1 on Fedora 19:
Network or server failure. Please check your Internet connection to
192.168.11.119 and choose Retry Network. If you need to enter Offline Mode,
choose Ignore Errors in this and subsequent dialogs. If you believe this error
is due to a bug in Evergreen and not network problems, please contact your help
desk or friendly Evergreen administrators, and give them this information:
method=open-ils.circ.circ_modifier.retrieve.all
params=[{"full":true}]
THROWN:
{"payload":[],"debug":"osrfMethodException : Method [open-ils.circ.circ_modifier.retrieve.all]
not found for OpenILS::Application::Circ","status":404}
STATUS:
and from the shell:
srfsh# request open-ils.circ open-ils.circ.circ_modifier.retrieve.all
Received Exception:
Name: osrfMethodException
Status: Method [open-ils.circ.circ_modifier.retrieve.all] not found for
OpenILS::Application::Circ
Status: 404
------------------------------------
Request Completed Successfully
Request Time in seconds: 0.007245
------------------------------------
I found some old support issues regarding this error:
http://libmail.georgialibraries.org/pipermail/open-ils-dev/2007-May/001133.html
http://list.georgialibraries.org/pipermail/open-ils-general/2011-October/005574.html
These solutions did not solve my issue. Perhaps I am missing something?
-Blake-
Conducting Magic
MOBIUS
573-234-4513
On 10/16/2013 1:54 PM, Justin Hopkins wrote:
Dan,
+1 for your list of goals
I do have 1 tiny commit, but I think that we could satisfy #4. Our
database was started in the 1.6 days and has encountered problems at
pretty much every upgrade which makes it good to test against in my
opinion. Also, Blake is new to the upgrade process so a fresh set of
eyes might do some good.
Regards,
Justin
On Wed Oct 16 11:01:23 2013, Dan Wells wrote:
Hello all,
I am pleased to announce that Evergreen 2.5-rc1 is now available for
download. Once again, thank you to the many folks who put in some
extra time to help us get to this point! You can grab RC1 from the
downloads page here:
_http://evergreen-ils.org/egdownloads/_
Given the relatively short timeframe, the RC period was a bit busier
than expected. In all, 22 bugs were committed in the (roughly) two
weeks since beta1, which you can see here:
_https://launchpad.net/evergreen/+milestone/2.5.0-rc_
My site installed an early cut of the RC upgrade on Friday, and after
a few hiccups (which have since been fixed), things are going smoothly.
So, now that RC1 has landed, how do we get from here to a final
2.5.0? Until now, I have been setting fairly arbitrary deadlines for
milestones, but as the needs of these last few milestones have become
less fluid, selecting target dates has become a little more futile.
For 2.5.0, I’d like to try something a bit different. Basically, I am
proposing that we use a checklist of specific goals, and when we meet
every goal, then 2.5.0 final will be cut. Here are the goals I have
in mind:
1. At least two sites do a clean install of 2.5-rc1 from the release
tarball
2. At least one site upgrades a production database (or exact clone)
to 2.5-rc1 using the release tarball upgrade script
3. At least one additional site upgrades to 2.5-rc1 (code and DB,
production or testing) from the release tarball
4. At least one site managed by a non-committer either installs or
upgrades to 2.5-rc1
The reason these goals specify using the release tarball is because we
want to validate not only the code, but the release process. I should
also note that it’s possible that the event which satisfies goal 4
will at least partially satisfy one of the first three. Overall, what
do we think about these goals as a benchmark for release? Too much?
Not enough? Please reply if you have any feedback on this idea!
Finally, as far as bug management, I have created two new milestones,
both 2.5.0 and 2.5.1. Since the ideal situation for release will be
to make as few changes as possible for 2.5.0, I have moved all but one
bug to 2.5.1. If you think there are things in the 2.5.1 list which
are critical for 2.5.0, please do make a case for them, but also
please keep in mind that if too many changes get applied to 2.5.0, we
may need to release it as RC2 and try the process again.
As always, feedback is welcome.
Thanks,
Dan
Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College
616.526.7133
