Hi, there is a new version of the sleuthkit (2.10): http://sourceforge.net/project/showfiles.php?group_id=55685&package_id=78997&release_id=561209
WFM - copied the 2.09 ebuild and modified it to use the 2.08 dbtool patch (since the 2.09 one is just a renamed copy of it). Works with both -dbtool and dbtool. Can upload the ebuild if you like.
Sleuthkit is at 2.51 now; I haven't worked on porting the dbtool patch, but without it the package installs fine anyway. Ported the fscheck.c_fix patch as well.
Created attachment 144281 [details] ebuild for 2.51 A tad rough, IMO, but it works for me.
Created attachment 144283 [details] ebuild for 2.51 Better version, doesn't reference the interim 2.50 version I have in my repository.
Created attachment 144285 [details, diff] patch for fscheck.c One necessary ported patch
2.52 is out, with bugfixes.
Created attachment 154711 [details, diff] fscheck patch for 2.52 Adding updated fscheck patch: naming convention changed, one hunk was failing due to a changed #include.
Created attachment 154713 [details] 2.52 ebuild Ebuild for 2.52; this drops the dbtool situation completely (in favor of using pyFlag's) and adds autoconf support. Although 2.52 was billed as a minor update, there was a great deal of source shuffling (.c -> .cpp, autoconf, etc.). I'm working on ebuilds for afflib and libewf shortly, so those can be supported in 2.52; expect an updated sleuthkit ebuild to reflect USE flag additions.
I'd suggest updating the summary to reflect we're now waiting for 2.52. The dbtool patch for 2.08 and 2.09 was nice, but is there any reason to keep that, particularly considering pyFlag (upstream for the utility) has switched to a pure python implementation? It'd be awfully nice to get these forensic packages updated; there are several hanging out here with version bumps that don't take much work (or have already had the work done).
Created attachment 154745 [details] 2.52 with ewf/aff support Sooner than I thought - adds optional dependencies for libewf and afflib.
Created attachment 155751 [details] fixed 2.52 ebuild I realized I'd been propagating a spelling mistake in the original sleuthkit-2.09 ebuild, which instead of installing 'dstat' upon collision with sys-apps/dstat as 'dstat-tsk' did 'dstat-dsk'. In doing so, I also (I think) fixed bugs 131268 and bug 197259 (a dupe of 131268).
> if has_version 'sys-apps/dstat' ; then This doesn't work. One can always install sys-apps/dstat after sleuthkit and be greeted by a file collision. Ebuild conflicts have always to be handled mutally, no matter, in which order ebuilds get installed. In this case, the dstat binary of sleuthkit should be renamed unconditionally - best would be to convince upstream to do so. Given that this is warn level, the message block is way too verbose for my taste. Who likes spammed logs?!
I didn't write that particular bit, but I'll bite. I don't see why sleuthkit should change; not only does it precede dstat in portage by 6 months, but it's more than two years older. As a central piece to many other forensics packages which are themselves (due to their nature) rather sensitive to change, I don't see this being even negotiable. I don't even like the way it's being done now; I'd rather just see them block each other.
Personally I don't care, either one package has to change or they have to block each other. I'd say it's quite obvious that you rather change the name of a binary that is named different than the application itself, instead a binary that is named as the application. Making them block each other just asks for another bug being filed by a person who wants to use both applications and therefore means more work in the end.
Created attachment 165528 [details] ebuild blocking dstat Updated ebuild blocking sys-apps/dstat. According to ML traffic, upstream is going to re-name d* to blk* in the upcoming 3.x releases.
Created attachment 165530 [details] fscheck patch 2.52 sanity renaming This is the original patch for 2.52, re-named to avoid the generic 'fix' nomenclature.
Actually, we have a major version bump here: http://www.sleuthkit.org/ Sleuthkit 3.0.0 and Autopsy 2.2.0 are out.
Created attachment 169184 [details] sleuthkit-3.0.0 ebuild :) Already packaged yesterday.
(In reply to comment #18) > Created an attachment (id=169184) [edit] > sleuthkit-3.0.0 ebuild > > :) Already packaged yesterday. It would be nice to see it in portage, at least as ~x86... it's been 2 months since last activity here. What's up? :)
I keep up with packaging the software, but the forensics "herd" has been off the grid for months. Too many politics prevent my becoming a developer and taking the helm, including the fact that there's no official developer request for the herd so I'd have to join another and cross lines to support the packages (but still do enough for the other herd so as to keep everyone happy). Not worth it. Email me directly if you want a link to my overlay.
Wheeeeee: + 04 Jan 2009; Patrick Lauer <patrick@gentoo.org> +sleuthkit-3.0.0.ebuild: + Bump to 3.0.0, fixes #203773 @RB: feel free to poke me if you have some other goodies up your sleeve, your work is appreciated.
Oh wait. Misfire. Let me try to fix this ... (sorry!)
Commit complete. RepoMan sez: "If everyone were like you, I'd be out of business!" Aaaah. Much better :D
