(In reply to Carlos Sánchez from comment #0)

Hello Carlos,

The Fedora package includes the normal graphical amule application. For remote administration, it includes the new amuleapi web interface rather than the limited legacy amuleweb interface. Upstream has deprecated amuleweb and intends to remove it.

The new interface covers downloads, searches, servers, Kad, shared files, clients, categories, statistics, logs, preferences and detailed file information. Could you clarify which functionality you require from amulegui that is unavailable through the new interface? amulegui remains supported upstream, so its inclusion can be considered if there is functionality that amuleapi does not provide.

If you would like to test the latest development package and web interface, you can enable my dogfood COPR:

sudo dnf copr enable gbcox/dogfood
sudo dnf upgrade --refresh amule amule-nogui

Please bear in mind that the dogfood repository contains development builds and is intended for testing.

I asked upstream to clarify the intended relationship between amulegui and the new amuleapi Web UI.

Upstream confirmed that amuleapi replaces the deprecated legacy amuleweb, not amulegui. Both interfaces remain actively maintained and serve different deployment models:

amulegui is a native desktop client that connects directly to a local or remote aMule core over EC.
amuleapi provides a REST/SSE service and a modern browser interface, particularly suited to headless systems and access from desktop or mobile platforms.

Upstream recommends that distributions package both amulegui and amuleapi when possible. I will follow that recommendation and restore amulegui to the Fedora package.

The new Web UI already covers downloads, shared files, searches, clients, servers, Kad, categories, preferences, statistics, logs and IP-filter management. Friends and chat are implemented in the REST API but do not yet have Web UI views; upstream’s goal is full feature parity.

Users therefore have a meaningful choice. Those who prefer a traditional native desktop application can use amulegui. Those who prefer a headless installation can install only amule-nogui and manage aMule from any web browser without installing the monolithic client or remote GUI. The new Web UI already has near-feature parity with the desktop client, with friends and chat remaining to be added to the frontend.

Both remote interfaces communicate with the aMule core over EC, so the client and core must use compatible EC protocol versions. In particular, a 3.x amulegui or amuleapi cannot connect to a 2.3.x core. If the remote server is still running aMule 2.3.x, it must be upgraded first.

You can test amulegui immediately using my COPR repository, as described in my previous comment. Please bear in mind that the COPR contains development builds and is intended for testing.

Once the update is available, you can choose whichever approach best fits your deployment: install amule for the native desktop clients, or install only amule-nogui and administer the daemon through the new browser interface.

Hello Gerald,

Thanks a lot for your comments...

I was using amule since long time ago with an architecture of client/server, so I have a server with the amuled running (this is a F43), and at the client side I had amulegui running (in a F44) and now the amulegui package has disappeared in F44 and only remains the package amule (for local use) in version 3.0.1.

According to their documentation:

https://amule-org.github.io/docs/manual/interfaces/gui

They are mantaining amulegui.

At the moment I have not tested this version of amuleapi, wich means that I need somehow to update my server from F43 to F44, in the current version of amule in F43 (I think it is 2.3.3) the amuleweb is very poor compared to amulegui. But I will try this server update just to see if it is enough to manage the server (according to your comments, amuleapi provides almost the same functionality than the amulegui version).

Nevertheless, if you are going to repackage the amulegui, these are good news, so in the future anyone can decide which approach is more suitable.

By the way, I've installed your COPR repository but I'm not able to see the package amule-gui, so I couldn't test it, unless is still not released..., but as you said is not compatible with amuled 2.3.x.

Again, thanks for your comments, I will be updating you with my tests.

Best regards.

Hello Carlos,

aMule 2.x was available only from RPM Fusion; it was never part of the official Fedora repositories. When aMule 3.x was released, I took ownership of the package and introduced it into Fedora.

In the RPM Fusion 2.x package, amulegui was included in the main amule package rather than provided as a separate package. As mentioned earlier, I consulted upstream about the intended relationship between amulegui and amuleapi (see the upstream discussion linked in this Bugzilla ticket). Based on their feedback, amulegui will again be included in the main amule package. It is available now from my COPR repository and will be included in the next official Fedora update.

Please note that aMule 3.x is not packaged for Fedora 43. It is available beginning with Fedora 44.

You are correct that the old amuleweb interface was extremely limited compared with amulegui. However, I think you will be pleasantly surprised by the new amuleapi Web UI in the COPR build. The difference is substantial: it covers downloads, shared files, search, servers and Kad, clients, categories, preferences, statistics, the log, and IP filter management. The only two things it does not yet have are friends and chat. Upstream tells me both are already implemented in the REST API and simply do not yet have frontend views. For what it is worth, I run amule-nogui myself and manage it entirely from the browser; I have not found anything missing in daily use.

I expect many users running aMule on a remotely administered server will prefer to install only amule-nogui on the server and manage it from a web browser, without installing additional software on their client machines. amulegui, which will be included in the monolithic amule package, remains available for users who prefer a native desktop application.

I am reopening this ticket. Please use it for further questions and to report your testing results.

Thank you for helping test the package.

I've created a F43 package in COPR to make it easier for you to test.

Hello Gerald,

I've installed a new F44 server with amuled + amuleapi, and I have to tell that amuleapi interface is much better than amuleweb, even more stable, but still not the same functionality than amulegui, specially on settings side, where the gui version allows you to modify every single parameter for amuled, this is not a big issue because it's possible to modify them in amule.conf file in the server...

I would like to test the new amulegui 3.0.x, but I'm not in a hurry, so I can wait until it is available in the main repository or your COPR repository.

Thanks in advance for you support.

Hey Carlos: 

Thanks for the feedback.

I'm a little surprised by the comment about the settings, because the current amuleapi Preferences interface appears to expose essentially all of the settings that are meaningful for amuled. It has General, Connection, Directories, Servers, Files, Security, IP2Country, Proxy, Filters, Remote Controls, Online Signature and Advanced sections.

The desktop GUI has a few additional preferences which are specific to the wxWidgets GUI itself, such as interface/display settings, so naturally those don't make sense in a browser interface.

If there are specific amuled settings that you can change with amulegui but cannot change with amuleapi, could you let me know which ones? That would be useful information, especially since upstream has described the goal as feature parity with the desktop interface.

Also, you don't need to wait to test amulegui 3.0.x. It is already available in my COPR repository. amulegui is included in the main amule RPM rather than being packaged separately, so installing/updating the amule package from the COPR should give you amulegui as well.

Thanks again for testing this.

Hi again Gerald,

I've tried amulegui from your COPR repository, and it worked as expected, now we have back all the functionality.

And yes, I can confirm than in the web page consuming amuleapi on the settings page, only a few parameters about the connection are exposed, perhaps amuleapi is prepared for managing all of them, but for the moment only a few are accesible.

Now the question is, when will it be available on regular repositories?

Thanks in advance and best regards.

Carlos, I think we may be looking at different versions of the WebUI. In the current build I’m testing, the Preferences page exposes General, Connection, Directories, Servers, Files, Security, IP2Country, Proxy, Filters, Remote Controls, Online Signature and Advanced settings — not just a few connection parameters.

Could you please provide the exact aMule package version you have installed (rpm -q amule) and, if possible, a screenshot of the Preferences page you are seeing?

Created attachment 2156732 [details]
Preferences screenshot

Hi Gerald,

I have attached a screenshot of the preferences page, so you can analyze.

On the other hand, here are my versions:

* On the server machine: amule-nogui-3.0.1-2.20260721git3cfd01f.fc44.x86_64
* On the client machine: amule-3.0.1-2.20260721git3cfd01f.fc44.x86_64

I hope it helps.

Thanks and best regards.

Carlos,

Thanks, that explains the difference.

You are currently running the July 21 Fedora snapshot:

amule-nogui-3.0.1-2.20260721git3cfd01f.fc44.x86_64

Upstream development is moving quite quickly, particularly in the new WebUI, so that version is already significantly behind current upstream.

If you want to evaluate the current state of amuleapi and amulegui, please use the packages from my COPR repository. I am updating the COPR builds daily so they track upstream development closely.

You can verify that the COPR repository is enabled with:

dnf5 repo list --enabled | grep 'gbcox:amule'

If nothing is returned, the COPR is not currently enabled.

To enable:  run0 dnf5 copr enable gbcox/dogfood

Once it is enabled, on the server I would run:

run0 dnf5 clean all
run0 dnf5 upgrade amule-nogui

And on the client machine:

run0 dnf5 clean all
run0 dnf5 upgrade amule

The current COPR build should give you the much more complete Preferences interface, along with the other WebUI functionality that has been added since the Fedora 44 snapshot.

Thanks again for testing and for providing the version information.

Created attachment 2156773 [details]
Preferences screenshot with COPR version

Hi Gerald,

You were right, I've installed COPR version in the server and now the preferences page has almost all the parameters.

I've attached a new screenshot is you want to review.

Thanks and best regards.

Carlos,

Thanks for confirming.

When you say the current COPR version exposes “almost all” of the parameters, could you identify any specific amuled settings that are still available through amulegui but not through amuleapi?

I’m asking specifically about settings that affect the remote amuled daemon. The desktop GUI also has some preferences that are local to the wxWidgets client itself, such as interface/display, statistics presentation, events and debugging options, and I would not expect those to appear in the WebUI, since they do not apply.

From looking at the current code, the amuleapi Preferences interface appears to cover nearly all of the daemon-side configuration groups. So if there are still actual amuled parameters that require editing amule.conf, it would be useful to know exactly which ones.

Upstream has stated that the goal is feature parity with the desktop interface, so identifying any remaining daemon-side gaps would be helpful.



Thanks,
Gerald

Hi Gerald,

The missing sections in the web UI (amuleapi) are:

   * Interface: local adjustments of the amulegui client.
   * Statistics: parameters about how to show the statistics. The statistics are also shown in the web UI but the parameters in the settings are not present.
   * Events: related to notifications.

The rest of parameters exposed in the COPR version of amuleapi are the same as the ones exposed in the COPR version of amulegui.

But there are more functionalities missing in the web UI version compared to amulegui, perhaps is not possible to have them in the web UI, but for me are important, for example: in the search section in amulegui it's possible to search more than one time without losing the results of previous searches so it's very easy to compare the results of different searches, another useful feature is on the downloads section in amulegui it's possible to configure which columns are visible, the order they appear, and specifically the column remaining time (there are others not available in amuleapi).

I don't know if it's possible or it's the intention to add those missing functionalities. For these reason locally (in my LAN) I prefer to continue using the amulegui version while in remote it's better to use the web UI.

Thanks.

Carlos,

Thanks for testing the current COPR build and for going through the remaining differences.

After comparing the current amuleapi WebUI with amulegui, most of the items you mentioned appear to be differences in presentation rather than missing functionality:

Multiple searches are supported in the current WebUI and are preserved in separate tabs.
Download columns can be hidden/unhidden and resized. They cannot currently be reordered.
Additional per-download information, including Remaining Time, is available by opening the individual download details.
Statistics are available in the WebUI, although the desktop-specific display preferences are not reproduced exactly.
The Interface-related differences are largely local GUI presentation settings.
The Events section is the one area that appears to provide functionality not currently exposed by the WebUI, specifically event-triggered command hooks.

At this point, the original packaging issue is resolved. amulegui is available from the COPR as part of the main amule package, and the current amuleapi WebUI is substantially more complete than the older Fedora snapshot.

Since the remaining items are upstream WebUI feature/interface differences rather than a Fedora packaging problem, I am going to close this ticket.

Upstream development is still moving quickly, so I will continue updating the COPR on a daily basis, at least until the next release. If you are curious about new functionality as it is added upstream, the COPR should be a good place to try it.

If you have any additional questions or want to compare behavior in the current COPR builds, feel free to contact me on Matrix at @gbcox:fedora.im.

Thanks again for testing and for the feedback.

Gerald