Ouch. That shouldn't have happened. This is from sqlCVS when it's merging in database changes we made into your local copy. The field psc_id is the globally unique id sqlCVS assigns to each row to track changes. On the surface, this appears to indicate that we added a new record in that table for device template #69 (Generic Serial Device) and Device Category #6 (Computers), but that you already had made such an addition yourself into your local copy, therefore, the merge failed. But, that seems pretty unlikely. So, can you ssh over to the Core, run mysql, then type:use pluto_main;

and then copy/paste the following queries. For each query, copy/paste the results and post them as a reply to this message. Sorry about this.

SELECT * FROM DeviceTemplate_DeviceCategory_ControlledVia WHERE PK_DeviceTemplate_DeviceCategory_ControlledVia>4637;

SELECT * FROM DeviceTemplate_DeviceCategory_ControlledVia WHERE FK_DeviceTemplate=69;

Actually, never mind. I found the error. The table in question has an auto-increment primary key. You added a record locally (probably one of your own device templates) which added a record with the primary key 4639, and in between 2.0.0.11 and .12 we also added a new device template with that same primary key.

During a 'normal' sqlcvs update (ie syncing with the live host), sqlCVS handles this and re-locates conflicting ID's on your local machine. However I see that it's not doing this during an update from within a debian package. I'm fixing this now, and will put a new sqlCVS binary up that fixes this. Then you can use that binary and it should work. I'll post a message when I get this going ... Give me a couple hours. Thanks.

I posted a fixed sqlCVS. I tested it locally by adding a new device template locally and doing an update, confirmed the error during upgrade, and this fixed the problem. You'll need to ssh over to the core and do this:

I posted a fixed sqlCVS. I tested it locally by adding a new device template locally and doing an update, confirmed the error during upgrade, and this fixed the problem. You'll need to ssh over to the core and do this:

That will update your sqlCVS binary with the fixed one. Now you can run:

dpkg --configure

and that should cause it re-attempt to apply the update pluto-system-database package from the 2.0.0.12 update. This time it should work. When you're finished, you can do:

dpkg -l "*pluto*"

That will list all the pluto packages. They should all be version 2.0.0.12, and the status for each should be ii (meaning installed okay).

Hi,

thanks for help. I followed instructions and dpkg --configure complained that it needs package info. Then I just did it my (probably dirty way). Did install HP printer packages (in quest for print server) in parallel and those packages were updated. Error repeated once with another ID, and after second restart it went away, but also dcerouter appeared as not correctly configured. So I remove it and installed again (probably not wise idea).

Somewhere on this way I got into trap, where I'm getting some strange errors with apt-get update - for instance :

Sorry but those messages are in slovenian, if someone tells me how to simply switch to english ...

I'll try to translate :

First it's complaining that it cannot connect to 127.0.0.1:8123 (I've added this port to Firewall, but no go). Then it appears as looking for some package lists that doesn't exist and also for above error. Can I somehow regenerate package lists to correct state ? What could I do to get into clean state ?

I'm sorry for asking such newbie questions, I remember that installing some other packages on customized Debian distros is a bad idea, but I wanted to set home printer server ...

Any advice on where to send more general Debian Sarge related questions to get quick responses ? It seems like I'll need it more often that I expected ...