Release Notes

This page maintains the FOSSology Project release notes, from the most recent release to the oldest release.

Date: tbd

<create note about libextractor bug here>

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531864

https://bugzilla.redhat.com/show_bug.cgi?id=452504

Date: 17 July 2009

1. Email notification of job status: If enabled, FOSSology will email users when their jobs finish. This option will be available on a per user basis. For more information see how_to_use_email_notification.
2. Roll-up of many bug fixes.
3. Several new license templates added.
4. Code cleanup for improved efficiency and maintainability.
5. Tutorial section, with examples, added to fossology.org.
6. Lots of new tests added to the automated test suite.
7. RPM packages for RHEL4, CentOS4, RHEL5 and CentOS5 - see a Simple List of all RPMs Needed for Installing Fossology on RHEL CentOS
8. Added a watchdog to keep an eye on the scheduler and restart if it terminates/hangs unexpectedly (see “Known Issues” note below regarding changes to the startup script for the watchdog process)
9. Many improvements to scheduler to improve robustness.

• If you are upgrading fossology from a previous version, you'll need to update /etc/init.d/fossology if you wish to use the new scheduler watchdog daemon (fo_watchdog). This daemon watches for scheduler hangs, and restarts it if one is detected. If you are upgrading from a package install (debian package or RPM), you need to do nothing, the init.d/fossology file will automatically get updated (providing you did not edit the previous version). If you are doing an update from upstream (the source tarball), then you need to update this file yourself. An easy way is to:

cd fossology/scheduler
sudo make OVERWRITE=true install

• Multi-System Upgrades
  • When upgrading from the previous 1.0.0 package install, you'll have to manually update the /etc/fossology/Scheduler.conf file on the agent systems to include the new fo_notify agent. The entry line in Scheduler.conf will look something like this (where <agent_hostname> should be replace with the actual hostname):

agent=fo_notify host=<agent_hostname> | /usr/bin/ssh fossy@<agent_hostname> "/usr/lib/fossology/agents/engine-shell fo_notify '/usr/bin/fo_notify %{*}'"

• Single System Upgrades
  • The upgrade should regenerate your Scheduler.conf file to include the new email agent. If it does not, use the line below to manually update the Scheduler.conf file.

agent=fo_notify host=localhost | /usr/lib/fossology/agents/engine-shell fo_notify '/usr/bin/fo_notify %{*}'

• upstream install and package install conflicts
  • If you have your system installed with a source (upstream) install, it should be removed using utils/fo-cleanold before the packages are installed. We have noticed issues when both upstream and packages are installed on the same system. Having both on the system at the same time is not supported. The issue also applies if you have packages installed first and then use an upstream install. Remove the packages with apt-get purge/remove first then perform the upstream install.

• RPM install on RHEL4/CentOS4 x86_64 platform
  • If you install rpm package on RHEL4/CentOS4 x86_64 platform, you should first change the php initial configuration file php.ini. Then install the rpm package. The changes we use in php.ini are:

  memory_limit = 702M
  post_max_size = 701M
  upload_max_filesize = 700M

• PostgreSQL 8.3 minimal compatibility testing with FOSSology 1.1
  • We've performed minimal testing of PostgreSQL 8.3 to insure it will run with FOSSology 1.1.0. We have not taken advantage of any new 8.3 features or made any attempts at tuning with 8.3. (This is scheduled to be done in 1.2.) This version generates annoying warning messages in the PostgreSQL log file (these may safely be ignored.):

WARNING:  nonstandard use of escape in a string literal at character 104
HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.

• Incorrect license identification
  • One is due to an incorrect license template name.
  • In at least one case, identification of MPL 1.1 license is incorrectly identified as MPL.

• Delagent issue - Organize > Uploads > Delete Uploaded file

When you delete an uploaded file, DO NOT process any other jobs at the same time. If you simultaneously upload a file that contains duplicates of files that you are deleting, you can leave the database with holes for those files. For example, if you were to delete upload “myfiles.tar” and simultaneously upload a file “myotherfiles.tar” and both tar files contain “widget.c”, then it is possible that the delete removes widget.c after it is unpacked from myotherfiles.tar. This can lead to erroneous results. In this example, the licenses found in myotherfiles.tar could be missing the the licenses found in widget.c.

This problem is very dependent on the timing of the delete with other agents and is only a problem if there are files in common. But to be safe, queue up delagent all by itself. Don't queue something else until delagent has finished.

So how do you know when del agent finishes? This is harder than it sounds. Del agent removes itself from the job queue pretty early in its process execution. It does this because the job table contains a reference to the upload being deleted which must be removed before the actual files can be removed. So you can't use Jobs > Queue to tell you when delagent is done. It will disappear before the agent finishes.

The safest indicator is to use Admin > Agent > Status. Ten minutes after delagent has finished, this status will show delagent as “FREE”.

• defect #215: use the wiki page for the scheduler, the delivered man page needs to be updated.
• defect #259: temp files are left by wget on unsuccessful uploads, remove by hand in /var/lib/fossology.

17 December 2008 release_notes-1.0

release_notes-0.9

release_notes-0.8

release_notes-0.7

release_notes-0.6.1

release_notes-0.6