More installation fun with ImageMagick

13 01 2008

When I installed ImageMagick from source to install MagickWand, I broke the perl Image::Magick install.  So that the bugzilla checksetup.pl script broke on the check with the error message:

perl: symbol lookup error: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Image/Magick/Magick.so: undefined symbol: MagickCoreGenesis

So I needed to back out the manual ImageMagick build, or perl would be broken.  If that meant losing MagickWand, so be it.
A search for “how to uninstall perl modules” revealed some idiotic comments on the perl.beginners newsgroups to the effect that you’d never want to uninstall a perl module.  I originally attributed it to Randall Schwartz (author of Learning Perl), but in fact, though he was in the conversation, he only made technical clarification.

When an atrocious system like CPAN is your installer (or when you’re using anything that uses autoconf) you WILL want to uninstall something at some point.

Eventually, I decided the only solution I had was to run ‘make install’ again on the ImageMagick source distribution and see what it installed.

After a lot of analysis, it turned out to not be as bad as I thought.  I only had to remove two files:

# rm -r /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Image/Magick*
# rm -r /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Image/Magick*

and  edit perllocal.pod

I found a nice script to clean up perllocal at perlmonks:

http://www.perlmonks.org/?node_id=483020 

I then pruned the remaining Image::Magick sections from perllocal.pod and reinstalled the ImageMagick-perl-6.2.8 RPM.

I haven’t thoroughly tested it yet, but I believe both PerlMagick and MagickWand are still working, though I still have the two versions of ImageMagick.

I also removed the ImageMagick-devel-6.2.8 RPM.





Linode Installation

11 01 2008

QA-Site.com is on a Linode with 360MB RAM and 15GM Disk using the Linode Xen-beta. I pointed the qa-site.com domain registrar to user Linode’s nameservers:

NS1.LINODE.COM
NS2.LINODE.COM

The last couple of days have been spent installing software in order to set up. I still have some CPAN work (for bugzilla) and Python work (for trac) but once that’s ready I’ll take a snapshot as a base OS. I tried to use RPMs for everything (except MagickWand, as noted below) but I might in the future want to have a custom Apache + mod_perl + mod_ssl + mod_python + PHP and MySQL/PostgreSQL for each qa-site. That way install is just a copy & unzip. I would prefer everything to be tidily installed in /usr/local instead of RPMs with config files, init scripts, etc. scattered all over. But one of the advantages of the RPMs is the existing init scripts for things like service httpd start.

One thing I would need to do is remove the gcc dependencies, so I don’t have to add and remove it.

First, I removed the root login from /etc/ssh/sshd_config
Second, I did a complete ‘yum update’ from the CentOS 5 base repository.
Then I installed the web and database RPMs (using yum mostly)

Here is a list of what I’ve installed via yum:

  • http-2.2.3-11-el5
  • mod_ssl-2.2.3-11.el5.centos
  • perl-5.8.8-10.el5_0.2
  • php-5.1.6-15.el5
  • Ruby-1.8.5-5
  • ruby-ri ruby-rdoc ruby-irb ruby-docs
  • a bunch of perl libraries (whatever I needed from default RPMs)
  • a bunch of php/pear/pecl libraries (whatever I needed from default RPMSs)
  • mysql-5.0.22-2.2.el5_1.1, mysql-server-5.0.22-2.2.el5_1.1
  • mod_auth_mysql
  • subversion-1.4.2-2.el5
  • subversion-perl, subversion-ruby, mod_dav_svn
  • OpenLDAP-2.3.27-8
  • php-LDAP, perl-LDAP, python-LDAP, mod_authz_ldap
  • FreeRADIUS-1.1.3-1.2.el5
  • ImageMagick-6.2.8
  • ImageMagick-perl-6.2.8
  • ImageMagick-devel-6.2.8
  • gd-devel-2.0.33-9.3.fc6

For packages from utterramblings, I created the following file:
etc/yum.repos.d/utterramblings.repo

name=Jason’s Utter Ramblings Repo
baseurl=http://www.jasonlitka.com/media/EL$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka

And upgraded/installed the following from utterramblings.repo:

  • php- 5.2.5
  • php-xcache
  • mysql-5.0.54, , mysql-server-5.0.54




MagickWand

11 01 2008

There’s got to be a better way to install MagickWand.  I can’t find an RPM anywhere from Redhat, Fedora, CentOS, anything.  MagickWand required ImageMagick 6.3.5+ and the existing RPM for ImageMagick is 6.2.8.  Upgrading the ImageMagick RPM complains with:

Failed dependencies:
libHalf.so.6 is needed by ImageMagick-6.3.7-9.i386
libIex.so.6 is needed by ImageMagick-6.3.7-9.i386
libIlmImf.so.6 is needed by ImageMagick-6.3.7-9.i386
libIlmThread.so.6 is needed by ImageMagick-6.3.7-9.i386
libImath.so.6 is needed by ImageMagick-6.3.7-9.i386
libgvc.so.4 is needed by ImageMagick-6.3.7-9.i386
libjasper.so.1 is needed by ImageMagick-6.3.7-9.i386
XFree86-devel is needed by ImageMagick-devel-6.3.7-9.i386

I installed ilmbase and openexr, but RPM can’t find them.  There is no such thing as XFree86-devel anymore and xorg-x11-devel doesn’t satisfy it.  I tried building ImageMagick from a src.rpm, but it still complains, even with I specify –without-x.

In the end, I built ImageMagick from source into /usr/local/bin and kept the RPMs at 6.2.8 (including ImageMagick-perl)  in /usr/bin.  So I have two versions of ImageMagick installed, one of them a source build, which is linked (I hope to the MagickWand source build.  But I don’t want to have to do that for every QA Site.





I love blogging tools

2 01 2008

Why do they suck so much?





QA Site RFP

2 01 2008

REQUEST FOR PROPOSAL

Project Management, Development, and QA tools solution
12-31-2007

Overview

Organization

One Shore Inc is a software QA consulting firm with offices in Seattle, Washington and Cuenca, Ecuador. We provide support for open source tools and QA staffing.

Project

QA Site is our flagship product under development. It is a hosted solution that provides a collection of tools to facilitate collaboration for software development and testing organizations.

An organization purchases a QA Site, which is then configured with applications that fit its needs, and a project page that contains a project status dashboard and links to their applications.

Typical applications include version control, bug tracking, test cases, automated builds and test execution, requirements coverage, project management, and documentation. A single sign-on solution will be offered in a future release, as well as application information and project status available via web services on the dashboard or RSS feeds.

Problem

We need a solution to manage the development of the QA site product. Not surprisingly, we want something that looks a lot like a QA Site.

Target Audience

We are looking for an organization with the experience to deliver our solution. The qualified candidate will be able to set up and manage a Linux based operating system with web and email infrastructure, and has experience deploying, configuring, and managing open source QA tools.

Experience with lightweight methodologies such as Agile is a plus — as is experience with bureaucratic organizations and their needs, to better understand when lightweight methods are appropriate and when they are not practical.

Understanding of the roles and responsibility of the various roles in software development, as well as the software development life cycle is critical.

Solution

What is needed

The solution would enable project management, design, development, testing, and deployment operations to communicate and collaborate effectively in developing the QA site product. The following is a potential list of tools needed:

  1. A document management solution that enables team members to share documents over a distributed environment. It needs role based access restrictions and be safe to use from within or outside the VPN. All versions of documents need to be retained and marked. Editing should be easy and multiple users should be able to work on the same document simultaneously. A wiki might be good, but printing documents is also needed. Converting from wiki text to DOC or PDF format would be acceptable.

  2. A project management solution that keeps track of project schedule, tasks, budget, and resources. This should not be a heavyweight solution or too process heavy. We are open to a document-based project management solution, but would like the interactivity a dynamic application provides. Each person –designers, developers, testers, sysadmins, etc.– should be able to update their own tasks, and create sub-tasks.

  3. A requirements management solution that enables requirements to be cross referenced from design documents to implementation to tests. Requirements documents should be parseable and easy to update.

  4. A version control system for documents, code, and tests. We would like our document management system to use the same repository as our code and tests. Test results and bugs should also be able to be tied to a version.

  5. A continuous build solution that enables developers to immediately build, deploy, and execute tests. Automatic test results and bug reports from the build should be created.

  6. A system for writing test cases, associating tests with automated scripts, reporting test results, and requirements coverage.

  7. A searchable knowledge base that contains references to documents and online documentation.

  8. An access restricted web site that contains links to all these tools and reports status such as open bugs, recent document revisions, build status, etc. The full scope of what is available on this page has not yet been defined. This can be completed in a later stage.

  9. Optionally – web service status and RSS feeds for bugs, tests, build status, checkins, tasks, and documents.

  10. The ability to use different tools interchangeably (such as an alternate bug tracker) will be a future requirement.

  11. Single sign-on capability to the various tools will be a requirement in the future as well.

Training on the various tools and support/maintenance of them will be needed as well. An ongoing support and maintenance contract, as well as customization of tools is desirable.

Since we do not currently have the operations facility for maintaining these systems, they will need to be hosted offsite and be securely accessible by all team members.

 

[Deliverables]

[Plan]

Once a proposal is accepted, a timeline and budget will be negotiated. Final acceptance of the proposal will be contingent on acceptance of the plan. Failure to meet timeline and budget restraints will be specified in the contract.

[Product]

The QA site will be delivered in stages. Final scoping of the QA site project is yet to be determined.

 

Stage 1: Hosted OS available with Web and Email service

 

Stage 2: Solutions identified.

 

Stage 3: Documentation and Project solutions complete.

 

Stage 4: Design, Development, and Testing

 

Stage 5: Continuous build and automated tests

 

Stage 6: Dashboard

 

Stage 7: Single Sign-on

 

Stage 8: Web Services and RSS feeds

 

Stage 9: Virtual Appliance

 

Stage 10: Customer QA sites

 

Stage 11: Online purchasing

 

Stage 12: Online provisioning & customization

 

 

Artifacts

Design documents, administration and usage documentation, test results, requirements coverage, etc. will be delivered on project completion.

Site

A hosted site solution will be delivered, including root access and 1 full year’s hosting on completion. The site will be properly secured and stable.

Support

An ongoing support contract will be negotiated at project completion. It is expected to be a part time (approximately 5 hours/week) contract for support with additional development also expected. Additional support tickets can also be purchased as needed.

[Proposal]

[Format and Content]

Submit proposals in DOC or PDF format.

Your proposal should include a tentative timeline, and itemized budget. A list of applications proposed should be included, but will be not be set in stone yet. Please include your experience and alternate or additional solutions recommended.

Deadline

Proposals are being accepted until January 2, 2008.

Budget

The maximum budget for a QA solution is $1000.

Time line

Implementation through stage 6 should be completed no later than March 31, 2008.

Selection Criteria

A proposed solution will be selected by January 10, 2008.

The solution that is considered the best match for our needs, within the allocated budget and time line will be selected. Consideration will be made for our confidence in your ability to deliver the proposed solution. Experience counts.

[Contact]

Submit proposals to aaron _@_ oneshore.com.

Questions or clarifications about the proposal can also be directed to aaron _@_ oneshore.com

For additional information about One Shore, visit our website at http://one-shore.com.

 





QA Site concept

29 12 2007

Here’s the first draft of a “Concept” document for QA Site.

QA Site is a web hosting package. It is a SAS (Software as Service) or what used to be call an ASP (Application Service Provider).

QA Site consists of a collection of tools bundled together for the purpose of facilitating the testing, development, documentation, and management of a software project. Typically, these are open source tools, but proprietary tools may be included. Custom tools may also be developed.

Potential tools uses: bug tracking, test case authoring, test execution & results reporting, automated testing, automated builds & deployments, version control/configuration management, documentation, project management: tasks/schedule/budget/resources, etc.

QA site integrates these various tools, providing a single sign on, dashboard, status, cross tool communication, and workflow.

QA site tries not to force specific tools, processes, or methodologies, but we are biased to what we are familiar with and know works. We are willing to use the tools you prefer. The goal is to facilitate collaboration by using proven tools and best practices.

A “QA Site” is an instance of the QA Site solution. Each project will typically have it’s own QA site. A user (customer) may have multiple projects, and hence multiple QA sites. In the future, a QA site may accomodate multiple projects.

The value of a QA Site is that it provides the infrastructure, installation, and integration of tools. A QA Site can be set up quickly, customized for a particular organization, and grow with that organization. It does not require the purchase and maintenance of new hardware, or the administration and configuration of operating systems, supporting tools, and

One Shore provides QA Site management and training for supported tools. We also offer customization of open source tools and development of specific tools for our customers.

A QA Site “server appliance” is a possible other option.  This could be a VMWare image or a custom deployment within an organization.





QA Site Blog

29 12 2007

I’m working on a QA Site for qa-site.com.

I’m starting with a blog, but hope to add document management soon.  My first step will be a concept document, which may very well start as a blog post.  Then I’ll create a fictitious Request for Proposal from a hypothetical customer.  QA Site’s first goal will be to attempt to satisfy that RFP, by creating a proposal.

blog.qa-site.com will be the eventual home of the blog.  I requested a DNS CNAME of blog.qa-site.com to point to the One Shore webserver.  Then I created a blogger account that will post to blog.qa-site.com  I’m still waiting for the DNS to propogate, but it looks like the first post from blogger uploaded via SFTP.  It was just a test.

I’m starting here, in the spirit of getting started.

My first obstacle is getting a Virtual Server account set up for QA Site.  There has been some issues with the hosting provider, but I hope they will be taken care of soon.   I won’t worry about that now.  While I’m at it, I might as well start with the concept…