Table of Contents

Release Notes

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

1.2.0

Date: July 8, 2010

  1. Much faster and more accurate license detection. We call this the Nomos License scanner because it is based on a license scanner used internally by HP for several years. It's fast, it's accurate, but it no longer highlights the found license when you view the file and it requires one to update and recompile source code to add licenses.
  2. The previous license scanner (bSAM) has been moved to “Obsolete” in the top menu. We encourage people not to submit anything to the bSAM agent because we plan on removing it in a future version (probably v 1.3). Obsoleting bSAM also means that the license groups feature will go away (replaced by buckets, see below).
  3. Copyright/URL/email scanner. This is a new agent that beta users have liked, but has one flaw, it gets many false positives. This is unfortunate but beta users have still found this feature very usable and useful. The next version will do a much better job filtering out the false positives.
  4. Ability to customize reporting categories. For example, “copyleft licenses”, “ship hold licenses”, … these are defined by the administrator of the system you are using. These categories are called buckets and a set of buckets used together is called a bucket pool. When 1.2 is installed, a very simple demo bucket pool will be created. To use it, you must go into Admin > Users > Account Settings and set your Default Bucket Pool. Do this before submitting a job to the bucket agent.
  5. Much faster report (web page) generation
  6. Cataloging both RPM and Debian package data
  7. Ability to choose which agents are scheduled on a per user basis.

Buckets

Enabling Buckets

A Default bucket pool is created when FOSSology is installed or upgraded. Users do not have a default bucket pool defined for them. To enable the use of the default bucket or any bucket pool, the user account is modified to use the desired bucket pool. Use the Admin→Account Settings or Admin→Edit Users menus to select the bucket pool.

If a user has no bucket pool defined, when that user schedules the bucket agent it will not run as there is no bucket pool defined for the user as a default. The Bucket agent will not run successfully until user accounts are modified to use it or another defined bucket pool.

Restrictions

The bucket agent cannot determine who the user is when uploading from server. If selected during an upload from server, the bucket agent will not run. To schedule bucket analysis on jobs uploaded from server, wait till the job is complete then schedule the bucket analysis by using the Jobs→Agents menu.

Known Issues

WARNING:  nonstandard use of \\ in a string literal LINE 2: <some string>
                                                          ^
HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.

1.1.0

Date: 17 July 2009

New in FOSSology 1.1

  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.

Known Issues

cd fossology/scheduler
sudo make OVERWRITE=true install
agent=fo_notify host=<agent_hostname> | /usr/bin/ssh fossy@<agent_hostname> "/usr/lib/fossology/agents/engine-shell fo_notify '/usr/bin/fo_notify %{*}'"
agent=fo_notify host=localhost | /usr/lib/fossology/agents/engine-shell fo_notify '/usr/bin/fo_notify %{*}'
  memory_limit = 702M
  post_max_size = 701M
  upload_max_filesize = 700M

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'.

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”.

Outstanding Defects in 1.1.0

1.0.0

17 December 2008 release_notes-1.0

0.9.0

release_notes-0.9

0.8.0

release_notes-0.8

0.7.0

release_notes-0.7

0.6.1

release_notes-0.6.1

0.6.0

release_notes-0.6