Description of problem: When I try to re-sync channel from dump to another organization (channel already exists in some organization), I'm getting the traceback. Version-Release number of selected component (if applicable): spacewalk-backend-0.5.28-35.el4sat How reproducible: always Steps to Reproduce: 1. create channel "aaaaaa" in a orgid 1 and push some rpm into it 2. use rhn-satellite-exporter to dump that channel # rhn-satellite-exporter --dir=/tmp/aaaaaa --channel=aaaaaa 3. create new organization, say orgid 2 4. sync dumped channel into that organization 2 # satellite-sync -m /tmp/aaaaaa -c aaaaaa --orgid=2 Actual results: # satellite-sync -m /tmp/aaaaaa -c aaaaaa --orgid=4 15:49:16 Red Hat Network Satellite - file-system synchronization 15:49:16 mp: /tmp/aaaaaa 15:49:16 db: rhnsat/<password>@rhnsat [...] 15:49:17 Importing package metadata 15:49:17 Importing *relevant* package metadata: aaaaaa (1) 15:49:17 * WARNING: this may be a slow process. ________________________________________ Importing: ######################################## - complete 15:49:17 15:49:17 Linking packages to channels +++ sending log as an email +++ SYNC ERROR: unhandled exception occurred: (Check logs/email for potentially more detail) <rhnFault class (code = 23, text = 'ORA-00001: unique constraint (RHNSAT.RHN_CNP_CID_NID_UQ) violated ORA-06512: at "RHNSAT.RHN_CHANNEL", line 919 ORA-06512: at line 1 ')> (23, 'ORA-00001: unique constraint (RHNSAT.RHN_CNP_CID_NID_UQ) violated\nORA-06512: at "RHNSAT.RHN_CHANNEL", line 919\nORA-06512: at line 1\n', 'Could not update database entry.') In the error email sent to me is whole traceback: 15:49:17 SYNC ERROR: unhandled exception occurred: Exception reported from dhcp-lab-158.englab.brq.redhat.com Time: Tue Dec 1 15:49:17 2009 Exception type common.rhnException.rhnFault Exception Handler Information Traceback (most recent call last): File "/usr/bin/satellite-sync", line 142, in main return satsync.Runner().main() File "/usr/share/rhn/satellite_tools/satsync.py", line 212, in main ret = method() File "/usr/share/rhn/satellite_tools/satsync.py", line 324, in _step_packages self._affected_channels = self.syncer.import_packages() File "/usr/share/rhn/satellite_tools/satsync.py", line 1672, in import_packages return self._link_channel_packages() File "/usr/share/rhn/satellite_tools/satsync.py", line 1699, in _link_channel_packages importer = sync_handlers.link_channel_packages(uq_pkg_data, strict=0) File "/usr/share/rhn/satellite_tools/sync_handlers.py", line 442, in link_channel_packages importer.run() File "/usr/share/rhn/server/importlib/importLib.py", line 628, in run self.submit() File "/usr/share/rhn/server/importlib/packageImport.py", line 123, in submit affected_channels=self.affected_channel_packages) File "/usr/share/rhn/server/importlib/backend.py", line 1324, in update_newest_package_cache raise rhnFault(23, str(e[1]), explain=0) rhnFault: (23, 'ORA-00001: unique constraint (RHNSAT.RHN_CNP_CID_NID_UQ) violated\nORA-06512: at "RHNSAT.R HN_CHANNEL", line 919\nORA-06512: at line 1\n', 'Could not update database entry.') Channel is moved to the new organization, so this traceback do not seem to cause anything serve. Expected results: No traceback Additional info: Found during testing of bug 528227.
ALTER TABLE rhnChannelNewestPackage ADD CONSTRAINT rhn_cnp_cid_nid_uq UNIQUE (channel_id, name_id, package_arch_id); CREATE TABLE rhnChannelNewestPackage ( channel_id NUMBER NOT NULL CONSTRAINT rhn_cnp_cid_fk REFERENCES rhnChannel (id) ON DELETE CASCADE, name_id NUMBER NOT NULL CONSTRAINT rhn_cnp_nid_fk REFERENCES rhnPackageName (id), evr_id NUMBER NOT NULL CONSTRAINT rhn_cnp_eid_fk REFERENCES rhnPackageEVR (id), package_arch_id NUMBER NOT NULL CONSTRAINT rhn_cnp_paid_fk REFERENCES rhnPackageArch (id), package_id NUMBER NOT NULL CONSTRAINT rhn_cnp_pid_fk REFERENCES rhnPackage (id) ON DELETE CASCADE ) ENABLE ROW MOVEMENT ; So when 'moving' a channel from one org to another org using the steps outlined, we hit this constraint. This bug would have been within 530 GA code as well, in fact, searching BZ, I found a bug we punted off 530 near the end of testing cycles. right now, it seems only QE has used Satellite in this manner to encounter the error. I propose to close this out as a dupe, and then for us to keep tracking proposed for future Satellite release beyond 5.3.1. Cliff. *** This bug has been marked as a duplicate of bug 517173 ***