Hi Martin, The real issue is that we do not support jumping releases. We only test sequential upgrades (2.0 > 2.1 > 2.2 > 2.3 > 2.4). This is unfortunate because we could test and make 2.x > 2.y work, but nobody has taken this on. Does anyone want to volunteer for this testing?
I just reread the thread from Michael and it looks like we never solved the problem and he ended up “installing a clean instance of FOSSology and starting from scratch”. We gave up because he was having “frustrated users banging on his cubicle walls”, we weren’t able to solve the problem quickly, and starting over was acceptable to him. It looks like we got through the copyright table update problem but then ran into another issue with the agent table. So tell me how you would like to proceed: 1) If you can perform the sequential updates, that would be best. But this might not work since you got part way through the 2.4 upgrade. 2) If you are willing to start from scratch, that would work. 3) If your system is in an inconsistent state and 1 or 2 aren’t acceptable, we can try to reproduce the problem on one of our test systems and see what we need to do to solve it. Bob Gobeille On Mar 13, 2014, at 7:46 AM, Martin Hamant <m...@ow2.org> wrote: > Ok, so I am digging up in the other old issue posted by Michael on nov/2013 > > Bob, you suggested to create a view as "select ct_pk,pfile_fk,pfile_pk from > copyright right outer join pfile on pfile_fk=pfile_pk" > > Here is an extract of the result: > ct_pk | pfile_fk | pfile_pk > --------+----------+---------- > | | 2 > | | 3 > 2 | 4 | 4 > 1 | 4 | 4 > 4 | 5 | 5 > 3 | 5 | 5 > 6 | 6 | 6 > 5 | 6 | 6 > (...) > 727 | 440 | 440 > | | 542 > | | 1802 > | | 1921 > > As you can see, where there is no ct_pk, there is no pfile_fk neither. > > So in your delete statement : > delete from copyright where ct_pk in (select ct_pk from copyright_pfile where > pfile_fk != pfile_pk); > > the part "select ct_pk from copyright_pfile where pfile_fk != pfile_pk" will > always returns a null ct_pk. So it cannot work. > > Please could you tell me what would the needed delete statement ? What would > I need to delete exactly ? > > > Le 13/03/2014 10:26, Martin Hamant a écrit : >> Hi again, >> >> Admin > Upload permissions returns >> >> File: /usr/share/fossology/www/ui/upload_permissions.php, Line number: 239 >> ERROR: column "public_perm" does not exist LINE 1: select public_perm from >> upload where upload_pk='8' ^ >> select public_perm from upload where upload_pk='8' >> >> #0 debugbacktrace() called at >> [/usr/share/fossology/lib/php/common-db.php:158] >> #1 DBCheckResult(, select public_perm from upload where upload_pk='8', >> /usr/share/fossology/www/ui/upload_permissions.php, 239) called at >> [/usr/share/fossology/www/ui/upload_permissions.php:239] >> #2 upload_permissions->Output() called at >> [/usr/share/fossology/www/ui/index.php:51] >> >> ------------------------- >> >> I guess something went wrong at upgrading DB schema. >> I found >> http://lists.fossology.org/pipermail/fossology/2013-November/006093.html >> that seems a similar issue but I am not sure what I should do from now ! >> >> Le 13/03/2014 09:37, Martin Hamant a écrit : >>> Hi ! >>> >>> I am running a debian Squeeze server where fossology 2.0.0 was previously >>> installed on it. >>> I upgraded to 2.4.0 following the guide >>> http://www.fossology.org/projects/fossology/wiki/Debian_Install_2_4 >>> >>> I got the following trace : >>> (...) >>> Setting up fossology-common (2.4.0-1) ... >>> Installing new version of config file /etc/fossology/fossology.conf ... >>> Installing new version of config file /etc/fossology/VERSION ... >>> *** Running postinstall for common actions*** >>> *** Creating user and group *** >>> NOTE: group 'fossy' already exists, good. >>> NOTE: user 'fossy' already exists, good. >>> NOTE: change user 'fossy' homedir from /srv/fossology to /home/fossy. >>> *** Making sure needed dirs exist with right ownership/permissions *** >>> NOTE: Repository already exists at /srv/fossology/repository >>> NOTE: Running the PostgreSQL vacuum and analyze command can result in a >>> large database performance improvement. We suggest that you either >>> configure postgres to run its autovacuum and autoanalyze daemons, or >>> maintagent -D in a cron job, or run Admin > Maintenance on a regular basis. >>> Admin > Dashboard will show you the last time vacuum and analyze have been >>> run. >>> FOSSology postinstall complete, but sure to complete the remaining >>> steps in the INSTALL instructions. >>> Setting up fossology-db (2.4.0-1) ... >>> *** Setting up the FOSSology database *** >>> NOTE: fossology database already exists, not creating >>> *** Checking for plpgsql support *** >>> NOTE: plpgsql already exists in fossology database, good >>> Setting up fossology-web (2.4.0-1) ... >>> *** Running postinstall for web-only actions*** >>> *** update the database and license_ref table *** >>> PHP Warning: pg_query(): Query failed: ERROR: insert or update on table >>> "copyright" violates foreign key constraint "copyright_pfile_fk_fkey" >>> DETAIL: Key (pfile_fk)=(140) is not present in table "pfile". in >>> /usr/share/fossology/lib/php/libschema.php on line 456 >>> <hr>File: /usr/share/fossology/lib/php/libschema.php, Line number: >>> 457<br>ERROR: insert or update on table "copyright" violates foreign key >>> constraint "copyright_pfile_fk_fkey" >>> DETAIL: Key (pfile_fk)=(140) is not present in table "pfile".<br> ALTER >>> TABLE "copyright" ADD CONSTRAINT "copyright_pfile_fk_fkey" FOREIGN KEY >>> ("pfile_fk") REFERENCES "pfile" ("pfile_pk") ON UPDATE NO ACTION ON DELETE >>> CASCADE;<pre>#0 debugbacktrace() called at >>> [/usr/share/fossology/lib/php/common-db.php:158] >>> #1 DBCheckResult(, ALTER TABLE "copyright" ADD CONSTRAINT >>> "copyright_pfile_fk_fkey" FOREIGN KEY ("pfile_fk") REFERENCES "pfile" >>> ("pfile_pk") ON UPDATE NO ACTION ON DELETE CASCADE;, >>> /usr/share/fossology/lib/php/libschema.php, 457) called at >>> [/usr/share/fossology/lib/php/libschema.php:457] >>> #2 ApplySchema(/usr/share/fossology/www/ui/core-schema.dat, , fossology) >>> called at [/usr/lib/fossology/fossinit.php:102] >>> </pre><hr>*** Setting up the web interface *** >>> NOTE: Adding user www-data to group fossy >>> FOSSology postinstall complete, but sure to complete the remaining >>> steps in the INSTALL instructions. >>> Setting up fossology-scheduler (2.4.0-1) ... >>> *** Setting up scheduler *** >>> FOSSology postinstall complete, but sure to complete the remaining >>> steps in the INSTALL instructions. >>> Setting up fossology-ununpack (2.4.0-1) ... >>> Setting up fossology-copyright (2.4.0-1) ... >>> Setting up fossology-nomos (2.4.0-1) ... >>> Setting up fossology-pkgagent (2.4.0-1) ... >>> Setting up fossology-buckets (2.4.0-1) ... >>> Setting up fossology-mimetype (2.4.0-1) ... >>> Setting up fossology-delagent (2.4.0-1) ... >>> Setting up fossology-wgetagent (2.4.0-1) ... >>> Setting up fossology (2.4.0-1) ... >>> Database connectivity is good. >>> FOSSology postinstall complete, but sure to complete the remaining >>> steps in the INSTALL instructions. >>> Starting FOSSology job scheduler: fossology. >>> >>> Now here is the content of fossology.log >>> 2014-03-13 08:56:51 scheduler [15545] :: ERROR database.c.630: Column >>> jobqueue.jq_host does not exist >>> 2014-03-13 08:56:51 scheduler [15545] :: FATAL database.c.642: Scheduler >>> did not pass database check >>> 2014-03-13 08:56:51 scheduler [15545] :: FATAL database.c.643: Running >>> fo_postinstall should fix these issues >>> >>> Note that running fo-postinstall doesn't solve these issues >>> >>> In fossology > Browse I got the following: >>> >>> File: /usr/share/fossology/lib/php/common-tags.php, Line number: 231 >>> ERROR: relation "tag_manage" does not exist >>> select tag_manage_pk from tag_manage where upload_fk = 8 and is_disabled = >>> true; >>> #0 debugbacktrace() called at >>> [/usr/share/fossology/lib/php/common-db.php:158] >>> #1 DBCheckResult(, select tag_manage_pk from tag_manage where upload_fk = >>> 8 and is_disabled = true;, /usr/share/fossology/lib/php/common-tags.php, >>> 231) called at [/usr/share/fossology/lib/php/common-tags.php:231] >>> #2 TagStatus(8) called at >>> [/usr/share/fossology/lib/php/common-menu.php:434] >>> #3 menu_to_1list(Array ([0] => menu Object ([Name] => View,[URI] => >>> view,[HTML] => ,[Order] => 10,[Target] => ,[MaxDepth] => 0,[SubMenu] => >>> ,[FullName] => Browse-Pfile::View,[Title] => View file contents),[1] => >>> menu Object ([Name] => Info,[URI] => view_info,[HTML] => ,[Order] => >>> 5,[Target] => ,[MaxDepth] => 0,[SubMenu] => ,[FullName] => >>> Browse-Pfile::Info,[Title] => View file information),[2] => menu Object >>> ([Name] => Compare,[URI] => picker,[HTML] => ,[Order] => 0,[Target] => >>> ,[MaxDepth] => 0,[SubMenu] => ,[FullName] => Browse-Pfile::Compare,[Title] >>> => Compare this file to another.),[3] => menu Object ([Name] => >>> Download,[URI] => download,[HTML] => ,[Order] => 0,[Target] => ,[MaxDepth] >>> => 0,[SubMenu] => ,[FullName] => Browse-Pfile::Download,[Title] => Download >>> this file),[4] => menu Object ([Name] => Tag,[URI] => tag,[HTML] => >>> ,[Order] => 0 >>> ,[Target] >>> >>> >>> => ,[MaxDepth] => 0,[SubMenu] => ,[FullName] => Browse-Pfile::Tag,[Title] >>> => Tag files or containers)), upload=8&show=detail&item=84268, , , 1, 8) >>> called at [/usr/share/fossology/www/ui/ui-browse.php:322] >>> #4 ui_browse->ShowFolder(1, detail) called at >>> [/usr/share/fossology/www/ui/ui-browse.php:479] >>> #5 ui_browse->Output() called at [/usr/share/fossology/www/ui/index.php:51] >>> Is anyone can help me to sort it out ? >>> >>> Thanks ! >> >> >> >> _______________________________________________ >> fossology mailing list >> fossology@lists.fossology.org >> http://lists.fossology.org/mailman/listinfo/fossology >
_______________________________________________ fossology mailing list fossology@lists.fossology.org http://lists.fossology.org/mailman/listinfo/fossology
