Well hidden on the German site (winace.de) there is a link to a UNACE v2.5 ELF 386 binary (the current version in portage is 1.2b-r1, incompatible with 2.0 archives)
Created attachment 65822 [details] unace-bin-2.5.ebuild
Well, I tried to redo the tests from Bug 81958. It segfaults on ./unace {t,l,v} bufoflow1.ace, works on bufoflow2.ace and reports "Header broken: Error while reading archive" on dirtraversal{1,2}.ace.
I've posted another message on their forum, maybe this could be included in portage as a masked package?
You can also find it here: http://www.winace.com/down.html It's not that hidden ;)
Created attachment 75505 [details] /usr/portage/licenses/ACE I could not find a real license on WinAce's homepage, but this document could go into the /usr/portage/licenses directory.
Created attachment 75506 [details] unace-2.5.ebuild An alternative ebuild for unace, which installs the unarchiver into /opt (like rar). I would also suggest to rename the old app-arch/unace to app-arch/unace-gpl (as with unrar and unrar-gpl), and let this binary package reside in app-arch/unace. The attached ebuild incorporates the above suggestion. Best regards Christian
Created attachment 75507 [details] unace-bin-2.5.ebuild An ebuild which installs unace into /opt and conforms to the naming scheme suggested by Dick.
Created attachment 75509 [details] /usr/portage/licenses/ACE I just noticed that the .tgz contains a license file...
(In reply to comment #6) > I would also suggest to rename the old app-arch/unace to > app-arch/unace-gpl (as with unrar and unrar-gpl), and let this binary package > reside in app-arch/unace. There's no reason for this. The ebuilds should be slotted, when they can live side by side.
(In reply to comment #9) > (In reply to comment #6) > > I would also suggest to rename the old app-arch/unace to > > app-arch/unace-gpl (as with unrar and unrar-gpl), and let this binary package > > reside in app-arch/unace. > > There's no reason for this. The ebuilds should be slotted, when they can live > side by side. > That would be fine for me, either. How should one deal with the fact that both the GPL version and the binary version use the same executable name?
(In reply to comment #10) > That would be fine for me, either. How should one deal with the fact that both > the GPL version and the binary version use the same executable name? The GPL version isn't of much use anyways, when you do not want to open very dated ace archives exclusively, so I don't see why someone would want to keep it. But it's the users decision how to deal with it.
Created attachment 76286 [details] unace-2.5.ebuild (In reply to comment #11) > (In reply to comment #10) > > That would be fine for me, either. How should one deal with the fact that both > > the GPL version and the binary version use the same executable name? > > The GPL version isn't of much use anyways, when you do not want to open very > dated ace archives exclusively, so I don't see why someone would want to keep > it. But it's the users decision how to deal with it. > This ebuild does not install unace into another slot as the GPL'd version. This is OK for me since I was not able to extract a single ACE archive using the older version.
(In reply to comment #6) > I would also suggest to rename the old app-arch/unace to > app-arch/unace-gpl > The old version does not seem very GPL to me... The "file_id.diz" file contains the following notice: "the source may be distributed and used, but I,Marcel Lemke, retain ownership of the copyrights to the source."... There does not seem to be any other mention to a licence. There is nothing about GPL, nothing about being free to modify the source and redistribute it... even the "may be distributed and used", does not mean much... It is important to separate the source from the binary version, so we should name the new binary ebuild "unace-bin", as the original reported did, and keep "unace" for the source version... (which we should keep, as it is working -not on recent archives, indeed-, and as... well, it is the source version...). But did anyone tried to contact Marcel Lemke, the author of both versions, about maybe distributing newer versions of the source code (under a more precise licence)?
(In reply to comment #13) > The old version does not seem very GPL to me... > Sorry, it is indeed GPL... I just saw bug #92846 :/
This is now in the sunrise overlay: http://gentoo-sunrise.org/svn/reviewed/app-arch/unace-bin/unace-bin-2.5.ebuild thanks to peper.
*** Bug 139398 has been marked as a duplicate of this bug. ***
*** Bug 139788 has been marked as a duplicate of this bug. ***
just got a bunch of archives for which gpl version says: "File compressed with unknown method. Decompression not possible.", so maybe ressurect old binary unace? maybe in ~ slots, or masked (if there still exists exploitable bugs).
unace-bin-2.5.ebuild in sunrise overlay works for amd64.
Can someone merge this with the main portage tree?
(In reply to comment #20) > Can someone merge this with the main portage tree? I second that. I must also stress that I do not see the point in having the GPL'ed unace version in portage. It is practically useless as it is not able to extract most ACE archives (in fact, I was not able to extract a single ACE archive with it). This is also the reason why I'm for renaming "unace-bin" to simply "unace" in the overlay. There is no need for having both versions installed at the same time. As a compromise, the current "unace" could be "unace-gpl" (as "unrar-gpl"), and the overlay's "unace-bin" could become "unace". But it seems I am just warming up an old discussion...
that ebuild in the sunrise overlay is just plain terrible added as unace-2.5
