[Bug 1368855] Review Request: radare2 - The reverse engineering framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1368855

Michal Ambroz <rebus@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |ASSIGNED
         Resolution|DEFERRED                    |---
           Keywords|                            |Reopened



--- Comment #27 from Michal Ambroz <rebus@xxxxxxxxx> ---
Bump to release 2.3.0
https://rebus.fedorapeople.org/SPECS/radare2.spec
https://rebus.fedorapeople.org/SRPMS/radare2-2.3.0-1.fc27.src.rpm

> As I mentioned earlier, one option is to drop the affected functionality.
OK dropped the webui for now.

> Is this an upstream opinion? Did they actually do this on purpose? My guess is not.
> To clarify, this absolutely needs fixing before the package can be imported.
This is the upstream default behaviour. There is actually undocumented
HAVE_LIBVERSION=1 option which makes the linking of the binaries point to
versioned so libraries. I believe this should be acceptable for you.
I got it checking the Debian package ... but then I found you actually had it
in your spec file as well.

> Well I'm probably just nitpicking here, but that %changelog entry doesn't 
> reflect reality (perhaps Pavel would be surprised to learn that he did an 
> initial radare2 package?).
Yes I consider this nitpicking.
Here is the upstream commit of the line directly by Pavel Odvody -
https://github.com/radare/radare2/commit/3640a0481c1ba8b40a40eda6834ac02d51475267
I originally thought tito was his other nick-name. Now I guess he re-used tito
spec-file and possibly forgot to replace "tito" with "radare2" in the
changelog.

>This still requires action.
I have added a comment.
I consider this nitpicking as well ... have not seen SPEC file where it would
be described which options were not used and why.

>>2.2.) Bundling of C libraries
> This is still a problem (perhaps rather easy) that needs to be addressed; 
> in particular the "provides" tags.
I have added "provides" tag for some of the libraries I found bundled.
I do not consider this as finished, because it remains to pinpoint the versions
used.

Best regards
Michal Ambroz

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux