gtk-gnutella cannot connect to newer network - ancient version detected

Bug #248055 reported by Hew on 2008-07-13
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Hardy Backports
Wishlist
Unassigned
gtk-gnutella (Ubuntu)
High
Unassigned
Nominated for Dapper by Hew
Nominated for Feisty by Hew
Nominated for Gutsy by Hew
Nominated for Hardy by Hew

Bug Description

Binary package hint: gtk-gnutella

gtk-gnutella 0.96.4-2 in Hardy is outdated, as the latest version 0.96.5-1 in Intrepid is what is now required by the network. No doubt the same issue applies to Dapper, Feisty and Gutsy. Just like the resolved bug #6472 and bug #92160, gtk-gnutella reports to the user via a popup:

Ancient version detected
Warning
­This version of gtk-gnutella is pretty old. Please visit http://gtk-gnutella.sourceforge.net/ and update your copy of gtk-gnutella.

This is also displayed as an icon in the top-right corner.

Intrepid version (0.96.5-1) has been tested to work just fine, whereas Hardy version (0.96.4-2) cannot connect to any nodes. In practice, this means gtk-gnutella is useless without having the latest version.

WORKAROUND:
Grab the latest version of gtk-gnutella from Intrepid (0.96.5-1):
http://archive.ubuntu.com/ubuntu/pool/universe/g/gtk-gnutella/gtk-gnutella_0.96.5-1_amd64.deb
http://archive.ubuntu.com/ubuntu/pool/universe/g/gtk-gnutella/gtk-gnutella_0.96.5-1_i386.deb

SOLUTION:
Backport gtk-gnutella 0.96.5-1 from Intrepid in the form of a SRU.

Hew (hew) on 2008-07-13
Changed in gtk-gnutella:
importance: Undecided → High
status: New → Incomplete
Hew (hew) wrote :

I just installed Intrepid with gtk-gnutella 0.96.5-1 and on testing, it immediately connected to a bunch of nodes. I tried again using my Hardy install and a Hardy Live CD and both have the ancient version issue while incorrectly reporting that I am firewalled. gtk-gnutella is broken until it receives an update.

Changed in gtk-gnutella:
status: Incomplete → New
schiemanski (schiemanski) wrote :

I confirm this bug (hardy). I've got gtk-gnutella about 10 july by synaptic
This is what I get when I start up gtk-gnutella in terminal:
~$ gtk-gnutella
08-07-13 15:33:14 (MESSAGE): language code: "nl"
08-07-13 15:33:14 (MESSAGE): using locale character set "UTF-8"
08-07-13 15:33:14 (MESSAGE): primary filename character set "UTF-8"
08-07-13 15:33:14 (MESSAGE): gtk-gnutella/0.96.4-14059 (2007-07-07; GTK2; Linux i686)
08-07-13 15:33:14 (MESSAGE): D-BUS set up and ready for use.
08-07-13 15:33:14 (MESSAGE): Sent D-BUS signal 'Events': started
08-07-13 15:33:14 (WARNING): [hostile IP addresses (private)] unable to retrieve: no alternate locations known
08-07-13 15:33:14 (WARNING): iprange_sync(): 208.80.0.0/0xfff00000 overlaps with 208.80.8.0/0xfffff800
08-07-13 15:33:14 (WARNING): [SHA-1 cache] unable to retrieve: no alternate locations known
08-07-13 15:33:14 (WARNING): [Host Whitelist] unable to retrieve: no alternate locations known
08-07-13 15:33:15 (WARNING): version of gtk-gnutella is too old, you should upgrade!
08-07-13 15:33:16 (MESSAGE): Sent D-BUS signal 'PeermodeChange': leaf

Hew (hew) on 2008-07-13
description: updated
Changed in gtk-gnutella:
status: New → Triaged
lizardmenke (lizardmenke) wrote :

I just installed the .deb file from the intrepid download page: http://packages.ubuntu.com/intrepid/i386/gtk-gnutella/download
It seems to work fine in Hardy.

schiemanski (schiemanski) wrote :

Thanks, to install the .deb file from the intrepid downloadpage did it. Works fine now.
Temporary turn on the hardy backports en proposed, and after the install of gtk-gnutella turn it off again (and do not install updates)

chris_debian (cjhandrew) wrote :

This problem occurred with an earlier distro, and I seem to remember that by editing one of the config files, the client was still allowed to connect, even though it was ancient.

Anyone remember which file it was?

Thanks,

Chris.

The old "trick" won't work anymore because it is unnecessary since 0.96.4. Older versions wouldn't even start if they were too old. As of 0.96.4 you can use outdated versions for all eternity to your own and everyone else's disadvantage again. It will however not bootstrap - that is contact peer caches when its own cache is empty - any longer. Many or most of these peer caches have become defunct anyway since the last release as usual anyways.

If you don't remove your ~/.gtk-gnutella directory, it should be able to connect to the network just fine as usual. You should never remove your ~/.gtk-gnutella directory, especially not because of an update.
You can also always manually connect to other peers and therefore the network.

Regarding, "It also now says the client is firewalled". This is just the default assumption. As long as there are no incoming connections, gtk-gnutella has to assume it is "firewalled". gtk-gnutella has absolutely no knowledge whether you actually have any firewall activated. Thus, switching your firewall on and off won't be noticed by gtk-gnutella at all. The only thing that matters is whether there are incoming connections or not.

Now that doesn't mean you shouldn't update. You really should. However, old versions are neither banned nor defunct. After all a it just sits there like a web browser before you enter any URL. The only difference is that users seemingly expect it to connect on its own.

Luca Falavigna (dktrkranz) wrote :

Could you please state if packages in stable releases connect to servers or not?

Hew (hew) wrote :

gtk-gnutella 0.96.5-1 (Intrepid) DOES work.
gtk-gnutella 0.96.4-2 (Hardy) DOES NOT work.
Following this logic, I believe gtk-gnutella does not work in the other stable releases either.

Users here have confirmed that installing 0.96.5-1 on Hardy fixes the problem. This needs to be SRU/backported to at least Hardy.

Luca Falavigna (dktrkranz) wrote :

Thanks. If we can isolate a patch to have gtk-gnutella working properly on stable releases, it's a good SRU candidate.

Hew (hew) wrote :

I believe the reason that it currently doesn't work is due to it being the old version. Lying about the version is possibly a solution, but that's cheating imo (and bad for the network). It would be much better to introduce the new version as a SRU (at least for Hardy).

I understand that a small patch is desired to reduce the chance of regressions, but in this case, the existing version is itself the problem, and users have an application that is next to useless (hence the high priority). This problem is best solved as a backport in the form of a SRU.

Hew (hew) on 2008-08-04
description: updated
spacefight (spacefight) wrote :

Please speed up the deployment of a working package. I'm suffering from the very same problem as described. I have removed the host cache and since that, I can't reconnect to the network and as others have said, the client is useless. If this would be firefox and firefox would stop working, the fix would be out within hours or days, with this package, it takes weeks and still no fix out.

Thanks.

08-08-11 19:56:15 (MESSAGE): language code: "de"
08-08-11 19:56:15 (MESSAGE): using locale character set "UTF-8"
08-08-11 19:56:15 (MESSAGE): primary filename character set "UTF-8"
08-08-11 19:56:15 (MESSAGE): gtk-gnutella/0.96.4-14059 (2007-07-07; GTK2; Linux i686)
08-08-11 19:56:15 (MESSAGE): D-BUS set up and ready for use.
08-08-11 19:56:15 (MESSAGE): Sent D-BUS signal 'Events': started
08-08-11 19:56:15 (WARNING): [hostile IP addresses (private)] unable to retrieve: no alternate locations known
08-08-11 19:56:15 (WARNING): iprange_sync(): 208.80.0.0/0xfff00000 overlaps with 208.80.8.0/0xfffff800
08-08-11 19:56:15 (WARNING): [Host Whitelist] unable to retrieve: no alternate locations known
08-08-11 19:56:16 (WARNING): version of gtk-gnutella is too old, you should upgrade!
08-08-11 19:56:16 (MESSAGE): NTP detected at 127.0.0.1
08-08-11 19:56:16 (MESSAGE): detected NTP-3, stratum 0, offset -0.107430 secs
08-08-11 19:56:17 (MESSAGE): Sent D-BUS signal 'PeermodeChange': leaf

Here are two workarounds:

1. Just download the sources for gtk-gnutella 0.96.5 from SourceForge:
   https://sourceforge.net/project/platformdownload.php?group_id=4467

   Then compile it yourself following these simple instructions:
   https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella/README.Debian

2. If the above is too hard for you and you really don't know anyone else using
   Gnutella you could connect to, try connecting manually to this peer as long
   as it's still online:

   tls:yang.cloud.bishopston.net:53615

--
Christian

Hew (hew) wrote :

Just grab the package from the workaround section of the bug description for now (unofficial fix). I agree it's strange that this hasn't received proper attention; I'll see what I can do about it.

spacefight (spacefight) wrote :

The workaround deb from Intrepid isn't installing on 7.10, somewhat about lib6 being incompatible is popping up.

lizardmenke (lizardmenke) wrote :

You have to temporarily open proposed and backports for the intrepid .deb.
Then install the intrepid .deb and close proposed and backports again. Don't install updates with proposed and backports open!!

spacefight (spacefight) wrote :

I won't install anything at all. I will wait for the official fix. I thought this is the way Ubuntu and lots of other distros work. Patch if broken. In reasonable time.

Ben (ben2talk) wrote :

I'd love to believe that that's how they work. I have around a hundred thousand files here, each one with a hundred thousand lines of code - and I'm not actively recoding any one of them, so I hope that there are more than a hundred million Ubuntu coders out there working hard to do the work.

I can confirm that the Intrepid version works with Hardy - actually it makes a nice addition (I also have limewire and Frostwire ticking away) and put in a very nice performance once it managed to connect (and given the nature of my Thai managed apartment's free WiFi connection).

Hew (hew) wrote :

Please backport gtk-gnutella 0.96.5-1 from Intrepid to Hardy and Gutsy.

spacefight (spacefight) wrote :

A month has passed since this bug has been opened. Who is responsible for having this fixed?

Hew (hew) wrote :

motu-sru are responsible for providing the SRU. Normally a SRU is in the form of a small patch rather than being a new version of the package, which is why I believe it's taking a while to consider. I've been mentioning this bug in #ubuntu-motu the last couple of days to get it looked at, but progress is slow. I understand that this is a critical issue for gtk-gnutella users, so I've requested that the package be backported as this should be faster to implement.

spacefight (spacefight) wrote :

Three days passed, no action. Who is "moto-sur" and what means "SRU"? Yes, I play the dumb, because as a regular john-doe user, I simply want a working update in a timely manner.

Hello,

 My name is Cody Somerville and I'm a member of the MOTU-SRU Team. The acronym SRU stands for "Stable Release Update" which is the name for the procedure involved in updating a package in a stable release. My team, MOTU-SRU, is responsible for approving or denying requests made via said SRU procedure. You can find more information about Stable Release Updates by visiting http://wiki.ubuntu.com/StableReleaseUpdates

 As for this request, I spoke with Hew McLachlan last week. An entire new release of gtk-gnutella will not be approved for an SRU but I'd be happy to review a minimally invasive patch that would correct this issue if anyone is interested in providing one. I also recommended to Hew that he contact upstream to get their opinion on the issue.

 At the moment, pursuing a backport of the new version (as it appears some have begun) is the best course of action for those interested in this package until we figure out what to do for the SRU.

Cheers,

Cody Somerville

Hew (hew) wrote :

Taken from http://gtk-gnutella.sourceforge.net/en/?page=faq#gnet6 :
What does "Outdated version, please upgrade" mean?
Versions of gtk-gnutella more than one year old are banned, since they lack features that are important to the rapidly evolving gnet's health and scalability. In addition, unstable versions are banned after 90 days.

I've found that Debian stable does not include gtk-gnutella precisely for this reason, as expiring software such as this cannot be supported without major version upgrades. Backporting the software appears to be the only option. While I would classify this issue as a severe regression, it cannot be solved by a minimally invasive patch, and is therefore not a candidate for a SRU.

I am marking this bug as Won't Fix against Ubuntu for the reasons discussed above. The backport requests are still open, so the new version should be in backports soon.

Changed in gtk-gnutella:
status: Triaged → Won't Fix
spacefight (spacefight) wrote :

Thanks for all the insights Cody and Hew. Marking it as Won't Fix means it's broken and will not be fixed, right? Will backports be distributed over the software update mechanism as well?

From the page linked by Cody:

"Stable release updates will, in general, only be issued in order to fix high-impact bugs. Examples of such bugs include:

    * Bugs which may, under realistic circumstances, directly cause a security vulnerability. These are done by the security team and are documented at SecurityUpdateProcedures.
    * Bugs which represent severe regressions from the previous release of Ubuntu. This includes packages which are totally unusable, like being uninstallable or crashing on startup."

From a simple user point of view, gtk-gnutella is totally unusable if we consider the network connection establishing part of gtk-gnutella as part of its startup procedure. It isn't a regression from the previous version per se, it's worse.

I kindly ask you to reconsider.

ram (raphael-manfredi) wrote :

Hello,

I am part of the gtk-gnutella development team. I'd like to make a few points:

First, since 0.96.4, gtk-gnutella no longer prevents anyone from using an "old" version, You are simply reminded that you should upgrade as older versions are harmful to the network and 0.96.4 is REALLY old.

Secondly, it is not possible to provide a simple patch to make 0.96.4 work. I can send you a patch between 0.96.6 and 0.96.4 if you want though.

Lastly, I wonder what kind of release management it is to refuse to upgrade an application that, by nature, cannot work as distributed because it could introduce "instabilities"? Do you consider a program that does not work "stable"? I consider it "dead", which indeed is the most stable state you can find.

It shows that binary distribution is harmful, if anything, and that change control (a good practice, don't get me wrong) must be dealt with using 120% of your intellect instead of just following written procedures. We're talking about an application that cannot work in today's environment, and which is not a dependency source: nothing depends on gtk-gnutella in Debian, nothing should depend on it in Ubuntu as well. So tell me, what kind of harm can there be upgrading to a newer version?

For all users out there who want a working gtk-gnutella, the answer is easy. Install SVN, then do:

svn co https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella

Then follow the instructions in README.Debian, which should also apply to Ubuntu. The build should take minutes and then you'll be able to join the Gnutella network again.

This is dep-wait on libmicrohttpd4, and gnunet 0.80. Marking Incomplete.

Changed in hardy-backports:
importance: Undecided → Wishlist
status: New → Incomplete
Changed in gutsy-backports:
importance: Undecided → Wishlist
status: New → Incomplete

Michael Casadevall wrote:
> This is dep-wait on libmicrohttpd4, and gnunet 0.80. Marking Incomplete.

gtk-gnutella has nothing to do with those packages.

I was informed that this bug was fixed via SRU. I'm marking WONTFIX. If this is not the case, please reopen this bug.

Changed in hardy-backports:
status: Incomplete → Won't Fix
Changed in gutsy-backports:
status: Incomplete → Won't Fix
Hew (hew) wrote :

This is not the case, reopening. No updates to gtk-gnutella have been issued for any release.

Again, gtk-gnutella 0.96.5 is the minimum required to work with the rest of the network. While this isn't a problem for Intrepid users such as myself, I'm sure at least Hardy still has a need for the backport.

Changed in hardy-backports:
status: Won't Fix → New
Changed in gutsy-backports:
status: Won't Fix → New
Matt Joiner (anacrolix) wrote :

This is still broken in Hardy. Please update.

Hew (hew) wrote :

This should be a medium or high importance backport for Hardy.

Gabriel Rota (gabriel-rota) wrote :

prevu gtk-gnutella/intrepid
ls /var/cache/prevu/hardy-debs/gtk-gnutella_0.96.5-1build1~8.04prevu1_amd64.deb
sudo apt-get update
sudo apt-get install gtk-gnutella
gtk-gnutella
sudo apt-get remove gtk-gnutella
all ok

Changed in hardy-backports:
status: New → Confirmed
Wizarth (wizarth) wrote :

Confirming that using prevu to build a back-ported package works.

Would a patch that disables the out-"of-date version detection disables initial peer retrieval" (in the case of a new install) work?

Dimitri John Ledkov (xnox) wrote :

gutsy no longer supported =(

Changed in gutsy-backports:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions