[hardy] Request of update of aMule to 2.2.2 final release

Bug #244670 reported by Kevin on 2008-07-01
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
amule (Ubuntu)
Wishlist
Unassigned
Hardy
Undecided
Unassigned

Bug Description

The current version of aMule in Ubuntu 8.04 LTS is not a stable version (2.2.0~svn20080218-0ubuntu4, it is a svn snapshot). Yet at the time was more stable than 2.1.3 so it was included.

Please, read: http://www.amule.org/amule/index.php?topic=15834.0

Now it has published the final version 2.2.2 that can be considered stable.

The main reasons why I am requesting that the upgrade program are as follows:

* High importance:

- Version 2.2.2 has several changes were made to Kad in order to defy routing attacks.

- The extended version of the Kademlia network, Kad2, wasn't complete in the svn ubuntu has. That was Bad (tm), to the extent of damaging the network, especially when dealing with firewalled users, but also when indexing files >4GB. that's serious, from the network perspective. (from Kry, aMule dev)

- Also the new network code reinforces the security of the network about attacks to its nodes, and it's important not to have old clients around. (from Kry, aMule dev)

- In the connection process amulegui exchanges some information with the target, including some 'protocol version'. If the client and server don't agree on this number the connection is rejected. The number interchanged is different in the SVN version. In the function ExternalConn::Authenticate it states that

  // For release versions, we don't want to allow connections from any arbitrary SVN client.

It seems that a SVN version gui cannot communicate with a 'release' version daemon. (bug #206648)

* Medium importance:

- It solves many problems of stability of svn that caused unexpected falls.
    + (bug #230015/comments/3)
    + Also bug #230015, bug #213586, bug #207178
    + in 2.2.2: bug #242220

* Low importance:

- Copy ED2K link to clipboard works strange (bug #244670)
- aMule makes bad hashlinks (ed2k://) (bug #94231)
- amule have by default konqueror browser in ubuntu (bug #209810)
- Shared files priority don't get updated on amulegui
- 100% of CPU used by amuleweb
- broken log view
- disable upnp in preferences if library loading fails

Possible bugs to be solved:

  - bug #234422, bug #214100, bug #260078, bug #228704, bug #219671, bug #175284, bug #106009
  - in 2.2.2: bug #210554

Old reasons (Not so Disabled):

  * This release could be considered a bugfix release since most of the new features of aMule 2.2.1 are already included in the latest svn. Indeed! Some features are incomplete in the svn snapshot
  * Version 2.2.2, to be an official launch, can be reported hypothetical errors in the program. A snapshot is svn, from the standpoint of developers, a lot of provisional code and that is no longer present at the launch stable.
  * Ubuntu 8.04 is a LTS release so it will be in use at least 3 years for desktops. I do not think it good maintain a snapshot svn for 3 years since "svn snapshot" is not synonymous of stability.
  * At least in the forum of aMule have been reported numerous problems with the svn snapshot where developers can only advise compile a stable version or an svn latest snapshot. The end user should avoid the process of compiling whenever possible.

Some of these problems are in https://bugs.launchpad.net/ubuntu/+source/amule/+bug/230015/comments/3

And these are just one example (if I am put a full list would be too large).

I do not say that 2.2.2 is a "panacea" but at least is a stable version. I am using self since he left and it seems to be more stable than version repositories

Changed in amule:
assignee: nobody → festor90
status: New → In Progress
description: updated
Changed in amule:
assignee: festor90 → motu-sru
status: In Progress → Confirmed

It is not easy to separate between a svn bugs and the final, but I can say that many people who updated the end had no problems with the svn

What bugs are filed in Launchpad that don't happen with the final. Unless you
can point to SRU worthy bugs, this won't get updated.

Bugs:
https://bugs.launchpad.net/ubuntu/+source/amule/+bug/94231
https://bugs.launchpad.net/ubuntu/+source/amule/+bug/187041
https://bugs.launchpad.net/ubuntu/+source/amule/+bug/209810

* From Mantis Bug Tracker:
    - Fixed 0001313: broken log view
    - Fixed 0001296: 100% of CPU used by amuleweb
    - Fixed 0001289: amule fails to build on non glibc systems (e.g. uclibc)
    - Fixed 0001267: Shared files priority don't get updated on amulegui
    - Fixed 0001266: aMule SVN fails when enabling GeoIP with LDFLAGS="--as-needed" [PATCH]
    - Other minor fixes

Of https://bugs.launchpad.net/ubuntu/+source/amule/+bug/234807

-> Network protocol updated to eMule 0.49a (svn of hardy have an incomplete implementation)

I'm looking for bugs fixed

This:

* From Mantis Bug Tracker:
    - Fixed 0001313: broken log view
    - Fixed 0001296: 100% of CPU used by amuleweb
    - Fixed 0001289: amule fails to build on non glibc systems (e.g. uclibc)
    - Fixed 0001267: Shared files priority don't get updated on amulegui
    - Fixed 0001266: aMule SVN fails when enabling GeoIP with LDFLAGS="--as-needed" [PATCH]
    - Other minor fixes

Only until May 25

hardy -> 18 feb
2.2.1 -> June 11,

working in the main post

description: updated
description: updated
description: updated
description: updated
description: updated

Here is my package based on recent sync with Debian (diff.gz taken from aMule 2.2.1 Intrepid)

amule (2.2.1-1ubuntu1) hardy; urgency=low

  * New upstream release for Hardy
    - Completed implementation of the Kademlia network (Kad 2.0)
    - The new network code reinforces the security of the network
      about attacks to its nodes.
    - Fixed "amulegui does not start in Hardy Heron" (LP: #206648)
      because a SVN version gui cannot communicate with a 'release'
      version daemon.
    - It solves many problems of stability of svn that caused unexpected falls.
      (LP: #230015) (LP: #213586) (LP: #207178)
    - Others fixes: (LP: #244670) (LP: #94231) (LP: #209810)
      -From Mantis Bug Tracker
      +Shared files priority don't get updated on amulegui
      +100% of CPU used by amuleweb
      +broken log view
      +disable upnp in preferences if library loading fails
  * debian/control
   - Changed libupnp3 for libupnp2

 -- Festor Wailon Dacoba <email address hidden> Wed, 02 Jul 2008 08:11:32 +0200

I think that is enough for now. If you need more information (specific) let me know and I will try to look

I have a PPA with aMule 2.2.1 for Intrepid, Hardy and Gutsy:

https://launchpad.net/~festor90/+archive

Scott Kitterman (kitterman) wrote :

SInce intrepid has 2.2.1-1ubuntu1, hardy cannot have the same version. It should be 2.2.1-1ubuntu0.1. I'd appreciate it if you'd delete the Hardy PPA package and then re-upload it as 2.2.1-1ubuntu0.1~ppa1 so that if we can get this published, users who install from the PPA will upgrade to the official package.

Are there any changes needed to the version in Intrepid to make it work in Hardy?

Scott Kitterman (kitterman) wrote :

Please subscribe, not assign motu-sru (I've fixed).

Changed in amule:
assignee: motu-sru → nobody

2008/7/2 Scott Kitterman <email address hidden>:

> SInce intrepid has 2.2.1-1ubuntu1, hardy cannot have the same version.
> It should be 2.2.1-1ubuntu0.1. I'd appreciate it if you'd delete the
> Hardy PPA package and then re-upload it as 2.2.1-1ubuntu0.1~ppa1 so that
> if we can get this published, users who install from the PPA will
> upgrade to the official package.
>

Give me a few minutes and I'll do

> Are there any changes needed to the version in Intrepid to make it work
> in Hardy?

Only

 * debian/control
   - Changed libupnp3 for libupnp2

NEWS!!...

I received an e-mail of upstream:

"Hey, it's best not to upload the 2.2.1, and put it on hold waiting for 2.2.2, which will be out next week as much as possible.

Believe me, is a serious reason. You can put in upstream bug that you have been asked to wait for this new version until next week by a security patch that is not yet available."

Can you wait a few more days?

Yes. But this highlights why we don't like complete new upstream updates.
I really would like to know how I can be confident regression testing is
well done and complete.

This is the thing: the hint I gave Festor about the upstream release is unrelated to regression testing or similar. It is actually a new security problem that needs to be patched - upstream is waiting for a concurrent eMule release (or their beta) before releasing a new version. Releasing 2.2.1, or keeping the current one would keep the same vulnerability that would have to be patched.

It can be easily applied as a patch over this release instead if that's what you prefer - it's been out for a month with no important reports, and I can probably package a couple of important patches (well tested ones) from this last month. But I think this duplicated effort can easily be avoided by waiting till our actual release.

You tell me what you prefer, really.

Festor, I tried your amule package from the PPA. It works well, but I want to report a little thing, in case this will be backported to Ubuntu, don't know if it was present also in the official Ubuntu version. The check to search new versions during startup should be disabled and the option should be greyed out, since the update/upgrade process should be managed by Ubuntu and not amule. In Ubuntu's Firefox this check is also disabled and the option is greyed out.

It appears that the version check only prints the availability of the new version in the logfile, so this is harmless and should be leaved.

In the meantime, amule 2.2.2 was released (which include changes to defy routing attacks), but it's not yet in debian/intrepid. Changelog: http://www.amule.org/wiki/index.php/Changelog_2.2.2

Changed in amule:
status: Confirmed → Fix Released
Oibaf (oibaf) wrote :

This bug refers to update amule in Ubuntu 8.04, not in intrepid, because the current SVN version is obsolete and don't work with other ed2k software.

Also it was decided to update to 2.2.2 which fixes some security problems in the protocol.

Changed in amule:
status: Fix Released → Confirmed
description: updated
Oibaf (oibaf) wrote :

2.2.2 is now in debian / experimental. Once it get synced to intrepid a SRU can be done for 8.04.

Oibaf (oibaf) on 2008-08-27
description: updated
Oibaf (oibaf) on 2008-08-27
description: updated
Scott Kitterman (kitterman) wrote :

Subscribing motu-sru so they can evaluate this for SRU. I'm working on the sync now.

Oibaf (oibaf) on 2008-10-23
description: updated
Oibaf (oibaf) wrote :

amule 2.2.2-1ubuntu1 is now also in intrepid. Can we make an SRU for hardy?

Fabio Pedretti ha scritto:
> amule 2.2.2-1ubuntu1 is now also in intrepid. Can we make an SRU for
> hardy?

At a first glance, I'd say go for a backport instead. There have been
some new features in Kademilia and I think they're most suitable for the
backport process, but if you can provide motu-sru team a good rationale,
it can be reviewed properly.

Oibaf (oibaf) wrote :

This bug was indeed a SRU request. The reasons for the SRU are listed (and kept updated) in the first post of this bug.

Changed in amule:
status: Confirmed → Fix Released
JD Evora (jdevora) wrote :

The fix was released for Intrepid not for Hardy (a LTS(

Changed in amule:
status: Fix Released → In Progress
Changed in amule:
importance: Undecided → Wishlist
status: In Progress → Fix Released

Hello Luca,

Sorry for disturb you with this but why did you change it to Fix
Released? The "fix" was indeed released for 8.10 but the bug was
requesting a fix for the LTS 8.04 that still is a svn snapshot

Cheers
 JD

Wednesday, November 12, 2008, 7:39:01 PM, you wrote:

> ** Changed in: amule (Ubuntu)
> Importance: Undecided => Wishlist
> Status: In Progress => Fix Released

--
Best regards,
 JD mailto:<email address hidden>

Ansus (neptunia) wrote :

When clicking a e2k link in web browser (I tried Firefox and Epiphany), there is a message that no application is registered for this protocol.

I use Intrepid 8.10 and aMule 2.2.2 from the repo.

Oibaf (oibaf) wrote :

Is there something holding this SRU?

BTW, 2.2.3 is now in jaunty.

Changed in amule:
status: New → Confirmed

This bug has not yet been fixed for Hardy

Changed in amule:
status: Fix Released → Confirmed

I build aMule 2.2.2 for Ubuntu 8.04, please, test

https://launchpad.net/~surfaz28/+archive/ppa

I just had to change libupnp3 by libupnp2:

amule (2.2.2-1ubuntu1~hardy1) hardy; urgency=low

  * New upstream stable release (LP: #244670)
    - Change libupnp3 for libupnp2 because in Hardy
      only exists libupnp2

 -- Surfaz Gemon Meme <email address hidden> Sun, 01 Feb 2009 21:15:14 +0000

Attached diff

Citando Surfaz Gemon Meme <email address hidden>:

> Also, this sru will fix:
>
> https://bugs.launchpad.net/ubuntu/+source/amule/+bug/201624

I think that for this bug you should use at least 2.2.2-2 (note the -2) or 2.2.3, due to this change:

amule (2.2.2-2) experimental; urgency=low

   * The "The Luckiest Guy on the Lower East Side" release.

> * Build-Depend on libupnp3-dev: configure now detects its presence at build
> time and links against it, instead of the program dlope'ing it at run time.
> (Thanks Sven Hartge for the heads-up, closes: #509218).

   * Make amule Replace: old versions of amule-common as found in Ubuntu
     (they used to ship the skins in amule-common for some time).

Fabio Pedretti, that is not possible because the library libupnp3-dev is not available in Hardy

Oibaf (oibaf) wrote :

> the library libupnp3-dev is not available in Hardy

What about libupnp-dev ?

http://changelogs.ubuntu.com/changelogs/pool/universe/a/amule/amule_2.2.0~svn20080218-0ubuntu4/changelog

" * debian/control:
    - Do not build-depend on libupnp-dev as the headers needed are shipped
      by upstream and not used from the system, and make amule depend on
      libupnp2 as it uses dlopen() to call the library.
      Changes taken from the Debian package, thanks to Adeodato Simó
      for letting me know about this."

And see this: http://<email address hidden>/msg596361.html

"It seems from version 2.2.2 on, aMules configure is able to correctly detect
the presence of libupnp3-dev and use it accordingly.

Earlier versions (=< 2.2.1) seem to try to unconditionally dlopen()
libupnp.so.3, but the version from experimental does it right by checking at
compile time, if the library is available.

Please apply attached patch to correctly use libupnp3, as current version
in experimental depends on libupnp3 but the binary does not use it, because
libupnp3-dev was not present during build."

Oibaf (oibaf) wrote :

Citando Surfaz Gemon Meme <email address hidden>:

> http://changelogs.ubuntu.com/changelogs/pool/universe/a/amule/amule_2.2.0~svn20080218-0ubuntu4/changelog
>
> " * debian/control:
> - Do not build-depend on libupnp-dev as the headers needed are shipped
> by upstream and not used from the system, and make amule depend on
> libupnp2 as it uses dlopen() to call the library.
> Changes taken from the Debian package, thanks to Adeodato Simó
> for letting me know about this."

OK, older version of amule didn't Build-Depends on the libupnp*-dev packages (but Depends on binary version of libupnp).

> And see this: http://www.mail-archive.com/debian-bugs-
> <email address hidden>/msg596361.html
>
> "It seems from version 2.2.2 on, aMules configure is able to correctly detect
> the presence of libupnp3-dev and use it accordingly.
>
> Earlier versions (=< 2.2.1) seem to try to unconditionally dlopen()
> libupnp.so.3, but the version from experimental does it right by checking at
> compile time, if the library is available.
>
> Please apply attached patch to correctly use libupnp3, as current version
> in experimental depends on libupnp3 but the binary does not use it, because
> libupnp3-dev was not present during build."

 From 2.2.2 amule appears to be able to link to libupnp at build time, so libupnp3-dev was added to Build-Depends (and libupnp3 removed from explicit Depends). Apparently 2.2.2 only support libupnp linked during built time and not dlopened, see comments from 2008-11-07 of:
https://bugs.launchpad.net/ubuntu/+source/amule/+bug/201624

Any news?

Daniel T Chen (crimsun) wrote :

The main task tracks the *current* development release, and there exists a hardy task already, so I'm closing the jaunty task.

Changed in amule:
status: Confirmed → Fix Released

Attached main changes from svn to 2.2.2

I remove of this diff the following folders:

* aMule.app

Folder for Mac OS X related files

* debian-upstream, docs, po (translations)

Not relevant

* MSVC Solution

Folder for MicroSoft Visual C++ IDE related files

About my las post: https://bugs.launchpad.net/ubuntu/hardy/+source/amule/+bug/244670/comments/41

These changes are not improvements in the package.

Only is a file that is trying to show the changes between version svn and 2.2.2

Any news ¿?

description: updated
Oibaf (oibaf) wrote :

Ubuntu 8.04 is near to be unsupported on the desktop. Users should upgrade to 10.04 if they want a recent amule on a LTS release. Closing.

Changed in amule (Ubuntu Hardy):
status: Confirmed → 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