http://qa.mandrakesoft.com/show_bug.cgi?id=5767
------- Additional Comments From [EMAIL PROTECTED] 2003-23-09 01:33 ------- Gwenole or Damien, will this bug fix make it into 9.2? A broken vgetty would be disappointing, and I haven't seen anything for mgetty/vgetty show up in the changelogs yet, despite it being marked as 'applied'... Tx. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------- Reminder: ------- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: The voicemail/answering machine I have running, based on vgetty on my mandrake 9.0 system was suddenly broken by the last mandrake security update to mgetty/vgetty packages. Recording a voice message from the modem (a US Robotics in my case), suddenly started failing with a message saying "Illegal sample rate" : reading ring_type ring configuration from config file /etc/mgetty+sendfax/voice.conf 09/17 17:33:45 yS0 playing voice file /var/spool/voice/messages/standard.rmd 09/17 17:33:55 yS0 recording voice file /var/spool/voice/incoming/v-9144-1063784024.rmd 09/17 17:33:55 yS0 US Robotics: Illegal sample rate (1953456751) 09/17 17:33:55 yS0 vgetty: Illegal compression method 0x80664b3, speed 1953456751 09/17 17:33:55 yS0 vgetty: Could not record a message -- 09/17 17:33:55 yS0 vgetty: experimental test release 0.9.33 / 26Dec02 09/17 17:33:55 yS0 mgetty: experimental test release 1.1.30-Dec16 09/17 17:33:55 yS0 reading generic configuration from config file /etc/mget The last mgetty/vgetty release didn't backport the security patches, so mdk9.0 was forced to update from 1.1.28 to vgetty 1.1.30, but, after some digging, that wasn't the problem. I tracked the fault back to a change to 'record.c' in libvoice, where default arguments to set_compression are passed in without initialisation. In stock vgetty, the arguments are passed in as members of a structure (which has been initialised to all zeros), but Patch12 (mgetty-1.1.28-64bit-fixes.patch) replaces the actual structure members with new local variables, and then copies the results into the structure afterwards. This breaks because the local variables are not initialised (to zero) before set_compression is called. According to the changelog, this is a mandrake localisation: * Thu Nov 28 2002 Gwenole Beauchesne <[EMAIL PROTECTED]> 1.1.28-3mdk - Temporarily leave mgetty+sendfax data in %{_prefix}/lib, will likely have to be moved to %{_datadir}/mgetty+sendfax/ - Patch10: Welcome it to wonderful x86-64 world - Patch11: Add missing includes, not critical but saner - Patch12: Minor 64-bit fixes, probably better to fix set_compression() so there's no point me reporting this upstream - it needs to be fixed in the mgetty rpm build. Here's the one line change to the patch that fixed it for me: Patch for mgetty-1.1.28-64bit-fixes.patch: (needs refactoring, of course): *** mgetty-1.1.28-64bit-fixes.patch.old 2003-09-17 19:43:09.000000000 +1000 --- mgetty-1.1.28-64bit-fixes.patch 2003-09-17 19:43:27.000000000 +1000 *************** *** 4,10 **** int result; rmd_header header; int bits; ! + int compression, speed; lprintf(L_MESG, "recording voice file %s", name); --- 4,10 ---- int result; rmd_header header; int bits; ! + int compression=0, speed=0; lprintf(L_MESG, "recording voice file %s", name); I.E. just patch the patch to initialise the variables. This then 'works for me'. This certainly needs fixing for 9.2+, but I suspect it should really be re-issued as an errata for 9.0 & 9.1 as well, as it has killed functionality that was in the original release, and effectively prevents any voice applications based on vgetty (i.e. most of them) from working (at least for any of the hardware modules that rely on their parameters being initialised). Cris
