app-forensics/libewf-20150126 is released after moving from Google Code to github. Old homepage http://code.google.com/p/libewf/ New homepage https://github.com/libyal/libewf. Also see https://sourceforge.net/projects/libewf/ for confirmation. Reproducible: Always
20160424 is available: https://github.com/libyal/libewf/releases
Created attachment 462146 [details] ebuild of libewf 20160424 version This is ebuild which I have prepared for Avidata Odzyskiwanie Danych (my polish data recovery company). It was checked on x86 and amd64 architecture, but it is "keyworded" as it is only proposition of ebuild. Joachim Metz (author of this library) often removes old "experimental" versions from github, so RESTRICT="mirror" might fail after some time (be warned), but now it is only one solution to automatic download sources. In new libewf api version (v2), there was some changes so: testdisk, dff, bulk_extractor, dfvf, plaso, and sleuthkit need some patching (be warned too) to be able compile with ewf use flag turned on after libewf upgrade. I will deploy patches for that packages and new ebuilds on separate bugs tickets.
So here they are. testdisk compatible ebuild and patch: https://bugs.gentoo.org/show_bug.cgi?id=607948 dff compatible ebuild and patch: https://bugs.gentoo.org/show_bug.cgi?id=607954 bulk_extractor compatible ebuild and patch: https://bugs.gentoo.org/show_bug.cgi?id=607950 dfvfs compatible ebuild https://bugs.gentoo.org/show_bug.cgi?id=607956 plaso compatible ebuild https://bugs.gentoo.org/show_bug.cgi?id=607962 sleuthkit compatible ebuild and patchs: https://bugs.gentoo.org/show_bug.cgi?id=607968
libewf-experimental-20170703 is out. Could you bump this version instead?
This would need a proxy maintainer: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Otherwise I would treeclean this after disabling the optional support for it in reverse deps
FWIW, the Pentoo overlay is maintaining a working ebuild for this and most of the libyal cluster.
I'm confused about the decision to remove this package. Version 20130416 is marked stable in the tree with no open bugs. The upstream looks alive with the last pre-release in November 2017. In any case, sleuthkit only supports the stable version anyway (https://github.com/sleuthkit/sleuthkit/blob/322c1d2560662886e6f394e931ecabf667e13854/INSTALL.txt#L44). I object to this removal.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cf8e9d3b0a683e46d6d26d529f4c03b2f748cced commit cf8e9d3b0a683e46d6d26d529f4c03b2f748cced Author: Göktürk Yüksek <gokturk@gentoo.org> AuthorDate: 2018-04-04 11:10:50 +0000 Commit: Göktürk Yüksek <gokturk@gentoo.org> CommitDate: 2018-04-04 11:22:44 +0000 app-forensics/sleuthkit: unmask ewf USE flag for >=4.6.0 Starting with 4.6.0, we statically link sleuthkit to a locally complied libewf since it is getting tree-cleaned (#547418). Mask the USE flag in prior versions. See the commit message for the sleuthkit 4.6.0 bump for more details. This partially reverts commit 37d9e41ab5c6fb2031aefdeb7af72a7354472031. The mask was put in place without it being communicated to the maintainer. Bug: https://bugs.gentoo.org/547418 Bug: https://bugs.gentoo.org/607968 profiles/base/package.use.mask | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3bf2cef453d6ee0d6aece0e8e91a049d556e2687 commit 3bf2cef453d6ee0d6aece0e8e91a049d556e2687 Author: Göktürk Yüksek <gokturk@gentoo.org> AuthorDate: 2018-04-04 11:01:32 +0000 Commit: Göktürk Yüksek <gokturk@gentoo.org> CommitDate: 2018-04-04 11:22:40 +0000 app-forensics/sleuthkit: bump to 4.6.0 This bump starts to bundle libewf since app-forensics/libewf is about to get treecleaned (see #547418). The upstream only supports libewf version 20130128[0], which is not available in the tree. Because they haven't clarified the supported libewf versions until recently, we have been depending on any version and it's been causing build failures (see #607968). Although there are compatibility patches to support later versions of libewf in tsk, they are not supported by upstream. There's little to no expactation of tsk updating its code to use the latest libewf since they've forked the version 20130128[1]. In terms of stability, 20130128 was marked stable in Gentoo at some point[2]. There are no known security vulnerabilities. If in the future the upstream fork diverges, we can add it to the tree as a new package and establish a proper dependency relationship. Note though that the ewf USE flag is masked by treecleanears[3], so this change currently has no visible impact on users. [0] https://github.com/sleuthkit/sleuthkit/blob/sleuthkit-4.6.0/INSTALL.txt#L44 [1] https://github.com/sleuthkit/libewf_64bit [2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-forensics/libewf/libewf-20130128.ebuild?revision=1.6&view=markup [3] https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/base/package.use.mask?id=f103062521b15cddc67a822a7a25640d3fbab76a#n65 Bug: https://bugs.gentoo.org/547418 Bug: https://bugs.gentoo.org/607968 Package-Manager: Portage-2.3.27, Repoman-2.3.9 app-forensics/sleuthkit/Manifest | 2 + app-forensics/sleuthkit/sleuthkit-4.6.0.ebuild | 229 +++++++++++++++++++++++++ 2 files changed, 231 insertions(+)}
@treecleaners, I retract my objection. I have no problems with this package being removed.
There are significant uses for libewf beyond linking from Sleuthkit, namely generating E01 and Ex01 disk images for evidence preservation. Recent versions add significant performance and stability benefits over the 2013 version that Sleuthkit has inexplicably locked to. While I find the removal decision regrettable, at least the tooling is available in the Pentoo overlay.
@goturk - a late thought, if you're bundling libewf with >=sleuthkit-4.6.0, is it statically linking, or are you laying down the entire package, which will introduce file conflicts with third-party packages?
(In reply to RB from comment #11) > @goturk - a late thought, if you're bundling libewf with >=sleuthkit-4.6.0, > is it statically linking, or are you laying down the entire package, which > will introduce file conflicts with third-party packages? It's strictly statically linked to libewf.a and no files from libewf are installed to the system.
(In reply to RB from comment #10) > There are significant uses for libewf beyond linking from Sleuthkit, namely > generating E01 and Ex01 disk images for evidence preservation. Recent > versions add significant performance and stability benefits over the 2013 > version that Sleuthkit has inexplicably locked to. > > While I find the removal decision regrettable, at least the tooling is > available in the Pentoo overlay. You know it wouldn't get treecleaned if somebody steps forward to maintain it ;)
(In reply to Göktürk Yüksek from comment #13) > You know it wouldn't get treecleaned if somebody steps forward to maintain > it ;) I've been on a Gentoo packaging hiatus for a while, and Pentoo satisfies my specific needs (although the libewf situation isn't quite as dire as blkshv points out in the see-also link). If they stop for some reason, I'll reconsider my hiatus.
libewf-20171104 now in the tree, but not all the other libyal libs yet.
Please remove the use mask as well, /usr/portage/profiles/base/package.use.mask: # Pacho Ramos <pacho@gentoo.org> (13 Mar 2018) # libewf is going to be removed, bug #547418 app-admin/testdisk ewf
