Bug#578950: [Linphone-developers] bug+patch: Identifies with IP6 to IP4 hosts with dual AAAA/A DNS resource record
Hi Lionel, Thanks a lot for reporting with problem with much details. The patch does not apply to git tree, but no problem I made the change manually as it was trivial. So the bug should be fixed in next release. Best regards Simon Le lundi 26 avril 2010 à 21:33 +0200, Lionel Elie Mamane a écrit : > This is bug #578950 in the Debian bug tracker: > http://bugs.debian.org/578950 > > Please keep 578950-forwar...@bugs.debian.org, 578...@bugs.debian.org > and lio...@mamane.lu as CC in the discussion (M-F-T is set). > > When > > - the SIP server has both A and records in DNS > - linphone is configured to use IPv4, not IPv6 > > linphone speaks over IPv4 to the server, but puts an IPv6 address in > the SIP messages. This, at least in the case where Asterisk is the > server (and probably for other servers that don't implement IPv6) > makes calls not work. (registration works) > > The attached patch (against v3.2.1) fixes the issue. > > Analysis: > > Abstract from the debug log: > > linphonec> call 500 > ortp-message-Local interface to reach sip.mamane.lu is 2001:960:2:97::2. > > First sign of trouble: linphone identifies its own IP as an IPv6... > > ortp-message-getaddrinfo returned the following addresses: > ortp-message-94.142.241.136 port 5060 > ortp-message-Message sent: (to dest=94.142.241.136:5060) > > but OK, it still speaks to the server over IPv4 > > v=0 > o=lionel 123456 654321 IN IP6 2001:960:2:97::2 > s=A conversation > c=IN IP6 2001:960:2:97::2 > > the IP6 address there makes Asterisk balk. The Asterisk log says: > > WARNING[3678] chan_sip.c: Invalid host in c= line, 'IN IP6 2001:960:2:97::2' > > and it returns this message to Linphone: > > ortp-message-Received message: SIP/2.0 488 Not acceptable here > > ___ > Linphone-developers mailing list > linphone-develop...@nongnu.org > http://lists.nongnu.org/mailman/listinfo/linphone-developers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#480041: subversion: Breaks client certificate negotiation
Hello, Here is some more information: I downgraded subversion and libsvn1 to 1.4.2dfsg1-2 (this is the version availaible in debian-stable), and installed libneon26 and libneon26-gnutls (required by the 1.4.2dfsg1-2), and everything works well now. It is probable that the bug is not in subversion but rather in libneon27 or libneon27-gnutls. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480041: subversion: Breaks client certificate negotiation
Hi, Using neon backend, it fails with exactly with the same scenario as before (repeatly ask me the ssl certificate path). Using libserf (0.2.0-1) backend, it fails with this error: svn: Error running context: Appel système interrompu "Appel système interrompu"="Interrupted system call" Simon Le Wednesday 25 June 2008 02:42:30 Peter Samuelson, vous avez écrit : > [Dmitry Kurochkin] > > > Actually, error with serf backend is not the same: > > > svn update > > > > svn: Error running context: Internal error > > I hate to ask yet another round-trip of testing, but serf 0.2.0 was > recently uploaded to unstable. If you are still using serf 0.1.2, > could you upgrade and try again? The package name is 'libserf-0-0'. > Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#538945: I confirm this bug too.
Hello, I had this problem because after installing virtualbox-ose-additions, virtualbox gets automatically upgraded, but not virtualbox-ose-qt. After a manual upgrade of virtualbox-ose-qt, it worked. As you see you don't need to do obscure things to enter this failure state. Please add strong dependency rules between all virtualbox packages, this is the only way to have it working for everybody and anytime. Thanks, Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#359813: is it still possible to build an out of tree kernel module ?
Hello, I have exactly the same problem with make that does nothing. For me it's happening while trying to compile the pwc and spca5xx drivers. Seems the out-of-tree kernel module build system is broken for many drivers in this 2.6.16. I tried to compile my own kernel-source-2.6.16 using make-kpkg and exactly the same thing happened. Thanks for tracking this. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322415: libsdl1.2debian: IYUV blitting does not work
Hello, The bug has probably been fixed with SDL 1.29. I do not have it also. You can close it. Thanks, Simon Le Jeudi 2 Mars 2006 20:32, Sam Hocevar a écrit : > On Wed, Aug 10, 2005, Simon Morlat wrote: > > My favourite application using libSDL is unable to display correctly > > IYUV overlays. The colors are wrong and the shapes very approximative, > > sometimes it displays unidentified things. > > The problem is known, it occurs when compiling libSDL with nasm support. > >I no longer have the problem here. Could you please confirm the bug > is gone with the latest Debian libSDL? If it is not, please let me know > the colour depth you are running at. > > Regards,
Bug#357352: libavcodec-dev: missing libvorbisenc dependency in pkg-config (.pc) file.
Package: libavcodec-dev Version: 0.cvs20050918-6 Severity: normal Hello, /usr/lib/libavcodec.a references some symbols from libvorbisenc : nm /usr/lib/libavcodec.a |grep vorbis_encode_init t oggvorbis_encode_init U vorbis_encode_init U vorbis_encode_init_vbr nm /usr/lib/libvorbisenc.a |grep vorbis_encode_init 1c90 T vorbis_encode_init 1aa0 T vorbis_encode_init_vbr However the pkg-config (libavcodec.pc) file does not mention this dependency, breaking build of some packages using libavcodec-dev (such as linphone with video support). It does not break everything since the gcc linker optimizes and get rid of archive library object files not referenced by the main program, so the object including those vorbisenc dependency may or may not included to the final binary. Thanks for fixing this. Simon -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages libavcodec-dev depends on: ii liba52-0.7.4-dev [liba52- 0.7.4-1Development library and headers fo ii libdc1394-13-dev 1.1.0-3high level programming interface f ii libdts-dev0.0.2-svn-1development files for libdts ii libgsm1-dev 1.0.10-13 Development libraries for a GSM sp ii libogg-dev1.1.3-2Ogg Bitstream Library Development ii libraw1394-dev0.10.1-1.1 library for direct access to IEEE ii libtheora-dev 0.0.0.alpha5-1 The Theora Video Compression Codec ii libvorbis-dev 1.1.2-1The Vorbis General Audio Compressi ii zlib1g-dev1:1.2.3-9 compression library - development libavcodec-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361913: linphone: passwords stored world-readable
Hi, Any ideas on an api to store password in an encrypted manner ? The .gnome2/ tree is (as far as I understand) outdated since gconf is being used. I would prefer those password to be stored encrypted by linphone itself, since the linphone engine is independant from gnome/kde or whatever. Simon Le Mercredi 12 Avril 2006 01:11, Samuel Mimram a écrit : > Lionel Elie Mamane wrote: > > The accounts information, including CLEAR-TEXT passwords, is stored in > > $HOME/.gnome2/linphone, which is by default world-readable. It should > > be in $HOME/.gnome2_private/linphone (or any other path below > > $HOME/.gnome2_private/), where it will be safe, since > > $HOME/.gnome2_private/ is mode 0700. > > Argh. Thanks for noticing this. I'll try to come up with a patch soon. > > Cheersn > > Samuel.
Bug#361913: linphone: patch for "passwords stored world-readable"
Hello, Thanks a lot for the patch. It is merged in CVS. Simon Le Lundi 15 Mai 2006 00:41, Alec Berryman a écrit : > Package: linphone > Version: 1.3.3-1 > Followup-For: Bug #361913 > > Linphone also stores passwords in ~/.linphonerc. That file may have > been created group- or world-accessible because it was created with > fopen(), which uses the user's umask. See coreapi/lpconfig.c:211. Both > frontends use functions in coreapi/lpconfig.c to store configuration > information, and do not implement separate read/parse/write functions. > > Per console/linphonec.c:739, linphone appears to be migrating to use > ~/.linphonerc for both the console and GNOME client, so any discussion > of ~/.gnome2_private vs gconf is probably moot. Encrypting saved > passwords is also not a good option; see > http://gaim.sourceforge.net/plaintextpasswords.php for more > information. > > The GNOME client does not appear to be using ~/.linphonerc as of > 1.3.3-1; in gnome/linphone.c:344, the configuration file name is still > ~/.gnome2/linphone. > > I believe that the attached dpatch corrects the issue of world-readable > passwords. When the configuration file is to be written, the user's > umask is overridden so that the file will not be created group- or > world-accessible. Additionally, when parsing the configuration file on > startup, it will forcibly set permissions to 600. This may be too > heavy-handed and it might be more appropriate to stat() and possibly > emit a g_warning() to the user, but I thought it was better to require > no user intervention. > > The patch applies and compiles correctly (when docs are removed from the > build; see #365523). I have tested the GNOME frontend, and > ~/.gnome2/linphone is created correctly and is properly updated when it > already exists. > > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/dash > Kernel: Linux 2.6.16-alec-laptop > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > > Versions of packages linphone depends on: > ii libart-2.0-2 2.3.17-1 Library of functions for 2D > graphi ii libatk1.0-01.11.4-2 The ATK accessibility > toolkit ii libbonobo2-0 2.14.0-1 Bonobo CORBA > interfaces library ii libbonoboui2-0 2.14.0-2 The Bonobo > UI library ii libc6 2.3.6-7 GNU C Library: > Shared libraries ii libcairo2 1.0.4-2 The Cairo 2D > vector graphics libra ii libfontconfig1 2.3.2-5.1 generic > font configuration library ii libgconf2-42.14.0-1 > GNOME configuration database syste ii libglib2.0-0 2.10.2-2 > The GLib library of C routines ii libgnome-keyring0 0.4.9-1 > GNOME keyring services library ii libgnome2-02.14.1-2 > The GNOME 2 library - runtime file ii libgnomecanvas2-0 > 2.14.0-2 A powerful object-oriented display ii libgnomeui-0 > 2.14.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 > 2.14.1-2 GNOME virtual file-system (runtime ii libgtk2.0-0 > 2.8.17-2 The GTK+ graphical user interface ii libice6 >1:1.0.0-3 X11 Inter-Client Exchange library ii > liblinphone1 1.3.3-1 linphone web phone's library (supp > ii liborbit2 1:2.14.0-1libraries for ORBit2 - a CORBA > ORB ii libosip2-3 2.2.2-3 Session Initiation > Protocol (SIP) ii libpanel-applet2-0 2.14.1-1 library for > GNOME 2 panel applets ii libpango1.0-0 1.12.1-3 Layout > and rendering of internatio ii libpopt0 1.7-5 > lib for parsing cmdline parameters ii libsm6 1:1.0.0-4 > X11 Session Management library ii libx11-6 2:1.0.0-6 > X11 client-side library ii libxcursor11.1.5.2-5 X > cursor management library ii libxext6 1:1.0.0-4 X11 > miscellaneous extension librar ii libxi6 1:1.0.0-5 > X11 Input extension library ii libxinerama1 1:1.0.1-4 > X11 Xinerama extension library ii libxml22.6.24.dfsg-1 > GNOME XML library > ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library > ii libxrender11:0.9.0.2-4 X Rendering Extension client > libra ii linphone-nox 1.3.3-1 web phone > ii zlib1g 1:1.2.3-11compression library - runtime > > linphone recommends no packages. > > -- no debconf information
Bug#374791: ITP: ortp -- Real-time Transport Protocol library
Le mercredi 21 juin 2006 16:52, Mark Purcell a écrit : > On Wednesday 21 June 2006 21:15, Samuel Mimram wrote: > > I've already packaged the ortp library which comes with linphone and > > which is the same as the one packaged separately (Simon, can you confirm > > that?). See libortp4-dev. Therefore, I don't think that you need to do > > this package. > It's the same branch. The version packaged in linphone has been sometimes a little more in advance compared to ortp standalone source package, but I now wish to have them together: one release of linphone = one release of ortp. > Samuel, > > I am proposing to maintain this through pkg-voip maintainers, of which you > are a member... > > http://svn.debian.org/wsvn/pkg-voip > > You have commit rights to the svn archive, so please feel free to commit > changes as you think necessary.. Including the extended debian/changelog if > you have done some packaging work in the past.. > > Mark
Bug#332649: linphone: STUN support needed
Hello, I've started working on that. I think I'm going to use the 'mystun' client program to discover nat settings. However this program is not distributed by linux vendors, I think it is not also a mature code. So I will need to deliver it as an helper program for linphone: should I put it as /usr/lib/linphone/linphone-stunguess or /usr/libexec/linphone-stunguess, or simply /usr/bin/linphone-stunguess ? Simon Le Mardi 11 Octobre 2005 23:46, Samuel Mimram a écrit : > Erich Schubert wrote: > > Package: linphone > > Version: 1.1.0-2 > > Severity: normal > > > > Hi, > > Users behind firewalls often can't use linphone without STUN support. > > So this feature is really needed for some of them... For a friend of > > mine, linphone won't work, while kphone does just fine. This likely is > > due to missing STUN support in linphone. > > I agree, it would be a nice feature to have. Simon, is it doable quickly? > > Cheers, > > Samuel.
Bug#332646: linphone: Support for alsa "dmix" plugin
Within the config file you can add alsadev= within the [sound] section. I don't see why it should not work with the dmix plugin. Simon Le Mercredi 12 Octobre 2005 00:06, Samuel Mimram a écrit : > Erich Schubert wrote: > >>Simon, it would be nice if there was a simple way to change the alsa > >> device. > > > > There is an option for that in linphone. > > But it doesn't include the dmix virtual device. > > What I'm most concerned about is that linphone won't "ring" if e.g. my > > mp3 playing application is using the device. Having to stop my music > > before taking a call isn't bad, but not hearing the ring is... > > Yes, I meant a way to write down the alsa device to use. There might be > some obscure option in a configuration file but none I'm aware of. So > let's wait the answer for linphone's developper... > > Regards, > > Samuel.
Bug#333987: external linphone address book
Le Dimanche 16 Octobre 2005 16:13, Martin Samuelsson a écrit : > Samuel Mimram @ 2005-10-16 (Sunday), 13:46 (+0200) > > > To the best of my knowledge, there is no unified library for handling > > adress books (do you have in mind some prog which is able to handle them > > uniformly?). However, it should be doable with specific modules. In fact I know two good modules for that: gnome-evolution and kontact (kde). It would require however that those two software add the "sip phone address" field to their interface. The gtk interface of linphone is quite independant from both gnome and kde. I think it would be good that someone re-write from scratch a new interface compliant with one of gnome or kde standarts. (i would prefer kde). Unfortunately I have no time for that: I prefer stay focus on liblinphone (the core library, independant from interfaces). Simon > > I'm afraid my ideas are quite few at the moment. I'll try to find the > time looking at what's out there and if it can be reused. Expect a post > to this report when it happens. > > > Simon, one more item on your TODO-list :) > > Thanks for your great work, both of youse! > -- > /Martin
Bug#332646: linphone: Support for alsa "dmix" plugin
the dev_id should point to the alsa device (the numbering is made in the order linphone detects sound devices, first oss /dev/dsp, then alsa devices. The alsadev is a hack that applies to alsa detected cards only. So normally if your linphone already uses the alsa device, thus adding alsadev= should make it use your dmix plugin. If alsadev is unspecified, linphone opens 'plughw:,0' . However as you see I'm not a specialist of alsa configuration. Try to see alsa documentation. Simon Le Mercredi 19 Octobre 2005 11:04, Erich Schubert a écrit : > Hi, > > > Within the config file you can add > > alsadev= > > within the [sound] section. > > I only have > [sound] > dev_id=1 > playback_dev_id=1 > capture_dev_id=1 > > what is the dev_id for dmix? > I don't think dmix supports recording. maybe I could set it up that way, > though. > > best regards, > Erich Schubert
Bug#335304: udev doesn't load usbnet
Package: udev Version: 0.071-1 Severity: important Hello, If I have a good understanding of the situation, udev now provides its own hotplug scripts, that's the reason why it conflicts with the old hotplug package. However after upgrading to udev >0.070 the usbnet module that was automatically loaded by the old hotplug upon detection of my usb adsl modem is no more loaded by the new udev. I need to modprobe it manually. I had a look into udev 's packaged files and I could see any reference to usb drivers. So that now I even wonder if udev deals with hotplugging of usb devices. Should I use usbmgr instead ? (unfortunately it conflicts with udev). Please clarify. Thanks a lot. Simon -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 0 lrwxrwxrwx 1 root root 20 2005-06-10 14:10 020_permissions.rules -> ../permissions.rules lrwxrwxrwx 1 root root 19 2005-10-16 09:38 025_libgphoto2.rules -> ../libgphoto2.rules lrwxrwxrwx 1 root root 16 2005-10-16 09:38 025_libsane.rules -> ../libsane.rules lrwxrwxrwx 1 root root 12 2005-10-21 22:29 050_hal-plugdev.rules -> ../hal.rules lrwxrwxrwx 1 root root 19 2005-02-02 17:00 cd-aliases.rules -> ../cd-aliases.rules lrwxrwxrwx 1 root root 13 2005-02-02 17:00 udev.rules -> ../udev.rules lrwxrwxrwx 1 root root 19 2005-08-19 11:23 z20_persistent.rules -> ../persistent.rules lrwxrwxrwx 1 root root 12 2005-08-19 11:23 z50_run.rules -> ../run.rules lrwxrwxrwx 1 root root 16 2005-10-21 22:22 z55_hotplug.rules -> ../hotplug.rules lrwxrwxrwx 1 root root 19 2005-08-19 11:31 z60_alsa-utils.rules -> ../alsa-utils.rules lrwxrwxrwx 1 root root 15 2005-10-16 09:33 z60_hdparm.rules -> ../hdparm.rules lrwxrwxrwx 1 root root 17 2005-10-22 21:08 z60_usbmount.rules -> ../usbmount.rules lrwxrwxrwx 1 root root 17 2005-08-19 11:23 z70_hotplugd.rules -> ../hotplugd.rules -- /sys/: /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hda/hda4/dev /sys/block/hdc/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/class/input/event0/dev /sys/class/input/event1/dev /sys/class/input/mice/dev /sys/class/input/mouse0/dev /sys/class/misc/agpgart/dev /sys/class/misc/apm_bios/dev /sys/class/misc/device-mapper/dev /sys/class/misc/hw_random/dev /sys/class/misc/psaux/dev /sys/class/printer/lp0/dev /sys/class/sound/adsp/dev /sys/class/sound/audio/dev /sys/class/sound/controlC0/dev /sys/class/sound/dmmidi/dev /sys/class/sound/dsp/dev /sys/class/sound/midiC0D0/dev /sys/class/sound/midi/dev /sys/class/sound/mixer/dev /sys/class/sound/pcmC0D0c/dev /sys/class/sound/pcmC0D0p/dev /sys/class/sound/pcmC0D1p/dev /sys/class/sound/timer/dev -- Kernel configuration: -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages udev depends on: ii initscripts 2.86.ds1-4 Standard scripts needed for bootin ii libc6 2.3.5-7GNU C Library: Shared libraries an ii libselinux1 1.26-1 SELinux shared libraries ii libsepol1 1.8-1 Security Enhanced Linux policy lib ii lsb-base 3.0-10 Linux Standard Base 3.0 init scrip ii makedev 2.3.1-78 creates device files in /dev ii sed 4.1.4-4The GNU sed stream editor udev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335304: udev doesn't load usbnet
Here's attached the /dev/hotplug.log.
There are lots of usb related logs, none of them talks about usbnet.
After booting:
/sbin/lsmod |grep usb
usbcore 122300 2 uhci_hcd
The thing I don't understand is how udev makes the relationship between
devices's usb ids and the modules to load. The table is in the kernel maybe ?
Thanks
Simon
Le Dimanche 23 Octobre 2005 11:54, Marco d'Itri a écrit :
> tag 335304 unreproducible moreinfo
> thanks
>
> On Oct 23, Simon Morlat <[EMAIL PROTECTED]> wrote:
> > I had a look into udev 's packaged files and I could see any reference
> > to usb drivers.
>
> Drivers are loaded by this rule in /etc/udev/rules.d/z55_hotplug.rules:
>
> # load the drivers
> ENV{MODALIAS}=="?*",RUN+="/sbin/modprobe $env{MODALIAS}"
>
> Please generate an events log by uncommenting the logger.agent rule in
> the same file, reboot and then check /dev/hotplug.log.
>
> > So that now I even wonder if udev deals with hotplugging of usb devices.
>
> It does.
>
> > Should I use usbmgr instead ? (unfortunately it conflicts with udev).
>
> No, it's crap.
hotplug.log.bz2
Description: BZip2 compressed data
Bug#333423: linphonec doesn't like Ctrl-D
Thanks a lot.
I 've merged it into cvs.
Simon
Le Jeudi 20 Octobre 2005 17:17, wieseltux23 a écrit :
> if(fgets (input, LINE_MAX_LEN-1, stdin))
>
> >+ {
> >+ run=linphonec_parse_command_line(&linphonec,input);
> >+ printf("linphonec> ");fflush(stdout);
> >+ }
> >+ else
> >+ run=FALSE;
Bug#335304: udev doesn't load usbnet
> > Yes, the table is in the drivers themselves. Great. The best place for that. > See the 'modalias' file in > the usb device directory for what should be passed to modprobe to load > the proper driver. Unfortunatly, this is a kernel bug, we didn't get > some of these aliases in the usb devices correct. Thanks for your investigation. Waiting for linux-source-2.6.13... > > thanks, > > greg k-h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321064: Clearing of passwords does not happen
Hello, For now I have no idea. I'll try reproduce the bug with valgrind. Simon Le Vendredi 5 Août 2005 13:05, Martin Samuelsson a écrit : > Samuel Mimram @ 2005-08-04 (Thursday), 19:12 (+0200) > > > >In the preferences dialog under the SIP tab there is a button to: > > >"Clear all stored authentication information" > > >However, when using it nothing happens. All information is still present > > >in ~/.gnome2/linphone > > >Clicking the same dialog twice results in a crash. > > > > Thanks for the report. I did not manage to make linphone crash by > > clicking twice. Could you give me a gdb stack trace? > > I'm providing one below. Although I don't know if it has enough > information. Please let me know if there's anything else I should do. > > Thanks, > > (gdb) r > Starting program: /usr/bin/linphone > [Thread debugging using libthread_db enabled] > [New Thread -1223708544 (LWP 6739)] > [New Thread -1227625552 (LWP 6749)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1223708544 (LWP 6739)] > 0xb75cdd89 in free () from /lib/tls/libc.so.6 > (gdb) bt full > #0 0xb75cdd89 in free () from /lib/tls/libc.so.6 > No symbol table info available. > #1 0xb7731ac4 in g_free () from /usr/lib/libglib-2.0.so.0 > No symbol table info available. > #2 0xb76c43d8 in linphone_auth_info_destroy (obj=0x81dd700) at > authentication.c:63 No locals. > #3 0xb76c498a in linphone_core_clear_all_auth_info (lc=0x8068bc0) at > authentication.c:184 info = (LinphoneAuthInfo *) 0xfff9 > elem = (GList *) 0x8122748 > i = 1 > #4 0xb79412a6 in g_cclosure_marshal_VOID__VOID () from > /usr/lib/libgobject-2.0.so.0 No symbol table info available. > #5 0xb792f736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #6 0xb7940dcf in g_signal_emit_by_name () from > /usr/lib/libgobject-2.0.so.0 No symbol table info available. > #7 0xb793fe9c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #8 0xb7940126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #9 0xb7ab5af5 in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0 > No symbol table info available. > #10 0xb7ab697a in _gtk_button_paint () from /usr/lib/libgtk-x11-2.0.so.0 > No symbol table info available. > #11 0xb79412a6 in g_cclosure_marshal_VOID__VOID () from > /usr/lib/libgobject-2.0.so.0 No symbol table info available. > #12 0xb792f9c9 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #13 0xb792f736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #14 0xb7940651 in g_signal_emit_by_name () from > /usr/lib/libgobject-2.0.so.0 No symbol table info available. > #15 0xb793fe9c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #16 0xb7940126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #17 0xb7ab5a65 in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0 > No symbol table info available. > #18 0xb7ab6823 in _gtk_button_paint () from /usr/lib/libgtk-x11-2.0.so.0 > No symbol table info available. > #19 0xb7b7c47e in _gtk_marshal_BOOLEAN__BOXED () from > /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. > #20 0xb792f9c9 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #21 0xb792f736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #22 0xb7940855 in g_signal_emit_by_name () from > /usr/lib/libgobject-2.0.so.0 No symbol table info available. > #23 0xb793fc8c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #24 0xb7940126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > No symbol table info available. > #25 0xb7c6bcf7 in gtk_widget_send_expose () from > /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. > #26 0xb7b7af92 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 > No symbol table info available. > #27 0xb7b79de6 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 > No symbol table info available. > #28 0xb7a188e5 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 > No symbol table info available. > #29 0xb772b5c2 in g_main_depth () from /usr/lib/libglib-2.0.so.0 > No symbol table info available. > #30 0xb772c638 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 > No symbol table info available. > #31 0xb772c970 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 > No symbol table info available. > #32 0xb772cf13 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 > No symbol table info available. > #33 0xb7b79693 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > No symbol table info available. > #34 0x08050c6a in main (argc=0, argv=0x0) at main.c:65 > p = (void *) 0xfff9 > (gdb)
Bug#322695: linphone -- alsa_card_write: assertion failed
Hello, This problems usually happens when linphone fails to open the alsa device in one direction, in this case this is in write direction (playing sounds). This can happen it another program opens the alsa audio device in writing mode just before linphone wants to use it: maybe esd does that. Can you reproduce the problem with esd off ? Simon Le Vendredi 12 Août 2005 22:08, Samuel Mimram a écrit : > Hi, > > Filip Van Raemdonck wrote: > > Package: linphone > > Version: 1.0.1-5 > > Severity: important > > > > Linphone installed on a testing system, with selected packages from > > unstable. System is on NAT behind a sarge-based firewall with static > > public IP; option about NAT has been set in linphone. > > > > I have setup a SIPphone account in linphone, settings are correct (I've > > set it up the same a system in a different location and it works fine > > there). > > When I try to call e.g. the SIPphone test number at > > sip:[EMAIL PROTECTED] the connection is established, but > > then the terminal from which linphone was started is flooded with this > > message: > > > > (linphone:15778): MediaStreamer-CRITICAL **: alsa_card_write: assertion > > `obj->write_handle!=NULL' failed > > > > and no sound is played. > > > > Linphone is set to use alsa, sound does work when I listen to the > > ringing sound in preferences. DE is GNOME with esd running. > > Thanks for reporting. There are a few things I'd like to check here. > > * Have you tried with oss (if you have oss emulation with alsa)? > * Have you tried to call sipomatic (launch the sipomatic program and > call sip:[EMAIL PROTECTED]:5064)? > * Could you send me the output of linphone --verbose when calling? > > Regards, > > Sam.
Bug#322695: linphone -- alsa_card_write: assertion failed
Can't it be a sound that is being play while pressing a gtk button or something like this ? Simon Le Jeudi 25 Août 2005 11:05, Filip Van Raemdonck a écrit : > Hi all, > > On Wed, Aug 24, 2005 at 10:58:19PM +0200, Simon Morlat wrote: > > This problems usually happens when linphone fails to open the alsa device > > in one direction, in this case this is in write direction (playing > > sounds). This can happen it another program opens the alsa audio device > > in writing mode just before linphone wants to use it: maybe esd does > > that. > > Can you reproduce the problem with esd off ? > > No I can't, esd seems to be the culprit indeed. > > However, while it could be that esd indeed tries to open just before > linphone, this (naive assumption ;) appears not all too likely as there is > no other sound playing at that time. Don't know how esd handles the audio > device, though. > > > > Filip Van Raemdonck wrote: > > > > When I try to call e.g. the SIPphone test number at > > > > sip:[EMAIL PROTECTED] the connection is established, > > > > but then the terminal from which linphone was started is flooded with > > > > this message: > > > > > > > > (linphone:15778): MediaStreamer-CRITICAL **: alsa_card_write: > > > > assertion `obj->write_handle!=NULL' failed > > > > > > > > and no sound is played. > > Regards, > > Filip
Bug#321064: Clearing of passwords does not happen
Hello, Great investigation ! In the 1.1.0 release I use the bug was fixed (I did not remember), that 's why it could not happen, even with valgrind. Thanks Simon Le Jeudi 25 Août 2005 16:18, Martin Samuelsson a écrit : > Simon Morlat @ 2005-08-24 (Wednesday), 23:27 (+0200) > > > Hello, > > Hi there, > > > For now I have no idea. I'll try reproduce the bug with valgrind. > > That's an idea I never though of, and silly enough it still chrashes for > me when running it through valgrind. :/ > > I'm not an total expert on valgrind either, but my expection was that a > memory access error shouldn't result in a chrash... > > Spending a few minutes actually stepping through with gdb made me find > something suspicious. Applying the attached patch fixes the problem for > me, but I guess it's time to do an audit if more things are coded the > way that they assume g_list_free() should NULL the pointer. > -- > /Martin
Bug#327457: PL: Incorrect use of unicode?
Ok it's done for next 1.2.0 release. Simon Le Samedi 10 Septembre 2005 22:59, Samuel Mimram a écrit : > Hi, > > teodozjan wrote: > > Package: linphone > > Version: 1.1.0-1 > > Severity: minor > > > > Translation uses unicode chars. Looks awful > > (weird symbols - unicode encoding without unicode font). > > Chars in menu displayer correctly. > > > > Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) > > You seem to be right : the pl.po file contains "charset=iso-8859-1" but > the messages are coded in utf8. The obvious fix is to change this to > "charset=UTF-8". Simon, can you do this? > > Thanks for reporting. > > Regards, > > Samuel.
Bug#322415: libsdl1.2debian: IYUV blitting does not work
Package: libsdl1.2debian Version: 1.2.7+1.2.8cvs20041007-5.3 Severity: important Hello, My favourite application using libSDL is unable to display correctly IYUV overlays. The colors are wrong and the shapes very approximative, sometimes it displays unidentified things. The problem is known, it occurs when compiling libSDL with nasm support. Please see: http://www.devolution.com/pipermail/sdl/2005-April/068463.html Despite I do not use fbdev; I have the problem. I've verified that when compiling my own libsdl with --disable-nasm, the yuv blitting works perfectly. You can reproduce the problem with SDL's own test programs (the one in the test subdir) ../testoverlay2 -format IYUV Not using nasm seems only to decrease performance when using software blitting (hardware blitting is unaffected). I think it is acceptable to recompile a SDL without nasm waiting for this bug to be fixed by authors. It would make some SDL based application to work. Thanks Simon -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-fm Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages libsdl1.2debian depends on: ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-5.3 Simple DirectMedia Layer (with all libsdl1.2debian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#189399: kernel oops with i810
Hi, You can close it. I think it has disapeared since kernel-2.6 Simon Le samedi 13 janvier 2007 23:07, Brice Goglin a écrit : > Hi, > > About 4 years ago, you reported a bug to the Debian BTS regarding a > kernel oops (probably fixed in 2.4.21 or soon after) and the display > disappearing with the i810 X driver. Did you reproduce this problem > recently? If not, I will close this bug in the next weeks. > > Thanks, > Brice
