search

radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.67k stars 3k forks source link

Marked for autoremoval on 11 March due to valabind: #920524 from Debian Package Tracker #12991

Closed Anutrix closed 5 years ago

Anutrix commented 5 years ago

Work environment

Radare2 Version 3.2.1 I use kali-linux on Windows WSL.

Expected behavior

Be not auto-removed from Debian Package Tracker.

Actual behavior

Version 3.2.1+dfsg-2 of radare2 is marked for autoremoval from testing on Mon 11 Mar 2019. It depends (transitively) on valabind, affected by #920524. You should try to prevent the removal by fixing these RC bugs.

To be auto-removed from Debian Package Tracker on March 11th 2019.

Steps to reproduce the behavior

Visit this link . See 'action needed' area.

radare commented 5 years ago

this is another completely nosense from debian, not surprised at all...

r2 have 0 dependencies, if debian adds stupid dependencies to their packages this is not our fault.

valabind build and works fine if you use a recent (2 yo) version of Vala, but debian uses an ancient one, so it cant be used to compile radare2-bindings which are completely not used by anybody and its in maintainance mode.

But again, if debian takes the radare2-bindings tarball from our build server instead oft he github tarballs they will discover valabind is not needed at all because the autogenerated .cxx files are there to make binding compilation work fine without valabind.

XVilka commented 5 years ago

Maybe at least Debian users will be able to use recent radare2 versions, not 10 years old one.

sre commented 5 years ago

Hi,

So first of all we currently do not package radare2-bindings at all. This is an ancient dependency, that has not been dropped for some reason. I do not even remember when I dropped the r2-bindings package in Debian. Probably when bokken was removed. I agree, that valabind is very old. Mainly because it was not used at all, so nobody cared. The bug report is from Hilko Bengen, who recently started supporting me in updating r2 packages in Debian and planned to re-introduce r2-bindings. I think he gave up on that plan, so probably we can just drop valabind from Debian (and the bogus dependency of course).

@XVilka This only affects Debian testing, which has 3.2.1 right now. Current stable has 1.1.0 and is completly unaffected by this.

P.S.: I'm not sure why this is reported upstream. This is obviously a downstream issue and should be reported like this: https://www.debian.org/Bugs/Reporting (FWIW I get push notification for autoremoval issues in r2 anyways, so not really helpful)

-- Sebastian

radare commented 5 years ago

Thanks for the quick response! Yes this dependency should be removed from the radare2 package.

Also, i would like to know if Debian maintain any patch that is not commited in master.

About valabind i think its fine to remove it from debian, people can actually install it via r2pm and its only used in radare2-bindings as far as i know, but will be good to fix this issue with the vala developers. because this library shuold be accessible from valabind.

--pancake

On 4 Feb 2019, at 22:02, Sebastian Reichel notifications@github.com wrote:

Hi,

So first of all we currently do not package radare2-bindings at all. This is an ancient dependency, that has not been dropped for some reason. I do not even remember when I dropped the r2-bindings package in Debian. Probably when bokken was removed. I agree, that valabind is very old. Mainly because it was not used at all, so nobody cared. The bug report is from Hilko Bengen, who recently started supporting me in updating r2 packages in Debian and planned to re-introduce r2-bindings. I think he gave up on that plan, so probably we can just drop valabind from Debian (and the bogus dependency of course).

@XVilka https://github.com/XVilka This only affects Debian testing, which has 3.2.1 right now. Current stable has 1.1.0 and is completly unaffected by this.

P.S.: I'm not sure why this is reported upstream. This is obviously a downstream issue and should be reported like this: https://www.debian.org/Bugs/Reporting https://www.debian.org/Bugs/Reporting (FWIW I get push notification for autoremoval issues in r2 anyways, so not really helpful)

-- Sebastian

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/12991#issuecomment-460411472, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lip0lS-G99TSAIUJn3AFZ6Ck3kObks5vKJ_agaJpZM4ahpNk.

sre commented 5 years ago

I usually send patches upstream, so that I do not need to maintain them downstream forever and usually other distribution people also need them. Still there is currently one patch (https://salsa.debian.org/pkg-security-team/radare2/blob/debian/master/debian/patches/0001-fix-FTBFS-for-as-needed.patch) missing upstream, since I have not checked if its still needed and I don't want to submit useless crap :)

Regarding vala: I think upstream assumes, that libvalaccodegen.so is private and thus does not install it into $LIBDIR by intention. I might be wrong about that one, though. It has been some time, that I was involved with vala people.

-- Sebastian

radare commented 5 years ago

i have released valabind 1.7 can you try upgrading it?

On 4 Feb 2019, at 22:25, Sebastian Reichel notifications@github.com wrote:

I usually send patches upstream, so that I do not need to maintain them downstream forever and usually other distribution people also need them. Still there is currently one patch (https://salsa.debian.org/pkg-security-team/radare2/blob/debian/master/debian/patches/0001-fix-FTBFS-for-as-needed.patch https://salsa.debian.org/pkg-security-team/radare2/blob/debian/master/debian/patches/0001-fix-FTBFS-for-as-needed.patch) missing upstream, since I have not checked if its still needed and I don't want to submit useless crap :)

can you make a pr with this patch? thanks! Regarding vala: I think upstream assumes, that libvalaccodegen.so is private and thus does not install it into $LIBDIR by intention. I might be wrong about that one, though. It has been some time, that I was involved with vala people.

they are pretty active if you jump into the irc.gnome.org #vala channel

radare commented 5 years ago

Another option would be to add support for meson in valabind. i will look into that

sre commented 5 years ago

I've dropped the above mentioned patch after switching to meson build for the Debian package. Comparing the generated packages I noticed, that meson does not install a couple of things:

  1. v850.sdb
  2. mfc120.sdb
  3. r2 -> radare2 symlink (binary and manpage)
  4. lot's of documentation files (but actually quite a few of them do not make sense to be installed anyways. E.g. the operating system specific installation tips are not useful after installation)

Also csmtpapi.sdb and csncdapi.sdb were not installed by ACR/Makefile buildsystem, but are now installed by meson.

radare commented 5 years ago

I will have a look at those meson/make inconsistencies! Thanks!!

On 5 Feb 2019, at 16:31, Sebastian Reichel notifications@github.com wrote:

I've dropped the above mentioned patch after switching to meson build for the Debian package. Comparing the generated packages I noticed, that meson does not install a couple of things:

v850.sdb mfc120.sdb r2 -> radare2 symlink (binary and manpage) lot's of documentation files (but actually quite a few of them do not make sense to be installed anyways. E.g. the operating system specific installation tips are not useful after installation) Also csmtpapi.sdb and csncdapi.sdb were not installed by ACR/Makefile buildsystem, but are now installed by meson.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

ret2libc commented 5 years ago

@sre

  • v850.sdb
  • mfc120.sdb

Sure, they are probably just missing, thanks!

  • r2 -> radare2 symlink (binary and manpage)

This is not going to happen soon. Last time I checked, meson did not support links in a clean way (you could "install" them, but then they would never be removed). Again, for distributions I think we should just implement it in the package itself.

  • lot's of documentation files (but actually quite a few of them do not make sense to be installed anyways. E.g. the operating system specific installation tips are not useful after installation)

Could you list which doc files you miss? Also, on Fedora pkg I have manually added the documentation I needed.

radare commented 5 years ago

ive fixed the make part in 1587e3eaa9da4ffdd9a6cc69924b48d36cb8e533

radare commented 5 years ago

The autoremoval issue is fixed, so im closing this issue, @ret2libc will fix those remaining meson things.

thanks everyone!