Mailing List Archive: Interchange: users

Upgrade procedure

Index | Next | Previous | View Threaded

emailgrant at gmail

Jun 13, 2009, 4:33 PM

Post #1 of 20 (2065 views)
Permalink

Upgrade procedure

I'd like to perform a safe upgrade from a 5.5 nightly to 5.6. Should
this be sufficient:

# tar -cvzf ic.tar.gz /usr/local/ic
# su - interchange
$ cd /new/ic/source
$ ./configure
$ exit
# cd /new/ic/source
# make install

- Grant

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Jun 13, 2009, 9:50 PM

Post #2 of 20 (2003 views)
Permalink

Re: Upgrade procedure [In reply to]

On 06/13/2009 04:33 PM, Grant wrote:
> I'd like to perform a safe upgrade from a 5.5 nightly to 5.6. Should
> this be sufficient:
>
> # tar -cvzf ic.tar.gz /usr/local/ic
> # su - interchange
> $ cd /new/ic/source
> $ ./configure
> $ exit
> # cd /new/ic/source
> # make install

No, my usual upgrade procedure is this:
As unprivileged user:

~$ tar.cvzf ic.tar.gz # use the proper name of the tarball here

~$ cd interchange # use the correct name of the directory that the
tarball created here

~/interchange$ /path/to/your/perl Makefile.PL # and answer prompt about
where to put interchange

~/interchange$ make

~/interchange$ make test

~/interchange$ su

At this point make a backup of your current interchange install.

~/interchange# make install

At this point you need to read the UPGRADE file (actually you should
have already read it) and make any tweaks or adjustments listed in there
for your particular version upgrade.

Also at this point you should compile a new vlink or tlink or whatever
you use. See the compile_link program in the ic/bin directory for more
info, "./compile_link --help" gives you the arguments to use.

Cross fingers and restart interchange.

Check the error logs to make sure that startup is clean.

Check your sites to make sure they all still work as expected.

Note that if you've made any custom tweaks to the interchange core then
the onus is on you to make sure they are still there and re-tweak if
necessary.

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

gert at 3edge

Jun 14, 2009, 12:02 AM

Post #3 of 20 (2000 views)
Permalink

Re: Upgrade procedure [In reply to]

> -----Original Message-----
> From: interchange-users-bounces [at] icdevgroup [mailto:interchange-
> users-bounces [at] icdevgroup] On Behalf Of Peter
> Sent: Sunday, June 14, 2009 7:51 AM
> To: interchange-users [at] icdevgroup
> Subject: Re: [ic] Upgrade procedure
>
> On 06/13/2009 04:33 PM, Grant wrote:
> > I'd like to perform a safe upgrade from a 5.5 nightly to 5.6. Should
> > this be sufficient:
> >
> > # tar -cvzf ic.tar.gz /usr/local/ic
> > # su - interchange
> > $ cd /new/ic/source
> > $ ./configure
> > $ exit
> > # cd /new/ic/source
> > # make install
>
> No, my usual upgrade procedure is this:
> As unprivileged user:
>
> ~$ tar.cvzf ic.tar.gz # use the proper name of the tarball here
>
> ~$ cd interchange # use the correct name of the directory that the
> tarball created here
>
>
> ~/interchange$ /path/to/your/perl Makefile.PL # and answer prompt about
> where to put interchange

My different approach at this point is that I put the new interchange in a
separate directory, ie:
/opt/interchange-5.7.1/

> ~/interchange$ make
>
> ~/interchange$ make test
>
> ~/interchange$ su
>
> At this point make a backup of your current interchange install.
>
> ~/interchange# make install
>

In the most simple case you now have an interchange.cfg file to copy over to
the new tree.
When you have done various changes to your core, I'd suggest to create a
'build' script that you can run over the latest tree to apply your patches
to the tree ...

There would be a symlink pointing to the latest version you are using
ie /opt/interchange/ pointing to /opt/interchange-5.4.0

Once you did all your custom fixes and followed further steps regarding the
UPGRADE (changes to pages, local usertags, databases etc). Then you can
switch around your symlink and restart.

If things do not look like they are working well, you can switch back your
symlink and restart and you're back on your previous install.

> At this point you need to read the UPGRADE file (actually you should
> have already read it) and make any tweaks or adjustments listed in
> there
> for your particular version upgrade.
>
> Also at this point you should compile a new vlink or tlink or whatever
> you use. See the compile_link program in the ic/bin directory for more
> info, "./compile_link --help" gives you the arguments to use.
>
> Cross fingers and restart interchange.
>
> Check the error logs to make sure that startup is clean.
>
> Check your sites to make sure they all still work as expected.
>
> Note that if you've made any custom tweaks to the interchange core then
> the onus is on you to make sure they are still there and re-tweak if
> necessary.
>
>
> Peter
>
> _______________________________________________
> interchange-users mailing list
> interchange-users [at] icdevgroup
> http://www.icdevgroup.org/mailman/listinfo/interchange-users

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Jun 14, 2009, 1:34 AM

Post #4 of 20 (1989 views)
Permalink

Re: Upgrade procedure [In reply to]

On 06/14/2009 12:02 AM, Gert van der Spoel wrote:
> My different approach at this point is that I put the new interchange in a
> separate directory, ie:
> /opt/interchange-5.7.1/

If you're going to do this then it's a good idea to copy your existing
directory over first (cp -a interchange interchange-5.7.1), that way you
will keep your old interchange.cfg and other custom usertags, modules,
etc without having to worry about copying them over after the fact.

> In the most simple case you now have an interchange.cfg file to copy over to
> the new tree.
> When you have done various changes to your core, I'd suggest to create a
> 'build' script that you can run over the latest tree to apply your patches
> to the tree ...

I was avoiding getting into this much detail, but if you're going to do
this you are probably just as well off cloning git and maintaining your
changes there, that way they will be automatically merged with upgrades
and all you have to do is watch for conflicts.

Better yet, avoid core changes all together and if you absolutely have
to make a core change post to the ml first so that others can review it
and make suggestions about possible ways to do what you want without a
core change, and if it's absolutely needed it is not beyond reason for a
core developer to check your core change (or a similar one) into the
Interchange core itself and then you won't have to worry about
maintaining the change in future upgrades.

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Jun 14, 2009, 1:34 AM

Post #5 of 20 (2005 views)
Permalink

Re: Upgrade procedure [In reply to]

On 06/14/2009 12:02 AM, Gert van der Spoel wrote:
> My different approach at this point is that I put the new interchange in a
> separate directory, ie:
> /opt/interchange-5.7.1/

If you're going to do this then it's a good idea to copy your existing
directory over first (cp -a interchange interchange-5.7.1), that way you
will keep your old interchange.cfg and other custom usertags, modules,
etc without having to worry about copying them over after the fact.

> In the most simple case you now have an interchange.cfg file to copy over to
> the new tree.
> When you have done various changes to your core, I'd suggest to create a
> 'build' script that you can run over the latest tree to apply your patches
> to the tree ...

I was avoiding getting into this much detail, but if you're going to do
this you are probably just as well off cloning git and maintaining your
changes there, that way they will be automatically merged with upgrades
and all you have to do is watch for conflicts.

Better yet, avoid core changes all together and if you absolutely have
to make a core change post to the ml first so that others can review it
and make suggestions about possible ways to do what you want without a
core change, and if it's absolutely needed it is not beyond reason for a
core developer to check your core change (or a similar one) into the
Interchange core itself and then you won't have to worry about
maintaining the change in future upgrades.

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

Jun 14, 2009, 9:29 AM

Post #6 of 20 (1996 views)
Permalink

Re: Upgrade procedure [In reply to]

>> I'd like to perform a safe upgrade from a 5.5 nightly to 5.6. �Should
>> this be sufficient:
>>
>> # tar -cvzf ic.tar.gz /usr/local/ic
>> # su - interchange
>> $ cd /new/ic/source
>> $ ./configure
>> $ exit
>> # cd /new/ic/source
>> # make install
>
> No, my usual upgrade procedure is this:
> As unprivileged user:
>
> ~$ tar.cvzf ic.tar.gz # use the proper name of the tarball here
>
> ~$ cd interchange # use the correct name of the directory that the
> tarball created here
>
>
> ~/interchange$ /path/to/your/perl Makefile.PL # and answer prompt about
> where to put interchange
>
> ~/interchange$ make
>
> ~/interchange$ make test
>
> ~/interchange$ su
>
> At this point make a backup of your current interchange install.
>
> ~/interchange# make install
>
> At this point you need to read the UPGRADE file (actually you should
> have already read it) and make any tweaks or adjustments listed in there
> for your particular version upgrade.
>
> Also at this point you should compile a new vlink or tlink or whatever
> you use. �See the compile_link program in the ic/bin directory for more
> info, "./compile_link --help" gives you the arguments to use.
>
> Cross fingers and restart interchange.
>
> Check the error logs to make sure that startup is clean.
>
> Check your sites to make sure they all still work as expected.
>
> Note that if you've made any custom tweaks to the interchange core then
> the onus is on you to make sure they are still there and re-tweak if
> necessary.
>
>
> Peter

Thanks a lot, that worked perfectly. Here are some peculiarities:

1. I get this when restarting IC:

Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".

2. I get this when restarting IC:

Warning while compiling UserTag 'ups_query':
"my" variable $result masks earlier declaration in same scope at
/usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
line 154.

3. I use Interchange::Link and I had to add "SocketPerms 0666" to
interchange.cfg. I get the following warning in the global error.log:

ALERT: /usr/local/interchange/etc/socket socket permissions are
insecure; are you sure you want permissions 666?

- Grant

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Jun 14, 2009, 9:58 AM

Post #7 of 20 (1990 views)
Permalink

Re: Upgrade procedure [In reply to]

On 06/14/2009 09:29 AM, Grant wrote:
> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".

You have a duplicate Database line for your variable database. check
your catalog.cfg and included files (including files in the dbconf
directory and subdirectories).

> Warning while compiling UserTag 'ups_query':
> "my" variable $result masks earlier declaration in same scope at
> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
> line 154.

This is an issue with Business::UPS and needs to be taken up with the
author of that module. It is porobably safe to ignore the warning, though.

> 3. I use Interchange::Link and I had to add "SocketPerms 0666" to
> interchange.cfg. I get the following warning in the global error.log:
>
> ALERT: /usr/local/interchange/etc/socket socket permissions are
> insecure; are you sure you want permissions 666?

If you trust everyone who has access to the server then you generally
don't have to worry about that, but it's a good idea to fix it anyways.
The proper way to fix it is to properly set the owner and suid
permissions bit on your vlink file so that it can access the socket
without requiring 666 permissions on the socket.

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

Jun 14, 2009, 1:32 PM

Post #8 of 20 (1986 views)
Permalink

Re: Upgrade procedure [In reply to]

>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>
> You have a duplicate Database line for your variable database. �check
> your catalog.cfg and included files (including files in the dbconf
> directory and subdirectories).

You're right, I had variable.dbm in both dbconf/default_db and
dbconf/mysql. I noticed I also have identical access.dbm and
mv_metadata.dbm files in those locations. Does variable have special
handling in this case?

>> Warning while compiling UserTag 'ups_query':
>> "my" variable $result masks earlier declaration in same scope at
>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
>> line 154.
>
> This is an issue with Business::UPS and needs to be taken up with the
> author of that module. �It is porobably safe to ignore the warning, though.

OK but should that usertag be disincluded from IC since it has a problem?

code/UserTag/ups_query.tag

>> 3. I use Interchange::Link and I had to add "SocketPerms 0666" to
>> interchange.cfg. �I get the following warning in the global error.log:
>>
>> ALERT: /usr/local/interchange/etc/socket socket permissions are
>> insecure; are you sure you want permissions 666?
>
> If you trust everyone who has access to the server then you generally
> don't have to worry about that, but it's a good idea to fix it anyways.
> �The proper way to fix it is to properly set the owner and suid
> permissions bit on your vlink file so that it can access the socket
> without requiring 666 permissions on the socket.

Do I need to stick with 666 permissions since I'm using
Interchange::Link instead of vlink?

- Grant

> Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Jun 14, 2009, 2:29 PM

Post #9 of 20 (1978 views)
Permalink

Re: Upgrade procedure [In reply to]

On 06/14/2009 01:32 PM, Grant wrote:
>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>> You have a duplicate Database line for your variable database. check
>> your catalog.cfg and included files (including files in the dbconf
>> directory and subdirectories).
>
> You're right, I had variable.dbm in both dbconf/default_db and
> dbconf/mysql. I noticed I also have identical access.dbm and
> mv_metadata.dbm files in those locations. Does variable have special
> handling in this case?

Only the ones in the mysql directory should get pulled in. Check your
catalog.cfg for an extra Database line for the variable file.

>>> Warning while compiling UserTag 'ups_query':
>>> "my" variable $result masks earlier declaration in same scope at
>>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
>>> line 154.
>> This is an issue with Business::UPS and needs to be taken up with the
>> author of that module. It is porobably safe to ignore the warning, though.
>
> OK but should that usertag be disincluded from IC since it has a problem?
>
> code/UserTag/ups_query.tag

If you're not using ups then you should be able to exclude the usertag
without problems. I would not consider the warning you mention to be
enough of a "problem" to merit removing the usertag from IC.

>>> 3. I use Interchange::Link and I had to add "SocketPerms 0666" to
>>> interchange.cfg. I get the following warning in the global error.log:
>>>
>>> ALERT: /usr/local/interchange/etc/socket socket permissions are
>>> insecure; are you sure you want permissions 666?
>> If you trust everyone who has access to the server then you generally
>> don't have to worry about that, but it's a good idea to fix it anyways.
>> The proper way to fix it is to properly set the owner and suid
>> permissions bit on your vlink file so that it can access the socket
>> without requiring 666 permissions on the socket.
>
> Do I need to stick with 666 permissions since I'm using
> Interchange::Link instead of vlink?

I missed that you're using Interchange::Link. I don't use that or know
much about it so someone else will have to answer your question.

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

markl at gasupnow

Jun 14, 2009, 3:42 PM

Post #10 of 20 (1989 views)
Permalink

Re: Upgrade procedure [In reply to]

Peter wrote:
> On 06/14/2009 01:32 PM, Grant wrote:
>> Do I need to stick with 666 permissions since I'm using
>> Interchange::Link instead of vlink?
>
> I missed that you're using Interchange::Link. I don't use that or know
> much about it so someone else will have to answer your question.

If you use Interchange::Link, the socket needs to be able to be
read/write by the same user that Apache runs as.

In addition to all the other great upgrade advice that has come out of
this thread, remember to back up your existing interchange directory,
and database. It almost goes without saying, but not quite.

Regards,
Mark

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

Jun 15, 2009, 7:44 AM

Post #11 of 20 (1980 views)
Permalink

Re: Upgrade procedure [In reply to]

>>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>>> You have a duplicate Database line for your variable database. �check
>>> your catalog.cfg and included files (including files in the dbconf
>>> directory and subdirectories).
>>
>> You're right, I had variable.dbm in both dbconf/default_db and
>> dbconf/mysql. �I noticed I also have identical access.dbm and
>> mv_metadata.dbm files in those locations. �Does variable have special
>> handling in this case?
>
> Only the ones in the mysql directory should get pulled in. �Check your
> catalog.cfg for an extra Database line for the variable file.

The message actually disappeared after I removed the line from
dbconf/default_db/variable.dbm. A bug maybe?

>>>> Warning while compiling UserTag 'ups_query':
>>>> "my" variable $result masks earlier declaration in same scope at
>>>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
>>>> line 154.
>>> This is an issue with Business::UPS and needs to be taken up with the
>>> author of that module. �It is porobably safe to ignore the warning, though.
>>
>> OK but should that usertag be disincluded from IC since it has a problem?
>>
>> code/UserTag/ups_query.tag
>
> If you're not using ups then you should be able to exclude the usertag
> without problems. �I would not consider the warning you mention to be
> enough of a "problem" to merit removing the usertag from IC.

A fresh installation of IC throwing a warning upon start/restart seems
to me like it should be fixed, but it's not a big deal. I renamed
ups_query.tag to ups_query.tag.conflict and the warning disappeared.

Thanks a lot for all your advice. The upgrade went very smoothly thanks to you.

- Grant

>>>> 3. I use Interchange::Link and I had to add "SocketPerms 0666" to
>>>> interchange.cfg. �I get the following warning in the global error.log:
>>>>
>>>> ALERT: /usr/local/interchange/etc/socket socket permissions are
>>>> insecure; are you sure you want permissions 666?
>>> If you trust everyone who has access to the server then you generally
>>> don't have to worry about that, but it's a good idea to fix it anyways.
>>> �The proper way to fix it is to properly set the owner and suid
>>> permissions bit on your vlink file so that it can access the socket
>>> without requiring 666 permissions on the socket.
>>
>> Do I need to stick with 666 permissions since I'm using
>> Interchange::Link instead of vlink?
>
> I missed that you're using Interchange::Link. �I don't use that or know
> much about it so someone else will have to answer your question.
>
>
>
> Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

Jun 15, 2009, 7:45 AM

Post #12 of 20 (1974 views)
Permalink

Re: Upgrade procedure [In reply to]

>>> Do I need to stick with 666 permissions since I'm using
>>> Interchange::Link instead of vlink?
>>
>> I missed that you're using Interchange::Link. �I don't use that or know
>> much about it so someone else will have to answer your question.
>
> If you use Interchange::Link, the socket needs to be able to be
> read/write by the same user that Apache runs as.

Got it, thank you.

- Grant

> In addition to all the other great upgrade advice that has come out of
> this thread, remember to back up your existing interchange directory,
> and database. �It almost goes without saying, but not quite.
>
> Regards,
> Mark

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Jun 15, 2009, 10:00 AM

Post #13 of 20 (1978 views)
Permalink

Re: Upgrade procedure [In reply to]

On 06/15/2009 07:44 AM, Grant wrote:
>>>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>>>> You have a duplicate Database line for your variable database. check
>>>> your catalog.cfg and included files (including files in the dbconf
>>>> directory and subdirectories).
>>> You're right, I had variable.dbm in both dbconf/default_db and
>>> dbconf/mysql. I noticed I also have identical access.dbm and
>>> mv_metadata.dbm files in those locations. Does variable have special
>>> handling in this case?
>> Only the ones in the mysql directory should get pulled in. Check your
>> catalog.cfg for an extra Database line for the variable file.
>
> The message actually disappeared after I removed the line from
> dbconf/default_db/variable.dbm. A bug maybe?

Only one of the two directories should get pulled in from your
catalog.cfg, so check that and any files included from that. Certain
variables set in the variables.txt file itself can control the flow of
things in catalog.cfg, explicitly where control of which db is pulled in
is concerned.

>>>>> Warning while compiling UserTag 'ups_query':
>>>>> "my" variable $result masks earlier declaration in same scope at
>>>>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
>>>>> line 154.
>>>> This is an issue with Business::UPS and needs to be taken up with the
>>>> author of that module. It is porobably safe to ignore the warning, though.
>>> OK but should that usertag be disincluded from IC since it has a problem?
>>>
>>> code/UserTag/ups_query.tag
>> If you're not using ups then you should be able to exclude the usertag
>> without problems. I would not consider the warning you mention to be
>> enough of a "problem" to merit removing the usertag from IC.
>
> A fresh installation of IC throwing a warning upon start/restart seems
> to me like it should be fixed, but it's not a big deal. I renamed
> ups_query.tag to ups_query.tag.conflict and the warning disappeared.

Yes and no. The warning is not coming from any Interchange code itself,
but from the module. It is even possible that you have a specific
version of the module which throws the warning. At any rate, given a
choice between having functionality and a warning or having to implement
such a broad range of functionality ourselves or removing the
functionality generally having the functionality and the warning wins out.

If it were an Interchange bug causing the warning then you would be correct.

> Thanks a lot for all your advice. The upgrade went very smoothly thanks to you.

You're welcome :-)

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

Jun 15, 2009, 3:00 PM

Post #14 of 20 (1971 views)
Permalink

Re: Upgrade procedure [In reply to]

>>>>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>>>>> You have a duplicate Database line for your variable database. �check
>>>>> your catalog.cfg and included files (including files in the dbconf
>>>>> directory and subdirectories).
>>>> You're right, I had variable.dbm in both dbconf/default_db and
>>>> dbconf/mysql. �I noticed I also have identical access.dbm and
>>>> mv_metadata.dbm files in those locations. �Does variable have special
>>>> handling in this case?
>>> Only the ones in the mysql directory should get pulled in. �Check your
>>> catalog.cfg for an extra Database line for the variable file.

I do have in catalog.cfg:

VariableDatabase variable

Does that refer specifically to dbconf/default_db/variable.dbm? I'm
afraid to remove the line to find out.

>> The message actually disappeared after I removed the line from
>> dbconf/default_db/variable.dbm. �A bug maybe?
>
> Only one of the two directories should get pulled in from your
> catalog.cfg, so check that and any files included from that. �Certain
> variables set in the variables.txt file itself can control the flow of
> things in catalog.cfg, explicitly where control of which db is pulled in
> is concerned.
>
>>>>>> Warning while compiling UserTag 'ups_query':
>>>>>> "my" variable $result masks earlier declaration in same scope at
>>>>>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
>>>>>> line 154.
>>>>> This is an issue with Business::UPS and needs to be taken up with the
>>>>> author of that module. �It is porobably safe to ignore the warning, though.
>>>> OK but should that usertag be disincluded from IC since it has a problem?
>>>>
>>>> code/UserTag/ups_query.tag
>>> If you're not using ups then you should be able to exclude the usertag
>>> without problems. �I would not consider the warning you mention to be
>>> enough of a "problem" to merit removing the usertag from IC.
>>
>> A fresh installation of IC throwing a warning upon start/restart seems
>> to me like it should be fixed, but it's not a big deal. �I renamed
>> ups_query.tag to ups_query.tag.conflict and the warning disappeared.
>
> Yes and no. �The warning is not coming from any Interchange code itself,
> but from the module. �It is even possible that you have a specific
> version of the module which throws the warning. �At any rate, given a
> choice between having functionality and a warning or having to implement
> such a broad range of functionality ourselves or removing the
> functionality generally having the functionality and the warning wins out.
>
> If it were an Interchange bug causing the warning then you would be correct.

I see what you're saying, so the conflict is due to a problem with
/usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm, not a problem with
ups_query.tag. Do you know which version would be pulled in by
Interchange::Bundle? It looks like Business-UPS-2.0 is the latest. I
can't find mention of the version in the installed module's source.
If Interchange::Bundle pulls in the latest Business::UPS, isn't it
fair to say there is a problem with ups_query.tag (which is
distributed with IC)?

- Grant

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

jon at endpoint

Jun 15, 2009, 3:50 PM

Post #15 of 20 (1974 views)
Permalink

Re: Upgrade procedure [In reply to]

On Mon, 15 Jun 2009, Grant wrote:

> I do have in catalog.cfg:
>
> VariableDatabase variable
>
> Does that refer specifically to dbconf/default_db/variable.dbm?

No, that refers to products/variable.txt.

> I see what you're saying, so the conflict is due to a problem with
> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm, not a problem with
> ups_query.tag. Do you know which version would be pulled in by
> Interchange::Bundle? It looks like Business-UPS-2.0 is the latest. I
> can't find mention of the version in the installed module's source. If
> Interchange::Bundle pulls in the latest Business::UPS, isn't it fair to
> say there is a problem with ups_query.tag (which is distributed with
> IC)?

Grant, I think something must be old there: Either the Business::UPS, or
the ups-query tag, or something, because I don't get any warning on
startup, and I don't see the $result variable mentioned in your error
message in either Business::UPS or ups_query.tag.

Are you sure you don't have an old ups-query tag floating around in a
different directory, catalog.cfg, or one of its includes?

Is there a $result variable in your Business::UPS source at line 97 as the
error would indicate?

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

Jun 15, 2009, 4:40 PM

Post #16 of 20 (1965 views)
Permalink

Re: Upgrade procedure [In reply to]

>> I do have in catalog.cfg:
>>
>> VariableDatabase variable
>>
>> Does that refer specifically to dbconf/default_db/variable.dbm?
>
> No, that refers to products/variable.txt.

OK, I don't know why dbconf/default_db/variable.dbm is conflicting
with dbconf/mysql/variable.dbm since dbconf/default_db/access.dbm and
dbconf/default_db/mv_metadata.dbm aren't conflicting with their
identical copies in dbconf/mysql.

>> I see what you're saying, so the conflict is due to a problem with
>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm, not a problem with
>> ups_query.tag. �Do you know which version would be pulled in by
>> Interchange::Bundle? �It looks like Business-UPS-2.0 is the latest. �I
>> can't find mention of the version in the installed module's source. If
>> Interchange::Bundle pulls in the latest Business::UPS, isn't it fair to
>> say there is a problem with ups_query.tag (which is distributed with
>> IC)?
>
> Grant, I think something must be old there: Either the Business::UPS, or
> the ups-query tag, or something, because I don't get any warning on
> startup, and I don't see the $result variable mentioned in your error
> message in either Business::UPS or ups_query.tag.
>
> Are you sure you don't have an old ups-query tag floating around in a
> different directory, catalog.cfg, or one of its includes?
>
> Is there a $result variable in your Business::UPS source at line 97 as the
> error would indicate?

Yeah I sure do have $result at line 97. I guess I've got an old
version? Are you on the latest? I just installed Interchange::Bundle
via IC's 'make install', and shouldn't Business::UPS have been
updated?

- Grant

> Jon Jensen
> End Point Corporation
> http://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

jon at endpoint

Jun 15, 2009, 6:10 PM

Post #17 of 20 (1964 views)
Permalink

Re: Upgrade procedure [In reply to]

On Mon, 15 Jun 2009, Grant wrote:

> I don't know why dbconf/default_db/variable.dbm is conflicting with
> dbconf/mysql/variable.dbm since dbconf/default_db/access.dbm and
> dbconf/default_db/mv_metadata.dbm aren't conflicting with their
> identical copies in dbconf/mysql.

As someone else mentioned, normally dbconf/default_db/* is not used at all
if you're using an SQL database.

Feel free to delete the entire dbconf/default_db directory, as you should
have no need of it.

>> Grant, I think something must be old there: Either the Business::UPS,
>> or the ups-query tag, or something, because I don't get any warning on
>> startup, and I don't see the $result variable mentioned in your error
>> message in either Business::UPS or ups_query.tag.
>>
>> Are you sure you don't have an old ups-query tag floating around in a
>> different directory, catalog.cfg, or one of its includes?
>>
>> Is there a $result variable in your Business::UPS source at line 97 as
>> the error would indicate?
>
> Yeah I sure do have $result at line 97. I guess I've got an old
> version? Are you on the latest? I just installed Interchange::Bundle
> via IC's 'make install', and shouldn't Business::UPS have been updated?

Aha. Look carefully at Bundle::Interchange. It doesn't actually include
Business::UPS! It mentions it in the description, but isn't specified as
one of the dependencies. So you probably didn't update it when you thought
you did. Try updating it by hand.

If that still doesn't work, search your Perl include paths to see if
there's an old version earlier in the path than the new one you install.

BTW, Bundle::InterchangeKitchenSink *does* include Business::UPS.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Jun 15, 2009, 9:20 PM

Post #18 of 20 (1968 views)
Permalink

Re: Upgrade procedure [In reply to]

On 06/15/2009 03:00 PM, Grant wrote:
>>>>>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>>>>>> You have a duplicate Database line for your variable database. check
>>>>>> your catalog.cfg and included files (including files in the dbconf
>>>>>> directory and subdirectories).
>>>>> You're right, I had variable.dbm in both dbconf/default_db and
>>>>> dbconf/mysql. I noticed I also have identical access.dbm and
>>>>> mv_metadata.dbm files in those locations. Does variable have special
>>>>> handling in this case?
>>>> Only the ones in the mysql directory should get pulled in. Check your
>>>> catalog.cfg for an extra Database line for the variable file.
>
> I do have in catalog.cfg:
>
> VariableDatabase variable
>
> Does that refer specifically to dbconf/default_db/variable.dbm? I'm
> afraid to remove the line to find out.

No, that's not the line. Look further down at the "Database Setup"
section. It should look like this (from foundation, standard demo is
different):

ifdef MYSQL
DatabaseDefault NO_ASCII_INDEX 1
include dbconf/mysql/mysql.cfg
endif

ifdef PGSQL
DatabaseDefault NO_ASCII_INDEX 1
include dbconf/pgsql/pgsql.cfg
endif

ifdef ORACLE
DatabaseDefault NO_ASCII_INDEX 1
include dbconf/oracle/oracle.cfg
endif

ifdef SQLITE
DatabaseDefault NO_ASCII_INDEX 1
include dbconf/sqlite/sqlite.cfg
endif

# Default DBM if nothing else defined
ifndef SOME_DATABASE
include dbconf/default_db/default_db.cfg
endif

So according to that you should have MYSQL set to a true value (1, yes,
whatever) in your variables.txt in order to run the MYSQL part of that
and slurp in mysql.cfg. You should also *not* have PGSQL ORACLE or
SQLITE set to true values. Then look at dbconf/mysql/mysql.cfg and make
sure there are no explicit references to anything in default_database
(or any directory other than dbconf/mysql). Also there should be this
line at the bottom of the file:
Variable SOME_DATABASE 1

That last line will prevent
the default_db.cfg file from being slurped in. Somehow either the
default_db.cfg file is getting slurped in or you are including the
dbconf/default_db/variables.dbm file from somewhere else.

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

Jun 16, 2009, 10:01 AM

Post #19 of 20 (1955 views)
Permalink

Re: Upgrade procedure [In reply to]

>> I don't know why dbconf/default_db/variable.dbm is conflicting with
>> dbconf/mysql/variable.dbm since dbconf/default_db/access.dbm and
>> dbconf/default_db/mv_metadata.dbm aren't conflicting with their
>> identical copies in dbconf/mysql.
>
> As someone else mentioned, normally dbconf/default_db/* is not used at all
> if you're using an SQL database.
>
> Feel free to delete the entire dbconf/default_db directory, as you should
> have no need of it.
>
>>> Grant, I think something must be old there: Either the Business::UPS,
>>> or the ups-query tag, or something, because I don't get any warning on
>>> startup, and I don't see the $result variable mentioned in your error
>>> message in either Business::UPS or ups_query.tag.
>>>
>>> Are you sure you don't have an old ups-query tag floating around in a
>>> different directory, catalog.cfg, or one of its includes?
>>>
>>> Is there a $result variable in your Business::UPS source at line 97 as
>>> the error would indicate?
>>
>> Yeah I sure do have $result at line 97. �I guess I've got an old
>> version? �Are you on the latest? �I just installed Interchange::Bundle
>> via IC's 'make install', and shouldn't Business::UPS have been updated?
>
> Aha. Look carefully at Bundle::Interchange. It doesn't actually include
> Business::UPS! It mentions it in the description, but isn't specified as
> one of the dependencies. So you probably didn't update it when you thought
> you did. Try updating it by hand.
>
> If that still doesn't work, search your Perl include paths to see if
> there's an old version earlier in the path than the new one you install.
>
> BTW, Bundle::InterchangeKitchenSink *does* include Business::UPS.
>
> Jon

Got it, thanks Jon. I just tried to install
Bundle-InterchangeKitchenSink via Gentoo's g-cpan but this list of
dependencies looks ridiculous:

[ebuild N ] perl-gcpan/OLE-Storage-Lite-0.18
[ebuild N ] perl-gcpan/IO-Stty-0.02
[ebuild N ] perl-gcpan/Set-Crontab-1.02
[ebuild N ] x11-misc/util-macros-1.2.1
[ebuild N ] dev-perl/OLE-StorageLite-0.14
[ebuild N ] perl-core/Text-Balanced-2.0.0
[ebuild N ] perl-gcpan/Image-Size-3.2
[ebuild N ] dev-perl/IO-Tty-1.07
[ebuild N ] dev-perl/TermReadKey-2.30
[ebuild N ] dev-perl/Term-ReadLine-Perl-1.03.02
[ebuild N ] dev-lang/tcl-8.4.18 USE="-debug -threads"
[ebuild N ] dev-perl/Unicode-Map-0.112
[ebuild N ] x11-proto/xproto-7.0.14
[ebuild N ] x11-libs/xtrans-1.2.3 USE="-debug"
[ebuild N ] x11-proto/kbproto-1.0.3
[ebuild N ] x11-proto/inputproto-1.5.0
[ebuild N ] dev-perl/Spreadsheet-ParseExcel-0.32 USE="unicode -cjk -test"
[ebuild N ] x11-proto/xf86bigfontproto-1.1.2
[ebuild N ] x11-proto/bigreqsproto-1.0.2
[ebuild N ] x11-proto/xcmiscproto-1.1.2
[ebuild N ] virtual/perl-Text-Balanced-2.0.0
[ebuild N ] dev-perl/Parse-RecDescent-1.94
[ebuild N ] x11-libs/libICE-1.0.4 USE="-debug -ipv6"
[ebuild N ] x11-proto/xextproto-7.0.4
[ebuild N ] x11-libs/libXau-1.0.4 USE="-debug"
[ebuild N ] x11-libs/libXdmcp-1.0.2 USE="-debug"
[ebuild N ] x11-libs/libX11-1.1.5 USE="-debug -ipv6 -xcb"
[ebuild N ] dev-perl/Spreadsheet-WriteExcel-2.20
[ebuild N ] x11-libs/libSM-1.1.0 USE="-debug -ipv6"
[ebuild N ] x11-libs/libXt-1.0.5 USE="-debug"
[ebuild N ] dev-lang/tk-8.4.18-r1 USE="-debug -threads"
[ebuild N ] perl-gcpan/Bundle-InterchangeKitchenSink-1.06

I'll see if I can figure this out.

- Grant

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

Jun 16, 2009, 11:35 AM

Post #20 of 20 (1958 views)
Permalink

Re: Upgrade procedure [In reply to]

>>>>>>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>>>>>>> You have a duplicate Database line for your variable database. �check
>>>>>>> your catalog.cfg and included files (including files in the dbconf
>>>>>>> directory and subdirectories).
>>>>>> You're right, I had variable.dbm in both dbconf/default_db and
>>>>>> dbconf/mysql. �I noticed I also have identical access.dbm and
>>>>>> mv_metadata.dbm files in those locations. �Does variable have special
>>>>>> handling in this case?
>>>>> Only the ones in the mysql directory should get pulled in. �Check your
>>>>> catalog.cfg for an extra Database line for the variable file.
>>
>> I do have in catalog.cfg:
>>
>> VariableDatabase variable
>>
>> Does that refer specifically to dbconf/default_db/variable.dbm? �I'm
>> afraid to remove the line to find out.
>
> No, that's not the line. �Look further down at the "Database Setup"
> section. �It should look like this (from foundation, standard demo is
> different):
>
> ifdef MYSQL
> DatabaseDefault NO_ASCII_INDEX 1
> include dbconf/mysql/mysql.cfg
> endif
>
> ifdef PGSQL
> DatabaseDefault NO_ASCII_INDEX 1
> include dbconf/pgsql/pgsql.cfg
> endif
>
> ifdef ORACLE
> DatabaseDefault NO_ASCII_INDEX 1
> include dbconf/oracle/oracle.cfg
> endif
>
> ifdef SQLITE
> DatabaseDefault NO_ASCII_INDEX 1
> include dbconf/sqlite/sqlite.cfg
> endif
>
> # Default DBM if nothing else defined
> ifndef SOME_DATABASE
> include dbconf/default_db/default_db.cfg
> endif
>
>
> So according to that you should have MYSQL set to a true value (1, yes,
> whatever) in your variables.txt in order to run the MYSQL part of that
> and slurp in mysql.cfg. �You should also *not* have PGSQL ORACLE or
> SQLITE set to true values. �Then look at dbconf/mysql/mysql.cfg and make
> sure there are no explicit references to anything in default_database
> (or any directory other than dbconf/mysql). �Also there should be this
> line at the bottom of the file:
> Variable SOME_DATABASE 1
>
> That last line will prevent
> the default_db.cfg file from being slurped in. �Somehow either the
> default_db.cfg file is getting slurped in or you are including the
> dbconf/default_db/variables.dbm file from somewhere else.

Right again, I had in catalog.cfg without a conditional:

include dbconf/default_db/default_db.cfg

Thanks a lot for your help.

- Grant

> Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads