Message-ID: <4EDA5F21.1060901@gmail.com>
Date: Sat, 03 Dec 2011 18:40:49 +0100
From: marco atzeri <marco DOT atzeri AT gmail DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Understanding versions of apps in cygwin suite
References: <loom DOT 20111203T052154-912 AT post DOT gmane DOT org> <4ED9EF82 DOT 3030606 AT gmail DOT com> <loom DOT 20111203T160032-680 AT post DOT gmane DOT org>
In-Reply-To: <loom.20111203T160032-680@post.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 12/3/2011 4:26 PM, Andrew Hancock wrote:
> marco atzeri<marco.atzeri<at>  gmail.com>  writes:
>> On 12/3/2011 5:26 AM, Andrew Hancock wrote:
>>> According to
>>> http://savannah.gnu.org/bugs/?func=detailitem&item_id=30309 , a bug
>>> with octave's wavread function was fixed in octave 3.2.3.  My
>>> "cygcheck -cvs" shows an octave of 3.4.2, but I still get the bug.
>>> I was wondering if it is wise to assume that the app version number
>>> from cygcheck is the same as the version number from the gnu site?
>>
>> in general the cygwin packages are aligned with upstream versions,
>> eventually with additional patches.  Octave package 3.4.2-3 is
>> aligned with upstream 3.4.2.
>> http://cygwin.com/ml/cygwin-announce/2011-10/msg00001.html
>>
>> I guess you have some problem on your octave package, and you can
>> also check the version with:
>>
>> $ /usr/bin/octave --version
>> GNU Octave, version 3.4.2
>>
>> and on my system:
>>
>> octave:2>  Y = wavread("oddchunk.wav")
>>
>> is working fine as expected.  If you have problem with a different
>> example file, than please rise the problem on octave bug system or
>> send me by private mail your file, and I will check against the
>> development build.
>>
>> If your version is not 3.4.2-3, close all cygwin programs and
>> re-install octave.
>
> Thanks, Marco.  I posted on another thread asking whether it was wise to update
> Octave without updating the cygwin DLL.  Updating the cygwin DLL using Setup is
> actually downgrading, since I currently use a snapshot of the cygwin DLL to get
> around a problem with creating files/folders on a network drive (unrelated to
> Octave).

Andrew,
cygwin setup is not aware of any snapshot you can install manually,
as it compares the info from setup.ini (from website) with
the info stored on its database /etc/setup/installed.db

So if you have

$ cygcheck -c cygwin
Cygwin Package Information
Package              Version        Status
cygwin               1.7.9-1        OK

as 1.7.9-1 is the last released version, running setup again
to upgrade octave, will not replace your snapshot.

I am also running a snapshot as 1.7.9

$ uname -rv
1.7.10s(0.255/5/3) 20111129 17:41:48

for the reason reported on
http://cygwin.com/ml/cygwin-announce/2011-10/msg00001.html

>
> Since I am unclear about the interactions between the packages and the cygwin
> DLL, I have been trying to avoid updates to cygwin and packages until a new
> release.  However, I will do it if all other ways of poking and prodding a
> problem are exhausted.  One of the poking/prodding I want to do is check octave
> release notes.  I haven't been able to find an archive of release notes for
> various octave versions and subversions, but I did find the savannah bug
> tracking system.  It doesn't help determine the incremental changes from version
> 3.4.2-1 (what I have) and 3.4.2-3.  Finding your postings on the cygwin mailing
> list archive indicates that the changes are not related to wavread, but as you
> say, it might be my particular circumstance -- especially since the bug was
> apparently fixed in 3.2.3.
>
> I'll take you up on your offer to email you the file.  It is a 23KB file that is
> a truncation of drum beat track 428 available at
> http://www.instructables.com/id/Drum-Beats-in-Audacity.  Thanks.
>
>

It seems a different problem of the bug you thought about,
both the 3.4.2-3 and the latest development build do not recognize
the file format.

octave:2> Y = wavread("428shortMono.wav")
error: wavread: file contains no RIFF chunk
error: called from:
error:   /usr/share/octave/3.4.2/m/audio/wavread.m at line 74, column 5
octave:2> exit

octave:2> Y = wavread("428shortMono.wav")
error: wavread: file contains no RIFF chunk
error: called from:
error:   /pub/hg/octave_build/../octave/scripts/audio/wavread.m at line 
77, column 7

Please note that

$ file *.wav
428shortMono.wav: RIFF (big-endian) data, WAVE audio, mono 44100 Hz
oddchunk.wav:     RIFF (little-endian) data, WAVE audio, Microsoft PCM, 
16 bit, mono 1000 Hz

I am not sure that your file is compatible with octave expectation,
I suggest to rise the question on octave-help as I know nothing about
sound file format.

Regards
Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple