After compiling the latest version of wvstreams (4.3-r2) and then running revdep-rebuild (which recompiled wvdial(1.56) to fix broken deps), gnome-ppp stopped detecting the modem connection state. Although it establishes the connection properly, its User-Interface fails to detect that the connection is successful. Hence it keeps on showing the same window with the message "Connecting....". A fix which works on my machine is attached herewith. Reproducible: Always Steps to Reproduce: 1.Start gnome-ppp 2.Click on the connect button. 3. Actual Results: The "Connecting..." window appears and never goes away. Expected Results: The window should hide and should appear in the Notification area emerge --info: Portage 2.1.2.7 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.4-r4, 2.6.19-gentoo-r5 i686) ================================================================= System uname: 2.6.19-gentoo-r5 i686 Intel(R) Pentium(R) M processor 1.73GHz Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 28 May 2007 06:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium-m -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--progress" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 acl acpi aiglx alsa berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups dbus directfb dri dvd dvdr dvdread emboss encode esd evo fam fbcon firefox gdbm gif gnome gpm gstreamer gtk hal iconv isdnlog jpeg kerberos libg++ mad midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcmcia pcre pdf perl png pppd python qt3support quicktime readline real reflection sdl session spell spl ssl svg tcpd tiff truetype truetype-fonts type1-fonts usb vcd vorbis wifi win32codecs x86 xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="i810 vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Created attachment 120680 [details, diff] patch for fixing the "Connecting...." problem
Created attachment 120682 [details] ebuild to include the patch This is the ebuild for including the patch submitted earlier
Not maintained by gnome.
Have you contacted upstream author? This patch should be applied upstream as well.
(In reply to comment #4) > Have you contacted upstream author? This patch should be applied upstream as > well. > No I haven't. Could not trace him. The home-page links on packages.gentoo.org don't work.
OK. I found his email address on GNOME PPP page on gnomefiles.org and sent him an email. This project has not made any release for two years, I don't know whether he keeps maintaining the project any more. I'll apply the patch next week (and fix HOMEPAGE as well) if he does not reply. Please remind me if you see no action on this bug after a week ;)
I've taken a look at the patch: if this change in output string of the wvdial is made by the wvdial developers and not the gentoo patch developers than this patch just might do the work; but the best things to do is make a condition to build system, so that the new (or old) line of code is used depending on the wvdial version detected. Hope I'm not late...
(In reply to comment #7) > I've taken a look at the patch: if this change in output string of the wvdial > is made by the wvdial developers and not the gentoo patch developers than this > patch just might do the work; but the best things to do is make a condition to > build system, so that the new (or old) line of code is used depending on the > wvdial version detected. Hope I'm not late... > Well. I don't think it is wvdial. It is still at version 1.56. Rather the culprit seems to be wvstreams. wvstreams-4.2.2-r2 worked fine. Upgrading to wvstreams-4.3-r2 broke things. I don't know how will we detect the installed version of wvstreams from within the code of gnome-ppp. If I am not wrong, the patch will work even with older version of wvstreams. Since we are just doing a string search. Although I am not sure what else it might break. :)
(In reply to comment #7) > I've taken a look at the patch: if this change in output string of the wvdial > is made by the wvdial developers and not the gentoo patch developers than this > patch just might do the work; but the best things to do is make a condition to > build system, so that the new (or old) line of code is used depending on the > wvdial version detected. Hope I'm not late... > I've had a look at Gentoo patches applied to wvstreams (both versions). Nothing seems related to the bug. However I encountered this code in wvdial.cc (wvdial-1.56): void WvDialLogger::_make_prefix() /*******************************/ { WvString name = last_source; if(name == "WvDial Modem") { prefix = ""; prelen = 0; } else { prefix = "--> "; prelen = 4; } } It might be the cause but I did not track how _make_prefix was used though.
(In reply to comment #9) > (In reply to comment #7) > > I've taken a look at the patch: if this change in output string of the wvdial > > is made by the wvdial developers and not the gentoo patch developers than this > > patch just might do the work; but the best things to do is make a condition to > > build system, so that the new (or old) line of code is used depending on the > > wvdial version detected. Hope I'm not late... > > > > I've had a look at Gentoo patches applied to wvstreams (both versions). Nothing > seems related to the bug. However I encountered this code in wvdial.cc > (wvdial-1.56): > > void WvDialLogger::_make_prefix() > /*******************************/ > { > WvString name = last_source; > if(name == "WvDial Modem") > { > prefix = ""; > prelen = 0; > } > else > { > prefix = "--> "; > prelen = 4; > } > } > > It might be the cause but I did not track how _make_prefix was used though. > I compiled wvdial after changing the above function such that both "if" "else" cases become the same. Still there was no change in the log output. wvdial still omits "--> ". Pretty confusing. I tried downgrading to wvstreams-4.2.2-r2 but can't do that. It fails to compile with gcc-4.1.2. Did you get any response from the author? There isn't any other decent GTK2 dialer. :(
(In reply to comment #10) > I compiled wvdial after changing the above function such that both "if" "else" > cases become the same. Still there was no change in the log output. wvdial > still omits "--> ". Pretty confusing. :( It's too bad I don't have a dialup connection here to test those > > I tried downgrading to wvstreams-4.2.2-r2 but can't do that. It fails to > compile with gcc-4.1.2. Did you get any response from the author? There isn't > any other decent GTK2 dialer. :( > Vladimir Djokic is the author ;)
(In reply to comment #11) > (In reply to comment #10) > > I compiled wvdial after changing the above function such that both "if" "else" > > cases become the same. Still there was no change in the log output. wvdial > > still omits "--> ". Pretty confusing. > > :( It's too bad I don't have a dialup connection here to test those > > > > > I tried downgrading to wvstreams-4.2.2-r2 but can't do that. It fails to > > compile with gcc-4.1.2. Did you get any response from the author? There isn't > > any other decent GTK2 dialer. :( > > > Vladimir Djokic is the author ;) > Well, when we have the author, I think I should just shut up!! ;) The fix that I had submitted may not work always. This might be because the change that I discovered in wvdial output may not be the only change. For example, the icon in "notification area" doesn't go away even after disconnecting. Also, the .xsession-errors file contains: "GNOME PPP: Unable to KILL wvdial process!" I guess Vladimir is the best person to fix this. I hope he is still maintaining it.
Created attachment 124152 [details, diff] patch fix incorrect handle of new wvdial events (i.e. wvdial-1.56) patch for full fix the "Connecting...." and related notifying problem between gnome-ppp and new wvdial. It is also correct behaviour for 'connected' window. With this patch 'connected' window normal hide when user close it.
(In reply to comment #13) > Created an attachment (id=124152) [edit] > patch fix incorrect handle of new wvdial events (i.e. wvdial-1.56) > > patch for full fix the "Connecting...." and related notifying problem between > gnome-ppp and new wvdial. It is also correct behaviour for 'connected' window. > With this patch 'connected' window normal hide when user close it. > I tested it with wvdial-1.56. It appears to work properly. I could not test it with older versions of wvdial though.
Fixed in -r1. Thanks!
