headers
Kent Boortz | 13 May 2007 05:59
Picon
Favicon

Files in CVS that should not be?


Hi,

I'm working on enabling "make dist" to work in the CVS version, and
found some "Makefile.in" files to be checked into the CVS repository.
I think they should not be under CVS control, or?

  unixODBC/DataManagerII/Makefile.in
  unixODBC/Drivers/MySQL/Makefile.in
  unixODBC/Drivers/MySQL/samples/Makefile.in
  unixODBC/gODBCConfig/Makefile.in
  unixODBC/gODBCConfig/intl/Makefile.in
  unixODBC/gODBCConfig/po/Makefile.in.in
  unixODBC/libltdl/Makefile.in
  unixODBC/DataManagerII/Makefile.am~    <<< emacs backup file checked in
  odbctest/C:\IB6TRACE.LOG               <<< garbage checked in?

Not near finished, but as there are things that you might prefer to
remove from the CVS source repository instead of adding to the source
distribution, I include my first version of the patch.

As you don't seem to have some daily build to check that "make dist"
works, I have used the feature of automake that you can give a
directory name to EXTRA_DIST, and a top level "dist-hook" target to
remove the "CVS", ".libs" and ."deps" directories before packaging.

The advantage with giving a directory to EXTRA_DIST is that you don't
have to list all files, the drawback is that if you do "make dist" in
a source tree you have built in, you might get garbage into the
created source TAR.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nick Gorham | 14 May 2007 11:03
Favicon

Re: Files in CVS that should not be?

Kent Boortz wrote:

>Hi,
>
>I'm working on enabling "make dist" to work in the CVS version, and
>found some "Makefile.in" files to be checked into the CVS repository.
>I think they should not be under CVS control, or?
>
>  unixODBC/DataManagerII/Makefile.in
>  unixODBC/Drivers/MySQL/Makefile.in
>  unixODBC/Drivers/MySQL/samples/Makefile.in
>  unixODBC/gODBCConfig/Makefile.in
>  unixODBC/gODBCConfig/intl/Makefile.in
>  unixODBC/gODBCConfig/po/Makefile.in.in
>  unixODBC/libltdl/Makefile.in
>  unixODBC/DataManagerII/Makefile.am~    <<< emacs backup file checked in
>  odbctest/C:\IB6TRACE.LOG               <<< garbage checked in?
>
>Not near finished, but as there are things that you might prefer to
>remove from the CVS source repository instead of adding to the source
>distribution, I include my first version of the patch.
>  
>
Ok, I will look at removing them. The log file ins't in the source 
distribution BTW.

The Makefile.in's are in the distrib for platforms that don't have their 
own automake installed, I don't see the real problem.

>As you don't seem to have some daily build to check that "make dist"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kent Boortz | 14 May 2007 11:34
Picon
Favicon

Re: Files in CVS that should not be?


Nick Gorham <nick.gorham <at> easysoft.com> writes:
>>I'm working on enabling "make dist" to work in the CVS version, and
>>found some "Makefile.in" files to be checked into the CVS repository.
>>I think they should not be under CVS control, or?
>>
>>  unixODBC/DataManagerII/Makefile.in
>>  unixODBC/Drivers/MySQL/Makefile.in
>>  unixODBC/Drivers/MySQL/samples/Makefile.in
>>  unixODBC/gODBCConfig/Makefile.in
>>  unixODBC/gODBCConfig/intl/Makefile.in
>>  unixODBC/gODBCConfig/po/Makefile.in.in
>>  unixODBC/libltdl/Makefile.in
>>  unixODBC/DataManagerII/Makefile.am~    <<< emacs backup file checked in
>>  odbctest/C:\IB6TRACE.LOG               <<< garbage checked in?
>>
>>Not near finished, but as there are things that you might prefer to
>>remove from the CVS source repository instead of adding to the source
>>distribution, I include my first version of the patch.
>>
> Ok, I will look at removing them. The log file ins't in the source 
> distribution BTW.

I talk about the CVS tree, I don't know how you produce the source TAR
from that. I just assumed you don't use "make dist", as I found it to
be broken. I could be wrong of course, that something in my setup made
it break. I do think the LOG file is in CVS, but I could read it wrong
as well

  % grep LOG odbctest/CVS/Entries
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nick Gorham | 14 May 2007 12:42
Favicon

Re: Files in CVS that should not be?

Kent Boortz wrote:

>Nick Gorham <nick.gorham <at> easysoft.com> writes:
>  
>
>>>I'm working on enabling "make dist" to work in the CVS version, and
>>>found some "Makefile.in" files to be checked into the CVS repository.
>>>I think they should not be under CVS control, or?
>>>
>>> unixODBC/DataManagerII/Makefile.in
>>> unixODBC/Drivers/MySQL/Makefile.in
>>> unixODBC/Drivers/MySQL/samples/Makefile.in
>>> unixODBC/gODBCConfig/Makefile.in
>>> unixODBC/gODBCConfig/intl/Makefile.in
>>> unixODBC/gODBCConfig/po/Makefile.in.in
>>> unixODBC/libltdl/Makefile.in
>>> unixODBC/DataManagerII/Makefile.am~    <<< emacs backup file checked in
>>> odbctest/C:\IB6TRACE.LOG               <<< garbage checked in?
>>>
>>>Not near finished, but as there are things that you might prefer to
>>>remove from the CVS source repository instead of adding to the source
>>>distribution, I include my first version of the patch.
>>>
>>>      
>>>
>>Ok, I will look at removing them. The log file ins't in the source 
>>distribution BTW.
>>    
>>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Harvey | 16 May 2007 05:17
Gravatar

Re: Files in CVS that should not be?

*.vpj is a SlickEdit project file used, at least by me, for development :)
> Also your patches adds various makefiles and projects, at the moment 
> the code builds using the standard unix tools, I have enough trouble 
> as it is keeping the QT code building as TT change stuff. Not sure 
> where DriverManager.vpj came from in CVS for example (ok I know I can 
> check), but I don't think it needs to be in the distribution IHMO.
>

--
Peter

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> easysoft.com
http://mail.easysoft.com/mailman/listinfo/unixodbc-dev
Permalink | Reply | 0 comments |
headers
Leif Madsen | 18 May 2007 05:36
Picon

Segfault when utilizing libodbc with Asterisk

Evening all!

I apologize now if I'm utilizing the wrong mailing list. I was
debating between support and the dev list, but the description of the
dev list seemed more appropriate. I will be sure to correct this in
the future if I'm wrong :)

I am utilizing unixODBC package (unixODBC and unixODBC-devel version
2.2.12-1.el4s1.1) on CentOS 4.4, and have been seeing some random
segfaults of Asterisk when utilizing the libodbc libraries. The
developers of Asterisk have stated they believe it to be a problem in
the libodbc driver, and the developers of the Progress (not
postgresql) database have fixed a similar issue apparently for another
implementor I speak with regularly and his crashes seem to have become
resolved. (I do not have the fix he received from the vendor, but if
you think it would be of use, then I can follow up with that
information.)

I have posted a pair of backtraces from the Asterisk systems which
crashed. This may not be overly useful to the development team, but
this is what I have to work with right now. Hopefully this will help
start the discussion and determine where to go from here.

The backtraces are located here:

http://www.pastebin.ca/494189
http://www.pastebin.ca/494193

Asterisk seems to crash randomly about every other day it seems.
Unfortunately this is preventing us from going to production, so I'm
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nick Gorham | 18 May 2007 10:35
Favicon

Re: Segfault when utilizing libodbc with Asterisk

Leif Madsen wrote:

> Evening all!
>
> I apologize now if I'm utilizing the wrong mailing list. I was
> debating between support and the dev list, but the description of the
> dev list seemed more appropriate. I will be sure to correct this in
> the future if I'm wrong :)

No, this will do :-)

>
> I am utilizing unixODBC package (unixODBC and unixODBC-devel version
> 2.2.12-1.el4s1.1) on CentOS 4.4, and have been seeing some random
> segfaults of Asterisk when utilizing the libodbc libraries. The
> developers of Asterisk have stated they believe it to be a problem in
> the libodbc driver, and the developers of the Progress (not
> postgresql) database have fixed a similar issue apparently for another
> implementor I speak with regularly and his crashes seem to have become
> resolved. (I do not have the fix he received from the vendor, but if
> you think it would be of use, then I can follow up with that
> information.)

Ok, I don't know exactly how (or what) 2.2.12-1.el4s1 is, I guess its 
based on the 2.2.12 tree, but as I know people started producing builds 
before it was released your guess is as good as mine. I could do with a 
bit more information, what odbc driver are you using under libodbc? Yes 
any details from the postgres folk could help.

The backtrace show two failures in different places, that makes me
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan Radman | 18 May 2007 10:59
Favicon

RE: Segfault when utilizing libodbc with Asterisk

FYI
> Ok, I don't know exactly how (or what) 2.2.12-1.el4s1 is, I guess its 
> based on the 2.2.12 tree, but as I know people started 
unixODBC-2.2.12-1.el4s1.1 is part of the CentOS WebStack of the CentOS
Plus Repository
http://wiki.centos.org/Repositories/CentOSPlus
http://wiki.centos.org/Repositories/CentOSPlus/CentOSWebStack
http://isoredirect.centos.org/centos/4/centosplus/SRPMS/unixODBC-2.2.12-
1.el4s1.1.src.rpm 
It seems to be identical with an RPM in the Red Hat Application Stack
1.1 for RHEL4
https://rhn.redhat.com/errata/RHEA-2007-0084.html
The source RPM includes the official 2.2.12 tarball from Oct 2006 with 4
additional patches.

Stefan
> -----Original Message-----
> From: unixodbc-dev-bounces <at> easysoft.com 
> [mailto:unixodbc-dev-bounces <at> easysoft.com] On Behalf Of Nick Gorham
> Sent: Friday, 18 May, 2007 10:35
> To: Development issues and topics for unixODBC
> Subject: Re: [unixODBC-dev] Segfault when utilizing libodbc 
> with Asterisk
> 
> Leif Madsen wrote:
> 
> > Evening all!
> >
> > I apologize now if I'm utilizing the wrong mailing list. I was
> > debating between support and the dev list, but the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nick Gorham | 18 May 2007 11:42
Favicon

Re: Segfault when utilizing libodbc with Asterisk

Stefan Radman wrote:

>FYI
>  
>
>>Ok, I don't know exactly how (or what) 2.2.12-1.el4s1 is, I guess its 
>>based on the 2.2.12 tree, but as I know people started 
>>    
>>
>unixODBC-2.2.12-1.el4s1.1 is part of the CentOS WebStack of the CentOS
>Plus Repository
>http://wiki.centos.org/Repositories/CentOSPlus
>http://wiki.centos.org/Repositories/CentOSPlus/CentOSWebStack
>http://isoredirect.centos.org/centos/4/centosplus/SRPMS/unixODBC-2.2.12-
>1.el4s1.1.src.rpm 
>It seems to be identical with an RPM in the Red Hat Application Stack
>1.1 for RHEL4
>https://rhn.redhat.com/errata/RHEA-2007-0084.html
>The source RPM includes the official 2.2.12 tarball from Oct 2006 with 4
>additional patches.
>
>  
>
What are the patches?

I thought any changes like that were meant to be offered back to the 
project? (or maybe that have been)

--

-- 
Nick Gorham
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Radman | 18 May 2007 11:58
Favicon

RE: Segfault when utilizing libodbc with Asterisk

Here they are
Do they look familiar to you?

> -----Original Message-----
> From: unixodbc-dev-bounces <at> easysoft.com 
> [mailto:unixodbc-dev-bounces <at> easysoft.com] On Behalf Of Nick Gorham
> Sent: Friday, 18 May, 2007 11:43
> To: Development issues and topics for unixODBC
> Subject: Re: [unixODBC-dev] Segfault when utilizing libodbc 
> with Asterisk
> 
> Stefan Radman wrote:
> 
> >FYI
> >  
> >
> >>Ok, I don't know exactly how (or what) 2.2.12-1.el4s1 is, I 
> guess its 
> >>based on the 2.2.12 tree, but as I know people started 
> >>    
> >>
> >unixODBC-2.2.12-1.el4s1.1 is part of the CentOS WebStack of 
> the CentOS
> >Plus Repository
> >http://wiki.centos.org/Repositories/CentOSPlus
> >http://wiki.centos.org/Repositories/CentOSPlus/CentOSWebStack
> >http://isoredirect.centos.org/centos/4/centosplus/SRPMS/unixO
> DBC-2.2.12-
> >1.el4s1.1.src.rpm 
> >It seems to be identical with an RPM in the Red Hat Application Stack
(Continue reading)

Permalink | Reply | 1 comment |

Gmane