A new release may be due #237
Replies: 30 comments
-
I agree atleast to fix the various issues with Wx as example and bump the dependencies. |
Beta Was this translation helpful? Give feedback.
-
Remember that most/all Linux distributions will only bundle released versions. So, most people (on Linux anyway) are still using the 2016 code. |
Beta Was this translation helpful? Give feedback.
-
Yes usually is patched to compile it with the updated dependencies like on debian https://metadata.ftp-master.debian.org/changelogs//main/a/amule/amule_2.3.2+git20200530.3a77afb-1_changelog |
Beta Was this translation helpful? Give feedback.
-
@Mte90 : Well, yes, but the patch doesn't include your leak fixes, crash fixes, (performance improvements?), translation additions etc. |
Beta Was this translation helpful? Give feedback.
-
That's true but in the case of debian sid they are using git, so they get the last updates just to be able to compile it. As example to be able to run the web interface of amule you need wxWidgets so in an environment without x11 you are not able to run it/compile it easily. |
Beta Was this translation helpful? Give feedback.
-
The new release is on its way, but at least the issues in the 2.3.3 milestone should be fixed first. I'm working on it, but I have a real life, too.
Bad example. It won't get any easier to run or compile amuleweb with the new release. However, amuleweb requires only the wxBase port of wxWidgets, so it works (and can easily be compiled) on any system, even without a display, not to speak of graphical user interface. |
Beta Was this translation helpful? Give feedback.
-
aMule started as an extremely hostile fork of my project, xMule, in 2004. The amount of toxicity from people responsible for aMule led to great mental degradation for me and I quit the project altogether in 2007 and became much happier for it. I think it's truly incredible, tho, that my creation lives on into 2020 via aMule. Last time I checked, in 2015, it hadn't had a release in a long time and I assumed it was dead. I wonder if Kry is still involved in this project? If so, I'll stay far far away. |
Beta Was this translation helpful? Give feedback.
-
If you look at the very first commit of aMule, d0b1049, you'll see that Merkur ripped out all of my It was blatant theft and against the GPL. That, combined with the targetted harassment, in both public and personal life, was very unethical. https://en.wikipedia.org/wiki/XMule |
Beta Was this translation helpful? Give feedback.
-
@hopeseekr : I was not aware of any of these events. Is "Merkur" the same person as @Mte90? Also, that first commit is huge. I see some license text, but - I don't know about your 2002 copyrights or where they were. If you've written a longer description of this saga somewhere, I wouldn't mind a link. Also, I'm not sure how this relates to this specific issue report or how I could possibly do something about all this. @Mte90 : If what @hopeseekr says is correct, should we not open a new issue to changes the license text, recognizing him as well? That shouldn't hurt anything since it's all GPL. |
Beta Was this translation helpful? Give feedback.
-
No I don't have anything to do with this project, @eyalroz. |
Beta Was this translation helpful? Give feedback.
-
@hopeseekr Kry retired in 2012 from the project, so feel free to jump in (at least from my side). |
Beta Was this translation helpful? Give feedback.
-
@gonosztopi @Vollstrecker debian just entered the first phase of the freeze in preparation for the next stable release. There's still plenty of time to get a new version of amule into debian so that we can release with it, but that is around 2 months from today. Would you think you're gonna be able to release something by that timeframe? thanks! |
Beta Was this translation helpful? Give feedback.
-
@sandrotosi I guess there should be no problem releasing the current code as 2.3.3 in the first week of February. |
Beta Was this translation helpful? Give feedback.
-
From my side, too. The cmake stuff is done so far (not in the branch, as it would remove autotools etc. and I decided to keep it a it still works), I'm just wating for @mrjimenez to merge my pull-request int pupnp before commiting it, as I would need to do some different things if that doesn't happen. After that I just remove the conditionals for cryptopp < 5.5, as we don't need to care about that old version, and upnpinit will be changed, as in newer versions this isn't included anymore, and the replacement is there for 13 years now. And it seems that I'm the only one that has problems with newer boost. Since 1.72 asio is header-only and doesn't need boost-system anymore, but our checks deactivate asio if libsystem wasn't found, but that code is a real pita, so I'll just rely on cmake here, as it's working with that. And btw. I consider this as fix also for #232. |
Beta Was this translation helpful? Give feedback.
-
Done, and the upnp was fixed before my last pull, so from my side no showstopper left. |
Beta Was this translation helpful? Give feedback.
-
cool, thanks guys! |
Beta Was this translation helpful? Give feedback.
-
Please make sure and write a significant changelog for the new release, which isn't just a long list of bug numbers - since it's four years of work. A broad-strokes description of the significant changes/fixes/improvement would be great. |
Beta Was this translation helpful? Give feedback.
-
You mean like this? Most things changed are just fixes for problems that occured since the last version for compilation, so for users that don't compile not really interesting, and for users that only compile releases also not interesting. For users that compile master, this should be understandable, otherwise they should overthink their attempt to get dev versions. |
Beta Was this translation helpful? Give feedback.
-
@Vollstrecker : That would do. I somehow had the idea there were more changes. |
Beta Was this translation helpful? Give feedback.
-
I'll check if anything is missing from the changelog before releasing. |
Beta Was this translation helpful? Give feedback.
-
Not really. The cmake stuff requires cmake version >= 3.11, but even Ubuntu 18.04 (which is not old at all and is quite widespread) has only 3.10.2. Thus we still need to keep a working autoconf around... |
Beta Was this translation helpful? Give feedback.
-
18.04 is ~3 years old (duh) and there's already a new LTS release, 20.04 which i imagine ubuntu is suggesting users to use instead of older releases (even tho 18.04 is going to be supported thru 2023). Are you thinking about people compiling amule by themselves or ubuntu releasing a new version of amule to 18.04? the latter wont happen, while for the former, these people will need to have figured out a way to keep their distro up-to-date with newer software anyway. in my opinion, and if 18.04 is the only reason, that constraint should be lifter and move to cmake entirely without considering backward compat that old in the past |
Beta Was this translation helpful? Give feedback.
-
As always, my scale is Debian stable, but I consider it a fix, as there is something that makes it uncompileable when autoconf 2.70 reaches enough installations which is in 18.04 not given. So everything up to now works with autotools, and everything upcoming works with cmake. And to be honest, I can't remember why 3.11 is needed, I'll check that over the day. |
Beta Was this translation helpful? Give feedback.
-
As this issue here seems to be a more or less a general discussion over the time, could I propose to activate Discussions for the project? |
Beta Was this translation helpful? Give feedback.
-
Sure, I'll do that when I get home.
I tried lowering the required version to 3.10.2 and it failed for several reasons. I can show you the failure when I get home, if you're interested. As for autoconf, 2.70 is yet only seven weeks old, so everyone has 2.69. For now I'll make it an error if one uses 2.70 and we can make a real fix (or abandon autotools completely) later.
It was just an example. There are actual users out there compiling aMule on much older systems, too. (And of course they could install a new enough version of cmake, too...) |
Beta Was this translation helpful? Give feedback.
-
Just checked that. The add_definitions aren't supposed to be there anyways. The link_libraries don't work in wx.cmake as they do now, but can be replaced with an set property with the same effect would be cleaner anyways. Then just muleunit needs to be a static instead of object lib (need to check if this works on windows, I've something on my mind that there has been problems with it anyways) and it works until all libs are compiled, then I get a strange Makefile error. The question is, if we want to support this old stuff, as there are newer LTS-releases available, before I waste time on finding out what goes wrong there. |
Beta Was this translation helpful? Give feedback.
-
On my libraries, I try to reduce the CMake version as far as I can manage it, using ugly workarounds for things the CMake people fixed in recent years. But usually, between version 3.x and version 3.(x+1) the differences are not that big, so it should be doable. Given that the previous release is from 2016, I think it's reasonable to expect that the next release work with build toolchains from 2018. So, I encourage you to try and support the "old stuff" :-) |
Beta Was this translation helpful? Give feedback.
-
That's the problem. With cruel workarounds autotools were invented. This end's up like my wx.cmake. A lot of work, just to have the same libnames to link against on linux and windows. Unreadable. The big advantage on cmake are the readable files, and the easy way of chanloading projects. The hacks are going to far already (and after reading it again, I'm not sure if this works on debian-stable, too as it is depending on the wx-version). For thew chainloading: That's why I started CmDaB, if I get all the deps done, I start with including wx there. Maybe they include it in there source like with upnp, or with a separate find-module like with pthreads. Unfortunately this requires at least 3.13, so Debian stable is out, too. Fortunately we will get a new one soon. Until then, there are the autotools that work there, and as long as there are alternatives, I always vote against cruel hacks that noone understands in a year anymore, just to reach a goal we already have. |
Beta Was this translation helpful? Give feedback.
-
Well, in that case... better to have a release requiring CMake 3.13 then the release waiting for who knows how long... |
Beta Was this translation helpful? Give feedback.
-
I must agree with you @Vollstrecker . As neither MSW nor MacOS comes with cmake preinstalled and Linuxes are able to use autotools, I see no cluttter your CMakeFiles. The drawback is, that we'll need to maintain two different build system side-by-side (or, looking from the other side, only two). |
Beta Was this translation helpful? Give feedback.
-
It's been about 4 years since the last release. Is it not perhaps time to consolidate most of the changes since then and publish a proper release?
Beta Was this translation helpful? Give feedback.
All reactions