Release Notes

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

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.

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.

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.

• Make sure your postgresql.conf had standard_conforming_strings = on. Otherwise, it can cause agent warnings and prevent the analysis for completing. The symptom of this config error will look like this in your fossology.log file:

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

• If the package agent tries to process a mis-identified debian control file, it gets a fatal error and dies. This bug has already been fixed in the top of our development source tree (http://fossology.svn.sourceforge.net/fossology/?rev=3324&view=rev). The fix will be included the next release.

• Scheduler.conf does not get created correctly for a cluster. fosscp_agent and fo_notify should only be run on the scheduler host (localhost). This bug is documented in the task_list for the 1.3 release.

• MyJobs display will not show delete jobs or jobs uploaded from server by the user. Those jobs are performed by the user fossy.

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